One clarification - this file is a configuration file but it's going to be static, and specifically non-editable by the user. /usr being mounted as read-only in this case would be fine. Effectively we're vendoring a static file that should not change. Since it's going to be a static file, /etc/puppet wouldn't be the best location because we're relying on it being static and if it's in /etc/puppet it might get changed, which could break things.
On Tue, Feb 19, 2013 at 8:14 PM, Michael Stahnke <[email protected]>wrote: > 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. > > > -- 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.
