Bewertung: 5 / 5

Stern aktivStern aktivStern aktivStern aktivStern aktiv
 

 

Das Problem ist dass bereits ein DHCP Server im lokalen Netz, eine FB 7390, bei mir existiert und es nicht erlaubt bootp Definitionen fuer PXE zu konfigurieren. Deshalb habe ich auf einer Raspberry einen DNSMASQ DHCP Server als DHCP-Proxy sowie einen tftp Server und nfs Server konfiguriert. D.h. diese Raspberry übernimmt den gesamten PXE Prozess während die FB weiterhin nur die IP Adresse sowie default Gateway IP und DNS Server IP liefert.


 

 

 

Einsatz einer Raspberry als DHCP-Proxy Server und tftp Server

Ab der Raspberry 3 kann die Raspberry auch ohne SD Karte starten und laufen. Ihr Bootcode sucht sie im lokalen Netz von einem PXE Server und lädt dann davon das Rootfilesystem. Das ist sehr praktisch wenn man z.B. eine größere Menge von Raspberries alle mit demselben Image starten lassen will wie z.B. Raspberry Schulungen. Weiterhin kann man aber auch jeder Raspberry im lokalen Netz unterschiedliche Images geben. Der Vorteil ist dass es keine SD Karte mehr gibt die sich abnutzt und man zentral Backups der Images erstellen kann. Nachteil ist dass saemtliche Aenderungen der Daten der Rootpartition ueber das Netz gehen muessen und dadurch die Performance etwas leidet.

Den DHCP Server sowie den tftp Server den man dazu benötigt kann man auch gut auf eine Raspberry legen. Ich habe so einen Testsetup bei mir lokal mal interessehalber aufgesetzt und primaer dazu diese Anleitung von Raspberry Pi Geek benutzt.

In der Anleitung wird als Unterordner in /nfs und /tftp die IP Adresse genommen. Ich habe dazu aber die CPU ID genommen, die man mit grep -i Serial /proc/cpuinfo erhält. Dann davon die letzten 8 Stellen nehmen. Alternativ kann man natuerlich auch die IP Adressen nehmen. Nur muss man dann darauf achten dass die Clients von der FB immer dieselbe IP Adresse bekommen. Wenn man eine groessere Anzahl von PXE Clients in einem kleinen Netz hat (/24 = 254 IPs) ist das aber ungeschickt da dann alle IPs immer reserviert sind und von anderen Clients nicht mehr benutzt werden koennen.

Wichtig ist die Option tftp-unique-root in /etc/dnsmasq.conf. Dadurch werden beim PXE Boot in /tftpboot/<serialid> die Bootinformationen incl /etc/cmdline.txt genutzt wo konfiguriert ist wo der PXE Client sein Rootverzeichnis bezieht. Aus nicht verstaendlichen Gruenden muss auch ein Teil des Bootverzeichnisses auch in /tftpboot stehen.

Das /tftpboot Verzeichnis sieht dann wie folgt aus (87f728f5 ist die CPU ID meiner Raspberry)

├── 87f728f5
├── bootcode.bin

 

Per nfs ist das root Verzeichnis der Raspberry exposed. Letztendlich kann das jedes Verzeichnis sein denn dessen Pfad wird in der /tftpboot/87f728f5/etc/cmdline.txt definiert. Aus Konsistenzgründen sollte es aber /nfs/87f728f5 sein.

Etwas problematisch ist es mit der Bootpartition die ja in einem tftp Verzeichnis auf der Raspi liegt. Damit ein Update der Bootpartition der PXE Client Raspberries auf dem tftp Server stattfindet sollte man als Bootverzeichnis in der /etc/fstab der PXE Clients das tftp Bootverzeichnis definieren und das tftp Verzeichnis per nfs exportieren. Damit erfolgt dann ein Update des tftp Bootverzeichnisses transparent beim Update den Clients.

Inhalte der /etc/fstab eines PXE Clients mit der serverid 87f728f5 in /volume1/pxe_nfs/87f728f5/etc/fstab:

proc            /proc           proc    defaults          0       0
<tftpserverIP>:/tftpboot/87f728f5  /boot   nfs defaults,vers=3 0 0

Inhalt der /etc/cmdline.txt eines PXE Clients mit der serverid 87f728f5 auf dem tftp Server in /tftpboot/87f728f5

dwc_otg.lpm_enable=0 console=serial0,115200 console=tty1 root=/dev/nfs nfsroot=<synologyIP>:/volume1/pxe_nfs/87f728f5,vers=3 rw ip=dhcp elevator=deadline fsck.repair=yes rootwait

 

Einsatz einer Synology als DHCP und tftp Server

Auf einer Synology kann man mit DSM Standardmitteln keinen dhcp-proxy konfigurieren. D.h. man muss dann einen DHCP Server auf der Syno konfigurieren und den DHCP Server auf der FB deaktivieren. Aber man kann dem tftp Server den Servicenamen Raspberry Pi Bootkonfigurieren der von der Raspberry verlangt wird. Man muss dazu im DHCP Server der Syno eine Vendordefinition wie folgt vornehmen:

 

