Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 18 May 2017 23:24:29 +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:  <20170518212429.rugl6vnv5d2b2hpb@ivaldir.net>
In-Reply-To: <2201156.H7EQSgYph9@ralph.baldwin.cx>
References:  <201705180625.v4I6Pd9j062495@repo.freebsd.org> <201705180956.v4I9uVpQ065465@pdx.rh.CN85.dnsmgr.net> <20170518130932.eo5clhki4za2vigz@ivaldir.net> <2201156.H7EQSgYph9@ralph.baldwin.cx>

next in thread | previous in thread | raw e-mail | index | archive | help

--plhgbr6l2qpe7eme
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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, which t=
ries
> > > >   to run a non-existent program via cron(8) every 5 minutes with the
> > > >   default /etc/crontab, prior to this commit.
> > > >  =20
> > > >   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.
> > > >  =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 file =
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 contriversia=
l change.
> > >=20
> > > I strongly object to further splitting of /etc/FOO into /etc/foo.d/FO=
O files
> > > to suite Dell/EMC/Isilon's needs.  It is in conflict with the needs a=
nd
> > > desires of others.
> >=20
> > 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
>=20
> Though it doesn't _hurt_, and breaking POLA has to be worth it, not just
> 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 often e=
nds up
> >   using tools like puppet, chef, ansible, cfengine. When programmatical=
ly
> >   handling configuration management it is way easier and safer to simple
> >   add/removes files in a directory rather than mangling^Winplace editin=
g 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 req=
uire
> 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 by ma=
king
> >   symlinks from the said file which would live in share/* into the .d d=
irectory.
> >=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 system=
 has
> not used them previously for default config shipped during a release.  Th=
at
> is in fact a new trend.
>=20
> However, the current approach seems to be the absolute worst way to do th=
is.
> 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 diffe=
rent
> service).  It's also the worst case for humans trying to work with our sy=
stem
> 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 trying t=
o 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 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.
>=20
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.

Bapt

--plhgbr6l2qpe7eme
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEEgOTj3suS2urGXVU3Y4mL3PG3PloFAlkeEQkACgkQY4mL3PG3
PlpEQQ/9EXMRc61538j3jaOjXNgWkwpZojKwebrudlrNLTAmUSbDIunl0n6HG/4B
VE5M0xP19SM9GSV4nDxd/rKZty/Ybn2NBqB8pePRJTxcSX96qI1ZjBK/7xsIHsAk
BbiPNFr+yZwOZt8C9zlKCNOX2EZ4YILS6onHEJV6oGbLK5ORdpo8EnLfNcwsNqiX
yk9CmZ3E56lJ1t/YeX6hd/vgLMBh0Ur/eVoFQl8SjzXuAeLAa9thrd1utkrSOknY
CLwbRteHTvOvrudIT6R83ODwdvVApImHpXFQDW6lezlwTbmy1fLoiEZBy94KmzOv
NJXgdmZ2dgmCgen9YhHaKeHwgZZgfsoP5Ee5wAUsf5bzQ4ucp+y9VZwDn5Ew1Jr7
5bsxmX70hMZ/KgvhhIcP+PRIvMpUU7sTTCxdUlt3LopA/B66oXW2EFQ/Hh4o4oGv
cEt5r29mez+Rf/k7rc2vEMGl031N08+bY9GrrSGUIwPiQAkdlhM00lqNhnYKeYfU
3Axe2NO7vguO1Jpl7dDZWBtGvt0LSMeVh/hpKLNkEnBIBA/0/FVW8Xm24IAyCWr0
8ElR1Az4d/zVJZt2Wo0gPYtS/rQHt+pt5muONTUnNWG3a/eVfnMSboBfUE0+zUOh
l+UY5ULFz5cv4QqZf+7dMytj8YC7CR96ZDgVTcCIGgrxYArFvBQ=
=nA5v
-----END PGP SIGNATURE-----

--plhgbr6l2qpe7eme--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20170518212429.rugl6vnv5d2b2hpb>