> 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 rgri...@freebsd.org _______________________________________________ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
