Keine Anmeldung auf UMC nach Update mehr möglich!

Seit dem letzten Update des OX6 auf Univention-Basis auf 6.20.7 Rev2, ist keine Anmeldung als “Administrator” über die “Univention-Management-Konsole” (UMC) mehr möglich. Auch ein Zugriff auf das “Univention-Directory-Management” (UDM) scheitert. Dieses Tool ist offensichtlich gar nicht mehr vorhanden! Denn wenn ich - wie bisher - den UDM-Aufruf über server-adresse/umc an dem Anmeldebildschirm mit dem gültigen Administrator-Account anzumelden, erscheint die Meldung “Ihre Sitzung ist abgelaufen!” und der Anmeldebildschirm wird wieder angezeigt.
Eine Anmeldung als root über eine ssh-Konsole ist aber noch möglich. Leider kann ich darüber keine OX-Accounts administrieren - ich brauche die GUI.
Wie kann man die Sperre der Anmeldung an der UMC wieder hinbekommen?

Hallo,

der Univention-Directory-Manager wurde zu UCS 3 in der UMC 2 zusammengefasst. Sehen Sie hierzu gern auch die UCS 3.0 Release-Notes.
Um das von Ihnen geschilderte Verhalten besser beurteilen zu können wäre es gut, wenn Sie einmal die Datei /var/log/univention/updater.log auf eventuelle Probleme beim Update hin untersuchen könnten.
Gern können Sie uns die Datei natürlich zur kurzen Durchsicht auch als Anhang zur Verfügung stellen.

Beachten Sie bitte darüberhinaus, dass Sie Ihr Anliegen direkt bei Open-Xchange melden können, um dieses bei gegebenenfalls vorhandenem Maintenance- bzw. Support-Key bearbeiten zu lassen.

Mit freundlichen Grüßen,
Tim Petersen

Danke für die schnelle Reaktion.
In der Anlage die updater.log sowie die Ausgabe von ox_support_infos…
Leider reagiert der OX-Support schleppend bzw. er will scheinbar gar nicht reagieren (zumindest geht das so aus der Supportanfrage hervor), da angeblich dieser Fall vom Maintenance-Vertrag nicht abgedeckt sei, was ich echt nicht verstehen kann, wenn der Zustand nach Inanspruchnahme der Maintenance, spricht der updates, entsteht.
Wie auch immer - ich brauche dringend Hilfe…

Vielen Dank im Voraus.

edit Support: das von Ihnen angehängte Archiv wurde gesichert und entfernt, da es Klartextpasswörter und sensible Daten enthalten kann
updater.log (3.81 KB)

Hallo,

bei der Durchsicht des Updateverlaufs ist aufgefallen, dass einige Konfigurationsdateien nicht aktualisiert werden konnten, da lokale Anpassungen erkannt wurden.

Für die UCS-spezifischen Templates können Sie versuchen, mittels

univention-check-templates

eine Liste der Dateien zu erhalten, welche aufgrund lokaler Modifikationen nicht angepasst werden konnten. Diese Dateien solten durch die neuen Versionen getauscht werden.
Die neuen Konfigurationsdateien enthalten einen Suffix wie “dpkg-dist”, oder auch “dpkg.orig”.
Die vorhandenen Konfigurationsdateien sollten hier je durch die aktuellste ersetzt werden.

Bezüglich der eventuell nicht aktualisierten Konfigurationsdateien für die OX-Komponente muss ich Sie bitten, sich an Open-XChange zu wenden, da diese nicht durch den UCR-Template Mechanismus abgedeckt sind.

Mit freundlichen Grüßen,
Tim Petersen

Erst mal vielen Dank für die schnelle Antwort. Damit habe ich zumindest einen Ansatz.
Der Witz ist der, dass ich niemals irgendwelche individuellen Anpassungen von Templates oder anderen Konfigurationsdateien gemacht habe. Ich habe das System in 2009 standardmäßig aufgesetzt und seitdem immer über die vorhandenen Update-Funktionen geupdated. Leider gab es auch schon in der Vergangenheit einige Probleme nach den Updates. Aber die letzten liefen einigermaßen sauber durch. Das System war in meinen Augen also vor dem letzten Update “sauber”. Auch war mir nicht bekannt, dass mit dem Updates ein genereller Systemwechsel bezügl. UCS vorgenommen wird. Da hätte man ruhig mal vorher hinweisen können, finde ich.

