www.fabiankeil.de/blog-surrogat/2005/11/19/freebsd-nfs-probleme.html

Kleinere Probleme bei der NFS-Einrichtung

Africanqueen, mein Schreibtisch-Rechner, läuft seit dem ATA-Kabelwechsel vor zwei Wochen fehlerfrei, unter FreeBSD gab es keine Ausfälle mehr. Zwei Jahre Martyrium konnten durch Investition von 2,90 € beendet werden. Weitere Tausch-Experimente mit Netzteil und Mainboard kann ich mir sparen.

Zum Ausgleich durfte ich mich heute mit Samba, dem File-Server im Keller, beschäftigen. Sambas Hauptaufgabe ist es, den Inhalt meines iRiver H340 zu spiegeln und über smbfs an interessierte Windows-nutzende Mitbewohner zu verteilen. Daher auch der Name. Nebenbei arbeitet Samba gelegentlich als IPsec-Gegenstelle und beherbergt eine brach liegende Privoxy-Installation.

Läuft und läuft und läuft

Samba arbeitet seit Monaten keine problemlos. Um mir die Sicherung vom Laptop aus zu erleichtern, entschied ich mich heute spontan dazu, den Rechner zusätzlich als NFS-Server zu konfigurieren.

Natürlich kann auch FreeBSD mit mount_smbfs auf smbfs zugreifen, im Vergleich zu den kranken Limitierungen von net use unter Windows ist es sogar das reinste Zuckerschlecken.

Sichern auf Dateisystem-Ebene fällt aber flach, ansonsten würden einige Datei-Eigenschaften flöten gehen, die in smbfs nicht implementiert sind.

tar kann ich benutzen, auf Dauer ist es mir jedoch zu umständlich, mit rsync wäre es einfacher.

nfsd ist nicht zu stoppen

Africanqueen läuft seit Jahren nebenbei als NFS-Server, die Einrichtung hat keine zwanzig Minuten gedauert. FreeBSD regelt, die Dokumentation rockt.

Bei Samba brauchte ich heute etwas länger, zum einen weil ich nach Gedächtnis arbeitete, zum anderen, weil nfsd sich seltsam – beziehungsweise anders als von mir erwartet – verhielt. Es gelang mit nicht, nfsd zu beenden:

root@samba /home/fk #ps aux|grep nfs[d]
root   387  0.0  0.3  1300   968  ??  Is    9:34PM   0:00.07 nfsd: master (nfsd)
root   389  0.0  0.2  1224   800  ??  I     9:34PM   0:00.00 nfsd: server (nfsd)
root   391  0.0  0.2  1224   800  ??  I     9:34PM   0:00.00 nfsd: server (nfsd)
root   392  0.0  0.2  1224   800  ??  I     9:34PM   0:00.00 nfsd: server (nfsd)
root   393  0.0  0.2  1224   800  ??  I     9:34PM   0:00.00 nfsd: server (nfsd)
root@samba /home/fk #killall nfsd
root@samba /home/fk #ps aux|grep nfs[d]
root   387  0.0  0.3  1300   968  ??  Is    9:34PM   0:00.07 nfsd: master (nfsd)
root   389  0.0  0.2  1224   800  ??  I     9:34PM   0:00.00 nfsd: server (nfsd)
root   391  0.0  0.2  1224   800  ??  I     9:34PM   0:00.00 nfsd: server (nfsd)
root   392  0.0  0.2  1224   800  ??  I     9:34PM   0:00.00 nfsd: server (nfsd)
root   393  0.0  0.2  1224   800  ??  I     9:34PM   0:00.00 nfsd: server (nfsd)

Ob das Verhalten normal ist, habe ich noch nicht erforscht, da killall keine Probleme meldete, habe ich es auch erstmal gar nicht wahrgenommen. Wie die nfsd-Manpage verrät, ist alles im grünen Bereich:

The nfsd utility has to be terminated with SIGUSR1 and cannot be killed with SIGTERM or SIGQUIT. The nfsd utility needs to ignore these signals in order to stay alive as long as possible during a shutdown, otherwise loopback mounts will not be able to unmount. If you have to kill nfsd just do a ``kill -USR1 <PID of master nfsd>''

Hätte ich die Dokumentation befolgt, hätte ich killall nicht bemühen müssen. So habe ich eine saubere Syntax-Verletzung in /etc/exports gebastelt. Auf dem Laptop meldete mount_nfs: PCPROG_NFS: RPC: Program not registered.

Im Nachhinein denke ich, Neuinitialisieren von mountd auf dem Server hätte auch gereicht. Doch da mountd sich zwar in /var/log/messages, nicht aber auf der Konsole beschwerte, stocherte ich erstmal im Nebel.

