puppet agent 4.0 running as root vs puppet server 2.0 running as puppet

Johnson Earls

unread,

May 6, 2015, 1:40:00 AM5/6/15

to puppet...@googlegroups.com

I'm running into a frustrating issue, and I'm wondering if I'm just not doing something right.

My understanding is that the puppet agent has to run with the config "user" and "group" set to "root" so that it can make changes to the system.

The puppet server, on the other hand, runs as user and group "puppet".

However, every time the puppet agent activates, it changes the ownership of most of the subdirectories and files within the /etc/puppetlabs/puppet/ssl directory to root, which then prevents the puppet server from either starting up or being able to sign certificates.

Am I misunderstanding how these two processes work and interact?

Should the puppet agent run with the config user/group set to "puppet", even though puppet won't have permission to make most of the changes on the system?

Or should the puppet server run as root?

Johnson Earls

unread,

May 6, 2015, 10:29:39 AM5/6/15

to puppet...@googlegroups.com

never mind. puppet agent ignores the user/group config settings, so those should be kept at puppet, and ${::settings::user} / ${::settings::group} should not be used to configure agent-related options (such as file ownership).

Josh Cooper

unread,

May 7, 2015, 1:32:59 AM5/7/15

to puppet...@googlegroups.com

On Wed, May 6, 2015 at 7:29 AM, Johnson Earls <darkfo...@gmail.com> wrote:

never mind. puppet agent ignores the user/group config settings, so those should be kept at puppet, and ${::settings::user} / ${::settings::group} should not be used to configure agent-related options (such as file ownership).

The `puppet` user and group are really server-side settings, to specify a less privileged account to run the webrick/passenger/puppetserver process as.

To confuse things, `puppet` packages (rpm/deb) have always created the `puppet` user and group, but was unnecessary on the agent. In Puppet 4, we have fixed this, so the puppet-agent package does not create a `puppet` user or group. Only the puppetserver package does that.

On Tuesday, May 5, 2015 at 10:40:00 PM UTC-7, Johnson Earls wrote:
I'm running into a frustrating issue, and I'm wondering if I'm just not doing something right.

My understanding is that the puppet agent has to run with the config "user" and "group" set to "root" so that it can make changes to the system.
The puppet server, on the other hand, runs as user and group "puppet".

However, every time the puppet agent activates, it changes the ownership of most of the subdirectories and files within the /etc/puppetlabs/puppet/ssl directory to root, which then prevents the puppet server from either starting up or being able to sign certificates.

In Puppet 4, you can get into this state if you install puppet-agent, and run it at least once. Since the `puppet` user won't exist, the agent will set permissions to `root:root:750` for file/directory-related settings like `privatekeydir`.

If you then install puppetserver, it will create the `puppet` user, start the server as that user, and fail to start, because the puppet user can't read `privatekeydir`, etc. However, as soon as you run `puppet agent` (or `apply`) on the master, it will restore the permissions to `puppet:puppet` and the puppetserver will start successfully.

Am I misunderstanding how these two processes work and interact?

Should the puppet agent run with the config user/group set to "puppet", even though puppet won't have permission to make most of the changes on the system?
Or should the puppet server run as root?

--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/3955db48-4062-460c-a8a4-0df405277afb%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Josh Cooper

Developer, Puppet Labs

PuppetConf 2015 is coming to Portland, Oregon! Join us October 5-9.

Register now to take advantage of the Early Adopter discount —save $349!

jcbollinger

unread,

May 7, 2015, 9:19:50 AM5/7/15

to puppet...@googlegroups.com

On Thursday, May 7, 2015 at 12:32:59 AM UTC-5, Josh Cooper wrote:

On Wed, May 6, 2015 at 7:29 AM, Johnson Earls <darkfo...@gmail.com> wrote:
never mind. puppet agent ignores the user/group config settings, so those should be kept at puppet, and ${::settings::user} / ${::settings::group} should not be used to configure agent-related options (such as file ownership).

The `puppet` user and group are really server-side settings, to specify a less privileged account to run the webrick/passenger/puppetserver process as.

Right.

To confuse things, `puppet` packages (rpm/deb) have always created the `puppet` user and group, but was unnecessary on the agent. In Puppet 4, we have fixed this, so the puppet-agent package does not create a `puppet` user or group. Only the puppetserver package does that.

So the new package naming confuses even PL itself?

I mean, in our recent discussion of the new package naming and versioning, Eric and Michael asserted that the "puppet-agent" package is the basic Puppet infrastructure package, with which one can run the agent, the traditional rack-based master, and everything else from Puppet's Ruby stack. They claim the "puppetserver" package is optional. I completely believe that's the intention, but in that case the "puppet-agent" package should be the one responsible for the "puppet" user and group.

