[users] Nagios 3.2.3

[Scott Reese]

Greetings:

I am trying to use the latest Nagios 3.2.3 packages on a CentOS 5.5 64-bit virtual machine. I started with an up to date CentOS 5.5 install, added the rpmforge repo, and then installed the nagios, nagios-plugins, and nagios-plugins-setuid packages.

I am using the default nagios.cfg that came with the package for testing. My problem is that the nagios service won't start using the normal tools. When I try start the service using "service nagios start", I get an error back saying "Configuration validation failed".

What's unusual about this is that if I validate the configuration by hand "nagios -v /etc/nagios/nagios.cfg", it returns as valid, with 0 warnings and 0 errors. I also tried a manual verification as the nagios user "su - nagios; nagios -v /etc/nagios/nagios.cfg", and that validates correctly as well. Additionally, if I start the service manually "su - nagios; nagios -d /etc/nagios/nagios.cfg", nagios starts up and runs properly. Once I have manually started the service, things like "service nagios status" and "service nagios stop" all work properly, but once the service is stopped, you can't use the service command to start it again.

As part of my troubleshooting, I modified the /etc/init.d/nagios file's check_config() function so that instead of piping the output of the config check to /dev/null, it printed it out on the screen. When I run the modified service start, it reports that there is an error in the configuration file at line 465, and that the directory is not valid. Line 465 in the default configuration file is "check_result_path=/var/nagios/spool/checkresults". I have verified that the specified directory exists, is owned by nagios:nagios, and has appropriate permissions (755), and that there are no SELinux denies being generated.

It seems that there is something different about the environment that /etc/init.d/nagios runs in than the normal environment. I don't know enough about the CentOS startup scripts to really go beyond that.

If it's not too much trouble, could someone try installing nagios and see if they get the same behavior with the default config files? And any pointers as to how the environment that /etc/init.d/nagios gets run in differs from a normal environment would be appreciated.

Thanks for your time.

-Scott
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.repoforge.org/pipermail/users/attachments/20101221/e1239a65/attachment.html

[Erik Wasser]

Post by Scott Reese
I have verified that
the specified directory exists, is owned by nagios:nagios, and has
appropriate permissions (755), and that there are no SELinux denies being
generated.

Just to be sure. Can to disable SELinux and try it again? So we can exclude
this?

[Scott Reese]

Post by Erik Wasser
Just to be sure. Can to disable SELinux and try it again? So we can exclude
this?

My apologies. Since I wasn't seeing anything in the audit log I assumed
that SELinux wasn't the problem. However, I disabled it and the problem
went away.

I will troubleshoot this as an SELinux issue.

Thanks for your help.

-Scott
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/ms-tnef
Size: 2505 bytes
Desc: not available
Url : http://lists.repoforge.org/pipermail/users/attachments/20101222/767c396a/attachment.bin

[Yury V. Zaytsev]

Post by Scott Reese
I will troubleshoot this as an SELinux issue.
Thanks for your help.

Hi!

Please keep us posted if you come up with a SELinux module to solve this
issue. I wonder if it can be packaged along with Nagios...

[Scott Reese]

Post by Yury V. Zaytsev
Please keep us posted if you come up with a SELinux module to solve this
issue. I wonder if it can be packaged along with Nagios...

Greetings Yury:

I was surprised to find that the SELinux policy for Nagios is actually
distributed as part of the base SELinux install - the machine has the
contexts defined and rules in place even before Nagios is installed.

I'll certainly report my findings back, but actually fixing these
problems is a new experience for me. We have usually just turned
SELinux off rather than trying to fix it. It might take me a little
while to get it sorted out.

Thanks, everyone, for your help with this.

-Scott
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/ms-tnef
Size: 2849 bytes
Desc: not available
Url : http://lists.repoforge.org/pipermail/users/attachments/20101223/9dcb3d7a/attachment.bin

[Scott Reese]

