On 2018/01/08 00:34, Chris H wrote:
On Sun, 7 Jan 2018 23:05:44 -0500 said
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!
Hmm, if they are "arguably" already ignoring their system emails. Won't
they then *also* "arguably" ignore their [system] log files?
Why not just remove periodic etc/periodic(daily/weekly/monthly/security)?
But maybe I've just misunderstood the attempt here.
But this way partitions don't get filled. Massive backlogs don't build,
etc. Hence the logrotation benefit - the data's not permanently disposed
of, but it's also not slowly killing a machine.
You keep the benefit of the default periodic jobs.
On 2018/01/08 10:26, Rodney W. Grimes wrote:
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.
Okay: In the ~300 machines I manage, 2 of them have their mailers set up
to get those messages in front of an admin... and that's because those
two machines are MTAs. The other 500+ FreeBSD installs I've done for
clients are in the same boat... nobody wants more email, and no
monitoring system is parsing the messages. (And who wants a passive
monitoring system that only alerts daily?)
Arguably having a machine years (or months!) down the road opaquely
running out of disk is _not_ POLA.
I'm not going to argue too hard for point #2, but I don't see how #1 is
a bad idea: No MTA? Don't send emails. (Or create zillions of bounces.)
On 2018/01/08 22:26, Mark Heily wrote:
> 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.
Arguably turning off periodic is far more disruptive than rendering it's
output useful.
I also think changing the output to logfiles (in absence of an MTA) is
much better POLA than the 'new' offer of nuking /tmp on reboot; while it
is an option, it's far more dangerous to delete data than not fill a
disk with cruft.
Myke
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
