Thanks for the reply!
I was able to get override to work correctly.
My classes are inheriting each other. prac inherits all_hosts_redhat which
inherits all_hosts.
I cleaned up some unnecessary duplicate checks like chmod and own.
I changed the definition to the overided file to File['/etc/motd'] { ....
I also set a variable at the top of the class so I can easily override
content source
ie...
class all_hosts_redhat inherits all_hosts {
$dir = redhat/all
#CONFIGURE MOTD
file { "/etc/motd":
checksum => md5,
source => "/net/puppetmaster/etc/puppet/manifests/files/$dir/motd"
}
}
This gives me the option to have different motd's for different classes and
I no longer have the funny flip flopping of content in motd...
The tutorial at puppetlabs really helped to iron out the issues.
I have some comments. They are inline.
>
> > I had a heck of a time getting around the "Duplicate Definition"
> > issue.
> >
> > Shouldn't file { "/etc/motd" in prac override file { "/etc/motd" in
> > all_hosts?
>
> No. For good reasons, Puppet forbids duplicate resource declarations
> in the scope of any node (but see below).
>
> > When I do a puppetd --test the content of motd flip flops
> > between the two classes.
>
> That's surprising, because
>
> a) unless its hostname changes or your manifests change, each node
> will get only one definition of File["/etc/motd"], and besides,
> b) both definitions you have shown point to the same file. (*)
>
> (*) Filesystem paths are resolved on the client, and it looks like in
> your case the file is remote, so you might be getting changes either
> because a different remote filesystem is mounted at different times or
> because the remote file is changing.
>
>
Maybe I found a bug. Does Puppetlabs pay like Mozilla pays? ;)
>
> > Maybe there is a better way to do this and I'm just missing something.
>
> Yes, there are better ways. Here are several recommendations, with
> varying degrees of specificity for your stated problem:
>
> 1) Organize your manifests into modules. It is never too early to do
> this.
>
>
What do you mean by this? I thought my manifest was modular?
> 2) As a general rule, do not declare resources directly in node
> definitions. Declare them only in classes or definitions. (This does
> not appear currently to be an issue for you.)
>
>
Only class includes are being added to my node definition
> 3) Where you want Puppet to manage individual files (such as /etc/
> motd), use its built-in file server. Refer clients to this by using a
> "source" URL of the form "puppet:///<module>/<file>".
>
>
Is using the puppet fileserver high performance? I'm expecting to have
300-500 clients. These VM's just keep popping up like daisy's in my lawn.
4) If you don't need or want a stand-alone external file to serve,
> especially if the contents rarely change, then consider using
> "content" instead of "source".
>
>
Hm. I think I will consider that. I have 60 some checks and doing md5sum's
seems heavy weight.
My intention is to use Puppet to manage the content of our public website.
Our website is extensive.
> 5) If you use node inheritance at all, keep your inheritance tree
> extremely shallow. If find yourself using more than two levels then
> either refactor your manifests or switch to an external node
> classifier (or both).
>
>
I do want to use an external node classifier. I don't think I'm far enough
along yet.
I would like our Active Directory to hold manifest data. Unfortunately our
AD needs ALOT of cowbell at this time. That is going to be my winter
project.
> 6) Instead of multiple, similar classes for differing circumstances,
> write single classes that use nodes' facts where necessary to tailor
> resources to the target node.
>
> 7) Use classes instead of node groups to describe facilities or roles
> that systems should have. Nodes that serve multiple roles or have
> multiple unrelated features then simply include all the appropriate
> classes.
>
> 8) If you have resources so general that it's otherwise difficult to
> declare them in only one place, then create central, virtual
> declarations for them, and "realize" them wherever needed. System
> users are the canonical example of such resources.
>
>
I saw those features in the tutorial. I'm definitely going to go that
direction. I'm glad to get this first step to work.
My classes are already getting out of hand. It sure didn't take long.
> 9) Puppet does provide a feature for overriding resource definitions:
> a subclass may override properties of resources declared by one of its
> superclasses, using a special syntax. Leveraging this feature is the
> *only* good reason for creating a subclass; for any other purpose it
> is better to "include" another class than to inherit from it. Avoid
> the temptation to overuse resource overrides, however.
>
> 10) For details on how to use any of the features I've mentioned
> above, consult the Puppet documentation. In particular, these
> documents may be helpful to you:
> http://docs.puppetlabs.com/guides/language_tutorial.html,
> http://docs.puppetlabs.com/guides/modules.html,
> http://docs.puppetlabs.com/guides/file_serving.html. Perhaps also
> http://docs.puppetlabs.com/guides/best_practices.html, though it's a
> bit skeletal at the moment.
>
>
Thanks,
/Chris C
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-us...@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.
