Don wrote:
> I apologize if this has been asked before but if it has- my google
> technique has failed me. If anyone can point me at the right docs I'm
> happy to dive right in.
>
> While I'm not having any problems with Puppet, I am having some
> trouble understanding the best practices.
>
> Specifically:
> I have a basenode defined. I also have several different collections
> of servers and workstations. I've created a class called prodservers,
> a class called devservers and a class called workstations- each one
> inherits basenode and is then inherited by specific nodes. Should I be
> doing this in a class? If so what is the best place to store these
> class definitions- right now I am using manifests/classes/
> workstation.pp and server.pp. Should this be done in a module instead?
> Putting specific configuration settings in a module (even if it is a
> module called "workstation" just feels wrong.
>
> http://reductivelabs.com/trac/puppet/wiki/PuppetBestPractice
> specifically says:
> "Stop using the manifests area to house classes, definitions, etc.
> Instead, use module exclusively to manage almost every single class,
> definition, template, file, etc."
>
> That would seem to run counter to the way I've done things. What am I
> missing? I'd like the admin that comes after me to be able to make
> sense of this deployment.
I like to think about modules as "implementation", while the manifests
area is "configuration" and "policy." That a node of the "webserver"
kind should have an apache and a NTP client is policy and thus belongs
into the manifest area. What in _means_ to have apache and NTP installed
is implentation and should be defined in their respective modules.
> Another question:
> The sample templates.pp in the best practices page defines a baseclass
> and then several types of servers. In what case would you define a
> baseclass instead of a basenode that you inherit?
> If you have different classes of servers then templates.pp can easily
> get unwieldy. I'm using templates.pp and just including my server and
> workstation specific classes. Is there a more sensible way to organize
> this?
>
If you ever want to switch to external node classification, it is good
to have nodes that look like this:
node name {
$var1 = val1
$var2 = val2
include class1, class2
}
> Lastly:
> Was there a technical reason to split out /services/ and /clients/
> from the rest of the modules? It seems somewhat arbitrary and makes
> configuring certain services a little less intuitive (for example: NTP
> which is included on all servers, but has a different configuration on
> the NTP master).
My own ntp module[1] only knows two kinds of ntp hosts: servers and
clients. The former connect to each other and external sources, while
the latter only connect to the local servers. The distinction is easily
done: those nodes which have set $ntp_servers are those which connect to
these external servers and thus _are_ servers. All others are clients.
> What's the best practice here? Do people create a
> subclass that overrides and disables the generic NTP config and
> substitutes a server config? What's the best way to define a
> "::disabled" class? The best practices gives openssh::disabled as an
> example but I'm having trouble understanding how that would work if
> the openssh class was already added to the generic server class, but
> needed to be disabled on a specific system.
You can include classes that inherit from classes that are already
included and this will "patch up" the resources. The following is legal
and will result in a disabled openssh service on the node "strange":
class openssh {
service { openssh: ensure => running, enable => true }
class disabled inherits openssh {
Service[openssh] { ensure => stopped, enable => false }
}
}
node fine {
include openssh
}
node strange inherits fine {
include openssh::disabled
}
Regards, DavidS
[1] http://git.black.co.at/?p=module-ntp
--~--~---------~--~----~------------~-------~--~----~
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+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---
