Univention Bugzilla – Bug 16454
00_ucs_temporary_installation.list wird im postup.sh entfernt
Last modified: 2010-03-04 12:07:51 CET
An Bug #16331 ist aufgefallen, daß 00_ucs_temporary_installation.list ausschließlich im postup.sh entfernt wird. Wir sollten prüfen, ob dies auch direkt im univention-updater gemacht werden kann.
Ich denke, dass univention-updater die Datei (auch) entfernen sollte. Ich habe gerade ein System aktualisiert von 2.2-0 auf 2.2-2, dabei ist das Update auf 2.3-0 abgebrochen worden, weil die UCR-Variable update23/ignoressh absichtlich nicht gesetzt wurde. Nach dem Systemneustart standen in der 00_ucs_temporary_installation.list die 2.3-deb-lines, obwohl mein System noch auf 2.2-2 war. Dies halte ich für sehr gefährlich.
"univention-updater" verwendet resultCode=os.system('%s %s %s | tee -a /var/log/univention/updater.log') zum ausführen der Skripte. Der resultCode eines "prog1 | prog2" Konstrukts in der Shell ist der Rückgabe werde des letzten Programms, hier also der von "tie", so daß der Exit-Code des eigentlichen Skripts insbesondere im Fehlerfall verloren geht. Wohl aus diesem Grund wird innerhalb des "preup.sh" Skripts "killall univention-updater" aufgerufen, um diesen doch noch irgendwie zu stoppen. Dadurch hat der Updater aber auch keine Chance mehr, etwaige Dateien wie dir '00_ucs_temporary_installation.list' im Fehlerfall aufzuräumen. 1. univention-updater wurde so angepasst, daß der Exit-Status des Skriptes zum Beenden führt. 2. Da beim nächsten Update noch die alte Version von univention-updater verwendet werden wird, wird im preup.sh-Skript '00_ucs_temporary_installation.list' im EXIT-Hook gelöscht, falls die Installation abgebrochen wird.
Paket gebaut und rudimentät getestet. ChangeLog-Eintrag ist geschrieben.
Created attachment 2183 [details] Test-Skript für list-Änderung Da beim dem Check-In noch eine andere Änderung mit drin war, hier der Nachweis, daß die neue Variante äquivalent ist.
Der updater macht i.M. keine Updates -> Failed to execute preup.sh liegt es vielleicht an: postup = subprocess.Popen( tee = subprocess.Popen(('tee', tee.communicate() # sollte hier nicht tee.returncode stehen ??? if postup.returncode !=
Created attachment 2230 [details] Reihenfolge von subprocess.communicate in Python Die Reihenfolge, in der auf die Prozese gewartet wird, ist entscheidend. Ansonsten wird der nachfolgende Prozeß anscheinend zu früh beendet, wie das angehängte Beispiel zeigt. 1024+0 Datensätze ein 1024+0 Datensätze aus 1073741824 Bytes (1,1 GB) kopiert, 9,70587 s, 111 MB/s 1474424+0 Datensätze ein 1474424+0 Datensätze aus 754905088 Bytes (755 MB) kopiert, 9,71503 s, 77,7 MB/s a: True a: False 0 b: False b: False 0
Es muß explizit auch auf das Ende des Sktiptes gewartet werden, nicht nur auf das 'tee'. Dabei ist die Reihenfolge des Warten wichtig: Von hinten nach vorne, erst 'tee', dann das Skript. Ansonsten kann es passieren, daß 'tee' sich vorzeitig beendet (Siehe Attachment 2230 [details]). ChangeLog bleibt unverändert: \item Die Datei \ucsURL{/etc/apt/source.d/00\_ucs\_temporary\_installation.list} wird nun auch im Falle eines abgebrochenen Upgrades gelöscht (\ucsBug{16454}).
OK, /etc/apt/sources.list.d/00_ucs_temporary_installation.list wird nun durch das postup.sh gelöscht, falls etwas schief geht. Zusätzlich prüft der univention-updater den Rückgabewert des Script und wirft wenn nötig ein UpdateError (der dann ebenfalls 00_ucs_temporary...) löscht.
UCS 2.3-1 wurde veröffentlicht. Sollte der hier beschriebene Bug mit einer neueren Version von UCS erneut auftreten, so sollte der Bug dupliziert werden: "Clone This Bug".