Jira (PUP-1635) current thread not owner after Puppet Agent receives USR1 signal
Title: Message Title Logan Attwood commented on an issue Re: current thread not owner after Puppet Agent receives USR1 signal Also chiming in on this. [centos@galen-stage ~]$ ruby -v ruby 2.0.0p353 (2013-11-22) [x86_64-linux] [centos@galen-stage ~]$ rpm -qa | grep puppet puppetlabs-release-7-11.noarch puppet-3.7.1-1.el7.noarch mcollective-puppet-agent-1.9.1-1.el7.noarch mcollective-puppet-common-1.9.1-1.el7.noarch Add Comment
Jira (PUP-1635) current thread not owner after Puppet Agent receives USR1 signal
Title: Message Title Logan Attwood updated an issue Puppet / PUP-1635 current thread not owner after Puppet Agent receives USR1 signal Change By: Logan Attwood Environment: Ubuntu12.04.2LTSRuby2.0.0(patchlevel353)ORRuby2.1.0(patchlevel0) CentOS7Ruby2.0.0(patchlevel353) Add Comment This message was sent by Atlassian JIRA (v6.1.4#6159-sha1:44eaede) -- You received this message because you are subscribed to the Google Groups Puppet Bugs group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.
Jira (FACT-596) selinux_config_policy returns unknown on Debian
Title: Message Title Logan Attwood commented on an issue Re: selinux_config_policy returns unknown on Debian Adrien Thebo, this is an issue in CentOS7 as well. rpm -qa | grep selinux selinux-policy-targeted-3.12.1-153.el7_0.10.noarch libselinux-ruby-2.2.2-6.el7.x86_64 libselinux-utils-2.2.2-6.el7.x86_64 libselinux-python-2.2.2-6.el7.x86_64 selinux-policy-3.12.1-153.el7_0.10.noarch libselinux-2.2.2-6.el7.x86_64 facter | grep selinux_config_policy selinux_config_policy = unknown Add Comment Facter / FACT-596 selinux_config_policy returns unknown on Debian selinux_config_policy always returns unknown on Debian. As far I can tell this is due to Facter looking for the output line Policy from config file (line 76 of selinux.rb) in sestatus but Debian's sestatus instead uses Loaded policy name See example output on Debian: ``` SELinux status: enabled SELinuxfs mount: ... This message was sent by Atlassian JIRA (v6.1.4#6159-sha1:44eaede)
Jira (PUP-2413) Attempting to log the output of service initialization on CentOS 6.5 causes SELinux violations
Title: Message Title Logan Attwood created an issue Puppet / PUP-2413 Attempting to log the output of service initialization on CentOS 6.5 causes SELinux violations Issue Type: Bug Assignee: Unassigned Created: 01/May/14 8:12 AM Environment: CentOS 6.5 Puppet 3.5.0 Priority: Normal Reporter: Logan Attwood It looks like puppet is creating a file in /tmp to connect to the stdout of service httpd start to. Out of the box CentOS 6 (and I can only assume RHEL 6) does not permit Apache to write to /tmp, causing an SELinux violation similar to the following: kernel: type=1400 audit(1398909812.247:10): avc: denied { read write } for pid=20375 comm=httpd path=/tmp/puppet20140501-19869-xtobvy-0 dev=xvde ino=18584 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:initrc_tmp_t:s0 tclass=file I suspect this had to do with bringing the service resource providers up to feature parity with the exec resource providers. The workaround would be to accept not getting Apache's startup output when using Puppet, or create an selinux module to permit apache writing to /tmp.