- openldap-bugs - openldap.org

(ITS#4924) assertion failure during test039-glue-ldap-concurrency
by rhafer＠suse.de 10 Apr '07

10 Apr '07

Full_Name: Ralf Haferkamp Version: 2.3.35 OS: Linux (Kernel 2.6 on ppc) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (89.166.148.128) 2.3.35 failed for me during test039-glue-ldap-concurrency with: lt-slapd-search: request.c:465: ldap_new_connection: Assertion `0' failed. stopping: child terminated with signal 6 Unfortunately, I can't provide any more info currently as the logs were already removed from our build farm :( I'll try to reproduce the problem again. But it seems to not to occur during every run.

1 0

Re: (ITS#4922) test_filter problem on uid filter
by h.b.furuseth＠usit.uio.no 10 Apr '07

10 Apr '07

juritanganelli(a)gmail.com writes: > I don't believe that i can use an index. The result is returned from > my backend that doesn't use any dbd based database but generates data > on the fly ( merging results from an oracle db with some custom > business logic.). I read somewhere else that this was a known issue on > a previous version of openldap but in this situation i can't generate > any useful index Duh.. sorry, I read "custom backend" as "customized"... What you described is the usual symptom when you use a backend which does support indexing (bdb/hdb/ldbm) and you edit slapd.conf to include a new index. -- Regards, Hallvard

1 0

Re: (ITS#4922) test_filter problem on uid filter
by h.b.furuseth＠usit.uio.no 10 Apr '07

10 Apr '07

juritanganelli(a)gmail.com writes: > - when i use the complete value of the attribute such as uid=e497004 > no result is returned, but there is an entry with that value. stop slapd, run sbin/slapindex, restart slapd, and tell us if that helped. Needed if you add the index to slapd.conf when you alreayd have a database, since just editing slapd.conf does not index existing data. > - when i use some regular expressions the result is correclty such as > uid=e* the corresponding entry is correctly returned. Substring, not a regular expression. By default, a substring search with just a single letter does not use indexes, it just trawls through each entry in scope. -- Regards, Hallvard

1 0

Re: (ITS#4923) back-config and olcModuleLoad kills slapd
by ghenry＠suretecsystems.com 10 Apr '07

10 Apr '07

<quote who="hyc(a)symas.com"> > ghenry(a)suretecsystems.com wrote: >> Full_Name: Gavin Henry >> Version: 2.3.35 >> OS: Fedora Core 6 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (212.159.59.85) >> >> >> Dear All, >> >> I know you can add modules like: >> >> dn: cn=module{0},cn=config >> objectClass: olcModuleList >> cn: module{0} >> olcModuleLoad: /usr/local/lib/smbk5pwd.la >> >> dn: cn=module{1},cn=config >> objectClass: olcModuleList >> cn: module{1} >> olcModulePath: /usr/local/lib:/usr/local/lib/slapd >> olcModuleLoad: accesslog.la >> olcModuleLoad: pcache.la >> >> But when migrating from slapd.conf, they get listed as: >> >> dn: cn=module{0},cn=config >> olcModuleLoad: {0}back_hdb.la >> olcModuleLoad: {1}accesslog.la >> olcModuleLoad: {2}syncprov.la >> olcModuleLoad: {3}back_monitor.la >> >> I am trying to add the smbk5pwd module like so: >> >> dn: cn=module{0},cn=config >> changetype: modify >> replace: olcModuleLoad >> olcModuleLoad: {0}back_hdb.la >> olcModuleLoad: {1}accesslog.la >> olcModuleLoad: {2}syncprov.la >> olcModuleLoad: {3}back_monitor.la >> olcModuleLoad: {4}smbk5pwd.la >> >> Command: >> >> ldapmodify -d 1 -x -D "cn=config" -W -f /home/ghenry/Desktop/smb.ldif >> -ZZ >> >> ldapmodify excepts the above LDIF. >> >> But slapd dies: >> >> Program received signal SIGABRT, Aborted. >> [Switching to Thread -1558062192 (LWP 24587)] >> 0x00bfd402 in __kernel_vsyscall () >> (gdb) bt >> #0 0x00bfd402 in __kernel_vsyscall () >> #1 0x0026ad40 in raise () from /lib/libc.so.6 >> #2 0x0026c591 in abort () from /lib/libc.so.6 >> #3 0x0026438b in __assert_fail () from /lib/libc.so.6 >> #4 0x080a26ce in slap_bv2ad () >> #5 0x080a33c0 in slap_str2ad () >> #6 0x08060f81 in init_config_attrs () >> #7 0x0805f7e7 in config_register_schema () >> #8 0x004db1e3 in hdb_back_init_cf (bi=0x4f8960) at config.c:695 >> #9 0x004d755d in hdb_back_initialize (bi=0x4f8960) at init.c:683 >> #10 0x08075e6b in backend_add () >> #11 0x004d7328 in init_module (argc=0, argv=0x0) at init.c:693 >> #12 0x080aec33 in module_load () >> #13 0x0805abd6 in str2loglevel () >> #14 0x080611e2 in config_set_vals () >> #15 0x0806310d in config_parse_add () >> #16 0x0805d899 in str2loglevel () >> #17 0x0807f89b in fe_op_modify () >> #18 0x080800d8 in do_modify () >> #19 0x08068bd9 in connection2anonymous () >> #20 0x0099260d in ldap_int_thread_pool_wrapper (xpool=0xa3c1ffd8) at >> tpool.c:478 >> #21 0x006e63db in start_thread () from /lib/libpthread.so.0 >> #22 0x0030f26e in clone () from /lib/libc.so.6 >> >> Is this a LDIF format issue on my part? > > Yes. > > You should just be doing a modify like > > > dn: cn=module{0},cn=config > > changetype: modify > > add: olcModuleLoad > > olcModuleLoad: smbk5pwd.la > > since you're not actually changing any of the other values. True. I remember reading somewhere the ordering etc. nm. as slapd does that bit. > > In the meantime, back-config should not be accepting a "replace" request > for olcModuleLoad attributes, since you're not allowed to delete > modules, and replace is just delete/add. Yeah, anything that causes a crash shouldn't be allowed ;-) Thanks. > > -- > -- Howard Chu > Chief Architect, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ > > >

1 0

Re: (ITS#4921) back-config and included ACLs
by ghenry＠suretecsystems.com 10 Apr '07

10 Apr '07

<quote who="hyc(a)symas.com"> > hyc(a)symas.com wrote: >> ghenry(a)suretecsystems.com wrote: >>> Full_Name: Gavin Henry >>> Version: 2.3.35 >>> OS: Fedora Core 6 >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (212.159.59.85) >>> >>> >>> Dear All, >>> >>> Minor issue. When including an acl file, this acl file appears in >>> cn=schema: >>> >>> dn: cn=include{8},cn=config >>> objectClass: olcIncludeFile >>> cn: include{8} >>> olcInclude: /usr/local/etc/openldap/suretec.acl >>> >>> Shows as: >>> >>> dn: cn={8}suretec,cn=schema,cn=config >>> objectClass: olcSchemaConfig >>> cn: {8}suretec >>> >>> I don't think this should show in the schema tree. >> >> Indeed. It's only supposed to show up there if it actually contained any >> schema directives. Oops. > > back-config in HEAD/RE24 already does the right thing here. The > corresponding code just didn't get backported to RE23. I guess we can > fix it in the next RE23, but it doesn't seem critical. Nah, just thought it worth a mention. Gavin. > > -- > -- Howard Chu > Chief Architect, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ > > >

1 0

Re: (ITS#4921) back-config and included ACLs
by hyc＠symas.com 10 Apr '07

10 Apr '07

hyc(a)symas.com wrote: > ghenry(a)suretecsystems.com wrote: >> Full_Name: Gavin Henry >> Version: 2.3.35 >> OS: Fedora Core 6 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (212.159.59.85) >> >> >> Dear All, >> >> Minor issue. When including an acl file, this acl file appears in cn=schema: >> >> dn: cn=include{8},cn=config >> objectClass: olcIncludeFile >> cn: include{8} >> olcInclude: /usr/local/etc/openldap/suretec.acl >> >> Shows as: >> >> dn: cn={8}suretec,cn=schema,cn=config >> objectClass: olcSchemaConfig >> cn: {8}suretec >> >> I don't think this should show in the schema tree. > > Indeed. It's only supposed to show up there if it actually contained any > schema directives. Oops. back-config in HEAD/RE24 already does the right thing here. The corresponding code just didn't get backported to RE23. I guess we can fix it in the next RE23, but it doesn't seem critical. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#4923) back-config and olcModuleLoad kills slapd
by hyc＠symas.com 10 Apr '07

10 Apr '07

ghenry(a)suretecsystems.com wrote: > Full_Name: Gavin Henry > Version: 2.3.35 > OS: Fedora Core 6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (212.159.59.85) > > > Dear All, > > I know you can add modules like: > > dn: cn=module{0},cn=config > objectClass: olcModuleList > cn: module{0} > olcModuleLoad: /usr/local/lib/smbk5pwd.la > > dn: cn=module{1},cn=config > objectClass: olcModuleList > cn: module{1} > olcModulePath: /usr/local/lib:/usr/local/lib/slapd > olcModuleLoad: accesslog.la > olcModuleLoad: pcache.la > > But when migrating from slapd.conf, they get listed as: > > dn: cn=module{0},cn=config > olcModuleLoad: {0}back_hdb.la > olcModuleLoad: {1}accesslog.la > olcModuleLoad: {2}syncprov.la > olcModuleLoad: {3}back_monitor.la > > I am trying to add the smbk5pwd module like so: > > dn: cn=module{0},cn=config > changetype: modify > replace: olcModuleLoad > olcModuleLoad: {0}back_hdb.la > olcModuleLoad: {1}accesslog.la > olcModuleLoad: {2}syncprov.la > olcModuleLoad: {3}back_monitor.la > olcModuleLoad: {4}smbk5pwd.la > > Command: > > ldapmodify -d 1 -x -D "cn=config" -W -f /home/ghenry/Desktop/smb.ldif -ZZ > > ldapmodify excepts the above LDIF. > > But slapd dies: > > Program received signal SIGABRT, Aborted. > [Switching to Thread -1558062192 (LWP 24587)] > 0x00bfd402 in __kernel_vsyscall () > (gdb) bt > #0 0x00bfd402 in __kernel_vsyscall () > #1 0x0026ad40 in raise () from /lib/libc.so.6 > #2 0x0026c591 in abort () from /lib/libc.so.6 > #3 0x0026438b in __assert_fail () from /lib/libc.so.6 > #4 0x080a26ce in slap_bv2ad () > #5 0x080a33c0 in slap_str2ad () > #6 0x08060f81 in init_config_attrs () > #7 0x0805f7e7 in config_register_schema () > #8 0x004db1e3 in hdb_back_init_cf (bi=0x4f8960) at config.c:695 > #9 0x004d755d in hdb_back_initialize (bi=0x4f8960) at init.c:683 > #10 0x08075e6b in backend_add () > #11 0x004d7328 in init_module (argc=0, argv=0x0) at init.c:693 > #12 0x080aec33 in module_load () > #13 0x0805abd6 in str2loglevel () > #14 0x080611e2 in config_set_vals () > #15 0x0806310d in config_parse_add () > #16 0x0805d899 in str2loglevel () > #17 0x0807f89b in fe_op_modify () > #18 0x080800d8 in do_modify () > #19 0x08068bd9 in connection2anonymous () > #20 0x0099260d in ldap_int_thread_pool_wrapper (xpool=0xa3c1ffd8) at > tpool.c:478 > #21 0x006e63db in start_thread () from /lib/libpthread.so.0 > #22 0x0030f26e in clone () from /lib/libc.so.6 > > Is this a LDIF format issue on my part? Yes. You should just be doing a modify like > dn: cn=module{0},cn=config > changetype: modify > add: olcModuleLoad > olcModuleLoad: smbk5pwd.la since you're not actually changing any of the other values. In the meantime, back-config should not be accepting a "replace" request for olcModuleLoad attributes, since you're not allowed to delete modules, and replace is just delete/add. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#4921) back-config and included ACLs
by hyc＠symas.com 10 Apr '07

10 Apr '07

ghenry(a)suretecsystems.com wrote: > Full_Name: Gavin Henry > Version: 2.3.35 > OS: Fedora Core 6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (212.159.59.85) > > > Dear All, > > Minor issue. When including an acl file, this acl file appears in cn=schema: > > dn: cn=include{8},cn=config > objectClass: olcIncludeFile > cn: include{8} > olcInclude: /usr/local/etc/openldap/suretec.acl > > Shows as: > > dn: cn={8}suretec,cn=schema,cn=config > objectClass: olcSchemaConfig > cn: {8}suretec > > I don't think this should show in the schema tree. Indeed. It's only supposed to show up there if it actually contained any schema directives. Oops. > > Thanks, > > Gavin. > > > . > -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#4923) back-config and olcModuleLoad kills slapd
by ghenry＠suretecsystems.com 10 Apr '07

10 Apr '07

Full_Name: Gavin Henry Version: 2.3.35 OS: Fedora Core 6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (212.159.59.85) Dear All, I know you can add modules like: dn: cn=module{0},cn=config objectClass: olcModuleList cn: module{0} olcModuleLoad: /usr/local/lib/smbk5pwd.la dn: cn=module{1},cn=config objectClass: olcModuleList cn: module{1} olcModulePath: /usr/local/lib:/usr/local/lib/slapd olcModuleLoad: accesslog.la olcModuleLoad: pcache.la But when migrating from slapd.conf, they get listed as: dn: cn=module{0},cn=config olcModuleLoad: {0}back_hdb.la olcModuleLoad: {1}accesslog.la olcModuleLoad: {2}syncprov.la olcModuleLoad: {3}back_monitor.la I am trying to add the smbk5pwd module like so: dn: cn=module{0},cn=config changetype: modify replace: olcModuleLoad olcModuleLoad: {0}back_hdb.la olcModuleLoad: {1}accesslog.la olcModuleLoad: {2}syncprov.la olcModuleLoad: {3}back_monitor.la olcModuleLoad: {4}smbk5pwd.la Command: ldapmodify -d 1 -x -D "cn=config" -W -f /home/ghenry/Desktop/smb.ldif -ZZ ldapmodify excepts the above LDIF. But slapd dies: Program received signal SIGABRT, Aborted. [Switching to Thread -1558062192 (LWP 24587)] 0x00bfd402 in __kernel_vsyscall () (gdb) bt #0 0x00bfd402 in __kernel_vsyscall () #1 0x0026ad40 in raise () from /lib/libc.so.6 #2 0x0026c591 in abort () from /lib/libc.so.6 #3 0x0026438b in __assert_fail () from /lib/libc.so.6 #4 0x080a26ce in slap_bv2ad () #5 0x080a33c0 in slap_str2ad () #6 0x08060f81 in init_config_attrs () #7 0x0805f7e7 in config_register_schema () #8 0x004db1e3 in hdb_back_init_cf (bi=0x4f8960) at config.c:695 #9 0x004d755d in hdb_back_initialize (bi=0x4f8960) at init.c:683 #10 0x08075e6b in backend_add () #11 0x004d7328 in init_module (argc=0, argv=0x0) at init.c:693 #12 0x080aec33 in module_load () #13 0x0805abd6 in str2loglevel () #14 0x080611e2 in config_set_vals () #15 0x0806310d in config_parse_add () #16 0x0805d899 in str2loglevel () #17 0x0807f89b in fe_op_modify () #18 0x080800d8 in do_modify () #19 0x08068bd9 in connection2anonymous () #20 0x0099260d in ldap_int_thread_pool_wrapper (xpool=0xa3c1ffd8) at tpool.c:478 #21 0x006e63db in start_thread () from /lib/libpthread.so.0 #22 0x0030f26e in clone () from /lib/libc.so.6 Is this a LDIF format issue on my part? Thanks, Gavin.

1 0

(ITS#4922) test_filter problem on uid filter
by juritanganelli＠gmail.com 10 Apr '07

10 Apr '07

Full_Name: juri tanganelli Version: 2.3.27 OS: Red Hat EL 3 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (195.7.19.10) I have developed a custom backend that uses the test_filter function to determine if an entry is matching a given input filter. Filter on any of the entry attribute but Uid works fine. When i specify i filter on the uid attribute i get very strange results for example: - when i use the complete value of the attribute such as uid=e497004 no result is returned, but there is an entry with that value. - when i use some regular expressions the result is correclty such as uid=e* the corresponding entry is correctly returned. Regards, Juri

1 0

(ITS#4921) back-config and included ACLs
by ghenry＠suretecsystems.com 10 Apr '07

10 Apr '07

Full_Name: Gavin Henry Version: 2.3.35 OS: Fedora Core 6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (212.159.59.85) Dear All, Minor issue. When including an acl file, this acl file appears in cn=schema: dn: cn=include{8},cn=config objectClass: olcIncludeFile cn: include{8} olcInclude: /usr/local/etc/openldap/suretec.acl Shows as: dn: cn={8}suretec,cn=schema,cn=config objectClass: olcSchemaConfig cn: {8}suretec I don't think this should show in the schema tree. Thanks, Gavin.

1 0

Re: (ITS#4920) bad connection sequencing
by hyc＠symas.com 10 Apr '07

10 Apr '07

h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: HEAD > OS: Linux > URL: http://folk.uio.no/hbf/OpenLDAP/bug032.tgz > Submission from: (NULL) (129.240.202.105) > Submitted by: hallvard > > > Statslog() from even successful tests can show strange sequencing. > > grep '^conn=' testrun/slapd.*.log from a test032-chain run shows > - Operations logged on connections before ACCEPT > (slapd.1.log conn=2,3 + slapd.2.log conn=7,9) > - Operations on a connection with no ACCEPT (slapd.1.log conn=10), > but a 'conn=-1 fd=21 ACCEPT' _after_ that fd's 'close', > and valgrind shows memory errors between the close and the ACCEPT. > The enclosed URL gives the testrun directory and test output. Haven't looked at that yet. > Similar things show up in other tests. A test019 run with a > conn=-1 ACCEPT did not get valgrind memory compaints though. > grep 'conn=-1' testrun/slapd.*.log also found a number of > send_ldap_result: conn=-1 op=0 p=<0 or 3> > even in logs without any conn=-1, but maybe that's a "fake > connection"? Don't know why results are sent though. send_ldap_result is always logged, since it occurs before callback processing. So even if it's an internal op with a null callback, it will get logged. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#4920) bad connection sequencing
by h.b.furuseth＠usit.uio.no 09 Apr '07

09 Apr '07

Full_Name: Hallvard B Furuseth Version: HEAD OS: Linux URL: http://folk.uio.no/hbf/OpenLDAP/bug032.tgz Submission from: (NULL) (129.240.202.105) Submitted by: hallvard Statslog() from even successful tests can show strange sequencing. grep '^conn=' testrun/slapd.*.log from a test032-chain run shows - Operations logged on connections before ACCEPT (slapd.1.log conn=2,3 + slapd.2.log conn=7,9) - Operations on a connection with no ACCEPT (slapd.1.log conn=10), but a 'conn=-1 fd=21 ACCEPT' _after_ that fd's 'close', and valgrind shows memory errors between the close and the ACCEPT. The enclosed URL gives the testrun directory and test output. Similar things show up in other tests. A test019 run with a conn=-1 ACCEPT did not get valgrind memory compaints though. grep 'conn=-1' testrun/slapd.*.log also found a number of send_ldap_result: conn=-1 op=0 p=<0 or 3> even in logs without any conn=-1, but maybe that's a "fake connection"? Don't know why results are sent though.

1 0

Re: (ITS#4919) Why CPU usage can not reach 100% while doing modify operation?
by hyc＠symas.com 09 Apr '07

09 Apr '07

The ITS is for tracking bug reports and enhancement requests. I don't see a bug report here. Try asking your question on the OpenLDAP-software mailing list. This ITS will be closed. seuler(a)163.com wrote: > Full_Name: Seuler Shi > Version: openldap-2.3.30 > OS: SUSE 9 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (194.138.202.50) > > > When I do the search operation, the CPU usage of OpenLDAP Server can reach 100% > when the number of search operations per second arise? But for the modify > operation, > the CPU usage can only reach 87% at most? > > What is the bottleneck that makes OpenLDAP can not make CPU recource fully while > > doing modify operation? -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#4919) Why CPU usage can not reach 100% while doing modify operation?
by seuler＠163.com 09 Apr '07

09 Apr '07

Full_Name: Seuler Shi Version: openldap-2.3.30 OS: SUSE 9 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (194.138.202.50) When I do the search operation, the CPU usage of OpenLDAP Server can reach 100% when the number of search operations per second arise? But for the modify operation, the CPU usage can only reach 87% at most? What is the bottleneck that makes OpenLDAP can not make CPU recource fully while doing modify operation?

1 0

Re: (ITS#4916) syncrpl consumer not listing contextcsn as operation attr
by brian＠zimbra.com 07 Apr '07

07 Apr '07

thanks, that worked, this case can be closed. Brian Peterson On Apr 6, 2007, at 1:58 PM, Howard Chu wrote: > brian(a)zimbra.com wrote: >> Full_Name: Brian Peterson >> Version: 2.3.34 >> OS: Linux >> URL: pro >> Submission from: (NULL) (66.92.25.194) >> When setup sync replication the contextCSN is available via >> ldapsearch on the >> provider but not the consumer as an operation attribute. If we do >> a slapcat on >> the consumer the resulting ldif contains the contextCSN. > > This is because your context entry has no DN, it's a glue entry. > When you do a search on it you get the contents of the server > rootDSE instead of your glue entry. The search works on the > provider because the syncprov overlay intercepts searches to insert > the current contextCSN value in the result. You can add a syncprov > overlay to the consumer to get the same effect. > >> Top entry from slapcat ldif on the consumer. >> dn: >> objectClass: glue >> structuralObjectClass: glue >> contextCSN: 20070405182202Z#000000#00#000000 >> entryCSN: 20070405182202Z#000000#00#000000 >> modifiersName: uid=zimbra,cn=admins,cn=zimbra >> modifyTimestamp: 20070405182202Z > > > -- > -- Howard Chu > Chief Architect, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#4918) int = pointer assignment in syncrepl
by hyc＠symas.com 06 Apr '07

06 Apr '07

h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: RE23 > OS: > URL: > Submission from: (NULL) (129.240.202.105) > Submitted by: hallvard > > > In RE23:syncrepl.c:do_syncrepl() lin 1155, the statement > fail = si->si_retrynum; > assigns an int* to an int. > > > . > Thanks, fixed. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#4918) int = pointer assignment in syncrepl
by h.b.furuseth＠usit.uio.no 06 Apr '07

06 Apr '07

Full_Name: Hallvard B Furuseth Version: RE23 OS: URL: Submission from: (NULL) (129.240.202.105) Submitted by: hallvard In RE23:syncrepl.c:do_syncrepl() lin 1155, the statement fail = si->si_retrynum; assigns an int* to an int.

1 0

Re: (ITS#4916) syncrpl consumer not listing contextcsn as operation attr
by hyc＠symas.com 06 Apr '07

06 Apr '07

brian(a)zimbra.com wrote: > Full_Name: Brian Peterson > Version: 2.3.34 > OS: Linux > URL: pro > Submission from: (NULL) (66.92.25.194) > > > When setup sync replication the contextCSN is available via ldapsearch on the > provider but not the consumer as an operation attribute. If we do a slapcat on > the consumer the resulting ldif contains the contextCSN. This is because your context entry has no DN, it's a glue entry. When you do a search on it you get the contents of the server rootDSE instead of your glue entry. The search works on the provider because the syncprov overlay intercepts searches to insert the current contextCSN value in the result. You can add a syncprov overlay to the consumer to get the same effect. > Top entry from slapcat ldif on the consumer. > dn: > objectClass: glue > structuralObjectClass: glue > contextCSN: 20070405182202Z#000000#00#000000 > entryCSN: 20070405182202Z#000000#00#000000 > modifiersName: uid=zimbra,cn=admins,cn=zimbra > modifyTimestamp: 20070405182202Z > > > -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#4917) at_insert() moves sat_ad_mutex
by h.b.furuseth＠usit.uio.no 06 Apr '07

06 Apr '07

hyc(a)symas.com wrote: >h.b.furuseth(a)usit.uio.no wrote: >> If so, the simplest clean fix may be to destroy and reinitialize >> the mutexes (instead of swapping them back), I think strictly >> speaking behaviour is undefined if one copies mutexes around at >> all. Or since one will immediately be destroyed, maybe they should >> be destroyed when SLAP_AT_DELETED is set, if it is not needed then. > > Destroying immediately is not feasible since the attribute may still > be in use. OK. > Show me the POSIX spec that indicates this behavior is undefined. I wasn't thinking of POSIX in particular (OpenLDAP supports several mutex types afer all), though the pthread_mutex_init() spec says Only mutex itself may be used for performing synchronization. The result of referring to copies of mutex in calls to pthread_mutex_lock(), pthread_mutex_trylock(), pthread_mutex_unlock(), and pthread_mutex_destroy() is undefined. Attempting to initialize an already initialized mutex results in undefined behavior. The current swap definitely makes it undefined. Whether swapping and copying back does so as well is probably just pedantry when they are unlocked, though in theory I imagine some thread magic could happen even to "passive" mutexes. Except I take it only one thread is running... -- Regards, Hallvard

1 0

Re: (ITS#4917) at_insert() moves sat_ad_mutex
by hyc＠symas.com 06 Apr '07

06 Apr '07

h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: HEAD > OS: > URL: > Submission from: (NULL) (129.240.202.105) > Submitted by: hallvard > > > slapd/at.c:at_insert() swaps the contents of the initialized > mutexes 'old_sat->sat_ad_mutex' and 'sat->sat_ad_mutex' in the > /* replacing a deleted definition? */ code. > > I hope they are at least unlocked at the time... > Does ldap_pvt_thread_pool_pause() in config_back_add() & co block > the other threads? Yes of course, otherwise none of the config activities would be safe. > If so, the simplest clean fix may be to destroy and reinitialize > the mutexes (instead of swapping them back), I think strictly > speaking behaviour is undefined if one copies mutexes around at > all. Or since one will immediately be destroyed, maybe they should > be destroyed when SLAP_AT_DELETED is set, if it is not needed then. Destroying immediately is not feasible since the attribute may still be in use. Show me the POSIX spec that indicates this behavior is undefined. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#4917) at_insert() moves sat_ad_mutex
by h.b.furuseth＠usit.uio.no 06 Apr '07

06 Apr '07

Full_Name: Hallvard B Furuseth Version: HEAD OS: URL: Submission from: (NULL) (129.240.202.105) Submitted by: hallvard slapd/at.c:at_insert() swaps the contents of the initialized mutexes 'old_sat->sat_ad_mutex' and 'sat->sat_ad_mutex' in the /* replacing a deleted definition? */ code. I hope they are at least unlocked at the time... Does ldap_pvt_thread_pool_pause() in config_back_add() & co block the other threads? If so, the simplest clean fix may be to destroy and reinitialize the mutexes (instead of swapping them back), I think strictly speaking behaviour is undefined if one copies mutexes around at all. Or since one will immediately be destroyed, maybe they should be destroyed when SLAP_AT_DELETED is set, if it is not needed then.

1 0

(ITS#4916) syncrpl consumer not listing contextcsn as operation attr
by brian＠zimbra.com 06 Apr '07

06 Apr '07

Full_Name: Brian Peterson Version: 2.3.34 OS: Linux URL: pro Submission from: (NULL) (66.92.25.194) When setup sync replication the contextCSN is available via ldapsearch on the provider but not the consumer as an operation attribute. If we do a slapcat on the consumer the resulting ldif contains the contextCSN. relavent slapd.conf entries from provider(please let me know if you want the entire file). database bdb suffix "" rootdn "uid=zimbra,cn=admins,cn=zimbra" # recommended for replication index entryUUID eq index entryCSN eq overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 500 slapd.conf entries from consumer. database bdb suffix "" rootdn "uid=zimbra,cn=admins,cn=zimbra" syncrepl rid=022 provider=ldap://ldapmaster:389 retry="60 +" type=refreshAndPersist schemachecking=off updatedn="uid=zimbrareplication,cn=admins,cn=zimbra" searchbase="" bindmethod=simple binddn="uid=zimbra,cn=admins,cn=zimbra" creditionals=secret updateref ldap://ldapmaster:389 Ldap search output from the consumer ldapsearch -LLL -x -D uid=zimbra,cn=admins,cn=zimbra -w secret -H ldap://ldapreplica:389 -s base -b "" + dn: structuralObjectClass: OpenLDAProotDSE configContext: cn=config namingContexts: supportedControl: 1.3.6.1.4.1.4203.1.9.1.1 supportedControl: 2.16.840.1.113730.3.4.18 supportedControl: 2.16.840.1.113730.3.4.2 supportedControl: 1.3.6.1.4.1.4203.1.10.1 supportedControl: 1.2.840.113556.1.4.319 supportedControl: 1.2.826.0.1.334810.2.3 supportedControl: 1.2.826.0.1.3344810.2.3 supportedControl: 1.3.6.1.1.13.2 supportedControl: 1.3.6.1.1.13.1 supportedControl: 1.3.6.1.1.12 supportedExtension: 1.3.6.1.4.1.1466.20037 supportedExtension: 1.3.6.1.4.1.4203.1.11.1 supportedExtension: 1.3.6.1.4.1.4203.1.11.3 supportedFeatures: 1.3.6.1.1.14 supportedFeatures: 1.3.6.1.4.1.4203.1.5.1 supportedFeatures: 1.3.6.1.4.1.4203.1.5.2 supportedFeatures: 1.3.6.1.4.1.4203.1.5.3 supportedFeatures: 1.3.6.1.4.1.4203.1.5.4 supportedFeatures: 1.3.6.1.4.1.4203.1.5.5 supportedLDAPVersion: 3 entryDN: subschemaSubentry: cn=Subschema Top entry from slapcat ldif on the consumer. dn: objectClass: glue structuralObjectClass: glue contextCSN: 20070405182202Z#000000#00#000000 entryCSN: 20070405182202Z#000000#00#000000 modifiersName: uid=zimbra,cn=admins,cn=zimbra modifyTimestamp: 20070405182202Z

1 0

Re: (ITS#4915) Syncrepl task exits are not logged
by hyc＠symas.com 06 Apr '07

06 Apr '07

unix.gurus(a)gmail.com wrote: > Full_Name: Sean Burford > Version: 2.3.32 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (65.57.245.11) > > > It is hard to tell when the syncrepl task has exited. The attached patch adds > logging of syncrepl hard and soft failures. > > Using this patch, it is easier to spot unfortunate conditions where recoverable > failures are treated as hard failures, for example the third line below shows > that a (temporarily) unavailable kerberos credential cache causes a hard > failure: > GSSAPI Error: Miscellaneous failure (No credentials cache found) > do_syncrep1: rid 123 ldap_sasl_interactive_bind_s failed (-2) > do_syncrepl: rid 123 hard failure Looks like a good idea, thanks. I think I'd just change the messages to "giving up" or "quitting", and "retrying". That final else clause in your patch should never occur, there is no 3rd outcome. > > Hmm, no attachment because the FTP server returns: > 200 PORT command successful. > 150 Opening ASCII mode data connection for > 'openldap-2.3.32-syncrepl-log-failure.patch'. > ## > 452 Error writing file: No space left on device. > 1104 bytes sent in 0.00011 seconds (1e+04 Kbytes/s) > > The patch was: > *** openldap-2.3.32.orig/servers/slapd/syncrepl.c Wed Apr 4 17:21:31 > 2007 > --- openldap-2.3.32/servers/slapd/syncrepl.c Wed Apr 4 17:55:58 2007 > *************** > *** 1147,1159 **** > --- 1147,1169 ---- > } > > if ( !si->si_retrynum || si->si_retrynum[i] == RETRYNUM_TAIL ) > { > + Debug( LDAP_DEBUG_ANY, > + "do_syncrepl: rid %03d hard failure\n", > + si->si_rid, 0, 0 ); > ldap_pvt_runqueue_remove( &slapd_rq, rtask ); > } else if ( RETRYNUM_VALID( si->si_retrynum[i] ) ) { > if ( si->si_retrynum[i] > 0 ) > si->si_retrynum[i]--; > + Debug( LDAP_DEBUG_ANY, > + "do_syncrepl: rid %03d soft failure, > rescheduling (retries left: %d)\n", > + si->si_rid, si->si_retrynum[i], 0 ); > rtask->interval.tv_sec = si->si_retryinterval[i]; > ldap_pvt_runqueue_resched( &slapd_rq, rtask, 0 ); > slap_wake_listener(); > + } else { > + Debug( LDAP_DEBUG_ANY, > + "do_syncrepl: rid %03d soft failure, > rescheduling\n", > + si->si_rid, 0, 0 ); > } > } > > > -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#4915) Syncrepl task exits are not logged
by unix.gurus＠gmail.com 06 Apr '07

06 Apr '07

Full_Name: Sean Burford Version: 2.3.32 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (65.57.245.11) It is hard to tell when the syncrepl task has exited. The attached patch adds logging of syncrepl hard and soft failures. Using this patch, it is easier to spot unfortunate conditions where recoverable failures are treated as hard failures, for example the third line below shows that a (temporarily) unavailable kerberos credential cache causes a hard failure: GSSAPI Error: Miscellaneous failure (No credentials cache found) do_syncrep1: rid 123 ldap_sasl_interactive_bind_s failed (-2) do_syncrepl: rid 123 hard failure Hmm, no attachment because the FTP server returns: 200 PORT command successful. 150 Opening ASCII mode data connection for 'openldap-2.3.32-syncrepl-log-failure.patch'. ## 452 Error writing file: No space left on device. 1104 bytes sent in 0.00011 seconds (1e+04 Kbytes/s) The patch was: *** openldap-2.3.32.orig/servers/slapd/syncrepl.c Wed Apr 4 17:21:31 2007 --- openldap-2.3.32/servers/slapd/syncrepl.c Wed Apr 4 17:55:58 2007 *************** *** 1147,1159 **** --- 1147,1169 ---- } if ( !si->si_retrynum || si->si_retrynum[i] == RETRYNUM_TAIL ) { + Debug( LDAP_DEBUG_ANY, + "do_syncrepl: rid %03d hard failure\n", + si->si_rid, 0, 0 ); ldap_pvt_runqueue_remove( &slapd_rq, rtask ); } else if ( RETRYNUM_VALID( si->si_retrynum[i] ) ) { if ( si->si_retrynum[i] > 0 ) si->si_retrynum[i]--; + Debug( LDAP_DEBUG_ANY, + "do_syncrepl: rid %03d soft failure, rescheduling (retries left: %d)\n", + si->si_rid, si->si_retrynum[i], 0 ); rtask->interval.tv_sec = si->si_retryinterval[i]; ldap_pvt_runqueue_resched( &slapd_rq, rtask, 0 ); slap_wake_listener(); + } else { + Debug( LDAP_DEBUG_ANY, + "do_syncrepl: rid %03d soft failure, rescheduling\n", + si->si_rid, 0, 0 ); } }

1 0

Re: (ITS#4907) Syncrepl consumer failing to perform deletes
by unix.gurus＠gmail.com 06 Apr '07

06 Apr '07

------=_Part_45311_2874873.1175811229646 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline On 4/3/07, Howard Chu <hyc(a)symas.com> wrote: > The log says that ITS#4638 was already fixed in 2.3.32. Why are you > still using that particular patch, given that an alternate solution is > already present in the release? I can't replicate ITS#4638 under 2.3.32, so you can mark ITS#4907 resolved (I removed the bad patch). I also see that in RE23 we had one more patch to fix some interaction > between slapo-rwm and back-meta for filter processing. I suggest you > test against the current RE23 code. I expect to push 2.3.35 out pretty > soon. Thank you. Sean ------=_Part_45311_2874873.1175811229646 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline <span class="gmail_quote">On 4/3/07, <b class="gmail_sendername">Howard Chu</b> <<a href="mailto:hyc@symas.com">hyc(a)symas.com</a>> wrote:</span><br><div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> The log says that ITS#4638 was already fixed in 2.3.32. Why are you<br>still using that particular patch, given that an alternate solution is<br>already present in the release?</blockquote><div><br>I can't replicate ITS#4638 under 2.3.32, so you can mark ITS#4907 resolved (I removed the bad patch).<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">I also see that in RE23 we had one more patch to fix some interaction <br>between slapo-rwm and back-meta for filter processing. I suggest you<br>test against the current RE23 code. I expect to push 2.3.35 out pretty soon.</blockquote><div><br>Thank you. <br></div><br></div>Sean ------=_Part_45311_2874873.1175811229646--

1 0

Re: (ITS#4913) configure & BerkleyDB
by ando＠sys-net.it 05 Apr '07

05 Apr '07

fredo(a)sundancer.us wrote: > Full_Name: Fred Obermann > Version: 2.3.34 > OS: linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (24.20.15.25) > > > I just downloaded, built and installed openldap-2.3.34 using BerkeleyDB-4.5.20. > > > There seems to be a disconnect between where openldap-2.3.34 'configure' expects > db.h is and where Oracle's build procedure puts db.h. > > For 4.5.20, db.h is located in "/usr/local/BerkeleyDB.4.5/include". Setting: > CPPFLAGS="I/usr/local/BerkeleyDB.4.5/include", prior to invoking 'configure' Perhaps adding a "-" before "I" could help. Please check and report. > does not seem to enable 'configure' to find 'db.h'. Providing soft link from > /usr/local/BerkeleyDB.4.5/include/db.h to /usr/include seems to fix this > problem > > Furthermore there seems to be a disconnect between the Oracle naming convention > for the BerkeleyDB libraries and what openldap's 'configure' utility seems to > expect. > > I set: > LIBS=-L/usr/local/BerkeleyDB.4.5/lib prior to invoking 'configure' > > But 'configure' is looking for libdb45.a or libdb-45.a or libdb4.5.a. > > However, what the Oracle build procedure produces are: libdb-4.5.a > libdb-4.5.la libdb-4.5.so libdb-4.so libdb.a libdb.so > > Creating a soft link from libdb-4.5.a to libdb45.a seems to fix this problem. > > Nonetheless, it would be better if the 'configure' script were expanded to > gracefully handle this latest release of BerkeleyDB from Oracle. > > > > > > 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(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#4913) configure & BerkleyDB
by hyc＠symas.com 05 Apr '07

05 Apr '07

fredo(a)sundancer.us wrote: > Full_Name: Fred Obermann > Version: 2.3.34 > OS: linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (24.20.15.25) > > > I just downloaded, built and installed openldap-2.3.34 using BerkeleyDB-4.5.20. > > > There seems to be a disconnect between where openldap-2.3.34 'configure' expects > db.h is and where Oracle's build procedure puts db.h. > > For 4.5.20, db.h is located in "/usr/local/BerkeleyDB.4.5/include". Setting: > CPPFLAGS="I/usr/local/BerkeleyDB.4.5/include", prior to invoking 'configure' > does not seem to enable 'configure' to find 'db.h'. Providing soft link from > /usr/local/BerkeleyDB.4.5/include/db.h to /usr/include seems to fix this > problem If that's exactly what you used, you're missing the "-" in CPPFLAGS="-I..." > Furthermore there seems to be a disconnect between the Oracle naming convention > for the BerkeleyDB libraries and what openldap's 'configure' utility seems to > expect. The configure script works perfectly fine with all 4.x releases of BerkeleyDB, including 4.6 which has not yet been publicly released. This ITS will be closed. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#4914) It's possible to add multiple config-Databases
by rhafer＠suse.de 05 Apr '07

05 Apr '07

Full_Name: Ralf Haferkamp Version: HEAD OS: Linux (Kernel 2.6) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (89.166.166.70) Subject say it. You can add multiple olcDatabase=config Entries to the cn=config Backend. (With slapadd or through ldapadd) A fix is on the way to CVS. It will also make sure that olcDatabase=config always gets the Index 0.

1 0

(ITS#4913) configure & BerkleyDB
by fredo＠sundancer.us 05 Apr '07

05 Apr '07

Full_Name: Fred Obermann Version: 2.3.34 OS: linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (24.20.15.25) I just downloaded, built and installed openldap-2.3.34 using BerkeleyDB-4.5.20. There seems to be a disconnect between where openldap-2.3.34 'configure' expects db.h is and where Oracle's build procedure puts db.h. For 4.5.20, db.h is located in "/usr/local/BerkeleyDB.4.5/include". Setting: CPPFLAGS="I/usr/local/BerkeleyDB.4.5/include", prior to invoking 'configure' does not seem to enable 'configure' to find 'db.h'. Providing soft link from /usr/local/BerkeleyDB.4.5/include/db.h to /usr/include seems to fix this problem Furthermore there seems to be a disconnect between the Oracle naming convention for the BerkeleyDB libraries and what openldap's 'configure' utility seems to expect. I set: LIBS=-L/usr/local/BerkeleyDB.4.5/lib prior to invoking 'configure' But 'configure' is looking for libdb45.a or libdb-45.a or libdb4.5.a. However, what the Oracle build procedure produces are: libdb-4.5.a libdb-4.5.la libdb-4.5.so libdb-4.so libdb.a libdb.so Creating a soft link from libdb-4.5.a to libdb45.a seems to fix this problem. Nonetheless, it would be better if the 'configure' script were expanded to gracefully handle this latest release of BerkeleyDB from Oracle.

1 0

Re: (ITS#4911) slapadd uses slap_op_mutex uninitialized
by hyc＠symas.com 05 Apr '07

05 Apr '07

h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: HEAD > OS: Linux > URL: > Submission from: (NULL) (129.240.202.105) > Submitted by: hallvard > > > slapadd uses slap_op_mutex uninitialized in operation.c:slap_op_time() Fixed. > Any hope of making the tools and slapd go through the same init/destroy code > in main(), maybe by making the server just another "tool"? Seems to me the > only hope of making bugs like this keep popping up... In the past the tools didn't use threads and didn't share as much code with slapd. As such, it seems a lot of subsystems really didn't need to be set up for tool mode. I guess things have changed since we now use Operation structures everywhere. Tools like slappasswd don't even read the slapd config. That means you can't use slappasswd with a dynamically loaded password-hash module. So yes, some of this structuring needs to be revisited. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

ITS#4910 mirrormode
by hyc＠symas.com 05 Apr '07

05 Apr '07

The mirrormode functionality has changed in 2.4.4 (compared to 2.4.3 and earlier) since full multimaster is now supported. You must set a unique serverID on each server to enable replication. See slapd-config(5) for the olcServerID config item. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#4912) test043 cores in bdb_locker_id_free()
by hyc＠symas.com 05 Apr '07

05 Apr '07

h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: HEAD > OS: Linux > URL: > Submission from: (NULL) (129.240.202.105) > Submitted by: hallvard > > > test043 leaves behind two core files from a crash in bdb_locker_id_free(). Fixed. > > The test does succeed though. (Argh, I've got to dig up that test script > patch of mine, I don't even remember what the showstopper was anymore...) Would be nice to get that in. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#4912) test043 cores in bdb_locker_id_free()
by h.b.furuseth＠usit.uio.no 04 Apr '07

04 Apr '07

Full_Name: Hallvard B Furuseth Version: HEAD OS: Linux URL: Submission from: (NULL) (129.240.202.105) Submitted by: hallvard test043 leaves behind two core files from a crash in bdb_locker_id_free(). The test does succeed though. (Argh, I've got to dig up that test script patch of mine, I don't even remember what the showstopper was anymore...) >>>>> Starting test043-delta-syncrepl ... running defines.sh Starting producer slapd on TCP/IP port 9011... Using ldapsearch to check that producer slapd is running... Using ldapadd to create the context prefix entries in the producer... Starting consumer slapd on TCP/IP port 9012... Using ldapsearch to check that consumer slapd is running... Using ldapadd to populate the producer directory... Waiting 15 seconds for syncrepl to receive changes... Stopping the provider, sleeping 10 seconds and restarting it... ./scripts/test043-delta-syncrepl: line 130: 5697 Segmentation fault (core dumped) $SLAPD -f $CONF1 -h $URI1 -d $LVL $TIMING >$LOG1 2>&1 Using ldapsearch to check that producer slapd is running... Using ldapmodify to modify producer directory... Waiting 15 seconds for syncrepl to receive changes... Stopping consumer to test recovery... Modifying more entries on the producer... Restarting consumer... Waiting 25 seconds for syncrepl to receive changes... Try updating the consumer slapd... Waiting 15 seconds for syncrepl to receive changes... Using ldapsearch to read all the entries from the producer... Using ldapsearch to read all the entries from the consumer... Filtering producer results... Filtering consumer results... Comparing retrieved entries from producer and consumer... >>>>> Test succeeded ./scripts/test043-delta-syncrepl: line 356: 5715 Segmentation fault (core dumped) $SLAPD -f $CONF1 -h $URI1 -d $LVL $TIMING >>$LOG1 2>&1 >>>>> ./scripts/test043-delta-syncrepl completed OK. $ gdb ../servers/slapd/slapd core.5697 (the other crashes with the same backtrace) (gdb) thread apply all backtrace Thread 1 (process 5697): #0 0xdbdbdbdb in ?? () #1 0x08119e27 in bdb_locker_id_free (key=0x83536b0, data=0x7) at cache.c:1360 #2 0x0818e6ec in ldap_int_thread_pool_context_reset (vctx=0x8275160) at tpool.c:912 #3 0x081913a6 in ldap_pvt_thread_pool_context_reset (vctx=0x7) at thr_debug.c:1263 #4 0x080aad9f in slap_destroy () at init.c:271 #5 0x080670fb in main (argc=8, argv=0xbfffee84) at main.c:949 Configuration: CPPFLAGS='-DLDAP_REL_ENG -DLDAP_THREAD_DEBUG -DLDAP_RDWR_DEBUG' \ ./configure --prefix=/hbf/scratch/ldap/install/head \ --enable-crypt --enable-dynacl --enable-aci --enable-lmpasswd \ --enable-spasswd --enable-modules --enable-rlookups \ --enable-slapi --enable-slp --enable-wrappers \ --enable-backends --disable-sql --enable-overlays

1 0

(ITS#4911) slapadd uses slap_op_mutex uninitialized
by h.b.furuseth＠usit.uio.no 04 Apr '07

04 Apr '07

Full_Name: Hallvard B Furuseth Version: HEAD OS: Linux URL: Submission from: (NULL) (129.240.202.105) Submitted by: hallvard slapadd uses slap_op_mutex uninitialized in operation.c:slap_op_time() >>>>> Starting test049-sync-config ... running defines.sh == thr_debug: Leaked 1 mutexes. == Starting producer slapd on TCP/IP port 9011... thr_debug.c:432: ldap_pvt_thread_mutex_lock error: usage->magic is 0 ./scripts/test049-sync-config: line 47: 6207 Aborted (core dumped) $SLAPADD -F $CFPRO -n 0 -l $CONFLDIF Using ldapsearch to check that producer slapd is running... (gdb) backtrace ... #3 0x0818efbd in check_usage (usage=0x8253018, msg=0x6 "") at thr_debug.c:432 #4 0x08190779 in ldap_pvt_thread_mutex_lock (mutex=0x8253000) at thr_debug.c:978 #5 0x0809150e in slap_op_time (t=0xbfffd3a0, nop=0xbfffd3a4) at operation.c:125 #6 0x08080f54 in connection_fake_init2 (conn=0xbfffd548, op=0xbfffd398, ctx=0x8275160, newmem=0) at connection.c:2053 #7 0x08080db1 in connection_fake_init (conn=0x0, op=0x0, ctx=0x0) at connection.c:2000 #8 0x0806e870 in config_setup_ldif (be=0x82cb1e8, dir=0x8277008 "/usit/bombur/site/hbf/scratch/ldap/ldap/HEAD/tests/testrun/pro/slapd.d", readit=1) at bconfig.c:3451 #9 0x0806ec91 in read_config (fname=0x0, dir=0x8277008 "/usit/bombur/site/hbf/scratch/ldap/ldap/HEAD/tests/testrun/pro/slapd.d") at bconfig.c:3574 #10 0x080e04bc in slap_tool_init (progname=0x81cef70 "slapadd", tool=1, argc=10, argv=0xbfffee54) at slapcommon.c:510 #11 0x080de993 in slapadd (argc=0, argv=0x0) at slapadd.c:70 #12 0x08066142 in main (argc=10, argv=0xbfffee54) at main.c:645 (gdb) frame 3 #3 0x0818efbd in check_usage (usage=0x8253018, msg=0x6 "") at thr_debug.c:432 432 ERROR( usage->magic, msg ); (gdb) print *usage $2 = {magic = 0, self = 0, mem = {ptr = 0x0, num = 0}, state = 0} Configuration: CPPFLAGS='-DLDAP_REL_ENG -DLDAP_THREAD_DEBUG -DLDAP_RDWR_DEBUG' \ ./configure --prefix=/hbf/scratch/ldap/install/head \ --enable-crypt --enable-dynacl --enable-aci --enable-lmpasswd \ --enable-spasswd --enable-modules --enable-rlookups \ --enable-slapi --enable-slp --enable-wrappers \ --enable-backends --disable-sql --enable-overlays Any hope of making the tools and slapd go through the same init/destroy code in main(), maybe by making the server just another "tool"? Seems to me the only hope of making bugs like this keep popping up...

1 0

(ITS#4910) mirrormode prevents syncrepl engine from working
by ali.pouya＠free.fr 04 Apr '07

04 Apr '07

Full_Name: Ali Pouya Version: 2.4.4alpha OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.227.144.113) mirrormode is essential to my new directory project, so I resubmit this issue. I mounted two servers A and B with openldap 2.4.4alpha. If I set "mirrormode on" in the config file of B it does not receive any syncrepl data from A. If I comment out the line and restart slapd on B, then it receives all outstanding modifications done on A. I think that mirrormode prevents syncrepl engine from working. I can provide any information required. Best regards Ali

1 0

(ITS#4909
by ali.pouya＠free.fr 04 Apr '07

04 Apr '07

I would like to bring a precision for ITS 4909. Contrarily to what I wrote in the problem description , the replica DOES NOT upload the written data to the master. Best regards Ali

1 0

Re: (ITS#4907) Syncrepl consumer failing to perform deletes
by hyc＠symas.com 03 Apr '07

03 Apr '07

Sean Burford wrote: > Hi, > > On 4/2/07, *Howard Chu* <hyc(a)symas.com <mailto:hyc@symas.com>> wrote: > > > I am attempting to set up syncrepl between two OpenLDAP 2.3.32 > servers. Adds > > and Modifies are replicated from the provider to the consumer, > but deletes > > result in thousands of "unknown filter type 136644788" messages > in the consumer > > log and no deletion. Commenting out the syncprov-sessionlog > directive works > > around the issue. > > I don't see this with 2.3.32 on Linux 2.6.18. You'll probably need to > trace the activity with gdb to see what's wrong with the filter. > > > Right you are. The patch for ITS#4638 (rejected here: > http://www.openldap.org/lists/openldap-bugs/200608/msg00043.html) > introduced the bug. I'll send in a corrected patch once it has been QA'd. The log says that ITS#4638 was already fixed in 2.3.32. Why are you still using that particular patch, given that an alternate solution is already present in the release? I also see that in RE23 we had one more patch to fix some interaction between slapo-rwm and back-meta for filter processing. I suggest you test against the current RE23 code. I expect to push 2.3.35 out pretty soon. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#4907) Syncrepl consumer failing to perform deletes
by unix.gurus＠gmail.com 03 Apr '07

03 Apr '07

------=_Part_14849_31495008.1175634207921 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, On 4/2/07, Howard Chu <hyc(a)symas.com> wrote: > > > I am attempting to set up syncrepl between two OpenLDAP 2.3.32servers. Adds > > and Modifies are replicated from the provider to the consumer, but > deletes > > result in thousands of "unknown filter type 136644788" messages in the > consumer > > log and no deletion. Commenting out the syncprov-sessionlog directive > works > > around the issue. > > I don't see this with 2.3.32 on Linux 2.6.18. You'll probably need to > trace the activity with gdb to see what's wrong with the filter. Right you are. The patch for ITS#4638 (rejected here: http://www.openldap.org/lists/openldap-bugs/200608/msg00043.html) introduced the bug. I'll send in a corrected patch once it has been QA'd. -- Thanks, Sean Burford ------=_Part_14849_31495008.1175634207921 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi,<br><br><div><span class="gmail_quote">On 4/2/07, <b class="gmail_sendername">Howard Chu</b> <<a href="mailto:hyc@symas.com">hyc(a)symas.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> > I am attempting to set up syncrepl between two OpenLDAP 2.3.32 servers.  Adds<br>> and Modifies are replicated from the provider to the consumer, but deletes<br>> result in thousands of "unknown filter type 136644788" messages in the consumer <br>> log and no deletion.  Commenting out the syncprov-sessionlog directive works<br>> around the issue.<br><br>I don't see this with 2.3.32 on Linux 2.6.18. You'll probably need to<br>trace the activity with gdb to see what's wrong with the filter. </blockquote><div><br> Right you are.  The patch for ITS#4638 (rejected here: <a href="http://www.openldap.org/lists/openldap-bugs/200608/msg00043.html">http://www.openldap.org/lists/openldap-bugs/200608/msg00043.html</a>) introduced the bug.  I'll send in a corrected patch once it has been QA'd. <br><br></div></div>-- <br>Thanks,<br>Sean Burford ------=_Part_14849_31495008.1175634207921--

1 0

RE: (ITS#4908) bug ldapsearch.c
by Dale.Moore＠cs.cmu.edu 03 Apr '07

03 Apr '07

> The bug is still present. It is a consequence of naively assuming that > argv[] is NULL terminated, which is not required to be, AFAIK. My spec for ANSI C (ISO/IEC 9899:1990 (E)) says on section 5.1.2.2.1 (page 7) - argv[argc] shall be a null pointer. Maybe my C spec is a little out of date.

1 0

Re: (ITS#4908) bug ldapsearch.c
by h.b.furuseth＠usit.uio.no 03 Apr '07

03 Apr '07

ando(a)sys-net.it writes: > The bug is still present. It is a consequence of naively assuming that > argv[] is NULL terminated, which is not required to be, AFAIK. Yes it is. The C standard's "Program Startup" section requires argv[argc] == NULL. Though I suppose some systems may break it. And the standard does allow argc == 0 (and thus argv[0] == NULL), maybe some OpenLDAP code mishandles that. -- Regards, Hallvard

1 0

Re: (ITS#4908) bug ldapsearch.c
by ando＠sys-net.it 03 Apr '07

03 Apr '07

quanah(a)stanford.edu wrote: > --On Tuesday, April 03, 2007 3:01 PM +0000 buwalgui(a)etu.univ-rouen.fr wrote: > >> Full_Name: Guillaume BUWALDA >> Version: 2.2.3 >> OS: Linux ubuntu > > > The current released version of OpenLDAP is 2.3.34. OpenLDAP 2.2.x is a > historic release. As such, bugs against it will not be investigated. If > you can reproduce this issue with the current release, then please follow > up. The bug is still present. It is a consequence of naively assuming that argv[] is NULL terminated, which is not required to be, AFAIK. 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(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#4908) bug ldapsearch.c
by quanah＠stanford.edu 03 Apr '07

03 Apr '07

--On Tuesday, April 03, 2007 3:01 PM +0000 buwalgui(a)etu.univ-rouen.fr wrote: > Full_Name: Guillaume BUWALDA > Version: 2.2.3 > OS: Linux ubuntu The current released version of OpenLDAP is 2.3.34. OpenLDAP 2.2.x is a historic release. As such, bugs against it will not be investigated. If you can reproduce this issue with the current release, then please follow up. Regards, Quanah -- Quanah Gibson-Mount Senior Systems Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

1 0

(ITS#4908) bug ldapsearch.c
by buwalgui＠etu.univ-rouen.fr 03 Apr '07

03 Apr '07

Full_Name: Guillaume BUWALDA Version: 2.2.3 OS: Linux ubuntu URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (62.23.181.151) Hello, I do not know where I can send this message, so I send it to you... I found a little error in the source file client/tools/ldapsearch.c . gdb give me this bt: [Cacher les citations] Program received signal SIGSEGV, Segmentation fault. > 0xb7eb3c53 in strlen () from /lib/tls/i686/cmov/libc.so.6 (gdb) bt > #0 0xb7eb3c53 in strlen () from /lib/tls/i686/cmov/libc.so.6 > #1 0xb7e40031 in ber_put_string () from /usr/lib/liblber.so.2 > #2 0xb7e40321 in ber_printf () from /usr/lib/liblber.so.2 > #3 0xb7f8a376 in ldap_build_search_req () from /usr/lib/libldap_r.so.2 > #4 0xb7f8a7fe in ldap_search_ext () from /usr/lib/libldap_r.so.2 when it calls the function ldap_search_ext(). I think the error comes from then "attrs" parameters of this function. At line 611 of the file: > if ( argv[optind] != NULL ) { > attrs = &argv[optind]; > } You may put the last element of the array at NULL. I did this and it work. I hope this message will help you, and I'm sorry for my very bad english... lol Good Luck Guillaume BUWALDA

1 0

Re: (ITS#4879) URL parse/unparse troubles
by h.b.furuseth＠usit.uio.no 03 Apr '07

03 Apr '07

Howard Chu writes: >> The url.c Novell kludge does not work (for the example URL). >> If the bug is old and nobody has complained, maybe it should be >> removed. If it's fixed instead, note that the code looks like >> it'll handle Novell URLs with '/' in components after hostport: >> ldap_url_parse_ext() does strchr( url, '/' ) very early to find >> the end of the hostport. > > Hm, I think I see what you mean, but I don't see what to do about that. I think we can just replace strchr(,'/') with strpbrk(,"/?") or strcspn and take it from there. And require '?' in ldapi filenames to be URL-escaped, if they are not already. Thank you, much easier to see now the rest of the mess is cleaned up:-) >> Converting "%00" to char* should return an error, since the char* >> will not match the source URL: >> >> ldapi://a%00b/cn=d%00e -> host "a", DN "cn=d" -> >> ldapi://a/cn=d??base > > I've left this alone for now. We can make ldap_pvt_hex_unescape() return success/failure instead of void (and the output URL would be undefined). At the same time also reject bad %escapes - see that function's comment * FIXME: what if '%' is followed * by non-hexpair chars? >> ================ >> >> The RFCs 4516/2255 hostport part has grammar [host [":" port]], >> but ldap_url_desc2str() produces [host][":" port]. >> >> ldap:// -> host NULL, port 389 -> >> ldap://:389/??base >> >> That's OK as an ldap_url_parse() OpenLDAP extension, but not as >> ldap_url_desc2str() output given to non-OpenLDAP applications. > > This is a mess. The ldap: scheme definition has always been broken, and > it certainly does not conform to the basic URI syntax in RFC3986 section > 3. In particular, RFC3986 forbids a URI from containing "//" when the > authority component is absent. Would it help to produce ldap://0:389/? Helps the syntax, but I don't know if host 0 or 0.0.0.0 for INADDR_ANY is OK or just another unportable hack. > Looks like RFC4516 should not have been approved in its current state. I'd say RFCs2255 should not have been, but RFC4516 should since it was too late; it didn't introduce any new bugs. -- Regards, Hallvard

1 0

Re: (ITS#4907) Syncrepl consumer failing to perform deletes
by hyc＠symas.com 03 Apr '07

03 Apr '07

unix.gurus(a)gmail.com wrote: > Full_Name: Sean Burford > Version: 2.3.32 > OS: Linux 2.4.20 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (65.57.245.11) > > > I am attempting to set up syncrepl between two OpenLDAP 2.3.32 servers. Adds > and Modifies are replicated from the provider to the consumer, but deletes > result in thousands of "unknown filter type 136644788" messages in the consumer > log and no deletion. Commenting out the syncprov-sessionlog directive works > around the issue. I don't see this with 2.3.32 on Linux 2.6.18. You'll probably need to trace the activity with gdb to see what's wrong with the filter. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#4879) URL parse/unparse troubles
by hyc＠symas.com 03 Apr '07

03 Apr '07

h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: HEAD > OS: Linux > URL: > Submission from: (NULL) (129.240.202.105) > Submitted by: hallvard > > > Here are some URLs parsing/building bugs in libldap/url.c. > Some may be design bugs. Possibly some fixes will need backwards > bug-compatibility. > > I show URLs converted from string to LDAPURLDesc format with > ldap_url_parse(), back to string format with ldap_url_desc2str() > when the result differs from the original, back to LDAPURLDesc... > > ================ > > The url.c Novell kludge does not work (for the example URL). > If the bug is old and nobody has complained, maybe it should be > removed. If it's fixed instead, note that the code looks like > it'll handle Novell URLs with '/' in components after hostport: > ldap_url_parse_ext() does strchr( url, '/' ) very early to find > the end of the hostport. Hm, I think I see what you mean, but I don't see what to do about that. > ldap://111.222.333.444:389??cn=abc,o=company -> > error 5 (LDAP_URL_ERR_BADURL) This now works. > > Example URL without port number: > > ldap://111.222.333.444??cn=abc,o=company -> > host "111.222.333.444??cn=abc,o=company", DN NULL -> > ldap://111.222.333.444??cn=abc,o=company:389/??base This now works. > > ================ > > ldap_url_desc2str() outputs IPv6 host addresses as "addr" rather > than "[addr]". (LDAPURLDesc does not contain the '[]'s in > .lud_host, nor any flag which says it's an IPv6 host address). > > I don't know the syntax of such addresses, but I seem to remember > they contains ':'s. If so the parser could fail if an IPv6 > address does not contains ':', and the URL builder could test for > ':' to determine if there should be [] around the host part. This now works. > > Also, what does stuff between the ']' and ':port' mean? > Should anything be allowed there? > > ldap://[::1]what's this:222/ -> host "::1", port 222 -> This is now correctly rejected. > ldap://::1:222/??base -> error 5 (LDAP_URL_ERR_BADURL) > > ================ > > Converting "%00" to char* should return an error, since the char* > will not match the source URL: > > ldapi://a%00b/cn=d%00e -> host "a", DN "cn=d" -> > ldapi://a/cn=d??base I've left this alone for now. > ================ > > The RFCs 4516/2255 hostport part has grammar [host [":" port]], > but ldap_url_desc2str() produces [host][":" port]. > > ldap:// -> host NULL, port 389 -> > ldap://:389/??base > > That's OK as an ldap_url_parse() OpenLDAP extension, but not as > ldap_url_desc2str() output given to non-OpenLDAP applications. This is a mess. The ldap: scheme definition has always been broken, and it certainly does not conform to the basic URI syntax in RFC3986 section 3. In particular, RFC3986 forbids a URI from containing "//" when the authority component is absent. Looks like RFC4516 should not have been approved in its current state. > ================ > > While I'm writing, I wonder if OpenLDAP 2.4 could omit defaults > and final "?"s from the ldap_url_desc2str() output. E.g. ldap:// > would become ldap:// and not ldap://:389/??base. But maybe we get > into trouble if ldap.conf has another port or something. I thought about changing this, but left it alone for now. Agreed, the interaction with ldap.conf isn't clear. > ================ > > ldapi URL (un)parsing has several problems: > > ldap_url_parse() always treats ':' as a host:port separator. > Thus one can produce an ldapi LDAPURLDesc with a meaningless port. > However ldap_url_desc2str() does not URL-escape ':', and it also > takes port!=0 to mean it is not an ldapi URL and needs no > '/'-escaping. Similarly filenames with initial '[' do not work. > > ldapi://%2Ftmp%2Ffoo%3A222/ -> host "/tmp/foo:222" (correct) -> > ldapi://%2Ftmp%2Ffoo:222/??base -> host "/tmp/foo", port 222 -> > ldapi:///tmp/foo:222/??base -> host NULL, DN "tmp/foo:222/" > > ldapi://%2Ftmp%2Ffoo:000/ -> host "/tmp/foo" -> > ldapi://%2Ftmp%2Ffoo/??base > > ldapi://%2Ftmp%2Ffoo:bar/ -> error 5 (LDAP_URL_ERR_BADURL) These are all fixed. Note that the "ldapi:///tmp/foo:222/" case simply means an ldapi:// URL with a DN of "tmp/foo:222/" which is legal in a URL parsing sense, even though DN validation would reject it. > > ==== > > The current implementation would handle some non-Unix ldapi > filenames wrong. (They'll need well-defined URL-escaping rules > if they get implemented, so it might as well be fixed now.) Of > course these can also be strange Unix relative filenames... > > Windows-like filenames: > > ldapi://C%3A%2Fldapi/ -> host "C:/ldapi" -> > ldapi://C:%2Fldapi/??base -> error 5 (LDAP_URL_ERR_BADURL) > > Tops-20-like filenames resemble IPv6 addresses (not that I expect > to port OpenLDAP to Tops-20:-) > > ldapi://[ldap.var.run]ldapi/ -> host "ldap.var.run" -> > ldapi://ldap.var.run/??base > > URL-escaping the '[' and ']' does not help; the '[' is lost: > > ldapi://%5Bldap.var.run%5Dldapi/ -> host "ldap.var.run]ldapi" -> > ldapi://ldap.var.run%5Dldapi/??base > These are all fixed. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#4907) Syncrepl consumer failing to perform deletes
by unix.gurus＠gmail.com 03 Apr '07

03 Apr '07

Full_Name: Sean Burford Version: 2.3.32 OS: Linux 2.4.20 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (65.57.245.11) I am attempting to set up syncrepl between two OpenLDAP 2.3.32 servers. Adds and Modifies are replicated from the provider to the consumer, but deletes result in thousands of "unknown filter type 136644788" messages in the consumer log and no deletion. Commenting out the syncprov-sessionlog directive works around the issue. The search that the syncrepl consumer does, when presented with a delete from the syncprov log, seems to be poorly formed or corrupted. Overflowing the syncprov-sessionlog between consumer polls prevents this behaviour. Provider config: overlay syncprov syncprov-checkpoint 100 10 # Values 1 and 100 tested for syncprov-sessionlog. # Both have same symptoms. syncprov-sessionlog 1 Consumer config: syncrepl rid=007 provider=ldaps://ldaptest-master.SITE:636 type=refreshOnly interval=00:00:00:10 searchbase="XXX" filter="(objectClass=*)" scope=sub # Different attrs values do not affect this issue attrs="*,+" schemachecking=off # Different bind methods do not affect this issue bindmethod=sasl saslmech=GSSAPI updateref ldap://ldaptest-master.SITE:389 With "loglevel stats sync" on the consumer, syslog logs this: Apr 2 13:18:16 slapd[964]: do_syncrep2: rid 007 LDAP_RES_SEARCH_RESULT Apr 2 13:18:26 slapd[964]: do_syncrep2: rid 007 LDAP_RES_SEARCH_RESULT Apr 2 13:18:36 slapd[964]: do_syncrep2: rid 007 LDAP_RES_SEARCH_RESULT Apr 2 13:18:46 slapd[964]: do_syncrep2: rid 007 LDAP_RES_INTERMEDIATE - SYNC_ID_SET Apr 2 13:18:46 slapd[964]: unknown filter type 136644788 Apr 2 13:18:46 slapd[964]: unknown filter type 136644788 Apr 2 13:18:46 slapd[964]: unknown filter type 136644788 Apr 2 13:18:46 slapd[964]: unknown filter type 136644788 ... Running slapd with -d1 on the consumer produces the following debug output. You can see the intermediate result getting parsed (it contains the refreshdeletes flag then a set of (one) UUIDs to delete). The backend is then searched for the UUID, but each entry in the backend generates an unknown filter type message: ... read1msg: ld 0x8814ea0 msgid 2 message type intermediate ber_scanf fmt ({eaa) ber: ldap_parse_intermediate ber_scanf fmt ({) ber: ber_scanf fmt (a) ber: ber_scanf fmt (O) ber: ber_scanf fmt (t{) ber: ber_scanf fmt (m) ber: ber_scanf fmt (b) ber: ber_scanf fmt ([W]) ber: ber_scanf fmt (}) ber: => bdb_search bdb_dn2entry("dc=XXX") search_candidates: base="dc=XXX" (0x00000001) scope=2 => bdb_dn2idl("dc=XXX") bdb_search_candidates: id=-1 first=1 last=203912 unknown filter type 136644788 bdb_search: 1 does not match filter entry_decode: "ou=YYY,XXX" <= entry_decode(ou=YYY,XXX) => bdb_dn2id("ou=YYY,XXX") <= bdb_dn2id: got id=0x00000002 unknown filter type 136644788 bdb_search: 2 does not match filter ... entry_decode: "uid=ZZZ,YYY" <= entry_decode(uid=ZZZ,YYY) unknown filter type 136644788 bdb_search: 203912 does not match filter send_ldap_result: conn=-1 op=0 p=3 ldap_msgfree ldap_result ld 0x8814ea0 msgid -1 ldap_chkResponseList ld 0x8814ea0 msgid -1 all 0 ldap_chkResponseList returns ld 0x8814ea0 NULL wait4msg ld 0x8814ea0 msgid -1 (infinite timeout) wait4msg continue ld 0x8814ea0 msgid -1 all 0 136644788 (0x82508B4) is not consistent across runs, it appears to be an address in the JCR rather than a valid filter type. The delete message content looks OK: 0040 30 68 02 01 02 79 63 80 18 31 2e 33 2e 36 0h...y c..1.3.6 | | | | +---------------syncoid.syncinfo | | | +---------------------req oid (len 0x18) | | +-----------------------length 0x63 | +---------------------------result intermediate +-------------------------------------message ID 2 0050 2e 31 2e 34 2e 31 2e 34 32 30 33 2e 31 2e 39 2e .1.4.1.4 203.1.9. 0060 31 2e 34 81 47 a3 45 04 2c 63 73 6e 3d 32 30 30 1.4.G.E. ,csn=200 | | | +---------------------CSN,RID (cookie) | | +----------------------------sync cookie (len 0x2c) | +----------------------------------SYNC_ID_SET (len 0x45) +----------------------------------------req value (len 0x47) 0070 37 30 34 30 32 32 30 34 38 32 33 5a 23 30 30 30 70402204 823Z#000 0080 30 30 30 23 30 30 23 30 30 30 30 30 30 2c 72 69 000#00#0 00000,ri 0090 64 3d 30 30 37 01 01 ff 31 12 04 10 48 4a 1b 88 d=007... 1...HJ.. | | | +------------UUID (remainder of packet) | | +------------------octetstring (len 0x10) | +------------------------lber set (len 0x12) +----------------------------------refreshdeletes(bool:FF) 00a0 75 a6 10 2b 8c 79 83 6d 14 6d 34 77 Backend: bdb 4.4.20

1 0

Re: (ITS#4881) ldapsearch, SSL and segmentation fault
by hyc＠symas.com 03 Apr '07

03 Apr '07

andrej.groups(a)gmail.com wrote: > Full_Name: Andrej Ricnik > Version: ldapsearch 2.3.21 > OS: Slackware 11 > URL: > Submission from: (NULL) (138.235.105.2) > > > I'm trying to use ldapsearch against Novell eDir 8.7.3.9 (on Solaris) which > works fine when used w/o encryption. If I use the self-signed Cert created on > the eDir server ldapsearch segfaults. > > This works fine (returns the expected 46 DNs): > ldapsearch -D cn=wpsbind,ou=wcm,ou=systemusers,ou=users,o=myorg -W -h > dev4.kdc.myorg.org -x -s sub -LLL '(cn=*)' > > This one segfaults after the 45th DN: > ldapsearch -ZZ -D cn=wpsbind,ou=wcm,ou=systemusers,ou=users,o=myorg -W -h > dev4.kdc.myorg.org -x -s sub -LLL '(cn=*)' > > It looks similar to ITN# 889 ... Not likely, since that involved SASL and this does not. There's not enough info here. Please provide a stack trace of the crash in the client. Also see the FAQ http://www.openldap.org/faq/index.cgi?file=59 -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: slapd+pcache keeps crashing on FreeBSD 6.2 (ITS#4841)
by hyc＠symas.com 02 Apr '07

02 Apr '07

imriz(a)co.zahav.net.il wrote: > Sure. New core dumps and binary file is at > http://mariska.inter.net.il/~imriz/slapd-core.tar.gz The slapd in this snapshot was stripped so no debug symbols are present. Please be sure to use an unstripped binary. Also, since you're also loading libldap_r, liblber, back-ldap, back-bdb, back-meta, and back-ldbm dynamically, you'll need to include those modules in the tarball. (Also with debug and unstripped.) Although at this point I'm wondering why you're using back-ldbm, which has been deprecated for quite a long time. > Please notice that the previous dump was from FreeBSD ports (OpenLDAP > version 2.3.33). > > This one was fetched from the CVS (OPENLDAP_REL_ENG_2_3), with the > following configure options: > > ./configure --with-threads=posix --with-tls=openssl --enable-dynamic > --without-cyrus-sasl --enable-modules --localstatedir=/var/ > db --enable-ldbm=mod --enable-crypt --enable-lmpasswd --enable-ldap=mod > --enable-meta=mod --enable-rewrite --enable-null=mod --enabl > e-monitor=mod --enable-proxycache --disable-syncprov --enable-bdb=mod > --enable-hdb=mod --enable-dbm-api=berkeley --disable-slurpd -- > prefix=/usr/local --enable-debug > > > -----Original Message----- > From: Howard Chu [mailto:openldap-its@OpenLDAP.org] > Sent: Tuesday, February 13, 2007 1:14 AM > To: Imri Zvik > Subject: Re: slapd+pcache keeps crashing on FreeBSD 6.2 (ITS#4841) > > It looks like this core is from a binary without debug symbols present, > can you > recompile with debugging enabled and get a new stack trace and core > file? > > > . > -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs