Opensuse 13.1 – Kernelmodule beim Booten statisch laden

Posted on by

Nach einer kompletten Neuinstallation von Opensuse 13.1 auf einem meiner Systeme gab es keinen Eintrag mehr für das automatische, statische Laden von Kernelmodulen beim Booten in YaST’s Modul “/etc/sysconfig”-editor”. Normalerweise fand sich ein solcher Eintrag unter:

YaST2 >> Editor für /etc/sysconfig >> System >> Kernel >> MODULES_LOADED_ON_BOOT

Unter OS 13.1 fehlt der Punkt MODULES_LOADED_ON_BOOT dagegen einfach. Ich hatte diese Konfigurationsmöglichkeit in der Vergangenheit immer mal wieder benutzt, um bestimmte Module automatisch zur Bootzeit zu laden. Ein Beispiel ist etwa das Module “loop” zur Behandlung von Loop-Devices. Solche Devices brauche ich etwa im Zusammenhang mit Tests von virtuellen Maschinen oder aber um Realcrypt-Container ins Filesystem einzuhängen.

YaST2’s “/etc/sysconfig”-Editor-Modul editiert unter “System >> Kernel” über Schlüsselwörter entsprechende Einträge in der Datei “/etc/sysconfig/kernel“. Natürlich konnte man diese Datei auch manuell editieren. Unter OS 13.1 findet sich in der Datei selbst kein Bereich mehr zum Schlüsselwort MODULES_LOADED_ON_BOOT.

Dass der Punkt zum Laden von Kernelmodulen unter YaST2 nicht mehr automatisch vorhanden ist, war mir bislang nicht aufgefallen, da ich die meisten meiner Systeme von Opensuse 12.3 aus upgegradet hatte. Offenbar wurden auf den upgegradeten Maschinen die ursprünglich unter MODULES_LOADED_ON_BOOT angegebenen Module aber anstandslos geladen.

Anlass genug, den Änderungen auf den Grund zu gehen.

Korrespondierende Einstellungen konnte man früher übrigens unter Red Hat in der Datei “/etc/rc.modules”, unter Arch Linux unter der “/etc/rc.conf” und unter Debian in der “/etc/modules” vornehmen. Wenn sich bewährte sysconfig-Dinge im einstmals überschaubaren, script-getriebenen Boot-Prozess plötzlich verändern oder entfernt werden, liegt der Verdacht nahe, dass das mit Auswirkungen der Einführung von “systemd” zu tun hat.

Tatsächlich ist dem auch in diesem Fall so. Eigentlich logischerweise – ob man systemd nun mag oder nicht …. Immerhin sorgt es nun zwischen den Distributionen, die heute “systemd” einsetzen, für eine gewisse Vereinheitlichung – auch wenn bisherige Einstellmöglichkeiten über bewährte Admin-Tools dadurch wegfallen.

Interessanterweise legte aber der bei einer Internet-Recherche auftauchende Artikel
http://b.agilob.net/opensuse-how-to-install-truecrypt/
nahe, dass das Schlüsselwort MODULES_LOADED_ON_BOOT in der Datei “/etc/sysconfig/kernel” auch von Opensuse 13.1 sehr wohl noch beachtet wird.

Nach einem Blick auf die systemd-bedingten Änderungen diskutiere ich weiter unten daher 3 Wege, um Kernelmodule unter Opensuse 13.1 gezielt zu laden – ohne dies in Grub oder Grub2 zu verankern. Zukunftsträchtig ist wegen “systemd” vermutlich nur der letzte der Wege sein, obwohl gerade das dortige Vorgehen nicht mehr die Möglichkeit bietet, YaST zur Konfiguration heranzuziehen. Ich beschreibe das Vorgehen jeweils am Beispiel des Moduls “loop”. Zunächst gehe ich aber auf das statische Laden von Kernelmodulen unter “systemd”-Bedingungen ein.

systemd und das statische Laden von Kernel-Modulen im Boot-Prozess

systemd liegt u.a. die Vorstellung zugrunde, dass der Boot-Prozess letztlich das Bereitstellen von Service-, Socket, Mount und Device-Units für bestimmte Target-Zustände leistet und dabei bestehende Abhängigkeiten auflöst. Im Rahmen dieser Philosophie erwartet man einen relativ freistehenden elementaren Service, der Kernel-Module lädt. Wie das prinzipiell funktioniert beschreiben folgende Artikel:
http://0pointer.de/blog/projects/the-new-configuration-files
https://wiki.archlinux.org/index.php/systemd
https://wiki.archlinux.de/title/Wechsel_von_Sysvinit_zu_systemd
https://wiki.archlinux.de/title/Kernelmodule#Module_beim_Systemstart_automatisch_laden

Wir zitieren aus dem zweiten wiki-Artikel für Arch-Linux:

Alle Module die bisher in der rc.conf bei MODULES=() eingetragen waren müssen jetzt in eine Datei in /etc/modules-load.d/ eingetragen werden.

Unter Opensuse 13.1 gilt das Analoge für diejenigen Module, die bisher in der “/etc/sysconfig/kernel” unter dem Parameter MODULES_LOADED_ON_BOOT eingetragen wurden.

Und weiter aus dem dritten wiki-Arch-Artikel:

Die meisten benötigten Module werden beim Systemstart vom Init System erkannt und automatisch geladen. Es kann allerdings vorkommen, dass einige Module nicht automatisch erkannt werden. Sollen diese dennoch bei jedem Systemstart geladen werden, müssen sie in eine Datei mit der Endung .conf im Verzeichnis /etc/modules-load.d/ eingetragen werden. Der Name der Datei ist frei wählbar, sie muss nur die Endung .conf haben. Zum Beispiel /etc/modules-load.d/my-modules.conf. Die zu ladenden Module werden zeilenweise in diese Datei eingetragen.

Wie systemd konkret mit einem solchen File unter “/etc/modules-load.d/” umgeht, beschreibt konkret die Antwort auf eine entsprechende Frage in folgendem Forum
http://unix.stackexchange.com/questions/71064/automate-modprobe-command-at-boot-time-on-fedora

Weitere Auskünfte geben folgende man-Seiten:

man systemd-modules-load.service
man modules-load.d

Mit eigenen Worten zusammengefasst:

Unter systemd sorgt ein spezieller Service “systemd-modules-load.service” für das gezielte statische Laden von Kernelmodulen. Die Service-Unit “systemd-modules-load.service” wird spätestens vom systemd-Target “sysinit.target” angefordert. Welche Module durch diese spezielle Unit geladen werden, wird u.a. über Dateien der Form “*.conf” unter dem Verzeichnis “/etc/modules-load.d/” gesteuert. In jeder dieser Dateien kann eine Liste von Modulen angegeben werden. Jedes Modul wird in eine separate Zeile eingetragen.

Hingewiesen sei darauf, dass der Service neben den dateien unter “/etc/modules-load.d/”
auch noch Dateien aus anderen Verzeichnissen aufsammelt! Vorgegeben ist das durch die Datei
“/usr/lib/systemd/system/sysinit.target.wants/systemd-modules-load.service”:

# This file is part of systemd.
#
# systemd is free software; you can redistribute it and/or modify it
# under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2.1 of the License, or
# (at your option) any later version.
 
