Author Archives: Ralph Mönchmeyer

Opensuse 12.1 – LDAP I

Posted on by

Hätte nie gedacht, dass es tricky sein kann, unter Opensuse 12.1 OpenLDAP für SSL/TLS mit YaST2 einzurichten. Ist es aber – und mir ist es in einem ersten naiven Anlauf sogar gelungen, die Yast2-Umgebung so zu ruinieren, dass die YaST2-LDAP-Clients nicht mehr zur Kooperation mit mir und dem LDAP-Server zu bewegen waren.

Interessanterweise habe ich für Opensuse 12 keine zusammenhängende Beschreibung im Internet gefunden, wie man ein elementares LDAP-Setup zu vollziehen hat. Im Gegenteil fand ich in Foren und Blogs etliche Warnungen davor, so etwas in einem produktiven Netzwerk überhaupt mit den SUSE-Tools zu versuchen. Es geht aber doch … Na ja, ich sollte besser sagen: Zumindest kommt man mit den Bordmitteln von Opensuse und YaST2 ganz schön weit.

Deshalb beschreibe ich nachfolgend in einer 5-teiligen Serie von Blog-Beiträgen einfach mal die Konfigurationsschritte, die ich zum Aufbau eines einfachen LDAP-Einsatzszenarios auf einem Testserver und Test-Hosts durchgeführt habe. Alle Systeme liefen dabei unter Opensuse 12 und befanden sich in einem kleinen Netzwerk. (Faktisch war die ganze Testumgebung unter KVM virtualisiert.)

Interessant fand ich dabei die Frage, ob wir mit YaST2 allein und auf einfache Weise einen LDAP-Server und Opensuse-Hosts so aufsetzen können, dass es danach möglich ist,

  • User-Account-Daten auf dem LDAP-Server von jedem anderen System aus anzulegen und zu verwalten,
  • User über den LDAP-Server zu authentifizieren,
  • Logins auf Hosts über das LDAP-System autorisieren zu lassen und
  • für spezifische User den Zugang auf bestimmte Hosts einzuschränken.

Meine Erfahrungen bei diesem Vorhaben erwiesen sich erwartungsgemäß als gemischt. YaST2 hilft gut über die anfänglichen Hürden hinweg, denen ein LDAP-Neuling begegnet. Früher oder später muss man aber über den Tellerand der Opensuse-Tools hinausblicken und sich ein tieferes Verständnis der Zusammenhänge erarbeiten.

Mit meiner kleinen Serie von Artikeln zum Einsatz von LDAP unter Opensuse 12 möchte ich hierzu ein paar Hilfestellungen geben. An passender Stelle werde ich dabei auf Artikel im Internet verweisen, die einige spezielle Themen tiefer behandeln, als ich das in einem Blog tun kann.

Vorweg sollte ich ein paar Einschränkungen klarstellen:

  • Grundlagenkenntnisse zum Aufbau eines LDAP-Verzeichnisses, der zugrunde liegenden (hierarchischen) LDAP-Datenbank und zu LDAP-Schemata werden vorausgesetzt. So sollte dem Leser bekannt sein, was “Distinguished Names” sind und was im besonderen eine “Base-DN” oder eine “Root-DN” ist. Eine Kurzeinführung bietet z.B. Wikipedia unter:
    http://de.wikipedia.org/wiki/Lightweight_Directory_Access_Protocol
    Ausführliche Informationen zu OpenLDAP erhält man z.B. unter
    http://www.openldap.org/doc/admin24/
  • In diesem Beitrag geht es nicht um eine umfassende LDAP-Einrichtung und die Konfiguration aller möglichen Clients (z.B. Postfix, Samba) auf Netzwerk-Hosts für die effiziente Nutzung eines zentralen LDAP-Verzeichnis-Dienstes. Es geht nur darum, LDAP neben dem gewöhnlichen Passwort-Mechanismus eines Linux-Systems als Authentifizierungsbackend für den Login auf unterschiedlichen Linux-Hosts zu nutzen.
  • Die Pflege der User-Accounts, Passwörter etc. auf dem LDAP-Server möchte ich – soweit möglich – mit den entsprechenden Yast2-Tools vornehmen.
  • Die Verbindungskanäle der verschiedenen Linux-Hosts, die zur Authentifizierung, aber auch zur Pflege ihrer User und Gruppen auf den zentralen LDAP-Server zugreifen, sollen mit Hilfe von TLS verschlüsselt werden.
  • Es geht hier nicht darum, den Zugang zum LDAP-Server – außer für Rootprozesse – durch einen eigenen speziellen Authentifizierungsmechanismus wie z.B. SASL in Kombination mit Kerberos abzusichern. Wir begnügen uns hier vielmehr mit einfachen LDAP-Zugriffsvarianten, die auf sog. “Bind”-Verfahren beruhen (s. die Diskussion weiter unten). In Netzen mit geringen Sicherheitsansprüchen ist dies aus meiner Sicht ausreichend, um Authentifizierungsverfahren mit Hilfe eines zentralen LDAP-Backends durchzuführen, wenn die betreffenden Hosts im Netzwerk mit dem LDAP-Server über TLS-gesicherte Verbindungen kommunizieren.
  • Es geht zunächst auch nicht darum, den Zugang zu bestimmten Informationen auf der LDAP-Datenbank user- oder gruppenspezifisch (besser: bindspezifisch) abzusichern. Lediglich der Zugriff auf die Passwörter zu den Personenaccounts, die im LDAP-Verzeichnis vorgehalten werden, wird beschränkt.
  • Bzgl. der Sicherheit vertrauen wir in unseren Beispiel-Szenarien lediglich auf die eben erwähnte TLS-Verschlüsselung der Verbindungen zum Server, eine zeitgemäße Verschlüsselung der auf dem LDAP-System hinterlegten Passwörter sowie elementare Zugriffsbeschränkungen auf Zweige des LDAP-Verzeichnisses.

Ich versuche nun kurz, den Inhalt der kommenden Beiträge abzustecken. Unter einem “Host” verstehe ich nachfolgend ein beliebiges Linux-System in unserem Netzwerk, das vom LDAP-Server verschieden ist.

  • Voraussetzung eines einfachen LDAP-basierten Authentifizierungs-Szenarios in einem Netzwerk ist in jedem Fall, dass die entsprechenden Test-User-Accounts auf dem zentralen LDAP-Server angelegt werden können. Hierzu muss man zunächst den LDAP-Server selbst aufsetzen. Wir wollen dies mit den Mitteln von YaST2 versuchen.
  • Ein zweite Ziel unserer Auseinandersetzung mit LDAP unter Opensuse ist es, die Benutzer- und Gruppenverwaltung auf dem LDAP-Server mit YaST2-Tools abzuwickeln. Voraussetzung hierfür ist die korrekte Einrichtung der YaST2-LDAP-Clients für die “YaST User- und Gruppenverwaltung”. Und dies nicht nur auf dem LDAP-Server selbst sondern auch auf anderen Netzwerk-Hosts.
  • Ein weiteres Ziel ist es, einen User-Login sowohl auf einem weiteren Host als auch auf dem LDAP-Server selbst über eine Authentifizierung durch das LDAP-Backend autorisieren zu lassen. Zur Überwachung von Login-Vorgängen sollen klassische Linux-Tools (PAM in Kombination mit NSS; s.u.) eingesetzt werden, die LDAP neben möglichen anderen Authentifizierungsverfahren nutzen sollen. Diese Tools müssen dazu als Linux-Clients konfiguriert werden – auf unseren Netzwork-Hosts und natürlich auch auf dem LDAP-Server selbst. Insgesamt müssen wir also sowohl PAM/NSS als auch die YAST2-Module zur User-Verwaltung auf unseren Netzwerk-Hosts zur Verwendung von LDAP und zur Kommunikation mit dem LDAP-Server einrichten. Interessant ist die Frage wie diese unterschiedlichen LDAP-Clients auf unseren Netzwerk-Hosts miteinander interagieren.
  • Alle erforderlichen “LDAP-Clients” kommen nicht nur auf dem LDAP-Server, sondern vor allem auf Netzwerk-Hosts, die ganz unabhängig vom LDAP-Server sind, zum Einsatz. Der jeweilige Host muss dann mit dem LDAP-Server über eine TCP/IP-Verbindung kommunizieren (Ports: 389 und ggf. auch 636). Die Verbindung soll dabei durch Verschlüsselung geschützt werden. Der Schutz des Zugriffs auf den LDAP-Server soll sowohl für den pflegenden Administrator, der YaST2 nutzt, als auch für PAM/NSS sowie andere LDAP-Clients (u.a. Kommandozeilentools) über eine TLS-gesicherte Verbindung gewährleistet sein. Hierfür müssen der Server wie auch die LDAP-Clients auf den Netzwerk-Hosts passend eingerichtet werden.
  • PAM kann über bestimmte Module sog. “Policies” etablieren, denen die
    Qualität von Passwörtern gehorchen muss. Das wirft die Frage auf, ob man mittels LDAP statt einer lokalen auch eine zentrale Passwort-Politik für die User eines Netzwerkes etablieren kann. Wenn ja: Wie unterstützt einen YaST2 in diesem Zusammenhang?
  • Auch auf dem LDAP-Server selbst wird man ggf. LDAP-basierte Authentifizierungsmechanismen einsetzen wollen; schließlich muss man sich als User auch dort authentisieren. In diesem Zusammenhang stellt sich dann aber die klassische Frage eines Netzwerk-Administrators, welche User eigentlich auf den LDAP-Server oder andere Hosts und Server zugreifen können sollen. Dies führt zu der sicherheitsrelevanten Problemstellung, wie man mit Hilfe von LDAP für einzelne User Zugriffseinschränkungen auf spezifische Hosts verwalten und im Netzwerk durchsetzen kann.

