Eisfair Update auf 1.2.0

Beitrag von **Frockert** » Sonntag 15. Januar 2006, 13:08

Hallo zusammen,

ich möchte die Nutzer vom Eisfair informieren, das beim Update auf 1.2.0 ein ACL-fähiger Kernel und ebenfalls dessen automatische Nutzung beim lokalen Mounten installiert wird.

Was auf den ersten Blick uninteressant erscheint, hat aber fatale Auswirkungen auf den von "uns" genutzen Nfs-Server.
Bis zur aktuellen Nfs-Server Version 1.1.1 ist dieser nicht fähig ACL als Freigabe-Option zu deaktivieren.
Das bedeutet, das alle Clienten, die nach dem gemachten Update auf den Nfs-Server zugreifen wollen, ein Berechtigungsproblem haben.

Bei mir sah das so aus:

root@amd64:/# mount /public
mount: 192.168.0.7:/public failed, reason given by server: Keine Berechtigung

Das Problem habe ich in der Newsgroup spline.eisfair geschildert und als "Blitzhilfe" diese erste Abhilfe geschildert bekommen (nur für diejeningen, die das Update ebenfalls gemacht haben):

Datei /etc/init.d/boot ändern (mit vi oder joe):
ALT:
...
91 if [ "$point" != "/boot" ]
92 then
93 /bin/mount -o remount,acl,user_xattr $point
94 fi
...
NEU:
...
91 if [ "$point" != "/boot" ]
92 then
93 # /bin/mount -o remount,acl,user_xattr $point
94 true
95 fi

Die Eisfair-Entwickler werden wohl in Kürze für eine Bereinigung sorgen.

Hier noch Informationen zu ACL:
http://de.wikipedia.org/wiki/Access_Control_List

Gruß
Frockert

Beitrag von **wolgade** » Sonntag 15. Januar 2006, 14:47

Nur mal so aus Neugierde: Kann Eisfair mittlerweile NFS Version 3, konkret rsize,wsize > 8k.

Ich hab meine Installation seit über einem Jahr nicht angefasst, da die Kiste mit dem Kernel von ypsilon genau das macht was sie soll.

Beitrag von **Frockert** » Sonntag 15. Januar 2006, 14:54

Ja, kann er (schon lange).

Ich habe hier Testergebnisse verschiedener Paketgrössen genannt:

http://forum.tuxbox-cvs.sourceforge.net ... highlight=

Gruß
Frockert

Beitrag von **wolgade** » Sonntag 15. Januar 2006, 15:17

Hoppla, das ist an mir vorbeigegangen. Liegt wohl daran, daß ich seit über einem Jahr keinen Ärger mehr hatte. NFS-Server im Kernel (nicht als Modul), Switch getauscht, zwischendurch immer mit dem Essu-Skript gemessen, fertig wars.

Benutzt du eigentlich immer noch den Pentium-Oldie als Server?

Beitrag von **Frockert** » Sonntag 15. Januar 2006, 15:32

wolgade hat geschrieben: Benutzt du eigentlich immer noch den Pentium-Oldie als Server?

Der Oldie werkelt nun beim Bruder, der Oldie konnte ja nur 2,7 mb/s im Netz, das war als Fileserver für den anderen Kram einfach was träge.

Aktuell habe ich einen Epia 6000 cl --> 10 mb/s

Gruß
Frockert

Beitrag von **wolgade** » Sonntag 15. Januar 2006, 15:56

der Oldie konnte ja nur 2,7 mb/s im Netz

Jetzt tust du ihm aber unrecht. Da hat noch was anderes geklemmt. Bei mir arbeitet immer noch die alte Siemens-Nixdorf-Möhre mit Pentium 133 oder 166. Performant wurde die allerdings erst durch den Ypsilon-Kernel. Damit komme ich auf gute 8,5 Mbit/s und das reicht.

Jetzt weißt du auch, warum ich kein Update mache. Ich möchte die Kiste nicht noch einmal tunen müssen.

Beitrag von **Frockert** » Sonntag 15. Januar 2006, 16:06

wolgade hat geschrieben:
der Oldie konnte ja nur 2,7 mb/s im Netz
Jetzt tust du ihm aber unrecht. Da hat noch was anderes geklemmt. Bei mir arbeitet immer noch die alte Siemens-Nixdorf-Möhre mit Pentium 133 oder 166. Performant wurde die allerdings erst durch den Ypsilon-Kernel. Damit komme ich auf gute 8,5 Mbit/s und das reicht.

Jetzt weißt du auch, warum ich kein Update mache. Ich möchte die Kiste nicht noch einmal tunen müssen.

