Answer the meta question of how do you make this work, If you're using Passenger to run your Puppet master, which you should if you've a system of any size, there is a simple workaround to the madness that is the puppetlabs module. You simply drop a new file called /etc/puppet/puppetmaster.conf and maybe some other bits of config in a new module called puppetmaster and also add this line to the config.ru
ARGV << "--config=/etc/puppet/puppetmaster.conf"
You can use some of the logic inside the puppetlabs module, but it might be simpler to just push a file or less complex template if you don't care about having every single bit of config as a parameter. Then include puppetmaster on the nodes that are masters and you're set. You can also modify the existing puppetlabs to do the above.
Addressing the original question, Hiera might be the simplest solution. Use this in the init.pp
$master = hiera('puppet_master','false'),
and then set puppet_master: true for the machines that need it. Personally my preference is for the first method.
You can name your classes as you want, but you need to use the right name for resources. In this case, the resource you want to use is user
.
There is a very simple way to know how a resource should look:
$ puppet resource user dawud
user { 'dawud':
ensure => 'present',
comment => 'David Sastre Medina,,,',
gid => '1001',
groups => ['sudo', 'audio', 'src', 'video', 'libvirt'],
home => '/home/dawud',
shell => '/bin/bash',
uid => '1001',
}
That code, inside a class would look:
class foo {
user { 'dawud':
ensure => 'present',
comment => 'David Sastre Medina,,,',
gid => '1001',
groups => ['sudo', 'audio', 'src', 'video', 'libvirt'],
home => '/home/dawud',
shell => '/bin/bash',
uid => '1001',
}
}
Puppetlabs have a very good documentation on the resource abstraction layer, RAL for short.
Best Answer
As Felix said, I had some
apt
class shadowing the one from the module.I replaced:
with:
And the issue was fixed.