8 Contact Methods

The SUSE Manager daemon can be configured by editing the file on the client:

/etc/sysconfig/rhn/rhnsd

This is the configuration file the rhnsd initialization script uses. An important parameter for the daemon is its check-in frequency. The default interval time is four hours (240 minutes). If you modify the configuration file, you must as root restart the daemon with:

/etc/init.d/rhnsd restart

Important: Minimum Allowed Check-in Parameter

The minimum allowed time interval is one hour (60 minutes). If you set the interval below one hour, it will change back to the default of 4 hours (240 minutes).

On systemd-based systems (for example, SLE 12 and later), the default time interval is set in /etc/systemd/system/timers.target.wants/rhnsd.timer:

[Timer]
OnCalendar=00/4:00
RandomizedDelaySec=30min

You can create an overriding drop-in file of rhnsd.timer with:

systemctl edit rhnsd.timer

For example, if you want configure a two hour time interval, enter:

[Timer]
OnCalendar=00/2:00

On write, the file will be saved as /etc/systemd/system/rhnsd.timer.d/override.conf. For more information about system timers, see the manpages of systemd.timer and systemctl.

As the root you may view the status of the rhnsd daemon with:

/etc/init.d/rhnsd status

And the status of the rhnsd service with:

service rhnsd status

For tunneling connections via SSH, two available port numbers are required, one for tunneling HTTP and the second for tunneling via HTTPS (HTTP is only necessary during the registration process). The port numbers used by default are 1232 and 1233. To overwrite these, add two custom port numbers greater than 1024 to /etc/rhn/rhn.conf like this:

ssh_push_port_http = high port 1
ssh_push_port_https = high port 2

If you would like your clients to be contacted via their hostnames instead of an IP address, set the following option:

ssh_push_use_hostname = true

It is also possible to adjust the number of threads to use for opening client connections in parallel. By default two parallel threads are used. Set taskomatic.ssh_push_workers in /etc/rhn/rhn.conf like this:

taskomatic.ssh_push_workers = number

For security reasons you may desire to use sudo and SSH into a system as a user other than root . The following procedure will guide you through configuring sudo for use with Push via SSH.

Note: sudo Requirements

The packages spacewalk-taskomatic >= 2.1.165.19 and spacewalk-certs-tools ⇒ 2.1.6.7 are required for using sudo with Push via SSH.

As your clients cannot reach the server, you will need to register your clients from the server. A tool for performing registration of clients from the server is included with SUSE Manager and is called mgr-ssh-push-init. This tool expects a client’s hostname or IP address and the path to a valid bootstrap script located in the server’s filesystem for registration as parameters.

Important: Specifying Ports for Tunneling before Registering Clients

The ports for tunneling need to be specified before the first client is registered. Clients already registered before changing the port numbers must be registered again, otherwise the server will not be able to contact them anymore.

Note: mgr-ssh-push-init Disables rhnsd

The mgr-ssh-push-init command disables the rhnsd daemon which normally checks for updates every 4 hours. Because your clients cannot reach the server without using the Push via SSH contact method, the rhnsd daemon is disabled.

For registration of systems which should be managed via the Push via SSH tunnel contact method, it is required to use an activation key that is configured to use this method. Normal Push via SSH is unable to reach the server. For managing activation keys, see Chapter 7, Activation Key Management.

Run the following command as root on the server to register a client:

# mgr-ssh-push-init --client client --register \
/srv/www/htdocs/pub/bootstrap/bootstrap_script --tunnel

To enable a client to be managed using Push via SSH (without tunneling), the same script may be used. Registration is optional since it can also be done from within the client in this case. mgr-ssh-push-init will also automatically generate the necessary SSH key pair if it does not yet exist on the server:

# mgr-ssh-push-init --client`client`--register bootstrap_script

