Management Console tot nach Eingabe von IPv6 Adressen

german

#1

Liebe Community,

ich wollte gerade bei meinem Domain Controller eine IPv6 Adresse setzen. Da gab es bereits die erste Auffälligkeit: der Ladebalken zeigte den Schritt “setting proxy” (oder so ähnlich) sehr lange an. Ich nahm dann irgendwann an, der Prozess ist schon abgeschlossen und es liegt nur ein Interface-Fehler vor.

Seither kann ich mich nicht mehr in die UMC einloggen. Der Login scheint erst zu funktionieren, bleibt aber dann an der stelle hängen, wo das Univention-Logo mit dem rot-grünen Rand sichtbar ist. Wenn man dann die Seite neu lädt, landet man wieder beim Login. Versucht man es jetzt erneut, kommt eine Fehlermeldung:


Interner Server-Fehler: Der Dienst ist momentan nicht erreichbar!

The Univention Management Console Server is currently not running.
If you have root permissions on the system you can restart it by executing the following command:

  • invoke-rc.d univention-management-console-server restart
    The following logfile may contain information why the server is not running:
  • /var/log/univention/management-console-server.log
    Otherwise please contact an administrator or try again later.

Wenn ich die UMC neu starte, fängt das ganze von neuem an. In der angegebenen Logdatei steht folgendes:


29.07.15 16:37:36.424 MAIN ( PROCESS ) : Processor: dying
29.07.15 16:47:35.031 DEBUG_INIT
29.07.15 16:47:35.032 MAIN ( PROCESS ) : Starting UMC server …
29.07.15 16:47:35.259 MAIN ( PROCESS ) : Server started
29.07.15 16:47:40.222 AUTH ( WARN ) : Canonicalization of username was not possible: {‘desc’: ‘No such object’}
29.07.15 16:47:40.584 MAIN ( ERROR ) : Traceback (most recent call last):
File “/usr/sbin/univention-management-console-server”, line 212, in
umc_daemon.do_action()
File “/usr/lib/pymodules/python2.7/daemon/runner.py”, line 186, in do_action
func(self)
File “/usr/sbin/univention-management-console-server”, line 144, in _restart
self._start()
File “/usr/lib/pymodules/python2.7/daemon/runner.py”, line 131, in _start
self.app.run()
File “/usr/sbin/univention-management-console-server”, line 194, in run
notifier.loop()
File “/usr/lib/pymodules/python2.7/notifier/nf_generic.py”, line 283, in loop
step()
File “/usr/lib/pymodules/python2.7/notifier/nf_generic.py”, line 270, in step
not __sockets[ cond ] fd :
File “/usr/lib/pymodules/python2.7/univention/management/console/protocol/server.py”, line 152, in _receive
self._handle(state, msg)
File “/usr/lib/pymodules/python2.7/univention/management/console/protocol/server.py”, line 205, in _handle
state.processor = Processor(*state.credentials())
File “/usr/lib/pymodules/python2.7/univention/management/console/protocol/session.py”, line 217, in init
self._search_user_dn()
File “/usr/lib/pymodules/python2.7/univention/management/console/protocol/session.py”, line 227, in _search_user_dn
ldap_dn = self.lo.searchDn(’(uid=%s)’ % ldap.filter.escape_filter_chars(self._username))
File “/usr/lib/pymodules/python2.7/univention/admin/uldap.py”, line 367, in searchDn
raise univention.admin.uexceptions.noObject(_err2str(msg))
noObject: No such object

29.07.15 16:47:40.592 MAIN ( PROCESS ) : Processor: dying

Ich kann aus diesen Logeinträgen leider überhaupt nichts herauslesen.

Hat irgendwer eine Idee welcher Fehler hier vorliegt?

LG, David C.


#2

Hallo,

File "/usr/lib/pymodules/python2.7/univention/management/console/protocol/session.py", line 227, in _search_user_dn ldap_dn = self.lo.searchDn('(uid=%s)' % ldap.filter.escape_filter_chars(self._username)) File "/usr/lib/pymodules/python2.7/univention/admin/uldap.py", line 367, in searchDn raise univention.admin.uexceptions.noObject(_err2str(msg)) noObject: No such object

Ich würde diese Meldung so deuten, dass der angegebene Nutzer im LDAP nicht gefunden werden kann. Die Meldung ist allerdings eine andere, wenn man bei einer funktionierenden UMC einen nicht existenten Nutzer angibt. Da käme “PAM: authentication error: (‘User not known to the underlying authentication module’, 10)”.
Es wäre trotzdem ratsam, zunächst die Funktionalität des LDAP-Server selbst zu prüfen. Also Logs auf Hinweise durchsuchen, univention-ldapsearch verwenden und am Besten auch mit einem normalen ldapsearch gegen die v4 und v6-Adressen testen.

Viele Grüße,
Dirk Ahrnke


#3

Danke für die Hinweise. Ich habe inzwischen die einfachste Lösung gewählt: zurück zum Backup vom Vorabend.

LG, David C.