Damit ist der Themenkreis der kommenden Beiträgsserie “LDAP I” bis “LDAP V” gut umrissen.

In diesem ersten Beitrag “LDAP I” beschreibe ich zunächst die Einrichtung des LDAP-Servers mit YAST2-Tools – allerdings noch ohne TLS-Fähigkeiten. Wir werden dabei für erste Tests bereits die YaST2-Tools zur “User- und Gruppenverwaltung” auf dem Server nutzen.

Der zweite Teil “LDAP II” beschreibt dann das Anlegen eines SSL-Zertifikats für den LDAP-Server und dessen Konfiguration für die Unterstützung von SSL/TLS-Verbindungen.

Im Teil “LDAP III” gehe ich dann auf die Konfiguration der YaST2 “User- und Gruppen-Verwaltung”, von PAM/NSS als auch von klassischen LDAP-Kommandozeilen-Tools als LDAP-Clients auf beliebigen Netzwerk-Hosts ein. Die Konfiguration dieser Clients berücksichtigt dabei die Anforderung nach einer TLS-Verschlüsselung. Wir betrachten im Beitrag “LDAP III” zudem das Zusammenspiel von PAM und LDAP etwas genauer; geleitet werden wir dabei von den erforderlichen Einträgen in den PAM-Konfigurationsdateien.

Im Beitrag “LDAP IV” befasse ich mich schließlich mit der Etablierung einer zentralen Password-Politik über den LDAP-Server. Dabei werden wir unser Verständnis der Wechselwirkung zwischen PAM und dem LDAP-Server zwangsläufig vertiefen. Es wird sich zeigen, dass die LDAP-basierte Password-Politik eine lokale PAM-basierte Politik nicht ersetzen sondern nur ergänzen kann.

Im Beitrag “LDAP V” zeige ich abschließend anhand zweier einfacher Verfahren, wie man mit LDAP Zugriffsbeschränkungen für spezifische Hosts realisiert. Dabei werden wir erstmalig auf andere Werkzeuge als YaST2-Tools zurückgreifen müssen.

Hinweis:
Es empfiehlt sich übrigens, alle Experimente in einer z.B. mit KVM virtualiserten Test-Umgebung vorzunehmen, bevor man sich an die produktiven Systeme seines Netzwerkes heranwagt. Ich habe beim Test von Serverkonfigurationen generell sehr gute Erfahrungen mit virtualisierten Servern in einem separaten, ggf. ebenfalls virtualiserten Netzwerksegment gemacht.

Punkt 1: Einige Vorüberlegungen vor der Serverinstallation

Welche Verfahren/Module für die User-Authentisierung bzw. -Authentifizierung werden auf Linux-Systeme eingesetzt? Zu nennen sind hier in erster Linie PADL’s PAM (Plugable Authentication Modules) und NSS (Name Service Switch). [Neuere Entwicklungen wie SSSD lasse ich in dieser Artikelserie mal unter den Tisch fallen.]

Die genannten Module sind auf den meisten Linux-Systemen als Standard installiert. Sie steuern und überwachen auch unter Opensuse 12 die Authentifizierung eines Users mit Hilfe verschiedener Backends. U.a. können sie als LDAP-Clients fungieren und auf externe (oder interne) LDAP-Systeme zugreifen. Die Interaktionskette, mit der ein User sich gegenüber einem zentralen LDAP-Server zu authentisieren versucht und mit der die Authentifizierung vom LDAP-Server vorgenommen wird, sieht dabei etwa so aus:

Login- und Authentisierungs-Versuch eines Users mit UID und Passwort auf einem Linux-Host im Netzwerk
>>
NSS/PAM entscheidet auf dem Host über den Authentifizierungsweg und stößt verschiedene Authentifizierungsvorgänge an
>>
PAM nimmt bei Versagen anderer Mechanismen schließlich Kontakt zum LDAP-Server auf (über das Netzwerk oder – falls der Login-Versuch auf dem LDAP-Server selbst erfolgt – über ein lokales Socket-Protokoll)
>>
PAM erhält Zugang zum LDAP-Server und durchsucht die LDAP-Daten-Bank nach einem Eintrag für den User mit der angegebenen UID
>>
PAM versucht mit den LDAP-Informationen und dem vom User eingegebenen Passwort danach einen sog. BIND zum LDAP-Server
>>
Gelingt der BIND, so wird die LDAP-Authentifizierung als gelungen zurückgemeldet
>>
Ist diese Authentisierung gemäß der PAM-Einstellungen hinreichend, wird der Zugang zum Linux-Host gewährt.
 

Was unter einem “BIND” genauer zu verstehen ist, bespreche ich weiter unten.

Wir kümmern uns in diesem ersten LDAP-Artikel noch nicht um Details der PAM-Bedingungs-Kaskade für eine hinreichende Authentifizierung auf einem Linux-Host (siehe aber “LDAP III”). Das Schöne an Opensuse ist nämlich, dass uns YaST2 sowohl auf dem Server als auch auf anderen Hosts die grundlegenden Arbeitsschritte im Rahmen der Konfiguration der “Yast2-User und Gruppenverwaltung” für die LDAP-Nutzung abnimmt. Wir akzeptieren zunächst einfach, dass Opensuse bei der Einrichtung der YAST2-Benutzerverwaltung Standardeinstellungen für eine hinreichende User-Authentifizierung vornimmt. Welche Konfigurationsdateien welcher potentiellen LDAP-Clients von YaST2 wie beeinflusst werden, sehen wir uns später aber noch im Detail an.

Bevor wir den LDAP-Server mittels YaST2 einrichten, noch ein paar Hinweise zu gedanklichen Fehlern, die man beim Einsatz von LDAP unter Opensuse 12.1 machen kann :

Einsatz modularer LDAP-Konfigurationsdateien anstelle der klassischen Datei “slapd.conf”

Das YaST-Modul von Opensuse 12.1 zur Einrichtung eines LDAP-Servers verwendet die klassische Konfigurationsdatei “slapd.conf” nicht mehr. Das merkt man aber nicht unbedingt auf Anhieb. Vielmehr ist der optische Informationsstand zu diesem Thema auch noch davon abhängig, auf welchem aktuellen Update-Zustand sich das Opensuse 12.1-System befindet und wie man diesen Zustand erreicht hat – über eine Neuinstallation oder aber über Upgrades von früheren Opensuse 11-Systemen aus.

Auf einem voll aktualisierten System erhält man in der Datei “/etc/openldap/slapd.conf” keine regulären Einträge mehr, sondern nur noch Kommentare, in denen auf die neue dynamische und modulare Konfiguration verwiesen wird.

Auf einem frisch von CD installiertem oder upgegradeten System hingegen gibt es dagegen die Datei “/etc/openldap/slapd.conf” auch nach der Installation des Openldap2-RPMs noch. Sie weist Standard-Einträge auf, und sie bleibt auch noch nach der Konfiguration des LDAP-Servers mittels YaST2 unverändert bestehen. Das war für mich zunächst total verwirrend. Nach einigem Testen fand ich aber heraus, dass man die Einstellungen in der herkömmlichen “slapd.conf” vergessen kann. Die eigentlichen Konfigurationseinstellungen befinden sich in den Verzeichnissen

  • /etc/openldap/slapd.d/
  • /etc/openldap/schema/