SynoRaspiDHCP

 

Ansonsten konfiguriert man alles genauso wie im ersten Fall mit der Raspberry konfiguriert. Nur eben dass nicht nur die Rootpartitionen per nfs von der Syno exportiert werden sondern auch die tftp Verzeichnisse.

 

tree -L 2 /volume1
├── pxe_nfs
│   ├── 7f308a52
│   ├── 87f728f5
│   └── @eaDir
├── pxe_tftp
│   ├── 7f308a52
│   ├── 87f728f5
│   ├── bootcode.bin

 


 

Synology DHCP Server als DHCP Proxy konfigurieren und Synology tftp Server benutzen

Man kann auch den Syno DHCP Server als DHCP Proxy konfigurieren. Dann hat der Syno DHCP Server nur die PXE Funktion aber die eigentliche DHCP Funktion bleibt weiterhin dem lokalen DHCP Server wie z.B. einer Fritzbox überlassen. Dazu muss man in /etc/dhcpd/dhcpd.conf folgendes  eintragen:

cat /etc/dhcpd/dhcpd.conf
interface=eth0
dhcp-range=set:eth00,192.168.0.0,proxy
dhcp-option=vendor:PXEClient,43,Raspberry Pi Boot
dhcp-leasefile=/etc/dhcpd/dhcpd.conf.leases
dhcp-script=/usr/share/dhcpd/dhcpd-script.sh

Danach ist ein Restart des DHCP Servers notwendig.

Folgendes Script hilft dabei:

#!/bin/bash
cp /etc/dhcpd/dhcpd.proxy.conf /etc/dhcpd/dhcpd.conf
OLD_PID="$(ps -e ww | grep dnsmasq | grep -v grep | head -n 1 | awk ' { print $1 }' )"
COMMAND="$(ps --no-header -p $OLD_PID -o args)"
kill $OLD_PID
$COMMAND &

Dummerweise wird die DHCP Konfiguration immer bei jeglichen DHCP Änderungen per DSM sowie bei einem Syno Restart wieder überschrieben. Ein Workaround ist auf der Syno ein triggered Task beim Booten ausfuehren lassen der das Script ausführt.

Einsatz einer Synology bei älteren Raspberries die kein PXE Boot können

In diesem Falle benötigt man immer noch eine SD Karte. Sie wird aber fast nur gelesen und nutzt sich deshalb so gut wie nicht ab. Sie wird nur benötigt damit die Raspberry booten kann und sich dann das /boot wie auch das Root Verzeichnis per nfs von der Synology mounted. Die /boot/cmdline.txt der SD Karte sieht exakt genauso aus wie die beim PXE Boot: Es muss die Rootpartition per nfs eingebunden werden. Die /etc/fstab von der Synology muss ebenso genauso aussehen wie die beim PXE Boot: /boot wird von der Synology als /volume1/pxe_tftp/<systemid> eingebunden. An eine Sache muss man aber denken: Wenn es mal ein Update der /boot Partition gibt wird dieser Update auf der Synology gemacht damit dort das ganze Image gesichert werden kann. Man muss aber immer danach alles aus dem /boot Ordner noch einmal lokal auf die SD Karte kopieren da sonst beim Booten der Raspberry nicht der aktuelle /boot Code angezogen wird.

 

Hinweis

Irgendwann stellte ich zu meiner Verwunderung fest dass PXE Boot meiner Raspberries nicht mehr funktioniert. Sie luden den Bootcode per tftp abder bekamen keine Rootpartition per nfs. Letztendlich stellte sich heraus dass es daran lag dass ich in der Zwischenzeit NFS 4 Support auf der Syno enabled hatte und nfs3 in den Config Dateien wie /etc/fstab stand. Nachdem ich den Support für NFS4 wieder deaktiviert hatte funktionierte wieder alles wie gewohnt.

 

 

Nützlich Befehle zum Debuggen

Auf einem System die DHCP-DISCOVER Antworten lesen und auf den PXE System ein DHCP-DICSCOVER Request losschicken.

sudo tcpdump -vvveni eth0 portrange 67-68

sudo nmap --script broadcast-dhcp-discover 255.255.255.255 -p67

 

Referenzen

https://www.raspberrypi.org/documentation/hardware/raspberrypi/bootmodes/net_tutorial.md

https://stackoverflow.com/questions/40008276/dnsmasq-different-tftp-root-for-each-macaddress

Kommentar schreiben

*** Hinweis ***

Kommentare sind erwünscht. Aber um lästige Spamposts abweisen zu können gibt es ein paar Dinge die zu beachten sind:
  1. Kommentare mit dem Text http werden sofort zurückgewiesen mit der Meldung Sie sind nicht berechtigt den Tag zu verwenden. zz
  2. Kommentare werden manuell überprüft und es dauert deshalb in der Regel einen Tag bis sie veröffentlicht werden.