Zitat von Pierangelo Masarati ando@sys-net.it:

Markus Krause wrote:

...

Hi list!

i have several consumer and one provider (lets call them ldapconX and ldapprov). syncrepl works fine, but i actually do not want any clients to contact the provider directly (and i have in addition some clients which would not understand referrals anyway), so reading through the admin guide and man pages i thought slapo-chain would be the solution! (correct me if i am wrong ;-)) But somehow a can not get it working...

the slapd.conf of the provider is untouched, the consumer have (simplified in some places; please tell me if you need it in more details):

slapo-chain must be global (i.e. before any database) since referrals are returned by the frontend, as soon as it discovers that the database that is candidate for a modification is shadow. See example in consumer slapd.conf in test018.

thanks for your answer! i assume you are referring to slapd-chain1.conf, as in slapd-chain2.conf the overlay chain is after the database definition (which i used after the success following your hint in my acl problem thread). but i am still doing something wrong... just to be sure i ran all tests again (make test) which all were finished ok.

now my slapd.conf is like: --- slapd.conf (simplified) ... acl overlay chain chain-rebind-as-user FALSE chain-uri "ldaps://ldapprov" chain-rebind-as-user TRUE chain-idassert-bind bindmethod="simple" binddn="cn=manager,o=test" credentials="secret" mode="self" flags=non-prescriptive database bdb ... overlay smbk5pwd syncrepl .... updateref ldaps://ldapprov ---- end of slapd.conf

using "ldappasswd -x <...>" i get: Re-enter new password: Enter LDAP Password: ldappasswd: ldap_result: Can't contact LDAP server (-1)

and the ldap consumer segfaults. last messages from slapd -d 65535 was: --- slapd -d 65535 .... conn=0 op=1 PASSMOD id="uid=testuser,ou=people,o=test" new

...

...

dnPrettyNormal: <uid=testuser,ou=people,o=test>

