Re: svn commit: r318441 - in head/etc: . cron.d
On Mon, Jun 5, 2017 at 10:33 AM, Don Lewis wrote: > On 3 Jun, Rodney W. Grimes wrote: > >> 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. > > That doesn't help with packaged base where you can add one of the > optional pieces later. BINGO. ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r318441 - in head/etc: . cron.d
On 3 Jun, Rodney W. Grimes wrote: > 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. That doesn't help with packaged base where you can add one of the optional pieces later. ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r318441 - in head/etc: . cron.d
On Saturday, June 03, 2017 01:49:34 PM Ngie Cooper wrote: > > > On Jun 3, 2017, at 12:05, John Baldwin wrote: > > … > > > 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. > > Please, no. The single monolithic foo.conf idea may have made sense back in > the day, but with the various knobs that are available for building the > system, for ease-of-use/intuitiveness the feature makes sense. > I planned on introducing more of these files for other areas of the system > that aren’t currently being handled— like bsnmpd’s logging, etc. I think the > modularization makes sense. To be clear, I listed two options, and you have only implemented a third (which is to mix the two styles). I think mixing the two styles is the absolute worst thing to do. If we are going to split a given foo.conf up we should split it up fully so that the out-of-box configuration for a given daemon is consistent. -- John Baldwin ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r318441 - in head/etc: . cron.d
On 6/4/17 11:43 AM, Alexey Dokuchaev wrote: > On Sun, Jun 04, 2017 at 11:32:21AM -0700, Rodney W. Grimes wrote: >>> On 06/03/17 21:39, Rodney W. Grimes wrote: Are we going to end up with /etc/rc.conf.d? >>> >>> We've had this for over 15 years -- ever since NetBSD rc.d system was >>> imported. >> >> We have had it, but it ships empty, > > I'm also not that sure about 15 years: I don't see it on my 8.4-STABLE. > > ./danfe > It came in the original import in r78345. > ~/svn/base # svn diff -c 78345 |grep -F rc.conf.d > + if [ -f /etc/rc.conf.d/"$_command" ]; then > + . /etc/rc.conf.d/"$_command" > ~/svn/base # svn log -vr 78345 ^/|grep rc.subr >A /head/etc/rc.subr (from /vendor/NetBSD/dist/etc/rc.subr:78344) > r78345 | obrien | 2001-06-16 00:16:14 -0700 (Sat, 16 Jun 2001) | 3 lines -- Regards, Bryan Drewery signature.asc Description: OpenPGP digital signature
Re: svn commit: r318441 - in head/etc: . cron.d
On Sun, Jun 04, 2017 at 11:32:21AM -0700, Rodney W. Grimes wrote: > > On 06/03/17 21:39, Rodney W. Grimes wrote: > > > Are we going to end up with /etc/rc.conf.d? > > > > We've had this for over 15 years -- ever since NetBSD rc.d system was > > imported. > > We have had it, but it ships empty, I'm also not that sure about 15 years: I don't see it on my 8.4-STABLE. ./danfe ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r318441 - in head/etc: . cron.d
[ Charset UTF-8 unsupported, converting... ] > On Sun, Jun 4, 2017 at 12:32 PM, Rodney W. Grimes < > free...@pdx.rh.cn85.dnsmgr.net> wrote: > > > [ Charset windows-1252 unsupported, converting... ] > > > On 06/03/17 21:39, Rodney W. Grimes wrote: > > > > Are we going to end up with /etc/rc.conf.d? > > > > > > We've had this for over 15 years -- ever since NetBSD rc.d system was > > > imported. > > > > We have had it, but it ships empty, that is different than what is > > going on with newsyslog/syslog/cron, we have had those too for > > various amounts of time, but now we are not shipping them empty. > > > > Shipping empty is over rated. What's the point of having a feature we can > use to make things less monolithic if we don't use that feature? Shipped empty is extremly valuable, it is why we have /etc/defaults/rc.conf and ship without an /etc/rc.conf. It would be nice to have similiar functionality for all of this. The feature is there for the system administrators to use, not for the developers to use to implement policies rather than methods. -- Rod Grimes rgri...@freebsd.org ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r318441 - in head/etc: . cron.d
On Sun, Jun 4, 2017 at 12:32 PM, Rodney W. Grimes < free...@pdx.rh.cn85.dnsmgr.net> wrote: > [ Charset windows-1252 unsupported, converting... ] > > On 06/03/17 21:39, Rodney W. Grimes wrote: > > > Are we going to end up with /etc/rc.conf.d? > > > > We've had this for over 15 years -- ever since NetBSD rc.d system was > > imported. > > We have had it, but it ships empty, that is different than what is > going on with newsyslog/syslog/cron, we have had those too for > various amounts of time, but now we are not shipping them empty. > Shipping empty is over rated. What's the point of having a feature we can use to make things less monolithic if we don't use that feature? Warner ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r318441 - in head/etc: . cron.d
[ Charset windows-1252 unsupported, converting... ] > On 06/03/17 21:39, Rodney W. Grimes wrote: > > Are we going to end up with /etc/rc.conf.d? > > We've had this for over 15 years -- ever since NetBSD rc.d system was > imported. We have had it, but it ships empty, that is different than what is going on with newsyslog/syslog/cron, we have had those too for various amounts of time, but now we are not shipping them empty. -- Rod Grimes rgri...@freebsd.org ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r318441 - in head/etc: . cron.d
On 06/03/17 21:39, Rodney W. Grimes wrote: > Are we going to end up with /etc/rc.conf.d? We've had this for over 15 years -- ever since NetBSD rc.d system was imported. -- Colin Percival Security Officer Emeritus, FreeBSD | The power to serve Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r318441 - in head/etc: . cron.d
> 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
Re: svn commit: r318441 - in head/etc: . cron.d
> On Jun 3, 2017, at 12:05, John Baldwin wrote: … > 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. Please, no. The single monolithic foo.conf idea may have made sense back in the day, but with the various knobs that are available for building the system, for ease-of-use/intuitiveness the feature makes sense. I planned on introducing more of these files for other areas of the system that aren’t currently being handled— like bsnmpd’s logging, etc. I think the modularization makes sense. Thanks, -Ngie signature.asc Description: Message signed with OpenPGP using GPGMail
Re: svn commit: r318441 - in head/etc: . cron.d
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 setti
Re: pkgbase and conf files (was Re: svn commit: r318441 - in head/etc: . cron.d)
On Fri, May 19, 2017 at 10:43:30AM -0700, John Baldwin wrote: > On Friday, May 19, 2017 06:33:55 PM Baptiste Daroussin wrote: > > On Fri, May 19, 2017 at 09:17:23AM -0700, John Baldwin wrote: > > > On Thursday, May 18, 2017 11:24:29 PM Baptiste Daroussin wrote: > > > 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). > > > > I need to check, I do not remember what I did here and I will certainly add > > a > > regression test for that to ensure this behaviour is always working as > > expected. > > One nice "feature" to have in pkg for pkgbase would be a way to ask pkg to > restore > a stock configuration file (perhaps with an option to restore it to an > alternate > directory or filename?) This would imply that packages would need to keep the > "pristine" conf files around somewhere. This would also let you do 'pkg > confdiff' > or the like (as a replacement for 'etcupdate diff') Yes this is in my TODO list Bapt signature.asc Description: PGP signature
pkgbase and conf files (was Re: svn commit: r318441 - in head/etc: . cron.d)
On Friday, May 19, 2017 06:33:55 PM Baptiste Daroussin wrote: > On Fri, May 19, 2017 at 09:17:23AM -0700, John Baldwin wrote: > > On Thursday, May 18, 2017 11:24:29 PM Baptiste Daroussin wrote: > > 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). > > I need to check, I do not remember what I did here and I will certainly add a > regression test for that to ensure this behaviour is always working as > expected. One nice "feature" to have in pkg for pkgbase would be a way to ask pkg to restore a stock configuration file (perhaps with an option to restore it to an alternate directory or filename?) This would imply that packages would need to keep the "pristine" conf files around somewhere. This would also let you do 'pkg confdiff' or the like (as a replacement for 'etcupdate diff') -- John Baldwin ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r318441 - in head/etc: . cron.d
On Fri, May 19, 2017 at 09:17:23AM -0700, 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
Re: svn commit: r318441 - in head/etc: . cron.d
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
Re: svn commit: r318441 - in head/etc: . cron.d
On 05/18/2017 16:34, Ian Lepore wrote: > On Thu, 2017-05-18 at 23:29 +0200, Baptiste Daroussin wrote: >> On Thu, May 18, 2017 at 03:27:49PM -0600, Ian Lepore wrote: >>> >>> On Thu, 2017-05-18 at 23:24 +0200, 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: >>> >>> >> [...] > 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. Bapt >>> Would you not just comment out or delete the line, exactly as you >>> would >>> do in the main /etc/crontab? >> Right but with a .d directory I would expect to just remove/add >> files/symlinks >> rather than editing it, which defeat the point of the .d >> >> Bapt > > Hrm, I don't see any conflict between "this fine-grained file holds > config for just one component" and "edit the file if you want to change > the config". That is, making the file fine-grained is to make editing > it EASIER (for a human or a program), not to eliminate editing it. > > I do see how thinking that deleting the file (or renaming it to file.no > or something) would seem like the right thing to do. How can we fix > that? How would an upgrade bring back /etc/cron.d/at if the end-user deleted it? Eric ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r318441 - in head/etc: . cron.d
On Thu, May 18, 2017 at 03:34:38PM -0600, Ian Lepore wrote: > On Thu, 2017-05-18 at 23:29 +0200, Baptiste Daroussin wrote: > > On Thu, May 18, 2017 at 03:27:49PM -0600, Ian Lepore wrote: > > > > > > On Thu, 2017-05-18 at 23:24 +0200, 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: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > [...] > > > > > 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. > > > > > > > > Bapt > > > Would you not just comment out or delete the line, exactly as you > > > would > > > do in the main /etc/crontab? > > Right but with a .d directory I would expect to just remove/add > > files/symlinks > > rather than editing it, which defeat the point of the .d > > > > Bapt > > Hrm, I don't see any conflict between "this fine-grained file holds > config for just one component" and "edit the file if you want to change > the config". That is, making the file fine-grained is to make editing > it EASIER (for a human or a program), not to eliminate editing it. > > I do see how thinking that deleting the file (or renaming it to file.no > or something) would seem like the right thing to do. How can we fix > that? > For now I don't know :) I'm thinking about it Bapt signature.asc Description: PGP signature
Re: svn commit: r318441 - in head/etc: . cron.d
On Thu, 2017-05-18 at 23:29 +0200, Baptiste Daroussin wrote: > On Thu, May 18, 2017 at 03:27:49PM -0600, Ian Lepore wrote: > > > > On Thu, 2017-05-18 at 23:24 +0200, 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: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > [...] > > > > 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. > > > > > > Bapt > > Would you not just comment out or delete the line, exactly as you > > would > > do in the main /etc/crontab? > Right but with a .d directory I would expect to just remove/add > files/symlinks > rather than editing it, which defeat the point of the .d > > Bapt Hrm, I don't see any conflict between "this fine-grained file holds config for just one component" and "edit the file if you want to change the config". That is, making the file fine-grained is to make editing it EASIER (for a human or a program), not to eliminate editing it. I do see how thinking that deleting the file (or renaming it to file.no or something) would seem like the right thing to do. How can we fix that? -- Ian ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r318441 - in head/etc: . cron.d
On Thu, May 18, 2017 at 03:27:49PM -0600, Ian Lepore wrote: > On Thu, 2017-05-18 at 23:24 +0200, 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: > > > > > > > > > > > > > > > > > > > > > [...] > > > 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. > > > > Bapt > > Would you not just comment out or delete the line, exactly as you would > do in the main /etc/crontab? Right but with a .d directory I would expect to just remove/add files/symlinks rather than editing it, which defeat the point of the .d Bapt signature.asc Description: PGP signature
Re: svn commit: r318441 - in head/etc: . cron.d
On Thu, 2017-05-18 at 23:24 +0200, 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: > > > > > > > > > > > > > > > > > [...] > > 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. > > Bapt Would you not just comment out or delete the line, exactly as you would do in the main /etc/crontab? -- Ian ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r318441 - in head/etc: . cron.d
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
Re: svn commit: r318441 - in head/etc: . cron.d
On Thu, May 18, 2017 at 3:56 AM, 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. > > I especially object to it being done on a 1 of case, either completly split > the file or make it 1 file, but making it this miss match is just adding to > the work load of ansible and puppet task writting. You now have to mange > 2 config files rather than 1 for cron, and 7 for newsyslog instead of 1. In the vast majority of the cases so far, I'm convinced the changes are for the better and will make things like mergemaster / etcupate / etc easier on our users. Since the files are separate, and you almost never touch them, it's a net win. Consider this a strong encouragement to proceed. Warner >> Added: head/etc/cron.d/Makefile >> == >> --- /dev/null 00:00:00 1970 (empty, because file is newly added) >> +++ head/etc/cron.d/Makefile Thu May 18 06:25:39 2017(r318441) >> @@ -0,0 +1,11 @@ >> +# $FreeBSD$ >> + >> +.include >> + >> +.if ${MK_AT} != "no" >> +FILES+= at >> +.endif >> + >> +BINDIR= /etc/cron.d >> + >> +.include >> >> Added: head/etc/cron.d/at >> == >> --- /dev/null 00:00:00 1970 (empty, because file is newly added) >> +++ head/etc/cron.d/atThu May 18 06:25:39 2017(r318441) >> @@ -0,0 +1,7 @@ >> +# $FreeBSD$ >> +# >> +SHELL=/bin/sh >> +PATH=/etc:/bin:/sbin:/usr/bin:/usr/sbin >> + >> +# See crontab(5) for field format. >> +*/5 * * * * root/usr/libexec/atrun >> >> Modified: head/etc/crontab >> == >> --- head/etc/crontab Thu May 18 06:15:42 2017(r318440) >> +++ head/etc/crontab Thu May 18 06:25:39 2017(r318441) >> @@ -7,8 +7,6 @@ PATH=/etc:/bin:/sbin:/usr/bin:/usr/sbin >> # >> #minute hourmdaymonth wdaywho command >> # >> -*/5 * * * * root/usr/libexec/atrun >> -# >> # Save some entropy so that /dev/random can re-seed on boot. >> */11 * * * * operator /usr/libexec/save-entropy >> # >> >> > > -- > Rod Grimes rgri...@freebsd.org > ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r318441 - in head/etc: . cron.d
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. -- John Baldwin __
Re: svn commit: r318441 - in head/etc: . cron.d
On Thu, 2017-05-18 at 02:56 -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(r3184 > > 40) > > +++ head/etc/Makefile Thu May 18 06:25:39 2017(r3184 > > 41) > > @@ -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. > Actually, the newsyslog thread showed that 4 people supported Ngie's changes, and 4 people objected to them. Not exactly a raging controversy. Given how many people read this list, a pretty tepid response really. The objections seemed to boil down to: 1. It's not how we've done it for years; I don't like newfangled stuff. 2. It's strange to have some stuff in the old monolithic file and some in new little files in a directory. 3. It will be hard to update existing systems. I don't see any point in discussing #1 further (not because peoples' opinions don't matter, but rather because there will never be universal agreement no matter how much it's discussed). I think #2 has some validity, but not as an argument for stopping or undoing the changes, but more as a valid design issue to be discussed. Do we need an "all or nothing" rule when it comes to changing existing config files to be fine-grained? Or some other rule? Right now I infer the rule Ngie is using to be "if you can disable a component with build/install controls, then its config should be fined-grained", and that strikes me as a workable rule, but not the only one possible. #3 seems like a strongly valid concern. People following -current have agreed to take on some pain to do so, but when 12.0-release hits the streets there needs to be a way to upgrade existing systems without a lot of pain. What can we do to make it easier? -- Ian ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r318441 - in head/etc: . cron.d
> 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 l
Re: svn commit: r318441 - in head/etc: . cron.d
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 2. Packaging base if one does not install at there is no need for the at crontab to be installed (same reason as 1.) 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. 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. Best regards, Bapt signature.asc Description: PGP signature
Re: svn commit: r318441 - in head/etc: . cron.d
> 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. I especially object to it being done on a 1 of case, either completly split the file or make it 1 file, but making it this miss match is just adding to the work load of ansible and puppet task writting. You now have to mange 2 config files rather than 1 for cron, and 7 for newsyslog instead of 1. > Added: head/etc/cron.d/Makefile > == > --- /dev/null 00:00:00 1970 (empty, because file is newly added) > +++ head/etc/cron.d/Makefile Thu May 18 06:25:39 2017(r318441) > @@ -0,0 +1,11 @@ > +# $FreeBSD$ > + > +.include > + > +.if ${MK_AT} != "no" > +FILES+= at > +.endif > + > +BINDIR= /etc/cron.d > + > +.include > > Added: head/etc/cron.d/at > == > --- /dev/null 00:00:00 1970 (empty, because file is newly added) > +++ head/etc/cron.d/atThu May 18 06:25:39 2017(r318441) > @@ -0,0 +1,7 @@ > +# $FreeBSD$ > +# > +SHELL=/bin/sh > +PATH=/etc:/bin:/sbin:/usr/bin:/usr/sbin > + > +# See crontab(5) for field format. > +*/5 * * * * root/usr/libexec/atrun > > Modified: head/etc/crontab > == > --- head/etc/crontab Thu May 18 06:15:42 2017(r318440) > +++ head/etc/crontab Thu May 18 06:25:39 2017(r318441) > @@ -7,8 +7,6 @@ PATH=/etc:/bin:/sbin:/usr/bin:/usr/sbin > # > #minute hourmdaymonth wdaywho command > # > -*/5 * * * * root/usr/libexec/atrun > -# > # Save some entropy so that /dev/random can re-seed on boot. > */11 * * * * operator /usr/libexec/save-entropy > # > > -- Rod Grimes rgri...@freebsd.org ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
svn commit: r318441 - in head/etc: . cron.d
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 Added: head/etc/cron.d/Makefile == --- /dev/null 00:00:00 1970 (empty, because file is newly added) +++ head/etc/cron.d/MakefileThu May 18 06:25:39 2017(r318441) @@ -0,0 +1,11 @@ +# $FreeBSD$ + +.include + +.if ${MK_AT} != "no" +FILES+=at +.endif + +BINDIR=/etc/cron.d + +.include Added: head/etc/cron.d/at == --- /dev/null 00:00:00 1970 (empty, because file is newly added) +++ head/etc/cron.d/at Thu May 18 06:25:39 2017(r318441) @@ -0,0 +1,7 @@ +# $FreeBSD$ +# +SHELL=/bin/sh +PATH=/etc:/bin:/sbin:/usr/bin:/usr/sbin + +# See crontab(5) for field format. +*/5* * * * root/usr/libexec/atrun Modified: head/etc/crontab == --- head/etc/crontabThu May 18 06:15:42 2017(r318440) +++ head/etc/crontabThu May 18 06:25:39 2017(r318441) @@ -7,8 +7,6 @@ PATH=/etc:/bin:/sbin:/usr/bin:/usr/sbin # #minutehourmdaymonth wdaywho command # -*/5* * * * root/usr/libexec/atrun -# # Save some entropy so that /dev/random can re-seed on boot. */11 * * * * operator /usr/libexec/save-entropy # ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"