PXE Bootmenu erzeugen und Testen

[bau]

DNSMASQ eignet sich hervorragend als Proxy-DHCP, dabei kann bei dnsmasq der Service DHCP abgeschaltet werden (dhcp-range=proxy, der DNS-Dienst muss garnicht erst eingeschaltet werden). Über die Schalter

 pxe-prompt=
 pxe-service=

können verschiedene PXE-Boot-Optionen auch auf anderen TFTP-Servern angesteuert werden, genau das, was wir wollen. Hintergrundinfos:

• ​http://www.thekelleys.org.uk/dnsmasq/docs/dnsmasq-man.html
• ​http://www.syslinux.org/wiki/index.php/PXE_native_boot_menu

Auf den LTSP läuft wegen des LXC bereits ein dnsmasq, auf dem virtuellen Network-Device lxcbr0. Wo muss der dnsmasq konfiguriert werden, damit er auch auf eth0 hört? Oder kann man den auch mehrmals starten?

[Rüdiger Kupper]

Aus der Manpage von dnsmasq:

-i, --interface=<interface name>

Listen only on the specified interface(s). Dnsmasq automatically adds the loopback (local) interface to the list of interfaces to use when the --interface option is used. If no --interface or --listen-address options are given dnsmasq listens on all avail‐ able interfaces except any given in --except-interface options. IP alias interfaces (eg "eth1:0") cannot be used with --inter‐ face or --except-interface options, use --listen-address instead.

Wie ich sehe, hat ltsp1 bereits ein /etc/dnsmasq/dnsmasq.conf-File mit der option interface=eth0. Läuft dort bereits ein dnsmasq?

[Rüdiger Kupper]

Querverweis: #52. Wenn das PXE-Menü funktioniert könnte auch das automatische Aufnehmen neuer LtspClients darüber laufen.

[bau]

Ich habe mal am ltsp1 mit dnsmasq herumgespielt, bin bislang aber noch nicht richtig dazugekommen (Notenkonferenzen, Projekttage). Ich bleibe dran.

[bau]

Bootmenü funktioniert nun, auf allen ltsp läuft ein dnsmasq, der dieses ausliefert, ebenso auf dem proxy im Schülernetz (liefert für Rembo das Bootmenu aus). Der isc-dhcp auf dem paedml liefert nur noch für registrierte Laptops und für LinboHosts IP's aus. Dynamisch kommen IP von den dnsmasq-Servern, im PXE-Bootmenu kann dann Linbo ausgewählt werden.

Näheres unter

• AdminIp
• AdminPxe
• PaedmlAnpassungen

Die dnsmasq auf den ltsp-Servern benötigten noch den User dnsmasq, den ich angelegt habe. Das Startscript habe ich vom proxy rüberkopiert und angepasst, es startet die Config aus

/etc/dnsmasq.d/ltsp_config/ltspX/conf

Die Clients, die versorgt/nicht versorgt werden sollen stehen in

/etc/dnsmasq.d/ltsp_config/ltspX/clients
/etc/dnsmasq.d/ltsp_config/ltspX/notclients

Die Dateien werden per script auf dem paedml erzeugt und per rsync auf die ltsp-Server verteilt.

ToDo:
Die Aufweckscripte leben noch von den Config-Dateien unter /etc/dhcp3 (eventuell noch einiges anderes).
Ich habe die Client-Infos zentral zusammengefasst unter /etc/linuxmuster/workstations und /etc/dhcp3/ltsp_config. Die Scripte müssten entsprechend angepasst werden.

[Rüdiger Kupper]

Okay.

[bau]

Ich habe abschließend noch die Rechner in 1.09 und 1.10 im BIOS auf PXE-booten umgestellt und dabei gleich noch USB-Legacy-Support eingeschaltet, wo das noch nicht der Fall war und desweiteren auch das BIOS-Passwort gesetzt. Richtig gut: per bootmenu kann man jetzt auch in den PCRäumen mit Edubuntu arbeiten, dasselbe gilt für die Clients in den Fachräumen (Physik, NwT, BK), hier muss ich nur noch die Bootreihenfolge im BIOS anpassen.

[Rüdiger Kupper]

Replying to bau:

