SURVIVOR: Remote Daemon | |||||||
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
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-remoteThis 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 ModuleIn 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 daemonIt 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 : DENYFinally, 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/modOr 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.orgOr 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,ptysA 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 ModuleIn 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/modFor 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 GoodbyeThe tunnel transport module may now be configured.
$Date: 2006/11/19 17:29:50 $ $Revision: 0.13 $ |
keywords |