Date: Mon, 15 May 2017 14:14:29 -0700 From: John Baldwin <jhb@freebsd.org> To: Ian Lepore <ian@freebsd.org> Cc: Warner Losh <imp@bsdimp.com>, Ngie Cooper <yaneurabeya@gmail.com>, "Rodney W. Grimes" <rgrimes@freebsd.org>, Ngie Cooper <ngie@freebsd.org>, src-committers <src-committers@freebsd.org>, "svn-src-all@freebsd.org" <svn-src-all@freebsd.org>, "svn-src-head@freebsd.org" <svn-src-head@freebsd.org> Subject: Re: svn commit: r318250 - in head: etc etc/newsyslog.conf.d etc/syslog.d tools/build/mk Message-ID: <1767029.V8VxJpCATJ@ralph.baldwin.cx> In-Reply-To: <1494879113.59865.129.camel@freebsd.org> References: <201705131537.v4DFbgWV045290@pdx.rh.CN85.dnsmgr.net> <4703731.Pl02uSWy7k@ralph.baldwin.cx> <1494879113.59865.129.camel@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1767029.V8VxJpCATJ>