Na na, nicht Äpfel und Birnen vergleichen

2,7 mb/s * 8 = 21,6 mbit/s

Und dies zum Linux-Clienten/Windows-Clienten, zu der dbox waren es dann weniger, wegen der 10 mbit-Schnittstelle der dbox.

Achja, und es war bei mir ein P75, der hat die Aufgabe genauso gut erfüllt wie der aktuelle Epia, deshalb streamt mein Bruder jetzt damit.
Da steht er sogar geräuchlos im Fernsehrack.

Gruß
Frockert

Beitrag von **wolgade** » Sonntag 15. Januar 2006, 20:26

Na na, nicht Äpfel und Birnen vergleichen

2,7 mb/s * 8 = 21,6 mbit/s

Daß du mit mb/s MB/s meinst, kann ich ja nicht wissen. Das kleine "b" steht bei mir immer für bit und nicht Byte. Der Wert, den ich angegeben habe, ist übrigens zwischen Box und Eisfair. Alles andere hat mich nicht interessiert, da der Eisfair bei mir einen einzigen Einsatzzweck hat.

Beitrag von **Frockert** » Sonntag 15. Januar 2006, 21:21

Ein Missverständnis.

Gruß
Frockert

Beitrag von **eisfair** » Dienstag 17. Januar 2006, 17:32

Hallo!
Ich habe auch in letzter Zeit mit 32k Size rumgespielt. Es reicht aus die zwei Module nfs.o und nfsd.o zu tauschen (mit den neu kompilierten Modulen).
Dazu läd man sich das Paket Kernel Source Loader, welches die aktuellen kernelsourcen herunterlädt (vorher das Developer Paket installieren, da sonst der Kernel nicht gepatcht wird).

Dann editiert man die Datei /usr/src/linux-2.4.26-1/include/linux/nfsd/const.h

Und zwar ändert man die Zeile
#define NFSSVC_MAXBLKSIZE (8*1024)
in
#define NFSSVC_MAXBLKSIZE (32*1024)

Ich weiss, darüber steht, dass der Daemon das nicht unterstützt, aber er läuft.

Danach nach /usr/src/linux-2.4.26-1 wechseln und mit "make oldconfig" die Standard kernel-config erstellen und mit "make modules" die Module kompilieren.

er kompiliert dann die Module nfs.o und nfsd.o mit 32k Size.
Diese nehmt ihr dann und ersetzt damit die original module. Die genauen Pfade wo die kompilierten liegen und die originalen hab ich grad nciht im Kopf.
Auf jeden Fall leigen die Originalen in irgendeinem unterverzeichnis von /lib/modules/linux-2.4.26-1
und die neuen in nem unterverzeichnis von /usr/src/linux-2.4.26-1.

Einfach mal suchen. Danach geht auch 32k size!

Wenn irgendwer interesse hat, kann ich auch die fertig kompilierten Module zur verfügung stellen.

Beitrag von **Frockert** » Dienstag 17. Januar 2006, 19:17

Hi,

geht bei mir auch beim Standard, ohne dies Anpassung.

Ich habe diese Speedtests mit dem Standard gemacht, und da wird auch mit diesen Paketgrössen getestet.

Gruß
Frockert

Beitrag von **eisfair** » Mittwoch 18. Januar 2006, 14:01

Echt? auch ohne den Kernel von Epsilon.
Bis du dir sicher, dass die box wirklich mit 32k mountet, weil der original kernel (bzw. die Module) vom eisfair dies definitiv nivht unterstützen.
Ich hatte übrigens auch keine Probleme bei dem update auf 1.2.0!

Beitrag von **Frockert** » Mittwoch 18. Januar 2006, 19:35

eisfair hat geschrieben:Echt? auch ohne den Kernel von Epsilon.
Bis du dir sicher, dass die box wirklich mit 32k mountet, weil der original kernel (bzw. die Module) vom eisfair dies definitiv nivht unterstützen.
Ich hatte übrigens auch keine Probleme bei dem update auf 1.2.0!

Hiho,
ok, ich nehme alles zurück und behaubte das Gegenteil

Zugegebenermassen habe ich an meiner Produktiv-dbox nie mit anderen Mountoptionen wie rsize=8192 und wsize=8192 gearbeitet, es läuft ja einwandfrei.

Ich habe mich auf die Ausgabe von chickens script verlassen
http://forum.tuxbox-cvs.sourceforge.net ... highlight=

Nun habe ich mit meiner Test-dbox (Nokia-Kabel) das nochmal nachvollzogen.

siehe hier:

/var # sh speed.sh