Post by Yury V. Zaytsev
Please keep us posted if you come up with a SELinux module to solve this
issue. I wonder if it can be packaged along with Nagios...

Greetings Yury:

I was surprised to find that the SELinux policy for Nagios is actually
distributed as part of the base SELinux install - the machine has the
contexts defined and rules in place even before Nagios is installed.

I'll certainly report my findings back, but actually fixing these
problems is a new experience for me. We have usually just turned
SELinux off rather than trying to fix it. It might take me a little
while to get it sorted out.

Thanks, everyone, for your help with this.

-Scott
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/ms-tnef
Size: 2849 bytes
Desc: not available
Url : http://lists.repoforge.org/pipermail/users/attachments/20101223/9dcb3d7a/attachment-0001.bin

[Scott Reese]

Post by Yury V. Zaytsev
Please keep us posted if you come up with a SELinux module to solve this
issue. I wonder if it can be packaged along with Nagios...

Greetings Yury:

I was surprised to find that the SELinux policy for Nagios is actually
distributed as part of the base SELinux install - the machine has the
contexts defined and rules in place even before Nagios is installed.

I'll certainly report my findings back, but actually fixing these
problems is a new experience for me. We have usually just turned
SELinux off rather than trying to fix it. It might take me a little
while to get it sorted out.

Thanks, everyone, for your help with this.

-Scott
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/ms-tnef
Size: 2849 bytes
Desc: not available
Url : http://lists.repoforge.org/pipermail/users/attachments/20101223/9dcb3d7a/attachment-0002.bin

[Scott Reese]

Post by Yury V. Zaytsev
Please keep us posted if you come up with a SELinux module to solve this
issue. I wonder if it can be packaged along with Nagios...

Greetings Yury:

I was surprised to find that the SELinux policy for Nagios is actually
distributed as part of the base SELinux install - the machine has the
contexts defined and rules in place even before Nagios is installed.

I'll certainly report my findings back, but actually fixing these
problems is a new experience for me. We have usually just turned
SELinux off rather than trying to fix it. It might take me a little
while to get it sorted out.

Thanks, everyone, for your help with this.

-Scott
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/ms-tnef
Size: 2849 bytes
Desc: not available
Url : http://lists.repoforge.org/pipermail/users/attachments/20101223/9dcb3d7a/attachment-0003.bin

[Scott Reese]

Post by Yury V. Zaytsev
Please keep us posted if you come up with a SELinux module to solve this
issue. I wonder if it can be packaged along with Nagios...

Greetings Yury:

I was surprised to find that the SELinux policy for Nagios is actually
distributed as part of the base SELinux install - the machine has the
contexts defined and rules in place even before Nagios is installed.

I'll certainly report my findings back, but actually fixing these
problems is a new experience for me. We have usually just turned
SELinux off rather than trying to fix it. It might take me a little
while to get it sorted out.

Thanks, everyone, for your help with this.

-Scott
-------------- next part --------------
A non-text attachment was scrubbed...
Name: winmail.dat
Type: application/ms-tnef
Size: 2849 bytes
Desc: not available
URL: <http://lists.repoforge.org/pipermail/users/attachments/20101223/9dcb3d7a/attachment-0004.bin>

[Yury V. Zaytsev]

Post by Scott Reese
I will troubleshoot this as an SELinux issue.
Thanks for your help.

Hi!

Please keep us posted if you come up with a SELinux module to solve this
issue. I wonder if it can be packaged along with Nagios...

[Yury V. Zaytsev]

Post by Scott Reese
I will troubleshoot this as an SELinux issue.
Thanks for your help.

Hi!

Please keep us posted if you come up with a SELinux module to solve this
issue. I wonder if it can be packaged along with Nagios...

[Yury V. Zaytsev]

Post by Scott Reese
I will troubleshoot this as an SELinux issue.
Thanks for your help.

Hi!

