Troubleshooting Clients
Bare Metal Systems
If a bare metal system on the network is not automatically added to the Systems
list, check these things first:
-
You must have the
pxe-default-image
package installed. -
File paths and parameters must be configured correctly. Check that the
vmlinuz0
andinitrd0.img
files, which are provided bypxe-default-image
, are in the locations specified in therhn.conf
configuration file. -
Ensure the networking equipment connecting the bare metal system to the Uyuni server is working correctly, and that you can reach the Uyuni server IP address from the server.
-
The bare metal system to be provisioned must have PXE booting enabled in the boot sequence, and must not be attempting to boot an operating system.
-
The DHCP server must be responding to DHCP requests during boot. Check the PXE boot messages to ensure that:
-
the DHCP server is assigning the expected IP address
-
the DHCP server is assigning the the Uyuni server IP address as
next-server
for booting.
-
-
Ensure Cobbler is running, and that the Discovery feature is enabled.
If you see a blue Cobbler menu shortly after booting, discovery has started. If it does not complete successfully, temporarily disable automatic shutdown in order to help diagnose the problem. To disable automatic shutdown:
-
Select
pxe-default-profile
in the Cobbler menu with the arrow keys, and press the Tab key before the timer expires. -
Add the kernel boot parameter
spacewalk-finally=running
using the integrated editor, and press Enter to continue booting. -
Enter a shell with the username
root
and passwordlinux
to continue debugging.
Duplicate profiles
Due to a technical limitation, it is not possible to reliably distinguish a new bare metal system from a system that has previously been discovered. Therefore, we recommended that you do not power on bare metal systems multiple times, as this will result in duplicate profiles. |
Cloned Salt Clients
If you have used your hypervisor clone utility, and attempted to register the cloned Salt client, you might get this error:
We're sorry, but the system could not be found.
This is caused by the new, cloned, system having the same machine ID as an existing, registered, system. You can adjust this manually to correct the error and register the cloned system successfully.
For more information and instructions, see Troubleshooting Registering Cloned Clients.
Disabling the FQDNS grain
The FQDNS grain returns the list of all the fully-qualified DNS services in the system. Collecting this information is usually a fast process, but if the DNS settings have been misconfigured, it could take a much longer time. In some cases, the client could become unresponsive, or crash.
To prevent this problem, you can disable the FQDNS grain with a Salt flag. If you disable the grain, you can use a network module to provide FQDNS services, without the risk of the client becoming unresponsive.
This only applies to older Salt clients. If you registered your Salt client recently, the FQDNS grain is disabled by default. |
On the Uyuni Server, at the command prompt, use this command to disable the FQDNS grain:
salt '*' state.sls util.mgr_disable_fqdns_grain
This command restarts each client and generate Salt events that the server needs to process. If you have a large number of clients, you can execute the command in batch mode instead:
salt --batch-size 50 '*' state.sls util.mgr_disable_fqdns_grain
Wait for the batch command to finish executing. Do not interrupt the process with Ctrl+C.
Mounting /tmp with noexec
Salt runs remote commands from /tmp
on the client’s file system.
Therefore you must not mount /tmp
with the noexec
option.
Passing Grains to a Start Event
Every time a Salt client starts, it passes the machine_id
grain to Uyuni. Uyuni uses this grain to determine if the client is registered.
This process requires a synchronous Salt call. Synchronous Salt calls block other processes, so if you have a lot of clients start at the same time, the process could create significant delays.
To overcome this problem, a new feature has been introduced in Salt to avoid making a separate synchronous Salt call.
To use this feature, you can add a configuration parameter to the client configuration, on clients that support it.
To make this process easier, you can use the mgr_start_event_grains.sls
helper Salt state.
This only applies to already registered clients. If you registered your Salt client recently, this config parameter is added by default. |
On the Uyuni Server, at the command prompt, use this command to enable the start_event_grains
configuration helper:
salt '*' state.sls util.mgr_start_event_grains
This command adds the required configuration into the client’s configuration file, and applies it when the client is restarted. If you have a large number of clients, you can execute the command in batch mode instead:
salt --batch-size 50 '*' state.sls mgr_start_event_grains
Proxy Connections and FQDN
Sometimes clients connected through a Uyuni Proxy appear in the Web UI, but do not show that they are connected through a proxy. This can occur if you are not using the fully-qualified domain name (FQDN) to connect, and the proxy is not known to Uyuni.
To correct this behavior, specify additional FQDNs as grains in the client configuration file on the proxy:
grains: susemanager: custom_fqdns: - name.one - name.two
Registering Older Clients
To register and use CentOS 6, Oracle Linux 6, Red Hat Enterprise Linux 6, or SUSE Linux Enterprise Server with Expanded Support 6 clients, you need to configure the Uyuni Server to support older types of SSL encryption.
If you are attempting to register at the command prompt, you will see an error like this:
Repository '<Repository_Name>' is invalid. [|] Valid metadata not found at specified URL(s) Please check if the URIs defined for this repository are pointing to a valid repository. Skipping repository '<Repository_Name>' because of the above error. Download (curl) error for 'www.example.com': Error code: Unrecognized error Error message: error:1409442E:SSL routines:SSL3_READ_BYTES:tlsv1 alert protocol version
If you are attempting to register in the Web UI, you will see an error like this:
Rendering SLS 'base:bootstrap' failed: Jinja error: >>> No TLS 1.2 and above for RHEL6 and SLES11. Please check your Apache config. ...
This occurs because Apache requires TLS v1.2, but older operating systems do not support this version of the TLS protocol.
To fix this error, you need to force Apache on the server to accept a greater range of protocol versions.
On the Uyuni Server, as root, open the /etc/apache2/ssl-global.conf
configuration file, locate the SSLProtocol
line, and update it to read:
SSLProtocol all -SSLv2 -SSLv3
This will need to be done manually on the server, and with a Salt state on the Proxy, if applicable.
Restart the apache
service on each system after making the changes.