openldap-bugs

openldap-bugs@openldap.org

1 participants
21063 discussions

(ITS#8060) mdb_from_db (bdb import)
by graehl＠gmail.com 17 Feb '15

17 Feb '15

Full_Name: Jonathan Graehl Version: n/a OS: n/a URL: ftp://ftp.openldap.org/incoming/0001-mdb_from_db-new-options-bugfix.patch Submission from: (NULL) (104.174.227.200) (see 0001-mdb_from_db-new-options-bugfix.patch) mdb_from_db utility for direct import from Berkeley DB to mdb Apparently this can only be distributed in binary form using older berkeley db versions, but building the utility from source for bulk import should be fine.

1 0

Re: (ITS#8044) openldap 2.4.39-8.el6: issue causing server unavailability
by hyc＠symas.com 17 Feb '15

17 Feb '15

Diana.Scannicchio(a)cern.ch wrote: > Is there anybody that could help on this issue?=20 > this version of openldap is not usable, so I would like to understand which= > is the problem and if can be fixed. > Thank you and best regards, The error message you're referring to was added in the patch for this ITS http://www.openldap.org/its/index.cgi/Software%20Bugs?id=6851;selectid=6851 Check that you've configured appropriate credentials if you're using idassert on the target URI. > > Diana > > > On 02 Feb 2015, at 20:56, diana.scannicchio(a)cern.ch wrote: > >> Should not, I did not enable it in the slapd.conf. >> =20 >> Diana >> =20 >> On 02 Feb 2015, at 20:34, <michael(a)stroeder.com> <michael(a)stroeder.com> w= > ro=3D >> te: >> =20 >>> Is SSL/TLS part of the game? >>> =3D20 >>> Ciao, Michael. >>> =3D20 >>> =3D20 >>> =3D20 >>> =3D20 >> =20 >> - >> Diana Scannicchio >> University of California, Irvine >> ATLAS TDAQ SysAdmin group >> Office: +41 22 76 75240 >> OnCall: 164851 >> =20 >> =20 >> =20 >> =20 >> =20 >> =20 >> =20 >> =20 >> =20 > > - > Diana Scannicchio > University of California, Irvine > ATLAS TDAQ SysAdmin group > Office: +41 22 76 75240 > OnCall: 164851 > > > > > > > > > > -- -- Howard Chu CTO, 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#8059) In client code, set option LDAP_OPT_DEBUG_LEVEL LDAP_DEBUG_ANY does not set option.
by hyc＠symas.com 17 Feb '15

17 Feb '15

peter.driscoll(a)dionglobal.com wrote: > Full_Name: Peter John Driscoll > Version: openldap-2.4.40 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (203.3.133.17) > > > Set this option does not turn on debugging. > > #define LDAP_DEBUG_ANY 0xffff > const int optionValue = LDAP_DEBUG_ANY; > CHECK_RESULT(ldap_set_option(m_ld, LDAP_OPT_DEBUG_LEVEL, &optionValue), > "ldap_set_option debug level"); The ITS is for actual bug reports, not usage questions. Closing this ITS. Use the -technical mailing list for usage questions. -- -- Howard Chu CTO, 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#8044) openldap 2.4.39-8.el6: issue causing server unavailability
by Diana.Scannicchio＠cern.ch 17 Feb '15

17 Feb '15

Is there anybody that could help on this issue?=20 this version of openldap is not usable, so I would like to understand which= is the problem and if can be fixed. Thank you and best regards, Diana On 02 Feb 2015, at 20:56, diana.scannicchio(a)cern.ch wrote: > Should not, I did not enable it in the slapd.conf. >=20 > Diana >=20 > On 02 Feb 2015, at 20:34, <michael(a)stroeder.com> <michael(a)stroeder.com> w= ro=3D > te: >=20 >> Is SSL/TLS part of the game? >> =3D20 >> Ciao, Michael. >> =3D20 >> =3D20 >> =3D20 >> =3D20 >=20 > - > Diana Scannicchio > University of California, Irvine > ATLAS TDAQ SysAdmin group > Office: +41 22 76 75240 > OnCall: 164851 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 - Diana Scannicchio University of California, Irvine ATLAS TDAQ SysAdmin group Office: +41 22 76 75240 OnCall: 164851

1 0

Re: AW: (ITS#8058) OpenLDAP: module autogroup (memberof)
by michael＠stroeder.com 17 Feb '15

17 Feb '15

Tobias.Helfenstein(a)wald-rlp.de wrote: > sorry, I forgot to say that we have to use the version 2.4.39 from CentOS. > So we checked out the repo and compiled the latest autogroup source code > against the CentOS patched 2.4.39 slapd. Of course, mixing sources can lead to seg faults. Why didn't you compile the whole 2.4.40 release or even better the RE24 git branch? Export the RE24 git branch here: http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=snapshot;h=refs/h… Ciao, Michael.

1 0

AW: (ITS#8058) OpenLDAP: module autogroup (memberof)
by Tobias.Helfenstein＠wald-rlp.de 17 Feb '15

17 Feb '15

Hello,=0A= =0A= sorry, I forgot to say that we have to use the version 2.4.39 from CentOS.= =0A= So we checked out the repo and compiled the latest autogroup source code ag= ainst the CentOS patched 2.4.39 slapd.=0A= =0A= When we tried to compile the autogroup source code provided with CentOS the= n the module triggers a segmentation fault.=0A= =0A= Is it possible that the problem occurs because of the CentOS patches?=0A= =0A= Best regards=0A= Tobias=0A= ________________________________________=0A= Von: Michael Str=F6der [michael(a)stroeder.com]=0A= Gesendet: Sonntag, 15. Februar 2015 20:16=0A= An: Helfenstein, Tobias; openldap-its(a)OpenLDAP.org=0A= Betreff: Re: (ITS#8058) OpenLDAP: module autogroup (memberof)=0A= =0A= tobias.helfenstein(a)wald-rlp.de wrote:=0A= > Version: 2.4.39=0A= >=0A= > we have problems when activating the module autogroup (memberof).=0A= =0A= There were several fixes after 2.4.39.=0A= =0A= Could you please try RE24 branch from git repo?=0A= =0A= Ciao, Michael.=0A= Mail wurde erfoglreich durch Sophos PureMessage auf Viren gepr=FCft.=

1 0

(ITS#8059) In client code, set option LDAP_OPT_DEBUG_LEVEL LDAP_DEBUG_ANY does not set option.
by peter.driscoll＠dionglobal.com 17 Feb '15

17 Feb '15

Full_Name: Peter John Driscoll Version: openldap-2.4.40 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (203.3.133.17) Set this option does not turn on debugging. #define LDAP_DEBUG_ANY 0xffff const int optionValue = LDAP_DEBUG_ANY; CHECK_RESULT(ldap_set_option(m_ld, LDAP_OPT_DEBUG_LEVEL, &optionValue), "ldap_set_option debug level"); Calling ldap_get_option confirms the change. But in libraries/libldap/sbind.c int ldap_simple_bind_s( LDAP *ld, LDAP_CONST char *dn, LDAP_CONST char *passwd ) The call, Debug( LDAP_DEBUG_TRACE, "ldap_simple_bind_s\n", 0, 0, 0 ); Does not log any debug information, because ldap_debug does not returns 0 instead of 0xFFFF. Debug is defined, #define Debug( level, fmt, arg1, arg2, arg3 ) \ Log3( (level), 0, (fmt), (arg1), (arg2), (arg3) ) #define Log3( level, severity, fmt, arg1, arg2, arg3 ) \ do { \ if ( ldap_debug & (level) ) \ lutil_debug( ldap_debug, (level), (fmt), (arg1), (arg2), (arg3) ); \ } while ( 0 ) #define ldap_debug ((LDAP_INT_GLOBAL_OPT())->ldo_debug) The option is set in, libraries/libldap/options.c int ldap_set_option( LDAP *ld, int option, LDAP_CONST void *invalue) starts with lo = LDAP_INT_GLOBAL_OPT(); but a few lines down, if(ld != NULL) { assert( LDAP_VALID( ld ) ); if( !LDAP_VALID( ld ) ) { return LDAP_OPT_ERROR; } lo = &ld->ld_options; } This code breaks the logic so that the option is not set in the right place. So later in the method, case LDAP_OPT_DEBUG_LEVEL: lo->ldo_debug = * (const int *) invalue; rc = LDAP_OPT_SUCCESS; break; is writing to the wrong place, because lo != LDAP_INT_GLOBAL_OPT() FYI my methods, doing the calling is, void NovaLdap::Connect() { NovaString ldaps = "ldap://"; if (m_SSL) { ldaps = "ldaps://"; } NovaString server = ldaps + m_IpAddress + ":" + ToNovaString(m_IpPort); JOURNAL(SECURITYSERVER,DTL) << "Security Server : Connect " << server << endl; #ifdef _WIN32 m_ld = ldap_sslinit((LDAP_PCHAR) m_IpAddress.data(), m_IpPort, m_SSL); #else CHECK_RESULT(ldap_initialize(&m_ld, server), "ldap_initialize(\2"22 + server + "\")"); #endif JOURNAL(SECURITYSERVER,DTL) << "Security Server : Connected - OK " << endl; if (!m_ld) { JOURNAL(SECURITYSERVER,DTL) << "Security Server : Connect - NULL LD " << endl;D0D throw NovaError(ISSFactory::Error_LDAP_INIT_NULL); } JOURNAL(SECURITYSERVER,DTL) << "Security Server : Connect - set option" << endl; int myVersion =LDAP_VERSION3; CHECK_RESULT(ldap_set_option(m_ld, LDAP_OPT_PROTOCOL_VERSION, &myVersion), "ldap_set_option version"); //CHECK_RESULT(ldap_set_option(m_ld, LDAP_OPT_TLS, &reqcert), "ldap_set_option TLS requires certificate"); #ifdef LDAP_OPT_DEBUG_LEVEL const int optionValue = LDAP_DEBUG_ANY; CHECK_RESULT(ldap_set_option(m_ld, LDAP_OPT_DEBUG_LEVEL, &optionValue), "ldap_set_option debug level"); int optionValueReturned = 0; CHECK_RESULT(ldap_get_option(m_ld, LDAP_OPT_DEBUG_LEVEL, &optionValueReturned), "ldap_set_option debug level"); JOURNAL(SECURITYSERVER,DTL) << "Security Server : Set debug level: " << optionValueReturned << endl; #endif #ifdef LDAP_OPT_CONNECT_ASYNC ldap_set_option( m_ld, LDAP_OPT_CONNECT_ASYNC, LDAP_OPT_OFF ); #endif ldap_set_option(m_ld, LDAP_OPT_REFERRALS, LDAP_OPT_OFF ); ldap_set_option(m_ld, LDAP_OPT_RESTART, LDAP_OPT_ON ); JOURNAL(SECURITYSERVER,DTL) << "Security Server : Connect - OK " << endl; #ifdef _WIN32 CHECK_RESULT(ldap_connect(m_ld, NULL), "ldap_connect"); #endif if (m_StartTLS) { JOURNAL(SECURITYSERVER,DTL) << "Security Server : Connect - Start TLS" << endl; #ifdef _WIN32 CHECK_RESULT(ldap_start_tls_s(m_ld, NULL, NULL, NULL, NULL), "ldap_start_tls_s"); // WINLDAPAPI ULONG LDAPAPI ldap_start_tls_sA ( // IN PLDAP ExternalHandle, // OUT PULONG ServerReturnValue, // OUT LDAPMessage **result, // IN PLDAPControlA *ServerControls, // IN PLDAPControlA *ClientControls // ); #else CHECK_RESULT(ldap_start_tls(m_ld, NULL, NULL, NULL), "ldap_start_tls_s"); #endif } } void NovaLdap::CheckConnection() { JOURNAL(SECURITYSERVER,DTL) << "NovaLdap::CheckConnection: Checking connection" << endl; Connect(); // See if can bind to the DN. if (!m_ServiceAccountUsername.isNull()) { JOURNAL(SECURITYSERVER,DTL) << "Security Server : GetDistinguishedNameForUserName Service service login " << m_ServiceAccountUsername << endl; puts("Security Server : GetDistinguishedNameForUserName Service service login\n"); LDAP_RESULT result = ldap_simple_bind_s(m_ld, (LDAP_PCHAR) m_ServiceAccountUsername.data(), (LDAP_PCHAR) m_ServiceAccountPassword.data()); if (result != (LDAP_RESULT) LDAP_SUCCESS) { NovaString errorMessage(ldap_err2string(result)); throw NovaError(ISSFactory::Error_LDAP_FAILURE, "bind as service user: ", errorMessage); char sevLevel; } ldap_unbind(m_ld); } JOURNAL(SECURITYSERVER,DTL) << "NovaLdap::ececkConnection: Success" << endl; }

1 0

Re: (ITS#8058) OpenLDAP: module autogroup (memberof)
by michael＠stroeder.com 15 Feb '15

15 Feb '15

tobias.helfenstein(a)wald-rlp.de wrote: > Version: 2.4.39 > > we have problems when activating the module autogroup (memberof). There were several fixes after 2.4.39. Could you please try RE24 branch from git repo? Ciao, Michael.

1 0

(ITS#8058) OpenLDAP: module autogroup (memberof)
by tobias.helfenstein＠wald-rlp.de 15 Feb '15

15 Feb '15

Full_Name: Tobias Helfenstein Version: 2.4.39 OS: CentOS 7.0 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (87.165.195.65) Hello, we have problems when activating the module autogroup (memberof). We configured the module like the described way in the README file. If we add a new entry to the LDAP tree, the entry is added to the desired group automatically. This is the expected behavior. We can add entries as much as possible and there is no problem. Now, if we delete one of the entries the slapd is very slow and hangs. The action have to be aborted to continue, there is no debug output. Because of that we have to restart the slapd daemon. But the restart takes a long time (3+ minutes). After the restart we can delete only one entry, then the described problem occurs again. We think it is a bug an hope you can help us. Thank you

1 0

(ITS#8057) slapo-unique can be bypassed by anyone
by ondra＠mistotebe.net 14 Feb '15

14 Feb '15

Full_Name: Ondrej Kuznik Version: master OS: URL: ftp://ftp.openldap.org/pub/Ondrej-Kuznik-20150214-ITS-8057-uniqueness-ACL.p… Submission from: (NULL) (86.177.93.243) This is caused by my fix for #6641. Since anyone can specify the manageDSAit control on an operation it is trivial to bypass the uniqueness check as it stands. The above patch is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the above patches were developed by Ondrej Kuznik <ondra(a)mistotebe.net>. I have not assigned rights and/or interest in this work to any party. I, Ondrej Kuznik, hereby place the above modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice.

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