Please keep us posted if you come up with a SELinux module to solve this
issue. I wonder if it can be packaged along with Nagios...

[Yury V. Zaytsev]

Post by Scott Reese
I will troubleshoot this as an SELinux issue.
Thanks for your help.

Hi!

Please keep us posted if you come up with a SELinux module to solve this
issue. I wonder if it can be packaged along with Nagios...

[Scott Reese]

Post by Erik Wasser
Just to be sure. Can to disable SELinux and try it again? So we can exclude
this?

My apologies. Since I wasn't seeing anything in the audit log I assumed
that SELinux wasn't the problem. However, I disabled it and the problem
went away.

I will troubleshoot this as an SELinux issue.

Thanks for your help.

-Scott
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/ms-tnef
Size: 2505 bytes
Desc: not available
Url : http://lists.repoforge.org/pipermail/users/attachments/20101222/767c396a/attachment-0001.bin

[Scott Reese]

Post by Erik Wasser
Just to be sure. Can to disable SELinux and try it again? So we can exclude
this?

My apologies. Since I wasn't seeing anything in the audit log I assumed
that SELinux wasn't the problem. However, I disabled it and the problem
went away.

I will troubleshoot this as an SELinux issue.

Thanks for your help.

-Scott
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/ms-tnef
Size: 2505 bytes
Desc: not available
Url : http://lists.repoforge.org/pipermail/users/attachments/20101222/767c396a/attachment-0002.bin

[Scott Reese]

Post by Erik Wasser
Just to be sure. Can to disable SELinux and try it again? So we can exclude
this?

My apologies. Since I wasn't seeing anything in the audit log I assumed
that SELinux wasn't the problem. However, I disabled it and the problem
went away.

I will troubleshoot this as an SELinux issue.

Thanks for your help.

-Scott
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/ms-tnef
Size: 2505 bytes
Desc: not available
Url : http://lists.repoforge.org/pipermail/users/attachments/20101222/767c396a/attachment-0003.bin

[Scott Reese]

Post by Erik Wasser
Just to be sure. Can to disable SELinux and try it again? So we can exclude
this?

My apologies. Since I wasn't seeing anything in the audit log I assumed
that SELinux wasn't the problem. However, I disabled it and the problem
went away.

I will troubleshoot this as an SELinux issue.

Thanks for your help.

-Scott
-------------- next part --------------
A non-text attachment was scrubbed...
Name: winmail.dat
Type: application/ms-tnef
Size: 2505 bytes
Desc: not available
URL: <http://lists.repoforge.org/pipermail/users/attachments/20101222/767c396a/attachment-0004.bin>

[Hugo van der Kooij]

On Tue, 21 Dec 2010 10:02:46 -0500, "Scott Reese" wrote:

I am
trying to use the latest Nagios 3.2.3 packages on a CentOS 5.5 64-bit
virtual machine. I started with an up to date CentOS 5.5 install, added
the rpmforge repo, and then installed the nagios, nagios-plugins, and
nagios-plugins-setuid packages.

Apart from the 64 bit stuff I have an
identical setup and it works straight out of the box on Centos 5.5
32bit.

OK. I started to build my own config host by host but it runs
like a charm.

I wrote a small script to reload only after a succesful
verification:

#!/bin/sh

nagios -v
/etc/nagios/nagios.cfg

STATUS=$?

if [ $STATUS -eq 0 ]; then

service
nagios reload

else

echo "NAGIOS CONFIGURATION FAILURE!"

echo "EXIT
STATUS: $STATUS"

fi

Hugo.

[Pavel Kankovsky]

Post by Scott Reese
My apologies. Since I wasn't seeing anything in the audit log I assumed
that SELinux wasn't the problem. However, I disabled it and the problem
went away.

It might have hit a dontaudit rule. Some access failures are "expected"
or even "intended" and dontaudit rule prevent them from polluting the
audit log. Unfortunately sometimes even the "expected" failures can cause
trouble.

Try the following command to disable dontaudit rules:
# semodule -b /usr/share/selinux/targeted/enableaudit.pp

This command will enable dontaudit again:
# semodule -b /usr/share/selinux/targeted/base.pp

[Scott Reese]

Greetings:

I am trying to use the latest Nagios 3.2.3 packages on a CentOS 5.5 64-bit virtual machine. I started with an up to date CentOS 5.5 install, added the rpmforge repo, and then installed the nagios, nagios-plugins, and nagios-plugins-setuid packages.

I am using the default nagios.cfg that came with the package for testing. My problem is that the nagios service won't start using the normal tools. When I try start the service using "service nagios start", I get an error back saying "Configuration validation failed".

What's unusual about this is that if I validate the configuration by hand "nagios -v /etc/nagios/nagios.cfg", it returns as valid, with 0 warnings and 0 errors. I also tried a manual verification as the nagios user "su - nagios; nagios -v /etc/nagios/nagios.cfg", and that validates correctly as well. Additionally, if I start the service manually "su - nagios; nagios -d /etc/nagios/nagios.cfg", nagios starts up and runs properly. Once I have manually started the service, things like "service nagios status" and "service nagios stop" all work properly, but once the service is stopped, you can't use the service command to start it again.

As part of my troubleshooting, I modified the /etc/init.d/nagios file's check_config() function so that instead of piping the output of the config check to /dev/null, it printed it out on the screen. When I run the modified service start, it reports that there is an error in the configuration file at line 465, and that the directory is not valid. Line 465 in the default configuration file is "check_result_path=/var/nagios/spool/checkresults". I have verified that the specified directory exists, is owned by nagios:nagios, and has appropriate permissions (755), and that there are no SELinux denies being generated.

It seems that there is something different about the environment that /etc/init.d/nagios runs in than the normal environment. I don't know enough about the CentOS startup scripts to really go beyond that.

If it's not too much trouble, could someone try installing nagios and see if they get the same behavior with the default config files? And any pointers as to how the environment that /etc/init.d/nagios gets run in differs from a normal environment would be appreciated.

Thanks for your time.

-Scott
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.repoforge.org/pipermail/users/attachments/20101221/e1239a65/attachment-0001.html

[Erik Wasser]

Post by Scott Reese
I have verified that
the specified directory exists, is owned by nagios:nagios, and has
appropriate permissions (755), and that there are no SELinux denies being
generated.

Just to be sure. Can to disable SELinux and try it again? So we can exclude
this?

[Hugo van der Kooij]

On Tue, 21 Dec 2010 10:02:46 -0500, "Scott Reese" wrote:

I am
trying to use the latest Nagios 3.2.3 packages on a CentOS 5.5 64-bit
virtual machine. I started with an up to date CentOS 5.5 install, added
the rpmforge repo, and then installed the nagios, nagios-plugins, and
nagios-plugins-setuid packages.

Apart from the 64 bit stuff I have an
identical setup and it works straight out of the box on Centos 5.5
32bit.

OK. I started to build my own config host by host but it runs
like a charm.

I wrote a small script to reload only after a succesful
verification:

#!/bin/sh

nagios -v
/etc/nagios/nagios.cfg

STATUS=$?

if [ $STATUS -eq 0 ]; then

service
nagios reload

else

echo "NAGIOS CONFIGURATION FAILURE!"

echo "EXIT
STATUS: $STATUS"

fi

Hugo.

[Pavel Kankovsky]

Post by Scott Reese
My apologies. Since I wasn't seeing anything in the audit log I assumed
that SELinux wasn't the problem. However, I disabled it and the problem
went away.

It might have hit a dontaudit rule. Some access failures are "expected"
or even "intended" and dontaudit rule prevent them from polluting the
audit log. Unfortunately sometimes even the "expected" failures can cause
trouble.

Try the following command to disable dontaudit rules:
# semodule -b /usr/share/selinux/targeted/enableaudit.pp

This command will enable dontaudit again:
# semodule -b /usr/share/selinux/targeted/base.pp

[Scott Reese]

Greetings:

I am trying to use the latest Nagios 3.2.3 packages on a CentOS 5.5 64-bit virtual machine. I started with an up to date CentOS 5.5 install, added the rpmforge repo, and then installed the nagios, nagios-plugins, and nagios-plugins-setuid packages.

I am using the default nagios.cfg that came with the package for testing. My problem is that the nagios service won't start using the normal tools. When I try start the service using "service nagios start", I get an error back saying "Configuration validation failed".

What's unusual about this is that if I validate the configuration by hand "nagios -v /etc/nagios/nagios.cfg", it returns as valid, with 0 warnings and 0 errors. I also tried a manual verification as the nagios user "su - nagios; nagios -v /etc/nagios/nagios.cfg", and that validates correctly as well. Additionally, if I start the service manually "su - nagios; nagios -d /etc/nagios/nagios.cfg", nagios starts up and runs properly. Once I have manually started the service, things like "service nagios status" and "service nagios stop" all work properly, but once the service is stopped, you can't use the service command to start it again.

As part of my troubleshooting, I modified the /etc/init.d/nagios file's check_config() function so that instead of piping the output of the config check to /dev/null, it printed it out on the screen. When I run the modified service start, it reports that there is an error in the configuration file at line 465, and that the directory is not valid. Line 465 in the default configuration file is "check_result_path=/var/nagios/spool/checkresults". I have verified that the specified directory exists, is owned by nagios:nagios, and has appropriate permissions (755), and that there are no SELinux denies being generated.

It seems that there is something different about the environment that /etc/init.d/nagios runs in than the normal environment. I don't know enough about the CentOS startup scripts to really go beyond that.

If it's not too much trouble, could someone try installing nagios and see if they get the same behavior with the default config files? And any pointers as to how the environment that /etc/init.d/nagios gets run in differs from a normal environment would be appreciated.

Thanks for your time.

-Scott
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.repoforge.org/pipermail/users/attachments/20101221/e1239a65/attachment-0002.html

[Erik Wasser]

Post by Scott Reese
I have verified that
the specified directory exists, is owned by nagios:nagios, and has
appropriate permissions (755), and that there are no SELinux denies being
generated.

Just to be sure. Can to disable SELinux and try it again? So we can exclude
this?

[Hugo van der Kooij]

On Tue, 21 Dec 2010 10:02:46 -0500, "Scott Reese" wrote:

I am
trying to use the latest Nagios 3.2.3 packages on a CentOS 5.5 64-bit
virtual machine. I started with an up to date CentOS 5.5 install, added
the rpmforge repo, and then installed the nagios, nagios-plugins, and
nagios-plugins-setuid packages.

Apart from the 64 bit stuff I have an
identical setup and it works straight out of the box on Centos 5.5
32bit.

OK. I started to build my own config host by host but it runs
like a charm.

I wrote a small script to reload only after a succesful
verification:

#!/bin/sh

nagios -v
/etc/nagios/nagios.cfg

STATUS=$?

if [ $STATUS -eq 0 ]; then

service
nagios reload

else

echo "NAGIOS CONFIGURATION FAILURE!"

echo "EXIT
STATUS: $STATUS"

fi

Hugo.

[Pavel Kankovsky]

Post by Scott Reese
My apologies. Since I wasn't seeing anything in the audit log I assumed
that SELinux wasn't the problem. However, I disabled it and the problem
went away.

It might have hit a dontaudit rule. Some access failures are "expected"
or even "intended" and dontaudit rule prevent them from polluting the
audit log. Unfortunately sometimes even the "expected" failures can cause
trouble.

Try the following command to disable dontaudit rules:
# semodule -b /usr/share/selinux/targeted/enableaudit.pp

