- openldap-bugs - openldap.org

Re: (ITS#6587) lconn_refcnt is not thread-safe
by hyc＠symas.com 10 Jul '10

10 Jul '10

test.007(a)seznam.cz wrote: > Full_Name: Test Seven > Version: 2.4.22 > OS: Windows > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (195.113.184.10) > > > lconn_refcnt is read and written without any sync mechanism, which may cause > subtle multi-threading issues. You're mistaken. ld->ld_res_mutex is owned in all cases where lc->lconn_refcnt is touched. > E.g. libldap/result.c -r1.172 > #ifdef LDAP_R_COMPILE > ldap_pvt_thread_mutex_unlock(&ld->ld_conn_mutex ); > #endif > rc = try_read1msg( ld, msgid, all, lc, result ); > lnext = lc->lconn_next; > /* Only take locks if we're really freeing */ > if ( lc->lconn_refcnt<= 1 ) { > #ifdef LDAP_R_COMPILE > ldap_pvt_thread_mutex_lock(&ld->ld_req_mutex ); > #endif > ldap_free_connection( ld, lc, 0, 1 ); > > -- -- 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

(ITS#6587) lconn_refcnt is not thread-safe
by test.007＠seznam.cz 09 Jul '10

09 Jul '10

Full_Name: Test Seven Version: 2.4.22 OS: Windows URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (195.113.184.10) lconn_refcnt is read and written without any sync mechanism, which may cause subtle multi-threading issues. E.g. libldap/result.c -r1.172 #ifdef LDAP_R_COMPILE ldap_pvt_thread_mutex_unlock( &ld->ld_conn_mutex ); #endif rc = try_read1msg( ld, msgid, all, lc, result ); lnext = lc->lconn_next; /* Only take locks if we're really freeing */ if ( lc->lconn_refcnt <= 1 ) { #ifdef LDAP_R_COMPILE ldap_pvt_thread_mutex_lock( &ld->ld_req_mutex ); #endif ldap_free_connection( ld, lc, 0, 1 );

1 0

(ITS#6586) PASSMOD operations are not getting chained correctly
by moenoel＠informatik.uni-bremen.de 01 Jul '10

01 Jul '10

Full_Name: Christian Manal Version: 2.4.21 OS: SunOS 5.10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2001:638:708:30dd:221:85ff:fe3f:1775) I have noticed a problem regarding ExOp PASSMOD and chaining in my OpenLDAP environment. Maybe some of the other overlays are doing their part in this as well. Password changes started behaving weird at some point: When a slave runs for a few days and some user tries to change his password, the change is done in the local database only (no chaining done or referral returned), resulting in an inconsistent database between the slave and all the other servers. That way logging in to services which connect to the LDAP servers in a round-robin fashion sometimes works with the "new" password and sometimes with the old one. After I restart the slapd on the slaves, everything works again for a few days, before it goes bad again. Every other write gets chained just fine when a slave is in this condition. It's only the PASSMOD operations that are stuck. I have one master and four slaves running on Solaris 10. One of them SPARC, the others x86. Software Versions are: OpenLDAP 2.4.21 BDB 4.8.26 Cyrus SASL 2.1.23 Heimdal Kerberos 1.3.3 All the configs and the sourcecode of my self-made pwdCheckModule for ppolicy can be found here: http://www.informatik.uni-bremen.de/~moenoel/ldap/ As pointed out by Pierangelo Masarati, this may be the same issue as reported here: <http://www.openldap.org/lists/openldap-technical/201003/msg00019.html> Regards, Christian Manal

1 0

(ITS#6585) close is called from dap_unbind_s with fd = -1
by asifiqbal.desai＠gmail.com 01 Jul '10

01 Jul '10

Full_Name: Asif Iqbal Desai Version: 2.4.16 OS: Solaris 10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (130.214.64.6) This is a consulation bug for clarification on close() being called from ldap_unbind_s with fd = 1. The application uses ldap client apis for user authentication. We recently upgraded to use OpenLDAP version 2.4.16 and are getting an unexpected AIO error issue when ldap user authentication is enabled. Investigating further revealed that from ldap_unbind_s ( close(-1) is getting called. However the close function of solaris libaio does a special handling when fd < 0 which causes AIO errors. The application needs solaris aio support and hence cannot link libc before libaio. Is there any specific reason for close being called with fd = -1 from ldap_unbind_s. This issue didnot exist with OpenLDAP 2.3.27. Following is the stacktrace: [1] _libaio_close(0xffffffffffffffff, 0x2, 0x1, 0xffffffff7f300200, 0x0, 0x0), at 0xffffffff7f406a64 [2] sb_stream_close(0x100151d80, 0x0, 0x0, 0xffffffff7f300200, 0x0, 0x0), at 0xffffffff7d21eafc [3] ber_int_sb_close(0x100151d00, 0x0, 0x0, 0xffffffff7f300200, 0x0, 0x0), at 0xffffffff7d21e160 [4] ber_sockbuf_free(0x100151d00, 0x1001497d0, 0x1, 0x1, 0xffffffff7dbad2ec, 0xd), at 0xffffffff7d21cebc [5] ldap_ld_free(0x100149520, 0x1, 0x0, 0x0, 0x100117020, 0xdc3), at 0xffffffff7d26a4bc [6] ldap_unbind_ext(0x100149520, 0x0, 0x0, 0x1001219e0, 0x1001219f8, 0x100121a00), at 0xffffffff7d26a048 [7] ldap_unbind_s(0x100149520, 0x1001471d0, 0x100149520, 0xfffffffffffffff2, 0x0, 0x100117728), at 0xffffffff7d26a55c ... ... Thanks in Advance, Asif Iqbal Desai

1 0

Re: ( ITS#6580)
by gianluigi.nigro＠passepartout.sm 01 Jul '10

01 Jul '10

I think that is right for new implementations, but should be guaranteed compatibility with the old interface (netscape slapi plugin). The patch serves only this purpose (and I have a set of extended operations written through that interfaces that I want to carry on openldap). -------------------------------------------------------------------- Il contenuto di questo messaggio di posta elettronica e ogni eventuale = documento a quest'ultimo allegato puo contenere informazioni la cui = riservatezza e' tutelata ed e' rivolto unicamente agli effettivi = destinatari i quali prendono atto del carattere non strettamente = personale dei messaggi di risposta, che potranno essere noti = all'organizzazione aziendale. Sono vietati la riproduzione e l'uso di = questo messaggio in mancanza di autorizzazione del destinatario. Se = avete ricevuto questo messaggio per errore, vogliate cortesemente = chiamarci immediatamente per telefono o fax e distruggere quanto = ricevuto (compresi i file allegati) senza farne copia. Qualsivoglia = utilizzo non autorizzato del contenuto di questo messaggio costituisce = violazione dell'obbligo di non prendere cognizione della corrispondenza = tra altri soggetti.

1 0

RE: intent of pwdGraceAuthNLimit when using ppolicy overlay
by Licause, Al 30 Jun '10

30 Jun '10

I have been attempting to use the ppolicy overlay on an openldap server running on a Red Hat V5.4 platform with the following components: openldap-servers-2.3.43-3.el5 checkpassword-ldap-0.01-1.2.el5.rf mozldap-6.0.5-1.el5 openldap-2.3.43-3.el5 openldap-debuginfo-2.3.43-3.el5 nss_ldap-253-22.el5_4 openldap-clients-2.3.43-3.el5 openldap-servers-overlays-2.3.43-3.el5 I was unable to get the users password to expire by simply setting a value for pwdMaxAge without the use of the pwdReset parameter. I finally turned on all debugging in the slapd.conf file (value -1) and noticed that the value of pwdGraceAuthNLimit in the default policy, was set to 3, which allowed the ldap user access without changing the password. The disturbing thing about this was the fact that the user is not notifed that their password has expired. I would have thought that if the intent was to allow an expired password, then the user should be notified of not only the fact that their password has expired but how many more grace logins they would be allowed before either having to change the password or having the account disabled. Is this really what development had intended or are there some enhancements to this behavior in a later version ? Thanks, Al Licause HP Services Unix Network Team

1 0

Re: (ITS#6581) API C : freeze of the function "ldap_modify_ext_s"
by philippe.eychart＠mail.pf 25 Jun '10

25 Jun '10

Yet good for me ... Program source : m_connectForm->getLdapHandle()->doModifyEntries( entry( "dc=mydomain", attribute("userPassword", LDAP_MOD_ADD ) ) ); -> ... Debugger trace on breakPoint: this->m_connectForm->getLdapHandle()->getErrorNumber() = 2,, this->m_connectForm->getLdapHandle()->getErrorString() = "Protocol error", Regards, PE Le samedi 26 juin 2010 à 04:46 +0200, masarati(a)aero.polimi.it a écrit : > > Now, ldap_modify_ext_s returns with error = 2 ( Protocol error )... > > Nothing to hurry about, but I had to change the fix (not related to the > issue you reported). No strict need to test again. > > p. >

1 0

Re: (ITS#6581) API C : freeze of the function "ldap_modify_ext_s"
by masarati＠aero.polimi.it 25 Jun '10

25 Jun '10

> Now, ldap_modify_ext_s returns with error = 2 ( Protocol error )... Nothing to hurry about, but I had to change the fix (not related to the issue you reported). No strict need to test again. p.

1 0

Re: R: ITS#6580
by masarati＠aero.polimi.it 25 Jun '10

25 Jun '10

> Hi, > the issue is that in release 2.4.21 is not possible execute an exended > operation registered in a plugin: THIS way doesnt work because slapd (in > extended.c fe_extended(), line 199) only look for built-in extended > operations and not plugin-defined extended operations (in a plugin calling > slapi_pblock_set() with SLAPI_EXT_OP_RET_OID and SLAPI_EXT_OP_RET_VALUE). > > In fe_extended() I tried to extend the search to all extended operations > and now things start to work, but the main question concerns the choice of > backend. > > Uploaded files: > > servers-slapd-extended.patch -> gianluigi.nigro1-100625.patch > servers-slapd-slapi-slapi_overlay.patch -> gianluigi.nigro2-100625.patch I think this approach is not correct, in many senses. First of all, you should use the native API instead of SLAPI. In fact, SLAPI is essentially unsupported. It was intended to give the possibility to somehow recycle software coded according to Netscape's API, but there's little point in developing new code based on that interface. Second, the whole purpose of implementing the slapi overlay was to avoid the pervasive presence of #ifdef LDAP_SLAPI in baseline code. So a more appropriate approach would be to have the slapi overlay register the extended operation using the native API, rather than having #ifdef LDAP_SLAPI in extended.c to check that any extop was loaded using SLAPI, as in gianluigi.nigro1-100625.patch. I can't say anything about gianluigi.nigro2-100625.patch because the file looks corrupted. p.

1 0

R: ITS#6580
by gianluigi.nigro＠passepartout.sm 25 Jun '10

25 Jun '10

This is a multi-part message in MIME format. ------_=_NextPart_001_01CB14A1.5852206C Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, the issue is that in release 2.4.21 is not possible execute an exended = operation registered in a plugin: THIS way doesnt work because slapd (in = extended.c fe_extended(), line 199) only look for built-in extended = operations and not plugin-defined extended operations (in a plugin = calling slapi_pblock_set() with SLAPI_EXT_OP_RET_OID and = SLAPI_EXT_OP_RET_VALUE). In fe_extended() I tried to extend the search to all extended operations = and now things start to work, but the main question concerns the choice = of backend. Uploaded files: servers-slapd-extended.patch -> gianluigi.nigro1-100625.patch servers-slapd-slapi-slapi_overlay.patch -> gianluigi.nigro2-100625.patch -----Messaggio originale----- Da: masarati(a)aero.polimi.it [mailto:masarati@aero.polimi.it]=20 Inviato: mercoled=EC 23 giugno 2010 00:36 A: Gianluigi Nigro Cc: openldap-its(a)openldap.org Oggetto: ITS#6580 No clue about the slapi way, but extended operations can be successfully registered using OpenLDAP's native API, load_extop2(). See for example overlays/dds.c p. -------------------------------------------------------------------- Il contenuto di questo messaggio di posta elettronica e ogni eventuale = documento a quest'ultimo allegato pu=F2 contenere informazioni la cui = riservatezza e' tutelata ed e' rivolto unicamente agli effettivi = destinatari i quali prendono atto del carattere non strettamente = personale dei messaggi di risposta, che potranno essere noti = all'organizzazione aziendale. Sono vietati la riproduzione e l'uso di = questo messaggio in mancanza di autorizzazione del destinatario. Se = avete ricevuto questo messaggio per errore, vogliate cortesemente = chiamarci immediatamente per telefono o fax e distruggere quanto = ricevuto (compresi i file allegati) senza farne copia. Qualsivoglia = utilizzo non autorizzato del contenuto di questo messaggio costituisce = violazione dell'obbligo di non prendere cognizione della corrispondenza = tra altri soggetti. ------_=_NextPart_001_01CB14A1.5852206C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <HTML> <HEAD> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; = charset=3Diso-8859-1"> <META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version = 6.5.7654.12"> <TITLE>R: ITS#6580</TITLE> </HEAD> <BODY>  Hi, the issue is that in release 2.4.21 is not possible execute an exended = operation registered in a plugin: THIS way doesnt work because slapd (in = extended.c fe_extended(), line 199) only look for built-in extended = operations and not plugin-defined extended operations (in a plugin = calling slapi_pblock_set() with SLAPI_EXT_OP_RET_OID and = SLAPI_EXT_OP_RET_VALUE). In fe_extended() I tried to extend the search to all extended operations = and now things start to work, but the main question concerns the choice = of backend. Uploaded files: servers-slapd-extended.patch -> gianluigi.nigro1-100625.patch servers-slapd-slapi-slapi_overlay.patch -> = gianluigi.nigro2-100625.patch -----Messaggio originale----- Da: masarati(a)aero.polimi.it [<A = HREF=3D"mailto:masarati@aero.polimi.it">mailto:masarati@aero.polimi.it</A= >] Inviato: mercoled=EC 23 giugno 2010 00:36 A: Gianluigi Nigro Cc: openldap-its(a)openldap.org Oggetto: ITS#6580 No clue about the slapi way, but extended operations can be = successfully registered using OpenLDAP's native API, load_extop2().  See for = example overlays/dds.c p.    <hr color=3D'#D2D3D2' noshade> Il contenuto di questo messaggio di posta elettronica e = ogni eventuale documento a quest'ultimo allegato pu=F2 contenere = informazioni la cui riservatezza e' tutelata ed e' rivolto unicamente = agli effettivi destinatari i quali prendono atto del carattere non = strettamente personale dei messaggi di risposta, che potranno essere = noti all'organizzazione aziendale. Sono vietati la riproduzione e l'uso = di questo messaggio in mancanza di autorizzazione del destinatario. Se = avete ricevuto questo messaggio per errore, vogliate cortesemente = chiamarci immediatamente per telefono o fax e distruggere quanto = ricevuto (compresi i file allegati) senza farne copia. Qualsivoglia = utilizzo non autorizzato del contenuto di questo messaggio costituisce = violazione dell'obbligo di non prendere cognizione della corrispondenza = tra altri soggetti. </body></html> ------_=_NextPart_001_01CB14A1.5852206C--

1 0

Re: (ITS#6581) API C : freeze of the function "ldap_modify_ext_s"
by philippe.eychart＠mail.pf 25 Jun '10

25 Jun '10

Now, ldap_modify_ext_s returns with error = 2 ( Protocol error )... Thanks, PE Le jeudi 24 juin 2010 à 19:27 +0200, masarati(a)aero.polimi.it a écrit : > The error is in the server: for this specific error, no response is > returned to the client. It is now fixed in HEAD, please test. Thanks, p. >

1 0

Re: (ITS#6581) API C : freeze of the function "ldap_modify_ext_s"
by masarati＠aero.polimi.it 24 Jun '10

24 Jun '10

The error is in the server: for this specific error, no response is returned to the client. It is now fixed in HEAD, please test. Thanks, p.

1 0

Re: (ITS#6584) dynlist group expansion doesn't use internal serach
by quanah＠zimbra.com 23 Jun '10

23 Jun '10

--On Wednesday, June 23, 2010 4:03 PM -0700 Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > --On Wednesday, June 23, 2010 9:53 PM +0000 openldap-its(a)OpenLDAP.org > wrote: > > > Note: this comes in the form of: > > olcObjectClasses: {1}( DynGroupOC:1 NAME 'dgIdentityAux' SUP top > AUXILIARY MAY > ( dgIdentity $ dgAuthz ) ) > > > in dyngroup overlay (it lets you specify the internal identity to use for > the searches/auth identity). Never mind, browsing the dynlist code, I see this is implemented in there. ;) --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6584) dynlist group expansion doesn't use internal serach
by quanah＠zimbra.com 23 Jun '10

23 Jun '10

--On Wednesday, June 23, 2010 9:53 PM +0000 openldap-its(a)OpenLDAP.org wrote: Note: this comes in the form of: olcObjectClasses: {1}( DynGroupOC:1 NAME 'dgIdentityAux' SUP top AUXILIARY MAY ( dgIdentity $ dgAuthz ) ) in dyngroup overlay (it lets you specify the internal identity to use for the searches/auth identity). --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6584) dynlist group expansion doesn't use internal serach
by quanah＠zimbra.com 23 Jun '10

23 Jun '10

Full_Name: Quanah Gibson-Mount Version: 2.4.22 OS: NA URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.45.108) When dynlist expands the group membership from a URI statement, it applies the bind identity to the search to expand it. This does not conform to the dyngroup behavior as was requested. Instead, dynlist should allow expansion by doing an internal search on the specified URI value, so that the binding identity is not required to have "compare" access on the attributes making up the query. This was implemented in dyngroup for security purposes, and those reasons still apply. --Quanah

1 0

(ITS#6583) API C : freeze of the function "ldap_modify_ext_s"
by philippe.eychart＠mail.pf 23 Jun '10

23 Jun '10

Full_Name: Philippe EYCHART Version: last OS: GNU-Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (123.50.75.139) Hi, I have done an error in my program (I know, it's bad ;-) but, according to me, the reponse of the LDAP API C (function: ldap_modify_ext_s) is not appropriate: I've tried to create a new attribute in an existing LDAPEntry (attribute "userPassword"), but with ... no attribute value! Program trace, stopped on this break point: ... -> m_errNo = ldap_modify_ext_s ( m_desc, (*m_entryIn)->getIdentifier().c_str(), tmpMods, NULL, NULL ); this->freeMemory ( tmpMods ); ... At this point, the debugger shows: Function Arguments m_desc = (LDAP *) 0x991820 *m_desc ... ld_errno = 0 ld_error = 0 ... (*(this->m_entryIn))->getIdentifier().c_str() = 0xb92968 "dc=accounts,dc=mydomain",, *tmpMods[0] mod_op = 128 mod_type = 0xa4dc50 "userPassword" mod_vals modv_strvals = 0x0 modv_bvals = 0x0 tmpMods[1] = (LDAPMod *) 0x0 So, there is actually (in "LDAPMod*[]" parameter) a null terminated array of "ldapmod" structures with only one structure defined, a structure where "mod_vals" is empty ... Resultat: when this line (m_errNo = ldap_modify_ext_s...) is executed, no error is returned ; in fact, the program never returns !... Regards. Philippe EYCHART <http://home.gna.org/ldapcppei/Frontends/Howto-5.fr.html>

1 0

(ITS#6582) API C : freeze of the function "ldap_modify_ext_s"
by philippe.eychart＠mail.pf 22 Jun '10

22 Jun '10

Full_Name: Philippe EYCHART Version: last OS: GNU-Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (123.50.75.139) Hi, I have done an error in my program (I know, it's bad ;-) but, according to me, the reponse of the LDAP API C (function: ldap_modify_ext_s) is not appropriate: I've tried to create a new attribute in an existing LDAPEntry (attribute "userPassword"), but with ... no attribute value! Program trace, stopped on this break point: ... -> m_errNo = ldap_modify_ext_s ( m_desc, (*m_entryIn)->getIdentifier().c_str(), tmpMods, NULL, NULL ); this->freeMemory ( tmpMods ); ... At this point, the debugger shows: Function Arguments m_desc = (LDAP *) 0x991820 *m_desc ... ld_errno = 0 ld_error = 0 ... (*(this->m_entryIn))->getIdentifier().c_str() = 0xb92968 "dc=accounts,dc=mydomain",, *tmpMods[0] mod_op = 128 mod_type = 0xa4dc50 "userPassword" mod_vals modv_strvals = 0x0 modv_bvals = 0x0 tmpMods[1] = (LDAPMod *) 0x0 So, there is actually (in "LDAPMod*[]" parameter) a null terminated array of "ldapmod" structures with only one structure defined, a structure where "mod_vals" is empty ... Resultat: when this line (m_errNo = ldap_modify_ext_s...) is executed, no error is returned ; in fact, the program never returns !... Regards. Philippe EYCHART <http://home.gna.org/ldapcppei/Frontends/Howto-5.fr.html>

1 0

(ITS#6581) API C : freeze of the function "ldap_modify_ext_s"
by philippe.eychart＠mail.pf 22 Jun '10

22 Jun '10

Full_Name: Philippe EYCHART Version: last OS: GNU-Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (123.50.75.139) Hi, I have done an error in my program (I know, it's bad ;-) but, according to me, the reponse of the LDAP API C (function: ldap_modify_ext_s) is not appropriate: I've tried to create a new attribute in an existing LDAPEntry (attribute "userPassword"), but with ... no attribute value! Program trace, stopped on this break point: ... -> m_errNo = ldap_modify_ext_s ( m_desc, (*m_entryIn)->getIdentifier().c_str(), tmpMods, NULL, NULL ); this->freeMemory ( tmpMods ); ... At this point, the debugger shows: Function Arguments m_desc = (LDAP *) 0x991820 *m_desc ... ld_errno = 0 ld_error = 0 ... (*(this->m_entryIn))->getIdentifier().c_str() = 0xb92968 "dc=accounts,dc=mydomain",, *tmpMods[0] mod_op = 128 mod_type = 0xa4dc50 "userPassword" mod_vals modv_strvals = 0x0 modv_bvals = 0x0 tmpMods[1] = (LDAPMod *) 0x0 So, there is actually (in "LDAPMod*[]" parameter) a null terminated array of "ldapmod" structures with only one structure defined, a structure where "mod_vals" is empty ... Resultat: when this line (m_errNo = ldap_modify_ext_s...) is executed, no error is returned ; in fact, the program never returns !... Regards. Philippe EYCHART <http://home.gna.org/ldapcppei/Frontends/Howto-5.fr.html>

1 0

ITS#6580
by masarati＠aero.polimi.it 22 Jun '10

22 Jun '10

No clue about the slapi way, but extended operations can be successfully registered using OpenLDAP's native API, load_extop2(). See for example overlays/dds.c p.

1 0

(ITS#6580) slapi extended operation not executed
by gianluigi.nigro＠passepartout.sm 22 Jun '10

22 Jun '10

Full_Name: gianluigi nigro Version: 2.4.21 OS: Linux CentOS release 5.5 ( i686) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (89.186.39.1) An extended operation with slapi plugin does not work, it is never executed because slapd doesnt look for an extended operation registered in a plugin (debugging slapd i verified that the list struct extop_list -extended.c, function find_extop, line 208 - contains only built-in extended operation). 1) The initialization function look like this: char** oids = (char**) slapi_ch_malloc( 2 * sizeof( char * ) ); oids[0] = 1.3.6.1.4.1.35746.2.11.1"; oids[1] = NULL; i_ret = slapi_pblock_set(pb, SLAPI_PLUGIN_EXT_OP_OIDLIST, oids ); if( i_ret == 0 ) i_ret = slapi_pblock_set(pb, SLAPI_PLUGIN_EXT_OP_FN, (void*) extop1_start ); if( i_ret != 0 ) slapi_log_error( SLAPI_LOG_PLUGIN, "extop1_init", "[ERROR] registrazione %s\n", pluginDescription.spd_description ); 2) slapd.conf look like this: ... pluginlog /var/log/caronte/plugin.log plugin extendedop /opt/ldap/slapi/libextop1-plugin.so extop1_init ... After server restart: a) the log file plugin.log tell me that the plugin was successfully registered: ... 06/17/10 10:43:53 plugin_pblock_new: Registered plugin my-plugin 0.1 [mycompany] (description plugin) ... b) and the rootDSE object contains information about my extended operation, an 'ldapsearch -x -s base -b "" "(objectclass=*)" +' output like this: ... supportedControl: 1.3.6.1.1.12 supportedExtension: 1.3.6.1.4.1.35746.2.11.1 supportedExtension: 1.3.6.1.4.1.4203.1.11.1 supportedExtension: 1.3.6.1.4.1.4203.1.11.3 supportedExtension: 1.3.6.1.1.8 But, when i perform the extended operation, no plugin is executed and i get the error code 2 and the slapd log file look like this: Jun 17 09:53:03 linux-setup slapd[11969]: conn=1000 op=1 EXT oid=1.3.6.1.4.1.35746.2.11.1 Jun 17 09:57:33 linux-setup slapd[11969]: conn=1000 op=1 do_extended: unsupported operation "1.3.6.1.4.1.35746.2.11.1" Jun 17 09:57:33 linux-setup slapd[11969]: conn=1000 op=1 RESULT tag=120 err=2 text=unsupported extended operation Is it a bug or a lack of implementation?

1 0

Re: (ITS#6579) syncrepl lost in refreshAndPersist mode
by quanah＠zimbra.com 21 Jun '10

21 Jun '10

--On Monday, June 21, 2010 7:42 AM +0000 haller(a)efrei.fr wrote: > Full_Name: Nicolas Haller > Version: 2.4.22 > OS: FreeBSD 8.0 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (2001:7a8:1:15::143) > > > Hi, > > I have a master LDAP server and two slaves. The slaves use syncrepl in > refreshAndPersist mode. > > it's working until I see the message "connection_read(128): no > connection!" in a slave log file. Here, I must restart the slave slapd to > force the slave to be syncronized. > > I post the syncrepl slave conf: > > syncrepl rid=1 > provider=ldap://ldap-master.blah.net > type=refreshAndPersist > interval=00:00:05:00 > retry="30 +" > searchbase="dc=blah,dc=net" > schemachecking=on > bindmethod=simple > binddn="cn=root,dc=blah,dc=net" > credentials=blahblah It sounds like you have a device between the master and the replicas that cuts the connection after some period of time. If the operating system supports it, you can set a tcp keepalive in the sycnrepl configuration block in 2.4.22. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6579) syncrepl lost in refreshAndPersist mode
by haller＠efrei.fr 21 Jun '10

21 Jun '10

Full_Name: Nicolas Haller Version: 2.4.22 OS: FreeBSD 8.0 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2001:7a8:1:15::143) Hi, I have a master LDAP server and two slaves. The slaves use syncrepl in refreshAndPersist mode. it's working until I see the message "connection_read(128): no connection!" in a slave log file. Here, I must restart the slave slapd to force the slave to be syncronized. I post the syncrepl slave conf: syncrepl rid=1 provider=ldap://ldap-master.blah.net type=refreshAndPersist interval=00:00:05:00 retry="30 +" searchbase="dc=blah,dc=net" schemachecking=on bindmethod=simple binddn="cn=root,dc=blah,dc=net" credentials=blahblah thanks, Nicolas Haller

1 0

(ITS#6578) Mailman subscribtion answer update
by daniel＠pluta.biz 19 Jun '10

19 Jun '10

Full_Name: Daniel Pluta Version: NULL OS: MS-DOS URL: http://www.openldap.org/lists/openldap-software/201005/msg00096.html Submission from: (NULL) (2001:470:9feb:ff02:b173:4a10:490:24af) As the OpenLDAP-software mailinglist has been shutdown Mailman's subscribtion auto answer should perhaps be updated to mention OpenLDAP-technical instead of OpenLDAP-software... For example openldap-devel's current answer is: "... Discussions regarding the use of the software, including use of provided SDKs, should be directed to the OpenLDAP-software mailing list. ..."

1 0

Re: (ITS#6575) Feature Request: ldapsearch ldif export without wrap
by michael＠stroeder.com 18 Jun '10

18 Jun '10

marco.pizzoli(a)gmail.com wrote: > This is a feature request. > > I would like tools like ldapsearch have an option to produce a LDIF export > without wrapping to the next row when the dn is too long. We had this request many times before. And similar the one to avoid base64-encoding of non-ASCII chars. IMO LDIF should simply comply to RFC 2849. There are enough decent LDIF parser modules out there for one of your favourite scripting languages. OpenLDAP should not support half-baked LDIF parsing. Ciao, Michael.

1 0

Re: (ITS#6575) Feature Request: ldapsearch ldif export without wrap
by hyc＠symas.com 18 Jun '10

18 Jun '10

marco.pizzoli(a)gmail.com wrote: > Full_Name: Marco Pizzoli > Version: * > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (193.41.84.11) > > > This is a feature request. > > I would like tools like ldapsearch have an option to produce a LDIF export > without wrapping to the next row when the dn is too long. This is a duplicate of ITS#4269, #6149, and probably a few others. Closing. -- -- 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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs