UCS-4.0 und Management-Console kein Login

Hi!

Seit kurzem ist ein Login auf einem UCS-4.0, der als Member-Server in einer durch UCS-3.2 aufgespannten Domäne läuft, nicht mehr möglich. Nach stoppen des UCS-Management-Servers, hochsetzen des Debug-Levels mit ucr set umc/server/debug/level=4 und einem Neustart, liefert das Log univention/management-console-server.log nach einem Einlogversuch (vorgeschlagenes Vorgehen nach sdb.univention.de/content/18/172 … -fail.html):02.12.14 10:46:35.554 LOCALE ( INFO ) : Searching for de_DE.UTF-8 translation of "ip 02.12.14 10:46:35.554 LOCALE ( INFO ) : Searching for de_DE.UTF-8 translation of "dhcp 02.12.14 10:46:35.554 LOCALE ( INFO ) : Searching for de_DE.UTF-8 translation of "dns 02.12.14 10:46:35.555 LOCALE ( INFO ) : Searching for de_DE.UTF-8 translation of "nameserver 02.12.14 10:46:35.555 LOCALE ( INFO ) : Searching for de_DE.UTF-8 translation of "forwarder 02.12.14 10:46:35.555 LOCALE ( INFO ) : Searching for de_DE.UTF-8 translation of "gateway 02.12.14 10:46:35.555 LOCALE ( INFO ) : Searching for de_DE.UTF-8 translation of "interface 02.12.14 10:46:35.556 LOCALE ( INFO ) : Searching for de_DE.UTF-8 translation of "Network settings 02.12.14 10:46:35.556 LOCALE ( INFO ) : Searching for de_DE.UTF-8 translation of "Windows-compatible Memberserver 02.12.14 10:46:35.556 LOCALE ( INFO ) : Loading locale de_DE.UTF-8 for domain apps 02.12.14 10:46:35.556 LOCALE ( INFO ) : Found translation file /usr/share/univention-management-console/i18n/de/apps.mo 02.12.14 10:46:35.560 MAIN ( ERROR ) : Traceback (most recent call last): File "/usr/sbin/univention-management-console-server", line 209, in <module> umc_daemon.do_action() File "/usr/lib/pymodules/python2.7/daemon/runner.py", line 186, in do_action func(self) File "/usr/lib/pymodules/python2.7/daemon/runner.py", line 131, in _start self.app.run() File "/usr/sbin/univention-management-console-server", line 192, in run notifier.loop() File "/usr/lib/pymodules/python2.7/notifier/nf_generic.py", line 284, in loop step() File "/usr/lib/pymodules/python2.7/notifier/nf_generic.py", line 271, in step not __sockets[ cond ][ fd ]( sock_obj ): File "/usr/lib/pymodules/python2.7/univention/management/console/protocol/server.py", line 168, in _receive self._handle(state, msg) File "/usr/lib/pymodules/python2.7/univention/management/console/protocol/server.py", line 286, in _handle state.processor.request(msg) File "/usr/lib/pymodules/python2.7/univention/management/console/protocol/session.py", line 287, in request self.handle_request_get(msg) File "/usr/lib/pymodules/python2.7/univention/management/console/protocol/session.py", line 439, in handle_request_get 'name': self.i18n._(flavor.name, translationId), File "/usr/lib/pymodules/python2.7/univention/management/console/locales.py", line 180, in _ self[domain] = I18N(self.locale, domain) File "/usr/lib/pymodules/python2.7/univention/management/console/locales.py", line 78, in __init__ self.load(locale, domain) File "/usr/lib/pymodules/python2.7/univention/management/console/locales.py", line 108, in load self.mofile = polib.mofile(filename) File "/usr/lib/python2.7/dist-packages/polib.py", line 141, in mofile return _pofile_or_mofile(mofile, 'mofile', **kwargs) File "/usr/lib/python2.7/dist-packages/polib.py", line 74, in _pofile_or_mofile instance = parser.parse() File "/usr/lib/python2.7/dist-packages/polib.py", line 1536, in parse magic_number = self._readbinary('<I', 4) File "/usr/lib/python2.7/dist-packages/polib.py", line 1621, in _readbinary tup = struct.unpack(fmt, bytes) error: unpack requires a string argument of length 4

