Puppet users - May 2012 - automatic load of node definition file

I vaguely recall some kind of reference mentioning that as a fallback, 
puppet master would attempt to load  host.fqdn.pp to find a node 
definition. Is that a false memory?  
In practice, it does not seem to do that.

Along those lines, is it possible to MAKE it do that?

I''ve tried

import "nodes/$hostname.pp"
but puppet doesnt seem happy with that.
I''d like to keep things simple and file-based, rather than going to a 
separate external database or LDAP server. So yes I know about those, but 
would prefer not to go there.
I prefer the "one service, one process to babysit" methodology :)

The closest method I''ve found so far, is creating my own custom
*class*,
autohost, and then using

include "autohost::$hostname"

Comments on this?

I''m not sure what the effective difference between nodes and classes
are,
at this point.Other than the fact that you can wildcard node definitions, 
which is nice. Seems like they are practically equivalent. both can 
"inherit". both can include other classes. etc, etc.

Currently, I''m liking the idea of 300 separate files, one per host,
under
autohost, where only ONE gets loaded... vs the old brute-force method of
import "nodes/*.pp"

It disturbs my sense of efficiency to read in 300 files, when 299 of them 
will be unneeded.






-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/QF_o0kR7w5IJ.
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.

At the bottom of my site.pp I have:

import "nodes/*"

I haven''t heard of this autoload thing, but then I''m newish.

On Wed, May 02, 2012 at 11:06:17AM -0700, Philip Brown
wrote:
>    I vaguely recall some kind of reference mentioning that as a fallback,
>    puppet master would attempt to load  host.fqdn.pp to find a node
>    definition. Is that a false memory? 
>    In practice, it does not seem to do that.
> 
>    Along those lines, is it possible to MAKE it do that?
> 
>    I''ve tried
> 
>    import "nodes/$hostname.pp"
>    but puppet doesnt seem happy with that.
>    I''d like to keep things simple and file-based, rather than
going to a
>    separate external database or LDAP server. So yes I know about those,
but
>    would prefer not to go there.
>    I prefer the "one service, one process to babysit" methodology
:)
> 
>    The closest method I''ve found so far, is creating my own custom
*class*,
>    autohost, and then using
> 
>    include "autohost::$hostname"
> 
>    Comments on this?
> 
>    I''m not sure what the effective difference between nodes and
classes are,
>    at this point.Other than the fact that you can wildcard node
definitions,
>    which is nice. Seems like they are practically equivalent. both can
>    "inherit". both can include other classes. etc, etc.
> 
>    Currently, I''m liking the idea of 300 separate files, one per
host, under
>    autohost, where only ONE gets loaded... vs the old brute-force method of
>    import "nodes/*.pp"
> 
>    It disturbs my sense of efficiency to read in 300 files, when 299 of
them
>    will be unneeded.
> 
>    --
>    You received this message because you are subscribed to the Google
Groups
>    "Puppet Users" group.
>    To view this discussion on the web visit
>    [1]https://groups.google.com/d/msg/puppet-users/-/QF_o0kR7w5IJ.
>    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.
> 
> References
> 
>    Visible links
>    1. https://groups.google.com/d/msg/puppet-users/-/QF_o0kR7w5IJ
-- 
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.

Hi,
>> load  host.fqdn.pp to find a node
it will search hostname and fqdn but not hostname.fqdn.

This all sounds like a lot of work to me. How do you intend to manage changes
that effect 300 nodes?

What I do is that I create a custom that assigns a role to certain node types. I
then have a roles class that queries that fact and goes off and load whatever it
needs (from general to specific).

So all I need in nodes.pp is:
node default { include roles }

Then in roles module I add users, sort of distros and load specific modules with
the data coming in from hiera.

I''m not seeing a need to make it more complicated than that in you
scenario. But you may have your valid reasons.

Cheers
Den

