Anleitung zum Ersetzen des 1&1-Rootserver-Kernels auf openSUSE-11-Installationen

Wie bereits im Heise-Forum von mir zum Heise News-Artikel openSuse-Kernel auf 1&1-Root-Servern möglicherweise veraltet angemerkt, lässt sich der 1&1-eigene Kernel, der offenbar Sicherheitslücken aufweist und sich über die Paketverwaltung nicht aktualisieren lässt, relativ einfach durch den Standard-Kernel von openSUSE ersetzen.

Die folgende Anleitung wurde erfolgreich auf 3 Root-Servern bei 1&1 getestet (1&1 Root-Server S64 mit Athlon64 Single- oder Dual-Core-CPU, 1GB RAM, NVIDIA-Chipsatz (lspci.txt)).

Wie immer bei Anleitungen aus dem Internet gilt auch hier:

Verwendung der Anleitung auf eigene Gefahr. Zu Risiken und Nebenwirkungen fragen Sie Ihren kompetenten Systemadministrator!

Wir aktualisieren die lokale Datenbank des Paketmanagers und schauen uns an, wieviele Updates darauf warten, eingespielt zu werden:

zypper refresh && zypper patch-check

Die letzte Zeile der Ausgabe könnte z.B. so aussehen:

4 patches needed (2 security patches)

Das Release bzw. die Versionsnummer des aktuell laufenden Kernels lassen wir uns mit

uname -r

anzeigen:

2.6.27.31rootserver-20090819a

Durch den Zusatz “rootserver” können wir erkennen, dass hier der von 1&1 selbstgebackene Kernel läuft, den wir gerne ersetzen wollen.

Wir installieren den openSUSE-Standard-Kernel mittels

zypper install kernel-default

Wie ich durch eigene Tests herausgefunden habe, stört sich der SUSE-Kernel an dem Boot-Parameter ro (das Root-FS wird dadurch read-only gemountet, openSUSE mountet dies während der Boot-Phase offenbar selbst nicht read-write).

Ob wir davon betroffen sind, verrät uns

grep kernel /boot/grub/menu.lst

Die Ausgabe könnte z.B. so aussehen:

kernel /boot/vmlinuz-2.6.25.20-0.5-default root=/dev/md1 ro console=tty0 console=ttyS0,57600
kernel /boot/vmlinuz-2.6.25.20-0.5-default root=/dev/md1 showopts ide=nodma apm=off acpi=off noresume edd=off x11failsafe console=tty0 console=ttyS0,57600

Falls bei Euch das ro in der Zeile auftaucht, die mit kernel beginnt, solltest Du mit Deinem Lieblingseditor (z.B. vim oder nano) die Datei /boot/grub/menu.lst bearbeiten und das ro entfernen.

Die Angabe root=/dev/md1 ist darüber hinaus ein Indiz, dass im Server ein Software-RAID eingerichtet ist.

Überprüfen lässt sich das mit

cat /proc/mdstat

Tauchen hier ein oder mehrere md-Devices (md1, …) auf, so ist ein Software-RAID eingerichtet.

Bei den von mir aktualisierten 1&1-Root-Servern war die Datei /etc/mdadm.conf nicht vorhanden.

Diese Datei sollte unbedingt vorhanden sein und die aktuellen RAID-Einstellungen widerspiegeln, wenn man den SUSE-Kernel booten will:

test -e /etc/mdadm.conf && mv /etc/mdadm.conf /etc/mdadm.conf.backup
mdadm –detail –scan > /etc/mdadm.conf

Wichtig: Das initrd-Image muss neu gebaut werden, damit dies die mdadm.conf enthält:

mkinitrd

Die Fehler bzgl. des 1&1 Kernels ignorieren wir.

Anschließend via

reboot

den Server rebooten.

An dieser Stelle empfiehlt es sich, sich zu Diagnose-Zwecken über den seriellen Konsolen-Server von 1&1 mit dem Server zu verbinden – damit ist man in der Lage, dem Kernel beim Booten zuzusehen und eventuelle Unregelmäßigkeiten zu erkennen. Die Zugangsdaten zum Konsolen-Server findest Du im 1&1 Control-Center unter dem Menüpunkt Server-Verwaltung/Serielle Konsole.

Sobald der Server wieder erreichbar und Du per SSH eingeloggt bist, kannst Du mit

uname -r

prüfen, dass nun der SUSE-Kernel geladen wurde. Der aktuelle SUSE-Kernel (Stand 26.11.2009) für openSUSE 11.0 ist:

2.6.25.20-0.5-default

Damit ist das Update des Kernels abgeschlossen.

