Bug 46465

Summary: postup.sh is run with outdated version/version
Product: UCS Reporter: Dirk Wiesenthal <wiesenthal>
Component: Update - Release updatesAssignee: Florian Best <best>
Status: CLOSED FIXED QA Contact: Jürn Brodersen <brodersen>
Severity: normal    
Priority: P5 CC: best, botner, damrose
Version: UCS 4.3   
Target Milestone: UCS 4.4-5-errata   
Hardware: Other   
OS: Linux   
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:
Bug Depends on:    
Bug Blocks: 51531, 51623    

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