Re: (ITS#4192) cn=config rootdn issues

[hyc@symas.com]

quanah@stanford.edu wrote:
> 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).
>   

No, this has nothing to do with naming contexts. The DN you specified 
caused a syntax error in the normalizer. This happens because it was 
parsing the root entry cn=config, which occurs before user-specified 
schema are loaded. The odd thing is that there should not be any rootdn 
attribute in the cn=config entry. The configuration for the config 
database resides under "olcDatabase={0}config,cn=config" and that's 
where the rootdn belongs. Did you create this config.ldif manually?

-- 
  -- Howard Chu
  Chief Architect, Symas Corp.  http://www.symas.com
  Director, Highland Sun        http://highlandsun.com/hyc
  OpenLDAP Core Team            http://www.openldap.org/project/