Volution

Although Linux is powering a huge percentage of the Internet’s Web sites and running on countless workstations and servers in the corporate world, the operating system still suffers from an image problem compared to commercial UNIX versions such as SunSoft’s Solaris. The reasons are many, but one of the most important as far as the corporate IT culture is concerned is the lack of complex network management tools under Linux. Caldera aims to change all that with Volution.

Volution is, according to Caldera’ literature, “a Web-based Linux management product for system administrators. Volution offers administrators the capability to effectively manage large systems through health monitoring, software and hardware inventory, printer management, and software distribution.” In other words, Volution duplicates many of the features the IT people have loved on Sun and HP workstations, moving it to the Linux platform.

In English, what does Volution really do? In its simplest form, when properly running Volution provides a system administrator with two things: a graphical view of the network and all its components, and it allows for software changes to clients remotely. There is the ability to implement some policies for client machines, but the user can override these anyway. The main use for Volution, running off a Linux machine, will be to get an overview of a Linux-based network and its resources, and to handle autoimated software updates.

The Volution architecture is rather complex, as you would expect of a package that aims to do so much. The keystone around which Volution is built is the Lightweight Directory Access Protocol (LDAP). Volution uses LDAP to store the information about objects on a network. The system administrator can use Volution to establish relationships between the objects on the network, and to store this information for future use. The primary object in Volution is the computer, which is represented as virtual computer objects when managed by Volution. Relationships between computer objects and any other object in the network (such as a printer, CD-ROM jukebox, modem pool, and so on) can be set up in two ways: one on one (a computer directly connected to the object), one to many (one network resource can be linked to a group of computers at once, either as a particular group of machines or as a container drawn on the screen encompassing everything within the boundaries). Groups of computers can be set up for any reason, and managed as a single group.

The other components of Volution are OpenSLP, the Volution client and server services, and DENS. OpenSLP is the Open Service Location Protocol which is a proposed standard for services on a network to make their presence known and for clients to detect and accept services. By running OpenSLP, Volution can detect clients, services, and services on the network without extensive manual configuration by a system administrator.

The Volution client and server are designed to handle communications. The client software is installed on computers managed by Volution and a daemon on that machine runs all the time. The Volution server uses OpenSLP, DENS and a “computer creation daemon” to run the Volution system. DENS is the Distributed Event Notification System and it is responsible for notifying the server of any changes to a client, as well as the polling of a network for resources. The computer creation daemon is used by Volution to authenticate systems on the network, and to search for any new or changed resources.

The final component of Volution is the management console, which is the primary interface used by system administrators. The management console shows the relationships between network resources, and allows management of them individually or as groups. The management console is based around a series of Java applets and servlets, and hinges on a Web server (Apache is highly recommended by Caldera).

Installation and configuration

Volution requires a fairly hefty machine to run properly. Although Caldera claims an 80486 with 40MB RAM is a minimum, our tests of the gold release showed poor performance even on a mid-range Pentium with 64MB RAM. As a realistic minimum for the server and management console machine (which can be different computers or both on the same workstation), a Pentium III at 350MHz and 128MB RAM should really be considered a minimum setup.

The documentation that accompanied our gold release of Volution is a spiral bound Administrator’s Guide. Whether this is all the documentation that ships with the final release is unknown at press time. The document does a good job of guiding you through the installation and configuration process, and an acceptable job of showing the different actions you can take at the management console. A few more screen shots would have been helpful, but the document is good enough for most administrators to use effectively.

In addition to one of the supported Linux distributions (Caldera, RedHat, SuSE, or TurboLinux), you will also need to load a Web server such as Apache. The other necessary software components (Java JDK, Apace JServ, and OpenSLP) are included on the Volution CD-ROMs. The Volution system works best with OpenLDAP (included with the application), although it can also run over either Novell NDS eDirectory or Netscape’s iPlanet. iPlanet can be downloaded free of charge from www.iplanet.com and the Linux version of eDirectory is included on the CD-ROM. Prior to installing Volution, OpenSLP, iPlanet or eDirectory must be installed and running.

Most system administrators will install Volution using a GUI terminal. We installed our gold release under both GNOME and KDE with identical results. Prior to installing under any GUI, the Apache Jserv package should be installed. The Volution CD-ROM will autorun under KDE and GNOME if the autorun flag is set, or an install script can be triggered from a window. The installation process is well documented in the dialogs that appear, with descriptions and recommended actions noted in some cases.

The first step is to select the components to be installed (directory server, client, server, or management console) or any combination of the four. Next, you select the directory service (OpenLDAP is the default for most setups), followed by the configuration screens for the selected service. The process of installing and configuring OpenLDAP, eDirectory or iPlanet is easy enough for even new system administrators. After entering a fully qualified domain name for the target machine, the server configuration window asks for passwords and repository locations. Finally, the management console window asks for basic directory information and server ports (defaults are fine for most installations), and the scripts then install the required components and configure them based on your responses. The entire process will take about twenty minutes, about five of which require human interaction. The installation routine works smoothly and the configuration can be changed manually if mistakes are made. For client machines, you need only install the client software, which takes much less time.

