Hallo, Ich möchte meinen Server (Feste Internet-IP) einen Dienst aus dem Intranet nach draussen leiten lassen. Im Detail wäre das: a) Ein Suse-Linux-7.3-Server mit der gedachten IP 1.1.1.1 (extern, eth0) sowie 192.168.0.1 (intern, eth1) b) Ein Mac, auf dem ein Filemaker-Server 3.0 unter OS 9.x läuft, IP 192.168.0.1 Filemaker servt auf Port 5003. Um das ganze erstmal zu testen, habe ich einfach angefangen mit einem Webserver: rinetd.conf: 1.1.1.1 81 192.168.0.1 www allow *.*.*.* ...ermöglicht problemlos den Zugriff auf den Webserver von 192.168.0.1, wenn ich im Browser eingebe: 1.1.1.1:81 Geht also. Dann umgestrickt auf Filemaker: 1.1.1.1 5003 192.168.0.1 5003 Firewall entsprechend geöffnet (Im Log fängt sich auch nix). Geht nicht. Ich öffne Filemaker, gebe die IP 1.1.1.1 manuell an, und - keine Datenbanken da. Jetzt habe ich gewühlt, und im Filemakersupport gelesen: Filemaker verwendet ausschliesslich TCP, nur beim "einloggen" wird UPD verwandt. Kann es daran liegen? Habe ich einen Denkfehler? Geht das generell nicht mit rinetd? Würde es mit xinetd gehen? Womit dann? ;-) Tschüß, Ratti
... Firewall entsprechend geöffnet (Im Log fängt sich auch nix). Geht nicht. Ich öffne Filemaker, gebe die IP 1.1.1.1 manuell an, und - keine Datenbanken da.
Jetzt habe ich gewühlt, und im Filemakersupport gelesen: Filemaker verwendet ausschliesslich TCP, nur beim "einloggen" wird UPD verwandt. Kann es daran liegen? Habe ich einen Denkfehler? Geht das generell nicht mit rinetd? Würde es mit xinetd gehen? Womit dann? ;-) ...
Hi, vielleicht solltest Du vorher mal so eine Filemaker Session mit dem Netzwerkmonitor beobachten und anhand des Trace entscheiden, ob Du mit rinted weiterkommst. Vermutlich klemmt also nicht der rinetd, sondern es werden Pakete nicht an den Filemaker gelassen, die andere Ports benutzen etc. Prinzipiell wäre das Forwarding ja auch mit iptables oder DeleGate machbar. HTH, Thorsten !
Hallo Leute, ich versuch gerade auf ner Suse 7.1 einen neuen Kernel 2.4.17 zu installiere. System: Athlon 1500+, Epox KHA+ 256 MB RAM, Adaptec AHA-2940 UW mit zwei IBM Platten. SUSE 7.1 installiert (ReiserFS) geht alles. Neuer Kernel und Module erzeugt, ne Initrd mit dem aic7xxx, scsi_mod sd_mod und reiserFS erzeugt. lilo noch drüber und neustart. Alles geht gut (scsi wird geladen die Platten erkannt) bis: VFS: Mounted root (reiserfs filesystem) readonly devfs: devfs_do_symlink(root): coud not append to parent, err: -17 chang_root: old root has d_count=2 // komisch bei SUSE ist d_count=3 kernel Bug at slab.c:815! invalid operrand:0000 CPU:0 EIP:0010 [<c0126eb2>] Not tainted EFLAGS 00010286 // Dann kommt ein Registerauszug Process swapper (pid: 1, stackpage=cffe700) // dann der Stackauszug <0>Kernel panic: Attempted to kill init! //Was er dann auch mach :-( Das ist also mein Leidensweg. Ich hab auch schon alle möglichen CPU futures an und ausgeschaltet. In der Datei slab.c scheint es bei der Zeile 815 ums swappen zu gehen. Findet er meine Swappartition (hab zwei bei sda2 und sdb1) nicht? Bin echt ratlos, das Zeug hat mich schon 2 Nächte gekostet, daher hoffe ich hier kann mir einer helfen. Mit freundlichen Grüssen Reiner Zimmermann -- RZ EDV Beratung | Tel. : 07337 - 921390 Reiner Zimmermann | Fax. : 07337 - 921389 Forststr. 2 | Mobil : 0170 - 9091809 89191 Nellingen | email : reiner.zimmermann@student.uni-ulm.de
Am Donnerstag, 21. Februar 2002 15:08 schrieb Reiner Zimmermann:
Hallo Leute,
ich versuch gerade auf ner Suse 7.1 einen neuen Kernel 2.4.17 zu installiere. System: Athlon 1500+, Epox KHA+ 256 MB RAM, Adaptec AHA-2940 UW mit zwei IBM Platten.
SUSE 7.1 installiert (ReiserFS) geht alles. Neuer Kernel und Module erzeugt, ne Initrd mit dem aic7xxx, scsi_mod sd_mod und reiserFS erzeugt. lilo noch drüber und neustart. Alles geht gut (scsi wird geladen die Platten erkannt) bis:
VFS: Mounted root (reiserfs filesystem) readonly devfs: devfs_do_symlink(root): coud not append to parent, err: -17 chang_root: old root has d_count=2 // komisch bei SUSE ist d_count=3 kernel Bug at slab.c:815! invalid operrand:0000 CPU:0 EIP:0010 [<c0126eb2>] Not tainted EFLAGS 00010286 // Dann kommt ein Registerauszug Process swapper (pid: 1, stackpage=cffe700) // dann der Stackauszug
<0>Kernel panic: Attempted to kill init! //Was er dann auch mach :-(
Das ist also mein Leidensweg. Ich hab auch schon alle möglichen CPU futures an und ausgeschaltet. In der Datei slab.c scheint es bei der Zeile 815 ums swappen zu gehen. Findet er meine Swappartition (hab zwei bei sda2 und sdb1) nicht? Bin echt ratlos, das Zeug hat mich schon 2 Nächte gekostet, daher hoffe ich hier kann mir einer helfen.
Warum hast du devfs aktiviert ? SuSE ist darauf noch nicht vorbereitet. So ohne weiteres dürfte es also nicht laufen... Das muss nicht der Fehler sein, aber das fällt mir erst mal auf.
Hallo Reiner, Reiner Zimmermann wrote:
Hallo Leute,
ich versuch gerade auf ner Suse 7.1 einen neuen Kernel 2.4.17 zu installiere. System: Athlon 1500+, Epox KHA+ 256 MB RAM, Adaptec AHA-2940 UW mit zwei IBM Platten.
SUSE 7.1 installiert (ReiserFS) geht alles. Neuer Kernel und Module erzeugt, ne Initrd mit dem aic7xxx, scsi_mod sd_mod und reiserFS erzeugt. lilo noch drüber und neustart.
Initrd: Als ich hier Fagen zum Kernelbacken hatte, wurde mir gesagt, dass eine initrd bei einem eigenen Kernel NICHT sinnvoll ist. Das wird nur benoetigt, wenn ein Kernel auf unterschiedlichen Systemen laufen soll. Versuch doch mal die Module, die Dein System benoetigt, fest reinzukompelieren (reiserfs + SCSI beispielsweise). Ob's Dir hilf weiss ich nicht :-(
Alles geht gut (scsi wird geladen die Platten erkannt) bis:
VFS: Mounted root (reiserfs filesystem) readonly devfs: devfs_do_symlink(root): coud not append to parent, err: -17 chang_root: old root has d_count=2 // komisch bei SUSE ist d_count=3 kernel Bug at slab.c:815! invalid operrand:0000 CPU:0 EIP:0010 [<c0126eb2>] Not tainted EFLAGS 00010286 // Dann kommt ein Registerauszug Process swapper (pid: 1, stackpage=cffe700) // dann der Stackauszug
<0>Kernel panic: Attempted to kill init! //Was er dann auch mach :-(
Das ist also mein Leidensweg. Ich hab auch schon alle möglichen CPU futures an und ausgeschaltet. In der Datei slab.c scheint es bei der Zeile 815 ums swappen zu gehen. Findet er meine Swappartition (hab zwei bei sda2 und sdb1) nicht? Bin echt ratlos, das Zeug hat mich schon 2 Nächte gekostet, daher hoffe ich hier kann mir einer helfen.
viel Erfolg Werner
Hi, Werner Franke wrote:
Hallo Reiner,
Reiner Zimmermann wrote:
Hallo Leute,
ich versuch gerade auf ner Suse 7.1 einen neuen Kernel 2.4.17 zu installiere. System: Athlon 1500+, Epox KHA+ 256 MB RAM, Adaptec AHA-2940 UW mit zwei IBM Platten.
SUSE 7.1 installiert (ReiserFS) geht alles. Neuer Kernel und Module erzeugt, ne Initrd mit dem aic7xxx, scsi_mod sd_mod und reiserFS erzeugt. lilo noch drüber und neustart.
Initrd: Als ich hier Fagen zum Kernelbacken hatte, wurde mir gesagt, dass eine initrd bei einem eigenen Kernel NICHT sinnvoll ist. Das wird nur benoetigt, wenn ein Kernel auf unterschiedlichen Systemen laufen soll.
Seh' ich auch so, in den Kernel gehört alles, was man unbedingt (zum booten) braucht, also Filesysysteme, Plattentreiber EIDE/SCSI und alle Hardware, die sowieso ständig benutzt wird (Netzwerk,Keyboard,Maus,Graphik etc ..) Module nur für selten benutzte Dinge oder Geräte, die evtl. mit verschiedenen Parametern getestet werden sollen oder müssen. Ich versteh diesen Aufwand mit der initrd nicht oder habe ich da mir unbekannten einen Vorteil übersehen ?
Versuch doch mal die Module, die Dein System benoetigt, fest reinzukompelieren (reiserfs + SCSI beispielsweise).
Ob's Dir hilf weiss ich nicht :-(
Ist auf jeden Fall ein vernünftiger Ansatz.
Alles geht gut (scsi wird geladen die Platten erkannt) bis:
VFS: Mounted root (reiserfs filesystem) readonly devfs: devfs_do_symlink(root): coud not append to parent, err: -17 chang_root: old root has d_count=2 // komisch bei SUSE ist d_count=3 kernel Bug at slab.c:815! invalid operrand:0000 CPU:0 EIP:0010 [<c0126eb2>] Not tainted EFLAGS 00010286 // Dann kommt ein Registerauszug Process swapper (pid: 1, stackpage=cffe700) // dann der Stackauszug
<0>Kernel panic: Attempted to kill init! //Was er dann auch mach :-(
Das ist also mein Leidensweg. Ich hab auch schon alle möglichen CPU futures an und ausgeschaltet. In der Datei slab.c scheint es bei der Zeile 815 ums swappen zu gehen. Findet er meine Swappartition (hab zwei bei sda2 und sdb1) nicht? Bin echt ratlos, das Zeug hat mich schon 2 Nächte gekostet, daher hoffe ich hier kann mir einer helfen.
viel Erfolg Werner
mfg Harry
Hy,
Ich versteh diesen Aufwand mit der initrd nicht oder habe ich da mir unbekannten einen Vorteil übersehen ?
IMHO kann es für einen Distributor Vorteile haben. Er kann eine ganze Palette von Hardwarekonfigurationen mit ein paar Standardkernel erschalgen. -- - maik
Hallo,
hier nochmal eine Zusammenfassung aus dem SuSE Handbuch
zum Thema initrd:
Früher wurden für die verschiedenen SCSI-Treiber unterschiedliche
Kernel zur Installation angeboten (>40). Dies war notwendig, da der
Linux-Kernel das Root-Dateisystem mounten können muß. Außerdem
braucht der Kernel den Code für das Dateisystem um es lesen zu können
und, falls auch noch verschlüsselt, die Eingabe des Schlüssels/Passwort.
Würden die SCSI-Treiber als Module geladen, währe das zu spät -
zu mindest, wenn man ein SCSI-CD ROM Laufwerk zur Installation
bzw. eine SCSI-Festplatte zum booten verwendet.
Die initial ramdisk schafft die Möglichkeit, Userspace-Programme
vor dem Mounten des Root Dateisystems auszuführen.
Wenn also der 'neu' gebackene Kernel die SCSI-Treiber einkompiliert
hat und auch das entsprechende fs, so muß man das erneute Laden
der selbigen Module unterbinden.
Gruß
Michael
From: "Harry Rüter"
Hi,
Werner Franke wrote:
Hallo Reiner,
Reiner Zimmermann wrote:
Hallo Leute,
ich versuch gerade auf ner Suse 7.1 einen neuen Kernel 2.4.17 zu
...
Initrd: Als ich hier Fagen zum Kernelbacken hatte, wurde mir gesagt, dass eine initrd bei einem eigenen Kernel NICHT sinnvoll ist. Das wird nur benoetigt, wenn ein Kernel auf unterschiedlichen Systemen laufen soll.
Seh' ich auch so, in den Kernel gehört alles, was man unbedingt (zum booten) braucht, also Filesysysteme, Plattentreiber EIDE/SCSI und alle Hardware, die sowieso ständig benutzt wird (Netzwerk,Keyboard,Maus,Graphik etc ..)
Module nur für selten benutzte Dinge oder Geräte, die evtl. mit verschiedenen Parametern getestet werden sollen oder müssen.
Ich versteh diesen Aufwand mit der initrd nicht oder habe ich da mir unbekannten einen Vorteil übersehen ?
Reiner Zimmermann
Hallo Leute,
ich versuch gerade auf ner Suse 7.1 einen neuen Kernel 2.4.17 zu installiere.
[...]
Alles geht gut (scsi wird geladen die Platten erkannt) bis:
VFS: Mounted root (reiserfs filesystem) readonly devfs: devfs_do_symlink(root): coud not append to parent, err: -17 chang_root: old root has d_count=2 // komisch bei SUSE ist d_count=3 kernel Bug at slab.c:815! invalid operrand:0000 CPU:0 EIP:0010 [<c0126eb2>] Not tainted EFLAGS 00010286 // Dann kommt ein Registerauszug Process swapper (pid: 1, stackpage=cffe700) // dann der Stackauszug [...] Bin echt ratlos, das Zeug hat mich schon 2 Nächte gekostet, daher hoffe ich hier kann mir einer helfen.
Hast du im Kernel auch devfs und tmpfs aktiviert ? -Dieter -- Dieter Kluenter | Systemberatung Tel:040.64861967 | Fax: 040.64891521 mailto: dkluenter@schevolution.com http://www.schevolution.com/tour
Hallo,
Dieter Kluenter
Reiner Zimmermann
writes: Hallo Leute,
ich versuch gerade auf ner Suse 7.1 einen neuen Kernel 2.4.17 zu installiere.
[...]
Alles geht gut (scsi wird geladen die Platten erkannt) bis:
VFS: Mounted root (reiserfs filesystem) readonly devfs: devfs_do_symlink(root): coud not append to parent, err: -17 chang_root: old root has d_count=2 // komisch bei SUSE ist d_count=3 kernel Bug at slab.c:815! invalid operrand:0000 CPU:0 EIP:0010 [<c0126eb2>] Not tainted EFLAGS 00010286 // Dann kommt ein Registerauszug Process swapper (pid: 1, stackpage=cffe700) // dann der Stackauszug [...] Bin echt ratlos, das Zeug hat mich schon 2 Nächte gekostet, daher hoffe ich hier kann mir einer helfen.
Hast du im Kernel auch devfs und tmpfs aktiviert ?
Das ist eine sinnentstellende Formulierung gewesen, eigentlich sollte die Frage lauten Hast du im Kernel etwa auch devfs und tmpfs aktiviert ? -Dieter -- Dieter Kluenter | Systemberatung Tel:040.64861967 | Fax: 040.64891521 mailto: dkluenter@schevolution.com http://www.schevolution.com/tour
Dieter Kluenter wrote:
Das ist eine sinnentstellende Formulierung gewesen, eigentlich sollte die Frage lauten
Hast du im Kernel etwa auch devfs und tmpfs aktiviert ?
Jau, das war auch das Problem. Weil ich die .config von meinem Kernel (Mandrake 8.2) ferwendet habe. Ja machmal sied man den Wlad vor lauter Bäume nicht. Gruss an alle die mir geschrieben haben. -- RZ EDV Beratung | Tel. : 07337 - 921390 Reiner Zimmermann | Fax. : 07337 - 921389 Forststr. 2 | Mobil : 0170 - 9091809 89191 Nellingen | email : reiner.zimmermann@student.uni-ulm.de
Hallo, Ratti:
Firewall entsprechend geöffnet (Im Log fängt sich auch nix). Geht nicht. Ich öffne Filemaker, gebe die IP 1.1.1.1 manuell an, und - keine Datenbanken da.
Jetzt habe ich gewühlt, und im Filemakersupport gelesen: Filemaker verwendet ausschliesslich TCP, nur beim "einloggen" wird UPD verwandt. Kann es daran liegen? Habe ich einen Denkfehler? Geht das generell nicht mit rinetd? Würde es mit xinetd gehen? Womit dann?
Thorsten Dieckhoff:
Hi, vielleicht solltest Du vorher mal so eine Filemaker Session mit dem Netzwerkmonitor beobachten und anhand des Trace entscheiden, ob Du mit rinted weiterkommst. Vermutlich klemmt also nicht der rinetd, sondern es werden Pakete nicht an den Filemaker gelassen, die andere Ports benutzen etc. Prinzipiell wäre das Forwarding ja auch mit iptables oder DeleGate machbar. HTH, Thorsten !
Hallo, Danke für die Tips. Die Ports sind es definitiv nicht, die habe ich vom Filemakersupport, und außerdem haben wir Filemaker auf einem Windows-Webserver laufen, für den eine Profi die Firewall gemacht hat. Um ganz sicher zu gehen, habe ich kurzzeitig die Firewall deaktiviert, und es hat auch nix gebracht. Da ich nicht so der Netzwerkprofi bin: Auf der Manpage von rinetd steht ja z.B. ganz klar, daß man ftp _nicht_ umleiten kann, da es über zwei Ports läuft, und auch gleich im ersten Satz: rinetd redirects _TCP_ connections. Ist das wohlmöglich zu wenig, und ich bin mit rinetd einfach beim falschen Tool? Gruß, Ratti
Hallo Ratte ;),
From the keyboard of Ratti,
Hallo,
Ratti:
Firewall entsprechend geöffnet (Im Log fängt sich auch nix). Geht nicht. Ich öffne Filemaker, gebe die IP 1.1.1.1 manuell an, und - keine Datenbanken da.
Jetzt habe ich gewühlt, und im Filemakersupport gelesen: Filemaker verwendet ausschliesslich TCP, nur beim "einloggen" wird UPD verwandt. Kann es daran liegen? Habe ich einen Denkfehler? Geht das generell nicht mit rinetd? Würde es mit xinetd gehen? Womit dann?
Thorsten Dieckhoff:
Hi, vielleicht solltest Du vorher mal so eine Filemaker Session mit dem Netzwerkmonitor beobachten und anhand des Trace entscheiden, ob Du mit rinted weiterkommst. Vermutlich klemmt also nicht der rinetd, sondern es werden Pakete nicht an den Filemaker gelassen, die andere Ports benutzen etc. Prinzipiell wäre das Forwarding ja auch mit iptables oder DeleGate machbar. HTH, Thorsten !
Hallo, Danke für die Tips. Die Ports sind es definitiv nicht, die habe ich vom Filemakersupport, und außerdem haben wir Filemaker auf einem Windows-Webserver laufen, für den eine Profi die Firewall gemacht hat. Um ganz sicher zu gehen, habe ich kurzzeitig die Firewall deaktiviert, und es hat auch nix gebracht.
Da ich nicht so der Netzwerkprofi bin: Auf der Manpage von rinetd steht ja z.B. ganz klar, daß man ftp _nicht_ umleiten kann, da es über zwei Ports läuft, und auch gleich im ersten Satz: rinetd redirects _TCP_ connections. Ist das wohlmöglich zu wenig, und ich bin mit rinetd einfach beim falschen Tool?
Wenn u.a. zum Verbindungsaufbau oder Authentifizierung ("einloggen") UDP verwendet wird, dann kommst du mit rinetd nicht auf einen grünen Zweig. Starte mal auf dem Linuxserver ethereal und beobachte was bei einem Verbindungsaufbau von der Internetseite zu deinem "Filemaker" passiert. Hast du einen speziellen Client dafür oder warum muß "Filemaker" von außen erreichbar sein? gruß Waldemar -- Are your questions smart enough? http://www.tuxedo.org/~esr/faqs/smart-questions.html If not: perl -e 'print $i=pack(c5,(41*2),sqrt(7056),(unpack(c,H)-2),oct(115),10);'
Waldemar Brodkorb: [Filemaker über rinetd]
Wenn u.a. zum Verbindungsaufbau oder Authentifizierung ("einloggen") UDP verwendet wird, dann kommst du mit rinetd nicht auf einen grünen Zweig.
Danke, das wollte ich wissen. Ja, UDP wird verwandt.
Starte mal auf dem Linuxserver ethereal und beobachte was bei einem Verbindungsaufbau von der Internetseite zu deinem "Filemaker" passiert.
Das Tool kannte ich noch gar nicht. Werde ich heute tun und dann berichten.
Hast du einen speziellen Client dafür oder warum muß "Filemaker" von außen erreichbar sein?
Ja. Ich habe das alte Filemaker 3 am laufen, der hat noch keinen http-Server drin, sondern nur sein eigenes Protokoll. Ich würde ungern dem Mac-Server eine externe IP verpassen. Er soll aber von außen erreichbar sein. Welche Alternativen gibt es denn zu rinetd? Ich nehme an, das iptables das auch kann, aber reichlich komplexer ist? Gruß, Danke, Ratti
Hallo,
Waldemar Brodkorb:
Starte mal auf dem Linuxserver ethereal und beobachte was bei einem Verbindungsaufbau von der Internetseite zu deinem "Filemaker" passiert.
Ups, der will wohl ein X. Sowas hab ich nicht drauf. Aber deine Aussage, daß ich rinetd vergessen kann, wenn ich UDP brauche, langt ja eigentlich schon, um rinetd zu verwerfen. Hmmm...was nehmt ihr denn so in solchen Fällen? Gruß, Ratti
Hallo Ratti,
From the keyboard of Ratti,
Hallo,
Waldemar Brodkorb:
Starte mal auf dem Linuxserver ethereal und beobachte was bei einem Verbindungsaufbau von der Internetseite zu deinem "Filemaker" passiert.
Ups, der will wohl ein X. Sowas hab ich nicht drauf.
Wahlweiße mit tcpdump einen Snapshot machen und dann die Analyse auf irgendeinem Rechner mit ethereal machen.
Aber deine Aussage, daß ich rinetd vergessen kann, wenn ich UDP brauche, langt ja eigentlich schon, um rinetd zu verwerfen.
Hmmm...was nehmt ihr denn so in solchen Fällen?
iptables könnte man dafür nehmen, könnte deswegen weil es ohne genau analyse des verwendeten Protokolls nicht pauschal zu erläutern ist. Mit iptables kann man aber udp-Ports forwarden. f.e.: IPT=`which iptables` $IPT -t nat -A PREROUTING -p udp --dport 4000 -i $OUTIF -j DNAT --to 192.168.0.2:4000 gruß Waldemar -- Are your questions smart enough? http://www.tuxedo.org/~esr/faqs/smart-questions.html If not: perl -e 'print $i=pack(c5,(41*2),sqrt(7056),(unpack(c,H)-2),oct(115),10);'
Hallo, Waldemar Brodkorb:
Wahlweiße mit tcpdump einen Snapshot machen und dann die Analyse auf irgendeinem Rechner mit ethereal machen. [...] iptables könnte man dafür nehmen, könnte deswegen weil es ohne genau analyse des verwendeten Protokolls nicht pauschal zu erläutern ist. Mit iptables kann man aber udp-Ports forwarden.
f.e.: IPT=`which iptables` $IPT -t nat -A PREROUTING -p udp --dport 4000 -i $OUTIF -j DNAT --to 192.168.0.2:4000
Danke, das ist doch eine schöne Steilvorlage. :-) Ich glaube, die Analyse von Datenpaketen kann ich überspringen. Die Aussage der Firma Filemaker ist ganz klar: Es wird ausschliesslich Port 5003 verwandt, es kommt TCP und UDP zum Einsatz. Alles andere kann geblockt werden. Ich werde am Montag mal gucken, was genau deine Regel bedeutet. Die bezieht sich ja anscheinend nur auf UDP. Auf der Basis würde ich dann eine Regel für TCP erstellen, rinetd erstmal ganz rauslassen, und hoffentlich war es das dann. Tschüß, Ratti
participants (10)
-
Dieter Kluenter
-
Harry Rüter
-
Maik Holtkamp
-
Mathias Weigt
-
Michael Lootz
-
Ratti
-
Reiner Zimmermann
-
Thorsten Dieckhoff
-
Waldemar Brodkorb
-
Werner Franke