Make periodic's output log to files if sendmail is disabled on install

[m***@mWare.ca]

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

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!



[22:54.53]  <Myke> AllanJude: will you make the installer smart that if
the user disables sendmail, that periodic's output will be sent to
logfiles instead?
[22:55.17]  <AllanJude> not sure how doable that is
[22:57.20]  <Myke> AllanJude:
https://www.freebsd.org/cgi/man.cgi?periodic(8) <-- see examples
[22:57.55]  <AllanJude> ohh
[22:57.57]  <AllanJude> ok then
[22:58.04]  <AllanJude> should be fairly easy to do then
[23:00.02]  <Myke> AllanJude: I'd argue logging periodic to files should
become the default since I'm willing to bet 99% of fBSD machines' output
is ignored.
[23:00.34]  <AllanJude> Myke: that is a reasonable idea for freebsd 12
[23:00.42]  <Myke> :)
[23:00.55]  <AllanJude> want to email that to freebsd-***@freebsd.org
[23:00.57]  <AllanJude> and then i'll do it ;)

[Mark Heily]

On Mon, Jan 8, 2018 at 10:26 AM, Rodney W. Grimes <

Post by m***@mWare.ca
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

Post by m***@mWare.ca
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.

[Chris H]

Post by Mark Heily
On Mon, Jan 8, 2018 at 10:26 AM, Rodney W. Grimes <

Post by m***@mWare.ca
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

Post by m***@mWare.ca
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.

Nothing personal, Mark. But my personal opinion/choice on this change; is
to leave it as-is. My justification is that after *years* of users expecting,
things to be as they are, and adjusting as-needed. Changing this will
more likely cause more interference, than joy. 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. I'd wager those stats to be
fairly reasonable.

--Chris