Using Volution

System administrators interact with Volution through the management console that is launched in any browser (Netscape was used in our tests). The browser window is divided into two panes, one a Windows Explorer like interface to all objects, and the right pane showing any commands available for highlighted objects, as well as other functions as needed.

The overall view of the network expands and contracts using plus or minus signs next to each machine or resource, or each group or container. You can rearrange the objects into groups any time you want by dragging and dropping. On larger networks, the view gets very busy when items are expanded, so containers are a useful way of embedding many items under one simple, recognizable name. By default, a number of containers are created by Volution when installed. These include the software repository that holds RPMs, as well as policies and profiles for objects on the system. Each computer is listed individually, leaving it up to the administrator to assign groups or containers for them.

For each object selected in the overview, the right pane shows several tabs that can be clicked to provide different management options. Each machine can have links to profiles, policies, and scheduled actions. Profiles change the software configuration on a client and can be used to install and uninstall software components. Policies affect the configuration of the machine. We’ll look at policies and profiles in more detail below.

Creating organizational units is quick with Volution, and can be used to organize objects into hierarchical structures. A search system built into the management console allows you to locate objects based on a number of criteria. In practice, the search routines were slow and not too useful, although it does allow location of a misplaced resource.

The primary use of Volution, other than obtaining overall views of the network, will be to perform particular actions on objects managed by the software. The management console lets you set particular events to be performed on any managed object, and you can set a particular execution time or execute immediately. All such activity is done through the management console, using links. Links permit an action, policy or profile to be associated with a single resource, group of resources, or a container, and are established using an Add Link button. Actions are usually combined with a policy to tell Volution what should be done to a particular client, such as installing or removing a package. Two links need to be set up to an object for this kind of activity: one for the profile and one for the action. This can be a little bothersome at times and should be possible with one system administration action instead of two.

Policies affect machine configurations or some component of the Volution network. Changing the DENS policy will be one of the first steps many administrators perform, since clients will default to notification mode in all cases. This can cause network congestion on larger networks, so timed polling is often a better approach, and requires a new DENS policy to be set up. The process for creating policies is simple enough through the management console, and actions and events can be associated with policies.

Profiles are used to add or remove software components from client machines. This requires the Volution engine to know which RPMs are available, and where they are stored on the network. This information is embedded in the profile and linked to the machines to be changed along with an action telling Volution when to perform the updates. Setting up the software repository can take a while, but once done allows an entire network or groups of machines to be remotely updated. When the network grows large, the timesavings this step alone implies is enormous.

The HTML-based interface to Volution means that any client with a browser can be used for the management console, not necessarily on the server. The HTML and Java interface is good but not blazingly fast in screen refresher or information updates. Also, we had a few Java problems on two RedHat systems where an applet or servlet would report an error. In most cases, refreshing the browser and trying again solved the problem. This problem could be fixed in the shipping releases.

There appears to be no performance difference between the supported Linux implementations. Caldera’s OpenLinux actually seemed to run Volution a little slower than either RedHat 6.2 or RedHat 7.0, and SuSE. Optimizing the kernel for the Volution server daemons may increase speed for the Volution applications overall, but the effect of the tweaks we tried was small. Volution’s daemons do imposed a bit of a load on the server system, especially when the network map is being created. Client performance was virtually unaffected by the client daemon, although OpenSLP does involve a bit of a slowdown on heavily loaded or underpowered systems.

Living with Volution

The learning process for Volution is not really steep, but it does take a little while to get used to the interface and its abilities. The next few releases of Volution will probably see the interface change to correct some of the awkward steps, and to add better management abilities, but this first release does the job acceptably. Installing Volution on the machines in a network, and implementing OpenSLP takes a while, so there’s a bit of overhead involved in the network before Volution can be used.

Volution is not a fast system, either from the snooping of network resources point of view or that of managing the system through the console. It will save time for network administrators in the sense that software updates are easier to perform on large numbers of machines, but automated software updating has been available through other vehicles before. The policies and profiles implemented by Volution can be modeled through other approaches, as well.

Working with Volution on a regular basis is pleasant, but after you’ve done software updates on all your clients, Volution doesn’t offer as much flexibility and capability as networking management software currently available on other platforms. Those who wish to compare Volution to UNIX or Windows NT based network management software will find Volution a subset for the most part, although the potential is underneath the surface.

In short, Volution isn’t really the overwhelming management tool Caldera touts it as, but the base is good and effective, and the promise for the future is better. For software management, Volution is very good. For network management, Volution falls down. SNMP capabilities are almost nonexistent and really need to be added to make Volution competitive with the other operating systems. Linux has needed a product in this niche for a while, and Volution is the first pass at such a product. Future versions should make it more useful and attractive for administrators.