One of the most serious problems facing larger organizations considering using Linux and Open Source application stacks is managing the software environment.

The basic Linux system has adequate tools to manage a single machine, or even a small group of machines, but once the population of these machines reaches into the tens and hundreds and spreads across multiple application areas and multiple locations the management task becomes harder.

When the complete system configuration includes items not directly supported by the Linux distribution, the tools provided with the system are often not enough.

Management tasks that become non-trivial for larger installations typically are:

• Configuration management: In larger deployments it's usual to have multiple defined configurations, each specific to a given task. Each configuration will typically have loaded only those components required for the task for which the configuration is defined, and configuration parameters in various files defined to tune the system to its specific class of task.
• Application deployment: New application deployment, or an upgrade of an existing application, in itself not typically a difficult task, can have implications for other parts of the system if any changes to the configuration are required due to dependency requirements of the new/upgraded application. Usually not particularly difficult to manage when the application is one directly supported by the Linux distribution vendor, which will ensure that dependencies are met without disrupting the rest of the system, but potentially much more complex when it's not directly supported.
• Loading the software on to multiple (potentially hundreds) of machines, often having to take into account factors such as performing the task when no user is present, stopping and starting system services, and possibly needing to reboot the system if any OS components are modified.

Jefferson County in Colorado makes heavy use of Linux where F/OSS makes good sense. With around 60 servers to manage, the systems administrator Jeff Falgout and the team of systems engineers that he leads need all the help they can get in automating and managing configurations used for multiple purposes.

The servers run mainly Red Hat Linux 8, with a small number of SuSE servers thrown into the mix, but are slowly transitioning to Red Hat ES and AS. The application stack includes Novell e-Directory and some test installations of Fedora Directory Server (the ex-Netscape/AOL directory server closely related to Sun's JES directory server). Other services include e-mail with sendmail and SpamAssassin in conjunction with mail-scanner providing spam and virus filtering. These provide front-end filtering and routing for Novell GroupWise. Apache Web servers are used in conjunction with Tomcat application servers. Proxying/caching of user Web access is covered by Squid with appropriate anti-virus components installed. Add in a few in-house developed applications and the result is a very capable software stack, but one that if not managed correctly could give any systems administrator, as well as the IT manager, sleepless nights.

Using Aduva OnStage to manage these configurations takes a lot of the hard work out of the process and lets Jeff sleep comfortably at night.

Jeff has few worries about those components supported in the base distribution of any of the systems. With the focus that Aduva puts on the base Linux distributions, the Aduva KnowlegeBase, which OnStage depends on to ensure that all dependency requirements are met correctly, faithfully tracks the changes that distributions make as new revisions of various components are released and, especially importantly, as security issues arise. The Aduva KnowlegeBase contains all the required information to keep distributions up-to-date, avoiding known security issues or warning where avoidance might not be possible with currently available packages, while maintaining correct dependencies throughout the system.

The tracking between the Aduva KnowlegeBase and the Linux distributors' own dependency/update systems is so good that Jeff feels comfortable using them interchangeably, but in practice uses OnStage as a replacement for Linux distributors tools, such as Red Hat's to maintain a complete and accurate record of the current state of every machine. On systems that have the Red Hat applet that warns that there are system updates available from Red Hat, the applet will occasionally show red, indicating pending updates, but after the next run of OnStage, those same applets will once again show green, illustrating the close tracking between OnStage and the Linux distribution's own systems.

For stack components not directly handled in distribution base systems, Jefferson County maintains its own private extension to the KnowlegeBase, containing information on dependency requirements of those components and a repository of the RPMs containing them. All the in-house applications are managed this way, as is Tomcat, which is not part of the Red Hat base system and so not automatically included in the Aduva KnowlegeBase for Red Hat.

OnStage handles the configuration management and automatic updates of components in that configuration as they become available. Not only are system and application binaries managed, so are the various associated configuration files. OnStage can be used to build a system "from bare metal" based on any one of these configurations, or for the transformation of a system in one configuration to another. Changes are recorded and, if required, can be backed out very simply. Configurable rules can be used to schedule updates to specific machine groups and can take account of requirements such as waiting until there's no user and doing a system reboot at the end.

The ability to clone a configuration on a machine is something that Jeff uses when major updates have to be tested. The new configuration can be tested and tuned, then that identical configuration is applied to specific groups of machines once testing is complete. OnStage uses the KnowlegeBase, both the central Aduva copy and Jefferson County's own, to determine exactly which packages to remove and which to install to ensure that existing systems end up being identical to the staging/test system(s).

When asked if he trusted OnStage enough to consider skipping the verification staging build of significant changes before deployment, Jeff responded like any systems administrator faced with applying untested patches to many production system would, saying, "No, I have faith in the system, but not that much!" Then after reflection, he added, "Actually, we do allow the system updates to go straight through without testing and have never has any issues, so I guess I do trust it after all."