svn commit: r318250 - in head: etc etc/newsyslog.conf.d etc/syslog.d tools/build/mk

[Ngie Cooper (yaneurabeya)]

> On May 13, 2017, at 9:51 AM, Alexey Dokuchaev <danfe at FreeBSD.org> wrote:
> 
> On Sat, May 13, 2017 at 10:24:20AM -0600, Ian Lepore wrote:
>> ...
>> The evolution for years has been away from monolithic config files
>> containing a mashup of values for unrelated subsystems and towards
>> .conf.d directories containing many single-subject files.
> 
> This "evolution" had probably originated in people's minds who know little
> about software development and maintenance.  And FWIW, newsyslog files are
> not about "unrelated subsystems", it's about one subsystem responsible for
> log rotation.

This hasn’t really changed with moving to .conf.d. A single subsystem is managing a series of modular config files, instead of a single config file. I firmly believe that this was the right general approach to go.

> Speaking of "unrelated subsystems", /etc/rc.conf is a living manifestation
> of how "unrelated subsystems" can be configured in a single file and, mind
> you, everyone is being quite happy about it.

… except people have to bake in defaults in rc.d scripts for whether or not services should be disabled because they can’t put apache defaults in /etc/rc.conf . /etc/rc.conf isn’t managed via etcupdate or mergemaster, so I think this comparison is like apples to oranges.

>> The monolithic files are difficult to edit
> 
> Quite on the contrary: monolithic files are much easier to edit and keep
> track of by a human being (system operator).

I strongly disagree, having seen multiple configuration files a couple hundred lines long. It gets messy and for those who don’t understand how syslogd/newsyslog works (inevitably, these people are the ones that get charged with implementing daemons, and this is one of the pieces that needs to be done).

>> and otherwise manage programmatically, and especially difficult to manage
>> in terms of software packaging and software updates.
> 
> Please don't mix "difficult to edit" and "manage programmatically".  As I
> have said, having support for "include *.conf.d" makes sense for 3rd-party
> software (read: ports), but has little need for the base, and IMHO brings
> more maintenance burden than any benefit.

Can you please provide an example of how it’s more burdensome going to .conf.d? Personally, I think it’s a whole lot easier doing `rm -f /etc/newsyslog.d/amd.conf`, than it is to open up the file and edit out the amd entries, or invoke sed/something else to do the same thing.

Even ansible/chef/puppet would have to bake the configuration removal logic into its template files, which seems like a pain for folks (and the same logic would need to be implemented multiple times instead of once).

Thanks,
-Ngie
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.freebsd.org/pipermail/svn-src-head/attachments/20170513/dc2d3bb7/attachment.sig>