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

Re: (ITS#4613)



On Wed, Jul 19, 2006 at 08:02:02PM -0700, Howard Chu wrote:
> twopir@nmt.edu wrote:
> >>How were those non-working entries created? A current OpenLDAP release 
> >>will always create entryUUID and entryCSN attributes for all entries. 
> >>Can you obtain logs for the  operations used to create these entries?
> >>    
> >
> >We create all our entries with either ldapadd/ldapmodify or Perl's
> >Net::LDAP. We do not have logs of the non-working entries available, but
> >I could do some experimenting with manually synchronizing my testbed
> >servers.
> 
> Well, it's pretty much impossible for normal LDAP requests to cause 
> entries to be created without these operational attributes, in a normal 
> configuration. What else is configured on these databases? Perhaps we 
> should look at the complete provider's slapd.conf.

The database configuration is fairly simple - a boatload of indices and
ACLs. I put a copy of both ldap0 and ldap1's config files up at
http://infohost.nmt.edu/~twopir/ldap_syncrepl_issue/slapd_conf_ldap0
(and slapd_conf_ldap1)

> Was the database converted from an earlier release of OpenLDAP?

Yes, but it was converted by the debian postinstall scripts taking a
slapcat of the old database, moving the data files out of the way, and
slapadd'ing, then starting the server. On the test systems (which
exhibit the same behavior) I manually loaded a slapcat from the old
database.

> 
> -- 
>  -- 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/

-- 
Too many errors on one line (make fewer)
-- Apple MPW C compiler