| OPENBENCH LABS SCENARIO |
Under examination
Network-based system management
What we tested
Volution 1.0
www.caldera.com
How we tested
Server and client systems running Red Hat Linux v6.2
www.redhat.com
Key findings
- Volution provided a good basic system for monitoring and managing distributed Linux systems via an OpenLDAP repository.
- More notification options, such as paging, are needed for health-monitoring actions.
- The LDAP repository is automatically populated only with data associated with the Volution clients and not the Volution server.
|
When you install Linux on a system, you get a fairly robust set of tools that allow you to do common system-management tasks. Unfortunately, this fact holds true only for the local system. What do you do when you have to manage and distribute software to remote systems? If you have tens or perhaps hundreds of systems on your network, you're going to need a lot of help.
Riding to the rescue of the network-challenged systems manager is Caldera, which has introduced a systems-management tool called Volution. With standards-based Volution, system managers can perform common management tasks-including hardware and software inventories, software distribution, printer management, and system-health monitoring-on any networked workstations and servers running the Volution client. In essence, Volution opens the door to wider corporate use of Linux by providing a rudimentary analog to Microsoft's SMS.
After working extensively with Volution, we can confirm that it does everything it promises. If your shop is having trouble keeping track of its systems and you can't visit every system in person, Volution might very well be the ticket, albeit marked with a steep price tag: $2,995 for a Volution server and 10 managed clients. Caldera chose to make Volution 100% standards-based, and they delivered on this choice. If you check under the hood, you'll find the Lightweight Directory Access Protocol (LDAP) at the center of a Volution installation. The LDAP directory stores all the information about the installation and the systems and software that make up the network. Prior to installing Volution, an LDAP directory server must be installed and running on your network.
Volution supports three different LDAP directory servers-OpenLDAP v2, Netscape iPlanet v4.11, and Novell NDS eDirectory 8.5; OpenLDAP and NDS are included on the Volution CD. If you choose to use OpenLDAP, the installation program will install and start the OpenLDAP server before moving on to install Volution. If you want to use the Netscape or Novell directories, you'll have to install them first and make sure they work before running the Volution installation program.
Volution itself is composed of four separate components: OpenSLP, Client, Server, and Management Console. OpenSLP is a standards-based protocol for advertising and finding services. This protocol allows each Volution client to automatically find any service that it needs without having to individually modify each client's configuration file.
Each system set to be managed by Volution must have the Client daemon installed on it. The Server is made up of two daemons, the Distributed Event Notification System daemon, which handles client event notification; and the Computer Creation Daemon, which handles requests to add computers to the LDAP repository. To access the LDAP directory and actually manage your systems, you use the Management Console, a Java application that runs under Apache and Apache JServ.
The different components of Volution can be installed on one server or distributed across multiple servers. For our testing, we chose to install all of the server-side components on a single system. Nonetheless, as a standards-based tool, Volution can perform no better than the level of its underlying building blocks, and some of them hold this product back.
The Volution Management Console is an Apache JServ application and needs Apache with the JServ extensions to be up and running. JServ needs the Java 2 SDK installed before it can be installed. Fortunately, both JServ and the SDK are on the Volution CD and installing them was easy. Unfortunately, configuration was a different matter as we delved into the intricacies of Apache JServ and its unforgiving ways of dealing with our misspelled datapath. So beware: The Volution install does not take care of everything for you.
Once our JServ problem was solved, we ran the Volution installation program on a server running version 6.2 of Red Hat Linux-version 7.0 is not yet supported. Since we chose to install the OpenLDAP directory server, we then had to configure the LDAP repository. Entering the name of our organization and the password for access the LDAP directory was the minimum information needed for the installation to continue to completion.
We now had a functioning-albeit somewhat useless-Volution installation running. We say "somewhat useless" because Volution's default position is not to automatically store information in the LDAP directory about the server on which it is installed. For performance reasons, Volution assumes that the local computer will be managed directly. While Volution automatically adds the necessary information about client systems into the LDAP repository, you must manually place the server's information into the repository to manage that too.
The task of managing systems with Volution is accomplished through the Management Console, a browser-based application. We tested all but one of the common system-management tasks that Volution could perform: We didn't test its ability to manage printers, since we didn't have one set up.
We launched Netscape Navigator on our server and entered the appropriate URL to access the Management Console. The first screen we saw was the login screen. Here we entered a fully qualified username, in LDAP format, plus our password. We clicked on the login button and were taken to the main Volution screen.
In the main screen there's an LDAP directory-tree control on the left and a main content area to the right, which initially is blank. We explored the directory tree and found the computer on which we had installed the Volution client. There was nothing under the computer at this time, but we took care of that in short order.
Volution can work with three major categories: Actions, Policies, and Profiles. The five different actions that Volution can perform are hardware inventory, software inventory, install software, health monitor, and printer configuration. Each of these actions has a script associated with it and must be linked to a container, computer group, or computer to be executed. The install software, health monitor, and printer configuration actions must also be linked to a policy or profile. Each action has a schedule flexible enough to allow actions to be performed pretty much at any time and any frequency you desire.
The easiest actions to kick off are for hardware and software inventory. We started by defining a hardware-inventory action, which was scheduled to run immediately and every 24 hours thereafter; we linked it to sloth, our five-year-old client computer. After a few minutes we drilled down through the directory tree and found that two new containers had been added beneath sloth: hardware inventory scans and hardware.
The hardware inventory scans container had a single entry with the date and time the hardware inventory had been run. When we clicked on the entry, a list of the hardware items present on our test system, such as CPU, hard disks, and monitors, was displayed to the right. Each time the inventory was run, a new entry was added to the container. These entries simply identified what hardware had been added to or deleted from the system. The hardware container maintained the list of all current hardware on sloth. Examining these entries, we found a wealth of information about the computer. We especially liked the graphical pie charts that showed free space on the system's disk drives.
Satisfied with the function of the hardware inventory action, we next tried to schedule a software inventory. This was done in much the same manner as the hardware inventory and achieved similar results. We should point out that software inventories often take longer than hardware inventories since the client daemon has to execute an RPM command for each of the installed software packages on the system. In the case of our very minimal client, the client daemon still had to query 175 separate RPM packages.
The results of the software inventory were analogous to the hardware inventory. We had two new containers: software inventory scans and software. When we browsed the software container, we found a single entry called RPMs, which contained a list of all the RPM-based software packages that were installed on the system. Clicking on any of the RPM entries provided a listing similar to that resulting from the "rpm-qi" command.
The inventory actions are the simplest and most straightforward to execute. While the ability to find out what software is running on all of your systems is interesting, it is of limited use. We next moved on to one of the most complicated and useful actions that you can perform with Volution.
The real power of Volution, in terms of software, is its ability to distribute software to remote systems for installation or upgrade. The only drawback we see to this action is that it only works with RPM packages. If the software is installed through some other mechanism, you are out of luck. In order to install software with Volution, you must first make the RPM package available on a publicly accessible FTP directory. Next, you must register the package using the rpmadd utility, a command-line utility that places information about the RPM package in the LDAP repository. In our tests, we used rpmadd to make Volution aware of the Java 2 SDK v1.3 package and the Forte for Java Community Edition package, which depends on the Java 2 SDK.
Unlike the inventory actions we created before, it's not enough to simply link the Install Software to a computer or container; instead, you must first define a profile for the software you want to install or uninstall. The profile holds information about exactly what you want to do-i.e., install, upgrade or freshen; which RPMs are affected, along with any pre- or post-install scripts you want executed.
We defined a profile for the Java 2 SDK and linked it to sloth. We then created an install software action and set it to run immediately; we linked it to sloth and clicked on the submit button. After waiting a few minutes and watching the lights flash on our network switch, we checked sloth to see if the software had been installed. Presto, there it was. We then repeated the process for Forte for Java.
Of all the things that Volution can do, we believe that automated software installation will be the most useful to system managers: Not only is it a tremendous time-saver, but it also obviates the need for system managers to personally visit every system. Our only problem with the process is that there is no automated way to find out if the installation was successful on each client. Actually, about all that you can do is to perform a search for the package and to note all of the remote systems that do not have it installed.
Volution's health monitor action lets you head a system failure off at the pass. First you define a health monitor policy, which tells it what to monitor on a system or systems, such as number of processes, CPU utilization, or free space on a mount point. You set thresholds for sending a notice, warning, or alert by e-mail to the address specified in a gateway policy. Volution uses policies stored in the LDAP repository to define various things such as the place to send e-mail (gateway policy), and the health monitor configuration (health monitor policy).
We tested this function and found that although it works, it wasn't as useful as it could be. We'd like to see the threshold values, not merely whether the policy was exceeded, stored in the LDAP repository. In this way, system health could be monitored over time. The e-mails are helpful, but greater flexibility could make this function more useful as well. On other platforms, this function often offers such options as the ability to page an administrator when a threshold is exceeded.
While it is true that Volution does everything that it is supposed to do, we can't say that it does it all spectacularly well. That doesn't mean Volution isn't useful: It may well be one of the best tools currently in the Linux market. Still, in its current state it is rudimentary. For one thing, support for various Linux distributions is very limited. In addition, the management console's user interface could be better. For a first release, however, Volution is a promising product; in time, it could grow to be a great one.
| 
