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

[mykel at mware.ca]

On 2018/01/08 00:34, Chris H wrote:
> On Sun, 7 Jan 2018 23:05:44 -0500 <mykel at mWare.ca> 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