Opensuse 12.3, LDAP-Client, sssd erfordert TLS/SSL – I

Posted on by

Vor ca. einem Jahr habe ich 5 Artikel zur Implementierung von LDAP mit Hilfe von YaST2-Tools auf Opensuse 12.1-Systemen verfasst. Die einleitenden Artikel waren:

Opensuse 12.1 -LDAP I/
Opensuse 12.1 – LDAP II
Opensuse 12.1 – LDAP III

Gestern hat sich leider bei Einrichtung eines neuen Opensuse-12.3-LDAP-Servers und zugehöriger OS12.3-Client-Systeme erwiesen, dass die Übertragbarkeit dieser Artikel auf Opensuse 12.3 nicht mehr uneingeschränkt gegeben ist. YaST2’s LDAP-Client-Einrichtung erzwingt offenbar seit Opensuse 12.2 den Einsatz von SSSD und führt dadurch potentiell zu einer Reihe von Problemen. In diesem und nachfolgenden Beiträgen gehe ich auf einige dieser Punkte und ein paar damit zusammenhängende Ungereimtheiten der YaST2-LDAP-Module ein.

Background-Infos: Ankündigung der SSSD-Umstellung durch SuSE für Opensuse 12.2

Nachdem ich Probleme mit der LDAP-User-Authentifizierung bekam und diese auf SSSD zurückführen konnte, war es gestern interessant für mich, zumindest ansatzweise herauszufinden, wann und wie der Umstieg auf SSSD bei Opensuse eigentlich herbeigeführt wurde. SSSD bedeutet “System Security Services Daemon”, ist meines Wissens eine Erfindung von Red Hat und soll gerade die Interaktion mit Remote-Auth-Diensten über geeignete PAM-Module vereinfachen und sicherer machen.

Begonnen wurde mit der Diskussion und Bereitstellung von SSSD offenbar schon im Vorfeld von OS 11.4 und des SLES 11. Im Opensuse-Bereich wurde der finale Umstieg dann offenbar mit Opensuse 12.2 beschlossen. Siehe hierzu:

http://swik.net/opensuse/Planet+SuSE/openSUSE+TV%3A+Deploying+sssd+%28Marcus+Moeller%29/e5l4h
https://features.opensuse.org/308902
https://features.opensuse.org/313142
http://lists.opensuse.org/opensuse-factory/2012-02/msg00167.html

Das Video unter dem ersten Link (von der FOSDEM 2011) zeigt, dass ein wichtiges Motiv für die Einführung von SSSD neben einer Vereinfachung der Konfigurationsdateien wohl die Beseitigung von Problemen mit dem NSCD-Offline-Caching in großen Installationen war. Vielleicht nicht unbedingt ein Problem, das die Masse der OS 12.3-User, sondern wohl eher SLES-Admins betrifft. Aber vielleicht täusche ich mich da.

Nun ist eine Umstellung von Remote-Authentisierungs-Modulen aus meiner Sicht doch eine größere Änderung an einem Linux-System. Man würde daher erwarten, dazu etwas in den Release Notes von Opensuse 12.2 oder Opensuse 12.3 zu finden. Fehlanzeige !

https://www.suse.com/releasenotes/i386/openSUSE/12.2/RELEASE-NOTES.en.html
https://www.suse.com/releasenotes/i386/openSUSE/12.3/RELEASE-NOTES.en.html

Geradezu amüsant mutet angesichts mancher Folgen dann die Diskussion der Umstellungs-Ankündigung im Opensuse Factory-Bereich an:

http://lists.opensuse.org/opensuse-factory/2012-02/msg00167.html
http://opensuse.14.
x6.nabble.com/Removing-support-for-nss-ldap-pam-ldap-from-YaST-LDAP-client-td4373062.html

Da wird lapidar das Ende von “nss_ldap” und “pam_ldap” zugunsten von sssd angekündigt. Zitat:

" According to feature #313142 (“YaST support only SSSD for LDAP based authentication”) we want to remove current nss_ldap/pam_ldap support from YaST modules and leave only support for SSSD. Target is next openSUSE realease (12.2). SSSD is there already now (12.1), but still only as an option. With new approach, we should of course provide a migration from current setups.
 
However, this also means that we will stop supporting non-encrypted connections to LDAP server, because SSL/TLS is a requirement for SSSD. So you have to prepare your LDAP servers so they are able to provide TLS."

Die Hervorhebung erfolgte durch mich. Interessant ist hier ja aber vor allem der letzte Satz, der natürlich Auswirkungen auf laufende LDAP-Installationen impliziert! Als Reaktion meinte dann einer der SuSE-Entwickler sehr zu Recht, dass das wohl Eingang in die Release Notes finden sollte. Darauf warteten wir aber leider vergeblich ….

