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

[Rodney W. Grimes]

> On Friday, May 19, 2017 09:17:23 AM 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).
> > 
> > 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).

>From the discussion that has occured there are defanitly different views
on what would be best.  I do not think all the aspects of this type of
change have been discussed.  This is a basic philisophical change to how
we configure FreeBSD and it has very wide reaching ramifications for not
only the project but for all down stream consumers.

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

Very resonable.

> > 3) This is probably a sufficiently large POLA violation to not MFC, but be
> >    part of a new X.0.

Very much in agreement.

> 
> Ping?  bapt@ agreed with this, but I haven't seen any other feedback?  If others
> agree then we should either revert back to a single foo.conf or we should fully
> split newsyslog.conf and syslogd.conf out to individual files.
> 

I though I commented on this before, but I shall make sure by responding to
this ping.  I think it might be good to have a general discussion on this
topic at BSDCan, even if it is a hallway track.  How far does this reach?
Are we going to end up with /etc/rc.conf.d?

Is anyone actually doing this type of thing in a deployed managed set of
systems?   

I still assert your going to break a LOT of peoples ansible, chef, puppet,
what ever tool they have chosen management systems that are currently
deployed.  Your going to be breaking pre-canned task, reciepe, what ever
the tool chooses to call it that already know how to deal with this.

And one thing I have not seen addressed that applies specifically to
doing this with cron, you have to duplicate the environment setup
in every single file, and that is just an ugly situation from a
systems point of view.

As far as fixing the builds for optional stuff that is rather
easily done in the Makefile with some if's to build a list of
files that can then be catted to conf.foo, using m4 or even
cpp to pre process conf.foo.src, etc, several very easy ways
to solve that and leave the system administration interface
alone.

-- 
Rod Grimes                                                 rgrimes at freebsd.org