SURVIVOR: Remote Daemon
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