openldap-bugs

openldap-bugs@openldap.org

1 participants
20967 discussions

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

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