Scott Reese wrote: > Greetings: > > I've been looking at the SELinux policy as it relates to Nagios. It's > been a learning experience, and I now fully understand why people just > turn SELinux off. What a hassle. In any event, I've isolated the > issues, and I'm looking for advice from those of you who package > software around here on which way of solving the problem is best. > > RedHat is shipping a Nagios SELinux policy module as part of their base > selinux-policy package. It has a few problems, some major, some minor. > The major one, which causes Nagios to not be able to start if SELinux is > set to Enforcing is that the policy expects certain Nagios files to be > in one place, but they are somewhere else. The problem is in the /var > directory structures. RedHat expects Nagios to put its files into the > existing /var structures. PID files go in /var/run, spool files (which > Nagios is using to get results back from the plugins) in > /var/spool/nagios, etc. The way that Nagios is packaged, however, is > different. It creates a /var/nagios directory structure, and puts all > of its files in there. Since the files aren't where the SELinux policy > expects them to be, it generates denials and Nagios doesn't work. > > So, the options boil down to change the Nagios packages to fit the > shipping RedHat SELinux policy, or modify the SELinux policy to match > the shipping Nagios package. My question is, which do you think is the > best way to go? > > Yury had previously asked if the SELinux policy could be packaged and > shipped with the Nagios RPMs. The infrastructure to do that is built > into the RPM packaging system, so it would be a possibility. What I > haven't figured out is how that would interact with the policy module > that RedHat is shipping as part of the base package. I don't know if > RedHat would have to remove that module from the package, or if just > shipping a module with a higher version number would replace the RedHat > module with the Nagios module.
One can leave the Nagios structure intact and just create a local SELinux policy related to it. Local policies are not wiped-out during SELinux policy updates and as you stated, rpm provides tools for such purposes. Cheers Frank -- <[email protected]> _______________________________________________ users mailing list [email protected] http://lists.rpmforge.net/mailman/listinfo/users
