Puppet users - Jan 2011 - Puppet Clients requesting classes

We are currently using puppet with a node based configuration on the
master, so we have a structure similar to that:

node xyz {
    /* do something here */
}

node default {
   /* do something here */
}

in the included files and classes we have our setup procedures ongoing
and everything is working as intended.

But what we really want to achieve is not to register every node in
our master configuration (hostnames can totally vary so no wildcard
matching), but to give the nodes the possibility to request a specific
class or to report themselves as a specific type of server.

So when I start my new server for the first time I put the information
about the server type into the puppet config file or anywhere else
where suitable. The I start my puppet client, sign its certificate on
the master and the puppet client reports to the server being a server
of type "xyz" (or whatever type I configured it to be) and it pulls
the configuration of the master.

Is that somehow possible with puppet?

-- 
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 Tue, Jan 11, 2011 at 02:09:27AM -0800, Exinferis
wrote:
> But what we really want to achieve is not to register every node in
> our master configuration (hostnames can totally vary so no wildcard
> matching), but to give the nodes the possibility to request a specific
> class or to report themselves as a specific type of server.
I think that approach is fundamentally wrong.  I do not believe that a
puppetmaster should allow clients to decide which host they are, or
which configuration they receive.  The whole point about central
configuration is that you manage it centrally; if your clients can
decide, how do you determine what is going on without inspecting every
host directly?

If most of your hosts are going to have the same configuration, but some
will differ, why not use the default node for the common configuration
and make different entries for other hosts when you need to?  What do
you gain by having to go and make configuration changes on each host,
rather than just changing configurations in one place?  I can tell you
one thing you lose; you lose the ability to rebuild from scratch a node
that died (with, say, an unrecoverable hard disk).

If you really want to do this thing, you could achieve it by modifying
your default node configuration so that the extra configuration options
are contained in classes which are only included if certain facts are
true.  You then only create those facts on the hosts you want to have
those configurations.  I urge you not to do this.

-- 
Bruce

Hierophant: someone who remembers, when you are on the way down,
everything you did to them on the way up.

-- 
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 Tue, Jan 11, 2011 at 8:57 AM, Bruce Richardson <itsbruce@workshy.org>
wrote:
> On Tue, Jan 11, 2011 at 02:09:27AM -0800, Exinferis wrote:
>> But what we really want to achieve is not to register every node in
>> our master configuration (hostnames can totally vary so no wildcard
>> matching), but to give the nodes the possibility to request a specific
>> class or to report themselves as a specific type of server.
>
> I think that approach is fundamentally wrong.  I do not believe that a
> puppetmaster should allow clients to decide which host they are, or
> which configuration they receive.  The whole point about central
> configuration is that you manage it centrally; if your clients can
> decide, how do you determine what is going on without inspecting every
> host directly?
I disagree that this approach is fundamentally wrong, but it''s not
always appropriate.

Imagine you''re managing thousands of desktops. Rather than giving them
administrative rights, why not allow them to tweak the configuration
that they receive and allow them to tune certain parameters that
specify the kind of configuration that will be applied?

You can use reports to see what the actual state of your fleet is, you
don''t need to manage a central database for minor differences.

> If most of your hosts are going to have the same configuration, but some
> will differ, why not use the default node for the common configuration
> and make different entries for other hosts when you need to?  What do
> you gain by having to go and make configuration changes on each host,
> rather than just changing configurations in one place?  I can tell you
> one thing you lose; you lose the ability to rebuild from scratch a node
> that died (with, say, an unrecoverable hard disk).
>
> If you really want to do this thing, you could achieve it by modifying
> your default node configuration so that the extra configuration options
> are contained in classes which are only included if certain facts are
> true.  You then only create those facts on the hosts you want to have
> those configurations.  I urge you not to do this.
And on the flip side, I say that this is a perfectly valid way of
managing certain deployments.
>
> --
> Bruce
>
> Hierophant: someone who remembers, when you are on the way down,
> everything you did to them on the way up.
>
> --
> 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.
>
>
-- 
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.

Exinferis <der.aaron.koenig@googlemail.com> writes:
> Is that somehow possible with puppet?
Role-based configuration is possible with puppet.  The selection of
available roles will have to be preconfigured, but it is possible.

Instead of selecting on the registered host name you select on the role
it reports to have.

You will need to make a "role" fact, and you need to use a selector
within the default node definition, or with a matching wildcard node
definition:

,----[ server_role ]
| # role.rb
| Facter.add("role") do
|   setcode do
|     begin
|       file = File.new("/etc/role", "r")
|       line = file.gets
|       line.chomp
|     rescue => err
|       "undefined"
|     end
|   end
| end
`----

This allows for config like:

,----
| node default {
|     case $server_role {
|         ''desktop'': {
|             include my::desktop::class
|             include my::other::things
|         }
|     }
| }
`----

You should also be able to list multiple roles.  If you specify roles in
your file like this:

:one:two:three:desktop:whohooo:mission_critical:

you can match on:

,----
| node *.desktops.example.org {
|     case $server_role {
|         /:desktop:/ { include my::desktop::class }
|         /:mission_critical:/ { include corp::absolutely::vital:class }
|         /:whohooo:/ { include rubber::ducky }
|     }
| }
`----

...of course, I don''t see that anyone would have absolutely vital stuff
on a desktop, but you get the picture. :)


Note: This will not remove things installed by other roles, if you
switch roles.  Your classes will have to fix that.  If one role installs
"apache HTTPD", your other roles would have to know about this, and
remove it.  This is not specific to role-based configuration.

-- 
Stig Sandbeck Mathisen
(fnord)

-- 
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 Tue, Jan 11, 2011 at 09:05:43AM -0800, Nigel Kersten
wrote:
> 
> I disagree that this approach is fundamentally wrong, but it''s not
> always appropriate.
I''ll concede I''m being a little over-emphatic, but the
OP''s situation
didn''t read to me as if it had anything to justify that approach.  And
I did tell him how to do it, anyway.  Can''t say fairer than that.


-- 
Bruce

I must admit that the existence of Disneyland (which I know is real)
proves that we are not living in Judea in AD 50. -- Philip K. Dick

-- 
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.

Stig Sandbeck Mathisen <ssm@fnord.no> writes:
> ,----
> | node *.desktops.example.org {
> |     case $server_role {
> |         /:desktop:/ { include my::desktop::class }
> |         /:mission_critical:/ { include corp::absolutely::vital:class }
> |         /:whohooo:/ { include rubber::ducky }
> |     }
> | }
> `----
This should perhaps use a series of if tests instead, or you''ll only
get
the classes from the first match.

-- 
Stig Sandbeck Mathisen
                              Oooo, shiny!

-- 
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.