Date: Thu, 18 May 2017 09:48:25 -0700 From: John Baldwin <jhb@freebsd.org> To: Baptiste Daroussin <bapt@freebsd.org> Cc: rgrimes@freebsd.org, Ngie Cooper <ngie@freebsd.org>, svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r318441 - in head/etc: . cron.d Message-ID: <2201156.H7EQSgYph9@ralph.baldwin.cx> In-Reply-To: <20170518130932.eo5clhki4za2vigz@ivaldir.net> References: <201705180625.v4I6Pd9j062495@repo.freebsd.org> <201705180956.v4I9uVpQ065465@pdx.rh.CN85.dnsmgr.net> <20170518130932.eo5clhki4za2vigz@ivaldir.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thursday, May 18, 2017 03:09:32 PM Baptiste Daroussin wrote: > On Thu, May 18, 2017 at 02:56:31AM -0700, Rodney W. Grimes wrote: > > > Author: ngie > > > Date: Thu May 18 06:25:39 2017 > > > New Revision: 318441 > > > URL: https://svnweb.freebsd.org/changeset/base/318441 > > > > > > Log: > > > Handle the cron.d entry for MK_AT in cron conditionally > > > > > > Install /etc/cron.d/at if MK_AT != no, always using it, which tries > > > to run a non-existent program via cron(8) every 5 minutes with the > > > default /etc/crontab, prior to this commit. > > > > > > SHELL and PATH are duplicated between /etc/crontab and /etc/cron.d/at > > > because atrun(8) executes programs, which may rely on environment > > > currently set via /etc/crontab. > > > > > > Noted by: bdrewery (in an internal review) > > > MFC after: 2 months > > > Relnotes: yes (may need to add environmental modifications to > > > /etc/cron.d/at) > > > Sponsored by: Dell EMC Isilon > > > > > > Added: > > > head/etc/cron.d/ > > > head/etc/cron.d/Makefile (contents, props changed) > > > head/etc/cron.d/at (contents, props changed) > > > Modified: > > > head/etc/Makefile > > > head/etc/crontab > > > > > > Modified: head/etc/Makefile > > > ============================================================================== > > > --- head/etc/Makefile Thu May 18 06:15:42 2017 (r318440) > > > +++ head/etc/Makefile Thu May 18 06:25:39 2017 (r318441) > > > @@ -8,6 +8,7 @@ FILESGROUPS= FILES > > > # No need as it is empty and just causes rebuilds since this file does so much. > > > UPDATE_DEPENDFILE= no > > > SUBDIR= \ > > > + cron.d \ > > > newsyslog.conf.d \ > > > syslog.d > > > > The thread on the newsyslog clearly shows that this is a contriversial change. > > > > I strongly object to further splitting of /etc/FOO into /etc/foo.d/FOO files > > to suite Dell/EMC/Isilon's needs. It is in conflict with the needs and > > desires of others. > > Has multiple people has stated, on the newsyslog thread. this is not a > DELL/EMC/Isilon need, this is also a requirement for plenty of use cases > 1. Consistency > as a project we do support building WITHOUT_FOO there is no reason to install > syslog, cron configuration for FOO if the system was built without foo Though it doesn't _hurt_, and breaking POLA has to be worth it, not just because it looks nice. > 2. Packaging base > if one does not install at there is no need for the at crontab to be installed > (same reason as 1.) This is a viable reason except that it isn't fully baked yet. > 3. Large deployment of freebsd farms > Being able to administrate thousands of FreeBSD machines, one often ends up > using tools like puppet, chef, ansible, cfengine. When programmatically > handling configuration management it is way easier and safer to simple > add/removes files in a directory rather than mangling^Winplace editing files. There's nothing preventing you now from deploying split files and an empty global configuration file since the daemons support foo.d. You don't require that to change in upstream since you should be using some sort of VCS to manage your configuration as it is. > 4. Ports/packages > On can provide easily sample configuration for cron, syslog (not only) and the > admin can decide to use it or not easily (ususally this is done by making > symlinks from the said file which would live in share/* into the .d directory. > > This is not a new trend in FreeBSD: newsyslog, rc.conf, libmap and more. The support for broken out files has long been there, but the base system has not used them previously for default config shipped during a release. That is in fact a new trend. However, the current approach seems to be the absolute worst way to do this. If someone wants to use the existing base system image and modify it with config management, they now have to use a mix of styles (for some services edit a global config file for certain settings, but use a dedicated file for other settings for the same service, or for the same settings but a different service). It's also the worst case for humans trying to work with our system as the division between which services are broken out vs global is inconsistent and arbitrary. Once you split up the files you make a merge conflict for anyone trying to do an upgrade. If we do this piecemail then we create N merge conflicts for users to deal with as opposed to if you split it up all at once. Also, there wasn't a clear consensus (a mail to arch@ with "hey, we should switch to splitting up config files for reasons A and B and let's do this for 12.0 but not merge to stable so there is a clear flag day / sign post for users to manage upgrades". Instead there have been a couple of commits and any not-in-100%-agreement opinions are ignored. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2201156.H7EQSgYph9>