dd-b wrote:
>
>
> On Oct 1, 12:24 pm, Jeroen van Meeuwen <[EMAIL PROTECTED]> wrote:
>
>> Does that help?
>
> Yes, thanks.
>
> I'm inferring from your answer that not only does that work, but you
> think it's a reasonable approach.
>
Yes sir I do, and I split these manifests up in different categories as
well (usefulness depending on the scale of the environment of course):
- classes/
Aggregations of classes (from modules?), environment specific
settings for those classes, overriding/extension of classes (such as
subclassing the ssh module to make it apply to your organization):
class yum-repo-profile {
include yum::standard
yum::repository { "custom":
enable => true
}
}
- domains/
Branch offices / co-locations with different dns suffices, network
settings, security profiles. Maybe some organization specific stuff
if your environment is a merger hybrid.
- groups/
A group of hosts getting the same configuration (cluster-app1,
cluster-app2, reverse-proxy-dmz)
- services/
Sets of services
- webservice (hourly logrotate maybe some selinux config)
- ldapservice (no ldap authentication for these, only local
system administrators)
Basically a complete configuration in one service specific class of
what your organization defines as a "service"
How does that sound?
-Jeroen
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---