Der o.a. Befehl ergibt folgende Aussage:
[ul]univention-check-templates
WARNING: The following UCR templates were not updated because they are local modified. An updated version was installed as FILENAME.dpkg-new or FILENAME.dpkg-dist. The difference should be checked.
/etc/univention/templates/files/etc/issue.oxsave
/etc/univention/templates/files/etc/pam.d/univention-management-console.dpkg-dist
[/ul]

Nun habe ich noch eine Frage: Woher bekomme ich denn die neuen Dateien? Gibt es einen Befehl, um diese nachträglich nachzuladen?
Oder kann ich mit einem erneuten update-Versuch von der Kommandozeile aus die fehlenden Dateien versuchen zu beziehen?
Wenn ja, wie mache ich das?
Im Verzeichnis des jeweils angegebenen Pfades finde ich sowohl eine alte Version als auch eine neuere Version der beiden Dateien - allerdings ist z. B. die univention-management-console.dpkg-dist auch vom 03.06.2011, also viel älter als mein vorletztes Update vor dem bewussten letzten Update. Und die issue-oxsave.dpkg-new ist gar vom 08.11.2010. Dort gibt es noch eine issue.net und eine issue. Letztere ist 23.03.2012.
Also , was muss ich mit welcher Datei wohin machen???

Wie gesagt, bin ich ohne GUI zwar ziemlich hilflos, da ich das System bisher nur via GUI administriert habe. Aber ich kann natürlich Dateien etc. von der Konsole aus kopieren, verschieben, löschen. Nur ich muss genau wissen, mit welcher Datei von wo nach wohin was zu machen ist.

(Nebenbei: vielen Dank für das Löschen der einen angehängten Datei, ich bin davon ausgegangen, dass da keine sensiblen Daten drinstehen.)

Vielen Dank für die Unterstützung!

Hallo,

[quote=“pschulze59”]Erst mal vielen Dank für die schnelle Antwort. Damit habe ich zumindest einen Ansatz.
Der Witz ist der, dass ich niemals irgendwelche individuellen Anpassungen von Templates oder anderen Konfigurationsdateien gemacht habe. Ich habe das System in 2009 standardmäßig aufgesetzt und seitdem immer über die vorhandenen Update-Funktionen geupdated. Leider gab es auch schon in der Vergangenheit einige Probleme nach den Updates. Aber die letzten liefen einigermaßen sauber durch. Das System war in meinen Augen also vor dem letzten Update “sauber”. Auch war mir nicht bekannt, dass mit dem Updates ein genereller Systemwechsel bezügl. UCS vorgenommen wird. Da hätte man ruhig mal vorher hinweisen können, finde ich.
[/quote]
Generell finden Sie alle Informationen und Änderungen über neue Veröffentlichungen in den entsprechenden Release-Notes:

Die Ausgabe des Befehls univention-check-templates entspricht einer Liste der zurückgehaltenen, neuen Konfigurationsdateien.
Das bedeutet, dass Sie bitte folgende Befehle ausführen, um das UCR-Template zu ersetzen:

#Es folgt ein zusammenhängender Befehl
mv /etc/univention/templates/files/etc/pam.d/univention-management-console \
/etc/univention/templates/files/etc/pam.d/univention-management-console_bak
#Es folgt ein zusammenhängender Befehl
mv /etc/univention/templates/files/etc/pam.d/univention-management-console.dpkg-dist \
/etc/univention/templates/files/etc/pam.d/univention-management-console
# Neues Template comitten
ucr commit /etc/pam.d/univention-management-console
# Neustart der Univention Management Console
invoke-rc.d univention-management-console-server restart

