subentries (Was: Need new replica configuration without shutting down slapd)

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

Ganesan,

I encourage you to read my I-D
        draft-zeilenga-ldap-subentry-01.txt
available at www.ietf.org.

X.500 subentries in general approach we need to use to
hold and maintain administrative information in the
directory.

In implementing subentries, I suggest with starting with
the basic use of mechanism.  The most basic use I know
is to support collective attributes.
        draft-zeilenga-ldap-collective-03.txt

Other uses (subschema, ACI, replication agreements) are
far more complex and interject too many extraneous issues
into the proper implementation of subentries.  But I do
understand that practicalities may call for implementing
replication agreement subentries first.

Also, you might note that I recently added UUID/CSN
operational attributes which you might find useful.

Kurt

At 12:42 AM 2001-12-06, Ganesan R wrote:
>>>>>> "Howard" == Howard Chu <hyc@highlandsun.com> writes:
>
>>> What alternative is there to get at all the attributes (including
>>> operational attributes like creationTimeStamp) of a database? I need a way
>>> to essentially create a replication log for the entire database. May be
>>> slurpd can do a "normal" ldap search on the localhost with a special
>>> control?
>
>> Well as you already noted, you can use ldapsearch. I forgot that back-ldbm
>> also has a "dbnolocking" config keyword which can be used to turn off
>> locking for the database. I suppose you could run with this if you needed
>> to, although you open the door to a host of unknown troubles using this.
>
>Actually, for now I would prefer to use ldapsearch till IBM's NSAPI code
>gets integrated. To avoid races in replication I may have to depend on
>searching for entries modified before/after a certain timestamp. 
>
>> back-bdb in the HEAD stream is getting closer to maturity. It supports finer
>> grained locking than back-ldbm, so it's feasible for other tools to operate
>> on the database while slapd runs. However, the code for this backend is in a
>> fairly continual state of flux, so I can't recommend it for anything more
>> than experimentation at this point. (But if you'd like to bang on it and see
>> where it falls apart, go ahead......)
>
>I have been watching your posts on performance comparisons with back-ldbm
>with interest. I think you mentioned that the last numbers you posted were
>bogus; any updates on them yet? Our requirement for OpenLDAP in production
>is atleast six months away so, I am keen on using back-bdb with
>transactions.
>
>Ganesan