Diese Dateien sind gemäß des LDIF-Formats aufgebaut. Weitere Informationen zum hierarchischen Aufbau der LDAP-Konfigurationsdateien erhält man durch die Installation des Paketes “openldap2-doc” und dann durch Lesen folgender HTML-Seite

/usr/share/doc/packages/openldap2/adminguide/guide.html#Configuring slapd

Modifikationen an den Dateien kann man über die CLI-Kommandos “ldapmodify”,
“ldapadd” und “ldapdelete” durchführen, wenn man ein direktes Editieren scheuen sollte.

Benutzerauthentifizierung auf einem Host unter Nutzung eines zentralen LDAP-Verzeichnisses ist logisch etwas anderes als die konkrete Authentisierung eines Users oder Systems gegenüber dem LDAP-Server, um Zugang zu den dort hinterlegten Informationen zu erhalten

Im Zuge eines Loginversuch eines Users auf einem Linux-Host werden die User-Credentials über PAM-Module mit entsprechenden Einträgen in der Datenbank des LDAP-Servers verglichen. Der LDAP-Verzeichnisdienst und seine Einträge werden dabei also als Mittel zur User-Authentifizierung für den Host-Zugang eingesetzt.

Das LDAP-System selbst gewährt als sicherheitsrelevantes Datenbank-System aber natürlich nicht so ohne weiteres jedem Anwender oder jedem Programm lesenden oder schreibenden Zugang zu den Datenbank-Inhalten. Ein User oder ein Programm wie PAM, das einen solchen Zugang erlangen möchte, muss sich je nach den gesetzten Bedingungen also selbst erst einmal gegenüber dem LDAP-Server als berechtigt ausweisen oder authentisieren. Dieser Schritt wurde für PAM in der oben dargestellten Kette als “PAM erlangt Zugang zum LDAP-Server” gekennzeichnet. Der Zugang zum LDAP-System kann durch folgende Varianten ermöglicht werden:

  • Es können sekundäre, also LDAP-externe Auth.-Mechanismen (wie SASL) und andere Sicherheitslayer eingesetzt werden,
  • Es werden diejenigen Informationen, die im LDAP-System selbst zu Usern, Systemen und zugehörigen Passwörtern hinterlegt sind, verwendet, um den LDAP-Zugang zu gewähren.

Die zweite Variante wird als “Bind” gegenüber dem LDAP-System bezeichnet.

Die beim Bind verwendete “LDAP-Identität” hat gemäß der Struktur der LDAP-Einträge eine spezifische Form, die die Baumstruktur der Information widerspiegelt (z.B. “cn=Administrator, dc=anracona,dc=de” oder “cn=Ralph,ou=people,dc=anracona,dc=de”).

Damit bei Binds nicht jeder alles zu sehen bekommt oder alles ändern darf, müssen “Bind”-spezifische, also Identitäts-spezifische Rechte für die LDAP-Datenbank-Informationen vorgegeben sein. Ein LDAP-Server bietet hierfür ein ausgeklügeltes System zur Rechteverwaltung für Zugriffe auf spezifische LDAP-Inhalte – z.B. in einem bestimmten Zweig des Verzeichnisbaumes – an. Die Zugriffsrechte werden in einer bestimmten Konfigurationsdatei des LDAP-Servers hinterlegt. Siehe hierzu etwa http://www.openldap.org/doc/admin24/access-control.html.

Will man eine LDAP-Zugangsautorisierung über “Binds” generell nicht zulassen, so muss man “Binds” explizit in der Konfiguration des LDAP-Servers ausschließen. Dies ist bei der Standardeinrichtung von Opensuse 12.1 jedoch nicht der Fall. Die von YaST2 gesetzten Standardrechte bzgl. der im LDAP-System erfassten Linux-User- und Gruppen-Daten entscheiden letztlich darüber, ob Authentisierungs-Clients wie PAM sich über spezielle LDAP-Identitäten und zugehörige Binds Zugang zum LDAP-System verschaffen müssen. Bei Opensuse 12.1 ist ein lesendes Durchsuchen des gesamten LDAP-Baumes jedoch auch bei anonymen Zugriffen durchaus gestattet.

Die erste der oben genannten LDAP-Zugriffsvarianten wird in professionellen Umgebungen meist über das “SASL Authentisierungs- und Authorisierungs-Framework” und seine Untervarianten für die Authentisierung realisiert. Dabei werden ggf. SASL-eigene Datenbanken oder aber Zusatzsysteme wie Kerberos eingesetzt. Eine spezielle Variante für LDAP im Rahmen von SASL ist die sog. “External”-Variante, bei der SASL auf die eine User-Authentifizierung durch andere externe Layer oder Protokolle zurückgreift.

Bei Opensuse 12.1 greift die “External”-Variante für Root-Prozesse, die über ihre Systemberechtigungen authentisiert und für den LDAP-Zugang autorisiert werden. Hierbei wird
ein (lokales) IPC-Unix-Socket-basiertes Zugriffs-Protokoll namens “ldapi” eingesetzt, das auf der Unix-Interprozesskommunikation über Sockets basiert.

“SASL External” wird als Voreinstellung für die LDAP-Zugangs-Autorisierung von Prozessen eingesetzt, die mit Linux Root-Rechten laufen

Im Zuge einer initialen LDAP-Einrichtung sollte Root oder sollten Root-Prozesse mit Hilfe des “ldapadd”-CLI-Kommandos in der Lage sein, das LDAP-System und auch dessen modulare “cn=config”-Konfigurationsdateien zu modifizieren.

Deshalb werden lokale Root-Prozesse auf dem LDAP-Server unter Opensuse 12 standardmäßig über den SASL External-Mechanismus im Zusammenspiel mit dem IPC-Unix-Socket-ldapi-Interface für den Zugriff auf den LDAP-Server autorisiert.

Erreicht wird dies einerseits durch Einträge für den Start des LDAP-“slapd”-Dämons, bei dem auch das IPC-LDAPI-Protokoll für den Zugriff auf den LDAP-Server initialisiert wird (s. die Datei “/var/run/slapd/slapd.args”). Andererseits muss in den LDAP-Konfigurationsdateien ein Mapping der folgenden Form

gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth

vorgenommen werden. Wir kommen darauf weiter unten noch einmal explizit zurück.

Unabhängig von diesem Sonderfall erfolgen andere Zugriffe – u.a. auch die durch PAM ausgelösten Authentifizierungsanfragen von einem beliebigen Host aus – in der Standardeinstellung von Opensuse 12.1 aber lediglich über klassische “Binds”.

Punkt 2: Elementare Einrichtung und Konfiguration eines LDAP-Servers mittels YaST2

Nun die einzelnen Schritte zur initialen LDAP-Einrichtung unter Opensuse 12.1:

Schritt 1: Installieren bzw. Update der notwendigen Pakete

Als Kernpakete für die wichtigsten Einrichtungsschritte und später darüber hinausgehende Schritte sind empfehlenswert:

  • openldap2
  • libldap-2_4-2
  • openldap2-client
  • openldap2-doc
  • pam-ldap
  • nss_ldap
  • perl-ldap
  • yast2-ldap
  • yast2-ldap-client
  • yast2-ldap-server
  • cyrus-sasl-ldap-auxprop

Will man die Pakete nicht einzeln holen, ist es unter der YaST2-SW-Verwaltung sinnvoll, sich am Opensuse-SW-Pattern “Directory Server (LDAP)” zu orientieren. Die oben genannten Pakete sollte man sich natürlich auf dem neuesten Stand besorgen.

Schritt 2: Aufsetzen des Servers mittels YaST2

Die nachfolgenden Abbildungen zeigen den Durchgang durch eine erste LDAP-Server-Konfiguration mittels des Yast2-Moduls “LDAP-Server”. Hierbei haben wir als Base-DN des LDAP-Servers “dc=anracona,dc=de” angenommen. Ferner wird noch keine TLS-Konfiguration vorgenommen.

ldap_1

ldap_2

ldap_3

ldap_4

Das hier eingegebene Passwort für den LDAP-Admin mit der
DN

cn=Administrator,dc=anracona,dc=de

verwenden wir nachfolgend in einer Reihe von Einrichtungsschritten zur Authentisierung.

Nachtrag 17.06.2012 zum LDAP-Backend für die Datenhaltung:

Bei Opensuse 12.1 ist das Standard-Backend für das OpenLDAP-System die BDB [Berkeley Database]. Zu den heute möglichen Backend-Varianten siehe etwa http://linux.die.net/man/5/slapd.backends.

