[Date Prev][Date Next] [Chronological] [Thread] [Top]

(ITS#4192) cn=config rootdn issues



Full_Name: Quanah Gibson-Mount
Version: 2.3.12
OS: Solaris 8
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (171.66.155.86)


I'm trying to set up a replicated config environment, so that I can just update
the master to push changes to all my replicas.  However, I've found an early
obstacle to making this as easy as I'd like.  I have this configuration:

database        config
rootdn          "cn=replicator,cn=service,cn=applications,dc=stanford,dc=edu"


but that results in the following error:

<= ldap_dn2bv(cn=config)=0 Success
<<< dnPrettyNormal: <cn=config>, <cn=config>
>>> dnNormalize: <cn=replicator,cn=service,cn=applications,dc=stanford,dc=edu>
=> ldap_bv2dn(cn=replicator,cn=service,cn=applications,dc=stanford,dc=edu,0)
ldap_err2string
<= ldap_bv2dn(cn=replicator,cn=service,cn=applications,dc=stanford,dc=edu)=0
Success
<= str2entry NULL (smr_normalize 21)
=> ldif_enum_tree: failed to read entry for
/usr/local/etc/openldap/slapd.d/cn=config.ldif
send_ldap_result: conn=-1 op=0 p=0
send_ldap_result: err=51 matched="" text=""
slapd destroy: freeing system resources.

I'm guessing because the rootdn is outside of the context of the config backend.
 However, I also can't set the rootdn to be the SASL bind ID
(uid=service/ldap,cn=stanford.edu,cn=auth or whatever) because my connection
gets immediately mapped to the replicator ID.

I'd really prefer a way to replicate to cn=config using GSSAPI.  I imagine this
may take some additional parameters? Some way to create an identity in cn=config
for the rootDN?  Or to allow entries from naming contexts to have permissions
into cn=config (like I'd really like my ldapadmin group to be able to read the
cn=config DB on all the slaves, too).

--Quanah