Date: Fri, 19 May 2017 18:33:55 +0200 From: Baptiste Daroussin <bapt@freebsd.org> To: John Baldwin <jhb@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: <20170519163355.rs5w3hr6dltdx7kv@ivaldir.net> In-Reply-To: <9570430.uB7Ojud3DG@ralph.baldwin.cx> References: <201705180625.v4I6Pd9j062495@repo.freebsd.org> <2201156.H7EQSgYph9@ralph.baldwin.cx> <20170518212429.rugl6vnv5d2b2hpb@ivaldir.net> <9570430.uB7Ojud3DG@ralph.baldwin.cx>
next in thread | previous in thread | raw e-mail | index | archive | help
--fpgvlokedjylwomp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, May 19, 2017 at 09:17:23AM -0700, John Baldwin wrote: > On Thursday, May 18, 2017 11:24:29 PM Baptiste Daroussin wrote: > > 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 > > > > > >=20 > > > > > > Log: > > > > > > Handle the cron.d entry for MK_AT in cron conditionally > > > > > > =20 > > > > > > Install /etc/cron.d/at if MK_AT !=3D no, always using it, whi= ch tries > > > > > > to run a non-existent program via cron(8) every 5 minutes wit= h the > > > > > > default /etc/crontab, prior to this commit. > > > > > > =20 > > > > > > SHELL and PATH are duplicated between /etc/crontab and /etc/c= ron.d/at > > > > > > because atrun(8) executes programs, which may rely on environ= ment > > > > > > currently set via /etc/crontab. > > > > > > =20 > > > > > > 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 > > > > > >=20 > > > > > > 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 > > > > > >=20 > > > > > > Modified: head/etc/Makefile > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D > > > > > > --- 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=3D FILES > > > > > > # No need as it is empty and just causes rebuilds since this f= ile does so much. > > > > > > UPDATE_DEPENDFILE=3D no > > > > > > SUBDIR=3D \ > > > > > > + cron.d \ > > > > > > newsyslog.conf.d \ > > > > > > syslog.d > > > > >=20 > > > > > The thread on the newsyslog clearly shows that this is a contrive= rsial change. > > > > >=20 > > > > > 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 nee= ds and > > > > > desires of others. > > > >=20 > > > > Has multiple people has stated, on the newsyslog thread. this is no= t 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 reaso= n to install > > > > syslog, cron configuration for FOO if the system was built withou= t foo > > >=20 > > > Though it doesn't _hurt_, and breaking POLA has to be worth it, not j= ust > > > because it looks nice. > > >=20 > > > > 2. Packaging base > > > > if one does not install at there is no need for the at crontab to= be installed > > > > (same reason as 1.) > > >=20 > > > This is a viable reason except that it isn't fully baked yet. > > >=20 > > > > 3. Large deployment of freebsd farms > > > > Being able to administrate thousands of FreeBSD machines, one oft= en ends up > > > > using tools like puppet, chef, ansible, cfengine. When programmat= ically > > > > handling configuration management it is way easier and safer to s= imple > > > > add/removes files in a directory rather than mangling^Winplace ed= iting files. > > >=20 > > > 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. > > >=20 > > > > 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 b= y making > > > > symlinks from the said file which would live in share/* into the = =2Ed directory. > > > >=20 > > > > This is not a new trend in FreeBSD: newsyslog, rc.conf, libmap and = more. > > >=20 > > > The support for broken out files has long been there, but the base sy= stem has > > > not used them previously for default config shipped during a release.= That > > > is in fact a new trend. > > >=20 > > > However, the current approach seems to be the absolute worst way to d= o 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 ser= vices > > > edit a global config file for certain settings, but use a dedicated f= ile for > > > other settings for the same service, or for the same settings but a d= ifferent > > > service). It's also the worst case for humans trying to work with ou= r system > > > as the division between which services are broken out vs global is > > > inconsistent and arbitrary. > > >=20 > > > Once you split up the files you make a merge conflict for anyone tryi= ng 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. > > >=20 > > > Also, there wasn't a clear consensus (a mail to arch@ with "hey, we s= hould > > > 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. > > >=20 > > That's true, another thing is the way it is done, there is no simple wa= y to > > disable the at cron from an admin point of view rather than rm /etc/cr= on.d/at > > for an end user which an upgrade will bring back. >=20 > I think an upgrade won't bring the file back necessarily (etcupdate warns= you > that a removed file changed, but it doesn't bring it back, I think a simi= lar > strategy might be sensible for pkg as well). I need to check, I do not remember what I did here and I will certainly add= a regression test for that to ensure this behaviour is always working as expe= cted. >=20 > To be clear, my main thoughts are that if we are going to start using con= f.d > for the base system: >=20 > 1) We should be intentional about deciding to use that approach in general > (so discuss it first, though perhaps we've had enough discussion in the > current threads). >=20 > 2) When converting a utility from a global foo.conf to a conf.d style, I > think we should convert it all at once, not piecemeal so that there's = just > one painful update for users to work through instead of N updates to t= he > same file. >=20 > 3) This is probably a sufficiently large POLA violation to not MFC, but be > part of a new X.0. I agree with the 3 points above. Bapt --fpgvlokedjylwomp Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEgOTj3suS2urGXVU3Y4mL3PG3PloFAlkfHnAACgkQY4mL3PG3 PlqWoQ//UGIf5rjCu3zCc7QBhD93NVqeMc5M3c1o8GiqmPbpUaj4wHYCpaMnbcZ/ ljH2SPR5h+JAaNEvgNsn0qHokSEfxM3k4l/Y/BQ7ofgqn4+rVmhei4XGhu3sIqmC OiJXB1UBJPCSheLFcAd14lhfKgBJgC2+1/JV2iWWR5fepd7aTBBsSh/hIrMafmhc iO8Iu9/3ZVGdrm7qeuqjWmD5yYtoZaQ24SJLi1pI2nt/QS5HIvqZ4xrTAXcpCIyG h5u4TF64iH+IRYfqIkY9F6ziZk4kqbMsz+dihBJNw4kFvW0QploWoqpJK+1J7tJA vvWjmVKa9zQcpbgY47ADxzqGQH/TYb0uGqqhfBqDK/pNUXOZIIbX0AjVgORzq4Tw hZ9kcno1ufBIefYY1si+iN4fangRUVdx0zFAJGL+EJLO/SlkrKXtbgVeiT+qHS8v JmlwQLMysccsfw4T2whnxMtFV52YsbOM/N17aIqL3aDyQw9HiQv4luMAykJDBb27 1aeu3FckRrHS6Gc1Eb74P7hkcWvElwcGdWPUpqm2SWH7OEyYIgpET0tuus9NAMoA IVV/WfPMv48EUltP9prYdYUDQaERpbU4SZiIwacuuAh6Z8Qu1U/iK/5DnsC8RUPb jPRGcaQ6bcU4Z50K+ghtrpzKOGeu7DZXPk+XJVDR/+HnAXIoX40= =MMKP -----END PGP SIGNATURE----- --fpgvlokedjylwomp--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20170519163355.rs5w3hr6dltdx7kv>