setiherder - GTK+ application for managing SETI@home clients

    Version 0.2, beta release Copyright Brian Naylor, April-May 1999
    <brian+seti@sackheads.org>
    http://www.sackheads.org/setiherder/

--------------------------------------------------------------------------

  setiherder is a GTK+ interface that can monitor and control a set of 
remote SET@home clients for you under a single gui.  It simplifies 
management of numerous hosts, making the task of finding alien 
intelligence that much easier. 

  setiherder was inspired by Andy Sloane's ncurses program, setiview, and
the fact that I found it an extreme PITA to check and restart all my 
screened setiview sessions on 20 different machines.

OSes supported:
  - Linux
  - AIX
  - FreeBSD
Reported as working:
  - Solaris
    (shouldn't be too hard to build elsewhere)
Software required:
  - SETI@home client.  Tested with versions 0.42 - 1.1.
    http://setiathome.ssl.berkeley.edu/
  - GTK+ 1.2  (gtk 1.2.2 or better is suggested, as 1.2.{0,1} have a bug
               that affects the expanded dialog)
  - ssh, or some other way of non-interactively spawning processes on
    remote hosts (a perl one is included in the distribution if you'd 
    rather use that.  see docs/README.setid)

  Read the INSTALL file for installation instructions, and PORTING for 
information on porting setiherder to other OSes.


What you need to know right off the bat:

    Add a client with the 'Add client' button.  Setiherder will 
  automatically save all your client info.  Edit those clients and
  perform operations on them by right-clicking them in the list.

  Executing seti@home:

   -- in general:

      You must decide whether you want to use my 'setid' perl script on
    your client boxes to control the setiathome process, or the previous
    ssh/rsh method.  Using setid will allow you to "detach" a remote client,
    leaving it running when you exit setiherder.  It also may be easier to
    set up if you don't already have ssh/etc working correctly.  OTOH, 
    setid is new code, and hasn't been pounded on, so if you're paranoid
    I'd recommend sticking with what you know.  See docs/README.setid
    for more info.

      -- If you *don't* use setid:

      You must provide setiherder with a local command that will cause
    the seti client to be run on a remote machine with no user interaction.
    I use ssh (-t) to do this, though I suppose rsh would work as well, or
    whatever else you might want to use that can do the same thing.  ssh
    is clearly superior. :)  If you need to know how to get ssh to do
    that without user interaction, please see docs/README.ssh.

      The only requirement is that you execute setiathome and return its
    output in a timely fashion (as it occurs.)

      Now, you can't just execute '/path/to/seti/setiathome'.  The seti 
    client will start out in whatever directory you start in, and will
    not be able to find its data files.  There is no option on the client
    to tell it where to look, so you have to first change into that
    directory yourself.  
      The easiest way of doing this is with a small script that just 
    changes to the appropriate directory and exec's setiathome.  Just such
    a script is included in this tarball.  (scripts/setistart)  You call it 
    like:

      setistart /path/to/seti

      It's annoying to have to copy that script to all your target machines, 
    but you should only have to do it once.  If that's too annoying for you, 
    you can enter the whole command in as an argument to ssh in the gui like 
    this:

      ssh -t hostname sh -c "cd /path/to/seti; exec ./setiathome"

      ..and that also works like a charm.  It's up to you.  

      NOTE: You *must* use ssh's -t argument.  If you don't, it won't
      allocate a pseudo-terminal for its child and the remote system
      will buffer seti@home's output indefinitely.

     -- If you *do* use setid:

      XXX


   -- locally: 

        You *must* use the 'exec' keyword when starting setiathome
      from an intermediate script.  If you do not, it will drop into the
      background like a daemon and setiherder will not be able to stop it.
      Furthermore, you have to use the script on localhost -- the sh -c ".."
      trick is currently unsupported when used directly from the gui.

        A current bug manifests itself in such a way that if the command
      you enter as your seti@home command is not correct -- non-executable
      script, command not found in path, etc -- Bad Things Happen.  To 
      avoid this, don't type in bogus commands.  =)  Seriously, I'm working
      on it.  In the meantime, be careful.
       
  That's it for now.  More later.  Have fun.  Send problems, comments, 
flames, praise, patches, etc. to brian+seti@sackheads.org.

