On Aug 22, 2007, at 5:58 AM, Beyerle Urs wrote:
> Hi all,
>
> I''m new to puppet (coming from cfengine). I have a question
> concerning recursive copy. We
> have about 20 different types of desktop PC installations (typeA,
> typeB, ...). Each type
> has about 10-40 different config files. What I would like to do:
>
> I have a file server with the following structure:
>
> /dist/typeA
> /dist/typeB
> /dist/typeC
> ...
>
> Inside /dist/typeA the config files have the same place as they
> should have on the client,
> for example
>
> /dist/typeA
> |-- etc
> | |-- cups
> | | `-- client.conf
> | |-- hosts.allow
> | |-- ..
> .
> `-- usr
> `-- share
> `-- config
> `-- kdesktoprc
I *highly* recommend against this style of organization. I started
out using it in Cfengine, but I soon switched to organizing files
semantically and was much happier. When I was using Cfengine, I had
my dist directories organized by app:
dist/
sudo/
sudoers
cups/
client.conf
...
Then I''d have a service-specific cfengine file to manage where files
went.
With Puppet modules, life becomes even easier. For instance, you can
easily create a cups module that looks like this:
modules/
cups/
files/
client.conf
manifests/
init.pp
In your init.pp, you''d have something like this:
class cups {
file { "/etc/cups/client.conf": ... }
}
I understand that it''s more work up-front to organize your files like
this, but the long-term payoff is immense. Really. The biggest
differences are that you never have to wonder where a file is ("Does
the cups client.conf go in /etc or /etc/cups?") and that the same
classes can be more easily made cross-platform (e.g., you only have
to slightly modify your ssh class to get sshd_config to /etc, /etc/
ssh, /opt/local/etc/ssh, or /usr/local/etc/ssh, whichever your
platform requires).
You should at least give it a try; this is the kind of thing that I
basically tell my clients, do this or I can''t support you.
It''s that
big of a difference.
> However, this takes much too long. I think because puppet goes
> through all the files in /
> on the client.
You are correct. We''ve talked about being able to selectively use
only remote recursion or something, but no one''s done that work.
> Further, the directories on the file server - let''s say /dist/
> typeA. Will be populated and
> managed by the admin responsible for typeA PCs. And I (or he)
don''t
> want to change the
> manifest every time a new file is added to /dist/typeA.
If you''ve got this kind of separation, have multiple module
directories, with different people responsible for different
directories. Or, even better, just different modules and different
people responsible for each.
You''ll still be modifying manifests when you add files, but
they''ll
be the module-specific manifests, not some central manifest you don''t
want to give those admins the rights to.
> To make it even more complicate, the admin responsible for typeA PC
> will have only access
> to /dist/typeA on the file server and the files which are created
> inside /dist/typeA will
> belong to him. Therefore I have to ensure that the owner of each
> config file transfered to
> the client is root. However, if I do
>
> file { "/":
> source => "puppet://puppet/dist/$type",
> ensure => file,
> recurse => true,
> owner => "root";
> }
>
> things get even worse. Puppet will now change the owner of each
> file on the client to root
> (because it goes recursively into /) .
This problem basically goes away with per-service modules.
> Is there a better way for this task?
> Any suggestion are very welcome!
Indeed there is. :)
--
We cannot really love anybody with whom we never laugh. --Agnes
Repplier
---------------------------------------------------------------------
Luke Kanies | http://reductivelabs.com | http://madstop.com