Category Archives: Opensuse

Upgrade OpenLDAP-Server unter Opensuse auf Leap 42.2 – Fehler – OLC-Konfiguration für Datenbank Backends

Posted on by

Heute bin ich endlich eine Aufgabe angegangen, dass ich schon seit einem Jahr vor mir her schiebe: Ich habe einen LDAP-Server, der noch unter Opensuse 13.1 lief auf Opensuse Leap 42.2 umgestellt.

Die Umstellung habe ich schrittweise abgewickelt : OS 13.1 => OS 13.2 => Leap 42.1 => Leap 42.2. Beschreibungen eines generellen Upgrade-Vorgehensmodell auf Basis von “zypper” für Opensuse finden sich hier:

https://www.unixmen.com/upgrade-opensuse-13-2-opensuse-13-1/
https://www.unixmen.com/how-to-upgrade-to-opensuse-42-1-from-opensuse-13-2/
http://www.2daygeek.com/how-to-upgrade-from-opensuse-leap-42-1-to-opensuse-leap-42-2/2/

Die Paket-Updates liefen (bis auf bekannte Kleinigkeiten) eigentlich ganz gut ab; jede neue erzielte Opensuse-Version konnte erfolgreich gebootet werden. Auch praktisch alle Services liefen – mit Ausnahme eines bekannten Apache-Problems, das nach den Updates ein Eingreifen in bestimmte Konfigurationseinstellungen erfordert. Und eben auch bis auf den LDAP-Service; nach dem letzten Update musste ich schnell zur Kenntnis nehmen, dass es da ein gravierendes Problem gab.

Nach Upgrade zu Leap 42.2 war kein Login mehr auf anderen Servern möglich

Nach dem Übergang von Leap 42.1 zu Leap 42.2 konnte ich mich mit definierten UIDs (außer root) nicht mehr auf Server-Systemen in unserem LAN einloggen. Praktisch alle unsere Server beziehen Authentifizierungsinformationen eben vom zwischenzeitlich upgegradeten OpenLDAP-Server.

Die Authentifizierung läuft dabei über eine Kombination aus SSSD-Services und OpenLDAP (unter TLS). Zunächst dachte ich deshalb, dass ggf. der SSSD-Dämon auf dem OpenLDAP Server nicht laufen würde. Der erfreute sich aber selbst nach den drei Updates bester Gesundheit: 

serv:~ # rcsssd status
● sssd.service - System Security Services Daemon
   Loaded: loaded (/usr/lib/systemd/system/sssd.service; enabled; vendor preset: disabled)
   Active: active (running) since Thu 2017-06-01 15:21:30 CEST; 1h 9min ago
  Process: 1249 ExecStart=/usr/sbin/sssd -D -f (code=exited, status=0/SUCCESS)
 Main PID: 1294 (sssd)
    Tasks: 4 (limit: 512)
   CGroup: /system.slice/sssd.service
           ├─1294 /usr/sbin/sssd -D -f
           ├─1297 /usr/lib/sssd/sssd_be --domain default --uid 0 --gid 0 --debug-to-files
           ├─1298 /usr/lib/sssd/sssd_nss --uid 0 --gid 0 --debug-to-files
           └─1299 /usr/lib/sssd/sssd_pam --uid 0 --gid 0 --debug-to-files

