openldap-bugs June 2010

openldap-bugs@openldap.org

23 participants
57 discussions

(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

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

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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs June 2010