SlapD will nach Update von 42.1 nicht mehr

Moinsen,

ich habe auf meinem Homeserver heute Morgen den Schritt von 42.1 auf 42.2 gemacht. Seitdem mag der Slapd (dummerweise habe ich alle User im ldap, hier geht gerade nix mehr) nicht mehr starten und ich komme mit der Fehlermeldung nicht ganz klar. Händisch den slapd mit -d 64 gestartet sehe ich:

-----------------------schnipp-----------------------
587e1983 <= str2entry: str2ad(olcDbCacheSize): attribute type undefined
587e1983 UNKNOWN attributeDescription “OLCDBCACHESIZE” inserted.
587e1983 <= str2entry: str2ad(olcDbCheckpoint): attribute type undefined
587e1983 UNKNOWN attributeDescription “OLCDBCHECKPOINT” inserted.
587e1983 <= str2entry: str2ad(olcDbIDLcacheSize): attribute type undefined
587e1983 UNKNOWN attributeDescription “OLCDBIDLCACHESIZE” inserted.
587e1983 <= str2entry: str2ad(olcDbIndex): attribute type undefined
587e1983 UNKNOWN attributeDescription “OLCDBINDEX” inserted.
587e1983 >>> dnNormalize: <cn=config>
…]
587e1983 => access_allowed: search access to “olcDatabase={1}hdb,cn=config” “objectClass” requested
587e1983 <= root access granted
587e1983 => access_allowed: search access granted by manage(=mwrscxd)
587e1983 <= test_filter 6
587e1983 : config_add_internal: DN=“olcDatabase={1}hdb,cn=config” no structural objectClass in configuration table
587e1983 config error processing olcDatabase={1}hdb,cn=config:
587e1983 send_ldap_result: conn=-1 op=0 p=0
587e1983 send_ldap_result: err=65 matched="" text=""
587e1983 slapd destroy: freeing system resources.
587e1983 slapd stopped.
587e1983 connections_destroy: nothing to destroy.
-----------------------schnipp-----------------------

Die Config hat sich nicht geändert, ich sehe auf den ersten und zweiten Blick auch keinen Fehler in der Config - habe ich übersehen ob sich etwas grundlegendes von 42.1 zu 42.2 beim ldap verändert ?

Danke im voraus - Michael

Kleines Update: ich habe die drei Pakete (openldap2-, -client und das passende lib-paket) auf den Stand der 42.1 gebracht und schon funktioniert der LDAP Server wieder. Hmmm …:\

exakt dasselbe Problem hier… gibt es noch eine andere Lösung?

…und der Workaround funktioniert auch bei mir…

Same issue here : another solution than going backward with 42.1 rpm packets ? On my side and after activating all possible logs, it seems related to the content of a ‘olcDatabase={1}hdb.ldif’ file, and it complains about a missing ‘StructuralClass’ or something like that. This file ‘olcDatabase={1}hdb.ldif’ is working perfectly since all opensuse releases since 11.2, except 42.2.

Ideas or hints welcome.

Hallo Michael,

nachdem ich über das gleiche Problem gestolpert bin und diesen (noch lösungsfreien) thread fand, hier meine Erkenntnis: Im aktuellen Openldap2-Paket scheint es notwendig, das BDB-Modul explizit zu laden:

myserver:/etc/openldap/slapd.d # grep -r ModuleLoad .
./cn=config/cn=module{0}.ldif:olcModuleLoad: {0}memberof.la
./cn=config/cn=module{0}.ldif:olcModuleLoad: {1}back_bdb.la

Ich hatte das entsprechend in der zur Erstbetankung genutzten LDIF-Datei nachgetragen - schon gab es das Problem nicht mehr.

Viele Grüße
J

Ich hatte das gleiche Problem.

Die Lösung, die bei mir funktioniert hat, war der Eintrag der folgenden zwei Zeilen in /etc/openldap/slapd.conf

modulepath /usr/lib64/openldap/
moduleload back_bdb.la

Grüße,

Björn