- openldap-bugs - openldap.org

Re: (ITS#4996) Use SRV records to locate local server for command-line clients
by rra＠stanford.edu 11 Jun '07

11 Jun '07

ando <ando(a)sys-net.it> writes: > Committed to HEAD. Command-line clients now use DNS SRV to look up the > host names related to a DN and build a list of URIs for subsequent use. > To trigger, use -H "<proto>:///DN". The <host> portion must be empty, > and a DN must be present. The DN must be in the "dc=<component>" form; > it's turned into a domain and the host list is looked up using DNS SRV. > After that, a list of URIs is built using the returned host/ports, and > using <proto> as the LDAP scheme. Thank you! I've forwarded this information to the original Debian bug reporter who was interested in the feature in the hopes that he'll be able to test and provide feedback on the implementation. -- Russ Allbery (rra(a)stanford.edu) <http://www.eyrie.org/~eagle/>

1 0

Re: (ITS#5011) loglevel packet doesn't work
by ando＠sys-net.it 11 Jun '07

11 Jun '07

ando(a)sys-net.it wrote: > ... it's "packets". The man page (or the code) is wrong. ... but the man page is correct in HEAD; so it was fixed, but not backported. 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#5011) loglevel packet doesn't work
by ando＠sys-net.it 11 Jun '07

11 Jun '07

quanah(a)zimbra.com wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.3.35 > OS: mac os x > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (66.92.25.194) > > > The slapd.conf man page says: > > loglevel <integer> [...] > 2 (0x2 packet) debug packet handling > > but if you specify packet, slapd refuses to start, stating: > > /opt/zimbra/openldap-2.3.35.7/etc/openldap/slapd.conf: line 53: <loglevel> > unknown level "packet" ... it's "packets". The man page (or the code) is wrong. 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

(ITS#5011) loglevel packet doesn't work
by quanah＠zimbra.com 11 Jun '07

11 Jun '07

Full_Name: Quanah Gibson-Mount Version: 2.3.35 OS: mac os x URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (66.92.25.194) The slapd.conf man page says: loglevel <integer> [...] 2 (0x2 packet) debug packet handling but if you specify packet, slapd refuses to start, stating: /opt/zimbra/openldap-2.3.35.7/etc/openldap/slapd.conf: line 53: <loglevel> unknown level "packet" --Quanah

1 0

Re: (ITS#5008) Do you have the win32 version of OpenLDAP
by h.b.furuseth＠usit.uio.no 11 Jun '07

11 Jun '07

caojunliang(a)huawei.com writes: > I want to know whether or not the win32 version of OpenLDAP exsits. Please take this to the mailinglist openldap-software(a)openldap.org. The Issue Tracking System is for bug reports etc, not for help requests. This ITS will be closed. -- Regards, Hallvard

1 0

(ITS#5010) broken ber_encode_oid/ber_decode_oid()
by h.b.furuseth＠usit.uio.no 11 Jun '07

11 Jun '07

Full_Name: Hallvard B Furuseth Version: HEAD OS: URL: http://folk.uio.no/hbf/OpenLDAP/oid-encdec.txt Submission from: (NULL) (129.240.202.105) Submitted by: hallvard The 40*X+Y rule for first 2 components is decoded wrong, it should be X = val < 80 ? val/40 : 2 # X = 0, 1 or 2 Y = val - 40*X # Y is unlimited when X==2, <40 otherwise See X.690 8.19.4: ... (X*40) + Y: NOTE - This packing of the first two object identifier components recognizes that only three values are allocated from the root node, and at most 39 subsequent values from nodes reached by X = 0 and X = 1. 40*X+Y can take more than one octet. The functions allow buffer overruns. ber_decode_oid() if the oid has many small components. ber_encode_oid() for negative input (which becomes a large ulong), or if sizeof(long) == 8. The latter can just as easily be avoided by producing the bytes backwards and then reversing. They do not check much for invalid input or too large values. Possibly they ought to be a bit paranoid about that since they are used for certificates, I don't know. E.g. check that the BER encoding has "fewest possible octets" (X.690 8.19.2), i.e. no initial 0x80 in subidentifiers. ber_encode_oid() seems a bit strange about which errors it accepts and which ones it rejects. E.g. garbage after first 2 components is OK. The "assert(foo != NULL)"s are after "der = foo->bv_val":-) I enclose untested new versions. Will test and commit when I have time if someone says OK, but it depends e.g. on how paranoid the routines should or should not be. Or if they should trust the ber values to end with \0, for that matter. Finally, libldap/tls.c does not check if ber_decode_oid() fails.

1 0

Re: (ITS#5009) ldapsearch -C not in manpage
by dustin＠puryear-it.com 11 Jun '07

11 Jun '07

Thinking about this further, it looks like the manpage is really deferring to 'ldapsearch --help' since that is where the meat of the documentation is. There is some potential confusion here I think. What if the manpage just refers the reader to 'ldapsearch --help' for complete information? -- Puryear Information Technology, LLC Baton Rouge, LA * 225-706-8414 http://www.puryear-it.com Author: "Best Practices for Managing Linux and UNIX Servers" "Spam Fighting and Email Security in the 21st Century" Download your free copies: http://www.puryear-it.com/pubs/ebooks/

1 0

Re: (ITS#5009) ldapsearch -C not in manpage
by dustin＠puryear-it.com 11 Jun '07

11 Jun '07

By the way, I did verify that -C does work. It simply isn't in the manpage. Also, a quick grep of the binary: [root@samba openldap]# strings /usr/bin/ldapsearch | grep -- -C -C chase referrals (anonymously) This is a low priority documentation bug only. The binary works fine. -- Puryear Information Technology, LLC Baton Rouge, LA * 225-706-8414 http://www.puryear-it.com Author: "Best Practices for Managing Linux and UNIX Servers" "Spam Fighting and Email Security in the 21st Century" Download your free copies: http://www.puryear-it.com/pubs/ebooks/

1 0

(ITS#5009) ldapsearch -C not in manpage
by dustin＠puryear-it.com 11 Jun '07

11 Jun '07

Full_Name: Dustin Puryear Version: 2.213-7 OS: CentOS 4.3 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (72.242.176.166) The -C flag is not in the ldapsearch manpage. # rpm -q -a | grep openldap openldap-2.2.13-7.4E openldap-devel-2.2.13-7.4E openldap-servers-2.2.13-7.4E openldap-clients-2.2.13-7.4E # # man ldapsearch | grep -- -C # Alias info is there: # man ldapsearch | grep -- -a [-s base|one|sub] [-a never|always|search|find] [-l timelimit] ldapsearch is a shell-accessible interface to the ldap_search(3) -a never|always|search|find audio:< file:///tmp/ldapsearch-audio-a19924 jpegPhoto:< file:///tmp/ldapsearch-jpegPhoto-a19924 # # man ldapsearch | tail The OpenLDAP Project <http://www.openldap.org/> ACKNOWLEDGEMENTS OpenLDAP is developed and maintained by The OpenLDAP Project (http://www.openldap.org/). OpenLDAP is derived from University of Michigan LDAP 3.3 Release. OpenLDAP 2.2.13 2004/06/10 LDAPSEARCH(1) # # cat /etc/redhat-release CentOS release 4.3 (Final) #

1 0

Re: (ITS#5005) test017 fails
by ando＠sys-net.it 11 Jun '07

11 Jun '07

dieter(a)dkluenter.de wrote: > the patch fails, this is the patch reject file: That's probably because you cut'n'pasted from the email, where the tabs were probably replaced by whitespaces. I'll apply that fix if anyone confirms that cookie is legal at all. Cheers, 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#5005) test017 fails
by dieter＠dkluenter.de 10 Jun '07

10 Jun '07

Quanah Gibson-Mount <quanah(a)zimbra.com> writes: > --On June 8, 2007 6:43:50 PM +0000 dieter(a)dkluenter.de wrote: > >> Full_Name: Dieter Kluenter >> Version: HEAD >> OS: Linux >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (84.142.196.121) >> >> >> here the output of test017 logfiles >> >> ---slapd.1.log---------------- >> ber_scanf fmt (}) ber: >> <= get_ctrls: n=1 rc=2 err="Sync control : cookie parsing error" >> send_ldap_result: conn=7 op=1 p=3 >> send_ldap_result: err=2 matched="" text="Sync control : cookie parsing >> error" send_ldap_response: msgid=2 tag=101 err=2 > > Hm, is this possibly related to the fix for ITS#4977? If you revert > that checkin for syncprov.c today, does the test pass? > > > <http://www.openldap.org/devel/cvsweb.cgi/servers/slapd/overlays/syncprov.c.…> Unfortunately no chance, still the same error. -Dieter -- Dieter Klünter | Systemberatung http://www.dkluenter.de GPG Key ID:8EF7B6C6

1 0

Re: (ITS#5005) test017 fails
by dieter＠dkluenter.de 10 Jun '07

10 Jun '07

Pierangelo Masarati <ando(a)sys-net.it> writes: > dieter(a)dkluenter.de wrote: > > The problem is in slap_parse_sync_cookie(); when no cookie is passed, a > string containing "rid=001" is parsed. The parser expects it to end > with a comma. If passing "rid=001" is correct, the fix is trivial: > instead of checking for (*next != ','), check for (*next && *next != ','). > > Index: servers/slapd/ldapsync.c > =================================================================== > RCS file: /repo/OpenLDAP/pkg/ldap/servers/slapd/ldapsync.c,v > retrieving revision 1.42 > diff -u -r1.42 ldapsync.c > --- servers/slapd/ldapsync.c 18 May 2007 12:46:52 -0000 1.42 > +++ servers/slapd/ldapsync.c 9 Jun 2007 09:42:24 -0000 > @@ -180,7 +180,10 @@ > if ( !strncmp( next, "rid=", STRLENOF("rid=") )) { > rid_ptr = next; > cookie->rid = strtoul( &rid_ptr[ STRLENOF( > "rid=" ) ], &next, 10 ); > - if ( next == rid_ptr || next > end || *next != > ',' ) { > + if ( next == rid_ptr > + || next > end > + || ( *next && *next != ',' ) ) > + { > return -1; > } > if ( *next == ',' ) { > @@ -194,7 +197,10 @@ > if ( !strncmp( next, "sid=", STRLENOF("sid=") )) { > rid_ptr = next; > cookie->sid = strtoul( &rid_ptr[ STRLENOF( > "sid=" ) ], &next, 16 ); > - if ( next == rid_ptr || next > end || *next != > ',' ) { > + if ( next == rid_ptr > + || next > end > + || ( *next && *next != ',' ) ) > + { > return -1; > } > if ( *next == ',' ) { > > I'm not committing this fix because I'm not sure it doesn't break > anything else. the patch fails, this is the patch reject file: ---ldapsync.c.rej ------------------------------- *************** *** 180,186 **** if ( !strncmp( next, "rid=", STRLENOF("rid=") )) { rid_ptr = next; cookie->rid = strtoul( &rid_ptr[ STRLENOF( "rid=" ) ], &next, 10 ); - if ( next == rid_ptr || next > end || *next != ',' ) { return -1; } if ( *next == ',' ) { --- 180,189 ---- if ( !strncmp( next, "rid=", STRLENOF("rid=") )) { rid_ptr = next; cookie->rid = strtoul( &rid_ptr[ STRLENOF( "rid=" ) ], &next, 10 ); + if ( next == rid_ptr + || next > end + || ( *next && *next != ',' ) ) + { return -1; } if ( *next == ',' ) { *************** *** 194,200 **** if ( !strncmp( next, "sid=", STRLENOF("sid=") )) { rid_ptr = next; cookie->sid = strtoul( &rid_ptr[ STRLENOF( "sid=" ) ]. &next, 16 ); - if ( next == rid_ptr || next > end || *next != ',' ) { return -1; } if ( *next == ',' ) { --- 197,206 ---- if ( !strncmp( next, "sid=", STRLENOF("sid=") )) { rid_ptr = next; cookie->sid = strtoul( &rid_ptr[ STRLENOF( "sid=" ) ]. &next, 16 ); + if ( next == rid_ptr + || next > end + || ( *next && *next != ',' ) ) + { return -1; } if ( *next == ',' ) { -Dieter -- Dieter Klünter | Systemberatung http://www.dkluenter.de GPG Key ID:8EF7B6C6

1 0

Re: (ITS#4629) slapd failure on HP-UX 11.23/IA 64-bit
by h.b.furuseth＠usit.uio.no 10 Jun '07

10 Jun '07

Fixed in cvs (RE23 and HEAD) with a somewhat different patch. It should be more comprehensive than the old one, but testing on various systems is welcome anyway. -- Regards, Hallvard

1 0

Re: (ITS#4936) default modulepath
by ando＠sys-net.it 10 Jun '07

10 Jun '07

> No, they are installed in $(moduledir), which depends on LDAP_LIBEXECDIR > and --with-subdir. So, put that in some C variable or #define. Yes, I figured that out. I'll fix this later. 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#4936) default modulepath
by h.b.furuseth＠usit.uio.no 10 Jun '07

10 Jun '07

I wrote: > Use LDAP_LIBEXECDIR/openldap/, that's where modules get installed. > Try with ./configure --enable-overlays=mod --enable-monitor=mod. No, they are installed in $(moduledir), which depends on LDAP_LIBEXECDIR and --with-subdir. So, put that in some C variable or #define. -- Regards, Hallvard

1 0

(ITS#5007) Compilation problems
by h.b.furuseth＠usit.uio.no 09 Jun '07

09 Jun '07

Full_Name: Hallvard B Furuseth Version: HEAD, RE23 OS: HP-UX, OSF1, non-gcc URL: Submission from: (NULL) (129.240.202.105) Submitted by: hallvard HEAD/RE23: liblber/sockbuf.c uses pointer arithmetic on void*, a gcc extension. HEAD: OSF1 pthread.h defines "leave" as an exception keyword, which breaks slapd and bdb. I'll rename "leave" labels to "done" or "finish". liblutil/getpeereid.c breaks if LDAP_PF_LOCAL_SENDMSG is defined but MSG_WAITALL is not. (Not sure why that's compiled at all after the ldapi trouble, but that's another matter.) I'll fix it by #ifdeffing MSG_WAITALL in getpeereid.c rather than where LDAP_PF_LOCAL_SENDMSG is defined, since we need LDAP_PF_LOCAL_SENDMSG to decide whether to send a dummy abandon to previous OpenLDAP server versions.

1 0

Re: (ITS#4936) default modulepath
by h.b.furuseth＠usit.uio.no 09 Jun '07

09 Jun '07

ando(a)sys-net.it writes: > It would be pretty straightforward to call lt_dlsetsearchpath() > (actually, the module_path() wrapper) from module_init() with a default > value. This could be, for example, LDAP_LIBEXECDIR, where slapd itself > gets installed by default. Use LDAP_LIBEXECDIR/openldap/, that's where modules get installed. Try with ./configure --enable-overlays=mod --enable-monitor=mod. -- Regards, Hallvard

1 0

Re: (ITS#4996) Use SRV records to locate local server for command-line clients
by ando＠sys-net.it 09 Jun '07

09 Jun '07

Committed to HEAD. Command-line clients now use DNS SRV to look up the host names related to a DN and build a list of URIs for subsequent use. To trigger, use -H "<proto>:///DN". The <host> portion must be empty, and a DN must be present. The DN must be in the "dc=<component>" form; it's turned into a domain and the host list is looked up using DNS SRV. After that, a list of URIs is built using the returned host/ports, and using <proto> as the LDAP scheme. Please test. 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#4936) default modulepath
by ando＠sys-net.it 09 Jun '07

09 Jun '07

It would be pretty straightforward to call lt_dlsetsearchpath() (actually, the module_path() wrapper) from module_init() with a default value. This could be, for example, LDAP_LIBEXECDIR, where slapd itself gets installed by default. Comments? 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#4943) tpool.c pause vs. finish
by h.b.furuseth＠usit.uio.no 09 Jun '07

09 Jun '07

I wrote: > I'll just make [the hash table] chained. (...) > Solves the multi-pool problem too. No it doesn't. pool_pause() would stilll only pause one pool, while purgekey() needs all pools to be paused. I guess I'll chain it anyway. I forgot one bug in my summary: Slapd does not always check if pool_submit() and pool_setkey() succeed, even though failure is not a bug. (They can run into some limits.) pool_submit(): daemon.c:slapd_daemon_task() with rtask->routine connection.c:connections_shutdown() with c_clientfunc connection.c:connection_read() with c_clientfunc back-bdb/tools.c:bdb_tool_entry_open() with trickle and index tasks pool_setkey(): connection.c:connection_fake_init2() for slapi object extensions backend.c:be_isroot_pw() for SLAPD_SPASSWD passwd.c:slap_passwd_check() for SLAPD_SPASSWD sl_malloc.c:slap_sl_mem_create() back-bdb/search.c:search_stack() back-meta/conn.c:meta_back_candidates_get() slapd-modules/smbk5pwd/smbk5pwd.c:smbk5pwd_op_bind() -- Regards, Hallvard

1 0

Re: (ITS#4986) manageDSAit might control cause problems in database selection
by ando＠sys-net.it 09 Jun '07

09 Jun '07

A tentative fix is in HEAD (servers/slapd/backend.c 1.377 -> 1.378). Please test. 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#4943) tpool.c pause vs. finish
by h.b.furuseth＠usit.uio.no 09 Jun '07

09 Jun '07

hyc(a)symas.com writes: > h.b.furuseth(a)usit.uio.no wrote: >> * When a thread is finishing, make it go active for context_reset(). >> Should make slapi module destructors safer, and I don't see that it >> can hurt. > > I don't understand this. Let me dig a bit back in the ITS... "context_reset() can call connection_fake_destroy(), which via slapi_int_free_object_extensions() calls slapi module destructors, which can do who-knows-what." >> * I'd like to rename thread contexts to tasks(?) and user contexts back >> to contexts (as in RE23). The current terminology is confusing. > > I don't care about this either way. Then I will. I still confuse myself sometimes, and I certainly would if I came back to this code next year. >> (...) > Never use malloc unless absolutely necessary. We have enough problems > with heap fragmentation already. Aha. OK. >> * Scheduling: If several threads call pool_pause(), then once there is a >> pause tpool does not schedule them all. They could get handled then, >> or another thread could undo the pause so tpool would wait to pause >> again. Is that deliberate? > > I don't understand the question. The point of the pause is to prevent > any other thread (in the pool) from running. Why should tpool schedule > any other threads at this point? Two threads call pool_pause(). Eventually the pool gets paused, and one pool_pause() call returns. When that thread calls pool_resume(), the other thread waiting in pool_pause() may or may not get scheduled. >> - pool_context() breaks if several ldap_pvt_thread_t bit patterns can >> represent the same thread ID: TID_HASH() would give different hashes >> for the same thread, and pool_context() stops searching when it hits >> a slot with ctx == NULL. (My previous bug report was a bit wrong.) > > How can a single thread ID be represented by multiple bit patterns? A struct/union with padding bytes seems the least unlikely possibility. A pointer in hardware where several address representations map to the same physical address, and the compiler handles that by normalizing pointers when they are compared/subtracted. Like DOS "huge" pointers would have been if the compiler normalized them when comparing them instead of when incrementing/decrementing them. 20-bit address bus, 32-bit pointers, physical address = 16 * <segment half of pointer> + <offset half of pointer>. Or, not that I take this too seriously: A pthread implementation which uses e.g. a 32-bit integer type for thread IDs but just ignores the top 22 bits. The Posix spec seems to allow that, and thread IDs are to be compared with pthread_equal(). >> The best fix would be to use use real thread-specific data instead. >> Just one key with the ctx for now, that minimizes the changes. OTOH >> it also means we'll do thread-specific key lookup twice - first in >> pthread to get the ctx, and then in ltu_key[] to find our data. >> Anyway, I said I'd do that later but might as well get on with it, >> at least for pthreads. Except I don't know if that's OS-dependent >> enough that it should wait for RE24? > > The best fix may be to just use the address of the thread's stack as the > thread ID. That's actually perfect for our purpose. How does a function called from somewhere inside the thread know that address? That's almost what the user context is, and thus what thread_keys[] maps the thread ID to. >> - thread_keys is a poor hash table implementation with a poor hash >> function. > > Ideally it would not be a hash table at all, but a direct lookup based > on the thread ID. If we can. See above. Anyway, I don't know why I keep kvetching about the hash table implementation. I'll just make it chained. As I finally figured out, that can be done without mallocs. Solves the multi-pool problem too. >> * I wonder if there are long-lived ldap_pvt_thread_cond_wait(), >> [r]mutex_lock() or rdwr_[rw]lock() calls which should make the thread >> go inactive first (after waiting for any pause to finish), so that >> (a) a pool_pause() will not block waiting for them, and >> (b) all threads in the pool can't be blocked in long waits without >> tpool knowing about it. > > Long-lived lock calls would be a quite noticeable bug. This seems to be > a non-issue. Well, it'd have to be with code which is very rarely executed, or unusual configurations. But yes, I feel relaxed enough about it. >> * back-bdb/tools.c uses pool_submit() to start long-lived threads: >> (...) > Tool threads are completely separate from slapd threads. This is not an > issue. Fine. I don't understand that in this context, but I'll take your word for it:-) >> * slapd/bconfig.c maintains its own idea of the max number of threads >> in connection_pool_max and slap_tool_thread_max, which does not match >> tpool's idea if the limit is <=0 or larger than LDAP_MAXTHR. >> >> Since slapd acts on its own count, I imagine that can cause breakage. >> Simplest fix might be to set max #threads and then read it back, >> I haven't checked. Would need to return LDAP_MAXTHR instead of 0 >> for "as many as allowed". Note however also the issue above: >> tpool's idea of actually available threads can be too high too. > > The practical limits are actually pretty low. Even if you're on a 1024 > processor machine with many terabytes of RAM, it's not a good idea to > have many thousands of threads... Scheduler overhead would overshadow > any useful work. OK. I forgot how much RAM a slapd thread requires. But then it won't hurt to give slapd a max limit lower than LDAP_MAXTHR either. >> * I said my new ltp_pause waits might be too aggressive. Maybe I should >> clarify: I don't see any instances where they can be dropped, but it's >> possible that slapd expects pauses to be less aggressive somewhere. > > I don't understand this comment. Clarifying the clarification: I don't know slapd well enough to know if the extra pauses do something bad to it. >> Oh, the comment /* no open threads at all?!? */: That's not strange. >> Happens in the first pool_submit() call(s) if thread_create() fails. >> Though in that case there was no danger of removing the wrong ctx >> from ltp_pending_list after all (fixed in rev 1.63). > > (Sure, but thread_create() should never fail if you have a sane > configuration.) And if the rest of the machine doesn't run wild. I imagine thread_create() can fail when fork() can fail on some OSes. -- Regards, Hallvard

1 0

Re: (ITS#5003) issue about upper_needs_cast
by ando＠sys-net.it 09 Jun '07

09 Jun '07

caojunliang(a)huawei.com wrote: > when I set the option upper_needs_cast as Yes.It only takes effect on id_query > when adding an entry,but does not take effect on child id query when deleting an > entry. > > I found that in the src file back-sql/init.c > > line 374 --379 > > there are not operation about upper cast. > > I want to know if what I think is right. Not clear what's your point. "upper_needs_cast" is a hack to work around the fact that some RDBMSes need an explicit cast before passing a literal into whatever "uppercase" function they provide. Can you point out what's the problem and what's the expected behavior? I don't see any literal passed to the query that looks up the parent's and that needs any special treatment. A log of the offending operation, and an example of what you'd consider correct, would help. 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#4965) slapd stops if access to cn=monitor is restricted
by ando＠sys-net.it 09 Jun '07

09 Jun '07

This is now made consistent in HEAD: the inability to register custom monitor stuff always results in a failure. Note that the software provides different means to prevent this feature: a) allow anonymous read access to the monitor database b) define a rootdn (even without any possibility to auth) for the monitor database c) disable monitoring for all bdb/hdb databases 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#5005) test017 fails
by ando＠sys-net.it 09 Jun '07

09 Jun '07

dieter(a)dkluenter.de wrote: The problem is in slap_parse_sync_cookie(); when no cookie is passed, a string containing "rid=001" is parsed. The parser expects it to end with a comma. If passing "rid=001" is correct, the fix is trivial: instead of checking for (*next != ','), check for (*next && *next != ','). Index: servers/slapd/ldapsync.c =================================================================== RCS file: /repo/OpenLDAP/pkg/ldap/servers/slapd/ldapsync.c,v retrieving revision 1.42 diff -u -r1.42 ldapsync.c --- servers/slapd/ldapsync.c 18 May 2007 12:46:52 -0000 1.42 +++ servers/slapd/ldapsync.c 9 Jun 2007 09:42:24 -0000 @@ -180,7 +180,10 @@ if ( !strncmp( next, "rid=", STRLENOF("rid=") )) { rid_ptr = next; cookie->rid = strtoul( &rid_ptr[ STRLENOF( "rid=" ) ], &next, 10 ); - if ( next == rid_ptr || next > end || *next != ',' ) { + if ( next == rid_ptr + || next > end + || ( *next && *next != ',' ) ) + { return -1; } if ( *next == ',' ) { @@ -194,7 +197,10 @@ if ( !strncmp( next, "sid=", STRLENOF("sid=") )) { rid_ptr = next; cookie->sid = strtoul( &rid_ptr[ STRLENOF( "sid=" ) ], &next, 16 ); - if ( next == rid_ptr || next > end || *next != ',' ) { + if ( next == rid_ptr + || next > end + || ( *next && *next != ',' ) ) + { return -1; } if ( *next == ',' ) { I'm not committing this fix because I'm not sure it doesn't break anything else. 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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs