A brief discussion and implementation plan for RedHat Enterprise Linux updates and system administration

There seems to be quite a bit of confusion surrounding package management in linux operating systems in current enterprise environments.

up2date has rollback capability and is already installed on all RHEL [RedHat Enterprise Linux] servers All that would be required to centrally manage a RHEL environment would be to push out an updated config file for up2date and point it to a central repository.

Both yum and up2date are just front-ends for rpm management and operate with all the same mechanisms. Here are the current directions to get yum to save rollback information, however, it is supposed to be unreliable (more on that later):

To configure yum to save rollback information, add the line tsflags=repackage to /etc/yum.conf.

To configure command-line rpm to do the same thing, add the line%_repackage_all_erasures 1 to /etc/rpm/macros.

Install, erase, and update packages to your heart's content, using pup, pirut, yumex, yum, rpm, and the yum automatic update service.

If/when you want to rollback to a previous state, perform an rpm update with the –rollback option followed by a date/time specification. Some examples:

rpm -Uhv --rollback '9:00 am'
rpm -Uhv --rollback '4 hours ago'
rpm -Uhv --rollback 'december 25'

Reference: ONLamp, January 22 2006

Rollbacks in rpm are said to be an experimental feature on mailing lists as of just a few months ago, so I believe, some testing of rpm procedure may be in order before boilerplating/finalizing the process. Here is a note about yum compatibility as of October of last year:

P.S. Yum supporting rollbacks is not something Seth Vidal is looking into, but the more stable they get and the more people start using(and carefully crafted patches to yum) may sway Seth’s opinion. Thereal problem is that most people don’t work within the confines of the Telco space so they don’t really understand our needs. While their all looking at network depsolvers (which is a good thing) these solutions seldom work well for vendors of telco companies because they typically have strong seperation of their telephony networks and the internet.

A Comparison of yum and up2date clients:


  • Both front ends to rpm management
  • Both can source yum, redhat, and apt repositories
  • Both use standard rpm pgp signatures
  • Neither require rhn registration, though up2date is configured to use it by default.


  • (still looking for pros)


  • Not supported by RH.

If running unsupported software was acceptable to your enterprise, you could save a lot of money by running unsupported RHEL by using CentOS or Whitebox and updating from internet sources.


  • Supported by RedHat Corporate
  • RPM rollback is optional and available in configuration. This is likely a requirement in your companies change management process.


  • None really.

There may be some yum client options available that up2date does not have, but I have not been able to find any examples.

Current is a tool that can manage yum, up2date, and apt archives and allows granular control and automation of repositories and is described as such:

..an open source Advanced Management System for Linux machines. This is a web based system administrator’s tool that is capable of deploying package updates and errata and managing the state of each client. Ideally, we want to be what cfengine is to configuration files to state management. A part of this is to implement a correct server for all of Red Hat’s excellent up2date tools and be able to scale to thousands of machines.

Repository setup examples for a variety of methods:

I believe that a best practice checklist would be similar to the following:

  • Make a patch management repository for each supported platform.
  • Make groups for different linux server profiles to standardize configuration and patch level: webservers, databases, applications, infrastructure, etc.
  • Establish rpm testing/certification environment to ensure stability in production.
  • Automate updates to linux hosts.
  • Configure stock installations to update from internal sources.
    Have all clients check for updates in a tested repository for regular updates via a process like: cron “up2date –u” on a weekly/daily/monthly/quarterly basis
  • Update repositories with tested updates for each server group.
  • Document process for rpm rollback for operations in case of update QA failure.
  • Get buy-in from operations and enterprise security management on the update and QA process to be performed in regularly scheduled maintenance windows via automated methods with operational alerting.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s