Auf der letzten der dargestellten Masken kann man zwischen speziellen Varianten der BDB wählen (“bdb” oder “hdb”). Zu der Backend-Variante HDB, die als echte hierarchische Datenbank realisiert ist und bei der man bei Bedarf auch ganze Zweige der späteren LDAP-Datenhierarchie umbenennen kann, siehe z.B. die Hinweise unter
http://www.highlandsun.com/hyc/ldapguide/backends.html,
http://onlamp.com/onlamp/2007/09/13/an-openldap-update.html und
http://www.gsp.com/cgi-bin/man.cgi?section=5&topic=slapd-hdb.
Man beachte insbesondere den Hinweis zur “idlecachesize” beim Performancetuning im ersten Link.

Direktiven zur Einrichtung der BDB-Backends findet man hier:
http://www.zytrax.com/books/ldap/ch6/bdb.html,
speziell für die “bdb” hier: http://linux.die.net/man/5/slapd-bdb
und für die “hdb” hier: http://linux.die.net/man/5/slapd-hdb.

Ich habe im oberen Beispiel die “hdb” gewählt. Lesern, die im ersten Schritt keine Experimente machen wollen, sei aber die “bdb” ans Herz gelegt.

Schritt 3: Starten des LDAP-Servers und Test der Verbindung über den YaST2 LDAP Browser

Wir prüfen nun, ob der LDAP-Server läuft, und zwar mittels des Kommandos :

rcldap status

und versuchen ggf., ihn danach mit

rcldap restart

zu starten. Das sollte bereits einwandfrei funktionieren.

Ein Test zur Verbindungsaufnahme ist möglich mit

ldapsearch -x -b ” -s base ‘(objectclass=*)’ namingContexts

vms2:~ # ldapsearch -x -b ” -s base ‘(objectclass=*)’ namingContexts
# extended LDIF
#
# LDAPv3
# base <> with scope baseObject
# filter: (objectclass=*)
# requesting: namingContexts
#
#
dn:
namingContexts: dc=anracona,dc=de
# search result
search: 2
result: 0 Success
# numResponses: 2
# numEntries: 1
vms2:~ #

Ein zusätzlicher Test ist auch möglich über den “Yast2 LDAP Browser”. Dort passen allerdings die generellen LDAP-Client-Einstellungen des Systems (noch) nicht. Deswegen fügt man über die Schaltfläche “Add” ein weiteres Zugriffsprofil mit einem beliebigen Namen (hier “X”) ein.

In unserem Testfall heißt der Server “vms2.anracona.de”. TLS ist abzuwählen.
ldap_6
Ein Drücken auf den OK-Button führt in unserem Fall zu folgendem Ergebnis:
ldap_7

Dass kaum etwas zu sehen ist, liegt natürlich daran, dass unser LDAP-
Verzeichnis noch so gut wie leer ist.

An dieser Stelle lohnt sich ein Blick in zwei Konfigurationsdateien, die von YaST angelegt wurden. Die erste Datei “/etc/openldap/slapd.d/cn=config.ldif” zeigt den Eintrag

olcAuthzRegexp: {0}gidNumber=0\+uidNumber=0,cn=peercred,cn=external,cn=auth dn
:cn=config

ldap_18

Dieser Eintrag ist typisch für das oben angesprochene “External Authentisierungs-Verfahren” für Prozesse mit Root-Rechten im Linux-System – hier über das IPC”-ldapi-Protokoll. Siehe zu Details die oben erwähnte Openldap2-Dokumentation.

Die zweite Datei “/etc/openldap/slapd.d/cn=config/olcDatabase={1}bdb.ldif” zeigt u.a. die Anlage des LDAP-Administrators und den Hash für das Passwort:

ldap_19

Weiter unten in dieser Konfigurationsdatei erkennt man übrigens die Vorgabe für die Anlage von Indices über bestimmte Felder der eingerichteten Account-Schemata.

Welche Standard-LDAP-Schemata für Objektklassen eingerichtet wurden, offenbart übrigens ein Blick in das Verzeichnis “/etc/openldap/slapd.d/”cn=config”/”cn=Schema”/. Es handelt sich um die Schemata

core, cosine, inetOrgPerson, rfc2307bis, yast

User werden später als Objekte, die die Eigenschaften einiger dieser Klassen kombinieren, angelegt. Dabei wird Konformität zu Posix-Accounts erreicht.

Die folgende Abbildung zeigt die Verzeichnisstruktur der Konfigurationsdateien und noch einmal die von Opensuse installierten Standardschemata:

ldap_20

Schritt 4: Einrichtung der Yast2 “User- und Gruppenverwaltung” auf dem LDAP-Server als LDAP-Client

In diesem Schritt binden wir das Yast2-Modul für die User- und Gruppen-Verwaltung an den LDAP-Server an. Hierbei wird ein wesentlicher Teil der LDAP-Client-Einrichtung auf unserem lokalen Opensuse 12.1-Testsystem vorweggenommen.

Natürlich greifen die YaST-Clients unseres LDAP-Servers eigentlich nur auf den “localhost” (127.0.0.1) zu.

Die dargestellten Prinzipien gelten aber analog auch für Opensuse-Systeme, deren YaST-Module Zugriffe auf Remote-LDAP-Server durchführen sollen. Die nachfolgenden Schritte lassen sich deshalb später auf andere, externe Opensuse-Systeme übertragen, von denen mit den dortigen YaST-Tools User- und Gruppen-Accounts auf unserem frisch eingerichteten LDAP-Server angelegt werden sollen.

Wir öffnen auf unserem LDAP-Server die Yast2-User-und Gruppenverwaltung und gehen dort auf den letzten Reiter.

ldap_8

Dort klicken wir nun auf den Link “LDAP” (oder gehen alternativ über den Configure-Dialog):
ldap_9

Hier klicken wir TLS im Moment weg. Auch mit SSSD und Kerberos wollen wir uns in diesem Beitrag nicht befassen.

Von relativ Bedeutung ist, dass man bereits jetzt die Adressangabe bzgl. des Servers unter Benutzung der FQD-Form machen sollte. In den von Opensuse vorgenommenen Standardeinstellungen werden später, wenn wir TLS benutzen, Vergleiche des LDAP-Peer-Namens mit der im Server-Zertifikat überlicherweise verwendeten FQD-Bezeichnung vorgenommen. Die Bezeichnungen müssen übereinstimmen, wenn man in den LDAP-Einstellungen keine besonderen Vorkehrungen treffen will.

Wir klicken nun auf die Schaltfläche “Advanced Configuration” und lassen dort die Einstellungen des Reiters “Client Settings” unverändert.

ldap_10

Nun wechseln wir zum Reiter “Administration Settings” und geben die Daten zur Administrator-DN ein.

ldap_11

Wir drücken den Button “Configure User Management Settings” und geben im erscheinenden Dialog das Passwort ein:

ldap_12

Wir bestätigen die nächste Frage:

ldap_13

Auf der folgenden Optionen-Seite legen wir nichts Neues an; wir drücken auf OK

ldap_14

Danach drücken wir in 2 weiteren Rücksprung-Dialogen ebenfalls auf OK und erhalten am Schluss einen konfigurierten LDAP-Client für die User- und Gruppen-Verwaltung von YaST :

ldap_15

Wir drücken erneut auf OK und wechseln zur Userverwaltung unseres Testsystems. Dort drücken wir auf den Button “Filter” und wählen “LDAP Users” und geben erneut das LDAP-Admin-Passwort ein:

ldap_16

Wir sind dann im (noch leeren) Bereich derjenigen User auf unserem System, die über unseren LDAP-Server verwaltet werden. Wir legen testweise einen neuen, ersten Useraccount im LDAP-System an:

ldap_17

Für diesen User testen wir abschließend und hoffentlich erfolgreich einen Login-Versuch auf unserem LDAP-Server-System und freuen uns, dass wir unsere User zumindest auf diesem System künftig mit YaST und LDAP verwalten können.

Im nächsten Teil stellen wir den LDAP-Server für die sichere (Remote-) Nutzung auf SSL/TLS um.

OX 5 – LDAP Restaurierung nach Fehler

Posted on by

Gestern hatte ich nach 6 Jahren erstmals ein größeres LDAP-Problem mit unserem alten OX5-Server.

Meine Kollegin hatte versucht, eine neue Mail-Adresse auf dem OX 5 Server von Kontakt/Kmail eines Client-Rechners aus zu speichern. Dabei wird ein neuer Kontakt angelegt, dessen Daten bei meinem OX 5 sowohl in der Postgres-Datenbank als auch in einer LDAP-Datenbank hinterlegt werden.

