[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