On Thu, May 18, 2017 at 09:48:25AM -0700, John Baldwin wrote: > 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. > That's true, another thing is the way it is done, there is no simple way to disable the at cron from an admin point of view rather than rm /etc/cron.d/at for an end user which an upgrade will bring back.
Bapt
signature.asc
Description: PGP signature
