Update UCS 4.1-4 auf 4.2-1 schläg fehlt

UCS - Univention Corporate Server
, ,
#1

Hallo

ich kann den Server nicht abdaten und daher auch keinen 2ten Server mit Domäne joinen da dieser 2te Server bereits UCS 4.2-1 hat.

Einie Deinstallationen scheine fehlegeschlagen zu sein und auch einige UCS Komponenten sind NOK.

Hier die Meldungen des UCS-Updates:
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Modulsuche
Benachrichtigung
Ein Update für UCS ist verfügbar. Es kann über das Modul “Software-Aktualisierung” im System eingespielt werden.
Software-Aktualisierung
UCS Aktualisierung fehlgeschlagen
Die Aktualisierung schlug fehl, bitte prüfen sie die Log-Datei für den genauen Grund. Betätigen Sie die Schaltfläche “Zurück”, um diese Ansicht zu schließen.
26.08.17 12:17:09.718 DEBUG_INIT
**** Starting univention-updater with parameter=[’/usr/share/univention-updater/univention-updater’, ‘net’, ‘–updateto’, ‘4.2-1’, ‘–ignoressh’, ‘–ignoreterm’]
Version=4.1
Patchlevel=4
starting net mode
—>DBG:update_available(mode=net, cdrom_mount_point=/media/cdrom, iso=None)
Checking network repository
Update to = 4.2-0
**** Downloading scripts at Sat Aug 26 12:17:14 2017
**** Starting actual update at Sat Aug 26 12:17:18 2017
Running preup.sh script
Sa 26. Aug 12:17:18 CEST 2017

HINT:
Please check the release notes carefully BEFORE updating to UCS 4.2-0:
English version: https://docs.software-univention.de/release-notes-4.2-0-en.html
German version: https://docs.software-univention.de/release-notes-4.2-0-de.html

Please also consider documents of following release updates and
3rd party components.

Do you want to continue [Y/n]?
Trying to detect if migration to dependency based boot will fail:
WARNING: App1_Container is provided by multiple scripts in /etc/init.d/
WARNING: Removed, but configured, package bareos-director left /etc/init.d/bareos-dir behind
WARNING: Removed, but configured, package bareos-filedaemon left /etc/init.d/bareos-fd behind
WARNING: Removed, but configured, package bareos-storage left /etc/init.d/bareos-sd behind
WARNING: Removed, but configured, package sesam-srv left /etc/init.d/sesam behind
insserv: warning: script ‘K50univention-directory-listener’ missing LSB tags and overrides
insserv: warning: script ‘K20univention-saml’ missing LSB tags and overrides
insserv: warning: script ‘K85bind9’ missing LSB tags and overrides
insserv: warning: script ‘K99univention-firewall’ missing LSB tags and overrides
insserv: warning: script ‘K20univention-management-console-server’ missing LSB tags and overrides
insserv: warning: script ‘K99univention-welcome-screen’ missing LSB tags and overrides
insserv: warning: script ‘K20univention-directory-policy’ missing LSB tags and overrides
insserv: warning: script ‘K93univention-system-setup-boot’ missing LSB tags and overrides
insserv: warning: script ‘K21rdate’ missing LSB tags and overrides
insserv: warning: script ‘K05univention-maintenance’ missing LSB tags and overrides
insserv: warning: script ‘K20univention-management-console-web-server’ missing LSB tags and overrides
insserv: warning: script ‘K92univention-runit’ missing LSB tags and overrides
insserv: warning: script ‘K98univention-network-common’ missing LSB tags and overrides
insserv: warning: script ‘K20univention-directory-notifier’ missing LSB tags and overrides
insserv: warning: script ‘K97univention-s4-connector’ missing LSB tags and overrides
insserv: warning: script ‘univention-directory-notifier’ missing LSB tags and overrides
insserv: warning: script ‘univention-network-common’ missing LSB tags and overrides
insserv: warning: script ‘univention-directory-listener’ missing LSB tags and overrides
insserv: warning: script ‘univention-system-setup-boot’ missing LSB tags and overrides
insserv: warning: script ‘rdate’ missing LSB tags and overrides
insserv: warning: script ‘univention-s4-connector’ missing LSB tags and overrides
insserv: warning: script ‘bind9’ missing LSB tags and overrides
insserv: warning: script ‘univention-system-setup-boot-prepare’ missing LSB tags and overrides
insserv: warning: script ‘univention-directory-policy’ missing LSB tags and overrides
insserv: warning: script ‘univention-firewall’ missing LSB tags and overrides
insserv: warning: script ‘univention-runit’ missing LSB tags and overrides
insserv: warning: script ‘univention-saml’ missing LSB tags and overrides
insserv: warning: script ‘univention-welcome-screen’ missing LSB tags and overrides
insserv: script docker-app-nextcloud: service App1_Container already provided!
insserv: warning: script ‘univention-maintenance’ missing LSB tags and overrides
insserv: warning: script ‘univention-management-console-server’ missing LSB tags and overrides
insserv: warning: script ‘univention-management-console-web-server’ missing LSB tags and overrides
insserv: warning: script ‘klogd’ missing LSB tags and overrides
insserv: remove service /etc/init.d/…/rc0.d/K50univention-directory-listener
insserv: enable service …/init.d/univention-directory-listener -> /etc/init.d/…/rc0.d/K01univention-directory-listener

