hi all,
sometimes my server a not in sync. because server ignoring entry:
do_syncrep2: rid=102 CSN too old, ignoring 20130923090023.266239Z#000000#002#000000
@(#) $OpenLDAP: slapd 2.4.33 (....)
4 server host1 and host 2: only one database c=fr ( contain an ou=apps-ext ) host3 and host 4: tow database: first ou=apps-ext (glued with c=fr ). writable by host1,2,3,4 second c=fr writable only by host1,2
ldap-int1 and ldap-int2 cn=config also into syncrepl mirrorMode ldap-ext1 and ldap-ext2 cn=config also into syncrepl mirrorMode
Configuration: grep serverID /etc/openldap/slapd.d/* /etc/openldap/slapd.d/cn=config.ldif:olcServerID: 1 ldaps://ldap-int1.dom.fr /etc/openldap/slapd.d/cn=config.ldif:olcServerID: 2 ldaps://ldap-int2.dom.fr /etc/openldap/slapd.d/cn=config.ldif:olcServerID: 3 ldaps:// ldap-ext1.vlandata.dom.fr /etc/openldap/slapd.d/cn=config.ldif:olcServerID: 4 ldaps:// ldap-ext2.vlandata.dom.fr
syncrepl: ldap-int1 and ldap-int2 cn=config also into syncrepl
olcSyncrepl: {0}rid=101 provider=ldaps://ldap-int1.dom.frbinddn="uid=syncrepl ,ou=system,ou=dom,o=domgroup,c=fr" bindmethod=simple credentials=XXXXXX sea rchbase="c=fr" tls_reqcert=never type=refreshAndPersist interval=00:00:00:10 retry="5 5 300 +" timeout=1 olcSyncrepl: {1}rid=102 provider=ldaps://ldap-int2.cdoms.frbinddn="uid=syncrepl ,ou=system,ou=dom,o=domgroup,c=fr" bindmethod=simple credentials=XXXXXX sea rchbase="c=fr" tls_reqcert=never type=refreshAndPersist interval=00:00:00:10 retry="5 5 300 +" timeout=1 olcSyncrepl: {2}rid=103 provider=ldaps://ldap-ext2.vlandata.dom.frbinddn="uid =syncrepl,ou=system,ou=dom,o=domgroup,c=fr" bindmethod=simple credentials=XX XXXX tls_reqcert=never searchbase="o=apps-ext,c=fr" type=refreshAndPersist r etry="5 5 300 +" timeout=1 olcSyncrepl: {3}rid=104 provider=ldaps://ldap-ext1.vlandata.dom.frbinddn="uid =syncrepl,ou=system,ou=dom,o=domgroup,c=fr" bindmethod=simple credentials=XXX XXXX searchbase="o=apps-ext,c=fr" tls_reqcert=never type=refreshAndPersist r etry="5 5 300 +" timeout=1
syncrepl host3 and host4:
database apps-ext: olcSyncrepl: {0}rid=303 provider=ldaps://ldap-ext1.vlandata.dom.frbinddn="uid =syncrepl,ou=system,ou=dom,o=domgroup,c=fr" bindmethod=simple credentials=XXX XXXX searchbase="o=apps-ext,c=fr" tls_reqcert=never type=refreshAndPersist r etry="5 5 300 +" timeout=1 olcSyncrepl: {1}rid=304 provider=ldaps://ldap-ext2.vlandata.dom.frbinddn="uid =syncrepl,ou=system,ou=dom,o=domgroup,c=fr" bindmethod=simple credentials=XXX XXX searchbase="o=apps-ext,c=fr" tls_reqcert=never type=refreshAndPersist r etry="5 5 300 +" timeout=1
database c=fr: olcSyncrepl: {0}rid=201 provider=ldaps://ldap-int1.dom.frbinddn="uid=syncrepl ,ou=system,ou=dom,o=domgroup,c=fr" bindmethod=simple credentials=XXXXXX sea rchbase="c=fr" tls_reqcert=never type=refreshOnly interval=00:00:00:10 retry= "5 5 300 +" timeout=1 olcSyncrepl: {1}rid=202 provider=ldaps://ldap-int2.dom.frbinddn="uid=syncrepl ,ou=system,ou=dom,o=domgroup,c=fr" bindmethod=simple credentials=XXXXX tls _reqcert=never searchbase="c=fr" type=refreshOnly interval=00:00:00:10 retry= "5 5 300 +" timeout=1
log message into ldap-int1: ep 23 09:00:26 ldap-int1 slapd[30481]: do_syncrep2: rid=104 LDAP_RES_INTERMEDIATE - NEW_COOKIE Sep 23 09:00:26 ldap-int1 slapd[30481]: do_syncrep2: rid=104 NEW_COOKIE: rid=104,sid=003,csn=20130304121522.188962Z#000000#000#000000;20130920094938.821063Z#000000#001#000000;20130923081114.470856Z#000000#002#000000;20130920094950.036431Z#000000#003#000000;20130912174047.679980Z#000000#004#000000;20130304131428.455916Z#000000#00b#000000;20130304125618.164164Z#000000#00c#000000 Sep 23 09:00:26 ldap-int1 slapd[30481]: do_syncrep2: rid=104 LDAP_RES_INTERMEDIATE - NEW_COOKIE Sep 23 09:00:26 ldap-int1 slapd[30481]: do_syncrep2: rid=104 NEW_COOKIE: rid=104,sid=003,csn=20130304121522.188962Z#000000#000#000000;20130920094938.821063Z#000000#001#000000;20130923090023.733719Z#000000#002#000000;20130920094950.036431Z#000000#003#000000;20130912174047.679980Z#000000#004#000000;20130304131428.455916Z#000000#00b#000000;20130304125618.164164Z#000000#00c#000000 Sep 23 09:00:26 ldap-int1 slapd[30481]: slap_queue_csn: queing 0x7f3787471a90 20130923090023.733719Z#000000#002#000000 Sep 23 09:00:26 ldap-int1 slapd[30481]: slap_graduate_commit_csn: removing 0x7f37873baa10 20130923090023.733719Z#000000#002#000000 Sep 23 09:00:27 ldap-int1 slapd[30481]: syncprov_matchops: skipping original sid 002 Sep 23 09:00:27 ldap-int1 slapd[30481]: slap_graduate_commit_csn: removing 0x7f37803e9320 20130923090023.225026Z#000000#002#000000 Sep 23 09:00:27 ldap-int1 slapd[30481]: syncrepl_entry: rid=102 be_add cn=502257-dt-global-gridded-adt-ref,ou=affectations,ou=console,o=apps,c=fr (0) Sep 23 09:00:27 ldap-int1 slapd[30481]: do_syncrep2: rid=102 cookie=rid=102,sid=002,csn=20130923090023.266239Z#000000#002#000000 Sep 23 09:00:27 ldap-int1 slapd[30481]: do_syncrep2: rid=102 CSN too old, ignoring 20130923090023.266239Z#000000#002#000000 (cn=502257-dt-med-gridded-sla-ref,ou=affectations,ou=console,o=apps,c=fr) Sep 23 09:00:27 ldap-int1 slapd[30481]: do_syncrep2: rid=102 cookie=rid=102,sid=002,csn=20130923090023.278474Z#000000#002#000000 Sep 23 09:00:27 ldap-int1 slapd[30481]: do_syncrep2: rid=102 CSN too old, ignoring 20130923090023.278474Z#000000#002#000000 (cn=502257-dt-blacksea-alongtrack-sla-ref,ou=affectations,ou=console,o=apps,c=fr)
time sync host1 ntpq> lpeers remote refid st t when poll reach delay offset jitter ============================================================================== *date.dom.fr 145.238.203.10 3 u 676 1024 377 1.592 0.284 0.018 +date2.dom.fr 145.238.203.10 3 u 295 1024 377 2.681 -0.410 0.326
host2 ntpq> lpeers remote refid st t when poll reach delay offset jitter ============================================================================== *date.dom.fr 145.238.203.10 3 u 954 1024 377 1.028 1.012 0.343 +date2.dom.fr 145.238.203.10 3 u 413 1024 377 2.171 0.098 0.606
does somebody see what is wrong . thanks
On 09/24/2013 12:01 PM, Lanfeust troy wrote:
hi all,
sometimes my server a not in sync. because server ignoring entry:
do_syncrep2: rid=102 CSN too old, ignoring 20130923090023.266239Z#000000#002#000000
@(#) $OpenLDAP: slapd 2.4.33 (....)
If you search the list for any older version you will see a consistent recommendation to upgrade to the latest version (currently 2.4.36) and see if the problem persists.
If you use RHEL/CentOS you can find packages here: http://ltb-project.org/wiki/download#openldap
Regards, Patrick
I understand that but before post my message i read openldap release note but i can't see something related to my problem.
2013/9/24 Patrick Lists openldap-list@puzzled.xs4all.nl
On 09/24/2013 12:01 PM, Lanfeust troy wrote:
hi all,
sometimes my server a not in sync. because server ignoring entry:
do_syncrep2: rid=102 CSN too old, ignoring 20130923090023.266239Z#000000#**002#000000
@(#) $OpenLDAP: slapd 2.4.33 (....)
If you search the list for any older version you will see a consistent recommendation to upgrade to the latest version (currently 2.4.36) and see if the problem persists.
If you use RHEL/CentOS you can find packages here: http://ltb-project.org/wiki/**download#openldaphttp://ltb-project.org/wiki/download#openldap
Regards, Patrick
On Tue, 24 Sep 2013, Lanfeust troy wrote:
I understand that but before post my message i read openldap release note but i can't see something related to my problem.
[which is]
do_syncrep2: rid=102 CSN too old, ignoring 20130923090023.266239Z#000000#002#000000 @(#) $OpenLDAP: slapd 2.4.33 (....)
So you're running MMR and seeing issues about "old" CSNs and don't see the potential relevance of a change log that references:
Fixed slapd syncrepl updateCookie status (ITS#7531) Fixed slapd syncrepl for old entries in MMR setup (ITS#7427)
...maybe they're your issue, maybe they're not, but in the amount of time you need to simply read this you could find a 2.4.36 package.
Hi all,
I have upgraded to 2.4.36 openLDAP version. The problem still exists. It seem to be appear less than before. This week this problem occur only once.
To resolve this problem i'm doing:
stop slapd on ldap that haven't entry and launch it with
/usr/local/openldap/libexec/slapd -c rid=201,dsn=20131003140020.844217Z#000000#002#000000 -h "ldap://:389 ldaps://:636" -F /usr/local/openldap/etc/openldap/slapd.d -u ldap -g ldap -l local4
rid number is my source syncrepl dsn is 20 seconds before the problem ( retrieve from entryCSN in question )
is't the good way to do
2013/9/24 Aaron Richton richton@nbcs.rutgers.edu
On Tue, 24 Sep 2013, Lanfeust troy wrote:
I understand that but before post my message i read openldap release note
but i can't see something related to my problem.
[which is]
do_syncrep2: rid=102 CSN too old, ignoring20130923090023.266239Z#000000#**002#000000 @(#) $OpenLDAP: slapd 2.4.33 (....)So you're running MMR and seeing issues about "old" CSNs and don't see the potential relevance of a change log that references:
Fixed slapd syncrepl updateCookie status (ITS#7531) Fixed slapd syncrepl for old entries in MMR setup (ITS#7427)...maybe they're your issue, maybe they're not, but in the amount of time you need to simply read this you could find a 2.4.36 package.
On Fri, 4 Oct 2013 11:05:57 +0200 Lanfeust troy lanfeust99@gmail.com wrote
I have upgraded to 2.4.36 openLDAP version. The problem still exists. It seem to be appear less than before. This week this problem occur only once.
I did not follow your issue in detail. Are you using slapo-memberof in your deployment?
Ciao, Michael.
No; it's not the problem
2013/10/4 Michael Ströder michael@stroeder.com
On Fri, 4 Oct 2013 11:05:57 +0200 Lanfeust troy lanfeust99@gmail.com wrote
I have upgraded to 2.4.36 openLDAP version. The problem still exists. It seem to be appear less than before. This week this problem occur only once.
I did not follow your issue in detail. Are you using slapo-memberof in your deployment?
Ciao, Michael.
another logs with 2.4.36
ldap-int1 receive syncrepl modification from ldap-int2 with this log:
ldap-int1 log: syncprov_matchops: skipping original sid 002 Oct 4 15:00:24 ldap-int1 slapd[24555]: slap_graduate_commit_csn: removing 0x7f7bf8200b40 20131004150021.988007Z#000000#002#000000 Oct 4 15:00:24 ldap-int1 slapd[24555]: syncrepl_entry: rid=102 be_add cn=502296-xxxxxx,ou=aaaaa,ou=bbbb,o=cccc,c=dd (0) ... ...
ldap-ext2 receive the same modification an reply to ldap-int1 with new cookie
ldap-int1 log Oct 4 15:00:24 ldap-int1 slapd[24555]: do_syncrep2: rid=103 NEW_COOKIE: rid=103,sid=004,csn=20130304121522.188962Z#000000#000#000000;20131004082718.688747Z#000000#001#000000;20131004150023.350876Z#000000#002#000000;20130920094950.036431Z#000000#003#000000;20130930134451.718477Z#000000#004#000000;20130304131428.455916Z#000000#00b#000000;20130304125618.164164Z#000000#00c#00000
Another modification from ldap-int2 isn't apply to ldap-int1 because of csn too old
Oct 4 15:00:24 ldap-int1 slapd[24555]: syncrepl_entry: rid=102 be_add cn=502296-bbbb,ou=aaaaa,ou=bbbb,o=cccc,c=dd (0) Oct 4 15:00:24 ldap-int1 slapd[24555]: do_syncrep2: rid=102 cookie=rid=102,sid=002,csn=20131004150022.050845Z#000000#002#000000 Oct 4 15:00:24 ldap-int1 slapd[24555]: do_syncrep2: rid=102 CSN too old, ignoring 20131004150022.050845Z#000000#002#000000 (cn=502296-bbbb,ou=aaaaa,ou=bbbb,o=cccc,c=dd) Oct 4 15:00:24 ldap-int1 slapd[24555]: do_syncrep2: rid=102 cookie=rid=102,sid=002,csn=20131004150022.100121Z#000000#002#000000
2013/10/4 Lanfeust troy lanfeust99@gmail.com
No; it's not the problem
2013/10/4 Michael Ströder michael@stroeder.com
On Fri, 4 Oct 2013 11:05:57 +0200 Lanfeust troy lanfeust99@gmail.com wrote
I have upgraded to 2.4.36 openLDAP version. The problem still exists. It seem to be appear less than before. This week this problem occur only once.
I did not follow your issue in detail. Are you using slapo-memberof in your deployment?
Ciao, Michael.
Hi!
Are you sure you are chasing a real problem? AFAIK, in multi-master sync, the server that receives a change will send that change to all other nodes, which, in turn, will also send the changes received to all other nodes. That means that the original submitter of the changes will receive ist own change.
I also think that "too old" means "not newer" here. I wonder if the message shouldn't be dropped instead of complaining that the requested change is already there.
The gurus may correct me if I'm wrong.
Regards, Ulrich
Lanfeust troy lanfeust99@gmail.com schrieb am 08.10.2013 um 10:13 in
Nachricht CAJ=nZHMkk9hd7UdcrDW6zirjheBXqcjkhHBFEbvP3nTJu+v9Fg@mail.gmail.com:
another logs with 2.4.36
ldap-int1 receive syncrepl modification from ldap-int2 with this log:
ldap-int1 log: syncprov_matchops: skipping original sid 002 Oct 4 15:00:24 ldap-int1 slapd[24555]: slap_graduate_commit_csn: removing 0x7f7bf8200b40 20131004150021.988007Z#000000#002#000000 Oct 4 15:00:24 ldap-int1 slapd[24555]: syncrepl_entry: rid=102 be_add cn=502296-xxxxxx,ou=aaaaa,ou=bbbb,o=cccc,c=dd (0) ... ...
ldap-ext2 receive the same modification an reply to ldap-int1 with new cookie
ldap-int1 log Oct 4 15:00:24 ldap-int1 slapd[24555]: do_syncrep2: rid=103 NEW_COOKIE:
rid=103,sid=004,csn=20130304121522.188962Z#000000#000#000000;20131004082718.
688747Z#000000#001#000000;20131004150023.350876Z#000000#002#000000;2013092009
4950.036431Z#000000#003#000000;20130930134451.718477Z#000000#004#000000;20130
304131428.455916Z#000000#00b#000000;20130304125618.164164Z#000000#00c#00000
Another modification from ldap-int2 isn't apply to ldap-int1 because of csn too old
Oct 4 15:00:24 ldap-int1 slapd[24555]: syncrepl_entry: rid=102 be_add cn=502296-bbbb,ou=aaaaa,ou=bbbb,o=cccc,c=dd (0) Oct 4 15:00:24 ldap-int1 slapd[24555]: do_syncrep2: rid=102 cookie=rid=102,sid=002,csn=20131004150022.050845Z#000000#002#000000 Oct 4 15:00:24 ldap-int1 slapd[24555]: do_syncrep2: rid=102 CSN too old, ignoring 20131004150022.050845Z#000000#002#000000 (cn=502296-bbbb,ou=aaaaa,ou=bbbb,o=cccc,c=dd) Oct 4 15:00:24 ldap-int1 slapd[24555]: do_syncrep2: rid=102 cookie=rid=102,sid=002,csn=20131004150022.100121Z#000000#002#000000
2013/10/4 Lanfeust troy lanfeust99@gmail.com
No; it's not the problem
2013/10/4 Michael Ströder michael@stroeder.com
On Fri, 4 Oct 2013 11:05:57 +0200 Lanfeust troy lanfeust99@gmail.com wrote
I have upgraded to 2.4.36 openLDAP version. The problem still exists. It seem to be appear less than before. This week this problem occur
only
once.
I did not follow your issue in detail. Are you using slapo-memberof in your deployment?
Ciao, Michael.
On Tue, 08 Oct 2013 12:15:56 +0200 "Ulrich Windl" Ulrich.Windl@rz.uni-regensburg.de wrote
Are you sure you are chasing a real problem? AFAIK, in multi-master sync, the server that receives a change will send that change to all other nodes, which, in turn, will also send the changes received to all other nodes.
It would be pretty inefficient if a provider in a MMR setup receives its own modifications.
Given the fact that I'm also seeing missing entries in a MMR setup I suspect there are indeed problems with the contextCSN.
Another one ITS#7710 which likely is limited to use of slapo-memberof but I'm not really sure about that. (The data consistency issues happened without slapo-memberof.)
Ciao, Michael.
"Michael Ströder" michael@stroeder.com schrieb am 08.10.2013 um 12:40 in
Nachricht dbc9e8c25a1bb1bac7905cb6950c87ad@srv1.stroeder.com:
On Tue, 08 Oct 2013 12:15:56 +0200 "Ulrich Windl" Ulrich.Windl@rz.uni-regensburg.de wrote
Are you sure you are chasing a real problem? AFAIK, in multi-master sync,
the
server that receives a change will send that change to all other nodes, which, in turn, will also send the changes received to all other nodes.
It would be pretty inefficient if a provider in a MMR setup receives its
own
modifications.
I agree, but from the logs my version seems to do exactly that, so maybe my config is not correct, or the software has a bug. As it still does what it should do, I don't care about the bug for the moment...
Given the fact that I'm also seeing missing entries in a MMR setup I
suspect
there are indeed problems with the contextCSN.
Another one ITS#7710 which likely is limited to use of slapo-memberof but I'm not really sure about that. (The data consistency issues happened without slapo-memberof.)
Ciao, Michael.
Do I open an issue about that with more log. Everyday we have consistency problem.
This bug ( for me ) appear on "ou" with more than 120K entrie. Every entry is check by another application every hour.
when are schedule the next release please ? Thanks
2013/10/8 Ulrich Windl Ulrich.Windl@rz.uni-regensburg.de
"Michael Ströder" michael@stroeder.com schrieb am 08.10.2013 um
12:40 in Nachricht dbc9e8c25a1bb1bac7905cb6950c87ad@srv1.stroeder.com:
On Tue, 08 Oct 2013 12:15:56 +0200 "Ulrich Windl" Ulrich.Windl@rz.uni-regensburg.de wrote
Are you sure you are chasing a real problem? AFAIK, in multi-master
sync,
the
server that receives a change will send that change to all other nodes, which, in turn, will also send the changes received to all other nodes.
It would be pretty inefficient if a provider in a MMR setup receives its
own
modifications.
I agree, but from the logs my version seems to do exactly that, so maybe my config is not correct, or the software has a bug. As it still does what it should do, I don't care about the bug for the moment...
Given the fact that I'm also seeing missing entries in a MMR setup I
suspect
there are indeed problems with the contextCSN.
Another one ITS#7710 which likely is limited to use of slapo-memberof but I'm not really sure about that. (The data consistency issues happened without slapo-memberof.)
Ciao, Michael.
Lanfeust troy wrote:
Do I open an issue about that with more log. Everyday we have consistency problem.
This bug ( for me ) appear on "ou" with more than 120K entrie. Every entry is check by another application every hour.
when are schedule the next release please ?
You could try to compile OPENLDAP_REL_ENG_2_4 branch snapshot from git.
http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=tree;h=refs/heads/...
Direct snapshot link:
http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=snapshot;h=refs/he...
Ciao, Michael.
Lanfeust troy wrote:
Do I open an issue about that with more log. Everyday we have consistency problem.
This bug ( for me ) appear on "ou" with more than 120K entrie. Every entry is check by another application every hour.
when are schedule the next release please ? Thanks
2013/10/8 Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de mailto:Ulrich.Windl@rz.uni-regensburg.de>
>>> "Michael Ströder" <michael@stroeder.com <mailto:michael@stroeder.com>> schrieb am 08.10.2013 um 12:40 in Nachricht <dbc9e8c25a1bb1bac7905cb6950c87ad@srv1.stroeder.com <mailto:dbc9e8c25a1bb1bac7905cb6950c87ad@srv1.stroeder.com>>: > On Tue, 08 Oct 2013 12:15:56 +0200 "Ulrich Windl" > <Ulrich.Windl@rz.uni-regensburg.de <mailto:Ulrich.Windl@rz.uni-regensburg.de>> wrote >> Are you sure you are chasing a real problem? AFAIK, in multi-master sync, > the >> server that receives a change will send that change to all other nodes, >> which, in turn, will also send the changes received to all other nodes. > > It would be pretty inefficient if a provider in a MMR setup receives its own > modifications. I agree, but from the logs my version seems to do exactly that, so maybe my config is not correct, or the software has a bug. As it still does what it should do, I don't care about the bug for the moment...
If a server is receiving its own modifications that means your serverIDs are not configured correctly. If your serverIDs are not configured correctly MMR cannot work correctly. Fix your configuration.
> > Given the fact that I'm also seeing missing entries in a MMR setup I suspect > there are indeed problems with the contextCSN. > > Another one ITS#7710 which likely is limited to use of slapo-memberof but > I'm > not really sure about that. (The data consistency issues happened without > slapo-memberof.) > > Ciao, Michael.
Howard Chu hyc@symas.com schrieb am 10.10.2013 um 12:23 in Nachricht
Lanfeust troy wrote:
Do I open an issue about that with more log. Everyday we have consistency
problem.
This bug ( for me ) appear on "ou" with more than 120K entrie. Every entry
is
check by another application every hour.
when are schedule the next release please ? Thanks
2013/10/8 Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de mailto:Ulrich.Windl@rz.uni-regensburg.de>
>>> "Michael Ströder" <michael@stroeder.com <mailto:michael@stroeder.com>> schrieb am 08.10.2013 um 12:40 in Nachricht <dbc9e8c25a1bb1bac7905cb6950c87ad@srv1.stroeder.com <mailto:dbc9e8c25a1bb1bac7905cb6950c87ad@srv1.stroeder.com>>: > On Tue, 08 Oct 2013 12:15:56 +0200 "Ulrich Windl" > <Ulrich.Windl@rz.uni-regensburg.de <mailto:Ulrich.Windl@rz.uni-regensburg.de>> wrote >> Are you sure you are chasing a real problem? AFAIK, in multi-master
sync,
> the >> server that receives a change will send that change to all othernodes,
>> which, in turn, will also send the changes received to all othernodes.
> > It would be pretty inefficient if a provider in a MMR setup receives
its
own > modifications. I agree, but from the logs my version seems to do exactly that, so
maybe
my
config is not correct, or the software has a bug. As it still does what
it
should do, I don't care about the bug for the moment...If a server is receiving its own modifications that means your serverIDs are
not configured correctly. If your serverIDs are not configured correctly MMR
cannot work correctly. Fix your configuration.
It could be due to an older version (openldap2-2.4.26-0.16.1 of SLES11 SP2) being used...
> > Given the fact that I'm also seeing missing entries in a MMR setup
I
suspect > there are indeed problems with the contextCSN. > > Another one ITS#7710 which likely is limited to use of
slapo-memberof
but
> I'm > not really sure about that. (The data consistency issues happenedwithout
> slapo-memberof.) > > Ciao, Michael.-- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
openldap-technical@openldap.org
-
Aaron Richton -
Howard Chu -
Lanfeust troy -
Michael Ströder -
Patrick Lists -
Ulrich Windl