Date: Mon, 8 Jan 2018 22:26:14 -0500 From: Mark Heily <mark@heily.com> To: "Rodney W. Grimes" <freebsd-rwg@pdx.rh.cn85.dnsmgr.net> Cc: mykel@mware.ca, freebsd-current <freebsd-current@freebsd.org> Subject: Re: Make periodic's output log to files if sendmail is disabled on install Message-ID: <CAGfo=8=qq8AXS7rdO1utsRxiQzEkHc%2B%2B_CqtKSVxRfoBd76h-Q@mail.gmail.com> In-Reply-To: <201801081526.w08FQhA8022158@pdx.rh.CN85.dnsmgr.net> References: <a5c844a7-feb3-f153-3c8e-f95fb69f05bb@mware.ca> <201801081526.w08FQhA8022158@pdx.rh.CN85.dnsmgr.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Jan 8, 2018 at 10:26 AM, Rodney W. Grimes < freebsd-rwg@pdx.rh.cn85.dnsmgr.net> wrote: > > 1) if sendmail is disabled during installation, have periodic's output > > logged to files (per example in > > https://www.freebsd.org/cgi/man.cgi?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. > > 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. And to minimize any changes to > all the post install configuration that people have been > doing up until now. > > 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? > 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. > > I'm in favor of the suggestion of leaving the periodic cronjobs turned off by default in the next release. Any existing automation is likely geared towards turning those jobs off, and it would be trivial to turn them back on again. 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAGfo=8=qq8AXS7rdO1utsRxiQzEkHc%2B%2B_CqtKSVxRfoBd76h-Q>