Notes on Puppet

Point Zero: Vital Concepts

  • Puppet is based upon certificates. If you don't trust the certificate from your client, it's never going to work. And Puppet is going to just about flat-out demand that you name the puppet master server 'puppet', so just make it easy on yourself and create that cname until you get more advanced.
  • Puppet runs as root, and can do all kinds of administrative duties. However, puppetmaster (which controls all the clients) does not. So if you have files which the 'puppet' user can't access, it will not be able to serve them to the clients.
  • It would appear that there is no need to replicate configuration files out to the clients, unlike in a cfengine installation.
  • The puppet community has major objections to having anything like the 'editfiles' directive in cfengine. I think there's a 'search and replace' type functionality, but the more powerful editfile feature is generally deemed to be a "there be dragons here" feature akin to 'goto' in BASIC.
  • On the master server, this is your friend if you're muddling about with trying to find pending CA requests to approve: the puppetca command. If you're lazy, just puppetca --list and puppetca sign --all if you don't see anything scary in there.

Initial Gripes

Puppet insists on using COLOR in its debugging output. The colors chosen are all light, which means they are flat-out illegible on a terminal with a white background. Which happens to be MOST TERMINALS nowadays.

Notes for CFengine folks

Looks like there's no need tor replicate your manifests directory out to the clients. It appears to handle this remotely.

Gotchas for getting things to work

It seems that if you don't have hosts listed in /etc/puppet/fileserver.conf, you'll get errors claiming that you can't do a find on the files, or the catalog won't transfer, etc.

Somewhat similar is the fact that puppetmaster runs as the user 'puppet', not as root - but the puppet process on the clients runs as root. This leads to strange situations where if the 'puppet' user can't read a file, it will not have the ability to serve it. However, if the file is only owned by root, but is still readable to the puppet user, the file will replicate out just fine. This means that if you DO have a desire for root-only permissions, you won't be able to put it within a recursively managed directory. You'll actually have to set the permissions looser on the master server so that it can actually read it, and make specific instructions in the puppet manifest to dictate which permissions the file should be set for on the client side. There's probably a way around this by just having puppetmaster run as root, but I imagine that's not a preferred security practice.

-- SeanNewton - 10 Apr 2011

Edit | Attach | Watch | Print version | History: r3 < r2 < r1 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r3 - 2016-02-12 - SeanNewton
 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 2008-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback