Hi All,

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.

Things to consider include :

  • Ensuring that all repositories are locally replicated.
    Direct access by servers to the Internet isn't a good idea for a number of reasons, with security and repository consistency being the main items to consider.

  • In addition to the patching repositories (latest versions of the various OL6 repositories), make sure that the repository used to build the original system (ol6_base) and the typically available local repositories are available for any roll back work.

  • Find a server (or clone a VM) where both the patching and rolling back processes can be practiced.
    It's important that you feel comfortable with the whole procedure - ironing out any issues along the way.

  • It's well worth using management software - for example RunDeck - to create jobs that then run the scripts described in this article. Taking this approach is beneficial since RunDeck keeps full log outputs from the jobs it runs - great for review or auditing purposes.

  • Get buy in from the Application owners (who own the Apps that the server runs) to perform some level of testing after the patching. This is an important step to confirm that the patching process has not broken anything.

  • Spend some time how you'll manage Production level patching.

    Plan out both the patching and rolling back cycles and make that information well know - get buy in for it from your customers!
    Remember - unexpected things do happen - and it's best to be totally prepared and expectations set.

    Your customers will more likely forgive a well planned patch roll back, but they will never forgive bad planning and (to them) nasty surprises.

  • Plan your patching and roll back actions in advance and test them.

    It'll make the whole process much smoother and enjoyable.

As for the general execution steps :

Patching.


  • Ensure all applications are down before patching begins

  • Catalog the system before starting (use : catalog-linux-system.sh )

    Take a note of the current Linux kernel version. It's likely that the patching process will update it and you'll need to confirm this has occurred after the patching.

  • Run Patch Security Update Minimal (use : update-minimal.sh ) - to apply the minimal security patches to the server.

    The standard repositories are disabled and patching repositories enabled by this script.

  • Review the results from Update Minimal and create your own version of update-extras.sh (if required) and execute it.

    ** Note ** : Each system is different so your requirements for 'update-extras.sh' is very likely to be different from that shown in this article.

  • Reboot the system.

  • Check with 'grubby' that any new kernel is not the default (and active) one.
    Check Linux logs and 'dmesg' that the system looks good from the Linux side of things.

  • Ask the Application owners (owners of the Apps that run on the server) to confirm that all is good.

  • Catalog the system after the patching.

  • Patching of server complete!


Rolling Back


  • Ensure all applications are down before patching begins

  • Ensure that apart from the patching repositories, 'ol6_base' and the standard 'ol6_lastest' repositories are available.

    Use something like the 'enable-extra-undo-repos.sh' to do this.

  • Catalog the system before starting (use : catalog-linux-system.sh )

    Take a note of the current Linux kernel version. It's likely that the patching process will revert it back to the original kernel level after the roll back.

  • Use 'yum history list' to list out the transactions that require rolling back.

    Take a snapshot of the transaction numbers.

  • Working in reverse order (from the highest transaction number), roll back each transaction.

  • Examine the default kernel with 'grubby'. Set the default kernel to the previous version if required

    (This will most likely need to be done).

  • Reboot

  • Ask the Application owners (owners of the Apps that run on the server) to confirm that all is good.

  • Catalog the system after the roll back.

  • Rolling back of server complete!


And that's it - welcome to the world of Linux patching.

I hope that you have found this series useful.

Of course, there are many variations on the Linux patching theme - what I have discussed here is just one approach.

Have fun and good luck patching your Linux servers!