This command will enable dontaudit again:
# semodule -b /usr/share/selinux/targeted/base.pp

[Scott Reese]

Greetings:

I am trying to use the latest Nagios 3.2.3 packages on a CentOS 5.5 64-bit virtual machine. I started with an up to date CentOS 5.5 install, added the rpmforge repo, and then installed the nagios, nagios-plugins, and nagios-plugins-setuid packages.

I am using the default nagios.cfg that came with the package for testing. My problem is that the nagios service won't start using the normal tools. When I try start the service using "service nagios start", I get an error back saying "Configuration validation failed".

What's unusual about this is that if I validate the configuration by hand "nagios -v /etc/nagios/nagios.cfg", it returns as valid, with 0 warnings and 0 errors. I also tried a manual verification as the nagios user "su - nagios; nagios -v /etc/nagios/nagios.cfg", and that validates correctly as well. Additionally, if I start the service manually "su - nagios; nagios -d /etc/nagios/nagios.cfg", nagios starts up and runs properly. Once I have manually started the service, things like "service nagios status" and "service nagios stop" all work properly, but once the service is stopped, you can't use the service command to start it again.

As part of my troubleshooting, I modified the /etc/init.d/nagios file's check_config() function so that instead of piping the output of the config check to /dev/null, it printed it out on the screen. When I run the modified service start, it reports that there is an error in the configuration file at line 465, and that the directory is not valid. Line 465 in the default configuration file is "check_result_path=/var/nagios/spool/checkresults". I have verified that the specified directory exists, is owned by nagios:nagios, and has appropriate permissions (755), and that there are no SELinux denies being generated.

It seems that there is something different about the environment that /etc/init.d/nagios runs in than the normal environment. I don't know enough about the CentOS startup scripts to really go beyond that.

If it's not too much trouble, could someone try installing nagios and see if they get the same behavior with the default config files? And any pointers as to how the environment that /etc/init.d/nagios gets run in differs from a normal environment would be appreciated.

Thanks for your time.

-Scott
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.repoforge.org/pipermail/users/attachments/20101221/e1239a65/attachment-0003.html

[Erik Wasser]

Post by Scott Reese
I have verified that
the specified directory exists, is owned by nagios:nagios, and has
appropriate permissions (755), and that there are no SELinux denies being
generated.

Just to be sure. Can to disable SELinux and try it again? So we can exclude
this?

[Hugo van der Kooij]

On Tue, 21 Dec 2010 10:02:46 -0500, "Scott Reese" wrote:

I am
trying to use the latest Nagios 3.2.3 packages on a CentOS 5.5 64-bit
virtual machine. I started with an up to date CentOS 5.5 install, added
the rpmforge repo, and then installed the nagios, nagios-plugins, and
nagios-plugins-setuid packages.

Apart from the 64 bit stuff I have an
identical setup and it works straight out of the box on Centos 5.5
32bit.

OK. I started to build my own config host by host but it runs
like a charm.

I wrote a small script to reload only after a succesful
verification:

#!/bin/sh

nagios -v
/etc/nagios/nagios.cfg

STATUS=$?

if [ $STATUS -eq 0 ]; then

service
nagios reload

else

echo "NAGIOS CONFIGURATION FAILURE!"

echo "EXIT
STATUS: $STATUS"

fi

Hugo.

[Pavel Kankovsky]

Post by Scott Reese
My apologies. Since I wasn't seeing anything in the audit log I assumed
that SELinux wasn't the problem. However, I disabled it and the problem
went away.

It might have hit a dontaudit rule. Some access failures are "expected"
or even "intended" and dontaudit rule prevent them from polluting the
audit log. Unfortunately sometimes even the "expected" failures can cause
trouble.

Try the following command to disable dontaudit rules:
# semodule -b /usr/share/selinux/targeted/enableaudit.pp

