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

[Ngie Cooper]

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

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

[Don Lewis]

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

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

[John Baldwin]

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

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

[Bryan Drewery]

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

[Alexey Dokuchaev]

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

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

[Rodney W. Grimes]

[ 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-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"

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

[Warner Losh]

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

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

[Rodney W. Grimes]

[ 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-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"

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

[Colin Percival]

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

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

[Rodney W. Grimes]

> On Friday, May 19, 2017 09:17:23 AM John Baldwin wrote:
> > On Thursday, May 18, 2017 11:24:29 PM Baptiste Daroussin wrote:
> > > On Thu, May 18, 2017 at 09:48:25AM -0700, John Baldwin wrote:
> > > > On Thursday, May 18, 2017 03:09:32 PM Baptiste Daroussin wrote:
> > > > > On Thu, May 18, 2017 at 02:56:31AM -0700, Rodney W. Grimes wrote:
> > > > > > > Author: ngie
> > > > > > > Date: Thu May 18 06:25:39 2017
> > > > > > > New Revision: 318441
> > > > > > > URL: https://svnweb.freebsd.org/changeset/base/318441
> > > > > > > 
> > > > > > > Log:
> > > > > > >   Handle the cron.d entry for MK_AT in cron conditionally
> > > > > > >   
> > > > > > >   Install /etc/cron.d/at if MK_AT != no, always using it, which 
> > > > > > > tries
> > > > > > >   to run a non-existent program via cron(8) every 5 minutes with 
> > > > > > > the
> > > > > > >   default /etc/crontab, prior to this commit.
> > > > > > >   
> > > > > > >   SHELL and PATH are duplicated between /etc/crontab and 
> > > > > > > /etc/cron.d/at
> > > > > > >   because atrun(8) executes programs, which may rely on 
> > > > > > > environment
> > > > > > >   currently set via /etc/crontab.
> > > > > > >   
> > > > > > >   Noted by:   bdrewery (in an internal review)
> > > > > > >   MFC after:  2 months
> > > > > > >   Relnotes:   yes (may need to add environmental 
> > > > > > > modifications to
> > > > > > >/etc/cron.d/at)
> > > > > > >   Sponsored by:   Dell EMC Isilon
> > > > > > > 
> > > > > > > Added:
> > > > > > >   head/etc/cron.d/
> > > > > > >   head/etc/cron.d/Makefile   (contents, props changed)
> > > > > > >   head/etc/cron.d/at   (contents, props changed)
> > > > > > > Modified:
> > > > > > >   head/etc/Makefile
> > > > > > >   head/etc/crontab
> > > > > > > 
> > > > > > > Modified: head/etc/Makefile
> > > > > > > ==
> > > > > > > --- head/etc/Makefile Thu May 18 06:15:42 2017
> > > > > > > (r318440)
> > > > > > > +++ head/etc/Makefile Thu May 18 06:25:39 2017
> > > > > > > (r318441)
> > > > > > > @@ -8,6 +8,7 @@ FILESGROUPS=  FILES
> > > > > > >  # No need as it is empty and just causes rebuilds since this 
> > > > > > > file does so much.
> > > > > > >  UPDATE_DEPENDFILE=   no
> > > > > > >  SUBDIR=  \
> > > > > > > + cron.d \
> > > > > > >   newsyslog.conf.d \
> > > > > > >   syslog.d
> > > > > > 
> > > > > > The thread on the newsyslog clearly shows that this is a 
> > > > > > contriversial change.
> > > > > > 
> > > > > > I strongly object to further splitting of /etc/FOO into 
> > > > > > /etc/foo.d/FOO files
> > > > > > to suite Dell/EMC/Isilon's needs.  It is in conflict with the needs 
> > > > > > and
> > > > > > desires of others.
> > > > > 
> > > > > Has multiple people has stated, on the newsyslog thread. this is not a
> > > > > DELL/EMC/Isilon need, this is also a requirement for plenty of use 
> > > > > cases
> > > > > 1. Consistency
> > > > >   as a project we do support building WITHOUT_FOO there is no reason 
> > > > > to install
> > > > >   syslog, cron configuration for FOO if the system was built without 
> > > > > foo
> > > > 
> > > > Though it doesn't _hurt_, and breaking POLA has to be worth it, not just
> > > > because it looks nice.
> > > > 
> > > > > 2. Packaging base
> > > > >   if one does not install at there is no need for the at crontab to 
> > > > > be installed
> > > > >   (same reason as 1.)
> > > > 
> > > > This is a viable reason except that it isn't fully baked yet.
> > > > 
> > > > > 3. Large deployment of freebsd farms
> > > > >   Being able to administrate thousands of FreeBSD machines, one often 
> > > > > ends up
> > > > >   using tools like puppet, chef, ansible, cfengine. When 
> > > > > programmatically
> > > > >   handling configuration management it is way easier and safer to 
> > > > > simple
> > > > >   add/removes files in a directory rather than mangling^Winplace 
> > > > > editing files.
> > > > 
> > > > There's nothing preventing you now from deploying split files and an 
> > > > empty
> > > > global configuration file since the daemons support foo.d.  You don't 
> > > > require
> > > > that to change in upstream since you should be using some sort of VCS to
> > > > manage your configuration as it is.
> > > > 
> > > > > 4. Ports/packages
> > > > >   On can provide easily sample configuration for cron, syslog (not 
> > > > > only) and the
> > > > >   admin can decide to use it or not easily (ususally this is done by 
> > > > > making
> > > > >   symlinks from the said file which would live in share/* into the .d 
> > > > > directory.
> > > > > 
> > > > > This is not a new trend in FreeBSD: newsyslog, rc.conf, libmap and 
> > > > > more.
> > > > 
> > > > The support for broken out files has long been there, but the base 
> > > > system has
> > > > not used them previously for default config shipped during a release.  
> > > > That
> > > > is in fact 

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

[Ngie Cooper (yaneurabeya)]

> 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

[John Baldwin]

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 

Re: pkgbase and conf files (was Re: svn commit: r318441 - in head/etc: . cron.d)

[Baptiste Daroussin]

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)

[John Baldwin]

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

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

[Baptiste Daroussin]

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 

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

[John Baldwin]

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 

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

[Eric van Gyzen]

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

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

[Baptiste Daroussin]

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

[Ian Lepore]

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

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

[Baptiste Daroussin]

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

[Ian Lepore]

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

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

[Baptiste Daroussin]

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 

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

[Warner Losh]

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

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

[John Baldwin]

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

[Ian Lepore]

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

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

[Rodney W. Grimes]

> 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 

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

[Baptiste Daroussin]

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

[Nikolai Lifanov]

On 05/18/2017 05:56, 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
>>   

> 
> 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'm not an appliance vendor and am not affiliated with Dell/EMC/Isilon
and this change served my needs and desires.

When automating configuration management, templating a file instead of
conditionally installing/removing configuration snippets is:

1) less performant because you can't just check mtime of the expanded
template vs. the source file to figure out whether to expand it again,
which affects practical frequency of configuration runs
2) couples logic from unrelated configuration modules, making working on
different configuration with different people more difficult

I really wish we had /etc/fstab.d/ :)

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

I agree that inconsistencies are bad, but I think we can get there
incrementally, unbundling configuration of one MK_* thing at a time.

- Nikolai Lifanov



signature.asc
Description: OpenPGP digital signature

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

[Rodney W. Grimes]

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

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

[Ngie Cooper]

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