YaST2 erzwingt die Nutzung von SSSD auf LDAP-Clients

Unter Opensuse 12.1 bot das YaST2-Modul “LDAP-Client” die Möglichkeit zur Nutzung von SSSD und zugehöriger PAM-Module bei der Interaktion mit einem LDAP-Server noch als wählbare Option an. Hier der entsprechende Screenshot von einem OS 12.1-System:

ldap_36

Ich hatte diese Option in meinen Artikeln zur LDAP-Konfiguration mittels YaST2 außen vor gelassen, da mir eine konventionelle Einrichtung des Servers und der Clients mit anschließender, kontrollierter Etablierung einer TLS-Kommunikation zwischen LDAP-Clients und LDAP-Server besser und verständlicher erschien.

Die Linux-Götter bei SuSE mögen wissen, wieso diese Option seit Opensuse 12.2 ersatzlos gestrichen wurde und “sssd” nun zwangsverordnet wird ! Ich fühle mich dadurch – trotz aller unbestrittenen Vorteile von SSSD – ungewarnt überfahren bis bevormundet. Und wie man sehen wird, gefährdet eine solches radikales Vorgehen laufende produktive Opensuse-Installationen, bei denen LDAP als Authentifizierungsmittel genutzt wird, zumindest potentiell.

Liegt es daran, dass die SuSE-Verantwortlichen Opensuse-Releases sowieso nur noch als Testplattform für den (inzwischen bei Einsatz von Virtualisierung überteuerten) SLES-Enterprise Server sehen und dass Ihnen eine Kontinuität beim Betrieb von Opensuse-Systemen herzlich egal ist? Alles unter dem wohlfeilen Deckmantel einer erzwungenen verbesserten Systemsicherheit? Die dann seltsamerweise gerade beim Einsatz von YaST2 zur Benutzerverwaltung doch nicht eingehalten wird (s.u.!) ?

Ich finde, man sollte den Opensuse-Usern die Chance geben, sich systematisch in Neuerungen/Verbesserungen einzuarbeiten, diese auszuprobieren und vor dem produktiven Einsatz verstehen zu lernen. In Sicherheitsfragen muss Überzeugung und Verständnis der Ausgangspunkt erforderlicher Maßnahmen sein. Da muss und sollte den Opensuse-Freunden eine Lernkurve zugestanden werden. Und nicht jeder baut sich mit Opensuse gleich ein Hochsicherheitsnetz auf. Für viele ist LDAP selbst ja schon eine gewaltige Herausforderung!

Wohlgemerkt:
Ich beklage nicht die Existenz oder den möglichen Einsatz von SSSD unter Opensuse 12.3 und erst recht nicht unter SLES. Ganz im Gegenteil !
Ich kritisiere aber die unkommentierte Einschränkung der Admin-Tools von YaST2 in dem Sinne, dass hier bislang fast problemfrei funktionierende Optionen zu einer sssd-freien Installation des LDAP-Dienstes
entfernt wurden. Und ich beklage zudem den eklatanten Mangel an einer Integration von entsprechenden Informationen zu SSSD und seinen Voraussetzungen in Yast2 oder aber den Release-Notes ! Letzteres vor allem im Interesse von Opensuse-Nutzern, die sich nicht dauernd und professionell mit allen Änderungen auseinandersetzen können.

Den Zwang zur Nutzung von SSSD würde man nömlich wirklich verstehen, wenn es dem unbedarften Nutzer dadurch tatsächlich leichter fallen würde, zu einem laufenden LDAP-Dienst oder clientseitig zu einer laufenden Verbindung mit einem bereits vorhandenen LDAP-Server zu kommen. Ohne bereits laufende Installation in ihrer Funktionstüchtigkeit zu gefährden. Das ist unter YaST2 aber leider nicht der Fall !

Davon zeugen hinreichend viele Artikel im Internet und Linuxforen. Man google mal zu “Opensuse 12.2 12.3 LDAP sssd TLS getent Problem” oder “Opensuse sssd PAM TLS LDAP Problem”.

Typische Probleme, die sich nach der Umstellung auf sssd ergeben können

