FreeBSD Diskless

AceX5

Well-Known Member
Bei meinem FreeBSD Diskless Projekt ergeben sich nun langsam Fragen und Probleme bei denen ich nicht weiter weiss. Hoffe das mir hier etwas auf die Sprünge geholfen werden kann. Sage schon mal danke!

Situation:
- FreeBSD 5.2.1-p4 (Server und Clients)
- Dienste: TFTP, DHCP, NFS soweit eingerichtet
- unter /netboot liegt die pxeboot File mit LOADER_TFTP_SUPPORT=YES gebaut
- unter /usr/diskless liegt ein aus den Quellen gebautes FreeBSD System (make world usw.)
- Kernel für Client mit GENERIC.hints, BOOTP, BOOTP_NFSROOT, BOOTP_COMPAT in /usr/diskless gebaut + installiert
- NFS-root kann von diesem Client gemountet werden (ro | getestet)

Problem:
Den Client, den ich in der dhcpd.conf eingestellt habe, kann die pxeboot Datei vom TFTP beziehen, kann jedoch nicht den Kernel finden/booten. "can't find 'kernel'"

Fragen:
Was muss ich wohin kopieren, damit er den Kernel finden kann? (/usr/diskless/boot/kernel oder usr/diskless/boot/kernel/kernel nach /netboot)
Woher weiss pxeboot welcher Kernel / welche Datei gelanden werden soll und woher?
Habe ich etwas bei meinen bisherigen Einstellungen vergessen, was diesen Fehler auslösen kann?

# Auszug rc.conf #########

# INETD
inetd_enable="YES"

# ISC DHCP
dhcpd_enable="YES"
dhcpd_flags="-q"
dhcpd_conf="/usr/local/etc/dhcpd.conf"
dhcpd_ifaces="xl0"

# NFS Server
rpcbind_enable="YES"
nfs_server_enable="YES"

# Auszug dhcpd.conf #########

subnet 172.30.1.0 netmask 255.255.255.0 {
# Name der Hostdeklaration = Hostname des Clients
use-host-decl-names on;

option subnet-mask 255.255.255.0;
option broadcast-address 172.30.1.255;

host client1 {
hardware ethernet 00:07:e9:9b:5f:6d;
fixed-address 172.30.1.52;
filename "pxeboot";
option root-path "172.30.1.215:/usr/diskless";
}
}

# Auszug exports.conf #########

/usr -ro -maproot=0 -network 172.30.1.0 -mask 255.255.255.0
/usr/diskless -ro -maproot=0 client1
 

MuffiXXL

Well-Known Member

AceX5

Well-Known Member
Danke für deine Antwort. War heute zwar noch nicht auf allen Links, die du gepostet hast, aber dafür auf genug eher weniger aufschlussreicheren japanischen Seiten. :D
Mittlerweile habe ich eine Lösung gefunden. Musste das Root-FS mit der pxeboot Datei (TFTP Verzeichnis) in mein NFS Root packen und somit ist ein komplettes booten über das Netzwerk möglich. PXEBOOT benötigt das /boot Verzeichnis mit den Scripten + Kernel + Module.
Wenn du noch ein paar gute Links brauchst - habe mittlerweile eine erstaunliche Sammlung. :)
 

Maledictus

FreeBSD ftw
*ausgrab*

Wie macht ihr das denn mit dem runterfahren vom diskless client?
Meiner startet beim booten automatisch `X -query 192.168.0.2`, worauf ich dann meinen normalen KDM vor mir habe. Also den welchen ich auch auf 192.168.0.2 sehe.

In dem KDM kann ich natürlich nur den Server, möchte aber gerne den Client runterfahren.
Bisher wechsle ich auf Textconsole, logge mich als root ein und mache das übliche `shutdown -p now`.
Das ist mir aber zu aufwendig.

Jemand Ideen?

Gruss
Male
 
P

p.h.

Guest
Vorweg: Du kannst im KDM das Herunterfahren von einer Remote-Verbindung aus deaktivieren, was ich dir anraten würde, da sonst jeder remote den Server runterfahren darf. Das muß ja nicht mal Absicht sein, sondern könnte auch versehentlich passieren und ist eigentlich selten gewünscht.

