Hallo,
mein UCS-Server (Basissystem) befindet sich in einem LAN,
abgeschottet durch eine Firewall ohne Zugang zum Internet.
Fall 1:
Trage ich auf dem UCS-Server in /etc/resolv.conf den
(unerreichbaren) Nameserver meines Providers ein
(217.0.43.193), dann bootet der Server “normal”.
Fall 2:
Trage ich in /etc/resolv.conf den Nameserver ein, den ich
selbst im LAN betreibe und der vor allem Namen im LAN aber
ueber einen Forwarder auch Namen aus dem Internet aufloest,
dann stoppt der Bootvorgang fuer ca. 6 Minuten nach der Ausgabe
von “Starting … cron … [ok]”.
Was ich herausgefunden habe:
In /etc/rc2.d/ folgt auf S89cron S97univention-maintenance.
“date; /etc/rc2.d/S97univention-maintenance start; date”
erzeugt z.B. folgende Ausgabe:
Fr 22. Jan 18:30:02 CET 2010
Univention Updater is updating the system.
- Starting Univention Updater
…done.
Fr 22. Jan 18:36:21 CET 2010
Ausgeloest wird das lange Warten in S97univention-maintenance
durch die Zeile
/usr/sbin/univention-updater net --check
Im python-Script /usr/sbin/univention-updater wird in Zeile 279
offenbar eine Instanz der Klasse UniventionUpdater() erzeugt mit
“updater = UniventionUpdater()”.
Leider kann ich kein python, ich denke folgendes:
Die Klasse UniventionUpdater() wird definiert in der Datei
/usr/share/pyshared/univention/updater/tools.py
Dort bei “class UniventionUpdater: … init …” scheint die
Funktion schnell abgebrochen zu werden, wenn kein Nameserver
available ist, was dem obigen Fall 1 entspricht.
Was da (6 Minuten lang) passiert, wenn zwar ein Nameserver
available ist, aber keine Verbindung zum Univention Update
Server (apt.univention.de) moeglich ist, verstehe ich nicht.
Ich habe provisorisch mit
“univention-baseconfig set repository/online/server=xyz” den
nicht existierenden Update Server “xyz” eingetragen, damit das
Booten wieder schneller geht.
Besser ist es sicher, den Aufruf von /etc/rc2.d/S97univention-
maintenance beim Booten ganz abzuschalten. aber ich finde nicht
die passende Registry-Variable.
Tschuess
Karl