Univention Bugzilla – Bug 55499
DDoS by update/check/cron/entry
Last modified: 2023-01-23 08:00:33 CET
base/univention-updater/conffiles/etc/cron.d/univention-updater-check: > ("cron", 600, configRegistry.get('update/check/cron/entry', '5 * * * *')), By default all UCS systems perform a check for available each hour between 5-15. For months now we receive errors around that time that - customers get errors from the updater because of broken SSL handshake - errors during downloading Packages files - errors while accessing our App center - our internal tests fail because of those errors A single UCS-4.4 performs 240-600 HTTPS requests, even if all of them receive a HTTP response "304 Not Modified". For UCS-5.0 this was changed to only perform 2-4 requests, but still they add to the load. See https://luns.knut.univention.de/etherpad/p/ucs5-repository Internal-IT started the process to migrate to a new server, we still should change the code to do this check less often and distribute it over a longer period. This might affect our reporting which depends on the UCS updater contacting our server on a regular basis: https://git.knut.univention.de/univention/internal/univention-internal-reporting
AFAIR the objective of this CRON job was to ensure that people get noticed about available security updates within a reasonable time; let's say that is 6 hours. Maybe we can modify it to not repeat the check if it was successfull in the last 6 hours?
(In reply to Ingo Steuwer from comment #1) > AFAIR the objective of this CRON job was to ensure that people get noticed > about available security updates within a reasonable time; let's say that is > 6 hours. Maybe we can modify it to not repeat the check if it was > successful in the last 6 hours? Currently we only release errata each Wednesday, so checking more often than once a week is a waste IMHO. Debian already contains a mechanism `/lib/systemd/system/apt-daily.service` to do a (bi-)daily "apt-get update", which is triggered by `/lib/systemd/system/apt-daily.timer` to run in a randomized 12h window. It is disabled by default and simply needs this to be added to /etc/apt/apt.conf.d/ APT::Periodic::Update-Package-Lists "1"; The `systemd.trigger` has the advantage over plain CRON, that it guarantees a run every 12h, even when the host ist turned off at the scheduled time. In that case `systemd` will rerun the skipped trigger some short time after the next power-on. Using plain CRON does not have that "recovery" mechanism: If the job is set to 06:00 and the host is only turned on during the day 09-17, it would never trigger. In addition to the *periodic* update other actions like opening some UMC modules do also trigger an *additional synchronous* update. For those case it would be nice if our automatic update would already have fetches the latest lists as this will reduce the time of the blocking part to only get those "304 Not Modified" instead of having to then spend time on downloading the latest list. Also each `reboot`, but that is not critical IMHO. So "weekly" would be enough for most users and be the nicest for our download server as then we distribute the load over a whole week. "daily" would also work and does have the benefit for our users, that they all see updates within 24h after getting the e-mail from us.
(In reply to Philipp Hahn from comment #2) > (In reply to Ingo Steuwer from comment #1) > > AFAIR the objective of this CRON job was to ensure that people get noticed > > about available security updates within a reasonable time; let's say that is > > 6 hours. Maybe we can modify it to not repeat the check if it was > > successful in the last 6 hours? > > Currently we only release errata each Wednesday, so checking more often than > once a week is a waste IMHO. We shouldn't do that assumption for at least two reasons: 1. We don't follow that rule in every errata release (the January erratas so far were on a wednesday and a friday) and we shouldn't limit us here 2. Apps are released "as soon as they are ready", and variuos Apps to errata like package updates which are also identified by this mechanism. Please also keep in mind that we do statistics based on repository access which would also need changes if we can't assume that each instance tries to fetch package lists on a daily base.