(By the way, I should have referred to myself as a new Puppet _user_.
I certainly didn't mean to imply that I'm a developer of Puppet open
source software. I'm obviously not up to that challenge.)
Thanks a lot, Craig.
I'm using Webrick now, and will move to Apache before release to
production. I did see the chapter 4 in Pro Puppet, Turnbull, on making
the puppet master scalable. I also have "Pulling strings with Puppet,"
Turbull, and have ordered "Puppet 2.7 Cookbook," Arundel.
It sounds like you're suggesting a good practice is for users to su to
the puppet user and do their work as puppet. That's what I've read and
that's why it's bugging me that I can't seem to switch to the puppet
user.
I'll be the primary developer of modules, manifests, etc, with a
backup person. Also a few other ops people would make changes to
configuration files that get served out as updates to the clients.
I get the part about separate environments and puppet masters for dev
and test. Thanks for that. I need to read and understand about
environments.
As I mentioned, I'm having trouble switching to the puppet user. Maybe
this is an Ubuntu sys admin question, but it pertains specifically to
the puppet user. The user is set up during install. I installed from
the following debians:
facter_1.6.4-1puppetlabs1_all.deb
puppet_2.7.9-1puppetlabs1_all.deb
puppet-common_2.7.9-1puppetlabs1_all.deb
puppet-dashboard_1.2.4-1puppetlabs1_all.deb
puppetmaster_2.7.9-1puppetlabs1_all.deb
puppetmaster-common_2.7.9-1puppetlabs1_all.deb
# sam (not the real user name) has admin rights.
# the password required here isn't the one for sam and I don't have a
password for puppet since it was set up during install.
sam@puppetmaster:~$ su - puppet
Password:
adding 'puppet ALL=(ALL) NOPASSWD:ALL' to the sudoers file didn't
help. 'su - puppet' still wants a password.
sudo password puppet # lets me create a password for puppet
The command line now accepts 'su - puppet' with the password for
puppet, but the prompt still says 'sam@puppetmaster:~$' and puppet
won't create a subdirectory from a directory owned by puppet:puppet.
Also I still have admin rights form the command line. I don't think
switch user to puppet is actually occurring.
The command line accepts 'sudo su - puppet' without a password, but
same behavior as immediately above.
I could blow away the puppet user and re-create it as a member of
puppet group and not of admin. Does that seem like a good idea? I'm
curious about the nature of the puppet user that's created during
install, and whether I'm losing anything important if I blow it away
and recreate with:
sudo useradd puppet --create-home --user-group --shell /bin/bash
Thanks for any help,
Paul
On Feb 21, 7:19 am, Craig White <craig.wh...@ttiltd.com> wrote:
> 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.
