openldap-bugs March 2008

openldap-bugs@openldap.org

34 participants
162 discussions

Re: (ITS#5329) back-ldif deadlock
by h.b.furuseth＠usit.uio.no 11 Mar '08

11 Mar '08

I wrote: > Assuming the acl call should be there, one simple fix could be to > introduce a 'li_wlock' mutex, lock it early on LDAP update operations, > and delay locking li_rdwr until the operation is about to update > the database. That does affect scheduling: Incoming read operations bypass pending write operations that are waiting for another write operation. (Since write but not read operations lock li_wlock before li_rdwr.) Looks acceptable to me, back-ldif doesn't exist for max performance. -- Hallvard

1 0

ITS#5396
by ecizaguirre＠gmv.com 10 Mar '08

10 Mar '08

Hi Pierangelo, I guess I have to explain a little bit more about the configuration I am working with. I didn't send the whole config file, there are two URIs defined in it with correspondig rewrite rules so the rewrite engine is needed, although I have to check the rewrite capabilities of back-meta. I have used the single-conn directive but I have faced the same problem, every connection gets stuck in the CLOSE_WAIT state in the metadirectory server but is closed in the remote LDAP servers. I guess you are rigth and is only a configuration issue but, why every socket remains open, in CLOSE_WAIT state, even when there is no more connections to the server? I have reproduced the issue in a test enviroment and the sockets are freed only when the slapd server is stopped. The whole config file follows: # # See slapd.conf(5) for details on configuration options. # This file should NOT be world readable. # ### Fichero de schema basico de OpenLDAP. include /opt/openldap-2.4.8/etc/openldap/schema/core.schema ### Definiciones incluidas con OpenLDAP. Es importante usar el orden dado ya ### que hay atributos definidos en un schema que se usan en los siguientes. include /opt/openldap-2.4.8/etc/openldap/schema/cosine.schema include /opt/openldap-2.4.8/etc/openldap/schema/inetorgperson.schema ### Definicion de atributos de Active Directory. include /opt/openldap-2.4.8/etc/openldap/schema/AD.schema ### Definicion incluida con OpenLDAP para usar LDAP como servicio NIS. include /opt/openldap-2.4.8/etc/openldap/schema/nis.schema ### Definicion de atributos y objetos de Grupo GMV. include /opt/openldap-2.4.8/etc/openldap/schema/local.schema ### Definicion de atributos y objetos de samba. include /opt/openldap-2.4.8/etc/openldap/schema/samba.schema # Define global ACLs to disable default read access. pidfile /opt/openldap-2.4.8/var/run/slapd.pid argsfile /opt/openldap-2.4.8/var/run/slapd.args ## TTL para tirar una conexion inactiva (1 minuto). idletimeout 60 ## Caractersiticas adicionales. allow bind_anon_cred ####################################################################### # # Definicion de una base de datos Metadirectorio para consultas a AD. # ####################################################################### 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 120 ## Version del protocolo LDAP a utilizar. protocol-version 3 ## Accion ante un referral. chase-referrals no ##################################################################### ### 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/" ## Habilitamos el sistema de reescritura para las consultas. rewriteEngine on overlay rwm ## Pseudoroot DN. idassert-bind bindmethod=simple binddn="CN=proxymetadir,OU=SISTEMAS,OU=Usuarios,DC=gmv,DC=es" credentials="****" mode=none ################################################################### ################################################################### # Definicion de las reglas de reescritura a utilizar para los DCs. ################################################################### ################################################################### ## Reglas de reescritura para buscar informacion en los DCs. ## Primero se cambia el sufijo del arbol para buscar grupos. rwm-suffixmassage "ou=group,dc=gmv,dc=es" "OU=Proyectos,OU=Grupos,DC=gmv,DC=es" ## Ahora se modifica para buscar las cuentas de usuario. rwm-suffixmassage "ou=people,dc=gmv,dc=es" "OU=Usuarios,DC=gmv,DC=es" ## Regla de reescritura para el DN de los grupos. ## Teoricamente solo deberia aplicarse a los resultados devueltos ## a los clientes del servidor. rwm-rewriteContext searchEntryDN rwm-rewriteRule "(.+)?_prj,ou=Group,dc=gmv,dc=es" "$1,ou=Group,dc=gmv,dc=es" ## Ahora vienen las reglas de reescritura de los atributos y las ## clases de objeto de cuentas de usuario y grupo UNIX. rwm-map objectClass posixAccount user rwm-map objectClass shadowAccount person rwm-map objectClass posixGroup group ## ## Definicion de atributos a mapear con MS SFU 3.0. ## rwm-map attribute gecos msSFU30Gecos rwm-map attribute homeDirectory msSFU30HomeDirectory rwm-map attribute uidNumber msSFU30UidNumber rwm-map attribute loginShell msSFU30LoginShell rwm-map attribute gidNumber msSFU30GidNumber rwm-map attribute memberUid msSFU30MemberUid rwm-map attribute ShadowFlag msSFU30ShadowFlag rwm-map attribute ShadowExpire msSFU30ShadowExpire rwm-map attribute ShadowInactive msSFU30ShadowInactive rwm-map attribute ShadowMax msSFU30ShadowMax rwm-map attribute ShadowWarning msSFU30ShadowWarning rwm-map attribute ShadowLastChange msSFU30ShadowLastChange rwm-map attribute ShadowMin msSFU30ShadowMin ### Como hay dos atributos iguales para los usuarios y para ### los grupos haremos esta distincion entre unos y otros ### para realizar el mapeo entre los dos. ## Los grupos se identifican por cn. rwm-map attribute cn msSFU30Name ## Los usuarios se identifican por uid. rwm-map attribute uid sAMAccountName ## El resto de atributos no los quiero para nada asi que me los ## cargo con los siguientes mapeos. rwm-map attribute DSCOREPROPAGATIONDATA rwm-map attribute SHOWINADDRESSBOOK rwm-map attribute MSEXCHHOMESERVERNAME rwm-map attribute MSEXCHALOBJECTVERSION rwm-map attribute MSEXCHMAILBOXSECURITYDESCRIPTOR rwm-map attribute MSEXCHUSERACCOUNTCONTROL rwm-map attribute MSEXCHMAILBOXGUID rwm-map attribute PROXYADDRESSES rwm-map attribute MEMBEROF rwm-map attribute HOMEMTA rwm-map attribute HOMEMDB rwm-map attribute USERACCOUNTCONTROL rwm-map attribute manager rwm-map attribute LEGACYEXCHANGEDN rwm-map attribute BADPWDCOUNT rwm-map attribute BADPASSWORDTIME rwm-map attribute LASTLOGOFF rwm-map attribute LASTLOGON rwm-map attribute USERWORKSTATIONS rwm-map attribute PWDLASTSET rwm-map attribute OBJECTSID rwm-map attribute ADMINCOUNT rwm-map attribute ACCOUNTEXPIRES rwm-map attribute LOGONCOUNT rwm-map attribute DIRECTREPORTS rwm-map attribute USNCREATED rwm-map attribute USNCHANGED rwm-map attribute CODEPAGE rwm-map attribute OBJECTGUID rwm-map attribute MDBUSEDEFAULTS rwm-map attribute title rwm-map attribute physicalDeliveryOfficeName rwm-map attribute objectCategory rwm-map attribute LASTLOGONTIMESTAMP rwm-map attribute MSEXCHPOLICIESINCLUDED rwm-map attribute MSRTCSIP-PRIMARYHOMESERVER rwm-map attribute MSRTCSIP-PRIMARYUSERADDRESS rwm-map attribute MSRTCSIP-FEDERATIONENABLED rwm-map attribute MSRTCSIP-OPTIONFLAGS rwm-map attribute street rwm-map attribute jpegPhoto rwm-map attribute USERPARAMETERS rwm-map attribute member rwm-map attribute INSTANCETYPE rwm-map attribute WHENCREATED rwm-map attribute WHENCHANGED rwm-map attribute COMPANY rwm-map attribute DELIVERANDREDIRECT rwm-map attribute AUTHORIGBL rwm-map attribute MAILNICKNAME rwm-map attribute COUNTRYCODE rwm-map attribute LOGONHOURS rwm-map attribute PRIMARYGROUPID rwm-map attribute SAMACCOUNTTYPE rwm-map attribute USERPRINCIPALNAME rwm-map attribute textEncodedORAddress rwm-map attribute mail rwm-map attribute MSRTCSIP-USERENABLED rwm-map attribute MSRTCSIP-INTERNETACCESSENABLED rwm-map attribute SRTCSIP-ARCHIVINGENABLED rwm-map attribute c rwm-map attribute l rwm-map attribute st rwm-map attribute postalCode rwm-map attribute telephoneNumber rwm-map attribute facsimileTelephoneNumber rwm-map attribute givenName rwm-map attribute initials rwm-map attribute MSRTCSIP-ARCHIVINGENABLED rwm-map attribute MSSFU30NISDOMAIN rwm-map attribute SCRIPTPATH rwm-map attribute DEPARTMENT rwm-map attribute co rwm-map attribute GECOS-OLD rwm-map attribute UIDNUMBER-OLD rwm-map attribute GIDNUMBER-OLD rwm-map attribute LOGINSHELL-OLD rwm-map attribute MSSFUHOMEDIRECTORY rwm-map attribute MSSFUNAME ############################################## ### Opciones comunes a todo el metadirectorio. ############################################## ######################################### #### Directivas comunes de configuracion. ## TTL para tirar una conexion, aunque no este inactiva (60 segundos). conn-ttl 90 ## Version del protocolo LDAP a utilizar. protocol-version 3 ## Accion ante un referral. chase-referrals no ##################################################################### ### Definicion del LDAP local para las consultas de informacion de ### mapas de automount, perfiles de inicializacion de clientes Solaris ### y los netgroups. ##################################################################### ## Ahora defino el ldap que contiene los mapas de autofs ## asi como los perfiles para los clientes LDAP Solaris. ## De momento hago la prueba en local. uri "ldap://172.22.4.13:390/dc=gmv,dc=es" ## Habilitamos el sistema de reescritura para las consultas. rewriteEngine on ## Pseudoroot DN. idassert-bind bindmethod=simple binddn="CN=proxymetadir,OU=SISTEMAS,OU=Usuarios,DC=gmv,DC=es" credentials="****" mode=none ######################################################################## ######################################################################## # Definicion de las reglas de reescritura a utilizar para el LDAP local. ######################################################################## ######################################################################## ## Ahora las reglas de reescritura del servidor LDAP que contiene ## los mapas de automount asi como los perfiles de Solaris y los ## netgroups de Unix. rwm-suffixmassage "ou=Profile,dc=gmv,dc=es" "ou=Profile,ou=Unix,dc=gmv,dc=es" rwm-suffixmassage "ou=Automount,dc=gmv,dc=es" "ou=Automount,ou=Unix,dc=gmv,dc=es" rwm-suffixmassage "ou=netgroup,dc=gmv,dc=es" "ou=Netgroup,ou=Unix,dc=gmv,dc=es" rwm-suffixmassage "automountmapname=auto_home,dc=gmv,dc=es" "automountmapname=auto_home,ou=Unix,dc=gmv,dc=es" rwm-suffixmassage "automountmapname=auto_master,dc=gmv,dc=es" "automountmapname=auto_master,ou=Unix,dc=gmv,dc=e s" rwm-suffixmassage "automountmapname=auto_direct,dc=gmv,dc=es" "automountmapname=auto_direct,ou=Unix,dc=gmv,dc=e s" rwm-map objectClass nisObject nisObject rwm-map objectClass nisNetgroup nisNetgroup rwm-map objectClass automountMap automountMap rwm-map objectClass automount automount rwm-map objectClass DUAConfigProfile DUAConfigProfile rwm-map attribute memberNisNetgroup memberNisNetgroup rwm-map attribute automountMapName automountMapName rwm-map attribute automountKey automountKey rwm-map attribute nisNetgroupTriple nisNetgroupTriple Thanks again, Eduardo. -----Mensaje original----- De: Eduardo Izaguirre Pazos Enviado el: viernes, 29 de febrero de 2008 13:28 Para: 'openldap-its(a)openldap.org' Asunto: ITS#5396 Another update about this problem. Connections between slpad and the remote active directory servers remains in ESTABLISHED state for a long time and changes to CLOSE_WAIT state in the slapd server. In the active directory servers the connections then changes to FIN_WAIT_2, so it seems the slapd server is not sending the FIN packet to close the socket. Cheers. Eduardo ________________________________ De: Eduardo Izaguirre Pazos Enviado el: jueves, 28 de febrero de 2008 13:21 Para: 'openldap-its(a)openldap.org' Asunto: ITS#5396 An update about the case, the problem seems to be related with the connections which remains in CLOSE_WAIT state, as an example: [root@metaldap openldap]# netstat -an | grep -i close | wc -l 11361 all these connections are to the remote ldap servers. Cheers. Eduardo. ________________________________ Eduardo Izaguirre Pazos Administrador de Sistemas / Systems Administrator GRUPO TECNOLÓGICO E INDUSTRIAL GMV,S.A. Isaac Newton, 11 P.T.M. Tres Cantos E-28760 Madrid Tel. +34 91 807 21 00 Fax +34 91 807 21 99 www.gmv.com ______________________ Este mensaje, y en su caso, cualquier fichero anexo al mismo, puede contener informacion clasificada por su emisor como confidencial en el marco de su Sistema de Gestion de Seguridad de la Informacion siendo para uso exclusivo del destinatario, quedando prohibida su divulgacion copia o distribucion a terceros sin la autorizacion expresa del remitente. Si Vd. ha recibido este mensaje erroneamente, se ruega lo notifique al remitente y proceda a su borrado. Gracias por su colaboracion. ______________________ This message including any attachments may contain confidential information, according to our Information Security Management System, and intended solely for a specific individual to whom they are addressed. Any unauthorised copy, disclosure or distribution of this message is strictly forbidden. If you have received this transmission in error, please notify the sender immediately and delete it. ______________________

1 0

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 09 Mar '08

09 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 09 Mar '08

09 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 09 Mar '08

09 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 09 Mar '08

09 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 09 Mar '08

09 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 09 Mar '08

09 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 09 Mar '08

09 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

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs March 2008