Adrian Nakon

This final article is a brief review of the steps that were examined across all of these articles.There is much to consider when patching your Linux environment and it's well worth planning out the approach before you start.

This article is the last in this series and discusses how to roll back the patches that have been made on a Linux system.

So now, after all the preparation we are ready to actually apply the security patches!There are a number of options we have for patching - based on how much we would like to patch (the scope).

In this article, we're going to take a look at Cataloging the state of a Linux system - both before and after a patching run.

Continuing on with the series, this article looks at some of the powerful tooling available with the Linux 'rpm' command.

This article is a little different from the previous ones - in that it takes a look at some of the useful utilities 'yum' provides in order to support the patching work.

This next article in the series discusses how to enable and disable locally available repositories.

Continuing on with the Linux patching series, this article looks at how to make sure the newly set up patching repositories are kept up to date on a nightly basis.

So, onto part #2 of this series - setting up the Linux repositories that will be accessed from our VMs.

As we all know, patching is an important and necessary part of the Support work we do. In terms of Linux, patching of Linux servers is a vital part of ensuring that there are no security holes that could be exploited by outside attackers.

Hi Everyone,

In Part #1 of this series : Removing SSH 'pem' files from Jump Boxes in AWS - Introduction, I described the problem of SSH management and started on a solution to restrict the spread of SSH key distribution across the servers in an environment.

Hi Everyone,

During the work of a major Client Project, one issue that was continually on my mind was how we were using SSH 'pem' files on the non-prod and prod jump boxes.