Kein Netzwerkzugiff mittels ssh - CentOS 6.3

A

Anton50

Jungspund
Benötige dringend Expertenrat.
Seit Jahren betreibe ich einen Applianceserver (Magnia SG30) an einer Schule mit dem OS RedHat 7.3.
Mittels eines "zerlegten" Magnia SG30 (ich musste eine Grafikkarte einbauen) habe ich inzwischen ein modernes CentOS 6.3 installiert und kann auf diesen Server über die NICs (eth0 und eth1) mittels ssh zugreifen (ein Magnia SG30 besitzt keine Grafikkarte!).
Dies funktioniert auch, wenn ich die Grafikkarte wieder entferne (grub2 wurde entsprechend angepasst).
Da ich mehrere Magnia SG30 besitze und mit CentOS 6.3 auch meinen IT-Unterricht künftig durchführen möchte, habe ich die erfolgreich eingerichtete HDD geklont (und der Clone funktioniert auch auf dem "zerlegten" Magnia SG30) und verzweifle inzwischen, weil die eingerichtete Platte zwar auf den anderen Magnia SG30 startet, aber kein Zugriff mittels ssd möglich ist. Die "message-Ausgabe" zeigt, dass nach "ip_tables: (C) 2000-2006 Netfilter Core Team" der Bootvorgang stehen bleibt (siehe hochgeladene message-Datei). Die Zuordnung MAC-Eth0 scheint zu klappen und die 70-persistent-net.rules habe ich bereits vor der Verwendung der geklonten HDD entsprechend "gesäubert".
Ich bin für jeden Tipp sehr dankbar, weil ich nach stundenlangem Experimentieren mit meinem Latein am Ende bin.
P.S.: Auffallend der Eintrag "udev: renamed network interface eth0 to eth2" obwohl die 70-persistent-net.rules definitiv von mir "geleert" wurde; so kann ssh nicht an eth0 "gebunden" werden.
 

Anhänge

  • messages.txt
    117,2 KB · Aufrufe: 8
Zuletzt bearbeitet:
firmware: requesting e100/d102e_ucode.bin

Code:
egrep "ssh|e100"  messages.txt
Laborrechner Magnia SG30 mit Grafikkarte (Zugriff �ber ssh)

Feb 13 08:59:38 localhost kernel: pci 0000:00:09.0: Firmware left e100 interrupts enabled; disabling
Feb 13 08:59:38 localhost kernel: e100: Intel(R) PRO/100 Network Driver, 3.5.24-k2-NAPI
Feb 13 08:59:38 localhost kernel: e100: Copyright(c) 1999-2006 Intel Corporation
Feb 13 08:59:38 localhost kernel: e100 0000:00:09.0: PCI INT A -> Link[LNKC] -> GSI 7 (level, low) -> IRQ 7
Feb 13 08:59:38 localhost kernel: e100 0000:00:09.0: PME# disabled
Feb 13 08:59:38 localhost kernel: e100 0000:00:09.0: eth1: addr 0xdfdde000, irq 7, MAC addr 00:10:c6:1f:61:70
[COLOR="#FF0000"]Feb 13 08:59:38 localhost kernel: e100 0000:00:09.0: firmware: requesting e100/d102e_ucode.bin[/COLOR]
Feb 13 08:59:38 localhost kernel: e100 0000:00:09.0: eth0: NIC Link is Up 100 Mbps Full Duplex
Laborrechner Magnia SG30 ohne Grafikkarte (Zugriff �ber ssh)

Feb 13 09:06:11 localhost kernel: pci 0000:00:09.0: Firmware left e100 interrupts enabled; disabling
Feb 13 09:06:11 localhost kernel: e100: Intel(R) PRO/100 Network Driver, 3.5.24-k2-NAPI
Feb 13 09:06:11 localhost kernel: e100: Copyright(c) 1999-2006 Intel Corporation
Feb 13 09:06:11 localhost kernel: e100 0000:00:09.0: PCI INT A -> Link[LNKC] -> GSI 15 (level, low) -> IRQ 15
Feb 13 09:06:11 localhost kernel: e100 0000:00:09.0: PME# disabled
Feb 13 09:06:11 localhost kernel: e100 0000:00:09.0: eth1: addr 0xdfffe000, irq 15, MAC addr 00:10:c6:1f:61:70
[COLOR="#FF0000"]Feb 13 09:06:11 localhost kernel: e100 0000:00:09.0: firmware: requesting e100/d102e_ucode.bin[/COLOR]
Feb 13 09:06:11 localhost kernel: e100 0000:00:09.0: eth0: NIC Link is Up 100 Mbps Full Duplex

