Bug 29880 - DNS Timeouts / resolv.conf Handling
DNS Timeouts / resolv.conf Handling
Status: CLOSED FIXED
Product: Z_Univention Corporate Client (UCC)
Classification: Unclassified
Component: General
unspecified
Other Linux
: P5 normal
: UCC 1.0
Assigned To: Felix Botner
Moritz Muehlenhoff
: interim-3
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-12-21 14:32 CET by Felix Botner
Modified: 2013-03-26 09:14 CET (History)
2 users (show)

See Also:
What kind of report is it?: ---
What type of bug is this?: ---
Who will be affected by this bug?: ---
How will those affected feel about the bug?: ---
User Pain:
Enterprise Customer affected?:
School Customer affected?:
ISV affected?:
Waiting Support:
Flags outvoted (downgraded) after PO Review:
Ticket number:
Bug group (optional):
Max CVSS v3 score:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Felix Botner univentionstaff 2012-12-21 14:32:13 CET
Wenn ich einem UCC Client das Netzwerk wegnehme (Kabel gezogen), kommt es zu diversen DNS Timeouts, das System ist praktisch nicht mehr verwendbar.

Wenn ich "options timeout:2" in die resolv.conf aufnehme, wird es schon etwas besser, wenn ich alles in der resolv.conf auskommentiere, läuft das System rund.

Wir müssen uns noch überlegen, wie die resolv.conf auf Änderungen des Netzwerk-Status reagieren soll (vielleicht kann man sich auch einmal dnsmasq bzw. openresolv anschauen).
Comment 1 Moritz Muehlenhoff univentionstaff 2013-01-09 17:08:20 CET
Bitte mal mit dem aktuellen UCC-Stand testen: 

1. Ein Desktop-Image installieren 
2. Joinen
3. Mit einem Domänen-Benutzer anmelden
4. Netzkabel ziehen

Ist ein typischer Offline-Betrieb weiterhin möglich?
Comment 2 Erik Damrose univentionstaff 2013-01-15 11:19:47 CET
Einem virtuellen Desktop Image per 

sudo virsh qemu-monitor-command "$VM" --hmp "set_link net0 off"

den Netzstecker zu ziehen hat keine merkbaren Auswirkugen auf das System, Offline weiterarbeiten geht flüssig.
Comment 3 Stefan Gohmann univentionstaff 2013-01-15 11:35:20 CET
(In reply to comment #2)
> Einem virtuellen Desktop Image per 
> 
> sudo virsh qemu-monitor-command "$VM" --hmp "set_link net0 off"
> 
> den Netzstecker zu ziehen hat keine merkbaren Auswirkugen auf das System,
> Offline weiterarbeiten geht flüssig.

Bitte auch testen, ob der Boot usw. funktioniert.
Comment 4 Erik Damrose univentionstaff 2013-01-15 12:25:59 CET
Boot funktioniert, allerdings gibt es einen langen timeout beim warten auf das Netzinterface (um die 2 Minuten).

Wenn in der /etc/network/interfaces das device eth0 von auto auf allow-hotplug gesetzt wird, wird dhcp bei fehlendem Kabel gar nicht erst gestartet. Allerdings wird das spätere einstecken eines Kabels nicht bemerkt und das interface nicht konfiguriert. 

Hierbei kann evtl. ifplugd helfen und standardmäßig installiert werden.
Comment 5 Erik Damrose univentionstaff 2013-01-24 13:01:38 CET
In bug 30031 wurde die Konfiguration so angepasst das nach einer Installation der networkmanager die Schnittstellen konfiguriert. Damit kommt es auch beim booten nicht mehr zu langen timeouts.
Comment 6 Lukas Walter univentionstaff 2013-01-31 10:55:15 CET
Ich konnte keim Booten keine Timeouts mehr feststellen.

Daher, Verified.
Comment 7 Felix Botner univentionstaff 2013-02-12 15:48:03 CET
Wenn ein System in ein anderes Netz kommt und eine andere DHCP Konfiguration bezieht, wird diese nicht in /etc/resolv.conf abgebildet und es kommt zu timeouts.
Comment 8 Felix Botner univentionstaff 2013-02-13 11:25:01 CET
Wir verwenden jetzt standardmäßig bei gejointen System den NetworkManager und den lokalen "dns forwarder" dnsmasq mit nameserver1=127.0.0.1 für DNS (kubunut Standard).

Falls eine "externer" DNS Server verwendet wird, wird das dnsmasq Backend vom NetworkManager entsprechend auf diesen Nameserver konfiguriert.

Gibt es kein DHCP kommt es in diesem Setup nicht zu Timeouts bei der Namensauflösung (es gibt sofort einen entsprechenden Fehler).

Änderungen: 

univention-ucc-initramfs:
Zu Beginn wird die resolv.conf aus der initrd (falls sie existiert und ein nameserver gesetzt hat) in das Image kopiert damit dort die Namensauflösung klappt. Am Ende wird nun, falls das System gejoint ist, ein commit auf die resolv.conf im Image gemacht, damit im System dann die Einstellungen aus UCR für die Namensauflösung gelten.

univention-ucc-join:
Die Nameserver auf resolv.conf werden nun nicht mehr übernommen. Statt dessen wird am Ende des join nameserver1 auf 127.0.0.1 gesetzt (damit der dnsmasq des System verwendet wird).

Damit sollten es auch möglich sein neben dem Standard-Setup (NetworkManager und dnsmasq) eine eigene Netzwerk-Konfiguration per UCR vorzugeben.
Comment 9 Moritz Muehlenhoff univentionstaff 2013-02-13 17:00:15 CET
Ein ausgerollter Client verwendet für die Namensauflösung standardmässig 127.0.0.1.

Ein PXE-Boot funktioniert weiterhin, hier steht dann der UCC-PXE-Server als Nameserver in der /etc/resolv.conf.

Ein Start auf einem Notebook ohne Netz findet ohne spürbare Verzögerung statt. Bei abzogenem Netzwerkkabel kommt ein "ping univention.de" auch ohne Timeouts direkt zurück. Steckt man an einen Client, der ohne Netz gebootet wurde ein
Netzwerkkabel an, erfolgt direkt eine Konfiguration per DHCP und die Namensauflösung funktioniert nach einigen Sekunden.

Ein Client wurde mit dem DNS-Server des UCS-System gebootet und verwendet dann dessen Nameserver. Anschließend wurde der Client heruntergefahren und die DHCP-Konfiguration auf den Google-Nameserver umgestellt (8.8.8.8), also das Szenario, dass das Notebook mit ins Home Office genommen wird. DNSmasq verwendete dann den 8.8.8.8-Nameserver.
Comment 10 Moritz Muehlenhoff univentionstaff 2013-03-26 09:14:10 CET
UCC 1.0 has been released: 
http://forum.univention.de/viewtopic.php?f=26&t=2417
http://forum.univention.de/viewtopic.php?f=54&t=2418

If this error occurs again, please use "Clone This Bug".