Date: Thu, 18 May 2017 09:48:21 -0700 (PDT) From: "Rodney W. Grimes" <freebsd@pdx.rh.CN85.dnsmgr.net> To: Baptiste Daroussin <bapt@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: <201705181648.v4IGmLqr067011@pdx.rh.CN85.dnsmgr.net> In-Reply-To: <20170518130932.eo5clhki4za2vigz@ivaldir.net>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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@freebsd.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201705181648.v4IGmLqr067011>