Richtig gut: per bootmenu kann man jetzt auch in den PCRäumen mit Edubuntu arbeiten, dasselbe gilt für die Clients in den Fachräumen (Physik, NwT, BK), hier muss ich nur noch die Bootreihenfolge im BIOS anpassen.

Das klingt super! Ich glaube, genau dafür gab es auch ein Ticket, das jetzt geschlossen werden kann.

Ehrlichgesagt durchschaue ich noch nicht genau, was Du da jetzt implementiert hast, aber Du vermittelst den Eindruck, dass Du die Übersicht hast ;-).

[bau]

Ja, nachdem ich eine Woche mit dem dnsmasq und der irrwitzigen PXE-Implementierung gekämpft habe sieht das Ergebnis eigentlich ganz einfach aus :-)

Neben den Aufweckscripten sind es auch noch die shutdownclients-Scripte, die geändert werden müssen. Ich würde mir beim Aufwecken noch eine Optionen wünschen:

• -c Clientname
• -s ltspserver (alle clients des angegebenen ltsp-server)
• -rr rembo/raum
• -ra rembo/alle
• -a alle Clients

Grade gestern wollte ich einzelne Clients aufwecken (weil Schalter defekt) - ich habe dann die MAC aus der Config (/etc/linuxmuster/workstations) rausgesucht, die anderen Infos liegen in /etc/dhcp3/ltsp_config/ltspclients. Vielleicht kannst du ja auch noch eine Config-Datei vorsehen, in der mal Client-Namen eintragen kann, die morgens nicht eingeschaltet werden sollen.

Für den shutdown gibt es für die Windows-Clients bereits ein Script unter /root/rechneraus namens rechneraus.pl, welches die Optionen -c und -r akzeptiert. Das könntest du für die Windows-Maschinen benutzen, für das Script fände ich Optionen wie oben auch wieder ganz gut, aber da gibt es ja bereits den Parameter -m.

[bau]

Hoppla - nochwas:
Bei shutdownclients -m auf den ltsp-Servern muss in Zukunft geprüft werden, ob noch weitere Clients am Server hängen, das kann man jetzt nicht mehr aus der statischen Config entnehmen, es könnten noch weitere sein. Das müsste sich aber im Syslog finden lassen, denn der dnsmasq logged dort rein, wenn er per PXE Antworten rausgibt, eventuell macht sich auch der TFTP oder der NBD bemerkbar oder ein einfaches ARP gibt die Clients aus.

[Rüdiger Kupper]

Replying to bau:

Ich habe abschließend noch die Rechner in 1.09 und 1.10 im BIOS auf PXE-booten umgestellt und dabei gleich noch USB-Legacy-Support eingeschaltet, wo das noch nicht der Fall war und desweiteren auch das BIOS-Passwort gesetzt. Richtig gut: per bootmenu kann man jetzt auch in den PCRäumen mit Edubuntu arbeiten, dasselbe gilt für die Clients in den Fachräumen (Physik, NwT, BK), hier muss ich nur noch die Bootreihenfolge im BIOS anpassen.

Im Lehrerzimmer ging das noch nicht -- können wir auch die sechs Rechner im LZ auf das PXE-Bootmenü umstellen? Dann könnten wir ab und zu immer schonmal ein oder zwei der Rechner unter Ubuntu booten und sehen, wie die Kollegen reagieren :-).

[bau]

Sobald wir im Lehrernetz LTSP-Server stehen haben können wir das tun :-)

[Rüdiger Kupper]

Achja, klar :-).

[bau]

PXE-Bootmenü und DHCP-Umstellung laufen erstaunlich gut.
Lediglich beim Client von Hannes Roser im LZ ist das Problem, dass der Client bei Einstellung des Legacy-Supports im BIOS anschließend unendlich lange braucht, bis er mal bootet (ist so seit der Kartenleser eingebaut ist) Abhilfe wäre z.B. eine PS/2-Tastatur, dann könnte man das Bootmenü auch ohne Legacy-Support bedienen.

Ich denke, dieses Ticket kann geschlossen werden.

[Rüdiger Kupper]

