Bug 46465 - postup.sh is run with outdated version/version
postup.sh is run with outdated version/version
Status: CLOSED FIXED
Product: UCS
Classification: Unclassified
Component: Update - Release updates
UCS 4.3
Other Linux
: P5 normal (vote)
: UCS 4.4-5-errata
Assigned To: Florian Best
Jürn Brodersen
:
Depends on:
Blocks: 51531 51623
  Show dependency treegraph
 
Reported: 2018-03-02 14:52 CET by Dirk Wiesenthal
Modified: 2020-08-26 16:35 CEST (History)
3 users (show)

See Also:
What kind of report is it?: Development Internal
What type of bug is this?: ---
Who will be affected by this bug?: ---
How will those affected feel about the bug?: ---
User Pain:
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:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Dirk Wiesenthal univentionstaff 2018-03-02 14:52:19 CET
When updating from, say, UCS 4.2 to 4.3, all steps are executed with the UCRV version/version set to 4.2. This also holds for the postup.sh. Intuitively, I would say that "postup" is already run with 4.3.

This is a problem in the App Center, where Apps cannot be registered in the postup as many checks include a comparison with "ucr get version/version". This leads to a situation where Apps from 4.2 are registered on a UCS 4.3.

Setting version/version to 4.3 is kind of a "promise" that everything is up and right. If postup.sh exits with 1, it can be re-executed exactly because version/version is still 4.2.

Maybe there is more "logic" why postup.sh should run with version/version=4.2?

Anyway, we should to find other solutions and run postup.sh on a UCS 4.3 - with the correct version/version.
Comment 1 Florian Best univentionstaff 2020-08-18 13:00:48 CEST
The UCR variables version/version and version/patchlevel are now set before the execution of postup.sh.
The current postup.sh doesn't rely on the old version/version.
I didn't add code to revert the UCR variable setting in case of errors, because only the components postup and cleanup code follow this. If one needs to restart the upgrade if something fails in the cleanup code, he can set it manually back, if that even helps.

univention-updater (14.0.2-16)
c8dbda3dcafd | Bug #46465: call postup.sh after setting version/version

univention-updater.yaml
9faa8f960547 | YAML Bug #46465


I tested it with this patch:
diff --git a/base/univention-updater/modules/univention/updater/tools.py b/base/univention-updater/modules/univention/updater/tools.py
index 68916c84b1..e030aa7853 100644
--- a/base/univention-updater/modules/univention/updater/tools.py
+++ b/base/univention-updater/modules/univention/updater/tools.py
@@ -1897,6 +1897,7 @@ class UniventionUpdater(object):
             uri = server.join(path)
             fd, name = tempfile.mkstemp(suffix='.sh', prefix=phase, dir=tempdir)
             try:
+                script = '%s\necho VERSION\nucr get version/version\nucr get version/patchlevel\n%s' % (script.splitlines()[0], script)
                 size = os.write(fd, script)
                 os.chmod(name, 0o744)
                 if size == len(script):
Comment 2 Jürn Brodersen univentionstaff 2020-08-21 11:21:42 CEST
Looks good

What I tested:
Upgrade from 4.4-5 to 5.0-0 -> version/version (timestamp config-registry.replog) is set before postup.sh is run (timestamp updater.log) -> OK
Jenkins -> OK
YAML -> OK