On 05/06/2014 04:56 PM, jcbollinger wrote: > Ah, so you're running the master from an unprivileged user. That > makes a > lot of sense now. > > > > Maybe. It is normal to run the /master/ as an unprivileged user. The > master does not store anything in its home directory in that case, > unless its home directory is set to something like /var/lib/puppet. Or > am I stuck in the past?
More or less. Hence my awkward wording of "running *from* an unprivileged user". Sure, you normally want the master to drop root privileges after initialization, and run as the puppet user. Since Puppet 3 it is surpassingly easy to run independent master processes with webrick, though, by just exclaiming `puppet master` from a terminal, which will (just as the agent) use ~/.puppet as its base of operation/configuration. (Of course, care must be taken if the master port is already in use, but that should be it.) > It is /ab/normal to run the agent as an unprivileged user, because that > prevents the agent from applying most of the kinds of system changes > that Puppet is typically wanted for. It is perhaps more common to run > 'puppet apply' as a normal user, but the same limitations apply. Under > these circumstances, however, it is my understanding that agent or apply > will use $HOME/.puppet. Right. > Again, maybe. If the agents have in the past run successfully as root > (as is more usual), then they will have certificates signed by the > master and living in Puppet's normal system directory. If one then > tries to run the agent on one or more of those machines, however, then > just such a problem as is reported might arise. > > Specifically, when running as an ordinary user, the agent cannot use the > certificate that puppet-as-root uses, because it cannot access the > corresponding private key. Instead, it creates its own key pair, and > issues a certificate request to the master based on that public key. > The master, on the other hand, already has a signed certificate for the > node, which it returns to the agent (this is a feature). That > certificate is indeed not based on the same key pair as the cert > request, so the agent would emit exactly the message described. Very true. Specifically, I have found during last night's debugging session that the $ssldir contents are very prone to fall off balance if they are ever used by an agent that has the wrong permissions. Sadly, bottom line likely remains: If an intact copy of the certs and keys cannot be secured, it will be necessary to certify from scratch. Regards, Felix -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/5368FDF7.5080702%40alumni.tu-berlin.de. For more options, visit https://groups.google.com/d/optout.