On 03/05/2012, at 4:28, Christopher Wood <christopher_wood@pobox.com>
wrote:
> At the bottom of my site.pp I have:
> 
> import "nodes/*"
> 
> I haven''t heard of this autoload thing, but then I''m
newish.
> 
> On Wed, May 02, 2012 at 11:06:17AM -0700, Philip Brown wrote:
>>  I vaguely recall some kind of reference mentioning that as a fallback,
>>  puppet master would attempt to load  host.fqdn.pp to find a node
>>  definition. Is that a false memory? 
>>  In practice, it does not seem to do that.
>> 
>>  Along those lines, is it possible to MAKE it do that?
>> 
>>  I''ve tried
>> 
>>  import "nodes/$hostname.pp"
>>  but puppet doesnt seem happy with that.
>>  I''d like to keep things simple and file-based, rather than
going to a
>>  separate external database or LDAP server. So yes I know about those,
but
>>  would prefer not to go there.
>>  I prefer the "one service, one process to babysit"
methodology :)
>> 
>>  The closest method I''ve found so far, is creating my own
custom *class*,
>>  autohost, and then using
>> 
>>  include "autohost::$hostname"
>> 
>>  Comments on this?
>> 
>>  I''m not sure what the effective difference between nodes and
classes are,
>>  at this point.Other than the fact that you can wildcard node
definitions,
>>  which is nice. Seems like they are practically equivalent. both can
>>  "inherit". both can include other classes. etc, etc.
>> 
>>  Currently, I''m liking the idea of 300 separate files, one per
host, under
>>  autohost, where only ONE gets loaded... vs the old brute-force method
of
>>  import "nodes/*.pp"
>> 
>>  It disturbs my sense of efficiency to read in 300 files, when 299 of
them
>>  will be unneeded.
>> 
>>  --
>>  You received this message because you are subscribed to the Google
Groups
>>  "Puppet Users" group.
>>  To view this discussion on the web visit
>>  [1]https://groups.google.com/d/msg/puppet-users/-/QF_o0kR7w5IJ.
>>  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.
>> 
>> References
>> 
>>  Visible links
>>  1. https://groups.google.com/d/msg/puppet-users/-/QF_o0kR7w5IJ
> 
> -- 
> 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.

[yes, this is a reply to an OOOLD message. sorry :) I think it''s still 
useful]

This is regarding a construct that I suggested to the list back in May, and 
still haven''t found anything better for my purposes.
So, I''m fleshing out the implementation details for people a bit more.

The idea:
Have a pseudo-database-driven site.pp... without the bother of setting up 
an actual standalone database, etc, etc.
I would have preferred if puppet some built-in manifest support for
  (load nodes/$hostname.pp)
But since it doesn''t... here''s the next best thing

The advantage to using this methodology:
1. no extra software package to install and maintain for a DB
2. breakage in a host-specific file, does not affect any other host.
   In contrast, using "import nodes/*.pp" is fragile to any problem in
any
node file. Not to mention inefficient in loading potentially hundreds of 
node definitions every time, when they are not needed.


The implementation:
In site.pp, have, as pretty much the only line,

  include "autohost::$hostname"

Then in modules/autohost/manifests/yourhost.pp, have contents of

class autohost::yourhost {
        # Whatever-you-want-here
}


Now to address an older question,


On Wednesday, May 2, 2012 6:44:45 PM UTC-7, denmat
wrote:
>
> Hi, 
> ...
>
> This all sounds like a lot of work to me. How do you intend to manage 
> changes that effect 300 nodes? 
>
Very easy. Presuming that there is something these 300 nodes have in 
common; you make a shared base class for them.
eg:

class autohost::yourhost inherits autohost::commonbase {
        # Whatever-you-want-here
}

Want to make a "global" change? Then make it to autohost::commonbase.

Similarly, for smaller subgroupings, you treat the autohost::yourhost 
class, as a node definition, and just include any host-specific class you 
want.

 
class autohost::yourhost inherits autohost::commonbase {
    include specialserverclass1
    include specialserverclass2
    #etc, etc.
}
.
 


