On Mon, Nov 29, 2010 at 6:46 AM, jcbollinger <john.bollin...@stjude.org> wrote:
>
>
> 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
I often have trouble convincing people of this, but if you've got a
good automated package build environment, I'm a big fan of packaging
content like websites based upon tags, and then using Puppet to ensure
those packages are installed.
>
>
> 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.
>
>
--
Nigel Kersten - Puppet Labs - http://www.puppetlabs.com
--
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.
