Using ssh to retrieve hobbit data 🔗 link

I am converting my BB 19.c system to Hobbit 4.1.2p1.  With BB I used to 
use ssh to fetch data from remote servers in a DMZ (using the 
bb-fetchtab).   Can I do this in Hobbit.  I have searched the mail archive 
and manuals and didn't see the option anywhere. 

Regards,
Jim

Jim Horwath
SANS Certified: GCUX, GCIH, GCIA, GHTQ, GREM
Unix Admin


This message, and any attachments to it, may contain information that
is privileged, confidential, and exempt from disclosure under
applicable law.  If the reader of this message is not the intended
recipient, you are notified that any use, dissemination, distribution,
copying, or communication of this message is strictly prohibited.  If
you have received this message in error, please notify the sender
immediately by return e-mail and delete the message and any
attachments.  Thank you.

OK, this probably isn't the ideal solution, but it seems to be working
for me at the moment.  I've only just started with Hobbit, so I'm sure
there's a better way of doing this.

My remote system is running bb18b3, with bb-file.sh from
bbfetch2.3.tar.gz replacing bin/bb so that tmp/BBSTAT is created
instead of pushing local messages to a BB server.  You probably
already had that part working...

On my Hobbit server I copied bb-fetch.sh to server/ext.  The only
change necessary in bb-fetch.sh was

   <     . $BBHOME/etc/bbdef.sh                    # INCLUDE STANDARD
DEFINITIONS
   ---

    . $BBHOME/etc/hobbitserver.cfg                    # INCLUDE

STANDARD DEFINITIONS

Then in server/etc/hobbitlaunch.cfg, add:

   [fetch]
           ENVFILE /home/hobbit/server/etc/hobbitserver.cfg
           NEEDS hobbitd
           CMD $BBHOME/ext/bb-fetch.sh
           LOGFILE $BBSERVERLOGS/hobbitclient.log
           INTERVAL 5m


Hobbit seems to be happy fetching the remote BBSTAT file and receiving
the extracted cpu, disk, msgs & procs data.

Unfortunately I don't have time right now to upgrade the remote client
to Hobbit, so I don't know how (or if) bb-file.sh would work with it.

Ralph Mitchell

On 1/3/06, James B Horwath <user-9b4f5b722116@xymon.invalid> wrote:

On Tue, Jan 03, 2006 at 02:37:15PM -0500, James B Horwath wrote:

I haven't done this, but off the top of my head it could be done like
this:

1) Install the Hobbit client on the servers you monitor.
   Near the bottom of the clients' ~hobbit/client/bin/hobbitclient.sh
   you'll see this bit of code:

     if test "$LOCALMODE" = "yes"; then
        echo "@@" >> $TEMPFILE
        $BBHOME/bin/hobbitd_client --local --config=$BBHOME/etc/localclient.cfg <$TEMPFILE
     else
        $BB $BBDISP "@" < $TEMPFILE
     fi

   Which is what takes care of sending the client status to Hobbit.
   Just comment out those lines, or delete them ... this will simply
   make the client put the status message in client/tmp/msg.txt .


2) On the Hobbit server, run a script to fetch the client status files.
   You can run it as a Hobbit server extension script (add it to 
   hobbitlaunch.cfg); it would go something like this:

   bbhostgrep fetchdata | \
   while read L; do
         set $L
	 IP=$1
	 HOSTNAME=$2
	 LOGFILE=$BBTMP/clientmsg-$HOSTNAME.txt

	 # Delete the old statusfile and get the new one
	 rm -f $MSGFILE
	 scp hobbit@$HOSTNAME:client/tmp/msg.txt $MSGFILE

         if test -f $MSGFILE; then
	    # Got a statusfile, send it to Hobbit
	    $BB $BBDISP "@" < $MSGFILE
	 fi
   done

   This uses the bbhostgrep command to pick out those hosts that have a
   "fetchdata" in their bb-hosts entry. It then scp's the client status
   file over to the Hobbit server, and runs the normal "bb" command to
   feed the client status report into the Hobbit server.

   You will of course need to arrange for ssh to login to each of the
   clients without requiring a password, but you probably already did
   that with bb-fetch.


This is a rough solution. It doesn't deal with scp taking a loooooong
time to login or timeout if your client is down; it doesn't delete the
client-side status message, so if you client stops running you won't
notice it going purple. But it should give you an idea of how it can
be done, and it would work for the common case.


Regards,
Henrik

On 1/4/06, Henrik Stoerner <user-ce4a2c883f75@xymon.invalid> wrote:

bb-fetch.sh doesn't delete the client-side status message either.  It
keeps the old copy and diffs the new copy against it.  If there's no
difference, the client-side isn't updating.  So, your rough solution
would become something along the lines of:

         # Save the old statusfile and get the new one
        mv $HOSTNAME.$MSGFILE $HOSTNAME.$MSGFILE.old
        scp hobbit@$HOSTNAME:client/tmp/msg.txt $HOSTNAME.$MSGFILE
        if [ -f $HOSTNAME.$MSGFILE.old ]; then
            changed=`$DIFF $HOSTNAME.$MSGFILE $HOSTNAME.$MSGFILE.old`
        else
            changed="new"
        fi

        if [ "$changed" = "" ]; then
             # report that the client isn't updating
        fi

Perhaps scp options ConnectionAttempts & ConnectTimeout would help
deal with the long login timeout??

Ralph Mitchell

In these scenarios, I have done a poor mans VPN with SSH instead of
fetching.  Using RSA keys, build a port forward from the BB/hobbit client
local 1984 to the BB/hobbit server.  You then configure the BB/hobbit
client to use localhost as its BB/hobbit server for communications.

This is "trusted Network' to 'DMZ" security friendly . . .

I then run a monitor on the BB/hobbit server, that attempts to detect the
VPN, and create if it doesn't exist.  The VPN is 'activated' by an "rvs"
tag in the bb-hosts file.  I have had issues with the monitor attempting
to build multiple tunnels, but haven't pinned it down.

This all presumes the bb/hobbit user on the bb/hobbit server can signing
via ssh to the bb/hobbit client without passwords (using keys).

Personally, I prefer unencrypted user private keys over HostBased.


-- 
Scott Walters
-PacketPusher

The script might help ;)

On Wed, 4 Jan 2006, Scott Walters wrote:

-- 
Scott Walters
-PacketPusher