-
-
Notifications
You must be signed in to change notification settings - Fork 124
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix Idempotence issue for RHEL 7 forwarder install #153
base: master
Are you sure you want to change the base?
Fix Idempotence issue for RHEL 7 forwarder install #153
Conversation
Hard to tell what's going on without actually testing the module myself, but my initial guess is that something changes the SELinux policy while puppet is running (eg. one of the packages it installs) so that on the next run, the file contexts for that particular path are different than on the first run and puppet corrects them. To see which is "correct", run restorecon on that path. If it changes from unconfined_u to system_u, then that's what the policy declares and the puppet code should probably default to that too. |
I'm also not sure, but what @oranenj says makes sense (if the settings are coming from the package rather than from Puppet, you could also try looking at the rpm's scripts). |
I'll give this a shot. |
@@ -171,7 +171,8 @@ | |||
mode => $facts['kernel'] ? { | |||
'windows' => undef, | |||
default => '0600', | |||
} | |||
}, | |||
seluser => 'unconfined_u', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure this is right. If on the second run, puppet wants to set it to system_u
that's probably because a new selinux module has been installed with the RPM and the type should be system_u
. I think there's also a high probability users are bumping into https://tickets.puppetlabs.com/browse/PUP-2169 which puppet apply
(as used in the acceptance tests) won't be affected by.
Basically, puppet defaults the value of seluser
based on what it thinks it should be. But, there's a caching issue and it never rechecks after a new selinux policy is loaded. You need to restart the puppet service... :(
Dear @TraGicCode, thanks for the PR! This is pccibot, your friendly Vox Pupuli GitHub Bot. I noticed that your pull request contains merge conflict. Can you please rebase? You can find my sourcecode at voxpupuli/vox-pupuli-tasks |
Dear @TraGicCode, thanks for the PR! This is pccibot, your friendly Vox Pupuli GitHub Bot. I noticed that your pull request contains merge conflict. Can you please rebase? You can find my sourcecode at voxpupuli/vox-pupuli-tasks |
Dear @TraGicCode, thanks for the PR! This is pccibot, your friendly Vox Pupuli GitHub Bot. I noticed that your pull request contains merge conflict. Can you please rebase? You can find my sourcecode at voxpupuli/vox-pupuli-tasks |
Dear @TraGicCode, thanks for the PR! This is pccibot, your friendly Vox Pupuli GitHub Bot. I noticed that your pull request contains merge conflict. Can you please rebase? You can find my sourcecode at voxpupuli/vox-pupuli-tasks |
I could really use a second pair of 👀 on this. I was sifting through the issues on github for this module and noticed someone having a problem a RHEL 7. While i was not able to reproduce their issue specifically ( i assume it's fixed ) i did notice the idempotence test for the forwarder is failing when run under beaker. I know pretty much nothing about se_linux on RHEL 7 but what i do know is the following attribute on the file resource solves the forwarder idempotence test. Could anyone verify this fix is indeed valid?
FYI. Here is the failing beaker test without this change.
First Run
Second run