openldap-bugs

openldap-bugs@openldap.org

1 participants
20966 discussions

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

(ITS#6577) OL failes to delete valid entries
by quanah＠zimbra.com 17 Jun '10

17 Jun '10

Full_Name: Quanah Gibson-Mount Version: RE24 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.45.108) When running test008 in a loop, it will occasionally fail. Investigation shows that it fails to delete an entry known to exist in the database: Here we can see a search that finds the entry: conn=1028 op=433 SRCH base="dc=example,dc=com" scope=2 deref=0 filter="(cn=james*)" conn=1028 op=433 SRCH attr=cn sn => hdb_search bdb_dn2entry("dc=example,dc=com") search_candidates: base="dc=example,dc=com" (0x00000001) scope=2 => hdb_dn2idl("dc=example,dc=com") => bdb_equality_candidates (objectClass) => key_read bdb_idl_fetch_key: [b49d1940] <= bdb_index_read: failed (-30988) <= bdb_equality_candidates: id=0, first=0, last=0 => bdb_substring_candidates (cn) => key_read bdb_idl_fetch_key: [0d554a2b] <= bdb_index_read 4 candidates <= bdb_substring_candidates: 4, first=12, last=148 bdb_search_candidates: id=4 first=12 last=148 => send_search_entry: conn 1028 dn="cn=James A Jones 1,ou=Alumni Association,ou=People,dc=example,dc=com" ber_flush2: 146 bytes to sd 34 <= send_search_entry: conn 1028 exit. => send_search_entry: conn 1028 dn="cn=James A Jones 2,ou=Information Technology Division,ou=People,dc=example,dc=com" ber_flush2: 157 bytes to sd 34 <= send_search_entry: conn 1028 exit. => send_search_entry: conn 1028 dn="cn=James A Jones 2,ou=Alumni Association,ou=People,dc=example,dc=com" ber_flush2: 146 bytes to sd 34 <= send_search_entry: conn 1028 exit. => send_search_entry: conn 1028 dn="cn=James A Jones 4,ou=People,dc=example,dc=com" ber_flush2: 122 bytes to sd 34 <= send_search_entry: conn 1028 exit. A few lines further, this entry is deleted: => send_search_entry: conn 1049 dn="cn=James A Jones 1,ou=Alumni Association,ou=People,dc=example,dc=com" ber_flush2: 47 bytes to sd 29 ber_flush2: 146 bytes to sd 32 <= send_search_entry: conn 1056 exit. send_ldap_result: conn=1056 op=289 p=3 send_ldap_result: err=0 matched="" text="" send_ldap_response: msgid=290 tag=101 err=0 ber_flush2: 15 bytes to sd 29 conn=1056 op=289 SEARCH RESULT tag=101 err=0 nentries=1 text= bdb_dn2entry("cn=james a jones 4,ou=people,dc=example,dc=com") <=- hdb_delete: no such object cn=James A Jones 4,ou=People,dc=example,dc=com send_ldap_result: conn=1002 op=44 p=3 send_ldap_result: err=10 matched="ou=People,dc=example,dc=com" text="" send_ldap_response: msgid=45 tag=107 err=32 ber_flush2: 41 bytes to sd 14 The resulting diff show the entry still exists in the generated database: [root@build01 tests]# diff -u testrun/ldapsearch.flt testrun/ldif.flt --- testrun/ldapsearch.flt 2010-06-17 16:12:41.000000000 -0700 +++ testrun/ldif.flt 2010-06-17 16:12:41.000000000 -0700 @@ -308,25 +308,6 @@ facsimileTelephoneNumber: +1 313 555 8688 telephoneNumber: +1 313 555 7334 -dn: cn=James A Jones 4,ou=People,dc=example,dc=com -objectClass: OpenLDAPperson -cn: James A Jones 4 -cn: James Jones -cn: Jim Jones -sn: Jones -uid: jaj -postalAddress: Alumni Association $ 111 Maple St $ Anytown, MI 48109 -seeAlso: cn=All Staff,ou=Groups,dc=example,dc=com -userPassword:: OiBhbUZx -homePostalAddress: 3882 Beverly Rd. $ Anytown, MI 48105 -homePhone: +1 313 555 4772 -description: Outstanding -title: Mad Cow Researcher, UM Alumni Association -pager: +1 313 555 3923 -mail: jaj(a)mail.alumni.example.com -facsimileTelephoneNumber: +1 313 555 4332 -telephoneNumber: +1 313 555 0895 - dn: cn=Jane Doe,ou=Alumni Association,ou=People,dc=example,dc=com objectClass: OpenLDAPperson cn: Jane Doe