Measuring NFS throughput...
Mount options: udp, async, 8192
writing 32 MBytes...
Success after 35 seconds
reading 32 MBytes...
Success after 35 seconds

Mount options: tcp, async, 8192
writing 32 MBytes...
Success after 46 seconds
reading 32 MBytes...
Success after 40 seconds

Mount options: udp, async, 16384
writing 32 MBytes...
Success after 35 seconds
reading 32 MBytes...
Success after 35 seconds

Mount options: tcp, async, 16384
writing 32 MBytes...
Success after 48 seconds
reading 32 MBytes...
Success after 40 seconds

Mount options: udp, async, 32768
writing 32 MBytes...
Success after 36 seconds
reading 32 MBytes...
Success after 34 seconds

Mount options: tcp, async, 32768
writing 32 MBytes...
Success after 45 seconds
reading 32 MBytes...
Success after 41 seconds

Leider sind Daten vermutlich > 8192 falsch, ich habe während des Testlaufs parallel in einem zweiten Fenster den gemounteten Zustand anzeigen lassen (siehe unten).
Obwohl das skript versucht mit grösseren Werten zu mounten, und dieses auch so anzeigt, wird max. nur mit 8192 gemountet.

Tut mir Leid wegen den Falschinformationen, man sollte vor Nutzung des Testskripts die Mountmöglichkeiten gesondert prüfen

/var # mount
/dev/root on / type squashfs (ro)
none on /dev type devfs (rw)
proc on /proc type proc (rw)
tmpfs on /tmp type ramfs (rw)
/dev/mtdblock/2 on /var type jffs2 (rw)
192.168.1.6:/daten on /mnt type nfs (rw,v3,rsize=8192,wsize=8192,soft,udp,nolock,addr=192.168.1.6)

Gruß
Frockert

Beitrag von **eisfair** » Mittwoch 18. Januar 2006, 21:29

macht ja nix. Na dann weißt du jetzt ja, wie du auf 32k size kommen könntest.

Bei mir tritt das Problem nun auch auf - nur dass der Hack der /etc/init.d/boot keine Besserung verschafft hat. Und das beste: Auch Samba scheint nciht mehr zu funktionieren... Weiß jemand Rat?

Beitrag von **amiga4@ver** » Montag 30. Januar 2006, 19:05

Hi eisfair,

der Tip mit der geänderten const.h ist einfach genial und easy.
Da ich seit Jahresanfang massive Streamingprobleme beim ZDF hatte, hab ich mittlerweile so ziemlich alle Foren abgegrast.
Das streamen unter Windoof ging seltsamerweise mit dboxwinserver und udrec nur NFS unter Eisfair wollte net mehr.
Aber seit gestern funktioniert es wieder

!

Performance vor dem Patch:
8192, 8192
8192+0 records in
8192+0 records out
real 1m 9.28s
user 0m 0.23s
sys 0m 11.26s
7420
8192+0 records in
8192+0 records out
real 1m 15.10s
user 0m 0.18s
sys 0m 8.38s
6826
192.168.1.106:/daten/video on /mnt/filme type nfs (rw,v3,rsize=8192,wsize=8192,s
oft,udp,nolock,addr=192.168.1.106)

und hier danach:
32768, 32768
8192+0 records in
8192+0 records out
real 1m 0.20s
user 0m 0.27s
sys 0m 10.74s
8393
8192+0 records in
8192+0 records out
real 1m 3.93s
user 0m 0.23s
sys 0m 7.13s
8000
192.168.1.106:/daten/video on /mnt/filme type nfs (rw,v3,rsize=32768,wsize=32768
,soft,udp,nolock,addr=192.168.1.106)

Danke!

eisfair hat geschrieben:Hallo!
Ich habe auch in letzter Zeit mit 32k Size rumgespielt. Es reicht aus die zwei Module nfs.o und nfsd.o zu tauschen (mit den neu kompilierten Modulen).
Dazu läd man sich das Paket Kernel Source Loader, welches die aktuellen kernelsourcen herunterlädt (vorher das Developer Paket installieren, da sonst der Kernel nicht gepatcht wird).

Dann editiert man die Datei /usr/src/linux-2.4.26-1/include/linux/nfsd/const.h

Und zwar ändert man die Zeile
#define NFSSVC_MAXBLKSIZE (8*1024)
in
#define NFSSVC_MAXBLKSIZE (32*1024)

Ich weiss, darüber steht, dass der Daemon das nicht unterstützt, aber er läuft.

Danach nach /usr/src/linux-2.4.26-1 wechseln und mit "make oldconfig" die Standard kernel-config erstellen und mit "make modules" die Module kompilieren.