Jetzt kommen ca.1000 Zeilen mit Einträgen zu
remove service
enable service

DANN das Ende:

insserv: remove service /etc/init.d/…/rcS.d/S70screen-cleanup
insserv: enable service …/init.d/screen-cleanup -> /etc/init.d/…/rcS.d/S20screen-cleanup
insserv: dryrun, not creating .depend.boot, .depend.start, and .depend.stop
insserv --dryrun: OK
Aborting, because the update would likely fail.
Please check and fix the aforementioned issues.
(To ignore, set the UCRV variable update42/ignore_insserv to yes)
Error: Update aborted by pre-update script of release 4.2-0

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Ist die Installation noch zu retten? Ich müsste ein Samba-Share zu fliegen bringen, aber unter
“Samba kein Zugriff auf shares aus Windows” habe ich bereits eine Anfrage offen, weil der Zugriff auf das Samba share nur mit root funktioniert und sonst nicht.

vielen Dank im Voraus für Hilfe
Matthias Janbeck

#2

Habe das gleiche Problem - unabhängig von dem erwähnten Samba-Problem, welches ich so nicht habe.
Ich konnte in den ganzen LOG-Zeilen keinen Hinweis auf echte Fehler entdecken. Nur ein paar Warnungen (genau genommen nur die ersten 6, die MaJa auch hatte) und jede Menge “insserv: remove” und “insserv: enable” - aber nix, woran man etwas fest machen könnte.
Hat einer das Problem schon gelöst???

Gruß
Guido

#3

Hallo Guido,

ist auf deinem Server Bareos installiert ?
Wenn ja, das gibt es leider (noch) nicht für 4.2, soweit es mir bekannt ist.
Deshalb laufen meine Server auch weiterhin auf 4.1.

https://help.univention.com/t/recommended-app-updates-4-1-4-2/5494

Gruß
Oliver Bertgen

#4

