resolvconf-Konfiguration auf den ltsp

[Rüdiger Kupper]

Beim Aufsetzen des ltspl1 ist mir aufgefallen, dass die resolvconf-Konfiguration auf den LtspServern nicht sauber ist: Effektiv war die ganze Funktion von resolvconf ausgehebelt.
In der /etc/network/interfaces fanden sich überhaupt keine dns-* Einträge, stattdessen wurden die Einträge über das "tail"-File festgelegt. Das ist Murks.

• entweder resolvconf verwenden und die dns-* Einträge in der /etc/network/interfaces machen
• oder resolvconf gar nicht verwenden und die Einträge von Hand in /etc/resolv.conf machen

[Rüdiger Kupper]

Okay, das war nicht ganz einfach :-). Ich musste Deinen dnsmasq-Mechanismus für den PXE-Boot verstehen und viel über dnsmasq/resolvconf lernen. Daher ist dieser Kommentar auch etwas länglich (trotzdem bitte lesen ;-))

Im Bereich DNS gibt es mehrere Pakete/Mechanismen, die miteinander interagieren (oder es zumindest sollten):

• die gute alte /etc/resolv.conf
• der resolvconf-Mechanismus. Dieser erzeugt den Inhalt von /etc/resolv.conf dynamisch, auf Anfrage beliebiger Programme, die sich mit dem Netzwerk befassen (z.B. ppp, ifup/down, was das einzige ist, das für uns entscheidend ist). Vgl. "man resolvconf"
• NetworkManager, standardmäßig Bestandteil von Ubuntu Desktop. Stellt bei wechselndem Verbindungsangebot immer die "beste" Verbindung her. Zu diesem Zweck startet es einen dnsmasq-Prozess, der DNS-Anfragen an den gerade "aktuellen" DNS-Server weiterleitet -- unter der Annahme, dass auf dem System sonst standardmäßig kein dnsmasq läuft. Läuft dort einer, wird davon ausgegangen, dass der DNS laut Standardkonfiguration übernimmt. (Hinweis: weil das zu oft zu Problemen führte, startet NetworkManager nun wohl einen zusätzlichen dnsmasq auf Port 127.0.1.1 für seine Zwecke. Das ist aber noch nicht Teil von Ubuntu 13.04)
• dnsmasq, wobei die Standardkonfiguration annimmt, dass der auch das DNS übernimmt. Falls zusätzlich ein resolvconf auf dem System läuft (was in Ubuntu Standard ist), müssen die beiden Mechanismen unbedingt miteinander kommunizieren, weil sonst der eine dem anderen "den Boden unter den Füßen wegzieht..."

...und genau das war bei uns der Fall.

Bei uns läuft neuerdings ein explizit gestarteter dnsmasq für den DHCP/PXE-Boot. Wie es sich gehört, hattest Du den so konfiguriert, dass er nur das macht, was er muss, nämlich DHCP und kein DNS-Forwarding. Das widersprach allerdings der Annahme, welche die Ubuntu-Standardkonfigurationen machen.
Das sind kurz gesagt folgende:

• es läuft ein resolvconf-Prozess, der den Inhalt von /etc/resolv.conf dynmaisch erzeugt
• seine Informationen (welcher DNS-Server und welche Search-Domain?) erhält resolvconf von den Daemons, welche die Netzwerk-Interfaces verwalten. Bei uns ist da nur "ifup/down" relevant. Dieser liest aus der /etc/network/interfaces die Einträge "dns-nameservers" und "dns-search" und leitet sie an resolvconf/ weiter. resolvconf schreibt diese dann in die /etc/resolv.conf, und der Name-Lookup funktioniert.

Dieser Mechanismus war bei uns bereits nicht mehr funktional, weil (a) die "dns-*"-Einträge in /etc/network/interfaces fehlten, und (b) die Datei /etc/resolvonf/resolvcnf.d/tail hart eincodierte dns-Einträge aufwies (was allerdings auch nicht stört).

Ich habe nun die "dns-*"-Einträge auf allen LtspServern in /etc/network/interfaces hinzugefügt (und ebenfalls im Ltsp-setup -Skript, per [603/keplertools]). Dann habe ich die hart eincodierten DNS-Einträge entfernt, in der Erwartung, dass resolvconf die ja dynamisch erzeugt -- und nichts ging mehr. Keine DNS-Auflösung.

Ursache: Bei uns läuft außerdem noch ein dnsmasq-Prozess. Und jetzt wird's spaßig: resolvconf und dnsmasq interagieren. Dnsmasq hat nämlich standardmäßig die Aufgabe, DNS-caching und -forwarding zu machen. Dazu liest es den Inhalt von /etc/resolv.conf aus, übernimmt die dortigen DNS-Server-Einträge in seine eigene Konfiguration und schreibt sich dann selbst in die /etc/resolv.conf ("nameserver 127.0.0.1" = schickt bitte alle DNS-Anfragen an localhost, denn dort läuft der dnsmasq).

Soweit, so gut. Da aber nun sowohl resolvconf als auch dnsmasq an der /etc/resolv.conf herummanipulieren, müssen sich die beiden Mechanismen austauschen. Das geschieht folgendermaßen:

Wird das dnsmasq-Paket installiert und stellt fest, dass ebenfalls das resolvconf-Paket installiert ist, so erzeugt es einen "Hook" für resolvconf. Dieser sorgt dafür, dass resolvconf sein Ergebnis eben nicht direkt nach /etc/resolv.conf schreibt, sondern nach /var/run/dnsmasq/resolv.conf. Gleichzeitig wird das init.d-Startskript für dnsmasq so modifiziert, dass es bei seinem Start die Informationen über den aktiven DNS-Server nicht mehr aus /etc/resolv.conf liest, sonder eben aus /car/run/dnsmasq/resolv.conf. Danach schreibt es sich als "nameserver 127.0.0.1" selbst in die /etc/resolv.conf)