=> ldap_bv2dn(uid=testuser,ou=people,o=test,0) <= ldap_bv2dn(uid=testuser,ou=people,o=test)=0 => ldap_dn2bv(272) <= ldap_dn2bv(uid=testuser,ou=people,o=test)=0 => ldap_dn2bv(272) <= ldap_dn2bv(uid=testuser,ou=people,o=test)=0 <<< dnPrettyNormal: <uid=testuser,ou=people,o=test>, <uid=testuser,ou=people,o=test> bdb_dn2entry("uid=testuser,ou=people,o=test") => bdb_dn2id("uid=testuser,ou=people,o=test") <= bdb_dn2id: got id=0x0000284c => bdb_dn2id("uid=testuser,ou=people,o=test") <= bdb_dn2id: got id=0x00002861 => bdb_dn2id("uid=testuser,ou=people,o=test") <= bdb_dn2id: got id=0x0000337f entry_decode: "uid=testuser,ou=people,o=test" <= entry_decode(uid=uid=testuser,ou=people,o=test) ldap_url_parse_ext(ldaps://ldapprov) send_ldap_extended: err=10 oid= len=0 ldap_url_parse_ext(ldaps://ldapprov) ----

the strace backlog says: --- strace (only last ~130 lines ... tell me if you want to read the whole 2500+!) [snip] read(13, "B\223l\0008\0\0\0007\376\205V8\0\0\0.\0\0\200\22\0\0\0"..., 32768) = 32768 _llseek(13, 7146591, [7146591], SEEK_SET) = 0 read(13, "\0\0\0\0\0\0\0\0\0\0\0\0", 12) = 12 close(13) = 0 stat64("/var/lib/ldap/__db.004", 0xbfd23b2c) = -1 ENOENT (No such file or directory) open("/var/lib/ldap/__db.004", O_RDWR|O_CREAT|O_LARGEFILE, 0600) = 13 fcntl64(13, F_SETFD, FD_CLOEXEC) = 0 _llseek(13, 0, [0], SEEK_END) = 0 _llseek(13, 442368, [442368], SEEK_CUR) = 0 write(13, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 8192) = 8192 mmap2(NULL, 450560, PROT_READ|PROT_WRITE, MAP_SHARED, 13, 0) = 0xb647d000 close(13) = 0 stat64("/var/lib/ldap/__db.005", 0xbfd23b6c) = -1 ENOENT (No such file or directory) open("/var/lib/ldap/__db.005", O_RDWR|O_CREAT|O_LARGEFILE, 0600) = 13 fcntl64(13, F_SETFD, FD_CLOEXEC) = 0 _llseek(13, 0, [0], SEEK_END) = 0 _llseek(13, 16384, [16384], SEEK_CUR) = 0 write(13, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 8192) = 8192 mmap2(NULL, 24576, PROT_READ|PROT_WRITE, MAP_SHARED, 13, 0) = 0xb6477000 close(13) = 0 time(NULL) = 1179177532 time(NULL) = 1179177532 stat64("/var/lib/ldap/log.0000000018", {st_mode=S_IFREG|0600, st_size=10485760, ...}) = 0 open("/var/lib/ldap/log.0000000018", O_RDONLY|O_LARGEFILE) = 13 fcntl64(13, F_SETFD, FD_CLOEXEC) = 0 fstat64(13, {st_mode=S_IFREG|0600, st_size=10485760, ...}) = 0 _llseek(13, 7146535, [7146535], SEEK_SET) = 0 read(13, "\316\vm\0008\0\0\0\376\346\315~", 12) = 12 _llseek(13, 7113823, [7113823], SEEK_SET) = 0 read(13, "\0\0\0\30\0\0\0\317\2\0\0\220\1\0\0\10\0\0\0\10\0\0\0\4"..., 32768) = 32768 stat64("/var/lib/ldap/log.0000000001", 0xbfd2386c) = -1 ENOENT (No such file or directory) open("/var/lib/ldap", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 14 fstat64(14, {st_mode=S_IFDIR|0700, st_size=4096, ...}) = 0 fcntl64(14, F_SETFD, FD_CLOEXEC) = 0 getdents64(14, /* 33 entries */, 4096) = 1176 getdents64(14, /* 0 entries */, 4096) = 0 close(14) = 0 stat64("/var/lib/ldap/log.0000000018", {st_mode=S_IFREG|0600, st_size=10485760, ...}) = 0 open("/var/lib/ldap/log.0000000018", O_RDONLY|O_LARGEFILE) = 14 fcntl64(14, F_SETFD, FD_CLOEXEC) = 0 read(14, "\330\354\237\0\34\0\0\0\0!\301\205\210\t\4\0\n\0\0\0\0"..., 28) = 28 close(14) = 0 stat64("/var/lib/ldap/log.0000000017", {st_mode=S_IFREG|0600, st_size=10485760, ...}) = 0 open("/var/lib/ldap/log.0000000017", O_RDONLY|O_LARGEFILE) = 14 fcntl64(14, F_SETFD, FD_CLOEXEC) = 0 read(14, "\236\377\237\0\34\0\0\0\0!\301\205\210\t\4\0\n\0\0\0\0"..., 28) = 28 close(14) = 0 close(13) = 0 stat64("/var/lib/ldap/log.0000000017", {st_mode=S_IFREG|0600, st_size=10485760, ...}) = 0 open("/var/lib/ldap/log.0000000017", O_RDONLY|O_LARGEFILE) = 13 fcntl64(13, F_SETFD, FD_CLOEXEC) = 0 fstat64(13, {st_mode=S_IFREG|0600, st_size=10485760, ...}) = 0 _llseek(13, 0, [0], SEEK_SET) = 0 read(13, "\236\377\237\0\34\0\0\0\0!\301\205", 12) = 12 _llseek(13, 0, [0], SEEK_SET) = 0 read(13, "\236\377\237\0\34\0\0\0\0!\301\205\210\t\4\0\n\0\0\0\0"..., 32768) = 32768 close(13) = 0 stat64("/var/lib/ldap/log.0000000018", {st_mode=S_IFREG|0600, st_size=10485760, ...}) = 0 open("/var/lib/ldap/log.0000000018", O_RDONLY|O_LARGEFILE) = 13 fcntl64(13, F_SETFD, FD_CLOEXEC) = 0 fstat64(13, {st_mode=S_IFREG|0600, st_size=10485760, ...}) = 0 _llseek(13, 7146535, [7146535], SEEK_SET) = 0 read(13, "\316\vm\0008\0\0\0\376\346\315~", 12) = 12 _llseek(13, 7113823, [7113823], SEEK_SET) = 0 read(13, "\0\0\0\30\0\0\0\317\2\0\0\220\1\0\0\10\0\0\0\10\0\0\0\4"..., 32768) = 32768 stat64("/var/lib/ldap/id2entry.bdb", {st_mode=S_IFREG|0600, st_size=15826944, ...}) = 0 stat64("/var/lib/ldap/id2entry.bdb", {st_mode=S_IFREG|0600, st_size=15826944, ...}) = 0 open("/var/lib/ldap/id2entry.bdb", O_RDWR|O_LARGEFILE) = 14 fcntl64(14, F_SETFD, FD_CLOEXEC) = 0 read(14, "\22\0\0\0\212^i\0\0\0\0\0b1\5\0\t\0\0\0\0@\0\0\0\t\0\0"..., 512) = 512 close(14) = 0 stat64("/var/lib/ldap/id2entry.bdb", {st_mode=S_IFREG|0600, st_size=15826944, ...}) = 0 open("/var/lib/ldap/id2entry.bdb", O_RDWR|O_LARGEFILE) = 14 fcntl64(14, F_SETFD, FD_CLOEXEC) = 0 fstat64(14, {st_mode=S_IFREG|0600, st_size=15826944, ...}) = 0 pread64(14, "\22\0\0\0\212^i\0\0\0\0\0b1\5\0\t\0\0\0\0@\0\0\0\t\0\0"..., 16384, 0) = 16384 close(14) = 0 time(NULL) = 1179177532 time(NULL) = 1179177532 close(13) = 0 lseek(12, 0, SEEK_SET) = 0 fcntl64(12, F_SETLKW, {type=F_WRLCK, whence=SEEK_CUR, start=0, len=1024}) = 0 fstat64(12, {st_mode=S_IFREG|0644, st_size=4096, ...}) = 0 lseek(12, 2048, SEEK_SET) = 2048 read(12, "xV4\22\0\0\0\0\2\0\0\0\0\0\0\0\20\322HF\0\0\0\0\271v\0"..., 1024) = 1024 lseek(12, 2048, SEEK_SET) = 2048 fcntl64(12, F_GETLK, {type=F_UNLCK, whence=SEEK_CUR, start=0, len=1024, pid=0}) = 0 lseek(12, 2048, SEEK_SET) = 2048 read(12, "xV4\22\0\0\0\0\2\0\0\0\0\0\0\0\20\322HF\0\0\0\0\271v\0"..., 1024) = 1024 lseek(12, 2048, SEEK_SET) = 2048 write(12, "xV4\22\0\0\0\0\0\0\0\0\0\0\0\0\20\322HF\0\0\0\0\271v\0"..., 1024) = 1024 lseek(12, 3072, SEEK_SET) = 3072 read(12, "xV4\22\0\0\0\0\0\0\0\0\0\0\0\0 yHF\0\0\0\0\242q\0\0\0\0"..., 1024) = 1024 lseek(12, 0, SEEK_SET) = 0 fcntl64(12, F_SETLK, {type=F_UNLCK, whence=SEEK_CUR, start=0, len=1024}) = 0 stat64("/var/lib/ldap/id2entry.bdb", {st_mode=S_IFREG|0600, st_size=15826944, ...}) = 0 stat64("/var/lib/ldap/id2entry.bdb", {st_mode=S_IFREG|0600, st_size=15826944, ...}) = 0 open("/var/lib/ldap/id2entry.bdb", O_RDWR|O_LARGEFILE) = 13 fcntl64(13, F_SETFD, FD_CLOEXEC) = 0 read(13, "\22\0\0\0\212^i\0\0\0\0\0b1\5\0\t\0\0\0\0@\0\0\0\t\0\0"..., 512) = 512 close(13) = 0 stat64("/var/lib/ldap/id2entry.bdb", {st_mode=S_IFREG|0600, st_size=15826944, ...}) = 0 open("/var/lib/ldap/id2entry.bdb", O_RDWR|O_LARGEFILE) = 13 fcntl64(13, F_SETFD, FD_CLOEXEC) = 0 fstat64(13, {st_mode=S_IFREG|0600, st_size=15826944, ...}) = 0 time(NULL) = 1179177532 stat64("/var/lib/ldap/dn2id.bdb", {st_mode=S_IFREG|0600, st_size=5132288, ...}) = 0 stat64("/var/lib/ldap/dn2id.bdb", {st_mode=S_IFREG|0600, st_size=5132288, ...}) = 0 open("/var/lib/ldap/dn2id.bdb", O_RDWR|O_LARGEFILE) = 14 fcntl64(14, F_SETFD, FD_CLOEXEC) = 0 read(14, "\22\0\0\0\tEQ\0\0\0\0\0b1\5\0\t\0\0\0\0\20\0\0\0\t\0\0"..., 512) = 512 close(14) = 0 stat64("/var/lib/ldap/dn2id.bdb", {st_mode=S_IFREG|0600, st_size=5132288, ...}) = 0 open("/var/lib/ldap/dn2id.bdb", O_RDWR|O_LARGEFILE) = 14 fcntl64(14, F_SETFD, FD_CLOEXEC) = 0 fstat64(14, {st_mode=S_IFREG|0600, st_size=5132288, ...}) = 0 pread64(14, "\22\0\0\0\tEQ\0\0\0\0\0b1\5\0\t\0\0\0\0\20\0\0\0\t\0\0"..., 4096, 0) = 4096 time(NULL) = 1179177532 pread64(13, "\20\0\0\0008\fY\0\1\0\0\0\0\0\0\0\0\0\0\0\2\0\344?\3\3"..., 16384, 16384) = 16384 pread64(13, "\22\0\0\0:^i\0\220\3\0\0\0\0\0\0\0\0\0\0\335\0010"\2\3"..., 16384, 14942208) = 16384 pread64(13, "\22\0\0\0\235\0m\0W\3\0\0O\3\0\0\0\0\0\0\20\0\270!\1\5"..., 16384, 14008320) = 16384 write(2, "slapd starting\n", 15) = 15 mmap2(NULL, 385024, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb6419000 mmap2(NULL, 8392704, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb5c18000 mprotect(0xb5c18000, 4096, PROT_NONE) = 0 clone(child_stack=0xb64184d4, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, parent_tidptr=0xb6418be8, {entry_number:6, base_addr:0xb6418ba0, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}, child_tidptr=0xb6418be8) = 30400 futex(0xb6418be8, FUTEX_WAIT, 30400, NULL) = -1 EINTR (Interrupted system call) +++ killed by SIGSEGV +++ ----------------

what i find odd is the error "stat64("/var/lib/ldap/__db.004", 0xbfd23b2c) = -1 ENOENT (No such file or directory)" (just at the beginning of the post) because the file actually is there and accessable:

[host]: ls -l /var/lib/ldap/__db.004 -rw------- 1 ldap ldap 450560 May 12 22:45 /var/lib/ldap/__db.004

now if i change the settings in slapd.conf on the consumer and remove the line "updateref" (as in slapd-chain1.conf is no such line) the server (consumer) stays alive but on running "ldappasswd -x <...>" i get: ---- ldappasswd -x <...> New password: Re-enter new password: Enter LDAP Password: Result: Server is unwilling to perform (53) Additional info: shadow context; no update referral ----

is the line "updateref" needed? but it crashes the server with my config?!

what am i doing wrong?

thanks in advance for your help and patience (and sorry for the long post ...)

regards markus

+-----------------------------------------------------------------+ | Markus Krause, Mogli-Soft | | Support for Mac OS X, Webmail/Horde, LDAP, RADIUS, MySQL | | by order of the | | Computing Center of the Max-Planck-Institute of Biochemistry | +--------------------------------+--------------------------------+ | E-Mail: krause@biochem.mpg.de | Tel.: 089 - 89 40 85 99 | | markus.krause@mac.com | Fax.: 089 - 89 40 85 98 | | Skype: markus.krause | iChat: markus.krause@mac.com | +--------------------------------+--------------------------------+

---------------------------------------------------------------------- This message was sent using https://webmail2.biochem.mpg.de If you encounter any problems please report to rz-linux@biochem.mpg.de

Zitat von Pierangelo Masarati ando@sys-net.it:

Markus Krause wrote:

...

Zitat von Pierangelo Masarati ando@sys-net.it:

...

Markus Krause wrote:

...

Hi list!

i have several consumer and one provider (lets call them ldapconX and ldapprov). syncrepl works fine, but i actually do not want any clients to contact the provider directly (and i have in addition some clients which would not understand referrals anyway), so reading through the admin guide and man pages i thought slapo-chain would be the solution! (correct me if i am wrong ;-)) But somehow a can not get it working...

the slapd.conf of the provider is untouched, the consumer have (simplified in some places; please tell me if you need it in more details):

slapo-chain must be global (i.e. before any database) since referrals are returned by the frontend, as soon as it discovers that the database that is candidate for a modification is shadow. See example in consumer slapd.conf in test018.

thanks for your answer! i assume you are referring to slapd-chain1.conf, as in slapd-chain2.conf

No. I'm referring to slapd.4.conf as generated by the test018 script.

ah ok, sorry for that. i could not find it at first, had ro stop "make test" at test018 to get it ... now i used it (and slapd.1.conf) as template for my config.

...

the overlay chain is after the database definition (which i used after the success following your hint in my acl problem thread).

In that case, the test was testing slapo-chain behavior when used to chain databases, not to chase referrals originating by writing to a shadow. That requires replication, and that's why it's in test018.

...

but i am still doing something wrong... just to be sure i ran all tests again (make test) which all were finished ok.

now my slapd.conf is like: --- slapd.conf (simplified) ... acl overlay chain chain-rebind-as-user FALSE chain-uri "ldaps://ldapprov" chain-rebind-as-user TRUE chain-idassert-bind bindmethod="simple" binddn="cn=manager,o=test" credentials="secret" mode="self" flags=non-prescriptive database bdb ... overlay smbk5pwd syncrepl .... updateref ldaps://ldapprov

Please muve the updateref and the syncrepl lines __before__ overlays related lines.

i am really sorry about still bothering you with my problems but i still have no success... :-( my slapd.conf now looks like (now in more detail, just cleaned up): --- slapd.conf ... modulepath /usr/lib/openldap/modules moduleload smbk5pwd.so sizelimit unlimited acl ... TLSstuff ... #### chain overlay definition overlay chain chain-rebind-as-user FALSE chain-uri "ldaps://ldapprov" chain-rebind-as-user TRUE chain-idassert-bind bindmethod="simple" binddn="cn=manager,o=test" credentials="secret" mode="self"

database bdb suffix "o=test" directory /var/lib/ldap/ rootdn "cn=manager,o=test" rootpw "secret" index objectClass,uidNumber,gidNumber eq index member,mail eq,pres index cn,displayname,uid,sn,givenname sub,eq,pres index sambaSID,sambaPrimaryGroupSID,sambaDomainName eq index entryCSN,entryUUID eq index dhcpHWAddress eq,pres index relativeDomainName eq,pres index ipHostNumber eq,pres index zoneName eq,pres index radiusGroupName eq,pres

syncrepl rid=13 provider=ldaps://ldapprov type=refreshAndPersist retry=1,5,5,6,30,+ interval=00:00:00:30 searchbase="o=test" filter="(objectclass=*)" scope=sub attrs="*" schemachecking=off binddn="cn=manager,o=test" bindmethod=simple credentials="secret" sizelimit=unlimited updateref ldaps://ldapprov

overlay syncprov overlay smbk5pwd smbk5pwd-enable samba --- end of slapd.conf

...

the strace backlog says:

I'd stick with slapd logs.

ok.

...

is the line "updateref" needed? but it crashes the server with my config?!

Please rearrange the configuration as instructed and retry. In general, never intermix database and overlay directives. Order matters (as it always did; but now violations are no longer harmless).

i hope i did understand how which order the entries should have ... (see above)

but the last lines before the consumer dies after running "ldappasswd .." show: --- slapd -d 65535 output ... => bdb_dn2id("uid=user,o=test") <= bdb_dn2id: got id=0x0000337f entry_decode: "uid=user,o=test" <= entry_decode(uid=user,o=test) ldap_url_parse_ext(ldaps://ldapprov) send_ldap_extended: err=10 oid= len=0 ldap_url_parse_ext(ldaps://ldapprov) Segmentation fault --- end of slapd -d 65535 output

ineresting (at least for me) is that if i provide the wrong ldap password to "ldappasswd" the output of "ldappaswd" is: --- ldappasswd -x -h localhost <...> New password: Re-enter new password: Enter LDAP Password: ldap_bind: Invalid credentials (49) --- and the consumer stays alive.. does this mean there is something wrong with the provider config? just to be sure the slapd.conf: ---- slapf.conf of provider include ... modulepath /usr/lib/openldap/modules moduleload smbk5pwd.so sizelimit unlimited acls ... TLSStuff database bdb suffix "o=teset" directory /var/lib/ldap/ rootdn "cn=manager,o=test" rootpw "secret" index ...

overlay syncprov overlay smbk5pwd smbk5pwd-enable samba ---

but the provider debug output seems to be ok, just says: --- slapd -d 65535 of provider ber_get_next on fd 16 failed errno=0 (Success) connection_read(16): input error=-2 id=2, closing. connection_closing: readying conn=2 sd=16 for close connection_close: conn=2 sd=16 daemon: removing 16 tls_write: want=37, written=37 0000: 15 03 01 00 20 ff da 2f 93 ad 2b 27 df b9 2c f5 .... ../..+'..,. 0010: 3f 57 27 a2 12 f8 35 d4 76 3e 35 a1 04 78 e3 9b ?W'...5.v>5..x.. 0020: bd d0 6f fc 29 ..o.) TLS trace: SSL3 alert write:warning:close notify conn=2 fd=16 closed (connection lost) daemon: epoll: listen=7 active_threads=0 tvp=NULL ---

it seems i am still configuring something completely wrong (or am misunterstanding some basic concepts ..). where is my mistake??

thanks in advance for your help and patience!

with best regards markus

+-----------------------------------------------------------------+ | Markus Krause, Mogli-Soft | | Support for Mac OS X, Webmail/Horde, LDAP, RADIUS, MySQL | | by order of the | | Computing Center of the Max-Planck-Institute of Biochemistry | +--------------------------------+--------------------------------+ | E-Mail: krause@biochem.mpg.de | Tel.: 089 - 89 40 85 99 | | markus.krause@mac.com | Fax.: 089 - 89 40 85 98 | | Skype: markus.krause | iChat: markus.krause@mac.com | +--------------------------------+--------------------------------+

---------------------------------------------------------------------- This message was sent using https://webmail2.biochem.mpg.de If you encounter any problems please report to rz-linux@biochem.mpg.de

Zitat von Pierangelo Masarati ando@sys-net.it:

Markus Krause wrote:

...

...

No. I'm referring to slapd.4.conf as generated by the test018 script.

ah ok, sorry for that. i could not find it at first, had ro stop "make test" at test018 to get it ... now i used it (and slapd.1.conf) as template for my config.

I assumed you knew that you can tun a single test by issuing

./run test018

from the tests/ directory. Sorry about that.

ok, no problem, next time i'll use that!

...

i am really sorry about still bothering you with my problems but i still have no success... :-( my slapd.conf now looks like (now in more detail, just cleaned up): --- slapd.conf [...] --- end of slapd.conf

To me, it looks just fine.

good! :-) at least i got that now!

...

...

Please rearrange the configuration as instructed and retry. In general, never intermix database and overlay directives. Order matters (as it always did; but now violations are no longer harmless).

i hope i did understand how which order the entries should have ... (see above)

but the last lines before the consumer dies after running "ldappasswd .." show: --- slapd -d 65535 output ... => bdb_dn2id("uid=user,o=test") <= bdb_dn2id: got id=0x0000337f entry_decode: "uid=user,o=test" <= entry_decode(uid=user,o=test) ldap_url_parse_ext(ldaps://ldapprov) send_ldap_extended: err=10 oid= len=0 ldap_url_parse_ext(ldaps://ldapprov) Segmentation fault --- end of slapd -d 65535 output

That's another issue. You may send a stack backtrace after this crash.

here are the last 70 lines which i think are written by strace after i used ldappasswd (just tell me if you want to see more of it, i just thought that 2600+ lines are to much for the list and of no use): --- tail -70 strace slapd -d 65535 time(NULL) = 1179248871 time(NULL) = 1179248871 close(14) = 0 close(15) = 0 close(13) = 0 lseek(12, 0, SEEK_SET) = 0 fcntl64(12, F_SETLKW, {type=F_WRLCK, whence=SEEK_CUR, start=0, len=1024}) = 0 fstat64(12, {st_mode=S_IFREG|0644, st_size=4096, ...}) = 0 lseek(12, 2048, SEEK_SET) = 2048 read(12, "xV4\22\0\0\0\0\2\0\0\0\0\0\0\0 \300IF\0\0\0\0\310~\0\0"..., 1024) = 1024 lseek(12, 2048, SEEK_SET) = 2048 fcntl64(12, F_GETLK, {type=F_UNLCK, whence=SEEK_CUR, start=0, len=1024, pid=0}) = 0 lseek(12, 2048, SEEK_SET) = 2048 read(12, "xV4\22\0\0\0\0\2\0\0\0\0\0\0\0 \300IF\0\0\0\0\310~\0\0"..., 1024) = 1024 lseek(12, 2048, SEEK_SET) = 2048 write(12, "xV4\22\0\0\0\0\0\0\0\0\0\0\0\0 \300IF\0\0\0\0\310~\0\0"..., 1024) = 1024 lseek(12, 3072, SEEK_SET) = 3072 read(12, "xV4\22\0\0\0\0\0\0\0\0\0\0\0\0 yHF\0\0\0\0\242q\0\0\0\0"..., 1024) = 1024 lseek(12, 0, SEEK_SET) = 0 fcntl64(12, F_SETLK, {type=F_UNLCK, whence=SEEK_CUR, start=0, len=1024}) = 0 stat64("/var/lib/ldap/id2entry.bdb", {st_mode=S_IFREG|0600, st_size=15826944, ...}) = 0 stat64("/var/lib/ldap/id2entry.bdb", {st_mode=S_IFREG|0600, st_size=15826944, ...}) = 0 open("/var/lib/ldap/id2entry.bdb", O_RDWR|O_LARGEFILE) = 13 fcntl64(13, F_SETFD, FD_CLOEXEC) = 0 read(13, "\22\0\0\0\212^i\0\0\0\0\0b1\5\0\t\0\0\0\0@\0\0\0\t\0\0"..., 512) = 512 close(13) = 0 stat64("/var/lib/ldap/id2entry.bdb", {st_mode=S_IFREG|0600, st_size=15826944, ...}) = 0 open("/var/lib/ldap/id2entry.bdb", O_RDWR|O_LARGEFILE) = 13 fcntl64(13, F_SETFD, FD_CLOEXEC) = 0 fstat64(13, {st_mode=S_IFREG|0600, st_size=15826944, ...}) = 0 time(NULL) = 1179248871 stat64("/var/lib/ldap/dn2id.bdb", {st_mode=S_IFREG|0600, st_size=5132288, ...}) = 0 stat64("/var/lib/ldap/dn2id.bdb", {st_mode=S_IFREG|0600, st_size=5132288, ...}) = 0 open("/var/lib/ldap/dn2id.bdb", O_RDWR|O_LARGEFILE) = 14 fcntl64(14, F_SETFD, FD_CLOEXEC) = 0 read(14, "\22\0\0\0\tEQ\0\0\0\0\0b1\5\0\t\0\0\0\0\20\0\0\0\t\0\0"..., 512) = 512 close(14) = 0 stat64("/var/lib/ldap/dn2id.bdb", {st_mode=S_IFREG|0600, st_size=5132288, ...}) = 0 open("/var/lib/ldap/dn2id.bdb", O_RDWR|O_LARGEFILE) = 14 fcntl64(14, F_SETFD, FD_CLOEXEC) = 0 fstat64(14, {st_mode=S_IFREG|0600, st_size=5132288, ...}) = 0 time(NULL) = 1179248871 pread64(13, "\20\0\0\0008\fY\0\1\0\0\0\0\0\0\0\0\0\0\0\2\0\344?\3\3"..., 16384, 16384) = 16384 pread64(13, "\22\0\0\0:^i\0\220\3\0\0\0\0\0\0\0\0\0\0\335\0010"\2\3"..., 16384, 14942208) = 16384 pread64(13, "\22\0\0\0\235\0m\0W\3\0\0O\3\0\0\0\0\0\0\20\0\270!\1\5"..., 16384, 14008320) = 16384 mmap2(NULL, 1052672, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb63c3000 time(NULL) = 1179248871 write(2, "=> bdb_entry_get: ndn: "o=testh"..., 49) = 49 write(2, "=> bdb_entry_get: oc: "(null)", "..., 49) = 49 write(2, "bdb_dn2entry("o=test"..., 40) = 40 write(2, "=> bdb_dn2id("o=test"..., 40) = 40 pread64(14, "\t\0\0\0D+=\0\1\0\0\0\0\0\0\0\0\0\0\0\20\0\214\r\3\3\364"..., 4096, 4096) = 4096 pread64(14, "\n\0\0\0\212\242P\0_\2\0\0\0\0\0\0G\4\0\0G\0\364\7\2\3"..., 4096, 2486272) = 4096 pread64(14, "\22\0\0\0i\374l\0\n\0\0\0Q\3\0\0\33\4\0\0>\0\230\6\1\5"..., 4096, 40960) = 4096 write(2, "<= bdb_dn2id: got id=0x00000001\n", 32) = 32 pread64(13, "\20\0\0\0\230\313X\0\217\3\0\0\0\0\0\0\0\0\0\0\307\1\224"..., 16384, 14925824) = 16384 pread64(13, "\22\0\0\0O\2m\0\2\0\0\0\0\0\0\0\3\0\0\0(\0|\4\1\5\370?"..., 16384, 32768) = 16384 write(2, "entry_decode: "o=test"..., 40) = 40 write(2, "<= entry_decode(o=test"..., 41) = 41 write(2, "=> bdb_entry_get: found entry: ""..., 57) = 57 write(2, "bdb_entry_get: rc=0\n", 20) = 20 mmap2(NULL, 8392704, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb5bc2000 mprotect(0xb5bc2000, 4096, PROT_NONE) = 0 clone(child_stack=0xb63c24d4, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, parent_tidptr=0xb63c2be8, {entry_number:6, base_addr:0xb63c2ba0, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}, child_tidptr=0xb63c2be8) = 374 futex(0xb63c2be8, FUTEX_WAIT, 374, NULL) = 0 write(2, "slapd starting\n", 15) = 15 mmap2(NULL, 385024, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb5363000 clone(child_stack=0xb63c24d4, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, parent_tidptr=0xb63c2be8, {entry_number:6, base_addr:0xb63c2ba0, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}, child_tidptr=0xb63c2be8) = 375 futex(0xb63c2be8, FUTEX_WAIT, 375, NULL) = 0 +++ killed by SIGSEGV +++ ---

In any case, you didn't specify you were trying to perform an extended operation (ldap passwd); there might be some bg in how extended operations are handled by slapo-chain(5).

sorry, i thought i mentioned that the crash occurs on using "ldappasswd" via the command line ... and did not know that this is an extended operation

I'd narrow this down by running ldappasswd within a simpler configuration setup. In case, please file an ITS.

ok, its ID 4964: http://www.openldap.org/its/index.cgi/Incoming?id=4964;expression=slapo-chai...

In the meanwhile, I'd check your configuration by using a less challenging write operation (like a modify).

thanks again for your help!

with best regards markus

+-----------------------------------------------------------------+ | Markus Krause, Mogli-Soft | | Support for Mac OS X, Webmail/Horde, LDAP, RADIUS, MySQL | | by order of the | | Computing Center of the Max-Planck-Institute of Biochemistry | +--------------------------------+--------------------------------+ | E-Mail: krause@biochem.mpg.de | Tel.: 089 - 89 40 85 99 | | markus.krause@mac.com | Fax.: 089 - 89 40 85 98 | | Skype: markus.krause | iChat: markus.krause@mac.com | +--------------------------------+--------------------------------+

---------------------------------------------------------------------- This message was sent using https://webmail2.biochem.mpg.de If you encounter any problems please report to rz-linux@biochem.mpg.de

Zitat von Pierangelo Masarati ando@sys-net.it:

Markus Krause wrote:

...

...

That's another issue. You may send a stack backtrace after this crash.

here are the last 70 lines which i think are written by strace after i used ldappasswd (just tell me if you want to see more of it, i just thought that 2600+ lines are to much for the list and of no use): --- tail -70 strace slapd -d 65535

I mean: stack backtrace from a debugger, e.g. gdb.

ok, the final lines are:

Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1255220320 (LWP 2118)] 0xb7afbe8b in strlen () from /lib/libc.so.6 (gdb) bt #0 0xb7afbe8b in strlen () from /lib/libc.so.6 #1 0xb7ad0828 in vfprintf () from /lib/libc.so.6 #2 0x801450a2 in __PRETTY_FUNCTION__.10283 () from /usr/lib/openldap/slapd #3 0x00000015 in ?? () #4 0x00000000 in ?? ()

regards markus

p.

Ing. Pierangelo Masarati OpenLDAP Core Team

SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it

---

Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati@sys-net.it

---

+-----------------------------------------------------------------+ | Markus Krause, Mogli-Soft | | Support for Mac OS X, Webmail/Horde, LDAP, RADIUS, MySQL | | by order of the | | Computing Center of the Max-Planck-Institute of Biochemistry | +--------------------------------+--------------------------------+ | E-Mail: krause@biochem.mpg.de | Tel.: 089 - 89 40 85 99 | | markus.krause@mac.com | Fax.: 089 - 89 40 85 98 | | Skype: markus.krause | iChat: markus.krause@mac.com | +--------------------------------+--------------------------------+

---------------------------------------------------------------------- This message was sent using https://webmail2.biochem.mpg.de If you encounter any problems please report to rz-linux@biochem.mpg.de

Zitat von Pierangelo Masarati ando@sys-net.it:

...

my slapd.conf now looks like (now in more detail, just cleaned up): --- slapd.conf ... modulepath /usr/lib/openldap/modules moduleload smbk5pwd.so sizelimit unlimited acl ... TLSstuff ... #### chain overlay definition overlay chain chain-rebind-as-user FALSE chain-uri "ldaps://ldapprov" chain-rebind-as-user TRUE chain-idassert-bind bindmethod="simple" binddn="cn=manager,o=test" credentials="secret" mode="self"

database bdb suffix "o=test" directory /var/lib/ldap/ rootdn "cn=manager,o=test" rootpw "secret" index objectClass,uidNumber,gidNumber eq index member,mail eq,pres index cn,displayname,uid,sn,givenname sub,eq,pres index sambaSID,sambaPrimaryGroupSID,sambaDomainName eq index entryCSN,entryUUID eq index dhcpHWAddress eq,pres index relativeDomainName eq,pres index ipHostNumber eq,pres index zoneName eq,pres index radiusGroupName eq,pres

syncrepl rid=13 provider=ldaps://ldapprov type=refreshAndPersist retry=1,5,5,6,30,+ interval=00:00:00:30 searchbase="o=test" filter="(objectclass=*)" scope=sub attrs="*" schemachecking=off binddn="cn=manager,o=test" bindmethod=simple credentials="secret" sizelimit=unlimited updateref ldaps://ldapprov

overlay syncprov overlay smbk5pwd smbk5pwd-enable samba --- end of slapd.conf

To me, it looks just fine.

In the meanwhile, I'd check your configuration by using a less challenging write operation (like a modify).

i just tried an "ldapadd" and get: --- ldapadd -x -h localhost -D "cn=manager,o=test" -W -f testuser.ldif Enter LDAP Password: adding new entry "uid=testuser,ou=People,o=test ldap_add: Referral (10) referrals: ldaps://ldapprov/uid=testuser,ou=People,o=test ---

actually i thought that the consumer (on localhost) with slapo-chain should send the "change command" to the provider without notifying the client?

regards markus

+-----------------------------------------------------------------+ | Markus Krause, Mogli-Soft | | Support for Mac OS X, Webmail/Horde, LDAP, RADIUS, MySQL | | by order of the | | Computing Center of the Max-Planck-Institute of Biochemistry | +--------------------------------+--------------------------------+ | E-Mail: krause@biochem.mpg.de | Tel.: 089 - 89 40 85 99 | | markus.krause@mac.com | Fax.: 089 - 89 40 85 98 | | Skype: markus.krause | iChat: markus.krause@mac.com | +--------------------------------+--------------------------------+

---------------------------------------------------------------------- This message was sent using https://webmail2.biochem.mpg.de If you encounter any problems please report to rz-linux@biochem.mpg.de