Leider hatte die Kollegin die Mail von einem Outlook-Benutzer erhalten, der seine Adressangaben recht chaotisch gepflegt hatte. Seine “von”-Adresse wies eine Angabe der Form “mailto:xxx@yyy.com” auf. Unvorsichtigerweise hat meine Kollegin zur Übernahme der Mailadresse in das Kmail-Adressbuch (das eigentlich ein OX-Adressbuch ist) wie gewohnt mit der rechten Maustaste auf diesen “mailto-Link” im Adressbereich der an sie weitergeleiteten Mail geklickt. Dies hatte schlimme Folgen:

Der Speichervorgang für den neu anzulegenden “Kontakt” in den Kontakte- und Adressen-Verzeichnissen des OX5 Servers wurde leider nicht korrekt abgearbeitet. Als resultierende Symptome musste ich nach einiger Analyse von Log-Dateien des Servers leider einen traurigen Zustand feststellen:

  • Absturz von Tomcat
  • Korrumpierte LDAP-Datenbank
  • Massive Performancereduktion des OX-Servers wegen hängendem LDAP

Für die, die hier evtl. schlimmere Dinge vermuten: Ein Virenscan der Mail mit unterschiedlichen Scannern hat nichts erbracht.

Wegen der korrupten LDAP-Datenbank war auf dem OX5-server natürlich auch keinerlei Login mehr für die OX-User möglich, da diese alle über LDAP verwaltet und über “pam-ldap” authentisiert werden. User auf externen Servern konnten daher weder Dienste des OX-IMAP-Servers, noch Samba- und NFS-Dienste nutzen. Hier war schnelle Abhilfe von Nöten.

Die Lösung brachte hier (SUSE-SLES-System) folgende Kommandosequenz :

cd /var/lib/ldap
rcldap stop
db_recover -v
slapindex
rcldap start

LDAP unter Opensuse und auf SLES-Systemen nutzt defaultmäßig die Berkely DB als Backend zur Datenhaltung. Damit ist das Kommando “db_recover” angesagt. ( Unter Red Hat ist übrigens statt “db_recover -v” das Kommando “/usr/sbin/slapd_db_recover -h /var/lib/ldap ” einzusetzen.)

Für “katastrophale” Fälle kann man auch – nach weiteren Sicherungsmaßnahmen (! siehe die Links unten !) – die Variante

db_recover -v -c

verwenden. “-c” steht hier für “catastrophic”.

Will man das Kommando von einem anderen Ort als dem Verzeichnis “/var/lib/ldap” ausführen, so ist die Option “-h” nützlich.

Weitere Informationen – auch für hartnäckige Fälle der Restaurierung der LDAP Backend Datenbank – liefert die Artikel unter folgenden Links:

http://sdb.open-xchange.com/node/29
http://blog.mydream.com.hk/howto/linux/openldap-recovery-howto

Zu den Optionen von “db_rcover” für die BDB siehe :

http://www.manpagez.com/man/1/db_recover/

Weitere Informationen zur Fehlerbehebung findet man unter:

http://techarold.blogspot.com/2006/07/more-openldap-recovery.html
http://www.prestonlee.com/2009/07/08/recovering-a-corrupt-openldap-database-on-osx-server/
http://serverfault.com/questions/87889/ldap-database-recovery-after-server-crash
http://
web.archiveorange.com/archive/v/TDuKz11zCkpKFJNjBppH
http://www.bynari.net/support/users/kb.php?id=236

Generelle LDAP-Admin-Informationen findet man unter :

http://www.openldap.org/doc/admin24/

Zum Einsatz der BDB als LDAP-Backen siehe:

http://www.zytrax.com/books/ldap/ch6/bdb.html

Kmail 4.8 – Suchfunktionalität weiterhin im Eimer

Posted on by

Seit der Umstellung auf das akonadi-basierte Kmail2 (unter Opensuse passierte das nach KDE 4.6.4) gibt es Probleme mit der Suche nach Mails unter Kmail. Diese Feststellung ist mehr als traurig, denn im täglichen professionellen Einsatz von Mail-Programmen benötigt man Suchfunktionen, die einen schnell mehrere Suchkriterien miteinander kombinieren lassen – z.B. für den Mail-Text und für das Absender-Feld.

Kmail 1.13.7 wies hierfür einen voll funktionsfähigen eigenen Such-Dialog auf. Auf einem unserer Rechner ist die alte Version noch unter KDE 4.6.4 installiert. Da läuft alles noch prima – auch im Zusammenspiel mit IMAP-Servern.

Wie ist der Zustand seit KDE 4.7 und auch jetzt noch unter KDE 4.8 ?

  • Weder unter Kmail 4.7.4 noch unter Kmail 4.8 gibt der Suchdialog einem eine Möglichkeit zur Eingabe eines Mailverzeichnisses, den man durchsuchen will.
  • Wenn gesucht wird, so wird (manchmal) in allen Mailverzeichnissen gesucht.
  • Unter KDE 4.7.4 liefern viele Suchvorgänge Ergebnislisten mit leeren Zeilen am Anfang.
  • Unter KDE 4.8 liefert eine Suche mit mehreren kombinierten Such-Kriterien leere Resultsets, obwohl es viele Mails gibt, die die Kriterien erfüllen.
  • Manche Suchen nach Begriffen im vollständigen Mailtext liefern Resultsets – aber auch die nicht immer zuverlässig. Die Suchergebnisse sind nicht immer vollständig.

Das Ganze ist so fehlerhaft, dass man den Suchdialog unter Kmail im Moment als nicht benutzbar ansehen muss. Im Grunde ein Desaster! Hingewiesen hat mich darauf übrigens Martin Lüchem. Ich wollte es ihm zunächst gar nicht glauben, aber leider hat er recht.

Die einzige Suche, die bei mir z.Z. noch funktioniert, ist die über die Eingabezeile im normalen Kmail-Fenster. Das ist eine Volltext-Suche. Die scheint zu klappen. Aber wie gesagt, das reicht für den professionellen Einsatz überhaupt nicht.

Da fragt sich der KDE-Anwender erneut: Wie kann es sein, dass sich solche Mängel über zwei größere Releases von KDE 4 hinweg halten können?

Update KDE 4.8 – Nepomuks hohe CPU-Last

Posted on by

Habe gerade unter Opensuse 12.1 auf KDE 4.8 upgegraded. Danach erzeugt Nepomuk samt virtuoso-t ähnlich wie früher bei KDE 4.6 eine enorm hohe CPU-Last, die sich leider nicht so ohne weiteres beseitigen lässt.

Bei mir hat folgendes geholfen:

  • Stoppen von Nepomuk über die KDE-Systemeinstellungen.
  • Stoppen von Akonadi (man benutze das Kommando “kcmshell4 kcm_akonadi”,
    gehe dann im sich öffenenden Fenster auf den 2-ten Reiter für die “Einrichtung des Akonadi-Servers”
    und stoppe dort den Akonadi-Server).
  • Zur Sicherheit : Herunterfahren in den Runlevel 3
  • Löschen des Verzeichnisses ~/.kde4/share/apps/nepomuk
  • Löschen aller Konfigurationsdateien der Form ~/.kde4/share/config/nepomuk*
  • Löschen aller Konfigurationsdateien der Form ~/.kde4/share/config/akonadi_nepomuk_*
  • Hochfahren in den Runlevel 5 und Log in in den KDE-Desktop.

Danach wurden bei mir neue Konfigurationsdateien angelegt und auch das Nepomuk-Verzeichnis wurde erneuert.

Nepomuk begann dann mit einer Reindizierung aller möglichen Ressourcen, aber beanspruchte die CPU dabei viel, viel weniger als zuvor. Ferner verhält sich Nepomuk jetzt bei mir sogar adaptiv und begrenzt die CPU-Belastung auf Zeiten, in denen ich mit anderen Programmen nicht so viel macht.

Siehe hierzu auch https://bugs.kde.org/show_bug.cgi?id=289932, Kommentar #3 und weitere Kommentare.

Schade, dass die KDE-Entwickler immer wieder solche Schnitzer produzieren. Es muss doch möglich sein, die Programme neuer Versionen so zu gestalten, dass es möglich wird KDE-Updates durchzuführen, ohne Konfigurationsdateien von Schlüsselkomponenten löschen und neu anlegen zu müssen.

Nachtrag 15.02.2012:

Ich habe ein anderes System, auf dem folgende Voraussetzungen gegeben waren:

1) Opensuse 12.1 wurde von scratch neu installiert – und zwar zunächst ohne KDE, aber mit XFCE.
2) Danach habe ich direkt KDE 4.8 aus dem Repository http://download.opensuse.org/repositories/KDE:/Release:/48/openSUSE_12.1/ installiert. Es gab also kein Update von KDE 4.7.2.

