Puppet users - Feb 2012 - file and user permissions on the puppet master, best practice

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.

--
Paul Stivers
Software development operations engineer
Hewlett-Packard

Opinions expressed here are my own, and not those of Hewlett-Packard
company.


-- 
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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

(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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Feb 21, 2012, at 11:46 AM, paulS wrote:
> (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
----
the one thing I have always appreciated about Linux/UNIX is that the config
files are always text files and can be fixed and thus you don''t have to
resort to things like uninstalling/re-installing, deleting/recreating users
because everything is relatively easily fixed - at least assuming that you know
how.

su - puppet # if done by root doesn''t require a password. 
            # Root user doesn''t need a password for anything
            # if done by a user, needs puppet user''s password

/etc/sudoers -  ''puppet ALL=(ALL) NOPASSWD:ALL''
            # Can''t imagine a good reason to do this but will only 
            # allow user ''puppet'' to sudo anything without a
password

if ''su - puppet'' doesn''t give you the bash shell as
user puppet then perhaps you don''t have a good shell set up for user
puppet.
getent passwd | grep puppet   # will list things like the shell 
                              # which should be /bin/bash but if not, use chsh
sudo chsh puppet -s /bin/bash # will set puppet users shell to /bin/bash

It''s also possible that user puppet''s home directory is
wrongly set or the permissions are bad...
# getent passwd | grep puppet
puppet:x:1001:1001:Puppet,,,:/var/lib/puppet:/bin/bash

sudo chown puppet:puppet /var/lib/puppet -R

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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

Nice! Thanks!

sam@puppetmaster:~$ getent passwd | grep puppet  # /bin/false is not
good
puppet:x:108:113:Puppet configuration management daemon,,,:/var/lib/
puppet:/bin/false

sam@puppetmaster:~$ sudo chsh puppet -s /bin/bash

sam@puppetmaster:~$ getent passwd | grep puppet  # that''s better
puppet:x:108:113:Puppet configuration management daemon,,,:/var/lib/
puppet:/bin/bash

sam@puppetmaster-1e:~$ su - puppet  # now I can switch user
Password:
puppet@puppetmaster-1e:~$

--
Paul


On Feb 21, 1:27 pm, Craig White <craig.wh...@ttiltd.com> wrote:
>
> ----
> the one thing I have always appreciated about Linux/UNIX is that the config
files are always text files and can be fixed and thus you don''t have to
resort to things like uninstalling/re-installing, deleting/recreating users
because everything is relatively easily fixed - at least assuming that you know
how.
>
> su - puppet # if done by root doesn''t require a password.
>             # Root user doesn''t need a password for anything
>             # if done by a user, needs puppet user''s password
>
> /etc/sudoers -  ''puppet ALL=(ALL) NOPASSWD:ALL''
>             # Can''t imagine a good reason to do this but will only
>             # allow user ''puppet'' to sudo anything
without a password
>
> if ''su - puppet'' doesn''t give you the bash shell
as user puppet then perhaps you don''t have a good shell set up for user
puppet.
> getent passwd | grep puppet   # will list things like the shell
>                               # which should be /bin/bash but if not, use
chsh
> sudo chsh puppet -s /bin/bash # will set puppet users shell to /bin/bash
>
> It''s also possible that user puppet''s home directory is
wrongly set or the permissions are bad...
> # getent passwd | grep puppet
> puppet:x:1001:1001:Puppet,,,:/var/lib/puppet:/bin/bash
>
> sudo chown puppet:puppet /var/lib/puppet -R
>
> 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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.