[Unit]
Description=Load Kernel Modules
Documentation=man:systemd-modules-load.service(8) man:modules-load.d(5)
DefaultDependencies=no
Conflicts=shutdown.target
After=systemd-readahead-collect.service systemd-readahead-replay.service
Before=sysinit.target shutdown.target
ConditionCapability=CAP_SYS_MODULE
ConditionPathExists=|/etc/sysconfig/kernel
ConditionDirectoryNotEmpty=|/lib/modules-load.d
ConditionDirectoryNotEmpty=|/usr/lib/modules-load.d
ConditionDirectoryNotEmpty=|/usr/local/lib/modules-load.d
ConditionDirectoryNotEmpty=|/etc/modules-load.d
ConditionDirectoryNotEmpty=|/run/modules-load.d
r
ConditionKernelCommandLine=|modules-load
ConditionKernelCommandLine=|rd.modules-load
 
[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/lib/systemd/systemd-modules-load

Siehe auch:
https://disunitedstates.org/wiki/index.php/Systemd-modules-load.service

Wie man die Module nach Einsatzzwecken in separaten Dateien unter “/etc/modules-load.d/” organisiert, kann man selbst festlegen. Ich habe nicht überprüft, ob eine Nummernvergabe am Anfang des Namens im Stile “nn-name.conf”, wie sie unter Opensuse z.B. im Verzeichnis “/etc/modprobe.d/” vorgenommen wird, auch im Verzeichnis “etc/modules-load.d/” wirksam wirkt, um eine Reihenfolge der Abarbeitung zu erzwingen. Wahrscheinlich nicht. Was wiederum zu Problemen führen kann – siehe
http://archlinux.2023198.n4.nabble.com/systemd-fails-to-set-console-font-td4657110.html

Was ist zu tun, wenn dem Modul auch noch Parameter übergeben werden sollen? Hier hat sich eigentlich nicht viel geändert – im zweiten Artikel findet man eine Beschreibung des klassischen Vorgehens, um den geladenen Modulen Parameter zu übergeben. Dazu sind zusätzliche Dateien unter “/etc/modeprobe.d/” anzulegen.

Unter dem Verzeichnis “/etc/modprobe.d” findet man unter OS 13.1 in der Regel denn auch mit hoher Wahrscheinlichkeit einige Beispiele (u.a. für die jeweilie Soundkarte), die zeigen, wie die Übergabe von Parametern funktioniert. Zur Namensgebung und der Bedeutung der spezifischen Ziffern (seit OS 11.2) siehe
http://forums.opensuse.org/showthread.php/419615-11-2-new-modprobe-d-naming-convention
und dort den letzten Beitrag. Oder auch an einem konkreten Beispiel:
http://en.opensuse.org/SDB:Intel-HDA_sound_problems

Unter Opensuse kann man spezifische lokale Parameterübergaben demnach am besten in einer Datei

/etc/modprobe.d/99-local.conf

abhandeln.

Siehe zur Parameterübergabe an die Module aber auch:
https://bbs.archlinux.org/viewtopic.php?id=176942
http://www.opensuse-forum.de/allgemeines/opensuse-installation/8793-gel%C3%B6st-deprecated-config-file/

Wodurch wurde das früher MODULES_LOADED_ON_BOOT in der Datei “/etc/sysconfig/kernel” unter OS 13.1 ersetzt?

Nach dem erarbeiteten Wissen zum Laden von Kernelmodulen über die systemd-Service-Unit “systemd-modules-load.service” liegt es nahe, dass die unter älteren Opensuse-Versionenen vorgebenen Einträge in “/etc/sysconfig/kernel” beim Upgrade auf OS 13.1 in eine Datei unter “/etc/modules-load.d” verschoben wurden. Tatsächlich findet man dort auf meinen upgegradeten Systemen die Datei

/etc/modules-load.d/MODULES_LOADED_ON_BOOT.conf

Die enthält erwartungsgemäß alle ursprünglich mal über YaST vorgebenen statisch zu ladenden Module.

Ich beschreibe nachfolgend nun drei Wege, wie man unter OS 13.1 z.B. das Modul “loop” statisch beim Booten laden kann.

Weg 1 – händischer Eintrag MODULES_LOADED_ON_BOOT in der Datei
“/etc/sysconfig/kernel”

Folgender händischer Eintrag am Ende der Datei “/etc/sysconfig/kernel” führt zum Erfolg :

## Type: string
## Default: “”
#

# Old fashioned way to load kernel modules under OS 13.1
# Added by root, 27.05.2014
MODULES_LOADED_ON_BOOT=”loop”

Für die Dateiänderung sind natürlich root-Rechte erforderlich. Beim nächsten Start von OS 13.1 wird das Kernel-Module “loop” tatsächlich geladen.

Netterweise taucht nun auch in YaST’s “/etc/sysconfig”-Editor wieder die Möglichkeit zum Editieren des Eintages auf. Ich nehme an, dass Weg 1 z.Z. noch durch nicht bereinigte YaST-Überbleibsel aus vergangenen Zeiten ermöglicht wird. Erweitert oder ändert man übrigens den händisch vorgenommenen Datei-Eintrag mittels YaST’s sysconfig-Editor und nicht durch direktes Bearbeiten der Datei, so wird der Eintrag von YaST auch an “mkinitrd” übergeben. Ich weiß nicht, wie man das unterbinden kann. Notwendig ist diese Übergabe nicht; eigentlich sollten über mkinitrd ja nur Module zu beginn des Bootprozesses zum Tragen kommen, die zum Auslesen von Boot-Devices und zum Ansteuern anderer wichtiger Hardware unumgänglich sind.

Weg 2 – Ergänzen der Module unter
YaST2 >> Editor für /etc/sysconfig >> System >> Kernel >> INITRD_MODULES

Bei diesem Weg verankert man das Laden des gewünschten Modules explizit über “mkinitrd” in die initiale Auswertung eines “initramfs” cpio-Archivs des Kernels (im RAM). Ein totaler Overkill – aber möglich. Natürlich könnte man den Abschnitt zu INITRD_MODULES auch direkt in der Datei “/etc/sysconfig/kernel” editieren. Dieser zweite Weg gefällt mir nicht, weil er explizit ein Modul in das “initramfs”-cpio-Archiv des Kernels verlagert, das aus meiner Sicht dort eigentlich wenig zu suchen hat.

Weg 3 – Anlegen einer Datei
“/etc/modules-load.d/MODULES_LOADED_ON_BOOT.conf”
mit einer Zeile zu dem gewünschten Modul

Der Inhalt der Datei “/etc/modules-load.d/MODULES_LOADED_ON_BOOT.conf” ist in unserem Beispiel für das Modul “loop” denkbar simpel:

mytux:~ # echo loop > /etc/modules-load.d/MODULES_LOADED_ON_BOOT.conf
mytux:~ # cat /etc/modules-load.d/MODULES_LOADED_ON_BOOT.conf
loop

Weitere benötigte statische Module ergänzt man durch neue Zeilen pro Modul. Natürlich hätte man die Datei auch “loop.conf” nennen können. Ich finde die auch von Opensuse selbst gewählten Namen aber instruktiv.

Nach dem erneuten Starten des Systems kann man den Status des zugehörigen systemd-Services abfragen mit:

mytux:~ # systemctl status systemd-modules-load.service
systemd-modules-load.service – Load Kernel Modules
Loaded: loaded (/usr/lib/systemd/system/systemd-modules-load.service; static)
Active: active (exited) since Tue 2014-05-27 17:36:06 CEST; 1min 2s ago
Docs: man:systemd-modules-load.service(8)
man:modules-load.d(5)
Process: 353 ExecStart=/usr/lib/systemd/systemd-modules-load (code=exited, status=0/SUCCESS)
Main PID: 353 (code=exited, status=0/SUCCESS)

May 27 17:36:06 mytux systemd[1]: Starting Load Kernel Modules…
May 27 17:36:06 mytux systemd-modules-load[353]: Inserted module ‘loop’
May 27 17:36:06 rux systemd[1]: Started Load Kernel Modules.
 
 
mytux:~ # lsmod | grep loop
loop 27985 0
mytux:~ #

Obwohl ich systemd nicht mag, empfehle ich, diesen Weg 3 zum statischen Laden von Kernelmodulen ab Opensuse 13.1 zu gehen. Auch wenn man dann auf eine einfache Konfiguration mit YaST verzichten muss.

Heartbleed – kein Ende und dann auch noch Opensuse 12.2

Posted on by

Das ganze Thema “Heartbleed” hält einen aus verschiedenen Gründen in Atem:

Einerseits, weil man nicht weiß, welche Systeme von Online-Diensten, die aktuell in einem Heartbleed-Test als OK gekennzeichnet werden, eigentlich wann genau vom Provider auf den momentan sichereren Stand gebracht wurden. Vielleicht geschah das erst gestern – und vorher war der Serverdienst über Monate hackbar? Auf Webservern mit CM-Systemen, Shops etc. treten die Folgen vielleicht erst künftig zu Tage ….

Es ist deshalb aus meiner Sicht schon aus Vorsichtsgründen erforderlich, alle Passwörter von solchen Diensten, bei denen SSL eine Rolle spielte, schleunigst zu ändern. Die Provider werden kaum in Gänze zugebe, dass sie auch betroffen waren. Bei gehosteten Blogs, CM-Diensten, Shops, … sind zudem umfangreichere Prüfungen auf potentielle ingeschleuste Schadcodes erforderlich. Die Heartbleed-Lücke zu stopfen ist aus meiner Sicht wirklich nur ein erster Schritt zur Schadensbegrenzung.

Der andere Grund sind die im Kundenauftrag verwalteten Server. Was Opensuse anbelangt:

Die betroffenen OpenSSL-Bibliotheken sind auf Opensuse 12.2, 12.3, 13.1 upzudaten, SSL-Zertifikate (Server- wie ggf. Client-Zertifikate) und Passwörter müssen geändert werden. Und der Kunde ist davon in Kenntnis zusetzen. Im Falle von Opensuse 12.3 und 13.1 ist wenigstens das Installieren oder Überinstallieren der aktuellen SSL-RPMs noch auf einfache Weise möglich.

Achtung: Bei den aktualisierten Opensuee-Paket-Versionen für SSL handelt es sich um gepatchte “e”-Versionen und keine “g”-Versionen der Openssl-Bibliotheken/Pakete. Also nicht dadurch verwirren lassen, dass man überall – zuletzt in Mails diverser Provider – liest, dass man unbedingt auf die g-Version upgraden müsse ! Stimmt nicht ! Eine gepatchte frühere Version tut es auch. Nicht nicht vergessen, Apache neu zu starten und danach erneut auf die Heartbleed-Schwäche zu testen!

z.B. über folgende Seite: http://filippo.io/Heartbleed/

Sonderfall Opensuse 12.2:
Leider kann man sich nicht immer aussuchen, wann die eigenen Kunden Geld in die Hand nehmen, um ihre (V-) Server upgraden zu lassen. Das Problem sind auch ein wenig die Provider, wie z.B. Strato. Die hinken mit ihren Angeboten zu virtuellen Servern bei den OS-Paketen dem Entwicklungsstand (vielleicht aus guten Gründen) immer ein ganzes Stück hinterher. V-Server bei Strato wurden z.B. noch vor einem Jahr mit Opensuse 12.2 angeboten. Nach 2 neuen Releases fällt die alte OS-Version aber aus der Update-Wartung durch Suse raus. So kann man mit einem gehosteten V-Server halt schon nach deutlich weniger als 18 Monaten aus dem Wartungsintervall herausfallen. Opensuse 12.2 wird z.B. seit Januar nicht mehr mit neuen Update-Paketen versorgt.

Was kann man nun tun, wenn man noch einen solchen “veralteten” Server verwalten muss?

Zunächst mal versuchen, dem Kunden anhand von “Heartbleed” klarmachen, wie wichtig eine relativ zeitnahe Upgrade- und Maintenance-Politik ist. Es gibt ja auf einem systematisch veraltenden System vermutlich noch viel mehr Schwachstellen als so ein Paradebeispiel wie SSL-Heartbleed. Darunter natürlich auch solche, die erst dann aufgedeckt werden, wenn es keine Updates mehr gibt.

Bekommt man vom Kunden nach einem Überzeugungsgespräch die Zeit und das Geld, so ist zunächst ein Upgrade von 12.2 auf 12.3 am sinnvollsten. Dieser Upgrade funktioniert nach meinen eigenen Erfahrungen relativ schmerzfrei. Ein Upgrade 12.2/12.3 auf 13.1 ist dagegen deutlich schwieriger, da man sich dabei mit einer Rekonfiguration des Apache-Servers herumschlagen muss, die wegen des Umstiegs der aktuellen Apache2 2.4-Version leider unumgänglich wird. Mich hat das damals (Nov. 2013) zumindest einiges an Zeit und Recherchen gekostet, bis die Webserver auf den upgegradeten 13.1-Systemen wieder anstandslos liefen.

Was aber, wenn man
aber kein Geld bekommt, um ein Upgrade durchzuführen?
Nun, dann führt wohl kein Weg an einer eigenen Kompilation des neuen SSL-Paketes aus den Sources inkl. Patch vorbei. Hierfür bietet sich ein Download der gepatchten aktuellen Source-Versionen für Opensuse 12.3 an, die dann gegen Opensuse 12.2 kompiliert werden müssen. Das ist der sicherste und korrekteste Weg. Er funktioniert und er bewahrt einen auch vor evtl. Pfad-Problemen. Die offiziellen Sources von OpenSSL und die zugehörigen Config/Make-Dateien gehen von einem anderen Verzeichnislayout als Opensuse aus.

Ein aus Sicherheitsaspekten deutlich problematischerer Weg besteht darin, Pakete zu nutzen, die von Dritten erstellt wurden. Das ist nicht nur eine Frage des Vertrauens. Programmware aus “privaten” Quell-Repositories zu installieren, ist immer ein potentielles Sicherheitsproblem und erfordert mindestens einen vorherigen Vergleich des (angeblich) verwendeten Sourcecodes gegenüber offiziellen Quellen und weitere nachfolgende Tests. Bei dem Zeitaufwand kann man dann auch schon gleich selbst kompilieren. Na ja, ….

Jedenfalls soll nicht unerwähnt bleiben, dass es unter
http://download.opensuse.org/repositories/home:/
Repositories gibt, die eine gepatchte 12.3 OpenSSL-Paketversion anbieten, die für Opensuse 12.2 kompiliert wurde.

Konkrete Hinweise findet man in
http://forums.opensuse.org/showthread.php/496947-opensuse-12-2-and-ssh-heartbleed/page3

Aber hier muss jeder selber wissen, wie er vorgeht. Bei allem Fluchen über die aktuellen Probleme:

  • Gut finde ich, dass die Sicherheitslücke gefunden wurde.
  • Gut finde ich auch, dass es Leute in der Opensource Community gibt, die sich regelmäßig um Sicherheit kümmern. Denn Lücken durch systematische Tests zu finden, erfordert Zeit und Aufwand. Und für den entsprechenden Einsatz sollte man den Leuten danken.
  • Noch besser finde ich, dass man kurzfristig mit Tipps versorgt wird, was man tun sollte und kann, um die Lücke zu schließen.

Schlecht finde ich nach der aktuellen Erfahrung die kurzen Wartungszyklen der Opensuse-Versionen. Das zeigt, dass die Community zwischenzeitlich immer mal wieder Long Term-Versionen (z.B. mit 3 Jahren Update-Versorgung) bereitstellen sollte.

Ansonsten bleibt mir nur, viel Erfolg beim Prüfen von Logs, Datenbankeinträgen etc. auf den Servern zu wünschen, die der OpenSSL-Verwundbarkeit ausgesetzt waren. Denn SSL setzt man ja z.B. ein, wenn Zugänge und Datentransfers für CM-Systeme etc. abgesichert werden sollten. Wurden die gehackt, so ….

Nachtrag 29.04.2012 :
Die in den vergangenen zwei Wochen in der dt. Presse erschienen Artikel zu Thema Heartbleed finde ich zum Teil unerträglich. Klar, es war ja zu erwarten, dass die Vertreter kommerzieller Closed Source Firmen das zum Anlass nehmen, Open Source zu kritisieren. Aber muss die Presse so unkritisch auf dieser Welle mitschwimmen? Welche Scheinheiligkeit! Als ob kommerzielle Interessen Sicherheit verbessern würden und als ob Entwickler bei kommerziellen Firmen besser und systematischer arbeiten würden als im Opensource Bereich. Nach meinen eigenen Erfahrungen kann man das keineswegs als grundsätzliche Feststellung treffen.
Tja, und man muss eigentlich lange nach Beispielen für Sicherheitsprobleme im kommerziellen Umfeld suchen? Spontan fallen mir ein: Die vielen, fast kontinuierlichen Probleme mit Java in den letzten Jahren, deren sich der kommerzielle Gigant Oracle nur schleppend annahm. Die laufenden Probleme mit dem MS IE und speziell die aktuellen Probleme mit dem MS IE 10. Oder auch: Die gezielte Entkernung von Linux in Bezug auf alle Sicherheitsaspekte bei der frühen Entwicklung von Android durch Google. Oder das Hacking von Linux Servern Anfang 2013, das seinen Ausgangspunkt allerdings in
massiven Fehlern von MS Windows Frontend-Systemen hatte …
Nein, es gibt nun wirklich keinen kausalen Zusammenhang der Art : kommerzielle Firma, Closed Source = Sicherheit. Allen Kritikern sei gesagt: Kehrt vor euren eigenen Haustür.

Wann tritt jemand das heutige Pulseaudio endlich in die Tonne für Fehlversuche?

Posted on by

Pulseaudio (PA) geht mir nun zum x-ten Male auf die Nerven und irgendwie muss ich meinen Frust mal loswerden. Ich sollte dazu sagen, dass ich in alten Zeiten eine Weile mit Jack gearbeitet habe, mich aber in den Untiefen der vielschichtigen aktuellen Sound-Architektur(en) nicht mehr auskenne und auch nicht auskennen will. Ich will Sound als Anwender unter Linux nach Bedarf hören, vom Browser, von Playern, von der CD und aus anderen Quellen. Wo sinnvoll will ich Surround-Sound transportiert bekommen und auch einen Upmix von Stereo auf 5.1 oder 7.1 Mehrkanal-Ton. Ich möchte gerne einen zentralen Equalizer für den Desktop (den z.B. KDE mangels Interesse der Entwickler verweigert). Ich möchte die Möglichkeiten der Sound-Karte ausnutzen und Input- wie Output-Kanäle getrennt regeln und auch Ton-Aufnahmen per Micro machen. Und Skype soll laufen.

Immer mal wieder richte ich ja Linux-Laptop- und Linux-Desktop-Systeme ein. Für den Eigenbedarf, aber auch mal für Bekannte oder Kunden. Die wollen eigentlich genau dasselbe – also das, was sie unter Windows auch bekommen. Und immer wieder gibt es bei der Systemeinrichtung einen gemeinsamen Schritt, zu dem ich regelmäßig gezwungen bin – nämlich der vollständigen Deinstallation von Pulseaudio [PA] und zugehöriger Tools. Einzige Ausnahme – und auch die nur manchmal: Laptops mit einfachen, sehr beschränkten Onboard-Soundkarten auf Basis von Standard-Massen-Chips.

Vielleicht war es ja mal eine gute Idee, zwischen Soundquellen (Applikationen) und die Hardwaretreiber einen eigenen Layer einzuschalten, der noch dazu netzwerkfähig ist. Aber das Ergebnis – nämlich PA – ist auf dem heutigen Stand für den normalen Anwender schlicht eine Katastrophe. Was immer PA angeblich an supertollen Dingen kann, die ALSA oder Jack in ihren jeweiligen Welten nicht können. Als Otto Normalverbraucher merke ich erstmal die elementaren Fehler und Unzulänglichkeiten. Vor dem Einsatz eines netzwerkweit arbeitenden Soundservers und vieler Spezialanwendungen kommen eben viel, viel einfachere Ansprüche des normalen Anwenders und erst recht des potentiellen Umsteigers von Windows :

Zunächst möchte man mal auf dem jeweiligen Desktop (u.a. KDE) etwas hören und dabei die Regelmöglichkeiten einer Soundkarte so gut ausnutzen können, wie es die aktuellen Treiber (meist Alsa-Libs) halt zulassen.

Hat sich PA in diesem Sinne bewährt? Meiner eigenen Erfahrung nach überhaupt nicht. Vor allem nicht für komplexere Soundkarten. Meine zusammenfassende Meinung – und die beruht auf mehrjährigen Erfahrungen mit vielen unterschiedlichen Systemen und Soundkarten – ist:

Es gibt kaum ein sog. “Werkzeug”, das in den letzten Jahren in den meisten Linux-Distributionen eingeführt wurde und das so sehr für eine Entmündigung des Anwenders und durch eben diesen nicht kontrollierbare Folgeprobleme steht wie “Pulseaudio” (PA). Man braucht hierzu nur mal das Internet zu durchsuchen. Siehe eine kleine Liste am Ende des Artikels.

Eigene schlechte Erfahrungen mit PA über viele Installationen hinweg – seit es PA gibt

Meine Meinung stützt sich auf folgende regelmäßige Erfahrungen (meist unter Opensuse und KDE, aber auch schon mal unter Debian und Ubuntu):

  • PA war und ist buggy – es schafft aus Sicht des Endanwenders in der Regel mehr Probleme, als das es welche löst.
  • PA blendet in der Standardinstallation gängiger Distributionen die oft vielfältigen Einstell-Möglichkeiten vieler Audiokarten brutalst möglich aus. Aus vielen Reglern werden oft genau einer oder zwei. Ein normaler Anwender hat i.d.R. keine Chance, die z.T. massiven Einschränkungen zu umgehen. Warum das so sein muss, weiß wohl nur der PA-Erfinder. Beim unbedarften Anwender bleibt aufgrund von PA bei gleicher Soundkarte gegenüber
    einer Windows-Umgebung meist der Eindruck eines Steinzeit-Soundsystems zurück. (Was allein an PA liegt, mit Plain Alsa sieht die Welt nämlich meist ganz anders aus; s.u.)
  • PA ist in seinem Standardverhalten (gekoppelte Lautstärke-Regelungen verschiedener Ein- und Ausgangskanäle) für den Standardanwender nicht nachvollziehbar und daher auch nicht sinnvoll kontrollierbar.
  • Im Aufnahmebereich fehlen für manche Soundkarten wichtige Regler; manchmal treten gegenüber einer Plain Alsa-Installation bei Aufnahmen unmotivierte Übersteuerungen auf.
  • Auch durch den Einsatz des PA-Mixers “pavucontrol” (ebenfalls buggy) und seiner Möglichkeiten wird man die Kopplungseffekte der Lautstärkeregelung bei vielen Mehrkanal-Audiokarten nicht los oder erhält. In vielen Fällen erhält man nach der gewünschten Einstellung der Kanaltrennung sogar ein völlig fehlerhaftes bis unkontrollierbares Verhalten bei der Lautstärkeregelung. (Ein Beispiel für eine Xonar D2X: Regelt man einen Kanal nach oben, werden plötzlich alle Kanäle gleichmäßig leiser. Danach geht die Lautstärkeregelung gar nicht mehr vernünftig. Ähnliches ist mir auch bei diversen Audigy-Karten und auch Realtek-Chips passiert – alles im Gegensatz zu Plain Alsa)
  • Manche Fehler der letzten Zeit – z.B. automatisches Springen der Lautstärke auf 100% bei KDE-Systemsoundtests – führten/führen zur Gefahr der Zerstörung von über externe Verstärker angeschlossene Lautsprecheranlagen.
  • PA führt bei einigen Soundkarten zu einer fehlerhaften Ansteuerung und zu dauerhaften knackenden Nebengeräuschen. Diese verschwinden oft bei einer reinen Alsa Installation
  • PA führt immer wieder zu massiven Problemen mit Anwendungen wie Skype – und manchmal zu unkontrollierbaren Dauergeräuschen schon beim Starten von Skype oder aber bei Versuchen im Audio-Einstellungs-Bereich. Auch hier wiederim Gegensatz zu einer reinen Alsa Installation.
  • Einziger Pluspunkt der PA-Tool-Palette ist aus meiner Sicht der LADSPA nutzende Equalizer, der dann unter PA naturgemäß systemweit wirkt. Aber auch hier gibt es manchmal hörbare Latenzprobleme.

Ursprünglich mal zur Vereinheitlichung der Benutzerschnittstelle gegenüber Sound-Systemen wie ALSA und dem bei KDE darüber liegenden “phonon” gedacht, zwingt PA dem User gegenüber einer reinen Alsa-Installation Einschränkungen und “Effekte” auf, die mit Vernunft nicht nachvollziehbar sind. Ich habe mich wirklich immer wieder bemüht, mich mit PA anzufreunden. Manchmal stundenlang. Übrig geblieben sind über die Jahre hinweg genau zwei Laptops mit Allerwelts-Onboard-Soundkarten, bei denen ich PA manchmal sinnvoll nutzen kann, ohne mir Ärger einzuhandeln. Aber auch nicht ohne zusätzliche Tools wie “pavucontrol”. Und selbst dann funktioniert nicht immer alles wie es soll: So schließt eine sinnvolle Nutzung von Skype die Anwendung von PA aus.

Dann gab es zwischenzeitlich auch richtig folgenschwere Bugs – u.a. im Zusammenspiel mit KDE. Vor einiger Zeit etwa das automatische Hochregeln der Lautstärke auf 100% nach dem ersten Anspielen von Systemsounds. Mit der Gefahr, seine Lautsprecher und das Verhältnis zu den Nachbarn zu ruinieren. Nicht weiter vertiefen will ich das gekoppelte Hochregeln von Volumecontrols sowohl für Multikanal Output-Devices wie gleichzeitig (!) auch für Input-Quellen. Den Schwachsinn wird man meist auch bei entsprechender Konfiguration von “pavucontrol” nicht los.

Plain Alsa – mehr als eine Alternative, wenn man nicht Sound im Netz verteilen will

Dagegen steht für den Normalanwender die Alternative einer Sound-Konfiguration unter Plain ALSA. Mein glasklares Ergebnis nach vielen Experimenten ist:

Eine Plain Alsa-
Installation funktioniert für den Alltagsbedarf meist schon auf Anhieb relativ problemfrei. Selbst bei schwierigeren Fällen bringt einen ein wenig Einsatz und Konfigurationsversuche deutlich weiter als PA. In einer reinen Alsa-Umgebung entdeckt der unbedarfte User plötzlich, was man alles an seiner Soundkarte regeln kann, dass man Input- und Output-Pegel unabhängig adjustieren kann, dass das Aufnehmen problemfrei geht, dass Skype problemfrei funktioniert, etc.. Ich habe das immer wieder und für ein breites Spektrum an Soundkarten (diverse Creative Soundblaster-Varianten, Audigy (2/4)- und XFi-Karten, Terratec-USB-Karten, Realtek-Onboard-Chips [PCI, PCIe, USB] und Xonar-Karten) hinter mir. Zuletzt für eine Xfi-Titanium und eine rel. kostspielige Xonar D2X. Zu beiden und deren Konfiguration schreibe ich bald mal Artikel, wenn ich denn Zeit finden sollte.

Man muss die Reaktion auch Linux-skeptischer Nutzer halt auch mal erlebt haben, wenn man verstehen will, welchen Schaden PA bzgl. der Linux-Wahrnehmung anrichten kann. Nach einer Opensuse-Standardinstallation (mit PA) auf Desktops mit SB Live, Audigy, XFi, …-Karten und einer Surround-Umgebung passiert immer das gleiche: Welche Enttäuschung – man kann ja nichts einstellen oder es funktioniert auch unter “pavucontrol” nichts wie erwartet. Der Anwender spürt Chaos…

Wenn man den Betroffenen nach einer De-Installation von PA unter Kmix dann plötzlich statt einem oder zwei Reglern eine umfassende Palette an funktionierenden Mehrkanal-Controls und Schaltern für spezielle Optionen der Soundkarten anbieten kann: Erstaunen und freudiges Kopfnicken.

audigy

xonar

(Zugegeben: bei der Xonar muss man noch ein wenig manuell für den “Stereo to 5.1/7.1”-Upmix tun). Die typische Frage, die dann vom künftigen Linux-Anwender kommt, ist: Warum ist denn die normale Alsa-Konfiguration dann nicht der primäre Standard der verschiedenen Linux-Distributionen? Tja, eine sehr gute Frage …

Was sagen andere ?

Ich zitiere aus https://de.opensuse.org/YaST_Module_Sound
“Da die Soundsteuerung über PulseAudio oftmals noch für Probleme (ALSA, Phonon, GStreamer) sorgt, kann es nötig sein PulseAudio zu deaktivieren, ja manchmal sogar komplett zu deinstallieren, um bestehende Probleme zu lösen.”

Ganz genau. Ergänzung aus meiner eigenen Erfahrung:

Die Deinstallation von PA ist fast immer nötig, um eine vernünftig funktionierende Sound-Umgebung unter Linux zu bekommen, wenn man eine etwas avanciertere Soundkarte hat.

Ich zitiere weiter aus http://www.tweakhound.com/2013/03/25/opensuse-12-3-tips-tricks-and-tweaks/ :

Disable or Uninstall Pulseaudio and reconfigure sound card:
Pulseaudio is and has been the source of many issues.
 
If you are having issues with sound you can:
1 – Check all PulsuAudio settings by installing pavucontrol.
Once installed it will be in the KMenu > Multimedia > Volume Control section.
Use it to configure your settings.
2 – Disable PulseAudio.
3 – Uninstall PulseAudio.
 
New users should simply disable PulseAudio:
Open YaST and go to > Hardware > Sound >
click the Other
button and choose PulseAudio Configuration >
Uncheck Enable PulseAudio Support and click OK.

Hervorhebung durch mich. Und das Gleiche auch hier: http://steamcommunity.com/app/221410/discussions/0/864979883831623432/ :

“The only problem with openSUSE is audio. If they stayed with just ALSA most of their problems would be solved and they wouldn’t need Wiki Pages telling how to get sound working on Skype/Steam.”

Ganz genau ! PA und Teile seiner Tools tragen letztlich zur Abschreckung normaler Nutzer von Linux bei. PA bietet aus meiner Sicht gegenüber dem, was ein aktuelles ALSA heute nativ abliefert, keinen nennenswerten Vorteil – wenn man mal von netzwerkfähigen Sound-Servern absieht. Im Gegenteil wird der unbedarfte Anwender um vielfältige Bedien- und Einsatzmöglichkeiten seiner Soundkarten betrogen.

Opensuse und KDE: Löst euch endlich von PA – oder lasst es komplett überarbeiten!

Es ist für mich als Anwender völlig unverständlich, dass sich KDE so an PA klammert und nicht endlich selbst die wenigen Lücken schließt, die z.B. bzgl. eines systemweiten Equalizers bestehen. Statt dessen klammert man sich an ein fehlerhaftes, für den Anwender enervierendes PA-Toolset.

Genauso schlimm verhalten sich die Distributionen wie Opensuse oder Ubuntu, die PA standardmäßig installieren. So hat Opensuse eine vorgesehene KDE-Einstellmöglichkeit für die relative Lautstärke von Systemsounds entfernt – weil der KDE-Regler unter PA nicht wirkt und es unter “pavucontrol” – das der normale Benutzer nicht mal kennt und das im Standard nicht mitinstalliert wird – einen Ersatzregler gibt. Interessanterweise musste ich durch Experimente vor kurzem mühsam lernen, dass der ursprüngliche KDE-Regler unter einer reinen Alsa-Installation sehr wohl seine Wirkung entfaltet.

Liebe Leute von Opensuse: Nur weil der PA-Erfinder und Entwickler von Red Hat bezahlt wird, ist PA für den Endanwender noch lange nicht gut. Zumindest nicht im heutigen Zustand.

Wann kommt ihr endlich zur Einsicht und tretet das permanente Mega-Ärgernis PA endlich in die Tonne? Schreibt lieber eine ordentliche Einführung in die Konfigurationsmöglichkeiten von ALSA (oder Jack). Und bringt die KDE-Leute freundlich dazu, Phonon mit ein paar Zusatztools wie einem systemweiten Equalizer abzurunden. Dafür gibt es nämlich wirklich einen Bedarf. Aber ich lebe lieber ohne systemweiten Equalizer als mit dem Ärger und den Bugs, die man sich mit PA nun schon über Jahre regelmäßig einhandelt.

PA muss entweder grundlegend überarbeitet werden – oder es sollte künftig nur optional installierbar sein. Bis die Distributoren das begreifen gilt:
Nerven schonen, Pulseaudio komplett deinstallieren und danach endlich wieder guten (Surround-) Sound mit ALSA und der Soundkarte seiner Wahl hören.

Kleine Liste mit Links zu Problemen von und mit PA

http://www.hecticgeek.com/2012/01/how-to-remove-pulseaudio-use-alsa-ubuntu-linux/
http://www.ubuntugeek.com/fix-for-all-pulseaudio-related-issues.html
http://www.opensuse-forum.de/pulseaudio-problem-hardware-treiber/themen-f9/t8816-f11/
http://www.techrepublic.com/blog/linux-and-open-source/pulseaudio-an-achilles-heel-that-needs-repair/
http://www.tweakhound.com/2013/03/25/
opensuse-12-3-tips-tricks-and-tweaks/
http://forums.fedoraforum.org/showthread.php?t=291978
http://askubuntu.com/questions/300838/pulseaudio-is-not-working-at-all
http://forums.opensuse.org/showthread.php/493766-SUSE-13-1-PulseAudio-not-working
http://www.opensuse-forum.de/kein-start-up-sound-skype-sound-mehr-nach-update-auf-13-1-anf%C3%A4nger-startprobleme/allgemeines-f17/t9561-f20/
http://steamcommunity.com/app/221410/discussions/0/864979883831623432/
http://linuxg.net/how-to-properly-replace-pulseaudio-with-alsa-on-crunchbag-linux-and-debian-squeeze/
https://coderwall.com/p/wajiaq

http://linuxhaters.blogspot.de/2008/10/pulse-my-audio.html
http://forums.fedoraforum.org/showthread.php?t=288682
https://bbs.archlinux.org/viewtopic.php?pid=1298297
https://bbs.archlinux.org/viewtopic.php?id=117822
http://linuxmusicians.com/viewtopic.php?f=27&t=847
http://forums.opensuse.org/showthread.php/468722-Pulseaudio-a-pain-in-the
http://www.linuxplanet.com/linuxplanet/tutorials/7130/1

And my latest absolute favourite
http://www.beastwithin.org/blogs/wolfheadofselfrepair/2013/07/pulseaudio-insidious-linux-malware

Cyrus IMAP mit SASL, PAM, SSSD und LDAP – Opensuse 12.3/13.1 – IV

Posted on by

In den vorhergehenden Beiträgen

Cyrus IMAP mit SASL, PAM, SSSD und LDAP – Opensuse 12.3/13.1 – I
Cyrus IMAP mit SASL, PAM, SSSD und LDAP – Opensuse 12.3/13.1 – II
Cyrus IMAP mit SASL, PAM, SSSD und LDAP – Opensuse 12.3/13.1 – III

dieser Artikel-Reihe hatten wir eine einfache Installation des Cyrus IMAP-Dienstes auf einem Host namens “mycyrus” vorbereitet und durchgeführt. Der IMAP-Server nutzt einen LDAP-Server “ldap-serv” zur Authentifizierung von Benutzern, die Zugriff auf vorhandene IMAP-Mailboxen erhalten wollen.

In diesem Beitrag kümmern wir uns nun um die Anbindung eines KDE “Kmail”-Client an den IMAP-Server. Wir starten dazu “Kontact” oder “Kmail” auf einem Host “tux” im Netzwerk. Die nächsten Schritte beinhalten lediglich das Eingeben der Verbindungsdaten:

Dazu gehen wir in die Konfiguration der sog. “Zugänge” (gemeint sind Server-Zugänge – oder besser noch “Server-Konten”) über

Menüpunkt “Einstellungen” >> “Kmail einrichten” >> “Zugänge” >> Tab “Empfang”

Dort drücken wir auf den Button “Hinzufügen” und wählen im folgenden Auswahldialog die Option “IMAP-E-Mail-Server“.

Im nächsten Konfigurationsdialog geben wir die erforderlichen Zugangs- und Authentifizierungsdaten zum Server ein. Das sind zunächst vor allem unsere Userdaten für den IMAP-Dienst – also genau jene Daten, die wir im LDAP-System zu unserer Authentifizierung hinterlegt haben, und auf die der Server “mycyrus” gem. unserer Einrichtung in den letzten Artikeln per SASLAUTHD, PAM, SSSD zugreift. Wir verwenden hier wieder die Zugangsdaten unserer Testuserin “tarja” aus den vorhergehenden Artikeln:

Kmail_IMAP2_600

Den Namen des Mail-Kontos (oberstes Feld) können wir dabei nach Gutdünken festlegen.

Von größerer Bedeutung ist ferner der Dialog unter dem Reiter “Erweitert“, den dort stellen wir ein, dass Kmail eine STARTTLS-Verbindung zum IMAP-Server aufbauen soll. Ein Druck auf den Button “Automatisch erkennen” sollte das fehlerfrei und im lokalen Netz innerhalb von Sekundenbruchteilen für uns erledigen. Falls der IMAP-Server TLS anbietet – und dafür haben wir ja durch die Cyrus Konfiguration im ersten Beitrag gesorgt – wird die TLS-Option automatisch ausgewählt. Als “Authentifizierung”s-Mechanismus kommt in unserem Fall nur “Plain” oder “Login” in Frage.

Kmail_IMAP3_600

Sollte die automatische Konfiguration lange dauern oder zu Meldungen führen, so ist dies meist ein Zeichen dafür, dass

  • entweder gar keine Kommunikation zum Server möglich ist
  • oder es ein Problem mit der Zugangsberechtigung oder der Authentifizierung – in unserem Fall gegenüber einem LDAP-System – gibt
  • oder TLS nicht funktioniert.

Dann sind eine Überprüfung der Kommunikation mit “telnet”, ein Check von Firewall-Einstellungen sowie spezifischere Tests (z.B. mit “imtest”) angesagt.

An dieser Stelle sollte man sich außerdem noch einmal bewusst machen, dass wir es gemäß unserer Installation mit 2 unterschiedlichen TLS-Verbindungen zu
tun haben:

  • Der Mail-Client Kmail auf dem Host “tux” baut eine per STARTTLS gesicherte Verbindung zum IMAP-Server “mycyrus” auf und tauscht so abgesichert Userdaten und später auch Maildaten mit dem IMAP-Server aus.
  • Der IMAP-Server “mycyrus” hingegen baut zur Authentifizierung des Users “tarja” über SASLAUTHD, PAM und vor allem SSSD eine per STARTTLS gesicherte Verbindung zum LDAP-Server (hier “ldap-serv”) auf.

Für die erste Verbindungsmöglichkeit sorgt eine adäquate Konfiguration des Cyrus IMAP-Dienstes und natürlich auch des E-Mail-Clients Kmail. Die zweite Verbindung beruht auf einer TLS-fähigen Auslegung des LDAP-Servers und einer geeigneten Konfiguration von SASL, PAM und SSSD auf dem Server “mycyrus”. Siehe hierzu die vorangegangenen Artikel.

Als nächstes schließen wir die Einrichtung unseres IMAP-Kontos durch Drücken des Buttons “OK” ab. Der Server-Zugang namens “mycyrus-tarja” sollte nun gem. der oben gewählten Einstellungen angelegt worden sein und als funktionstüchtig (“bereit”) angezeigt werden:

Kmail_IMAP5

Wechseln wir nun zur Standardansicht von “Kontact”, so sollten wir etwa ein Bild der folgenden Art erhalten:

Kmail_IMAP6

Natürlich ist die Mailbox im Gegensatz zur obigen Darstellung in Ihrem Fall noch leer. Aber mit Hilfe von Kontakt/Kmail können wir nun schon Mails aus anderen Mailfoldern anderer Server in die Mailfolder des neuen Accounts – hier “mycyrus-tarja” kopieren und die kopierten Mails danach auch ansehen.

Damit haben wir eine vollständige Kette

E-Mail-Client Kmail <= TLS => Cyrus IMAP-Server mit userspezifischen und allgemeinen Mailboxen < = TLS => LDAP-Server zur Authentifizierung von IMAP-User

realisiert. Denn in Zeiten wie diesen gilt auch im hauseigenen Netzwerk: Ein Schutz gegen unerwünschtes Ausspähen kann nicht verkehrt sein – zumal, wenn er sich – wie gezeigt – unter Linux doch recht einfach einrichten lässt.

Im nächsten Beitrag beschreibe ich zur Abrundung des Cyrus IMAP-Themas noch die Einrichtung von “Webmin” zur grafischen Verwaltung der Mailboxen und zugehöriger Zugriffsrechte.

Cyrus IMAP mit SASL, PAM, SSSD und LDAP – Opensuse 12.3/13.1 – III

Posted on by

In den letzten beiden Beiträgen
Cyrus IMAP mit SASL, PAM, SSSD und LDAP – Opensuse 12.3/13.1 – I
Cyrus IMAP mit SASL, PAM, SSSD und LDAP – Opensuse 12.3/13.1 – II
unserer kleinen Serie zur Implementierung eines Cyrus IMAP-Dienstes mit LDAP-Authentifizierung über PAM und SSSD hatten wir uns mit den IMAP-Konfigurationsdateien sowie der PAM, SSSD- und partiell auch der LDAP-Konfiguration herumgeschlagen. Getestet haben wir bereits den “saslauthd”-Authentifizierungsmechanismus.

Den IMAP-Service selbst hatten wir dagegen noch gar nicht gestartet oder benutzt. Wir holen dies nun nach und testen dann den Zugriff zunächst rein per “telnet” (oder “imtest”) und expliziten IMAP-Komandos. Ich finde es lehrreich, unabhängig von echten Mail-Clients auch mal die Kommandozeile zu nutzen.

Starten des Cyrus- IMAP-Servers

Wir starten den IMAP-Dienst:

systemctl start cyrus.service

Das sollte nach den Konfigurationsvorbereitungen der letzten Artikel anstandslos funktionieren ! Also etwa so:

mycyrus:~ # systemctl start cyrus.service
mycyrus:~ # systemctl status cyrus.service
cyrus.service – LSB: The cyrus-imapd mail system
Loaded: loaded (/etc/init.d/cyrus)
Active: active (running) since Wed 2014-03-12 19:56:23 CET; 7s ago
Process: 9392 ExecStop=/etc/init.d/cyrus stop (code=exited, status=0/SUCCESS)
Process: 9404 ExecStart=/etc/init.d/cyrus start (code=exited, status=0/SUCCESS)
CGroup: /system.slice/cyrus.service
├─9412 /usr/lib/cyrus/bin/master -p /var/run/cyrus.pid -d
└─9417 idled
Mar 12 19:56:23 mycyrus master[9418]: about to exec /usr/lib/cyrus/bin/ctl_cyrusdb
Mar 12 19:56:23 mycyrus ctl_cyrusdb[9418]: checkpointing cyrus databases
Mar 12 19:56:23 mycyrus ctl_cyrusdb[9418]: archiving log file: /var/lib/imap/db/log.0000000001
Mar 12 19:56:23 mycyrus ctl_cyrusdb[9418]: archiving log file: /var/lib/imap/db/log.0000000001
Mar 12 19:56:23 mycyrus ctl_cyrusdb[9418]: archiving log file: /var/lib/imap/db/log.0000000001
Mar 12 19:56:23 mycyrus ctl_cyrusdb[9418]: archiving database file: /var/lib/imap/annotations.db
Mar 12 19:56:23 mycyrus ctl_cyrusdb[9418]: archiving database file: /var/lib/imap/mailboxes.db
Mar 12 19:56:23 mycyrus ctl_cyrusdb[9418]: archiving log file: /var/lib/imap/db/log.0000000001
Mar 12 19:56:23 mycyrus ctl_cyrusdb[9418]: done checkpointing cyrus databases
Mar 12 19:56:23 mycyrus master[9412]: process 9418 exited, status 0

Danach “enablen” wir den Service mal prophylaktisch:

mycyrus:~ # systemctl enable cyrus.service

Anlegen von Mailverzeichnissen für unsere Test-Userin “tarja”

Wir legen nun gezielt eine Mailbox mit Subfoldern für unsere Testuserin “tarja” an. Dazu benutzen wir die “cyradm“-Umgebung:

mycyrus:/etc/pam.d # su – cyrus
cyrus@mycyrus:~> cyradm
cyradm> connect localhost
Password:
localhost> cm user.tarja
localhost> cm user.tarja.Drafts
localhost> cm user.tarja.Sent
localhost> cm user.tarja.Spam
localhost> cm user.tarja.Junk
localhost> cm user.tarja.Archive
localhost> lm user.tarja.*
user.tarja.Archive (\HasNoChildren) user.tarja.Sent (\HasNoChildren)
user.tarja.Drafts (\HasNoChildren) user.tarja.Spam (\HasNoChildren)
user.tarja.Junk (\HasNoChildren)
localhost> exit
cyrus@mycyrus:~> exit
Abgemeldet
mycyrus:/etc/pam.d #

Test des Remote-Zugangs

Nun testen wir von einem Remote-Host “tux” aus, ob wir den IMAP-Dienst auf “mycyrus” erreichen können. Ich setze voraus, dass alle Firewall-Einstellungen so gesetzt sind, dass ein Zugang über den Standard Imap-Port 143 möglich ist. Mehr benötigen wir bei Anwendung von STARTTLS nicht. Erstmal remote über “telnet” von einem anderen Linux-System “tux” aus :

tarja@tux:~> telnet mycyrus 143
Trying 192.168.0.88…
Connected to mycyrus.
Escape character is ‘^]’.
* OK [CAPABILITY IMAP4 IMAP4rev1 LITERAL+ ID STARTTLS AUTH=PLAIN AUTH=LOGIN SASL-IR COMPRESS=DEFLATE] mycyrus Cyrus IMAP v2.3.16 server ready
starttls login tarja TARJAPWD
starttls OK [CAPABILITY IMAP4 IMAP4rev1 LITERAL+ ID LOGINDISABLED COMPRESS=DEFLATE ACL RIGHTS=kxte QUOTA MAILBOX-REFERRALS NAMESPACE UIDPLUS NO_ATOMIC_RENAME UNSELECT CHILDREN MULTIAPPEND BINARY SORT SORT=MODSEQ THREAD=ORDEREDSUBJECT THREAD=REFERENCES ANNOTATEMORE CATENATE CONDSTORE SCAN IDLE X-NETSCAPE URLAUTH] User logged in
r list all “*”
r OK Completed (0.000 secs 1 calls)
r list “” “*”
* LIST (\Noinferiors) “.” “INBOX”
* LIST (\HasNoChildren) “.” “Archive”
* LIST (\HasNoChildren) “.” “Drafts”
* LIST (\HasNoChildren) “.” “Junk”
* LIST (\HasNoChildren) “.” “Sent”
* LIST (\HasNoChildren) “.” “Spam”
* LIST (\HasNoChildren) “.” “Trash”
r OK Completed (0.000 secs 8 calls)
s select Drafts
* FLAGS (\Answered \Flagged \Draft \Deleted \Seen)
* OK [PERMANENTFLAGS (\Answered \Flagged \Draft \Deleted \Seen \*)]
* 2 EXISTS
* 0 RECENT
* OK [UIDVALIDITY 1394475578]
* OK [UIDNEXT 3]
* OK [NOMODSEQ] Sorry, modsequences have not been enabled on this mailbox
* OK [URLMECH INTERNAL]
s OK [READ-WRITE] Completed
t search all
* SEARCH 1 2
t OK Completed (2 msgs in 0.000 secs)
E fetch 1 (body[text])
* 1 FETCH (BODY[TEXT] {6}
test
)
E OK Completed (0.000 sec)
. logout
* BYE LOGOUT received
. OK Completed
Connection closed by foreign host.
tarja@tux:~>

