Timothy
Parker Consulting Incorporated
|
|
|
|
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. |
|
Send mail to
tparker@tpci.com with
questions or comments about this web site.
|