Re: [Nagios-users] Advanced permissions/user properties
Hi!
On Tue, 05 Dec 2006, Tobias Klausmann wrote:
> Thus, I'll probably patch NG to just ignore the perms.
>
> I'll post the patch here (if it's not too ugly ;))
See the attached file. Have fun.
Regards,
Tobias
--
Never touch a burning system.
--- NagiosGrapher.pm.orig 2006-12-07 15:15:40.0 +0100
+++ NagiosGrapher.pm2006-12-07 15:15:54.0 +0100
@@ -181,12 +181,15 @@
sub AuthCheck {
my $rw=0;
my ($cfg,$host,$user)[EMAIL PROTECTED];
+ my $cgroups="";
read_nagios_cfg($cfg) if(!$nagios_loaded_cfg);
if($nagiosversion==2) {
# Nagios Version 2.? Perform test
- $rw=1
if(parse_nagios_cfg('contactgroup',parse_nagios_cfg('host',$host,'contact_groups'),'members')
=~ m/$user(,|$)/);
+ $cgroups = parse_nagios_cfg('host',$host,'contact_groups');
+ $cgroups =~ s/:[^,]*//g;
+ $rw=1 if(parse_nagios_cfg('contactgroup',$cgroups,'members') =~
m/$user(,|$)/);
} else {
# Nagios Version 1.X isn't supported yet so everything is allowd
$rw=1;
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___
Nagios-users mailing list
Nagios-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-users
::: Please include Nagios version, plugin version (-v) and OS when reporting
any issue.
::: Messages without supporting info will risk being sent to /dev/null
Re: [Nagios-users] Advanced permissions/user properties
Hi! On Mon, 06 Nov 2006, Tobias Klausmann wrote: > > For backwards compatibility, the default would be rwxn. > > > > So, the engineers would have: nrx, customer: nr and helpdesk r. > > > > Attached is an updated patch. > > I'll try to get a peek at it this week. Well, it took a little longer due to other things acting up elsewhere. As far as I can tell, it works perfectly - except... We use NagiosGrapher to turn the perfdata into nice little colorful thingies for the app developers. Unfortunately, NG seems to not work well with the patch: It thinks "foo:r" is the group of the same name, not the group "foo". This will probably be easy to fix in a generic way (i.e. drop everything after the last ":") and a little more complicated if the perms should be parsed (though I have no idea what perms would be needed for the graph: n or x only would prevent the user to see the host/service (and thus the extinfo link) in the first place. And preventing "r" users from seeing the graphs doesn't make much sense, IMO). Thus, I'll probably patch NG to just ignore the perms. I'll post the patch here (if it's not too ugly ;)) > Thanks, again (all of you). I can only re-iterate that. Regards, Tobias -- I love the smell of burning bridges - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Nagios-users mailing list Nagios-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nagios-users ::: Please include Nagios version, plugin version (-v) and OS when reporting any issue. ::: Messages without supporting info will risk being sent to /dev/null
Re: [Nagios-users] Advanced permissions/user properties
Hi Ton. Ton Voon wrote: > On 6 Nov 2006, at 16:43, Alex Burger wrote: >> I haven't tried Nagios 3 yet, but it doesn't look like my patch will >> work with it. I'll see if I can port it over. Any idea when the >> release date is for v3? > > Ethan stated at the Nagios Conference that he was aiming for v3 to go > stable by end of this year. I was able to port the patch to Nagios 3.0 so hopefully there is enough time to consider it for the final release. I have submitted patches for both 2.5 and 3.0 to the Nagios-Devel list. This version also adds permissions to the escalation checks. Alex - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Nagios-users mailing list Nagios-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nagios-users ::: Please include Nagios version, plugin version (-v) and OS when reporting any issue. ::: Messages without supporting info will risk being sent to /dev/null
Re: [Nagios-users] Advanced permissions/user properties
On 6 Nov 2006, at 16:43, Alex Burger wrote:I haven't tried Nagios 3 yet, but it doesn't look like my patch will work with it. I'll see if I can port it over. Any idea when the release date is for v3?Ethan stated at the Nagios Conference that he was aiming for v3 to go stable by end of this year.Tonhttp://www.altinity.comT: +44 (0)870 787 9243F: +44 (0)845 280 1725Skype: tonvoon - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642___ Nagios-users mailing list Nagios-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nagios-users ::: Please include Nagios version, plugin version (-v) and OS when reporting any issue. ::: Messages without supporting info will risk being sent to /dev/null
Re: [Nagios-users] Advanced permissions/user properties
Hi Ton. Ton Voon wrote: >> Ton Voon wrote: > My only request is to add in the ability to check for a single contact > too. This will be more important in Nagios 3 as Ethan has said you will > be allowed to specify single contacts from a host/service definition, > without the need for contactgroups. I haven't tried Nagios 3 yet, but it doesn't look like my patch will work with it. I'll see if I can port it over. Any idea when the release date is for v3? Thanks Alex - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Nagios-users mailing list Nagios-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nagios-users ::: Please include Nagios version, plugin version (-v) and OS when reporting any issue. ::: Messages without supporting info will risk being sent to /dev/null
Re: [Nagios-users] Advanced permissions/user properties
Hi Tobias. Tobias Klausmann wrote: > I think one could make a case for x being everything that > concerns the current state of an object, i.e. mainly > acknowledgement(s). The w flag could be used for en/disabling > (semi)permanent stuff, like disabling active checks. > > On the other hand, many actions (like schedule downtime) would > fall into a grey area, so maybe using x for all of them and > "keeping" w for later is better. Right now, all commands that can be submitted are grouped together. I don't think there is currently any way to to allow someone to schedule downtime, but not force a check of all services. This of course could be changed, but I haven't looked at it yet. To implement this, we would need a list of all the possible service / host commands, and what permission a user should have to execute it. I had a quick look and it looks like most should require a 'wx' permission except for maybe 'schedule an imemdiate check of all services'. I don't like the idea of giving 're-schedule the next check of this service' to anyone with read access as they could set it to check a week from now. Like you said, maybe it's better to just keep the 'x' as it is. >> I also changed it so that you will only see a service if you are a >> contact for it. I think this is the same change that Ton mentioned in >> his last email. I did this to test the 'r' permission. > > This was the default in our installation (by way of not having an > asterisk in the corresponding line(s) in the main config file. It looks like if you are a contact for a host, then you automatically have access to view all services. I tested this by making a user (group) a contact for a host and only two of the host's services. The user was able to see all services even though he was not listed on the others. Alex - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Nagios-users mailing list Nagios-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nagios-users ::: Please include Nagios version, plugin version (-v) and OS when reporting any issue. ::: Messages without supporting info will risk being sent to /dev/null
Re: [Nagios-users] Advanced permissions/user properties
Alex Burger wrote:
r: View in web interface
x: Submit commands for this host/service
w: Not really needed yet. Maybe some of the other programs that allow
you to modify the configuration files could use w to allow a user to
modify the host / service.
n: Notify if contact has a pager or email defined
I also changed it so that you will only see a service if you are a
contact for it. I think this is the same change that Ton mentioned in
his last email. I did this to test the 'r' permission.
For backwards compatibility, the default would be rwxn.
Attached is an updated patch that adds a 'default_permissions' option to
nagios.cfg and cgi.cfg that Steve Shipway suggested. From
sample-config/cgi.cfg.in:
# DEFAULT HOST/SERVICE PERMISSIONS
# This option contains a list of default permissions for hosts and
# services that will be used when permissions are not explicitly
# set on a host or service. When not defined, the default is all
# permissions (rwxn). Note: This option must be set the same in
# both cgi.cfg and nagios.cfg.
#default_permissions=rwxn
As you can see, the option needs to be in both config files although I
would prefer to have it only in nagios.cfg. It is needed in nagios.cfg
for base/notifications.c which has nothing to do with the cgi. If
someone knows how to combine the two, please let me know, but I suspect
that the cgi and main nagios programs are completely separate from each
other.
If anyone can do some testing I would appreciate it.
Alex
diff -ur nagios-2.5.org/base/config.c nagios-2.5/base/config.c
--- nagios-2.5.org/base/config.c2005-12-26 18:18:14.0 -0500
+++ nagios-2.5/base/config.c2006-11-06 10:14:42.0 -0500
@@ -166,8 +166,7 @@
extern host**host_hashlist;
extern service **service_hashlist;
-
-
+extern char *default_permissions;
/**/
/** CONFIGURATION INPUT FUNCTIONS */
@@ -1418,6 +1417,22 @@
#endif
}
+ else if(!strcmp(variable,"default_permissions")){
+ if(default_permissions!=NULL)
+ free(default_permissions);
+ default_permissions=(char *)strdup(value);
+ if(default_permissions==NULL){
+ strcpy(error_message,"Could not allocate memory
for default permissions string");
+ error=TRUE;
+ break;
+ }
+ strip(default_permissions);
+
+#ifdef DEBUG1
+ printf("\t\tdefault_permissions set to
'%s'\n",default_permissions);
+#endif
+ }
+
/* ignore old/external variables */
else if(!strcmp(variable,"status_file"))
continue;
diff -ur nagios-2.5.org/base/nagios.c nagios-2.5/base/nagios.c
--- nagios-2.5.org/base/nagios.c2006-07-13 17:57:33.0 -0400
+++ nagios-2.5/base/nagios.c2006-11-06 10:28:00.0 -0500
@@ -208,7 +208,7 @@
circular_buffer service_result_buffer;
pthread_t worker_threads[TOTAL_WORKER_THREADS];
-
+char *default_permissions;
/* Following main() declaration required by older versions of Perl ut 5.00503
*/
#ifdef EMBEDDEDPERL
diff -ur nagios-2.5.org/base/notifications.c nagios-2.5/base/notifications.c
--- nagios-2.5.org/base/notifications.c 2006-04-07 18:24:13.0 -0400
+++ nagios-2.5/base/notifications.c 2006-11-06 10:07:56.0 -0500
@@ -45,7 +45,7 @@
extern char*generic_summary;
-
+extern char*default_permissions;
/**/
/* SERVICE NOTIFICATION FUNCTIONS */
@@ -832,7 +832,7 @@
/* find all contacts for this service */
for(temp_contact=contact_list;temp_contact!=NULL;temp_contact=temp_contact->next){
- if(is_contact_for_service(svc,temp_contact)==TRUE)
+
if(is_contact_for_service_perm(svc,temp_contact,default_permissions,'n')==TRUE)
add_notification(temp_contact);
}
}
@@ -1572,7 +1572,7 @@
/* get all contacts for this host */
for(temp_contact=contact_list;temp_contact!=NULL;temp_contact=temp_contact->next){
- if(is_contact_for_host(hst,temp_contact)==TRUE)
+
if(is_contact_for_host_perm(hst,temp_contact,default_permissions,'n')==TRUE)
add_notification(temp_contact);
}
}
diff -ur nagios-2.5.org/cgi/cgiauth.c nagios-2.5/cgi/cgiauth.c
--- nagios-2.5.org/cgi/cgiauth.c2006-10-08 19:35:18.0 -0400
+++ nag
Re: [Nagios-users] Advanced permissions/user properties
On 6 Nov 2006, at 11:29, Hari Sekhon wrote: This is a very interesting thread, especially since I am currently wondering how I can do this sort of thing. I want to give a web interface to consultants to view our web site availability. I have created a user and contactgroup which shows only the services I have added the group to. The problem is that even this limited account can switch off checks or notifications and I can't see a way to stop this. You can either use the "view some, change none" patch that we did: http://altinity.blogs.com/dotorg/2006/02/a_view_some_cha.htmlor the earlier patch in this thread from Alex with his new contactgroups permissions.Tonhttp://www.altinity.comT: +44 (0)870 787 9243F: +44 (0)845 280 1725Skype: tonvoon - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642___ Nagios-users mailing list Nagios-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nagios-users ::: Please include Nagios version, plugin version (-v) and OS when reporting any issue. ::: Messages without supporting info will risk being sent to /dev/null
Re: [Nagios-users] Advanced permissions/user properties
This is a very interesting thread, especially since I am currently
wondering how I can do this sort of thing. I want to give a web
interface to consultants to view our web site availability. I have
created a user and contactgroup which shows only the services I have
added the group to. The problem is that even this limited account can
switch off checks or notifications and I can't see a way to stop this.
It appears that when this account switches off a notification, this is
done on a global basis which is bad. I'm using nagios 1.4.1.
Reading through this thread it appears that the issue is under debate
at the moment. Does this mean that what I want, a read only user cannot
be done at the moment?
-h
Hari Sekhon
Ton Voon wrote:
On 4 Nov 2006, at 16:43, Alex Burger wrote:
Ton Voon wrote:
Hi Alex,
I think the "read/write" attribute
needs to be associated with the contact. So this implementation looks
more obvious (to me):
define contact {
name person
contactgroups cg1,cg2,cg3 # means can
submit commands
contactgroups_viewonly cg5,cg6
}
This would effectively mean the
can_submit_commands attribute is redundant, because you just use
contactgroups_viewonly instead of contactgroups.
The more I think about it, the more I
think we are looking at this the wrong way. With file system or
application permissions, we would assign a group to a folder/object,
and then pick what rights the group would have. Why don't we do the
same thing with Nagios?
Leave the groups as they are, but modify
the host and service contact_groups command? For example:
define host{
host_name
localhost
contact_groups
netops:rw, helpdesk:r
}
For backwards compatibility, if no
permissions are set, the defaults would be rw so the following would be
the same:
define host{
host_name
localhost
contact_groups
netops, helpdesk:r
}
If a user was in both the netops and
helpdesk group, the user should have rw access.
This will take a bit more work to
implement, but I think it makes more sense. What do you think?
Firstly, this is fantastic work, Alex. Nice to see someone run
with an idea.
I've been mulling this over the weekend and I think you're
right: I was looking at this the wrong way. It was very smart of you to
make the analogy with filesystem security and I think you have the
right design.
Authorization is about defining a user's permissions on an
object (http://en.wikipedia.org/wiki/Access_control#Authorization).
The base objects in Nagios are the host and service object. These
objects should then hold information about which users (contacts) are
allowed which permission. You've got a good thread on what the
permissions should be, so I'll ignore that. But the assigning of
permissions at the host/service definition is, I think, the right way
to go.
My only request is to add in the ability to check for a single
contact too. This will be more important in Nagios 3 as Ethan has said
you will be allowed to specify single contacts from a host/service
definition, without the need for contactgroups.
When you have your patch applied, I will request removal of the
can_submit_commands patch as this is just a fudge from the
sophisticated security model you will have added in (my patch is
analogous to setting a user to "/bin/false" for their shell, I guess).
Ton
http://www.altinity.com
T: +44 (0)870 787 9243
F: +44 (0)845 280 1725
Skype: tonvoon
-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
___
Nagios-users mailing list
Nagios-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-users
::: Please include Nagios version, plugin version (-v) and OS when reporting any issue.
::: Messages without supporting info will risk being sent to /dev/null
-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642___
Nagios-users mailing list
Nagios-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-users
::: Plea
Re: [Nagios-users] Advanced permissions/user properties
On 4 Nov 2006, at 16:43, Alex Burger wrote:Ton Voon wrote: Hi Alex,I think the "read/write" attribute needs to be associated with the contact. So this implementation looks more obvious (to me):define contact {name personcontactgroups cg1,cg2,cg3 # means can submit commandscontactgroups_viewonly cg5,cg6}This would effectively mean the can_submit_commands attribute is redundant, because you just use contactgroups_viewonly instead of contactgroups. The more I think about it, the more I think we are looking at this the wrong way. With file system or application permissions, we would assign a group to a folder/object, and then pick what rights the group would have. Why don't we do the same thing with Nagios?Leave the groups as they are, but modify the host and service contact_groups command? For example:define host{ host_name localhost contact_groups netops:rw, helpdesk:r}For backwards compatibility, if no permissions are set, the defaults would be rw so the following would be the same:define host{ host_name localhost contact_groups netops, helpdesk:r}If a user was in both the netops and helpdesk group, the user should have rw access.This will take a bit more work to implement, but I think it makes more sense. What do you think?Firstly, this is fantastic work, Alex. Nice to see someone run with an idea.I've been mulling this over the weekend and I think you're right: I was looking at this the wrong way. It was very smart of you to make the analogy with filesystem security and I think you have the right design.Authorization is about defining a user's permissions on an object (http://en.wikipedia.org/wiki/Access_control#Authorization). The base objects in Nagios are the host and service object. These objects should then hold information about which users (contacts) are allowed which permission. You've got a good thread on what the permissions should be, so I'll ignore that. But the assigning of permissions at the host/service definition is, I think, the right way to go.My only request is to add in the ability to check for a single contact too. This will be more important in Nagios 3 as Ethan has said you will be allowed to specify single contacts from a host/service definition, without the need for contactgroups.When you have your patch applied, I will request removal of the can_submit_commands patch as this is just a fudge from the sophisticated security model you will have added in (my patch is analogous to setting a user to "/bin/false" for their shell, I guess).Tonhttp://www.altinity.comT: +44 (0)870 787 9243F: +44 (0)845 280 1725Skype: tonvoon-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642___
Nagios-users mailing list
Nagios-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-users
::: Please include Nagios version, plugin version (-v) and OS when reporting
any issue.
::: Messages without supporting info will risk being sent to /dev/null
Re: [Nagios-users] Advanced permissions/user properties
Hi! First off: thanks for all your work, it didn't quite expect so much (and such constructive/worthwile) feedback. On Sun, 05 Nov 2006, Alex Burger wrote: > How about: > > r: View in web interface > > x: Submit commands for this host/service > > w: Not really needed yet. Maybe some of the other programs that allow > you to modify the configuration files could use w to allow a user to > modify the host / service. > > n: Notify if contact has a pager or email defined I think one could make a case for x being everything that concerns the current state of an object, i.e. mainly acknowledgement(s). The w flag could be used for en/disabling (semi)permanent stuff, like disabling active checks. On the other hand, many actions (like schedule downtime) would fall into a grey area, so maybe using x for all of them and "keeping" w for later is better. > I also changed it so that you will only see a service if you are a > contact for it. I think this is the same change that Ton mentioned in > his last email. I did this to test the 'r' permission. This was the default in our installation (by way of not having an asterisk in the corresponding line(s) in the main config file. > > For backwards compatibility, the default would be rwxn. > > So, the engineers would have: nrx, customer: nr and helpdesk r. > > Attached is an updated patch. I'll try to get a peek at it this week. Thanks, again (all of you). Regards, Tobias - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Nagios-users mailing list Nagios-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nagios-users ::: Please include Nagios version, plugin version (-v) and OS when reporting any issue. ::: Messages without supporting info will risk being sent to /dev/null
Re: [Nagios-users] Advanced permissions/user properties
Hugo van der Kooij wrote:
On Mon, 6 Nov 2006, Steve Shipway wrote:
Alex Burger wrote:
Leave the groups as they are, but modify the host and service
contact_groups command? For example:
define host{
host_name localhost
contact_groups netops:rw, helpdesk:r
}
For backwards compatibility, if no permissions are set, the defaults
would be rw so the following would be the same:
define host{
host_name localhost
contact_groups netops, helpdesk:r
}
To remain in the traditional unix style. How about an eXecute flag?
In this contact it would best be written as Notify flag instead.
So I can have 1 group as nrw (the engineers on call), customer on nr,
helpdesk on r.
How about:
r: View in web interface
x: Submit commands for this host/service
w: Not really needed yet. Maybe some of the other programs that allow
you to modify the configuration files could use w to allow a user to
modify the host / service.
n: Notify if contact has a pager or email defined
I also changed it so that you will only see a service if you are a
contact for it. I think this is the same change that Ton mentioned in
his last email. I did this to test the 'r' permission.
For backwards compatibility, the default would be rwxn.
So, the engineers would have: nrx, customer: nr and helpdesk r.
Attached is an updated patch.
Alex
diff -ur nagios-2.5.org/base/notifications.c nagios-2.5/base/notifications.c
--- nagios-2.5.org/base/notifications.c 2006-04-07 18:24:13.0 -0400
+++ nagios-2.5/base/notifications.c 2006-11-05 22:23:57.0 -0500
@@ -832,7 +832,7 @@
/* find all contacts for this service */
for(temp_contact=contact_list;temp_contact!=NULL;temp_contact=temp_contact->next){
- if(is_contact_for_service(svc,temp_contact)==TRUE)
+
if(is_contact_for_service_perm(svc,temp_contact,'n')==TRUE)
add_notification(temp_contact);
}
}
@@ -1572,7 +1572,7 @@
/* get all contacts for this host */
for(temp_contact=contact_list;temp_contact!=NULL;temp_contact=temp_contact->next){
- if(is_contact_for_host(hst,temp_contact)==TRUE)
+ if(is_contact_for_host_perm(hst,temp_contact,'n')==TRUE)
add_notification(temp_contact);
}
}
diff -ur nagios-2.5.org/cgi/cgiauth.c nagios-2.5/cgi/cgiauth.c
--- nagios-2.5.org/cgi/cgiauth.c2006-10-08 19:35:18.0 -0400
+++ nagios-2.5/cgi/cgiauth.c2006-11-05 22:55:28.0 -0500
@@ -218,7 +218,7 @@
temp_contact=find_contact(authinfo->username);
/* see if this user is a contact for the host */
- if(is_contact_for_host(hst,temp_contact)==TRUE)
+ if(is_contact_for_host_perm(hst,temp_contact,'r')==TRUE)
return TRUE;
/* see if this user is an escalated contact for the host */
@@ -295,14 +295,14 @@
return FALSE;
/* if this user is authorized for this host, they are for all services
on it as well... */
- if(is_authorized_for_host(temp_host,authinfo)==TRUE)
- return TRUE;
+ /* if(is_authorized_for_host(temp_host,authinfo)==TRUE)
+ return TRUE;*/
/* find the contact */
temp_contact=find_contact(authinfo->username);
/* see if this user is a contact for the service */
- if(is_contact_for_service(svc,temp_contact)==TRUE)
+ if(is_contact_for_service_perm(svc,temp_contact,'r')==TRUE)
return TRUE;
/* see if this user is an escalated contact for the service */
@@ -419,16 +419,16 @@
if(temp_contact && temp_contact->can_submit_commands==FALSE)
return FALSE;
- /* see if this user is a contact for the host */
- if(is_contact_for_host(temp_host,temp_contact)==TRUE)
+ /* see if this user is a contact for the host with permissions
*/
+ if(is_contact_for_host_perm(temp_host,temp_contact,'x')==TRUE)
return TRUE;
/* see if this user is an escalated contact for the host */
if(is_escalated_contact_for_host(temp_host,temp_contact)==TRUE)
return TRUE;
- /* this user is a contact for the service, so they have
permission... */
- if(is_contact_for_service(svc,temp_contact)==TRUE)
+ /* see if this user is a contact for the service with
permissions */
+ if(is_contact_for_service_perm(svc,temp_contact,'x')==TRUE)
return TRUE;
/* this user is an escalated contact for the service, so they
have permission... */
@@ -469,8 +469,8 @@
i
Re: [Nagios-users] Advanced permissions/user properties
On Mon, 6 Nov 2006, Steve Shipway wrote:
> Alex Burger wrote:
> > Leave the groups as they are, but modify the host and service
> > contact_groups command? For example:
> > define host{
> > host_name localhost
> > contact_groups netops:rw, helpdesk:r
> > }
> >
> > For backwards compatibility, if no permissions are set, the defaults
> > would be rw so the following would be the same:
> >
> > define host{
> > host_name localhost
> > contact_groups netops, helpdesk:r
> > }
> >
> > If a user was in both the netops and helpdesk group, the user should
> > have rw access.
>
> This is exactly what we need, and the best way I have seen (so far) to
> implement it. In particular it has backwards compatibility and does
> not involve an additional directive. Much simpler to do it via groups
> rather than at a per-user level, and much more maintainable.
>
> This is the way I'd like to see it implemented in the official tree,
> maybe with a nagios.cfg option to allow you to set the default to be :rw
> or :r (so that once you've fully implemented things you can change
> default to be :r, best to default to the lower level)
To remain in the traditional unix style. How about an eXecute flag?
In this contact it would best be written as Notify flag instead.
So I can have 1 group as nrw (the engineers on call), customer on nr,
helpdesk on r.
Hugo.
--
[EMAIL PROTECTED] http://hvdkooij.xs4all.nl/
This message is using 100% recycled electrons.
-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
___
Nagios-users mailing list
Nagios-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-users
::: Please include Nagios version, plugin version (-v) and OS when reporting
any issue.
::: Messages without supporting info will risk being sent to /dev/null
Re: [Nagios-users] Advanced permissions/user properties
Alex Burger wrote:
> Leave the groups as they are, but modify the host and service
> contact_groups command? For example:
> define host{
> host_name localhost
> contact_groups netops:rw, helpdesk:r
> }
>
> For backwards compatibility, if no permissions are set, the defaults
> would be rw so the following would be the same:
>
> define host{
> host_name localhost
> contact_groups netops, helpdesk:r
> }
>
> If a user was in both the netops and helpdesk group, the user should
> have rw access.
This is exactly what we need, and the best way I have seen (so far) to
implement it. In particular it has backwards compatibility and does
not involve an additional directive. Much simpler to do it via groups
rather than at a per-user level, and much more maintainable.
This is the way I'd like to see it implemented in the official tree,
maybe with a nagios.cfg option to allow you to set the default to be :rw
or :r (so that once you've fully implemented things you can change
default to be :r, best to default to the lower level)
Steve
--
Steve Shipway
ITSS, University of Auckland
(09) 3737 599 x 86487
[EMAIL PROTECTED]
-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
___
Nagios-users mailing list
Nagios-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-users
::: Please include Nagios version, plugin version (-v) and OS when reporting
any issue.
::: Messages without supporting info will risk being sent to /dev/null
Re: [Nagios-users] Advanced permissions/user properties
Alex Burger wrote:
The more I think about it, the more I think we are looking at this the
wrong way. With file system or application permissions, we would assign
a group to a folder/object, and then pick what rights the group would
have. Why don't we do the same thing with Nagios?
Leave the groups as they are, but modify the host and service
contact_groups command? For example:
define host{
host_name localhost
contact_groups netops:rw, helpdesk:r
}
For backwards compatibility, if no permissions are set, the defaults
would be rw so the following would be the same:
define host{
host_name localhost
contact_groups netops, helpdesk:r
}
If a user was in both the netops and helpdesk group, the user should
have rw access.
This will take a bit more work to implement, but I think it makes more
sense. What do you think?
Alex
Attached is a patch for 2.5 that implements what I described above. It
works on both hosts and services.
The following four lines are are examples of read/write access for
netops and helpdesk:
contact_groups netops, helpdesk
contact_groups netops, helpdesk:rw
contact_groups netops:rw, helpdesk
contact_groups netops:rw, helpdesk:rw
The following two lines are are examples of read/write access for netops
and read only (view only) for helpdesk:
contact_groups netops, helpdesk:r
contact_groups netops:rw, helpdesk:r
Alex
diff -ur nagios-2.5.org/cgi/cgiauth.c nagios-2.5/cgi/cgiauth.c
--- nagios-2.5.org/cgi/cgiauth.c2006-10-08 19:35:18.0 -0400
+++ nagios-2.5/cgi/cgiauth.c2006-11-04 15:10:58.0 -0500
@@ -420,7 +420,7 @@
return FALSE;
/* see if this user is a contact for the host */
- if(is_contact_for_host(temp_host,temp_contact)==TRUE)
+ if(is_contact_for_host_w(temp_host,temp_contact)==TRUE)
return TRUE;
/* see if this user is an escalated contact for the host */
@@ -428,7 +428,7 @@
return TRUE;
/* this user is a contact for the service, so they have
permission... */
- if(is_contact_for_service(svc,temp_contact)==TRUE)
+ if(is_contact_for_service_w(svc,temp_contact)==TRUE)
return TRUE;
/* this user is an escalated contact for the service, so they
have permission... */
@@ -470,7 +470,7 @@
return FALSE;
/* this user is a contact for the host, so they have
permission... */
- if(is_contact_for_host(hst,temp_contact)==TRUE)
+ if(is_contact_for_host_w(hst,temp_contact)==TRUE)
return TRUE;
/* this user is an escalated contact for the host, so they have
permission... */
diff -ur nagios-2.5.org/common/objects.c nagios-2.5/common/objects.c
--- nagios-2.5.org/common/objects.c 2006-10-08 19:35:18.0 -0400
+++ nagios-2.5/common/objects.c 2006-11-04 15:48:16.0 -0500
@@ -4926,6 +4926,8 @@
/* find a contact group from the list in memory */
contactgroup * find_contactgroup(char *name){
contactgroup *temp_contactgroup;
+char *temp_contactgroup_name;
+char *perms;
#ifdef DEBUG0
printf("find_contactgroup() start\n");
@@ -4934,11 +4936,21 @@
if(name==NULL || contactgroup_hashlist==NULL)
return NULL;
-
for(temp_contactgroup=contactgroup_hashlist[hashfunc1(name,CONTACTGROUP_HASHSLOTS)];temp_contactgroup
&&
compare_hashdata1(temp_contactgroup->group_name,name)<0;temp_contactgroup=temp_contactgroup->nexthash);
+/* Ignore permissions */
+temp_contactgroup_name = strdup(name);
+perms = strstr(temp_contactgroup_name, ":");
+if (perms)
+ *perms = '\0';
- if(temp_contactgroup &&
(compare_hashdata1(temp_contactgroup->group_name,name)==0))
+
for(temp_contactgroup=contactgroup_hashlist[hashfunc1(temp_contactgroup_name,CONTACTGROUP_HASHSLOTS)];temp_contactgroup
&&
compare_hashdata1(temp_contactgroup->group_name,temp_contactgroup_name)<0;temp_contactgroup=temp_contactgroup->nexthash);
+
+ if(temp_contactgroup &&
(compare_hashdata1(temp_contactgroup->group_name,temp_contactgroup_name)==0))
return temp_contactgroup;
+if(temp_contactgroup_name)
+ free(temp_contactgroup_name);
+
+
#ifdef DEBUG0
printf("find_contactgroup() end\n");
#endif
@@ -5427,7 +5439,9 @@
int is_contact_for_host(host *hst, contact *cntct){
contactgroupsmember *temp_contactgroupsmember;
contactgroup *temp_contactgroup;
-
+char *temp_contactgroup_name;
+char *perms;
+
if(hst==NULL || cntct==NULL){
Re: [Nagios-users] Advanced permissions/user properties
Hi Ton.
Ton Voon wrote:
> Hi Alex,
>
> I think the "read/write" attribute needs to be associated with the
> contact. So this implementation looks more obvious (to me):
>
> define contact {
> name person
> contactgroups cg1,cg2,cg3 # means can submit commands
> contactgroups_viewonly cg5,cg6
> }
>
> This would effectively mean the can_submit_commands attribute is
> redundant, because you just use contactgroups_viewonly instead of
> contactgroups.
The more I think about it, the more I think we are looking at this the
wrong way. With file system or application permissions, we would assign
a group to a folder/object, and then pick what rights the group would
have. Why don't we do the same thing with Nagios?
Leave the groups as they are, but modify the host and service
contact_groups command? For example:
define host{
host_name localhost
contact_groups netops:rw, helpdesk:r
}
For backwards compatibility, if no permissions are set, the defaults
would be rw so the following would be the same:
define host{
host_name localhost
contact_groups netops, helpdesk:r
}
If a user was in both the netops and helpdesk group, the user should
have rw access.
This will take a bit more work to implement, but I think it makes more
sense. What do you think?
Alex
-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
___
Nagios-users mailing list
Nagios-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-users
::: Please include Nagios version, plugin version (-v) and OS when reporting
any issue.
::: Messages without supporting info will risk being sent to /dev/null
Re: [Nagios-users] Advanced permissions/user properties
Hi Alex,This is a really interesting idea. We've recently made a patch to Nagios so that a contact will only see the services in the CGIs based on their contact groups - currently Nagios 2.x will show all services if that contact is a contact for the host (which you would normally do so they receive host notifications).Our patch means we use contactgroups to "slice" which services are visible per contact. I'll be blogging about this soon (when I get a spare 30 mins!).However, this still lacks the ability to show some services but only allow changes to a subset, which is what Tobias is interested in.I think the "read/write" attribute needs to be associated with the contact. So this implementation looks more obvious (to me):define contact { name person contactgroups cg1,cg2,cg3 # means can submit commands contactgroups_viewonly cg5,cg6}This would effectively mean the can_submit_commands attribute is redundant, because you just use contactgroups_viewonly instead of contactgroups.Does this make sense?TonOn 3 Nov 2006, at 01:21, Alex Burger wrote:Hi Tobias.I have expanded on the Altinity patch by adding a 'can_submit_commands' and 'can_submit_commands_strict' option to contact groups. The limitation of having a can_submit_commands option on the user is that it's an all or nothing option. A user is either view-only for all devices, or not.I will be using can_submit_commands_strict for people who need to be able to submit commands for the servers and services they manage, but also be able to only view some other servers and devices. I don't want the users to be able to view ALL devices.*can_submit_commands_strict:* You grant users full access to all or some systems, but want to restrict them from issuing commands for a few devices.If a device has multiple contact groups defined and any one of them denies submit commands with can_submit_commands_strict 0, then the user is denied even if the user belongs to a group that permits it.*can_submit_commands:* You grant users read/only access to all systems, but you want to allow the user to issue commands for a few devices.With can_submit_commands, if a device has multiple contact groups defined and any one of them allows submit commands, the user can submit commands. If there was only one contact group listed and it had can_submit_commands set to 0, the user would not be able to submit commands.Is this what you are looking for?AlexTobias Klausmann wrote: Hi!I've got a problem that I don't how to solve best in Nagios. Ithink other people have run into the same problem (I know thatsomeone has run into a /similar/ problem).I'm running 2.5 on a mid-sized installations (~300 hosts, ~2500services). Thing is, our projects/(host|service)groups varywildly in who is responsible for them. Unfortunately, all theseprojects are also heavily intertwined in their dependencies.Say we have a web mail project A. This consists of severalweb servers, databases and the like. It is heavily dependent onthe LDAP project B and the mail server project C. While B and Chave the same group of admins, project A is managed by anentirely different group of people.As such, we have configured Nagios that the group that isresponsible for project can only see the machines of project A andthe "B-and-C-people" can only see B and C.Everything is peachy.Except. Sometimes, project A may look like it's broken (pagestime out etc). But in reality, there's a spam attack and theproject B (the LDAP infrastructure) is so slow it simply grindsto a halt. In this case it would obviously be nice if the peoplefrom project A could see that project B is slow. Yet they shouldnot be able to change the notification options/acknowledgementsetc etc of projects B or C. The altinity people have created a patch for the "view some,change none" scenario[0]. Unfortunately, what I'd need is amechanism for the "view some, change a few" scenario I outlinedabove.How do others deal with this kind of problem? I'm sure we're notthe only ones who've run into it.As of currently, our best guess would be to createpseudo-accounts (like john.foo and john.foo-admin) and hack theCGI(s) to only allow the commands from -admin accounts which arein the notification list (with notification options set to "n").We already do this to let people see machines they don'tmailed/paged/called about.Regards,Tobias[0] http://altinity.blogs.com/dotorg/2006/02/a_view_some_cha.html -Using Tomcat but need to do more? Need to support web services, security?Get stuff done quickly with pre-integrated technology to make your job easierDownload IBM WebSphere Application Server v.1.0.1 based on Apache Geronimohttp://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642___Nagios-users mailing listNagios-users@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/nagios-users::: Please include Nagios version, plugin version (-v) and
Re: [Nagios-users] Advanced permissions/user properties
Hi! On Thu, 02 Nov 2006, Alex Burger wrote: > I have expanded on the Altinity patch by adding a 'can_submit_commands' > and 'can_submit_commands_strict' option to contact groups. The > limitation of having a can_submit_commands option on the user is that > it's an all or nothing option. A user is either view-only for all > devices, or not. > > I will be using can_submit_commands_strict for people who need to be > able to submit commands for the servers and services they manage, but > also be able to only view some other servers and devices. I don't want > the users to be able to view ALL devices. > > *can_submit_commands_strict:* You grant users full access to all or > some systems, but want to restrict them from issuing commands for a few > devices. > > If a device has multiple contact groups defined and any one of them > denies submit commands with can_submit_commands_strict 0, then the user > is denied even if the user belongs to a group that permits it. > > *can_submit_commands:* You grant users read/only access to all systems, > but you want to allow the user to issue commands for a few devices. > > With can_submit_commands, if a device has multiple contact groups > defined and any one of them allows submit commands, the user can submit > commands. If there was only one contact group listed and it had > can_submit_commands set to 0, the user would not be able to submit commands. > > Is this what you are looking for? I'm not quite sure :) Actually I'm not sure I understand the functionality you added correctly. I'll explain what I think I've understood: The new attribute (..._strict) belongs to contact_groups. If it is set to 1 on a contactgroup, everything behaves as normal. If it is set to 0, then no user who's associated with a hostgroup that is also associated with this contactgroup may issue commands for that particular host(group). As this sounds more than counter-intuitive, I strongly suspect I've misunderstood something. Please enlighten me. :) Regards, Tobias - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Nagios-users mailing list Nagios-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nagios-users ::: Please include Nagios version, plugin version (-v) and OS when reporting any issue. ::: Messages without supporting info will risk being sent to /dev/null
Re: [Nagios-users] Advanced permissions/user properties
Hi Tobias. I have expanded on the Altinity patch by adding a 'can_submit_commands' and 'can_submit_commands_strict' option to contact groups. The limitation of having a can_submit_commands option on the user is that it's an all or nothing option. A user is either view-only for all devices, or not. I will be using can_submit_commands_strict for people who need to be able to submit commands for the servers and services they manage, but also be able to only view some other servers and devices. I don't want the users to be able to view ALL devices. *can_submit_commands_strict:* You grant users full access to all or some systems, but want to restrict them from issuing commands for a few devices. If a device has multiple contact groups defined and any one of them denies submit commands with can_submit_commands_strict 0, then the user is denied even if the user belongs to a group that permits it. *can_submit_commands:* You grant users read/only access to all systems, but you want to allow the user to issue commands for a few devices. With can_submit_commands, if a device has multiple contact groups defined and any one of them allows submit commands, the user can submit commands. If there was only one contact group listed and it had can_submit_commands set to 0, the user would not be able to submit commands. Is this what you are looking for? Alex Tobias Klausmann wrote: > Hi! > > I've got a problem that I don't how to solve best in Nagios. I > think other people have run into the same problem (I know that > someone has run into a /similar/ problem). > > I'm running 2.5 on a mid-sized installations (~300 hosts, ~2500 > services). Thing is, our projects/(host|service)groups vary > wildly in who is responsible for them. Unfortunately, all these > projects are also heavily intertwined in their dependencies. > > Say we have a web mail project A. This consists of several > web servers, databases and the like. It is heavily dependent on > the LDAP project B and the mail server project C. While B and C > have the same group of admins, project A is managed by an > entirely different group of people. > > As such, we have configured Nagios that the group that is > responsible for project can only see the machines of project A and > the "B-and-C-people" can only see B and C. > > Everything is peachy. > > Except. Sometimes, project A may look like it's broken (pages > time out etc). But in reality, there's a spam attack and the > project B (the LDAP infrastructure) is so slow it simply grinds > to a halt. In this case it would obviously be nice if the people > from project A could see that project B is slow. Yet they should > not be able to change the notification options/acknowledgements > etc etc of projects B or C. > > The altinity people have created a patch for the "view some, > change none" scenario[0]. Unfortunately, what I'd need is a > mechanism for the "view some, change a few" scenario I outlined > above. > > How do others deal with this kind of problem? I'm sure we're not > the only ones who've run into it. > > As of currently, our best guess would be to create > pseudo-accounts (like john.foo and john.foo-admin) and hack the > CGI(s) to only allow the commands from -admin accounts which are > in the notification list (with notification options set to "n"). > We already do this to let people see machines they don't > mailed/paged/called about. > > Regards, > Tobias > > [0] http://altinity.blogs.com/dotorg/2006/02/a_view_some_cha.html - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Nagios-users mailing list Nagios-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nagios-users ::: Please include Nagios version, plugin version (-v) and OS when reporting any issue. ::: Messages without supporting info will risk being sent to /dev/null
Re: [Nagios-users] Advanced permissions/user properties
Hi!
On Tue, 31 Oct 2006, Az wrote:
> > The altinity people have created a patch for the "view some,
> > change none" scenario[0]. Unfortunately, what I'd need is a
> > mechanism for the "view some, change a few" scenario I outlined
> > above.
> Is that to say that "view _all_, change some" wouldn't work for you?
> That's how we're working at present, out-of-the-box. While restricting
> viewing might reduce mental clutter for those concerned*, I can't see
> why being able to see everything is a big deal (unless you're displaying
> some super sensitive information in Nagios which is a totally different
> topic).
Well it's not super sensitive but when we started deploying
Nagios we were very happy to not clutter the webpages for everybody
(how we Nagios admins cope is another story ;)). We're currently
looking into hacking cmd.cgi to
a) log all issued commands with username and ip
and
b) do some permission checking
Unfortunately b) will leave us with yet another othogonal user
account type. Currently, most users have three accounts:
first.last, first.last-sms, first.last-email, first.last-phone.
The first account allows them to log onto the website and view
stuff, the other three are used to configure the respective
notification types (the first account has notifications disabled
entirely). This has the advantage that not everybody that wants
to see a host has to get any of the used notification types.
Unfortunately, you can not easily pull apart "view" and "disable
stuff" this way, hence my initial question.
The Nagios permission system is a bit lacking in this respect. As
far as I can tell from Ethan's presentation about 3.0, that won't
change (much) with the next version. It's not like I have the
perfect way to specify such fine-grained perms in my head,
either.
> *Our service centre can see everything, but we used service groups to
> provide "rolled up" views to keep it simple for them. All our engineers
> can see everything so when they spot an issue with someone elses kits
> that impacts their own, they can find out what the issue is and who to
> poke in the eye with a burnt stick to get it fixed. We found that trying
> to hide stuff just blinkered people and made them only responsive to
> their own issues ("not my server. not my problem.") which results in
> poor customer service at the end of the day.
While I agree with you mostly, we also offer Nagios monitoring to
our customers. This is turn means that we have to seperate them
in some way (it wouldn't be cool if all customers saw each
other's hosts and services). This is a hard requirement that I
can't move a single inch on (rather: my boss won't let me).
We're now looking at seperating our own Nagios and that for the
customers. That way, we'd get the "have N accounts for everybody"
to be a little more manageable. For our internal stuff, we'd go
the route you described (everybody seeing everything). Seeing as
about 90% of what we monitor is our own stuff, that would make
quite a difference.
Regards,
Tobias
--
Never touch a burning system.
-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
___
Nagios-users mailing list
Nagios-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-users
::: Please include Nagios version, plugin version (-v) and OS when reporting
any issue.
::: Messages without supporting info will risk being sent to /dev/null
Re: [Nagios-users] Advanced permissions/user properties
Tobias Klausmann wrote:
> The altinity people have created a patch for the "view some,
> change none" scenario[0]. Unfortunately, what I'd need is a
> mechanism for the "view some, change a few" scenario I outlined
> above.
Is that to say that "view _all_, change some" wouldn't work for you?
That's how we're working at present, out-of-the-box. While restricting
viewing might reduce mental clutter for those concerned*, I can't see
why being able to see everything is a big deal (unless you're displaying
some super sensitive information in Nagios which is a totally different
topic).
See
http://nagios.sourceforge.net/docs/2_0/configcgi.html#authorized_for_all_hosts
and
http://nagios.sourceforge.net/docs/2_0/configcgi.html#authorized_for_all_services.
*Our service centre can see everything, but we used service groups to
provide "rolled up" views to keep it simple for them. All our engineers
can see everything so when they spot an issue with someone elses kits
that impacts their own, they can find out what the issue is and who to
poke in the eye with a burnt stick to get it fixed. We found that trying
to hide stuff just blinkered people and made them only responsive to
their own issues ("not my server. not my problem.") which results in
poor customer service at the end of the day.
-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
___
Nagios-users mailing list
Nagios-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-users
::: Please include Nagios version, plugin version (-v) and OS when reporting
any issue.
::: Messages without supporting info will risk being sent to /dev/null
[Nagios-users] Advanced permissions/user properties
Hi! I've got a problem that I don't how to solve best in Nagios. I think other people have run into the same problem (I know that someone has run into a /similar/ problem). I'm running 2.5 on a mid-sized installations (~300 hosts, ~2500 services). Thing is, our projects/(host|service)groups vary wildly in who is responsible for them. Unfortunately, all these projects are also heavily intertwined in their dependencies. Say we have a web mail project A. This consists of several web servers, databases and the like. It is heavily dependent on the LDAP project B and the mail server project C. While B and C have the same group of admins, project A is managed by an entirely different group of people. As such, we have configured Nagios that the group that is responsible for project can only see the machines of project A and the "B-and-C-people" can only see B and C. Everything is peachy. Except. Sometimes, project A may look like it's broken (pages time out etc). But in reality, there's a spam attack and the project B (the LDAP infrastructure) is so slow it simply grinds to a halt. In this case it would obviously be nice if the people from project A could see that project B is slow. Yet they should not be able to change the notification options/acknowledgements etc etc of projects B or C. The altinity people have created a patch for the "view some, change none" scenario[0]. Unfortunately, what I'd need is a mechanism for the "view some, change a few" scenario I outlined above. How do others deal with this kind of problem? I'm sure we're not the only ones who've run into it. As of currently, our best guess would be to create pseudo-accounts (like john.foo and john.foo-admin) and hack the CGI(s) to only allow the commands from -admin accounts which are in the notification list (with notification options set to "n"). We already do this to let people see machines they don't mailed/paged/called about. Regards, Tobias [0] http://altinity.blogs.com/dotorg/2006/02/a_view_some_cha.html - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Nagios-users mailing list Nagios-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nagios-users ::: Please include Nagios version, plugin version (-v) and OS when reporting any issue. ::: Messages without supporting info will risk being sent to /dev/null
