Bewertung: 5 / 5

Stern aktivStern aktivStern aktivStern aktivStern aktiv
 

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 Änderungen 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. Alternativ kann man auch eine Synology als DHCP- und tftp Server benutzen. Dann hat man eine zentrale Stelle wo man die Raspberry Images mit der Synology sichern kann.

Man kann auch mit älteren Raspberries, die kein PXE Boot können, eine per nfs gemountete Root Partition benutzen. Nur beim Boot wird die SD Karte dabei lesend genutzt und nutz sich somit fast nicht ab.

 

 

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.

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

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.

grep -i Serial /proc/cpuinfo

erhaelt. 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

 

Syno DHCP Server als DHCP Proxy konfigurieren und Syno 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.

 

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

Ein jeder Kommentar wird wegen Spamposts manuell überprüft und es dauert in der Regel bis zu einem Tag bis der Kommentar veröffentlicht wird.
Um Spamkommentare von Spambots zu minimieren kann ein weiterer Kommentar erst nach 15 Minuten erstellt werden. Weiterhin wird ein Kommentar mit dem Text http sofort zurückgewiesen.
Tut mir leid wegen der Unannehmlichkeiten.