Jun 01 15:21:27 serv systemd[1]: Starting System Security Services Daemon...
Jun 01 15:21:29 serv sssd[1294]: Starting up
Jun 01 15:21:29 serv sssd[be[1297]: Starting up
Jun 01 15:21:29 serv sssd[1299]: Starting up
Jun 01 15:21:29 serv sssd[1298]: Starting up
Jun 01 15:21:30 serv systemd[1]: Started System Security Services Daemon.

Vom OpenLDAP-Service ließ sich das dagegen nicht behaupten; so zeigte ein Blick in das systemd Journal mittels
“journalctl -xe” : 

Jun 01 15:48:17 serv systemd[1]: Starting OpenLDAP Server Daemon...
-- Subject: Unit slapd.service has begun start-up
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- 
-- Unit slapd.service has begun starting up.
Jun 01 15:48:17 serv slapd[15835]: @(#) $OpenLDAP: slapd 2.4.44 $
                                          opensuse-buildservice@opensuse.org
Jun 01 15:48:17 serv slapd[15835]: UNKNOWN attributeDescription "OLCDBCACHESIZE" inserted.
Jun 01 15:48:17 serv slapd[15835]: UNKNOWN attributeDescription "OLCDBCHECKPOINT" inserted.
Jun 01 15:48:17 serv slapd[15835]
: UNKNOWN attributeDescription "OLCDBCONFIG" inserted.
Jun 01 15:48:17 serv slapd[15835]: UNKNOWN attributeDescription "OLCDBIDLCACHESIZE" inserted.
Jun 01 15:48:17 serv slapd[15835]: UNKNOWN attributeDescription "OLCDBINDEX" inserted.
Jun 01 15:48:17 serv slapd[15835]: config error processing olcDatabase={1}hdb,cn=config:
Jun 01 15:48:17 serv slapd[15835]: DIGEST-MD5 common mech free
Jun 01 15:48:17 serv slapd[15835]: slapd stopped.
Jun 01 15:48:17 serv slapd[15835]: connections_destroy: nothing to destroy.
Jun 01 15:48:17 serv start[15835]: Starting ldap-server
Jun 01 15:48:17 serv systemd[1]: slapd.service: Control process exited, code=exited status=1
Jun 01 15:48:17 serv systemd[1]: Failed to start OpenLDAP Server Daemon.
-- Subject: Unit slapd.service has failed
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- 
-- Unit slapd.service has failed.
-- 
-- The result is failed.
Jun 01 15:48:17 serv systemd[1]: slapd.service: Unit entered failed state.
Jun 01 15:48:17 serv systemd[1]: slapd.service: Failed with result 'exit-code'.

Auch ein manueller Start von OpenLDAP mittels

serv:/etc/openldap/slapd.d # /usr/sbin/slapd -u ldap -h ldap://127.0.0.1:389/ -d 256

lieferte die gleichen Fehlermeldungen. Der Grund für die fehlgeschlagenen Logins lag also schlicht darin, dass ausgerechnet der OpenLDAP-Service, über den in unserem LAN User und Gruppen verwaltet werden, nach den Upgrades – genauer: nach dem letzten Upgrade – nicht mehr lief.

Eigenschaften der LDAP “Datenbank Backends” wurden offenbar nicht erkannt

Die Fehlermeldungen deuteten an, dass Eigenschaften des eingesetzten Datenbank-Backends (in meinem Fall hdb) dem System nicht bekannt waren. Daraus ergibt sich die Frage: Weiß die neue OpenLDAP-Installation unter Laep 42.2 überhaupt irgendetwas von ihren Backends?

Wenn man sich ein wenig mit LDAP beschäftigt hat, hat man sicher mitbekommen, dass die Datenbank-Backends in neueren OpenLDAP-Versionen (wie andere LDAP-Komponenten auch) über Module geladen und konfiguriert werden können. In früheren Versionen haben dagegen Build-Optionen bei der Erzeugung der LDAP-Programme dafür gesorgt, dass diverse Backends von Haus verfügbar waren. Einträge in der “slapd.conf” dienten dann der Auswahl der konkret heranzuziehenden Datenbank-Variante.

Man kann Backends aber eben auch dynamisch nachladen. Typischerweise sollte das in der Grundkonfiguration von OpenLDAP geschehen; was wenn das aber unter Leap 42.2 nicht der Fall ist?

Mit ein wenig Recherche im Internet findet man genügend Hinweise, wie man Datenbank-Backend-Module lädt und dass das tatsächlich in etlichen Installationen der Fall ist: Siehe etwa

http://vaab.blog.kal.fr/2010/03/06/how-to-add-a-schema-in-openldap-24/
(siehe dort den Abschnitt (“How to add a database?”)).

https://www.digitalocean.com/community/tutorials/how-to-configure-openldap-and-perform-administrative-ldap-tasks
http://nodedirector.bigsister.ch/refdoc/group__ref__cfg–director__slapd__conf.html
https://github.com/yast/yast-auth-server/blob/master/package/yast2-auth-server.changes
https://cat.pdx.edu/~nibz/openldap/openldap-server.html
und
http://www.openldap.org/doc/admin24/backends.html
http://www.openldap.org/doc/admin24/
slapdconf2.html
Im letzteren Artikel siehe insbesondere Absatz 5.2.2.

Die genannten Artikel deuten an, dass man die Direktive “olcModuleLoad” in der sogenannten OLC-Grundkonfiguration des LDAP-Servers einsetzen soll.

Dass in meiner aktuellen LDAP-Konfiguration tatsächlich Module geladen werden, zeigte folgender Befehl: 

  
serv:/etc/openldap/slapd.d # grep -r ModuleLoad .
./cn=config/cn=module{0}.ldif:olcModuleLoad: {0}back_monitor.la

Leider handelt es sich hier aber nicht um ein Datenbank-Backend-Modul! Die nächste Frage war also: Welche Datenbank-Module werden denn überhaupt benutzt? 

  
serv:/etc/openldap/slapd.d/cn=config # grep -r olcDatabase .
./olcDatabase={2}monitor.ldif:dn: olcDatabase={2}Monitor
./olcDatabase={2}monitor.ldif:objectClass: olcDatabaseConfig
./olcDatabase={2}monitor.ldif:olcDatabase: {2}Monitor
./olcDatabase={-1}frontend.ldif:dn: olcDatabase={-1}frontend
./olcDatabase={-1}frontend.ldif:objectClass: olcDatabaseConfig
./olcDatabase={-1}frontend.ldif:olcDatabase: {-1}frontend
./olcDatabase={-1}frontend.ldif:structuralObjectClass: olcDatabaseConfig
./olcDatabase={0}config.ldif:dn: olcDatabase={0}config
./olcDatabase={0}config.ldif:objectClass: olcDatabaseConfig
./olcDatabase={0}config.ldif:olcDatabase: {0}config
./olcDatabase={0}config.ldif:structuralObjectClass: olcDatabaseConfig
./olcDatabase={1}hdb.ldif:dn: olcDatabase={1}hdb
./olcDatabase={1}hdb.ldif:objectClass: olcDatabaseConfig
./olcDatabase={1}hdb.ldif:olcDatabase: {1}hdb

Aha, ich hatte die LDAP-Datenbanken bei der ursprünglichen Servereinrichtung unter OS 13.1 offenbar als “hdb”-Banken aufgesetzt. Es lag daher nahe, mal versuchsweise das entsprechende Backend-Modul zu laden.

Ergänzungen in slapd.conf sind nicht hinreichend, wenn zur Konfiguration OLC [cn=config] benutzt wird

Dummerweise bin ich bei den Recherchen dann aber auch über folgenden Ratschlag gestolpert:

https://forums.opensuse.org/showthread.php/522385-SlapD-will-nach-Update-von-42-1-nicht-mehr?p=2817944#post2817944

Dem bin ich dann naiverweise gefolgt – und habe zunächst lediglich die “slapd.conf” so ergänzt, dass alle Backends geladen werden: 

# Load backend modules such as database engines
modulepath /usr/lib64/openldap
moduleload back_mdb.la
moduleload back_hdb.la
moduleload back_bdb.la

Das reichte in meinem Fall natürlich aber nicht ! Warum? Ich hatte die LDAP-Konfiguration beim Aufsetzen des LDAP-Servers unter Opensuse 13.1 mittels OLC, also über Einträge unter “cn=config“, vorgenommen! (Für weniger LDAP-Kundige: Die Konfigurationseinträge unter OLC sind ganz im Stil von LDAP-Datenbank-Records gehalten.)

Unter Opensuse wird die Verwendung der sog. Online-[OLC]-Konfiguration des OpenLDAP-Servers in der Datei “/etc/sysconfig/openldap” über die Option

OPENLDAP_CONFIG_BACKEND= “files|ldap”

festgelegt. In meinem Fall:

OPENLDAP_CONFIG_BACKEND=”ldap”

Das steuert dann den Aufruf des LDAP-Services und den Start des zugehörigen Programms. Letzteres wird dann die Konfigurationseinstellungen unter dem Verzeichnis “/etc/openldap/slapd.d/cn=config” auslesen und zur Anwendung bringen.

Die OLC-Konfiguration des OpenLDAP-Servers kann selbst über LDIF-Dateien oder LDAP-CLI-Kommandos (“ldapadd”, “ldapmodify”) angepasst werden. Damit werden dann die Einträge unter “cn=config” passend modifiziert.

Die notwendige initiale Datenbank-Konfiguration beim Starten des LDAP-Servers erfolgt unter dem Verzeichnis “cn=config” übrigens über folgende LDIF-Datei:

/etc/
openldap/slapd.d/cn=config/olcDatabase\=\{0\}config.ldif

Eine andere Stelle, die grundsätzlich auch für das Laden von Modulen mit Hilfe von “olcLoadModule”-Statements in Frage käme, wäre die grundlegende Konfigurationsdatei für Module:

/etc/openldap/slapd.d/cn=config/cn=module{0}.ldif

Sie hat in meinem Fall den Inhalt: 

# AUTO-GENERATED FILE - DO NOT EDIT!! Use ldapmodify.
# CRC32 5b49ffc3
dn: cn=module{0}
objectClass: olcModuleList
cn: module
cn: module{0}
structuralObjectClass: olcModuleList
entryUUID: 49b0aac8-614a-1032-8c55-83b54eef05ad
creatorsName: cn=config
createTimestamp: 20130604100720Z
olcModuleLoad: {0}back_monitor.la
entryCSN: 20130604100720.232512Z#000000#000#000000
modifiersName: cn=config
modifyTimestamp: 20130604100720Z

Ein möglicher Weg zur Ergänzung von Statements, mit denen man alle üblichen Datenbank-Module laden würde, sähe hierfür in etwa so aus: 

serv:/etc/openldap/slapd.d # ldapadd -Y EXTERNAL -H ldapi:///
dn: cn=module{0},cn=config
objectClass: olcModuleList
cn: module{0}
olcModulePath: /usr/lib64/openldap
olcModuleLoad: back_bdb.la
olcModuleLoad: back_hdb.la
olcModuleLoad: back_mdb.la

Würde das im vorliegenden Fehlerfall funktionieren? Natürlich nicht – der OpenLDAP-Server läuft ja überhaupt nicht und ein “ldapadd”-Befehl könnte deshalb gar nicht umgesetzt werden!

Direktes Editieren der Konfiguration?

Manche mutige Zeitgenossen wagen es bei kleineren Änderungen (und nach einem vorherigen Sicherheits-Backup der LDAP-Konfiguration), die Einträge in den LDIF-Dateien unter dem Verzeichnis “/etc/openldap/slapd.d/cn=config” auch direkt über Editor-Befehle zu modifizieren. An dieser Stelle muss allerdings gesagt werden, dass die offiziellen OpenLDAP Aministrationshandbücher davon streng abraten. Na ja …

In meinem Fall war eigentlich nur eine Ergänzung erforderlich (s.o.). Ich verhielt mich also mutig; nach einem 

serv:/etc/openldap/slapd.d/cn=config # vi olcDatabase\=\{0\}config.ldif

habe ich die folgende Zeile in der genannten Datei hinzugefügt: 

olcModuleLoad: {0}back_hdb

Insgesamt sieht die entsprechende Konfigurationsdatei “olcDatabase\=\{0\}config.ldif” nun so aus: 

# AUTO-GENERATED FILE - DO NOT EDIT!! Use ldapmodify.
# CRC32 a4b13d6e
dn: olcDatabase={0}config
objectClass: olcDatabaseConfig
olcDatabase: {0}config
olcRootDN: cn=config
structuralObjectClass: olcDatabaseConfig
entryUUID: 14a9819c-624a-1032-8687-49710846e729
creatorsName: cn=config
createTimestamp: 20130604100551Z
entryCSN: 20130604100551.266001Z#000000#000#000000
modifiersName: cn=config
modifyTimestamp: 20130604100551Z
olcModuleLoad: {0}back_hdb

Man sieht nebenbei: Mein OpenLDAP-Server ist schon was älter. Nach der obigen Modifikation lief und läuft er jedoch auch unter Leap 42.2 wieder und verrichtet nun erneut seinen wichtigen Dienst im Netz: 

serv:/etc/openldap/slapd.d/cn=config # systemctl start slapd.service 
serv:/etc/openldap/slapd.d/cn=config # systemctl status slapd.service 
● slapd.service - OpenLDAP Server Daemon
   Loaded: loaded (/usr/lib/systemd/system/slapd.service; enabled; vendor preset: disabled)
   Active: active (running) since Thu 2017-06-01 16:32:38 CEST; 2h 28min ago
  Process: 2632 ExecStart=/usr/lib/openldap/start (code=exited, status=0/SUCCESS)
 Main PID: 2735 (slapd)
    Tasks: 5 (limit: 512)
   CGroup: /system.slice/slapd.service
           └─2735 /usr/sbin/slapd -h ldap:/// ldaps:/// ldapi:/// -F /etc/openldap/slapd.d -u ldap -g ldap -o slp=off

Jun 01 19:00:25 serv slapd[2735]: conn=1304 op=37 SEARCH RESULT tag=101 err=0 nentries=0 text=
Jun 01 19:00:49 serv slapd[2735]: conn=1325 op=6 SRCH base="dc=superduper,dc=de" scope=2 deref=0 filter="(&(
objectClass=posixAccount)(uid=*)(uidNumber=*)(gidNumber=*))"
Jun 01 19:00:49 serv slapd[2735]: conn=1325 op=6 SRCH attr=objectClass uid userPassword uidNumber gidNumber gecos homeDirectory loginShell krbPrincipalName cn memberOf entryuuid modi...
Jun 01 19:00:49 serv slapd[2735]: conn=1325 op=6 SEARCH RESULT tag=101 err=0 nentries=5 text=
Jun 01 19:00:50 serv slapd[2735]: conn=1325 op=7 SRCH base="dc=superduper,dc=de" scope=2 deref=0 filter="(&(objectClass=posixGroup)(cn=*)(&(gidNumber=*)(!(gidNumber=0))))"
Jun 01 19:00:50 serv slapd[2735]: conn=1325 op=7 SRCH attr=objectClass cn userPassword gidNumber member entryuuid modifyTimestamp modifyTimestamp
Jun 01 19:00:50 serv slapd[2735]: conn=1325 op=7 SEARCH RESULT tag=101 err=0 nentries=0 text=
Jun 01 19:00:50 serv slapd[2735]: conn=1325 op=8 SRCH base="dc=superduper,dc=de" scope=2 deref=0 filter="(&(objectClass=ipService)(cn=*)(ipServicePort=*)(ipServiceProtocol=*))"
Jun 01 19:00:50 serv slapd[2735]: conn=1325 op=8 SRCH attr=objectClass cn ipServicePort ipServiceProtocol modifyTimestamp
Jun 01 19:00:50 serv slapd[2735]: conn=1325 op=8 SEARCH RESULT tag=101 err=0 nentries=0 text=
Hint: Some lines were ellipsized, use -l to show in full.