In verschiedenen Beiträgen im Internet findet man folgende Schwierigkeiten beschrieben:

  1. User eines “Opensuse 12.3”-Client-Systems, das mit YaST2’s Modul “LDAP Client” für die User-Authentifizierung per LDAP konfiguriert wurde, werden sich gegenüber einem vorhandenen LDAP-Server, der keine TLS/SSL-Absicherung bereitstellt, nicht mehr authentifizieren können. Mit allen Folgen für produktive Opensuse-basierte Netzwerke ….
  2. “getent passwd” zeigt (ohne besondere Maßnahmen) nur noch die Liste der User an, die in der lokalen “/etc/passwd”- bzw. “shadow”-Datei erfasst sind, und nicht mehr die zusätzliche Liste der LDAP-User.
  3. Nach dem Versuch, den LDAP-Server mit einem “Self-signed Certificate” für TLS auszustatten, ergeben sich möglicherweise Probleme beim Einsatz von SSSD.
  4. Auch wenn man parallel zur LDAP-Client-Einrichtung einen neuen LDAP-Server unter Opensuse 12.3 aufsetzt, kann man eine TLS-Konfiguration umgehen und läuft dann in einem reinen OS 12.3-Netz in die oben beschriebenen Schwierigkeiten.

Das erste und wichtigste der genannten Probleme betrifft diejenigen, die ihren LDAP-Server ohne TLS/SSL-Fähigkeit betreiben. Zwar sollten zwei meiner früheren Artikel zu LDAP ja gerade zeigen, wie man TLS aufsetzt. Aber ich habe durchaus Verständnis für Leute, die einen solchen Schritt in kleineren, privaten Netzwerken erstmal gescheut haben und damit vielleicht sogar gut leben konnten. Die müssen künftig was tun.

Erkenntnisse aus eigenen LDAP-Tests unter OS 12.3

Nach mehreren Experimenten auf verschiedenen virtuellen Systemen halte ich folgende Erkenntnisse fest, die die oben dargestellten Schwierigkeiten bestätigen:

  1. YaST2 erzwingt bei der Anlage und Konfiguration eines LDAP-Clients per YaST den Einsatz von SSSD.
     
    Dies schließt aber eine Deinstallation von SSSD und ein manuelles konventionelles Setup der LDAP-Verbindungen auf Opensuse 12.3 Clients (ohne Benutzung von YaST2) nicht aus.
  2. SSSD erfordert im Zusammenhang mit einer lokalen oder einer Remote Authentifizierung über LDAP zwingend den Einsatz von TLS/SSL für die Verbindung zum LDAP-Server. Voraussetzung sind natürlich entsprechende OpenSSL-Zertifikate einer CA für den Server und entweder eine “starttls”-Fähigkeit des LDAP-Servers oder aber der Einsatz von “ldaps”. “gssapi” geht als Sicherheits-layer angeblich auch – habe ich aber nicht getestet.
  3. YaST2 erzwingt aber das Aufsetzen einer TLS/SSL-fähigen LDAP-Server-Installation unter Opensuse 12.3 nicht. Man kann die TLS-bezogenen Angaben auch einfach leer lassen und Warnungen des YasST2-LDAP-Server-Moduls
    übergehen!
  4. Auch bei der Konfiguration des YaST2-LDAP-Clients für die Anlage von User- und Gruppen-Accounts auf dem LDAP-Server wird das Initiieren einer TLS-Verbindung nicht wirklich erzwungen. Auch hier kann man Zertifikatsangaben einfach leer lassen.
  5. Die Anlage von Usern und Gruppen auf einem LDAP-Server funktioniert mit dem YasT2-LDAP-Client in der YaST2-Userverwaltung auf Rückfrage gemeinerweise auch ohne TLS. Bei Setzen einer bestimmten Option in der “/etc/sssd/sssd.conf” muss man nicht einmal eine Rückfrage beantworten. Das wirkt unter Sicherheitsgesichtspunkten eher schizophren und ist mindestens mal verwirrend. Denn man kann ja neue User ordnungsgemäß mit YaST auf einem TLS/SSL-freien dem LDAP-Server anlegen – nur kommen diese User nie zu einem erfolgreichen Login.
  6. Ein Login von vorhandenen oder neuen Usern, die über den LDAP-Server authentifiziet werden müssen, wird nach dem per YaST erzwungenen Einsatz der SSSD-PAM-Module auf einem OS 12.3-System aber ohne TLS-Fähigkeit des Servers nicht funktionieren. Und dies erwies sich in meinen Tests als sehr unabhängig von den Einstellungen in der “sssd.conf”. Ganz im Sinne der SSSD-Erfinder!
  7. Weitere Schwierigkeiten bereiten ggf. Self-Signed-TLS-Zertifikate des LDAP-Servers, wenn die entsprechenden Serverzertifikate der CA nicht auf den Client kopiert wurden und eine bestimmte Option in “etc/sssd/sssd.conf” nicht gesetzt wurde.

