openldap-bugs

openldap-bugs@openldap.org

1 participants
20960 discussions

Re: (ITS#6382) Error in set example (groups of groups)
by gavin.henry＠gmail.com 18 Nov '09

18 Nov '09

Thanks. Will fix this next week as I'm with my son in hospital until Friday. Gavin. On 16/11/2009, andreas(a)canonical.com <andreas(a)canonical.com> wrote: > Full_Name: Andreas Hasenack > Version: head > OS: linux > URL: ftp://ftp.openldap.org/incoming/andreas-hasenack-091116.tar.gz > Submission from: (NULL) (63.133.153.66) > > > The picture set-recursivegroup.png has a typo in the reference to > accountadm. It > should be under ou=group, not ou=people, in the upper left box. > > For reference, it's published here: > http://www.openldap.org/doc/admin24/access-control.html#Sets%20-%20Granting… > > The andreas-hasenack-091116.tar.gz tarball I'm uploading has a fixed .svg > file > (the source) as well as an exported png one. > > I wrongly uploaded that file as openldap-guide-fix.tar.gz: you can delete > that > one. > > -- Sent from my mobile device http://www.suretecsystems.com/services/openldap/ http://www.suretectelecom.com

1 0

Re: (ITS#6371) problem with ber_flatten2
by h.b.furuseth＠usit.uio.no 18 Nov '09

18 Nov '09

dave.daugherty(a)centrify.com writes: > Version: 2.2.6 and 2.4.17 This bug was fixed in OpenLDAP 2.4.18. > 1) Is the zero terminator really necessary? Yes. Much OpenLDAP code expects bervalues to be \0-terminated. lber.h now has a LBER_BV_NOTERM flag for not \0-terminating it. > 2) If so, seems like it should only be done if we actually allocated > a new buffer (which does leave one byte at the end). That would have been a cleaner default for the input value, but not for the output value:-( In any case, this function was probably first written for internal use - for accessing a BerElement. That code does deal with \0-termination. This quirk should be documented though. Currently ber_flatten is not documented at all. -- Hallvard

1 0

Re: (ITS#6386) Usage of ldap_init_fd
by hyc＠symas.com 18 Nov '09

18 Nov '09

vitaly.kroivets(a)gmail.com wrote: > Full_Name: Vitaly > Version: 2.4.16 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (192.115.180.11) > > > I try to use function ldap_init_fd, but it fails . Thanks for the report, a fix is now in CVS HEAD. Please test. > > ldap_init_fd (sockfd , 1 ,host_uri , &server); > > ... > rc = ldap_simple_bind_s(server, bind_dn, password); > if (rc != 0) { > fprintf(stderr, "ldap_simple_bind_s: %s", (*ldap_err2string)(rc)); > return 1; > } > > rc = ldap_search_s(server, ludp->lud_dn, ludp->lud_scope, > ludp->lud_filter, ludp->lud_attrs, 0, &result); > > ... > fails with segmentation fault: > > #0 find_connection (ld=0x8073ae8, srv=0x807cd50, any=1) at request.c:629 > #1 0x080571ba in ldap_chase_referrals (ld=0x8073a08, lr=0x807cc98, > errstrp=0x807ccbc, sref=-1, hadrefp=0xbffff84c) at request.c:1356 > #2 0x0804c620 in try_read1msg (ld=0x8073a08, msgid=2, all=1, > lc=0x8073ae8, > result=0x8071ce0) at result.c:805 > #3 0x0804bab0 in wait4msg (ld=0x8073a08, msgid=2, all=1, > timeout=0x8073ae8, > result=0x8071ce0) at result.c:390 > #4 0x0804dc5e in ldap_search_s (ld=0x8073a08, base=0x8071d80 "cn=US", > scope=0, filter=0x0, attrs=0x0, attrsonly=0, res=0x8071ce0) at > search.c:428 > #5 0x0804ab38 in main (argc=3, argv=0xbffff9d0) at /tmp/get.c:182 > (gdb) p lc > $1 = (struct ldap_conn *) 0x8073ae8 > (gdb) p *lc > $2 = {lconn_sb = 0x807bb30, lconn_refcnt = 3, lconn_created = 0, > lconn_lastused = 1258722436, lconn_rebind_inprogress = 0, > lconn_rebind_queue = 0x0, lconn_status = 3, lconn_server = 0x0, > lconn_ber = 0x0, lconn_next = 0x0} > (gdb) quit > > > > > -- -- 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#6368) Bug in deleting entry in MirrorMode
by hyc＠symas.com 18 Nov '09

18 Nov '09

pitpalme+openldap(a)gmail.com wrote: > Hello, > > hyc(a)symas.com wrote: > >> Paste the debug log somewhere we can see it then. Might as well use = > debug >> level -1 while executing this sequence. And provide the debug output = > from both >> servers. > > I=92ve got 60MiB of log files (cumulated from both servers) from running = > slapd with "-d Any=93.=20 > Sadly this erroneous behavior did only happened after a couple of test = > runs, so it=92s a lot of "everything works normal" in this files. > > The logs are available here: > > <url:http://pitpalme.is-a-geek.net/ldap/> > > They're both equal regarding contents, just compressed differently for = > faster download if 'xz' as compression tool is available. > > The test DN that fails is "cn=3DMax = > Mustermann,ou=3DbulkTestPerl,ou=3Dtest,o=3Desolution,dc=3Ddeutscherv,dc=3D= > de". The log shows that the problem is because the two servers are not synchronized before you begin your test. If you search for "do_syncrep" in the ldap1 log, you'll see that it was unable to connect to its provider at the very beginning of the file. It doesn't successfully connect until much later, 97% of the way down in the log file, after the majority of your testing has already been running. That delay is based on your syncrepl retry setting. When it finally connects it sends a somewhat out of date cookie to the peer server, and so it starts receiving results back. You get the "already exists" error because the entry you're trying to add has just been added by syncrepl itself. Part of the problem is the out-of-date cookie; the consumer checks with syncprov to make sure it has an up-to-date cookie but obviously in your case the cookie continues to change since you're still making changes to the DB. You can avoid this issue by making sure both servers' consumers are connected before performing any write ops, and you can assist in that by using a faster initial retry time in your syncrepl config. -- -- 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#6387) Valgrind reports issues in pcache
by hyc＠symas.com 18 Nov '09

18 Nov '09

masarati(a)aero.polimi.it wrote: > masarati(a)aero.polimi.it wrote: >> Full_Name: Pierangelo Masarati >> Version: HEAD,re24,2.4.19 >> OS: irrelevant? >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (131.175.154.146) >> Submitted by: ando >> >> >> See <http://www.openldap.org/lists/openldap-devel/200911/msg00015.html> > > The fix to ITS#6388 fixes the first valgrind warning of this ITS. The 2nd warning is just noise, you can shut it off in BerkeleyDB with "configure--enable-umrw" but the condition is harmless, and shutting it up imposes a performance penalty. -- -- 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#6383) Very Slow Query Response
by quanah＠zimbra.com 18 Nov '09

18 Nov '09

--On November 18, 2009 9:39:02 AM +0000 Bill MacAllister <whm(a)stanford.edu> wrote: >> For historical note this was caused by Cyrus-sasl being built >> incorrectly by the debian packagers when heimdal is used. >> > > I don't understand why you refer to this finding as historical. Not a historical finding. As a record for anyone who comes across this ITS and wants to know what was found. > If I > am reading this correctly you and Howard have found the underlying > cause. Now that the problem is understood can you suggest a way for > us to cause the problem in our test environments? At this point we > will really need to convince ourselves that the problem is indeed fixed > before we try to deploy 2.4 in our production environment again. To note, first off, this issue was not a bug in OpenLDAP, and the project went beyond its scope in tracking down why cyrus-sasl was behaving the way it was. Finding out test cases for you to explore is also beyond the scope of the OpenLDAP project when dealing with non-OpenLDAP issues. However, given what is known, i.e., that the NTLM code path was being called during SASL/GSSAPI binds, I would suggest you either set up a number of windows boxes that try and do SASL/GSSAPI auth with NTLM to a test server, or write a script that does that and run it from multiple systems. Some reference points: <http://www.netid.washington.edu/documentation/ldapAuth.aspx> It also seems it may be possible to use python-ldap to do this. I don't know if it is possible with Net::LDAP or Net::LDAPapi --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6384) ldap.conf - problem with comments
by h.b.furuseth＠usit.uio.no 18 Nov '09

18 Nov '09

masarati(a)aero.polimi.it writes: > Hash marks as line-long comment indicators is documented in slapd.conf(5). > It is also documented in recent 2.4 ldap.conf(5). It doesn't actually mention the word "comment" though. I'll tweak a bit so a search for that word will find it, and expand the examples a bit. -- Hallvard

1 0

Re: (ITS#6387) Valgrind reports issues in pcache
by masarati＠aero.polimi.it 18 Nov '09

18 Nov '09

masarati(a)aero.polimi.it wrote: > Full_Name: Pierangelo Masarati > Version: HEAD,re24,2.4.19 > OS: irrelevant? > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (131.175.154.146) > Submitted by: ando > > > See <http://www.openldap.org/lists/openldap-devel/200911/msg00015.html> The fix to ITS#6388 fixes the first valgrind warning of this ITS. p.

1 0

(ITS#6388) A timeout of { -1, 0 } allows to never time out
by masarati＠aero.polimi.it 18 Nov '09

18 Nov '09

Full_Name: Pierangelo Masarati Version: HEAD OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (131.175.154.146) Submitted by: ando Some code in back-ldap used a timeout of { -1, 0 } to disable any timeout set via ldap_set_option(). However, the code does not honor it (AFAIK). A fix that explicitly adds this feature is being committed (and documented in ldap_result(3)). p.

1 0

(ITS#6387) Valgrind reports issues in pcache
by masarati＠aero.polimi.it 18 Nov '09

18 Nov '09

Full_Name: Pierangelo Masarati Version: HEAD,re24,2.4.19 OS: irrelevant? URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (131.175.154.146) Submitted by: ando See <http://www.openldap.org/lists/openldap-devel/200911/msg00015.html> p.

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