July 2010 - openldap-bugs

Re: (ITS#6586) PASSMOD operations are not getting chained correctly

by moenoel＠informatik.uni-bremen.de

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

13 years, 4 months

1
0
0 / 0

Re: (ITS#6612) Back SQL / Mysql / InnoDB

by f.bosch＠genkgo.nl

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--

13 years, 4 months

1
0
0 / 0

(ITS#6613) Back SQL / Mysql / InnoDB

by frederik.bosch＠gmail.com

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.

13 years, 4 months

1
0
0 / 0

(ITS#6612) Back SQL / Mysql / InnoDB

by frederik.bosch＠gmail.com

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.

13 years, 4 months

1
0
0 / 0

Re: (ITS#6586) PASSMOD operations are not getting chained correctly

by masarati＠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.

13 years, 4 months

1
0
0 / 0

ITS#6611

by masarati＠aero.polimi.it

Likely your ACL is exceeding ACLBUF_MAXLEN (8192, defined in servers/slapd/aclparse.c); you can workaround this issue by increasing that value to something *very* large, while the code is fixed. However, you should fix your configuration by assigning those DNs to a group, and using a group ACL instead. p.

13 years, 4 months

1
0
0 / 0

Re: (ITS#6540) test022-ppolicy is flawed, masks serious stability issue

by masarati＠aero.polimi.it

> Hey Pierangelo, > > I just noticed http://www.openldap.org/its/index.cgi?findid=6574 - this > looks like it fixes the issue I mentioned in > http://www.openldap.org/its/index.cgi?findid=6540? Is that assertion > correct? I couldn't specifically look at your issue (apart from the simple fix to allow cn=config to work). ITS#6574 should have nothing to do with your issue, as it affects back-meta in a part that has no code commonality with back-ldap, and slapo-chain is built on top of back-ldap. I'm sorry I went back through this thread and got somehow lost; what's the exact topic now? I infer (from followup #14) that there seems to be an issue about chaining because slapo-chain seems not to rebind as expected. Could you isolate the problem in a minimal setup (slapd.conf or the corresponding back-config's LDIF, a database and a simple operation that can be performed with ldapmodify/ldappasswd or so) to clearly reproduce the issue? Thanks, p.

13 years, 4 months

1
0
0 / 0

(ITS#6611) slapd: segmentation fault caused by large ACL

by leonardo＠ngdn.org

Full_Name: Leonardo Chiquitto Version: 2.4.23 OS: openSUSE URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (189.101.104.29) Setting up a large ACL entry (as the example below) in slapd.conf will make slapd crash with a segmentation fault when starting up. access to dn.subtree="ou=autofs,ou=l,dc=ngdn,dc=org" by dn.base="cn=1,ou=autofs,ou=l,dc=ngdn,dc=org" read by dn.base="cn=2,ou=autofs,ou=l,dc=ngdn,dc=org" read (...) by dn.base="cn=149,ou=autofs,ou=l,dc=ngdn,dc=org" read by dn.base="cn=150,ou=autofs,ou=l,dc=ngdn,dc=org" read Here's the back trace: Program terminated with signal 11, Segmentation fault. #0 0x00007fd98e223b68 in avl_find (root=0x3d63642c6c3d756f, data=0x7fffa163d0c0, fcmp=0x7fd98e1400e0 <attr_index_name_cmp>) at avl.c:545 545 while ( root != 0 && (cmp = (*fcmp)( data, root->avl_data )) != 0 ) { (gdb) bt #0 0x00007fd98e223b68 in avl_find (root=0x3d63642c6c3d756f, data=0x7fffa163d0c0, fcmp=0x7fd98e1400e0 <attr_index_name_cmp>) at avl.c:545 #1 0x00007fd98e13ef9f in at_bvfind (name=0x7fffa163d0c0) at at.c:126 #2 0x00007fd98e13d61d in slap_bv2ad (bv=0x7fd98e5b7880, ad=0x7fffa163d5a8, text=0x7fffa163d5a0) at ad.c:201 #3 0x00007fd98e10c81b in LDAPRDN_rewrite (rdn=0x7fd98e5b78c0, flags=<value optimized out>, ctx=0x0) at dn.c:285 #4 0x00007fd98e10c970 in LDAPDN_rewrite (dn=<value optimized out>, flags=0, ctx=0x0) at dn.c:406 #5 0x00007fd98e10e495 in dnNormalize (use=<value optimized out>, syntax=<value optimized out>, mr=<value optimized out>, val=0x7fd98e4bc1e8, out=0x7fd98e4bc1f8, ctx=0x0) at dn.c:446 #6 0x00007fd98e0ea70d in read_config ( fname=0x7fd98e535030 "/etc/openldap/slapd.conf", dir=0x0) at bconfig.c:4101 #7 0x00007fd98e0dbbf9 in main (argc=13, argv=0x7fffa163d8c8) at main.c:767

13 years, 4 months

1
0
0 / 0

Re: (ITS#6532) Support for common orderingMatching rules in extensible match filters

by daniel＠pluta.biz

The patch can be downloaded from here: ftp://ftp.openldap.org/incoming/servers-slapd-schema_init.patch.2 passive ftp rules - sorry for the confusion

13 years, 4 months

1
0
0 / 0

Re: (ITS#6610) Client receives SIGPIPE when connected via ldapi with TLS

by hyc＠symas.com

jzeleny(a)redhat.com wrote: > Full_Name: Jan Zeleny > Version: 2.4.23 > OS: Linux > URL: http://jzeleny.fedorapeople.org/debug/openldap/sigpipe-traces.tar.bz2 > Submission from: (NULL) (209.132.186.34) > > > When running slapd listening on local socket (ldapi:///), clients connecting to > it will sometimes SIGPIPE when using TLS. This happens in about 70% times. > > How to reproduce: > generate a pem certificate > slapd -h ldapi:/// > ldapsearch -H ldapi:/// -ZZ -x -d -1 > > I'm attaching straces from both slapd and ldapsearch. What seems to be happening > is that slapd receives EAGAIN during the read from socket, marks it for another > read, but then terminates a reading thread and closes the connection, while > client still wants to write some data. When doing ldapsearch, it does this after > result was returned, that's why it can be seen probably only in debugging mode. > > The issue was originally reported on 2.3.43, but I successfully reproduced it on > newer versions, including 2.4.23. The only exception was Fedora rawhide version > (currently 2.4.22), which is built with NSS instead of OpenSSL. NSS (and NSPR) > doesn't seem to support local sockets at all, so it is not possible to use ldapi > with -ZZ any more. Not sure this is worth investigating, since there's no reason to use TLS on ldapi://, and as you already said, it won't even be possible with the upcoming (rawhide) packages. > I'm attaching straces from both successful and unsuccessful run. For complete > information here is URL of relevant redhat bugzilla: > https://bugzilla.redhat.com/show_bug.cgi?id=564108 In regards to the original report, just leave ssl off in the nss_ldap config. Use the starttls URL extension instead. ldap://host/????starttls -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

13 years, 4 months

1
0
0 / 0

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs July 2010