On Nov 24, 9:37 am, Chris C <mazzy...@gmail.com> wrote:
> I was able to get override to work correctly.
I'm glad to hear it.
> 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
A class defining the common elements for all managed systems seems a
relatively common practice. It works for many people, but the devil
is in the details.
[...]
> > > 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? ;)
Not like Mozilla pays, no. Puppetlabs pays for accepted bug reports
by giving you the fixed version, when it's ready, free of charge. In
fact, you could consider filing good bug reports to be a quid pro quo
for Puppetlabs having given you Puppet in the first place.
> > 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?
I mean "module" in its Puppet-specific sense. See
http://docs.puppetlabs.com/guides/modules.html.
> > 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.
If you anticipate that many clients then you should be running Puppet
itself behind Apache httpd, via Passenger.
Whether Puppet's file serving performance suffices depends on many
parameters, some of them external to Puppet itself. I think the file
server's inherent efficiency is reasonably good, but you should be
aware that however files are served, Puppet uses checksumming (MD5 by
default) when managing them to determine which need to be synced. You
can instruct Puppet to use modification time instead, which will
greatly speed it up at the cost of reducing its reliability for
detecting out-of-sync files.
> My intention is to use Puppet to manage the content of our public website.
> Our website is extensive.
Honestly, I don't think that's a great idea. Puppet will be good for
managing the servers themselves, but not so much for directly managing
their extensive web content. Have you considered instead using a
version control system, such as Subversion or git? Puppet can easily
manage a cron job to periodically pull down changes, or you could use
an exec to have Puppet pull down changes itself on every run. Among
the advantages of doing it this way:
a) easy reversion of errors
b) content changes are traceable to specific users
c) web developers don't interact with Puppet
Cheers,
John
--
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.