Die nachfolgende Abbildung zeigt, dass bei der LDAP-Client-Installation mittels YaST2 auf Opensuse 12.3-Systemen SSSD gezwungenermaßen installiert und aktiviert wird.

ldap_client_OS123_sssd_small

Bei mir sorgten die Tests für ein wenig Verwirrung bzgl. der YaST-LDAP-Module:

Bei der Abänderung der YaST2-Module hat man einerseits bei der Installation des LDAP-Clients eine Option weggenommen und SSSD auf den Clients erzwungen. Andererseits kann man bei der LDAP-Client-Einrichtung per YaST die eigentlich erforderlichen Zertifikatseingaben bzgl. des LDAP-Servers umgehen. Das wirkt irgendwie inkonsequent – Sinn würde das höchstens für andere Auth-Domainen machen, aber hier geht es ja gerade um die Einrichtung eines LDAP-Clients mit SSSD.

In der YaST2-Benutzerverwaltung kann man ferner entgegen den Sicherheitsbestrebungen von SSSD eine verschlüsselte Verbindung als LDAP-Admin beim Zugriff auf den LDAP-Server explizit vermeiden! Man kann dann beliebig und ungesichert User und Gruppen anlegen – die entsprechenden armen Anwender werden sich aber von einem Opensuse 12.3-Client aus nie mittels dem LDAP-Server ohne TLS authentifizeren können, wenn auf dem OS12.2/12.3 Client-System SSSD’s PAM-Module laufen.

Auch bei der LDAP-Serverinstallation unter OS 12.2/OS12.3 sind die Dinge nur halbherzig abgeändert – auch hier kann man auch TLS vermeiden, obwohl der Server dann nicht mit Opensuse 12.3-Clients zusammenarbeiten wird.

Ich finde: Gerade wegen fehlender Alternativen zu SSSD und des Fehlens deutliche und klarer Warnhinweise bzgl. der Konsequenzen ist das Verhalten der YaST2-LDAP-Module unter Opensuse 12.3 wirklich verwirrend. Ganz schlimm und wahrscheinlich überraschend trifft es als Konsequenz diejenigen, die neue Opensuse 12.3-Systeme einführen oder vorhandene Opensuse 12.2-Client-Systeme auf Opensuse 12.3 upgedated haben, dort die Yast2-Client-Einrichtung durchlaufen haben und die sich dann wie gewohnt gegenüber einem älteren Opensuse SLES oder Opensuse 12.1-System ohne TLS-Konfiguration authentifizieren wollen. In einem solchen Fall wird wohl gar nichts mehr gehen.

Fazit:
Das Schlimmste an den LDAP-Auth-Mechanismen von Opensuse 12.3 ist nicht der Einsatz von SSSD
sondern, dass der unbedarfte User über die Ursachen seiner resultierenden Probleme im Unklaren gelassen wird. Schon kleine zarte Hinweise auf der Startseite im YaST2 LDAP Client Modul darauf,

  • dass sssd seit Opensue 12.2 für die LDAP-Authentifizierung zwangsweise eingesetzt wird,
  • dass die Authentifizierung nicht wie gewohnt über pam_ldap ("pam_ldap.so") und nss_ldap ("libnss_ldap.so.2") erfolgt, sondern über pam_sss ("pam_sss.so"),
  • dass nur noch verschlüsselte TLS/SSL-Verbindungen zum LDAP-Server erlaubt werden,
  • dass ein vorhandener LDAP-Server ggf. entsprechend ertüchtigt werden muss,

wären wirklich hilfreich gewesen. Ganz nett wären dann noch Links zu Webseiten für eine sssd-Beschreibung und Konfigurationsoptionen gewesen. Aber da habe ich wohl zuviel erwartet.

TLS/SSL-freie Autentifizierung gegenüber einem LDAP-System trotz laufendem SSSD ?

Ganz verwirrend wird es für die verzweifelt nach einer Abhilfe suchenden OS 12.2/12.3-Anwender dann, wenn man im Internet von “Lösungen” zu einer TLS/SSL-freien Authentifizierung mit SSSD liest, wie etwa im Beitrag von “gsancome” unter

http://forums.opensuse.org/english/get-technical-help-here/install-boot-login/478283-how-do-i-disable-tls-ldap-2.html

oder hier:
http://lists.opensuse.org/opensuse-de/2013-03/msg00528.html

oder hier:
http://www.susethailand.com/suseforum/how-tofaq-%28beginner-skill%29-43/disable-tlsssl-for-ldap-on-opensuse-12-2/

