Univention Bugzilla – Bug 51493
Despite update/secure_apt=no apt-get update refuses to pull packages files if system clock is behind
Last modified: 2020-11-26 13:27:58 CET
Created attachment 10390 [details] extend-Max-FutureTime.patch With the first UCS 5.0 iso images apt got more sensitive to the system clock. Even with a UCR setting of update/secure_apt=no apt-get update will refuse to pull the packages lists if the system time of the UCS VM is more than 10 seconds behind the signature of the Release file: E: Release file for http://192.168.0.10/build2/ucs_5.0-0/source/Release is not valid yet (invalid for another 2 d 19 h 44 min 10 s). Updates for this repository will not be applied. The attached patch may extend the 'Max-FutureTime' parameter to 10 years.
FYI: At first the "Release" file is downloaded and validated; as it is from the future, validation fails and the (updated) "Package" file is NOT downloaded - it would not be trusted anyway and as such the old file is kept. Even if the local time of the VM is corrected later on, APT does not fetch the "Release" file again if it was not updated in between - APT uses HTTPs "If-Modified-Since" with the original time stamp (from the future) as previously returned by our EXTERNAL repository server in the initial fetch. As the "Release" file is not updated, the "Package" update is skipped again. My advise is: Fix your ONE underlying time problem instead of fixing the TEN followup and other obscure and hard-to-debug issues like - gpg might complain too for {pre,post}up.sh.php - wget https:// - ...
Workaround: rm -f /var/lib/apt/lists/omar* && apt update
I filed an Upstream Debian APT bug for this: <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=975903>
As a temporary work-around during UCS 5.0-0 development: [5.0-0] 842f138ab0 Bug #51493 base: Temporary work-around for time skew. base/univention-base-files/conffiles/etc/apt/apt.conf.d/20secureapt | 1 + base/univention-base-files/debian/changelog | 6 ++++++ 2 files changed, 7 insertions(+)