Nach der Anbindung an einen IMAP-Server begann der Nepomuk-Indexer zu arbeiten und zwar ziemlich lange. Als nach ca. 30 Minuten kein Ende absehbar war, bin ich in die KDE-Systemeinstellungen (“systemsettings”) gegangen und dort in die Einstellungen zur “Desktopsuche”. Dort habe ich in der angegebenen reihenfolge folgende schritte durchgeführt:

  • Deaktivierung des Punktes “E-Mail-Indexer aktivieren” -> Button “Anwenden”
  • Deaktivierung des Punktes “Nepomuk-Datei-Indexer aktivieren” -> Button “Anwenden”
  • Deaktivierung des Punktes “Nepomuk-Semantik-Dienste aktivieren” -> Button “Anwenden”

Danach geht die CPU-Belastung durch Nepomuk auf 0. U.a. ist der Email-Indexer gestoppt. Dann habe ich folgendes gemacht:

  • Aktivierung des Punktes “E-Mail-Indexer aktivieren” -> Button “Anwenden”
  • Aktivierung des Punktes “Nepomuk-Datei-Indexer aktivieren” -> Button “Anwenden” und Durchlaufen lassen ! Ggf. über “Erweiterte Einstellungen” den verzeichnisbereich, der indiziert wird, einschränken.
  • Aktivierung des Punktes “E-Mail-Indexer aktivieren” -> Button “Anwenden”

Danach war Ruhe und die hohe CPU-Belastung durch virtuoso-t / nepomuk ging auf fast 0! Vermutlich wurde der erstmalige Neuindizierungsprozess von Nepomuk (kontrolliert?) abgebrochen. Danach scheint es aber leider so, dass der Email-Indexer gar nicht mehr läuft – zumindest werden bei Suchvorgängen nach Begriffen
im Text von Emails keine Treffer mehr unter neuen Emails gefunden.

Posted in KDE

Opensuse 12.1 – Installationserfahrungen

Posted on by

In der letzten Zeit habe ich mehrere Systeme auf Opensuse 12.1 upgraden müssen. Zudem habe ich zwei komplette Neuinstallationen vorgenommen. Zeit mal etwas über meine Erfahrungen zu schreiben – im speziellen auch zum neuen Startup-Verfahren “systemd”. In diesem Artikel geht es um eine Neuinstallation von Opensuse 12.1 auf einem System mit folgenden Charakteristika:

Quadcore CPU Intel Q9550, 8GB RAM, 3ware Raid-Controller mit 4 2TB-Platten im Raid 10 Modus, Nvidia Grafikkarte EVGA 9800GTX+ an einem 1920×1200 Schirm.

Ich möchte hier das System nur soweit installieren, dass mindest die Grafikkarte läuft, die Anbindung ans Netz erfolgt ist und ich in der Lage bin, einen Vergleich der Startup-Zeiten zwischen “systemd” und dem konventionellen “System V Init”-Verfahren durchzuführen.

Ergänzung 04.10.2012:

Wer sich für kritische Betrachtungen zur “systemd”-Einführung interessiert, kann gerne auch meinen Beitrag

Opensuse 12.1, systemd, shutdown, apache

lesen, in dem ich meinen Eindruck nach etwa einem halben Jahr “systemd”-Nutzung unter Opensuse 12.1 zusammengefasst habe.

Potentiell problematisch sind für eine Opensuse-Installation sind an der Hardwareliste zwei Dinge:

Einerseits das Raid 10-System – das Raid-Array entspricht netto einer Platte mit einem Plattenplatz oberhalb von 3,8 TB . D.h. “fdisk” fällt als Formatierungstool aus; es wird “GPT” benötigt. Hier ist aber Optimismus angesagt, denn der Opensuse-Installer bindet mindestens seit Opensuse 11.3 automatisch GPT ein, wenn er eine entsprechend große Platte erkennt. Das Gleiche gilt natürlich auch für den “Partitionierer” unter Yast. Aber man wiss ja nie …

Schwierigkeiten kann ebenfalls die EVGA-Grafikkarte machen. Bei früheren Installationen hatte ich mit dieser Karte regelmäßig Probleme mit dem 1600×1200-Framebuffer-Modus. Dieser wird von Opensuse aber als Modus mit der maximalen Auflösung angeboten – im besonderen für die Konsolen-Darstellung. Den hochauflösenden Modus möchte man natürlich auch gerne ausnutzen – oft genug mußte ich früher aber schon auf den 1280×1024-Modus ausweichen. Hier war ich gespannt, wie sich der “Opensuse 12.1”-Installer verhält und wie man den Nvidia-Treiber zum Laufen bringt.

Positive Punkte während der Installation

Der 1600×1200 Modus wird während der Installation auch bei der EVGA-Karte weitgehend akzeptiert

Ich konnte im graphischen Installer die Auflösung 1600×1200 wählen. Dies machte bis zum Neustart des installierten Systems über “kexec” auch keine Probleme – weder in zwischenzeitlichen Konsol-Ansichten noch im grafischen Modus selbst.

Die Formatierung des netto 3.8 TB umfassenden zusammenhängenden Raid-Arrays gelang ohne jegliche Probleme

Das Raid 10-System ist bei einer Frmwareversion “FE9X 4.10.00.007” des 3ware-Raid-Controllers recht performant – die Schreibraten liegen um die 220 – 250 MB/sec, die Leseraten sind noch höher. Mehr kann man bei den eingesetzten Samsung “2TB F4 HD204UI”-Platten einfach nicht erwarten. Es wäre schade gewesen, wenn das SuSE-System damit nicht hätte umgehen können. Aber weder der Installer noch der “YAST-Partitioner” hatten damit Probleme – wie erwartet benutzen beide automatisch GPT. Ich habe meiner Standardpolitik folgend, mehrere (genauer 4) 80 GB-umfassende Standard-Partitionen am Anfang des Arrays und danach einen großen LVM-Bereich zur Aufnahme flexibel erweiterbarer
Partitionen für Daten und spätere virtuelle KVM-Maschinen anlegen können. Es gab dabei keinerlei Schwierigkeiten.

Ergänzung 13.12.2012 zur “GPT-Partitionierung”:
Das System hat ein Gigabyte Board, das noch mit einem konventionellen BIOS betrieben wird. (Es gibt inzwischen zwar EFI-Updates von Gigabyte. Ich habe die aber nicht benutzt.) Die Reaktion des SuSE-Partitioners auf die Aufgabe, einen 3.8 TB-Platte mit einem BIOS zu kombinieren, war die Anlage eines sog. “Hybrid MBR”. Ich möchte an dieser Stelle darauf aufmerksam machen, dass ein “Hybrid MBR” nicht ohne Tücken ist: So kann man ein Booten aus Partitionen jenseits der ersten 3 in der Regel komplett vergessen – sowohl mit dem herkömmlichen Grub als auch mit bestimmten Grub2-Varianten.

Falls sich jemand fragt, woher die “Politik” mit den 4 Standardpartionen stammt:

Ich bringe hier bootfähige Fallbacksysteme unter, die in Notfällen in der Lage sein müssen, auch Daten in einem bestimmten Umfang aufzunehmen. Die Fallback-Systeme bestehen meist aus Abbildern bewährter Versionen auf einem bestimmten Update-Stand in Kombination mit bewährten KDE-Versionsständen. So komme ich bei größeren Problemen – wie sie im besonderen relativ häufig bei KDE-Upgrades auftreten – oder auch bei Schwierigkeiten mit LVM-Partitionen relativ schnell wieder zu laufenden Systemen, ohne komplette Neuinstallationen oder eine vollständige Restauration von Backups durchführen zu müssen. Hat man Sicherungen seiner Datenpartitionen auf Platten separater externer Systeme untergebracht, oder sind die Datenpartitionen selbst unbeschadet, so erledigt sich die Arbeit meist schon durch Einbinden der Datenpartitionen (ggf. über NFS). Abbilder der Systeme (z.B. per dd) haben sich in der Praxis schon mehrfach bewährt, wenn ein KDE-Upgrade das aktuelle System fast in die Unbenutzbarkeit getrieben hat.

Die Installation geht relativ zügig vonstatten

Aufgrund der hohen Performance des Raid 10-Arrays wird die Installation auch beim Laden vieler Serverkomponenten etc. zügig abgewickelt. Bei der vorgenommenen Installation habe ich praktisch alle relevanten Serverkomponenten sowei eine große Zahl von Entwicklungskomponenten mit installieren lassen. Insgesamt 3,6 GByte an Paketen. Das ging wirklich schnell. Ist aber kein spezielles Verdienst von SuSE.