Man erkennt nach der Initiierung des Dialogs, dass der Cyrus IMAP-Server zunächst seine Fähigkeiten – u.a. STARTTLS- ausweist. Das explizit abgesetzte “starttls”-Kommando funktioniert entsprechend problemlos.

Ferner sieht man, dass habe ich danach einige IMAP-Kommandos an den Server abgesetzt habe. Welche IMAP-Kommandos es gibt und wie man mit ihrer Hilfe unter “telnet” oder “imtest” direkt mit dem IMAP-Server kommunizieren kann, erfährt man z.B. hier:

http://www.skytale.net/blog/archives/23-Manual-IMAP.html
http://www.tcpipguide.com/free/t_IMAPOverviewHistoryVersionsandStandards.htm
http://donsutherland.org/crib/imap
http://adityo.blog.binusian.org/?tag=telnet-imap-command
http://busylog.net/telnet-imap-commands-note/
http://help.notify.net/TechDocs/enterprise/Troubleshooting/NetHelp/index.html?turl=WordDocuments%2Fotherimapcommands.htm

Jedes IMAP-Kommando wird durch einen Klein- oder Groß-Buchstaben oder einen “.” am Anfang der Zeile mit anschließendem Blank eingeleitet. Dieser Buchstabe ist syntaktisch erforderlich; er erleichtert die Orientierung im Kommandoablauf und zeigt anhand abschließender Bestätigungsmeldungen zu gleichen Startbuchstaben am Anfang der Zeile an, welche Antworten zu welchem Kommando gehören.

