Archive for the 'nagios' Category

Executing mailq as the nagios user on Fedora 12

Wednesday, January 13th, 2010

I added a new check command to nagios to check the sendmail mail queue but received an error while executing within nagios:

/usr/bin/mailq = can not chdir(/var/spool/mqueue/): Permission denied
Program mode requires special privileges, e.g., root or TrustedUser.
CRITICAL: Error code 78 returned from /usr/bin/mailq

This is because the nagios process (which runs as the nagios user) does not have the permissions to look at the spool directory for mail (/var/spool/mqueue) – the permissions on that directory are 700 and owned by root.

The fix is to permit nagios to execute this command as root and also to run the /usr/bin/mailq program with sudo in the check_mailq perl script.

Step 1: Modify check_mailq
Edit the check_mailq file, after making a backup of the file. Search for the place where the mailq is opened for reading from the pipe and add /usr/bin/sudo prior to the command. The resulting line looks like the following (note: this is does using sendmail as the MTA):

if (! open (MAILQ, "/usr/bin/sudo $utils::PATH_TO_MAILQ | " ) ) {

Step 2: Modify sudoers
Edit the sudoers file to give nagios permission to execute /usr/bin/mailq as root without requiring a password. I accomplished this by adding the following line to the end of the file:

nagios ALL= (root) NOPASSWD: /usr/bin/mailq

Test prior to reloading nagios by executing the check_mailq command as nagios:

su nagios -c "./check_mailq -w 5 -c 10"

If you see an error message about a tty, like:

sudo: sorry, you must have a tty to run sudo

or in nagios:

CRITICAL: Error code 1 returned from /usr/bin/mailq

you will need to either comment out the line about requiring the tty (Defaults requiretty), or add a new line not requiring the tty for nagios:

Defaults:nagios !requiretty

Nagios and checking samba disks – check_disk_smb

Wednesday, January 6th, 2010

The following is useful when the linux machine is not correctly joined to a domain:

I have noticed a number of PROBLEM alerts from my Nagios 3.2.0 implementation on Fedora 12 when checking the available disk space on a WinXP share such as:

  • Result from smbclient not suitable
  • No Answer from Client

This used to work before upgrading both my Nagios and Fedora implementations.

To get this working once again, I’ve had to do two things – allow Nagios to login and specify the domain name as part of the user name on the check_disk_smb command.

To permit login to nagios, edit the passwd file with sudo vipw and change the shell to /bin/sh for nagios (should have been /sbin/nologin).

Next, in the private configuration file for Nagios, change the USER variable to be DOMAIN\\\\User; note the four backslashes are necessary. If that USER variable is being used elsewhere where the the new value would alter the results from other Nagios checks, add a new USER variable and update the configuration files accordingly.

Cannot update Fedora 8 via yum

Wednesday, April 23rd, 2008

I’ve been having difficulties trying to update a Fedora 8 installation with yum. When I execute “yum update” I received the following error:

Transaction Check Error:
file /usr/lib/libsensors.so.3 from install of lm_sensors-2.10.6-1.fc8.i386 conflicts with file from package libsensors3-2.10.5-52.fc6.i386

When I try to remove lm_sensors, a bunch of dependant packages want to be removed, too (but that is not what I want).

I noticed there was a nagios plugin that was being updated called nagios-plugins-sensors. Removing that allowed me to successfully perform a yum update!

So, I typed yum erase nagios-plugins-sensors and yum removed the following:

=============================================================================
Package Arch Version Repository Size
=============================================================================
Removing:
nagios-plugins-sensors i386 1.4.8-9.fc8 installed 1.1 k
Removing for dependencies:
nagios-plugins-all i386 1.4.8-9.fc8 installed 0.0

Success!

nagios: Checking a samba share without a password

Sunday, October 29th, 2006

I was getting errors (Access Denied) when I tried to check a samba share that had no password (I know – bad practice). Turns out I needed to add a new entry in checkcommands.cfg specifically to test for no password.

define command{
command_name check_samba_disk_nopw
command_line $USER1$/check_disk_smb --hostname="$HOSTADDRESS$" --share="$ARG1$" -u "$ARG2$" -p "''" -w 85 -c 95
}

The trick is passing the nested empty quotes to check_disk_smb. This will make it work. Unfortunately, typing the command on the command line works, even without the nested quotes. It must be some internal parsing nagios does to the command_line parameter.

FC6, SELinux and Nagios

Sunday, October 29th, 2006

I love Nagios, but have been having issues with it running under SELinux targeted. I’ve finally made it work with no more AVC’s or other errors (so far!). Here is what I have done to get it to work:

  1. Install nagios.
    1. sudo yum install nagios
    2. sudo yum install 'nagios-plugins-*'
  2. Make changes to nagios configuration to account for your situation.
  3. Make certain the permissions are correct.
    1. User apache needs read access to cfg files in /etc/nagios.
    2. User apache needs read access to web site files under /usr/share/nagios/html.
    3. If using resouces.cfg, only nagios needs access to read, not apache!
    4. For the nagios.cmd fifo pipe (under /var/spool/nagios/cmd), permissions are 660, owner = nagios, group = apache.
    5. cgi files need to be executable by apache
    6. plugins need to be executable by nagios
  4. Set security contexts on files (all sone with sudo, of course)
    1. chcon -R -t httpd_sys_content_t /usr/share/nagios/html
    2. chcon -R -t nagios_etc_t /etc/nagios
    3. chcon -R -t nagios_log_t /var/log/nagios
    4. chcon -R -t var_spool_t /var/spool/nagios
    5. chcon -R -t bin_t /usr/lib/nagios/plugins
    6. chcon -t nagios_cgi_exec_t /usr/lib/nagios/cgi-bin/*.cgi
    7. /usr/sbin/nagios has a security domain type of sbin_t
  5. Apache alias is in /etc/httpd/conf.d/nagios.conf. Inspect and make changes as necessary. Restart httpd service.
  6. The check_mem plugin was not working for me, it couldn’t find utils.pm. I had to add the following line to near the top of the script:
    1. use lib "/usr/lib/nagios/plugins" ;
  7. I needed to add some local security policy. Read on for details.

There seems to be some holes in the policy for nagios. These are easily corrected with a little help from checkmodule.

First, need to install the SELinux tools to create new policies. These are not installed by default.

  1. sudo yum install checkpolicy
  2. sudo yum install selinux-policy-devel

There is a nice tool for troubleshooting policy called setroubleshoot. It is available at Dan Walsh’s yum repo. See his blog entry for details. The setools are also quite helpful at inspecting policy (although I believe you need at least version 3 to inspect policy on fc6 where version 2.4 can inspect the audit logs).

I then went through the process of running/using nagios, inspecting the audit.log and taking the appropriate lines and running them through audit2allow -M

to generate the proper policy and then load the policy module. I had to do this process a number of times to make certain I captured all the AVC’s. I ended up with the following policy module (I’ve named it local, feel free to change its name if it conflicts. If you do, you need to make a change in the file, too).

module local 1.0.0;
require {
class fifo_file read;
class fifo_file getattr;
class fifo_file write;
class dir search;
class process { sigkill signal };
type httpd_t;
type nagios_cgi_t;
type ping_t;
type var_spool_t;
role system_r;
};

allow ping_t var_spool_t:fifo_file read;
allow httpd_t nagios_cgi_t:process { sigkill signal };
allow nagios_cgi_t var_spool_t:fifo_file getattr;
allow nagios_cgi_t var_spool_t:dir search;
allow nagios_cgi_t var_spool_t:fifo_file write;
After capturing this in the file local.te, make the policy package with:

% make -f /usr/share/selinux/devel/Makefile

This will ultimately create local.pp which then can be loaded by executing:

% sudo semodule -i local.pp

A good review of all of this can be found in the Red Hat SELinux FAQ.

stop spam with honeypot!