Re: (ITS#7719) configure delayed response time
by quanah@zimbra.com
--On Tuesday, October 08, 2013 3:59 AM +0000 rashtrapathy(a)gmail.com wrote:
> Full_Name: Rashtrapathy
> Version: 2.4.36
> OS: GNU/Linux
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (72.163.217.105)
>
>
> Dear All,
>
> I want my openldap server to send a delayed searchResEntry &
> searchResDone for any searchRequest.
>
> Where i need to change the configuration file for this delayed response?
The ITS system is for reporting bugs, not asking usage questions. I would
however suggest you look at contrib modules like the noop module to see
about how to insert a delay into the slapd stack.
This ITS will be closed.
--Quanah
--
Quanah Gibson-Mount
Architect - Server
Zimbra Software, LLC
--------------------
Zimbra :: the leader in open source messaging and collaboration
9 years, 11 months
(ITS#7719) configure delayed response time
by rashtrapathy@gmail.com
Full_Name: Rashtrapathy
Version: 2.4.36
OS: GNU/Linux
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (72.163.217.105)
Dear All,
I want my openldap server to send a delayed searchResEntry & searchResDone for
any searchRequest.
Where i need to change the configuration file for this delayed response?
Please help me ASAP.
Thanks,
Rash.
9 years, 11 months
Re: (ITS#7717) Sudden memory increase leading to Master LDAP crash
by quanah@zimbra.com
--On Thursday, October 03, 2013 1:14 PM +0000 marcon.bruno(a)free.fr wrote:
> The problem is very easy to replay : one master and one slave are
> sufficient. Then run 9 windows with a script adding an entry and
> modifying an entry.
Please provide full configuration details.
--Quanah
--
Quanah Gibson-Mount
Architect - Server
Zimbra Software, LLC
--------------------
Zimbra :: the leader in open source messaging and collaboration
9 years, 11 months
Re: (ITS#7710) contextCSN values not updated by internal non-replicated ops
by ck@cksoft.de
Hi Michael,
On Sun, 6 Oct 2013, michael(a)stroeder.com wrote:
> I've updated the test data with LDIF files and a README describing the LDAP
> operations to perform:
>
> http://www.stroeder.com/temp/openldap-testbed-its7710.tar.bz2
>
> I consider this to be a serious issue which could be the cause for other
> replication issues including dead-locks we're experiencing. (Maybe there are
> similar issues in slapo-refint since dead-locks in our deployment arised when
> moving entries into different subtree.)
I can confirm that I can see the same bug with your testcase.
It seems that restarting the second slapd instance fixes the contextCSN
issue just because it scans all it's entries and does the right thing.
Even a slapcat of both directories shows the issue.
Things that I find disturbing:
After applying the group membership the member dn: gets it's memberOf
attribute updated accordingly. But the entryCSN stays unchanged.
Entry before applying group membership:
# michael, users, example.com
dn: uid=michael,ou=users,dc=example,dc=com
uid: michael
objectClass: account
objectClass: simpleSecurityObject
userPassword:: dGVzdHNlY3JldA==
description: test
entryCSN: 20131006193757.912740Z#000000#002#000000
Entry after applying group membership is obviously updated but still has
the same entryCSN:
# michael, users, example.com
dn: uid=michael,ou=users,dc=example,dc=com
uid: michael
objectClass: account
objectClass: simpleSecurityObject
userPassword:: dGVzdHNlY3JldA==
memberOf: cn=admins,ou=groups,dc=example,dc=com
memberOf: cn=testgroup1,ou=groups,dc=example,dc=com
description: test
entryCSN: 20131006193757.912740Z#000000#002#000000
I can also confirm the subsequent contextCSN mismatch.
I too consider this a serious issue.
If I read Howards reply correctly and from what I see in the source code
of the memberOf overlay the strategy here seems to be not to replicate the
side effect of adding the memberOf: entry.
OpenLDAP relies on the side effect happening on the replicas through the
same codepath when the member: attribute in the group gets updated
through replication.
This sounds very similar to the difference between:
1. statement replication in sql databases ala mysql
2. log based replication ala postgresql
OpenLDAP is doing 1. here while 2. would perhaps have been the better option.
I understand turning this around is propably too late at this point in time.
Looks like we will just have to work out the bugs the hard way.
I am using slapo-lastbind and slapo-ppolicy extensively in my current
project and will keep my eyes open for similar issues resulting from not
replicating the side effects that these overlays produce.
Greetings
Christian
--
Christian Kratzer CK Software GmbH
Email: ck(a)cksoft.de Wildberger Weg 24/2
Phone: +49 7032 893 997 - 0 D-71126 Gaeufelden
Fax: +49 7032 893 997 - 9 HRB 245288, Amtsgericht Stuttgart
Web: http://www.cksoft.de/ Geschaeftsfuehrer: Christian Kratzer
9 years, 11 months
Re: (ITS#7710) contextCSN values not updated by internal non-replicated ops
by michael@stroeder.com
Christian Kratzer wrote:
> This sounds very similar to the difference between:
>
> 1. statement replication in sql databases ala mysql
>
> 2. log based replication ala postgresql
>
> OpenLDAP is doing 1. here while 2. would perhaps have been the better option.
>From my understanding 2. is OpenLDAP's delta-syncrepl.
Ciao, Michael.
9 years, 11 months
Re: (ITS#7716) slapd crashes after search immediately followed by (abandon+) unbind
by quanah@zimbra.com
--On Wednesday, October 02, 2013 12:32 PM +0000
michael.vishchers(a)7p-group.com wrote:
> Full_Name: Michael Vishchers
> Version: 2.4.23
This release is years old, and has numerous known issues. It sounds like
you are using RedHat's package. If you absolutely have to use that
package, then you need to report this issue with RedHat. Otherwise, I
suggest upgrading to the latest release. If you don't feel comfortable
building OpenLDAP yourself, you can easily use the packages from the LTB
project:
<http://ltb-project.org/wiki/download#openldap>
This ITS will be closed.
Regards,
Quanah
--
Quanah Gibson-Mount
Architect - Server
Zimbra Software, LLC
--------------------
Zimbra :: the leader in open source messaging and collaboration
9 years, 11 months
Re: (ITS#7710) contextCSN values not updated by internal non-replicated ops
by michael@stroeder.com
I've updated the test data with LDIF files and a README describing the LDAP
operations to perform:
http://www.stroeder.com/temp/openldap-testbed-its7710.tar.bz2
I consider this to be a serious issue which could be the cause for other
replication issues including dead-locks we're experiencing. (Maybe there are
similar issues in slapo-refint since dead-locks in our deployment arised when
moving entries into different subtree.)
Ciao, Michael.
The README copied here for direct access:
----------------------------------------------------------------------------
0. Start both servers by invoking start-slapd1.sh and start-slapd2.sh
----------------------------------------------------------------------------
1. Add test entries on first server:
$ ldapadd -H ldap://localhost:2071 -D "uid=diradm,dc=example,dc=com" -w
testsecret -f 1_ldapadd.ldif
adding new entry "dc=example,dc=com"
[..]
adding new entry "cn=replicas,ou=groups,dc=example,dc=com"
You can now see contextCSN value of first server on both servers (as expected):
$ for I in 1 2 ; do (echo ldap://localhost:207$I ; ldapsearch -LLL -H
ldap://localhost:207$I -D "uid=diradm,dc=example,dc=com" -w testsecret -b
"dc=example,dc=com" -s base "(objectClass=*)" contextCSN ) ; done
ldap://localhost:2071
dn: dc=example,dc=com
contextCSN: 20131006154300.921415Z#000000#001#000000
ldap://localhost:2072
dn: dc=example,dc=com
contextCSN: 20131006154300.921415Z#000000#001#000000
----------------------------------------------------------------------------
2. Send a simple modification to second server:
$ ldapmodify -H ldap://localhost:2072 -D "uid=diradm,dc=example,dc=com" -w
testsecret -f 2_ldapmodify.ldif
modifying entry "uid=michael,ou=users,dc=example,dc=com"
You can now see contextCSN value of second server on both servers (as expected):
$ for I in 1 2 ; do (echo ldap://localhost:207$I ; ldapsearch -LLL -H
ldap://localhost:207$I -D "uid=diradm,dc=example,dc=com" -w testsecret -b
"dc=example,dc=com" -s base "(objectClass=*)" contextCSN ) ; done
ldap://localhost:2071
dn: dc=example,dc=com
contextCSN: 20131006154300.921415Z#000000#001#000000
contextCSN: 20131006154406.940154Z#000000#002#000000
ldap://localhost:2072
dn: dc=example,dc=com
contextCSN: 20131006154300.921415Z#000000#001#000000
contextCSN: 20131006154406.940154Z#000000#002#000000
----------------------------------------------------------------------------
3. Modification of group membership on first server:
$ ldapmodify -H ldap://localhost:2071 -D "uid=diradm,dc=example,dc=com" -w
testsecret -f 3_ldapmodify.ldif
modifying entry "cn=testgroup1,ou=groups,dc=example,dc=com"
Now the contextCSN values differ:
$ for I in 1 2 ; do (echo ldap://localhost:207$I ; ldapsearch -LLL -H
ldap://localhost:207$I -D "uid=diradm,dc=example,dc=com" -w testsecret -b
"dc=example,dc=com" -s base "(objectClass=*)" contextCSN ) ; done
ldap://localhost:2071
dn: dc=example,dc=com
contextCSN: 20131006154449.514135Z#000000#001#000000
contextCSN: 20131006154406.940154Z#000000#002#000000
ldap://localhost:2072
dn: dc=example,dc=com
contextCSN: 20131006154300.921415Z#000000#001#000000
contextCSN: 20131006154406.940154Z#000000#002#000000
9 years, 11 months