>>>>
>>>>
>>>
>>> $ cp /usr/lib/$proj/foo.conf /etc/$proj/
>>
>> Which is not trivial, really.
Well, it IS, but in the same way that "rm -rf /" is trivial. It's easy to do,
but some non-trivial thought should occur before doing it.
> Put another way: would it really be /usr/lib/$proj, or rather (since
> it's arch-independent) /usr/share/$proj, or rather (since that's
> documentation) /usr/share/do/$proj. How an admin would know? That's just
> hiding things, compared to the decades of habits.
>
> Also, /etc would thus be full of empty /etc/$proj directories? I don't
> see the point of not just putting the example files there? Why making it
> more difficult for the admin to configure their server?
This is how Splunk does it.
All project files are in $SPLUNK_HOME (hereafter $SH for brevity).
$SH/etc/system/default/thing.conf # defaults. strongly recommended not
to edit.
$SH/etc/system/local/thing.conf # read next. admin overrides for defaults.
does not have to exist.
$SH/etc/apps/$module/default/thing.conf # module-level "default overrides".
system-level changes (if any) required for $module. do not edit
$SH/etc/apps/$module/local/thing.conf # module-level admin overrides for all
of the above.
The part that's relevant to this conversation is that *everything* is under
$SH/etc/ (and always *.conf). It makes it feasible to do things like:
find $SH/etc -type f -name thing.conf -exec grep -H 'setting' + \;
Good luck doing that with config files in 5+ places all over the filesystem.
--J