This command will enable dontaudit again:
# semodule -b /usr/share/selinux/targeted/base.pp

[Scott Reese]

Greetings:

I am trying to use the latest Nagios 3.2.3 packages on a CentOS 5.5 64-bit virtual machine. I started with an up to date CentOS 5.5 install, added the rpmforge repo, and then installed the nagios, nagios-plugins, and nagios-plugins-setuid packages.

I am using the default nagios.cfg that came with the package for testing. My problem is that the nagios service won't start using the normal tools. When I try start the service using "service nagios start", I get an error back saying "Configuration validation failed".

What's unusual about this is that if I validate the configuration by hand "nagios -v /etc/nagios/nagios.cfg", it returns as valid, with 0 warnings and 0 errors. I also tried a manual verification as the nagios user "su - nagios; nagios -v /etc/nagios/nagios.cfg", and that validates correctly as well. Additionally, if I start the service manually "su - nagios; nagios -d /etc/nagios/nagios.cfg", nagios starts up and runs properly. Once I have manually started the service, things like "service nagios status" and "service nagios stop" all work properly, but once the service is stopped, you can't use the service command to start it again.

As part of my troubleshooting, I modified the /etc/init.d/nagios file's check_config() function so that instead of piping the output of the config check to /dev/null, it printed it out on the screen. When I run the modified service start, it reports that there is an error in the configuration file at line 465, and that the directory is not valid. Line 465 in the default configuration file is "check_result_path=/var/nagios/spool/checkresults". I have verified that the specified directory exists, is owned by nagios:nagios, and has appropriate permissions (755), and that there are no SELinux denies being generated.

It seems that there is something different about the environment that /etc/init.d/nagios runs in than the normal environment. I don't know enough about the CentOS startup scripts to really go beyond that.

If it's not too much trouble, could someone try installing nagios and see if they get the same behavior with the default config files? And any pointers as to how the environment that /etc/init.d/nagios gets run in differs from a normal environment would be appreciated.

Thanks for your time.

-Scott
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.repoforge.org/pipermail/users/attachments/20101221/e1239a65/attachment-0004.html>

[Erik Wasser]

Post by Scott Reese
I have verified that
the specified directory exists, is owned by nagios:nagios, and has
appropriate permissions (755), and that there are no SELinux denies being
generated.

Just to be sure. Can to disable SELinux and try it again? So we can exclude
this?

[Hugo van der Kooij]

On Tue, 21 Dec 2010 10:02:46 -0500, "Scott Reese" wrote:

I am
trying to use the latest Nagios 3.2.3 packages on a CentOS 5.5 64-bit
virtual machine. I started with an up to date CentOS 5.5 install, added
the rpmforge repo, and then installed the nagios, nagios-plugins, and
nagios-plugins-setuid packages.

Apart from the 64 bit stuff I have an
identical setup and it works straight out of the box on Centos 5.5
32bit.

OK. I started to build my own config host by host but it runs
like a charm.

I wrote a small script to reload only after a succesful
verification:

#!/bin/sh

nagios -v
/etc/nagios/nagios.cfg

STATUS=$?

if [ $STATUS -eq 0 ]; then

service
nagios reload

else

echo "NAGIOS CONFIGURATION FAILURE!"

echo "EXIT
STATUS: $STATUS"

fi

Hugo.

[Pavel Kankovsky]

Post by Scott Reese
My apologies. Since I wasn't seeing anything in the audit log I assumed
that SELinux wasn't the problem. However, I disabled it and the problem
went away.

It might have hit a dontaudit rule. Some access failures are "expected"
or even "intended" and dontaudit rule prevent them from polluting the
audit log. Unfortunately sometimes even the "expected" failures can cause
trouble.

Try the following command to disable dontaudit rules:
# semodule -b /usr/share/selinux/targeted/enableaudit.pp

This command will enable dontaudit again:
# semodule -b /usr/share/selinux/targeted/base.pp