The FHS says conf files don't live in /usr, especially your data dir. (Keep in mind the FHS follows some old-school ideas, like /usr should be able to be mounted Read-Only.).
Anyway, a conf file, if needed should be in /etc. If it's for a specific provider, ideally it would be something like /etc/puppet/user or libuser with the conf file under that directory. Now for the rulebreakers like gems, (and many other language library bundles), you would basically put the file in the libdir. Then packaging would correct Puppet's lack of FHS adherence. This is very common, you'll often see packages with symlinks in /usr/share/gems (or wherever else) into /etc where the actual file will live ater proper packaging. I'd really rather not see Puppet do this, (put a conf file in /usr). We know better. :) Maybe we just munge it in the gem layout, and put it in the gemdir, and do it correctly (from an FHS perspective) by default? Alternatively, Puppet could just look in /etc first and fallback to the libdir if /etc isn't there. On Tue, Feb 19, 2013 at 4:35 PM, Adrien Thebo <[email protected]> wrote: > Hi all, > > I'm hoping to get community feedback on dealing with external data or > configuration that needs to be shipped with Puppet. Pull request #1442 ( > https://github.com/puppetlabs/puppet/pull/1442) added support for > managing local users and groups by using libuser, solving issue 7911 ( > http://projects.puppetlabs.com/issues/7911). However to make libuser work > in a consistent manner it has to supply a specific libuser.conf config > file. We weren't able to come to a decision onto where this file should > ultimately go and I was hoping to collect some outside opinion. > > The ideal solution for this sort of thing is to use the FHS concept of an > application datadir, eg /usr/share/puppet. Installing Puppet would drop the > libuser.conf in a path like /usr/share/puppet/provider/libuser.conf and > Puppet would check $datadir/provider/libuser.conf for that configuration > file. Shipping configuration data in lib/ is definitely ideal and this > would address that problem. > > While this approach works swimmingly when puppet is installed by hand or > by package, but this completely breaks down when installing via a gem. > Since gems are entirely self contained in a directory the $datadir location > would have to change for gems. In short, any sort of datadir solution that > would mesh with gems fails with normal packages. > > It's foreseeable that we might have more configuration like this; data > that shouldn't be edited by the end user that Puppet needs to run. Stuffing > files into lib/ isn't a viable solution in the long run; does anyone see a > better way of addressing this? > > -- > Adrien Thebo | Puppet Labs > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/puppet-dev?hl=en. > For more options, visit https://groups.google.com/groups/opt_out. > > > -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/puppet-dev?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
