Caldera Volution Manager is a web-based management product for system administrators. Using the structure of a Lightweight Directory Access Protocol (LDAP) directory, Volution Manager provides cost-effective, remote management for computers. Volution Manager offers administrators the capability to effectively manage systems through health monitoring, software and hardware inventory, printer management, and software distribution.
Information in this chapter helps you determine if your network is configured appropriately to install Volution Manager. Each of these pieces must be in place and operating before you can install Volution Manager.
This chapter includes:
A list of the software required to install and run Volution Manager or require some explanation. See Section 1.1.
An overview of the Volution Manager installation. See Section 1.2.
Worksheets for the information required during the Volution Manager installation. Section 1.3.
This section describes the parts of your network that must be configured or require some explanation before installing Volution Manager:
LDAP (see Section 1.1.1)
OpenLinux (see Section 1.1.2)
DNS (see Section 1.1.3)
OpenSLP (see Section 1.1.4)
DENS (Section 1.1.5)
Firewall (see Section 1.1.9)
Tomcat (see Section 1.1.6)
SNMP (see Section 1.1.7)
SMTP (see Section 1.1.8)
Lightweight Directory Access Protocol (LDAP) (pronounced el dap with emphasis on el) is a "lighter" version of a network directory. A network directory (heretofore referred to simply as "directory") is a structured collection of users, user passwords, and, usually, information about what network resources they can access. Popular proprietary directories include Novell® NDS eDirectory from Novell, Active Directory® from Microsoft, OpenLDAP, and iPlanet from Sun Microsystems and Netscape.
Locating directory objects quickly and accessing the associated object information is essential for directory-based applications such as Volution Manager. By accessing directory objects, applications can execute on a global basis, rather than an individual basis. Using Volution Manager as an example, a network administrator can install applications on many servers at once, rather than one-at-a-time.
On TCP/IP networks (including the Internet), the domain name system (DNS) is the directory system used to associate the domain name to a specific network address. Often however, you might not know the domain name. LDAP allows you to search for a directory object without knowing where it's located.
An LDAP directory is organized in a simple "directory tree" hierarchy and can consist of the following levels:
The Root (the starting place or the source of the tree), which branches out to Countries
Countries, each of which branches out to Organizations
Organizations, which branch out to Organizational units
Organizational units (divisions, departments, and so forth), which branches out to Individuals (includes an entry for)
Individuals (which includes people, files, and shared resources such as printers)
Either the Root, Country, or Organization object can be the topmost object in the tree.
A sample LDAP directory structure follows.
The example shows a very simple directory with an Organization object as the topmost object in the directory tree. Below the Organization object are five Organizational Unit objects.
Organizations and Organizational Units are often referred to as "containers." This is because they contain other objects. In the example above, the Widgets Inc. Organization object contains five Organizational Unit objects.
In addition to containers, LDAP includes individual objects that represent users, computers, printers, or other network resources. Some commercial directory vendors (such as Novell) refer to these as "leaf" objects in the directory tree. For the sake of simplification, we also refer to these as leaf objects.
Leaf objects, along with container objects, are actually entries in the directory database. Each entry has a name called a distinguished name (DN) that uniquely identifies the LDAP object. Objects are structured in the directory tree based on their distinguished names.
DNs are made up of a sequence of relative distinguished names (RDNs). Each RDN in a DN corresponds to a branch in the directory tree leading from the root of the directory tree to the directory object.
The organization of the entries in the directory tree are restricted by their corresponding object class definitions. Therefore, a leaf object cannot contain other objects.
In the example below, the computer "Pluto" is located in the Engineering Organizational Unit, which is located in the Widgets, Inc. Organization.
The previous example shows a very simple directory with an Organization object as the topmost object in the directory tree. Below the Organization object are five Organizational Unit objects.
Objects are named according to their position in the directory tree. DNs follow a structure that is somewhat similar to a computer operating system's file structure, but in reverse order. For example, the netscape.exe file's location on your computer's hard disk might be:
C:\Program Files\Netscape\Communicator\Program\netscape.exe
Note how the netscape.exe program file is on the far right of the file path shown in descending order.
Using the illustration above as an example, the DN for the computer object Pluto would be:
cn=Pluto,ou=Engineering,o=WidgetsInc.
A "cn=" precedes Pluto, indicating that Pluto is a common name or, leaf object. An "ou=" precedes Engineering, showing the container in which Pluto resides. An "o=" precedes WidgetsInc, showing the Organization where the Organizational Unit Engineering resides. Since WidgetsInc is the furthermost object to the right as shown in ascending order, it is the topmost object in the directory tree.
While all LDAP directories have the standard LDAP objects such as Organizations and Organizational Units, many directory-based applications create new, unique objects by "extending the schema" of the directory. Extending the schema means adding new categories of entries to the directory.
Volution Manager adds a variety of new objects including computers, profiles, scheduled actions, policies, and a variety of individual hardware objects. These objects are vital to system management tasks using Volution Manager.
Before you begin installing Volution Manager, make sure your LDAP v3 compliant directory is installed and running. The OpenLDAP directory is installed with your distribution of the OpenLinux® server product.
The Volution Manager installation extends the schema of your directory to include the objects required by Volution Manager.
Volution Manager supports the following LDAP v3 compliant directories:
OpenLDAP v2.0.11 (installed with OpenLinux 3.1.1)
Novell NDS eDirectory 8.5 (included)
Sun Microsystems and Netscape iPlanet v4.13
OpenLDAP is installed with your OpenLinux Server installation. The Volution Manager installation process allows you to configure items required by Volution Manager and extend the schema.
For documentation on administering OpenLDAP, see:
http://www.openldap.org/
NDS eDirectory accommodates geographically dispersed organizations using its hierarchical structure. Be sure to organize your directory tree so that organizational units reflect geographical locations. That way you can manage computers through their organizational unit and reduce administrative time and effort.
Important: Package conflicts between the Volution Manager and NDS eDirectory implementations of the Service Location Protocol (SLP) require that you install NDS eDirectory on a computer other than the one on which the Volution Manager Server (VM Server) is installed.
Before you install NDS eDirectory on a server running OpenLinux 3.1.1, remove OpenLDAP and OpenSLP.
The Novell NDS eDirectory for Linux is shipped with Volution Manager. For documentation on installing and using the directory services, see:
http://www.novell.com/documentation/lg/ndsedir
NDS eDirectory is administered through ConsoleOne, the management interface product. Use ConsoleOne to make the changes necessary for Volution Manager to use this directory. The ConsoleOne User Guide (available at the same URL) provides you with information needed to administer NDS.
The following instructions assume you are using NDS eDirectory for Linux. If you are running eDirectory on another platform, the instructions for using ConsoleOne should be the same, but be aware that they were not tested on the other platforms.
Initiate ConsoleOne by typing the following on a computer with ConsoleOne installed:
/usr/ConsoleOne/bin/ConsoleOne
Authenticate by selecting the NDS tree in the left pane. Select File, then Authenticate.
Enter your authentication credentials.
Expand the NDS tree.
Select your tree name and locate your LDAP Group. (The location of the LDAP group depends on what location you specified as the server context during the NDS installation.) Then right-click and select Properties.
On the Properties of LDAP dialog, check the Allow Clear Text Password checkbox and click OK.
Note: Selecting the Allow Clear Text Password checkbox is only required during the Volution Manager installation for schema extension. You can uncheck the box once your installation of Volution Manager is complete.
Expand your tree by selecting the name beside your tree.
Right click on the name of the organization you use as your Volution Manager organization. This is the root of your directory tree.
Select Trustees of this Object and click Add Trustee.
In the Select Objects dialog, click Public and click OK.
In the Rights Assigned to Selected Objects dialog, click Entry Rights in the Property list.
Verify that Browse is checked.
In the Rights Assigned to Selected Objects dialog, click All Attribute Rights in the Property list, then select Compare and Read and click OK.
Important: Refer to Appendix A for post installation requirements for eDirectory.
In testing environments, iPlanet performed well in situations where:
Volution Manager manages more than 1,000 computers.
Computers are centrally located rather than geographically dispersed.
Actions such as software distribution or inventories for hardware and software are frequently performed.
To install iPlanet, see:
http://www.iplanet.com/
For documentation on installing and using the directory, see:
http://docs.iplanet.com
Once iPlanet is installed, use the following information to start and stop iPlanet and start its management console on a Linux system. The default location for iPlanet is /usr/netscape/server4.
To start iPlanet, enter:
./slapd-servername/start-slapd
To stop iPlanet, enter:
./slapd-servername/stop-slapd
To view the configuration file, enter:
./slapd-servername/getconf
To run the iPlanet configuration console, enter:
./startconsole
Important: Refer to Appendix A for post installation requirements for iPlanet.
The Volution Manager runs on the OpenLinux operating system. You must have OpenLinux installed and running before you begin installing Volution Manager.
For information on installing OpenLinux, refer to the OpenLinux 3.1.1 Installation Guide. The OpenLinux 3.1.1 Installation Guide explains how to install OpenLinux and where to look for further documentation. The OpenLinux System Administrator's Guide covers configuring and maintaining OpenLinux after completing the installation.
Volution Manager requires that a Domain Name System (DNS) server be installed and configured in your network. DNS allows users to look up hosts on a network (including the Internet) by name, rather than requiring the IP address of every computer. DNS provides mapping between Internet host names and the actual numeric IP address of computers.
For information on how to set up DNS, see:
OpenLinux System Administration Guide
Provides information for configuring DNS using Webmin or the command line method.
DNS HOWTO at http://www.linuxdoc.org/HOWTO/DNS-HOWTO.html
DOMAIN-Setup-mini-HOWTO at http://www.linuxdoc.org/HOWTO/mini/Domain.html
The Linux Documentation Project (LDP) website, www.linuxdoc.org, provides additional DNS documents as well.
Volution Manager uses the open source implementation of the Services Location Protocol (SLP) known as OpenSLP to discover the existence and location of Volution Manager components. OpenSLP provides a standard way for services to advertise and for consumers to find the advertised services. OpenSLP is based on RFCs 2165, 2608, 2609 and 2614. Caldera is the OpenSLP project maintainer and contributor of the original code base. As an open source project, OpenSLP is fast becoming a standard for service location management. This protocol eliminates the need to configure each Volution Manager Client (VM Client) on which Volution Manager is installed. OpenSLP allows the software running on a managed client to locate all of the services it needs without having to set up or modify its configuration files. OpenSLP is included in the Volution Manager Server (VM Server) and VM Client installations.
For additional introductory information, see Appendix B.
For more information on OpenSLP, refer to:
http://www.openslp.org
For information on troubleshooting using slptool, see the Volution Manager Administration Guide.
The Distributed Events Notification System (DENS), is used by the VM Server to communicate configuration changes to VM Clients. DENS depends on OpenSLP to advertise its services. When VM Clients start, they query OpenSLP to establish a connection with DENS. The DENS daemon (densd) runs by default.
Tomcat is a free, open source implementation of Java® Servlet and JavaServer Pages technologies that was developed as part of the Jakarta project from the Apache Software foundation.
Tomcat is installed with Volution Manager and provides Volution Manager Management Console (VM Management Console) services. The VM Management Console is the web browser interface to Volution Manager functionality. Once the VM Server and VM Clients are installed and initially configured, the VM Management Console is where all system management activity takes place.
The installation installs all of the necessary Java framework required to run Tomcat. If an older version of Tomcat is detected on your OpenLinux system, the Volution Manager installation updates it with the more current version.
The Simple Network Management Protocol (SNMP) is required to use the Volution Manager Diagnostic Tool. The Volution Manager Diagnostic Tool is available through the VM Management Console. For information on using the Volution Manager Diagnostic Tool, see Volution Manager Administration Guide.
SNMP is the internet standard protocol for monitoring network performance and network devices. SNMP uses programs called agents to monitor various devices on the network. Another program collects the data from the agents. The database created by the monitoring operations is called a management information base (MIB). This data indicates if all devices on the network are working properly.
When the diagnostic tool is selected, the console contacts the currently selected system using SNMP to gather information on the services running on that machine.
All components and features of Volution Manager have been enabled to generate information through unique SNMP alerts and traps. In addition, Volution Manager has the capability of monitoring the health of the managed systems. This means that administrators can receive large amounts of information regarding the day-to-day usage of Volution Manager in general as well as the specific health components being monitored. In order to use and understand all of the SNMP information being generated, an administrator needs to have an SNMP console product like the Tivoli®, Unicenter®, or OpenView® products. There are several OpenSource SNMP consoles like Big Brother, OpenNMS, and Scotty that can also be used. Volution Manager does not provide this console, but works with all industry standard consoles.
For information on SNMP numbers and their corresponding messages, refer to, csm_codes.html. This file is available on the Volution Manager CD in /mibs.
The Simple Mail Transfer Protocol (SMTP) is a protocol for sending email messages between servers. It is generally used to send messages between mail servers and between a mail client and a mail server.
In Volution Manager, SMTP is used in conjunction with monitoring system health. Using SMTP, you can receive mail alerting you to detected problems. SMTP is a good alternative if you do not have an SNMP console available.
To take advantage of this feature, you need an SMTP email server and valid email accounts. For information on setting up an email server, refer to the OpenLinux System Administration Guide.
If you want to manage VM Clients outside your firewall, you must allow traffic on the ports that VM Clients use to communicate with the VM Server. Opening additional ports can reduce the effectiveness of your firewall. One way to secure your firewall is to use firewall rules that specify the IP addresses of the specific machines that are allowed access. For each VM Client outside your firewall there should be a separate firewall rule that specifies its IP address and the ports it requires to contact VM Server components and services as the source location and the IP address of the VM Server behind the firewall as the destination location.
For information on understanding and changing firewall rules, see the chapter on configuring a firewall server in the OpenLinux System Administration Guide. For information on accessing the OpenLinux System Administration Guide, see Chapter 4.
Volution Manager components and services use ports below 1024 for VM Client to VM Server communication. Volution Manager components that require you to open ports through your firewall are:
Distributed Event Notification System Daemon (densd)
Computer Creation Daemon (volutionccd)
Volution Manager services that require you to open ports through your firewall are:
OpenSLP
LDAP
SNMP
SNMP traps
HTTP
FTP
SMTP
Additional information on each component and service follows.
When the DENS daemon, densd, starts, it binds to the first unused ports above 599. DENS requires only one port, usually 600 or 603 depending on whether densd or the computer creation daemon, volutionccd, starts first. To make sure that changes can be signalled to VM Clients, allow traffic on port 600 to 603.
The computer creation daemon, volutionccd, requires 3 ports, 600-602 or 601-603 depending on the order in which densd and volutionccd were started. To make sure that computer objects can be created when a VM Client starts, allow traffic on the first 4 unused ports above 599 (600-603 out of the box).
VM Clients use OpenSLP to find the VM Server. VM Clients must be able to communicate with an SLP Directory Agent (SLP DA), located on the VM Server to find DENS and the computer creation services.
Two changes must be made for VM Clients to locate the VM Server.
Firewall rules must be modified to allow connections on port 427 of the VM Server.
The VM Client configuration file, /etc/slp.conf, must be modified to identify the location of the directory agent (DA). By default, Volution Manager installs an SLP DA on the VM Server so the IP address of the VM Server is sufficient.
Log in remotely to the VM Client, open the slp.conf file, uncomment the line, and change the net.slp. DAAddresses entry to:
net.slp.DAAddresses=IP address of the VM Server
Restart the VM Client by entering:
/etc/rc.d/init.d/volutiond restart
For information on editing files, refer to the KDE User's Guide, available through the KHelpCenter on OpenLinux.
If Volution Manager is managing VM Clients outside your firewall, events can be signalled to VM Clients, but the VM Clients are not able to report back without a firewall configuration change. Your firewall must be configured to allow traffic on port 636. While your LDAP directory (OpenLDAP or iPlanet) can reside on the same server as the VM Server, your LDAP directory can also reside on a different server, particularly in the case of NDS eDirectory. If the LDAP server and the VM Server are on different physical servers and are on the same side of the firewall, you only need to allow access on port 636 on the LDAP server. If the LDAP server and the VM Server are on different physical servers and are on different sides of the firewall then you need to allow access on port 636 on both the LDAP server and the VM Server. Port 636 is the secure LDAP port (LDAPS).
Volution Manager stores software packages you plan to distribute in a publicly accessible HTTP or FTP site. When a VM Client is instructed to install a package, it downloads the package for the HTTP or FTP site. If your VM Clients are outside your firewall while the HTTP or FTP site resides within your firewall, implement one of the following:
If you are using HTTP, open port 80. If you are using FTP, open ports 20 and 21.
Give the VM Clients outside the firewall access to a local FTP or web server that resolves to the name of the FTP or web server within the firewall. Make sure that the FTP or web server outside the firewall has the same content as the FTP or web server within the firewall, using rsync (an open source utility for file transfers) or by manually copying software packages between servers.
Volution Manager uses SNMP to collect diagnostic information about each VM Client. If you want to use VM Manager diagnostics, open traffic on port 161. This is the standard SNMP port.
Volution Manager can monitor the health of VM Clients through SNMP traps. To use and understand all of the SNMP information being generated, requires an SNMP console. (For information on console products, see Section 1.1.7.) The SNMP console can be anywhere in your network, but if there is a firewall between the SNMP console and the VM Clients, open port 162.
Volution Manager can send email alerts associated with monitoring the health of your system. If you want to use SMTP to send email alerts regarding the health of your system, either set up a mail server outside your firewall to which you direct the email, or open port 25.
The following table summarizes the Volution Manager components and services and their associated ports.
Managing VM Clients across a wide-area network (WAN) requires additional configuration. The VM Clients must specify the location of the SLP DA. For information on how to specify the SLP DA, see Section 1.1.9.1.3.
Installing Volution Manager has multiple parts. The VM Server is installed first. Then you install VM Clients on systems that you want to manage via the VM Management Console. The VM Server must be installed before you install any of the VM Clients.
The VM Server installation is graphical and provides three choices: Custom, Quick, or Demo.
Use Custom if you want to:
Fully deploy Volution Manager.
Select and configure your LDAP directory.
Change the default location where computer objects are created.
Change the default location for storing software package information.
Select the security level you want to implement.
Use Quick if you want a basic VM Server installation. In a Quick install:
OpenLDAP is used.
Security is minimal.
Requires only an LDAP Directory Administrator password.
Use Demo is you want to:
Evaluate or review Volution Manager.
Assess Volution Manager in a pilot project.
VM Clients are installed on each managed system using a command line script. After the VM Client daemon, volutiond, is installed and running, it uses OpenSLP to find the Volution Manager computer creation daemon, volutionccd, on the VM Server. The volutionccd sends back the server certificate key and LDAP information to the VM Client. The volutionccd also creates the computer object for that managed client in the LDAP directory. The VM Client can now be managed by Volution Manager.
Before installing, complete the worksheets in the next section.
Use the following worksheets to keep track of data that you supply during the installation process. Once you complete these sheets, be sure to store them in a secure place.
Table 1-2. VM Server Configuration
Setting Name | Entry |
---|---|
VM Server name | |
Installation profile (see Table 2-3) | |
LDAP directory (see Table 2-4) |
For explanations of the setting names and the format to use for your entries in Table 1-3, see Table 2-5.
Table 1-3. LDAP Network Settings
Setting Name | Entry |
---|---|
LDAP server hostname | |
Secure server port | |
Unsecure server port | |
LDAP naming context |
For explanations of the setting names and the format to use for your entries in Table 1-4, see Table 2-6.
Table 1-4. LDAP Administrator Options
Setting Name | Entry |
---|---|
Directory administrator name | |
Directory administrator password |
For explanations of the setting names and the format to use for your entries in Table 1-5, see Table 2-7.
Table 1-5. Computer Creation Options
Setting Name | Entry |
---|---|
Computer creation location | |
Computer search location | |
Computer creation manager password |
For explanations of the setting names and the format to use for your entries in Table 1-6, see Table 2-8.
Table 1-6. Software Repository Options
Setting Name | Entry |
---|---|
Software repository (organizational unit) | |
Software repository manager password |
For explanations of the setting names and the format to use for your entries in Table 1-7, see Table 2-9.
Table 1-7. Software Repository Daemon Options
Setting Name | Entry |
---|---|
LDAP check interval (minutes) for the SRD | |
File system check interval | |
SRD source directory | |
SRD destination directory | |
SRD URL |
For description of the security levels available in Volution Manager, see, Table 2-10.
For explanations of the setting names and the format to use for your entries in Table 1-9, see Table 2-11.
Table 1-9. Volution Authority Key
Field | Description |
---|---|
Name of your company or organization | |
Your name | |
Your email address | |
Enter the CA Key password | |
Directory to backup keys and certificates |
Use Table 1-10 to indicate whether you are using the Volution Manager Certificates created during the Volution Manager installation for the Apache Web Server or if you are using a separate Apache certificate.