Zweiter, normaler Magnia SG30, also ohne Grafikkarte (kein Zugriff �ber ssh); 70-persistent-net.rules wurde stets "bereinigt"
Feb 13 09:45:41 localhost kernel: pci 0000:00:09.0: Firmware left e100 interrupts enabled; disabling
Feb 13 09:45:41 localhost kernel: e100: Intel(R) PRO/100 Network Driver, 3.5.24-k2-NAPI
Feb 13 09:45:41 localhost kernel: e100: Copyright(c) 1999-2006 Intel Corporation
Feb 13 09:45:41 localhost kernel: e100 0000:00:09.0: PCI INT A -> Link[LNKC] -> GSI 15 (level, low) -> IRQ 15
Feb 13 09:45:41 localhost kernel: e100 0000:00:09.0: PME# disabled
Feb 13 09:45:41 localhost kernel: e100 0000:00:09.0: eth1: addr 0xdfffe000, irq 15, MAC addr 00:10:c6:1f:5a:00

Funny,dass Du über den gleichen Mist stolperst wie ich bei meinem NB: Drecks proprietäre Netzwerkarten-Firmware.
Über USB hinkopieren, Hooray to Intel und glücklich sein.
 
Hallo

Komisch , bei Intel Karten, egal ob Intel pro100 , oder die 1000 Serie, hab ich nie irgendwelche firmware haben müssen, egal ob unter Debian-Sid, oder Archlinux.
Die Teile liefen und laufen out of the box.


mfg
schwedenmann
 
DANKE!!!!
Bitte noch einen genaueren Hinweis "über USB hineinkopieren, Hooray to Intel und glücklich sein".
Glücklich bin ich schon über deine wertvolle Hilfe. Nun freue ich mich auf eine kleine Anleitung.

Bei Debian gibt´s firmware-linux-nonfree.

Bei CentOS kernel-firmware-2.6.32-279.el6.noarch.rpm.

Als Grünschnabel deshalb die Frage: Welches Paket und wohin damit?

Nachtrag: Inzwischen habe ich die kernel-firmware....rpm auf der Magnia SG30 installiert. Leider jedoch hat sich am Verhalten nichts geändert. Vermutlich hab ich das noch gar nicht verstanden.
 
Zuletzt bearbeitet:
Und für eine Nachhilfe wäre ich auch dankbar: "requesting e100/d102e_ucode.bin"; weshalb erhalte ich diese Meldung nicht mehr nach einem Wechsel des Servers? Die Server sind doch völlig identisch?
 
Zunächst musst Du den Namen des zu Deiner Distribution passenden Pakets finden.

Am einfachsten bekommst Du es in Deinem Fall, indem Du auf einer Deiner funktionierenden Kiste nachschaust, wie es heißt:

Code:
rpm -qa *firmware*

Da werden u.U. mehrere Namen kommen.

Dieses Paket dann im im Netz suchen, auf USB-Datenträger kopieren, dann mit

Code:
yum install kernel-firmware-<foobar>.noarch.rpm

installieren.
 
Fühle mich in die Anfänge von Linux zurückversetzt.

Ich hatte bereits das Paket "kernel-firmware-2.6.32-279.el6.noarch.rpm." auf den Magnia SG30 kopiert und dort installiert (Installation verlief ohne Fehlermeldung)-
Die Eingabe rpm -qa *firmware* wurde akzeptiert, es dauerte eine Weile, jedoch wurde kein firmware-Paket gefunden! Nun wollte ich das Paket erst einmal wieder deinstallieren (rpm -e); es kam jetzt die Meldung, dass das Paket nicht installiert sei (!??). Die wiederholte Installation des Pakets wurde mit der Meldung, dass das Paket bereits installiert wäre, erledigt.

