Hi,
I would say that this is a good idea except for the custom fact part.
Since these are not items that you will 'discover' from the system, a
custom function that looks up items in a table/LDAP server/whatever
would be more appropriate.
This reduces the load on both your clients and your network. Yes, not
by much for only two facts but, once you start down this path, you
will rapidly have a glut of facts that could more easily be discovered
by the server.
Trevor
On Wed, May 6, 2009 at 03:26, Greg <greg.b...@gmail.com> wrote:
>
> 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
-~----------~----~----~----~------~----~------~--~---
