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

[John Baldwin]

On Monday, May 15, 2017 02:11:53 PM Ian Lepore wrote:
> On Mon, 2017-05-15 at 12:22 -0700, John Baldwin wrote:
> > Also, _you_ could just splat an empty /etc/newsyslog.conf file on
> > your
> > appliance and create a bunch of conf.d/foo files if that is easier
> > for
> > you to use on an appliance.  The files we ship in a release aren't
> > really
> > tailored for an appliance (I've yet to see an appliance that doesn't
> > use
> > a FooBSD with local patches).  OTOH, the existing setup is probably
> > simpler to manage for an out-of-the-box install.
> > 
> > I'm also suprised you don't manage the newsyslog.conf file yourself
> > rather than trying to edit and merge in upstream changes?  That is, I
> > can see a few approaches:
> > 
> 
> You seem to be picturing some sort of etcupdate kind of thing.  I'm
> more talking about a GUI or other config-management tool within an
> embedded product that has to edit or rewrite configuration on the fly
> based on user choices.
> 
> Of course, separate files does also simplify the update process, for
> the most part.  If a new subsystem is added in a new freebsd release, I
> have zero work to do to upgrade a system in the field if that new
> subsystem just drops a new file into a .conf.d directory.  If it has
> new entries in a monolithic file, then I do have to do some sort of
> merge/edit operation.

But given that the new system now supports both approaches, why wouldn't
you always split it up in your product?

> > 1) Keep your real newsyslog.conf / syslogd.conf files in your
> > FooBSD's
> >    VCS and when newsyslog.conf changes upstream you merge that in the
> >    way you normally merge changes.
> > 
> > 2) Move the "vendor" newsyslog.conf out entirely and install your own
> >    versions of these files either as a monolithic assembled by config
> >    management rules or a bunch of conf.d/foo files (here I would
> > probably
> >    opt for separate files).
> > 
> > However, your approach doesn't seem to describe either of these since
> > this commit doesn't impact those work flows (if 1), you would have
> > already
> > made any local changes you need and if anything merging this commit
> > gives
> > you the kind of merge conflicts people will get on the next
> > mergemaster /
> > etcupdate for non-appliance boxes, or if 2) you ignore these files)
> > 
> 
> This seems to be an argument for everyone doing for themselves the
> operation of splitting the distributed monolithic file into finer
> grained files, and re-performing that operation (or at least the
> analysis part of it) on every update.

s/everbody/appliance vendors/.  Not everyone is your use case (nor mine).

That said, I would think that the current approach is still the worst
of both worlds for you.  Now you have a single file you need to edit
in some cases and in other cases you generate the single foo.conf
file.  I don't see why you wouldn't always want to split things up in
your product and on the rare chance that the big file changes upstream
you alter the default broken-out file in your FooBSD (especially given
how rarely these files change).

> In general a lot of this feels like "I only needed 6 big config files
> to control my whole system in 1988, and so I should only need those
> same 6 files now."  Sure, all us old-timers have the finger memory for
> editing rc.conf and syslog.conf and so on, but how often do you crack
> open syslog.conf with the plan of editing 12 different lines in it at
> once?  Because the main objection to .conf.d directories seems to be
> that there are more files to edit, and that just doesn't feel like a
> big problem in actual daily use.

To be clear, I _don't_ object to conf.d directories and I'm happy to
have the tools support both types of configurations.  I object to
employing a half-way mix of both styles in a way that breaks POLA and
causes merge headaches for existing users that are applying these
changes as upgrades to existing systems.

-- 
John Baldwin