do_syncrepl: ... rc 68 retrying
by Peter Mogensen
I have a mirror which has stopped replicating. (slapd 2.4.21)
Somehow it has ended up in a situation where it looks like it is trying
to replicate a modrdn operation, but the new RDN already exists on the
consumer. Strangely, it doesn't exists on the producer.
Like this:
On Server1 (producer) I have:
contextCSN: 20100202142811.287095Z#000000#001#000000
cn=A,dc=example,dc=com
entryCSN: 20100127080339.261941Z#000000#001#000000
On Server2 (consumer) I have:
contextCSN: 20100127075402.694373Z#000000#001#000000
cn=A,dc=example,dc=com
entryCSN: 20100113084604.888851Z#000000#001#000000
cn=B,dc=example,dc=com
entryCSN: 20100127075357.910468Z#000000#001#000000
I notice that the contextCSN of server2 is only a few seconds after the
entryCSN for cn=B,dc=example,dc=com
The log says:
syncrepl_entry: rid=003 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD)
syncrepl_entry: rid=003 be_search (0)
syncrepl_entry: rid=003 cn=A,dc=example,dc=com
syncrepl_entry: rid=003 be_modrdn cn=B,dc=example,dc=com (68)
do_syncrepl: rid=003 rc 68 retrying
Any suggestion for how this could happen?
regards,
Peter
13 years, 10 months
Mingw regex compile issue
by Rasmus Schram
Hello
I am trying to compile the openldap v. 2.4.19 client api with MingW and Msys.
It will successfully make the configure command, but when I try to make, it complains about not having a shared version of the regex library.
I have tried to use both 'mingw-libgnurx-2.5.1' and 'regex-0.12' but with no luck.
I am only interested in building the client api libraries, but the error results in only building a static version of the library and I really need the shared dll's instead.
This is the Warning/issue I get trying to compile.
---------------------------------------------------------------------
/bin/sh ../../libtool --mode=link gcc -g -O2 -no-undefined -avoid-version -rpath /usr/local/lib -o liblber.la assert.lo decode.lo encode.lo io.lo bprint.lo debug.lo memory.lo options.lo sockbuf.lo nt_err.lo version.lo -lregex -lws2_32
*** Warning: linker path does not have real file for library -lregex.
*** I have the capability to make that library automatically link in when
*** you link to this library. But I can only do this if you have a
*** shared version of the library, which you do not appear to have
*** because I did check the linker path looking for a file starting
*** with libregex and none of the candidates passed a file format test
*** using a file magic. Last file checked: /bin/libregex.a
*** Warning: linker path does not have real file for library -lws2_32.
*** I have the capability to make that library automatically link in when
*** you link to this library. But I can only do this if you have a
*** shared version of the library, which you do not appear to have
*** because I did check the linker path looking for a file starting
*** with libws2_32 and none of the candidates passed a file format test
*** using a file magic. Last file checked: /mingw/lib/gcc/mingw32/3.4.5/../../..//libws2_32.a
*** The inter-library dependencies that have been dropped here will be
*** automatically added whenever a program is linked with this library
*** or is declared to -dlopen it.
*** Since this library must not contain undefined symbols,
*** because either the platform does not support them or
*** it was explicitly requested with -no-undefined,
*** libtool will only create a static version of it.
---------------------------------------------------------------------
I have tried various options but cannot find the cause of the problem. Any help would be appreciated.
Regards
Rasmus
_________________________________________________________________
NY Windows Live Messenger med nye fede funktioner. Hent den her!
http://download.live.com/messenger
13 years, 10 months
refint overlay don't works as expected
by Sergei Butakov
Hi
I'm using refint and memberof overlays.
Refint overlay don't works as expected - it don't modifying one entry:
uid=admin,ou=Users,dc=domain.local (which is a member of
cn=webers,ou=Groups,dc=domain.local - see dump.ldif attachment).
Changing the memberof-dangling option in the memberof overlay don't help.
If I turn off the memberof overlay or move this entry to the end of dump.ldif
file (after cn=webers,ou=Groups,dc=domain.local) then the refint overlay
works as needed.
Can somebody retest it or say where I'm wrong?
Steps to reproduce:
1) stop slapd
2) copy the files (slapd.conf, bsl.schema, dump.ldif) from the attachment to
the apropriate places. Correct the pathes (include, directory) in slapd.conf
file.
3) rm -rf /path/to/openldap-data/*
4) slapadd -l dump.ldif
5) chown -R ldapd:ldapd openldap-data
(use your own ldap user)
6) start slapd
7) test #1:
$ ldapsearch -LLL -D cn=manager -w 1 -b "" '(cn=webers)' member
dn: cn=webers,ou=Groups,dc=domain.local
member: uid=admin,ou=Users,dc=domain.local
member: uid=u1,ou=Users,dc=domain.local
$ ldapsearch -LLL -D cn=manager -w 1 -b "" '(uid=*)' memberOf
dn: uid=admin,ou=Users,dc=domain.local
memberOf: cn=webers,ou=Groups,dc=domain.local
dn: uid=u1,ou=Users,dc=domain.local
memberOf: cn=webers,ou=Groups,dc=domain.local
All OK.
8) now rename dc=domain.local:
$ ldapmodrdn -r -D cn=manager -w 1 dc=domain.local dc=example.org -v
ldap_initialize( <DEFAULT> )
Renaming "dc=domain.local"
new rdn="dc=example.org" (delete old rdn)
Rename Result: Success (0)
9) check #2:
$ ldapsearch -LLL -D cn=manager -w 1 -b "" '(cn=webers)' member
dn: cn=webers,ou=Groups,dc=example.org
member: uid=admin,ou=Users,dc=example.org
member: uid=u1,ou=Users,dc=example.org
$ ldapsearch -LLL -D cn=manager -w 1 -b "" '(uid=*)' memberOf modifiersName
dn: uid=admin,ou=Users,dc=example.org
memberOf: cn=webers,ou=Groups,dc=domain.local
memberOf: cn=webers,ou=Groups,dc=example.org
modifiersName: cn=Manager
dn: uid=u1,ou=Users,dc=example.org
memberOf: cn=webers,ou=Groups,dc=example.org
modifiersName: cn=Referential Integrity Overlay
Error: refint overlay didn't change the uid=admin entry.
--
Regards,
Sergei Butakov
13 years, 10 months
ACLs based on attributes?
by Jaap Winius
Hi all,
Is it possible to define an ACL that gives a DN access to a particular
attribute in other DNs based on the value of one of its own attributes?
For example, would it be possible to define an ACL that would allow a
DN with title=telephonemanager to update only the telephoneNumber
attribute of other DNs? In other words, the ACL would allow updates to
telephoneNumber, but only for search filter title=telephonemanager; a
simple a change of the title would result in the gain or loss of the
right to make such updates.
Thanks,
Jaap
13 years, 10 months
