SUSE Manager/Server Push
- 1 Server push for SUSE Manager - POC
- 1.1 Step by step for the impatient
- 1.1.1 Steps to be done on the server
- 1.1.2 Steps to be done on the client
- 1.2 Testing
- 1.3 Remarks and constrains
- 1.1 Step by step for the impatient
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 f65.suse.de, the client f247.suse.de. 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/id_rsa.pub email@example.com
Test ssh access to the client
f65:~ # ssh f247.suse.de ls bin ssl-build f65:~ #
Forbid access from the client to the server (testing)
f65:~ # iptables -I INPUT 1 --src f247.suse.de -p tcp --destination-port 443 -j REJECT
Test forbidden access from the client
f247:~ # rhn_check Could not retrieve action from <RetryServer for f65.suse.de/XMLRPC>. Possible networking problem?
Steps to be done on the client
Old: serverURL=https://f65.suse.de/XMLRPC New: serverURL=https://f65.suse.de:1234/XMLRPC
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: 127.0.0.1 localhost New: 127.0.0.1 localhost f65.suse.de 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 f65.suse.de:1234/XMLRPC>. Possible networking problem? f247:~ #
Now we trigger the action from the server via port forwarding:
f65:~ # ssh -R 1234:f65.suse.de:443 f247.suse.de rhn_check f65:~ #
Remarks and constrains
- while rhn_check is running, the server's port 443 can be reached from the client via port 1234 from other processes as well!
- 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.
- 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 1234:f65.suse.de:443 f247.suse.de rhn_check --proxy=localhost. But you will need to fiddle with all those interesting proxy settings then :/
- a server initiated rhn_check leads to warnings on the client Dec 3 11:57:12 f247 sshd: Address 10.10.102.65 maps to f65.suse.de, 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.
- 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.