Puppet
I’ve started reading Puppet 4 Essentials. I’m trying to set this up on Fedora 24, it seems
like the authors both used wheezy, and installed puppetlabs packages. The path of least
resistance should have been for me to use dnf install puppetserver
or the like, and I
did get the master instance in place. Fedora’s charming default firewall might be making
this unpleasant on my end, I’ll need to hammer through this. So Fedora specific notes.
- Fedora team seems to have abandoned use (not support) of puppet, see Fedora Project Infrastructure
- The instructions from puppet.com strongly suggest using their yum repo via rpm
Fedora Infrastructure notes point out these directories and files:
Puppet Master (server):
- /etc/puppet - Basic puppet configuration information
- /etc/puppet/manifests - node config mappings
- /etc/puppet/manifests/filetypes/* - Various filetype definitions
- /etc/puppet/manifests/nodes/* - Server lists and what classes[1] they use
- /etc/puppet/manifests/server-groups - Maps services with a server type
- /etc/puppet/manifests/service-types - Contains each service and whats required for that service
- /etc/puppet/manifests/site.pp - Contains the ‘root’ config file which includes other config files
- /var/lib/puppet/ - Puppet files
- /var/lib/puppet/config - Config files for our actual nodes (eg httpd.conf)
- /etc/lib/puppet/bucket - Backup of overwritten config files
Puppet client
- /etc/puppet - Basic configuration information
- /etc/sysconfig/puppet - Puppet startup definitions
Additionally, while I’m able to run the server directly, the bundled systemd file gives a permissions error on /usr/bin/puppet, and I’m suspecting the service is set to set the uid to puppet or similar (a service account that is not root).
start-puppet-master[8594]: /usr/bin/start-puppet-master: line 8: /usr/bin/puppet: Permission denied
Root can run the program directly without any error:
/usr/bin/start-puppet-master master
It does not look as though there should be any permissions issue:
# stat /usr/bin/puppet
File: '/usr/bin/puppet'
Size: 161 Blocks: 8 IO Block: 4096 regular file
Device: fd00h/64768d Inode: 238333 Links: 1
Access: (0755/-rwxr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root)
Context: system_u:object_r:puppetagent_exec_t:s0
Access: 2016-10-08 12:18:36.459333618 -0500
Modify: 2016-02-04 19:29:39.000000000 -0600
Change: 2016-10-02 17:23:49.337433436 -0500
Birth: -
However, all of the puppet config files and directories are set root owned. That might include a logging directory, in which case running as root once might break the non-privileged user forever until that’s fixed. It’s just disheartening that this doesn’t work out of the box. I might test in jessie later today to get a second opinion.
Help from the internet
I got an email from someone (Nick Maludy) who stumbled on my page here. It looks like he worked out a solution to the same issue, and that the start-puppet-master script appears to have been the culprit. Here’s what he wrote
I actually just figured this out….
/usr/lib/systemd/system/puppetmaster.service by default looks like:
[Unit]
Description=Puppet master
Wants=basic.target
After=basic.target network.target
[Service]
EnvironmentFile=-/etc/sysconfig/puppetmaster
ExecStart=/usr/bin/start-puppet-master master ${PUPPETMASTER_EXTRA_OPTS} --no-daemonize
[Install]
WantedBy=multi-user.target
I installed puppet directly from puppet labs: https://docs.puppet.com/puppet/latest/puppet_collections.html#yum-based-systems
And the same service file looks like:
[Unit]
Description=Puppet master
Wants=basic.target
After=basic.target network.target
[Service]
EnvironmentFile=-/etc/sysconfig/puppetmaster
ExecStart=/usr/bin/puppet master ${PUPPETMASTER_EXTRA_OPTS} --no-daemonize
[Install]
WantedBy=multi-user.target
I removed the puppet labs version and re-installed the one from EPEL, the modified the service file to use /usr/bin/puppet instead of /usr/bin/start-puppet-master
This solved my issue:
● puppetmaster.service - Puppet master
Loaded: loaded (/usr/lib/systemd/system/puppetmaster.service; disabled; vendor preset: disabled)
Active: active (running) since Fri 2016-12-23 23:22:54 EST; 1s ago
Main PID: 10696 (puppet)
CGroup: /system.slice/puppetmaster.service
└─10696 /usr/bin/ruby /usr/bin/puppet master --no-daemonize
Dec 23 23:22:54 puppetmaster.maludy.home systemd[1]: Started Puppet master.
Dec 23 23:22:54 puppetmaster.maludy.home systemd[1]: Starting Puppet master...
Dec 23 23:22:55 puppetmaster.maludy.home puppet-master[10696]: Starting Puppet master version 3.6.2