Testing interoperability between 2.3.35 and 2.4.7.
Consumer is 2.4.7, provider is 2.3.35.
I get messages in the 2.4.7 log that look like this:
Jan 15 13:07:47 mippet slapd[13134]: null_callback : error code 0x10 Jan 15 13:07:47 mippet slapd[13134]: syncrepl_updateCookie: rid=002 be_modify failed (16) Jan 15 13:07:47 mippet slapd[13134]: do_syncrepl: rid=002 retrying (4 retries left) Jan 15 13:07:52 mippet slapd[13134]: null_callback : error code 0x10 Jan 15 13:07:52 mippet slapd[13134]: syncrepl_updateCookie: rid=002 be_modify failed (16)
Seems to be related to adding/changing/deleting on the provider, although the changes do propagate. Is this fixed by 2.3.40, or is it a separate issue in 2.4.7?
On Tue, 15 Jan 2008, Dave Horsfall wrote:
Seems to be related to adding/changing/deleting on the provider, although the changes do propagate. Is this fixed by 2.3.40, or is it a separate issue in 2.4.7?
Found a spare server, and loaded up 2.3.40. Nope; still get the error on the 2.4.7 side (which subsequently works on the next attempt).
Can check from your 'source' server to see if there are ACL errors where it says that the user that is doing the replication is having a hard time seeing the attributes. You can turn on ACL logging with the -d flag by reading the man page for slapd.conf and add that value to your -d flag.
Sellers
On Jan 14, 2008, at 9:48 PM, Dave Horsfall wrote:
On Tue, 15 Jan 2008, Dave Horsfall wrote:
Seems to be related to adding/changing/deleting on the provider, although the changes do propagate. Is this fixed by 2.3.40, or is it a separate issue in 2.4.7?
Found a spare server, and loaded up 2.3.40. Nope; still get the error on the 2.4.7 side (which subsequently works on the next attempt).
-- Dave Horsfall DTM VK2KFU Ph: +61 2 9552-5509 (direct) +61 2 9552-5500 (switch) Corinthian Eng'ng P/L, Ste 54 Jones Bay Whf, 26-32 Pirrama Rd, Pyrmont 2009, AU
______________________________________________Chris G. Sellers | NITLE Technology 734.661.2318 | chris.sellers@nitle.org AIM: imthewherd | GTalk: cgseller@gmail.com
On Tue, 15 Jan 2008, Chris G. Sellers wrote:
(Please don't top-post.)
Can check from your 'source' server to see if there are ACL errors where it says that the user that is doing the replication is having a hard time seeing the attributes.
Then why would it work after a retry or two?
You can turn on ACL logging with the -d flag by reading the man page for slapd.conf and add that value to your -d flag.
Yes, I know; I've been fairly active on this list for several years...
And no, nothing unusual.
Seeing as no-one seems to have seen this before I guess I'd better file an ITS.
On Thu, 17 Jan 2008, Dave Horsfall wrote:
Seeing as no-one seems to have seen this before I guess I'd better file an ITS.
But before I do so, error code 0x10 is "LDAP_NO_SUCH_ATTRIBUTE"; I guess I'd better check my configuration very carefully...
Dave Horsfall wrote:
On Thu, 17 Jan 2008, Dave Horsfall wrote:
Seeing as no-one seems to have seen this before I guess I'd better file an ITS.
But before I do so, error code 0x10 is "LDAP_NO_SUCH_ATTRIBUTE"; I guess I'd better check my configuration very carefully...
Did you find anything obvious?
On Tue, 22 Jan 2008, Gavin Henry wrote:
But before I do so, error code 0x10 is "LDAP_NO_SUCH_ATTRIBUTE"; I guess I'd better check my configuration very carefully...
Did you find anything obvious?
No; I'll set up something simple at home because it's not really a works issue i.e. I can't justify the time...
It's not an ACL issue as someone suggested; I can reproduce it with "access to * by * write".
openldap-software@openldap.org
-
Chris G. Sellers -
Dave Horsfall -
Gavin Henry