Comments ( 11 )

  1. mex
    moinsen, danke für die Anleitung mex
  2. Max
    Hallo, danke für die Anleitung! gab es irgendwelche Probleme bzgl Hardwareunterstützung? Denn 1 und 1 sagt ja sie seie wg fehlender hardwareunterstützung gezwungen gewesen, 2.6.27 statt 2.6.25 zu installieren. ist davon irgendwas zu erkennen? Danke und Cheers! Max
  3. Marcel
    @Max Nö, die Hardware läuft. Ich wüsste nicht, dass nach dem Upgrade irgendwas nicht mehr läuft. CPU, Platten, Netzwerk & serielle Konsole läuft - keine Ahnung welche Wunder-Hardware 1&1 da angeblich verbaut hat. Laut lspci ist das nix Extravagantes. Hier läuft alles.
  4. Max
    Eben, hab nämlich die gleiche lspci ausgabe. und nach super aktueller hardware sieht das sowieso alles nicht aus^^ Dann werde ich die umstellung heute nacht auch mal vornehmen... werde dann berichten ;)
  5. Max
    Soweit so gut, er bootet, alles geht. Eine Sache ist mir beim booten nich ganz geheuer (außer, dass er nach starting pop3d für 2 minuten hängt (ich mich aber via SSh einloggen kann etc) .. aber er hat vorher auch schon recht lang gebraucht.. und dem gazen plesk mist traue ich nicht ;) ) ip6_tables: (C) 2000-2006 Netfilter Core Team 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 eth-id-00:19:99:07:1b:ee No interface found failed Setting up service network . . . . . . . . . . . . . . failed Failed services in runlevel 3: network nun muss ich ehrlich gestehen, ich hab schon so manchen kernel gebaut und auch schon einige (virtuelle) network interfaces verunstaltet. (allerdings meist unter debian) Aber damit weiß ich nicht wirklich etwas anzufangen, zumal ja alles geht. Kannst Du damit etwas anfangen? Dann noch eine ganz andere Sache. Die meisten der in letzter Zeit aufgetretenen Null Pointer Deref Lücken sind ja erst mit 2.6.31 gefixt. Nun Pflegen distributoren ja normalerweise sicherheitsupdates auch in alte kernel ein. Aber das macht mir Sorgen: s15313878:~ # uname -a Linux s15313878 2.6.25.20-0.5-default #1 SMP 2009-08-14 01:48:11 +0200 x86_64 x86_64 x86_64 GNU/Linux Der Kernel ist vom 14.8. ?? Da waren die meisten der aktuellen Lücken ja nichtmal bekannt, oder? ;) und warum er mir 3 mal erzählt, dass es ein 64 bit kernel ist, ist mir auch schleierhaft...^^
  6. Max
    Ahhh... cp: `/etc/sysconfig/network/ifcfg-eth0' and `/etc/sysconfig/network/ifcfg-eth-id-00:19:99:07:1b:ee' are the same file ich vermute das hängt damit zusammen... brauche ich mir also keine sorgen machen ?;)
  7. Max
    sorry für das ganze rumgespamme hier.... eine anmerkung noch, was mich vermuten lässt das die meldung überwichtig nicht sein kann: s15313878:/etc/sysconfig/network # cat ifcfg-eth-id-00\:19\:99\:07\:1b\:ee BOOTPROTO='dhcp' STARTMODE='onboot' s15313878:/etc/sysconfig/network # cat ifcfg-eth0 BOOTPROTO='dhcp' STARTMODE='onboot' also kompliziert ist die config zumindest nicht.... -.- ^^
  8. Marcel
    Hi Max, das ist alles OK. /etc/sysconfig/network/ifcfg-eth-id-MACADRESSE ist ein Symlink auf die Datei /etc/sysconfig/network/ifcfg-eth0, deshalb steht in beiden auch das gleiche drin ;-) Die Datei /etc/sysconfig/network/ifcfg-eth-id-MACADRESSE kannst Du gefahrlos löschen. Für openSUSE sind das 2 Konfigurationseinstellungen: einmal für das Interface eth0 und einmal für das Interface eth-id-MACADRESSE. Das Interface eth0 ist vorhanden und wird per DHCP konfiguriert. Ein Netzwerkinterface eth-id-MACADRESSE gibt es aber nicht, deshalb meckert openSUSE zu Recht darüber:
    eth-id-00:19:99:07:1b:ee No interface found
    Ich weiß nicht wer diesen Symlink anlegt, ob es SUSE ist oder Plesk. Auf jeden Fall kann der gelöscht werden - stört aber auch nicht, wenn er weiter da rumgammelt :-) Und das Plesk beim Booten gerne mal bisschen länger dauert, ist auch nix neues.
  9. Max
    Ah wunderbarst ;) sehe es gerade, die ifcfg-eth0 ist ein symlink auf die ifcfg-eth-id-MAC ... ich lasse mal beide da... wie ist denn die kernel updatepraktik bei suse generell? Neue Kernel Version nur mit neuem Release, aber warum ist der Kernel von 11.0 immernoch vom 14.08.? Das klingt unsicher^^ Danke nochmal, schöner guide, nette Hilfe :)))
  10. Marcel
    Am 14.08. wurde ein Bug im Linux-Kernel veröffentlicht: Heise: Kritische Lücke im Linux-Kernel betrifft alle Versionen seit 2001 Zitat aus http://lists.opensuse.org/opensuse-security-announce/2009-11/msg00003.html bzgl. der aktuellen Sicherheitslücke:
    openSUSE 11.0 openSUSE 11.1 Are affected by this problem, but the exploit can not be used to execute code, just to cause a crash / "Oops". The kernel is using the MMAP null page exploit protection by default and so the exploit is not effective (will just lead to a Ooops). You can verify the protection to be enabled by doing: cat /proc/sys/vm/mmap_min_addr A value larger than 0 means "enabled".
    Gruß, Marcel.
  11. Max
    Huch, verdammt dann hab ich das völlig in den falschen Hals bekommen. Ich war der festen Überzeugung dass mmap_min_addr unter openSUSE standardmäßig deaktiviert ist. so kann man sich täuschen. Danke Dir! :)