With an updated rndc exec statement I ran into an SELinux problem with
puppet. My exec statement is:
exec { "/usr/sbin/rndc reload":
subscribe => File["/var/named/chroot/etc/named.conf"],
refreshonly => true
}
When I ran puppetd on the client it appeared to run sucessfully:
puppetd --verbose --test
info: Caching catalog at /var/lib/puppet/localconfig.yaml
notice: Starting catalog run
notice: //Node[default]/named/Service[named]/ensure: ensure changed
'stopped' to 'running'
96a97
>
notice: //Node[default]/sendmail/File[/etc/aliases]/source: replacing
from source puppet:///files/aliases with contents {md5}
242e95de5ec05d8becabad5d3c33749c
info: //Node[default]/sendmail/File[/etc/aliases]: Scheduling refresh
of Exec[/usr/bin/newaliases]
notice: //Node[default]/sendmail/Exec[/usr/bin/newaliases]: Triggering
'refresh' from 1 dependencies
notice: //Node[default]/named/File[/var/named/chroot/etc/named.conf]/
ensure: created
info: //Node[default]/named/File[/var/named/chroot/etc/named.conf]:
Scheduling refresh of Exec[/usr/sbin/rndc reload]
notice: //Node[default]/named/Exec[/usr/sbin/rndc reload]: Triggering
'refresh' from 1 dependencies
notice: Finished catalog run in 6.74 seconds
But in the /var/log/messages file I got the following SELinux error:
Jun 10 16:09:13 vopssrv-02 setroubleshoot: SELinux is preventing the
rndc from using potentially mislabeled files (/tmp/puppet.5020.0). For
complete SELinux messages. run sealert -l 67cf31ee-
d618-4df7-87cf-777f5abcf277
Which sealert translated to:
SELinux is preventing the rndc from using potentially mislabeled files
(/tmp/puppet.5020.0).
. . .
Allowing Access:
If you want rndc to access this files, you need to relabel them using
restorecon
-v '/tmp/puppet.5020.0'. You might want to relabel the entire
directory using
restorecon -R -v '/tmp'.
Having seen a similar problem with nagios and ping:
> This is a classic leaked file descriptor. Obviously ping has no business
> reading the nagios spool file, it would know nothing about this
> file, but nagios has a open file descriptor to the fifo_file when it
> execs ping. ping inherits the open file descriptor. The kernel checks
> the ping policy to see if ping can read the fifo file, when it finds it
> can not, it reports a violation, closes the file desctriptor for ping
> and reopens it with /dev/null. It then completes the startup of ping.
> You should report this as a bug to nagios. They should execute
> fcntl(fd, F_SETFD, FD_CLOEXEC) on all open file descriptors before
> fork/exec of any subprocess.
So does this make any sense to one of the ruby programmers among you?
RLH
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Puppet Developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/puppet-dev?hl=en
-~----------~----~----~----~------~----~------~--~---
