>> I'm ok with your timings, except if the update corrects something that >> specifically affects us. E.g. the recent PHP update to correct the floating >> point bug[1][2]. For updates like that one, a couple of days and a search >> to confirm no issues with the update should be sufficient. > > I would agree, if it's a security patch with only a few changed things. If > it's a bigger one, I think we can't test enough. We're running Debian Stable. By definition there shouldn't be any large changes. In fact most updates will be security updates and I like these to be applied as fast as possible. If something breaks, then just downgrade to the old package (to be found in /var/lib/apt/cache). We're not the stock exchange - if we have some little downtime now and then it's better than running with security problems for several weeks. >> Can we adjust the verbosity or the timing of the emails being sent by some >> of the scheduled processes? >> I prefer not to receive "information" emails from the server, just "alerts" >> where some action is required. I think its counter-productive to send >> emails at such a frequency where the default action is to ignore them. When >> an important message comes along, it could get missed. I agree. Especially the rkhunter mails should be adjusted. Versions will always be out of date because we run Debian Stable, so checking them makes no sense. I'd like to get mails only when there is some action that has to be taken. >> And can we push forward the time that the tasks run to about 7am UTC (or at >> least the time that the emails get sent). > That should be easy if we all agree on that. fine with me Andi -- splitbrain.org