[Puppet Users] Re: Prevent users from creating new accounts

On Nov 4, 4:34 am, Patrick <> wrote:
> On Nov 4, 2010, at 12:28 AM, hywl51 wrote:
> > Hi, all
> > I want to control the user accounts on our company servers with
> > puppet. The complete requirements are the following:
> > 1. Assuming that one user run " useradd ...." on the server to create
> > a new account named "newuser".
> > 2. Puppet will konw the new user created soon, and restore the server
> > status to the before. That is, puppet will delete the new user.
> > I am not sure if puppet could fullfill this requirement. Could anyone
> > give me some advices.
> Puppet isn't good at requests phrased that way.  I don't use puppet to say, "make X stay how it currently is".  Instead you say, "Make X be the state I declare."

That's quite right.  However, Puppet supports the state you declare
encompassing exactly a specific set of users, or even exactly a
specific set of users having UIDs greater than a minimum threshold.

PROVIDED THAT you use Puppet to manage all the ordinary user accounts
you _do_ want, you can instruct it that no other non-system accounts
should be present.  Do so by adding this metaresource to your

resources { "user":
   purge => true,
   unless_system_user => 499

The value of the 'unless_system_user' property is the numerically
greatest UID that is considered a "system" user (administrative and
system services accounts), and thus not to be deleted.  499 is the
correct value for the standard setup of RedHat-family Linuxes; for
some other systems it would be 99, or perhaps some other number.  Read
the docs for (a bit) more detail.

I suspect that this will not remove user home directories, but that's
not documented and I have not tested it.

You should be able to do the same for groups, if you wish, but I don't
think there is a built-in concept of system groups parallel to that of
system users.

> You could push out /etc/passwd and /etc/group with Puppet, but you would need to be careful.

Indeed so.

Alternatively, you could perhaps take an altogether different approach
by relying on LDAP or NIS for user authentication.  That would work
best if the same set of users should have access to all the systems
you're managing, or if you can at least categorize the systems into a
small number of sets that each share a common pool of users (each set
would then need its own NIS or LDAP domain).  This assumes that your
local administrative accounts are not empowered to add new users in

As a third alternative, it ought to be possible to address the
underlying problem with judicious configuration of sudo, or, if that's
not sufficient, with SELinux (if you're using Linux).  With these
approaches the objective would be to grant users the ability to
perform the tasks they need to perform, without empowering them to
manage users.


Why hasn't my new node configuration been noticed?


Why hasn't my new node configuration been noticed?

If you're using separate node definition files and import them into site.pp with an import *.node (for example) you'll find that new files added won't get noticed until you restart puppetmasterd. This is due to the fact globs aren't evaluated on each run, but only when the 'parent' file is re-read.

To make sure your new file is actually read, simply 'touch' the site.pp (or importing file) and the glob will be re-evaluated.

Agreeing to the Sun Java License with Debconf Preseeds and Puppet


Stupid Puppet Trick: Agreeing to the Sun Java License with Debconf Preseeds and Puppet

I had a user ask for Java to be installed on the cluster systems, so I started up by making a simple JRE5 module for puppet, but this first one didn’t quite work:

class jre5 {
  package { "sun-java5-jre":
    ensure => latest;

It doesn’t work because Sun wants you to agree to its license before installing the JRE. There’s a couple of ways around this. First, the old-school method:

ssh host "yes | apt-get -y install sun-java5-jre"

where ‘yes’ is a standard Unix program that just prints out “yes” over and over until the program on the other side of the pipe terminates. But “ssh host foo” is not the way of the managed infrastructure.

The second method, much more friendly to centralized management, is to first install debconf-utils on a candidate system, and then install sun-java5-jre on the same system. Once that’s done, you can query the debconf database to see how it stored your answers to the Sun license agreement:

ch226-12:~# debconf-get-selections | grep sun-
sun-java5-bin   shared/accepted-sun-dlj-v1-1    boolean true
sun-java5-jre   shared/accepted-sun-dlj-v1-1    boolean true
sun-java5-jre   sun-java5-jre/jcepolicy note
sun-java5-jre   sun-java5-jre/stopthread        boolean true
sun-java5-bin   shared/error-sun-dlj-v1-1       error
sun-java5-jre   shared/error-sun-dlj-v1-1       error
sun-java5-bin   shared/present-sun-dlj-v1-1     note
sun-java5-jre   shared/present-sun-dlj-v1-1     note

Save those results (debconf seeds) into a file on the gold server. Then we can modify our jre5 class as follows:

class jre5 {
  package { "sun-java5-jre":
    require      => File["/var/cache/debconf/jre5.seeds"],
    responsefile => "/var/cache/debconf/jre5.seeds",
    ensure       => latest;

  file { "/var/cache/debconf/jre5.seeds":
    source => "puppet:///jre5/jre5.seeds",
    ensure => present;

Now our class will download the preseeded answers for the Java license, download and install the JRE, and then use the preseeded answers to skip past the license agreement. I had never messed with debconf seeding previously, since I had either just imaged my systems, or provided config files that would be used when I restarted any daemons or programs that depended on those files. Now debconf-utils is part of my standard system class definition.

Note that this method doesn’t work with the default puppet provided in Debian Etch (version 0.20) — the responsefile parameter for Debian packages was only added in puppet 0.22.

MacPorts Binary Packages


Binary packages are standalone binary installers that are precompiled; they do not require MacPorts on the target system. Binary files created with MacPorts may be either .pkg (Mac OS X Installer Packages), or RPM (RPM Package Manager) format. MacPorts may also process a .pkg package into a Mac OS X .dmg disk image file. You may create binary packages with the port command as shown in these examples.

%% port pkg pstree

You may create a Mac OS X .dmg disk image file as shown.

%% port dmg pstree

You may compile a port into an RPM file as shown, in order to install it onto a target that has RPM utilities or a full package management system that can install RPMs.

%% port rpm pstree

All packages are placed in a port's work directory.

Installing on OS X server 10.4.11 - Puppet Users | Google Groups

Hi Dan,

I am an absolute beginner at Puppet, but I do have it running under
10.5 and am using it for package management of our Mac laptops and
desktops. I haven't used puppet on 10.4 though.

I use Nigel Kerstens packages from and have had no
trouble with them.

You don't have to make users on the mac because puppet only runs as
root, I believe due to a limitation in how macosx works.

My rough notes on getting started are:

1) Install Puppet and Factor packages from Nigel's site

2) create /etc/puppet/puppet.conf with the following content

        user = 0
        group = 0
        server =
        certname = puppet.
        autosign = false

        evaltrace = true
        factsync = true

3) create /etc/puppet/fileserver.conf

  path /etc/puppet/dist/facts
  allow *

  path /etc/puppet/dist/files
  allow *

4) mkdir /etc/puppet/dist/facts

5) mkdir /etc/puppet/dist/files

6) create /etc/puppet/manifests/site.pp  (can be empty to start with)

7) sudo puppetmasterd --no-daemonize --verbose

That should get your puppetmasterd running.

I use the Launchd script from to keep
it running.

I hope that helps,


Debian package upgrade automation with Puppet



We got a lot of Debian servers and it's impractical to issue an 'apt-get dist-upgrade' on all of them separately. Also, we do not want unsupervised upgrades, since that could mess stuff up. We want to test before telling all the machines to upgrade.


We create a file on our puppetmaster. Where it resides or what the content is, doesn't matter. Let's call the file 'update_initiator'. Now we add the following recipe to the manifest we use for each server:

file { "/etc/update_initiator":
  source => "puppet://puppet/config/update_initiator",

exec { "/usr/bin/apt-get -y dist-upgrade":
  refreshonly => true,
  subscribe => File["/etc/update_initiator"],

Et voila, when we've tested all the available upgrades on our test server, we simply change the content of 'update-initiator' on the puppetmaster, the file registers as changed and the machines will initiate the dist-upgrade. This of course requires you to run a "apt-get update" once in a while on all the servers (we use cron-apt for that). A good way to change the file is to have the date of the last upgrade in there. That way it's a reference point.