John

jcf

unread,

May 7, 2015, 2:23:33 PM5/7/15

to puppet...@googlegroups.com

On May 6, 2015, at 22:32, Josh Cooper <jo...@puppetlabs.com> wrote:

On Wed, May 6, 2015 at 7:29 AM, Johnson Earls <darkfo...@gmail.com> wrote:
never mind. puppet agent ignores the user/group config settings, so those should be kept at puppet, and ${::settings::user} / ${::settings::group} should not be used to configure agent-related options (such as file ownership).

The `puppet` user and group are really server-side settings, to specify a less privileged account to run the webrick/passenger/puppetserver process as.

So, maybe there should be a test to see if the user even exists before mass-chown’ing directories?

To confuse things, `puppet` packages (rpm/deb) have always created the `puppet` user and group, but was unnecessary on the agent. In Puppet 4, we have fixed this, so the puppet-agent package does not create a `puppet` user or group. Only the puppetserver package does that.

So there is at least a dependency/ordering problem, at most an unchecked firehose turned on to change permissions, and this should be considered a bug. Also, this is playing pretty fast and loose with idempotence if this can’t be configured around.

On Tuesday, May 5, 2015 at 10:40:00 PM UTC-7, Johnson Earls wrote:
I'm running into a frustrating issue, and I'm wondering if I'm just not doing something right.

My understanding is that the puppet agent has to run with the config "user" and "group" set to "root" so that it can make changes to the system.
The puppet server, on the other hand, runs as user and group "puppet".

However, every time the puppet agent activates, it changes the ownership of most of the subdirectories and files within the /etc/puppetlabs/puppet/ssl directory to root, which then prevents the puppet server from either starting up or being able to sign certificates.

In Puppet 4, you can get into this state if you install puppet-agent, and run it at least once. Since the `puppet` user won't exist, the agent will set permissions to `root:root:750` for file/directory-related settings like `privatekeydir`.

Ouch. This violates the “principle of least surprise” at least two different ways.

If you then install puppetserver, it will create the `puppet` user, start the server as that user, and fail to start, because the puppet user can't read `privatekeydir`, etc. However, as soon as you run `puppet agent` (or `apply`) on the master, it will restore the permissions to `puppet:puppet` and the puppetserver will start successfully.

So, if I started the components in the wrong order once, it now takes an extra run to sort everything out, and doesn’t log it well enough to be deciphered? Double-ouch.

Am I misunderstanding how these two processes work and interact?

Should the puppet agent run with the config user/group set to "puppet", even though puppet won't have permission to make most of the changes on the system?
Or should the puppet server run as root?

--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/3955db48-4062-460c-a8a4-0df405277afb%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
Josh Cooper
Developer, Puppet Labs

PuppetConf 2015 is coming to Portland, Oregon! Join us October 5-9.
Register now to take advantage of the Early Adopter discount —save $349!

--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/CA%2Bu97unqBLmMMfqE%2BJQ_R8MguFntxD%3DHxynM0uuY-O9py-s%2B4Q%40mail.gmail.com.

Josh Cooper

unread,

May 7, 2015, 2:58:02 PM5/7/15

to puppet...@googlegroups.com

We will be releasing updated passenger packages compatible with puppet-agent "soon"[1]. These packages also create the `puppet` user and group, like puppetserver.

That leaves webrick. I agree, there is currently an inconsistency -- webrick functionality is provided by the puppet-agent package, but the package does not create the `puppet` user and group. However, you are free to create the accounts (using `puppet apply` even!), or specify an alternate account using Puppet's `user` and `group` settings.

That said, webrick is deprecated and will be removed in Puppet 5[2].

Josh

[1] https://tickets.puppetlabs.com/browse/PUP-4452

[2] https://groups.google.com/d/topic/puppet-dev/RHa2tMPRTx4/discussion

Josh Cooper

unread,

May 7, 2015, 3:06:53 PM5/7/15

to puppet...@googlegroups.com

On Thu, May 7, 2015 at 11:23 AM, jcf <joshua....@gmail.com> wrote:

On May 6, 2015, at 22:32, Josh Cooper <jo...@puppetlabs.com> wrote:

On Wed, May 6, 2015 at 7:29 AM, Johnson Earls <darkfo...@gmail.com> wrote:
never mind. puppet agent ignores the user/group config settings, so those should be kept at puppet, and ${::settings::user} / ${::settings::group} should not be used to configure agent-related options (such as file ownership).

The `puppet` user and group are really server-side settings, to specify a less privileged account to run the webrick/passenger/puppetserver process as.

So, maybe there should be a test to see if the user even exists before mass-chown’ing directories?