Probleme während der Installation

Die Weiterführung der grafischen Installation nach Ausführung von “kexec” bringt das System zum Sillstand

Nach der Installation aller Pakete versucht der Installer den neuen Kernel mit “kexec” zu laden und danach das neue System hochzufahren. Hierzu wird temporär auf die Konsolenansicht gewechselt. Danach sollte eigentlich die grafische Installationsoberfläche im aktualisierten System erneut gestartet werden; im Anschluß daran sollte die Konfiguration des neuen Systems (Geräteerkennung und Treiberimplementierung) erfolgen.

Der Wechsel des Installers auf die Konsole für die Durchführung von “kexec” funktionierte. Der Kernel wurde ordnungsgemäß mit “kexec” geladen. Danach werkelte das System noch fleissig im Verborgenen (aha – die erste Anzeichen von systemd – keine Meldungen mehr auf der Konsole!) – und dann wurde der erneute Start der grafischen Installer-Oberfläche eingeleitet. Bei mir endete das aber leider mit eine hübsch bunten Schirm aus Fragmenten und einem Einfrieren des Systems. Das System (besser X-Window) reagierte auch nicht mehr auf Tastatureingaben – ein “Ctrl-Alt-D” für ein geordnetes Herunterfahren blieb wirkungslos. Ich war also gezwungen, die Installation abzubrechen und einen Warmstart durchzuführen.

Ich möchte an dieser Stelle klarstellen, dass dieses Problem meiner Meinung nach vor allem durch
die EVGA Grafikkarte meines Testsystems bedingt ist. Denn auf anderen Systemen mit moderneren Nvidia-Karten trat das hier beschriebene Problem bei einer Neuinstallation vom Opensuse 12.1 nicht auf. Je nach Treibermodul (nouveau) hat die Karte halt doch immer mal wieder Probleme beim Wechseln zwischen dem 1600×1200-Framebuffermodus für die Konsole und dem grafischen Installationsmodus.

Warmstart und erneutes Booten nach System V-Manier ermöglichen nach ein paar Maßnahmen die Fortführung der grafischen Installation

Was macht man in einer solchen Situation, in der man zu Beginn der automatischen Konfiguration zum Warmstart gezwungen wird? Das danach möglicherweise inkonsistente Filesystem macht einem wenig Sorge; das schafft ext4 schon. Ein fsck-Vorgang geht auf dem Raid-System zudem sehr, sehr schnell. Aber wie geht man mit dem dem offenbar problematischen Standard-Grafiktreiber (Nouveau) für die Grafikkarte um?

Meine Schritte waren folgende:

Schritt 1:
Nach dem Warmstart boote ich nur in den Runlevel 3 und zur Elimination von Unwägbarkeiten zusätzlich auf “systemd” verzichten. Ersteres erreicht man durch Eingabe des Parameters “linux 3” in die Parameterzeile des Grub-Startup-Schirms. Und für das zweite hat SuSE dankenswerterweise eine Option angeboten. Man kann auf dem Startbildschirm “F5” betätigen und danach “System V” auswählen. Alternativ gibt man als Parameteroption

init=/sbin/sysvinit

ein. Dann wird der Startvorgang nach alter “System V”-Manier durchgeführt.

Der “System V”-Bootvorgang in den Runlevel 3 erfolgte dann problemlos. Das war auch fast zu erwarten, da die Darstellung der Konsole schon während des ersten Installationsanlaufes keine echten Probleme bereitet hatte. Der grafische Installationsvorgang wurde aber nicht sofort fortgesetzt.

Schritt 2:
Im nun erreichten Runlevel 3 habe ich als ersten geprüft, welches Grafikkartenmodul geladen war. Es war – wie vermutet – das “nouveau”-Treiber-Modul, das SuSE ja seit 11.4 als Default einsetzt. Dieses Treibermodul ließ sich auch nicht entladen – es wurde bei einem “rmmod”-Versuch als “in use” deklariert. Mit einer solchen Situation kann auch der Nvidia-Treiber-Installer nicht umgehen. Deshalb war ein erneuter Bootvorgang von vornherein unausweichlich. Als beste Methode, das System von einer Fortführung der Installation zu überzeugen, erschien es mir nach früheren Erfahrungen, KMS abzuschalten und auch die Pakete für den “Nouveau”-Treiber zu entfernen. Also habe ich mit

“Yast >> /ect/sysconfig-Editor >> System >> Kernel”

den SuSE-Konfigurationsparameter

“NO_KMS_IN_INITRD” auf “Yes”

gesetzt. Ferner habe ich über das Yast-Softwaremanagement das Paket

xorg-x11-driver-video-nouveau”

deinstalliert. Alles in der Hoffnung, dass das System nun erkennen würde, dass die automatische Konfiguration noch nicht durchgeführt oder abgeschlossen wurde. Typischerweise erkennt das SuSE-System das nämlich (wo immer SuSE diese Info hinterlegt wird).

Schritt 3:
Ich habe dann neu gebootet – wiederum mit den Parametern “linx 3 init=/sbin/sysvinit”. Und tatsächlich: Diesmal wurde direkt nach dem Hochfahren eine Meldung angezeigt, dass der Installationsvorgang wegen eines Fehlers nicht abgeschlossen wurde. Danach erfolgte direkt der Wechsel in den grafischen Modus zur Fortsetzung der automatischen Konfiguration. Die wurde auch ohne Fehlermeldungen abgeschlossen. Ein weiterer Bootvorgang in den Runlevel 3 verlief dann ohne Fehler.

Auf diese Weise hatte ich wenigstes die Installation ordnungsgemäß abgeschlossen. Ein “lsmod | grep nouveau” zeigte aber, dass nun immer noch (oder erneut?) der “nouveau”-Treiber geladen war. Dies war insofern überraschend als wir ja
zumindest einen entsprechenden Kernelparameter gesetzt hatten, der zu einer Deaktivierung von KMS führen sollte. Ich habe die Einstellungen erneut mit dem sysconfig-Editor geprüft. Auch “/sbin/mkinitrd” wurde am Ende der Einstellungen im sysconfig-Editor korrekt aufgerufen.

Dennoch wird also der Nouveau-Treiber geladen. Diese Ungereimtheiten kannte ich schon von Opensuse 11.4; siehe auch:

http://www.linuxforen.de/forums/archive/index.php/t-269600.html
und
http://de.opensuse.org/SDB:Probleml%C3%B6sungen-Grafiktreiber

Aus meiner Sicht reicht das Abstellen von KMS nicht; man muss den Treiber zusätzlich “blacklisten”. Dafür gibt es mehrere Möglichkeiten – man findet einige in den Beiträgen unter folgendem Link :

http://www.linuxforen.de/forums/showthread.php?t=269600

Man kann das “Blackliste” aber auch der Nvidia-Installationsroutine für den proprietären Treiber überlassen. Die setzt nämlich bei entdecktem “Nouveau”-Treiber auf Rückfrage beim User ebenfalls einen Blacklisting-Eintrag.

Das nächste größere Ziel war nun die Ersetzung des “nouveau”-Treibers durch den proprietären Treiber. Hierzu musste das neu installierte System erst einmal netzwerkfähg werden. In meinem Fall wollte ich den benötigten Treiber nämlich einfach per “scp” von einem anderen System kopieren. Hierzu muss man neben den Netzwerkeinstellungen auch den sshd-Daemon zum Laufen bringen. (Ein Treiberdownload per Browser kam erstmal nicht in Frage, da ja nicht klar war, ob der Nouveau nicht erneut Probleme machen würde.)

Netzwerk, sshd, IPV6 und Probleme mit dem dsa-key

In meiner Testinstallation schlägt die standardmäßige DHCP-Konfiguration fehl, weil sowohl auf unserem Router als auch dem Standard-DHCP-Server des Netzes unsere “iptables”-basierten Firewalls nur uns bekannte MAC-Adressen zulassen. Für den Nvidia-Test trage ich deshalb die IP(V4)-Adresse auf dem neuen System zunächst von Hand, und zwar mittels “Yast >> Netzwerkeinstellungen” ein – und gleich auch noch das Standardgateway sowie einen DNS-Server. Alles wie von früheren Opensuse-Installationen her gewohnt – das Setzen der Parameter funktionierte einwandfrei. (Nach der Freigabe der MAC-Adresse der Netzwerkkarte auf dem Router (Standard-Gateway) kann der PC dann auch auf das Internet zugreifen.)

