On Sun, May 28, 2006 at 02:46:45AM -0700, Charles Jones wrote:
I have several questions, none of them related to each other:
- 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.
- 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".
- Can we use regular expressions or wildcards in the "expect" option of bb-services?
No.
- 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.
- 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.
- 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