Category Archives: Erfahrungsberichte

Erfahrungen aus dem Alltag eines Linux-Anwenders

Erster Check Opensuse 12.3

Posted on by

Der Artikel ist wegen eines laufenden arbeitsintensiven Projektes zwar schon etwas veraltet, aber vielleicht interessiert meine Erfahrungen mit dem Upgrade auf Opensuse 12.3 doch noch jemanden – zumal sie sehr positiv ist und SuSE ein Lob verdient:

Ich war mutig und habe inzwischen auf gleich drei Systemen ein Upgrade von Opensuse 12.2 auf Opensuse 12.3 vorgenommen. Das ging auf 2 Opensuse 12.2 Systemen (fast) wie geschmiert. Ich habe selten ein so problemfreies Upgrade wie auf diesen Systemen erlebt!
Auf einem dritten System (alter Laptop mit Nvidia FX 1500M-Karte gab es größere Probleme mit Nvidia-Treibern – sowohl unter Windows als auch unter Linux). Die ließen sich durch das Zuschalten des Nvidia-Community-Repositories für Opensuse 12.3 lösen. Das wars dann aber auch schon.

Upgrade eines einfachen Server-Testsystems

Das erste System war ein rel. schlankes Testsystem mit einem aktuellen Opensuse 12.2, vielen Server-Komponenten (LAMP, LDAP, KVM, …) und KDE 4.9 – ohne weitere Updates aus anderen Zusatzrepositories – also nur mit Paketen aus dem OSS_Update-Repo von SuSE und dem KDE-Repository. Bzgl. der Grafik-Karte lief vor und nach dem dem Upgrade der Nouveau-Treiber mit einer GTX9800+.

Zu diesem System gibt es hinsichtlich des Upgrades fast nichts zu sagen:

CD rein, 1920×1200-Auflösung und deutsche Sprache wählen, Partition mit dem upzugradenden 12.2-System auswählen, Start drücken und (im falle meiner Paketzusammenstellung) ca. 6,5 GB installieren lassen. Was die SuSE-Installationsroutine dann an Schritten durchführte, ging ohne jede Schwierigkeiten über die Bühne.

Als Bootloader wurde ein vorhandenes Grub2 upgedated. Während der Installation führte die Installationsroutine auf diesem System einen expliziten Neustart durch, bevor die Installation dann in einer zweiten Phase regulär beendet wurde.

Es wurde im Gegensatz zu früheren Installationen auf diesem System kein Kernelstart mit kexec versucht. Es gab vor und nach dem Neustart zu meiner Überraschung und im Gegensatz zu Opensuse 12.1/12.2 keinerlei Schwierigkeiten mit der Grafikkarte und dem Nouveau-Treiber. (Vielleicht sollte der SuSE-Installer das kexec-Spielchen in Zukunft ganz unterlassen?)

Der KDE-Desktop erschien schließlich im neuen SuSE-Layout, Kontact lief mit seinen Anbindungen an 2 Imap-Server (einer im lokalen Netz, einer extern) und an 2 Open-Xchange-Server (OX5, OX6, beide im lokalen Netzwerk) problemfrei. Alles im grünen Bereich. Auch die Nachinstallation eines geeigneten Treibers von der NVidia-Webseite bereitete keine Probleme.

Danach habe ich KDE auf 4.10 upgegradet sowie meine anderen üblichen Repositories geladen und entpr. Updates durchgeführt. No problem – außer den üblichen internen KDE-Themen.

Upgrade eines produktiven Entwicklungs-Systems mit etlichen Serverkomponenten

Ein wenig hakeliger lief es mit einem anderen System, das eine andere Nvidia-Karte (GTX 460) beherbergt und sich bereits auf dem Stand von KDE 4.10.1 befand. Auch hier lief alles glatt bis zum Neustart des Systems. Der wurde hier mit kexec versucht, was nach früheen Erfahrungen fast erwartungsgemäß schief ging. Irgendwie hat auf diesem System das Umschalten der Grafik-Modi mit dem Nouveau-Treiber noch nie geklappt. Es taucht noch die Meldung auf “Der Kernel wird mit kexec geladen”. Dann kommt noch “rcnscd: no such service nscd”. Anschließend reagiert der Schirm nicht mehr. Ich kenne dieses Verhalten seit Opensuse 12.1 auf verschiedenen Systemen. Irgendwie habe ich den Eindruck, dass das bei mir immer dann passiert, wenn vor dem Upgrade eines Systems der proprietäre Nvidia-Treiber von der NVidia-Webseite der aktive war. Irgendwie bekommen SuSE’s Upgrade-Routinenn dann den Wechsel zum Nouveau-Treiber nicht hin.

Das System läuft trotz
eingefrorenem Schirm allerdings weiter und installiert auch brav weiter. Man lausche ein wenig auf die Festplatten (soweit noch vorhanden und nicht durch SSDs ersetzt), warte bis die Aktivitäten aufhören und probiere dann mal CTRL-ALT-DEL. In meinem Fall half das. Das System fuhr runter, startete neu, zeigte mir ein Grub1 im neuen dunklen Opensuse-Look und ließ mich dann das neue OS 12.3-System (Desktop-Kernel) hochfahren. (Netterweiser gibt es im Grub1-menü auch eine Verzweigung in ein Grub2-Menü).

Auf diesem System erscheinen dann, wenn man die Startmeldungen von systemd und den LSB-Init-Skripten verfolgt (CTRL-ALT-F1), Fehlermeldungen zum Start von VMware (logisch, das muss ja erst neu kompiliert werden). Und dann stoppt der Prozess des Hochfahrens beim Versuch, die grafische Oberfläche zu starten.

Ein “CTRL-Alt-F2” bringt mich allerdings auf ein nutzbares Konsolenfenster. Von dort kann ich sshd starten. Dann kopiere ich mir von einem anderen Rechner per “scp” einen aktuellen Nvidia-Treiber aufs System. Achtung: Bei mir ging mit dem Kernel 3.7.10 nur die Version 310.40 des Nvidia-Treibers. Ältere Versionen bringen im Zuge der Nvidia-Installationsroutine Fehlermeldungen zu fehlenden Header-Dateien. Zur Sicherheit setze ich als Kernelparameter über YaST “nomodeset”, installiere den NVidia-Treiber und starte das System neu.

Alles läuft – die grafische Oberfläche von SuSE erscheint. Das gesamte System ließ sich dann anstandlos über diverse Repositories hinsichtlich aller Desktop- und Server-Komponenten (LAMP-Entw.-System) auf den neuesten Stand bringen und läuft nun unter KDE 4.10.2. VMware-Workstation musste ich auf die Version 9.0.2 bringen, damit die sich für den neuen Kernel kompilieren ließ. Jetzt laufen auch Win XP und Win 7 wieder im Fenster mit. Mit virtuellen Linux-Maschinen unter einem upgedaten KVM hatte ich keinerlei Probleme.