Noch ein wichtiger Hinweis zu IPV6:

Man sollte beim Einstellen der Netzwerkparameter im ersten Anlauf IPV6 nicht deaktivieren (dies wäre bei “Yast >> Netzwerkeinstellungen” unter “Globale Optionen” möglich). Man läuft sonst in Schwierigkeiten beim Einsatz von “ssh -X” von Remotesystemen aus. Ferner entsteht ein kleines Problem bei Postfix, dass sich ggf. nicht mehr ordnungsgemäß starten läßt.

Zur Lösung des ssh/sshd-Problems siehe einen früheren Blog-Beitrag :

https://linux-blog.anracom.com/2012/01/03/opensuse-114121-problem-mit-ssh-x/

Dort wird auch einen Fehlermeldung beim Starten des “sshd”-Daemons bzgl. eines nicht gesetzten bzw. nicht ladbaren “DSA keys” behandelt.

Zum Postfix-Problem bei deaktiviertem IPV6 siehe dagegen die Kommentare unter

http://www.linux-club.de/viewtopic.php?f=5&t=114733

Nun starte ich schließlich nach den im anderen Blogbeitrag beschriebenen Maßnahmen zu ssh den sshd-Daemon “rcsshd start”. Von einem Remotesystem aus kopiere ich mir nun die Nvidia-Treiberdatei mittels

scp QUELL_PFAD_NVIDIA_TREIBER_DATEI UID@12.1_HOST:/ZIEL_PFAD_NVIDIA_TREIBER_DATEI

auf mein Opensuse 12.1-System. (Die groß geschriebenen Parameter sind natürlich an die jweiligen lokalen Verhältnisse anzupassen.)

Installation des Nvidia-Treibers

Welcher Treiber ist der
richtige? Hier ist nach einem Fehlversuch meinerseits darauf hinzuweisen, dass mit dem 3.1.0-Kernel von Opensuse 12.1 für neuere Grafikkarten nur der proprietäre Treiber ab der Version 290 kompatibel ist.

Dann teste ich im Runlevel 3 mal mit

sh NVIDIA-Linux-x86_64-290.10.run

ob eine Installation möglich ist. Natürlich nicht, da der Nouveau-Treiber ja noch geladen ist. Den Vorschlag des Nvidia-Installers, einen entspechend notwendigen Eintrag in Startup-Dateien vorzunehmen (Blacklisting des nouveau-Moduls), bestätige ich. Dann starte ich das System neu – nun auch noch zusätzlich mit dem Parameter “nomodeset”, also

linux 3 nomodeset init=/sbin/sysvinit

Danach probiere ich die Nvidia-Installation nochmals. Das funktioniert nun, der Nouveau-Treiber wird nicht mehr geladen. Ggf. zeigt der Nvidia-Installer während des Installationsvorgangs eine Warnmeldung wegen eines Symbolic-Links. Dies passiert oft, wenn zuvor ein anderer Nvidia-Treiber – aus einer anderen Quelle – geladen war. Der Nvidia-installer korrigiert selbständig den bemängelten Link. Dann ggf. zur Sicherheit die Treiber-Installation nochmals durchführen. Die Warnmeldung sollte dabei nicht mehr auftauchen. Auf meinem System musste ich nach Abschluß des Nvidias-Installers das Modul “nvidia.ko” übrigens per

modprobe nvidia

selbst laden. Der 290-Installer hatte dabei Probleme – und zwar auf mehreren Systemen – auch mit anderen Grakas. Das “modprobe”-Kommando läuft dann aber ohne Probleme.

Ein abschließendes “init 5” befördert uns danach vom Runlevel 3 in den Runlevel 5 – und dort wie erwartet endlich in den grafischen Login-Screen von kdm. Auch der nächste Reboot sowohl mit

nomodeset init=/sbin/sysvinit [>>> konventioneller System V Start]

als auch

nomodeset [>>> systemd – Start]

als Parametern läuft dann fehlerfrei bis auf den Runlevel 5 durch.

Bis auf die oben schon genannten Themen mit der Deaktivierung von IPV6 verhält sich das Opensuse-System dann im wesentlichen wie von Opensuse 11.4 her gewohnt.

Zeitvergleich zwischen Bootvorgängen mit “Systemd” und “System V init”

Nun trage ich noch die Parameter “nomodeset init=/sbin/sysvinit” mit Hilfe von “Yast >> bootloader >> Weitere >> Konfigurationsdateien bearbeiten” permanent für den Opensuse 12.1-Eintrag des Boot-Menüs in die Datei “/boot/grub(menu.lst” ein. Will ich künftihg ein wenig mit “systemd” herumexperimentieren, kann ich den Parameter auf dem initialen Bootscreen immer noch manuell löschen.

Diese Wahlmöglichkeit nutze ich als erstes für einen Zeitvergleich. Ich möchte gerne wissen, was mir “systemd” außer der Tatsache, dass ich keine Meldungen während des Bootvorgangs mehr sehe, an Performance beim Booten bringt. Als erstes sehe ich mir die Zeit an, die vergeht bis nach dem Start aus dem Grub-Menü heraus der KDM-Login-Schirm erscheint. Das ernüchternde, etwas subjektive und handgestoppte Ergebnis ist:

  • Booten in den Runlevel 5 mit konventioneller Methode: 20 Sek
  • Booten in den Runlevel 5 mit “systemd”: zw. 15 und 16 Sekunden

Im besten Fall !

Fairerweise muss man sagen, das beim Starten des X-Window-Systems Zeit vergeht, die nicht allein von systemd sondern von der Grafikkarte, dem Treiber und dem angeschlossenen Schirm abhängt : wir sprechen hier von ca. 4 Sekunden. Das passt zum Eintrag in “/var/log/messages”:

Jan 8 13:15:59 xen systemd[1]: Startup finished in 4s 211ms 950us (kernel) + 6s 583ms 110us (userspace) = 10s 795ms 60us.

Deshalb dachte ich, dass man einen faireren Vergleich dann bekommt, wenn man mit den
unterschiedlichen Startvarianten nur in den Runlevel 3 hochfährt. Also habe ich die Vergleichsläufe erneut mit “linux 3” als Startparameter durchgeführt. Und da erhielt ich dann ein wahrhaft schockierendes und für mich überhaupt nicht mehr nachvollziehbares (aber reproduzierbares) Ergebnis:

  • Booten in den Runlevel 3 mit konventioneller Methode: 13 Sek
  • Booten in den Runlevel 3 mit “systemd”: > 38 Sek

Tatsächlich finde ich in “/var/log/messages” folgenden Eintrag:

Jan 8 13:40:27 xen systemd[1]: Startup finished in 4s 163ms 726us (kernel) + 34s 824ms 357us (userspace) = 38s 988ms 83us.

Damit hatte ich erstmal genug von “systemd”! Was immer die Opensuse-Entwickler da fabriziert haben. Das wirkt nicht ganz ausgreift- trotz schöner Artikel wie etwa unter folgender Adresse:

http://news.opensuse.org/2011/12/22/systemd-%e2%80%93-boot-faster-and-cleaner-with-opensuse-12-1/

Man lese aber auch mal die anschließenden Kommentare!

Hinzu kommen richtig ernsthafte Probleme mit systemd beim Upgrade von komplexeren Opensuse 11.4-Systemen auf Opensuse 12.1. Dazu aber mehr in künftigen Beiträgen.

Erstes Fazit

Bei Schwierigkeiten während der Installation hilft es ggf. mit “F5” und auf konventionelle Weise zu booten.

Der Nouveau-Treiber kann während der Installation im Zusammenspeil mit bestimmten Grafikkarten erhebliche Probleme bereiten. Für Nvidia-Karten muss man nach der Installation von Opensuse 12.1 den neuesten proprietären Treiber der Version 290 installieren. Frühere Treiber laufen nicht mit dem neue Kernel.

Die größte Neuerung von Opensuse 12.1, nämlich “systemd” verbessert den Startvorgang -auf einem elementaren System, auf dem keine Serverkomponenten geladen werden. Der sowieso schon schnelle Startup wird beschleunigt – allerdings nicht um weltbewegende Faktoren. Die Verbesserung wird zudem auf einem frisch installierten System nur dann wirksam, wenn in den Runlevel 5 gebootet wird.

Bei einem Start in den Runlevel 3 verhält sich “systemd” unter Opensue 12.1 unerklärlich schlecht; der Startvorgang dauert dann um einen Faktor 3 länger als ein konventionelles Hochfahren des Systems nach bewährter “System V”-Manier.