On Feb 21, 2012, at 2:52 AM, paulS wrote: > Hi all. New puppet developer. Very excited. I have the agents > communicating with the puppet master. > > I'm wondering now about best practice for file and user permissions on > the puppet master. Most of my wonder probably stems from general lack > of understanding in this area. I'd like to get it right though to > avoid refactoring later. > > 1. What's the best practice, or your practice, for directory and file > permissions on the puppet master? > > 2. What's the best practice, or your practice, for users and their > permissions on the puppet master? > > Feel free to point me to posts, articles, or chapters in books. I > haven't found much so far on this topic; just that the agent should > be run as root so that it has permission to make any changes, and the > puppetmaster can be run as non root. > > Thanks for any discussion here. > > Here's my setup so far. > > ============================= > server OS and puppet versions > ============================= > > Ubuntu 10.04.3 LTS (Lucid) on puppet master and clients/agents > > puppet-master$ dpkg -l | grep puppet > ii facter 1.6.4-1puppetlabs1 Ruby module for > collecting simple facts abou > ii puppet 2.7.9-1puppetlabs1 Centralized > configuration management - agent > ii puppet-common 2.7.9-1puppetlabs1 Centralized > configuration management > ii puppetmaster 2.7.9-1puppetlabs1 Centralized > configuration management - maste > ii puppetmaster-common 2.7.9-1puppetlabs1 Puppet master > common scripts > > puppet-agent$ dpkg -l | grep puppet > ii facter 1.6.4-1puppetlabs1 Ruby module for > collecting simple facts abou > ii puppet 2.7.9-1puppetlabs1 Centralized > configuration management - agent > ii puppet-common 2.7.9-1puppetlabs1 Centralized > configuration management > > =================================================== > directory and file permissions on the puppet master > =================================================== > > puppet.conf shows default 'moduledir = /etc/puppet/modules:/var/lib/ > puppet/modules:/opt/modules' > > These directories are normally root:root so I've been making all > sudirectories and files for puppet manifests, modules, and files as > root:root. > > ===================== > users and permissions > ===================== > > puppet user > > upon install I have a puppet user. > > grep puppet /etc/group > puppet:x:113: > > grep puppet /etc/passwd > puppet:x:108:113:Puppet configuration management daemon,,,:/var/lib/ > puppet:/bin/false > > grep puppet /etc/group > puppet:x:113: > > 'sudo -s su puppet' does not switch the user to puppet, so I haven't > been doing anything as puppet. > > other users > > puppetadmin to store just a couple things in /home/puppetadmin that > don't belong in any one employees account. puppetadmin is a member of > its own group and of the admin group > > Individual user acccounts for a few ops engineer who will need access > to make changes to configuration files in /etc/puppet/files and /opt/ > stacks/<configuration files>. These users are members of their own > group and of the admin group. They generally switch user to root to > work on the puppet files since the files are root:root. ---- I think that the ownership of the files relates more to the services that use these files and you don't really say if you are still using webrick, apache, nginx to serve these files as that may have some impact.
I myself have all the files and folders owned by puppet:puppet (/etc/puppet, /var/lib/puppet, /var/www/foreman, /var/www/puppet-dashboard) and use nginx to serve forman, puppet & puppet-dashboard. I think if you want to change to user puppet, you probably only need to 'su - puppet' but if /var/lib/puppet isn't owned by puppet:puppet then switching to user puppet is probably going to be difficult. Also, it seems that if you have multiple users doing configuration, you probably should have multiple environments (ie, development & testing and not just a production) and also a version control system (git or subversion) and perhaps a separate puppet server for development & testing to avoid inflicting errors into running configurations. I found the book "Pro Puppet" very useful for defining the all of these best practices. Craig -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
