svn commit: r318441 - in head/etc: . cron.d

Fri May 19 16:33:56 UTC 2017

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
> > > > > > 
> > > > > > 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.
> 
> 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 similar
> 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 expected.
> 
> To be clear, my main thoughts are that if we are going to start using conf.d
> for the base system:
> 
> 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).
> 
> 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 the
>    same file.
> 
> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/svn-src-head/attachments/20170519/461edc74/attachment.sig>