Univention Bugzilla – Bug 26432
Fehlermeldung bei Errata-Updates
Last modified: 2018-04-14 13:51:44 CEST
Created attachment 4259 [details] Logfile Auf einem mit Samba4 installierten System trat währende des Errata-Updates (Befehl: "univention-upgrade --updateto 3.0-0") ein Fehler auf, so dass bei Errata10 abgebrochen wurde. Im errata-updates.log steht findet sich folgender Traceback: ========================= Traceback (most recent call last): File "/usr/share/univention-updater/univention-errata-update", line 247, in <module> updater = univention.updater.UniventionUpdater() File "/usr/lib/pymodules/python2.6/univention/updater/tools.py", line 451, in __init__ self.ucr_reinit() File "/usr/lib/pymodules/python2.6/univention/updater/tools.py", line 507, in ucr_reinit assert self.server.access('/univention-repository/') File "/usr/lib/pymodules/python2.6/univention/updater/tools.py", line 384, in access raise ConfigurationError(uri, reason) ConfigurationError: Configuration error: host is unresolvable Error: an error occurred during the update: Configuration error: host is unresolvable. Please check the logfile /var/log/univention/errata-updates.log ========================= Das Logfile ist angehangen an diesen Bug.
Beim nochmaligen Start laufen die Errata-Updates ab 11 weiter durch. Vielleicht wurde der DNS-Dienst zwischendurch neu gestartet?
Gleiches habe ich eben beim Update ohne errata auf errata47 beobachtet. System war hier allerdings 3.0-1. updates.software-univention.de war laut ping und nmap "unbekannt". nslookup hat die Adresse aber aufgelöst. "google.de" konnte hingegen erfolgreich angepingt werden. Ein Neustart von bind9 hat keine Abhilfe geschaffen - nach einigen Minuten Diagnose gab es dann ohne weiteres Zutun ein "self heal" und nach dem Committen der Sourcen ging es wieder...
(In reply to comment #2) > updates.software-univention.de war laut ping und nmap "unbekannt". nslookup hat > die Adresse aber aufgelöst. "google.de" konnte hingegen erfolgreich angepingt > werden. Ein Neustart von bind9 hat keine Abhilfe geschaffen - nach einigen > Minuten Diagnose gab es dann ohne weiteres Zutun ein "self heal" und nach dem > Committen der Sourcen ging es wieder... ping, nmap und nslookup verwenden verschiedene Routinen zur Namensauflösung: ping und nmap verwenden den über NSS konfigurierten Mechanismus (hier: resolver der libc6), insbesondere NSCD. nslookup verwendet dagegen den "Light Wight Resolver" direkt von Bind9, der direkt eine DNS-Anfrage generiert. Wenn der NSCD einmal eine negative Antwort (unresolvable) gecached hat, speichert er diese auch für die in der /etc/nscd.conf konfigurierte "negative-time-to-live" Zeit zwischen, d.h. alle weiteren Anfragen innerhalb dieser Zeit schlagen auch fehl. Da liblwres aber eben nicht NSS verwendet, bekommt man dort den aktuellen Stand im Gegensatz zum veralteten gecachten Zustand. $ grep negative-time-to-live /etc/nscd.conf # negative-time-to-live <service> <time in seconds> negative-time-to-live passwd 20 negative-time-to-live group 60 negative-time-to-live hosts 20
This issue has been filed against UCS 3. UCS 3 is out of the normal maintenance and many UCS components have vastly changed in UCS 4. If this issue is still valid, please change the version to a newer UCS version otherwise this issue will be automatically closed in the next weeks.
This issue has been filed against UCS 3.0. UCS 3.0 is out of maintenance and many UCS components have vastly changed in later releases. Thus, this issue is now being closed. If this issue still occurs in newer UCS versions, please use "Clone this bug" or reopen this issue. In this case please provide detailed information on how this issue is affecting you.