[Date Prev][Date Next]
subentries (Was: Need new replica configuration without shutting down slapd)
I encourage you to read my I-D
available at www.ietf.org.
X.500 subentries in general approach we need to use to
hold and maintain administrative information in the
In implementing subentries, I suggest with starting with
the basic use of mechanism. The most basic use I know
is to support collective attributes.
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.
At 12:42 AM 2001-12-06, Ganesan R wrote:
>>>>>> "Howard" == Howard Chu <email@example.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
>> 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