Benutzer-Werkzeuge

Webseiten-Werkzeuge


Writing /srv/www/htdocs/udo/singollo.de/linux.singollo.de/public_html/data/cache/6/6a2c5e4be88a835b2bf0da88e61e8e97.metadata failed
ldap:openldap24_pla

phpLDAPadmin 1.2+ und OpenLDAP 2.4.x

Erster Versuch

Ich wollte auf meinem Server singollo.de die virtuellen Mailadressen (siehe Verteiler mit LDAP) in mein Verzeichnisdienst auslagern, um sie bequem per Webinterface zu bearbeiten. Für die Tests allerdings hatte ich ein aktuelles phpLDAPadmin (im folgenden PLA genannt) installiert und bekam prompt die Fehlermeldung „Our attempts to find your SCHEMA for 'objectclasses' have FAILED.“. Leider hat das Wiki zu PLA nur eine Lösung für die OpenLDAP 2.3.x-Server. Somit war ich erstmal ratlos.

~ # ldapsearch -xh 127.0.0.1 -b 'cn=Subschema' -s base '(objectClass=subschema)' attributetypes
# extended LDIF
#
# LDAPv3
# base <cn=Subschema> with scope baseObject
# filter: (objectClass=subschema)
# requesting: attributetypes
#

# search result
search: 2
result: 0 Success

Fehlersuche

Nach langem Suchen mit den unterschiedlichsten Begriffen fand ich die Lösung: OpenLDAP 2.4 verwendet mit cn=config ein „run-time configuration (RTC)“-System. Dort sind zusätzlich zur slapd.conf ein paar ACLs hinterlegt. Leider lassen genau diese ACLs keinen Zugriff auf das gewünschte cn=Subschema zu. Ein vorgeschlagenes LDIF mit den Korrekturen sollte zwar helfen, ist aber bei mir mit einer Fehlermeldung abgewiesen worden, das Element sei schon vorhanden. Also suchte ich in der Konfiguration von cn=config die passende Antwort. In der Datei „olcDatabase={-1}frontend.ldif“ finden sich passende Zeilen, also modifizierte ich diese Datei.

Fix

Diese zwei Regeln reichen nicht aus:

olcAccess: {0}to dn.base="" by * read
olcAccess: {1}to dn.base="o=singollo,c=de" by * read by dn.base="o=singollo,c= de" manage

Erst mit der Modifikation funktioniert PLA:

olcAccess: {0}to dn.base="" by * read
olcAccess: {1}to dn.base="cn=Subschema" by * read
olcAccess: {2}to dn.base="o=singollo,c=de" by * read by dn.base="o=singollo,c= de" manage

Der neue Versuch zeigt es.

~ # ldapsearch -xh 127.0.0.1 -b 'cn=Subschema' -s base '(objectClass=subschema)' attributetypes
# extended LDIF
#
# LDAPv3
# base <cn=Subschema> with scope baseObject
# filter: (objectClass=subschema)
# requesting: attributetypes
#

# Subschema
dn: cn=Subschema
attributeTypes: ( 2.5.4.0 NAME 'objectClass' DESC 'RFC4512: object classes of
 the entity' EQUALITY objectIdentifierMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.
 38 )
[...]
attributeTypes: ( 1.3.6.1.4.1.10018.1.1.14 NAME 'mailhost' DESC 'Host to which
  incoming POP/IMAP connections should be proxied' EQUALITY caseIgnoreIA5Match
  SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256} )

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1
ldap/openldap24_pla.txt · Zuletzt geändert: 07.10.2012 18:31 (Externe Bearbeitung)