Best Practices on node declaration

309 views
Skip to first unread message

AnOnJoe

unread,
Nov 21, 2012, 12:46:06 PM11/21/12
to puppet...@googlegroups.com
Hello,

I would like to know what are the best pratices in node declaration.

I tried to play with inheritance with failures :
Here my puppet/manifest/site.pp

node basenode {
        class { 'ssh': }
        class { 'ntp': }
        class { 'users': }
        class { 'sudo': }
}

node default inherits basenode {
}

################################################################
# serv1
################################################################
node "serv1" inherits basenode {
        class { 'sudo' :
                sudoers => "sudoers_serv1"
        }
        class { 'debug': }
}

As you can see i have to manage 2 sudoers file :
One in almost all server, and an other one in my "serv1" server

here is my sudo class

class sudo ($sudoers="sudoers") {
        package { 'sudo':
                ensure => installed,
        }
        file { '/etc/sudoers':
                source  => "puppet://puppetmaster.foo.com/sudo/$sudoers",
                ensure => file,
                mode   => 440,
                owner   => 'root',
                group           => 'root',
                require => Package['sudo'],
        }
}


Can you tell me what is the best way to resolve that kind of problems.

Thx

Jakov Sosic

unread,
Nov 21, 2012, 1:27:19 PM11/21/12
to puppet...@googlegroups.com
On 11/21/2012 06:46 PM, AnOnJoe wrote:
> Hello,
>
> I would like to know what are the best pratices in node declaration.
>
> I tried to play with inheritance with failures :
> Here my*puppet/manifest/site.pp*
>
> node basenode {
> class { 'ssh': }
> class { 'ntp': }
> class { 'users': }
> class { 'sudo': }
> }


First of all, don't instant classes like resources... Use include
instead. So this would look like:

node basenode {
include ssh
include ntp
include users
include sudo
}


>
> node default inherits basenode {
> }
>
> ################################################################
> # serv1
> ################################################################
> node "serv1" inherits basenode {
> class { 'sudo' :
> sudoers => "sudoers_serv1"
> }
> class { 'debug': }
> }

When you instance classes like resources, then you cannot instance it
twice. You can only do it once, and you already did it in the basenode.
This is like defining the same resource twice. Your main problem is in
the basenode.


> As you can see i have to manage 2 sudoers file :
> One in almost all server, and an other one in my "serv1" server
>
> here is my *sudo class*
>
> class sudo ($sudoers="sudoers") {
> package { 'sudo':
> ensure => installed,
> }
> file { '/etc/sudoers':
> source =>
> "puppet://puppetmaster.foo.com/sudo/$sudoers",
> ensure => file,
> mode => 440,
> owner => 'root',
> group => 'root',
> require => Package['sudo'],
> }

You can use Hiera for this purpose. In the hiera yaml manifests you can
just then define something like:

sudo::sudoers: sudoers_serv1

and your class would get the data from hiera. That way it would be
enough to include it into basenode, and you would have opportunity to
set up each node differently without redefining the classes. I really
urge you to invest some time into learning hiera.

Ellison Marks

unread,
Nov 21, 2012, 1:46:00 PM11/21/12
to puppet...@googlegroups.com
Seconding this. When I first started using puppet, I thought that node inheritance would be a wonderful way to achieve a hierarchy. This was before I knew about hiera.

Long story short, node inheritance doesn't work that way, and if you try and force it to, things get really unpredictable. Hiera is definitely the way to go for this kind of structure. Best part is, once you get it going, you don't even have to declare nodes anymore. all you need is a default node and hiera_include.

node default {
  hiera_include('classes')
}

then just have an array of class names to include in your hiera files. For example, using the yaml backend with this hierarchy:

:hierarchy:
  - %{fqdn}
  - common

common.yaml would have

classes:
  - ssh
  - ntp
  - users
  - sudo

and (fqdn of serv1).yaml, along with what Jakov mentioned, would have

classes:
  - debug

With more complicated hierarchy's, you can also get more complicated layers of classes.

AnOnJoe

unread,
Nov 23, 2012, 3:08:06 AM11/23/12
to puppet...@googlegroups.com
Thank you very much guys.

Hiera saved my life ;-)
Reply all
Reply to author
Forward
0 new messages