Thanks John and Stefan. Sorry for the delay to answer. Actually, the /etc/puppet object was too ambitious, I modified it to handle every file and subdirectory under /etc/puppet. Like that, it's a lot easier to handle dependencies and ownership. Also, it's troublesome to handle the svn under /etc/ puppet/files so I think I'll move that somewhere else.
I didn't think about a script handeling the checkout and the permissions but it's a good idea, same for the resource, I've never used it before so I'll have to take a look. The problem with your 5) is that I would have too many puppetmasters to handle ( lots of separate networks ). Every modification I would make somewhere would have to be manually downloaded everywhere which mean loosing all the advantages of Puppet. My idea is to have a single point where I manage everything. What we plan to do manually ( as our configuration won't change often ) is the puppetd -t requests, from the level-2 puppetmasters and from the nodes, we don't want actually to automatize that. But it's also because we actually miss a development environment, which is the next step I'll have to work on ;-) I'll come back if I have any more questions, thanks again. Jay On 16 déc, 17:15, jcbollinger <[email protected]> wrote: > 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.
