automatic load of node definition file

[Philip Brown]

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.

[Christopher Wood]

At the bottom of my site.pp I have:

import "nodes/*"

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

> --
> 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...@googlegroups.com.
> To unsubscribe from this group, send email to
> puppet-users...@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

[Denmat]

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

[Philip Brown]

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

[jcbollinger]

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

[Philip Brown]

On Wed, Sep 19, 2012 at 7:36 AM, jcbollinger <John.Bo...@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 ?