New Features #2 (the 'publish-cookie' option)
list Tom Kauffman
Did this make it into 4.0.3 RC1 or 2? Although, truth to tell, I prefer the acknowledge web page option. And I need to dig into Apache security (pointers to appropriate doc cheerfully accepted). I have 14 remote sites whith equipment we monitor centrally. I would really like each site's local contact to be able to acknowledge alerts or disable tests for his site only, while leaving the central support group the option to handle alerts and test disabling for all systems. Tom -----Original Message----- From: Henrik Stoerner [mailto:user-ce4a2c883f75@xymon.invalid] Sent: Tuesday, April 19, 2005 7:37 AM To: user-ae9b8668bcde@xymon.invalid Subject: Re: [hobbit] New Features #2 On Tue, Apr 19, 2005 at 10:44:36AM +0100, Marsh, Ian wrote:
What I'd like to be able to do is to pre-empt the alert by having access to the ack code earlier, as soon as the status changes to red, and have the code displayed on the individual test page. The way I envisage this happening is that the ack code is generated when the test turns red rather than when an alert is sent out. This code can then be included on the tests status page where we have easy access to it. The text could be displayed in a similar fashion to the text currently added when an alert is acknowledged.
Try the attached patch - should work against 4.0.2. Apply with cd hobbit-4.0.2 patch -p0 </tmp/hobbit-4.0.2-cookies.patch make stop hobbit make install (as root) start hobbit This makes the cookie appear on the detailed status page if it has not yet been acknowledged. By default I've disabled this - you must add the option "--publish-cookies" to the hobbitsvc.cgi command in ~/server/cgi-bin/bb-hostsvc.sh to enable this. I haven't yet made up my mind if this is a good idea or not. Another solution I've thought about is to make an acknowledge webpage similar to the enable/disable webpage, where you can choose which tests to acknowledge. And publishing the cookies on the status-page becomes more difficult with the planned changes to the alerting where escalations are handled. Regards, Henrik
list Henrik Størner
On Wed, May 11, 2005 at 01:18:01PM -0500, Kauffman, Tom wrote:
Did this make it into 4.0.3 RC1 or 2?
As you've probably found out: No. I decided against it, because I really don't like the idea of putting something that is supposed to be confidential on a webpage. It's just the wrong solution, so I won't encourage people to use it. (A couple of years back, I was doing a lot of IT security work - pen-testing, vulnerability scanning and such ... I still have that slightly paranoid instinct).
Although, truth to tell, I prefer the acknowledge web page option.
Me too.
▸
And I need to dig into Apache security (pointers to appropriate doc cheerfully accepted). I have 14 remote sites whith equipment we monitor centrally. I would really like each site's local contact to be able to acknowledge alerts or disable tests for his site only, while leaving the central support group the option to handle alerts and test disabling for all systems.
Apache security is most easily setup by separating the webpages into
different directories. In Hobbit, that maps nicely into putting hosts
on different pages and subpages. E.g. if you have this bb-hosts file:
page nyc New York
10.0.0.1 nyc-router-1
10.0.0.2 nyc-firewall
... more New York hosts ...
page la Los Angeles
10.2.0.1 la-router-1
Then in Apache you can setup access rules like this:
AuthGroupFile /etc/hobbit/admingroups
AuthUserFile /etc/hobbit/adminusers
AuthType Basic
AuthName "Hobbit monitor"
<Directory /var/lib/hobbit/www>
# Restrict access to the top-level page
Require group globaladmin
</Directory>
<Directory /var/lib/hobbit/www/gifs>
# Everyone allowed access to this
Require valid-user
</Directory>
<Directory /var/lib/hobbit/www/nyc>
# NYC page: Access allowed for global admins and the NYC admins
Require group globaladmin nycadmin
</Directory>
<Directory /var/lib/hobbit/www/la>
# LA page: Access allowed for global admins and the LA admins
Require group globaladmin laadmin
</Directory>
The "adminusers" file is constructed with the "htpasswd" utility,
and holds the login-names and passwords for your users. The
"admingroups" file then maps a user to a group:
globaladmin: tkauffman
nyadmin: jdoe,bsmith
laadmin: ajones
So depending on what username you login with, you're mapped to
a group - and that group membership is what controls your access
to the Hobbit pages. You'll need to grant full access to some
directories - like the www/gifs/ and the cgi-bin directory.
Controlling access to the acknowledge- and enable/disable functions
is a bit tricky: Acknowledge should be simple since you need the
ack token from an alert so you can do it by controlling who gets alerts
for hosts; the enable/disable function needs some tweaking to "lock"
users into handling only their own hosts - it might require some
changes to the hobbit-enadis CGI.
Hope that helps,
Henrik
list Tom Kauffman
Henrik -- Thanks for the apache pointers -- I was headed in that direction already, this just helps the clarification (I've already got site-level subpages, so that helps). On the acknowledge -- just because there's only one of me doesn't mean I'm not paranoid (man, does that ever parse badly!) I'd like to see something along the lines of an 'acknowledge' button on the individual test detail page, with a slot for time to live, and user authentication when the button gets clicked. (I think this was where you were going, but it's near the end of the day and, to quote Mr. Gumby, "My Brain Hurts"). All I've got to do now is re-gen the openLDAP code to add kerberos support, so I can authenticate against Win2003 AD. Thanks --
▸
Tom
-----Original Message-----
From: Henrik Stoerner [mailto:user-ce4a2c883f75@xymon.invalid]
Sent: Tuesday, May 24, 2005 4:22 PM
To: user-ae9b8668bcde@xymon.invalid
Subject: Re: [hobbit] New Features #2 (the 'publish-cookie' option)
On Wed, May 11, 2005 at 01:18:01PM -0500, Kauffman, Tom wrote:Did this make it into 4.0.3 RC1 or 2?
As you've probably found out: No. I decided against it, because I really don't like the idea of putting something that is supposed to be confidential on a webpage. It's just the wrong solution, so I won't encourage people to use it. (A couple of years back, I was doing a lot of IT security work - pen-testing, vulnerability scanning and such ... I still have that slightly paranoid instinct).
Although, truth to tell, I prefer the acknowledge web page option.
Me too.
And I need to dig into Apache security (pointers to appropriate doc cheerfully accepted). I have 14 remote sites whith equipment we monitor centrally. I would really like each site's local contact to be able to acknowledge alerts or disable tests for his site only, while leaving the central support group the option to handle alerts and test disabling for all systems.
Apache security is most easily setup by separating the webpages into
different directories. In Hobbit, that maps nicely into putting hosts
on different pages and subpages. E.g. if you have this bb-hosts file:
page nyc New York
10.0.0.1 nyc-router-1
10.0.0.2 nyc-firewall
... more New York hosts ...
page la Los Angeles
10.2.0.1 la-router-1
Then in Apache you can setup access rules like this:
AuthGroupFile /etc/hobbit/admingroups
AuthUserFile /etc/hobbit/adminusers
AuthType Basic
AuthName "Hobbit monitor"
<Directory /var/lib/hobbit/www>
# Restrict access to the top-level page
Require group globaladmin
</Directory>
<Directory /var/lib/hobbit/www/gifs>
# Everyone allowed access to this
Require valid-user
</Directory>
<Directory /var/lib/hobbit/www/nyc>
# NYC page: Access allowed for global admins and the NYC admins
Require group globaladmin nycadmin
</Directory>
<Directory /var/lib/hobbit/www/la>
# LA page: Access allowed for global admins and the LA admins
Require group globaladmin laadmin
</Directory>
The "adminusers" file is constructed with the "htpasswd" utility,
and holds the login-names and passwords for your users. The
"admingroups" file then maps a user to a group:
globaladmin: tkauffman
nyadmin: jdoe,bsmith
laadmin: ajones
So depending on what username you login with, you're mapped to
a group - and that group membership is what controls your access
to the Hobbit pages. You'll need to grant full access to some
directories - like the www/gifs/ and the cgi-bin directory.
Controlling access to the acknowledge- and enable/disable functions
is a bit tricky: Acknowledge should be simple since you need the
ack token from an alert so you can do it by controlling who gets alerts
for hosts; the enable/disable function needs some tweaking to "lock"
users into handling only their own hosts - it might require some
changes to the hobbit-enadis CGI.
Hope that helps,
Henrik