Red Hat NETWORK SATELLITE SERVER 3.6, Руководство по установке

Страница: 47 / 62

Chapter 7. Troubleshooting 43
This problem typically originates from the
/etc/hosts
file. You may confirm this by examining
/etc/nsswitch.conf
, which defines the methods and the order by which domain names are re-
solved. Usually, the
/etc/hosts
file is checked first, followed by Network Information Service (NIS)
if used, followed by DNS. One of these has to succeed for the Apache HTTP Server to start and the
RHN client applications to work.
To resolve this problem, identify the contents of the
/etc/hosts
file. It may look like this:
127.0.0.1 this_machine.example.com this_machine localhost.localdomain.com localhost
First, in a text editor, remove the offending machine information, like so:
127.0.0.1 localhost.localdomain.com localhost
Then, save the file and attempt to re-run the RHN client applications or the Apache HTTP Server. If
they still fail, explicitly identify the IP address of the Satellite in the file, such as:
127.0.0.1 localhost.localdomain.com localhost
123.45.67.8 this_machine.example.com this_machine
Replace the value here with the actual IP address of the Satellite. This should resolve the problem.
Keep in mind, if the specific IP address is stipulated, the file will need to be updated when the machine
obtains a new address.
7.4. Connection Errors
A common connection problem, indicated by SSL_CONNECT errors, is the result of a Satellite being
installed on a machine whose time had been improperly set. During the Satellite installation process,
SSL certificates are created with inaccurate times. If the Satellite’s time is then corrected, the certifi-
cate start date and time may be set in the future, making it invalid.
To troubleshoot this, check the date/time on clients and the Satellite with the following command:
date
The results should be nearly identical for all machines and within the "notBefore" and "notAfter"
validity windows of the certificates. Check the client certificate dates and times with the following
command:
openssl x509 -dates -noout -in /usr/share/rhn/RHN-ORG-TRUSTED-SSL-CERT
Check the Satellite server certificate dates and times with the following command:
openssl x509 -dates -noout -in /etc/httpd/conf/ssl.crt/server.crt
By default, the server certificate has a one-year life while client certificates are good for 10 years. If
you find the certificates are incorrect, you can either wait for the valid start time, if possible, or create
new certificates, preferably with all system times set to GMT.
The following measures can be used to troubleshoot general connection errors:
•
Attempt to connect to the RHN Satellite Server’s database at the command line using the correct
connection string as found in
/etc/rhn/rhn.conf
:
sqlplus username/password@sid
•
Ensure the RHN Satellite Server is using Network Time Protocol (NTP) and set to the appropriate
time zone. This also applies to all client systems and the separate database machine in RHN Satellite
Server with Stand-Alone Database.