Ich rate dennoch zur Vorsicht! Wer lieber nicht mutig sein will und eher einen sauberen Weg bevorzugt, findet einen alternativen Vorschlag in den Diskussionsbeiträgen unter folgender Bug-Meldung:
https://bugzilla.opensuse.org/show_bug.cgi?id=1011582.

Viel Spass mit OpenLDAP unter Opensuse Leap 42.2 !

Opensuse Leap 42.1, Apache 2.4, Nagios-Modul und veraltete Access Right Syntax

Posted on by

Vor kurzem hatte ich das zweifelhafte Vergnügen, einen virtualisierten LAMP-Server von Opensuse 13.1 auf Opensuse Leap 42.1 zu hieven. Das ging zu meiner Überraschung weitgehend problemfrei über die Bühne. Eine kleine Besonderheit gab es aber schon.

Problem mit Apache 2.4 und der Konfiguration des Nagios-Moduls

Das Problem, dass bei der Umstellung auftauchte, war der Übergang des Apache-Servers zu einer neuen Version (2.2 => 2.4). Auf dem alten Server lief auch das Nagios-Modul für Apache mit. Nach dem Upgrade auf Opensuse Leap 42.1 verweigerte Apache den Start. 

lamp:~ # systemctl start apache2.service 
Job for apache2.service failed. See "systemctl status apache2.service" and "journalctl -xn" for details.
xlamp:~ # systemctl start apache2.service 
Job for apache2.service failed. See "systemctl status apache2.service" and "journalctl -xn" for details.

 
und 