When using the Push via SSH tunnel contact method, the client is configured to connect SUSE Manager via the high ports mentioned above (see /etc/sysconfig/rhn/up2date ). Tools like rhn_check and zypper will need an active SSH session with the proper port forwarding options in order to access the SUSE Manager API. To verify the Push via SSH tunnel connection manually, run the following command on the SUSE Manager server:

# ssh -i /root/.ssh/id_susemanager -R high port: susemanager :443`client`zypper ref

The contact method to be used for managing a server can also be modified via the API. The following example code (python) shows how to set a system’s contact method to ssh-push. Valid values are:

client = xmlrpclib.Server(SUMA_HOST + "/rpc/api", verbose=0)
key = client.auth.login(SUMA_LOGIN, SUMA_PASSWORD)
client.system.setDetails(key, 1000012345, {'contact_method' : 'ssh-push'})

Note: Migration and Management via Push via SSH

When a system should be migrated and managed using Push via SSH, it requires setup using the mgr-ssh-push-init script before the server can connect via SSH. This separate command requires human interaction to install the server’s SSH key onto the managed client (root password). The following procedure illustrates how to migrate an already registered system:

Existing activation keys can also be edited via API to use the Push via SSH contact method for clients registered with these keys:

client.activationkey.setDetails(key, '1-mykey', {'contact_method' : 'ssh-push'})

It is possible to use Push via SSH to manage systems that are connected to the SUSE Manager server via a proxy. To register a system, run mgr-ssh-push-init on the proxy system for each client you wish to register. Update your proxy with the latest packages to ensure the registration tool is available. It is necessary to copy the ssh key to your proxy. This can be achieved by executing the following command from the server:

{prompt.root}mgr-ssh-push-init --client`proxy`

Figure 8.3: Push via Salt SSH Contact Method #

Salt provides “Salt SSH” (salt-ssh), a feature to manage clients from a server. It works without installing Salt related software on clients. Using Salt SSH there is no need to have minions connected to the Salt master. Using this as a SUSE Manager connect method, this feature provides similar functionality for Salt clients as the traditional Push via SSH feature for traditional clients.

This feature allows:

To bootstrap a Salt SSH system, proceed as follows:

Now the system will be bootstrapped and registered in SUSE Manager. If done successfully, it will appear in the Systems list.

There are two kinds of parameters for Push via Salt SSH:

The Push via Salt SSH feature uses a taskomatic job to execute scheduled actions using salt-ssh. The taskomatic job periodically checks for scheduled actions and executes them. While on traditional clients with SSH push configured only rhn_check is executed via SSH, the Salt SSH push job executes a complete salt-ssh call based on the scheduled action.

For more information, see

This section covers enabling the osa-dispatcher and osad services, and performing initial setup.

OSAD clients use the fully qualified domain name (FQDN) of the server to communicate with the osa-dispatcher service.

SSL is required for osad communication. If SSL certificates are not available, the daemon on your client systems will fail to connect. Make sure your firewall rules are set to allow the required ports. For more information, see Table 1.1, “Required Server Ports”.

Configuration and Log Files. Each OSAD component is configured by local configuration files. We recommend you keep the default configuration parameters for all OSAD components.

Troubleshooting OSAD. If your OSAD clients cannot connect to the server, or if the jabberd service takes a lot of time responding to port 5552, it could be because you have exceeded the open file count.

Every client needs one always-open TCP connection to the server, which consumes a single file handler. If the number of file handlers currently open exceeds the maximum number of files that jabberd is allowed to use, jabberd will queue the requests, and refuse connections.

To resolve this issue, you can increase the file limits for jabberd by editing the /etc/security/limits.conf configuration file and adding these lines:

jabbersoftnofile5100
jabberhardnofile6000

Calculate the limits required for your environment by adding 100 to the number of clients for the soft limit, and 1000 to the current number of clients for the soft limit. In the example above, we have assumed 500 current clients, so the soft limit is 5100, and the hard limit is 6000.

You will also need to update the max_fds parameter in the /etc/jabberd/c2s.xml file with your chosen hard limit:

<max_fds>6000</max_fds>