Troubleshooting Oracle Linux Manager Problems

4 Troubleshooting Oracle Linux Manager Problems

WARNING:

The software described in this documentation is supported for a limited period under Extended Support. Oracle Linux 7 is now in Extended Support. See Oracle Linux Extended Support and Oracle Open Source Support Policies for more information.

Consider using OS Management Hub to manage operating system infrastructure. See OS Management Hub for more information.

This chapter describes how to diagnose and fix problems that you might encounter on an Oracle Linux Manager server. For information about other known issues and possible workarounds, see Oracle Linux Manager: Release Notes for Release 2.10 .

Checking the Status of Services

Use the /usr/sbin/spacewalk-service status command to identify Oracle Linux Manager services that might be running incorrectly. For Oracle Linux Manager proxy servers, use the rhn-proxy status command.

Services that do not start correctly are typically caused by incorrect configuration information that was provided during installation.

For Oracle Linux Manager proxies, verify also that the /etc/sysconfig/rhn/systemid file is owned by root:apache and that its mode is set to 640.

If required to clear up package provisioning problems on Oracle Linux Manager proxies, clear the proxy cache as follows:

Stop the httpd and squid services.

sudo systemctl stop httpd
sudo systemctl stop squid

Delete the contents of the cache as follows:
```
sudo rm -Rf /var/cache/rhn/*
```

Restart the squid and httpd services.

sudo systemctl start squid
sudo systemctl start httpd

Checking Logs for Errors

The following Oracle Linux Manager server logs are information sources when errors occur:

/var/log/httpd/*: httpd service log files.
/var/log/rhn_satellite_install.log: Installation log file.
/var/log/rhn/reposync/*: Repository synchronization log files.
/var/log/rhn/rhn_server_satellite.log: Synchronization log file.
/var/log/rhn/rhn_server_xmlrpc.log: XML-RPC transaction log file.
/var/log/rhn/rhn_taskomatic_daemon.log: Red Hat Network (RHN) Task Engine (Taskomatic) log messages.
/var/log/tomcat: Tomcat log messages for Oracle Linux.
/var/log/yum.log: Yum log file.

On Oracle Linux Manager proxies, these addiitonal logs are also useful for error checking:

/var/log/rhn/rhn_proxy_broker.log: Proxy brokering service log file.
/var/log/rhn/rhn_proxy_redirect.log: Proxy SSL redirection service log file.
/var/log/squid/*: Squid proxy log files.

Note:

Oracle Linux Manager generates large numbers of log messages, particularly under the /var/log/httpd directory. To avoid running out of disk space, adjust the logrotate settings to implement more active rotation, compression, and archival of log files.

For more information, see the Oracle Linux 7: Monitoring and Tuning the System.

Issues and Problems

This section describes issues you might encounter with the current Oracle Linux Manager release. It also includes workarounds should these errors occur.

osa-dispatcher Reports a Certificate Verification Failure

When you start the osa-dispatcher service, you might encounter an error message similar to the following:

sudo systemctl start osa-dispatcher

Starting osa-dispatcher: Oracle Linux Manager 10611 2015/05/26 17:11:22 +01:00: ('Traceback caught:',)
Oracle Linux Manager 10611 2015/05/26 17:11:22 +01:00: ('Traceback (most recent call last):\n  
    File "/usr/share/rhn/osad/jabber_lib.py", line 631, in connect\n    
    ssl.do_handshake()\nError: [(\'SSL routines\', \'SSL3_GET_SERVER_CERTIFICATE\', 
    \'certificate verify failed\')]\n',)
                                                          [FAILED]

This error usually indicates that the system's host name does not match its FQDN in DNS, or that you specified an incorrect FQDN for the name of the Organization Unit when you installed Oracle Linux Manager.

Resolving the issue involves regenerating the SSL certificate. However, if the system's host name has been changed over time, then regenerating the certificate requires you to provide the certificate password. To prepare, verify first that you know the correct password. Type the following command:

sudo openssl rsa -in /root/ssl-build/RHN-ORG-PRIVATE-SSL-KEY

You are prompted for the pass phrase before the key is displayed.

If you typed the correct password, the base64-encoded private key is displayed. Otherwise, the command generates the error message unable to load Private Key.

After verification, proceed to the following steps:

Issue the following command to regenerate the certificate:

sudo /usr/sbin/spacewalk-hostname-rename IP_address --ssl-orgunit=FQDN

If prompted for the password, type the same password that you used when you created the existing certificate previously.

Type the following commands to clear the jabberd database.

sudo systemctl stop jabberd
sudo systemctl stop osa-dispatcher
sudo rm -Rf /var/lib/jabberd/db/*
sudo systemctl start jabberd
sudo systemctl start osa-dispatcher

On every client that is registered with the server, verify that the value of serverURL in the /etc/sysconfig/rhn/up2date file is configured with the correct server host name or IP value, for example:
```
serverURL=https://olmsvr.mydom.com/XMLRPC
```

osa-dispatcher Reports an Invalid Password

If the osa-dispatcher service starts correctly, but later stops unexpectedly, you might see a log error similar to the following displayed:

Oracle Linux Manager 2316 2015/06/05 20:38:47 +01:00: ('Invalid password',)

This error can occur if the jabberd database contains invalid entries.

To clear the error, stop the jabberd and osa-dispatcher services, clear the jabberd database, then restart the jabberd and osa-dispatcher services.

sudo systemctl stop jabberd
sudo systemctl stop osa-dispatcher
sudo rm -Rf /var/lib/jabberd/db/*
sudo systemctl start jabberd
sudo systemctl start osa-dispatcher

Note:

To avoid problems with OSA, you should clear the jabberd database at regular intervals.

To avoid database corruption, follow the instructions in Preparing to Upgrade.