Hallo, Ich habe mal wieder ein Problem, welch Wunder. Wir haben hier einen Server und 4 Clients mit openSUSE 12.1. Der Server stellt Samba, Webseite, CUPS, LDAP (Nutzeranmeldung) und NFS zur Verfügung. U.a. die home- Verzeichnisse liegen auf der NFS- Freigabe. Leider hängen nun die Oberflächen der Clients immer so für ca. 5-10 Sekunden. Manchmal tritt das sporadisch 1-2 mal am Tag auf, aber leider auch öfter (2-3 mal pro Stunde). Das nervt nat. extrem, wenn KDE und die geöffneten Programme nicht reagieren. Installiert ist jeweils der NFS-Kernel Server und NFS-Client 1.2.5 aus dem openSUSE 12.1 Update Repo. Zum fraglichen Zeitpunkt sagt mir die "messages" der fraglichen Clients das hier: -------------------------------------------------------------------------------------------------------------------------------------------------- Feb 11 10:52:32 lmvws2 kernel: [15031.367211] nfs: server lmvserver OK Feb 11 10:55:38 lmvws2 kernel: [15216.083039] nfs: server lmvserver not responding, still trying -------------------------------------------------------------------------------------------------------------------------------------------------- Zur gleichen Zeit kommt im Serverlog das hier (steht nur nichts von NFS-Server drin!): -------------------------------------------------------------------------------------------------------------------------------------------------- Feb 11 10:51:51 lmvserver kernel: ll header: 00000000: ff ff ff ff ff ff 00 e0 81 bd 60 40 08 00 ..........`@.. Feb 11 10:52:19 lmvserver kernel: IPv4: martian source 192.168.0.255 from 192.168.0.200, on dev eth1 Feb 11 10:52:19 lmvserver kernel: ll header: 00000000: ff ff ff ff ff ff 00 e0 81 bd 60 40 08 00 ..........`@.. Feb 11 10:52:19 lmvserver kernel: IPv4: martian source 192.168.0.255 from 192.168.0.200, on dev eth1 Feb 11 10:52:19 lmvserver kernel: ll header: 00000000: ff ff ff ff ff ff 00 e0 81 bd 60 40 08 00 ..........`@.. Feb 11 10:52:22 lmvserver kernel: IPv4: martian source 192.168.0.255 from 192.168.0.200, on dev eth1 Feb 11 10:52:22 lmvserver kernel: ll header: 00000000: ff ff ff ff ff ff 00 e0 81 bd 60 40 08 00 ..........`@.. Feb 11 10:52:22 lmvserver kernel: IPv4: martian source 192.168.0.255 from 192.168.0.200, on dev eth1 Feb 11 10:52:22 lmvserver kernel: ll header: 00000000: ff ff ff ff ff ff 00 e0 81 bd 60 40 08 00 ..........`@.. Feb 11 10:52:50 lmvserver kernel: IPv4: martian source 192.168.0.255 from 192.168.0.200, on dev eth1 Feb 11 10:52:50 lmvserver kernel: ll header: 00000000: ff ff ff ff ff ff 00 e0 81 bd 60 40 08 00 ..........`@.. Feb 11 10:52:50 lmvserver kernel: IPv4: martian source 192.168.0.255 from 192.168.0.200, on dev eth1 Feb 11 10:52:50 lmvserver kernel: ll header: 00000000: ff ff ff ff ff ff 00 e0 81 bd 60 40 08 00 ..........`@.. Feb 11 10:52:53 lmvserver kernel: IPv4: martian source 192.168.0.255 from 192.168.0.200, on dev eth1 Feb 11 10:52:53 lmvserver kernel: ll header: 00000000: ff ff ff ff ff ff 00 e0 81 bd 60 40 08 00 ..........`@.. Feb 11 10:52:53 lmvserver kernel: IPv4: martian source 192.168.0.255 from 192.168.0.200, on dev eth1 Feb 11 10:52:53 lmvserver kernel: ll header: 00000000: ff ff ff ff ff ff 00 e0 81 bd 60 40 08 00 ..........`@.. Feb 11 10:53:21 lmvserver kernel: IPv4: martian source 192.168.0.255 from 192.168.0.200, on dev eth1 Feb 11 10:53:21 lmvserver kernel: ll header: 00000000: ff ff ff ff ff ff 00 e0 81 bd 60 40 08 00 ..........`@.. Feb 11 10:53:21 lmvserver kernel: IPv4: martian source 192.168.0.255 from 192.168.0.200, on dev eth1 Feb 11 10:53:21 lmvserver kernel: ll header: 00000000: ff ff ff ff ff ff 00 e0 81 bd 60 40 08 00 ..........`@.. Feb 11 10:53:24 lmvserver kernel: IPv4: martian source 192.168.0.255 from 192.168.0.200, on dev eth1 Feb 11 10:53:24 lmvserver kernel: ll header: 00000000: ff ff ff ff ff ff 00 e0 81 bd 60 40 08 00 ..........`@.. Feb 11 10:53:24 lmvserver kernel: IPv4: martian source 192.168.0.255 from 192.168.0.200, on dev eth1 Feb 11 10:53:24 lmvserver kernel: ll header: 00000000: ff ff ff ff ff ff 00 e0 81 bd 60 40 08 00 ..........`@.. Feb 11 10:53:51 lmvserver kernel: IPv4: martian source 192.168.0.255 from 192.168.0.200, on dev eth1 Feb 11 10:53:51 lmvserver kernel: ll header: 00000000: ff ff ff ff ff ff 00 e0 81 bd 60 40 08 00 ..........`@.. Feb 11 10:53:51 lmvserver kernel: IPv4: martian source 192.168.0.255 from 192.168.0.200, on dev eth1 Feb 11 10:53:51 lmvserver kernel: ll header: 00000000: ff ff ff ff ff ff 00 e0 81 bd 60 40 08 00 ..........`@.. Feb 11 10:53:54 lmvserver kernel: IPv4: martian source 192.168.0.255 from 192.168.0.200, on dev eth1 Feb 11 10:53:54 lmvserver kernel: ll header: 00000000: ff ff ff ff ff ff 00 e0 81 bd 60 40 08 00 ..........`@.. Feb 11 10:53:54 lmvserver kernel: IPv4: martian source 192.168.0.255 from 192.168.0.200, on dev eth1 Feb 11 10:53:54 lmvserver kernel: ll header: 00000000: ff ff ff ff ff ff 00 e0 81 bd 60 40 08 00 ..........`@.. Feb 11 10:54:23 lmvserver kernel: IPv4: martian source 192.168.0.255 from 192.168.0.200, on dev eth1 Feb 11 10:54:23 lmvserver kernel: ll header: 00000000: ff ff ff ff ff ff 00 e0 81 bd 60 40 08 00 ..........`@.. Feb 11 10:54:23 lmvserver kernel: IPv4: martian source 192.168.0.255 from 192.168.0.200, on dev eth1 Feb 11 10:54:23 lmvserver kernel: ll header: 00000000: ff ff ff ff ff ff 00 e0 81 bd 60 40 08 00 ..........`@.. Feb 11 10:54:26 lmvserver kernel: IPv4: martian source 192.168.0.255 from 192.168.0.200, on dev eth1 Feb 11 10:54:26 lmvserver kernel: ll header: 00000000: ff ff ff ff ff ff 00 e0 81 bd 60 40 08 00 ..........`@.. Feb 11 10:54:26 lmvserver kernel: IPv4: martian source 192.168.0.255 from 192.168.0.200, on dev eth1 Feb 11 10:54:26 lmvserver kernel: ll header: 00000000: ff ff ff ff ff ff 00 e0 81 bd 60 40 08 00 ..........`@.. Feb 11 10:54:47 lmvserver kernel: packagekitd[5219]: segfault at 20 ip 00007f6cbe9bd33f sp 00007f6cba227370 error 4 in libzypp.so.1003.1.5[7f6cbe720000+4ca000] Feb 11 10:54:54 lmvserver kernel: IPv4: martian source 192.168.0.255 from 192.168.0.200, on dev eth1 Feb 11 10:54:54 lmvserver kernel: ll header: 00000000: ff ff ff ff ff ff 00 e0 81 bd 60 40 08 00 ..........`@.. Feb 11 10:54:54 lmvserver kernel: IPv4: martian source 192.168.0.255 from 192.168.0.200, on dev eth1 Feb 11 10:54:54 lmvserver kernel: ll header: 00000000: ff ff ff ff ff ff 00 e0 81 bd 60 40 08 00 ..........`@.. Feb 11 10:54:57 lmvserver kernel: IPv4: martian source 192.168.0.255 from 192.168.0.200, on dev eth1 Feb 11 10:54:57 lmvserver kernel: ll header: 00000000: ff ff ff ff ff ff 00 e0 81 bd 60 40 08 00 ..........`@.. Feb 11 10:54:57 lmvserver kernel: IPv4: martian source 192.168.0.255 from 192.168.0.200, on dev eth1 Feb 11 10:54:57 lmvserver kernel: ll header: 00000000: ff ff ff ff ff ff 00 e0 81 bd 60 40 08 00 ..........`@.. Feb 11 10:55:25 lmvserver kernel: IPv4: martian source 192.168.0.255 from 192.168.0.200, on dev eth1 Feb 11 10:55:25 lmvserver kernel: ll header: 00000000: ff ff ff ff ff ff 00 e0 81 bd 60 40 08 00 ..........`@.. Feb 11 10:55:25 lmvserver kernel: IPv4: martian source 192.168.0.255 from 192.168.0.200, on dev eth1 Feb 11 10:55:25 lmvserver kernel: ll header: 00000000: ff ff ff ff ff ff 00 e0 81 bd 60 40 08 00 ..........`@.. Feb 11 10:55:28 lmvserver kernel: IPv4: martian source 192.168.0.255 from 192.168.0.200, on dev eth1 Feb 11 10:55:28 lmvserver kernel: ll header: 00000000: ff ff ff ff ff ff 00 e0 81 bd 60 40 08 00 ..........`@.. Feb 11 10:55:28 lmvserver kernel: IPv4: martian source 192.168.0.255 from 192.168.0.200, on dev eth1 Feb 11 10:55:28 lmvserver kernel: ll header: 00000000: ff ff ff ff ff ff 00 e0 81 bd 60 40 08 00 ..........`@.. Feb 11 10:55:55 lmvserver kernel: IPv4: martian source 192.168.0.255 from 192.168.0.200, on dev eth1 Feb 11 10:55:55 lmvserver kernel: ll header: 00000000: ff ff ff ff ff ff 00 e0 81 bd 60 40 08 00 ..........`@.. Feb 11 10:55:55 lmvserver kernel: IPv4: martian source 192.168.0.255 from 192.168.0.200, on dev eth1 Feb 11 10:55:55 lmvserver kernel: ll header: 00000000: ff ff ff ff ff ff 00 e0 81 bd 60 40 08 00 ..........`@.. Feb 11 10:55:58 lmvserver kernel: IPv4: martian source 192.168.0.255 from 192.168.0.200, on dev eth1 Feb 11 10:55:58 lmvserver kernel: ll header: 00000000: ff ff ff ff ff ff 00 e0 81 bd 60 40 08 00 ..........`@.. Feb 11 10:55:58 lmvserver kernel: IPv4: martian source 192.168.0.255 from 192.168.0.200, on dev eth1 Feb 11 10:55:58 lmvserver kernel: ll header: 00000000: ff ff ff ff ff ff 00 e0 81 bd 60 40 08 00 ..........`@.. Feb 11 10:56:26 lmvserver kernel: IPv4: martian source 192.168.0.255 from 192.168.0.200, on dev eth1 Feb 11 10:56:26 lmvserver kernel: ll header: 00000000: ff ff ff ff ff ff 00 e0 81 bd 60 40 08 00 ..........`@.. -------------------------------------------------------------------------------------------------------------------------------------------------- Die Adresse 192.168.0.200 ist allerdings die Adresse des Servers! Das mit den "martian Source" ist zwar ärgerlich, aber sollte doch den NFS-Server nicht beeinflussen? Hat jemand eine Idee bzw. sind solche Probleme bekannt? -- Mit freundlichen Grüßen Sebastian Reinhardt -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am 11.02.13 17:46, schrieb Sebastian Reinhardt:
Hallo, Ich habe mal wieder ein Problem, welch Wunder. Wir haben hier einen Server und 4 Clients mit openSUSE 12.1. Der Server stellt Samba, Webseite, CUPS, LDAP (Nutzeranmeldung) und NFS zur Verfügung. U.a. die home- Verzeichnisse liegen auf der NFS- Freigabe. Leider hängen nun die Oberflächen der Clients immer so für ca. 5-10 Sekunden. Manchmal tritt das sporadisch 1-2 mal am Tag auf, aber leider auch öfter (2-3 mal pro Stunde). Das nervt nat. extrem, wenn KDE und die geöffneten Programme nicht reagieren. Installiert ist jeweils der NFS-Kernel Server und NFS-Client 1.2.5 aus dem openSUSE 12.1 Update Repo.
Zum fraglichen Zeitpunkt sagt mir die "messages" der fraglichen Clients das hier: --------------------------------------------------------------------------------------------------------------------------------------------------
Feb 11 10:52:32 lmvws2 kernel: [15031.367211] nfs: server lmvserver OK Feb 11 10:55:38 lmvws2 kernel: [15216.083039] nfs: server lmvserver not responding, still trying --------------------------------------------------------------------------------------------------------------------------------------------------
Zur gleichen Zeit kommt im Serverlog das hier (steht nur nichts von NFS-Server drin!): --------------------------------------------------------------------------------------------------------------------------------------------------
Feb 11 10:51:51 lmvserver kernel: ll header: 00000000: ff ff ff ff ff ff 00 e0 81 bd 60 40 08 00 ..........`@.. Feb 11 10:52:19 lmvserver kernel: IPv4: martian source 192.168.0.255 from 192.168.0.200, on dev eth1
[...]
--------------------------------------------------------------------------------------------------------------------------------------------------
Die Adresse 192.168.0.200 ist allerdings die Adresse des Servers! Das mit den "martian Source" ist zwar ärgerlich, aber sollte doch den NFS-Server nicht beeinflussen?
Naja, Du solltest Dir mal eine IP Konfiguration/Routen ansehen, denn die Meldung kommt ja nicht von ungefähr. Dein NFS Server will mit dem Mars reden, ggf. wartet er dann auf Antwort, die er nicht bekommt... oder er will eine Antwort an den Mars senden. -- ae | Andreas Ernst | IT Spektrum Postfach 5, 65612 Beselich Schupbacher Str. 32, 65614 Beselich, Germany Tel: +49-6484-91002 Fax: +49-6484-91003 ae@ae-online.de | www.ae-online.de www.parcelchecker.de | www.tachyon-online.de -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am 11.02.2013 18:14, schrieb Andreas Ernst:
Die Adresse 192.168.0.200 ist allerdings die Adresse des Servers! Das mit den "martian Source" ist zwar ärgerlich, aber sollte doch den NFS-Server nicht beeinflussen?
Naja, Du solltest Dir mal eine IP Konfiguration/Routen ansehen, denn die Meldung kommt ja nicht von ungefähr.
Dein NFS Server will mit dem Mars reden, ggf. wartet er dann auf Antwort, die er nicht bekommt... oder er will eine Antwort an den Mars senden.
Das Problem ist nur, dass ich die Quelle dieser Meldung nicht wirklich identifizieren kann. Beim Server (192.168.0.200 und 192.168.0.201) steht nur der Router (192.168.0.100) als Nameserver drin und als Route über eth0 (192.168.0.200) ist auch nur der Router drin. Also sollte der sich eignetlich nicht selber solche Pakete schicken..... ------------------------------------------------------------------------------- route Kernel IP Routentabelle Ziel Router Genmask Flags Metric Ref Use Iface default router.lmv 0.0.0.0 UG 0 0 0 eth0 loopback * 255.0.0.0 U 0 0 0 lo link-local * 255.255.0.0 U 0 0 0 eth0 192.168.0.0 * 255.255.255.0 U 0 0 0 eth0 192.168.0.0 * 255.255.255.0 U 0 0 0 eth1 -------------------------------------------------------------------------------- -- Mit freundlichen Grüßen Sebastian Reinhardt -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am 11.02.2013 19:14, schrieb Sebastian Reinhardt:
Am 11.02.2013 18:14, schrieb Andreas Ernst:
route Kernel IP Routentabelle Ziel Router Genmask Flags Metric Ref Use Iface default router.lmv 0.0.0.0 UG 0 0 0 eth0 loopback * 255.0.0.0 U 0 0 0 lo link-local * 255.255.0.0 U 0 0 0 eth0 192.168.0.0 * 255.255.255.0 U 0 0 0 eth0 192.168.0.0 * 255.255.255.0 U 0 0 0 eth1 --------------------------------------------------------------------------------
Sehe ich das richtig, dass 192.168.0.0 über 2 Interfaces geroutet wird (eth0 und eth1)? Das könnte evtl. Probleme geben. mfg Hendrik -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am 11.02.2013 19:43, schrieb Hendrik Woltersdorf:
Am 11.02.2013 19:14, schrieb Sebastian Reinhardt:
Am 11.02.2013 18:14, schrieb Andreas Ernst: route Kernel IP Routentabelle Ziel Router Genmask Flags Metric Ref Use Iface default router.lmv 0.0.0.0 UG 0 0 0 eth0 loopback * 255.0.0.0 U 0 0 0 lo link-local * 255.255.0.0 U 0 0 0 eth0 192.168.0.0 * 255.255.255.0 U 0 0 0 eth0 192.168.0.0 * 255.255.255.0 U 0 0 0 eth1 --------------------------------------------------------------------------------
Sehe ich das richtig, dass 192.168.0.0 über 2 Interfaces geroutet wird (eth0 und eth1)?
Das könnte evtl. Probleme geben.
mfg Hendrik Ganz ehrlich: Das hat Yast automatisch so vergeben. Ich hatte auch schon Probleme, als ich die default-Route nicht von Hand gesetzt hatte. Da habe ich aber noch nie was dran geändert und bis 11.3 gab es diese Probleme nicht. Nun gut, ich sollte vielleicht noch folgendes ergänzen: Der Server hat die zwei LAN-Anschlüsse und beide befinden sich im selben Netzsegment (eth0:192.168.0.200 und eth1:192.168.0.201). Die benutze ich, um ein bisschen "Load-Balancing" zu betreiben. Grundsätzlich bietet der Server aber alle Dienste auf beiden Schnittstellen an. Wenn ja, wo liegt da das Problem? Internet bekommen alle, wie schon erwähnt, über den Router (pfSense- Box: 192.168.0.100).
-- Mit freundlichen Grüßen Sebastian Reinhardt -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am 11.02.2013 21:21, schrieb Sebastian Reinhardt:
Am 11.02.2013 19:43, schrieb Hendrik Woltersdorf:
Am 11.02.2013 19:14, schrieb Sebastian Reinhardt:
Am 11.02.2013 18:14, schrieb Andreas Ernst: route Kernel IP Routentabelle Ziel Router Genmask Flags Metric Ref Use Iface default router.lmv 0.0.0.0 UG 0 0 0 eth0 loopback * 255.0.0.0 U 0 0 0 lo link-local * 255.255.0.0 U 0 0 0 eth0 192.168.0.0 * 255.255.255.0 U 0 0 0 eth0 192.168.0.0 * 255.255.255.0 U 0 0 0 eth1 --------------------------------------------------------------------------------
Sehe ich das richtig, dass 192.168.0.0 über 2 Interfaces geroutet wird (eth0 und eth1)?
Das könnte evtl. Probleme geben.
mfg Hendrik Ganz ehrlich: Das hat Yast automatisch so vergeben. Ich hatte auch schon Probleme, als ich die default-Route nicht von Hand gesetzt hatte. Da habe ich aber noch nie was dran geändert und bis 11.3 gab es diese Probleme nicht. Nun gut, ich sollte vielleicht noch folgendes ergänzen: Der Server hat die zwei LAN-Anschlüsse und beide befinden sich im selben Netzsegment (eth0:192.168.0.200 und eth1:192.168.0.201). Die benutze ich, um ein bisschen "Load-Balancing" zu betreiben. Grundsätzlich bietet der Server aber alle Dienste auf beiden Schnittstellen an. Wenn ja, wo liegt da das Problem? Internet bekommen alle, wie schon erwähnt, über den Router (pfSense- Box: 192.168.0.100).
Ich bin jetzt nicht der große Netzwerk-Guru, aber ich könnte mir vorstellen, dass es Clients verwirrt, wenn sie Pakete an eth0 (bzw. dessen MAC-Adresse) schicken und bekommen die Antwort von einer anderen MAC-Adresse (eth1). Aber das kann man sicher auch konfigurieren, dass die Antwort immer auf die Schnittstelle geht, über die die Anfrage kam. -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am Montag, 11. Februar 2013 schrieb Sebastian Reinhardt: (...)
Nun gut, ich sollte vielleicht noch folgendes ergänzen: Der Server hat die zwei LAN-Anschlüsse und beide befinden sich im selben Netzsegment (eth0:192.168.0.200 und eth1:192.168.0.201). Die benutze ich, um ein bisschen "Load-Balancing" zu betreiben. (...)
Hmm ... ja, das solltest Du evtl. erwähnen ;-) Wenn Du Load-Balancing machen willst, ist das Stichwort Bonding! Was Du da treibst ist zumindest(!) fragwürdig ... Bonding zu aktivieren ist recht simple. (per YaST) Du vergibst an die zwei Netzwerkkarten keine Adresse und erstellst eine zusätzliche Bonding-Karte die bekommt eine IP-Adresse und ihr werden die beiden physikalischen NIC zugewiesen. Dann kommt der spannende Teil: Welches Protokoll soll genutzt werden? (In der Drop-Down Box Bond-Treiber-Optionen). Das hängt in erster Linie vom Switch ab an dem die beiden NIC hängen. Um es kurz zu machen: Probiert aus was bei dir (am besten) läuft. (802.3 ad kannst du wahrscheinlich direkt ausschließen das klappt nur mit der entsprechenden Konfig am Router) Bye Bernd Bye Bernd -------------------------------------------------- Bitte nur der Liste antworten, danke -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am 12.02.2013 08:37, schrieb Bernd Nachtigall:
Am Montag, 11. Februar 2013 schrieb Sebastian Reinhardt: (...)
Nun gut, ich sollte vielleicht noch folgendes ergänzen: Der Server hat die zwei LAN-Anschlüsse und beide befinden sich im selben Netzsegment (eth0:192.168.0.200 und eth1:192.168.0.201). Die benutze ich, um ein bisschen "Load-Balancing" zu betreiben. (...)
Hmm ... ja, das solltest Du evtl. erwähnen ;-)
Wenn Du Load-Balancing machen willst, ist das Stichwort Bonding! Was Du da treibst ist zumindest(!) fragwürdig ... Naja, das mache ich eigentlich schon seit ca. 5 Jahren so (da kam der erste Rechner mit 2 NIC's zum Einsatz). Hat bis zur 11.3 so funktioniert. Mir ist allerdings auch klar, das das so eine Art "Poor-Mans-Load-Balancing" ist. Also nicht schön, hat aber funktioniert. Offenbar ist jetzt einiges nicht mehr so fehlertolerant wie früher (ist ja auch gut so).
Bonding zu aktivieren ist recht simple. (per YaST) Du vergibst an die zwei Netzwerkkarten keine Adresse und erstellst eine zusätzliche Bonding-Karte die bekommt eine IP-Adresse und ihr werden die beiden physikalischen NIC zugewiesen.
Dann kommt der spannende Teil: Welches Protokoll soll genutzt werden? (In der Drop-Down Box Bond-Treiber-Optionen). Das hängt in erster Linie vom Switch ab an dem die beiden NIC hängen. Um es kurz zu machen: Probiert aus was bei dir (am besten) läuft. (802.3 ad kannst du wahrscheinlich direkt ausschließen das klappt nur mit der entsprechenden Konfig am Router) Das kann ich aber erst am Wochenende ausprobieren.
Und ihr seid der Meinung, das das schon des Rätsels Lösung ist? Ich habe da bei den "afrikanischen Stammesbrüdern" auch schon was zum Thema nfs gefunden (z.B.:http://ubuntuforums.org/showthread.php?t=1357352&highlight=nfs+large+file). Dort war die "Lösung" die Cache-Einstellungen des NFS-Servers anzupassen. Läuft aber auch auf "ausprobieren" raus. Wenn ich mich da nicht durcharbeiten muss bin ich allerdings auch nicht böse. -- Mit freundlichen Grüßen Sebastian Reinhardt -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
On 02/11/2013 09:21 PM, Sebastian Reinhardt wrote:
192.168.0.0 * 255.255.255.0 U 0 0 0 eth0 192.168.0.0 * 255.255.255.0 U 0 0 0 eth1 --------------------------------------------------------------------------------
Sehe ich das richtig, dass 192.168.0.0 über 2 Interfaces geroutet wird (eth0 und eth1)?
Ich könnte mir vorstellen, dass das hier hilft: http://lartc.org/howto/lartc.kernel.html rp_filter und log_martians wird von der SuSEfirewall normalerweise angeschaltet. Torsten -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
On Tue, Feb 12, 2013 at 09:13:05AM +0100, Torsten Förtsch wrote:
On 02/11/2013 09:21 PM, Sebastian Reinhardt wrote:
192.168.0.0 * 255.255.255.0 U 0 0 0 eth0 192.168.0.0 * 255.255.255.0 U 0 0 0 eth1 --------------------------------------------------------------------------------
Sehe ich das richtig, dass 192.168.0.0 über 2 Interfaces geroutet wird (eth0 und eth1)?
Ich könnte mir vorstellen, dass das hier hilft:
http://lartc.org/howto/lartc.kernel.html
rp_filter und log_martians wird von der SuSEfirewall normalerweise angeschaltet.
Halten Einträge in /proc nicht nur bis zum nächsten Reboot? Lieber in sysctl abstellen schlumpf:/home/florian # sysctl -a | grep martian net.ipv4.conf.all.log_martians = 0 net.ipv4.conf.default.log_martians = 0 net.ipv4.conf.lo.log_martians = 0 net.ipv4.conf.eth2.log_martians = 0 net.ipv4.conf.eth3.log_martians = 0 net.ipv4.conf.eth1.log_martians = 0 net.ipv4.conf.sit0.log_martians = 0 net.ipv4.conf.he-ipv6.log_martians = 0 Das sollte es tun (evtl. noch die Devices extra, ich weiß es nicht mehr) sysctl net.ipv4.conf.all.log_martians=0 sysctl net.ipv4.conf.default.log_martians=0 flo -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
On 02/14/2013 09:21 PM, Florian Groß wrote:
On Tue, Feb 12, 2013 at 09:13:05AM +0100, Torsten Förtsch wrote:
On 02/11/2013 09:21 PM, Sebastian Reinhardt wrote:
> 192.168.0.0 * 255.255.255.0 U 0 0 0 eth0 > 192.168.0.0 * 255.255.255.0 U 0 0 0 eth1 > -------------------------------------------------------------------------------- > > > Sehe ich das richtig, dass 192.168.0.0 über 2 Interfaces geroutet wird (eth0 und eth1)?
Ich könnte mir vorstellen, dass das hier hilft:
http://lartc.org/howto/lartc.kernel.html
rp_filter und log_martians wird von der SuSEfirewall normalerweise angeschaltet. Halten Einträge in /proc nicht nur bis zum nächsten Reboot?
Lieber in sysctl abstellen
schlumpf:/home/florian # sysctl -a | grep martian net.ipv4.conf.all.log_martians = 0 net.ipv4.conf.default.log_martians = 0 net.ipv4.conf.lo.log_martians = 0 net.ipv4.conf.eth2.log_martians = 0 net.ipv4.conf.eth3.log_martians = 0 net.ipv4.conf.eth1.log_martians = 0 net.ipv4.conf.sit0.log_martians = 0 net.ipv4.conf.he-ipv6.log_martians = 0
Das sollte es tun (evtl. noch die Devices extra, ich weiß es nicht mehr) sysctl net.ipv4.conf.all.log_martians=0 sysctl net.ipv4.conf.default.log_martians=0
Freilich. Die Frage war aber doch eigentlich, woher die Fehler kommen und nicht, wie Kernel Parameter so auf der Platte verankert werden, dass sie den Reboot überleben. Außerdem liest bzw. schreibt sysctl auch nur /proc. Ob Du sysctl benutzt oder /proc ist völlig gleich. Damit die Parameter den Reboot überleben, müssen sie irgendwo im Filesystem hinterlegt sein und während des Systemstarts eingelesen werden. Normalerweise werden sie in /etc/sysctl.conf eingetragen und mittels /etc/init.d/boot.sysctl beim Systemstart aktiviert. Der wichtige Punkt in meiner Antwort war jedoch nicht log_martians, sondern rp_filter. Ich denke, dass Sebastians Kernel einige IP Pakete, die er eigentlich beachten sollte, verwirft, weil sie auf dem falschen Interface ankommen. Torsten -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am 14.02.2013 22:45, schrieb Torsten Förtsch:
On 02/14/2013 09:21 PM, Florian Groß wrote:
On Tue, Feb 12, 2013 at 09:13:05AM +0100, Torsten Förtsch wrote:
On 02/11/2013 09:21 PM, Sebastian Reinhardt wrote:
>> 192.168.0.0 * 255.255.255.0 U 0 0 0 eth0 >> 192.168.0.0 * 255.255.255.0 U 0 0 0 eth1 >> -------------------------------------------------------------------------------- >> >> >> Sehe ich das richtig, dass 192.168.0.0 über 2 Interfaces geroutet wird (eth0 und eth1)? Ich könnte mir vorstellen, dass das hier hilft:
http://lartc.org/howto/lartc.kernel.html
rp_filter und log_martians wird von der SuSEfirewall normalerweise angeschaltet. Halten Einträge in /proc nicht nur bis zum nächsten Reboot?
Lieber in sysctl abstellen
schlumpf:/home/florian # sysctl -a | grep martian net.ipv4.conf.all.log_martians = 0 net.ipv4.conf.default.log_martians = 0 net.ipv4.conf.lo.log_martians = 0 net.ipv4.conf.eth2.log_martians = 0 net.ipv4.conf.eth3.log_martians = 0 net.ipv4.conf.eth1.log_martians = 0 net.ipv4.conf.sit0.log_martians = 0 net.ipv4.conf.he-ipv6.log_martians = 0
Das sollte es tun (evtl. noch die Devices extra, ich weiß es nicht mehr) sysctl net.ipv4.conf.all.log_martians=0 sysctl net.ipv4.conf.default.log_martians=0 Freilich. Die Frage war aber doch eigentlich, woher die Fehler kommen und nicht, wie Kernel Parameter so auf der Platte verankert werden, dass sie den Reboot überleben. Außerdem liest bzw. schreibt sysctl auch nur /proc. Ob Du sysctl benutzt oder /proc ist völlig gleich. Damit die Parameter den Reboot überleben, müssen sie irgendwo im Filesystem hinterlegt sein und während des Systemstarts eingelesen werden. Normalerweise werden sie in /etc/sysctl.conf eingetragen und mittels /etc/init.d/boot.sysctl beim Systemstart aktiviert.
Der wichtige Punkt in meiner Antwort war jedoch nicht log_martians, sondern rp_filter. Ich denke, dass Sebastians Kernel einige IP Pakete, die er eigentlich beachten sollte, verwirft, weil sie auf dem falschen Interface ankommen.
Torsten Ich fasse das mal zusammen: Der Kernel (i.Ü. ein 3.6.9-1-desktop, 64bit) hat das Problem, das er mit den NIC's durcheinander gerät und Datenpakete falsch zuordnet bzw. verwirft. Dann kommt es zu den "Martian-Source"- Meldungen. Zusätzlich könnte es auch ein Problem mit IPv6 geben. Ist das so richtig?
Lösung wäre dann ein Interface-Bonding zu einem und die richtigen Einstellungen durch ausprobieren heraus bekommen. Dann ggf. noch in der /etc/sysctl.conf IPv6 deaktivieren und schauen, ob es geht. Ist das erstmal richtig? Ich möchte morgen (Freitag) ab ca. 16/17 Uhr anfangen unseren Server "lahm zu legen" und das ausprbieren (reguläre Arbeitszeit ist bei uns bis 16.00Uhr, bis dahin muss ich mich noch gedulden.....sonst würgen die mich....:-) ) Ich habe nat. in der Zwischenzeit ein wenig gesucht und u.a. das hier zum Thema IPv6 gefunden (wobei ich gehofft hatte, das das Thema inzwischen durch ist und das funktioniert): http://linuxpoison.blogspot.de/2008/08/how-to-disable-ipv6-on-suse-linux.htm... Ich verwende i.Ü. kein IPv6 im LAN....brauche es also nicht. Außerdem habe ich auch schon sehr viele "martian-source" Meldungen von den Client- Adressen aus dem Server- Log verbannt, indem ich bei den Clients nur den Router als DNS- Server angegeben habe und den 2. Eintrag (Server-IP) rausgenommen habe. Was mich noch nicht 100%-ig von der "2 NIC Theorie" überzeugt ist, dass die "martian Source"- Meldungen auch auf anderen Rechnern "Stand-alones" mit nur einem NIC auftreten.... Ich habe auch schon verschiedene Kernel probiert, in der Hoffnung, dass sich das von selbst klärt.. leider nicht. Dabei habe ich auch mitbekommen, dass sich ab den 3.7'ern im Kernel:stable REpo sich die NVidia-Treiber nicht mehr installieren/ Kompilieren lassen (es fehlt wohl die linux.h, obwohl devel und source installiert sind!). Das habe ich mit 3.71 und 3.73 probiert, seither nicht mehr. Ich wollte das auch deshalb installieren, da ja die tolle Erweiterung von der "Datenkrake" ab 3.7 drin sein soll. Habe aber keine Ahnung, ob die was bringt. Ist aber ein anderes Thema...... Egal, wenn es keine Einwände gibt, würde ich dann morgen das Bonding einrichten und ggf. IPv6 abschalten. Danach melde ich mich wieder.... -- Mit freundlichen Grüßen Sebastian Reinhardt -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Hallo Sebastian,
Ich habe auch schon verschiedene Kernel probiert, in der Hoffnung, dass sich das von selbst klärt.. leider nicht. Dabei habe ich auch mitbekommen, dass sich ab den 3.7'ern im Kernel:stable REpo sich die NVidia-Treiber nicht mehr installieren/ Kompilieren lassen (es fehlt wohl die linux.h, obwohl devel und source installiert sind!). Das habe ich mit 3.71 und 3.73 probiert, seither nicht mehr. Ich wollte das auch deshalb installieren, da ja die tolle Erweiterung von der "Datenkrake" ab 3.7 drin sein soll. Habe aber keine Ahnung, ob die was bringt. Ist aber ein anderes Thema......
Wenn du im entsprechen dir angepasstem Verzeichnis: /usr/src/linux-3.7.6-23-obj/x86_64/desktop/include/ einen Link legst: ln -s generated/uapi/linux linux geht es wieder da er nach der version.h sucht. Gruß Frank -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
On 02/14/2013 11:16 PM, Sebastian Reinhardt wrote:
Lösung wäre dann ein Interface-Bonding zu einem und die richtigen Einstellungen durch ausprobieren heraus bekommen.
Bonding ist auf jeden Fall die bessere Lösung, muss aber soweit ich weiß vom Switch unterstützt werden. Auch einige andere Unterschiede gibt es. Ich habe vor ein paar Jahren mal 2 Maschinen direkt, ohne Switch mit 2 Leitungen und Bonding verbunden. Theoretisch hatte ich damit eine Bandbreite von 2 GBit/sec. Jede einzelne TCP Verbindung konnte aber nur 1 GBit/sec nutzen. 2 parallele TCP Verbindungen mit je 1 GBit/sec funktionierten problemlos. Wenn Du die Last mit Deiner Methode verteilen willst, sollte eigentlich auf IP Ebene, also über einzelne Pakete passieren. Wenn Du das Routing aller beteiligten Maschinen so hinkriegst, dass sie beide Leitungen nutzen, sollte damit auch eine TCP Verbindung mit 2 GBit/sec machbar sein. Das habe ich aber noch nie ausprobiert. Zur Vorgehensweise, ich würde, bevor ich anfange produktive Server umzustellen, das Ganze mal mit ein paar virtuellen Maschinen üben. Da hast Du zwar noch keinen realen Switch, aber mit dem Bonding kannst Du vertraut werden. Ich glaube, in einem der letzten Linux Magazine einen Artikel über einen Switch in Software gelesen zu haben. Damit könntest Du dann auch diese Seite möglicherweise üben. Wie das Ding heißt, weiß ich nicht mehr. Torsten -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am 15.02.2013 11:52, schrieb Torsten Förtsch:
Lösung wäre dann ein Interface-Bonding zu einem und die richtigen Einstellungen durch ausprobieren heraus bekommen. Bonding ist auf jeden Fall die bessere Lösung, muss aber soweit ich weiß vom Switch unterstützt werden. Auch einige andere Unterschiede gibt es. Ich habe vor ein paar Jahren mal 2 Maschinen direkt, ohne Switch mit 2 Leitungen und Bonding verbunden. Theoretisch hatte ich damit eine Bandbreite von 2 GBit/sec. Jede einzelne TCP Verbindung konnte aber nur 1 GBit/sec nutzen. 2 parallele TCP Verbindungen mit je 1 GBit/sec funktionierten problemlos. Wenn Du die Last mit Deiner Methode verteilen willst, sollte eigentlich auf IP Ebene, also über einzelne Pakete
On 02/14/2013 11:16 PM, Sebastian Reinhardt wrote: passieren. Wenn Du das Routing aller beteiligten Maschinen so hinkriegst, dass sie beide Leitungen nutzen, sollte damit auch eine TCP Verbindung mit 2 GBit/sec machbar sein. Das habe ich aber noch nie ausprobiert.
Zur Vorgehensweise, ich würde, bevor ich anfange produktive Server umzustellen, das Ganze mal mit ein paar virtuellen Maschinen üben. Da hast Du zwar noch keinen realen Switch, aber mit dem Bonding kannst Du vertraut werden. Ich glaube, in einem der letzten Linux Magazine einen Artikel über einen Switch in Software gelesen zu haben. Damit könntest Du dann auch diese Seite möglicherweise üben. Wie das Ding heißt, weiß ich nicht mehr.
Torsten
Ich habe das nat. erst mal probiert. Ich habe hier auch einen Rechner mit 2 NIC's und bei dem läuft es seit gestern abend. Als Modus habe ich erst mal "RoundRobin" ausgewählt. Da das so problemlos funktioniert hat, habe ich heute in der Mittagspause den Server umgestellt (ich weiß, sehr mutig auf die Schnelle). Bisher hängt nichts mehr. Das IPv6 habe ich im Yast auch gleich mit abgeschaltet (hoffe das reicht). Nun ist im Log des Servers aber immer noch einiges los: --------------------------------------------- Feb 15 14:12:01 lmvserver kernel: IPv4: martian source 192.168.0.255 from 192.168.0.200, on dev bond0 Feb 15 14:12:01 lmvserver kernel: ll header: 00000000: ff ff ff ff ff ff 00 e0 81 bd 60 40 08 00 ..........`@.. --------------------------------------------- Bei meinem "Probierrechner" sind die Meldungen mit "martian source" auch nicht weg! Geht jetzt auch nur aufs "bond0" Device..... Dafür habe ich mir auf dem Server ein neues Problem eingehandelt: Die Nutzer loggen sich per "ssh -X" im Server ein (läuft über ein kleines Script=> kann niemand was vergessen, z.B. das "-X"). Nach Eingabe des Nutzenamens und Passwortes wird der Thunderbird des jeweiligen Nutzers aufgerufen. Ging bis heute Mittag problemlos. Seit dem kommt nur "Error: no display specified"! Im Server-Log gibt es folgenden Eintrag: -------------------------------------------- eb 15 12:43:13 lmvserver sshd[6058]: Accepted keyboard-interactive/pam for xx from 192.168.0.200 port 39816 ssh2 Feb 15 12:43:13 lmvserver systemd-logind[1033]: New session 6 of user xx. Feb 15 12:43:13 lmvserver sshd[6075]: error: Failed to allocate internet-domain X11 display socket. -------------------------------------------- Da ich auf meinem Probierrechner mit meinem Nutzernamen direkt eingeloggt bin, geht bei mir der Thunderbird etc. auf! Scheint also ein Problem mit ssh zu sein, nur welches? DISPLAY exportieren etc. hilt nicht. Was nun? -- Mit freundlichen Grüßen Sebastian Reinhardt -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
On 02/15/2013 02:21 PM, Sebastian Reinhardt wrote:
Ich habe das nat. erst mal probiert. Ich habe hier auch einen Rechner mit 2 NIC's und bei dem läuft es seit gestern abend. Als Modus habe ich erst mal "RoundRobin" ausgewählt. Da das so problemlos funktioniert hat, habe ich heute in der Mittagspause den Server umgestellt (ich weiß, sehr mutig auf die Schnelle). Bisher hängt nichts mehr. Das IPv6 habe ich im Yast auch gleich mit abgeschaltet (hoffe das reicht). Nun ist im Log des Servers aber immer noch einiges los: --------------------------------------------- Feb 15 14:12:01 lmvserver kernel: IPv4: martian source 192.168.0.255 from 192.168.0.200, on dev bond0 Feb 15 14:12:01 lmvserver kernel: ll header: 00000000: ff ff ff ff ff ff 00 e0 81 bd 60 40 08 00 ..........`@.. --------------------------------------------- Bei meinem "Probierrechner" sind die Meldungen mit "martian source" auch nicht weg! Geht jetzt auch nur aufs "bond0" Device.....
Dafür habe ich mir auf dem Server ein neues Problem eingehandelt: Die Nutzer loggen sich per "ssh -X" im Server ein (läuft über ein kleines Script=> kann niemand was vergessen, z.B. das "-X"). Nach Eingabe des Nutzenamens und Passwortes wird der Thunderbird des jeweiligen Nutzers aufgerufen. Ging bis heute Mittag problemlos. Seit dem kommt nur "Error: no display specified"! Im Server-Log gibt es folgenden Eintrag: -------------------------------------------- eb 15 12:43:13 lmvserver sshd[6058]: Accepted keyboard-interactive/pam for xx from 192.168.0.200 port 39816 ssh2 Feb 15 12:43:13 lmvserver systemd-logind[1033]: New session 6 of user xx. Feb 15 12:43:13 lmvserver sshd[6075]: error: Failed to allocate internet-domain X11 display socket. -------------------------------------------- Da ich auf meinem Probierrechner mit meinem Nutzernamen direkt eingeloggt bin, geht bei mir der Thunderbird etc. auf! Scheint also ein Problem mit ssh zu sein, nur welches? DISPLAY exportieren etc. hilt nicht. Was nun?
da Du IPv6 disabled hast, musst Du m.E. die Option "AddressFamily inet" in die /etc/sshd/sshd.conf aufnehmen. Hth, Kai -- Rechenzentrum GEOMAR Helmholtz-Zentrum für Ozeanforschung Kiel Duesternbrooker Weg 20 D-24105 Kiel, Germany Tel.: +49 431 600-1557 kgrunau@geomar.de www.geomar.de -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am 15.02.2013 14:30, schrieb Kai Grunau:
On 02/15/2013 02:21 PM, Sebastian Reinhardt wrote:
Ich habe das nat. erst mal probiert. Ich habe hier auch einen Rechner mit 2 NIC's und bei dem läuft es seit gestern abend. Als Modus habe ich erst mal "RoundRobin" ausgewählt. Da das so problemlos funktioniert hat, habe ich heute in der Mittagspause den Server umgestellt (ich weiß, sehr mutig auf die Schnelle). Bisher hängt nichts mehr. Das IPv6 habe ich im Yast auch gleich mit abgeschaltet (hoffe das reicht). Nun ist im Log des Servers aber immer noch einiges los: --------------------------------------------- Feb 15 14:12:01 lmvserver kernel: IPv4: martian source 192.168.0.255 from 192.168.0.200, on dev bond0 Feb 15 14:12:01 lmvserver kernel: ll header: 00000000: ff ff ff ff ff ff 00 e0 81 bd 60 40 08 00 ..........`@.. --------------------------------------------- Bei meinem "Probierrechner" sind die Meldungen mit "martian source" auch nicht weg! Geht jetzt auch nur aufs "bond0" Device.....
Dafür habe ich mir auf dem Server ein neues Problem eingehandelt: Die Nutzer loggen sich per "ssh -X" im Server ein (läuft über ein kleines Script=> kann niemand was vergessen, z.B. das "-X"). Nach Eingabe des Nutzenamens und Passwortes wird der Thunderbird des jeweiligen Nutzers aufgerufen. Ging bis heute Mittag problemlos. Seit dem kommt nur "Error: no display specified"! Im Server-Log gibt es folgenden Eintrag: -------------------------------------------- eb 15 12:43:13 lmvserver sshd[6058]: Accepted keyboard-interactive/pam for xx from 192.168.0.200 port 39816 ssh2 Feb 15 12:43:13 lmvserver systemd-logind[1033]: New session 6 of user xx. Feb 15 12:43:13 lmvserver sshd[6075]: error: Failed to allocate internet-domain X11 display socket. -------------------------------------------- Da ich auf meinem Probierrechner mit meinem Nutzernamen direkt eingeloggt bin, geht bei mir der Thunderbird etc. auf! Scheint also ein Problem mit ssh zu sein, nur welches? DISPLAY exportieren etc. hilt nicht. Was nun?
da Du IPv6 disabled hast, musst Du m.E. die Option "AddressFamily inet" in die /etc/sshd/sshd.conf aufnehmen.
Hth, Kai
Danke Kai! Das war es! Und seit 12:31Uhr (da hab ich auf's bond- Device umgestellt) gibt es noch keinen Hänger beim NFS....Daumen drücken, das es so bleibt! -- Mit freundlichen Grüßen Sebastian Reinhardt -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Am 15.02.2013 15:07, schrieb Sebastian Reinhardt:
Am 15.02.2013 14:30, schrieb Kai Grunau:
On 02/15/2013 02:21 PM, Sebastian Reinhardt wrote:
Ich habe das nat. erst mal probiert. Ich habe hier auch einen Rechner mit 2 NIC's und bei dem läuft es seit gestern abend. Als Modus habe ich erst mal "RoundRobin" ausgewählt. Da das so problemlos funktioniert hat, habe ich heute in der Mittagspause den Server umgestellt (ich weiß, sehr mutig auf die Schnelle). Bisher hängt nichts mehr. Das IPv6 habe ich im Yast auch gleich mit abgeschaltet (hoffe das reicht). Nun ist im Log des Servers aber immer noch einiges los: --------------------------------------------- Feb 15 14:12:01 lmvserver kernel: IPv4: martian source 192.168.0.255 from 192.168.0.200, on dev bond0 Feb 15 14:12:01 lmvserver kernel: ll header: 00000000: ff ff ff ff ff ff 00 e0 81 bd 60 40 08 00 ..........`@.. --------------------------------------------- Bei meinem "Probierrechner" sind die Meldungen mit "martian source" auch nicht weg! Geht jetzt auch nur aufs "bond0" Device.....
Dafür habe ich mir auf dem Server ein neues Problem eingehandelt: Die Nutzer loggen sich per "ssh -X" im Server ein (läuft über ein kleines Script=> kann niemand was vergessen, z.B. das "-X"). Nach Eingabe des Nutzenamens und Passwortes wird der Thunderbird des jeweiligen Nutzers aufgerufen. Ging bis heute Mittag problemlos. Seit dem kommt nur "Error: no display specified"! Im Server-Log gibt es folgenden Eintrag: -------------------------------------------- eb 15 12:43:13 lmvserver sshd[6058]: Accepted keyboard-interactive/pam for xx from 192.168.0.200 port 39816 ssh2 Feb 15 12:43:13 lmvserver systemd-logind[1033]: New session 6 of user xx. Feb 15 12:43:13 lmvserver sshd[6075]: error: Failed to allocate internet-domain X11 display socket. -------------------------------------------- Da ich auf meinem Probierrechner mit meinem Nutzernamen direkt eingeloggt bin, geht bei mir der Thunderbird etc. auf! Scheint also ein Problem mit ssh zu sein, nur welches? DISPLAY exportieren etc. hilt nicht. Was nun?
da Du IPv6 disabled hast, musst Du m.E. die Option "AddressFamily inet" in die /etc/sshd/sshd.conf aufnehmen.
Hth, Kai
Danke Kai! Das war es! Und seit 12:31Uhr (da hab ich auf's bond- Device umgestellt) gibt es noch keinen Hänger beim NFS....Daumen drücken, das es so bleibt!
Dumme Sache, da hatte ich mich zu früh gefreut. Das ist nun von Tag zu Tag schlimmer geworden. Meine Vermutung ist, dass NFS- Kernelserver und Kernel nicht zusammen passen. Außerdem wird das "PackageKit" auch ständig "distroyed" und der Blödsinn mit der "Martian-Source" ist auch immer noch da (sowohl mit IPv4 als auch IPv6). Die Clienten bringen immer wieder, dass der NFS-Server nicht reagiert/ antwortet. Im Server-Log ist aber von NFS keine Rede mehr......Egal, Ich habe mich nun entschlossen eher ein openSUSE_12.3 mit "nur" Standardquellen zu installieren, in der Hoffnung, dass das dort weg ist...... Da der Rechner irgendwie langsam ist (habe hier fast eine 1:1 Kopie, die echt schneller reagiert und mehr Plattendurchsatz bringt;, sind alles SATA-Platten mit SATAII direkt auf dem MB, ohne RAID etc.) werde ich auch die Investition in einen SAS- Controller und SAS- Platten vorziehen. Nun die "Religionsfrage": Was nimmt man da am Besten? Ich dachte an so was hier: http://www.alternate.de/html/product/Adaptec/RAID_51245T/1012634/? Kriterien: - Linux-kompatibel (möglichst "out-of-the-box") - sollte auf das Board passen: http://www.tyan.com/product_board_detail.aspx?pid=175 - PCIe - max. Durchsatz (es laufen Postgres- und MySQL- Datenbanken, LDAP, CUPS und NFS auf dem Rechner)! - min. 4 Platten - kein RAID (hatte schon 3ware - SATAII- Raidkontroller und nur halben Plattendurchsatz => nie wieder!, wenn, dann machen wir lieber SoftRAID mit openSUSE) - keine "Billig-darf-nichts-kosten-Lösung"! eher was "ordentliches" (hab keine Lust das noch mal zu machen - robust (wir haben das Büro mit Server neben einer Werkstatt, dort gibt es eine "böse" Mischung aus Dreck: Dieselruß, Ölnebel, feinste Metallspäne und ganz normalen Dreck) -- Mit freundlichen Grüßen Sebastian Reinhardt -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
Ich möchte in unseren Server einen SAS Kontroller mit entsprechenden Platten einbauen: Gibt es da Erfahrungen/ Empfehlungen bzw. Kontroller, die man gar nicht nehmen sollte? Ich hatte da an so was gedacht: http://www.alternate.de/html/product/Adaptec/RAID_51245T/1012634/? Kriterien: - Linux-kompatibel (möglichst "out-of-the-box") - sollte auf das Board passen: http://www.tyan.com/product_board_detail.aspx?pid=175 - PCIe - max. Durchsatz (es laufen Postgres- und MySQL- Datenbanken, LDAP, CUPS und NFS auf dem Rechner)! - min. 4 Platten - kein RAID (hatte schon 3ware - SATAII- Raidkontroller und nur halben Plattendurchsatz => nie wieder!, wenn, dann machen wir lieber SoftRAID mit openSUSE) - sollte robust sein (wir haben das Büro mit Server neben einer Werkstatt, dort gibt es eine "böse" Mischung aus Dreck: Dieselruß, Ölnebel, feinste Metallspäne und ganz normalen Dreck) -- Mit freundlichen Grüßen Sebastian Reinhardt -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org
participants (8)
-
Andreas Ernst -
Bernd Nachtigall -
Florian Groß -
Frank Babies -
Hendrik Woltersdorf -
Kai Grunau -
Sebastian Reinhardt -
Torsten Förtsch