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

[Rodney W. Grimes]

> 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

>From other mail in the newsyslog thread it was very evident that the
newsyslog changes where driven by a specific need and desire of
Dell/EMC/Isilon.  And as others pointed out that was more or less
in conflict with others needs and desires.  I did not see any conclusion
reached in that thread.

> 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

And there are very clean ways to do this WITHOUT the need to make this a
bunch of seperate files.  This actually creates an inconsistent system,
do I manage crons FOO item with /etc/crontabl or /etc/cron.d/FOO?  

As I said lets do it one way or the other, but NOT a half baked some in
one file and some others split into seperate files.  Others expressed
this exact some issue, why is this issue being ignored?

I also stated that this could be done and meet the requirements of one file
with conditionalized Makefile syntax it is a trivial matter to create
a string of files to cat from the src/etc directory into the objdir with
the right lines in it based on if {${MK_FOO} knobs.

> 2. Packaging base
>   if one does not install at there is no need for the at crontab to be installed
>   (same reason as 1.)

Lets cross that bridge when the package of base is done, and with a great
deal more engineering than this simple hack.    The configuration management
of a packaged base is gona be a messy nightmare at best from what I am
seeing, especially if this is the road to be taken.

> 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.

This actually is breaking a massive deployment of both ansible and puppet
based management tools.  Again, how does splitting this into 2 files to
manage make it any easier to manage?  We now have to teach the management
tools to deal with both /etc/crontab and /etc/cron.d/at if I want it to
manage at.  And this tool has to be taught that FreeBSD < r318441 uses
one way and >=r318441 is another way.

> 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.

These files for ports/packages do not belong in /etc/cron.d but in
/usr/local/etc/cron.d, I would fully support that as an addition if it
does not exist, but that has nothing to do with /etc/crontab or /etc
cron.d, or moving of 1 single /etc/crontab line to /etc/cron.d.

> 
> This is not a new trend in FreeBSD: newsyslog, rc.conf, libmap and more.

This IS a new trend in FreeBSD, the base system has always shipped with
a minimal set of /etc/FOO files and not split them in to FOO.d.  The
system SUPPORTS foo.d but does not ship that as its base configuration.

-- 
Rod Grimes                                                 rgrimes at freebsd.org