This is a pointless exercise.
--On Thursday, December 14, 2006 2:27 PM +0800 "石斌(Seuler.shi)"
<[EMAIL PROTECTED]> wrote:
Dear Quanah:
Because the replication features provided by OpenLDAP do not
meet our software requirement.
If there are N slaves and 1 master in a re
--On Thursday, December 14, 2006 3:58 PM +0800 "石斌(Seuler.shi)"
<[EMAIL PROTECTED]> wrote:
I have solved the problem just now. The BDB replication can work well
with OpenLDAP.
I doubt that it really does. In any case, if you want to discuss this,
keep it to openldap-devel and not my add
石斌(Seuler.shi) wrote:
I just solve the problem and the BDB replication can work well with the
OpenLDAP.
The back-bdb caching mechanism is not removed. I will test the
performance while
deploying back-bdb configuration in OpenLDAP.
Have fun testing. You're getting well ahead of yourself; fir
Howard Chu wrote:
One feature that's still needed in some cases (e.g., using syncrepl to
push updates to another slave thru back-ldap) is an updatedn identity
with the privilege to write to unmodifiable operational attributes.
I guess this isn't something the Relax control is intended to allow
Problem using BDB replication in OpenLDAP
Software version:
Berkeley DB: 4.5.20
OpenLDAP:2.3.30
We want to configure the replication management in OpenLDAP's backend
database. All write requests in OpenLDAP master site will spread to
OpenLDAP client site for we have configured the backend data
At 03:42 AM 12/14/2006, Pierangelo Masarati wrote:
>Howard Chu wrote:
>>One feature that's still needed in some cases (e.g., using syncrepl to push
>>updates to another slave thru back-ldap) is an updatedn identity with the
>>privilege to write to unmodifiable operational attributes.
>>I guess th
Kurt D. Zeilenga wrote:
At 03:42 AM 12/14/2006, Pierangelo Masarati wrote:
Howard Chu wrote:
One feature that's still needed in some cases (e.g., using
syncrepl to push updates to another slave thru back-ldap) is an
updatedn identity with the privilege to write to unmodifiable
operational attri
At 08:36 AM 12/14/2006, Howard Chu wrote:
>The new mechanism wouldn't behave a whole lot differently... If we were to
>make this a control I would only define it for Bind operations, thus
>identifying an entire session to be a server-to-server interaction.
I would hesitate a bit on making this a
> Why we can not search any info during the client is normally
running? But
> once I rebooted the client site, it worked well and could accept search
> requests? How to solve this problem:)
There are quite a few potential problems with your approach.
The first one that comes to mind is th
[EMAIL PROTECTED] wrote:
implement full IPv6 support in ACLs; use URL notation (as suggested by Howard)
to disambiguate parsing (ITS#4756)
OK, I see this breaks sasl_server_new() where it expects IPv6
iplocalport and ipremoteport in the form ip;port regardless of IPv4/6.
I'll back part of
2006/12/14, Howard Chu <[EMAIL PROTECTED]>:
This is a pointless exercise.
> --On Thursday, December 14, 2006 2:27 PM +0800 "石斌(Seuler.shi)"
> <[EMAIL PROTECTED]> wrote:
>> Dear Quanah:
>>
>> Because the replication features provided by OpenLDAP do
not
>> meet our software requireme
If I turn off cache of openldap, and configure the back-bdb as main memory
state,
the problem you mentioned will not occur any more.
2006/12/14, David Boreham <[EMAIL PROTECTED]>:
>
> > Why we can not search any info during the client is normally
> running? But
> > once I rebooted the client
12 matches
Mail list logo
