Opensuse Leap 42.2, Android, KDE, Dolphin – Dateitransfer mit MTP – Probleme und mögliche Ursachen

Vor einiger Zeit habe ich auf einigen Geräten ein Upgrade auf Leap 42.2 vorgenommen. Das lief alles ganz OK. Nun wollte ich von einem der betroffenen Laptops Dateien auf ein Smartphone übertragen. Dabei stolperte ich bei Einsatz von “MTP” und dem zugehörigen kio-Slave “kio_mtp” unter KDE in ähnliche Probleme, wie sie unter den folgenden Links beschrieben sind:

http://linux-club.de/forum/viewtopic.php?t=121313
https://forums.opensuse.org/showthread.php/526021-Erneute-Probleme-beim-Zugriff-auf-Android-Smartphone-via-MTP
https://forums.oneplus.net/threads/zugriff-auf-daten-ueber-computer.598702/

Ich weiß nicht, ob meine Problem die gleichen Ursachen hatten, wie bei meinen Leidensgenossen – aber die nachfolgenden Punkte sind jedenfalls der Beachtung wert.

Typischer fehlerhafter Verlauf beim Einsatz von “mtp” unter KDE

Fehler 1: Zugriff auf das erkannte Smartphone führt zu keiner Verzeichnisanzeige unter Dolphin

Man schließt das Smartphone an; es kommt zuerst eine Freigabeaufforderung auf dem Smartphone. Danach öffnet man Dolphin – und dann kommt da erneut eine Warnhinweis, dass man das Smartphone freigeben/entsperren müsse; tatsächlich erscheint am Phone eine neue Aufforderung. Die bestätigt man und schließt danach das Popup in Dolphin. Anschließend lädt und lädt Dolphin den Ordnerinhalt angeblich – es passiert aber weiter nichts und zur Anzeige der Speichermedien des Smartphones und deren Inhalte kommt es nie.

Fehler 2: Dolphin kann aus dem Gerätemanager heraus nicht gestartet werden

Ein weiterer ärgerlicher Punkt war in meinem Fall der, dass unter der Geräteüberwachung zwar Dolphin-Icons als Optionen für “Aktionen” angezeigt wurden; ein Klick darauf führte aber jedesmal zu einer Fehlermeldung, die man wegklicken muss. Dolphin öffnet sich dann aber nicht.

Ein solches Verhalten macht einen wahnsinnig; im besonderen, wenn man unter Zeitdruck steht und man weiß, dass früher alles schon mal funktioniert hat. In meinem Fall halfen mir “kde-connect” und die zugehörige App auf dem Smartphone aus der unmittelbaren Patsche heraus, weil beide Geräte (Laptop, Smartphone) sich zufällig im selben WLAN befanden. In unserer Firma gibt es aber Geräte, die aus Sicherheitsgründen in anderen WLAN-Netzen als die Smartphones hängen. Da hilft KDE-Connect nichts. Nun kann man auf SSH-/FTPS-Verbindungen ausweichen. MTP wäre aber doch so einfach … warum sollte das unter Leap nicht gehen?

Ein paar Experimente

Ich habe dann in meinem Ärger ein wenig rumexperimentiert. Als erster Schritt zur Analyse hilft in einem solchen Fall oft, das Ganze mal mit einem frisch angelegten User oder als User “root” auszuprobieren; Letzteres, um evtl. Rechteprobleme festzustellen.

In meinem Fall reichte schon der erste Schritt: Mit frisch angelegten UserIDs gab es kein größeres Problem mit MTP und einer USB-Kabelverbindung zu unseren verschiedenen Smartphones (LG 2, Samsung Note, Samsung 6). Da lief alles wie erwartet: Anschließen des USB-Kabels an die Linux Workstation, Dolphin öffnen, Android Phone wählen, auf dem Phone die angeforderte MTP-Verbindung freigeben, kurz warten, in Dolphin mit F5 die Ansicht aktualisieren und schließlich durch die Datenträger des Smartphones browsen und Dateien zwischen den Geräten hin und her kopieren.

Workaround

Das brachte mich zu einem ersten Workaround, den ich hier aufliste, weil er vielleicht beim einen oder anderen auch helfen mag. Auf die tatsächlichen
Ursachen der Fehler in meiner Konfiguration gehe ich weiter unten ein.

