openldap-bugs

openldap-bugs@openldap.org

1 participants
20967 discussions

Re: (ITS#6617) back-sql: 64-bit parent IDs get munged
by masarati＠aero.polimi.it 07 Aug '10

07 Aug '10

> 64-bit values for (at least) parent IDs do not get resolved correctly - > only the > lower 32 bits are preserved. This leads up to a crash as it tries to > resolve a > non-existant ID: > > To reproduce: > ldap_entries has a row with an ID of 1,000,000,000 with a parent of > 9,999,999,999 (and > a row 9,999,999,999 for the parent). When back-sql goes to resolve this, the > following shows in the ODBC trace: > > SELECT COUNT(*) FROM > ldap_entry_objclasses,ldap_entries,ldap_static_entries > WHERE ldap_static_entries.id=1410065407 AND > ldap_entries.id=ldap_entry_objclasses.entry_id AND > ldap_entries.keyval=ldap_static_entries.id and ldap_entries.oc_map_id=4 > > (1,410,065,407 = 32-bit rollover of 9,999,999,999). Currently, IDs are hardcoded as 32-bit unsigned (unsigned long) for internal use. In back-sql, we used the same type. I wonder whether it makes sense to allow to customize them (I think using 64-bit regardless of the arch is not a choice). p.

1 0

(ITS#6617) back-sql: 64-bit parent IDs get munged
by 7003＠blargh.com 06 Aug '10

06 Aug '10

Full_Name: Andrew Gray Version: 2.4.23 OS: Debian 5 64-bit URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (131.216.14.1) 64-bit values for (at least) parent IDs do not get resolved correctly - only the lower 32 bits are preserved. This leads up to a crash as it tries to resolve a non-existant ID: To reproduce: ldap_entries has a row with an ID of 1000000000 with a parent of 9999999999 (and a row 9999999999 for the parent). When back-sql goes to resolve this, the following shows in the ODBC trace: SELECT COUNT(*) FROM ldap_entry_objclasses,ldap_entries,ldap_static_entries WHERE ldap_static_entries.id=1410065407 AND ldap_entries.id=ldap_entry_objclasses.entry_id AND ldap_entries.keyval=ldap_static_entries.id and ldap_entries.oc_map_id=4 (1410065407 = 32-bit rollover of 9999999999).

1 0

(ITS#6616) back-sql crashing
by rex.johnston＠gmail.com 06 Aug '10

06 Aug '10

Full_Name: Rex Johnston Version: cvs OS: debian URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (123.255.40.107) Attempting to create an inetOrgPerson interface to a proprietary database schema. Obviously something wrong at this stage, causes slapd to SEGV. gdb tells me that in servers/slapd/back-sql/entry-id.c:backsql_id2entry() bsi->bsi_oc is null going into this call. rc = attr_merge_normalize_one( bsi->bsi_e, slap_schema.si_ad_objectClass, &bsi->bsi_oc->bom_oc->soc_cname, bsi->bsi_op->o_tmpmemctx ); Without any time to absorb any implications, adding this just before the above call // added without any clue... Rex if ( eid->eid_oc == NULL ) return LDAP_NO_SUCH_OBJECT; fixes the SEGV, but not my interface.

1 0

Re: (ITS#6615) objectClass definition and error 65
by quanah＠zimbra.com 04 Aug '10

04 Aug '10

--On Tuesday, August 03, 2010 10:43 PM +0000 philippe.eychart(a)mail.pf wrote: > Full_Name: Philippe EYCHART > Version: 2.4.21 > OS: Ubuntu 9.10 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (123.50.86.106) This is a question better suited to openldap-technical(a)openldap.org, but inheritance works by having included the previous parent. I.e., person <- organizationalPerson <- inetOrgPerson, as in, inetOrgPerson inherits from organizationalPerson, which inherits from person. person <- organizationalPerson and person <- referencePerson are different inheritance trees. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6614) Checking Pre-Requisities
by quanah＠zimbra.com 04 Aug '10

04 Aug '10

--On Tuesday, August 03, 2010 9:06 PM +0000 tcssuneelkumar(a)gmail.com wrote: > Full_Name: Suneel > Version: 2.4.23 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (198.95.226.224) The ITS system is for reporting bugs. For help with building the software, etc, use the openldap-technical(a)openldap.org mailing list. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6615) objectClass definition and error 65
by philippe.eychart＠mail.pf 03 Aug '10

03 Aug '10

Full_Name: Philippe EYCHART Version: 2.4.21 OS: Ubuntu 9.10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (123.50.86.106) Hi, Two structural (top) classes are not allowed in the same entry. (a person is not a posixGroup ...) Multiple inheritance is not allowed. (although "oc_sup_oids" is a "char **" in the structure "LDAPObjectClass" ... 8-| ) But, why "organisationalPerson" and "residentialPerson" are they not allowed (error returned: 65) in the same entry of type "person"? Yet, they both inherit from the same objectClass "person"?!... (And these two concepts are not incompatible...) Is this fact a misinterpretation of the "simple inheritance" or this return is correct?... (On the other hand, it's true that "person" and "posixGroup" inherit both from the same -abstract- objectClass : "top" ...) None of my research does the answer (Is this a bugg in the server or must I implement it like that?), so I turn to you ... Regards. PE <http://home.gna.org/ldapcppei/Frontends/Howto-7.fr.html#ss7.2>

1 0

(ITS#6614) Checking Pre-Requisities
by tcssuneelkumar＠gmail.com 03 Aug '10

03 Aug '10

Full_Name: Suneel Version: 2.4.23 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (198.95.226.224) Hi, I am not a experienced unix admin, but i need to setup OpenLdap 2.4.23 on RedHat Linux environments. As per the Admin guide, There are pre-requisites before we install the openldap. Could you please help me to identify if i have the required pre-install libraries / packages. 1. 4.2.1. Transport Layer Security: [root@tmp]# rpm -q openssl openssl-0.9.8e-12.el5_4.6 2. 4.2.2. Simple Authentication and Security Layer [root@tmp]# rpm -qa | grep -i cyr xorg-x11-drv-cyrix-1.1.0-4 cyrus-sasl-devel-2.1.22-5.el5_4.3 cyrus-sasl-lib-2.1.22-5.el5_4.3 cyrus-sasl-plain-2.1.22-5.el5_4.3 cyrus-sasl-2.1.22-5.el5_4.3 3. Kerberos Authentication Service [root@astro tmp]# rpm -qa | grep krb krb5-devel-1.6.1-36.el5_4.1 krb5-auth-dialog-0.7-1 krb5-libs-1.6.1-36.el5_4.1 pam_krb5-2.2.14-15 krb5-workstation-1.6.1-36.el5_4.1 4. Database Software I have downloaded the latest Oracle Berkley DB (5.0.26) and set it up as per the Berkley install guide. IS this good enough to continue with OpenLdap installation ? Are the 2nd and 3rd pre-requisites are good enough to continue ? Could you also please let me know how to check if the specified pre-requisite is already existing in the server or not. Your help is much appreciated. Thanks

1 0

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

31 Jul '10

Am 31.07.2010 04:46, schrieb masarati(a)aero.polimi.it: >> Every other write gets chained just fine when a slave is in this >> condition. It's only the PASSMOD operations that are stuck. > > One quick question: can you tell the parameters of the offending PASSMOD > operations? I mean: old/new password, password generated automatically or > provided, operation performed for self or by a privileged identity, and > so? > > Thanks, p. > > The PASSMODs are done by Linux 'passwd', using pam_ldap (mostly on Debian Lenny, if that matters). The new passwords are provided by the user and the operation is perfomed as "self". I don't know if pam_ldap provides the old password as a parameter to the PASSMOD operation. Binding is done with 'simple bind'. The whole SASL/Kerberos stuff is configured and working, but not yet deployed. I could add the client config (PAM, ldap.conf and so on) to the server related stuff in the linked directory, if you need it. Regards, Christian Manal

1 0

Re: (ITS#6612) Back SQL / Mysql / InnoDB
by f.bosch＠genkgo.nl 31 Jul '10

31 Jul '10

This is a multi-part message in MIME format. --------------020601050300000509070509 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I did some more research on this issue. I found that the problem can be solved more addequately by adding a configuration option called transaction_model with the following options default|read_committed|read_uncommitted|repeatable_read|serialize. The option default uses the database default, current OpenLDAP implementation, while the other 4 options set the transaction level explicitly. Since InnoDB has repeatable read as default, this prevents from updating resultsets. "For consistent reads, there is an important difference from the READ COMMITTED isolation level: All consistent reads within the same transaction read the snapshot established by the first read." http://dev.mysql.com/doc/refman/5.0/en/set-transaction.html SQL 2000 by Microsoft and PostgreSQL have read committed as default option. http://msdn.microsoft.com/en-us/library/aa259216%28SQL.80%29.aspx http://www.postgresql.org/docs/8.1/static/transaction-iso.html -- * Frederik Bosch* Partner - Genkgo email: f.bosch(a)genkgo.nl <mailto:f.bosch@genkgo.nl> tel: +31(0)6 241 97 443 *Genkgo V.o.f.* <http://www.genkgo.nl> adres: Rooseveltlaan 162-II postcode : 1078 NT Amsterdam web: www.genkgo.nl <http://www.genkgo.nl> Genkgo logo <http://www.genkgo.nl> Dit e-mailbericht is bestemd voor de geadresseerde(n) en kan vertrouwelijk zijn. Gebruik door anderen dan de geadresseerde(n) is verboden. Als dit bericht niet voor u bestemd is, wordt u vriendelijk verzocht dit aan de afzender te melden en het bericht te vernietigen. Genkgo staat geregistreerd bij de Kamer van Koophandel onder nummer 24296168 --------------020601050300000509070509 Content-Type: multipart/related; boundary="------------040401040908020101090801" --------------040401040908020101090801 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"> </head> <body bgcolor="#ffffff" text="#000000"> I did some more research on this issue. I found that the problem can be solved more addequately by adding a configuration option called transaction_model with the following options default|read_committed|read_uncommitted|repeatable_read|serialize. The option default uses the database default, current OpenLDAP implementation, while the other 4 options set the transaction level explicitly. Since InnoDB has repeatable read as default, this prevents from updating resultsets. "For consistent reads, there is an important difference from the READ COMMITTED isolation level: All consistent reads within the same transaction read the snapshot established by the first read." <a class="moz-txt-link-freetext" href="http://dev.mysql.com/doc/refman/5.0/en/set-transaction.html">http://dev.mysql.com/doc/refman/5.0/en/set-transaction.html</a> SQL 2000 by Microsoft and PostgreSQL have read committed as default option. <a class="moz-txt-link-freetext" href="http://msdn.microsoft.com/en-us/library/aa259216%28SQL.80%29.aspx">http://msdn.microsoft.com/en-us/library/aa259216%28SQL.80%29.aspx</a> <a class="moz-txt-link-freetext" href="http://www.postgresql.org/docs/8.1/static/transaction-iso.html">http://www.postgresql.org/docs/8.1/static/transaction-iso.html</a> <div class="moz-signature">-- <div class="vcard" style="border-top: 1px dotted rgb(153, 153, 153) ! important; padding: 8px ! important; line-height: 14px ! important; font-family: 'Lucida Grande',Verdana,Arial,Sans-Serif ! important; font-size: 10px ! important; color: rgb(85, 85, 85) ! important;"> <div style="border-bottom: 1px dotted rgb(153, 153, 153) ! important; margin: 6px 0pt ! important; width: 420px ! important;"> Frederik Bosch Partner - Genkgo email: <a class="email" href="mailto:f.bosch@genkgo.nl" style="color: rgb(0, 170, 173) ! important; text-decoration: none ! important;">f.bosch(a)genkgo.nl</a> tel: +31(0)6 241 97 443 <a class="organization-name" href="http://www.genkgo.nl" style="color: rgb(0, 170, 173) ! important; text-decoration: none ! important;">Genkgo V.o.f.</a> adres: Rooseveltlaan 162-II postcode : 1078 NT Amsterdam web: <a href="http://www.genkgo.nl" style="color: rgb(0, 170, 173) ! important; text-decoration: none ! important;">www.genkgo.nl</a> <a href="http://www.genkgo.nl"><img class="logo" src="cid:part1.09000506.03080001@genkgo.nl" alt="Genkgo logo" style="border: 0pt none ! important;"></a> </div> <div class="note" style="width: 420px ! important; line-height: 14px; font-family: 'Lucida Grande',Verdana,Arial,Sans-Serif ! important; font-size: 10px ! important; color: rgb(85, 85, 85) ! important;"> Dit e-mailbericht is bestemd voor de geadresseerde(n) en kan vertrouwelijk zijn. Gebruik door anderen dan de geadresseerde(n) is verboden. Als dit bericht niet voor u bestemd is, wordt u vriendelijk verzocht dit aan de afzender te melden en het bericht te vernietigen. Genkgo staat geregistreerd bij de Kamer van Koophandel onder nummer 24296168 </div> </div> </div> </body> </html> --------------040401040908020101090801 Content-Type: image/png; name="genkgo_signature_logo.png" Content-Transfer-Encoding: base64 Content-ID: <part1.09000506.03080001(a)genkgo.nl> Content-Disposition: attachment; filename="genkgo_signature_logo.png" iVBORw0KGgoAAAANSUhEUgAAAF4AAAAYCAMAAABEDbotAAAAGXRFWHRTb2Z0d2FyZQBBZG9i ZSBJbWFnZVJlYWR5ccllPAAAAKhQTFRFIh8fAKqs////WVdXyMfHv+rqkI+P8fHxEK+xQL/B MC0tYMrLg4GBz+/v7/r6TElJr+TlILW2Z2VlrKur3/T1dXNzPjs7f9TVnp2dMLq8n9/gcM/Q UMXGurm5gNXW4+Pj1dXVj9rbDXZ3BJmaAqGjF0pLICgoFVNUEWVm1tXVCYeJGkJCHDk5C3+A BpCSS0lJodbXE1xdU3FxHjAxKZKTsdzcgszN////7KRBsQAAADh0Uk5T//////////////// /////////////////////////////////////////////////////////wA7XBHKAAADR0lE QVR42qyW6ZbbNgyFQVGUZO3raLOssWfLLEnbLOX7v1kvSEnj9CSe+pzih0hr+QACl6BJL+ZP Hqy71VdZLGV16TnZYW5osRvPvwJ/Q+R9iPdjotfTFyHEy1/fKJz+Ox7xfBi9n9HbixB97qid EKdHiq/Bux/gQX9C4EXqwCIh7t4uL/hKfGPo4sB054jZ/dvlb67Cu/QqIqUOBj8UtVNHXx5v 1ue3ZUgUNhBVpTsZkkTlPSljt4QKqgUP/cgpR2JFP7ZtpNM2ECKIasZLuosAzkfHSRwhEsz7 T2vBJtrMy+yY+RIO7dw1+ArXMhKbJYUdg0TTTA8GWQTwnu/FkV3dU2bxwGRux3qV0GDoQWIU S+MFv4nl7M780p/AjWrPC9jxMiJ2V2iq6GTwxwE3+nrPBVbiwe4Hjg4bDYkobaDaA4qjd43m 2ZHmn3OLj7VOwRxyXJTWA4acPLpDVaM9qOkhcPJgcJy9+GQrxkyfi0+lx0zXrAQ8iYdySZoJ AfidxauRw4Zh3uJdDDsBzSs4cA5IHfx+tviZc2GcdJLO7QxvXtGsuJydiGRnPGndI12MDwDk kIsxT/BagMq8LHqL11bh/xYf8lOd9ktdI73ioZ4Ia7sfkRbgByfpxeEQ1bVYk2NyzTRfLxnR lrvg2UNnw093Riyt1uOCN8np6DMkeTR7yqlFwDUoxBPZxgbNNa47L+sw7dSff8Zz4REMRHNU KsV9ZCjAqDhRdEtPQZ1EFu8UA1978Zhtu1JOqKjrz6abul0cloCWZ3if0/PDCBOWaCxe7FUe GGHqDNLp0XBSlmfuGF2eqNt0v1i1tWzKbBde8Wbvfd02VZCO61QBX2Ff4eYu4AQdolwN4v4x XJr+9M5fy5xV0uJX3Zt9Qd83fqS5J6AAiWlpEhsLW21XA59gDMTrGrwfhxSj35QG47tT5/7m sEkgvLZtx8LWFVmq14Yc0kk57/b3AzXLR+V6GCG7FztnjXgNT3H0Px8ntyFNZ/h4o3Nls2n2 uT02F/HKlDOth4J3178PQ/mHv9Gfw/fD5Kycl0/gNNhSP/ziKK/KeHKfnWe3apr57HFnu3BZ fXSu1JFxEETqV/8UkKGuwaEQV77+P+0fAQYAR9P6f2qWAZwAAAAASUVORK5CYII= --------------040401040908020101090801-- --------------020601050300000509070509--

1 0

(ITS#6613) Back SQL / Mysql / InnoDB
by frederik.bosch＠gmail.com 31 Jul '10

31 Jul '10

Full_Name: Frederik Bosch Version: openldap_2.4.11-1+lenny1 OS: debian URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (80.56.158.179) http://www.openldap.org/lists/openldap-technical/201007/msg00390.html Problem Description: using InnoDB as MySQL table engine prevents records from updating. This is due to the autocommit=0 implementation in InnoDB. There are two possible solutions. 1. Execute COMMIT before every SELECT statement 2. Disable autocommit My suggestion is to use the latter one by adding a configuration option for slapd.conf to enable autocommit. Something like disable_autocommit no|yes, which defaults to yes (current implementation). Perhaps, this will have issues for write mode (INSERT), but this backend is intended for read only usage, isn't it? My C knowledge is too limited to add a patch myself. More details can be found in pasted mailing list thread.

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