NFS-Server Addon

[olistudent]

Hi.
Ein Patch für die uClibc ist natürlich schonmal etwas unschön, da sowas mit einigem Kompilieraufwand verbunden ist.
Aber ich werde mir die Sache nochmal anschauen. Ich hatte meine Experimente damals beendet, weil ich einfach nicht weitergekommen bin. In der Zwischenzeit sind die Debughelper (strace usw.) im dsmod aber etwas besser zu gebrauchen, daher besteht noch Hoffnung.

Da du dich ja anscheinend etwas mit dem knfsd auskennst könntest du mir vielleicht noch beschreiben was genau in welche Datei muss und welche Dateien ich in welcher Reihenfolge starten muss?

MfG Oliver

 

[capt_bluebaer]

Hallo,
ich glaube der Patch der uclibc (add support for getrpcbynumber_r/getrpcbyname_r/getrpcent_r and a config option to enable REENTRANT RPC) ist auch nicht zwingend erforderlich, siehe hier.
Um die betreffenden Zeilen des Patches 2 meiner Sammlung durch die bedingte Kompilierung nicht doch mitzubauen, habe ich sie auf meiner SuSE mal ganz 'rausgelöscht, der NFSD startet trotzdem und lässt sich von einem entfernten Rechner mounten.
Deshalb glaube ich, den uclibc-Patch sollten wir ersteinmal vergessen, war nur ein Versuch meinerseits.
Also angewendet habe ich auf die NFS-Utils die Patche 1 und 2 aus meiner Patch-Sammlung, den Kompiliervorgang habe ich beschrieben.
Zum Starten habe ich das rc-Script aus dem Addon des ersten Posting leicht modifiziert. Reihenfolge:
1. nfsd-Kernel-Modul laden (lockd und sunrpc werden automatisch nachgeladen)
2. Verzeichnis /var/lib/nfs anlegen und darin Datei rmtab erzeugen.
3. Daemons portmap, statd (auf den kann verzichtet werden), lockd starten.
4. exportfs -r aufrufen
5. Daemons nfsd und mountd starten
Gestern habe ich leider die wrapper-libs vergessen mitzuposten, ohne die wird sich der portmap wohl beschweren. Ich reiche sie hier nochmal nach.

 

[kriegaex]

Danke für die Beschreibung des Anwendungsfalls, damit entsteht eine ganz andere Motivation, das auch zu machen (auch wenn Oliver das tut und nicht ich).

 

[RalfFriedl]

- Warum läßt Du libwrap nicht ganz weg, zumindest für den Anfang?
- Startet bei Dir der lockd? Bei mir versucht er ein nfsservctl(0x10000, 0x7f8eace0, 0), und laut man-page kann man nicht erwarten, daß das geht.
- Bei mir wird vor nfsd noch exportfs geladen.
- Beim Start von nfsd bekomme ich EADDRINUSE.

 

[capt_bluebaer]

