openldap-bugs

openldap-bugs@openldap.org

1 participants
20961 discussions

Re: (ITS#5215) Use of ln is hardcoded in some files
by hyc＠symas.com 07 Nov '07

07 Nov '07

emmanuel.duru(a)atosorigin.com wrote: > Full_Name: Emmanuel Duru > Version: 2.3.38 > OS: Windows > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (195.68.44.148) > > > configure allows the use of "cp" instead of "ln", but the build/shtool tool uses > a hardcoded "ln" (line 1266). > Some makefiles (libraries/liblunicode, libraries/libldap_r and > servers/slapd/back-hdb) use a hardcoded "-s" option. This is a problem on > Windows because in cygwin environment "cp -s" behaves the same way as "ln -s". > The use of "ln" is not welcome here because it creates a Windows shortcut, which > is not understood by mingw compiler. We only support the MSYS build environment on Windows. If you'd like to submit a patch to address this issue that doesn't break the other platforms, we can look at incorporating it. -- -- 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#5218) ber_get_next at /liblber/io.c:710
by quanah＠zimbra.com 07 Nov '07

07 Nov '07

--On November 6, 2007 10:21:45 PM +0000 dappleby(a)deakin.edu.au wrote: > Is anyone able to tell me how/why this occurs? You made the mistake of using the RH ldap packages, that's why. As to whether or not this has been fixed, please don't open up bug reports on obsolete versions of OpenLDAP. Send your question to openldap-software, and maybe someone can help you there. Personally I'd suggest using Buchan Milne's builds for RH or Symas's CDS packages. Odds are though, it has been fixed. 2.2.13 is quite old, with 2.4.6 being the current release. <http://staff.telkomsa.net/packages/> <http://www.symas.com/> --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5217) refint overlay doc contribution
by ghenry＠OpenLDAP.org 06 Nov '07

06 Nov '07

<quote who="andreas(a)mandriva.com.br"> > Full_Name: Andreas Hasenack > Version: 2.3.39 > OS: linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (200.140.247.99) > > > Please find at > http://users.mandriva.com.br/~andreas/ldap-doc/doc-refint-patch/ > a patch and some image files for the admin guide. It adds documentation, > examples and figures for the referential integrity overlay. Looks good. Same comments as ITS#5216 I really appreciate your effort for this Andreas. Thanks. > Disclaimer (let me know if I got it right: I repeated it in the patch > file, but > obviously can't add it to the binary image files): > > This patch file is derived from OpenLDAP Software. All of the > modifications to > OpenLDAP Software represented in the following patch(es) were developed by > Andreas Hasenack <andreas(a)mandriva.com.br>. These modifications are not > subject > to any license of Mandriva. > I, Andreas Hasenack, hereby place the following modifications to OpenLDAP > Software (and only these modifications) into the public domain. Hence, > these > modifications may be freely used and/or redistributed for any purpose with > or > without attribution and/or other notice. > > >

1 0

Re: (ITS#5216) Dynamic Lists doc contribution to the admin guide
by ghenry＠OpenLDAP.org 06 Nov '07

06 Nov '07

<quote who="andreas(a)mandriva.com.br"> > Full_Name: Andreas Hasenack > Version: 2.3.39 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (200.140.247.99) > > > Please find at > http://users.mandriva.com.br/~andreas/ldap-doc/doc-dynlist-patch/ > a patch and some image files for the admin guide. It adds documentation, > examples and figures for the Dynamic List overlay. Thanks! As discussed in #ldap all looks good. > Disclaimer (let me know if I got it right: I repeated it in the patch > file, but > obviously can't add it to the binary image files): I'll leave Kurt to check this. Once approved I'll commit it and then look forward to the other patches you've got in your queue ;-) > > This patch file is derived from OpenLDAP Software. All of the > modifications to > OpenLDAP Software represented in the following patch(es) were developed by > Andreas Hasenack <andreas(a)mandriva.com.br>. These modifications are not > subject > to any license of Mandriva. > I, Andreas Hasenack, hereby place the following modifications to OpenLDAP > Software (and only these modifications) into the public domain. Hence, > these > modifications may be freely used and/or redistributed for any purpose with > or > without attribution and/or other notice. > > >

1 0

(ITS#5218) ber_get_next at /liblber/io.c:710
by dappleby＠deakin.edu.au 06 Nov '07

06 Nov '07

Full_Name: Daniel Appleby Version: 3 OS: RHEL4 Update 5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (128.184.138.7) Hi, I am getting a signal 6 (abort) in the samba logs which reports: [2007/11/06 19:01:06, 0, effective(0, 0), real(0, 0)] lib/smbldap.c:smbldap_search_suffix(1155) smbldap_search_suffix: Problem during the LDAP search: (Local error) smbd: ../../../libraries/liblber/io.c:516: ber_get_next: Assertion `ber->ber_buf == ((void *)0)' failed. It dropped a core and here is the full backtrace: #0 0x003db7a2 in ?? () #1 0x0025f7a5 in raise () from /lib/tls/libc.so.6 #2 0x00261209 in abort () from /lib/tls/libc.so.6 #3 0x007f06f4 in smb_panic2 (why=0x0, decrement_pid_count=1) at lib/util.c:1565 #4 0x007f086c in smb_panic (why=0x0) at lib/util.c:1454 #5 0x007dcd8f in sig_fault (sig=0) at lib/fault.c:41 #6 <signal handler called> #7 0x003db7a2 in ?? () #8 0x0025f7a5 in raise () from /lib/tls/libc.so.6 #9 0x00261209 in abort () from /lib/tls/libc.so.6 #10 0x00258d91 in __assert_fail () from /lib/tls/libc.so.6 #11 0x0094c1f5 in ber_get_next (sb=0x99231b0, len=0xbfe4072c, ber=0x992d880) at ../../../libraries/liblber/io.c:710 #12 0x0011a6a2 in try_read1msg (ld=0x9923100, msgid=10, all=1, sb=0x99231b0, lcp=0xbfe407dc, result=0xbfe40d34) at ../../../libraries/libldap/result.c:473 #13 0x0011bb6f in ldap_result (ld=0x9923100, msgid=10, all=1, timeout=0x0, result=0xbfe40d34) at ../../../libraries/libldap/result.c:378 #14 0x0011d28b in ldap_search_s (ld=0x9923100, base=0x992a618 "dc=deakin,dc=edu,dc=au", scope=2, filter=0x992da08 "(&(uid=pfield)(objectclass=sambaSamAccount))", attrs=0x992c580, attrsonly=0, res=0xbfe40d34) at ../../../libraries/libldap/search.c:364 #15 0x0086a9ff in smbldap_search (ldap_state=0x9922e70, base=0x992a618 "dc=deakin,dc=edu,dc=au", scope=2, filter=0xbfe408f0 "(&(uid=pfield)(objectclass=sambaSamAccount))", attrs=0x992c580, attrsonly=0, res=0xbfe40d34) at lib/smbldap.c:1047 #16 0x0086b116 in smbldap_search_suffix (ldap_state=0x9922e70, filter=0xbfe408f0 "(&(uid=pfield)(objectclass=sambaSamAccount))", search_attr=0x992c580, result=0xbfe40d34) at lib/smbldap.c:1148 #17 0x007c1cda in ldapsam_search_suffix_by_name (ldap_state=0x9922e00, user=Variable "user" is not available. ) at passdb/pdb_ldap.c:227 #18 0x007c524d in ldapsam_getsampwnam (my_methods=0x9922d70, user=0x992c410, sname=0x992d928 "pfield") at passdb/pdb_ldap.c:1291 #19 0x007bbaea in context_getsampwnam (context=0x9922c20, sam_acct=0x992c410, username=0x992d928 "pfield") at passdb/pdb_interface.c:197 #20 0x007bdbcf in pdb_getsampwnam (sam_acct=0x992c410, username=0x992d928 "pfield") at passdb/pdb_interface.c:883 #21 0x0082b2ad in check_sam_security (auth_context=0x9878dd0, my_private_data=0x0, mem_ctx=0x9924808, user_info=0x992d8b8, server_info=0x992afc0) at auth/auth_sam.c:240 #22 0x0082c54a in check_samstrict_security (auth_context=0x9878dd0, my_private_data=0x0, mem_ctx=0x0, user_info=0x992d8b8, server_info=0x0) at auth/auth_sam.c:372 #23 0x00829789 in check_ntlm_password (auth_context=0x9878dd0, user_info=0x992d8b8, server_info=0x992afc0) at auth/auth.c:255 #24 0x0083372e in auth_ntlmssp_check_password (ntlmssp_state=0x992bd68, user_session_key=0x0, lm_session_key=0x0) at auth/auth_ntlmssp.c:108 #25 0x00710a36 in ntlmssp_server_auth (ntlmssp_state=0x992bd68, request={data = 0x992c358 "NTLMSSP", length = 176, free = 0x7edc20 <free_data_blob>}, reply=0xbfe41350) at libsmb/ntlmssp.c:663 #26 0x0070ff0a in ntlmssp_update (ntlmssp_state=0x992bd68, in={data = 0x992c358 "NTLMSSP", length = 176, free = 0x7edc20 <free_data_blob>}, out=0xbfe41350) at libsmb/ntlmssp.c:259 #27 0x00833aa6 in auth_ntlmssp_update (auth_ntlmssp_state=0x0, request={data = 0x992c358 "NTLMSSP", length = 176, free = 0x7edc20 <free_data_blob>}, reply=0x0) at auth/auth_ntlmssp.c:187 #28 0x006b17a1 in reply_sesssetup_and_X_spnego (conn=0x0, inbuf=0xb7bc2008 "", outbuf=0xb7ba1008 "", length=354, bufsize=131072) at smbd/sesssetup.c:504 #29 0x006b2eb2 in reply_sesssetup_and_X (conn=0x0, inbuf=0xb7bc2008 "", outbuf=0xb7ba1008 "", length=354, bufsize=131072) at smbd/sesssetup.c:669 #30 0x006d95e2 in switch_message (type=115, inbuf=0xb7bc2008 "", outbuf=0xb7ba1008 "", size=354, bufsize=0) at smbd/process.c:968 #31 0x006d9a1c in process_smb (inbuf=0xb7bc2008 "", outbuf=0xb7ba1008 "") at smbd/process.c:998 #32 0x006da744 in smbd_process () at smbd/process.c:1560 #33 0x0086d057 in main (argc=2, argv=0xbfe44664) at smbd/server.c:900 Our openldap version is openldap-2.2.13-7.4E. I know that this is a redhat package etc but I would like to know if this has already been fixed or not? If it has been fixed can you let me know what version it was fixed in as I will need to supply redhat with a patch. Is anyone able to tell me how/why this occurs? If you need more info please let me know Thanks In Advance Daniel

1 0

(ITS#5217) refint overlay doc contribution
by andreas＠mandriva.com.br 06 Nov '07

06 Nov '07

Full_Name: Andreas Hasenack Version: 2.3.39 OS: linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (200.140.247.99) Please find at http://users.mandriva.com.br/~andreas/ldap-doc/doc-refint-patch/ a patch and some image files for the admin guide. It adds documentation, examples and figures for the referential integrity overlay. Disclaimer (let me know if I got it right: I repeated it in the patch file, but obviously can't add it to the binary image files): This patch file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Andreas Hasenack <andreas(a)mandriva.com.br>. These modifications are not subject to any license of Mandriva. I, Andreas Hasenack, hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice.

1 0

(ITS#5216) Dynamic Lists doc contribution to the admin guide
by andreas＠mandriva.com.br 06 Nov '07

06 Nov '07

Full_Name: Andreas Hasenack Version: 2.3.39 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (200.140.247.99) Please find at http://users.mandriva.com.br/~andreas/ldap-doc/doc-dynlist-patch/ a patch and some image files for the admin guide. It adds documentation, examples and figures for the Dynamic List overlay. Disclaimer (let me know if I got it right: I repeated it in the patch file, but obviously can't add it to the binary image files): This patch file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Andreas Hasenack <andreas(a)mandriva.com.br>. These modifications are not subject to any license of Mandriva. I, Andreas Hasenack, hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice.

1 0

cache? of parent failes for hdb
by Dan Oscarsson 06 Nov '07

06 Nov '07

I have found that using hdb there is a bug that now prevents me from moving from my old commercial X.500 database to openldap. I need to use hdb as I move objects using rename. I am running openldap under SLES 10. The version there is 2.3.32 but I have compiled 2.3.38 and tried that too. Both have same bug. Also compiled and tried openldap-2.4.5beta. Same failure there too. I am using hdb as database. What I do is to run a job that moves around a lot of leaf nodes to other branches, sometimes creating new branches before moving the leaf node there. The job moves about 7000 nodes out of 20000 when the bug occurs. After having run this, some nodes cannot be found by searching starting at a subtree under database suffix. I have done a simple test program to see if the bug appears. It does two searches: 1) Search with search base = database suffix 2) Search with search base = a branch 2 nodes deep below database suffix. If everything is correct, same number of objects should be found. My tests show: - running test: ok - running job that moves nodes - running test: failes, many objects are missing in search starting at search base that is 2 nodes below database suffix. - stopping and starting slapd - running test again: ok >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? 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. Regards, Dan

2 1

Re: (ITS#5213) LDAP detection failed
by quanah＠zimbra.com 06 Nov '07

06 Nov '07

--On Monday, November 05, 2007 1:56 PM +0000 harij2007(a)gmail.com wrote: The ITS system is for reporting bugs in OpenLDAP, not usage questions. Please send your questions on how to use and configure OpenLDAP to openldap-software(a)openldap.org --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#5187) test020-proxycache failing in RE_2_4
by rhafer＠suse.de 06 Nov '07

06 Nov '07

I think I have an idea what causes this bug. It is possible that the client closes the connection before the server had a chance to run the cleanup handler, the server sets op->o_abandon then (in connection_closing()). And after that the cleanup handler is started, which in case of op->o_abandon does not store the results in the cache. To make this race more reproduceable it is sufficient to insert a usleep(100) before the call to slap_cleanup_play() in send_ldap_response() in result.c. Any suggestions for possible ways to fix this? On Dienstag, 23. Oktober 2007, rhafer(a)suse.de wrote: > On Dienstag, 23. Oktober 2007, ando(a)sys-net.it wrote: > > For the records: I seem to be ble to consistently reproduce the issue > > when running slapd under valgrind; > > Thanks, that seems to do the trick for me as well. > > > I haven't seen it yet when running the test > > regularly (single CPU i386, recently). -- Ralf

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