From owner-svn-src-head@freebsd.org Mon May 15 19:29:54 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 EE96ED6E71E; Mon, 15 May 2017 19:29:54 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from mail.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) (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 C7495D18; Mon, 15 May 2017 19:29:54 +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 885A210A7B9; Mon, 15 May 2017 15:29:53 -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 12:22:50 -0700 Message-ID: <4703731.Pl02uSWy7k@ralph.baldwin.cx> User-Agent: KMail/4.14.10 (FreeBSD/11.0-STABLE; KDE/4.14.10; amd64; ; ) In-Reply-To: <1494870201.59865.103.camel@freebsd.org> References: <201705131537.v4DFbgWV045290@pdx.rh.CN85.dnsmgr.net> <2229085.lB46rKsq7o@ralph.baldwin.cx> <1494870201.59865.103.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 15:29:53 -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 19:29:55 -0000 On Monday, May 15, 2017 11:43:21 AM Ian Lepore wrote: > On Mon, 2017-05-15 at 10:13 -0700, John Baldwin wrote: > > On Saturday, May 13, 2017 10:39:15 AM Warner Losh wrote: > > > > > > > > > > > > > > > > > - It's really easy to screw up a mergemaster call if you edit > > > > > the files, and install the stock version which removes the > > > > > edits. > > > > Also, programmatically removing the entries means you have to > > > > bake the metadata into etc/Makefile, which is already complicated > > > > enough as-is. > > > Why do you care about removing them at all? They are no-ops if the > > > files don't exist. Why not just always install all these files is > > > where I'm going with this... > > I think this is actually the bigger question. I think it is > > perfectly > > sensible to support conf.d/* files for ports to use and as a way to > > manage logs for application logs on an appliance, etc. However, this > > shuffling is a bit of a merge nightmare for anyone using mergemaster > > or etcupdate, and the biggest cost is that newsyslog will create a > > one-line file in /var/log for entries with 'C'. > > > > That's only a good argument for keeping the lines in the monolithic > file if those lines will be ignored when a file in the .conf.d > directory provides conflicting config. Otherwise my embedded product > that drops different rules for rotating /var/log/messages into .conf.d > STILL has to programmatically edit the monolithic file to remove the > standard rule(s). Now you have to programmatically edit the file in conf.d/foo. However, by this argument the monolithic conf file shouldn't even exist. The current approach is a half-way mix with the worst of both models it seems. 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: 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) -- John Baldwin