survivor: Remote Daemon (sr)

SURVIVOR: Remote Daemon
About `sr` Dependencies Installation For Use With Plaintext Transport Module For Use With Tunnel Transport Module
About `sr`
usage |
        sr [-lL] [-C <checkmods>] [-F <fixmods>] [-h <hostlist>]
           -m <moddir> [-u <user>]
where -l: Enables syslogging of connections, to the `daemon.info` facility -L: Enables debugging via syslog, to the `daemon.info` facility checkmods: Permits the comma separated list of Check modules to run with superuser privileges (see `-u user`) fixmods: Permits the comma separated list of Fix modules to run with superuser privileges (see `-u user`) hostlist: Comma separated list of hosts permitted to connect moddir: The location where modules may be found user: If run as root, become this user before executing unprivileged modules
The Survivor Remote Daemon is a utility designed to execute Check and Fix modules directly on monitored hosts. It is designed to be used in conjunction with transport modules. The `sr` protocol is described here. ### Dependencies None.
Installation
The remote daemon is installed in `$INSTDIR/sbin/sr`. The modules it expects to run are installed under `$INSTDIR/mod`. Both of these must be installed on any host that will use remote Checks. No special configuration files are necessary. An installation suitable for these hosts can be made as follows:
      # cd survivor build directory
      # make install-remote
This will install a subset of the standard installation. Only scripted remote modules will be installed. `sr` can be accessed using two supplied methods. Both methods may be used concurrently, and additional methods may be added. ### For Use With Plaintext Transport Module In this method, the `plaintext` module establishes a TCP connection directly to the remote host, which runs `sr` via inetd. This method is somewhat easier to set up and requires less overhead in system resources, but offers somewhat weaker security. After the daemon and module directories are in place, add an entry to `/etc/services` for `sr`. Any service name and port number may be used (although the `plaintext` module uses the name `sr` by default), the following is only a suggestion:
     sr              4891/tcp        # Survivor remote daemon
It is strongly recommended that access to this service be restricted. This can be accomplished by wrapping the service with TCP Wrappers, or by providing a hostlist on the argument line. If TCP Wrappers are installed, the following line is suggested for `/etc/hosts.allow`:
     sr: ALL@ALL EXCEPT scheduler-host.site.org : DENY
Finally, add an entry to `/etc/inetd.conf`. The sample directories given below should be replaced with whatever the installed locations actually are. The user with the minimum amount of privileges required to execute the appropriate checks successfully should be used. However, it is also possible to run as root, and tell `sr` to drop privileges when not needed. With TCP wrappers, always running as user nobody:
     sr      stream  tcp     nowait  nobody \
     /opt/local/sbin/tcpd /opt/survivor/sbin/sr -m /opt/survivor/mod
Or without TCP wrappers, also running as user nobody:
     sr      stream  tcp     nowait  nobody \
     /opt/survivor/sbin/sr sr -l -m /opt/survivor/mod -h scheduler-host.site.org
Or without TCP wrappers, running as root, but dropping to nobody for any module other than mailq and ptys:
     sr      stream  tcp     nowait  root \
     /opt/survivor/sbin/sr sr -l -m /opt/survivor/mod \
     -h scheduler-host.site.org,test.domain.org -u nobody -C mailq,ptys
A test by hand should look something like this:
     scheduler-host% telnet clienthost 4891
     Trying 127.0.0.1...
     Connected to clienthost.
     Escape character is '^]'.

     version
     OK v2
     check ping
     OK send SurvivorCheckData
     BEGIN DATA
     <?xml version="1.0" encoding="iso-8859-1"?>
      <SurvivorCheckData Version="1.0">
       <Host>localhost</Host>
       <Timeout>180</Timeout>
      </SurvivorCheckData>
     END DATA
     BEGIN RESPONSE
     <?xml version="1.0" encoding="iso-8859-1"?>
     <SurvivorCheckResult Version="1.0">
      <Host>localhost</Host>
      <ReturnCode>0</ReturnCode>
      <Scalar>1</Scalar>
      <Comment>Host up</Comment></SurvivorCheckResult>
     END RESPONSE
     exit
     OK Goodbye
     Connection closed by foreign host.
The `plaintext` transport module may now be configured. Note: Some versions of inetd restrict the number of arguments that may be passed. For example, on Solaris 2.7 and earlier, this limit is five arguments, meaning the `-u` and `-C` options in the third example would not be passed. As a workaround, `sr` will accept semicolons instead of spaces as argument separators. For example:
     sr      stream  tcp     nowait  root    /opt/survivor/sbin/sr sr -l;\
     -m;/opt/survivor/mod;-h;scheduler-host.site.org,test.domain.org;-u;nobody;\
     -C;mailq,ptys
### For Use With Tunnel Transport Module In this method, the `tunnel` module executes the requested command/transport (ssh or kerberized rsh are recommended) to run `sr` on the remote host. This method is somewhat more difficult to set up and requires greater system resources, but offers better security. In order for this method to work, the `tunnel` module must be able to establish a connection to the remote host without receiving any messages and without needing to answer any prompts (eg: to type a password or passphrase). The specific details of how to do this are beyond the scope of this document, as they vary by method of transport used. However, the functionality required is the equivalent of that provided by a `.rhosts` file. This automatic login can be provided via several methods. Via ssh, files such as `.shosts` or authorized keys can be used. Via Kerberized rsh, files such as `.klogin` or `.k5login` can be used. The `tunnel` module does not need to run as the same user as `sr`. Any login authorized by the transport will work. To test automatic logins by hand, use the following format:
     $command $host $rinstdir/sbin/sr -m $rinstdir/mod
For example:
     scheduler-host% /usr/bin/ssh -l nobody clienthost \
     /opt/survivor-current/sbin/sr -m /opt/survivor-current/mod

     version
     OK v2
     check ping
     OK send SurvivorCheckData
     BEGIN DATA
     <?xml version="1.0" encoding="iso-8859-1"?>
      <SurvivorCheckData Version="1.0">
       <Host>localhost</Host>
       <Timeout>180</Timeout>
      </SurvivorCheckData>
     END DATA
     BEGIN RESPONSE
     <?xml version="1.0" encoding="iso-8859-1"?>
     <SurvivorCheckResult Version="1.0">
      <Host>localhost</Host>
      <ReturnCode>0</ReturnCode>
      <Scalar>1</Scalar>
      <Comment>Host up</Comment></SurvivorCheckResult>
     END RESPONSE
     exit
     OK Goodbye
The `tunnel` transport module may now be configured. $Date: 2006/11/19 17:29:50 $ $Revision: 0.13 $ | keywords