@RalfFriedl:
1) Die libwrap.so wird vom portmap benötigt, mir ist nicht bekannt, daß er ohne sie auskommt. Wie ich schon schrieb, ich bin nicht der große Profi, aber ich laß mich gerne eines besseren belehren. Falls Du aber die configure-options meinst, die habe ich in den nfs-utils 1.0.10 disabled (--without-tcp-wrappers). Bei früheren Versionen gab es die meines Wissens sowieso nicht.
2) Ich gehe davon aus, daß Du den Daemon meinst: nein, der startet auch nicht, das gleichnamige Kernel-Modul ist aber geladen.
3) Start-Reihenfolge habe oben beschrieben, ist bei mir auch: exportfs -r; nfsd. Im rc.init-Script meiner SuSi ist es genauso.
4) Irgendwann habe ich soetwas auch mal im syslog gesehen, ich kann mich aber bei meinen vielen Versuchen nicht mehr erinnern, unter welchen Bedingugen. Wo und wie (mit welchen Tools) hast Du es gesehen? Mit denen von olistudent (strace, usw)? Hab ich in meinem ds-mod nicht integriert, müsste ich event. nachholen.
Welche "address in use" könnte der nfsd gemeint haben? Ein nc -l -p 2049 funktioniert fehlerfrei und ein Portscan bestätigt das.
, oh!, netstat -l sagt:

Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State
tcp        0      0 *:5060                  *:*                     LISTEN
tcp        0      0 *:49000                 *:*                     LISTEN
tcp        0      0 *:8080                  *:*                     LISTEN
tcp        0      0 *:80                    *:*                     LISTEN
tcp        0      0 *:81                    *:*                     LISTEN
tcp        0      0 *:82                    *:*                     LISTEN
tcp        0      0 localhost:1011          *:*                     LISTEN
tcp        0      0 *:1012                  *:*                     LISTEN
tcp        0      0 *:21                    *:*                     LISTEN
tcp        0      0 *:53                    *:*                     LISTEN
tcp        0      0 *:8118                  *:*                     LISTEN
tcp        0      0 *:22                    *:*                     LISTEN
tcp        0      0 *:443                   *:*                     LISTEN
udp        0      0 *:2048                  *:*
udp        0      0 *:2049                  *:*
udp        0      0 *:2050                  *:*
udp        0      0 *:2051                  *:*
udp        0      0 *:2052                  *:*
udp        0      0 *:7077                  *:*
udp        0      0 *:53                    *:*
udp        0      0 *:67                    *:*
udp        0      0 *:5060                  *:*
udp        0      0 *:69                    *:*
udp        0      0 *:1900                  *:*
raw        0      0 *:2                     *:*                     0
raw        0      0 *:2                     *:*                     0
raw        0      0 *:2                     *:*                     0
Active UNIX domain sockets (only servers)
Proto RefCnt Flags       Type       State         I-Node Path

Da ist doch irgendwas auf dem (UDP-)Port 2049 aktiv, obwohl ich keinerlei NFS-Daemons/Kernel-Module geladen habe, muß von AVM sein und sollte nicht sein.
nmap von aussen sagt:

