Univention Bugzilla – Bug 47860
Wrong Documentation for Variable update/check/cron/entry
Last modified: 2021-09-01 17:07:09 CEST
Wrong description for the variable: root@ucs:/etc/cron.d# ucr search update/check/cron/entry update/check/cron/entry: <empty> Defines the interval for checking whether updates are available for this system. The configuration is done in Cron syntax, see 'man 5 crontab'. If the variable is unset, the check occurs every five minutes. If the variable is unset the default of "5 * * * *" applies- which means it will start hourly at five minutes after the full hour (i.e. 01:05, 02:05,...). Every five minutes would mean "*/5". So just misleading/ wrong documented here.
This issue has been filed against UCS 4.3. UCS 4.3 is out of maintenance and many UCS components have changed in later releases. Thus, this issue is now being closed. If this issue still occurs in newer UCS versions, please use "Clone this bug" or reopen it and update the UCS version. In this case please provide detailed information on how this issue is affecting you.
Still relevant for UCS-5 Even more descriptions are out-of-date: https://git.knut.univention.de/univention/ucs/-/merge_requests/111
[5.0-0] db110bae87 fix[up] Update UCRV descriptions and move defaults base/univention-updater/debian/changelog | 6 ++ base/univention-updater/debian/univention-updater.postinst | 24 ----- .../univention-updater.univention-config-registry-variables | 141 +++++++++++++++++++--------- doc/errata/staging/univention-updater.yaml | 11 +++ 4 files changed, 112 insertions(+), 70 deletions(-)
Package: univention-updater Version: 15.0.3-68A~5.0.0.202107020820 Branch: ucs_5.0-0 Scope: errata5.0-0 [5.0-0] a2b7d8ca6d Bug #47860: univention-updater 15.0.3-68A~5.0.0.202107020820 doc/errata/staging/univention-updater.yaml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
This changes the default behavior for update/check/cron/enabled in case it is unset. Before the change, the cron job was disabled when the variable was unset. After the change, the cron job is enabled when the variable is unset.
So I guess we have to differentiate here: * the UCR default value for update/check/cron/enabled should be "no", because that was the effective default in the UCR template if the variable is unset. * but the postinst sets the "non-UCR-default" value "yes" Right now I'm lacking a good solution for this.
(In reply to Arvid Requate from comment #6) > So I guess we have to differentiate here: > > * the UCR default value for update/check/cron/enabled should be "no", > because that was the effective default in the UCR template if the variable > is unset. > > * but the postinst sets the "non-UCR-default" value "yes" > > Right now I'm lacking a good solution for this. Dejavu: https://m.xkcd.com/927/ from Bug #38938 comment 12 With the new default layer we now have an additional standard to do things. The intention of the default layer is to unify all the other old alternatives into this new standard. We will not be able to do this in all cases and guarantee no change, especially by *unsetting* values to "empty", which now makes the "default" layer visible. So for `update/check/cron/enabled` we have this: - Old installations always set "update/check/cron/enabled?yes", which is our intended behavior: enable updates by cron by default. This should not change. - Changing it manually to "no" or "yes" still works as previously. - Unsetting it now has a different behavior: Previously it defaulted to "no", now it is "yes". This change is unfortunatedly, but IMHO acceptable.
The subject of this bug is "Wrong Documentation for Variable update/check/cron/entry" and the Bug description also doesn't say anything about changing the defaults for update/check/cron/enabled. So, yellow card here. At least behavior changes need to be stated in the advisory.
(In reply to Arvid Requate from comment #8) > The subject of this bug is "Wrong Documentation for Variable > update/check/cron/entry" and the Bug description also doesn't say anything > about changing the defaults for update/check/cron/enabled. So, yellow card > here. > > At least behavior changes need to be stated in the advisory. Let's move forward: I've documented the change: 926f0e6caa..700229178f
Thanks, LGTM.
<https://errata.software-univention.de/#/?erratum=5.0x79>