On Feb 20, 2013, at 6:57 AM, Adrien Thebo <[email protected]> wrote:
> 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. > How about the provider just writes it out as a temp file when it needs it? If it is static, should never be edited, and is needed for the provider to execute correctly, then I can see just keeping it the code and writing it out when needed. Also, I believe it was not a very large file, so it won't bloat the code. > > 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. > > -- 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.