Starting Nmap 4.11 ( http://www.insecure.org/nmap/ ) at 2007-08-28 16:51 CEST
Interesting ports on fritz.box (192.xxx.xxx.xxx):
PORT     STATE         SERVICE
2048/udp open|filtered dls-monitor
2049/udp open|filtered nfs
2050/udp open|filtered unknown
MAC Address: 00:xx:xx:xx:xx:xx (Unknown)

Nmap finished: 1 IP address (1 host up) scanned in 179.890 seconds

und ein nc -l -u -p 2049 funktioniert auch nicht!
Aber um die Euphorie zu dämpfen: ein z.B. nfsd -p 2063 oder nfsd -u oder eine Kombination aus beiden funktioniert auch nicht. Ist der nfsd an Port 2049 fest gebunden?

 

[RalfFriedl]

Ich meinte das Modul exportfs, das wird bei mir automatisch vor dem Modul nfsd geladen.

Port 2049 gehört zum ctlmgr. Wenn ich den stoppe, kann ich nfsd starten und auch ein Mount funktioniert. Ich mußte vorher den Client in der /etc/hosts eintragen, weil bei mir in der aktuellen Konstellation die Namensauflösung sonst nicht funktionierte. Um zu prüfen, ob dies notwendig ist, kann man mit nslookup nach der IP-Adresse des Clients suchen.
Bei einem Neustart des ctlmgr, nachdem nfsd läuft, versucht dieser erst gar nicht, Port 2049 zu bekommen. Anscheinend holt er sich einfach einen freien Port, und das ist nach dem Start gerade der Port 2049.

$ cat /proc/sys/net/ipv4/ip_local_port_range
2048    4999

Mit strace und ltrace kann man einiges erfahren darüber, was Programme tun, oder auch wo genau sie etwas nicht tun. Auch lsof kann nützliche Informationen liefern. Da man diese im ds-mod einfach anwählen kann, würde ich das sehr empfehlen. Eine Beschreibung gibt es auf den entsprechenden Internetseiten oder in den Linux man-pages.

Im Makefile zu portmap sind Kommentare zur libwrap:

# To disable tcp-wrapper style access control, comment out the following
# macro definitions.  Access control can also be turned off by providing
# no access control tables. The local system, since it runs the portmap
# daemon, is always treated as an authorized host.

[B]#[/B]HOSTS_ACCESS= -DHOSTS_ACCESS
[B]#[/B]WRAP_LIB = $(WRAP_DIR)/libwrap.a

und etwas weiter unten

portmap: $(OBJECTS) [B]# hier libwrap entfernen[/B]
        $(CC) $(CFLAGS) -o $@ $(OBJECTS) $(WRAP_LIB) $(LIBS)

 

[capt_bluebaer]

Das Modul exportfs hatte ich vergessen, es wird natürlich geladen.

Zu meiner Schande muß ich gestehen, daß dich den portmap und die libwrap als binary von OpenWRT habe, ich bekam sie irgendwie nicht gebacken. Nach Deiner Anleitung habe ich mir den portmap selbst erstellt, es ist allerdings eine V6, da sieht das Makefile geringfügig anders aus. Musste allderdings noch eine Abhängigkeit auskommentieren bezüglich tcp.h.

Vielen Dank für den Tipp mit den Tools. Die beiden Trace-Programme kannte ich noch nicht und getreu dem Motto von kriegaex bei der Paketauswahl für den ds-mod "Was man nicht kennt, braucht man nicht" hatte ich die auch nicht angewählt. lsof allerdings war mir ein Begriff, und so habe ich mir den mal eben so "on the fly" geholt. Und da kommt schon die nächste Überraschung: lsof -i -P | awk ' {if(NR!=1) {print $1" "$7" "$8}} ' | sort | uniq | grep *:

ctlmgr UDP *:2055
dnsmasq TCP *:53
dnsmasq UDP *:2049
dnsmasq UDP *:53
dnsmasq UDP *:67
dnsmasq UDP *:69
dropbear TCP *:22
ftpd TCP *:21
httpd TCP *:81
httpd TCP *:82
igdd TCP *:49000
igdd UDP *:1900
multid UDP *:2050
multid UDP *:2051
privoxy TCP *:8118
stunnel TCP *:443
syslogd UDP *:2052
telefon TCP *:1012
voipd TCP *:5060
voipd UDP *:5060
voipd UDP *:7077
websrv TCP *:80
websrv TCP *:8080

und sie da, der "Übeltäter" ist bei mir nicht der ctlmgr, sondern dnsmasq. Nach dessen Restart belegte er dann andere Ports und so war der Weg frei für meinen NFSD. Leider starten nach wie vor kein lockd und kein nsfd. Wie sieht es denn bei Dir mit dem lockd-(Daemon) aus?

 

[RalfFriedl]

Ich habe aus opensuse 10.2 portmap-5beta und nfs-utils-1.0.10 genommen.

Wie bereits gesagt ist lockd aus den nfs-utils in der Form nicht verwendbar, zum Glück auch nicht notwendig. Lockd macht einen Systemaufruf nfsservctl(0x10000, 0x7f8eace0, 0), aber laut man-page und Kernel-Sourcen sollte der erste Wert zwischen 0 und 6 liegen, da ist 0x10000 deutlich drüber.

Ich verwende keinen dnsmasq, daher kann er bei mir den Port nicht verwenden. Da die Ports ab 2048 verwendet werden, ist es naheliegend, daß irgend ein Programm beim Start den Port 2049 bekommt und dieser dann nicht mehr frei ist.

NFS kann man so starten:

modprobe nfsd
portmap
mkdir -p /var/lib/nfs
mount -t nfsd nfsd /proc/fs/nfsd
exportfs -r
echo 3 > /proc/fs/nfsd/threads
# Alternativ:
# nfsd 3
mountd

Wenn /proc/fs/nfsd/threads existiert, schreibt das Programm nfsd nur die Anzahl der gewünschten Prozesse auf /proc/fs/nfsd/threads und die Kernel-nfsd Prozesse und den Kernel-lockd zu starten. Sonst werden die gleichen Prozesse mit nfsservctl(0, ...) gestartet, das Ergebnis scheint das Gleiche zu sein.

Ich habe mal in die /etc/init.d/rc.S diese Zeile eingefügt, damit sind die unteren Ports frei.

echo 40000 49999 > /proc/sys/net/ipv4/ip_local_port_range

 

[capt_bluebaer]

Danke, das mit dem Freihalten der Ports wäre damit gelöst, da hätte ich mir sonst wieder die Zähne ausgebissen.

Aber bei mir beendet der nfsd mit einem Segmentation Fault wenn ich ihn nach dem Mounten des virtuellem Filesystems mount -t nfsd nfsd /proc/fs/nfsd aufrufe. Und das ganz ohne portmap.

Habe deshalb 'mal ein paar allgemeine Fragen:
1. Benutzt Du die in der ds-mod-Konfiguration die Option "Replace Kernel"?
2. Welche Patche hast Du auf die NFS-Utils-1.0.10 angewandt? Etwa auch welche von OpenSuSE?
3. Ist Deine uclibc gepatcht, wie ich es vorher 'mal beschrieben habe?

Irgendwas hakt bei mir noch, ich hoffe da kommen wir noch hinter.

Edit:
strace nfsd:

open("/proc/fs/nfsd/versions", O_WRONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
open("/proc/fs/nfsd/portlist", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
open("/proc/fs/nfsd/threads", O_WRONLY|O_LARGEFILE) = 4
write(4, "1\n", 2 <unfinished ...>
+++ killed by SIGSEGV +++
Process 3332 detached

ls /proc/fs/nfsd:

exports     filehandle  threads

Keine Datei versions, 'echo "+2 +3 -4" > /proc/fs/nfsd/versions' bringt
-sh: cannot create /proc/fs/nfsd/versions: Permission denied

 

[olistudent]

So, nachdem ich mal wieder 5h mit dem NFS-Server verbracht habe gibts im ersten Post das neue knfsd-Addon. Ich hab den Port des nfsd umgelegt, so dass es damit keine Schwierigkeiten geben sollte.

MfG Oliver

 

[RalfFriedl]

1. Ich verwende "Replace Kernel".
2. An den nfs-utils habe ich nur das nötigste geändert, getrpcbynumber_r. Keine Patches von Suse.
3. uclibc ist ohne Patch, aber mit LFS und IPV6. Das allerdings nicht wegen NFS und hat vermutlich auch nichts damit zu tun.

Portmap solltest Du schon aufrufen, bevor Du versuchst NFS zu starten. Der NFS-Server muß sich ja beim Portmap anmelden.

--- nfs-utils-1.0.10/support/nfs/svc_socket.c
+++ nfs-utils-1.0.10/support/nfs/svc_socket.c
@@ -35,6 +35,18 @@
 # define __close(f)            close ((f))
 #endif

+int
+getrpcbynumber_r (int __number, struct rpcent *__result_buf, char *__buffer, size_t __buflen, struct rpcent **__result)
+{
+  struct rpcent *rpcp = getrpcbynumber (__number);
+  if (rpcp) {
+    *__result = rpcp;
+    return 0;
+  }
+  __result = NULL;
+  return -1;
+}
+
 static int
 svc_socket (u_long number, int type, int protocol, int reuse)
 {

 

[olistudent]

Ich hab diesen Patch von openwrt genommen. Ist da ein Unterschied zu deinem?

--- nfs-utils-1.1.0/support/nfs/svc_socket.c~    2007-05-10 20:40:57.000000000 -0700
+++ nfs-utils-1.1.0/support/nfs/svc_socket.c    2007-06-07 15:37:39.000000000 -0700
@@ -67,8 +67,10 @@
   memset (&addr, 0, sizeof (addr));
   addr.sin_family = AF_INET;
 
-  ret = getrpcbynumber_r (number, &rpcbuf, rpcdata, sizeof rpcdata,
-              &rpcp);
+//  ret = getrpcbynumber_r (number, &rpcbuf, rpcdata, sizeof rpcdata,
+//              &rpcp);
+  rpcp = getrpcbynumber (number);
+  ret = 0;
   if (ret == 0 && rpcp != NULL)
     {
       /* First try name.  */

MfG Oliver

 

[RalfFriedl]

Das Ergebnis sollte das gleiche sein, ich habe nur nicht bei openwrt gesucht.

Hast Du noch Probleme damit?

Ich würde die default-Ports in /proc/sys/net/ipv4/ip_local_port_range ändern, so daß Port 2049 frei bleibt und nicht geändert werden muß.

 

[olistudent]

Wie soll ich das denn in meinem Addon machen? Dazu muss ja die /etc/init.d/rc.S gepatcht werden...

MfG Oliver

 

[kriegaex]

Ich würde die default-Ports in /proc/sys/net/ipv4/ip_local_port_range ändern, so daß Port 2049 frei bleibt und nicht geändert werden muß.

Wozu, wenn der Portmapper seinen Dienst tut?

 

[RalfFriedl]

Ok, als addon geht es so nicht.

 

[kriegaex]

Davon abgesehen, wäre, wenn das stabil läuft, eine Integration als Mod-Paket (inkl. CGI-Seite für Exports ähnlich Samba) sowieso eine gute Idee.

 

[capt_bluebaer]

So, ich habe jetzt auch neue Erkenntnisse, es geht! Mein Fragen an RalfFriedl waren nicht ganz unberechtigt. Ich arbeitete zuletzt immer mit dem AVM-Kernel, ich habe ihn in meinem neuen Image ersetzt (hatte ich sowieso vor, wegen dem iptables-Problem) ohne die übrige Konfiguration zu ändern. Damit kann ich den NFSD starten - kein Segmentation-Fault mehr.
Mein Portmapper läuft übrigens immer noch mit der libwrap, macht keine Probleme.

@kriegaex: Bitte daran denken, sollte der NFSD noch in dieser FW-Version in den dsmod aufgenommen werden, "Replace Kernel" automatisch selektieren lassen.

AVM muß man aber kritisieren, was deren Kernel alles verbockt (sind ja schon etliche bekannt, wie iptables, fat/vat). Im Falle des NFS-Server muß man sich um so mehr wundern, da sie dafür im Modul sunrpc selbst etwas geändert haben. Dann noch das Gießkannenprinzip, mit den der für NFS so wichtige Port 2049 an andere Anwendungen vergeben wird (OK, das ist kein Kernel-Problem).

Andererseits möchte ich mich aber an alle hier Beteilligten recht herzlich bedanken, ohne Eure Hilfe hätte ich es nicht hinbekommen. Da kann man nur sagen: Hut ab und weiter so.

 

[kriegaex]

Wir wissen gar nicht, ob AVM etwas "verbockt" hat, vom GPL-Lizenzverstoß fürs Nicht-Bereitstellen der Quellen mal abgesehen. Die FAT-Module von AVM gehen ja mit dem AVM-Kernel, also kann man annehmen, daß wir irgendetwas bauen, was aus irgendeinem Grund nicht zum Kernel von AVM paßt. Ob es an von AMV eingebrachten Fehlern oder an mangelnden Informationen unsererseits liegt, können wir nicht mit Sicherheit sagen. Also Vorsicht mit Pauschalurteilen!

Was ein mögliches NFS-Server-Paket in ds26 betrifft, wird es wohl eher so laufen, daß dieses von "Replace Kernel" abhängen wird, nicht umgekeht. D.h. man sieht es nicht, wenn "Replace Kernel" inaktiv ist.

 

[capt_bluebaer]

Original von kriegaex
Wir wissen gar nicht, ob AVM etwas "verbockt" hat, vom GPL-Lizenzverstoß fürs Nicht-Bereitstellen der Quellen mal abgesehen.

Da habe ich mich vielleicht auch ein wenig falsch ausgedrückt. Natürlich hat AVM das Recht, an ihrem Kernel Änderungen nach ihren Bedürfnissen vorzunehmen, aber würden diese offen liegen wie es die GPL vorsieht, würde man schnell Abweichungen von Linus' Kernel erkennen. Gegen diese Geheimhaltung richtete sich meine Kritik.
Aber was soll's, wollen hier nicht Off Topic kommen.
Der NFS-Server läuft nun und darüber sollten wir uns freuen.