er kompiliert dann die Module nfs.o und nfsd.o mit 32k Size.
Diese nehmt ihr dann und ersetzt damit die original module. Die genauen Pfade wo die kompilierten liegen und die originalen hab ich grad nciht im Kopf.
Auf jeden Fall leigen die Originalen in irgendeinem unterverzeichnis von /lib/modules/linux-2.4.26-1
und die neuen in nem unterverzeichnis von /usr/src/linux-2.4.26-1.

Einfach mal suchen. Danach geht auch 32k size!

Wenn irgendwer interesse hat, kann ich auch die fertig kompilierten Module zur verfügung stellen.

Hi!
make modules läuft bei mir leider nicht durch sondern bricht folgendermaßen ab:

Code: Alles auswählen

gcc -D__KERNEL__ -I/usr/src/linux-2.4.26-1/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=i486 -DMODULE  -nostdinc -iwithprefix include -DKBUILD_BASENAME=advansys  -c -o advansys.o advansys.c
advansys.c: In function `asc_prt_adv_board_eeprom':
advansys.c:8334: invalid operands to binary -
advansys.c:8334: too few arguments to function `asc_prt_line'
make[2]: *** [advansys.o] Error 1
make[2]: Leaving directory `/usr/src/linux-2.4.26-1/drivers/scsi'
make[1]: *** [_modsubdir_scsi] Error 2
make[1]: Leaving directory `/usr/src/linux-2.4.26-1/drivers'
make: *** [_mod_drivers] Error 2

Ideen was ich falsch mache?

Hab jetzt einfach die Binarys aus dem anderem Thread genommen - nur falls das noch jemand lesen sollte...

Beitrag von **webrider** » Sonntag 5. Februar 2006, 03:15

Doch, ich lese noch mit und bin an dem Thema auch höchst interessiert, da mein Eisfair auch mit Abbrüchen zu kämpfen hat und die Performace im Vergleich zu meinem ehemaligen WinXP-SFU miserabel ist.

Die kompilierten *.o Dateien hab ich mir auch schon gezogen, aber da ich von Linux NULL Ahnung hab, wäre eine Schritt für Schritt Anleitung für den Austausch der Dateien ne riesen Hilfe für mich... kann da jemand weiterhelfen?

Beitrag von **Frockert** » Sonntag 5. Februar 2006, 10:35

webrider hat geschrieben: Die kompilierten *.o Dateien hab ich mir auch schon gezogen, aber da ich von Linux NULL Ahnung hab, wäre eine Schritt für Schritt Anleitung für den Austausch der Dateien ne riesen Hilfe für mich... kann da jemand weiterhelfen?

Ok ich versuchs mal.

Aus diesem Thread die Module von Papst (dank an ihn) ziehen
http://forum.tuxbox.org/forum/viewtopic ... c&start=40

Das funktioniert nur mit dem aktuellen, genannten Kernel 2.4.26 Kernel.

Kontrolle aufem Eis:
eisfax # uname -a
Linux eisfax 2.4.26-1 #15 Sun Oct 24 22:54:01 CEST 2004 i686 athlon-4 i386 GNU/Linux
eisfax #

Beim entpacken werden zwei module erstellt:
-rw-r--r-- 1 frockert frockert 94056 2006-01-31 17:12 nfsd.o
-rw-r--r-- 1 frockert frockert 90275 2006-01-31 17:12 nfs.o

Diese müssen auf dem Eisfair ausgetauscht werden:
/lib/modules/2.4.26-1/kernel/fs/nfs/nfs.o
/lib/modules/2.4.26-1/kernel/fs/nfsd/nfsd.o

Ansicht mit den Rechten:
-rw-r--r-- 1 root root 90383 Oct 24 2004 /lib/modules/2.4.26-1/kernel/fs/nfs/nfs.o
-rw-r--r-- 1 root root 94072 Oct 24 2004 /lib/modules/2.4.26-1/kernel/fs/nfsd/nfsd.o

Nun zur Praxis:
Als root einloggen.

Erstmal die originale Retten:
mv /lib/modules/2.4.26-1/kernel/fs/nfs/nfs.o /lib/modules/2.4.26-1/kernel/fs/nfs/nfs.o.ret
mv /lib/modules/2.4.26-1/kernel/fs/nfsd/nfsd.o /lib/modules/2.4.26-1/kernel/fs/nfsd/nfsd.o.ret