lmp:~ # systemctl status apache2.service 
apache2.service - The Apache Webserver
   Loaded: loaded (/usr/lib/systemd/system/apache2.service; disabled)
   Active: failed (Result: exit-code) since Wed 2016-10-19 17:47:09 CEST; 37s ago
  Process: 2279 ExecStop=/usr/sbin/start_apache2 -DSYSTEMD -DFOREGROUND -k graceful-stop (code=exited, status=1/FAILURE)
  Process: 2272 ExecStart=/usr/sbin/start_apache2 -DSYSTEMD -DFOREGROUND -k start (code=exited, status=1/FAILURE)
 Main PID: 2272 (code=exited, status=1/FAILURE)

Oct 19 17:47:09 lmp start_apache2[2272]: AH00526: Syntax error on line 15 of /etc/apache2/conf.d/nagios.conf:
Oct 19 17:47:09 lmp start_apache2[2272]: Invalid command 'Order', perhaps misspelled or defined by a module ...ation
Oct 19 17:47:09 lmp systemd[1]: apache2.service: main process exited, code=exited, status=1/FAILURE
Oct 19 17:47:09 lmp start_apache2[2279]: AH00526: Syntax error on line 15 of /etc/apache2/conf.d/nagios.conf:
Oct 19 17:47:09 lmp start_apache2[2279]: Invalid command 'Order', perhaps misspelled or defined by a module ...ation
Oct 19 17:47:09 lmp systemd[1]: apache2.service: control process exited, code=exited status=1
Oct 19 17:47:09 lmp systemd[1]: Failed to start The Apache Webserver.
Oct 19 17:47:09 lmp systemd[1]: Unit apache2.service entered failed state.
Hint: Some lines were ellipsized, use -l to show in full.

 

