openldap-bugs

openldap-bugs@openldap.org

1 participants
20965 discussions

Re: (ITS#7054) Please drop support to FreeBSD 1.x
by d＠delphij.net 24 Oct '11

24 Oct '11

Just a headsup -- libtool 2.4.2 should have the required changes to support FreeBSD 10.x. Cheers, -- Xin LI <delphij(a)delphij.net> https://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die

1 0

Re: (ITS#7064) moznss SEC_ERROR_BAD_SIGNATURE with a certificate trusted by OpenSSL
by massimo.gravino＠pd.infn.it 24 Oct '11

24 Oct '11

On Mon, 24 Oct 2011, jvcelak(a)redhat.com wrote: > I believe this is a bug in Mozilla NSS and not in OpenLDAP. I have > successfully reproduced on Fedora. > > If you are interested in some details from my investigation, check: > https://bugzilla.redhat.com/show_bug.cgi?id=748394 > > -- > Jan V?el?k > Base Operating Systems Brno > Red Hat Inc. Thank you very much, I'll follow the discussion about this bug at bugzilla.redhat.com Best regards, Massimo Gravino System Administrator National Institute of Nuclear Physics - Padova (Italy)

1 0

Re: (ITS#7064) moznss SEC_ERROR_BAD_SIGNATURE with a certificate trusted by OpenSSL
by jvcelak＠redhat.com 24 Oct '11

24 Oct '11

I believe this is a bug in Mozilla NSS and not in OpenLDAP. I have successfully reproduced on Fedora. If you are interested in some details from my investigation, check: https://bugzilla.redhat.com/show_bug.cgi?id=748394 -- Jan Vèelák Base Operating Systems Brno Red Hat Inc.

1 0

Re: (ITS#7067) openldap not properly starting
by masarati＠aero.polimi.it 24 Oct '11

24 Oct '11

On 10/24/2011 07:18 AM, sanjiv.singh(a)impetus.co.in wrote: > --_000_23A2685ED8B30D46A90227113A1ECE0758F47662Mail3impetuscoi_ > Content-Type: text/plain; charset="us-ascii" > Content-Transfer-Encoding: quoted-printable > > How can I redirect to openldap-technical mailing list ? > Not getting any link for this . Subscribe to openldap-technical <http://www.openldap.org/lists/mm/listinfo/openldap-technical>; post your message to <mailto:openldap-technical@openldap.org> -- Pierangelo Masarati Associate Professor Dipartimento di Ingegneria Aerospaziale Politecnico di Milano

1 0

Re: (ITS#7067) openldap not properly starting
by sanjiv.singh＠impetus.co.in 23 Oct '11

23 Oct '11

--_000_23A2685ED8B30D46A90227113A1ECE0758F47662Mail3impetuscoi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable How can I redirect to openldap-technical mailing list ? Not getting any link for this . Regards, Sanjiv Singh ________________________________ New Impetus webcast on-demand 'Big Data Technologies for Social Media Analy= tics' available at http://bit.ly/nFdet0. Visit http://www.impetus.com to know more. Follow us on www.twitter.com/imp= etuscalling NOTE: This message may contain information that is confidential, proprietar= y, privileged or otherwise protected by law. The message is intended solely= for the named addressee. If received in error, please destroy and notify t= he sender. Any use of this email is prohibited when received in error. Impe= tus does not represent, warrant and/or guarantee, that the integrity of thi= s communication has been maintained nor that the communication is free of e= rrors, virus, interception or interference. --_000_23A2685ED8B30D46A90227113A1ECE0758F47662Mail3impetuscoi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > <style>  </style> </head> <body lang=3D"EN-US" link=3D"blue" vlink=3D"purple"> <div class=3D"WordSection1"> <pre>How can I redirect to openldap-technical mailing list ?</pre> Not getting any  link for this .   Regards, Sanjiv Singh     </div> <hr> New Impetus webcast on-demand ‘Big Data Technologies for Social Media= Analytics’ available at http://bit.ly/nFdet0. Visit http://www.impetus.com to know more. Follow us on www.twitter.com/imp= etuscalling NOTE: This message may contain information that is confidential, proprietar= y, privileged or otherwise protected by law. The message is intended solely= for the named addressee. If received in error, please destroy and notify t= he sender. Any use of this email is prohibited when received in error. Impetus does not represent, warrant = and/or guarantee, that the integrity of this communication has been maintai= ned nor that the communication is free of errors, virus, interception or in= terference. </body> </html> --_000_23A2685ED8B30D46A90227113A1ECE0758F47662Mail3impetuscoi_--

1 0

Re: (ITS#7065) changeType: modify "replace/delete" trick causes segmentation fault in cn=config
by h.b.furuseth＠usit.uio.no 23 Oct '11

23 Oct '11

Reproduced in master by trying to change olcSaslHost: config_modify_internal() does this with a == NULL: 5827 a->a_flags |= SLAP_ATTR_IXADD; jeffreyc(a)ucsc.edu writes: > To guarantee the removal of an attribute when I don't know if the attribute > exists already or not I often employ the following LDIF: > > ============== > dn: cn=config > changeType: modify > replace: attrToDelete > attrToDelete: dummy > - > delete: attrToDelete > ============== You can use this instead: dn: cn=config changeType: modify replace: attrToDelete - -- Hallvard

1 0

Re: (ITS#6763) slapd does not clear sr_entry/ctrls on sizelimit/busy
by h.b.furuseth＠usit.uio.no 23 Oct '11

23 Oct '11

I wrote: > slap_send_search_entry() does not always free/release the entry and > call slap_cleanup_play() on error. > > slap_send_search_reference() calls slap_cleanup_play(), but does not > always free/release the entry. > > I expect both functions always should do both, but don't know enough > myself to be sure. > > Resolution needed for ITS#6758 (SlapReply) - who should be responsible > for clearing out the entry? Nobody else were picking this up, and it was making back-monitor hang in ITS#7053. So I've made result.c always clean up. The code is still inconsistent: slap_send_search_entry() may flush the entry either before or after slap_cleanup_play(), while slap_send_search_reference() always flushes first. If anyone feels that should be regularized, feel free. I'm leaving it alone for now. -- Hallvard

1 0

Re: (ITS#7053) back-monitor blocks
by h.b.furuseth＠usit.uio.no 23 Oct '11

23 Oct '11

Fixed in master, dup of ITS#6763. Thank you for the simple test case. The '-z 10' identified the problem. slap_send_search_entry() did not call rs_flush_entry() when sizeLimitExceeded. I have not traced exactly what happened, but I expect this means some back-monitor entry kept its locks. -- Hallvard

1 0

Re: (ITS#7053) back-monitor blocks
by michael＠stroeder.com 22 Oct '11

22 Oct '11

This is still an issue also in HEAD.

1 0

Re: (ITS#7053) back-monitor blocks
by michael＠stroeder.com 22 Oct '11

22 Oct '11

But just for the records... Finally I managed to reproduce this with OpenLDAP's ldapsearch command-line tool. The bound entity needs read access to cn=monitor. Try this more than one time: ldapsearch -x -H ldapi://%2Ftmp%2Fopenldap-socket -b "cn=monitor" -z 10 -s one "(objectClass=*)" cn objectclass Do this as many times as you have threads configured and slapd becomes completely unresponsive and has to be stopped by kill -9. This was tested on my local install under openSUSE 11.4 but also on an installation running on HP-UX (64 bit build). Both running 2.4.26. Ciao, Michael.

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