Etwas unangenehme Schwierigkeiten bereitet mir auf diesem System gerade eine vorhandene Open-Xchange 6.22-Installation. Der OX 6.22 Daemon lässt sich seit den letzten Paketupdates auf meinem System nicht mehr mit systemd (“systemctl start open-xchange”) oder “rcopen-xchange” starten. Es hilft nur ein Wechsel in das Verzeichnis /etc/init.d und dort ein manueller Start mit “./open-change start”. Das Problem ist sowohl an Open-Xchange wie auch Novell gemeldet (https://bugzilla.novell.com/show_bug.cgi?id=813767). Das Server-Backend von OX 6.22. läuft übrigens trotzdem – von Kontact aus kann man problemfrei zugreifen. Nur die OX6-Web-Dienste gehen nicht ohne den Workaround des manuellen Starts mit “./open-xchange start”.

Upgrade eines alten Dell-M90-Laptops mit alter Nvidia FX 1500M Quadro

Opensuse 12.3 habe ich auf diesem System von Opensuse 12.1 aus upgegraded. Das lief problemfrei – bis auf den Nvidia-Treiber. Meine übliche Strategie, einen Treiber von der Nvidia-Web-Seite zu nehmen, funktionierte hier gar nicht. Der Treiber 310.40 unterstützt die alte Karte nicht mehr – ältere Treiber melden dagegen Probleme mit Header-Dateien. Hier ist Nvidia offenbar zu faul, noch was für Besitzer älterer Karten in Hinblick auf 3-er Kernelversionen von Linux zu tun. Als hilfreich und zeitsparend erwies es sich dann, auf die Treiber des Opensuse Nvidia-Repositories zurückzugreifen. Der im Paket “nvidia-gfxG02-kmp-desktop” enthaltene Treiber funktioniert anstandslos mit der Quadro FX 1500M. Alle anderen Systemkomponenten des alten Dell M90 wurden durch Opensuse 12.3 anstandslos, auf Anhieb und perfekt unterstützt. Super!

Ich möchte ausdrücklich sagen, dass ich auf diesem Laptop-System aus Projektgründen auch Windows 7 (64Bit) als Dual-Boot-Option installieren musste. Win 7 (64Bit) bootet zugegebenermaßen zwar rasch und ist insgesamt spürbar schneller als XP – aber die Installation erwies sich hinsichtlich von Treibern als viel, viel größeres Problem als das Linux-Upgrade.

Ich musste Zusatztools installieren, um überhaupt an
geeignete Treiber für etliche Systemkomponenten zu kommen. Die Windows-Installation (natürlich ohne Serverkomponenten) kostete mich insgesamt etwa doppelt so viel Zeit wie der Opensuse 12.3 Upgrade. Und – ehrlich – der Windows 7 Desktop wirkt nicht nur langweilig – er ist es gegenüber modernen Linux-Desktops auch. Man muss sich die Tortur mit Windows doch immer mal wieder antun, damit man wieder mal weiß, was man an einem modernen Linux-System hat!

Opensuse 12.2 – textbasierter Boot Screen ohne Plymouth Animation

Posted on by

Leider ist unter einem aktuellem Suse oder Red Hat System Plymouth so stark in das Gespann grub2 und systemd integriert, dass ich mich eher davor hüte, alle Plymouth bezogenen Pakete zu deinstallieren. Nebenbei: Inzwischen ist wohl auch unter Ubuntu eine starke Einbindung von Plymouth in die Prozesse beim Systemstart vorgenommen worden. Siehe: http://ubuntuforums.org/showthread.php?t=1457388

Dennoch kommt ab und zu der Wunsch auf, den animierten Plymouth-Splash-Screen während des Boot-Vorgangs los zu werden, um ohne Umwege die Boot-Meldungen sehen zu können. Diesen Wunsch hatte zumindest ein Admin, der mich vorgestern per Mail anschrieb.

Auf meinen Opensuse 12.2-Systemen mit Grub2 half hier folgendes Vorgehen:

Deaktivieren des animierten Plymouth-Boot-Screens mit Hilfe von YaST2

Man öffne unter YaST2 das Modul “Boot Loader”. Im sich öffnenden Fenster gehe man zum Button “Boot Loader Options”. Das nächste Fenster zeigt eine Zeile zu Kerneloptionen:

no_plymouth_600

In dieser Zeile setzt man

splash=0

ein. Zudem entfernt man ein evtl. vorhandenes Schlüsselwort “quiet”. In Fall meines betrachteten Systems lautet die fertige Zeile dann:

video=1920×1200 resume=/dev/disk/by-id/scsi-3600050e004a669001c4b00002aaf0000-part1 splash=0 showopts

Auf anderen Systemen wird natürlich das Resume-Device für den Swap-Bereich eine andere Bezeichnung haben. Danach schließt man sukzessive die YaST2-Fenster.

YaST2 speichert die eben angegebenen YaST2-Bootloader-Daten übrigens in der Datei “/etc/default/grub” ab. Es lohnt sich, bei Gelegenheit mal einen Blick in diese Datei zu werfen! In dieser Datei kann man Basisoptionen für Grub2 hinterlegen. Auch ganz ohne YaST2, wenn es ein muss.

Auf dem hier veränderten System sieht die Datei dann so aus:

GRUB_DISTRIBUTOR=openSUSE
GRUB_DEFAULT=saved
GRUB_HIDDEN_TIMEOUT=0
GRUB_HIDDEN_TIMEOUT_QUIET=true
GRUB_TIMEOUT=300
GRUB_CMDLINE_LINUX_DEFAULT=” video=1920×1200 resume=/dev/disk/by-id/scsi-3600050e004a669001c4b00002aaf0000-part1 splash=0 showopts”
# kernel command line options for failsafe mode
GRUB_CMDLINE_LINUX_RECOVERY=”showopts apm=off noresume edd=off powersaved=off nohz=off highres=off processor.max_cstate=1 nomodeset x11failsafe”
GRUB_CMDLINE_LINUX=””
# Uncomment to enable BadRAM filtering, modify to suit your needs
# This works with Linux (no patch required) and with any kernel that obtains
# the memory map information from GRUB (GNU Mach, kernel of FreeBSD …)
#GRUB_BADRAM=0x01234567,0xfefefefe,0x89abcdef,0xefefefef
# Uncomment to disable graphical terminal (grub-pc only)
GRUB_TERMINAL=gfxterm
# The resolution used on graphical terminal
# note that you can use only modes which your graphic card supports via VBE
# you can see them in real GRUB with the command "vbeinfo"
GRUB_GFXMODE=auto
# Uncomment if you don’t want GRUB to pass "root=UUID=xxx" parameter to Linux
#GRUB_DISABLE_LINUX_UUID=true
# Uncomment to disable generation of recovery mode menu entries
#GRUB_DISABLE_LINUX_RECOVERY=true
# Uncomment to get a beep at grub start
#GRUB_INIT_TUNE="480 440 1"
GRUB_THEME=/boot/grub2/themes/openSUSE/theme.txt
GRUB_BACKGROUND=/boot/grub2/themes/openSUSE/background.png

Die dortigen Infos werden dann von einem der Scripts unter /etc/grub.d aufgegriffen, sobald YaST2 im Hintergrund
zusätzlich
grub2-mkconfig -o /boot/grub2/grub.cfg
ausführt, um die eigentliche grub2-Konfigurationsdatei unter /boot/grub2/grub.cfg erstellen zu lassen. Dort findet man die getroffenen Einstellungen letztlich natürlich auch wieder.

Bootet man nun neu, fährt das System dann schön im Textmodus hoch und man kann einen Blick auf die schnell vorbeiziehenden Meldungen von systemd und den gestarteten Applikationen zum Bootvorgang werfen.

——–
Drei ergänzende Hinweise

Hinweis 1:Grub 2
Nebenbei haben wir mal wieder gelernt, dass Grub2 relativ kompliziert – nämlich teils über die über die “/etc/default/grub”, teils über Script-Dateien – zu konfigurieren ist. Hierzu ein paar Links;
http://www.dedoimedo.com/computers/grub-2.html
http://doc.opensuse.org/documentation/html/openSUSE/opensuse-reference/grub2.html
http://manual.siduction.org/de/sys-admin-grub2-de.htm

Hinweis 2: Etwas Tipparbeit beim Umgang mit grub2 sparen
Übrigens (off topic):
Um beim Experimentieren mit Grub etwas Tipparbeit zu sparen und eine Ähnlichkeit mit (älteren) Debian-Derivaten herzustellen, kann man sich unter SuSE einen abgekürzten Befehl “update-grub” als Skript (an geeigneter Stelle im Suchpfad) hinterlegen:

#!/bin/sh
set -e
exec grub2-mkconfig -o /boot/grub2/grub.cfg “$@”

Wer sich über das “$@” wundert: grub2-mkconfig hat z.Z. zwar nur 3 Parameter, kann ja aber künftig noch mehr bekommen:

mysystem:~/bin # ./update-grub -v
grub2-mkconfig (GRUB2) 2.00
mysystem:~/bin # ./update-grub -h
Usage: grub2-mkconfig [OPTION]
Generate a grub config file
 
-o, –output=FILE output generated config to FILE [default=stdout]
-h, –help print this message and exit
-v, –version print the version information and exit
 
Report bugs to <bug-grub@gnu.org>.
mysystem:~/bin #

Hinweis 3: Kein graphischer Grub2-Bildschirm
Übrigens: Will man neben Plymouth auch den grafischen Grub2-Schirm loswerden, so muss man im oben dargestellten YaST2-Fenster den Haken bei der Option “use graphical console” entfernen. Dies führt dann zu einem Eintrag “GRUB_TERMINAL=console” in der “/etc/default/grub”.

OX 6 – Upgrade von OX 6.20.7 auf OX 6.22.1 unter OS 12.2

Posted on by

Habe mich seit längerem nicht mehr um Upgrades des bei mir unter Opensuse 12.2 laufenden OX 6 kümmern können. Mein letzter Schritt war im letzten Jahr ein Update auf die Version 6.20.7 gewesen. Seitdem hat sich doch einiges geändert und demnächst steht auch die OX 7 App Suite vor der Tür.

Mögliche Upgrade-Pfade

Laut den Infos auf den einschlägigen Open-Xchange Webseiten sind folgende Upgrade-Pfade vorgesehen:

  • v6.20.7 auf v6.22.0 (man beachte die 0 bei der 6.22-er version!)
  • v6.22.x auf OX App Suite 7

Siehe hierzu:
http://oxpedia.org/wiki/index.php?title=Update_to_6_22
http://oxpedia.org/wiki/index.php?title=AppSuite:Upgrade_from_6.22_for_SLES11

Alle Wege führen also zwingend über die Version 6.22.0 !

Version 6.22 klingt harmlos. Diese Applikation bringt allerdings gegenüber den Versionen 6.20.X wesentliche Neuerungen mit sich. Insbesondere die Aufsplittung der Repositories für Server-Komponenten und das Ajax-Frontend. Zudem werden die bisher 2 Dämonen zum Starten des OX6-Systems zu einem zusammengefasst. Es verschwinden auch etliche der vielen bisherigen Pakete. Offenbar werden hier Änderungen vorgenommen, die in eine noch stärkere Rollenaufteilung zwischen einem komponentenbasierten Backend und mehreren unterschiedlich ausgeprägten Frontends in der App Suite münden werden.

Das machte mir dann doch ein wenig Angst vor einem Update des OX6 unter Opensuse 12.2. Die zugehörigen Infos in den OX-Webseiten entsprechen mehr denen eines echten Upgrades als eines kleineren Updates. Aber die nachfolgende Abbildung beweist, dass alles am Schluss glatt lief. Gezeigt wird der Blick von Kontact/Korganizer auf Kalender-Einträge auf meinem OX6 v6.22.1.

ox622_cal_600

Dennoch gab es ein paar kleinere Hürden zu überwinden, auf die ich nachfolgend eingehe.

Fehlendes Opensuse 12.2 Repository für die als Zwischenschritt erforderliche OX-Version 6.22.0

Unter den Repositories für Opensuse 12.2 findet man zwar bereits ein Verzeichnis für die App Suite. Das enthält aber noch keine Dateien. Also wollte ich auf meinem Opensuse 12.2-System zunächst nur das sowieso erforderliche Upgrade auf die Version v6.22 vornehmen.

Nun drohte dieses Vorhaben daran zu scheitern, dass sich im Moment kein Opensuse 12.2 Repository mit RPMs zur OX Version 6.22.0 mehr finden lässt. Vorhanden ist nur ein Repository zur Version v6.22.1. Dorthin führt aber z.B. von OX 6 V6.20.7 kein direkter Weg !

Umweg über ein 6.22.0 Repository für den SLES 11

Ich habe dann notgedrungen das Experiment gewagt, ein Repository für den SLES 11 zu benutzen. Ein solches Vorgehen ist nicht risikofrei. Bevor andere das nachmachen, empfehle ich unbedingt ein Backup der OX6 Datenbank auf seinem MySQL-Server, ein Backup der OX6-Verzeichnisse auf dem Apache-Server und ein Backup der OX6-Dateien – bei mir unter “/opt/open-xchange”.

Das von mir genutzten SLES11-Repositories findet man unter:
OX 6.22.0 Backend: http://software.open-xchange.com/OX6/6.22/6.22.0/backend/SLES11/
OX 6.22.0 Frontend: http://software.open-xchange.com/OX6/6.22/6.22.0/
frontend/SLES11/

Diese Repositories bindet man in die Paket-Verwaltung unter YaST2 ein. Unter YaST2’s Software-Update-Modul wechselt man dann am besten in die Ansicht für die “Installationsquellen”. Dort prüfe man für das Repository zum OX6-Backend und im Repository zum Frontend, welche Pakete als update-fähig angezeigt werden und hake die Einträge entsprechend ab. (Weiter unten findet man 2 Listen zu den erforderlichen Paketen). Man wundere sich beim Auflösen der Paketabhängigkeiten durch YaST2 nicht, dass dann sehr viele alte Pakete für als zu löschen markiert werden. Das hat tatsächlich seine Richtigkeit!

Ändern des OX6-Daemon-Starts über den Run-Level-Editor

Nachdem der Update gelaufen ist, muss man den Start des OX6-Daemons ändern. Die ursprünglich 2 Dämonen für die OX6-Groupware und die OX6-Administration sind nun zu einem Dämon zusammengezogen worden. Man nimmt die Änderungen am schnellsten über den YaST2-Runlevel-Editor vor. Ja, das geht auch unter den neuen systemd-Verhältnissen. YaST2 übersetzt die alten sysvinit-Angaben für diese konventionellen LSB-Applikationen unter systemd schon passend:

update_ox622_daemon_600

Nach dem Update funktioniert der OX6-Login über die Web-Oberfläche erstmal nicht – 503-Fehler

Hat man den OX6-Groupware-Server dann erneut gestartet, darf man sich ein kleines Frustrationserlebnis abholen. Versucht man sich nach den bisherigen Operationen auf dem OX6-Server über die OX6-Weboberfläche einzuloggen, so geht das schief. Egal, welchen User man probiert, man erhält eine “503-Meldung”: “Service temporarily not available”.

Zusätzlich tauchen in den OX6-Logs Fehlermeldungen zu fehlenden Sprachfiles auf.

Bevor du nun das Fluchen anfängt:
Prüfe erstmal, ob die Anbindung der Kalender-Clients unter OX6 funktioniert! Von dort klappt nämlich die Anbindung zum backend anstandslos, wie ich überrascht feststellen musste. So schlimm konnte der Fehler also nicht sein. Einige Minuten später stellte sich nach einem Blick auf den Webserver folgendes heraus:

Der Fehlschlag mit der OX6-Web-GUI liegt daran, dass für das 6.22-Frontend neue Pakete installiert werden müssen! Sieht man sich unter den OX6-Verzeichnissen seines Apache-Servers mal die Datumsangaben der installierten OX6-Files an, so wird man feststellen, dass der bisherige, oben beschriebene Update-Prozess die HTML- und Javascript-Files der früheren 6.20-Installation nicht angetastet hat. Der alte Client passt aber schlicht nicht zum neuen Backend! Wir korrigieren dieses Problem gleich im Zuge eines Upgrades auf die Version 6.22.1!

Upgrade auf die Version OX 6.22.1

Wir deaktivieren unter YaST2’s Paketverwaltung nun die OX 6.22.0-Repositories. Zusätzlich binden wir die aktuellen OX6-Repositories für OS 12.2 ein:

http://download.opensuse.org/repositories/server:/OX:/ox6.22:/frontend/openSUSE_12.2/
http://download.opensuse.org/repositories/server:/OX:/ox6.22:/backend/openSUSE_12.2/

Und nun stellen wir folgende Listen an Paketen für den Upgrade zusammen:

OX6-Backend (V6.22.1)
update_ox622_backend_600

Hier kommt zu den bisherigen Paketen eines für
die “de_DE”-Sprachunterstützung des Backends hinzu: open-xchange-l10n-de-de.

OX6-Frontend (V6.22.1)
update_ox622_frontend_600

Dies sind etliche Pakete mehr als beim Upgrade zu v6.22.0 ! Am wichtigsten ist das Paket “open-xchange-gui” ! Hinzu kommen Pakete zur deutschen Sprachunterstützung sowie zu Hilfe-Funktionen. Benötigt werden außerdem separate Pakete für die E-Mail-Account-Verwaltung und Plugin-Wizards:

open-xchange-gui-help-plugin, open-xchange-gui-help-plugin-gui, open-xchange-gui-l10n, open-xchange-gui-l10n-de-de, open-xchange-online-help-de-de, open-xchange-gui-themes-default, open-xchange-gui-loading-theme-default, open-xchange-gui-login-theme-default, open-xchange-gui-mail-accounts-plugin, open-xchange-gui-wizard-plugin, open-xchange-gui-wizard-plugin-gui

Man führe dann per YaST2 den Update zu diesen Paketen durch. Ein kurzer Blick auf den Webserver zeigt danach, dass dort jetzt aktuelle OX6-Web-GUI-Files mit einem neueren Datum vorliegen. Ferner ist jetzt auch das Verzeichnis “/opt/open-xchange/i18n” gefüllt.

Und jetzt klappt endlich auch der Web-Login für den OX6!

ox622_mail_600

Das Bild zeigt den Zugriff auf einen (separaten) IMAP-Server über den OX6! Der WE-GUI-Zugriff auf die im OX6 selbst verwalteten Kalender-Einträge, Aufgaben, den Infostrore, etc. funktionierten bei mir ebenso völlig anstandslos wie der Rest der upgedateten Web-GUI!

Ich musste nur bei einem einzigen User in die Datenbank eingreifen und dort den Email-Account für die Unified Mail (“unifiedinbox”) löschen. Bevor ich das tat, verweigerte OX6.22 für diesen speziellen Account jegliche Mail-Anzeige und deaktivierte das Mail-Modul. Die Ursache blieb unklar; aber das war mir auch egal, da dieser lokale Account sowieso nicht benutzt wurde. Bei keinem anderen User trat ein solches Problem auf!

Erfolgreicher Check des OX6-Zugriffs mit Kontact-Komponenten von KDE 4.10

Bleibt abschließend nur, den Zugriff von Kontakt/Organizer und vom Kontact/Addressbook (eiens aktuellen KDE 4.10) auf den OX6.22 zu prüfen. Der Zugriff läuft über Akonadi und da ist man bekanntlich nie vor Überraschungen gefeit.
Aber: Alles funktionierte auf Anhieb und ohne jede Änderungen oder Eingriffe. Der OX6-Konnektor von Akonadi funktioniert also auch mit OX 6.22.1 ! Interessant, dass auch die “Address Auto Completion” von Kmail 4.10 beim Zugriff auf das OX6-Adressbuch keine größeren Zicken machte. Soweit ich sehen kann, werden die vorhandenen Adressen genauso gut (oder schlecht) wie zuvor angezeigt. Sehr gut funktionierte CUH der Web-Dav-Zugriff auf die Verzeichnisse des InfoStore über Dolphin!

Geht doch !

Der Linux-Blog läuft endlich nicht mehr als 1&1 Applikation

Posted on by

Jahrelang habe ich meinen Linux-Blog als 1&1-Applikation genutzt. Das war am Anfang bequem, entpuppte sich aber mehr und mehr als Dummheit. Für den wachsenden Unmut waren folgende Gründe ausschlaggebend:

  • Man war bei 1&1 auf vorgefertigte und z.T. nicht fehlerfreien 1&1 Layouts begrenzt.
  • Das Verzeichnis mit den WordPress-Programm-Dateien war nicht zugänglich. Damit hatte man auch keinen Zugriff auf die Konfigurationsdatei.
  • Man kam nicht an die in irgendwelchen 1&1-Datenbanken hinterlegten Daten heran.
  • Es gab keine Export-Funktion in der von 1&1 beschnittenen Blog-Verwaltung.
  • Man konnte die Subdomaine/Domaine, unter der der 1&1-Blog eingerichtet war, nicht ohne ein gleichzeitiges Löschen aller Blog-Inhalte auf ein anderes Server-Verzeichnis legen.

Das alles waren Einschränkungen, mit denen 1&1 eine Kundenbindung erzwang. Ein einfacher Wechsel des Providers oder auch nur eine Übernahme des Blogs in selbst verwaltete Datenbanken und Webserver-Verzeichnisse war praktisch ausgeschlossen, weil das immer mit einer Aufgabe des Blogs und einem Verlust der Daten verbunden gewesen wäre. Nun konnte ich aber die von 1&1 zur Zeit systematisch vorgenommene Umstellung auf eine neuere WordPress-Version nutzen, um mich endlich ein wenig unabhängiger zu machen.

Das war auch bitter und dringlichst notwendig. Denn die heute von 1&1 vorgenommene sogenannte “Umstellung” erwies sich als nicht gelungen; 1&1 hat bei der Migration des Blogs offenbar wenig Wert auf ein sauberes Vorgehen gelegt:

  • Kein adäquates Layout mehr nach der “Umstellung”:
    Ich hätte erwartet, dass das von 1&1 früher angebotene und von mir vor Jahren gewählte Layout vorab überarbeitet und an die aktuelle WordPress-Version angepasst worden wäre. Man möchte seinen Blog nach einer Migration natürlich wieder mit dem Aussehen vorfinden, zu dem 1&1 einen früher verführt hatte. Weit gefehlt: Nach der Migration fand ich meinen Blog statt in dem früher von mir gewählten Layout im öden blauen WP-Basis-Layout vor. Und keines der früheren 1&1-Layouts war im Theme-Angebot zu finden.
  • Englisch als Standardsprache:
    Das zweite Übel bestand darin, dass die Sprache auf Englisch umgestellt worden war und dass die Datenbank nun unter UTF8 läuft. Leider war dies in den migrierten Datenbankdaten nicht nicht überall berücksichtigt worden. Das verhunzte u.a. alle Kategorie-Namen, die Umlaute enthalten hatten. Die Kategorie-Bezeichnungen wurden ab dem ersten Umlaut schlicht abgeschnitten.
  • Alle Posts waren nach der Migration für eine Kommentierung freigegeben:
    Noch viel schlimmer bewerte ich die Tatsache, dass das Spamaufkommen zu meinem Blog etwa 1 Stunde nach der Umstellung von 161 abrupt zunahm. Ursache hierfür war, dass das früher eingestellte Verbot einer Kommentierung von Artikeln nach der 1&1-Migration aufgehoben war.

Diese Art der Umstellung erfolgte wie gesagt heute und hatte mir erstmal einen kleinen Schock versetzt. Mein IMAP-Server füllte seinen Spam-Ordner und der Blog sah schlicht furchtbar aus. Das mochte ich meinen Lesern nicht zumuten.

Nachdem ich einen ersten Wutanfall überwunden hatte, habe ich dann den heutigen Nachmittag genutzt, um den Blog unter meine eigenen Fittiche zu bekommen. Vielleicht haben einige meiner Leser ja auch den Wunsch, sich im Zuge der “1&1-Migration” ihres Blogs sich diesbezüglich von 1&1 abzunabeln. Glaubt mir: So günstig erhaltet ihr vermutlich nie wieder die Chance, eure Daten auf einfache Weise und völlig ohne jedes Hacking in den Griff zu bekommen.

Also – nachfolgend findet ihr einen kleinen Handzettel zur

“Migration eures Blogs weg von der 1&1-Wordpress-Applikation in eine selbst kontrollierte Web-Präsenz”.

Diese selbst kontrollierte Web-Präsenz kann durchaus wieder bei 1&1 liegen – wichtig ist nur die eigene Kontrolle über die WordPress-Dateien und die WordPress-Daten (u.a. die der wertvollen Posts) in einer selbst verwalteten Datenbank.

Zur Vorbereitung der Migration habe ich mir zunächst genauer angesehen, ob ich die Daten meines Blogs nicht mit den Standardfunktionen der neuen WordPress-Version exportieren könnte. Ja das ging; das war von 1&1 diesmal nicht abgestellt. Also hatte ich nun schon mal eine XML-Datei meiner Daten als letzten Notanker. Leider musste ich dann feststellen, dass ein Import in einen kurzfristig installierten eigenen WordPress-Blog nicht funktionieren wollte. Vielleicht weil das Import-Plugin nicht mit der aktuellen WordPress-Version zusammenspielt (s. hierzu auch: http://blog.trisepo.com/archives/61/ ) oder weil der Import in meinem Fall alle gesetzten PHP- und MySQL-Zeitlimits auf den 1&1-Servern überstieg. Letzteres war und ist in meinem Fall mehr als wahrscheinlich.

Dann habe ich mir angesehen, auf welches Verzeichnis die Subdomaine meines 1&1-Blogs nach der Migration umgelenkt wurde. Und oh Wunder: Dieses Verzeichnis war zumindest für eine Weile in den Serververzeichnissen meines Hosting-Paketes bei 1&1 zugänglich! Damit hat man dann schon fast gewonnen:

Schritt 0: Man führe als allererstes eine Sicherung des gesamten neuen WordPress-Verzeichnisses durch. Danach studiere man die WordPress-Konfigurationsdatei “wp-config.php” des Hauptverzeichnisses. Die dort angegebenen Daten sind in zweierlei Hinsicht bedeutsam:

Erstens werden die Verbindungsdaten zur Datenbank angegeben, auf die 1&1 den Blog nun migriert hatte. Diese Datenbank ist ja nicht unter den normalen Banken zu finden, die dem eigenen 1&1-Paket zugeordnet sind. Damit sind sie auch nicht über die 1&1-MySQL-Verwaltung zugänglich. Zweitens enthält die Datei wichtige Angaben zu den Verschlüsselungsverfahren, die 1&1 zum Hashen der Passwörter verwendet. Diese Daten sind sehr wichtig, wenn man bei der Abnabelung Probleme mit den Passwörtern vermeiden will.

Die nächsten Schritte zur Abkopplung von der 1&1-Wordpress-Applikation sind dann folgende:

Schritt 1: PhpMyadmin in der eigenen Webpräsenz bei 1&1 installieren. Dort in der PhpMyAdmin-Konfiguration die Zugriffsdaten für die 1&1-Datenbank des migrierten 1&1-Wordpress-Blog eintragen. In diese 1&1-Datenbank kann man sich dann mit PhpMyAdmin einloggen. Jetzt erstmal die gesamte Bank per PhpMyAdmin-Export in eine Datei sichern und diese herunterladen. Dann erneut auf die Bank zugreifen und die Tabellen mit den angehäuften WordPress-Daten der letzten Jahre einzeln (!) exportieren.

Man tut einfach gut daran, Tabelle für Tabelle in separaten Dateien zu sichern und herunterzuladen – nicht alle Tabellen in einem einzigen Export-File. Gründe: Der spätere Import in eine selbstverwaltete Datenbank würde bei einer einzigen, großen Datei ggf. zu lang dauern und die Limit des Providers sprengen. Ferner muss man später in der Sicherungsdatei für die Tabelle der Posts per Editor die Link-Adressen aller Artikel ändern (s.u.). (Das Arbeiten an der Datei ist aus meiner Sicht jedenfalls das schnellste und einfachste Verfahren.)

Schritt 3: Download einer aktuellen (deutschen) WordPress-Version (Version 3.5.1) aus dem Web. Danach Upload der zugehörigen Verzeichnisse und Dateien in ein neues Blog-Verzeichnis auf dem gewünschten eigenen Web-Server. Aber danach bitte keine WordPress Installation vornehmen! Wir migrieren in den nachfolgenden Schritten vielmehr alle Tabellen und Daten aus der bisherigen 1&1-Blog-Installation und nutzen deren Konfigurationsdatei nach der
Durchführung erforderlicher Änderungen.

Schritt 4: Mit PhpMyAdmin eine eigene Datenbank auf einem eigenen DB-Server einrichten. Dann die vorher heruntergeladenen Sicherungsdateien der WordPress-Tabellen in die eigene Datenbank importieren. Ausnahme: Die Sicherungsdatei für die Tabelle, die die “Posts” enthält. Die erkennt man in der Regel am Namen (“…_wp_posts”). Die Namen aller anderen, durch die PhpMyAdmin-Importe erzeugten Tabelllen in der eigenen Datenbank nun durch eigene Namen ersetzen: Dies dient nur dazu, das 1&1-Tabellenprefix mit einem eigenen zu ersetzen (z.B.: myblog_wp_…. ). Die hinteren Namensanteile der Tabellen lassen wir dagegen unverändert.

Schritt 5: In den Tabellen “myblog_wp_usermeta”, “myblog_wp_options” alle erforderlichen Anpassungen vornehmen. (“myblog_wp_” ist natürlich durch den gewählten eigenen Prefix zu ersezen!) Die erforderlichen Änderungen betreffen u.a. die Rechtevorgaben an den Tabellen – man erkennt die alten Tabellen-Prefixes leicht in den entsprechenden Tabellenspalten. Diese Tabellenverweise muss man nun an die neuen Tabellen-Namen mit dem eigenen Prefix anpassen. Änderungen sind aber auch für die Domain-Angabe zum neuen, selbst verwalteten Blog erforderlich. Die bisherige Domain-Bezeichnung muss durch die Bezeichnung der künftigen (Sub-) Domaine für den neuen Blog ersetzt werden.

Wichtiger Hinweis: Man sollte dem neu eingerichteten Blog in jedem Fall so lange eine andere Domaine als die des bisherigen 1&1-Blog zuordnen, bis der neue Blog richtig läuft. Erst danach kann man den alten (Sub-) Domainnamen von 1&1 umlenken. Beachte: Eine Domain-Umlenkung und Akopplung von der 1&1-Blog-Applikation ist mit einer endgültigen Zerstörung aller Blogdaten bei 1&1 verbunden – das genau war ja deren Folterinstrument zur Kundenankettung. Und dieses Risiko nehmen wir erst nach einer erfolgreichen Blog-Migration auf uns.

Schritt 6: Editieren einer Kopie der per PhpMyAdmin erzeugten Sicherungsdatei für die Tabelle zu den Posts. Z.B. mit einem flexiblen Editor wie Kate. Kate muss dabei auf sehr (!) lange Zeilenlängen (ggf. 100000 Zeichen) eingestellt werden. Dann im File den alten Domainnamen durch den gewünschten neuen an allen vorkommenden Stellen ersetzen. Damit wird die URL der Artikel geändert. In den Statements der Datei für die Tabellengenerierung ist zudem der bisherige 1&1-Tabellennamen durch den gewünschten neuen mit dem eigenen Prefix zu ersetzen.

Schritt 7: Importieren des geänderten Files für die “Posts”-Tabelle per PhpMyAdmin in den eigenen Datenbankserver. Die erzeugte Tabelle sollte dann gleich die richtige Bezeichnung haben.

Schritt 8: In der Dateisicherung der 1&1-Wordpress-Dateien die Konfigurationsdatei “wp-config.php” ausfindig machen. Eine Kopie für Änderungen und den späteren Upload auf den eigenen Server erstellen. Diese Kopie muss nun editiert werden. U.a. muss die dortige Konfigurationsvorgabe für die Sprach-Einstellung explizit auf “de_DE” umgestellt werden. Ferner sind die neuen, eigenen Datenbankzugangsdaten einzugeben. (Gemeint ist hier natürlich die eigene Bank, auf der man den neuen Blog zum Laufen bringen will – also die Bank auf die man die Tabellen hochgeladen hat). Auch das Prefix für die Datenbank-Tabellen ist in den config-Einstellungen anzupassen. An den Verschlüsselungseinstellungen (Key- und Salt-Angaben) aber bitte nichts ändern! Das würde nämlich alle alten Passwörter unbrauchbar machen! Dann die veränderte Konfigurationsdatei unter dem Namen “wp-config.php” in das WordPress-Hauptverzeichnis der eigenen Installation hochladen.

Schritt 9: In der Datei-Sicherung des bisherigen 1&1-Blogs das Verzeichnis “wp-content/uploads” ausfindig machen. Dann ganzen Inhalt diese Verzeichnisses in das entsprechende Verzeichnis der neuen Blog-Installation hochladen. (Damit füllen wir die Mediathek des neuen
Blogs in konsistenter Weise zu den migrierten Datenbankdaten).

Schritt 10: In seiner Web-Präsenz eine (Sub-)Domaine für den neuen, eigenen Blog anlegen oder anlegen lassen. Dann diese (Sub-) Domaine auf das Verzeichnis der WordPress-Installation in der eigenen Webpräsenz lenken.

Schritt 11: Durchatmen, kurz Mut fassen und sich mit den alten Administrator-Zugangsdaten im neuen Blog unter dem (neuen) Domainnamen einloggen.

Schritt 12: Für alle alten Posts ggf. als erstes wieder die Kommentierungssperre setzen, die 1&1 während deren Umstellung aufgehoben hatte.

Schritt 13: Überprüfung und Setzen aller weiteren Einstellungen des Blogs. Wichtig ist auch hier die temporäre Umstellung der URL des Blogs unter “Einstellungen   >   Allgemein” auf die neue (Sub-) Domaine.

Schritt 14: Ändern des Layouts durch die Auswahl eines Themes, Nutzen der WordPresss Tools und durch Manipulation der CSS-Dateien des geladenen Themes. Da dieser Schritt einige Zeit in Anspruch nehmen kann, kann man ihn auch auf später verschieben.

Schritt 15: Überarbeiten der Kategoriebezeichnungen mit Umlauten, die ggf. von 1&1 während deren Blog-Umstellung zerstört worden waren.

Schritt 16: Alles sichern (Datenbanken und Dateien).

Schritt 17: Wenn der neue, selbstverwaltete Blog sauber läuft und alle Artikel inkl. Bilder und Anhängen anzeigt werden: Den alten Domainnamen bei 1&1 von der 1&1-WordPressP-Applikation lösen – dies bedeutet dann allerdings die unwiederbringliche Löschung aller alten Blog-Daten bei 1&1. Aber die hatten wir ja in den ersten Schritten bereits gesichert. Danach Zuweisung der (Sub-)Domaine zum neuen Blog-Verzeichnis, falls dieses in einer eigenen Web-Präsenz bei 1&1 liegt. Falls nicht, eine Domain-Umlenkung auf die neue Domaine vornehmen.

Schritt 18:Läuft dann auch unter dem alten Domainnamen alles wie gehabt, kann man zumindest im Fall einer Webpräsenz bei 1&1 alle Einstellungen zur Domain-URL des Blogs wieder auf die alten Einstellungen zurücksetzen. Dies geschieht teilweise durch Benutzung der Verwaltungsoberfläche “Einstellungen   >   Allgemein”, teilweise durch direkten Eintrag in die bereits genannten Datenbank-Tabellen, bzgl. der Posts aber durch Export der Tabelle in eine Datei, Überarbeiten der dortigen Adressangaben per Editor und Reimport der Tabelle.

Schritt 19: Einstellen des PING-Mechanismus unter “Einstellungen   >   Schreiben” zur Benachrichtigung von anderen Blog- und Crawler-Engines. Unter
http://www.instant-info-online.com/wordpress-compressed-all-inclusive-ping-list.html
wird zur Vermeidung von Mehrfachpings folgende komprimierte Liste empfohlen:

http://rpc.pingomatic.com
http://blogsearch.google.com/ping/RPC2
http://ping.myblog.jp

Dies liste funktioniert nach meiner Erfahrung sehr gut.

Schritt 20: Ggf. Installation eines Ping-Optimizer-Plugins zur Begrenzung des selbst verursachten Ping-Aufkommens, um beim eifrigen Bloggen nicht zum Ping-Spammer zu werden.

Und das wars dann schon. Viel Spass mit dem Bloggen unter eigener Kontrolle der erzeugten Daten.

Opensuse 12.2, systemd, 3ware 9650, Filesystem-Fehler

Posted on by

Ich habe auf einem System, das ich von Opensuse 12.1 auf Opensuse 12.2 upgegraded hatte, zweimal kurz hintereinander Probleme mit der Konsistenz des Root-Filesystems unter “ext4” bekommen.

Diese Schwierigkeiten kamen nach einigen größeren Update-Läufen, die ich nach dem Upgrade durchgeführt hatte.

Das Workstation-System beinhaltet einen LSI/3ware-Raid-Controller 9650SE mit einem Raid 10 Array. Das System hat sowohl unter Opensuse 11.4 als auch unter Opensuse 12.1 im Dauereinsatz gut und sehr performant funktioniert. Unter Opensuse 12.2 dagegen bereitet es nun leider Probleme nach Shutdowns mit PowerOff – die führen nämlich mindestens bei einer performance-orientierten Einstellung des Controllers zu Datenverlust und resultierenden Filesystem-Inkonsistenzen.

Interessanterweise konnte ich ähnliche Inkonsistenzen des Root-Filesystems trotz mehrer Anläufe und unterschiedlicher Einstellungen des Controllers nicht unter den auf dem PC immer noch vorhandenen Versionen Opensuse 11.4 und 12.1 provozieren. Das schließt RAM-Defekte praktisch aus. Man könnte nun noch auf einen Platten-Defekt in Sektoren, die die Root-Partition des Opensuse 12.2-Systems betreffen, als eigentliche Ursache tippen. Aber auch smartd zeigte keine Auffälligkeiten.

Die eine Frage ist also, wieso diese Probleme auf ein und demselben System hauptsächlich unter Opensuse 12.2 (vor allem nach umfangreichen SW-Updates) auftreten und nicht unter Opensuse 11.4 oder Opensuse 12.1.

Die andere Frage – und diese ist die für diesen Beitrag interessantere – ist, wie eigentlich systemd beim Booten mit einem inkonsistenten, korrumpierten Root-Filesystem umgeht.

Man muss sich ja selten genug mit dieser Situation auseinandersetzen – und fast hätte ich gerade wegen systemd nicht einmal gemerkt, dass ein gravierendes Problem vorlag ….

Früheres Verhalten von Opensuse bei defekten Root-Filesystemen unter System V

Man erinnere sich:

Unter System V stoppte der Bootprozess, wenn Opensuse 11.4 beispielsweise einen inkonsistenten Zustand des Filesystems entdeckte und wenn das dann automatisch gestartete “fsck” den Schaden nicht automatisch beheben wollte oder konnte. Der Admin wusste dann Bescheid, das System befand sich im Systemverwaltungs-Modus (Runlevel 1) und man konnte sich sofort um das Filesystem kümmern.

Das hatte u.a. den Vorteil, dass sich der Filesystem-Schaden in den vorgefundenen Grenzen hielt und nicht weiter durch Benutzung des fehlerhaften und inkonsistenten Systems verschlimmert wurde.

Aktuelles Verhalten von Opensuse 12.2 mit Systemd bei defekten Root-Filesystemen

Unter Opensuse 12.2 mit systemd ist die oben beschriebene, kluge Politik leider nicht mehr gegeben:

“fsck” (genauer e2fsck) wird zwar gestartet. Aber kommt “fsck” mit der Anzahl oder Qualität nicht klar, wird das fehlerhafte Root-Filesystem durch “systemd” nach kurzem Einblenden einer Warnung in die laufenden Startmeldungen gnadenlos gemounted und der Systemd-Bootvorgang setzt sich fort ! Ja – man mag es kaum glauben – mit einem korrumpierten Filesystem !

Das fand und finde ich nicht nur schockierend, sondern geradezu fahrlässig!

Denn man merkt das Ganze ggf. nur zufällig – nicht zuletzt wegen der hohen Geschwindigkeit von systemd. Bei angeschaltetem Plymouth sieht man u.U. gar nichts, wenn man nicht aufpasst. Zwar wechselt der Schirm beim Start von fsck zu einer Konsole mit Textmodus, aber danach geht es zügig weiter und man landet nach wenigen Sekunden im grafischen Modus – als ob nichts wäre.

Bei textorientiertem Startup ist es fast noch schwerer, das Problem mitzubekommen – die “fsck”-Warnung geht in
der Flut der schnell ablaufenden “systemd”-Meldungen zum Systemstart unter. Was für ein Sch….

Aber der Reihe nach!

Wann traten die Probleme auf?

Die Probleme traten bislang ausnahmslos nach umfangreichen mit YaST2 durchgeführten SW-Updates (KDE, Kernel, … ) auf. Und zwar dann, wenn ich nach den Updates nicht sofort einen Systemneustart durchgeführt hatte, sondern mehrere Stunden weiterarbeitete und danach einen Shutdown mit PowerOff machte.

Auf einem ähnlichen System, auf dem OS 12.2 neu installiert wurde, traten solche Probleme bislang nicht auf. Auch ein anderes upgegradetes System zeigt das Verhalten (noch) nicht. Die anderen Systeme befinden sich jedoch noch auf einem anderen SW-Update-Level.

Allerdings weisen diese anderen Systeme bzgl. des Write-Caches des Raid-Controllers auch andere Einstellungen auf:

Der Parameter “StorSave” des 9650-Raid-Controllers steht im Fall der anderen Systemen auf “Balance” – im Fall der problematischen Systeme jedoch auf “Performance”.

Der Controller der problembehafteten Systeme ist ferner nicht batteriegepuffert. Vielleicht passieren im Rahmen des von systemd gesteuerten Shutdowns bei “performanter” Nutzung des Schreibcaches ja unangenehme Dinge. Vielleicht wird der Puffer des LSI/3ware-Controllers beim Shutdown nicht rechtzeitig geleert, vielleicht wird kein “sync” mehr aufgerufen – was weiß ich.

Man muss die Sache, die erst mit Opensuse 12.2 aufgetreten ist, jedenfalls beobachten:

Das Problem trat ausschließlich auf dem Root-Filesystem auf. Alle anderen gemounteten Filesysteme (alle vom Typ “ext4”) des gleichen Raid 10 Arrays – auch solche für virtuelle Maschinen – meldeten auch bei regelmäßig erzwungenen fsck-Vorgängen keinerlei Problem. Das ist deswegen interessant, weil das Root-Filesystem vor dem Power Off als letztes ausgehängt wird.

Ein Verify des Raid-Arrays zeigt nach einem Auftreten von Fehlern im Root-Filesystem jedenfalls auch aufgetretene Parity-Fehler an. Das spricht ein wenig dafür, dass der Shutdown unter “systemd” ggf. zu rasch erfolgt. Komisch nur, dass das auf dem gleichen System unter Opensuse 12.1 nicht geschieht ! Eine Problem zwischen Treiber und Kernel 3.4 ???

Ich habe den LSI/3ware-Controller nun einige Wochen im “Balanced” Modus des Schreibcaches betrieben. Es trat bis heute kein weiteres Problem mit dem Root-Filesystem auf.

Noch fehlt allerdings noch die Gegenprobe, um auszuschließen, dass das Problem nicht einfach durch problematische Update-Pakete oder Update-Vorgänge erzeugt wurde. Ich hatte dafür wegen anderer Themen bislang einfach keine Zeit.

Wegen der Raid-Controller-Einstellungen möchte ich das Ganze bislang also lediglich als Beobachtung ansehen, deren Ursache unklar ist. Ich werde den Raid-Controller nun wieder auf “Performance” stellen und die Sachlage weiter verfolgen.

Nachtrag 19.01.2013:

Nach vielen Tests muss ich leider feststellen: Bei einem Shutdown mit PowerOff kommt es unter OS 12.2 und systemd mit relativ hoher Wahrscheinlichkeit zu Datenverlusten und inkonsistentem Root-Filesystem, wenn der 3Ware-Controller bzgl. der Schreibpufferung (Parameter “Storsave”) auf “Performance” eingestellt ist.

Wie äußerte sich die Inkonsistenz des Root-Filesystems?

Falsche Inode-Verweise, vor allem etliche verwaiste Inodes und falsche Referenz-Counter. Interessant ist, dass die Dateien, die im Rahmen der letzten “fsck”-Bereinigung im Verzeichnis “lost&found” auftauchten, alle mit YaST2 selbst zu tun
hatten.

Die Schäden waren insgesamt jedenfalls von einer solchen Qualität, dass das automatisch gestartete “fsck” damit nicht mehr ohne User-Eingriffe klarkommen wollte. In den von mir beobachteten 2 Fällen tauchte deshalb der Hinweis auf ein manuell durchzuführendes “e2fsck” auf (s.u.) !

Was macht Systemd beim Starten mit Inkonsistenzen im Root-Filesystem ?

Tja, in meinen Fällen bemerkte systemd beim Starten zwar die Fehler im Filesystem.
fsck wurde dann gestartet. Aber in den Fällen, in denen fsck nicht mehr ohne Userunterstützung mit den Fehlern klarkommen wollte, wurde das kaputte Filesystem – wie gesagt – gnadenlos gemountet.

Dies geschah in meinem Fall an vier Tagen hintereinander (2.11. bis 5.11.), weil ich von den Fehlern – dank des “fantastisch” schnellen systemd – im Entwicklungsstress nichts mitbekommen habe. Erstaunlich, dass ich überhaupt arbeiten konnte.

Nachfolgend ein Auszug aus “/var/log/messages”:

Nov 2 08:49:25 mux kernel: [ 36.774057] EXT4-fs (sda6): warning: mounting fs with errors, running e2fsck is recommended
Nov 2 08:49:25 mux kernel: [ 36.774270] EXT4-fs (sda6): re-mounted. Opts: acl,user_xattr
 
Nov 2 08:53:58 mux kernel: [ 325.684513] EXT4-fs (sda6): error count: 1896
Nov 2 08:53:58 mux kernel: [ 325.684518] EXT4-fs (sda6): initial error at 1351765087: ext4_lookup:1045: inode 922772
Nov 2 08:53:58 mux kernel: [ 325.684523] EXT4-fs (sda6): last error at 1351786094: ext4_lookup:1045: inode 922772
 
Nov 3 09:41:24 mux kernel: [ 30.059173] bootsplash: status on console 0 changed to on
Nov 3 09:41:24 mux kernel: [ 30.849236] EXT4-fs (sda6): warning: mounting fs with errors, running e2fsck is recommended
Nov 3 09:41:24 mux kernel: [ 30.855514] EXT4-fs (sda6): re-mounted. Opts: acl,user_xattr
 
Nov 3 09:46:00 mux kernel: [ 322.602348] EXT4-fs (sda6): error count: 1896
Nov 3 09:46:00 mux kernel: [ 322.602353] EXT4-fs (sda6): initial error at 1351765087: ext4_lookup:1045: inode 922772
Nov 3 09:46:00 mux kernel: [ 322.602357] EXT4-fs (sda6): last error at 1351786094: ext4_lookup:1045: inode 922772
 
Nov 4 08:34:31 mux kernel: [ 34.497854] bootsplash: status on console 0 changed to on
Nov 4 08:34:31 mux kernel: [ 35.111163] EXT4-fs (sda6): warning: mounting fs with errors, running e2fsck is recommended
Nov 4 08:34:31 mux kernel: [ 35.111397] EXT4-fs (sda6): re-mounted. Opts: acl,user_xattr
 
Nov 4 08:39:07 mux kernel: [ 326.695619] EXT4-fs (sda6): error count: 1898
Nov 4 08:39:07 mux kernel: [ 326.695621] EXT4-fs (sda6): initial error at 1351765087: ext4_lookup:1045: inode 922772
Nov 4 08:39:07 mux kernel: [ 326.695623] EXT4-fs (sda6): last error at 1352014560: ext4_lookup:1045: inode 922286
 
Nov 5 09:37:30 mux kernel: bootsplash: status on console 0 changed to on
Nov 5 09:37:31 mux kernel: EXT4-fs (sda6): warning: mounting fs with errors, running e2fsck is recommended
Nov 5 09:37:31 mux kernel: EXT4-fs (sda6): re-mounted. Opts: acl,user_xattr
 
Nov 5 09:42:22 mux kernel: EXT4-fs (sda6): error count: 2368
Nov 5 09:42:22 mux kernel: EXT4-fs (sda6): initial error at 1351765087: ext4_lookup:1045: inode 922772
Nov 5 09:42:22 mux kernel: EXT4-fs (sda6): last error at 1352067644: ext4_lookup:1045: inode 922721

Hübsch, nicht? Seitdem lasse ich “/var/log/messages” nach jedem Bootvorgang auf entsprechende Schlüsselwörter scannen.

Systemd im aktuellen Zustand ist dem Admin jedenfalls nicht dabei behilflich, solche katastrophalen Entwicklungen mit korrumpierten Filesystemen zu vermeiden.

Aber: ich will mich ja nicht aufregen …..

Schadensbehebung – trotz Chaos mit dem Rescue Target

Nun versuche man mal, auf einem von “systemd” gesteuerten Opensuse-System, das Rescue-Target zu erreichen, um “fsck” – wie empfohlen – manuell ablaufen zu lassen. Ich habe das interessehalber auf verschiedenen Systemen in verschiedenem Upgrade-Zuständen getestet.

Ergebnis: Es war unter Opensuse 12.1 und zeitweise (!) auch unter Opensuse 12.2 (vor allem im Originalzustand) fast abenteuerlich, das “isolated rescue target” zu erreichen:

  • Das lt. SuSE angeblich noch funktionierende “init 1” führte auf mehreren Systemen zu einem Herunterfahren des Systems mit unmittelbar danach – und ohne oder gar trotz Userinteraktion – ablaufendem Restart in das “default target” – also den grafischen Modus.
  • “systemctl isolate rescue.target” zeigte – je nach Update-Zustand des Opensuse 12.1 oder 12.2-Systems das gleiche fehlerhafte Verhalten wie “init 1” oder aber ein unterschiedliches Verhalten – je nachdem, ob es von Konsole “tty2” oder “tty1” gestartet wurde.
  • Zwischenzeitlich funktionierte dann lediglich “systemctl rescue” halbwegs wie erwartet. Einen Wechsel der Konsole musste man dabei aber vermeiden. Das Verhalten von systemd war in jedem Fall schwierig – oft verlor man auch den Prompt auf der Konsole, von der der Shutdown gestartet wurde. Überhaupt mutet es merkwürdig an, dass im “Rescue Modus” mehrere Konsolen ansprechbar sind.
  • Ein mehrfaches Hintereinanderausführen des Herunterfahrens in den Rescue Modus mit anschließendem Hochfahren in den Default-Modus mit Konsol-Wechsel verhielt sich z.T. unberechenbar.

Wohlgemerkt: Ich spreche hier von Tests auf Systemen, die (außer systemd) keine Defekte beherbergen.

Inzwischen – also auf dem aktuellen Update-Niveau des Opensuse 12.2-Systems – haben sich die Dinge aber deutlich verbessert. Nun funktionieren

“systemctl isolate rescue.target”

und

“systemctl rescue”

im wesentlichen wie erwartet. Man habe Geduld – die Meldung zum Eingeben des Passwortes und der Prompt erscheinen manchmal zeitversetzt.

Bevor nun aber möglicherweise Ekstase bei den systemd-Anhängern aufkommt – es gibt immer noch gravierende Probleme mit der systemd-Logik:

  • Ein anschließendes “systemctl default” führt zwar zum Hochfahren in den graphischen Modus – auf der ursprünglichen Konsole mag sich unter Opensuse 12.2 aber der Prompt nicht mehr einstellen.
  • Ferner läuft der “agetty”-Prozess nach “systemctl rescue” und einem anschließenden “systemctl default” unter Opensuse 12.2 regelmäßig Amok und verbraucht 90% der CPU-Zeit eines Prozessor-Cores. Man muss “agetty” tatsächlich abschießen, um dem Herr zu werden.

So ist das halt, wenn ein einziges Super-Programm wie “systemd” alles und jedes im System unter Kontrolle behalten muss. Die Tatsache, dass es mit mehreren Konsolen umgehen muss, ist von der neuen Superlösung wohl noch nicht richtig verdaut worden.

Aber ich rege mich nicht auf ….. auch vor den letzten Systemupdates kam man (nach mehreren Konsole-Wechseln und unermüdlichem Probieren) meist doch irgendwie in einen Zustand, der dem früheren “init 1 ” irgendwie ähnelte.

Leider, leider hieß das aber noch lange nicht, dass dann unter “systemd” immer ein

“mount -o remount,ro /dev/rootdevice”

für einen manuellen fsck-Lauf möglich gewesen wäre.

Das ging nur in 50 % der von mir untersuchten Fälle. Bei den Systemen mit bereits vorhandenem Filesystem-Fehler gar nicht. Vielleicht auch bedingt durch die sich inzwischen vergrößerten Probleme mit dem inkonsistenten Filesystem.

Ich musste
jedenfalls in zwei Fällen auf eine CD mit “Rescue-System” ausweichen und von dort meine Root-Partition auf der Platte reparieren.

Seitdem habe ich wieder Ruhe. Was immer die Ursache des defekten Filesystems war – der eigentliche Skandal ist der Umgang von systemd mit einem defekten Filesystem beim Booten !