Technically true, but administratively confusing IMHO. On Thu, Sep 1, 2011 at 1:08 PM, Scott Smith <sc...@ohlol.net> wrote:
> 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. > -- 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.