Einen ähnlichen Dialog
mit dem IMAP-Dienstes hätte man auch im Rahmen des Testkommando “imtest” führen können:

imtest -v -t “” -a tarja -u tarja -m login mycyrus

Das Absetzen des imtest-Kommandos erlaubt es einem zudem, den Austausch von TLS-Informationen direkt zu verfolgen. Das kann jeder mal selbst testen. Zu “imtest”findet man weitere Infos auf der man-Seite:
http://linux.die.net/man/1/imtest
http://www.cyrusimap.org/docs/cyrus-imapd/2.3.16/man/imtest.1.php

Der aufmerksame Leser wird beim Studieren des obigen IMAP-Dialogs unter “telnet” natürlich mitbekommen haben, dass ich dort im Ordner Drafts zwei Mails gefunden und eine davon sogar geöffnet habe. Natürlich muss man sich fragen, wie das vor sich gehen soll, wenn der Folder “Drafts” doch gerade erst angelegt wurde. Keine Sorge: Die Mails kommen nicht aus dem Nirwana; ich hatte sie dort vorab händisch reinkopiert, um zeigen zu können, dass man Mails auch über telnet öffnen kann.

Im nächsten Teil
Cyrus IMAP mit SASL, PAM, SSSD und LDAP – Opensuse 12.3/13.1 – IV
kümmere ich mich dann um eine Kmail-Anbindung an unseren offenbar funktionstüchtigen IMAP-Server, der unsere Testuserin “tarja” erfolgreich über ein LDAP-System authentifiziert hat.