Issue #16637 has been updated by Jeff McCune. Status changed from Closed to Needs More Information Target version changed from 3.0.1 to 3.0.x
Curtis Ruck wrote: > The sheer lack of thought for existing puppetmaster users on this commit is > frightening. This completely trashed my test environment. Curtis, I'm really sorry this trashed your test environment. I worked quite a long time on this issue tried my best to resolve the issue once and for all. If you have the time, I'd like to take a moment and explain our thinking about this issue. First, please understand that we put a _lot_ of thought into this. My goal was to resolve the issue once and for all, simplify the problem, simplify the explanation of the way Puppet behaves, and minimize the impact on you and all of our end users. As you can see by the list of related tickets and the History section above, this issue has been a "looping." In some releases we fix the issue, in other releases we regress. I found 30 tickets related to this issue going all the way back to the very beginning of the Puppet project. Using this data and history, I've come to the conclusion that if I simply try and fix the issue using the current semantics then there's a very high likelihood another issue will come up after the 3.0.0 release. Basically, we're unable to correctly implement the _previous_ description of the behavior of the puppetmaster: 0. Use explicitly set `--confdir` and `--vardir` if they're set on the command line _or_ in the configuration file. (Parsing `puppet.conf` poses a challenge because where is the default configuration file located given the rest of these rules?) 1. If the process is a puppet master _and_ is running as the system puppet user (which may not necessarily be "puppet"), then use the system directories. 2. If the process is the master and is running as a user who is EUID != 0 and who is now the system puppet user, then use the home directories. 3. If the process is anything other than the master and is running as EUID != 0, then use the home directories. 4. If the process EUID == 0 then use the system directories. So this set of rules pose a challenge to "get right." We also have a lot of evidence that we're unable to get it right. When we don't get it right we negatively affect all of our uses and also cause failures on the puppet master. I went through this myself a number of times when I managed Puppet so I totally understand your pain. My thinking on this issue was that if I can cause just a little bit of pain in a major, backwards-incompatible release but it means that the issue will be resolved once and for all, then it's worth it for all of us. I asked myself, what to do? What are the options I have? What if I can change the rules? Puppet 3.0.0 is a major release and presents me with the opportunity to do just that. I can change the rules of the game and call out the change as backwards incompatible. My intent with this patch was to do just that, here's what I came up with that I hope is more simple for everyone to understand from the perspective of a Puppet user and from my perspective of trying to make this code work well now and through the future. 1. If the user explicitly sets `--confdir` and `--vardir`, then use those values. 2. If the process us EUID == 0 then use the system directories. 3. For all other cases, use the personal directories. As you can see, this description of the behavior is much more simple. There are far fewer edge cases. The downside to this change is that I've eliminated the special case behavior for detecting if the process is running as the Puppet system user or not. My intent was to call out that this change requires a change to the `config.ru` to explicitly set `--confdir` and `--vardir`. Now, I overlooked something for the 3.0.0 release. I thought the only change required would be to set `--confdir`, so I updated our example config.ru to contain this argument. However, both `--confdir` _and_ `--vardir` must be specified in `config.ru`. I've since fixed the `config.ru` example in this commit: [623fa02 Update config.ru to fix issue with vardir](https://github.com/puppetlabs/puppet/commit/623fa02). So this brings us up to the 3.0.1rc1 version of Puppet. > So, historically, puppet master runs as the user 'puppet' since it doesn't > need root access. But Puppet master should keep its certs in a location > outside of his $HOME so things like httpd/mod_passenger can access the > certificates. By defaulting $confdir to ~/.puppet your hiding the certs by > default and making getting mod_passenger/httpd working for puppetmaster that > more difficult. httpd usually starts as EUID root and sheds permissions after reading the configuration files (and certificates). So it doesn't really matter where you keep the certificates, Apache will be able to read them when it starts because it's root. There are actually two modes of operation for puppet masters. If you start the master from the command line using `puppet master` as root, then it will run as root for a time and drop privs down to the user you've configured as the system user. If you use passenger, however, the Puppet process never starts as root because Passenger will shed permissions and change to the EUID of the account who owns the `config.ru` file. So this is all of the thinking that went into this relatively small, but knowingly-backwards-incompatible, change. How did this issue affect you? What caused you to upgrade to 3.0.0 in your test environment? What is the behavior you expected? What was the behavior you received? I hope this information and these questions help. I'm going to re-open this issue because as I mentioned, I hoped to resolve this issue in a manner that will stay resolved. Based on this update it seems to still be an issue. Cheers, -Jeff ---------------------------------------- Bug #16637: Puppet confdir and vardir are wrong when running non-root https://projects.puppetlabs.com/issues/16637#change-73728 Author: Jeff McCune Status: Needs More Information Priority: Normal Assignee: Category: settings Target version: 3.0.x Affected Puppet version: 3.0.0 Keywords: telly settings defaults confdir vardir runmode run_mode master system Branch: https://github.com/puppetlabs/puppet/pull/1194 # Overview Puppet master should default to confdir of `~/.puppet` and vardir of `~/.puppet/var` when running as non-root, instead defaults to `/etc/puppet` and `/var/lib/puppet` respectively. In Puppet 3.0.0, the semantics of the term, "configuration directory" (confdir) are as follows: 1. If `confdir` is explicitly configured, this value wins. 2. If Puppet is running as root (or the OS equivalent) then use the system configuration directory. (e.g. `/etc/puppet` for FOSS or `/etc/puppetlabs/puppet` for PE) 3. In all other situations use `~/.puppet` These semantics are no longer affected by the specific username when running non-root, or the application being run (master, agent, etc...). This is not actually the case in 3.0.0 though: # Actual Behavior <pre> $ puppet master --verbose --no-daemonize Error: Could not set 'directory' on ensure: Permission denied - /etc/puppet Error: Could not set 'directory' on ensure: Permission denied - /etc/puppetWrapped exception: Permission denied - /etc/puppet Error: /File[/etc/puppet]/ensure: change from absent to directory failed: Could not set 'directory' on ensure: Permission denied - /etc/puppet /File[/etc/puppet/var.master]: Dependency File[/etc/puppet] has failures: true Warning: /File[/etc/puppet/var.master]: Skipping because of failed dependencies /File[/etc/puppet/var.master/bucket]: Dependency File[/etc/puppet] has failures: true Warning: /File[/etc/puppet/var.master/bucket]: Skipping because of failed dependencies /File[/etc/puppet/var.master/log]: Dependency File[/etc/puppet] has failures: true Warning: /File[/etc/puppet/var.master/log]: Skipping because of failed dependencies /File[/etc/puppet/var.master/log/masterhttp.log]: Dependency File[/etc/puppet] has failures: true Warning: /File[/etc/puppet/var.master/log/masterhttp.log]: Skipping because of failed dependencies /File[/etc/puppet/var.master/yaml]: Dependency File[/etc/puppet] has failures: true Warning: /File[/etc/puppet/var.master/yaml]: Skipping because of failed dependencies /File[/etc/puppet/var.master/ssl]: Dependency File[/etc/puppet] has failures: true Warning: /File[/etc/puppet/var.master/ssl]: Skipping because of failed dependencies /File[/etc/puppet/var.master/ssl/public_keys]: Dependency File[/etc/puppet] has failures: true Warning: /File[/etc/puppet/var.master/ssl/public_keys]: Skipping because of failed dependencies/File[/etc/puppet/var.master/lib]: Dependency File[/etc/puppet] has failures: trueWarning: /File[/etc/puppet/var.master/lib]: Skipping because of failed dependencies/File[/etc/puppet/var.master/ssl/certificate_requests]: Dependency File[/etc/puppet] has failures: true Warning: /File[/etc/puppet/var.master/ssl/certificate_requests]: Skipping because of failed dependencies/File[/etc/puppet/var.master/run]: Dependency File[/etc/puppet] has failures: true Warning: /File[/etc/puppet/var.master/run]: Skipping because of failed dependencies/File[/etc/puppet/manifests]: Dependency File[/etc/puppet] has failures: trueWarning: /File[/etc/puppet/manifests]: Skipping because of failed dependencies /File[/etc/puppet/var.master/ssl/private]: Dependency File[/etc/puppet] has failures: true Warning: /File[/etc/puppet/var.master/ssl/private]: Skipping because of failed dependencies /File[/etc/puppet/var.master/ssl/private_keys]: Dependency File[/etc/puppet] has failures: true Warning: /File[/etc/puppet/var.master/ssl/private_keys]: Skipping because of failed dependencies /File[/etc/puppet/var.master/rrd]: Dependency File[/etc/puppet] has failures: true Warning: /File[/etc/puppet/var.master/rrd]: Skipping because of failed dependencies /File[/etc/puppet/var.master/ssl/certs]: Dependency File[/etc/puppet] has failures: true Warning: /File[/etc/puppet/var.master/ssl/certs]: Skipping because of failed dependencies /File[/etc/puppet/var.master/reports]: Dependency File[/etc/puppet] has failures: true Warning: /File[/etc/puppet/var.master/reports]: Skipping because of failed dependencies /File[/etc/puppet/var.master/server_data]: Dependency File[/etc/puppet] has failures: true Warning: /File[/etc/puppet/var.master/server_data]: Skipping because of failed dependencies /File[/etc/puppet/var.master/state]: Dependency File[/etc/puppet] has failures: true Warning: /File[/etc/puppet/var.master/state]: Skipping because of failed dependencies Error: Could not prepare for execution: Got 3 failure(s) while initializing: Could not set 'directory' on ensure: Permission denied - /etc/puppet; Could not set 'directory' on ensure: Permission denied - /etc/puppet Wrapped exception: Permission denied - /etc/puppet; change from absent to directory failed: Could not set 'directory' on ensure: Permission denied - /etc/puppet </pre> # Expected behavior `confdir` and `vardir` should default to my home directory when run as non-root user "jeff" <pre> $ puppet master --verbose --no-daemonize Info: Creating a new SSL key for ca Info: Creating a new SSL certificate request for ca Info: Certificate Request fingerprint (SHA256): E4:95:B1:A5:01:A5:07:80:0B:B7:C6:5E:C1:4F:58:EF:CD:FF:D3:DE:EC:30:EF:10:3C:92:53:91:7A:33:26:BC Signed certificate request for ca Rebuilding inventory file Info: Creating a new certificate revocation list Info: Creating a new SSL key for mccune.local Info: Creating a new SSL certificate request for mccune.local Info: Certificate Request fingerprint (SHA256): A8:77:22:5A:D0:C8:89:69:8E:3B:38:7A:0B:43:E3:D7:AA:E8:7F:73:F3:DC:E6:E2:0C:E1:BA:23:41:ED:4B:CF mccune.local has a waiting certificate request Signed certificate request for mccune.local Removing file Puppet::SSL::CertificateRequest mccune.local at '/Users/jeff/.puppet/ssl/ca/requests/mccune.local.pem' Removing file Puppet::SSL::CertificateRequest mccune.local at '/Users/jeff/.puppet/ssl/certificate_requests/mccune.local.pem' Starting Puppet master version 3.0.0 </pre> -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
