Date: Mon, 08 Jan 2018 23:37:13 -0800 From: "Chris H" <bsd-lists@BSDforge.com> To: "Mark Heily" <mark@heily.com> Cc: <mykel@mware.ca>, "freebsd-current" <freebsd-current@freebsd.org>, "Rodney W. Grimes" <freebsd-rwg@pdx.rh.cn85.dnsmgr.net> Subject: Re: Make periodic's output log to files if sendmail is disabled on install Message-ID: <c66154f7e778070a8b85e0bb7105dfdd@udns.ultimatedns.net> In-Reply-To: <CAGfo=8=qq8AXS7rdO1utsRxiQzEkHc%2B%2B_CqtKSVxRfoBd76h-Q@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 8 Jan 2018 22:26:14 -0500 "Mark Heily" <mark@heily=2Ecom> said > On Mon, Jan 8, 2018 at 10:26 AM, Rodney W=2E Grimes < > freebsd-rwg@pdx=2Erh=2Ecn85=2Ednsmgr=2Enet> wrote: >=20 > > > 1) if sendmail is disabled during installation, have periodic's outpu= t > > > logged to files (per example in > > > https://www=2Efreebsd=2Eorg/cgi/man=2Ecgi?periodic(8) ) > > > > I would not make this option dependent on sendmail, it should just > > be a stand alone set of options > > "Do you want logs" > > #Completely turn off periodic in crontab > > "Do you want logs mailed or stored in files" > > #dtrt > > > > > 2) make this the default anyway (logging to files), arguably the vast > > > majority of systems' reporting is ignored :) > > > At least now it could be logrotated out! > > > > You can argue that when you provide a statistical data set, > > until then this is speculation at best and should not be used > > in an argument for or against a change like this=2E > > > > > If I do nothing different in the installer please make sure > > the systems end up as they have been configured for a very > > long time to minimize POLA=2E And to minimize any changes to > > all the post install configuration that people have been > > doing up until now=2E > > > > > Do you have "statistical data" to back up your claim that the > the current installer settings cause the least amount > of astonishment to users? Why should your speculation about > POLA be given special treatment, while other people's speculation > requires hard evidence? >=20 >=20 > > Changing how things work out of the box undoes or adds to > > changes people already have in place, and for larger instances, > > probably have fully automated=2E > > > > > I'm in favor of the suggestion of leaving the periodic cronjobs turned > off by default in the next release=2E Any existing automation is likely > geared towards turning those jobs off, and it would be trivial to turn > them back on again=2E As long as user-visible changes are documented > in the release notes, and users have an easy way to override the default,= I > am all for providing a cleaner and simpler out of box experience=2E Nothing personal, Mark=2E But my personal opinion/choice on this change; is to leave it as-is=2E My justification is that after *years* of users expectin= g, things to be as they are, and adjusting as-needed=2E Changing this will more likely cause more interference, than joy=2E Given that in the 30 some yrs I've been riding some form of BSD, and this is the first I've heard a request/complaint about this specifically=2E I'd wager those stats to be fairly reasonable=2E --Chris
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?c66154f7e778070a8b85e0bb7105dfdd>