Bezüglich der OX-Konfigurationsdatei /etc/univention/templates/files/etc/issue.oxsave kann ich Ihnen wie gesagt leider nichts zum korrekten Vorgehen sagen - ich schlage vor, dass Sie die Datei vorerst unberührt lassen und beobachten ob Sie Probleme im Betrieb feststellen können.

Mit freundlichen Grüßen,
Tim Petersen

Vielen Dank für die Tipps.
Ich habe die Arbeiten entsprechend ausgeführt - leider kein Erfolg.
Kann es sein, dass die Authentifizierung fehlschlägt? Schlagwort “saslauthd”? Oder Reihenfolge/Verfügbarkeit der Authentifizierungsmodule? Oder einfach irgendwelche nicht gelöschten/nicht löschbaren Sperrdateien? SSL-Zertifikate sind eigentlich bis 12/2012 gültig. Datum des Systems stimmt auch.
Wie kann ich da weiterkommen? Welches logfile liefert mir da nähere bzw. die benötigten Informationen? Ich habe mal verschiedene logfiles geprüft - finde aber keine, in der der Anmeldeversuch des “Administrator” verzeichnet ist. Das ist doch komisch!?

Vielleicht haben Sie noch einen Tipp?

(Nebenbei: Der OX-Suppport ignoriert mich völlig - keine Ahnung warum - ich habe ein ordentliches Ticket, bekam auch eine lapidare Antwort, dass das nicht durch den Maintenance-Vertrag abgedeckt sei und fortan war’s still im Wald. Das ist das Gleiche, als wenn man ein Auto zur Wartung gibt und man bekommt es kaputt zurück. Müssen wir da wirklich erst unseren Anwalt einschalten?)

Hallo,

könnten Sie bitte einmal verifizieren, dass die entsprechenden Dienste der UMC derzeit laufen. Hierzu können Sie am besten den folgenden Befehls verwenden:

ps aux | grep management

Die Ausgabe sollten in etwa wie folgt aussehen:

root@master:~# ps aux | grep management root 1353 0.0 1.1 182828 22740 ? S 07:47 0:13 /usr/bin/python2.6 /usr/sbin/univention-management-console-server start root 1366 0.1 1.0 311160 20888 ? Sl 07:47 0:22 /usr/bin/python2.6 /usr/sbin/univention-management-console-web-server start root 12938 0.0 0.0 9664 852 pts/0 S+ 12:05 0:00 grep management
Sollte hier der univention-management-console-server nicht auftauchen, lassen Sie uns bitte direkt die folgende Datei zur kurzen Durchsicht zukommen:
/etc/init.d/univention-management-console-server
Desweiteren wäre in diesem Fall die Ausgabe des folgenden Befehls interessant:

