Issue #16637 has been updated by Jeff McCune.

Roman Chyla wrote:
> Jeff, may I suggest sb creates a unittest for this behaviour? As you say in 
> some releases regressions happen and I am right now on a fresh Puppet 
> installation, 3.0.1., I used puppetlabs repo to install puppetmaster. And I 
> get the same error (but as root)
> 
> my puppet.conf
> 
> [...]
> 
> output
> [...]
> 
> and if i comment factpath, i get:
> 
> [...]
> 
> Please note that $vardir is used by ssldir in the [main] section, and it is 
> fine (am I doing st wrong?)
> 
> To me it is scary to think that the same variation of error appears when it 
> was fixed already

This actually looks like a different issue in our settings subsystem.  It still 
exists in 3.1.0 and our master development branch.  Roman, would you mind 
filing this problem as a new issue and assign it to me?  I'll update the new 
issue with my investigation, but the use case you're trying to achieve will be 
important to understand the context of the issue.

Thanks,
-Jeff
----------------------------------------
Bug #16637: Puppet confdir and vardir are wrong when running non-root
https://projects.puppetlabs.com/issues/16637#change-84156

Author: Jeff McCune
Status: Closed
Priority: Normal
Assignee: 
Category: settings
Target version: 3.0.0
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 unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/puppet-bugs?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.


Reply via email to