Anbei: Der Client von ros braucht sowieso techische Hilfe: heute klang es so, als ob der Prozessorlüfter demnächst den Geist aufgibt. (Macht momentan eine ziemliche Lärmbelastung im LZ, ist also möglichst bald auszutauschen.)

[bau]

Hinweis: Die FSC-Clients haben keinen Prozessorlüfter, die werden vom Netzteil mitgelüftet

[Rüdiger Kupper]

Dann ist es der Netzteillüfter, jedenfalls macht er Lärm. Und sonst gibt es darin ja keine beweglichen Teile mehr :-).

[bau]

komische Sache: Ich wollte heute vom LTSP booten bekam aber immer den ltsp1. Ich stellte fest, dass auf allen LTSP-Servern zwar die PXELinux-Configs der jeweils anderen LTSP gepatcht waren nicht aber die des eigenen. So konnte das nicht funktionieren. Ich habe nun alle Configs auf allen Servern gleich gemacht. Lediglich der defazlt-Link muss auf jedem Server auf das richtige Config umgebogen sein.

[bau]

PXE-Bootmenu sind nun so umgestellt, dass jeder dnsmasq jeden Client versorgen kann. Umgesetzt habe ich das mit tagging (siehe Anleitung von dnsmasq). Bei Ausfall eines Servers übernehmen die anderen. Der Client wird dann zwar nicht mehr automatisch booten, da der Server ausgefallen ist - aus dem Bootmenü kann aber ein alternativer Server ausgewälhlt werden.

[Rüdiger Kupper]

Das ist super!

Ist das Skript zum Arzeugen der PXE-Einträge entsprechend angepsst und eingecheckt?

[bau]

Die Version von gestern ist eingecheckt.
Allerdings musste ich nochmals ändern, da ja nun alle DHCP-Server ALLE Clients versorgen.
Da musste ich zumindest den paedml rausnehmen, der versorgt nunmehr nur noch die aufgenommenen Clients, der zweite DHCP auf dem rembo-Server konnte entfallen (das kann der paedml-DHCP machen).
Außerdem musste ich auch die Einträge für DNS, WPAD und Gateway taggen, da auch aufgenommene Clients von den LTSP-Servern versorgt werden können - wer halt am schnellsten antwortet.
Ich programmiere nun noch die Änderung für das Lehrernetz, dann checke ich ein.

Etwas unschön:
Die Anzahl der Server muss in beiden Scripten, also

• /usr/local/sbin/make_ltsp_config
• /usr/local/sbin/make_ltsp_config.php

eingetragen werden.

[Rüdiger Kupper]

Ich habe jetzt auch die neuen Versionen der Dateien

• ltsp.template
• paedml.template
• ltspclients

eingecheckt (siehe [861/keplertools]).

Verstehe ich die Änderung richtig, dass

1. die Unterverzeichnisse /etc/linuxmuster/ltsp_config/ltsp{1,2,3,4,5,6,7,8,l1,l2} nicht mehr verwendet werden und gelöscht werden können?
2. diese Rolle jetzt /etc/linuxmuster/ltsp_config/clients übernimmt
3. der Inhalt dieses Verzeichnisses automatisch generiert wird und von svn ignoriert werden soll?

[bau]

Replying to kup:

Verstehe ich die Änderung richtig, dass

1. die Unterverzeichnisse /etc/linuxmuster/ltsp_config/ltsp{1,2,3,4,5,6,7,8,l1,l2} nicht mehr verwendet werden und gelöscht werden können?
2. diese Rolle jetzt /etc/linuxmuster/ltsp_config/clients übernimmt
3. der Inhalt dieses Verzeichnisses automatisch generiert wird und von svn ignoriert werden soll?

Nein, das verstehst du falsch!
In den Verzeichnissen werden die Configs für die einzelnen Server abgelegt, diese greifen dann auf das clients-Verzeichnis zu. Es sind nur die Unterverzeichnisse ltspX/conf sowie die Dateien ltspX/clients und ltspX/notclients weggefallen.

[Rüdiger Kupper]

Ah, verstehe. Das neue Verzeichnis /etc/linuxmuster/ltsp_config/clients ist trotzdem automatisch generiert und sollte nicht ins svn eingecheckt werden, richtig?

[bau]

Ja