Jetzt steh ich im Wald.
Und kann mich nur für die Hilfe bedanken.
Aber wie komm ich raus aus dem Wald?
 
Just for the record:

Den Namen für das firmware-Paket solltest Du auch mit

Code:
rpm -qf /lib/firmware/e100/d102e_ucode.bin

finden können ("zu welchen Paket gehört Datei xy?").

Was ganz anderes: Bist Du sicher, dass die Netzwerkbuchse an der Kiste funktioniert?

Kleine Lämpchen an der Buchse oder am Switch/Router schauen, ob der entsprechende Port "up" ist.
 
Zunächst: Ich bin mir absolut sicher, dass technisch alles in Ordnung ist. Ich habe 14 Magnia SG30 und alle funktionieren unter RedHat 7.3 und dem Bootloader Lilo. Wenn ich auf einem Magnia SG30 CentOS 6.3 installiere (mit Grafikkarte), anschließend den xserver abschalte, so läuft alles perfekt auf dieser (!) Magnia. Aber im Schulbetrieb bin ich darauf angewiesen die HDDs zu klonen, damit nach jedem Lernprojekt die Magnias wieder in den Urzustand (CentOS 6.3) zurückversetzt werden.
Nur das funktioniert eben nicht. In der message ist erkennbar, dass, sobald ich die HDD in eine andere Magnia stecke, jetzt die eth0-Schnittstelle nach eth2, die eth1-Schnittstelle nach eth3 umbenannt werden, obwohl ich vor dem Einbau die 70-persistent.rules "geleert" hatte, die eingetragene Devices-MAC-Bindungen also gelöscht habe.
Deshalb ist mir die Diagnose "proprietärer Treiber" auch nicht einleuchtend.
Herzlichen Dank noch einmal für die Hilfe; allein schaffe ich das nicht.
 
Sorry aber RedHat 7.3 und lilo ist nun wirklich absolute Steinzeit. Ich glaube nicht dass es dafür noch eine einfache Lösung gibt.
 
"7.3 und lilo ist nun wirklich absolute Steinzeit."
Völlig richtig und genau deshalb habe ich inzwischen einen Magnia SG30 auf CentOS und Grub2 erfolgreich umgestellt.
Da die Magnias keinen VGA-Anschluss haben, also nur über das Netz zu konfigurieren sind, musste ich dieses Geräte völlig zerlegen und mir eine Lösung für den vorhandenen AGP-Steckplatz einfallen lassen. Mit diesem "Laborgerät" arbeite ich absolut erfolgreich.
Nun will ich diese CentOS-Installation natürlich auf alle anderen baugleichen und mit jener "Steinzeit"-Software sehr gut funktionierenden Magnias portieren: Da die Magnias zwei gut zugängliche Schlitten-HDD-Steckplätze haben ist mit dd sehr schnell ein Klon erstellt. Diese Klons aber -und darum geht es- booten die anderen Magnias -nun auch ohne Grafikkarte (rhgb für die Kernelparameter wurde entfernt), aber lassen keinen ssh-Zugriff zu, weil, wie in der messages abgelegt, eth0 in eth2 usw. "verbogen" wird.
Gerne schreibe ich einen ausführlichen Aufsatz über meine Magnia-Arbeiten (diese Geräte sind mit der CentOS-Installation inzwischen wieder Gold wert), wenn ich nur diese letzte Hürde hoffentlich mit eurer Hilfe bewältige.
Dank an alle Helfer!
 
Zuletzt bearbeitet:
Moin,

CentOS ist jetzt nicht wirklich meine Welt, bin die Tage aber über folgendne Artikel gestolpert, da gehts um das Clonen von CentOS-VMs, aber ob VM oder "identische" Hardware ist ja erstmal egal ;).

http://www.theregister.co.uk/2013/02/21/linux_isnt_that_hard_really/
...
You'll notice after that reboot that /etc/udev/rules.d/70-persistent-net.rules now only contains one entry for each NIC in your system, but ifconfig still only shows the loopback adapter. This is because the sysconfig networking scripts (located at /etc/sysconfig/networking-scripts/ifcfg-eth*) haven't been updated with the new MAC address. Open up the appropriate file (for example /etc/sysconfig/networking-scripts/ifcfg-eth0) and edit the MAC address in there so that it matches the MAC address discovered by udev in /etc/udev/rules.d/70-persistent-net.rules.

