Univention Bugzilla – Bug 26470
univention-management-console-web-server startet nicht wenn ipv6.disable=1
Last modified: 2012-07-20 15:24:12 CEST
Der univention-management-console-web-server startet nicht mehr wenn im IPv6 im Kernel deaktiviert ist.
Ich würde vermuten, dass das Problem auch den UMC-Server betrifft
erneut aufgetreten an Ticket#: 2012052921002525 univention-management-console-server war auch betroffen
Ich kann das Problem reproduzieren auf einer VM mit abgeschaltetem IPv6. Wenn ein browser sich auf die UMC der VM verbindet, bekomme er beim Anmelden (nach dem Klick auf "Anmelden") die Fehlermeldung in einem popup-Fenster: http://10.200.29.7/univention-management-console/ Interner Server-Fehler: Der Dienst ist momentan nicht erreichbar! Im Gegensatz zum Bug #26469 geht es hier nicht um C-Quellkode sondern um Python-Quelkode. Andreas rät, ich soll mir folgende Dateien anschauen: dev/branches/ucs-3.0/ucs/management/univention-management-console-frontend/univention-management-console-web-server dev/branches/ucs-3.0/ucs/management/univention-management-console/scripts/univention-management-console-server
(In reply to comment #3) > Im Gegensatz zum Bug #26469 geht es hier nicht um C-Quellkode sondern um > Python-Quelkode. Andreas rät, ich soll mir folgende Dateien anschauen: Das ist nur der Ausgangspunkt. Zumindest für die UMC-Verbindungen wird die UMC-Bibliothek verwendet: dev/branches/ucs-3.0/ucs/management/univention-management-console/src/uinivention/management/console/protocol/
(In reply to comment #4) > Das ist nur der Ausgangspunkt. Zumindest für die UMC-Verbindungen wird die > UMC-Bibliothek verwendet: > > dev/branches/ucs-3.0/ucs/management/univention-management-console/src/uinivention/management/console/protocol/ Stimmt, guter Tipp. Das Öffnen von sockets passiert in folgenden Dateien und muss dort wohl nur mit "try .. except" umgeben werden, analog zu der Lösung in Bug #26469: src/univention/management/console/protocol/server.py self.__realsocket = socket.socket( socket.AF_INET6, socket.SOCK_STREAM ) src/univention/management/console/protocol/client.py self.__realsocket = socket.socket( socket.AF_INET, socket.SOCK_STREAM )
Das ursprünglich gemeldete Problem war, dass die Prozesse univention-management-console-web-server und univention-management-console-server nicht mehr laufen, sobald IPv6 im Kernel abgeschaltet wird. Dieses Problem ist nun behoben. Analog zu Bug #26469 wird in der Datei src/univention/management/console/protocol/server.py beim Öffnen eines socket nun erst AF_INET6 benutzt und (falls dabei eine Python exception auftritt) wird das Öffnen mit AF_INET wiederholt. Mit dieser Änderung laufen die o.g. Prozesse nun wieder. Wir können diesen Bug aber wahrscheinlich nicht schließen, weil im browser des Anwenders immer noch die Meldung "Interner Server-Fehler" aufpopt und ein Einloggen nicht möglich ist. Diese Meldung habe ich mit dem Firefox 10 beobachtet. Mit dem Konqueror trat die Fehlermeldung im browser nicht auf (einloggen ging auch mit dem Konqueror nicht). Vermutlich ist da in den höheren Schichten der UMC-Architektur noch eine Unverträglichkeit zu IPv4 versteckt.
Wie gerade besprochen liegt es daran, dass der UMC Webserver nicht auf seinem Port lauscht (8090). Es muss noch die CherryPy-Konfiguration angepasst werden.
Ok, ich hab die Konfi von cherrypy geändert: cherrypy.config.update( { 'server.socket_port': int( configRegistry.get( 'umc/http/port', 8090 ) ), - 'server.socket_host': '::', + 'server.socket_host': 'localhost', 'server.request_queue_size' : 100, 'engine.autoreload_on': False, } ) Der host "::" war nur unter IPv6 bekannt, der host "localhost" dagegen ist durch /etc/hosts für IPv6 und für IPv4 bekannt. Ich hab es getestet, bei beiden Protokollen läuft der web server hoch und man kann sich per browser einloggen. Eine Eintragung ins Kapitel "Univention Management Console web interface" des changelog Handbuchs hab ich gemacht.
Die beiden Server beherrschen jetzt einen Fallback auf IPv4-only. Wenn man es SEHR genau betrachtet, dann hat es allerdings eine kleine Änderung der Schnittstelle gegeben, da der UMC Webserver jetzt nur noch auf localhost lauscht (vorher auf ANY '::'). Für UCS selbst ist das nicht tragisch, da die Verbindungen immer über den Apache getunnelt werden, der sowieso per localhost:8090 die Verbindung aufbaut. Hat allerdings jemand den UMC-Webserver extern schon angesteuert würden wir hier gegen die Patch-Policy verstossen. Ich würde vermuten, dass das nicht so tragisch ist, aber mag das gerade nicht alleine entscheiden :-) -> daher wieder auf. ChangeLog-Eintrag existiert.
(In reply to comment #9) > Hat allerdings jemand den UMC-Webserver extern schon angesteuert würden wir > hier gegen die Patch-Policy verstossen. > > Ich würde vermuten, dass das nicht so tragisch ist, aber mag das gerade nicht > alleine entscheiden :-) -> daher wieder auf. Ideal wäre, wenn wie 'umc/http/port' direkt per UCR abgebildet wird. Das sollte einfach zu implementieren sein und jeder kann es ändern. Der Default sollte dann localhost sein.
Ja, gute Idee. Ich hab es genau so implementiert wie von Stefan vorgeschlagen: cherrypy.config.update( { 'server.socket_port': int( configRegistry.get( 'umc/http/port', 8090 ) ), - 'server.socket_host': 'localhost', + 'server.socket_host': configRegistry.get( 'umc/http/name', 'localhost' ), 'server.request_queue_size' : 100, 'engine.autoreload_on': False, } ) Die neue Variable hab ich ordentlich in debian/univention-management-console-web-server.univention-config-registry-variables mit deutschen und englischen Kommentaren eingetragen. Das neu gebaute Paket univention-management-console-frontend hab ich auf meinem Zielsystem installiert und damit getestet. Für beide Varianten (AF_INET6 und AF_INET) hab ich mehrere Varianten durchgetestet: umc/http/name ungesetzt umc/http/name leer umc/http/name :: umc/http/name localhost umc/http/name unsinn In allen Fällen verhielt sich der web server nach seinem restart so wie erwartet. Das changelog des Handbuchs hab ich ergänzt um den Eintrag für die neue UCR-Variable.
Ich finde den Name sowie die Beschreibung der Variable missverständlich. Ich finde es lässt vermuten, dass ich hier einen beliebigen _Name_ für den Webserver eintragen kann. Es ist aber nur möglich hier eine IP-Adresse oder einen Namen des lokalen Systems anzugeben. Daher würde ich hier vorschlagen die Variable eher umc/http/interface zu nennen und die Beschreibung entsprechend zu ändern. Gerade aus der Sicht heraus, dass umc/http/name=einschönername zu einem laufenden Web-Server führt, der aber auf keinem Port lauscht sollte die Beschreibung klar stellen was hier funktioniert. [umc/http/name] Description[de]=Name des UMC-HTTP-Servers, auf den mit listen reagiert werden soll (Vorgabe localhost) Description[en]=Name of UMC HTTP server to use when listening (default localhost) Type=str Categories=Management Die Funktionstests sind noch nicht ganz abgeschlossen, aber bis jetzt sieht es gut aus. ipv6.disable=1 Tests fehlen noch.
Ich hab die Umbenennung durchgeführt und sie kommt auf dem Zielsystem an: ucr search umc/http/interface umc/http/interface: localhost Name of UMC HTTP server to use when listening (default localhost) Das changelog im Handbuch hab ich entsprechend geändert. Alle Varianten (ipv6/v4 und die Fälle oben) hab ich durchprobiert und es lief wie erwartet. Damit müsste nun alles in Ordnung sein.
Das funktioniert jetzt soweit. (In reply to comment #13) > Ich hab die Umbenennung durchgeführt und sie kommt auf dem Zielsystem an: > > ucr search umc/http/interface > umc/http/interface: localhost > Name of UMC HTTP server to use when listening (default localhost) > > Das changelog im Handbuch hab ich entsprechend geändert. Alle Varianten > (ipv6/v4 und die Fälle oben) hab ich durchprobiert und es lief wie erwartet. Wird ein ungültiges Interface angegeben startet der Web-Server, aber funktioniert nicht. Da ich das nicht für tragisch halte habe ich einen neuen Bug angelegt (Bug #27691) Der ChangeLog-Eintrag wurde angepasst
Created attachment 4463 [details] output of tail -f on several log files Im Zusammenhang mit Bug 27632 ist folgendes Problem aufgetreten: Apache und UMC-Web-Server kommunizieren über localhost. Mittels netstat -nlpt wird angezeigt, dass UMC-Web-Server auf ::1 (=IPv6) lauscht. Beim System-Setup-Vorgang wird im Join-Skript 90univention-bind-post.inst der bind9-Server neugestartet, dabei wird /etc/resolv.conf neu geschrieben (der nameserver wird neu gesetzt). Danach ist die Verbindung zwischen Apache und Web-Server unterbrochen (siehe Ende der Logdatei). Als mögliche Lösung dieses Problems können Apache und UMC-Web-Server über 127.0.0.1 kommunizieren. Dazu wäre es gut, wenn die Apache Siteconf-Datei ebenfalls die UCR-Variable umc/http/interface ausliest.
(In reply to comment #15) > Created an attachment (id=4463) [details] > output of tail -f on several log files > > Im Zusammenhang mit Bug 27632 ist folgendes Problem aufgetreten: Apache und > UMC-Web-Server kommunizieren über localhost. Mittels netstat -nlpt wird > angezeigt, dass UMC-Web-Server auf ::1 (=IPv6) lauscht. Beim > System-Setup-Vorgang wird im Join-Skript 90univention-bind-post.inst der > bind9-Server neugestartet, dabei wird /etc/resolv.conf neu geschrieben (der > nameserver wird neu gesetzt). Danach ist die Verbindung zwischen Apache und > Web-Server unterbrochen (siehe Ende der Logdatei). Als mögliche Lösung dieses > Problems können Apache und UMC-Web-Server über 127.0.0.1 kommunizieren. Dazu > wäre es gut, wenn die Apache Siteconf-Datei ebenfalls die UCR-Variable > umc/http/interface ausliest. Die Änderungen wurden in das Paket mit eingebracht. univention-management-console-frontend (1.0.377-1) unstable; urgency=low . * use 127.0.0.1 as default host for proxy * read value from umc/http/interface for apache site config file Bug #26470
(In reply to comment #16) > (In reply to comment #15) > > Created an attachment (id=4463) [details] [details] > > output of tail -f on several log files > > > > Im Zusammenhang mit Bug 27632 ist folgendes Problem aufgetreten: Apache und > > UMC-Web-Server kommunizieren über localhost. Mittels netstat -nlpt wird > > angezeigt, dass UMC-Web-Server auf ::1 (=IPv6) lauscht. Beim > > System-Setup-Vorgang wird im Join-Skript 90univention-bind-post.inst der > > bind9-Server neugestartet, dabei wird /etc/resolv.conf neu geschrieben (der > > nameserver wird neu gesetzt). Danach ist die Verbindung zwischen Apache und > > Web-Server unterbrochen (siehe Ende der Logdatei). Als mögliche Lösung dieses > > Problems können Apache und UMC-Web-Server über 127.0.0.1 kommunizieren. Dazu > > wäre es gut, wenn die Apache Siteconf-Datei ebenfalls die UCR-Variable > > umc/http/interface ausliest. > > Die Änderungen wurden in das Paket mit eingebracht. Das funktioniert. Allerdings ist die Hilfe zur UCR-Variable noch nicht richtig: umc/http/interface: 127.0.0.1 Network interface to be used by UMC HTTP server when listening (default: localhost)
(In reply to comment #17) > Das funktioniert. Allerdings ist die Hilfe zur UCR-Variable noch nicht richtig: > > umc/http/interface: 127.0.0.1 > Network interface to be used by UMC HTTP server when listening (default: > localhost) Die Hilfebeschreibung wurde angepasst. univention-management-console-frontend (1.0.379-2) unstable; urgency=low . * adjusted variable description for umc/http/interface; Bug #26470
(In reply to comment #18) > Die Hilfebeschreibung wurde angepasst. Ist korrigiert
UCS 3.0-2 has been released: http://forum.univention.de/viewtopic.php?f=54&t=1905 If this error occurs again, please use "Clone This Bug".