[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [hobbit] Combo Message of Hobbit Questions :)
- To: hobbit (at) hswn.dk
- Subject: Re: [hobbit] Combo Message of Hobbit Questions :)
- From: henrik (at) hswn.dk (Henrik Stoerner)
- Date: Sun, 28 May 2006 12:53:08 +0200
- References: <44797185.9080907@cisco.com>
- User-agent: Mutt/1.5.9i
On Sun, May 28, 2006 at 02:46:45AM -0700, Charles Jones wrote:
> I have several questions, none of them related to each other:
>
> 1. I notice that "logfetch" is suid root. Will the hobbit client
> function normally if it is not suid and it is owned by the hobbit client
> user (assuming the hobbit client user can read /var/log/messages)? If so
> the client "make install" should not fail when being installed as the
> hobbit user.
It will function OK. It only uses suid-root privs when opening logfiles
or files that you request a checksum for. Assuming these can be done
without the root-privs, it will work fine.
I'll fix the "make install".
While on this subject, the "clientupdate" tool is also about to become
suid-root, because it needs root-privs to be able to update the logfetch
utility and keep that suid-root. I'll make sure that works OK if you
choose to install everything with non-root privileges.
> 2. Is there or will there be an option to not display the "Files"
> column? I'm not doing file checks on most hosts, and I'm tired of people
> asking me "why is that dot white?" :)
Will do. There will be "--no-clear-msgs", "--no-clear-files" and
"--no-clear-ports".
> 3. Can we use regular expressions or wildcards in the "expect" option of
> bb-services?
No.
> 4. If you update client-local.cfg, do you have to restart the clients
> for them to receive the new configurations, or will they pick it up on
> their next connect?
The hobbitd daemon keeps a copy of client-local.cfg in memory, and that
is what the clients actually get. It will check for updates to the file
regularly (every 10 minutes - the "--checkpoint-interval" option to
hobbitd), and reload it if there are any changes.
You can force a reload by sending a SIGHUP to the hobbitd process.
> 5. I have previously brought up the issue of Acknowledging alerts
> requires having the alert number from the alert email. This is a problem
> for folks who just monitor the web page, or more likely, find it
> frustrating to have to go find and open the alert email to cut and paste
> the number. What would be nice is if the Acknowledge alert page
> displayed all of the hosts currently in alert status, and let you select
> and ack them (either with seperate explanations, or a single for all
> selected).
The plan is to do the ack's directly from the web page of the status
that has a problem. This is being worked on, but will not appear until
after the 4.2 release.
> 6. I think I remember long ago you were considering adding a
> bbfetch-like functionality, to handle the cases where the remote hosts
> are behind a firewall/DMZ and the only port open was for SSH. Basically
> the Hobbit client would have an option to, instead of sending data to
> the hobbit server, write it to a static datafile that the hobbit server
> would scp over and process. Is this still on the drawing board?
It's not something I am working on. It would be a relatively simple job
for anyone who is interested, but I actually think it would be easier to
just setup SSH tunnels to the Hobbit server's port 1984 from the client
and let the client work without modifications.
I.e. from your Hobbit server you'd launch ssh connections to the clients
with "ssh -R 1984:127.0.0.1:1984 hobbit (at) clienthost" and then the Hobbit
client on clienthost is configured with BBDISP="127.0.0.1" .
That avoids the problems with having to copy the client-local.cfg
settings for each host over to the clients, and auto-update would also
work, because from the clients' perspective it is a normal network
connection to the Hobbit server.
Henrik