On Dec 15, 4:27 pm, "Jay N." <[email protected]> wrote:
> Hi,
>
> I have a dependency problem in my configuration. I have thoses 2
> objects.
>
> file { "/etc/puppet/files":
> ...
>
> }
>
> file { "/etc/puppet":
> ...
> require => File["/etc/puppet/files"],
>
> }
>
> I thought I would have no problem with that but /etc/puppet is
> autorequired by /etc/puppet/files, which means a dependency cycle. So
> my first question is, is there a way to avoid that unwanted
> autorequiring?
>
> Let me explain my choice : I first change the owner of /etc/puppet/
> files for someone else than root being able to write. Then I commit my
> svn configuration into /etc/puppet/files ( I do like that because root
> doesn't have the right to checkout, only some users does ), and in the
> end I update my puppet configuration ( with the /etc/puppet object )
> using the checkouted files. Maybe there's a better way to do it.
As I interpret what you wrote, you are giving Puppet conflicting
definitions for the properties of /etc/puppet/files and its contents:
one set of definitions in resource File["/etc/puppet/files"] and a
different set indirectly via recursion from File["/etc/puppet"]. This
is not the Puppet Way, and you are likely to continue to have problems
as long as you're fighting Puppet. Each managed resource's properties
should be defined exactly once.
Whenever you think "I first [...]. Then I [...]," you are trying to
use a Puppet configuration as a script, and that will mainly get you
into trouble. To master Puppet you must let go of the script engine
mentality. Puppet provides resource depenencies are all about state
(just like the rest of the DSL). For example, directory /etc/puppet/
files cannot exist unless /etc/puppet exists and is a directory,
therefore the former depends on the latter, whether you model it
explicitly or not. The Puppet agent does use that information to
choose an acceptable order to apply resources, but if you focus on
that detail then you are missing the point.
To put it an entirely different way, never try to model transient
state in your Puppet configuration. It goes against the tao of
Puppet.
[...]
> The weird thing I realized is that if I change my exec to :
> exec { "Dirty way":
> command => "chgrp grpsvn /etc/puppet/files",
> path => "/usr/bin:/usr/sbin",
> unless => "cd /etc; ls -la puppet/files | head -2 | grep grpsvn",
>
> }
>
> then I don't have any more the autorequire and the configuration is
> working just fine.
Puppet is only a program. If you try hard enough, you can usually
trick it. Doing so is rarely a good idea.
> Is it normal that puppet parses the unless
> parameter ( and maybe others ) to find autorequirements?
Yes.
> Isn't it too
> much autorequirements?
No.
You have several alternatives that should achieve the end result you
want, while being more in line with Puppet's model:
1) Give root svn access
2) Make the files (permanently) writable by some non-root user, and
perform the svn update as that user. The user can be a system user
such as puppet. Do not twiddle ownership or permissions back and
forth.
3) Find or create an svn resource type to add to Puppet that will
handle the twiddling for you.
4) Move all the ownership and permission twiddling into your checkout
script (i.e. remove the two File resources with which you are
currently trying to do the twiddling). That will make the overall
operation atomic from Puppet's perspective, which is a good thing.
5) If you only want to manage your puppetmaster in this particular way
(which seems possible given the specific resources involved) then it
may be more reasonable to do it manually. That will also give you the
opportunity to temporarily shut down puppetmasterd while you do so, to
avoid clients getting an inconsistent view of the files if they happen
to request them while the update is in progress. You could schedule
that with cron if you can accommodate puppetmasterd not coming back up
in the event that the script errors out.
Good luck,
John
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to [email protected].
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.