-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/hIEb3-1MkaAJ.
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 Tuesday, September 18, 2012 1:36:53 PM UTC-5, Philip Brown
wrote:
>
> [yes, this is a reply to an OOOLD message. sorry :) I think it''s
still
> useful]
>
> This is regarding a construct that I suggested to the list back in May, 
> and still haven''t found anything better for my purposes.
> So, I''m fleshing out the implementation details for people a bit
more.
> [...]
> In site.pp, have, as pretty much the only line,
>
>   include "autohost::$hostname"
>
> Then in modules/autohost/manifests/yourhost.pp, have contents of
>
> class autohost::yourhost {
>         # Whatever-you-want-here
> }
>
>
I think that''s just fine.  Though no one would know from the responses
you
received before, I think some people do pretty much what you''re
describing.

The main disadvantage I see is that you need a class for every host, 
whereas with node declarations you can match nodes to declarations via 
regexes, assign multiple node names and regexes to the same node 
declaration, and fall back to a default node.  If you''re not interested
in
doing any of those things, and if having one class per node does not 
present a scaling problem for you, then it sounds good to me.

Another way you could approach this might be to convert your node 
declarations to Hiera YAML files, and use hiera_include() to assign them to 
nodes in place of including "autohost:$hostname".  Your hiera
hierarchy
would have a level based on %hostname, which is where the per-node files 
would be pulled in.

The hiera approach has the advantages that you don''t necessarily need a
separate file for every node, that you can easily implement shared 
defaults, and that you can classify based on more criteria than just 
hostname, if you desire.  It has the disadvantages that you cannot specify 
class parameters that way (if you are unwise enough to use parametrized 
classes), and that you cannot set node variables.  The latter is mitigated 
by the ability to simply look up node data via hiera as well, and the 
former will be mitigated in Puppet 3 by the integration of class parameter 
resolution with hiera.

Note, however, that there are security implications to using facts instead 
of node identities to classify nodes.  Node declarations are matched to 
client SSL certnames, and it is only a convention that these are normally 
the same as the hostname.  If an existing client node is subverted then it 
can be made to report whatever facts the attacker wants to the puppet 
master, and if the master relies on those to classify nodes, then the 
attacker can steal the configuration of any node (possibly including 
sensitive information).  With node declarations, control of one client does 
not confer access to the configuration of other clients.
 
>
> Now to address an older question,
>
>
> On Wednesday, May 2, 2012 6:44:45 PM UTC-7, denmat wrote:
>>
>> Hi, 
>> ...
>>
>> This all sounds like a lot of work to me. How do you intend to manage 
>> changes that effect 300 nodes? 
>>
>
> Very easy. Presuming that there is something these 300 nodes have in 
> common; you make a shared base class for them.eg:
>

For what it''s worth, that is a misuse of class inheritance unless you
are
overriding parameters of a resource inherited from the base class. (That 
might be just what you wanted in some cases, however.)  Where you''re
not
overriding, it''s better to simply ''include'', much as
you describe for node
subgroupings.


John

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/ES71pNhTGvEJ.
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 Wed, Sep 19, 2012 at 7:36 AM, jcbollinger <John.Bollinger@stjude.org>
wrote:
>
>
> On Tuesday, September 18, 2012 1:36:53 PM UTC-5, Philip Brown wrote:
>>...
>>   ...
>
> I think that''s just fine.  Though no one would know from the
responses you
> received before, I think some people do pretty much what you''re
describing.
Thanks for the reply then :)
...
> Note, however, that there are security implications to using facts instead
> of node identities to classify nodes.  Node declarations are matched to
> client SSL certnames, and it is only a convention that these are normally
> the same as the hostname.
This sounds like an oversight in puppet design.
Seems like there would be a benefit for some kind of verification flag
somewhere, either as a "facter", or an optional class, or something,
for
ensure => signed_hostname
if you see what I mean.

and/or allow an additional, server-side "fact", that matches based on
the cert the client connects with, rather than $hostname.

$certname   ?

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