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

[Ian Lepore]

On Mon, 2017-05-15 at 14:11 -0600, Ian Lepore wrote:
> On Mon, 2017-05-15 at 12:22 -0700, John Baldwin wrote:
> > 
> > On Monday, May 15, 2017 11:43:21 AM Ian Lepore 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.
> 

And just to be clear here, I'm talking about running some kind of
merge/edit on the live system being updated in the field, not as part
of importing a newer freebsd snapshot into our VCS.

-- Ian