SUSE Manager/Server Push

From MicroFocusInternationalWiki
Jump to: navigation, search

Server push for SUSE Manager - POC

This describes the basic mechanisms how to configure SUSE Manager and a client so that actions for the client get triggered by the server.

Please note that for the initial installation of the client the server needs to be reachable by the client. Once the configuration is done, further system administration can be done via SUSE Manager even if the firewall on the server prohibits the client from connecting.

Step by step for the impatient

In this example the server is named, the client The assumption is that the client is already registered on the server.

Steps to be done on the server

Create ssh access to the client

 f65:~ # ssh-keygen
 f65:~ # ssh-copy-id -i ~/.ssh/

Test ssh access to the client

 f65:~ # ssh ls
 f65:~ #

Forbid access from the client to the server (testing)

 f65:~ # iptables -I INPUT 1 --src -p tcp --destination-port 443 -j REJECT

Test forbidden access from the client

 f247:~ # rhn_check
 Could not retrieve action from <RetryServer for>.
 Possible networking problem?

Steps to be done on the client

Modify /etc/sysconfig/rhn/up2date

 Old:  serverURL=
 New:  serverURL=

In this example 1234 is the (high) port we are going to use later on for port forwarding. Any arbitrary, unused port can be used.

Now modify /etc/hosts

 Old:       localhost
 New:       localhost f65



Now schedule some action for the client in the Web-UI (such as installing a package or deploying a config file).

Trying to execute action from the client will fail:

 f247:~ # rhn_check
 Could not retrieve action from <RetryServer for>.
 Possible networking problem?
 f247:~ #

Now we trigger the action from the server via port forwarding:

 f65:~ # ssh -R rhn_check
 f65:~ #


Remarks and constrains

  1. while rhn_check is running, the server's port 443 can be reached from the client via port 1234 from other processes as well!
  2. since we are faking localhost to be the server (via the entry in /etc/hosts), the server cannot be reached anymore from the client at all! But since the server should not be reachable from the client anyway, this should not be a problem.
  3. since rhn_check knows a special option --proxy, it would even be possible to install this mechanism without faking localhost to be the server. The call from the server then would look like this: ssh -R rhn_check --proxy=localhost. But you will need to fiddle with all those interesting proxy settings then :/
  4. a server initiated rhn_check leads to warnings on the client Dec 3 11:57:12 f247 sshd[25227]: Address maps to, but this does not map back to the address - POSSIBLE BREAK-IN ATTEMPT!. This can certainly be solved by some appropriate DNS setup, but I'm not an expert in that area. Just wanted to point it out. The message is quite clear.
  5. the server initiated rhn_check can be run via cron on a regular basis as long as it is not yet implemented in SUSE Manager. You need to ensure that the time between two runs is at least as long as rhn_check needs to finish. If you run rhn_check while another one is running, the second one will fail, as it will try to forward a port that is already in use. This will result in warning mails from cron that a command has failed.