Verwirrt hat mich außerdem die Ausgabe von top:

last pid:   649;  load averages:  0.00,  0.00,  0.00    up 0+00:27:53  22:01:31
39 processes:  1 running, 38 sleeping
CPU states:  0.0% user,  0.0% nice,  0.8% system,  0.0% interrupt, 99.2% idle
Mem: 11M Active, 8492K Inact, 15M Wired, 10M Buf, 334M Free
Swap: 743M Total, 743M Free

  PID USERNAME PRI NICE   SIZE    RES STATE    TIME   WCPU    CPU COMMAND
  [...]
  502 root      96    0  3524K  1796K select   0:00  0.00%  0.00% nmbd
  [...]
  389 root       4    0  1224K   800K -        0:00  0.00%  0.00% nfsd
  393 root       4    0  1224K   800K -        0:00  0.00%  0.00% nfsd
  392 root       4    0  1224K   800K -        0:00  0.00%  0.00% nfsd
  391 root       4    0  1224K   800K -        0:00  0.00%  0.00% nfsd

Die Bedeutung des Status - fand ich in tops Manpage nicht, dort heißt es: STATE is the current state (one of "sleep", "WAIT", "run", "idl", "zomb", or "stop"). Die als - gemeldeten Prozesse sind laut ps idle und sollten meiner Meinung nach unter top als idl gemeldet werden. Werde ich mir morgen mal genauer anschauen.

Nachdem ich dann irgendwann auch auf die falsche /etc/exports-Syntax stieß, korrigierte ich sie in drei Anläufen, das Sichern konnte endlich über NFS erledigt werden.

ndis0 sinnt auf Rache

Über das Funknetzwerk schiebe ich hier nur etwa zwei Megabyte pro Sekunde. Ich hatte etwa sechs Gigabyte zu sichern, damit hätte ich den Luftweg eine Weile saturiert. Den Laptop schleppte ich daher in den Keller, die Daten wurden durchs Kabel gepresst.

Den ndis-Kram entlud ich dazu aus dem Kernel, anschließend konnte em0 die Netzadresse und damit den NFS- und IPsec-Zugang erben.

Die Sicherung ging mit rekordverdächtigen sechs Megabyte pro Sekunde über die Bühne, die RealTek 8139 10/100BaseTX im Server ist eben ein 1A-Flaschenhals. Wird Zeit, auch Samba eine Gigabit-Karte zu spendieren und bei der Gelegenheit den verbuggten D-Link 664T in die Tonne zu treten.

Nachdem die Daten endlich übertragen waren, durfte ich noch eine Weile damit kämpfen, ndis0 wieder zur Mitarbeit zu überreden. Für das vorhergehende Entladen rächte sich das Gerät mit:

warning: KLD '/boot/kernel/ndis.ko' is newer than the linker.hints file
warning: KLD '/boot/kernel/if_ndis.ko' is newer than the linker.hints file
ndis0: <Intel(R) PRO/Wireless 2200BG Network Connection> mem 0xc0214000-0xc0214fff irq 11 at device 2.0 on pci2
ndis0: NDIS API version: 5.0
ndis0: NDIS ERROR: c000138d (unknown error)
ndis0: init handler failed
device_attach: ndis0 attach returned 6

Die ersten zwei Zeilen bin ich gewohnt, mit aktuellen Quellen bringe ich unter FreeBSD 5.4 seit ein paar Tagen das Funknetzwerk nicht verschlüsselt zum Laufen. Nach oberflächiger Diagnose fehlt mir das frisch ausgelagerte Modul wlan_wep. Falls es einen interessiert, die Fehlermeldung ist: ifconfig: SIOCS80211: Invalid argument.

Der Wechsel auf FreeBSD 6.0 ist seit Monaten für den Laptop eingeplant, von daher habe ich mich nicht dahinter geklemmt und benutze eine ältere ndis-Version. Eventuell hängt das Problem damit zusammen, nach ein paar Lade- und Entlade-Vorgängen stand die Funknetzwerkkarte jedenfalls wieder zu meiner Verfügung – und ich vor dem nächsten Problem.

Klebrige Default-Route

em0 hatte ich nur mit ifconfig down kaltgestellt, die Netzwerkadresse aber nicht entzogen. Trotz route flush wurde die neue Default-Route stets wieder auf em0 gelegt, die kabellose Kommunikation schlug fehl.

Diese kleiner Nerverei hielt mich vergleichsweise kurz auf, mittlerweile läuft auch der ThinkPad wieder wie gewohnt.