1 0

Re: (ITS#6572) slapd crash caused by refint's cn=config modification
by mbackes＠symas.com 17 Jun '10

17 Jun '10

--Apple-Mail-174--9407050 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hello, Daniel and Quanah. > I've tested your patch against HEAD and there seems to be a bug left = open within (or even newly introduced by?) your patch: > I've added Quanah into cc as his Call for 2.4.43RE testing seems to = depend on this ITS. > *** glibc detected *** /usr/local/openldap/sbin/slaptest: free(): = invalid pointer: 0x09d507d8 *** Heh, oops. Extra & in the add case for one of the attributes. Sorry = for the noise. See attached patch. Matthew Backes Symas Corporation mbackes(a)symas.com --Apple-Mail-174--9407050 Content-Disposition: attachment; filename=its-6572-amendment.txt Content-Type: text/plain; x-unix-mode=0644; name="its-6572-amendment.txt" Content-Transfer-Encoding: 7bit Index: refint.c =================================================================== RCS file: /repo/OpenLDAP/pkg/ldap/servers/slapd/overlays/refint.c,v retrieving revision 1.19.2.14 diff -u -r1.19.2.14 refint.c --- refint.c 13 Jun 2010 17:38:37 -0000 1.19.2.14 +++ refint.c 17 Jun 2010 18:04:18 -0000 @@ -263,8 +263,8 @@ break; case REFINT_MODIFIERSNAME: if ( !BER_BVISNULL( &c->value_ndn )) { - ch_free( &dd->refint_dn.bv_val ); - ch_free( &dd->refint_ndn.bv_val ); + ch_free( dd->refint_dn.bv_val ); + ch_free( dd->refint_ndn.bv_val ); dd->refint_dn = c->value_dn; dd->refint_ndn = c->value_ndn; rc = 0; --Apple-Mail-174--9407050--

1 0

Re: (ITS#6572) slapd crash caused by refint's cn=config modification
by daniel＠pluta.biz 17 Jun '10

17 Jun '10

Hi Matthew, I've tested your patch against HEAD and there seems to be a bug left open within (or even newly introduced by?) your patch: I've added Quanah into cc as his Call for 2.4.43RE testing seems to depend on this ITS. Executive summary: ;-) ====================== *** glibc detected *** /usr/local/openldap/sbin/slaptest: free(): invalid pointer: 0x09d507d8 *** Technical details: ;-) ====================== If I remove the following refint configuration directive from cn=config's refint-ldif file: olcRefintModifiersName: uid=refintOverlay,ou=users,ou=mgmt,ou=example.com,dc=f oo,dc=bar slaptest & slapd both startup fine. If the above statement is contained in the current configuration it results in an "invalid pointer" crash during slaptest and also during slapd startup (see below)... Cheers Daniel ldif_read_file: read entry file: "slapd.d/cn=config/olcDatabase={2}hdb/olcOverlay={4}refint.ldif" => str2entry: "dn: olcOverlay={4}refint objectClass: olcOverlayConfig objectClass: olcRefintConfig olcOverlay: {4}refint olcRefintAttribute: secretary olcRefintAttribute: manager olcRefintAttribute: roleOccupant olcRefintAttribute: member olcRefintAttribute: memberOf olcRefintAttribute: owner olcRefintNothing: uid=refintOverlay,ou=users,ou=mgmt,ou=example.com,dc=foo,dc= bar olcRefintModifiersName: uid=refintOverlay,ou=users,ou=mgmt,ou=example.com,dc=f oo,dc=bar structuralObjectClass: olcRefintConfig entryUUID: ac810092-0b82-102f-9080-ed6f5f0ebf63 creatorsName: cn=config createTimestamp: 20100613215924Z entryCSN: 20100614121813.528580Z#000000#000#000000 modifiersName: cn=ldapmanager,cn=config modifyTimestamp: 20100614121813Z " >>> dnPrettyNormal: <olcOverlay={4}refint> <<< dnPrettyNormal: <olcOverlay={4}refint>, <olcOverlay={4}refint> >>> dnPretty: <uid=refintOverlay,ou=users,ou=mgmt,ou=example.com,dc=foo,dc=bar> <<< dnPretty: <uid=refintOverlay,ou=users,ou=mgmt,ou=example.com,dc=foo,dc=bar> >>> dnPretty: <uid=refintOverlay,ou=users,ou=mgmt,ou=example.com,dc=foo,dc=bar> <<< dnPretty: <uid=refintOverlay,ou=users,ou=mgmt,ou=example.com,dc=foo,dc=bar> >>> dnPretty: <cn=config> <<< dnPretty: <cn=config> >>> dnNormalize: <cn=config> <<< dnNormalize: <cn=config> >>> dnPretty: <cn=ldapmanager,cn=config> <<< dnPretty: <cn=ldapmanager,cn=config> >>> dnNormalize: <cn=ldapmanager,cn=config> <<< dnNormalize: <cn=ldapmanager,cn=config> <= str2entry(olcOverlay={4}refint) -> 0x9cd6a04 >>> dnPrettyNormal: <uid=refintOverlay,ou=users,ou=mgmt,ou=example.com,dc=foo,dc=bar> <<< dnPrettyNormal: <uid=refintOverlay,ou=users,ou=mgmt,ou=example.com,dc=foo,dc=bar>, <uid=refintoverlay,ou=users,ou=mgmt,ou=example.com,dc=foo,dc=bar> >>> dnPrettyNormal: <uid=refintOverlay,ou=users,ou=mgmt,ou=example.com,dc=foo,dc=bar> <<< dnPrettyNormal: <uid=refintOverlay,ou=users,ou=mgmt,ou=example.com,dc=foo,dc=bar>, <uid=refintoverlay,ou=users,ou=mgmt,ou=example.com,dc=foo,dc=bar> >>> dnPrettyNormal: <uid=refintOverlay,ou=users,ou=mgmt,ou=example.com,dc=foo,dc=bar> <<< dnPrettyNormal: <uid=refintOverlay,ou=users,ou=mgmt,ou=example.com,dc=foo,dc=bar>, <uid=refintoverlay,ou=users,ou=mgmt,ou=example.com,dc=foo,dc=bar> >>> dnPrettyNormal: <uid=refintOverlay,ou=users,ou=mgmt,ou=example.com,dc=foo,dc=bar> <<< dnPrettyNormal: <uid=refintOverlay,ou=users,ou=mgmt,ou=example.com,dc=foo,dc=bar>, <uid=refintoverlay,ou=users,ou=mgmt,ou=example.com,dc=foo,dc=bar> *** glibc detected *** /usr/local/openldap/sbin/slaptest: free(): invalid pointer: 0x09d507d8 *** ======= Backtrace: ========= /lib/i686/cmov/libc.so.6(+0x6b321)[0xb735c321] /lib/i686/cmov/libc.so.6(+0x6cb78)[0xb735db78] /lib/i686/cmov/libc.so.6(cfree+0xAborted Matthew Backes schrieb: > Here's a patch that fixes 6572. > > * Switch to use BER_BVISNULL, BER_BVZERO, and ch_free instead > * Clean up Ozone's "breadcrumbs" while we're at it (unrelated but trivial) > * Should apply cleanly to RE24 and HEAD > * Older dyn-config refints (RE22, RE23) likely have the same problem > > Matthew Backes > Symas Corporation > mbackes(a)symas.com > >

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