Die Frage ist, warum du den Diskless Client herunterfahren möchtest. Normalerweise kannst du das Ding einfach ausschalten.

Du kannst aber auch in der Tastaturtabelle von syscons "boot" durch "pdwn" ersetzen, dann fährt die Kiste durch Strg+Alt+Entf herunter.

Oder du kannst X durch ein rc-Skript starten (mache ich selbst so) und nach dem X-Aufruf den shutdown-Aufruf setzen (ich habe da statt dessen ein Menü, mit dem man den X-Server neustarten, eine lokale Konsole anfordern oder den Client neubooten kann). Wenn du dann X mit Strg+Alt+Backspace beendest, fährt der Client runter.

Aber wie gesagt, normalerweise ist es ziemlich unnötig, einen Diskless Client herunterzufahren.
 

Maledictus

FreeBSD ftw
Vielen Dank für deine Antwort!

Das remote runterfahren kann nur root (default), und das reicht mir an sicherheit hier lokal :)

Einfach ausschalten? Irgendwie kann ich mir nicht vorstellen, dass die Daten dann vernünftig gesynced werden. z.B. die Log-Datei vom Xserver.

Das mit der Tastaturtabelle hört sich schon besser an. Wo finde ich die?

Ich hab mir auch ein kleines rc-Skript geschrieben, welches den Xserver beim booten startet. Würdest du dein skript mal hier posten? Würde mich sehr interessieren :)
 
P

p.h.

