I have no idea of the current dependency problem. I think your original
problem was caused by mv'ing files from an nfs share to /etc which
maintained the context. And SELinux prevented puppet from accessing
nfs_t type. If you had just run restorecon on the object it would have
set it back to the correct/default context.
You might want to setup an alias mv "mv -Z"
This changes the way mv works to set the context after mv rather then
maintaining the source context.
On 06/21/2015 02:05 PM, Tim Dunphy wrote:
> Hey guys,
>
> Quick update. I grepped through the output of getsebool -a to see that
> related to puppet. And I found this setting: puppetagent_manage_all_files.
>
> So I tried running this command: setsebool -P puppetagent_manage_all_files
> 0
>
> And did a restorecon on my modules directory: restorecon -R -v
> environments/production/moudles
>
> So there's good news and bad news to report! It seems that now puppet on
> the client isn't complaining about not having access to the cert and key
> files anymore! That's the good news. The bad news is, when I do puppet runs
> on all the hosts now, I get the following errors:
>
> Notice: /File[/var/lib/puppet/lib/facter/concat_basedir.rb]: Dependency
> File[/var/lib/puppet/lib] has failures: true
> Warning: /File[/var/lib/puppet/lib/facter/concat_basedir.rb]: Skipping
> because of failed dependencies
> Notice: /File[/var/lib/puppet/lib/facter/ssldir.rb]: Dependency
> File[/var/lib/puppet/lib] has failures: true
> Warning: /File[/var/lib/puppet/lib/facter/ssldir.rb]: Skipping because of
> failed dependencies
> Notice:
> /File[/var/lib/puppet/lib/puppet/parser/functions/ensure_resource.rb]:
> Dependency File[/var/lib/puppet/lib] has failures: true
> Warning:
> /File[/var/lib/puppet/lib/puppet/parser/functions/ensure_resource.rb]:
> Skipping because of failed dependencies
> Notice: /File[/var/lib/puppet/lib/puppet/parser/functions/validate_re.rb]:
> Dependency File[/var/lib/puppet/lib] has failures: true
> Warning: /File[/var/lib/puppet/lib/puppet/parser/functions/validate_re.rb]:
> Skipping because of failed dependencies
> Notice: /File[/var/lib/puppet/lib/puppet/reports/datadog_reports.rb]:
> Dependency File[/var/lib/puppet/lib] has failures: true
> Warning: /File[/var/lib/puppet/lib/puppet/reports/datadog_reports.rb]:
> Skipping because of failed dependencies
> Notice:
> /File[/var/lib/puppet/lib/puppet/parser/functions/is_function_available.rb]:
> Dependency File[/var/lib/puppet/lib] has failures: true
> Warning:
> /File[/var/lib/puppet/lib/puppet/parser/functions/is_function_available.rb]:
> Skipping because of failed dependencies
> Notice:
> /File[/var/lib/puppet/lib/puppet/parser/functions/str2saltedsha512.rb]:
> Dependency File[/var/lib/puppet/lib] has failures: true
> Warning:
> /File[/var/lib/puppet/lib/puppet/parser/functions/str2saltedsha512.rb]:
> Skipping because of failed dependencies
> Notice:
> /File[/var/lib/puppet/lib/puppet/parser/functions/delete_undef_values.rb]:
> Dependency File[/var/lib/puppet/lib] has failures: true
> Warning:
> /File[/var/lib/puppet/lib/puppet/parser/functions/delete_undef_values.rb]:
> Skipping because of failed dependencies
> Notice: /File[/var/lib/puppet/lib/puppet/parser/functions/fqdn_rotate.rb]:
> Dependency File[/var/lib/puppet/lib] has failures: true
> Warning: /File[/var/lib/puppet/lib/puppet/parser/functions/fqdn_rotate.rb]:
> Skipping because of failed dependencies
> Notice: /File[/var/lib/puppet/lib/facter/gemhome.rb]: Dependency
> File[/var/lib/puppet/lib] has failures: true
> Warning: /File[/var/lib/puppet/lib/facter/gemhome.rb]: Skipping because of
> failed dependencies
> Notice: /File[/var/lib/puppet/lib/puppet/parser/functions/values_at.rb]:
> Dependency File[/var/lib/puppet/lib] has failures: true
> Warning: /File[/var/lib/puppet/lib/puppet/parser/functions/values_at.rb]:
> Skipping because of failed dependencies
> Notice: /File[/var/lib/puppet/lib/puppet/parser/functions/getvar.rb]:
> Dependency File[/var/lib/puppet/lib] has failures: true
> Warning: /File[/var/lib/puppet/lib/puppet/parser/functions/getvar.rb]:
> Skipping because of failed dependencies
> Notice: /File[/var/lib/puppet/lib/puppet/provider/vcsrepo/cvs.rb]:
> Dependency File[/var/lib/puppet/lib] has failures: true
> Warning: /File[/var/lib/puppet/lib/puppet/provider/vcsrepo/cvs.rb]:
> Skipping because of failed dependencies
> Notice: /File[/var/lib/puppet/lib/puppet/parser/functions/strftime.rb]:
> Dependency File[/var/lib/puppet/lib] has failures: true
> Warning: /File[/var/lib/puppet/lib/puppet/parser/functions/strftime.rb]:
> Skipping because of failed dependencies
> Notice: /File[/var/lib/puppet/lib/puppet/parser/functions/chop.rb]:
> Dependency File[/var/lib/puppet/lib] has failures: true
> Warning: /File[/var/lib/puppet/lib/puppet/parser/functions/chop.rb]:
> Skipping because of failed dependencies
> Notice: /File[/var/lib/puppet/lib/puppet/util/firewall.rb]: Dependency
> File[/var/lib/puppet/lib] has failures: true
> Warning: /File[/var/lib/puppet/lib/puppet/util/firewall.rb]: Skipping
> because of failed dependencies
> Notice: /File[/var/lib/puppet/lib/puppet/parser/functions/is_float.rb]:
> Dependency File[/var/lib/puppet/lib] has failures: true
> Warning: /File[/var/lib/puppet/lib/puppet/parser/functions/is_float.rb]:
> Skipping because of failed dependencies
> Notice: /File[/var/lib/puppet/lib/puppet/parser/functions/parsejson.rb]:
> Dependency File[/var/lib/puppet/lib] has failures: true
> Warning: /File[/var/lib/puppet/lib/puppet/parser/functions/parsejson.rb]:
> Skipping because of failed dependencies
> Notice: /File[/var/lib/puppet/lib/puppet/parser/functions/validate_cmd.rb]:
> Dependency File[/var/lib/puppet/lib] has failures: true
> Warning:
> /File[/var/lib/puppet/lib/puppet/parser/functions/validate_cmd.rb]:
> Skipping because of failed dependencies
>
> It's actually a long list of errors that's too long to reproduce here. It'd
> go on for a couple pages at least.
>
> However if I turn off SELinux on the puppet master, everything returns to
> normal. Goes from utter chaos to complete order in an instant!
>
> So I guess I've muffed up my SELinux config on this puppet host. I just
> hope it's repairable at this point! I'd hate to leave it off just so that
> puppet will be able to do it's job. And of all the hosts that would need
> SELinux protection I would think that a puppet host would be one of the
> most important if not 'the' most important to protect!
>
> I'm definitely open to suggestions at this point!
>
> Thanks,
> Tim
>
> On Sun, Jun 21, 2015 at 11:11 AM, Tim Dunphy <bluethundr@xxxxxxxxx> wrote:
>
>> Hi all,
>>
>> Thanks for all your suggestions. Here's where I'm at with this.
>>
>> Can you give details about your puppetmasterd setup ? it seems that
>>> you're using Foreman as puppet ENC.
>>>
>> Yes, I'm on foreman 1.7.4 and puppet 3.75. You are correct that I'm using
>> foreman, sorry I hadn't thought to mention it!
>>
>>
>>> Foreman works fine with selinux enabled : that's what we use for the
>>> centos.org infra :-)
>>> Which version of puppet/foreman are you using ? Note that foreman has
>>> the foreman-selinux package that is used to automatically tune
>>> contexts and booleans needed for this.
>>> You can still reapply those settings with
>>> /usr/sbin/foreman-selinux-{disable,enable,relabel}
>>> There is no need to recompile a custom selinux policy for
>>> foreman/puppet those days
>>>
>> I didn't recompile any custom selinux policies. All I did to try to
>> resolve the issue is to consult audit2allow and install the module it
>> suggested.
>> I did try running /usr/sbin/foreman-selinux-enable but that didn't seem
>> to have an effect.
>>
>> Knowing nothing of your scenario, look at the source and target context.
>>> Looks like you copied a crt from an nfs location and you don't have a
>>> file context defined to transition labels, maybe something like:
>>>
>>> semanage fcontext -a -t passenger_t "/etc/puppet/environments(/.*)?"
>>>
>>> However, I know nothing of puppets selinux infrastructure, you may need
>>> a more applicable type.
>>>
>>> In these cases, audit2allow can't possibly guess the right thing and will
>>> certainly produce a rule that is either unsafe or simply wrong.
>>>
>> You are correct that I copied the key and cert from an NFS share! Both the
>> puppet server and the monitor1 client share the same /home directory via
>> NFS. Pretty cool that you picked up on that! I do suspect you're probably
>> right that this may be causing the problem. Just on a hunch, I tried
>> copying the certs and keys from the montior1 host over to the puppet host
>> to the /tmp directory on the puppet server. That leaves out NFS altogether.
>> And when I do that, my bacula puppet module WORKS!! Puppet doesn't complain
>> at all!
>>
>> But if I check out another host where I copied the cert and key from the
>> NFS home directory I still get the error:
>>
>> Error:
>> /Stage[main]/Bacula::Config/File[/etc/pki/tls/private/monitor2.mydomain.com.key]:
>> Could not evaluate: Could not retrieve information from environment
>> production source(s)
>> puppet:///modules/bacula/monitor2/monitor2.mydomain.com.key
>> Error:
>> /Stage[main]/Bacula::Config/File[/etc/pki/tls/certs/monitor2.mydomain.com.crt]:
>> Could not evaluate: Could not retrieve information from environment
>> production source(s)
>> puppet:///modules/bacula/monitor2/monitor2.mydomain.com.crt
>>
>> Also when I try to set context using the line you suggested I get an
>> error:
>>
>> #semanage fcontext -a -t passenger_t "/etc/puppet/environments(/.*)?"
>> ValueError: Type passenger_t is invalid, must be a file or device type
>>
>> So I googled around and found what seems to be the correct syntax:
>>
>> semanage fcontext -a -t passenger_exec_t "/etc/puppet/environments(/.*)?"
>>
>> Because when I applied that line, I didn't get any errors or complaints.
>> However the problem still existed on the monitor2 host which had the key
>> pair copied from the NFS share.
>>
>> So in summary it appears that there is some interaction between SELinux
>> and NFS that is causing the issue.
>>
>> Any thoughts?
>>
>> Thanks,
>> Tim
>>
>> On Sun, Jun 21, 2015 at 11:09 AM, Tim Dunphy <bluethundr@xxxxxxxxx> wrote:
>>
>>> Yes, you did when you used the audit2allow with the -M option argument
>>>> of "puppet", which is confirmed by the command you issued to try to load
>>>> it "semodule -i puppet.pp" (which you stated in your original message).
>>>> I'm okay with you asserting otherwise and not following my first
>>>> suggestion -- my second is to use a totally different name, e.g., "barf"
>>>> and thus "semodule -i barf.pp".
>>>
>>> Haha!! Ok man. I get you now. Thanks. Also I meant to send this to the
>>> list.. Whoops! I'll try doing it again with something like 'my' in the
>>> front. I remember having a similar problem with Zabbix last week that I
>>> solved this way.
>>>
>>> On Sun, Jun 21, 2015 at 12:19 AM, Mark Milhollan <mlm@xxxxxxxxxxxxx>
>>> wrote:
>>>
>>>> On Sat, 20 Jun 2015, Tim Dunphy wrote:
>>>>> I wrote:
>>>>>> That suggests there's already a module named puppet, and thus you are
>>>>>> replacing it with the one you made which does not supply the
>>>>>> puppet_var_lib_t type. Always prefix your own modules with something
>>>>>> that makes them almost certain to be unique, e.g., yourdom_puppet.
>>>>>>
>>>>> No, actually I didn't compile my own selinux module. :) Not sure how you
>>>>> got that idea, but that is not the case.
>>>> Yes, you did when you used the audit2allow with the -M option argument
>>>> of "puppet", which is confirmed by the command you issued to try to load
>>>> it "semodule -i puppet.pp" (which you stated in your original message).
>>>> I'm okay with you asserting otherwise and not following my first
>>>> suggestion -- my second is to use a totally different name, e.g., "barf"
>>>> and thus "semodule -i barf.pp".
>>>>
>>>>
>>>> /mark
>>>>
>>>
>>>
>>> --
>>> GPG me!!
>>>
>>> gpg --keyserver pool.sks-keyservers.net --recv-keys F186197B
>>>
>>>
>>
>> --
>> GPG me!!
>>
>> gpg --keyserver pool.sks-keyservers.net --recv-keys F186197B
>>
>>
>
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