Problemlösung 1 – Korrektur des Files nagios.conf

Die Ursache dieses Problems liegt in der Anweisungssyntax der Konfigurationsdatei zum Nagios-Modul und nicht im Nagios-Modul selbst. Die Anweisung zu den Zugangsrechten für Webserver-Verzeichnisse sind zwar noch für Apache-Versionen < 2.4 gültig; nicht aber für die Version 2.4.

Nehmen wir als Beispiel die Direktiven zu einem Verzeichnis aus der Datei “/etc/apache2/conf.d/nagios.conf”: 

   
<Directory "/usr/lib/nagios/cgi">
#  SSLRequireSSL
   Options ExecCGI
   AllowOverride None
   Order allow,deny
   Allow from all
#  Order deny,allow
#  Deny from all
#  Allow from 127.0.0.1
   AuthName "Nagios Access"
   AuthType Basic
   AuthUserFile /etc/nagios/htpasswd.users
   Require valid-user
</Directory>

Hier werden die Zugangsrechte in klassischer Manier durch die Statements 

   Order allow,deny
   Allow from all

geregelt. Diese Statements sind unter Apache 2.4 aber nicht mehr zu verwenden!

Nähere Informationen zur neuen Syntax liefert die Dokumentation unter:
https://httpd.apache.org/docs/2.4/upgrading.html

Die obige Sequenz ist – falls man die Zugriffsberechtigung tatsächlich so handhaben will –
durch das Statement

Require all granted

zu ersetzen. Also 

   
<Directory "/usr/lib/nagios/cgi">
#  SSLRequireSSL
   Options ExecCGI
   AllowOverride None
#	
   Require all granted 
   #   Order allow,deny
   #   Allow from all
#
#  Order deny,allow
#  Deny from all
#  Allow from 127.0.0.1
   AuthName "Nagios Access"
   AuthType Basic
   AuthUserFile /etc/nagios/htpasswd.users
   Require valid-user
</Directory>

Die auskommentierte Sequenz 

#  Order deny,allow
#  Deny from all
#  Allow from 127.0.0.1

wäre übrigens zu ersetzen durch

Require host 127.0.0.1

Führt man die vorgeschlagenen Änderungen für alle Directories in der “nagios.conf” durch, so läuft der Neustart u.U. erfolgreich. In meinem Fall war das nicht so, da ich natürlich auch in anderen Konfigurationsfiles (u.a. zu Webdomainen) weitere Access Right Statements mit alter Syntax eingefügt hatte. Hat man auch die dortigen Fehler korrigiert, läuft Apache2 wieder.

Problemlösung 2 – Nutzung eines Kompatibilitätsmoduls

Die Seite https://httpd.apache.org/docs/2.4/upgrading.html empfiehlt, wenn möglich, alle Änderungen auf einen Schlag durchzuführen. Das kann je nach Apache-Host und selbst eingeführten Zugangsrechten für die implementierten Web-Domainen aber aufwändig werden.

Ist einem diese Arbeit erstmal zu viel und will man nach dem Upgrade zunächst nur den Start des Apache-Servers trotz der neuen Syntax sicherstellen, so kann man das Modul “mod_access_compat” zu den Modulen hinzufügen, die der Apache-Server laden soll.

