Wenn die Updates über einen Proxy bezogen werden, kann es sein, dass der lokale Nameserver den Namen apt.univention.de nicht auflösen kann, aber das Update trotzdem funktioniert, weil die Auflösung über den Proxy erfolgt. Momentan führt dieser Zustand aber zu einem Traceback: root@ucselvis:~# univention-updater net Traceback (most recent call last): File "/usr/sbin/univention-updater", line 590, in ? main() File "/usr/sbin/univention-updater", line 506, in main nextversion=update_available('net', baseConfig, cdrom_mount_point,sourcedir, stdout, sys.stdout, reboot, iso=iso, updater=updater) File "/usr/sbin/univention-updater", line 281, in update_available nextversion = updater.release_update_available() File "/usr/lib/python2.4/site-packages/univention/updater/tools.py", line 280, in release_update_available return self.get_next_version( UCS_Version( ( self.version_major, self.version_minor, self.patchlevel ) ) ) File "/usr/lib/python2.4/site-packages/univention/updater/tools.py", line 269, in get_next_version if self.net_path_exists( '%d.%d/maintained/%d.%d-%d/' % ( version.major, version.minor, version.major, version.minor, version.patchlevel + 1 ) ): #check for x.y-(z+1) File "/usr/lib/python2.4/site-packages/univention/updater/tools.py", line 218, in net_path_exists proxy_headers = self.open_connection(server=server, port=port) File "/usr/lib/python2.4/site-packages/univention/updater/tools.py", line 120, in open_connection raise 'UniventionUpdater', 'The repository server %s could not be reached.' % (self.configRegistry.get('repository/online/server', 'apt.univention.de')) UniventionUpdater: The repository server apt.univention.de could not be reached. Die Überprüfung sollte entweder angepasst werden (direkter Webzugriff über den Proxy versuchen) oder abschaltbar sein.
Welche Version vom Updater war das? Ist das nicht mit UCS 2.2-2 angepasst worden? Was passiert, wenn der Repository Server auf die IP gesetzt wird, bspw.: ucr set repository/online/server="87.106.64.32" Zumindest auf einem UCS 2.2-2 System lief es dann problemlos durch.
(In reply to comment #1) > Welche Version vom Updater war das? Ist das nicht mit UCS 2.2-2 angepasst > worden? Wenn ich das richtig weiß, ist mit 2.2-2 die Überprüfung eingebaut worden. Siehe Bug #13696 > Was passiert, wenn der Repository Server auf die IP gesetzt wird, bspw.: > ucr set repository/online/server="87.106.64.32" > > Zumindest auf einem UCS 2.2-2 System lief es dann problemlos durch. Das müsste auch in diesem Fall gehen. Ich finde das ist aber eher ein Workaround.
Das Problem ist, daß in modules/univention/updater/tools.py zum Testen, ob DNS funktioniert, immer repository_server verwendet wird, auch wenn eigentlich eine http-Verbindung zu proxy_server aufgeaut wird.
*** Bug 16567 has been marked as a duplicate of this bug. ***
Wie besprochen, bitte prüfen ob der einfach umsetzbar ist. Wenn nicht, dann sollten wir den Bug nicht zur 2.3-1 beheben.
Zusätzlich ist es i.M. so, dass wenn der Repo-Server aufgelöst werden kann, der Proxy aber nicht, man folgende Fehlermeldung bekommt Error: The name qamaster.univention.qa is not known. Please check your network settings or set the UCR variable repository/online/server to a different value. Je nachdem wie der eigentlich Bug hier gelöst wird, sollte zumindest in der Fehlermeldung dann noch auf eine möglicherweise falsche Proxy Konfiguration (proxy/http) verwiesen werden.
Wie besprochen, bitte den Patch anhängen und dann vertagen wir den Fix, da das Problem derzeit nicht kritisch ist.
Created attachment 2236 [details] univention/updater/tools.py Rewrite Die Klasse UniventionUpdater wird auch von UniventionMirror, univention-updater, univention-security-update und univention/management/console/handlers/update/__init__.py verwendet. Letzteres ändert immer noch direkt einige Repository-Einstellungen und ruf reinit() auf. In den anderen Programmen ist immer eine Sonderbehandlung notwendig, wenn ein Proxy verwendet wird, da dann ein anderer Rechner kontaktiert, ein Prefix eingefügt und ggf. weitere HTTP-Header gesendet werden müssen. Deswegen neu geschrieben: ResolvableUrl() dient dem Zugriff auf eine URL und kapselt alle Proxy-Angelegenheiten. Kann sowohl zum herunterladen von Dateien (method='GET') als auch nur zum testen (method='HEAD') verwendet werden. In der Klasse wird auch behandelt, wenn der Name des Rechners nicht per DNS aufgelöst werden oder nicht erreicht werden kann (failed). RepositoryConfig() enthält alle Konfigurations-Einstellungen, die für den Zugriff auf ein Repository notwendig sind. Da die Namen der 'repository_*'-Variablen an mehreren Stellen verwendet werden, wurden die Namen beibehalten. Über die Methode repository() lässt sich aus den Einstellungen das eine ResolvableUrl()-Instanz erzeugen. Über repositoryFromRegistry() lässt sich die Konfiguration auch direkt aus dem U-Config-Registry erstellen- UniventionUpdater(): Da die Prefix-Geschichte jetzt in ResolvableUrl() gehandhabt wird, entfallen die ganzen Fallentscheidungen in den einzelnen Methoden. Für alle Methoden sind doctest's angegeben, die natürlich stark von den momentanen UCR-Einstellungen und den verfügbaren Servern abhängen. Weitere Vermesserungsmöglichkeiten: - Die ganzen Stellen, wo die URL zusammengestückelt und anschließend getestet wird, um dann abschließend die 'deb'- (und 'clean-') Zeilen zu konstruieren), können jetzt vermutlich auch noch vereinfacht werden. Getestet wurde bisher: - /etc/apt/sources.list.*/ und /etc/apt/mirror.list werden weiterhin richtig (bzw. sogar richtiger Bug #17428) erzeugt. Es muß noch getestet werden: - Interaktion mit UMC - Aufruf der u-updater, u-s-update, u-r-*, ...
Created attachment 2250 [details] univention/updater/tools.py Rewrite In mirror.py wurde noch "repository/online/*" statt "repository/mirror/*" verwendet.
erneut aufgefallen an Ticket#: 2011012710001845
Erneut aufgefallen an Ticket#2011031710001388 --- [...] nicht möglich über die UMC nach Updates zu suchen. Die Meldung lautete, das "apt" einen Fehler verursacht hatte. Die Meldung in den Logs lies darauf schließen, das etwas mit dem angegebenen Nameserver nicht korrekt sei. Allerdings war eine aktualisierung auf der Konsole möglich und auch andere Systeme konnten ohne Probleme über den gleichen Nameserver DNS auflösungen vornehmen. Versuchsweise gaben wir als Nameserver nicht unseren eigentlichen, primären, Nameserver an sondern ebenfalls den Proxy, da dieser auch eine DNS Auflösung unterstützt. Nach dieser Konfigurationsänderung konnten wir plötzlich auch über die UMC nach Updates suchen und diese installieren. Scheinbar ist das OX6ASE System so konzipiert, das eine DNS Auflösung erzwungen wird noch bevor das System den Proxy anspricht. ---
Der Bug ist mittlerweile auch behoben: # iptables -A OUTPUT -d apt.knut.univention.de -j REJECT # iptables -A OUTPUT -d apt.univention.de -j REJECT # iptables -A OUTPUT -d univention-repository.knut.univention.de -j REJECT # host xen5.knut.univention.de xen5.knut.univention.de has address 192.168.0.115 # mv /etc/resolv.conf /etc/resolv.conf.orig # ucr set proxy/http="http://192.168.0.115:3128" repository/online/server=apt.knut.univention.de repository/online/prefix= # ucr commit /etc/apt/sources.list.d/15_ucs-online-version.list # wegen Bug #12571 # grep ^deb /etc/apt/sources.list.d/15_ucs-online-version.list | wc -l 88 ChangeLog: \item Die Unterstützung von Proxies im Updater wurde verbessert und es werden jetzt mögliche Fehkonfigurationen besser erkannt und gemeldet (\ucsBug{21583}, \ucsBug{15550}).
(1) ProxyServer ist nicht per DNS auflösbar - OK: -> univention-updater net Error: Update aborted due to configuration error: Proxy configuration error: host is unresolvable Error: Please check "/var/log/univention/updater.log" for details. UMC Die Verbindung zum Repository-Server ist fehlgeschlagen: host is unresolvable. Bitte überprüfen Sie die Repository-Konfiguration und die Netzwerkverbindung. (2) Repo Server lokal nicht auflösbar, aber vom Proxy - OK: Ein UCS 2.4-1 mit ucs2.4-2 (a), ein UCS 2.4-1 mit squid (b). Auf a den dns forwarder entfernt, ping auf apt.knut.univention.de ist hier dann nicht mehr möglich (unknown host apt.knut.univention.de). Als HTTP Proxy wurde auf Rechner a auf b gesetzt. Update (UMC) und commit auf die sources.list Files haben funktioniert. (3) Repo Server lokal und vom Proxy nicht auflösbar: Szenario wie (2), jedoch repository/online/server="apt.knut.univention.dee" gesetzt, patchlevel auf 0 gesetzt version/patchlevel=0 und Update gestartet: -> univention-updater net Checking network repository System is up to date (UCS 2.4-0) Dies läßt sich aber wohl nicht vermeiden, da der Proxy in diesem Fall den Fehler zurück gibt, den er auch wirft wenn das Update wirklich nicht da ist.
UCS 2.4-2 wurde veröffentlicht. Sollte der hier beschriebene Bug mit einer neueren Version von UCS erneut auftreten, so sollte der Bug dupliziert werden: "Clone This Bug".
*** Bug 22194 has been marked as a duplicate of this bug. ***