Bug #2095
Changing the permissions of /etc/puppet/puppet.conf via puppet crashes puppetmaster
| Status: | Accepted | Start date: | 03/19/2009 | |
|---|---|---|---|---|
| Priority: | Normal | Due date: | ||
| Assignee: | - | % Done: | 0% | |
| Category: | file | |||
| Target version: | - | |||
| Affected Puppet version: | 0.24.7 | Branch: | ||
| Keywords: | ||||
Description
class puppetperms { file {“/etc/puppet/puppet.conf”: owner => root, group => root, mode => 600 } }
then invoke puppetd —test —tags puppetperms on the puppetmaster server machine. The perms get changed, puppetmaster gets notified then crashes.
In syslog I see this
puppetd[6381]: (//Node[infra]/puppetperms/File[/etc/puppet/puppet.conf]/mode) mode changed ‘644’ to ‘600’ puppetd[6381]: Finished catalog run in 7.08 seconds puppetmasterd[26866]: Reparsing /etc/puppet/puppet.conf
But puppetmaster is now dead.
Restart puppetmaster and all is OK again. Can happily run puppetd —test —tags puppetperms while the perms are correct. Reset them via
chmod 700 /etc/puppet/puppet.conf
and puppetmaster immediately crashes without even running puppetd —test —tags puppetperms.
BTW, puppetd does not run as a daemon on any of these machines, it’s only run manually.
Related issues
History
#1
Updated by James Turnbull about 4 years ago
- Status changed from Unreviewed to Needs More Information
- Target version set to 4
Trevor – what platform is this?
#2
Updated by Trevor Hemsley about 4 years ago
Almost certainly RHEL5.3 x86_64 though I may have been experimenting on the i386 version too.
#3
Updated by Nigel Kersten over 2 years ago
- Status changed from Needs More Information to Closed
- Assignee set to Nigel Kersten
If you reopen this, we’d like to see info on the user you’re running puppet as.
As per the below thread, we’re more aggressively closing tickets whose state is unsure, particularly old tickets with little to no inactivity in a long time.
You are free to reopen them.
http://groups.google.com/group/puppet-users/browse_thread/thread/a040cb9bc5c5b647
#4
Updated by James Turnbull over 2 years ago
- Target version deleted (
4)
#5
Updated by Russell Van Tassell almost 2 years ago
- Status changed from Closed to Re-opened
Re-opening to add more info (for what it may or may not be worth).
I’ve seen this behavior in both CentOS 5.6 and CentOS 6.0 with Puppet 2.7.3. Mistakenly changing permissions on /etc/puppet to make it unsearchable (no read perms) to the puppet master will crash the server and it will generally refuse to restart. Perhaps this is reasonable/expected behavior — though it might be better to just loudly complain to the system log while refusing to do anything.
Server is running as the “puppet” user, while most of /etc/puppet is root:root (except for parts of the ssl tree).
(found this bug while searching for “minimum recommended permissions for /etc/puppet”)
#6
Updated by Nigel Kersten almost 2 years ago
How silent was this error Russell?
#7
Updated by Russell Van Tassell almost 2 years ago
Just reproduced this on CentOS 6.0 … if the master is brought up without a site.pp manifest, it just complains when the permissions disappear and other agents try to connect to it.
Aug 31 16:48:43 puppet puppet-master[2566]: Permission denied - /etc/puppet/manifests/site.pp on node machinename.sub.mydomain.com Aug 31 16:48:43 puppet puppet-master[2566]: Permission denied - /etc/puppet/manifests/site.pp on node machinename.sub.mydomain.com
However, once the site.pp file and basic modules are added, it immediately and silently crashes if its permissions are yanked (sudo chmod go= /etc/puppet). Even better, if you try to restart the master, the logs seem to show normal startup, but nothing else:
Aug 31 17:04:23 puppet puppet-master[14250]: Reopening log files Aug 31 17:04:23 puppet puppet-master[14250]: Starting Puppet master version 2.7.3
However, the process actually fails to start. Fixed the permissions on /etc/puppet (sudo chmod go+rx /etc/puppet) allows the daemon to again function normally.
#8
Updated by Nigel Kersten almost 2 years ago
- Status changed from Re-opened to Accepted
- Assignee deleted (
Nigel Kersten) - Target version set to 2.7.x
The target goal here is to loudly complain and make it obvious to the user that the process is exceedingly unhappy about being unable to read the files.
#9
Updated by Andrew Parker 6 months ago
- Target version deleted (
2.7.x)