- openldap-bugs - openldap.org

Re: (ITS#5235) ppolicy leads to segfault
by dieter＠dkluenter.de 17 Nov '07

17 Nov '07

Pierangelo Masarati <ando(a)sys-net.it> writes: > dieter(a)dkluenter.de wrote: > >> (gdb) bt >> #0 0xb7a67139 in free () from /lib/libc.so.6 >> #1 0xb7ec128a in ber_memfree_x (p=0x2001, ctx=0x0) at memory.c:152 >> #2 0x0808f556 in ch_free () >> #3 0xb76f458c in ppolicy_restrict (op=0xa0a50d54, rs=0xa0a51148) >> at ppolicy.c:1245 > > I suspect this free occurs an internal operation initiated with > connection_fake_init(); can you check, from the core, if the value of > op->o_conn->c_conn_idx is -1? sorry :-( (gdb) gcore *** buffer overflow detected ***: gdb terminated ======= Backtrace: ========= -Dieter -- Dieter Klünter | Systemberatung http://www.dkluenter.de GPG Key ID:8EF7B6C6

1 0

Re: (ITS#5235) ppolicy leads to segfault
by ando＠sys-net.it 17 Nov '07

17 Nov '07

dieter(a)dkluenter.de wrote: > (gdb) bt > #0 0xb7a67139 in free () from /lib/libc.so.6 > #1 0xb7ec128a in ber_memfree_x (p=0x2001, ctx=0x0) at memory.c:152 > #2 0x0808f556 in ch_free () > #3 0xb76f458c in ppolicy_restrict (op=0xa0a50d54, rs=0xa0a51148) > at ppolicy.c:1245 I suspect this free occurs an internal operation initiated with connection_fake_init(); can you check, from the core, if the value of op->o_conn->c_conn_idx is -1? 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: Documentation should indicate that slurpd is deprecated (ITS#5196)
by ghenry＠OpenLDAP.org 16 Nov '07

16 Nov '07

marg(a)rz.tu-clausthal.de wrote: > Hello, > > fig. 3.3 in > > http://www.openldap.org/doc/admin24/config.html > > mentions "slurpd", while the text was updated to reflect syncrepl. > > bye > Christian Thanks, I haven't had time to update the pics yet. -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/

1 0

Re: (ITS#5236) core.ldif differs from core.schema
by ando＠sys-net.it 16 Nov '07

16 Nov '07

hyc(a)symas.com wrote: > dieter(a)dkluenter.de wrote: > Seems someone updated core.schema for RFC4519 but didn't update core.ldif. Was me, sorry. 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#5236) core.ldif differs from core.schema
by hyc＠symas.com 16 Nov '07

16 Nov '07

dieter(a)dkluenter.de wrote: > Full_Name: Dieter Kluenter > Version: HEAD > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (84.142.190.40) > > > core.ldif > > olcAttributeTypes: ( 2.5.4.6 NAME ( 'c' 'countryName' ) > DESC 'RFC2256: ISO-3166 country 2-letter code' > SUP name SINGLE-VALUE ) > > core.schema > attributetype ( 2.5.4.6 NAME 'c' > DESC 'RFC2256: ISO-3166 country 2-letter code' > SUP name > SYNTAX 1.3.6.1.4.1.1466.115.121.1.11 > SINGLE-VALUE ) > > As far as I understand, core.schema is correct here. Seems someone updated core.schema for RFC4519 but didn't update core.ldif. I'm puzzled why RFC4519 drops the 'countryName' alias for this type from the RFC2256 definition. -- -- 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#5236) core.ldif differs from core.schema
by dieter＠dkluenter.de 16 Nov '07

16 Nov '07

Full_Name: Dieter Kluenter Version: HEAD OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.142.190.40) core.ldif olcAttributeTypes: ( 2.5.4.6 NAME ( 'c' 'countryName' ) DESC 'RFC2256: ISO-3166 country 2-letter code' SUP name SINGLE-VALUE ) core.schema attributetype ( 2.5.4.6 NAME 'c' DESC 'RFC2256: ISO-3166 country 2-letter code' SUP name SYNTAX 1.3.6.1.4.1.1466.115.121.1.11 SINGLE-VALUE ) As far as I understand, core.schema is correct here. -Dieter

1 0

Re: Documentation should indicate that slurpd is deprecated (ITS#5196)
by marg＠rz.tu-clausthal.de 16 Nov '07

16 Nov '07

Hello, fig. 3.3 in http://www.openldap.org/doc/admin24/config.html mentions "slurpd", while the text was updated to reflect syncrepl. bye Christian -- Christian Marg mail : mailto:marg@rz.tu-clausthal.de Dezernat 2 TU Clausthal web : http://www.tu-clausthal.de D-38678 Clausthal-Zellerfeld fon : 05323/72-2107 Germany jabber: ifcma(a)jabber.tu-clausthal.de

1 0

(ITS#5235) ppolicy leads to segfault
by dieter＠dkluenter.de 15 Nov '07

15 Nov '07

Full_Name: Dieter Kluenter Version: HEAD OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.142.231.219) I am testing ppolicy overlay with HEAD. When starting slapd it segfaults with: .... ber_scanf fmt ({mm}) ber: ber_dump: buf=0xa015009c ptr=0xa01500bc end=0xa01500e5 len=41 0000: 00 27 04 14 65 6e 74 72 79 45 78 70 69 72 65 54 .'..entryExpireT 0010: 69 6d 65 73 74 61 6d 70 04 0f 32 30 30 37 31 31 imestamp..200711 0020: 31 35 32 31 31 31 32 33 5a 15211123Z end get_filter 0 end get_filter_list end get_filter 0 Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xa0a51b90 (LWP 5703)] 0xb7a67139 in free () from /lib/libc.so.6 this is gdb backtrace (gdb) bt #0 0xb7a67139 in free () from /lib/libc.so.6 #1 0xb7ec128a in ber_memfree_x (p=0x2001, ctx=0x0) at memory.c:152 #2 0x0808f556 in ch_free () #3 0xb76f458c in ppolicy_restrict (op=0xa0a50d54, rs=0xa0a51148) at ppolicy.c:1245 #4 0x080d564e in overlay_op_walk () #5 0x080d5bee in ?? () #6 0xa0a50d54 in ?? () #7 0xa0a51148 in ?? () #8 0x00000002 in ?? () #9 0x082695b0 in ?? () #10 0x08270c50 in ?? () #11 0xa0a50be8 in ?? () #12 0xa0a50cec in ?? () #13 0xa0a50ce8 in ?? () #14 0x00000002 in ?? () #15 0xa0a51148 in ?? () #16 0x08270c50 in ?? () #17 0x000003f2 in ?? () #18 0x00000000 in ?? () -Dieter

1 0

Re: (ITS#5187) test020-proxycache failing in RE_2_4
by ghenry＠suretecsystems.com 15 Nov '07

15 Nov '07

Tested in HEAD again, on same machine with same cmd: for i in `seq 1 100`; do ./run test020 >> test_results.log; done; and grepped the log file for "Error" and -i "succeed". Results: 100 Passes 0 Fails Looks good to me. Gavin. -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 824887 E ghenry(a)suretecsystems.com Open Source. Open Solutions(tm). http://www.suretecsystems.com/

1 0

Re: (ITS#5187) test020-proxycache failing in RE_2_4
by ghenry＠OpenLDAP.org 15 Nov '07

15 Nov '07

Make that: http://www.perl.me.uk/testrun008.tar.gz ftp.openldap.org incoming kept failing.

1 0

Re: (ITS#5187) test020-proxycache failing in RE_2_4
by ghenry＠OpenLDAP.org 15 Nov '07

15 Nov '07

rhafer(a)suse.de wrote: > On Donnerstag, 8. November 2007, you wrote: >> <quote who="Ralf Haferkamp"> >> >>> On Donnerstag, 8. November 2007, rhafer(a)suse.de wrote: >>>> I think I found a way. >>>> 1. The SLAPD_ABANDON/op->o_abandon part of the cleanup handler will now >>>> only get executed if the final result for the search has not been >>>> received >>>> (caching_reason == PC_IGNORE). >>>> 2. Additionally, to add the entries to the cache, I do no longer use the >>>> original Connection Object but create a new one >>>> (connection_fake_init()), >>>> because the op->o_abandon will be set for the original connection as >>>> soon >>>> as the client closes it. >>>> >>>> I'll do some more testing locally an submit this to HEAD later for more >>>> external testing. >>> Fix submitted to HEAD. Please test (preferably on the machine that caused >>> this >>> test to fail most often ;) ). >> I'll try this tonight. >> >> Just to clarify, this is a fix in the code, rather than the test, which I >> thought Howard had changed? > Yes, it is a fix in the pcache code. The fix in the testcase was only done > temporarely in the RE24 branch (HEAD was not changed). I intend to remove it > as soon as I get positive feedback. > Trying to test in HEAD, can't cant past test008-concurrency on bdb tests. Using ldapsearch to retrieve all the entries... Filtering ldapsearch results... Filtering original ldif used to create database... Comparing filter output... comparison failed - database was not created correctly >>>>> ./scripts/test008-concurrency failed (exit 1) make[2]: *** [bdb-mod] Error 1 make[2]: Leaving directory `/anything/src/openldap/ldap/tests' make[1]: *** [test] Error 2 make[1]: Leaving directory `/anything/src/openldap/ldap/tests' make: *** [test] Error 2 testrun data: ftp://ftp.openldap.org/incoming/test008.tar.gz -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/

1 0

Re: Contrib: addpartial overlay (ITS#3593)
by ghenry＠OpenLDAP.org 14 Nov '07

14 Nov '07

ghenry(a)OpenLDAP.org wrote: > dhawes(a)vt.edu wrote: >> On Friday 27 July 2007 05:20, ghenry(a)openldap.org wrote: >>> Hi David, >>> >>> http://www.openldap.org/devel/cvsweb.cgi/contrib/slapd-modules/addpartial/ >>> >>> Will be pushed out in the next 2.4 beta. >>> >>> Please bear in mind that you will be looking after this overlay, so test >>> as often as you can and re-submit and changes during our release cycle. >>> >>> Thank you for your contribution. >> Changes to work properly with 2.4.6 are at: >> >> ftp://ftp.openldap.org/incoming/david_hawes-addpartial-071109.tgz >> >> Thanks, >> >> dave >> >> > > Will take a look over the next week. > > Thanks. > Updated in RE24 and HEAD. -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/

1 0

Re: (ITS#5234) Feature request: mit-kr5 support in smbk5pwd
by hyc＠symas.com 14 Nov '07

14 Nov '07

openldap2007(a)mnagl.de wrote: > Full_Name: Matthias Nagl > Version: > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (137.248.132.104) > The current stable version of mit-krb5 (http://web.mit.edu/Kerberos/) seems to > have a much better support for LDAP-Backends than Heimdal. Sadly the > smbk5pwd-overlay currently won't support password synchronization with the new > MIT-schema. It would be great if smbk5pwd could be extended to work with the new > mit-krb5. You're welcome to submit a patch to provide the necessary support. I'll note that the MIT schema is deficient in a number of areas too; we're looking at writing up an IETF Draft defining a more comprehensive schema that can be used by both MIT and Heimdal going forward. As a total aside, the MIT code's stability leaves a lot to be desired. I won't deploy it on any of my networks because I've seen it crash too many times. In contrast, I've deployed Heimdal at numerous sites and never had to fuss with it, it just works. Your Mileage May Vary, just relating my personal experience accumulated over several years. -- -- 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#5234) Feature request: mit-kr5 support in smbk5pwd
by openldap2007＠mnagl.de 14 Nov '07

14 Nov '07

Full_Name: Matthias Nagl Version: OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (137.248.132.104) The current stable version of mit-krb5 (http://web.mit.edu/Kerberos/) seems to have a much better support for LDAP-Backends than Heimdal. Sadly the smbk5pwd-overlay currently won't support password synchronization with the new MIT-schema. It would be great if smbk5pwd could be extended to work with the new mit-krb5.

1 0

Re: (ITS#5228) Patches for minor typos in man pages
by ghenry＠suretecsystems.com 14 Nov '07

14 Nov '07

<quote who="ghenry(a)OpenLDAP.org"> > <quote who="Sam Varshavchik"> >> No problem. >> >> Here are the fixes diff-ed against CVS HEAD: >> >> http://www.tldp.org/manpages/openldap-2.4.6-manpatch.txt >> Now patched in HEAD. Gavin.

1 0

(ITS#5232) Running out of BDB locks causes truncated searches but no error code
by unix.gurus＠gmail.com 13 Nov '07

13 Nov '07

Full_Name: Sean Burford Version: 2.3.32 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (65.57.245.11) Searches that span periods of BDB lock exhaustion may return truncated results with a success error code. It should return an err=80 failure. This was with a BDB 4.4.20 backend. In the log below you can see: a search starts at 11:00:01 the search returns success:240 entries at 11:00:03 a search starts at 11:15:01 bdb runs out of locks at 11:15:02, informs the mod operation that it failed the search returns success:128 entries at 11:15:02 Both searches were identical. Nov 9 11:00:01 conn=71131 op=2 SRCH base="dc=example,dc=com" scope=2 deref=0 filter="(objectClass=exampleClass)" Nov 9 11:00:01 conn=71131 op=2 SRCH attr=* + Nov 9 11:00:03 conn=71131 op=2 SEARCH RESULT tag=101 err=0 nentries=240 text= ... Nov 9 11:15:01 conn=72711 op=2 SRCH base="dc=example,dc=com" scope=2 deref=0 filter="(objectClass=exampleClass)" Nov 9 11:15:01 conn=72711 op=2 SRCH attr=* + ... Nov 9 11:15:02 bdb(dc=example,dc=com): Lock table is out of available locks Nov 9 11:15:02 => bdb_idl_delete_key: c_get id failed: Cannot allocate memory (12) Nov 9 11:15:02 bdb(dc=example,dc=com): Lock table is out of available locks Nov 9 11:15:02 bdb(dc=example,dc=com): Lock table is out of available locks Nov 9 11:15:02 bdb(dc=example,dc=com): Lock table is out of available locks ... Nov 9 11:15:02 Attribute index delete failure Nov 9 11:15:02 bdb(dc=example,dc=com): Lock table is out of available locks Nov 9 11:15:02 bdb(dc=example,dc=com): Lock table is out of available locks Nov 9 11:15:02 bdb(dc=example,dc=com): Lock table is out of available locks Nov 9 11:15:02 conn=72642 op=10 RESULT tag=103 err=80 text= Nov 9 11:15:02 conn=72131 op=144 RESULT tag=103 err=80 text=internal error ... Nov 9 11:15:02 conn=72711 op=2 SEARCH RESULT tag=101 err=0 nentries=128 text= Nov 9 11:15:05 conn=72711 op=3 UNBIND Nov 9 11:15:05 conn=72711 fd=57 closed () The database definition is: database bdb suffix "dc=example,dc=com" directory /var/lib/ldap overlay auditlog auditlog /var/lib/ldap/ldif/auditlog/audit.com.ldif overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 1000 overlay accesslog logdb cn=accesslog logops writes logsuccess TRUE logpurge 02+23:46 01+23:46 # This limits section applies to the user this bug is about... limits dn.exact="uid=user1,ou=people,dc=example,dc=com" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited cachesize 100000 idlcachesize 10000 sizelimit 200000 checkpoint 512 1 lastmod on idletimeout 300 threads 64

1 0

Re: (ITS#5221) cache? of parent failes for hdb
by Dan.Oscarsson＠tietoenator.com 13 Nov '07

13 Nov '07

mån 2007-11-12 klockan 23:17 +0000 skrev quanah(a)zimbra.com: > --On Monday, November 12, 2007 7:02 AM +0000 hyc(a)symas.com wrote: > > > Dan.Oscarsson(a)tietoenator.com wrote: > >> Full_Name: Dan Oscarsson > >> Version: 2.3.32 > >> OS: SLES 10 > >> URL: ftp://ftp.openldap.org/incoming/ > >> Submission from: (NULL) (193.15.240.60) > > > Also, Just some general data on what it is you are doing that is a bit more > explanative. For example, what does your tree layout look like? A single > root with 20,000+ subtrees off of the root? A root with 10 subtrees, with > thousands of subtrees off of those? How are you doing these modrdn's? > Why, exactly? Anything that can help us to possibly come up with a > progamatic generation of dummy data. The tree is based on a company organisation structure, branching at each organisational level util you get to a person. So the root has only a few subtrees, and each subtree only a few (say 1-30) subtrees. Most entries will probably a subtree for a unit with the persons beloning to that unit. People will always be leafs but an entry may contain both people and subtrees as children. I have triggered the bug when doing major reorganisation of people. Then very many of the people are moved around to a new place in the tree. Many to newly created subtrees. I have now used 2.3.38 compiled myself so I can add tracing to the code if needed. Running a move of people, with logging set to any, and then running my simple check program, the search at a subtree that goes wrong (entries are missing) is logged as: filter: (&(objectClass=enterprisePerson)(ba=telecom & media)(bu=telecom solutions)) 2007-11-13 15.19.05 ra [local4.debug] slapd[27292]: search_candidates: base=\"bu=telecom solutions,ba=telecom & media,cn=organisation,o=xx\" (0x0000513a) scope=2 2007-11-13 15.19.05 ra [local4.debug] slapd[27292]: => hdb_dn2idl(\"bu=telecom solutions,ba=telecom & media,cn=organisation,o=xx\") 2007-11-13 15.19.05 ra [local4.debug] slapd[27292]: => bdb_filter_candidates 2007-11-13 15.19.05 ra [local4.debug] slapd[27292]: AND 2007-11-13 15.19.05 ra [local4.debug] slapd[27292]: => bdb_list_candidates 0xa0 2007-11-13 15.19.05 ra [local4.debug] slapd[27292]: => bdb_filter_candidates 2007-11-13 15.19.05 ra [local4.debug] slapd[27292]: OR 2007-11-13 15.19.05 ra [local4.debug] slapd[27292]: => bdb_list_candidates 0xa1 2007-11-13 15.19.05 ra [local4.debug] slapd[27292]: => bdb_filter_candidates 2007-11-13 15.19.05 ra [local4.debug] slapd[27292]: EQUALITY 2007-11-13 15.19.05 ra [local4.debug] slapd[27292]: => bdb_equality_candidates (objectClass) 2007-11-13 15.19.05 ra [local4.debug] slapd[27292]: => key_read 2007-11-13 15.19.05 ra [local4.debug] slapd[27292]: bdb_idl_fetch_key: [b49d1940] 2007-11-13 15.19.05 ra [local4.debug] slapd[27292]: <= bdb_index_read: failed (-30989) 2007-11-13 15.19.05 ra [local4.debug] slapd[27292]: <= bdb_equality_candidates: id=0, first=0, last=0 2007-11-13 15.19.05 ra [local4.debug] slapd[27292]: <= bdb_filter_candidates: id=0 first=0 last=0 2007-11-13 15.19.05 ra [local4.debug] slapd[27292]: => bdb_filter_candidates 2007-11-13 15.19.05 ra [local4.debug] slapd[27292]: AND 2007-11-13 15.19.05 ra [local4.debug] slapd[27292]: => bdb_list_candidates 0xa0 2007-11-13 15.19.05 ra [local4.debug] slapd[27292]: => bdb_filter_candidates 2007-11-13 15.19.05 ra [local4.debug] slapd[27292]: EQUALITY 2007-11-13 15.19.05 ra [local4.debug] slapd[27292]: => bdb_equality_candidates (objectClass) 2007-11-13 15.19.05 ra [local4.debug] slapd[27292]: => key_read 2007-11-13 15.19.05 ra [local4.debug] slapd[27292]: bdb_idl_fetch_key: [a98323a6] 2007-11-13 15.19.05 ra [local4.debug] slapd[27292]: <= bdb_index_read 20569 candidates 2007-11-13 15.19.05 ra [local4.debug] slapd[27292]: <= bdb_equality_candidates: id=20569, first=1483, last=26650 2007-11-13 15.19.05 ra [local4.debug] slapd[27292]: <= bdb_filter_candidates: id=20569 first=1483 last=26650 2007-11-13 15.19.05 ra [local4.debug] slapd[27292]: => bdb_filter_candidates 2007-11-13 15.19.05 ra [local4.debug] slapd[27292]: EQUALITY 2007-11-13 15.19.05 ra [local4.debug] slapd[27292]: => bdb_equality_candidates (ba) 2007-11-13 15.19.05 ra [local4.debug] slapd[27292]: => key_read 2007-11-13 15.19.05 ra [local4.debug] slapd[27292]: bdb_idl_fetch_key: [410ca247] 2007-11-13 15.19.05 ra [local4.debug] slapd[27292]: <= bdb_index_read 6991 candidates 2007-11-13 15.19.05 ra [local4.debug] slapd[27292]: <= bdb_equality_candidates: id=6991, first=15620, last=26644 2007-11-13 15.19.05 ra [local4.debug] slapd[27292]: <= bdb_filter_candidates: id=6991 first=15620 last=26644 2007-11-13 15.19.05 ra [local4.debug] slapd[27292]: => bdb_filter_candidates 2007-11-13 15.19.05 ra [local4.debug] slapd[27292]: EQUALITY 2007-11-13 15.19.05 ra [local4.debug] slapd[27292]: => bdb_equality_candidates (bu) 2007-11-13 15.19.05 ra [local4.debug] slapd[27292]: => key_read 2007-11-13 15.19.05 ra [local4.debug] slapd[27292]: bdb_idl_fetch_key: [8b819570] 2007-11-13 15.19.05 ra [local4.debug] slapd[27292]: <= bdb_index_read 2195 candidates 2007-11-13 15.19.05 ra [local4.debug] slapd[27292]: <= bdb_equality_candidates: id=2195, first=30, last=26614 2007-11-13 15.19.05 ra [local4.debug] slapd[27292]: <= bdb_filter_candidates: id=2195 first=30 last=26614 2007-11-13 15.19.05 ra [local4.debug] slapd[27292]: <= bdb_list_candidates: id=2144 first=20813 last=26614 2007-11-13 15.19.05 ra [local4.debug] slapd[27292]: <= bdb_filter_candidates: id=2144 first=20813 last=26614 2007-11-13 15.19.05 ra [local4.debug] slapd[27292]: <= bdb_list_candidates: id=2144 first=20813 last=26614 2007-11-13 15.19.05 ra [local4.debug] slapd[27292]: <= bdb_filter_candidates: id=2144 first=20813 last=26614 2007-11-13 15.19.05 ra [local4.debug] slapd[27292]: <= bdb_list_candidates: id=2130 first=20813 last=26614 2007-11-13 15.19.05 ra [local4.debug] slapd[27292]: <= bdb_filter_candidates: id=2130 first=20813 last=26614 2007-11-13 15.19.05 ra [local4.debug] slapd[27292]: bdb_search_candidates: id=2130 first=20813 last=26614 Stopping and starting the server. The check now works. The above search is logged the same except for the last part: 2007-11-13 15.19.41 ra [local4.debug] slapd[27460]: bdb_idl_fetch_key: [8b819570] 2007-11-13 15.19.41 ra [local4.debug] slapd[27460]: <= bdb_index_read 2195 candidates 2007-11-13 15.19.41 ra [local4.debug] slapd[27460]: <= bdb_equality_candidates: id=2195, first=30, last=26614 2007-11-13 15.19.41 ra [local4.debug] slapd[27460]: <= bdb_filter_candidates: id=2195 first=30 last=26614 2007-11-13 15.19.41 ra [local4.debug] slapd[27460]: <= bdb_list_candidates: id=2144 first=20813 last=26614 2007-11-13 15.19.41 ra [local4.debug] slapd[27460]: <= bdb_filter_candidates: id=2144 first=20813 last=26614 2007-11-13 15.19.41 ra [local4.debug] slapd[27460]: <= bdb_list_candidates: id=2144 first=20813 last=26614 2007-11-13 15.19.41 ra [local4.debug] slapd[27460]: <= bdb_filter_candidates: id=2144 first=20813 last=26614 2007-11-13 15.19.41 ra [local4.debug] slapd[27460]: <= bdb_list_candidates: id=2141 first=20813 last=26614 2007-11-13 15.19.41 ra [local4.debug] slapd[27460]: <= bdb_filter_candidates: id=2141 first=20813 last=26614 2007-11-13 15.19.41 ra [local4.debug] slapd[27460]: bdb_search_candidates: id=2141 first=20813 last=26614 In both above cases, with the same filter but search base set to o=xx witch is the database prefix, it works as it should. In this case the entries that were missing above is found. I do not know it this might give you some clue to what the problem is. Any suggestions on what I should look for or any suitable place in the code where I could add debug logging, would be nice. The logs get very large when running with logging set to any. Dan -- Dan Oscarsson TietoEnator Email: Dan.Oscarsson(a)tietoenator.com Box 85 201 20 Malmo, Sweden

1 0

Re: (ITS#5221) cache? of parent failes for hdb
by quanah＠zimbra.com 12 Nov '07

12 Nov '07

--On Monday, November 12, 2007 7:02 AM +0000 hyc(a)symas.com wrote: > Dan.Oscarsson(a)tietoenator.com wrote: >> Full_Name: Dan Oscarsson >> Version: 2.3.32 >> OS: SLES 10 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (193.15.240.60) > >> From this I suspect that it is the cache of which parent node belongs to >> that gets corrupted. Or can it be something else? >> What more could I do to trace down the bug? >> I do not know if the above information is enough for you to find what is >> wrong? Cannot include data as it contains company internal information >> and a simple test program did not give the same error. >> I have looked at the code, but it takes some time to understand it when >> doing it for the first time. maybe som debugging code could be added >> find the place where the bug is. > > This isn't a lot of information to go on. If you can create a test > program that shows the problem occurring, using dummy data, that would > help. -- Also, Just some general data on what it is you are doing that is a bit more explanative. For example, what does your tree layout look like? A single root with 20,000+ subtrees off of the root? A root with 10 subtrees, with thousands of subtrees off of those? How are you doing these modrdn's? Why, exactly? Anything that can help us to possibly come up with a progamatic generation of dummy data. And, you said you had a script to do this, can you include that? --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5183) Index problem with ;x- attributes.
by hyc＠symas.com 12 Nov '07

12 Nov '07

ando(a)sys-net.it wrote: > Magnus.Jonsson(a)umdac.umu.se wrote: >> Full_Name: Magnus Jonsson >> Version: 2.3.38 >> OS: Debian GNU/linux ”Etch” >> URL: http://foo.fot.nu/reproduce.txt >> Submission from: (NULL) (130.239.200.171) >> We are using ;x- attributes in a specific appliation to group some attributes. >> >> When removing a ;x- attrbute all the indexs for that attribute disapears. >> >> example: >> >> cn: index >> cn;x-f-1: index >> cn;x-f-2: index >> >> If a remove the cn;x-f-1 attribute I can't search for (cn=index) anymore. > > I confirm your report, except that if the type and all subtypes have the > same value, and if I remove the "cn;x-f-1" value, I can no longer search > for "cn" equality, but I can still search for "cn;x-f-2". This seems to be an old problem resurfacing, hash collisions in the index where multiple values hash to the same index slot. We either need to use ref-counts, or we just quit deleting index values at runtime, and require an explicit garbage-collection pass of some kind to regenerate indices. -- -- 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#5227) old dsn acceptance
by quanah＠zimbra.com 12 Nov '07

12 Nov '07

--On Monday, November 12, 2007 2:18 PM +0000 ando(a)sys-net.it wrote: > Howard Chu wrote: > >> Ah, ok. So, do you think we need to integrate this patch? > > Do you mean: in 2.3? It might be a good idea in case we want all > versions to be completely interoperable. Otherwise, as the code is now, > 2.4 tolerates 2.3 (and 2.2, AFAIK), while 2.2 and 2.3 do not tolerate > 2.4 (or, which is worse, tolerate but don't understand 2.4: issues could > arise when comparing CSNs generated by different versions, which only > 2.4 correctly handles by normalizing to its form). Eventually, this > could be a problem as soon as someone tries to use 2.4 as master and 2.3 > as slave. I'm not sure how much we should support any release older than 2.3 when combined with 2.4. Particularly something as ancient as 2.1. As far as replication goes, I think given the timestamp changes, the only supported format would be a 2.3 master with 2.4 slaves. Just my 2c. ;) --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5229) `make install' writes to the source tree as root
by mills＠cc.umanitoba.ca 12 Nov '07

12 Nov '07

On Sun, Nov 11, 2007 at 04:19:01PM -0800, Howard Chu wrote: > > Agreed, it should not be relinking, ever, but that's libtool. I've > submitted patches to libtool to correct this a number of times over the > past several years but the problem remains, and it's our policy to avoid > using customized OpenLDAP-specific versions of the GNU tools so we no > longer provide patched versions of libtool in our CVS. Yes, I understand your frustration with libtool and I don't expect OpenLDAP to include a patched version. Still, the OpenLDAP Makefiles could be modified to avoid libtool's relinking behavior. > In the meantime, there's no reason for this to be affecting your source > tree. You can always build using an object tree separate from the source > tree. And you can always use "make install DESTDIR=/tmp/foo" on the build > system to create an alternate hierarchy that can then be copied to any > other machine. I didn't realize that I could do that, but it's still second best. Copying doesn't preserve an existing slapd.conf, for example. `make install' would be superior if it avoided writing to the source tree. This is easy enough to accomplish if it's made part of the policy. > Since there is no fundamental bug in OpenLDAP here, this ITS will be closed. It's certainly not a bug in OpenLDAP, but just in the build and install system that accompanies OpenLDAP. I'd consider it a bug. -- -Gary Mills- -Unix Support- -U of M Academic Computing and Networking-

1 0

Re: (ITS#5231) test045 failure in HEAD/RE24
by ghenry＠suretecsystems.com 12 Nov '07

12 Nov '07

> I already fixed that in HEAD. See the commit logs. Ah, thanks.

1 0

Re: (ITS#5227) old dsn acceptance
by ando＠sys-net.it 12 Nov '07

12 Nov '07

Howard Chu wrote: > Ah, ok. So, do you think we need to integrate this patch? Do you mean: in 2.3? It might be a good idea in case we want all versions to be completely interoperable. Otherwise, as the code is now, 2.4 tolerates 2.3 (and 2.2, AFAIK), while 2.2 and 2.3 do not tolerate 2.4 (or, which is worse, tolerate but don't understand 2.4: issues could arise when comparing CSNs generated by different versions, which only 2.4 correctly handles by normalizing to its form). Eventually, this could be a problem as soon as someone tries to use 2.4 as master and 2.3 as slave. 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#5227) old dsn acceptance
by hyc＠symas.com 12 Nov '07

12 Nov '07

Pierangelo Masarati wrote: > hyc(a)symas.com wrote: > >> It seems a bit odd to be introducing support for that format now in 2.4, when >> it was completely unsupported in 2.2 and 2.3. I.e., why wasn't this issue >> raised during the migration to/thru either 2.2 or 2.3? > > Probably because until 2.4 > > #define csnValidate blobValidate > > and as such any incompatible CSN was silently ignored. So this has > always been broken, only 2.4 detects the inconsistency, but behaved > badly (assert) until your fix. Ah, ok. So, do you think we need to integrate this patch? -- -- 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#5231) test045 failure in HEAD/RE24
by hyc＠symas.com 12 Nov '07

12 Nov '07

Gavin Henry wrote: > <quote who="hyc(a)OpenLDAP.org"> >> Full_Name: Howard Chu >> Version: HEAD/RE24 >> OS: >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (76.168.84.21) >> Submitted by: hyc >> >> >> The comparison fails after the first modify step, an entry that should >> have been >> deleted is still present on the slave. >> >> The presentlist is still left over from the initial query, and hasn't been >> emptied yet. This appears to be a missing step when the initial query >> transitions from Refresh to Persist mode. > On RE24 mine on AMD64 Dual doesn't get that far. It dies on test033 with: > > Comparison failed - database not created correctly. > > I'll provide all details shortly, or best to create a new ticket? I already fixed that in HEAD. See the commit logs. -- -- 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