Hi, I''m a new puppet user (thanks !) and I''m just looking at moving my homegrown manifest structure into something resembling the best practise guide at : http://www.reductivelabs.com/trac/puppet/wiki/PuppetBestPractice. It seems as if the structure here doesn''t map to the default puppet layout (and thus doesn''t work with the standard puppet config files), so does anybody have any tips on the best way to take this from subversion and put it ''live'' ? Thanks, Rob
--On July 11, 2007 11:28:57 AM +0100 robl <robl@monkeyhelper.com> wrote:> Hi, > > I''m a new puppet user (thanks !) and I''m just looking at moving my > homegrown manifest structure into something resembling the best practise > guide at : > http://www.reductivelabs.com/trac/puppet/wiki/PuppetBestPractice. It > seems as if the structure here doesn''t map to the default puppet layout > (and thus doesn''t work with the standard puppet config files), so does > anybody have any tips on the best way to take this from subversion and > put it ''live'' ?When I deploy a new puppetmaster, I delete the empty directories under /var/lib/puppet and do a svn checkout start into that. I usually have to check out the master, dist, and modules separately.. It would be nice if the default layout was more compatible with the Best Practice or vice-versa.
(This email is as much an exercise of figuring out the ''right thing to do'' as it is a sharing of my thoughts on the subject. I am beginning, in earnest, to implement Puppet at my company and I running into this exact quandary: Best Practices File Hierarchy and default layout from EPEL packages.) Do the most common packagings of Puppet (RedHat, Debian, Solaris, etc.) use ''/var/lib/puppet''? (I am only using Fedora-EPEL packaging for RedHat) (http://fedoraproject.org/wiki/EPEL) General observation: Use of ''/var/lib/puppet'' is FHS-compliant, which is a good thing. (http://en.wikipedia.org/wiki/Filesystem_hierarchy_standard) Per Digant in his last email on this subject:>It would be nice if the default layout was more compatible with theBest Practice or vice-versa. I, generally speaking, like the Best Practice File Hierarchy (BPFH) well enough. My only real ''complaint'' is that it doesn''t mesh with FHS. I would argue that one should either: A) use /opt/puppet/<BPFH> (IMO, consistent with FHS) Or B) revise the BPFH to fit within FHS and ''/var/lib/puppet'' (per Digant''s comment) Option A) makes revision control of the BPFH *much* easier than B). Option B) would, it seems, require a lot of re-work and a much more complicated process of integration with a revision control system. When using the EPEL packaging of Puppetmaster, you''d need to update ''/etc/sysconfig/puppetmaster'' to include the directive: ''PUPPETMASTER_MANIFEST=/opt/puppet/master/manifests/site.pp'', Secondly, then there are a number of additional configuration changes one needs to make: 1) Configuration directives for puppetmaster: $manifestdir -> ''/opt/puppet/master/manifests'' (default: ''$confdir/manifests'') $modulepath -> ''/opt/puppet/modules'' (default: ''$confdir/modules'') $templatedir -> ''/opt/puppet/master/templates'' (default: ''$vardir/templates'') (for the puppet-server RPM, using ''PUPPETMASTER_EXTRA_OPTS='' in ''/etc/sysconfig/puppetmaster'' to set these parameters) 2) Configuration directives for the fileserver: ''path /opt/puppet/dist'' What are people''s observations, or concerns, with using ''/opt/puppet'' for the storing of the BPFH? Robb Wagoner Senior Systems and Database Administrator Klir Technologies 206-902-2028 robbw@klir.com -----Original Message----- From: puppet-users-bounces@madstop.com [mailto:puppet-users-bounces@madstop.com] On Behalf Of Digant C Kasundra Sent: Wednesday, July 11, 2007 6:35 AM To: Puppet User Discussion Subject: Re: [Puppet-users] Best practise guide --On July 11, 2007 11:28:57 AM +0100 robl <robl@monkeyhelper.com> wrote:> Hi, > > I''m a new puppet user (thanks !) and I''m just looking at moving my > homegrown manifest structure into something resembling the best > practise guide at : > http://www.reductivelabs.com/trac/puppet/wiki/PuppetBestPractice. It > seems as if the structure here doesn''t map to the default puppet > layout (and thus doesn''t work with the standard puppet config files), > so does anybody have any tips on the best way to take this from > subversion and put it ''live'' ?When I deploy a new puppetmaster, I delete the empty directories under /var/lib/puppet and do a svn checkout start into that. I usually have to check out the master, dist, and modules separately.. It would be nice if the default layout was more compatible with the Best Practice or vice-versa. _______________________________________________ Puppet-users mailing list Puppet-users@madstop.com https://mail.madstop.com/mailman/listinfo/puppet-users
Hi, Robb Wagoner wrote:> What are people''s observations, or concerns, with using ''/opt/puppet'' > for the storing of the BPFH?I''d rather it comply with the FHS right out of the box. I''ve done a little work with the FHS (analyzing an awful commercial product) and it shouldn''t be too difficult to make happen. Meaning: I''m willing to help recode things. :) -- Bob
> I''d rather it comply with the FHS right out of the box.You are advocating option B): revise the BPFH to fit within FHS and ''/var/lib/puppet'' Correct?> I''m willing to help recode things.What do you propose? -Robb -----Original Message----- From: puppet-users-bounces@madstop.com [mailto:puppet-users-bounces@madstop.com] On Behalf Of Bob Apthorpe Sent: Thursday, July 26, 2007 10:58 AM To: Puppet User Discussion Subject: Re: [Puppet-users] Best practise guide Hi, Robb Wagoner wrote:> What are people''s observations, or concerns, with using ''/opt/puppet'' > for the storing of the BPFH?I''d rather it comply with the FHS right out of the box. I''ve done a little work with the FHS (analyzing an awful commercial product) and it shouldn''t be too difficult to make happen. Meaning: I''m willing to help recode things. :) -- Bob _______________________________________________ Puppet-users mailing list Puppet-users@madstop.com https://mail.madstop.com/mailman/listinfo/puppet-users
Robb Wagoner wrote:> Do the most common packagings of Puppet (RedHat, Debian, Solaris, etc.) > use ''/var/lib/puppet''? (I am only using Fedora-EPEL packaging for > RedHat) > (http://fedoraproject.org/wiki/EPEL)I personally think under /etc/puppet/manifests is a little clumsy. I would have thought under /var/lib/puppet would fit with most Linux distros. But it does assume that all configuration is under revision control: "This hierarchy holds state information pertaining to an application or the system. State information is data that programs modify while they run, and that pertains to one specific host. Users must never need to modify files in /var/lib to configure a package''s operation." (http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLIBVARIABLESTATEINFORMATION) The most appropriate place is probably /opt but I don''t see a lot of people in the Linux-space packaging under /opt. Regards James Turnbull -- James Turnbull <james@lovedthanlost.net> --- Author of Pro Nagios 2.0 (http://www.amazon.com/gp/product/1590596099/) Hardening Linux (http://www.amazon.com/gp/product/1590594444/) --- PGP Key (http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x0C42DF40) _______________________________________________ Puppet-users mailing list Puppet-users@madstop.com https://mail.madstop.com/mailman/listinfo/puppet-users
> The most appropriate place is probably /opt but I don''t see a lot ofpeople in the Linux-space packaging under /opt. I don''t think one should package tools for delivery under /opt. I am thinking the packages should stay ''as-is''. I am seeing it this way: The manifests are created outside of Puppet itself. I tend to think of human generated content, or files / data generated by non-packaged tools as being well suited for placement in /opt. In the case of RPM/DEB (and presumably other package mgmt systems) our content (manifests/modules/templates) stay out of the way of the system processes, ''/var/lib/puppet'' being quite active in that regard. -----Original Message----- From: puppet-users-bounces@madstop.com [mailto:puppet-users-bounces@madstop.com] On Behalf Of James Turnbull Sent: Thursday, July 26, 2007 3:20 PM To: Puppet User Discussion Subject: Re: [Puppet-users] Best practise guide Robb Wagoner wrote:> Do the most common packagings of Puppet (RedHat, Debian, Solaris, > etc.) use ''/var/lib/puppet''? (I am only using Fedora-EPEL packaging > for > RedHat) > (http://fedoraproject.org/wiki/EPEL)I personally think under /etc/puppet/manifests is a little clumsy. I would have thought under /var/lib/puppet would fit with most Linux distros. But it does assume that all configuration is under revision control: "This hierarchy holds state information pertaining to an application or the system. State information is data that programs modify while they run, and that pertains to one specific host. Users must never need to modify files in /var/lib to configure a package''s operation." (http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLIBVARIABLESTATEINFORMA TION) The most appropriate place is probably /opt but I don''t see a lot of people in the Linux-space packaging under /opt. Regards James Turnbull -- James Turnbull <james@lovedthanlost.net> --- Author of Pro Nagios 2.0 (http://www.amazon.com/gp/product/1590596099/) Hardening Linux (http://www.amazon.com/gp/product/1590594444/) --- PGP Key (http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x0C42DF40)
Robb Wagoner wrote:>> The most appropriate place is probably /opt but I don''t see a lot of > people in the Linux-space packaging under /opt. > > I don''t think one should package tools for delivery under /opt. I amWell is the intent of /opt in FHS. It''s not designed to hold stand-alone configuration but rather whole application packages. Variable data for /opt packages should be stored in /var/opt. So I don''t think you should just migrate Puppet configuration only to /opt. That doesn''t seem to make sense from an FHS perspective to me. I also don''t think you should migrate the whole package either - hence the comment about lack of people packaging under /opt. Regards James Turnbull -- James Turnbull <james@lovedthanlost.net> --- Author of Pro Nagios 2.0 (http://www.amazon.com/gp/product/1590596099/) Hardening Linux (http://www.amazon.com/gp/product/1590594444/) --- PGP Key (http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x0C42DF40) _______________________________________________ Puppet-users mailing list Puppet-users@madstop.com https://mail.madstop.com/mailman/listinfo/puppet-users
IMO if you want you can make /opt/puppet/ and create symlinks to etc / var/lib/puppet /var/lib or whatnot .. in my org /opt isn''t on its own partition/LVM-LV and dumping crap in there fills up root which no one likes! On Jul 26, 2007, at 3:41 PM, Robb Wagoner wrote:> > The most appropriate place is probably /opt but I don''t see a lot of > people in the Linux-space packaging under /opt. > > I don''t think one should package tools for delivery under /opt. I am > thinking the packages should stay ''as-is''. I am seeing it this way: > The > manifests are created outside of Puppet itself. I tend to think of > human > generated content, or files / data generated by non-packaged tools as > being well suited for placement in /opt. In the case of RPM/DEB (and > presumably other package mgmt systems) our content > (manifests/modules/templates) stay out of the way of the system > processes, ''/var/lib/puppet'' being quite active in that regard. > > > > -----Original Message----- > From: puppet-users-bounces@madstop.com > [mailto:puppet-users-bounces@madstop.com] On Behalf Of James Turnbull > Sent: Thursday, July 26, 2007 3:20 PM > To: Puppet User Discussion > Subject: Re: [Puppet-users] Best practise guide > > Robb Wagoner wrote: > > Do the most common packagings of Puppet (RedHat, Debian, Solaris, > > etc.) use ''/var/lib/puppet''? (I am only using Fedora-EPEL packaging > > for > > RedHat) > > (http://fedoraproject.org/wiki/EPEL) > > I personally think under /etc/puppet/manifests is a little clumsy. I > would have thought under /var/lib/puppet would fit with most Linux > distros. But it does assume that all configuration is under revision > control: > > "This hierarchy holds state information pertaining to an > application or > the system. State information is data that programs modify while they > run, and that pertains to one specific host. Users must never need to > modify files in /var/lib to configure a package''s operation." > > (http://www.pathname.com/fhs/pub/ > fhs-2.3.html#VARLIBVARIABLESTATEINFORMA > TION) > > The most appropriate place is probably /opt but I don''t see a lot of > people in the Linux-space packaging under /opt. > > Regards > > James Turnbull > > -- > James Turnbull <james@lovedthanlost.net> > --- > Author of Pro Nagios 2.0 > (http://www.amazon.com/gp/product/1590596099/) > > Hardening Linux > (http://www.amazon.com/gp/product/1590594444/) > --- > PGP Key (http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x0C42DF40) > > _______________________________________________ > Puppet-users mailing list > Puppet-users@madstop.com > https://mail.madstop.com/mailman/listinfo/puppet-users >
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday 26 July 2007, Robb Wagoner wrote:> (This email is as much an exercise of figuring out the ''right thing to > do'' as it is a sharing of my thoughts on the subject. I am beginning, in > earnest, to implement Puppet at my company and I running into this exact > quandary: Best Practices File Hierarchy and default layout from EPEL > packages.) > > Do the most common packagings of Puppet (RedHat, Debian, Solaris, etc.) > use ''/var/lib/puppet''? (I am only using Fedora-EPEL packaging for > RedHat) > (http://fedoraproject.org/wiki/EPEL) > > General observation: > Use of ''/var/lib/puppet'' is FHS-compliant, which is a good thing. > (http://en.wikipedia.org/wiki/Filesystem_hierarchy_standard) > > Per Digant in his last email on this subject: > >It would be nice if the default layout was more compatible with the > > Best Practice or vice-versa. > > I, generally speaking, like the Best Practice File Hierarchy (BPFH) well > enough. My only real ''complaint'' is that it doesn''t mesh with FHS. > > I would argue that one should either: > > A) use /opt/puppet/<BPFH> (IMO, consistent with FHS) > Or > B) revise the BPFH to fit within FHS and ''/var/lib/puppet'' (per Digant''s > comment) > > Option A) makes revision control of the BPFH *much* easier than B). > Option B) would, it seems, require a lot of re-work and a much more > complicated process of integration with a revision control system.According to http://www.pathname.com/fhs/pub/fhs-2.3.html#SRVDATAFORSERVICESPROVIDEDBYSYSTEM , data for services provided by this system should go to /srv The rationale from there:> This main purpose of specifying this is so that users may find the location > of the data files for particular service, and so that services which > require a single tree for readonly data, writable data and scripts (such as > cgi scripts) can be reasonably placed. Data that is only of interest to a > specific user should go in that users'' home directory. > > The methodology used to name subdirectories of /srv is unspecified as there > is currently no consensus on how this should be done. One method for > structuring data under /srv is by protocol, eg. ftp, rsync, www, and cvs. > On large systems it can be useful to structure /srv by administrative > context, such as /srv/physics/www, /srv/compsci/cvs, etc. This setup will > differ from host to host. Therefore, no program should rely on a specific > subdirectory structure of /srv existing or data necessarily being stored in > /srv. However /srv should always exist on FHS compliant systems and should > be used as the default location for such data. > > Distributions must take care not to remove locally placed files in these > directories without administrator permission.This would suggest a hierarchy like this: /srv/ + puppet/ ++ manifests/ ++ files/ ++ templates/ ++ modules/ That can be kept under version control completely without colliding with anything. Config files (puppet.conf) would stay in /etc/puppet and localstate.yaml (and friends) in /var/lib/puppet where they belong respectivly. Regards, David - -- - - hallo... wie gehts heute? - - *hust* gut *rotz* *keuch* - - gott sei dank kommunizieren wir über ein septisches medium ;) -- Matthias Leeb, Uni f. angewandte Kunst, 2005-02-15 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGqbei/Pp1N6Uzh0URAr4pAKCHJyzXha7xwnZF+6IUPD2beWGv3ACfRW+x QutrVVAt43LLLbBr1zUeMq4=DVwW -----END PGP SIGNATURE-----
> data for services provided by this system should go to /srvYes. This is a good point, David. Thank you for pointing it out. Clearly, the right place to put the BPFH.> That can be kept under version control completely without colliding with anything. Config files (puppet.conf) would stay in /etc/puppet and localstate.yaml (and friends) in /var/lib/puppet where they belong respectivly.Agreed. All: I don''t have immediate access to any other platforms than recent RedHat and recent Debian systems. From some searching, it looks like OS X deviates from FHS, (which is not surprising) and does not have a ''/srv''. It am betting that Solaris does not either. I expect that BSD variants DO adhere to FHS, and thus use of ''/srv/puppet'' would not be problematic. So, from a Best Practice stand point, I think it would make sense to update it to *suggest* that Linux (and BSD?) admins store their File Hierarchy in ''/srv/puppet''. Any objections to my doing so? Thank you, Robb Wagoner Senior Systems and Database Administrator Klir Technologies 206-902-2028 robbw@klir.com -----Original Message----- From: puppet-users-bounces@madstop.com [mailto:puppet-users-bounces@madstop.com] On Behalf Of David Schmitt Sent: Friday, July 27, 2007 2:15 AM To: puppet-users@madstop.com Subject: Re: [Puppet-users] Best practise guide -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday 26 July 2007, Robb Wagoner wrote:> (This email is as much an exercise of figuring out the ''right thing to > do'' as it is a sharing of my thoughts on the subject. I am beginning, > in earnest, to implement Puppet at my company and I running into this > exact > quandary: Best Practices File Hierarchy and default layout from EPEL > packages.) > > Do the most common packagings of Puppet (RedHat, Debian, Solaris, > etc.) use ''/var/lib/puppet''? (I am only using Fedora-EPEL packaging > for > RedHat) > (http://fedoraproject.org/wiki/EPEL) > > General observation: > Use of ''/var/lib/puppet'' is FHS-compliant, which is a good thing. > (http://en.wikipedia.org/wiki/Filesystem_hierarchy_standard) > > Per Digant in his last email on this subject: > >It would be nice if the default layout was more compatible with the > > Best Practice or vice-versa. > > I, generally speaking, like the Best Practice File Hierarchy (BPFH) > well enough. My only real ''complaint'' is that it doesn''t mesh with FHS. > > I would argue that one should either: > > A) use /opt/puppet/<BPFH> (IMO, consistent with FHS) Or > B) revise the BPFH to fit within FHS and ''/var/lib/puppet'' (per > Digant''s > comment) > > Option A) makes revision control of the BPFH *much* easier than B). > Option B) would, it seems, require a lot of re-work and a much more > complicated process of integration with a revision control system.According to http://www.pathname.com/fhs/pub/fhs-2.3.html#SRVDATAFORSERVICESPROVIDEDBYSYSTEM , data for services provided by this system should go to /srv The rationale from there:> This main purpose of specifying this is so that users may find the > location of the data files for particular service, and so that > services which require a single tree for readonly data, writable data > and scripts (such as cgi scripts) can be reasonably placed. Data that > is only of interest to a specific user should go in that users'' home directory. > > The methodology used to name subdirectories of /srv is unspecified as > there is currently no consensus on how this should be done. One method > for structuring data under /srv is by protocol, eg. ftp, rsync, www, and cvs. > On large systems it can be useful to structure /srv by administrative > context, such as /srv/physics/www, /srv/compsci/cvs, etc. This setup > will differ from host to host. Therefore, no program should rely on a > specific subdirectory structure of /srv existing or data necessarily > being stored in /srv. However /srv should always exist on FHS > compliant systems and should be used as the default location for such data. > > Distributions must take care not to remove locally placed files in > these directories without administrator permission.This would suggest a hierarchy like this: /srv/ + puppet/ ++ manifests/ ++ files/ ++ templates/ ++ modules/ That can be kept under version control completely without colliding with anything. Config files (puppet.conf) would stay in /etc/puppet and localstate.yaml (and friends) in /var/lib/puppet where they belong respectivly. Regards, David - -- - - hallo... wie gehts heute? - - *hust* gut *rotz* *keuch* - - gott sei dank kommunizieren wir über ein septisches medium ;) -- Matthias Leeb, Uni f. angewandte Kunst, 2005-02-15 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGqbei/Pp1N6Uzh0URAr4pAKCHJyzXha7xwnZF+6IUPD2beWGv3ACfRW+x QutrVVAt43LLLbBr1zUeMq4=DVwW -----END PGP SIGNATURE----- _______________________________________________ Puppet-users mailing list Puppet-users@madstop.com https://mail.madstop.com/mailman/listinfo/puppet-users
On Jul 27, 2007, at 8:11 AM, Robb Wagoner wrote:> So, from a Best Practice stand point, I think it would make sense > to update it to *suggest* that Linux (and BSD?) admins store their > File Hierarchy in ''/srv/puppet''. > Any objections to my doing so?I''ve been at OSCON all week and thus very quiet on this subject (and everything else) but I just wanted to make it clear that I''m perfectly willing to change Puppet''s default layout to whatever the community decides makes sense. I have no attachment at all to the current structure. There will be some backward compatibility concerns, but they won''t be too bad, I think. -- Every generation laughs at the old fashions, but follows religiously the new. -- Henry David Thoreau --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
I think the layout of Puppet itself is just fine Luke. It''s consistent, overall, with FHS. I was finding myself hung-up on where I should put the Best Practices File Hierarchy. . . Hope your Wednesday session on Puppet went well. Robb -----Original Message----- From: puppet-users-bounces@madstop.com [mailto:puppet-users-bounces@madstop.com] On Behalf Of Luke Kanies Sent: Friday, July 27, 2007 10:37 AM To: Puppet User Discussion Subject: Re: [Puppet-users] Best practise guide On Jul 27, 2007, at 8:11 AM, Robb Wagoner wrote:> So, from a Best Practice stand point, I think it would make sense to > update it to *suggest* that Linux (and BSD?) admins store their File > Hierarchy in ''/srv/puppet''. > Any objections to my doing so?I''ve been at OSCON all week and thus very quiet on this subject (and everything else) but I just wanted to make it clear that I''m perfectly willing to change Puppet''s default layout to whatever the community decides makes sense. I have no attachment at all to the current structure. There will be some backward compatibility concerns, but they won''t be too bad, I think. -- Every generation laughs at the old fashions, but follows religiously the new. -- Henry David Thoreau --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com _______________________________________________ Puppet-users mailing list Puppet-users@madstop.com https://mail.madstop.com/mailman/listinfo/puppet-users
Robb Wagoner wrote:> I don''t have immediate access to any other platforms than recent RedHat and recent Debian systems. From some searching, it looks like OS X deviates from FHS, (which is not surprising) and does not have a ''/srv''. It am betting that Solaris does not either. I expect that BSD variants DO adhere to FHS, and thus use of ''/srv/puppet'' would not be problematic. > > So, from a Best Practice stand point, I think it would make sense to update it to *suggest* that Linux (and BSD?) admins store their File Hierarchy in ''/srv/puppet''. > Any objections to my doing so?Neither OS X (which is a *BSD derivative) nor any of the *BSDs have /srv (http://www.freebsd.org/cgi/man.cgi?query=hier) by default. Regards James Turnbull -- James Turnbull <james@lovedthanlost.net> --- Author of Pro Nagios 2.0 (http://www.amazon.com/gp/product/1590596099/) Hardening Linux (http://www.amazon.com/gp/product/1590594444/) --- PGP Key (http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x0C42DF40) _______________________________________________ Puppet-users mailing list Puppet-users@madstop.com https://mail.madstop.com/mailman/listinfo/puppet-users
On Fri, 2007-07-27 at 08:11 -0700, Robb Wagoner wrote:> So, from a Best Practice stand point, I think it would make sense to > update it to *suggest* that Linux (and BSD?) admins store their File > Hierarchy in ''/srv/puppet''. > Any objections to my doing so?As a FreeBSD admin deploying puppet, I would request that you *not* advocate using /srv. FreeBSD doesn''t use /srv and I hate the idea of adding clutter to my root (/). Dane -- Dane Miller Systems Administrator Great Schools, Inc http://greatschools.net
On Fri, 2007-07-27 at 10:37 -0700, Luke Kanies wrote:> On Jul 27, 2007, at 8:11 AM, Robb Wagoner wrote: > > > So, from a Best Practice stand point, I think it would make sense > > to update it to *suggest* that Linux (and BSD?) admins store their > > File Hierarchy in ''/srv/puppet''. > > Any objections to my doing so? > > I''ve been at OSCON all week and thus very quiet on this subject (and > everything else) but I just wanted to make it clear that I''m > perfectly willing to change Puppet''s default layout to whatever the > community decides makes sense. I have no attachment at all to the > current structure.Concerning /srv in particular: my understanding is that no package should ever touch /srv - it should be completely under the control of local admins; thus the default config files shouldn''t try to put anything there, though maybe a comment in the config file that comes with the rpm won''t hurt. David
On Thu, 2007-07-26 at 09:51 -0700, Robb Wagoner wrote:> When using the EPEL packaging of Puppetmaster, you''d need to update > ''/etc/sysconfig/puppetmaster'' to include the directive: > > ''PUPPETMASTER_MANIFEST=/opt/puppet/master/manifests/site.pp'',As you said, the same thing can be done by setting manifestdir in puppet.conf - that''s much preferrable. I am really not happy about the fact that I added files in /etc/sysconfig; I would love to remove them, but it''s more upgrade trouble than it''s worth. David
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Saturday 28 July 2007, David Lutterkort wrote:> On Fri, 2007-07-27 at 10:37 -0700, Luke Kanies wrote: > > On Jul 27, 2007, at 8:11 AM, Robb Wagoner wrote: > > > So, from a Best Practice stand point, I think it would make sense > > > to update it to *suggest* that Linux (and BSD?) admins store their > > > File Hierarchy in ''/srv/puppet''. > > > Any objections to my doing so? > > > > I''ve been at OSCON all week and thus very quiet on this subject (and > > everything else) but I just wanted to make it clear that I''m > > perfectly willing to change Puppet''s default layout to whatever the > > community decides makes sense. I have no attachment at all to the > > current structure. > > Concerning /srv in particular: my understanding is that no package > should ever touch /srv - it should be completely under the control of > local admins; thus the default config files shouldn''t try to put > anything there, though maybe a comment in the config file that comes > with the rpm won''t hurt.Yeah, the "I just want to install the package and distribute a small manifest" user is probably well enough served with manifests and data in /etc/puppet. The Best Practice for bigger installations should be changed though. In that case a example config file which already has the right layout would be cool. Then it''s only a matter of creating the directories and doing "git init" or whatever there. Regards, David - -- - - hallo... wie gehts heute? - - *hust* gut *rotz* *keuch* - - gott sei dank kommunizieren wir über ein septisches medium ;) -- Matthias Leeb, Uni f. angewandte Kunst, 2005-02-15 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGqvfv/Pp1N6Uzh0URAgE0AJwMzzfUygmxFMb0ZiUlvYjQSIcRjACfTiBn bEfuVyTDRhQcZCOglVdP5WM=2LfJ -----END PGP SIGNATURE-----