A directory is a directory. That a directory has a parent directory in which other files exist is pretty moot.
On Thu, Sep 1, 2011 at 12:13 PM, Aaron Grewell <aaron.grew...@gmail.com>wrote: > We don't put our manifests under /etc/puppet at all. It's convenient for > small installations but as we scaled up I found mixing configs (local, > managed by Puppet) and manifests (kept under version control) to be > problematic. > On Sep 1, 2011 11:58 AM, "Russell Van Tassell" <russel...@gmail.com> > wrote: > > I'm currently in the same position, and the solution I've proposed (and > am > > currently working on) involves using a central repository (likely git). > The > > puppet client (running on the master) simply checks the current master > > branch on the remote repository -- if the revisions are not the same, it > > just pulls a new copy. > > > > While I've not implemented this, yet ... I'm guessing it should work. > Anyone > > have any better ideas -- perhaps a check-in hook to trigger at export? > > > > Regards, > > Russell > > > > > > On Thu, Sep 1, 2011 at 11:47 AM, Douglas Garstang > > <doug.garst...@gmail.com>wrote: > > > >> I have a real-world, best practices, procedural question. > >> > >> How do you manage the he puppet master, under /etc/puppet, where > multiple > >> people may be editing files? The /etc/puppet directory is a working > copy, > >> and each user has read access to files created by other users. However, > if > >> one person adds a module directory to svn, the lock files that are > created > >> by svn are owned by that person, and the next person that comes along > can't > >> do svn updates etc. Similarly I can't write to files created by a > different > >> user. > >> > >> Yes, sure, the 'right way' to do this may be to have all the files owned > by > >> the puppet user, and users don't edit files directly in /etc/puppet, and > a > >> script is responsible for performing the svn update, but we're not there > >> yet. > >> > >> Ideas? > >> > >> Doug. > >> > >> -- > >> You received this message because you are subscribed to the Google > Groups > >> "Puppet Users" group. > >> To post to this group, send email to puppet-users@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. > >> > > > > -- > > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > > To post to this group, send email to puppet-users@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. > > > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To post to this group, send email to puppet-users@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. > -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@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.