Hi, nein Bareos habe ich nicht installiert.
Mir scheint allerdings inzwischen die Notwendigkeit einer Neuinstallation immer deutlicher zu werden, um auf 4.2 zu kommen. Der Upgrade ist alles andere als Bullet-Proof.
Diverse Änderungen der Vergangenheit sind nicht Update-Kompatibel!
So hatte ich einige Templates angepasst, um die Management-Konsole auf Port 8080 zu schieben, was wohl ein Fehler war, den das Pre-Update-Skript bemängelt.
Ferner sind einige Skripts in der init.d wohl noch übrig, obwohl das dazugehörige Paket nicht mehr auf dem System ist, wie z.B. klogd.
Entfernt man die verwaisten Skripte und ändert die Templates zurück, so läuft der Test durch und der Update findet auch statt, doch scheitert er spätestens an den Eintragungen, die ich habe machen müssen, um letsencrypt im Apache zu verankern.
Was übrig bleibt ist dann eine Ruine mit unklarem Status, da Apache nicht mehr startet.
Da ich schon in der Version 4.1 ein paar andere Ungereimtheiten feststellen musste, wie z.B. keine Anzeige mehr bzgl ausstehender AppCenter-Aktualisierungen, fehlende clamav-Pakete und falsch angezeigte Stati einiger System-Services (z.B. postgrey), werf ich nun die Flinte in’s Korn.
Ich werde einen Teil meiner Services auf ein Standard-Debian-System auslagern und den UCS stark abgespeckt nur noch als Domänen-Master in Version 4.2 neu aufsetzen. So reduziert sich die Komplexität und zukünftige Updates werden hoffentlich weniger zur Zitterpartie.
Ich habe stark das Gefühl, dass sich Univention mit diesem Upgrade etwas zu viel zugetraut hat. Und wenn ein System sich nur in der vordefinierten Standard-Konfiguration updaten lässt, ist es weitgehend nutzlos. Schließlich möchte man ja auch in den Genuss von aktuellen Versionen (Owncloud 9.1.6) kommen und auch Dienste wie Letsencrypt nutzen (was zwar schon mal angedacht war, aber bis heute nicht bei mir angekommen ist).
Also muss man Patchen. Und wenn dann ein Update fehlschlägt (weil der Update-Skript-Entwickler nicht weit genug gedacht hat), ist Standard-Debian evtl. doch die bessere Option.

Gruß
Guido

#5

Das ist kein Univention-spezifisches Problem. Je mehr du an einem System abseits der vom Entwickler vorgesehen Pfade rumschraubst, umso wahrscheinlich is es, daß ein Upgrade nicht ohne weiteres durchläuft. Früher hat man bei Linux allgemein von Upgrades eher abgeraten und eher neuinstalliert.

Der Funktions-Umfang von UCS ist nun noch mal deutlich höher. Entsprechend komplexer ist auch der Upgrade-Prozeß und es ist entsprechend schwierig alle Konfigurationsvarianten zu testen. Und Template-Anpassungen sind entsprechend nicht vorgesehen. Sie sollten demnach nur im Notfall vorgenommen werden und immer von einem entsprechenden Feature-Request begleitet sein. Wenn man auf der sicheren Seite sein will, macht man die Änderungen vor Upgrades rückgängig. Aber statt z.B. den UMC-Port umzubiegen hätte vielleicht auch eine .htaccess gereicht. Das hätte vermutlich mehr Sicherheit gebracht als dieser “Security by Obscurity”-Ansatz (ich unterstelle einfach mal, daß hier IT-Sicherheit das Motiv war).

So lange man auf offiziellen Pfaden bleibt, ist ein Upgrade sicher weniger problematisch als bei einer normalen DIstribution, sofern man sich bei dieser die Funktionalität von UCS nachbaut. Denn dafür wurde ein Upgrade eher nicht getestet.

EDIT: Just my 2 cents

1 Like
#6

Ich hatte zwar auf dem System auch mal Bareos installiert, aber auch wieder deinstalliert. jewiels über due UCS Console.

Es scheint so zu sein als ob UCS mit einem DC und Kopano und Samba so nicht Update-Sicher klar kommt. Bin noch 2 Wochen in Urlaub und werden den Server dann minimaler Konfiguration neu installieren. Eine NewCloud oder OwnCloud sollte wohl eher auf einen gesonderten Server.

Grüße
Matthias

Mastodon