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@gmail.com 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@pixelgate.net 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
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@gmail.com 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@gmail.com 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@pixelgate.net 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
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@gmail.com 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@gmail.com 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@pixelgate.net 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
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.
Thanks! That's probably a good suggestion. However I did try doing a restorecon -R -v on the entire puppet directory. No luck in resolving that error. And it's really bugging me that SELinux has to stay off in order for puppet to do it's thing.
However I was at least smart enough to keep my entire puppet directory, as well as my puppetdb directory in SVN. So in case of a need to rebuild, I can ease the process a bit. I'm heavily leaning to a rebuild at this point to resolve this. Sucks, but what can ya do!
And if I do actually take that step I hope that the rebuild resolves it. And that I haven't checked anything into SVN that would muff up SELinux on the rebuilt host.
On Mon, Jun 29, 2015 at 6:15 AM, Daniel J Walsh dwalsh@redhat.com wrote:
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@gmail.com
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@gmail.com
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@pixelgate.net 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@centos.org http://lists.centos.org/mailman/listinfo/centos
-
Daniel J Walsh -
Tim Dunphy