[PUP-4073] rundir and logdir are no longer relative to vardir Created: 2015/03/03  Updated: 2016/10/19  Resolved: 2015/03/03

Status: Closed
Project: Puppet
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Normal
Reporter: Nate Wolfe Assignee: Unassigned
Resolution: Won't Fix Votes: 0
Labels: AIO
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
relates to PUP-3632 Update paths and defaults for the uni... Closed
relates to SERVER-409 Plumb confdir, vardir, codedir, logdi... Closed
relates to SERVER-410 Explicitly override always_cache_feat... Closed
relates to PUP-4074 Remove master settings from puppet.conf Closed
relates to SERVER-403 Fix clojure unit tests in preparation... Closed
Story Points: 0
Sprint: Client 2015-03-04


There are several directories that are rooted under a parent directory, such as the $rundir and $logdir being under $vardir. If you do not rely on the default location of $vardir and specify it explicitly, the children directories do not move with it.

For example:

$ puppet master --configprint vardir
$ puppet master --configprint rundir
$ puppet master --configprint rundir --vardir=/tmp

I would expect the output to be:

$ puppet master --configprint rundir --vardir=/tmp

Note that this behavior might be different between root and non-root. This ticket is concerned with the non-root case, which is what is used by Puppet Server when loading the Puppet ruby code into JRuby.

I believe that in the early days of AIO this behavior was supported, but the implementation introduced some sort of cyclical dependency between various classes/modules (specifically the run_mode.rb and defaults.rb if I remember correctly), so this was undone.

Comment by Josh Cooper [ 2015/03/03 ]

The trouble is that logdir and rundir are only rooted under vardir when running as non-root, but not when running as root. Adding logic to in the non-root case to peek at Puppet[:vardir] while puppet is bootstrapping itself is super tricky, e.g. I don't know that there are guarantees that Puppet[:vardir] has been set to /tmp by the time that we try to resolve logdir. I'd recommend explicitly setting --logdir and --rundir.

Comment by Jeff McCune [ 2015/03/03 ]

We did a bisect and traced this down to PUP-3632 and commit https://github.com/puppetlabs/puppet/commit/2298179df857cf68e3ba509839a153eb58f5f461

The consensus on the puppet-server side of the bridge is that we think logdir and rundir should continue to have default values relative to vardir, not fully qualified default values as they currently do. Our reasoning is that these are end user settings, and ones that puppet-server utilizes, so making them absolute paths pushes the burden to line everything up onto the end user. Alternatively, we think the behavior of allowing the end user, or puppet-server in this case, to specify vardir alone and have rundir and logdir move as well should be preserved.


Comment by Jeff McCune [ 2015/03/03 ]

Thanks Josh Cooper.

Chris Price, what do you think? It appears that it would be more costly to resolve this in the puppet side and instead we should solve it in puppet-server, matching up logdir and rundir both in production and in our unit tests rather than relying on them following vardir.

Comment by Chris Price [ 2015/03/03 ]

OMG, run_mode.

Josh Cooper Jeff McCune I looked at the commit and I understand the issue now, and I guess I'm OK with the proposed path for now, but it's disconcerting.

Basically, the problem we have today is that the implementation of 'run_mode' is tightly coupled with the user account, and that's just totally, totally backwards for Puppet Server... because we will never be running as root, but we always want the root-user version of the paths.

If we stick with the current direction of things, it will mean that we need to duplicate every run_mode-related setting in puppetserver.conf, and pass them all in to the ruby code when we boot up. Before, that list was limited to one or two settings (confdir/vardir), and now it looks like we're talking about increasing that to 4. The user will have to potentially be aware of this and may need to modify these settings in two places. We are also at risk of the 'puppet master --configprint' command line tool returning invalid results for these settings.

I've suffered through the pain associated with that part of the code base enough to know how tricky it is to deal with, so if this is the path of least resistance and everyone thinks it's the only timely way to get things finished up, I won't argue too much. But it feels pretty ugly and risky.

I wonder if there's some other way that we could handle this such that the decision about the run_mode (during early boot up of the process) wouldn't be so tightly coupled to the UID of the process? Like, what if we tweaked things so that the only two args that Puppet Server passed into the ruby code were '--confdir' and some new flag like '--run-mode'. Then we could tweak Puppet so that in the spot where it determines the default run mode, it'd notice that cli flag and override the normal behavior? Skip the user check and put us into 'master' run_mode right away? This would be an improvement on the current releases in that we wouldn't even need to pass '--vardir' any longer, in addition to avoiding the need to add '--logdir' and '--rundir' on top of everything else.

It'd also allow us to get rid of some hacky code in Puppet Server where we have to force the run mode to 'master' after the settings have already all been loaded with 'agent/user' run_mode, as it works today.


Comment by Jeremy Barlow [ 2015/03/03 ]

+1 to coming up with some alternative means of instructing core Ruby Puppet code to use the root-compatible paths when running under Puppet Server instead of perpetuating the duplicated settings across puppetserver.conf and puppet.conf. Would be great, in the process, to eliminate the need for Puppet Server `master-var-dir` configuration .

Could this come down to somehow changing the logic in run_mode.rb's which_dir - https://github.com/puppetlabs/puppet/blob/e155144211688f883dd770f07b676311e9b421c1/lib/puppet/util/run_mode.rb#L52 - to force the root settings to be used even if Puppet.features.root? is false, maybe through reading back on some flag that only Puppet Server would set. I presume we don't want to have Puppet Server somehow configure `Puppet.feature.root?` to true because of other runtime uses of that feature flag that Puppet Server running under the "puppet" user would violate.

Comment by Past Haus [ 2015/03/03 ]

Jeremy Barlow I had a similar thought not too long ago. If which_dir had 3 cases instead of 2, it could meet puppetserver's needs. The 3 cases I can think of are:

running as root
running as puppet user in master runmode
(everything else) running as non-root user

Never mind. run_mode is terrible.

Comment by Josh Cooper [ 2015/03/03 ]

After discussing, we've decided to not modify puppet to detect if it's running inside of puppetserver, and I'm closing this ticket.

Instead puppetserver (and passenger's config.ru) will need to specify the logdir and rundir since they start as puppet but need to use the root related paths. Webrick does not have this issue because it starts as root, loads settings, and then drops privileges to puppet.

We will also remove the master section from the puppet.conf that the puppet-agent packages installs.

Generated at Sat Sep 26 15:50:07 PDT 2020 using Jira 8.5.2#805002-sha1:a66f9354b9e12ac788984e5d84669c903a370049.