Deployment to remote hosts

Method A: The deploy.sh script

samhain includes a system to facilitate deployment of the client to remote hosts. To use this system, the following requirements must be met:

  1. You must have compiled the server (yule) on the local host from which you distribute, and it must be in your PATH

  2. For each operating system type, there must be (at least) one host where development tools (C compiler, make, strip) are available to build the client.

  3. On each remote host, you must be able to login as root with ssh.

There are two major parts of this system:

After building the client on one host of some system type, the executable will automatically be retrieved and stored in profiles/os-machine/ for further distribution. No development tools (compiler, make, strip, install) are required then on other hosts of the same type for deployment of the compiled executable to them.

deploy.sh takes the following arguments:

Usage Notes

  • Deployment occurs in two separate stages: First, you need to build the executable on some host, using the --build-host option of deploy.sh. Second, you can then distribute to other hosts using the --remote-host option of deploy.sh.

  • You must run configure first, and compile and install the server (yule), before using deploy.sh.

  • yule must be in your PATH, if deploy.sh is not used from the top source directory. It is not necessary to have the server running, though.

  • It is recommended that you use make install-deploy to install the required files of the deploy system to to the samhain data directory (see the Section called Paths in the appendix called List of compilation options>), and deploy.sh to sbindir, i.e. the same directory where yule gets installed.

  • deploy.sh uses ssh/scp. You need to have the sshd daemon running on the remote host. It is helpful if RSA-based authentication is possible for root, otherwise you have to type in your password quite a few times.

    TipTIP
     

    To use RSA-based authentication in a secure way, it is recommended to proceed as follows:

    Use ssh-keygen to create a public/private key pair. Don't forget to set a passphrase for the private key (ssh-keygen will ask for it).

    Copy the public key (HOME/.ssh/identity.pub to HOME/.ssh/authorized_keys on any remote host where you want to log in. Do not copy the private key HOME/.ssh/identity to any untrusted host !

    On your central host, execute the commands (in a bash/bourne shell, and with "ssh-agent -s" in backticks):

    bash$eval `ssh-agent -s`
    bash$ssh-add

    You can then ssh/scp without typing the passphrase again, until you exit the current shell.

  • WarningWarning
     

    On Solaris, the PATH environment variable on the remote host (where you build or deploy) may get set according to /etc/default/su, which may be different from what you would expect (noted by S. Bailey).

  • Options --xor-code, --base1, --base2 are needed for consistency across multiple runs of configure. This is not important for client/server interaction, but for verification of e-mails/log files written by the client (if you make use of these additional logging facilities).

  • The deployed client is compiled to retrieve the database and the configuration file from the server. It will not work (except for initialization of the database) with database/configuration files stored on the client side. When invoked for file system checking, the deployed client will expect the server running on the host specified by --loghost, which by default is set to the local host on which deploy.sh is executed (surprise, surprise ...).

  • If you have properly used the options --clients and --client-files, you just need to send SIGHUP to the server after deploying a client, and everything is ready on the server side.

  • If you want to start the client immediately after deployment (normally, it would be started after the first reboot by the installed init script), then you need to add a command at the bottom of profiles/os-machine/bootscript (i.e. the shell script that modifies the remote host system configuration to make samhain start when booting).

    Note that when this script is run, the server is not yet ready for serving the database and config file to the client (they are not uploaded to the server yet), therefore you must use at to start the client with some delay (example for SuSE Linux): echo /sbin/init.d/samhain start | at now + 1hour

  • To add support for another system type, just create a subdirectory named profiles/architecture/ in the source tree, and figure out appropriate files configopts, samhainrc, and bootscript. Note that the layout of the run level directories (with scripts to start/stop services when booting) is usually different for any two different Linux distros.