Bei meinen Tests waren all diese Tipps zumindest unter Opensuse 12.3 nicht in dem Sinne wirksam, dass danach ein Login auf einem SSSD-basierten System nun plötzlich ohne SSL/TLS-Absicherung der Kommunikation zu einem LDAP-Server für die User-Authentifizierung funktioniert hätte. Nochmal im Klartext:

Ein Login von Usern mit LDAP-Authentifizierung funktioniert auf einem durch PAM und SSSD-PAM-Module geschützten Client grundsätzlich nicht, wenn der Client keine TLS/SSL-geschützte Verbindung zum authentifizierenden LDAP-Server aufbauen kann. Der LDAP-Server muss verschlüsselte Verbindungen unterstützen.

Dies gilt selbst dann, wenn es wie unter OS 12.3 auf einem Client-System als root möglich ist, die Userverwaltung unter YaST2 mit Login auf dem LDAP-Server über eine ungeschützte (!) Verbindung zu benutzen! Dass das möglich ist, liegt aber daran, dass YaST für den Kommunikationsaufbau mit dem LDAP-Server SSSD-Einstellungen über Py-LDAP-Connectivity-Module umgehen kann. Und solange der LDAP-Server auf dem normalen LDAP-Port offen sein sollte, ist ein Bind dorthin gar kein Problem. Dass hat aber mit der PAM-geschützten User-Authentifizierung und dem Login am OS12.3-Client leider gar nichts zu tun.

In den nächsten Beiträgen werde ich ein wenig näher auf ein paar Einstellungen in der “/etc/sssd.conf” eingehen und nochmal die Erzeugung von TLS/SSL-Zertifikate mittels YaST2 ansprechen. Ein sinnvoller Ausweg aus dem SSSD-Dilemma ist ja wohl der, seinen ungeschützten LDAP-Server endlich über “starttls” TLS/SSL-fähig zu machen !

WordPress und Anführungszeichen

Posted on by

Jetzt war ich so froh, die 1&1-Wordpress-Packungen hinter mir gelassen zu haben. Aber gestern hat mich dann ein Negativ-“Feature” aktueller WordPress-Versionen kalt erwischt:

