From owner-svn-src-head@freebsd.org Mon May 15 21:14:50 2017 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4312AD6C143; Mon, 15 May 2017 21:14:50 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from mail.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 02F48E2D; Mon, 15 May 2017 21:14:49 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from ralph.baldwin.cx (c-73-231-226-104.hsd1.ca.comcast.net [73.231.226.104]) by mail.baldwin.cx (Postfix) with ESMTPSA id EDAD910A7DB; Mon, 15 May 2017 17:14:47 -0400 (EDT) From: John Baldwin To: Ian Lepore Cc: Warner Losh , Ngie Cooper , "Rodney W. Grimes" , Ngie Cooper , src-committers , "svn-src-all@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 Date: Mon, 15 May 2017 14:14:29 -0700 Message-ID: <1767029.V8VxJpCATJ@ralph.baldwin.cx> User-Agent: KMail/4.14.10 (FreeBSD/11.0-STABLE; KDE/4.14.10; amd64; ; ) 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> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail.baldwin.cx); Mon, 15 May 2017 17:14:48 -0400 (EDT) X-Virus-Scanned: clamav-milter 0.99.2 at mail.baldwin.cx X-Virus-Status: Clean X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 May 2017 21:14:50 -0000 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