Caldera Volution Manager displays error messages and provides diagnostic tools to help you troubleshoot your VM Server, clients, and the management console.
This topic describes:
Section 5.1 - general troubleshooting information
Section 5.2 - how to use the graphical and command-line Volution Diagnostics Tool
Section 5.3 - how to run the slptool on a Linux system to diagnose OpenSLP problems
Section 5.4 - information about using webmin to correct system problems
Section 5.5 - how to use volutionkeytool to recover your server or authority key
If VM detects Compaq Insight Manager XE on a system, then a link to this network manager is also provided in the computer's task list.
Most errors you encounter fall into one of these categories:
The computers running the VM Server, VM Management Console, Directory Services, or VM Client software are down. Ensure that these systems are up and on the network before further troubleshooting.
The network is down. Test network connectivity between systems by running ping, telnet, or any other basic network command.
Network services are not running or are misconfigured. Verify that TCP/IP networking, including SNMP and DNS, are correctly installed, configured, and running on your system . See your operating system administration guide for more information.
Services used by VM are not running. Key functionality is managed by several daemons running on the VM Server and clients. Each daemon, such as densd or volutiond, can be manually re-started by using the /etc/rc.d/init.d/daemon start command. For example, to re-start densd, enter
/etc/rc.d/init.d/densd start
The VM Server must be running volutionccd, densd, volutionsrd, and slpd. Client systems must be running volutiond.
These services might also be running, but misconfigured. See Section 5.2 for more information.
An error is encountered, such as the absence of text in a required field, while you are using the VM Management Console. These types of errors generally pop up error messages describing the nature of the error and the corrective action you might take.
The remainder of this topic discusses specific troubleshooting issues: instances where the systems and network are up, and the correct software is installed, but a configuration, run-time, or user error causes loss of functionality.
If you experience problems with client/server communications, you can use the Volution Diagnostics Tool to troubleshoot the network. This tool can be run either in graphical mode from the VM Management Console, or from the command line. It provides status for the underlying network services upon which VM depends, such as TCP/IP and DNS, SLP and its daemons, LDAP, and the VM Server and management console.
If you notice network or LDAP service errors when trying to contact a particular computer, run the Volution Diagnostics Tool from the VM Management Console. This gives you a high level view of communication status between the client and VM Server and should give you information that facilitates further troubleshooting. In addition, the tool allows you to re-start the client remotely if certain conditions are met.
To run the Volution Diagnostics Tool :
Select the client you want to manage from the Contents pane. You might need to first open a computer group to find the computer you want.
Select View Diagnostics from the Page View pane.
The tool displays of statistics about the computer:
Based on the information that the Volution Diagnostics Tool provides, you should perform one of these actions listed in the following topics.
If the CCD, DENS, or LDAP services are missing from the list of contacted machines, you might have one of these errors:
The VM Server or network may be down. Ensure that the server is up and on the network by either logging onto the server console or using ping or telnet to access the system over the network. If the server is down, reboot the server if you can, or contact your network administrator. If the network is down, contact your network administrator.
Services provided by the VM Server may be down. While logged on to the server, verify that volutiond, densd, and slpd are all running. To do so, you can use the following command on most UNIX and Linux systems: ps -ef | grep daemon, where daemon is the name of the daemon in which you are interested. If the daemon is not running, the ps command does not list the daemon process. You can restart the daemon by issuing the /etc/rc.d/init.d/daemon start command. For example, to re-start the DENS daemon, enter
/etc/rc.d/init.d/densd start
Note: Depending upon the type of error encountered, it might be necessary to stop the daemon before starting or restarting it.
The Volution Daemon section reports the overall health of the daemon, whether the daemon is running, and version and uptime information.
If the Overall Health of the daemon is yellow, you need to log on to the client system directly and run voldiag. A yellow status shows that the daemon is running, but some services needed by VM are either misconfigured or not available.
If the Overall Health is status is red, the daemon might be running, but major problems exist with configured services or the network. Log onto the client and run voldiag.
If the Loaded status is red, the daemon is not running. To start the daemon, log on to the client and enter /etc/rc.d/init.d/volutiond start.
If uptime is high (weeks or months) you might want to re-start the daemon or reboot the system to improve performance. To re-start the daemon, log on to the client and enter /etc/rc.d/init.d/volutiond stop, then/etc/rc.d/init.d/volutiond start.
The LDAP Information section of the graphical Volution Diagnostics Tool reports whether or not the client can access directory services, where the directory services are located, and the Distinguished Name of the client.
If LDAP does not report a valid connection (status is red), the network might be down, the server providing directory services might be down, or the client might be misconfigured. Ensure that the server and network are up, and that both the server address and Distinguished Name are correct.
Both the server address and Distinguished Name can be manually configured by logging on to the client and editing the file /etc/opt/volution/volutiond.conf.
The information generated by the graphical Volution Diagnostics Tool summarizes Caldera Volution Manager status. To view detailed information about error conditions, run /opt/volution/bin/voldiag, the command-line version of the tool. Using voldiag you can view:
system information, such as platform and architecture
network analysis, including basic network functioning and name service resolution
SLP analysis, including availability of services and system scope
VM Client analysis, including information from the daemon's configuration file and current daemon functions
server analysis, including daemon and service diagnostics (available only if voldiag is installed and run on the Volution Server)
console analysis, including web services and port information (available only if voldiag is installed and run on the VM Server)
voldiag is installed as part of the VM Client package. For information about installing this package on the VM Server, see the Installation Guide.
To run voldiag:
Log onto the system you want to analyze as the superuser (root).
Enter /opt/volution/bin/voldiag -options at the command line.
You must log on to the system as root because voldiag allows the client to access LDAP and Software Repository services. In addition, many of the actions you might take as a result of voldiag output, such as re-starting a system or computer, require this permission level.
When run with no options, voldiag performs a standard client analysis. To perform a VM Server or VM Management Console analysis, use the -all option. Other options allow you to view a subset of diagnostics information. Use-h to list voldiag options.
Normally, voldiag reports the client system's platform, architecture, OS vendor, and OS version. This information is helpful when obtaining support from Caldera support services. If voldiag cannot determine system information, the OS running on the client might be an unsupported release, vendor, or architecture. Refer to the Installation Guide for a list of supported releases.
voldiag generates network information from both configuration files and a real-time test of the network and its services. The tool reads the system's host name and DNS configuration files, then tests the TCP/IP loopback mechanism and network card and attempts to contact the configured DNS servers.
If the hostname is not listed, you might have a system name configuration error. Check your operating system documentation for information on correctly setting the system name.
If the loopback address (lo0) is not listed, TCP/IP is not configured on your system. Configure your network as described in your operating system documentation.
If an ethernet card (for example, eth0) is not listed, the card is either not present, not configured correctly, or disabled. See your operating system documentation.
If configured name servers do not appear, DNS might not be configured on your system. You might need to update the DNS configuration file (usually /etc/resolv.conf).
If resolution of name servers and the local host does not succeed, the network or name services might be down. If you are certain that your network configuration is correct, you can stop and start network services (TCP/IP and DNS) to try to clear up the problem. See your operating system documentation.
The SLP Analysis section of the voldiag output describes the version of SLP running and the services found on the network by the client. It describes the scope, a logical partition of the network, currently detected. It also tests whether or not multicast routing is working successfully.
Note: You can also use the slptool command, described in Section 5.3, to troubleshoot SLP.
The SLP version must be 1.0.6 (or later) or client/server communications do not operate correctly. If this version is incorrect, install the correct version of SLP on the VM Server.
If Directory Agent Services are unavailable, VM does not function correctly. Services might be unavailable due to an offline server, or the daemon process might have died. Ensure that the server is running and available on the network, and that the daemon is running. To verify daemon operation, log on to the server and enter ps -ef | grep slpd. If the daemon does not appear in the output, enter /etc/rc.d/init.d/slpd start to restart the daemon.
If DENS services are unavailable, VM does not function correctly. Use the same procedure to troubleshoot DENS as in the previous item, but substitute densd for slpd.
If this approach does not work, you might have a security certificate error. If so, you need to re-authenticate the client to the VM Server. To do so, log on to the client and remove all files in /etc/opt/volution/cacerts, then run /etc/rc.d/init.d/volutiond stop and /etc/rc.d/init.d/volutiond start.
Depending on the security level you set during installation, either CCD or Secure CCD Services must be running. If one of these services fails, either the server is down or off the network or the volutionccd daemon died on the server. Log onto the server, verify the daemon is not running (ps -ef | grep volutionccd), then re-start the daemon (/etc/rc.d/init.d/volutionccd start).
In rare cases, there might be more than one SLP scope on your network. A scope is a way to logically partition your network such that groups of clients can access services from particular VM Servers. voldiag displays detected scopes and lists the Default Scope just beneath the SLP version. If the scope listed is incorrect, you must log on to the client and edit /etc/slp.conf to change the scope in the net.slp.useScopes field to the desired one, then re-start the daemon (/etc/rc.d/init.d/slpd stop, /etc/rc.d/init.d/slpd start).
If you do not see SUCCESS in the SLP Multicast Traffic Route field, packets cannot be routed correctly and SLP fails. You must manually set up either a default or multicast route. See the route manual page or the OpenSLP documentation at http://openslp.org/doc/html/UsersGuide/Installation.html.
The Volution Client Analysis section of the voldiag output contains information read from the volutiond configuration file (/etc/opt/volution/volutiond.conf) as well as real-time status of the daemon and the services it detects.
If volutiond.conf cannot be read because it has been corrupted or is not present, VM Client Configuration Information fails and the daemon does not run correctly. In this case, you need to re-authenticate the client to the VM Server by removing the file, then stopping and staring volutiond (/etc/rc.d/init.d/volutiond stop, /etc/rc.d/init.d/volutiond start). The VM Server computer creation daemon, volutionccd, then creates the configuration file automatically.
If the daemon is not running (if "Is Volution Client Running" is "NO"), re-start the daemon from the client by entering /etc/rc.d/init.d/volutiond start.
If the daemon is running, voldiag checks to see if it can contact services like CCD, DENS, LDAP, and SLP. This is primarily a cross-check at this point as these systems were located and verified as functional earlier in the diagnostic process.
Based on the ability to access the required services, voldiag reports system health. This is a summary of all diagnostic information.
VM Server diagnostics are reported by voldiag when you use the -all or -r options. You must run voldiag on the server itself. To install voldiag on the server, either copy /opt/volution/bin/voldiag from any client to the same location on the server or install the VM Client package on the VM Server. See the Installation Guide for more details.
The Server Analysis section of the voldiag output includes information about the various services the VM Server provides, including CCD, DENS, LDAP, SLP, and the SRD.
voldiag verifies that the configuration file, /etc/opt/volution/volutionsrd.conf exists and is readable. It also displays the contents of the file.
You can manually test connectivity to the systems listed to ensure that the systems are available.
You can verify that the locations of the Software Repository are correct.
You can change the authenticated name and password if necessary (if they were changed on the Directory Services server, you must do this).
You can change the polling intervals that determine how often the directory service and filesystem are scanned for changes that might affect clients.
All of these changes must be made to volutionsrd.conf, and the daemon must be stopped and re-started with the /etc/rc.d/init.d/volutionsrd stop and /etc/rc.d/init.d/volutionsrd start commands.
If the configuration file is present and readable, and the daemon is running, voldiag also displays a success message for the service.
voldiag verifies that the configuration file, /etc/opt/volution/volutionccd.conf exists and is readable. It also displays the contents of the file.
You can manually test connectivity to the systems listed to ensure that the systems are available.
You can verify that the locations of the Software Repository and computer creation location are correct.
You can change the authenticated name and password if necessary (if they were changed on the Directory Services server, you need to do this).
All of these changes must be made to volutionccd.conf, and the daemon must be stopped and re-started with the /etc/rc.d/init.d/volutionccd stop and /etc/rc.d/init.d/volutionccd start commands.
If the configuration file is present and readable, and the daemon is running, voldiag also displays a success message for the service.
For these services, voldiag reports whether or not the daemon is currently running. All are required, so a failure usually indicates a condition that must be corrected, either by re-starting the associated daemon or by rebooting the system. The exception is when a different server is providing LDAP services; in that case, the error is informational in nature.
Console diagnostics are reported by voldiag when you use the -all or -C options. You must run voldiag on the VM Server hosting the VM Management Console. To install voldiag on that system either copy /opt/volution/bin/voldiag from any client to the same location on the VM Management Console server or install the VM Client package on the VM Management Console server. See the Installation Guide for more details.
The Console Analysis section of the voldiag output contains general information about the VM Management Console and Apache and Tomcat configuration, including secure and insecure web addresses. When the VM Management Console is operating correctly, Apache handles all of the requests and normal web services. When a request goes through Apache for a URL that requires Java Servlets, Apache passes that request to Tomcat for processing using special ports. After Tomcat services the request, the response is then passed back to Apache and to the user.
voldiag verifies that several configuration files exist and are readable, and also displays the contents of particular troubleshooting interest.
Basic VM Management Console information is similar to that found in the VM Server diagnostics section and should match with respect to system names, directory service names and passwords, and the Software Repository location.
Caldera Volution Manager requires that Tomcat be installed and configured on the VM Server. voldiag reports on the presence of the Tomcat configuration file and lists the ports on which Tomcat is listening for servlet requests from Apache.
The two ports that should be present in the voldiag output are 8007 and 8009. These are the special ports used for communication with Apache. voldiag attempts to contact these ports and reports success or failure.
These ports should have been configured when Tomcat was installed. If they are not present, you can manually configure them. Refer to the Tomcat User Guide found at http://jakarta.apache.org/tomcat/tomcat-3.2-doc/uguide/tomcat_ug.html.
Caldera Volution Manager requires that Apache be installed and configured on the VM Server. voldiag reports on the presence of the Apache configuration file and lists the ports on which Apache is listening for web requests.
The two ports that should be present in the voldiag output are 80 (insecure communication) and 443 (secure communication). The 443 port is the standard port used when accessing the VM Management Console. voldiag attempts to contact these ports and reports success or failure.
These ports should have been configured when Apache was installed. If they are not present, you can try stopping and starting the Apache web server or re-install Apache. Refer to the Apache User Guide found at http://httpd.apache.org/docs.
Apache knows to pass requests to Tomcat whenever the URL contains a specific entity called a JKMount point. For VM, this entity is `volution'. The specific value of the JKMount point is contained in the Apache module file, mod_jk.conf.
voldiag first verifies that mod_jk.conf exists, then attempts to pass URLs to Apache that contain `volution' to see if the appropriate communications take place between Apache and Tomcat over the 8007/8009 ports.
If the file does not exist, reinstall the VM Management Console RPM, then restart Tomcat and Apache (in that order). If the file does exist but communication fails, restart Tomcat, then Apache. If this fails, contact Caldera Support. Additional information about mod_jk.conf can be found at the Jakarta documentation project Working with mod_jk site: http://jakarta.apache.org/tomcat/tomcat-3.3-doc/mod_jk-howto.html
slptool is a command you can run on a Linux system to diagnose OpenSLP problems. It installs by default as part of the openslp RPM. slptool is included with the OpenSLP packages for SCO OpenServer, UnixWare and Open UNIX 8 client systems.
To diagnose OpenSLP troubles, enter slptool findsrvtypes from a terminal window. If OpenSLP is running correctly on your network, you should see a list of all services currently being advertised on the network, including those used by VM.
On a correctly-configured VM network, you should see:
service:dens.x
service:csmwscs.x or service:csmwsc.
service:volution-ca.x
You can then follow up this initial query by querying the services displayed. For example, entering slptool findsrvs dens.x returns all servers running DENS.
If slptool returns error messages, most likely the network is not configured correctly: the name service or routing might not be set up or running. Refer to your operating system networking documentation for more information.
You can also use the slptool findscopes command to view all of the scopes currently configured on the network. This information is also provided by voldiag. If your client is authenticating to the wrong VM Server, you might have a scope configuration problem. Verify that the scope configured on the VM Server and that listed on the client's /etc/slp.conf file are equivalent.
Webmin is a web-based management tool that enables you to configure a single Linux system or UNIX system. Depending on the operating system and the modules that operating system supports, you can perform tasks as simple as adding a user to your system, to complete network analysis and configuration.
Because many of the error conditions that can affect VM are actually networking or operating system-related, webmin can be a useful tool to correct these errors after you have diagnosed them with the Volution Diagnostics Tool. For example, you can use webmin to configure the Domain Name Service, or list, stop, and start system processes (such as the various VM daemons).
To start webmin:
Select the client you want to manage from the Contents pane. You might need to open a computer group to find the computer you want to view.
Select Run Webmin from the Page View pane.
Refer to the webmin online help for more information about analyzing and diagnosing network and operating system problems.
Caldera Volution Manager uses a simplified public key infrastructure (PKI) to ensure secure communications between the VM Server and clients. See the Installation Guide for a Security Overview, and for information about installing keys on servers and clients.
volutionkeytool is the VM command line key and certificate configuration tool. It is located in /opt/volution/bin on the VM Server and on clients. The usage is:
volutionkeytool options [arguments]
Table 5-1. volutionkeytool Options
| Option | Description |
|---|---|
| help | display a usage message |
| cacert create | create a new VM Certificate Authority certificate |
| cacert import | import a VM Certificate Authority certificate |
| cacert list | list VM Certificate Authority certificates on this host |
| cert list | list VM Server Certificates that have been issued for this host |
| cert issue | issue (or re-issue) new VM Server Certificates for this host |
| cert request | generate an X509 certificate signing request (can use to obtain a VM Server Certificate that is signed by a non-VM certificate authority) |
| crl add | add a certificate to the Certificate Revocation List |
| crl list | list certificates on the Certificate Revocation List |
Each VM Server is issued a Server Certificate by the VM Certificate Authority when the server is installed. The Server Certificate and the Server private key are stored on the server, and are used for secure communications with client systems. If your server key is compromised or lost you need to revoke the old server certificate and issue a new one.
To revoke a VM Server certificate and issue a new one:
Create and schedule an action to restart all client systems. Schedule the action so that it does not run until after you have completed the remaining steps of this procedure.
Stop all VM Server processes and stop LDAP.
/etc/rc.d/init.d/volutionservers stop
/etc/rc.d/init.d/ldap stop
Note: The volutionservers script can be used to stop or start all VM daemons. You must issue the ldap command on the system running LDAP.
Add the compromised certificate to a certificate revocation list.
volutionkeytool crl add
You are prompted to enter the serial number of the compromised certificate. You are also prompted to insert the media that contains the VM Certificate Authority key.
Issue a new server certificate for your VM Server.
volutionkeytool cert issue
Restart VM Server processes.
/etc/rc.d/init.d/volutionservers start
/etc/rc.d/init.d/ldap start
When the client systems are restarted they automatically receive a Certificate Revocation List that revokes the old certificate.
Recreate the .signature files for all software packages. To recreate the .signature files, copy all of the software packages to be distributed (they are in /home/httpd/html/VolutionSoftware, by default) to the appropriate Software Repository package distribution directories. New .signature files are created when the SRD processes the package files.
The VM Certificate Authority is controlled by an administrator who only issues certificates to people authorized to operate Caldera Volution Manager. It is essential that the VM Certificate Authority private key be carefully protected: the private key should be stored on removable media and kept in a safe location. The private key is DES3 encoded before it is written to disk, and a password is required to decode it. A compromised or lost VM Certificate Authority private key poses a serious security problem. The only solution is to create a new VM Certificate Authority private key and certificate.
To create a new certificate authority:
Stop all VM Server processes.
Create a new authority key.
volutionkeytool cacert create
You are prompted for additional information. Supply a password, and save the authority private key to removable media.
Issue a new server certificate for your VM Server.
volutionkeytool cert issue
Display the new VM Certificate Authority certificate fingerprint.
volutionkeytool cacert list
Write down and save the certificate fingerprint.
Manually import the new VM Authority Certificate to each client system.
volutionkeytool cacert import
You must log into and perform this command on each client system.