Bug 47860 - Wrong Documentation for Variable update/check/cron/entry
Wrong Documentation for Variable update/check/cron/entry
Status: CLOSED FIXED
Product: UCS
Classification: Unclassified
Component: Update - univention-updater
UCS 5.0
Other Linux
: P5 normal (vote)
: UCS 5.0-0-errata
Assigned To: Philipp Hahn
Arvid Requate
https://git.knut.univention.de/univen...
:
Depends on: 38938
Blocks:
  Show dependency treegraph
 
Reported: 2018-09-26 10:19 CEST by Christian Völker
Modified: 2021-09-01 17:07 CEST (History)
2 users (show)

See Also:
What kind of report is it?: Bug Report
What type of bug is this?: 1: Cosmetic issue or missing function but workaround exists
Who will be affected by this bug?: 2: Will only affect a few installed domains
How will those affected feel about the bug?: 1: Nuisance – not a big deal but noticeable
User Pain: 0.011
Enterprise Customer affected?:
School Customer affected?:
ISV affected?:
Waiting Support:
Flags outvoted (downgraded) after PO Review:
Ticket number:
Bug group (optional):
Max CVSS v3 score:
hahn: Patch_Available+


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Christian Völker univentionstaff 2018-09-26 10:19:59 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.
Comment 1 Ingo Steuwer univentionstaff 2021-05-14 16:38:04 CEST
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.
Comment 2 Philipp Hahn univentionstaff 2021-07-01 07:54:49 CEST
Still relevant for UCS-5
Even more descriptions are out-of-date:

https://git.knut.univention.de/univention/ucs/-/merge_requests/111
Comment 3 Philipp Hahn univentionstaff 2021-07-02 08:19:21 CEST
[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(-)
Comment 4 Philipp Hahn univentionstaff 2021-07-02 08:23:32 CEST
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(-)
Comment 5 Arvid Requate univentionstaff 2021-08-18 16:26:38 CEST
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.
Comment 6 Arvid Requate univentionstaff 2021-08-18 21:32:24 CEST
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.
Comment 7 Philipp Hahn univentionstaff 2021-08-19 11:22:47 CEST
(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.
Comment 8 Arvid Requate univentionstaff 2021-08-19 11:48:08 CEST
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.
Comment 9 Philipp Hahn univentionstaff 2021-08-23 12:04:19 CEST
(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
Comment 10 Arvid Requate univentionstaff 2021-08-27 14:04:29 CEST
Thanks, LGTM.