Guest
Maledictus schrieb:
Das remote runterfahren kann nur root (default), und das reicht mir an sicherheit hier lokal :)
Gut, das ist dann natürlich auch völlig ok :)
Maledictus schrieb:
Einfach ausschalten? Irgendwie kann ich mir nicht vorstellen, dass die Daten dann vernünftig gesynced werden. z.B. die Log-Datei vom Xserver.
In welcher Hinsicht soll es da was zu syncen geben? Außerdem liegt /var/log auf einem Diskless Client üblicherweise in einer Ramdisk, da bringt dir ein Sync sowieso nichts. Wenn du auf einen syslog-Host schreibst, brauchst du dich um das Syncen auch nicht zu kümmern. Und wenn ein NFS-Share ins Spiel kommt - naja, ich brauch dir ja sicher nicht zu erzählen, daß NFS sowieso stateless ist (für diesen Fall jedenfalls).
Maledictus schrieb:
Das mit der Tastaturtabelle hört sich schon besser an. Wo finde ich die?
Aus syscons(4):
Code:
FILES

     /usr/share/syscons/keymaps/*    key map files
Welche Datei zu editieren mußt, hängt von deiner verwendeten Keymap ab.

Maledictus schrieb:
Ich hab mir auch ein kleines rc-Skript geschrieben, welches den Xserver beim booten startet. Würdest du dein skript mal hier posten? Würde mich sehr interessieren :)
Skript ist angehängt, ist aber nichts dolles. Denn es ist wirklich Zeitverschwendung, einen Diskless Client herunterzufahren. Das Menü ist mehr ein "Goodie" und soll verwirrten Anwendern helfen, die sich den X-Server mit Strg+Alt+Backspace abgeschossen haben (ja, ich weiß, daß man diese Tastenkombination in der xorg.conf abschalten kann, aber sie könnte ja mal die "letzte Rettung" sein). Jedenfalls kann der Anwender dann einfach durch ENTER die Endlos-Schleife fortsetzen, die wieder einen neuen X-Server startet.

Naja, und das STRG+C führt auf die lokale Konsole und ist nur für administrative Zwecke gedacht, wird aber eigentlich nicht gebraucht. Genau so gut kann ich auf dem NFS-Server ein chroot(8) ist das Root des Diskless Clients machen.

Ebenso braucht man das Strg+Alt+Entf zum Neustarten eigentlich nie, aber wenn man's doch mal brauchen würde, ist der Hinweis auf den Affengriff ganz hilfreich.

Wie gesagt, die Diskless Clients werden von unwissenden Anwendern bedient und genau darauf ist das Startskript ausgelegt.
 

Anhänge

  • ThinClientStartup.zip
    2 KB · Aufrufe: 148

Maledictus

FreeBSD ftw
p.h. schrieb:
In welcher Hinsicht soll es da was zu syncen geben? Außerdem liegt /var/log auf einem Diskless Client üblicherweise in einer Ramdisk, da bringt dir ein Sync sowieso nichts. Wenn du auf einen syslog-Host schreibst, brauchst du dich um das Syncen auch nicht zu kümmern. Und wenn ein NFS-Share ins Spiel kommt - naja, ich brauch dir ja sicher nicht zu erzählen, daß NFS sowieso stateless ist (für diesen Fall jedenfalls).
Mein Client hat leider sehr wenig Ram, deswegen liegt auch alles auf dem NFS Server.
Es stimmt natürlich, dass NFS stateless ist, aber ich könnte mir schon vorstellen, dass der Kernel noch einige dirty pages im ram hat, die beim einfachen ausschalten natürlich nicht mehr zum NFS Server geschickt werden?

p.h. schrieb:
Aus syscons(4):
Code:
FILES

     /usr/share/syscons/keymaps/*    key map files
Welche Datei zu editieren mußt, hängt von deiner verwendeten Keymap ab.
Vielen Dank :)

p.h. schrieb:
Skript ist angehängt, ist aber nichts dolles. Denn es ist wirklich Zeitverschwendung, einen Diskless Client herunterzufahren.
[...]
Wie gesagt, die Diskless Clients werden von unwissenden Anwendern bedient und genau darauf ist das Startskript ausgelegt.

Auch dafür vielen Dank, ich finds interessant :)
 
P

p.h.

Guest
Maledictus schrieb:
Mein Client hat leider sehr wenig Ram, deswegen liegt auch alles auf dem NFS Server.
Es stimmt natürlich, dass NFS stateless ist, aber ich könnte mir schon vorstellen, dass der Kernel noch einige dirty pages im ram hat, die beim einfachen ausschalten natürlich nicht mehr zum NFS Server geschickt werden?
Verstehe ich das recht, daß /etc, /dev und /var bei dir auf einem rw-NFS-Share liegen und der Rest über ein ro-NFS-Share gezogen wird? IMO ist es dann immer noch egal. Diese drei Verzeichnisse würde man normalerweise in eine Ramdisk legen, die bei jedem Booten auf einen definierten, fast leeren Stand gebracht wird. Was da drin steht, ist eigentlich ziemlich egal. Ein Syncen dieser Daten hielte ich nicht für nötig.

Insgesamt würde ich aber empfehlen, daß du Ramdisks einrichtest. Denn bei deiner jetzigen Variante brauchst du für jeden Diskless Client jeweils ein eigenes /etc, /dev und /var auf dem NFS-Server, weil diese Verzeichnisse sind als nicht shareable gekennzeichnet sind. Das wäre mir zuviel Verwaltungskram. So viel RAM brauchst du für die Ramdisks gar nicht mal. Ich habe standardmäßig:
  • 2 MB für /etc
  • 2 MB für /dev
  • 4 MB für /var
Wie viel RAM hat dein Diskless Client denn insgesamt? Meistens sollten 8 MB irgendwie noch rauszuholen sein. IMO wäre es im Falle der Fälle sogar zweckmäßig, den RAM entsprechend aufzurüsten, 8 MB sollte man nun wirklich irgendwie nachrüsten können. Das wäre mir auf jeden Fall lieber als das rw-NFS-Gefrickel, ganz ehrlich.

Aber selbst mit rw-NFS würde ich keinen Shutdown machen. Du könntest ja sogar beim Booten /etc, /dev und /var komplett löschen und das Grundgerüst aus der mdist herstellen lassen, das wäre gar kein Problem, also ist es eigentlich auch ziemlich egal, ob der Kernel da irgendwas synct oder sonstwas an den Daten macht.
 
Oben