openldap-bugs

openldap-bugs@openldap.org

1 participants
20962 discussions

Re: (ITS#4964) consumer with slapo-chain segfaults when using ldappasswd
by ando＠sys-net.it 19 May '07

19 May '07

This is now completely fixed in HEAD; I need to check any issue related to backporting to re23, for quick release. Please test. Thanks for reporting, 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#4973) Inconsistent initialization of internal modifications
by ando＠sys-net.it 19 May '07

19 May '07

Full_Name: Pierangelo Masarati Version: HEAD OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.72.89.40) Submitted by: ando While fixing slapo-chain(5) handling of passmods, I stumbled into an inconsistent initialization of internal modifications. What happens is that in most cases the Operation structure used for internal operations is either directly the structure passed to the function that performs the internal operation, or a copy of it, something like Operation op2 = *op; The oq_modify.rs_modlist member now contains an orm_no_opattrs field which, if non-zero, inhibits the modification of operational attributes, and thus indirectly breaks replication. I've fixed the occurrence in passwd_extop(), but the code is full of internal modifications that might need care. p.

1 0

Re: (ITS#4078) test001 fails on sparcv9
by h.b.furuseth＠usit.uio.no 18 May '07

18 May '07

I've updated and applied a patch I had lying around for this one: Give OperationBuffer struct members instead of using LBER_ALIGNED_BUFFER. -- Regards, Hallvard

1 0

Re: (ITS#4966) OpenLDAP 2.3.35 crashes on valsort overlay
by ando＠sys-net.it 18 May '07

18 May '07

digant(a)stanford.edu wrote: > When modding an entry, valsort seems to have crashed the server. I've uploaded > the stack trace and informaiton I was able to gather out of the core dump. In your upload: > #0 valsort_modify (op=0x2aabaeac0058, rs=0x417fef10) at valsort.c:455 > 455 for (i=0; !BER_BVISNULL( &ml->sml_values[i] ); i++) { can you detail what operation caused this? Can you print: ml, i, ml->sml_mod.sm_values, ml->sml_mod.sm_values[i] ? 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#4959) replica seg faults if syncrepl searchbase =""
by ando＠sys-net.it 18 May '07

18 May '07

ali.pouya(a)free.fr wrote: > The HEAD misses the definition of 'oids' 'oid_name', etc. So I get the following > error at build time : You probably caught HEAD in some inconsistent state during the addition of GNUTLS support; it's working just fine for me. Can you retry? 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#4961) If database suffix is ""
by ando＠sys-net.it 18 May '07

18 May '07

ali.pouya(a)free.fr wrote: > Unfortunately the problem has not been completely fixed in the HEAD. > With the fix in the head the error message disappears but the contextCSN ins NOT > ACTUALLY written to the disk. So at the next slapd startup the ContextCSN is > missing. An the servers hav to resynchronize. > > Below you find the log extract. Makes sense: the empty entry "" is not persistent... 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#4971) patch for OpenLDAP 2-3-32
by ando＠sys-net.it 18 May '07

18 May '07

jemeterisan(a)mail.ru wrote: > I had noticed, that the patch, used for 'schema-map.c' doesn't work > correct. I hope, You also had checked it up. So what had I found in > the function 'backsql_ad2at': > The attribute name is stored in 'struct berval' structure, so if > You change '.bv_val' from 'userCertificate;binary' to > 'userCertificate', You should change '.bv_len' in accordance to > strlen(aaa.bv_val) without strlen(";binary"). I assume you refer to a patch that was submitted along with ITS#4868; that patch is absolutely incorrect and in fact it has been rejected. A consistent fix has been applied to hEAD code. It has never been backported to OpenLDAP 2.3 because nobody fed back about it. If you wish to test HEAD code and report success, I'll be happy to backport it to OpenLDAP 2.3 so that it gets released with the next release. > And by the way I want to store 'userCertificate' attribute type in PostrgreSQL. > > What type of the field in the table should I use? Any blob-like format would be fine (although I haven't tested it with PostgreSQL yet). > Just another question to the developers: > I've heared that OpenLDAP is sensible to DOS attacks, so, how can I avoid this > trouble? And I want to know more about this problem, if possible. Please direct software use related questions to the openldap-software mailing list. 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#4972) thr_debug problems
by h.b.furuseth＠usit.uio.no 18 May '07

18 May '07

Full_Name: Hallvard B Furuseth Version: HEAD, RE23 OS: URL: Submission from: (NULL) (129.240.202.105) Submitted by: hallvard $LDAP_THREAD_DEBUG parsing is bogus, code in the inner loop should be outside it. Detached threads can validly exit after ldap_debug_thread_destroy() (fixed in HEAD). Valgrind carries the 'uninialized' state out of debug_already_initialized(). RE23/thr_debug.c has some other problems that are fixed in HEAD, but take a bit more work to fix and test. I'll align it with HEAD if anyone is interested.

1 0

Re: (ITS#4961) If database suffix is ""
by ali.pouya＠free.fr 18 May '07

18 May '07

Unfortunately the problem has not been completely fixed in the HEAD. With the fix in the head the error message disappears but the contextCSN ins NOT ACTUALLY written to the disk. So at the next slapd startup the ContextCSN is missing. An the servers hav to resynchronize. Below you find the log extract. Thanks Best regards Ali ============================ Log extract : daemon: shutdown requested and initiated. daemon: closing 7 connection_closing: readying conn=0 sd=11 for close connection_close: conn=0 sd=11 daemon: removing 11 conn=0 fd=11 closed (slapd shutdown) =>do_syncrepl rid=123 connection_get(12) connection_get(12): got connid=0 daemon: removing 12r slapd shutdown: waiting for 1 threads to terminate ldap_free_request (origid 2, msgid 2) ldap_free_connection 1 1 ldap_send_unbind ber_flush2: 7 bytes to sd 12 0000: 30 05 02 01 03 42 00 0....B. ldap_write: want=7, written=7 0000: 30 05 02 01 03 42 00 0....B. ldap_free_connection: actually freed slapd shutdown: initiated bdb_modify: bdb_dn2entry("") bdb_modify_internal: 0x00000000: <= acl_access_allowed: granted to database root bdb_modify_internal: replace contextCSN is_entry_objectclass("", "2.5.17.0") no objectClass attribute => entry_encode(0x00000000): bdb_modify: updated id=00000000 dn="" send_ldap_result: conn=-1 op=0 p=0 send_ldap_result: err=0 matched="" text="" ====> bdb_cache_release_all slapd destroy: freeing system resources. slapd stopped.

1 0

Re: (ITS#4965) slapd stops if access to cn=monitor is restricted
by ali.pouya＠free.fr 18 May '07

18 May '07

Hi Pierangelo; The HEAD misses some new definitions (see followup 5 in ITS 4959) so I reproduced the problem with OPENLDAP_REL_ENG_2_4. I feel that the problem has not been fixed in this release. Thanks and best regards Ali

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