Englische Zollzeichen (SHIFT+2) und einfache Anführungszeichen (SHIFT+#) werden standardmäßig in typographische Anführungszeichen umgewandelt. Dies erkennt man u.a. auch, wenn man den Quellcode der generierten Webseiten betrachtet. Dort sind die normal eingegebenen Anführungszeichen dann durch definierte Charactercodes ersetzt – und zwar doppelte wie einfache Anführungszeichen. Darüber mögen sich nun Freunde normgerechter deutscher Schriftsprachen-Zeichen sicher sehr freuen. Obwohl die Umwandlung nicht mal für alle Fonts sauber umgesetzt ist und keineswegs immer die ’66 99′-Abfolge dargestellt wird. Ich finde das ganze Theater für technisch orientierte Blogs aber geradezu als Belastung! Wegen der standardmäßig vorgenommenen Umwandlung lassen sich nämlich Informationen zu Kommando- oder Programmzeilen nicht mehr einfach aus WordPress-Beiträgen herauskopieren.

Das typographische Umsetzen von Anführungszeichen sollten die WordPress-Entwickler deshalb künftig unbedingt als abschaltbare Option definieren! Wer in Blogs unbedingt schön und normgerecht gesetzte Texte unterbringen will oder muss, mag eine solche Norm gerne nutzen. Als Standard sollte das aber nicht eingestellt sein.

Gott sei Dank gibt es hierfür aber eine Korrektur der entsprechenden PHP-Filtereinstellungen – also einen einfachen Workaround. Den entsprechenden Tipp habe ich unter

http://www.meinubuntu.de/2011/09/05/normale-anfuhrungszeichen-verwenden-in-wordpress/

gefunden! Gemäß dieses Artikels muss man die Datei “functions.php” unter dem WordPress-Menüpunkt “Design >> Editor” aufrufen und am Ende durch die Zeile

remove_filter(‘the_content’, ‘wptexturize’);

ergänzen. Das hat bei mir einwandfrei funktioniert.

Man sollte sich von der Datei “functions.php” seines Themes eine Kopie anlegen und die vorgenommene Änerung im Code deutlich durch einen Kommentar kennzeichnen – beim nächsten Update von WordPress wird diese Datei sicher überschrieben.

Weitere nette oder lesenswerte Artikel in diesem Zusammenhang sind :

http://www.interaktionsdesigner.de/2009/01/08/weg-mit-den-verdammten-anfuhrungszeichen-von-wordpress/
http://www.flomei.de/2012/04/29/deutsche-anfuhrungszeichen-in-wordpress-ohne-plugin-2/
http://www.reussmedia.de/wordpress-deutsche-anfuehrungszeichen/
http://www.elmastudio.de/wordpress/schrift-in-wordpress-optimieren-mit-dem-wp-typography-plugin/

KVM-Host – Mounten “virtueller” Gast-Partitionen aus logischen LVM-Volumes

Posted on by

Beim Aufsetzen eines neuen Servers schlage ich zur Zeit einen Weg ein, bei dem bestimmte Serveraspekte in virtuellen KVM-basierten Maschinen gekapselt werden sollen. Nun nutze ich auf dem KVM-Host als Basis einer flexiblen Partitionierung LVM. Die virtuellen KVM-Systeme erhalten ihre virtuellen Platten und zugehörige Partitionen in Form der Zuweisung von logischen LVM-Volumes, die auf dem KVM-Host vorliegen. Der Zugriff des Gastes auf dieses Raw-Device erfolgt in meinem Fall über “virtio”. Im Zuge der Installation des Gast-Systemes werden innerhalb der virtuellen Harddisk dann “virtuelle” Partitionen des Gastsystems angelegt. Die nachfolgende Darstellung illustriert dies:

KVM_Host_mit_LVM_V01

Aufgabenstellung: Mounten virtueller Partitionen eines KVM-Gastes auf dem KVM-Host

Der Inhalt der Aufgabenstellung hört sich nur scheinbar widersprüchlich an. Es kann tatsächlich mal vorkommen, dass man aus bestimmten Gründen gerne vom Host aus auf eine der “virtuellen” Partitionen des KVM-Gastes zugreifen möchte. Natürlich nur, wenn das KVM-Gastsystem nicht aktiv läuft und die virtuelle Harddisk nicht vom Gastsystem genutzt wird.

Bei ein wenig Nachdenken wird sofort klar: Ein solcher Zugriff des KVM-Hostes erfordert ein zwischengeschaltetes Tool – in den Partitionsverzeichnissen des Hosts wird die virtuelle Partition eines Gastes, die sich innerhalb eines logischen LVM-Volumes befindet, nicht direkt als mountbares Device bereitstehen. Die Situation ist hier vergleichbar mit der internen Struktur von Files, die als Loopback-Devices genutzt und gemountet werden. Der YaST2-“Partitioner” des Opensuse 12.3-Systems etwa lässt die interne Partitionierungs-Struktur logischer LVM-Volumes nicht erkennen. Schließlich wird ja das gesamte logische LVM-Volume von KVM als Raw-Device behandelt und enthält keine unmittelbaren Filesystem-Informationen wie eine normale formatierte (LVM-) Partition des Hosts.

Gründe für einen Zugriff auf virtuelle Partitionen der KVM-Gastsysteme vom Host aus können vielfältig sein – u.a. sind zu nennen:

  • Erstellung von Sicherungen bestimmter Inhalte des Gast-Filesystems.
  • Bearbeitung bestimmter Files des Filesystems des KVM-Gastes auch bei nicht laufendem KVM-Gast.

In meinem Fall hatte ich eine Konfigurationsdatei das Gastes verpfuscht, die ein normales Starten dieses KVM-Gastes verhinderte. Diese Datei hätte ich nun gerne vom Host aus bearbeitet, um das Gastsystem ohen Rückgriff auf Sicherungen wieder zum Laufen zu bringen.

Lösung: kpartx

Gibt es nun ein Linux-Tool mit dem man die Struktur des Raw-Devices auslesen und die Partitionen erkennen kann ? Ja, das gibt es – es heißt “kpartx”. Ich zitiere aus der zugehörigen “man-page”:

Name : kpartx – Create device maps from partition tables
Synopsis : kpartx [-a | -d | -l] [-v] wholedisk
Description : This tool, derived from util-linux’ partx, reads partition tables on specified device and create device maps over partitions segments detected. It is called from hotplug upon device maps creation and deletion.

“kpartx” kann man für verschiedene Devices oder Platten-Images einsetzen. Neben der Bereitstellung interner Partitionen von Raw-Device-Harddisks für virtuelle KVM-Systeme eignet es sich z.B. auch für den Zugriff auf Loopback-Device-Files.

Die verschiedenen Optionen von “kpartx” sehe man sich selber an. Mittels der Option “-a” erzeugt man eine vollständige Liste der Partitionen eines Raw-, LVM- oder Loopback-
Devices im Verzeichnis:

/dev/mapper

Die dortigen Einträge entsprechen unter Opensuse Links übrigens Devices der Form “/dev/dm-xx”. Diese Devices kann man dann im KVM-Host benutzen und u.a. mounten.

Ein Beispiel

Nachfolgend zur Illustration ein paar typische Kommandos für ein Testsetup:

Das Harddisk-Array der Testmaschine ist ein Raid 10-Array aus vier 2 TB-Platten. Das Array wurde mit GPT partitioniert. Die bislang aufgesetzten logischen Volumes befinden sich unter “/dev/volgrp1”. Einem virtuellen KVM-Gast wurde u.a. das logische Volume “/dev/volgrp1/vm_imap_hd0” als virtuelle Harddisk per virtio-Treiber zur Verfügung gestellt und beim Installieren des Betriebssystems OS 12.3 mit 2 “virtuellen” Partitionen – einem Swap-Bereich und einer ext4-Partition – ausgestattet.

Folgender Screenshot liefert einen Überblick:

kvm_partitions_1

Man erkennt, dass “fdisk” und “parted” den internen Aufbau z.B. des logischen LVM-Volumes “/dev/volgrp1/vm_imap_hd0” durchaus erkennen. Allerdings finden sich unter “/dev/mapper” noch keine entsprechenden Devices, die im Host direkt brauchbar und mountbar wären.

Hierfür benötigen wir nun den Befehl “kpartx” in der Form

kpartx -a /dev/volgrp1/vm_imap_hd0

kvm_partitions_2

Es wird klar, dass “kpartx -a /dev/volgrp1/vm_imap_hd0” denn internen Aufbau des logischen Volumes analysiert und entsprechende Devices unter “/dev/mapper” bzw. in unserem Fall als “/dev/dm-5” und “/dev/dm-6” bereitstellt. “/dev/dm-6” entspricht der Partition, die im virtuellen Gast als root-Filesystem gemountet wird.

Abschluss der Arbeiten mit Gast-Partitionen durch “kpartx -d”

Bitte nicht vergessen, nach dem Abschluss der Arbeiten mit den “virtuellen” Partitionen im KVM Host die Partitionen vor dem Neustart der virtuellen Maschinen wieder zu “umounten” und zur Sicherheit auch aus dem Device-Mapper zu entfernen. Letzteres ermöglicht “kpartx -d” – in unserem Beispiel:

kpartx -d /dev/volgrp1/vm_imap_hd0

Links

Natürlich ist die dargestellte Vorgehensweise nicht auf meinem Mist gewachsen. Deshalb stellvertretend für viele andere Links ein paar Hinweise auf Artikel, die für mich nützlich waren:

http://backdrift.org/mounting-a-file-system-on-a-partition-inside-of-an-lvm-volume
http://blog.normation.com/2011/04/07/mounting-partitions-stored-in-a-logical-volume-or-a-disk-image/
http://serverfault.com/questions/376421/how-to-access-partitions-inside-a-logical-volume-from-the-host-machine

Einige meiner Leser werden sich fragen, wie man die virtuellen Partitionen innerhalb eines logischen Volumes nun bei Bedarf in ihrer Größe abändern kann. Ein direktes Resizing mit LVM im Host ist hier natürlich nicht ohne größere Umwege möglich. Die Entwickler bei Red Hat haben aber den Befehl “virt-resize” bereitgestellt, der
im Zusammenspiel mit dem LVM-System des KVM-Hostes die erforderlichen Schritte sehr erleichtert. Hierzu seien dem interessierten Leser folgende Links ans Herz gelegt:

!!!!
http://unix-heaven.org/resizing-kvm-disk-image-lvm-the-easy-way
!!!!
http://www.pither.com/articles/2009/10/09/resize-ext3-in-lvm-in-partition-in-kvm-qemu-virtual-image-file
http://libguestfs.org/virt-resize.1.html

Viel Spass nun mit KVM, LVM, logischen Volumes und “virtuellen” Partitionen !

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.3 – OX 6.22 lässt sich mit systemd nicht starten

Posted on by

Nach dem Upgrade von Opensuse 12.2 auf Opensuse 12.3 musste ich leider feststellen, dass der Dienst “/etc/init.d/open-xchange” nicht mehr automatisch gestartet werden kann. Im Gegensatz zu Opensuse 12.2 führt ein "systemctl start open-xchange" nun leider ins Nirwana:

mysystem:/etc/init.d # systemctl status open-xchange.service
open-xchange.service – LSB: Open Xchange Daemon
Loaded: loaded (/etc/init.d/open-xchange)
Active: inactive (dead) since Wed, 2013-03-27 12:30:19 CET; 5min ago
Process: 13365 ExecStop=/etc/init.d/open-xchange stop (code=exited, status=0/SUCCESS)
Process: 13349 ExecStart=/etc/init.d/open-xchange start (code=exited, status=0/SUCCESS)
CGroup: name=systemd:/system/open-xchange.service
Mar 27 12:30:19 mysystem.mydomain.de systemd[1]: Starting LSB: Open Xchange Daemon…
Mar 27 12:30:19 mysystem.mydomain.de open-xchange[13349]: Starting open-xchange ..done
Mar 27 12:30:19 mysystem.mydomain.de systemd[1]: Started LSB: Open Xchange Daemon.
Mar 27 12:30:19 mysystem.mydomain.de su[13360]: (to open-xchange) root on none
Mar 27 12:30:19 mysystem.mydomain.de open-xchange[13365]: Shutting down open-xchange ..done

Jeder Start mit systemd führt also auch zu einem sofortigen Stop. Und der Service ist danach regelmäßig "dead".Was dem User beim Versuch, sich in OX 6 einzuloggen mit 503-Fehlermeldungen quittiert wird.

Na da freuen wir uns doch mal wieder herzlich über die "wunderbare" Welt von systemd! Was für OX 6.22 unter Opensuse 12.2 anstandslos lief, läuft unter Opensuse 12.3 nicht mehr. Und die Fehleranalyse ist für systend so kompliziert und unüberschaubar, dass ich im Moment keinerlei Lust verspüre, auf Fehlersuche zu gehen.

Workaround
Netterweise geht aber nach wie vor ein direkter Start über das Skript:

mysystem:/etc/init.d # ./open-xchange start
redirecting to systemctl start
Starting open-xchange done
mysystem:/etc/init.d # ./open-xchange status
Checking for service open-xchange running
Checking for service open-xchange running
mysystem:/etc/init.d # systemctl status open-xchange
open-xchange.service – LSB: Open Xchange Daemon
Loaded: loaded (/etc/init.d/open-xchange)
Active: inactive (dead) since Wed, 2013-03-27 12:57:05 CET; 1min 39s ago
Process: 15646 ExecStop=/etc/init.d/open-xchange stop (code=exited, status=0/SUCCESS)
Process: 15636 ExecStart=/etc/init.d/open-xchange start (code=exited, status=0/SUCCESS)
CGroup: name=systemd:/system/open-xchange.service
Mar 27 12:57:05 mysystem.mydomain.de systemd[1]: Starting LSB: Open Xchange Daemon…
Mar 27 12:57:05 mysystem.mydomain.de open-xchange[15636]: Starting open-xchange ..done
Mar 27 12:57:05 mysystem.mydomain.de open-xchange[15646]: Shutting down open-xchange ..done
Mar 27 12:57:05 mysystem.mydomain.de systemd[1]: Started LSB: Open Xchange Daemon.
mysystem:/etc/init.d #

Man beachte die Kleinigkeiten und erfreue sich an dieser berauschenden Logik: Das Startscript wird angeblich an systemctl redirected. Open-Xchange wird danach auch erfolgreich gestartet. Der Status ist bei normaler Abfrage per Script auch running. Man kann sich regulär per Browser in seinen OX6-Account einloggen. Aber systemd kann mit dem erfolgreichen Start offenbar gar nichts anfangen und sieht nicht mal, dass der Service läuft! Was für ein grandioses Chaos!

Jedenfalls läuft der Dienst nur nach einem normalen Start – also über /etc/init.d/open-xchange start regulär. Nicht aber das Rauf- und Runterfahren über systemd. Damit kann man den inzwischen auf ein Minimum reduzierten “Runlevel-Editor” von YaST für eine Aktivierung von OX 6.22 schlicht vergessen. Runlevels gibt es dort nicht mehr – und für OX funktioniert das Starten beim
Hochfahren in das Systemd-Default-Target mit systemd nicht.

Also gilt bis auf weiteres unter Opensuse 12.3: OX 6.22 händisch starten und vor dem Runterfahren auch wieder stoppen.
Schöne neue Welt …. Seufz ….

Nachtrag 08.06.2013 und Lösung:
Die Opensuse-Leute haben mir inzwischen wirklich geholfen, das Problem analysiert und ein service-file für den “open-xchange”-Service zusammengestellt. Dadurch ist nun ein Hochfahren von open-xchange beim Systemstart möglich.
Siehe
https://bugzilla.novell.com/show_bug.cgi?id=813767
Man beachte auch die gute Erklärung der Problem-Ursache.

Vielen Dank an Frederic Crozat !!