Hierzu benutzt man z.B. das Kommando “a2enmod” (s. etwa http://www.sysadminslife.com/linux/aktivierte-apache-module-anzeigen-deaktivieren-aktivieren/.
Unter Opensuse kann man die Module aber auch in einer entsprechenden Zeile der Datei “/etc/sysconfig/apache2” hinterlegen; also z.B.:

APACHE_MODULES=”actions alias auth_basic authn_file authz_host authz_groupfile authz_user autoindex cgi dir env expires include log_config mime mod_access_compat mod_rewrite negotiation setenvif ssl userdir php5 reqtimeout authn_core authz_core version”

Viel Spaß weiter beim Betrieb von Apache!

Firefox – HTML5 – kein Sound bei purem Alsa und Einsatz einer .asoundrc für eine Xonar D2X

Posted on by

Vor etwa 2 Jahren hatte ich in diesem Blog mehrere Artikel zur Einrichtung der Xonar D2X unter Linux – genauer unter Opensuse 13.1 (mit KDE) – verfasst. Ein Fazit war, dass Pulseaudio für diese Karte nicht vernünftig funktionierte. Zumindest dann nicht,

  • wenn man Stereo-Signale auf mehrere Ausgangskanäle upmixen will
  • und wenn man seine relativen Volume-Einstellungen für die verschiedenen analogen Ausgangskanäle nicht ständig bei Lautstärke-Änderungen unter dem Mixer von “pavucontrol” verlieren will.

Die Karte selbst nimmt keinen Mix auf N.1-Ausgabe-Systeme vor; das direkt unterstützte Mixing blendet den Center und Bass-Speaker aus.

Die Xonar D2X läuft bei mir inzwischen unter Leap 42.1. Dass der Pulseaudio-Layer mit pavucontrol als Mixer trotz diverser optischer Aufbesserungen inzwischen besser mit Mehrkanalkarten umgehen könne, sehe ich nicht. Ich bleibe dabei: Pulseaudio schafft mehr Probleme als es löst. Das liegt weniger an der Idee eines auf Alsa und anderen Soundsystemen aufsetzenden Zwischenlayers als an der schlechten Umsetzung dieses Layers für verschiedene Karten – im besonderen Multikanal-Karten. Problematisch ist dabei, dass für eine evtl. mögliche Reproduktion der Mixing- und PCM-Plugin-Optionen von Alsa unter Pulseaudio aus meiner Sicht erhebliche Detailkenntnisse von Pulseaudio erforderlich sind. Ganz schlimm wird es nach meiner Erfahrung dann, wenn das System mehrere Multikanal-Soundkarten enthält.

Im letzten meiner Artikel zur D2X
Asus Xonar D2X unter Linux / Opensuse 13.1 – III – Alsa Upmix 2.0 auf 5.1
hatte ich eine Muster-Datei “~/.asoundrc” für das Upmixing von Stereo-Eingangssignalen angegeben und die völlige Deaktivierung von Pulseaudio empfohlen. Über die “.asoundrc” wurde auch ein SW-Volume-Regler angelegt, um für alle Quellen und über alle Output-Kanäle der D2X hinweg die Lautstärke regeln zu können, ohne die relative Laustärke-Gewichtung der Kanäle zueinander zu verändern.

Probleme mit Firefox und mit KDE5

Leider verlassen sich offenbar immer mehr Entwickler auf ein laufendes Pulseaudio – so schlecht das auch sein mag. Das führt dann bei denjenigen, die aus guten Gründen nur mit Alsa arbeiten wollen, zu mehr oder weniger großen Problemen. Ein schlimmer Bug ist aus meiner Sicht der, dass z.B. unter KDE 5 (unter OS Leap 42.1) von bei mir über 20 verfügbaren HW und virtuellen PCM Alsa-Devices nur noch genau eines angezeigt wird, wenn Pulseaudio deaktiviert ist (s. https://bugs.kde.org/show_bug.cgi?id=362476). Dennoch sind die Devices da und aktiv – wie etwa die Device Übersichten unter Amarok oder VLC beweisen.

Richtig übel wurde es aber, als Firefox [FF] plötzlich keinen Sound mehr ohne Pulseaudio zu liefern schien.
Auch ein Leser, der meinen Vorschlägen aus dem oben genannten Artikel gefolgt ist, ist nun über dieses Problem gestolpert, dass auch mich schon seit einiger Zeit geplagt hat:

https://wiki.gentoo.org/wiki/ALSA und dort den Bereich “Troubleshooting” oder auch https://bbs.archlinux.org/viewtopic.php?id=186650.

Bei mir dagegen war das Problem mit FF anders gelagert. Vielleicht helfen die nachfolgenden Ausführungen deshalb auch dem einen oder anderen Leser weiter, der sein Firefox-Problem bislang nicht lösen konnte.

Ausgangssituation mit der Xonar D2X als primärer Soundkarte

In meinem aktuellen Arbeitsplatzsystem befinden sich mehrere Soundkarten. Ich befasse mich in diesem Artikel aber nur mit dem Fall, dass lediglich die Xonar D2X als primäre Karte genutzt wird. Unter Opensuse (in meinem Fall in der Version Leap 42.1) kann man die Grundeinrichtung etwa mit YaST vornehmen:

yast_snd

Mit Hilfe der Funktionalität von YaST’s Sound-Einrichtung deaktivieren wir zudem das Pulseaudio-System mittels entsprechender Optionen unter dem Button “Andere” >> “Pulseaudio-Konfiguration” vollständig. (Unter anderen Linux-Varianten sind zur Deaktivierung von Pulseaudio andere Schritte erforderlich). Danach sichern wir die Einstellungen und starten das System neu.

Die explizite Einrichtung der D2X mittels YaST bewahrt uns ggf. noch nicht zwingend vom Laden weiterer Kernelmodule und Treiber für andere Soundkarten durch udev. Wir müssen daher für die nachfolgenden Alsa-Einstellungen prüfen, an welcher Position die D2X unter den verschiedenen Soundkarten tatsächlich erkannt wird.

Die grundsätzlich verfügbaren Karten zeigen folgende Befehle; die D2X ist u.a. als “C-Media Electronics Inc CMI8788 [Oxygen HD Audio]” unter den PCI-Devices erkennbar. 

me@mysystem:~> aplay -l | grep Karte  
rmo@rux:/proc/asound> aplay -l | grep Karte
Karte 0: D2X [Xonar D2X], Gerät 0: Multichannel [Multichannel]
Karte 0: D2X [Xonar D2X], Gerät 1: Digital [Digital]
Karte 1: PCH [HDA Intel PCH], Gerät 0: ALC1150 Analog [ALC1150 Analog]
Karte 1: PCH [HDA Intel PCH], Gerät 1: ALC1150 Digital [ALC1150 Digital]
Karte 2: NVidia [HDA NVidia], Gerät 3: HDMI 0 [HDMI 0]
Karte 2: NVidia [HDA NVidia], Gerät 7: HDMI 1 [HDMI 1]
Karte 2: NVidia [HDA NVidia], Gerät 8: HDMI 2 [HDMI 2]
Karte 2: NVidia [HDA NVidia], Gerät 9: HDMI 3 [HDMI 3]
Karte 3: XFi [Creative X-Fi], Gerät 0: ctxfi [Front/WaveIn]
Karte 3: XFi [Creative X-Fi], Gerät 1: ctxfi [Surround]
Karte 3: XFi [Creative X-Fi], Gerät 2: ctxfi [Center/LFE]
Karte 3: XFi [Creative X-Fi], Gerät 3: ctxfi [Side]
Karte 3: XFi [Creative X-Fi], Gerät 4: ctxfi [IEC958 Non-audio]

 
und 

root:~ # lspci -nn | grep Audio
00:1f.3 Audio device [0403]: Intel 
Corporation Sunrise Point-H HD Audio [8086:a170] (rev 31)
01:00.1 Audio device [0403]: NVIDIA Corporation Device [10de:0fba] (rev a1)
02:00.0 Audio device [0403]: Creative Labs EMU20k2 [X-Fi Titanium Series] [1102:000b] (rev 03)
04:04.0 Multimedia audio controller [0401]: C-Media Electronics Inc CMI8788 [Oxygen HD Audio] [13f6:8788]

 
Nach der Konfiguration der D2X mit YaST und einem Neustart des Systems finden wir unter Opensuse folgenden Eintrag in der Datei “/etc/modprobe.d/50-sound.conf” vor: 

options snd slots=snd-virtuoso
# rChK.j3r564qQSgF:Virtuoso 200 (Xonar D2X)
alias snd-card-0 snd-virtuoso

Wir lassen diesen Eintrag unverändert.

Die aktuell gültige Reihenfolge der Karten ist auch wie folgt erkennbar: 

me@mysystem:~> cat /proc/asound/cards
 0 [D2X            ]: AV200 - Xonar D2X
                      Asus Virtuoso 200 at 0xd000, irq 16
 1 [PCH            ]: HDA-Intel - HDA Intel PCH
                      HDA Intel PCH at 0xdf640000 irq 146
 2 [NVidia         ]: HDA-Intel - HDA NVidia
                      HDA NVidia at 0xdf080000 irq 17
 3 [XFi            ]: SB-XFi - Creative X-Fi
                      Creative X-Fi 20K2 Unknown

 
Die D2X wird also von ALSA definitiv als erste Soundkarte (mit der Nummer 0) verwendet – was immer udev sonst entdeckt und an Modulen nachgeladen haben mag. Wäre dies nicht der Fall, hätten wir dies in der Datei “/etc/modprobe.d/50-sound.conf” durch Festlegung von “index”-Parameter-Werten für die Module festlegen müssen (s. hierzu etwa https://bbs.archlinux.org/viewtopic.php?pid=1445611#p1445611).

Eine mit Firefox nicht funktionierende “.asoundrc”

Meine ursprüngliche “~/.asoundrc” für diesen Fall sah (etwas verkürzt) etwa so aus: 

pcm.dmix51 {
	type asym
	playback.pcm {
		type dmix

		# Don't block other users
		# http://www.alsa-project.org/alsa-doc/alsa-lib/pcm_plugins.html
		ipc_key_add_uid true

		ipc_key 5678293
		ipc_perm 0660
		ipc_gid audio

		slave {
			# 2 for stereo, 6 for surround51, 8 for surround71
			channels 6
			pcm {
				# mplayer chooses S32_LE, but others usually S16_LE
				#format S24_LE
				format S16_LE

				# 44100 or 48000
				# 44100 for music, 48000 is compatible with most h/w
				rate 44100
				#rate 48000

				type hw
				card 0
				device 0
				subdevice 0
			}

			#period_size 512
			period_size 1024
			#period_size 512

			# 4096 might make sound crackle
			# mplayer2 chooses 8192. Half-Life 2 chooses 16384.
			# If too large, use CONFIG_SND_HDA_PREALLOC_SIZE=2048
			buffer_size 16384
		}
	}
	capture.pcm "hw:0"
}

ctl.dmix51 {
	type hw
	card 0
}

pcm.upmix {
	type plug
	slave.pcm "dmix51"
	   
	#front
   	ttable.0.0 1
    	ttable.1.1 1

	#side / rear -left
	ttable.0.2 1.0

	#side / rear - right
    	ttable.1.3 1.0

	#center    
    	ttable.0.4 0.5
    	ttable.1.4 0.5

	# bass
    	ttable.0.5 0.2
    	ttable.1.5 0.2
    
}
pcm.!default {
	type softvol
	slave.pcm "upmix"
	control {
	  name "SW master"
	  card 0
	}
}

 
Diese Datei mit ihren verketteten Upmixing-Definitionen (Stereo zu 5.1) und dem initial definierten Softvol-Regler funktioniert für praktisch alles – nur nicht für Firefox!

Den Softvol-Regler hatte ich, wie gesagt, am Anfang der Plugin-Kette angelegt, um den Input für die verschiedenen Kanäle der D2X an einer zentralen Stelle steuern zu können – bei gleichzeitiger
Aufrechterhaltung der relativen Lautstärke-Verhältnisse zwischen den Kanälen. Unter KMIX sieht das dann so aus:

kmix

Den “SW-Master”-Regler kann man dann zum Hauptkanal für die Kmix-Einstellungen machen und damit die Lautstärke über einen (!) Regler auch im Systemabschnitt der KDE-Kontrolleiste anpassen, ohne die relativen Kanal-Lautstärken zu verändern.

Lösungsansatz für das Firefox-Problem

Nach etwas Rumprobieren kam ich schließlich auf den Gedanken, dass Firefox beim Default-Device – also am Anfang der Plugin-Kette für die Sound-Verarbeitung – möglicherweise ein PCM-Device vom Typ “plug” erwartet und mit dem “softvol”-Plugin nicht umgehen kann. Ich habe daher folgende Änderung vorgenommen: 

defaults.pcm.card 0
defaults.pcm.device 0
defaults.ctl.card 0

pcm.dmix51 {
	type asym
	playback.pcm {
		type dmix

		# Don't block other users
		ipc_key_add_uid true

		ipc_key 5678293
		ipc_perm 0660
		ipc_gid audio

		slave {
			# 2 for stereo, 6 for surround51, 8 for surround71
			channels 6
			pcm {
				#format S32_LE
				format S16_LE

				# 44100 or 48000
				# 44100 for music, 48000 is compatible with most h/w
				rate 44100
				#rate 48000

				type hw
				card 0
				device 0
				subdevice 0
			}

			#period_size 512
			period_size 1024
			#period_size 512

			buffer_size 16384
		}
	}
	capture.pcm "hw:0"
}

ctl.dmix51 {
	type hw
	card 0
}

pcm.upmix {
	type plug
	slave.pcm "dmix51"
	   
	#front
    	ttable.0.0 1
    	ttable.1.1 1

	#side / rear -left
	ttable.0.2 1.0

	#side / rear - right
    	ttable.1.3 1.0

	#center    
    	ttable.0.4 0.5
    	ttable.1.4 0.5

	# bass
    	ttable.0.5 0.2
    	ttable.1.5 0.2
    
}

pcm.vol {
	type softvol
	slave.pcm "upmix"
	control {
	  name "SW master"
	  card 0
	 }
}

pcm.!default {
	# !!! 
	type plug 
	slave.pcm "vol"
}

 
(Die ersten Statements dienten nur der Sicherheit, dass in jedem Fall die erste Soundkarte genutzt wird. Mit der D2X funktioniert übrigens auch die Format-Festlegung “format S32_LE”).

Und siehe da:
Die vorgenommene kleine Änderung unter dem “pcm.!default”-Eintrag und das Verlagern des Volume-Reglers in ein eigenes Plugin “vol” brachte den Erfolg! Nach einem Ausloggen aus KDE und erneutem Einloggen produzierten Youtube-Videos unter FF plötzlich Töne – ohne dass ich irgendetwas an der vorherigen Funktionalität für die D2X verloren hätte.

Im Grunde ist durch das künstliche PCM-Device vom Typ “plug” mit dem Verweis auf das slave.pcm “vol” der SW-Volume-Regler nur als ein weiteres separates Glied der PCM-Plugin-Kette definiert worden.

Warum FF im Gegensatz zu anderen Browsern und Soundquellen so sensibel auf unterschiedliche Alsa-Plugin-Typen reagiert, ist mir unklar. Aber im Moment bin ich froh, das Problem wenigstens einer Lösung zugeführt zu haben, ohne Pulseaudio anwerfen zu müssen.

Viel Spass weiterhin mit der Xonar D2X – ohne Pulseaudio !