Die neuen Module dort hinkopieren:
cp /pfad/zu/den/entpackten/modulen/nfs.o /lib/modules/2.4.26-1/kernel/fs/nfs/nfs.o
cp /pfad/zu/den/entpackten/modulen/nfsd.o /lib/modules/2.4.26-1/kernel/fs/nfsd/nfsd.o

Bei mir sieht das den so aus:
eisfax # cp /root/nfs.o /lib/modules/2.4.26-1/kernel/fs/nfs/nfs.o
eisfax # cp /root/nfsd.o /lib/modules/2.4.26-1/kernel/fs/nfsd/nfsd.o

nachschauen:
eisfax # ls -l /lib/modules/2.4.26-1/kernel/fs/nfs/
total 192
-rw-r--r-- 1 root root 90275 Jan 15 17:54 nfs.o
-rw-r--r-- 1 root root 90383 Oct 24 2004 nfs.o.ret

eisfax # ls -l /lib/modules/2.4.26-1/kernel/fs/nfsd/
total 192
-rw-r--r-- 1 root root 94056 Jan 15 17:54 nfsd.o
-rw-r--r-- 1 root root 94072 Oct 24 2004 nfsd.o.ret

nun rebooten mit "reboot"

Ich gebe keine Gewähr auf die garantierte Funktion, dies ist lediglich ein Beispiel wie man die Module in detailierten Schritten austauschen kann.
Im schlimmsten Fall bootet der Eis net mehr.

Dann kann man immer noch mit ner Live-Cd booten (kanotix/knoppix) und die geretteten Module wieder zurück kopieren.

Wenn Unklarheiten sind, am besten erstmal hier fragen, bevor man was falsches macht.
Ich helfe auch gerne im ICQ etc. weiter.

Gruß
Frockert

Beitrag von **webrider** » Sonntag 5. Februar 2006, 12:46

@Frockert:

Tausend Dank. Dass sich einer die Mühe macht und sooo ne ausführliche Beschreibung erstellt, hät ich echt nicht gedacht. DANKE

Der erst Schritt war auch bei mir schon positiv, da ich den passenden, neuen Kernel hab.

Bevor ich aber weitermache, beherzige ich deinen Tipp und frage mal (blöd?) nach...

Das einzige, was mich ein wenig überrascht hat ist, dass man den "lilo" Befehl am Ende der Prozedur nicht mehr eingeben muss. Bei anderen Treads, in denen der Patch beschrieben wurde, musste man das unbedingt am Ende machen...
Aber da wurde auch noch der Kernel an sich ausgetauscht, wenn ich das Recht verstanden hab - hier das ist ja nur ein "kleiner Eingriff".

Brauch ich den Befehl also wirklich nicht?

Beitrag von **Frockert** » Sonntag 5. Februar 2006, 12:51

webrider hat geschrieben: Das einzige, was mich ein wenig überrascht hat ist, dass man den "lilo" Befehl am Ende der Prozedur nicht mehr eingeben muss. Bei anderen Treads, in denen der Patch beschrieben wurde, musste man das unbedingt am Ende machen...
Aber da wurde auch noch der Kernel an sich ausgetauscht, wenn ich das Recht verstanden hab - hier das ist ja nur ein "kleiner Eingriff".

Brauch ich den Befehl also wirklich nicht?

Richtig,
lilo ist ein Bootmanager (ähnlich grub), wenn man den Kernel tauscht muss man lilo mitteilen das eine Änderung stattgefunden hat.
Da wir hier keine Kerneländerung machen, sondern nur verwendete Module austauschen, ist die Ausführung von lilo nicht notwendig.

Gruß
Frockert

Beitrag von **webrider** » Sonntag 5. Februar 2006, 14:38

Hi, OK, ich hab die Prozedur jetzt mal durchgeführt und dir sogar nen "echten Screenshot" gemacht:

Ist das alles so korrekt? MIr ist nur aufgefallen, dass die Rechte bei mir noch zusätzlich auf Löschen stehen - soll/kann ich das noch ändern? Den Neustart hab ich bisher noch nciht gemacht. Ich wollte hier erst das OK abwarten...

Beitrag von **Papst** » Sonntag 5. Februar 2006, 15:45

Sieht gut aus. Allerdings kann man sich den Neustart auch sparen.
Mit
/etc/init.d/nfsserver stop
den NFS Server anhalten.
Dann mit
rmmod nfsd
das NFS Kernelmodul entladen.
Mit
modprobe nfsd
das neue Kernelmodul laden und abschließend mit
/etc/init.d/nfsserver start
den NFS Server wieder starten.

Beitrag von **webrider** » Sonntag 5. Februar 2006, 17:23

Super, es hat funktioniert - VIELEN DANK an Frockert & Co. für die Hilfe!