[Puppet Users] Re: Sharing the same file for different nodes
Joshua,
On Sep 15, 2:26 pm, Joshua Timberman [EMAIL PROTECTED] wrote:
On Mon, Sep 15, 2008 at 10:44 AM, josh [EMAIL PROTECTED] wrote:
class typeA {
file { /etc/ipf/ipf.conf:
owner = root,
group = sys,
mode = 644,
source = puppet://10.1.2.208/files/etc/ipf/ipf.conf.typeA,
alias = typeA
}
Try this, replacing X with A, B etc.
class typeX {
file { ipf-conf-typeX:
path = /etc/ipf/ipf.conf,
...
}
}
--
Joshua Timberman
Patriotism has no party - Barack Obama, DNC 2008.
Thank you, I will try that approach. It seems that I had a typo in
one of my nodes/foo.pp files, and fixing that resolved the issue for
now, but I like your approach.
Josh
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~--~~~~--~~--~--~---
[Puppet Users] Re: Getting started.. quick start guide?
On 9/16/2008 12:21 PM, Brian Mathis wrote: Does anyone know of a guide or site that can get someone going on puppet quickly, without having to swallow the whole system at once? Same recommendations as everyone else (James Turnbull's book, haven't read it, but everyone else says it's great), plus two others: 1. I've got several posts up about converting my systems over to a managed infrastructure at http://blogs.cae.tntech.edu/mwr/infrastructure-management/ -- there's still a few pieces left to write up (and to completely implement, for that matter), but it's pretty puppet-centric. 2. Similarly, there may be a few posts at http://blogs.cae.tntech.edu/mwr/category/puppet/ that aren't linked from the infrastructure management pages. But generally, a naive puppet setup is just a matter of writing down what you'd have to do to get a particular service up and running to your liking. Often it's of the form: 1) Install a package with my usual package manager. 2) Edit a configuration file from the package if necessary, or copy over a standard configuration file from a network location. 3) Restart the package's service if I actually changed anything in step 2. The writeup at http://blogs.cae.tntech.edu/mwr/2007/05/13/time-synchronization/ is a bit more complicated than the above, but only by trying to account for multiple platforms, and whether or not ntp should be running in a VM. Anything that's not obvious in the time sync post can most likely be clarified by checking Puppet's Type Reference. -- Mike Renfro / RD Engineer, Center for Manufacturing Research, 931 372-3601 / Tennessee Technological University --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~--~~~~--~~--~--~---
[Puppet Users] Re: Module Standards
2008/9/16 Digant C Kasundra [EMAIL PROTECTED]:
Hello everyone,
My team and I have been mulling over the module standards that were proposed
(http://www.reductivelabs.com/trac/puppet/wiki/ModuleStandards)
Members of our team like to break large classes up into tiny pieces, which
isn't covered in this doc. For instance, if a class declares 10 files and 12
packages and 5 services, there is a preference to break these into
foo::files, foo::packages, and foo:services and then have foo include these
things. My problem with this is that I like to preserve a clear
representation that :: denotes that the thing following is a subclass of the
thing proceeding (so ssh::server means this is a subclass of ssh, relating
specifically to ssh).
So my proposal is if there is need or want to break up large classes, the
fragment class (i.e. foo::files) be named specifically in a way that makes it
clear it is not a complete and functional class but only a fragment. Such a
naming convention might call for something like foo::_files or
foo::inc::files. I would like to open this topic up to discussion to the
greater community (you guys) and see what you think.
I guess I could see this if the classes were scattered throughout /manifests/.
I approach module building the same way in terms of breaking the classes
into smaller pieces. I guess I don't see a specific need for a
fragment designation.
I usually create a class named foo in init.pp and include the sub
classes there:
class files {
# include files class groups
include files::all
include files::rhel5
# include files class hosts
include files::host1
}
In site.pp I just include foo. I document all this in the README
and comment the init.pp file. It just seems natural to me that way.
My setup isn't probably as complex as some so maybe I'm missing
something..
Kent
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~--~~~~--~~--~--~---
