Alan,

One thing I found handy was to build up 2 custom facts to add into
facter: defaultroute and site.
defaultroute is used to determine which site a host is in...
Personally I found the class heirarchy
too limited since you can't inherit from multiple places... So you
would need classes like site1-webserver,
site2-webserver, site1-database, site2-database and so on... Too
annoying.

Adding in these custom facts allows you to add in config files based
on which site the node lives.
For example:

file { "/etc/resolv.conf":
   source => "puppet:///network/resolv.conf-$site"
   owner => root, group => root, mode => 644
}

Heres the custom facts I added.
(Note: the default route is Solaris specific as I don't need to manage
any Linux boxes at my site)
(Also note: My knowledge of Ruby is *really* basic at this stage,
apologies if this code is bad)

defaultroute.rb:
Facter.add("defaultroute") do
    setcode do
        defroutefh = File.open("/etc/defaultrouter")
        defroutefh.readline.chomp
    end
end

site.rb:
Facter.add("site") do
    setcode do
        case Facter.value('defaultroute')
            when "10.0.0.1"
                "site1"
            when "10.0.0.2", "10.0.0.3"
                "site2"
            else
                "unknown"
        end
    end
end

Now, this makes the answer to q1 a bit easier... I have mine
modularised into groups based on what the config is about. Networking
config is in one module, sudo management in another and so on. That
way its (hopefully) more sane when you come to make changes. I guess
the granularity that you put this on is up to you.

2. I will leave this one to someone more experienced with Puppet than
me, but I use modules to group similar classes
together - kind of like a library. Its probably a very simplistic view
of things, but so far it has worked well for me...

3. My svn repository is set up as follows:

    - baseline/
        Main trunk - This is where most of the work gets done... Keep
your live Puppet Master config tree here...
    - tags/
        Contains discrete release views.
    - branches/
        Haven't used this yet, but I'm planning on using this for
larger changes, development work and so forth...

I'm sure I have missed out something that I'm going to need later on,
but figure its a reasonable starting point...
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Reply via email to