Man lösche – soweit vorhanden – die Dateien “~/.config/dolphinrc”, “~/.kde4/share/config/dolphinrc” und das Verzeichnis “~/.local/share/dolphin”. Danach funktionierte folgender Workaround relativ zuverlässig:

  • Schritt 1: Anschluss des Smartphone per USB-Kabel an das OS Leap 42.2-Gerät.
  • Schritt 2: I.d.R. kommt keine Freigabeaufforderung auf dem Handy – falls doch: bestätigen.
  • Schritt 3: Geräteüberwachung im Systemtray (Systembereich der Kontrollleiste) öffnen.
  • Schritt 4: Optionen für Android-Gerät anzeigen lassen und auf erstes Dolphin-Symbol klicken.
  • Schritt 5: Fehlermeldung wegklicken und ggf. auftauchende Freigabeaufforderung auf dem Handy positiv beantworten.
  • Schritt 6: Erneut Geräteüberwachung öffnen.
  • Schritt 7: Diesmal auf das 2-te Dolphin-Symbol klicken.
  • Schritt 8: Erneut Fehlermeldung wegdrücken und ggf. Freigabeaufforderung auf dem Handy bestätigen.
  • Schritt 9: Dolphin unabhängig auf dem Desktop öffnen => dort das unter “Geräte” angezeigte > Android-Phone anklicken.
  • Schritt 10: Es werden die auf dem Smartphone verfügbaren Speicherbereiche (Standard “Phone” und (SD-) “Card” angezeigt.

Bei mir tauchte entweder bei Schritt 5 oder bei Schritt 6 eine Freigabeaufforderung auf. Nicht aber zweimal. Die oben beschriebene Schrittfolge ist die einzige, die bei mir zuverlässige Ergebnisse vor den weiter unten geschilderten Maßnahmen produzierte. Der Workaround beseitigte jedoch nicht das Problem des Fehlers beim Klick auf die Dolphin-Symbole in der Geräteüberwachung.

Dieser Zustand ist aus meiner Sicht absurd. Offenbar funktioniert die MTP-Verbindung im Prinzip – aber irgendetwas in der initialen Dialogführung zwischen kio_mtp, Dolphin und dem Android-Phone stimmte einfach nicht.

Lösung 1: Amarok’s MTP-Modul muss abgeschaltet werden!

Ich stelle auf einigen meienr Geräten entweder Amarok und Clementine beim KDE-Start zur Verfügung. Sowohl auf dem Laptop als auch auf der Workstation waren nach dem Start von KDE Amarok aktiv. (Auf er Arbeitstation übrigens, weil ich mich gerade mal wieder mit Pulseaudiio herunmschlage. Dazu mehr in einem kommenden Beitrag.)

Es hat mich eine Weile gekostet herauszufinden, dass Amarok standardmäßig das Modul “MTP-Sammlung” aktiviert. Nun stammt Amarok aus KDE4-Zeiten. Das Modul ist offenbar nicht mehr mit der aktuellen KDE5-Umgebung kompatibel oder interferiert in unzulässigerweise mit über “udev” festgelegten Reaktionen auf MTP-Ereignisse.

Also unbedingt im Dialog “Amarok >> Einstellungen >> Amarok Einrichten >> Module” das Modul “MTP-Sammlung” deaktivieren !

Dass dieses Modul wirklich Ungutes tut, kann man dadurch ausprobieren, dass man bei aktiver MTP-Verbindung das Modul mal wieder aktiviert! Viel Glück …

Lösung 2: KDE-Einstellung unter Standardanwendungen überprüfen

Mein zweiter Fehler hatte damit zu tun, dass ich irgendwann mal “PCManFM” als Dateimanager installiert hatte. Der hatte sich dann selbst in den KDE-Einstellungen als primärer Manager für die Dateiverwaltung hinterlegt. Das funktioniert aber nicht mit der KDE-Geräteüberwachung. Also unter
“systemsettings5 >> Anwendungen >> Standardanwendungen >> Dateiverwaltung” Dolphin als Standard-Dateimanager festlegen.

Schließe ich nun eines unseres Android Smartphones an die Linux-Geräte an, auf denen das erlaubt ist, so funktioniert MTP wieder schnell und flüssig – egal ob an einem USB2.0 oder 3.0-
Anschluss.

Fazit

Plugins oder Module von Applikationen, die MTP-Ereignisse erkennen und auf die dahinter liegenden Geräte zugreifen wollen, kommen als potentielle Ursachen von Problemen mit MTP-Verbindungen unter KDE und Dolphin in Frage. Unter Opensuse Leap 42.2 gilt das auf jeden Fall für das MTP-Modul von Amarok. Es ist aber gut vorstellbar, dass auch andere Anwendungen ähnliche Probleme, wie oben diskutiert, zeitigen können. In Frage kommen vor allem Multimedia-Anwendungen. Der KDE-User sollte hierauf eine Auge haben und nach der Installation solcher Anwendungen Tests zu MTP-Verbindungen durchführen.

Viel Spaß weiterhin mit Dateitransfers zu Smartphones – macht das aber bitte nur auf Geräten, auf denen die impliziten Sicherheitsrisiken einer Smartphone-Anbindung kontrollierbar sind, und nur für User mit minimalen Rechten …

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

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 !