openldap-bugs

openldap-bugs@openldap.org

1 participants
21001 discussions

Re: (ITS#7227) Problem to add new entry
by quanah＠zimbra.com 06 Apr '12

06 Apr '12

--On Friday, April 06, 2012 5:20 AM +0000 rai.abhishek(a)yahoo.com wrote: Stop filing ITSes because you don't know how to use the software. Again, subscribe to the openldap-technical(a)openldap.org mailing list, and ask your questions there. All of your ITSes will be ignored unless they are reporting an actual problem. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#7232) Searching for Deleted Objects
by rai.abhishek＠yahoo.com 06 Apr '12

06 Apr '12

Full_Name: Abhishek Rai Version: V3 OS: windows server 2008 r2 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (121.245.33.179) Hi All i am try to developed a small c# application through which i want to get all deleted objects information from OpenLDAP.i am using SQL db as a back-end at the time of set up the OpenLDAP server.i am enable to search deleted entity information (person,group etc) from openldap.as per my finding i am enable to find any procedure or trigger in OpenLDAP database. so please suggest me how can i get this information from OpenLDAP. thanks Abhishek

1 0

Re: (ITS#7224) Core dump while trying to run slapd
by ashish＠sendmail.com 06 Apr '12

06 Apr '12

On 4/6/2012 10:22 AM, Howard Chu wrote: > > Find out why oc->oc_names is NULL. It should not be. Seems like you > have an invalid schema definition. > I have fixed the objectClasses that were violating by adding "extensibleObject". Also, the slapadd-ing should not "core", and give the right error message.

1 0

Re: (ITS#7224) Core dump while trying to run slapd
by hyc＠symas.com 06 Apr '12

06 Apr '12

ashish(a)sendmail.com wrote: > Same place when I am trying to slapadd. Find out why oc->oc_names is NULL. It should not be. Seems like you have an invalid schema definition. > [root@qa-perf13 ~]# gdb /usr/local/sendmail/smd/sbin/slapadd > GNU gdb (GDB) Red Hat Enterprise Linux (7.0.1-42.el5) > Copyright (C) 2009 Free Software Foundation, Inc. > License GPLv3+: GNU GPL version 3 or later > <http://gnu.org/licenses/gpl.html> > This is free software: you are free to change and redistribute it. > There is NO WARRANTY, to the extent permitted by law. Type "show copying" > and "show warranty" for details. > This GDB was configured as "x86_64-redhat-linux-gnu". > For bug reporting instructions, please see: > <http://www.gnu.org/software/gdb/bugs/>... > Reading symbols from /usr/local/sendmail/smd-5.0/sbin/slapadd...done. > (gdb) core /var/core/core.slapadd.3064.11 > [New Thread 3064] > Reading symbols from /lib64/libdl.so.2...(no debugging symbols > found)...done. > Loaded symbols for /lib64/libdl.so.2 > Reading symbols from /lib64/libcrypt.so.1...(no debugging symbols > found)...done. > Loaded symbols for /lib64/libcrypt.so.1 > Reading symbols from /lib64/libresolv.so.2...(no debugging symbols > found)...done. > Loaded symbols for /lib64/libresolv.so.2 > Reading symbols from /lib64/libpthread.so.0...(no debugging symbols > found)...done. > [Thread debugging using libthread_db enabled] > Loaded symbols for /lib64/libpthread.so.0 > Reading symbols from /lib64/libc.so.6...(no debugging symbols found)...done. > Loaded symbols for /lib64/libc.so.6 > Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging symbols > found)...done. > Loaded symbols for /lib64/ld-linux-x86-64.so.2 > warning: no loadable sections found in added symbol-file system-supplied > DSO at 0x7fff4d324000 > Core was generated by `/usr/local/sendmail/smd/sbin/slapadd -l > newldif.new.new.6 -w -c'. > Program terminated with signal 11, Segmentation fault. > #0 oc_delete_names (oc=0x1bbbf6f0) at oc.c:403 > 403 oc.c: No such file or directory. > in oc.c > (gdb) where > #0 oc_delete_names (oc=0x1bbbf6f0) at oc.c:403 > #1 0x0000000000461aa7 in oc_destroy () at oc.c:470 > #2 0x000000000045128e in schema_destroy () at schema_init.c:6846 > #3 0x0000000000486ecd in slap_tool_destroy () at slapcommon.c:942 > #4 0x0000000000485f73 in slapadd (argc=<value optimized out>, > argv=<value optimized out>) at slapadd.c:493 > #5 0x0000000000404f32 in main (argc=5, argv=0x7fff4d2c1cf8) at main.c:410 > (gdb) p * names > Cannot access memory at address 0x0 > (gdb) p names > $1 = (char **) 0x0 > (gdb) p *oc > $2 = {soc_oclass = {oc_oid = 0x1bbbf370 "1.3.6.1.4.1.6152.10.3.2.16", > oc_names = 0x0, oc_desc = 0x0, oc_obsolete = 0, oc_sup_oids = 0x0, > oc_kind = 1, oc_at_oids_must = 0x0, oc_at_oids_may = 0x0, oc_extensions > = 0x0}, soc_cname = { > bv_len = 26, bv_val = 0x1bbbf370 "1.3.6.1.4.1.6152.10.3.2.16"}, > soc_sups = 0x1bbbf3a0, soc_required = 0x1bbbf3c0, soc_allowed = 0x0, > soc_check = 0, soc_oidmacro = 0x0, soc_flags = 0, soc_next = {stqe_next > = 0x1bbc0fd0}} > (gdb) p oc > $3 = (ObjectClass *) 0x1bbbf6f0 > > > -- -- Howard Chu CTO, 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#7224) Core dump while trying to run slapd
by ashish＠sendmail.com 06 Apr '12

06 Apr '12

Errors like this are logged while slapadd-ing: 4f7e23f3 bdb(): PANIC: fatal region error detected; run recovery 4f7e23f3 => hdb_tool_entry_put: txn_commit failed: DB_RUNRECOVERY: Fatal error, run database recovery (-30974) slapadd: could not add entry dn="sendmailMTAKey=69261@imcnamxe.ssmb.com,sendmailMTAMapName=emailtopnl,sendmailMTACluster=qqq,dc=maps,dc=repo" (line=3980378): txn_commit failed: DB_RUNRECOVERY: Fatal error, run database recovery (-30974) 4f7e23f3 bdb(): PANIC: fatal region error detected; run recovery 4f7e23f3 => hdb_tool_entry_put: txn_begin failed: DB_RUNRECOVERY: Fatal error, run database recovery (-30974) slapadd: could not add entry dn="sendmailMTAKey=69262@imcnamxe.ssmb.com,sendmailMTAMapName=emailtopnl,sendmailMTACluster=qqq,dc=maps,dc=repo" (line=3980389): txn_begin failed: DB_RUNRECOVERY: Fatal error, run database recovery (-30974) 4f7e23f3 bdb(): PANIC: fatal region error detected; run recovery

1 0

Re: (ITS#7224) Core dump while trying to run slapd
by ashish＠sendmail.com 06 Apr '12

06 Apr '12

Same place when I am trying to slapadd. [root@qa-perf13 ~]# gdb /usr/local/sendmail/smd/sbin/slapadd GNU gdb (GDB) Red Hat Enterprise Linux (7.0.1-42.el5) Copyright (C) 2009 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-redhat-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from /usr/local/sendmail/smd-5.0/sbin/slapadd...done. (gdb) core /var/core/core.slapadd.3064.11 [New Thread 3064] Reading symbols from /lib64/libdl.so.2...(no debugging symbols found)...done. Loaded symbols for /lib64/libdl.so.2 Reading symbols from /lib64/libcrypt.so.1...(no debugging symbols found)...done. Loaded symbols for /lib64/libcrypt.so.1 Reading symbols from /lib64/libresolv.so.2...(no debugging symbols found)...done. Loaded symbols for /lib64/libresolv.so.2 Reading symbols from /lib64/libpthread.so.0...(no debugging symbols found)...done. [Thread debugging using libthread_db enabled] Loaded symbols for /lib64/libpthread.so.0 Reading symbols from /lib64/libc.so.6...(no debugging symbols found)...done. Loaded symbols for /lib64/libc.so.6 Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging symbols found)...done. Loaded symbols for /lib64/ld-linux-x86-64.so.2 warning: no loadable sections found in added symbol-file system-supplied DSO at 0x7fff4d324000 Core was generated by `/usr/local/sendmail/smd/sbin/slapadd -l newldif.new.new.6 -w -c'. Program terminated with signal 11, Segmentation fault. #0 oc_delete_names (oc=0x1bbbf6f0) at oc.c:403 403 oc.c: No such file or directory. in oc.c (gdb) where #0 oc_delete_names (oc=0x1bbbf6f0) at oc.c:403 #1 0x0000000000461aa7 in oc_destroy () at oc.c:470 #2 0x000000000045128e in schema_destroy () at schema_init.c:6846 #3 0x0000000000486ecd in slap_tool_destroy () at slapcommon.c:942 #4 0x0000000000485f73 in slapadd (argc=<value optimized out>, argv=<value optimized out>) at slapadd.c:493 #5 0x0000000000404f32 in main (argc=5, argv=0x7fff4d2c1cf8) at main.c:410 (gdb) p * names Cannot access memory at address 0x0 (gdb) p names $1 = (char **) 0x0 (gdb) p *oc $2 = {soc_oclass = {oc_oid = 0x1bbbf370 "1.3.6.1.4.1.6152.10.3.2.16", oc_names = 0x0, oc_desc = 0x0, oc_obsolete = 0, oc_sup_oids = 0x0, oc_kind = 1, oc_at_oids_must = 0x0, oc_at_oids_may = 0x0, oc_extensions = 0x0}, soc_cname = { bv_len = 26, bv_val = 0x1bbbf370 "1.3.6.1.4.1.6152.10.3.2.16"}, soc_sups = 0x1bbbf3a0, soc_required = 0x1bbbf3c0, soc_allowed = 0x0, soc_check = 0, soc_oidmacro = 0x0, soc_flags = 0, soc_next = {stqe_next = 0x1bbc0fd0}} (gdb) p oc $3 = (ObjectClass *) 0x1bbbf6f0

1 0

Re: (ITS#7226) olcAuditlogFile At dos not accept multiple values
by hyc＠symas.com 06 Apr '12

06 Apr '12

quanah(a)zimbra.com wrote: > --On Thursday, April 05, 2012 7:38 PM +0000 h.b.furuseth(a)usit.uio.no wrote: > >> On Thu, 5 Apr 2012 13:12:31 GMT, michael(a)stroeder.com wrote: >>> hyc(a)symas.com wrote: >>>> michael(a)stroeder.com wrote: >>>>> 2. add an equality matching rule. >>>> >>>> My approach with config attrs has been to skip the equality rule for >>>> single-valued attrs. Since they are single-valued, there's obviously >>>> no need >>>> to allow for comparing multiple values. >> >> Users always find more ways to use a feature than its creator imagined. >> >> I wish people would give attributes all matching rules they can. >> Equality, ordering, substring. Except when: >> - flexibility would be a misfeature, e.g. SUBSTR for userPassword, >> - or it's unclear which rules to choose, e.g. caseIgnore vs caseExact. > > I agree. I think defining matching rules where possible is extremely > useful. Patch welcome. This is a pretty trivial patch to write, but I have more urgent things to attend to. -- -- Howard Chu CTO, 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#6656) logging "reqEntryUUID" in accesslog
by michael＠stroeder.com 06 Apr '12

06 Apr '12

This is a cryptographically signed message in MIME format. --------------ms030508030008000509010204 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Please revisit this ITS. I'd like to implement something like "svn revert= " based on accesslog entries. Having the entry's UUID in an indexable attri= bute would make this more robust. This could also be handy for delta-replication if "conflicting" modrdn requests were sent by a client which result in same reqDN. Ciao, Michael. --------------ms030508030008000509010204 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFOzCC BTcwggMfoAMCAQICAwl4kDANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4w HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMDEx MTcxNTQzMzFaFw0xMjExMTYxNTQzMzFaMD8xGDAWBgNVBAMUD01pY2hhZWwgU3Ry9mRlcjEj MCEGCSqGSIb3DQEJARYUbWljaGFlbEBzdHJvZWRlci5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDo2SKth5GhtaDrCyfGtyUG+/hAAa/J52L0NFN4SSRvTtdGf9HfWwwd NCtgae0TVGWk2lKDbXA9d5vmyIiRhuwxd90H6FLErhRBeB9G67qtw87E8WUoXt2DwPQEUTWV hqHpPadlmgFw3+i3TGQQTe3O3W9MMMd4GJNhObem2VGRuCD37OXnzBksTcq0FPJgcWAhe3d/ 0ItOkNWBqgq8Mf3p7WFBhaQ0a27BC/mKtH8fI3kPcS305imPRja69Msq3EwUZBc9ToVp6FRQ NYKjfOBybDUzVkmRZl3H8xutQP2w8Zxb8m5f7Q1BfLLrIFScfYvIDgOERxTCd4lab8+/09XH AgMBAAGjggEAMIH9MAwGA1UdEwEB/wQCMAAwVgYJYIZIAYb4QgENBEkWR1RvIGdldCB5b3Vy IG93biBjZXJ0aWZpY2F0ZSBmb3IgRlJFRSBoZWFkIG92ZXIgdG8gaHR0cDovL3d3dy5DQWNl cnQub3JnMEAGA1UdJQQ5MDcGCCsGAQUFBwMEBggrBgEFBQcDAgYKKwYBBAGCNwoDBAYKKwYB BAGCNwoDAwYJYIZIAYb4QgQBMDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcwAYYWaHR0cDov L29jc3AuY2FjZXJ0Lm9yZzAfBgNVHREEGDAWgRRtaWNoYWVsQHN0cm9lZGVyLmNvbTANBgkq hkiG9w0BAQUFAAOCAgEANPf/aLF41eQlvN5dEg3CFnlN//qQK7+EPIXLnHprNWLb4nBwgdPj /E+qa1umT7px4Py3VS0UTKqLmMdWftwid8MOMHWalZwrfx0Z8U3He+EdJhOSnn9vdd/ug7Xd dI/hRjLaBSq9ZhCczEUgL6vTxCYPlIoHF56y/oxSJw59vRBjvRFKXvpBZWseeRkcGACQduNH SNdWC1IqHAbQlgOS9VWQUYlm//BdaLkezRxqnQp5+KJMAcZzHpdNJ3G4SqCJ02Z3n4kk8IKZ AjgiWxisDFNsfXKDb9Ng5ntnnH2ouxrgPoNnW445tgkz50VKHstylx9s5O3G7uUTtg0J+z63 TA8xbN6kzRx7RgAUkEXhl6WEdW+3EVj5tYY38Uy8vleP+gYZfphKEmQJgIQqy9D2+gesbolT QdWYgbUYY2AHJOshskMW7pahYnFX2pZmn/ayaPc+JFJlCEqO0+DcYQjYuv6sntQgZGkok7yZ R4xMbyCp61pTrfGWOufZs/FiScJZg1IWY5qb4URH4VZZjLNMR2pFMRuE4LvgkkMRasbUv7Yv n3Lzv34lTfJKUqYW6nx//L2NS4rN63o0taPwRygnuBK4kp7EYEcwtLeanJhQoIu4b6If9rwy D7CFAp51wIewV9VtZ1Is0irNBcMVyhJogIcuIn+VWY1ff1RxySD/djMxggOUMIIDkAIBATCB gDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcx IjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1 cHBvcnRAY2FjZXJ0Lm9yZwIDCXiQMAkGBSsOAwIaBQCgggHoMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDQwNjA5NDgyNVowIwYJKoZIhvcNAQkEMRYE FEygunV2ggv0vvJFXsDT6osh9+aiMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoG CCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggq hkiG9w0DAgIBKDCBkQYJKwYBBAGCNxAEMYGDMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAc BgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5n IEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMJeJAwgZMG CyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6 Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEh MB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMJeJAwDQYJKoZIhvcNAQEBBQAE ggEAd3aWU7Cwit2Su125+MLAv0K6Ar9XJF9Uhm+X68eeerTXodk1MKIG9JX7PsdFrQyAX3KE R1PjeWVfQvUnVMlutKSem29k6q6pd+iATl+bSB3PgJXWyPKk2K3S2gAGPmL8vubRwEfoCCqt OJBAxseomsPbO1310vSt1KsJYxnLYIQIsBuY0mGWmNcwYCnLitW3erW1ipvancsxwVI4Uy4D EiwtVrP75c1f20VRdiUA5dCeBfi2f18bsyUyaLTccC7vHCMkwSx4VXJk8rEyYB74UpHM/Zbv a5tNipz5K3YDkSJbRhB+Qma2+hMSzvFhbq1XwI6HBladZ8hDmqOYZqGBhwAAAAAAAA== --------------ms030508030008000509010204--

1 0

Re: (ITS#7227) Problem to add new entry
by rai.abhishek＠yahoo.com 05 Apr '12

05 Apr '12

--1454997657-1528916171-1333689558=:73347 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi All=0A=0AI am using OpenLDAP server and use .net application as a client= but face issue regarding add new entry like (Country and Organization etc)= . the error message are =0A=0AAn error occurred while creating entry.=0AThe= server is not willing to handle directory requests.=0A=0Abut with the same= setting and access rights=A0i am able to create some entry like (Person,Gr= oup,Organizational Unit) i am new for OpenLDAP but as per my understanding = it's a access problem in slapd.conf file.=0A=0Afor safe point i am modifyed= the slapd.conf file and provide below access slapd.conf =0Aaccess to * by= * write=0A=A0=0Ato achieve this operation.=0A=A0=0APlease suggest what acc= ess rights need to provide or what changes need to done to resolve this pro= blem.=0A=A0=0AI am waiting for your replay.=0A=0A=0A=0A=0AThanks & Regards= =0AAbhishek Rai=0AHCL Technolog=0A =0A=0A________________________________= =0A From: Quanah Gibson-Mount <quanah(a)zimbra.com>=0ATo: rai.abhishek(a)yahoo.= com; openldap-its(a)openldap.org =0ASent: Friday, April 6, 2012 12:54 AM=0ASu= bject: Re: (ITS#7227) Problem to add new entry=0A =0A--On Thursday, April = 05, 2012 12:38 PM +0000 rai.abhishek(a)yahoo.com wrote:=0A=0A> Full_Name: Abh= ishek Rai=0A> Version: 3=0A> OS: Windows Server 2008 R2=0A> URL: ftp://ftp.= openldap.org/incoming/=0A> Submission from: (NULL) (207.46.55.29)=0A=0ATHe = ITS system is for reporting bugs, not asking usage questions.=A0 I suggest = you subscribe to the openldap-technical(a)openldap.org list, and ask your usa= ge questions there.=0A=0AThis ITS will be closed.=0A=0A--Quanah=0A=0A=0A--= =0A=0AQuanah Gibson-Mount=0ASr. Member of Technical Staff=0AZimbra, Inc=0AA= Division of VMware, Inc.=0A--------------------=0AZimbra ::=A0 the leader = in open source messaging and collaboration --1454997657-1528916171-1333689558=:73347 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable <html><body><div style=3D"color:#000; background-color:#fff; font-family:ve= rdana, helvetica, sans-serif;font-size:12pt"><div><span>Hi All<br><br>I am = using OpenLDAP server and use .net application as a client but face issue r= egarding add new entry like (Country and Organization etc). the error messa= ge are <br><br>An error occurred while creating entry.<br>The server is not= willing to handle directory requests.<br><br>but with the same setting and= access rights i am able to create some entry like (Person,Group,Organ= izational Unit) i am new for OpenLDAP but as per my understanding it's a ac= cess problem in slapd.conf file.<br><br>for safe point i am modifyed the sl= apd.conf file and provide below access slapd.conf <br>access to * by * wri= te</span></div><div><span></span> </div><div><span>to achieve this ope= ration.</span></div><div><span></span> </div><div><span>Please suggest= what access rights need to provide or what changes need to done to resolve this problem.</span></div><div><span></span> </div><div><span= >I am waiting for your replay.</div><div><br><br><br></div></span><div></di= v><div> </div><div>Thanks & Regards<br>Abhishek Rai<br>HCL Technol= og<br></div> <div style=3D"font-family: verdana, helvetica, sans-serif; fo= nt-size: 12pt;"> <div style=3D"font-family: times new roman, new york, time= s, serif; font-size: 12pt;"> <div dir=3D"ltr"> <font size=3D"2" face=3D"Ari= al"> <div style=3D"margin: 5px 0px; padding: 0px; border: 1px solid rgb(204= , 204, 204); height: 0px; line-height: 0; font-size: 0px;" class=3D"hr" con= tentEditable=3D"false" readonly=3D"true"></div> <b><span style=3D"font-wei= ght: bold;">From:</span></b> Quanah Gibson-Mount <quanah(a)zimbra.com><= br> <b><span style=3D"font-weight: bold;">To:</span></b> rai.abhishek@yahoo= .com; openldap-its(a)openldap.org <br> <b><span style=3D"font-weight: bold;">= Sent:</span></b> Friday, April 6, 2012 12:54 AM<br> <b><span style=3D"font-= weight: bold;">Subject:</span></b> Re: (ITS#7227) Problem to add new entry<br> </f= ont> </div> <br>=0A--On Thursday, April 05, 2012 12:38 PM +0000 <a href=3D"= mailto:rai.abhishek@yahoo.com" ymailto=3D"mailto:rai.abhishek@yahoo.com">ra= i.abhishek(a)yahoo.com</a> wrote:<br><br>> Full_Name: Abhishek Rai<br>>= Version: 3<br>> OS: Windows Server 2008 R2<br>> URL: <a href=3D"ftp:= //ftp.openldap.org/incoming/" target=3D"_blank">ftp://ftp.openldap.org/inco= ming/</a><br>> Submission from: (NULL) (207.46.55.29)<br><br>THe ITS sys= tem is for reporting bugs, not asking usage questions.  I suggest you = subscribe to the <a href=3D"mailto:openldap-technical@openldap.org" ymailto= =3D"mailto:openldap-technical@openldap.org">openldap-technical(a)openldap.org= </a> list, and ask your usage questions there.<br><br>This ITS will be clos= ed.<br><br>--Quanah<br><br><br>--<br><br>Quanah Gibson-Mount<br>Sr. Member = of Technical Staff<br>Zimbra, Inc<br>A Division of VMware, Inc.<br>--------= ------------<br>Zimbra ::  the leader in open source messaging and col= laboration<br><br><br> </div> </div> </div></body></html> --1454997657-1528916171-1333689558=:73347--

1 0

(ITS#7231) back0hdb search results disappear depending on search base
by hume-ol＠bofh.ca 05 Apr '12

05 Apr '12

Full_Name: Brandon Hume Version: -OPENLDAP_REL_ENG_2_4-0e03b13 OS: Redhat AS6 URL: http://den.bofh.ca/~hume/ldap_missing_results.tar.gz Submission from: (NULL) (2610:170:2c00:7:224:1ff:fed4:b4ff) Firstly, using RE24 built with the following ./configure: #!/bin/sh env CC=gcc CFLAGS="-m64 -ggdb" LDFLAGS="-Wl,-rpath -Wl,/appl/ldap/lib -L/appl/ldap/lib" CPPFLAGS="-I/appl/ldap/include" \ ./configure --prefix=/appl/ldap \ --libexecdir=/appl/ldap/sbin --localstatedir=/var/run --datadir=/appl/ldap/data \ --sysconfdir=/appl/ldap/etc --mandir=/appl/ldap/man --with-subdir=no \ --disable-rlookups --with-tls=openssl \ --enable-slapd --enable-crypt --with-cyrus-sasl=no --enable-debug \ --enable-dynamic --enable-modules \ --enable-backends=mod --enable-overlays=mod --enable-sql=no \ --enable-perl=no --enable-ndb=no --enable-shell=no Paired with BerkeleyDB built with the following: #!/bin/sh env CC=gcc CFLAGS="-m64 -ggdb" LDFLAGS="-Wl,-rpath -Wl,/appl/ldap/lib -L/appl/ldap/lib" CPPFLAGS="-I/appl/ldap/include" \ ../dist/configure --prefix=/appl/ldap DIT has 131207 entries. Search results will come and go as you shorten the search base. For example, when searching for "maillocaladdress=vbroken(a)dal.ca", which has the full DN of "cn=broken129251,cn=dal,cn=Mailmaps,cn=Services,dc=DAL,dc=CA", the following will occur: Searching with base=cn=dal,cn=Mailmaps,cn=services,dc=dal,dc=ca: Found. Searching with base=cn=Mailmaps,cn=services,dc=dal,dc=ca: NOT found. Searching with base=cn=services,dc=dal,dc=ca: NOT found. Searching with base=dc=dal,dc=ca: Found. cn=dal has 123312 children, which is very high. However, breaking the branch up into subcontainers, none of which had more than 10k entries, did not cure the problem. With olcLogLevel=any, the following is notable: Successful search: Apr 5 21:09:01 kil-ds-3 slapd[17628]: => hdb_dn2idl("cn=dal,cn=mailmaps,cn=services,dc=dal,dc=ca") Apr 5 21:09:03 kil-ds-3 slapd[17628]: => bdb_filter_candidates Apr 5 21:09:03 kil-ds-3 slapd[17628]: #011AND Apr 5 21:09:03 kil-ds-3 slapd[17628]: => bdb_list_candidates 0xa0 Apr 5 21:09:03 kil-ds-3 slapd[17628]: => bdb_filter_candidates Apr 5 21:09:03 kil-ds-3 slapd[17628]: #011OR Apr 5 21:09:03 kil-ds-3 slapd[17628]: => bdb_list_candidates 0xa1 Apr 5 21:09:03 kil-ds-3 slapd[17628]: => bdb_filter_candidates Apr 5 21:09:03 kil-ds-3 slapd[17628]: #011EQUALITY Apr 5 21:09:03 kil-ds-3 slapd[17628]: => bdb_equality_candidates (objectClass) Apr 5 21:09:03 kil-ds-3 slapd[17628]: => key_read Apr 5 21:09:03 kil-ds-3 slapd[17628]: bdb_idl_fetch_key: [b49d1940] Apr 5 21:09:03 kil-ds-3 slapd[17628]: <= bdb_index_read: failed (-30988) Apr 5 21:09:03 kil-ds-3 slapd[17628]: <= bdb_equality_candidates: id=0, first=0, last=0 Apr 5 21:09:03 kil-ds-3 slapd[17628]: <= bdb_filter_candidates: id=0 first=0 last=0 Apr 5 21:09:03 kil-ds-3 slapd[17628]: => bdb_filter_candidates Apr 5 21:09:03 kil-ds-3 slapd[17628]: #011EQUALITY Apr 5 21:09:03 kil-ds-3 slapd[17628]: => bdb_equality_candidates (mailLocalAddress) Apr 5 21:09:03 kil-ds-3 slapd[17628]: => key_read Apr 5 21:09:03 kil-ds-3 slapd[17628]: bdb_idl_fetch_key: [217e141f] Apr 5 21:09:03 kil-ds-3 slapd[17628]: <= bdb_index_read 1 candidates Apr 5 21:09:03 kil-ds-3 slapd[17628]: <= bdb_equality_candidates: id=1, first=129301, last=129301 Apr 5 21:09:03 kil-ds-3 slapd[17628]: <= bdb_filter_candidates: id=1 first=129301 last=129301 Apr 5 21:09:03 kil-ds-3 slapd[17628]: <= bdb_list_candidates: id=1 first=129301 last=129301 Apr 5 21:09:03 kil-ds-3 slapd[17628]: <= bdb_filter_candidates: id=1 first=129301 last=129301 Apr 5 21:09:03 kil-ds-3 slapd[17628]: <= bdb_list_candidates: id=1 first=129301 last=129301 Apr 5 21:09:03 kil-ds-3 slapd[17628]: <= bdb_filter_candidates: id=1 first=129301 last=129301 Apr 5 21:09:03 kil-ds-3 slapd[17628]: bdb_search_candidates: id=1 first=129301 last=129301 Apr 5 21:09:03 kil-ds-3 slapd[17628]: entry_decode: "" Apr 5 21:09:03 kil-ds-3 slapd[17628]: <= entry_decode() Apr 5 21:09:03 kil-ds-3 slapd[17628]: => test_filter Unsuccessful search: Apr 5 21:10:34 kil-ds-3 slapd[17628]: => hdb_dn2idl("cn=mailmaps,cn=services,dc=dal,dc=ca") Apr 5 21:10:34 kil-ds-3 slapd[17628]: => bdb_filter_candidates Apr 5 21:10:34 kil-ds-3 slapd[17628]: #011AND Apr 5 21:10:34 kil-ds-3 slapd[17628]: => bdb_list_candidates 0xa0 Apr 5 21:10:34 kil-ds-3 slapd[17628]: => bdb_filter_candidates Apr 5 21:10:34 kil-ds-3 slapd[17628]: #011OR Apr 5 21:10:34 kil-ds-3 slapd[17628]: => bdb_list_candidates 0xa1 Apr 5 21:10:34 kil-ds-3 slapd[17628]: => bdb_filter_candidates Apr 5 21:10:34 kil-ds-3 slapd[17628]: #011EQUALITY Apr 5 21:10:34 kil-ds-3 slapd[17628]: => bdb_equality_candidates (objectClass) Apr 5 21:10:34 kil-ds-3 slapd[17628]: => key_read Apr 5 21:10:34 kil-ds-3 slapd[17628]: bdb_idl_fetch_key: [b49d1940] Apr 5 21:10:34 kil-ds-3 slapd[17628]: <= bdb_index_read: failed (-30988) Apr 5 21:10:34 kil-ds-3 slapd[17628]: <= bdb_equality_candidates: id=0, first=0, last=0 Apr 5 21:10:34 kil-ds-3 slapd[17628]: <= bdb_filter_candidates: id=0 first=0 last=0 Apr 5 21:10:34 kil-ds-3 slapd[17628]: => bdb_filter_candidates Apr 5 21:10:34 kil-ds-3 slapd[17628]: #011EQUALITY Apr 5 21:10:34 kil-ds-3 slapd[17628]: => bdb_equality_candidates (mailLocalAddress) Apr 5 21:10:34 kil-ds-3 slapd[17628]: => key_read Apr 5 21:10:34 kil-ds-3 slapd[17628]: bdb_idl_fetch_key: [217e141f] Apr 5 21:10:34 kil-ds-3 slapd[17628]: <= bdb_index_read 1 candidates Apr 5 21:10:34 kil-ds-3 slapd[17628]: <= bdb_equality_candidates: id=1, first=129301, last=129301 Apr 5 21:10:34 kil-ds-3 slapd[17628]: <= bdb_filter_candidates: id=1 first=129301 last=129301 Apr 5 21:10:34 kil-ds-3 slapd[17628]: <= bdb_list_candidates: id=1 first=129301 last=129301 Apr 5 21:10:34 kil-ds-3 slapd[17628]: <= bdb_filter_candidates: id=1 first=129301 last=129301 Apr 5 21:10:34 kil-ds-3 slapd[17628]: <= bdb_list_candidates: id=0 first=3 last=0 Apr 5 21:10:34 kil-ds-3 slapd[17628]: <= bdb_filter_candidates: id=0 first=3 last=0 Apr 5 21:10:34 kil-ds-3 slapd[17628]: bdb_search_candidates: id=0 first=3 last=0 Apr 5 21:10:34 kil-ds-3 slapd[17628]: hdb_search: no candidates Apr 5 21:10:34 kil-ds-3 slapd[17628]: send_ldap_result: conn=1001 op=1 p=3 Apr 5 21:10:34 kil-ds-3 slapd[17628]: send_ldap_result: err=0 matched="" text="" Apr 5 21:10:34 kil-ds-3 slapd[17628]: send_ldap_response: msgid=2 tag=101 err=0 Apr 5 21:10:34 kil-ds-3 slapd[17628]: conn=1001 op=1 SEARCH RESULT tag=101 err=0 nentries=0 text= I'm including a link to a tarball that contains: - My (simplified) config, that still produces the problem. I'm managed to remove locally-created schemas. - My test LDIF, containing the entries that can produce the problem. They've been anonymized, but it doesn't affect the problem. A server loaded with the above config and this DIT will be consistently unable to find the "maillocaladdress=vbroken(a)dal.ca" entry at cn=services,dc=dal,dc=ca search base. - My test script, test_ldap.sh, that searches for the above entry at the levels in between it and the base naming context (dc=dal,dc=ca). I can provide more if needed, up to and including the compiled binaries.

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs