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

[Ian Lepore]

On Thu, 2017-05-18 at 02:56 -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	(r3184
> > 40)
> > +++ head/etc/Makefile	Thu May 18 06:25:39 2017	(r3184
> > 41)
> > @@ -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.
> 

Actually, the newsyslog thread showed that 4 people supported Ngie's
changes, and 4 people objected to them.  Not exactly a raging
controversy.  Given how many people read this list, a pretty tepid
response really.

The objections seemed to boil down to:

 1. It's not how we've done it for years; I don't like newfangled
stuff.

 2. It's strange to have some stuff in the old monolithic file and some
in new little files in a directory.

 3. It will be hard to update existing systems.

I don't see any point in discussing #1 further (not because peoples'
opinions don't matter, but rather because there will never be universal
agreement no matter how much it's discussed).

I think #2 has some validity, but not as an argument for stopping or
undoing the changes, but more as a valid design issue to be discussed.
 Do we need an "all or nothing" rule when it comes to changing existing
config files to be fine-grained?  Or some other rule?  Right now I
infer the rule Ngie is using to be "if you can disable a component with
build/install controls, then its config should be fined-grained", and
that strikes me as a workable rule, but not the only one possible.

#3 seems like a strongly valid concern.  People following -current have
agreed to take on some pain to do so, but when 12.0-release hits the
streets there needs to be a way to upgrade existing systems without a
lot of pain.  What can we do to make it easier?

-- Ian