A frustrating but fairly straightforward fix.
...

mfg
HeadCrash
 
Wie ich in #10 bereits geschrieben habe, sorgte ich dafür, dass der Inhalt von /etc/udev/rules.d/persistent-net.rules "leer" ist, dass also keine MAC-Bindung an die Devices (eth0 und eth1) vorgegeben ist. Eine MAC-Bindung in der ifcfg-eth0 ist nicht vorhanden, bzw. habe ich gelöscht.
An diese beiden Konfigurationen habe ich also gedacht.
Oder habe ich was übersehen?
 
Zuletzt bearbeitet:
Vorläufig gelöst. Ohne Hilfe meines Kollegen würde ich vermutlich noch lange an diesem Problem "rumdoktern".
Der Zugriff mittels ssh funktioniert jetzt. Aber was sich die Programmierer bei RedHat/CentOS da gedacht haben bleibt mir schleierhaft und so werde ich künftig auf dieses OS verzichten (müssen).
Der Zugriff funktioniert nur, wenn in der 70-persistent-net.rules die Bindung der Hardwareadresse an die jeweilige Ethernet-NIC gegeben ist und entsprechend die ifcfg-eth* konfiguriert ist (HWADDR).
In der Praxis bedeutet das, dass jeder Clon bezüglich der Hardwareadressen der SG30, in der er eingesetzt werden soll, nachbearbeitet und die SG30 mit ihren Hardwareadressen verwaltet werden müssen. Was für ein Unsinn!
Deshalb schreibe ich "vorläufige Lösung", weil ich solch einen Unsinn nicht wirklich glauben kann.
Freue mich über kritische Kommentare. Ich wechsle jetzt auf Debian und hoffe, dass jetzt alles wieder nachvollziehbar wird.
Und der Irrlauf über die "proprietären Treiber" ärgert mich etwas: Hier eilte das Vorurteil der Logik voraus: Wenn die Netzkartentreiber unter einer Grafikkarte ihren Dienst tun, dann legen sie sich ohne Grafikkarte nicht die Eigenschaft "proprietär" zu: Beide Netzwerkkarten werden vom Kernel unterstützt.
 
Ich würde mich über Kommentare freuen. Inzwischen sind alle Magnias SG30 mit CentOS 6.3 im Einsatz und alles funktioniert tadellos.
Jeder Klon musste für die jeweilige Magnia SG30 bezüglich der Hardwareadressen/MAC bearbeitet werden. Anschließend wurden Images der jetzt funktionierenden Festplatten für jede einzelne SG30 erstellt -und werden mittels der Seriennummern der SG30 zuverlässig zugeordnet- und der Aufwand hält sich doch in Grenzen, da diese Images lediglich knapp 700 MB groß sind und ein "Recovery" nur ca 5 Minuten dauert. Trotzdem: Ich suche andere Wege.
 
Ich würde mich über Kommentare freuen. Inzwischen sind alle Magnias SG30 mit CentOS 6.3 im Einsatz und alles funktioniert tadellos.
Jeder Klon musste für die jeweilige Magnia SG30 bezüglich der Hardwareadressen/MAC bearbeitet werden. Anschließend wurden Images der jetzt funktionierenden Festplatten für jede einzelne SG30 erstellt -und werden mittels der Seriennummern der SG30 zuverlässig zugeordnet- und der Aufwand hält sich doch in Grenzen, da diese Images lediglich knapp 700 MB groß sind und ein "Recovery" nur ca 5 Minuten dauert. Trotzdem: Ich suche andere Wege.
 
Also die Grafikkarte hat überhaupt nichts damit zu tun. Und das regelmäßige Clonen der HDDs ist auch nicht optimal. Das Stichwort heißt hier Kickstart, es spart Zeit, arbeitet sauber und du hast kein Ärger. Sei gewiss Debian ist da nicht viel anders. Die 70-persistent-net.rules- Regel wird mit dem Script /lib/udev/write_net_rules erzeugt. Es handelt sich um ein normales Shellscript das nur ausgeführt werden muss um eine neue udev-Regel zu erstellen.
 
Zurück
Oben