- openldap-bugs - openldap.org

Re: (ITS#5404) back-ldap fails intermittently with 80 Internal (implementation specific) error
by toby＠inf.ed.ac.uk 10 Mar '08

10 Mar '08

On 8 Mar 2008, at 14:45, Pierangelo Masarati wrote: > Please test and report; > > servers/slapd/back-ldap/bind.c > new revision: 1.244; previous revision: 1.243 > > The patch applies straightforwardly to re23 only if the first chunk is > omitted. OK, thanks. I'll patch and put into testing. Cheers Toby

1 0

Re: (ITS#5407) slapd hang in multimaster test
by hyc＠symas.com 08 Mar '08

08 Mar '08

ando(a)sys-net.it wrote: > This was after the > > syncprov.c 1.215 -> 1.216 > > commit for ITS#5405, which required some cleanup to compile. I'm posting this > as a separate ITS just to keep track, but I need to shut the hanging process > down. If this is related to ITS#5405, it can be closed. It was unrelated. It seems to be similar to this http://www.openldap.org/lists/openldap-devel/200802/msg00093.html Should be OK with HEAD now, please test. -- -- 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#4730) Overlay that generates operational attributes to support GUI interaction
by michael＠stroeder.com 08 Mar '08

08 Mar '08

I'd be interested to add support for something like this to my LDAP client. BTW: I'd vote against ";x-allowed" or ";x-required" since a schema-aware client can already determine this in a non-proprietary way from the subschema. The overlay's source is quite old. Does it still build with recent HEAD? Ciao, Michael.

1 0

(ITS#5407) slapd hang in multimaster test
by ando＠sys-net.it 08 Mar '08

08 Mar '08

Full_Name: Pierangelo Masarati Version: HEAD OS: GNU/Linux 2.6 (CentOS 5.1) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.63.140.131) Submitted by: ando I have the slapd starting on port 9013 in test050 (with back-hdb, if it matters at all) that's hanging. The test, so far, got to >>>>> Starting test050-syncrepl-multimaster ... running defines.sh Initializing server configurations... Starting producer slapd on TCP/IP port 9011... Using ldapsearch to check that producer slapd is running... Inserting syncprov overlay on producer... Starting consumer slapd on TCP/IP port 9012... Using ldapsearch to check that consumer slapd is running... Configuring syncrepl on consumer... Starting consumer2 slapd on TCP/IP port 9013... Using ldapsearch to check that consumer2 slapd is running... Configuring syncrepl on consumer2... Adding schema and databases on producer... Using ldapadd to populate producer... Waiting 20 seconds for syncrepl to receive changes... Using ldapsearch to check that syncrepl received database changes... Using ldapsearch to check that syncrepl received database changes on consumer2... I could attach the process with gdb; it yields: thread apply all bt Thread 8 (Thread 1081371536 (LWP 19254)): #0 0x40000402 in __kernel_vsyscall () #1 0x00d5b256 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #2 0x0821197c in ldap_pvt_thread_cond_wait (cond=0x94cc1ec, mutex=0x94cc1d4) at thr_posix.c:277 #3 0x08210598 in ldap_pvt_thread_pool_destroy (tpool=0x8345318, run_pending=1) at tpool.c:570 #4 0x08081b3e in slapd_daemon_task (ptr=0x0) at daemon.c:2578 #5 0x00d5745b in start_thread () from /lib/libpthread.so.0 #6 0x001cf24e in clone () from /lib/libc.so.6 Thread 7 (Thread 1085569936 (LWP 19257)): #0 0x40000402 in __kernel_vsyscall () #1 0x00d5b256 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #2 0x0821197c in ldap_pvt_thread_cond_wait (cond=0x94cc1ec, mutex=0x94cc1d4) at thr_posix.c:277 #3 0x082107fe in ldap_int_thread_pool_wrapper (xpool=0x94cc1d0) at tpool.c:654 #4 0x00d5745b in start_thread () from /lib/libpthread.so.0 #5 0x001cf24e in clone () from /lib/libc.so.6 Thread 6 (Thread 1089768336 (LWP 19258)): #0 0x40000402 in __kernel_vsyscall () #1 0x00d5b256 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #2 0x0821197c in ldap_pvt_thread_cond_wait (cond=0x94cc21c, mutex=0x94cc1d4) at thr_posix.c:277 #3 0x08210bb4 in ldap_pvt_thread_pool_pause (tpool=0x8345318) at tpool.c:736 #4 0x08072ddb in config_back_add (op=0x40f47db4, rs=0x40f47a44) at bconfig.c:4548 #5 0x080fe265 in overlay_op_walk (op=0x40f47db4, rs=0x40f47a44, which=op_add, oi=0x9517a40, on=0x0) at backover.c:653 #6 0x080fe41a in over_op_func (op=0x40f47db4, rs=0x40f47a44, which=op_add) at backover.c:705 #7 0x080fe526 in over_op_add (op=0x40f47db4, rs=0x40f47a44) at backover.c:751 #8 0x080f3700 in syncrepl_entry (si=0x951af10, op=0x40f47db4, entry=0x94f5db4, modlist=0x40f47bcc, syncstate=1, syncUUID=0x40f47c24, syncCSN=0x95191f0) at syncrepl.c:2052 #9 0x080ef610 in do_syncrep2 (op=0x40f47db4, si=0x951af10) at syncrepl.c:844 #10 0x080f0c40 in do_syncrepl (ctx=0x40f48210, arg=0x951b170) at syncrepl.c:1233 #11 0x08210871 in ldap_int_thread_pool_wrapper (xpool=0x94cc1d0) at tpool.c:663 #12 0x00d5745b in start_thread () from /lib/libpthread.so.0 #13 0x001cf24e in clone () from /lib/libc.so.6 Thread 5 (Thread 1095019408 (LWP 19260)): #0 0x40000402 in __kernel_vsyscall () #1 0x001b3f7c in sched_yield () from /lib/libc.so.6 #2 0x0821190e in ldap_pvt_thread_yield () at thr_posix.c:232 #3 0x081f04a9 in syncprov_op_mod (op=0x41449d64, rs=0x414499f4) at syncprov.c:1783 #4 0x080fe1e5 in overlay_op_walk (op=0x41449d64, rs=0x414499f4, which=op_add, oi=0x9517a40, on=0x9519630) at backover.c:643 #5 0x080fe41a in over_op_func (op=0x41449d64, rs=0x414499f4, which=op_add) at backover.c:705 #6 0x080fe526 in over_op_add (op=0x41449d64, rs=0x414499f4) at backover.c:751 #7 0x080f3700 in syncrepl_entry (si=0x9518440, op=0x41449d64, entry=0x94f5e54, modlist=0x41449b7c, syncstate=1, syncUUID=0x41449bd4, syncCSN=0x0) at syncrepl.c:2052 #8 0x080ef610 in do_syncrep2 (op=0x41449d64, si=0x9518440) at syncrepl.c:844 #9 0x080f0c40 in do_syncrepl (ctx=0x4144a210, arg=0x9516a48) at syncrepl.c:1233 #10 0x08084f67 in connection_read_thread (ctx=0x4144a210, argv=0x9) at connection.c:1213 #11 0x08210871 in ldap_int_thread_pool_wrapper (xpool=0x94cc1d0) at tpool.c:663 #12 0x00d5745b in start_thread () from /lib/libpthread.so.0 #13 0x001cf24e in clone () from /lib/libc.so.6 Thread 4 (Thread 1099217808 (LWP 19261)): #0 0x40000402 in __kernel_vsyscall () #1 0x00d5b256 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #2 0x0821197c in ldap_pvt_thread_cond_wait (cond=0x94cc1ec, mutex=0x94cc1d4) at thr_posix.c:277 #3 0x082107fe in ldap_int_thread_pool_wrapper (xpool=0x94cc1d0) at tpool.c:654 #4 0x00d5745b in start_thread () from /lib/libpthread.so.0 #5 0x001cf24e in clone () from /lib/libc.so.6 Thread 3 (Thread 1106574224 (LWP 19264)): #0 0x40000402 in __kernel_vsyscall () #1 0x00d5b256 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #2 0x0821197c in ldap_pvt_thread_cond_wait (cond=0x94cc1ec, mutex=0x94cc1d4) at thr_posix.c:277 #3 0x0821073a in ldap_int_thread_pool_wrapper (xpool=0x94cc1d0) at tpool.c:615 #4 0x00d5745b in start_thread () from /lib/libpthread.so.0 #5 0x001cf24e in clone () from /lib/libc.so.6 Thread 2 (Thread 1110772624 (LWP 19266)): #0 0x40000402 in __kernel_vsyscall () #1 0x00d5b256 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #2 0x0821197c in ldap_pvt_thread_cond_wait (cond=0x94cc1ec, mutex=0x94cc1d4) at thr_posix.c:277 #3 0x082107fe in ldap_int_thread_pool_wrapper (xpool=0x94cc1d0) at tpool.c:654 #4 0x00d5745b in start_thread () from /lib/libpthread.so.0 #5 0x001cf24e in clone () from /lib/libc.so.6 Thread 1 (Thread 1074717776 (LWP 19253)): #0 0x40000402 in __kernel_vsyscall () #1 0x00d58557 in pthread_join () from /lib/libpthread.so.0 #2 0x082118e7 in ldap_pvt_thread_join (thread=1081371536, thread_return=0x0) at thr_posix.c:197 #3 0x08081c36 in slapd_daemon () at daemon.c:2644 #4 0x0806708c in main (argc=8, argv=0xbfe2cd04) at main.c:946 #0 0x40000402 in __kernel_vsyscall () This was after the syncprov.c 1.215 -> 1.216 commit for ITS#5405, which required some cleanup to compile. I'm posting this as a separate ITS just to keep track, but I need to shut the hanging process down. If this is related to ITS#5405, it can be closed. p.

1 0

(ITS#5406) slapd-meta(5) does not mention idassert-* directives
by ando＠sys-net.it 08 Mar '08

08 Mar '08

Full_Name: Pierangelo Masarati Version: HEAD/re24/re23 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.63.140.131) Submitted by: ando See subject

1 0

Re: (ITS#5396) Too much open connections
by ando＠sys-net.it 08 Mar '08

08 Mar '08

ecip(a)gmv.es wrote: > Hi all, using openldap 2.4.8 as a metadirectory server in front of a couple of > Active Directory Servers and a local database we have found an issue with the > number of ESTABLISHED connections. > > This is a part of the slapd configuration file: > > backend meta > database meta > > ## Sufijo del arbol mostrado por el metadirectorio y usuario > ## administrador del mismo(superusuario de ldap). > suffix "dc=gmv,dc=es" > rootdn "cn=diradmin,dc=gmv,dc=es" > ## Password del superusuario, pasar a texto cifrado con slappasswd. > rootpw secret > > ############################################## > ### Opciones comunes a todo el metadirectorio. > ############################################## > ######################################### > #### Directivas comunes de configuracion. > ## TTL para tirar una conexion, aunque no este inactiva (6 minutos). > conn-ttl 360 > ## Version del protocolo LDAP a utilizar. > protocol-version 3 > ## Accion ante un referral. > chase-referrals no > ## TTL para tirar una conexion inactiva (5 minutos). > idletimeout 300 > ##################################################################### > ### Definicion del LDAP remoto para las consultas de informacion de > ### usuario y grupos UNIX desde maquinas que son clientes LDAP. > ##################################################################### > ## Definicion de los servidores target remotos a consultar. > ## Se consultara el primer servidor remoto que responda. > ## Defino una lista de dcs que pueden responder para el contexto de > ## nombre dc=gmv,dc=es. Primer target con sus parametros de configuracion. > uri "ldap://gmvdc1.gmv.es/DC=gmv,DC=es ldap://gmvdc2.gmv.es/" > idle-timeout 300 > ## Habilitamos el sistema de reescritura para las consultas. > rewriteEngine on > overlay rwm > > and the output of the netstat -an command shows too much ESTABLISHED connections > between the metadirectory and the remote servers. > > After a while, the process runs out of file descriptors. There seems to be no clear indication of a software bug, but rather a resource exhaustion, which could be reduced by properly identifying how the proxy works and how the clients exploit its functionalities. Few comments: - why do you use back-meta with just one URI? use back-ldap instead - why do you enable the rewrite engine for that uri but you don't specify any rewrite rule? Is your server so performing to deserve wasting some cycles? - why do you add a slapo-rwm (not needed with back-meta, since it has built-in rewrite capabilities you don't need, but you just switched on, see previous remark)? Again, do you urge to reduce the performances of your proxy? With respect to resource exhaustion, it might depend on the usage you make of your system. Are you using it for multiple authentications on the same client connection? In that case, you might need to look at the "single-conn" directive; in that case, if your clients are using authenticated connections for repeated operations, you might look at idassert-bind (I note it's not documented in slapd-meta(5), but it's identical to that for slapd-ldap(5), except it's on a per-target basis). Hope this helps. I suggest you move discussion to openldap-software, to find out how to improve your configuration. 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#5404) back-ldap fails intermittently with 80 Internal (implementation specific) error
by ando＠sys-net.it 08 Mar '08

08 Mar '08

Please test and report; servers/slapd/back-ldap/bind.c new revision: 1.244; previous revision: 1.243 The patch applies straightforwardly to re23 only if the first chunk is omitted. 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#5404) back-ldap fails intermittently with 80 Internal (implementation specific) error
by ando＠sys-net.it 08 Mar '08

08 Mar '08

toby(a)inf.ed.ac.uk wrote: > The backtrace (in ldap_host_connected_to) is: > > (gdb) bt > #0 ldap_host_connected_to (sb=0xb4124950, host=0x81b0efb "localhost") > at os-ip.c:586 > #1 0x081394b5 in ldap_int_sasl_bind (ld=0xb4131058, dn=0x0, > mechs=<value optimized out>, sctrls=0x0, cctrls=0x0, flags=2, > interact=0x81293b0 <lutil_sasl_interact>, defaults=0x892df98) > at cyrus.c:643 > #2 0x0813b45d in ldap_sasl_interactive_bind_s (ld=0xb4131058, dn=0x0, > mechs=0x88bef98 "GSSAPI", serverControls=0x0, clientControls=0x0, flags=2, > interact=0x81293b0 <lutil_sasl_interact>, defaults=0x892df98) at sasl.c:479 > #3 0x08109625 in ldap_back_dobind_int (lcp=0xb370e0a8, op=0x8952900, > rs=0xb370f1c4, sendok=<value optimized out>, retries=0, dolock=1) > at bind.c:1997 > #4 0x080dab4b in ldap_back_search (op=0x8952900, rs=0xb370f1c4) > at search.c:166 Actually, I was too quick: the above stack backtrace looks inconsistent: there is a call to ldap_sasl_interactive_bind_s at bind.c:1997, but it's not inside ldap_back_dobind_int(); it's rather in ldap_back_proxy_authz_bind(), which might be called by ldap_back_dobind_int(). It might be useful if you try to see if the issue can be reproduced with a non-optimized build, so that we can see the actual behavior of the code from the backtrace, and see some arg values that are now missing. What could actually be happening is that although the authentication fails, the fact that LDAP_OTHER is returned is not considered a condition that requires to invalidate the connection handler, while probably it should. I'll provide a fix in this sense. 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#5404) back-ldap fails intermittently with 80 Internal (implementation specific) error
by ando＠sys-net.it 08 Mar '08

08 Mar '08

toby(a)inf.ed.ac.uk wrote: > (gdb) bt > #0 ldap_host_connected_to (sb=0xb4124950, host=0x81b0efb "localhost") > at os-ip.c:586 > #1 0x081394b5 in ldap_int_sasl_bind (ld=0xb4131058, dn=0x0, > mechs=<value optimized out>, sctrls=0x0, cctrls=0x0, flags=2, > interact=0x81293b0 <lutil_sasl_interact>, defaults=0x892df98) > at cyrus.c:643 > #2 0x0813b45d in ldap_sasl_interactive_bind_s (ld=0xb4131058, dn=0x0, > mechs=0x88bef98 "GSSAPI", serverControls=0x0, clientControls=0x0, flags=2, > interact=0x81293b0 <lutil_sasl_interact>, defaults=0x892df98) at sasl.c:479 > #3 0x08109625 in ldap_back_dobind_int (lcp=0xb370e0a8, op=0x8952900, > rs=0xb370f1c4, sendok=<value optimized out>, retries=0, dolock=1) > at bind.c:1997 > #4 0x080dab4b in ldap_back_search (op=0x8952900, rs=0xb370f1c4) > at search.c:166 I think I see the issue: either ldap_back_search() or ldap_back_dobind_int() should invalidate that handle. I'll see if I can fix it. 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#5402) Sets: Hyphens within attribute names considered as separate tokens
by ando＠sys-net.it 08 Mar '08

08 Mar '08

Since the ITS' purpose consists in helping tracking issues, please keep it in CC in replies, otherwise you defeat its purpose. Norbert Rittel wrote: > Am 06.03.2008 um 23:32 schrieb Pierangelo Masarati: > >> The code that parses attribute descriptions appears to be definitely >> broken, since it does allow underscores but no hyphens, and it does not >> allow digits in attribute descriptions (including OIDs). This should be >> fixed now in HEAD, and the patch >> >> servers/slapd/sets.c 1.41 -> 1.42 >> >> seems to apply to current re24 and re23 without much hassle. >> >> Please test, p. > > Wow, really great turnaround :-) > > To test I've downloaded the current OpenLDAP sources used in Mac OS X > 10.5.2 from Apple's site at > > http://www.opensource.apple.com/darwinsource/10.5.2/ > > But unfortunately issuing a 'make' (on the unaltered source already) > results in an error (config.log enclosed if you want to take a look). > I've sent a follow-up to Apple, with A LOT of luck someone at > engineering there will come back to me on that > > If you have access to a Mac OS X (Server) box you might want to give it > a try, but I fully understand if this is not the platform you're working > on ;-) This error appears to have nothing to do with the proposed fix, so you should rather post to OpenLDAP-software (and, only in case another issue surfaces, file a separate ITS). I do not develop on that platform, nor I have access to it, so I'm afraid I can't 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

(ITS#5405) syncprov psearch race condition
by hyc＠OpenLDAP.org 07 Mar '08

07 Mar '08

Full_Name: Howard Chu Version: 2.4 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.91.220.157) Submitted by: hyc It's possible for a new update to be recorded after the syncprov_qtask has examined its response queue but before it has removed itself from the slapd runqueue. In this case, the qtask will not process the new response right away, it won't see it until the next time an operation occurs on the server.

1 0

Re: (ITS#5339) wrong referral from back-bdb
by hyc＠symas.com 07 Mar '08

07 Mar '08

Hallvard B Furuseth wrote: > Howard Chu writes: >> h.b.furuseth(a)usit.uio.no wrote: >>> Howard Chu writes: >>>>> Both RFCs disagree. >>>> They are wrong. Or at least, under-specified. In X.501 section 17.3 >>>> "Directory Distribution Model" it's quite clear that all of the >>>> components of a distributed directory must belong to a single DIT. >>> Which is not true in the LDAP world, and I don't know about today's >>> X.500 world. Nameflow died and Dante was unable to resurrect it. Maybe >>> the X.500 world has also switched to 'dc' structure, I don't know. >>> >>> Anyway, LDAP is not X.500. >> RFC4510 Section 2 "Relationship to X.500" >> (...) An LDAP server MUST act in accordance with the X.500 (1993) >> series (...) > > Except when it doesn't. Like the various implications of sending text > instead of ASN.1 and numeric OIDs. That's irrelevant. The service model and the on-the-wire encoding are two completely different things. The encoding of LDAP is of course different from DAP, but both are required to provide the same service model. Just as DSML is encoded differently, but still delivers the X.500 service model. >> (...) LDAPv1 had no referrals. When they were introduced in LDAPv2 >> it's clear that nobody knew what they were doing, or nobody wanted to >> tackle the glaring absence of an analogue to X.500 DSP. > LDAPv2 (the standard) has no referrals. The Umich implementation > introduced them as a hack: It stuffed them into the errorMessage field. > LDAPv3 moved them into the standard. And speaking for my own little > corner of the standardization process, I definitly was ignorant about > them and wanted nothing to do with them. I've still never had any use > for LDAP referrals. > >> They should never have been introduced. We're stuck with them for >> now, but we can at least try to make them make sense. > > Well, take it up with ldapext. And add an option to slapd to reject > attempts to add 'ref' attrs with a DN, or whatever. > > For now, once the directory contains a 'ref' URL which includes the DN, > I don't see any reason not to rewrite like the spec says. Whatever the > "right answer" is, a referral with an un-rewritten DN seems worse than > with a rewritten one. > Regarding the branches of bdb_referrals() and ldif_back_referrals() > which rewrite default_referral: I suggest we delete it. > The back-ldif code breaks exactly as one would expect: With > referral ldap://urgle/ > database ldif > suffix o=foo > and an empty database, ldapcompare cn=bar,o=foo gives a referral to > urgle. So does ldapadd of o=foo:-( I seem to remember someone meant > the latter was correct and there was a control to prevent it at some > point, maybe that is related. back-bdb has a test which prevents this > referral in case of the suffix dn, but not for superior DNs. But I > don't see why it would not be just as buggy for superiors, if it could > happen. Yeah, I noticed that in the source recently and thought that was bogus. The default referral was only supposed to be used when fielding a query for a completely unknown naming context. However, e.g. back-bdb tries to use the default referral whenever a requested entry does not exist, and leaves it to the frontend to turn that result back into NoSuchObject as appropriate. For cases where the context is known, but no data is present, it should just return NoSuchObject. Sending the client off to who-knows-where is completely wrong in this case. And of course, there should have been genuine X.500-style knowledge references, explicitly set for superior, peer, and subordinate DSAs. Any request that doesn't match the known naming contexts, or any of the explicitly defined knowledge references, should simply fail with NoSuchObject. The notion of "default referral" is just sloppy all around. -- -- 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#5339) wrong referral from back-bdb
by h.b.furuseth＠usit.uio.no 07 Mar '08

07 Mar '08

I wrote: > And speaking for my own little corner of the standardization process, > I definitly was ignorant about them and wanted nothing to do with > them. I've still never had any use for LDAP referrals. Hmm. Now that I think of it, that's not true. I did get involved in the details, sort of, but indeed not with the "big picture". It's just in real life I never used them, so to me it was almost a purely theoretical exercise. -- Hallvard

1 0

Re: (ITS#5339) wrong referral from back-bdb
by h.b.furuseth＠usit.uio.no 07 Mar '08

07 Mar '08

Howard Chu writes: >h.b.furuseth(a)usit.uio.no wrote: >>Howard Chu writes: >>>> Both RFCs disagree. >>> >>> They are wrong. Or at least, under-specified. In X.501 section 17.3 >>> "Directory Distribution Model" it's quite clear that all of the >>> components of a distributed directory must belong to a single DIT. >> >> Which is not true in the LDAP world, and I don't know about today's >> X.500 world. Nameflow died and Dante was unable to resurrect it. Maybe >> the X.500 world has also switched to 'dc' structure, I don't know. >> >> Anyway, LDAP is not X.500. > > RFC4510 Section 2 "Relationship to X.500" > (...) An LDAP server MUST act in accordance with the X.500 (1993) > series (...) Except when it doesn't. Like the various implications of sending text instead of ASN.1 and numeric OIDs. > (...) LDAPv1 had no referrals. When they were introduced in LDAPv2 > it's clear that nobody knew what they were doing, or nobody wanted to > tackle the glaring absence of an analogue to X.500 DSP. LDAPv2 (the standard) has no referrals. The Umich implementation introduced them as a hack: It stuffed them into the errorMessage field. LDAPv3 moved them into the standard. And speaking for my own little corner of the standardization process, I definitly was ignorant about them and wanted nothing to do with them. I've still never had any use for LDAP referrals. > They should never have been introduced. We're stuck with them for > now, but we can at least try to make them make sense. Well, take it up with ldapext. And add an option to slapd to reject attempts to add 'ref' attrs with a DN, or whatever. For now, once the directory contains a 'ref' URL which includes the DN, I don't see any reason not to rewrite like the spec says. Whatever the "right answer" is, a referral with an un-rewritten DN seems worse than with a rewritten one. Regarding the branches of bdb_referrals() and ldif_back_referrals() which rewrite default_referral: I suggest we delete it. The back-ldif code breaks exactly as one would expect: With referral ldap://urgle/ database ldif suffix o=foo and an empty database, ldapcompare cn=bar,o=foo gives a referral to urgle. So does ldapadd of o=foo:-( I seem to remember someone meant the latter was correct and there was a control to prevent it at some point, maybe that is related. back-bdb has a test which prevents this referral in case of the suffix dn, but not for superior DNs. But I don't see why it would not be just as buggy for superiors, if it could happen. -- Hallvard

1 0

Re: (ITS#5391) hdb deadlock
by h.b.furuseth＠usit.uio.no 07 Mar '08

07 Mar '08

hyc(a)symas.com writes: > One thing that I've started doing recently in my configs is to skip > the #bytes option (leave it zero), so that only time-based checkpoints > occur. Since they're done in a dedicated task, only one thread at a > time can trigger a checkpoint. How about making #bytes-based checkpoints signal or (pthread_kill?) the timed checkpoints thread, so that thread can handle all checkpoints? -- Hallvard

1 0

(ITS#5404) back-ldap fails intermittently with 80 Internal (implementation specific) error
by toby＠inf.ed.ac.uk 07 Mar '08

07 Mar '08

Full_Name: Toby Blake Version: 2.3.38 amd 2.3.40 OS: Fedora Core 5 and Fedora Core 6 URL: Submission from: (NULL) (129.215.218.33) Hi there, We're seeing a (seemingly) intermittent problem when using back-ldap (with or without using the pcache overlay for caching), where 1 in x queries fail with "result: 80 Internal (implementation specific) error", where x is anywhere between 2 and 10. We're seeing this with both openldap-2.3.38 and openldap-2.3.40 - running on Fedora Core 5 and 6. The remote server is running FC5, openldap 2.3.38. I currently have a machine exhibiting this problem - it's a machine in a student lab. The database part of slapd.conf on this machine is: database ldap suffix dc=inf,dc=ed,dc=ac,dc=uk rootdn uid=ldaprep/inganoust.inf.ed.ac.uk,cn=inf.ed.ac.uk,cn=gssapi,cn=auth uri ldap://testdir.inf.ed.ac.uk/ idassert-bind mode=none bindmethod=sasl saslmech=GSSAPI idassert-authzFrom "dn:*" I'm afraid I can't currently reproduce this error, but hopefully some of the information below will help... I've done some stepping through the code and what seems to be happening when the error occurs is that the call to getpeername in ldap_host_connected_to in libraries/libldap/os-ip.c:590 fails with errno=107 "transport endpoint is not connected" and thereafter ldap_int_sasl_open (cyrus.c:518) is called with NULL as the 'host' argument (in our case it should be 'hadrian.inf.ed.ac.uk') - this results in LDAP_LOCAL_ERROR being returned. The backtrace (in ldap_host_connected_to) is: (gdb) bt #0 ldap_host_connected_to (sb=0xb4124950, host=0x81b0efb "localhost") at os-ip.c:586 #1 0x081394b5 in ldap_int_sasl_bind (ld=0xb4131058, dn=0x0, mechs=<value optimized out>, sctrls=0x0, cctrls=0x0, flags=2, interact=0x81293b0 <lutil_sasl_interact>, defaults=0x892df98) at cyrus.c:643 #2 0x0813b45d in ldap_sasl_interactive_bind_s (ld=0xb4131058, dn=0x0, mechs=0x88bef98 "GSSAPI", serverControls=0x0, clientControls=0x0, flags=2, interact=0x81293b0 <lutil_sasl_interact>, defaults=0x892df98) at sasl.c:479 #3 0x08109625 in ldap_back_dobind_int (lcp=0xb370e0a8, op=0x8952900, rs=0xb370f1c4, sendok=<value optimized out>, retries=0, dolock=1) at bind.c:1997 #4 0x080dab4b in ldap_back_search (op=0x8952900, rs=0xb370f1c4) at search.c:166 #5 0x0806317f in fe_op_search (op=0x8952900, rs=0xb370f1c4) at search.c:355 #6 0x08063b31 in do_search (op=0x8952900, rs=0xb370f1c4) at search.c:217 #7 0x08061209 in connection_operation (ctx=0xb370f238, arg_v=0x8952900) at connection.c:1133 #8 0x081322f3 in ldap_int_thread_pool_wrapper (xpool=0x88a1d18) at tpool.c:478 #9 0x00db145b in start_thread () from /lib/libpthread.so.0 #10 0x001cf23e in clone () from /lib/libc.so.6 (gdb) When getpeername returns the error, it is always for the same 'sd' value - on the machine I'm looking at, it's 13, e.g. 590 if ( getpeername( sd, sa, &len ) == -1 ) { (gdb) p sd $3 = 13 (gdb) p errno $4 = 107 (gdb) What's interesting here is that if I use lsof to see the filehandles that slapd is holding open, I see this for FD 13: COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME slapd 2551 ldap 13u sock 0,5 3603708 can't identify protocol Interestingly, this is the exact same output I see from lsof if a socket() has been created, but not connect()ed. It appears then, that a socket of this type gets into the pool of connections to the remote server being used by the local slapd, thus explaining the 1 in x failure rate - as it cycles through the pool. I currently have a machine in this state, so if there's more information I could usefully provide, then let me know. I can of course change the loglevel, but that would involve restarting slapd on this machine - which fixes the problem. Anyway, let me know if there's more I can do - I can experiment on other machines. Cheers Toby Blake School of Informatics University of Edinburgh

1 0

Re: (ITS#5403) LDAP_OPT_X_SASL_SSF 64bit bugfix or workaround
by h.b.furuseth＠usit.uio.no 07 Mar '08

07 Mar '08

More detail in "private" ITS#3864. -- Hallvard

1 0

(ITS#5403) LDAP_OPT_X_SASL_SSF 64bit bugfix or workaround
by rein＠basefarm.no 07 Mar '08

07 Mar '08

Full_Name: Rein Tollevik Version: 2.4.8 OS: Solaris 10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.93.160.250) Below is a patch that fixes, or more correctly works around, a 64bit bug in servers/slapd/syncrepl.c that causes a bus error on (at least) 64bit Solaris. The real problem is imho that libraries/libldap/cyrus.c expects the argument where it should write the LDAP_OPT_X_SASL_* options to be of type ber_len_t and not the sasl_*_t type matching the option value it returns. I.e, the pointer variable where the returns values are written should be cast to the appropriate sasl_*_t type, not a ber_len_t. Writing to a 64bit ber_len_t when the argument is a 32bit sasl_ssf_t causes an alignment error at best case, memory corruption at worst. I haven't looked too deeply into other cases where LDAP_OPT_X_SASL_* options are set or retrieved with ldap_set_option() or ldap_get_option(), so I don't know the consequence of changing cyrus.c. That's why I don't have what I would consider a real fix to libraries/libldap/cyrus.c rather than this workaround. Rein Tollevik Basefarm AS Index: servers/slapd/syncrepl.c =================================================================== RCS file: /f/CVSROOT/drift/OpenLDAP/servers/slapd/syncrepl.c,v retrieving revision 1.1.1.18 diff -u -u -w -r1.1.1.18 syncrepl.c --- servers/slapd/syncrepl.c 21 Feb 2008 13:55:21 -0000 1.1.1.18 +++ servers/slapd/syncrepl.c 7 Mar 2008 11:34:08 -0000 @@ -444,6 +444,10 @@ #ifdef HAVE_TLS void *ssl; #endif + ber_len_t ssf; /* XXX The correct type would be sasl_ssf_t, but + * this is what the LDAP_OPT_X_SASL_SSF return + * value is cast into in libldap/cyrus.c + */ rc = slap_client_connect( &si->si_ld, &si->si_bindconf ); if ( rc != LDAP_SUCCESS ) { @@ -462,7 +466,8 @@ op->o_tls_ssf = ldap_pvt_tls_get_strength( ssl ); } #endif /* HAVE_TLS */ - ldap_get_option( si->si_ld, LDAP_OPT_X_SASL_SSF, &op->o_sasl_ssf ); + ldap_get_option( si->si_ld, LDAP_OPT_X_SASL_SSF, &ssf); + op->o_sasl_ssf = ssf; op->o_ssf = ( op->o_sasl_ssf > op->o_tls_ssf ) ? op->o_sasl_ssf : op->o_tls_ssf;

1 0

Re: (ITS#5402) Sets: Hyphens within attribute names considered as separate tokens
by ando＠sys-net.it 06 Mar '08

06 Mar '08

norbert(a)rittel.de wrote: > When using attribute names containing hyphens the Set code erroneously considers > the parts to either side of the hyphen as separate tokens. > > For example a <by> clause like > > by set.exact="this/apple-keyword & user/apple-keyword" read > > always yields an empty set. This means that on Apple Open Directory servers set > clauses canot be used with any Apple-supplied attribute as they all begin with > "apple-". The code that parses attribute descriptions appears to be definitely broken, since it does allow underscores but no hyphens, and it does not allow digits in attribute descriptions (including OIDs). This should be fixed now in HEAD, and the patch servers/slapd/sets.c 1.41 -> 1.42 seems to apply to current re24 and re23 without much hassle. 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

(ITS#5402) Sets: Hyphens within attribute names considered as separate tokens
by norbert＠rittel.de 06 Mar '08

06 Mar '08

Full_Name: Norbert Rittel Version: 2.3.27 OS: Mac OS X Server 10.5.2 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (217.91.71.78) When using attribute names containing hyphens the Set code erroneously considers the parts to either side of the hyphen as separate tokens. For example a <by> clause like by set.exact="this/apple-keyword & user/apple-keyword" read always yields an empty set. This means that on Apple Open Directory servers set clauses canot be used with any Apple-supplied attribute as they all begin with "apple-". Pierangelo Masarati was so kind to verify that this bug is still present in the latest release. Hopefully the fix is a simple diff that we can apply to the older version shipping with Mac OS X Server, too. :-)

1 0

Re: (ITS#5369) GSSAPI support for client library
by mimir＠samba.org 04 Mar '08

04 Mar '08

--opJtzjQTFsWo+cga Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Mar 03, 2008 at 02:50:49PM -0800, Kurt Zeilenga wrote: > On Mar 3, 2008, at 1:37 PM, mimir(a)samba.org wrote: > In your rights statement, you claim this patch is only derived from =20 > OpenLDAP Software. Is this correct? Are there are works from which =20 > your work is derived? That is, did you copy any material from any other= =20 > work (e.g., Samba)? Please document any in the rights statement and,=20 > when complete, update the ITS (by email reply-all) indicating so. No, it is purely OpenLDAP work using GSS-API libraries. > The rights statement needs to be amended to include a statement that the= =20 > modifications are not subject to Stefan's employer. And then Stefan=20 > needs to send a copy of both statements from his email address to=20 > openldap-its(a)openldap.org with a subject of "ITS#5369 IPR statements"=20 > confirming they are correct. I've cc'ed Stefan on this note. Thanks. The modifications are not subject to his employer, but thanks for cc-ing him. Sorry Metze, I should have not forgotten about this. > I note my review is limited to IPR issues. There may well be technical= =20 > issues to address separately from this. These will be handled separately= =20 > (normally post IPR review). Sure, I understand. cheers, --=20 Rafal Szczesniak Samba Team member http://www.samba.org Likewise Software http://www.likewisesoftware.com --opJtzjQTFsWo+cga Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHzRUvHvdfyv3qiKkRAga8AJ9aPei2BEkB0cAWnePy1oa0m09s/wCbBWs1 3l6JSyUrgaXSTr3GknJH/oQ= =OedS -----END PGP SIGNATURE----- --opJtzjQTFsWo+cga--

1 0

Re: (ITS#5401) slapd crashes in mirrormode
by ali.pouya＠free.fr 04 Mar '08

04 Mar '08

May be a useful precision : I think that the second protocol detail above shows that the sync provider in server A "ignores" that the server B has closed the TCP connection. Best regards Ali

1 0

Re: (ITS#5369) GSSAPI support for client library
by kurt＠OpenLDAP.org 03 Mar '08

03 Mar '08

On Mar 3, 2008, at 1:37 PM, mimir(a)samba.org wrote: > > --zhXaljGHf11kAtnf > Content-Type: text/plain; charset=iso-8859-2 > Content-Disposition: inline > Content-Transfer-Encoding: quoted-printable > > On Fri, Feb 15, 2008 at 09:28:56AM -1000, Kurt Zeilenga wrote: >> I note that the patch appears to be incomplete. No gssapi.c >> included. > > Sorry about that. Wrong working dir when generating the patch. I've > uploaded more complete file at http://samba.org/~mimir/head- > gssapi.diff > I've also added license notice. Let me know if there's anything else > missing. In your rights statement, you claim this patch is only derived from OpenLDAP Software. Is this correct? Are there are works from which your work is derived? That is, did you copy any material from any other work (e.g., Samba)? Please document any in the rights statement and, when complete, update the ITS (by email reply-all) indicating so. The rights statement needs to be amended to include a statement that the modifications are not subject to Stefan's employer. And then Stefan needs to send a copy of both statements from his email address to openldap-its(a)openldap.org with a subject of "ITS#5369 IPR statements" confirming they are correct. I've cc'ed Stefan on this note. I note my review is limited to IPR issues. There may well be technical issues to address separately from this. These will be handled separately (normally post IPR review). Regards, Kurt > > > > cheers, > --=20 > Rafal Szczesniak > Samba Team member http://www.samba.org > Likewise Software http://www.likewisesoftware.com > > > --zhXaljGHf11kAtnf > Content-Type: application/pgp-signature; name="signature.asc" > Content-Description: Digital signature > Content-Disposition: inline > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.6 (GNU/Linux) > > iD8DBQFHzG+9Hvdfyv3qiKkRAmFUAJ9mbHvUFgkz2f/urbdGwbjhSQ6mbQCeMxYZ > XF5OP4ZaFhwZ5T6rO1FJ4FM= > =Ii59 > -----END PGP SIGNATURE----- > > --zhXaljGHf11kAtnf-- > >

1 0

Re: (ITS#5369) GSSAPI support for client library
by mimir＠samba.org 03 Mar '08

03 Mar '08

--zhXaljGHf11kAtnf Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Feb 15, 2008 at 09:28:56AM -1000, Kurt Zeilenga wrote: > I note that the patch appears to be incomplete. No gssapi.c included. Sorry about that. Wrong working dir when generating the patch. I've uploaded more complete file at http://samba.org/~mimir/head-gssapi.diff I've also added license notice. Let me know if there's anything else missing. cheers, --=20 Rafal Szczesniak Samba Team member http://www.samba.org Likewise Software http://www.likewisesoftware.com --zhXaljGHf11kAtnf Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHzG+9Hvdfyv3qiKkRAmFUAJ9mbHvUFgkz2f/urbdGwbjhSQ6mbQCeMxYZ XF5OP4ZaFhwZ5T6rO1FJ4FM= =Ii59 -----END PGP SIGNATURE----- --zhXaljGHf11kAtnf--

1 0

(ITS#5401) slapd crashes in mirrormode
by ali.pouya＠free.fr 03 Mar '08

03 Mar '08

Full_Name: Ali Pouya Version: 2.4.8 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (145.242.11.4) Hi, I am testing OpenLdap 2.4.8 in mirrormode. I have two mirror servers (A, and B) synchronized in SearchAndPersist mode with a retry interval of 10 seconds : retry="10 +". An injector writes data to A. The data is replicated in B. But this server UNBINDs then reBINDs to A every 10 seconds ! This continues until slapd on A crashes with a SIGIOT. More investigation in the slapd log shows that the crash is caused by the losing of the client syncrepl connection coming from B ! If instead of B I configure an ordinary replica everything is OK. I think there are two distinct problems : 1) Contrarily to an ordinary replica, a mirror ends the persistent search, 2) slapd crashes (very scarcely) after losing the client syncrepl connection to which it was going to send data. Below you find the backtrace after slapd crash. See also more protocol details after the backtrace. If required I can send any detailed information about my configurations. Thanks for your help Best Regards Ali ============================ (gdb) bt #0 0x009b47a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 #1 0x00138815 in raise () from /lib/tls/libc.so.6 #2 0x0013a279 in abort () from /lib/tls/libc.so.6 #3 0x00131d91 in __assert_fail () from /lib/tls/libc.so.6 #4 0x0805ecb2 in connection_state_closing (c=0xa272585c) at connection.c:680 #5 0x0806c444 in send_ldap_ber (conn=0xa272585c, ber=0x9f7f3c00) at result.c:153 #6 0x0806f192 in slap_send_search_entry (op=0x9f7f3f50, rs=0x9f7f3de0) at result.c:1187 #7 0x08134038 in syncprov_qtask (ctx=0x9f7f4210, arg=0x8e21498) at syncprov.c:809 #8 0x081472df in ldap_int_thread_pool_wrapper (xpool=0x8cbf880) at tpool.c:625 #9 0x00a4e3cc in start_thread () from /lib/tls/libpthread.so.0 #10 0x001da1ae in clone () from /lib/tls/libc.so.6 ============================ More protocol details : 1) As an answer to the SearchAndPersist Request, A sends to B an LDAP message [OPERATION 25] (which I do not know). But this message is not sent to an ordinary replica. 2) I also noticed that after sending UNBIND, B sends a [FIN, ACK] TCP packet. As A does not ack this packet B sends a [RST, ACK] packet 30 micro-seconds later.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs