GNU/Linux software updates for the enterprise

By apexwm, 14 June, 2011 17:24

Software updates are one of the main areas of IT, mainly because of continuous security and enhancement updates. Microsoft usually releases a huge number of security updates each month, and even though they get criticised for this, GNU/Linux has a high number of updates as well, particularly Fedora which is treated as beta or cutting edge versions of free and open source software.

In Windows, software updates can be very complex to manage. In the past, SMS filled in the gaps and provided a platform for installing software and updates in the enterprise environment. But when dealing with 3rd party software like Adobe, Java, or any other vendor, the update command and switches can be totally different for each 3rd party package, which adds much more complexity. Windows Software Update Services (WSUS) and group policy are default mechanisms in place that can handle enterprise software management in Windows. But due to the complexity, some (very expensive) 3rd party solutions have appeared to fill in the extra gaps, like the Kace/Dell Kbox which is one of the leaders in this area. WSUS only handles Microsoft software, so group policy or SMS must be used for deploying other 3rd party software.

In GNU/Linux, with distributions like Ubuntu, Fedora, and others, there are default mechanism in place that are very powerful and offer a LOT of flexibility. In Fedora and Red Hat Linux specifically, the RPM (Red Hat Package Management), and Yum (Yellowdog Updater Modified) systems are two very powerful pieces of software. Yum is the tool that caches package metadata and downloads and installs packages and updates. Repositories are set up which yum connects to and pulls packages from. Documentation is available on setting up your own software repository, which you can automatically mirror the official Fedora repositories, or you can manually add packages yourself, after they are tested.

For this example, imagine setting up a manual repository so that packages would be deployed to clients, after they have been tested. This is a very common scenario in the enterprise world for keeping clients up to date. On a test machine, yum will install and cache packages in /var/cache/yum, when the value "keepcache" is set to 1 in the file /etc/yum.conf. After testing has completed on the test system, the packages in /var/cache/yum can be moved to your manual repository, where your clients are scheduled to check in and install the RPM packages it finds automatically. This involves some setup on the clients, such as a cron script that will pull and install packages on the clients. The clients can also be set to use ssh tunnelling to the repository (if you are concerned with security or exposing your repository to the public Internet), or left unencrypted. Also in this scenario, the default Fedora repositories would need to be disabled on the clients so that they do not attempt to install all of the updates (which may not have been tested yet on your test system).

Also, the RPM system can provide a complete list of packages installed with the command "rpm -qa". And, logs of the RPM installation process are always logged to /var/log/messages. Reporting could be set up to pull this data, however to date I have not discovered a central system for producing these types of reports. This is where the Kace/Dell Kbox steps in and uses a running agent on each client to gather data into a central SQL database.

This is a very vague post as some further setup instructions would be needed, such as here. But the point of this post is to relay that GNU/Linux already has the pieces in place to set up a complete and powerful software testing and deployment environment. What's better about this, is that all software provided with a GNU/Linux distribution (from the operating system to the suite of applications installed) can ALL be handled within the same repository and deployment system. Whether the Linux kernel needs updating, or the OpenOffice suite, it is all done through one central system. In Windows, this cannot be done because the operating system is released by Microsoft, and a lot of additional software is released by 3rd parties so there is no integration and consistency.