Review: Software For Managing Server Config Changes

Managing an application infrastructure can be demanding, especially in a tiered deployment architecture. If multiple Web and application server configurations are involved, the problems associated with maintaining consistency across the organization are compounded.

MValent's Integrity can help harried administrators by providing a centralized repository from which all text-based configurations can be managed and, in some circumstances, automated. Integrity 3.0 lets you perform audit configuration changes, and capture and centralize configurations. The program also notifies you immediately when a change is made.

Integrity, which is closely aligned with the ITIL (IT Infrastructure Library), organizes its features and functionality into three categories: configuration, change and release. In short, it provides mechanisms for managing configurations, tracking changes and provisioning configurations across the enterprise.

Specs and Setup

Integrity has some strict hardware requirements, and I scrambled to supply a machine that would meet its need for a dual 3-GHz processor with 3 MB of RAM in our NWC Inc. business applications lab in Green Bay, Wis. (For more on our 24/7, real-world production environment, go to inc.networkcomputing.com.) Unfortunately, the Windows 2003-based beta version of Integrity I loaded required a separate installation process for its embedded Oracle database. However, mValent says the final install program will be completely integrated.

Integrity can manage virtually any text-based configuration file. It's designed to suck in configurations from application servers, but also supports a wide variety of other infrastructure devices, including Web servers, routers and switches. For each machine I wanted to manage, I had to perform some setup within Integrity. Its power lies in its ability to both read and write managed configuration files, so you must make sure the access method includes write access for the specified user.

Access to resources is specified through authentication packs, which specify how Integrity should retrieve the configuration file--through FTP, SSH (secure shell) or a UNC (Universal Naming Convention). Integrity's power lies in its ability to both read and write managed configuration files, so you must make sure the access method includes write access for the specified user.

To test this, I specified a WebSphere 6.0 automation pack and then pointed Integrity at a WAS 6.0 directory over UNC. Integrity initially had some problems pulling in our WebSphere configuration--differences in configuration format between WAS 5.1 and 6.0 were the culprit--but mValent engineers quickly remedied the problem, and we moved forward without further delay.

Integrity supports a lengthy list of possible assets, including Apache Web server, BEA Systems WebLogic, IBM WebSphere, Microsoft Internet Information Server and SQL Server and Oracle databases. Integrity also provides an import mechanism similar to that found in Excel that lets you specify how the configuration file should be read--comma delimited (CSV) or XML-based--and then parses the file. In my tests, Integrity handled simple CSV or key-value pairs (Windows INI style) with ease.

Integrity organizes configurations into projects, which helps when using the comprehensive comparison tools. I configured two projects, one to hold my WAS 6.0 and Apache production configurations and another to represent a development or quality assurance (QA) environment. By selecting the Apache httpd.conf from both projects, I could compare the two (see screen, page 20).

One glitch: It's not readily apparent which configuration file belongs to which project. For each piece, such as DocumentRoot or Listen, I could ignore key-value pairs on a global, asset or session basis. This is useful if you need to ignore values that must be different across configurations, such as host-specific values, but still view base-configuration differences that may be causing problems or deviating from organizational standards.

The interface clearly shows configuration differences through bright color schemes and uses the same view an administrator would to edit the configuration file. This lets admins immediately change one or both files without moving between the config files in the hierarchy. Comparisons can be executed against configuration files from different machines or across versions of a single configuration file from a single machine.

Trail of Changes

Tracking is accomplished through a polling mechanism that occurs on a scheduled basis, so in a large network changes will only be detected periodically. Once a configuration is loaded, it's a simple task to enable tracking, which then logs each change to the configuration file whether it occurs out of band or from within Integrity's role-based structure.

I enabled tracking for my production WAS 6.0 configuration and then modified the configuration manually through the WAS administration console. Integrity picked up the change, shot off an e-mail and further notified me through the use of the alerts tab within the Integrity console. I scanned the differences and then was given the choice of provisioning the WAS configuration stored within Integrity back to the server or accepting the change and creating a new version within Integrity. I decided to provision the original configuration back to the server. When I reloaded the WAS admin console, it notified me--as expected--that the configuration had changed.

Functions such as copying, cloning, provisioning and versioning configurations are a breeze with Integrity, though the interface is cluttered by the extensive hierarchical nature of product configurations. Integrity continually polls for config changes through the defined authentication packs, and can be scripted using Python to provision configurations on a scheduled basis.

Administering Integrity

You can control configuration administration through Integrity's role-based authentication and authorization system, which provides a delegated admin environment. For even finer control, you may override permissions at the file level, which enables an administrative hierarchy of a single resource type. For example, I designated permissions on both WAS environments (production and QA) and then further dove into specific configuration files, giving one administrator access to modify the configuration for the production environment but not the QA.

Overall, mValent's Integrity 3.0 performed as advertised. The extensive hardware requirements may make the cost of acquisition less than appealing, but the reduction in risk, management time and troubleshooting may be well worth the $60,000 investment.

Lori MacVittie is a Network Computing senior technology editor working in our Green Bay, Wis., labs. She has been a software developer, a network administrator, and a member of the technical architecture team for a global transportation and logistics organization. Write to her at [email protected].