Date: Mon, 15 May 2017 12:22:50 -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: <4703731.Pl02uSWy7k@ralph.baldwin.cx> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4703731.Pl02uSWy7k>