ls -la /etc/init.d/*management*

Mit freundlichen Grüßen,
Tim Petersen

Oh, ich glaube, wir kommen der Sache näher…
Die Ausgabe macht wohl deutlich, dass der Dienst “univention-management-console-server” nicht gestartet ist, weil auch da ein nichtaktualisiertes Paket existiert. Liege ich damit richtig?
Hier die Ausgabe:

root@oxaeassv:~# ps aux | grep management root 2233 0.2 0.6 128208 6412 ? Sl Sep15 13:45 /usr/bin/python2.6 /usr/sbin/univention-management-console-web-server start root 14064 0.0 0.0 3316 808 pts/0 S+ 13:42 0:00 grep management root@oxaeassv:~# root@oxaeassv:~# ls -la /etc/init.d/*management* -rwxr-xr-x 1 root root 2083 22. Apr 2009 /etc/init.d/univention-management-console-server -rwxr-xr-x 1 root root 2879 12. Jun 16:09 /etc/init.d/univention-management-console-server.dpkg-dist -rwxr-xr-x 1 root root 2083 10. Mai 2009 /etc/init.d/univention-management-console-server.orig -rw-r--r-- 1 root root 538 10. Mai 2009 /etc/init.d/univention-management-console-server.rej -rwxr-xr-x 1 root root 2785 1. Jun 08:41 /etc/init.d/univention-management-console-web-server

Hallo,

auch hier scheint es zurückgehaltene (“diverted”) Paketdateien zu geben, korrekt.
Bitte benennen Sie auch hier die zurückgehaltene Version entsprechend um:

mv /etc/init.d/univention-management-console-server /etc/init.d/univention-management-console-server_bak mv /etc/init.d/univention-management-console-server.dpkg-dist /etc/init.d/univention-management-console-server

Im Anschluss versuchen Sie bitte den Mangagement-Console-Server mit dem neuen Initiskript zu starten:

invoke-rc.d univention-management-console-server start

Mit freundlichen Grüßen,
Tim Petersen

Juhu, das war es - der nicht laufende, weil nicht aktualisierte univention-management-console-Dienst.
Der Zugang zur UMC klappt nun, allerdings zeigen mir die Tests der einzelnen Module an, dass es noch weitere Probleme gibt.
Sie sind zum einen OX-bezogen, zum anderen UCS-bezogen.

So ist unter Basis-Einstellungen -> Software das Modul OpenXchange nicht angehakt, obwohl es ein OX-Server ist. Und wenn ich das Modul Online-Updates -> Komponenten mir anzeigen lasse, dann ist dort ebenfalls weder OX (OpenXchangeServer) noch ox4ucs angehakt. Auch fehlt bei Online-Update -> Einstellungen ein Repository-Server. Ist das denn so in Ordnung??? Müssten nicht beide Module zum updaten bzw. sowieso als Softwaremodul angehakt sein? Kann ich beide Module nachträglich anhaken und damit installieren, ohne an der jetzigen Konstellation was kaputt zu machen?

In dem Zusammenhang noch eine weitere Frage: Da bei den Updates “errate93” angezeigt wird - wie wahrscheinlich wird mein OX dann wieder schlechter oder sogar besser laufen, wenn ich das Update durchführe?

Vielleicht können mir in diesem Thread noch die o.a. Fragen beantwortet werden. Ansonsten bedanke ich mich bei Tim Petersen.

Hallo,

anhand Ihres zuvor angehängten OX-Support Archivs wird deutlich, dass die Repository Einstellungen hinsichtlich der OX-Komponenten in Ordnung sind.
Auffällig ist hier lediglich, dass Sie keinen Repository-Server spezifiziert haben.
DIes sollten Sie nachholen - am einfachsten machen Sie dies direkt per UCR:

ucr set repository/online/server="apt.univention.de"
apt-get update

Informationen zu den Errata-Updates können Sie gern hier einsehen.

Mit freundlichen Grüßen,
Tim Petersen

Danke für die Antwort, die Änderungen/Updates werde ich vermutlich am WE nach vorhergehenden Snapshot machen.
Dennoch meine Frage: Warum werden in den Basiseinstellungen die OX-Module und auch bei den Updates nicht als angehakt angezeigt?
und Frage2: Wäre es ein Fehler, diese nachträglich anzuhaken und damit dann die Updates durchzuführen?
und Frage3: falls ich die Module nicht anhake, werden dann trotzdem OX-Server-Komponenten geupdatet, vielleicht, weil es nur ein Anzeigefehler ist?
Siehe angehängte Bilder.

Hallo,

In Ihrem ersten Screenshot ist die Liste der verfügbaren Komponenten aufgeführt. Hier muss nichts angehakt werden - der Status der OX-Komponenten sollte allerdings auf “verfügbar” stehen - haben Sie den Repositoryserver bereits wie beschrieben angepasst?

in Ihrem zweiten Screenshot sind die installierten Softwarekomponenten - hier sollte ox und ox4ucs aktiviert sein - da anhand Ihrer UCR_Variablen aber ersichtlich wurde, dass die Komponenten erfolgreich eingebunden sind gehe ich eher von einem temporären Anzeigeproblem der UMC aus.

Bitte setzen Sie einmal wie erwähnt den Repositoryserver und führen folgenden Befehl zum Aktualisieren der Paketlisten aus:

apt-get update

Mit freundlichen Grüßen,
Tim Petersen

Hallo Herr Petersen,

leider komme ich jetz tdazu, weiter zu machen…
Also ich habe das Repo eingetragen und apt-get geupdated - allein es hat sich nichts geändert.
Die in den screenshots eingetragenen Haken bzw. “Nicht-Haken” der Komponenten sind so geblieben wie sie waren.
Klicken ich unter “online-Update” -> “Einstellungen” -> “Änderungen speichern” (unten), erscheint folgende Fehlermeldung:

[quote]Auf dem angegebenen Server konnte kein gültiges Repository gefunden werden
Da es auch ein temporäres Problem des betreffenden Servers sein kann, wurden Ihre Eingaben trotzdem gespeichert.
Das Problem ist:

Configuration error: non-existing prefix “univention-repository”: apt.univention.de/univention-repository/[/quote]
Wenn ich davon ausgehe, dass die URL stimmt, müsste es am Prefix liegen, so wie er anzeigt …

Jedenfalls ist kein Update möglich. Es wird zwar ein vorliegendes errata93 angezeigt, führe ich das update aus, ist er nach 3 Sekunden “fertig”. Irgendwas ist also noch immer faul.

Hallo,

aus der Ferne ist die Situation leider schwer zu beurteilen.
Bitte lassen Sie uns daher einmal die aktuellen Repository-Einstellungen zukommen.

Hierzu führen Sie den folgenden Befehl aus:

ucr search --brief repository > repository_settings_ucr

Im Anschluss öffnen Sie bitte die so erzeugte Datei repository_settings_ucr mit einem Editor Ihrer Wahl und entfernen alle OX-spezifischen Passwörter und Benutzernamen.
Danach hängen Sie uns die bearbeitet Datei bitte als Anhang an Ihre nächste Antwort.

Alternativ lassen Sie uns die Datei bitte per Mail unter Angabe des Forentopics als Refernz an feedback@univention.de zukommen.

Können Sie den Repository-Server von Ihrem System aus prinzipiell erreichen?

ping apt.univention.de host apt.univention.de

Mit freundlichen Grüßen,
Tim Petersen

Ja, der repo-server ist erreichbar. Die Namensauflösung funktioniert. host kennt die IP-Adresse.

[quote]l
root@oxaeassv:~# ping apt.univention.de
PING apt.univention.de (85.214.27.218) 56(84) bytes of data.
64 bytes from updates.software-univention.de (85.214.27.218): icmp_req=1 ttl=58 time=14.3 ms
64 bytes from updates.software-univention.de (85.214.27.218): icmp_req=2 ttl=58 time=14.2 ms
64 bytes from updates.software-univention.de (85.214.27.218): icmp_req=3 ttl=58 time=19.5 ms
^C
— apt.univention.de ping statistics —
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 14.254/16.046/19.574/2.494 ms
root@oxaeassv:~# host apt.univention.de
apt.univention.de has address 85.214.27.218

[/quote]

Hier noch die gewünschte Datei:
(Hoffe, das der Anhang dabei ist…sehe ihn nämlich nicht)

Hallo,

der Anhang ist leider nicht sichtbar. Bitte lassen Sie uns einmal ein, nach den Anweisungen im SDB Artikel Systeminformationen für den Univention-Support erzeugtes Archiv zukommen. Dies können Sie wie im Artikel beschrieben hochladen und teilen uns hier dann den Dateinamen mit.

Mit freundlichen Grüßen
Tobias Scherer

Sorry, dass ich mich erst jetzt wieder melde - ich war im Urlaub.

Im Anhang die gewünschte Datei.
Ich weiß jetzt auch, warum das Hochladen der Datei fehlschlug: [quote]Die Dateierweiterung ist nicht erlaubt.[/quote]
Habe jetzt mal ein .txt angehängt. Zugangsdaten + Passwörter sind gecleant.
repository_settings_ucr.txt (3.06 KB)

Hallo,

wie bereits vermutet ist mindestens der für das UCS Online-Repository verwendete Prefix derzeit noch problematisch.
Auf Ihrem System ist die folgende Variable auf einen falschen Wert gesetzt:

repository/online/prefix: univention-repository

Bitte setzen Sie diese Variable einmal leer:

ucr set repository/online/prefix=""

Mit freundlichen Grüßen,
Tim Petersen