Bis ich diesen Mechanismus durschaut hatte, hat es einige Zeit gedauert :-).

Der Punk war nun: Bei uns hat das alles nicht recht funktioniert, denn

1. hat der Hook für resolvconf gefehlt, die Datei /var/run/dnsmasq/resolv.conf wurde also nie erzeugt.
2. hattest Du dem dnsmasq explizit gesagt, dass er gar kein DNS machen sollte (logisch, war für den PXE-Boot ja auch nicht erforderlich)

Beides hat dazu geführt, dass der DNS-Lookup nicht mehr funktionierte, sobald ich resolvconf aktiviert hatte.

Zwei Möglichkeiten standen zur Wahl:

1. resolvconf deaktiviert lassen, die Datei /etc/resolv.conf von Hand verwalten, dnsmasq nur für DHCP benutzen. Das wäre eine Option, auf einem Server mit statischen Interfaces allemal.
2. Den Hook wiederherstellen und die dnsmasq-Konfiguration so anpassen, dass es DNS-Caching und -Forwarding macht.

Ich habe mich schließlich für den 2. Weg entschlossen, aus folgenden Gründen:

• einfachere Wartung bei zukünftigen Updates: Dies ist die von Ubuntu erwartete und verteilte Konfiguration. Bei zukünftigen Updates kann so einfach die neue Version der Config-Files übernommen werden, ohne dass irgend etwas von Hand angepasst werden muss. Das macht mir die Arbeit bei zukünftigen Updates einfacher.
• wir erhalten einen kleinen Performancegewinn, weil die lokalen dnsmasq-Prozesse DNS-Caching machen. Wenn sich also im Computerraum 20 Schüler auf dem selben Server einloggen und alle die selbe Internetseite anfragen (was nicht ungewöhnlich ist), gehen nun keine 20 DNS-Anfragen mehr an 10.32.1.251 heraus, sondern nur noch eine, und danach erfüllt der lokale dnsmasq den Name-Lookup. Das finde ich elegant.

Ich habe daher folgendes vorgenommen:

• resolvconf- und dnsmasq-Pakete reinstallieren, dabei wurden die Standardkonfigurationsdateien wiederhergestellt, u.a. der Hook für den Austausch zwischen resolvconf und dnsmasq. Außerdem wurde das Konfigurationsfile für dnsmasq mit der Standardversion überschrieben.
• Deine zuvor vorgenommene Anpassung, in /etc/init.d/dnsmasq die Option CONFIG_DIR zu setzen, habe ich auf einem anderen Weg realisiert, nämlich in /etc/defaults/dnsmasq. Dort steht jetzt also die einzige Anpassung, die auf den LtspServern vorzunehmen ist, um den PXE-Boot zu aktivieren, namlich die CONFIG_DIR-Option zu setzen. Das entspricht dem in letzter Zeit verstärkt eingesetzten Pragmatismus, alle administrativen Änderungen in /etc/defaults vorzunehmen.
• In Deinen dnsmasq-Konfig-Fils in /etc/dhcp3/ltsp_config habe ich den Eintrag "port=0" entfernt, damit der gestartete dnsmasq-Prozess seinen DNS-Job wieder erfüllt. Ebenso habe ich dort den searchdomain-Eintrag entfernt, weil der nun in /etc/network/interfaces steht. Dein Template für die neue Erzeugung der dnsmasq-Konfigurationen habe ich ebenfalls etsprechend angepasst. Praktischerweise steht das Verzeichnis ja unter svn-Verwaltung (ich nehme an, Du hast es einfach komplett vom paedml auf die LtspServer kopiert?). Siehe [604/keplertools].

Nun funktioniert alles, wie es soll:

• der dnsmasq verteilt die DHCP/PXE-Boot-Anfragen wie gewünscht
• er übernimmt außerdem seine generische Aufgabe als DNS-Forwarder und -Cacher
• er interagiert mit reolvconf wie gewünscht. Alle DNS-Anfragen gehen also an 127.0.0.1:53, wohinter der dnsmasq sitzt und die Anfragen nur einmal an unseren DNS-Server 10.32.1.251:53 weiterleitet. Danach beantwortet er Anfragen aus seinem Cache, was einen gewissen Performacegewinn bringen müsste. (Zumal zuvor der Eintrag 127.0.0.1 ebenfalls in der /etc/resolv.conf stand, aber nicht funktionierte! Daher haben vermutlich in der letzten Zeit alle DNS-Anfragen auf den LtspServern eine Sekunde gedauert, bis sie beantwortet wurde. Das ist nun behoben.)

Konfiguration

Die einzigen Stellen, an denen nun noch etwas konfiguriert werden muss/sollte, sind:

• /etc/network/interfaces. Hier gehören die "dns-*"-Einträge zum Nameserver und der Searchdomain hin. Die sind für alle Server im Schülernetz die selben, ebenso im Lehrernetz.
• /etc/defaults/dnsmasq. Hier muss die Option CONFIG_DIR für dnsmasq gesetzt werden. Verwendet man dort Deine Schreibweise mit $(hostname), ist diese Datei auf allen LtspServern identisch.
• das ltsp_config-Verzeichnis in /etc/dhcp3 muss auf allen LtspServern existieren (und nach /etc/dnsmasq/...(?) verlinkt sein).

[bau]

Spannend - schon wieder ein Mechanismus, den wir nun verstehen :-)
GUTE ARBEIT!