NCPA Passive Service Check on RHEL6

[onegative]

G 'Day Nagios Support,

I am trying to determine how to handle a situation on RHEL6 servers where the nagios user does not have permissions to determine Status for certain services. So I have a question about the underlying process being utilized to determine service status on RedHat 6.

Does the NCPA passive agent execute the standard /sbin/service command to determine status?

If so, then it makes sense I could establish a monitoring standard as follows. Please let me know if you see anything obvious or concerning that I am not thinking about.

sudoers entry:
nagios ALL=NOPASSWD:/sbin/service * status <-- allows only for status check, no start/stop/restart

nagios alias entry:
alias service='sudo /sbin/service' <-- adds the sudo call in front of service command

command being issued by ncpa_passive: ??? <-- this is what I am unsure about if this is the actual command being issued by NCPA
service <svc_name> status

If the command is indeed correct then my alias and sudo entries should work...
The reason I am requesting this information is to make sure I have a clear understanding when I make my policy request for the specific sudoers entry from Security and Unix support. This is not an issue on RHEL7 as systemd seems to allow a non-root user to query service status on all services.

Please let me know and as always thanks for your help, input and suggestions,
Danny

p.s. If anyone else has any suggestion or comment please chime in and thanks in advance for your help...Danny

[lmiltchev]

command being issued by ncpa_passive: ??? <-- this is what I am unsure about if this is the actual command being issued by NCPA
service <svc_name> status

The actual command is:

Code: Select all

def get_initd_service_status(self, service):
       service_status = subprocess.Popen(['service', service, 'status'], stdout=subprocess.PIPE, stderr=subprocess.PIPE)
       timer = Timer(2, self.kill_proc, [service_status])

but it boils down to:

Code: Select all

service <service> status

so the solution that you offer is fine.

Another way of doing it would be to set:

Code: Select all

uid = root
gid = root

in the ncpa.cfg file, but I would not recommend doing that.

I am trying to determine how to handle a situation on RHEL6 servers where the nagios user does not have permissions to determine Status for certain services.

Just curious - what kind of services you are not able to monitor? I tried determining the status of a bunch of services on RHEL 6 system, and didn't have any issues. I didn't even have to modify my sudoers (running NCPA 2.1.6).

[onegative]

Here are some examples...so as you can see certain root owned services prohibit status checks...whereas on RHEL7 systemd allows for all service status checks...or at least the ones I have been required to monitor...just trying to make sure I can execute passive checks in a standardized way.

You can lock this query...

Thanks for your help,
Danny

ip6tables: Only usable by root. [WARNING]
iptables: Only usable by root. [WARNING]
/etc/init.d/kdump: line 49: /var/lock/kdump: Permission denied
mdmonitor status unknown due to insufficient privileges.
mysqld status unknown due to insufficient privileges.
rsyslogd status unknown due to insufficient privileges.
Splunk status:
/etc/init.d/splunkforwarder: line 43: /opt/splunkforwarder/bin/splunk: Permission denied
/etc/init.d/sshd: line 33: /etc/sysconfig/sshd: Permission denied
/etc/init.d/xinetd: line 46: /etc/sysconfig/xinetd: Permission denied

[lmiltchev]

Here are some examples...so as you can see certain root owned services prohibit status checks...

I tested most of these on my test system, and didn't have any issues whatsoever.

Example:

Code: Select all

[root@main-nagios-xi libexec]# su - nagios
Last login: Wed Jan 23 13:04:21 CST 2019 on pts/0
[nagios@main-nagios-xi ~]$ cd /usr/local/nagios/libexec/
[nagios@main-nagios-xi libexec]$ ./check_ncpa.py -H 192.168.x.x -t 'mytoken' -M 'services' -q 'service=xinetd,status=running'
OK: xinetd is running

Perhaps, you've done some hardening on the server, changing the umask, pam settings, etc. I am not really sure. As long as you modified the sudoers as you described, you should be fine.

You can lock this query...

Sure. If you have any further questions/issues, please start a new thread. Thanks!