Im gleichen Zeitraum liefert das Log /var/log/univention/management-console-web-server.log:02.12.14 10:46:35.407 MAIN ( INFO ) : UMCP_Dispatcher: check_queue: new request: 0x2765390 02.12.14 10:46:35.407 MAIN ( INFO ) : UMCP_Dispatcher: check_queue: normal request 02.12.14 10:46:35.407 MAIN ( INFO ) : SessionClient(0x2757ed0): sending request(141751359539623-5) 02.12.14 10:46:35.407 PROTOCOL ( INFO ) : Sending UMCP GET REQUEST 141751359539623-5 02.12.14 10:46:35.408 MAIN ( INFO ) : UMCP_Dispatcher: check_queue: new request: 0x27654d0 02.12.14 10:46:35.408 MAIN ( INFO ) : UMCP_Dispatcher: check_queue: normal request 02.12.14 10:46:35.408 MAIN ( INFO ) : SessionClient(0x2757ed0): sending request(141751359539727-6) 02.12.14 10:46:35.408 PROTOCOL ( INFO ) : Sending UMCP GET REQUEST 141751359539727-6 02.12.14 10:46:35.408 MAIN ( INFO ) : CPGet (10.160.2.12:45621) got response(0x2765590) from queue(0x275c1b8): status=200 (sessionid="25f8e02a-71f3-42f5-aba0-3fdba1f49bb1") 02.12.14 10:46:35.619 MAIN ( INFO ) : Open sessions: 25f8e02a-71f3-42f5-aba0-3fdba1f49bb1 02.12.14 10:46:35.619 MAIN ( INFO ) : Cleaning up session 25f8e02a-71f3-42f5-aba0-3fdba1f49bb1

Das Login wird anscheinend abgearbeitet, aber danach “hängt” die Seite und zeigt für Minuten das UCS-Logo mit annimiertem Rand an. Anschliessend folgt die Fehlermeldung [quote]Benachrichtigung: Ein unbekannter Fehler mit Status-Code 502 trat während des Verbindungsaufbaus zum Server auf. Bitte versuchen Sie es später noch einmal.[/quote]

Es scheint so zu sein, dass der management-console-prozess mit einer Exception endet und dann keine Daten für die bestehende Session liefert. Diese bekommt das nicht mit und zeigt halt weiterhin das UCS-Logo während der Browser auf Daten mit der neuen Seite (der Seite nach dem Login) wartet. Irgendwann schlägt dann ein Timeout im Browser zu und er versucht einen Reload, diesmal mit dem Ergebnis einer Fehlermeldung, da der Prozess, der die Daten liefern sollte nicht mehr existiert. Bug??!

Die Verbindungen zum UCS-3.2-DC funktionieren einwandfrei: DNS, LDAP, Kerberos alles ist erreichbar und liefert die erwarteten Ergebnisse. Ein Login via ssh funktioniert ebenfalls ohne Probleme.

Der Master ist also noch auf UCS 3.2? Dieses Szenario wird eigentlich nicht unterstütz. Der Master sollte immer zuerst aktualisiert werden.

Unabhängig davon dass das natürlich korrekt ist, helfen evtl. die Hinweise aus dem Thead Anmeldung an UMC / Module werden nicht geladen.

Mit freundlichen Grüßen
Janis Meybohm

Ja, dass hat geholfen. Es bleibt die Frage, warum unter bestimmten Umständen, dieses File durch eine genau ein Zeichen (LF) enthaltende “Variante” ersetzt wird …

Geht in dem Fall nicht – ich benötige Python 3 in einer aktuelleren Version, als sie die UCS-3.2 liefert. In UCS-4.0 ist die Version aktuell genug! Das ist bei zwei Systemen notwendig. Das erste System hatte keinerlei Probleme verursacht. Nach dem Upgrade funktionierte alles wie gehabt, inklusive dem Web-Interface. Beim zweiten System gab es das Problem. Ein drittes System. anschliessend für Testzwecke aufgesetzt zeigte keine Probleme nach dem Upgrade. In einer anderen Umgebung waren von 11 Systemen zwei betroffen (beide wurden neu aufgesetzt).

Mastodon