The file and directories I'm talking about are internal to puppet, e.g. ssldir. When managing them, puppet already takes into account whether the `puppet` user exists or not.

To confuse things, `puppet` packages (rpm/deb) have always created the `puppet` user and group, but was unnecessary on the agent. In Puppet 4, we have fixed this, so the puppet-agent package does not create a `puppet` user or group. Only the puppetserver package does that.

So there is at least a dependency/ordering problem, at most an unchecked firehose turned on to change permissions, and this should be considered a bug. Also, this is playing pretty fast and loose with idempotence if this can’t be configured around.

The behavior of how puppet manages its internal files has not changed for a long, long time. The only part that is different is which package creates the `puppet` user and group.

What's the specific issue you're concerned about?

On Tuesday, May 5, 2015 at 10:40:00 PM UTC-7, Johnson Earls wrote:
I'm running into a frustrating issue, and I'm wondering if I'm just not doing something right.

My understanding is that the puppet agent has to run with the config "user" and "group" set to "root" so that it can make changes to the system.
The puppet server, on the other hand, runs as user and group "puppet".

However, every time the puppet agent activates, it changes the ownership of most of the subdirectories and files within the /etc/puppetlabs/puppet/ssl directory to root, which then prevents the puppet server from either starting up or being able to sign certificates.

In Puppet 4, you can get into this state if you install puppet-agent, and run it at least once. Since the `puppet` user won't exist, the agent will set permissions to `root:root:750` for file/directory-related settings like `privatekeydir`.

Ouch. This violates the “principle of least surprise” at least two different ways.

If the `puppet` user doesn't exist, we use secure defaults.

If you then install puppetserver, it will create the `puppet` user, start the server as that user, and fail to start, because the puppet user can't read `privatekeydir`, etc. However, as soon as you run `puppet agent` (or `apply`) on the master, it will restore the permissions to `puppet:puppet` and the puppetserver will start successfully.

So, if I started the components in the wrong order once, it now takes an extra run to sort everything out, and doesn’t log it well enough to be deciphered? Double-ouch.

In practice this happens rarely. Usually you install puppetserver, which brings in puppet-agent as a dependency.

But if you do run into this issue, I recommend filing a ticket and even submitting a PR to update the puppetserver install logic.

Am I misunderstanding how these two processes work and interact?

Should the puppet agent run with the config user/group set to "puppet", even though puppet won't have permission to make most of the changes on the system?
Or should the puppet server run as root?

--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/3955db48-4062-460c-a8a4-0df405277afb%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
Josh Cooper
Developer, Puppet Labs

PuppetConf 2015 is coming to Portland, Oregon! Join us October 5-9.
Register now to take advantage of the Early Adopter discount —save $349!

--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/CA%2Bu97unqBLmMMfqE%2BJQ_R8MguFntxD%3DHxynM0uuY-O9py-s%2B4Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/015ABFFD-CD73-4F7A-9813-23B1F2217C20%40gmail.com.

For more options, visit https://groups.google.com/d/optout.

Johnson Earls

unread,

May 7, 2015, 9:32:27 PM5/7/15

to puppet...@googlegroups.com

All of my systems get the puppet-agent package installed and enabled as part of kickstart. The puppetserver package only later gets installed for servers that will be puppet servers. Is this ordering really that unexpected?

On Thursday, May 7, 2015 at 12:06:53 PM UTC-7, Josh Cooper wrote:

In practice this happens rarely. Usually you install puppetserver, which brings in puppet-agent as a dependency.

--
Josh Cooper
Developer, Puppet Labs

PuppetConf 2015 is coming to Portland, Oregon! Join us October 5-9.
Register now to take advantage of the Early Adopter discount —save $349!

- Johnson

Josh Cooper

unread,

May 7, 2015, 10:20:28 PM5/7/15

to puppet...@googlegroups.com

On Thursday, May 7, 2015, Johnson Earls <darkfo...@gmail.com> wrote:

All of my systems get the puppet-agent package installed and enabled as part of kickstart. The puppetserver package only later gets installed for servers that will be puppet servers. Is this ordering really that unexpected?

That sounds like a great reason to open a ticket.

On Thursday, May 7, 2015 at 12:06:53 PM UTC-7, Josh Cooper wrote:
In practice this happens rarely. Usually you install puppetserver, which brings in puppet-agent as a dependency.
--
Josh Cooper
Developer, Puppet Labs

PuppetConf 2015 is coming to Portland, Oregon! Join us October 5-9.
Register now to take advantage of the Early Adopter discount —save $349!

- Johnson

--

You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/c7c9d0c4-6ac2-4b65-8ca8-3bad470c69e2%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

Reply all

Reply to author

Forward