you do not have permission to view information for any of the hosts you requested

[gregbeyer]

No, they do not. And neither do the hostgroups. Providing an entry from servicegroups.cfg and hostgroups.cfg

sample service group in servicegroups.cfg:

# Mon Aug 14 00:02:58 2023:
define servicegroup {
servicegroup_name phoenix-slurm-sg
alias phoenix slurm sg Nodes
}


sample hostgroup in hostgroups.cfg:

# Mon Aug 14 00:02:58 2023:
define hostgroup {
hostgroup_name phoenix-slurm-hg
alias phoenix slurm hg Nodes
}

[danderson]

Try adding members to those. I'm guessing you still have the default hostgroup "linux-servers" which is why you don't see the auth issue with hostgroups, but I noticed that when I removed all the members from all the groups, then I got the exact same error message you described. I noticed that authentication within core does not consider this case.

[gregbeyer]

I do not have the default hostgroup linux-servers.

And in my hostgroups.cfg file I have only two directives per host group, and neither is "member", for example:

define hostgroup {
hostgroup_name phoenix-slurm-hg
alias phoenix slurm hg Nodes
}


Well, tried to add a member directive to servicegroups.cfg. Results in an error in nagios -v /etc/nagios/nagios.cfg. Added members line, with a hostname (admin-coda) and one of the services (ping) that all of my hosts check

define servicegroup {
servicegroup_name phoenix-slurm-sg
alias phoenix slurm sg Nodes
members admin-coda,ping

}

Interestingly, documentation says that members is an optional directive. Only servicegroup_name and alias are required.
https://assets.nagios.com/downloads/nag ... rvicegroup.

So here's the error from nagios -v . . .

Read main config file okay...
Error: Could not find a service matching host name 'admin-coda' and description 'ping' (config file '/etc/nagios/groups/servicegroups.cfg', starting on line 15)
Error: Could not expand members specified in servicegroup 'phoenix-slurm-sg' (config file '/etc/nagios/groups/servicegroups.cfg', starting at line 15)
Error processing object config files!

[swolf]

Well, tried to add a member directive to servicegroups.cfg. Results in an error in nagios -v /etc/nagios/nagios.cfg. Added members line, with a hostname (admin-coda) and one of the services (ping) that all of my hosts check

define servicegroup {
servicegroup_name phoenix-slurm-sg
alias phoenix slurm sg Nodes
members admin-coda,ping

}

[...]

Read main config file okay...
Error: Could not find a service matching host name 'admin-coda' and description 'ping' (config file '/etc/nagios/groups/servicegroups.cfg', starting on line 15)
Error: Could not expand members specified in servicegroup 'phoenix-slurm-sg' (config file '/etc/nagios/groups/servicegroups.cfg', starting at line 15)
Error processing object config files!

How are admin-coda and the ping service defined? The specific error you're showing indicates that the Core daemon doesn't see a ping service is defined for admin-coda. I would be... very surprised if there was a bug or error in that part of the configuration processing

Interestingly, documentation says that members is an optional directive. Only servicegroup_name and alias are required.

My understanding is that "required" directives are meant in the most literal sense of "the nagios daemon will refuse to start if this is missing". I would also bet there are probably some "required" directives for which this doesn't hold anyways, but that's the closest intuitive rule I've been able to find.

The main reason servicegroups aren't required is because you can also use the servicegroups directive for services, which is how I'd assume you've set up your group membership given what you've shown so far.

As for fixing your issue, it does look like is_authorized_for_all_services should already be showing you the necessary services. Given that you already configured this and that you're authenticating successfully, I agree with Dylan that the most likely cause (from what we've seen) is that whatever servicegroups you're viewing don't seem to have services configured.

If you don't have services configured in your service groups, I guess I'd also like to know what the purpose or use-case is. I'm not opposed to having the CGI's authentication logic work a little differently, but I've never heard of someone doing that intentionally before.

[gregbeyer]

admin-coda is defined thusly:

in a <rack_name_.cfg file where all nodes in a given rack are define is this directive:

define host {
host_name admin-coda
alias <actual_host_name_removed>,admin-coda
address <ip_addr_removed>
use utility-host
hostgroups utility
-------- snip_data_from_hw_database -------
}

ping service is defined thusly:

in service_checks.cfg file is this directive:

define service {
name ping
service_description ping-host
use basic-service
check_command check-host-alive
hostgroup_name network-ib,infiniband,management,utility,storage,storage-appliance
register 1
}

I searched by servicegroups.cfg file for both the "utility" which admin-coda is....not found.

However in hostgroup.cfg (remember, Hosts section is working fine). I find directive:

define hostgroup {
hostgroup_name utility
alias utility Nodes
}

Spitballing . . . Wonder what would happen if I add
servicegroup_name utility to ping section of my service_checks.cfg file?

Nope that did not work, nagios -v barfed with:
Error: Invalid service object directive 'servicegroup_name'.
Error: Could not add object property in file '/etc/nagios/objects/service_checks.cfg' on line 80.
Error: Invalid max_check_attempts value for host 'localhost'
Error: Could not register host (config file '/etc/nagios/objects/localhost.cfg', starting on line 16)
Error processing object config files!

So there is Zen (intuition) in using Nagios .cfg file directive documentation. It's already complex as written.

Purpose or use-case -- IDK, I have inherited this Nagios setup by someone else. <bangs head -- really hard>. Aaand it's late on Fri, and I'm real tired of Nagios. Maybe it'll look better in three days.

[danderson]

https://assets.nagios.com/downloads/nag ... ml#service

Try adding the "servicegroups" utility instead of "servicegroup_name"