openldap-bugs June 2019

openldap-bugs@openldap.org

27 participants
104 discussions

Re: (ITS#8427) Incorrect value of tls_reqcert in syncrepl
by mkp37215＠gmail.com 28 Jun '19

28 Jun '19

Quanah, I can think of three reasons why the patch is causing problems: 1. The patch is three years old and was not validated against the current OpenLDAP version, to which it has been applied. Without additional testing, I am not even sure if the issue that the patch fixes still exists. 2. The patch was not tested in the proxy configuration. 3. The patch changes the way tls_reqcert parameter is handled. It is therefore possible that a setup with an incorrect TLS certificate would stop working. However, that is a general remark and the cause of Abdelkader Chelouah's problems may be entirely different. Unfortunately, I do not feel that I would be able to help with any further work on this patch. Due to the passage of time since this bug was reported, I would need to redo all the work from scratch (my test environment is long gone, and the limited understanding of OpenLDAP internals that I once had, has since faded from my memory). I do not believe that I can afford such an effort, particularly when I worry that the result could be shelved for years again. I would be grateful if others, who are more knowledgeable with OpenLDAP internals, look into this issue. Thank you very much Maciej Puzio

1 0

(ITS#9045) Crashes in cn=config (test050)
by ondra＠openldap.org 28 Jun '19

28 Jun '19

Full_Name: Ondrej Kuznik Version: master OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.10.24.68) Every so often (roughly once in a thousand runs or so it seems), a server will crash in test050 on master. This test replicates cn=config which is not officially supported yet. Some output from a gdb session from the core is uploaded here: ftp://ftp.openldap.org/incoming/test050-crash-master-20190628.txt It's not clear to me how attrs_dup has reached the attribute at 0x170b6a8 unless there was another thread messing with the same structure. str2entry2 is running in another thread, but I wouldn't think it runs on the same entry? Stuff is optimised out in this one.

1 0

(ITS#9044) fanruan
by leo.li＠fanruan.com 27 Jun '19

27 Jun '19

Full_Name: leo.li Version: 2.4.44 OS: CentOS7 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (114.223.227.133) I want to deploy Openldap server with the backend of mysql. By following https://gist.github.com/mahirrudin/9b7754e54f1e8e532049484864beba42#file-ub… , Openldap is started but I can't add new records. Log shows, 5d15b75a <<< dnPrettyNormal: <dc=fanruan,dc=com>, <dc=fanruan,dc=com> 5d15b75a ==>backsql_add("dc=fanruan,dc=com") 5d15b75a oc_check_required entry (dc=fanruan,dc=com), objectClass "dcObject" 5d15b75a oc_check_required entry (dc=fanruan,dc=com), objectClass "organization" 5d15b75a oc_check_allowed type "o" 5d15b75a oc_check_allowed type "objectClass" 5d15b75a oc_check_allowed type "structuralObjectClass" 5d15b75a oc_check_allowed type "dc" 5d15b75a backsql_add("dc=fanruan,dc=com"): create procedure is not defined for structuralObjectClass "organization" - aborting 5d15b75a send_ldap_result: conn=1012 op=1 p=3 5d15b75a send_ldap_result: err=53 matched="" text="operation not permitted within namingContext" 5d15b75a send_ldap_response: msgid=2 tag=105 err=53 ber_flush2: 58 bytes to sd 10 5d15b75a <==backsql_add("dc=fanruan,dc=com"): 53 "operation not permitted within namingContext" 5d15b75a connection_get(10) 5d15b75a connection_get(10): got connid=1012 5d15b75a connection_read(10): checking for input on id=1012 ber_get_next ber_get_next: tag 0x30 len 5 contents: 5d15b75a op tag 0x42, time 1561704282 I know I need to configure mysql table but how to do it? Any guide for it ?

1 0

Re: (ITS#8875) [Patch] Performance problems in back-mdb with large DITs and many aliases
by quanah＠symas.com 27 Jun '19

27 Jun '19

--On Sunday, April 07, 2019 10:15 AM +0000 henrik.bohnenkamp(a)ionos.com wrote: > On Thu, Apr 04, 2019 at 05:32:16PM +0100, Howard Chu wrote: > Hi Howard, > > thanks for your comments. There is now a new version of patches available > in my github repository. Apart from addressing your comments, I have > rebased the patches against the current master branch (quite a lot > activity in the last two months, I have noticed). In particular, the new > function mdb_get_aliases now also uses the global size variables for IDL > dimensions, rather than the previous CPP constants. Had a customer who was hitting this issue try out these patches -- It greatly decreases the search time (from unknown/infinite to 1 minute). Unfortunately slapd then segv's. Working on getting a test database to reproduce the issue with for a good backtrace. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8427) Incorrect value of tls_reqcert in syncrepl
by quanah＠symas.com 27 Jun '19

27 Jun '19

Hello, Unfortunately this patch introduces a regression and breaks existing configurations where the protocol in use is ldaps:///. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: Regression after ITS#8427 fix with back-ldap
by quanah＠symas.com 27 Jun '19

27 Jun '19

--On Thursday, June 27, 2019 11:51 PM +0200 Abdelkader Chelouah <a.chelouah(a)gmail.com> wrote: > > I tried with with > > > olcDbStartTLS: ldaps > > > with no success. > > > Logs on the proxy > > > 2019-06-27T20:46:07.602925+00:00 arrakis slapd-2.4-bb[17262]: conn=1001 > fd=11 ACCEPT from IP=[::1]:46462 (IP=[::1]:10020) > 2019-06-27T20:46:07.603476+00:00 arrakis slapd-2.4-bb[17262]: conn=1001 > op=0 BIND dn="uid=alice,ou=people,dc=local" method=128 > 2019-06-27T20:46:07.609212+00:00 arrakis slapd-2.4-bb[17262]: conn=1001 > op=0 ldap_back_retry: retrying URI="ldaps://arrakis.local:10011" DN="" > 2019-06-27T20:46:07.613435+00:00 arrakis slapd-2.4-bb[17262]: conn=1001 > op=0 RESULT tag=97 err=52 text=Proxy operation retry failed > 2019-06-27T20:46:07.613968+00:00 arrakis slapd-2.4-bb[17262]: conn=1001 > op=1 UNBIND > 2019-06-27T20:46:07.614264+00:00 arrakis slapd-2.4-bb[17262]: conn=1001 > fd=11 closed > > Logs on the backend ldap server > > > 2019-06-27T20:46:07.609971+00:00 arrakis slapd-2.4-aa[14682]: conn=1011 > fd=12 ACCEPT from IP=172.18.0.2:47156 (IP=172.18.0.2:10011) > 2019-06-27T20:46:07.613718+00:00 arrakis slapd-2.4-aa[14682]: conn=1011 > fd=12 closed (TLS negotiation failure) Thanks! Please include the openldap-its list in your replies so that they properly get associated with the relevant ITS. I'll raise this up as a priority for the 2.4.48 release. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: Regression after ITS#8427 fix with back-ldap
by quanah＠symas.com 27 Jun '19

27 Jun '19

--On Thursday, June 27, 2019 9:08 PM +0000 a.chelouah(a)gmail.com wrote: > This is a multi-part message in MIME format. > --------------93F3FA89632EC27DC6224304 > Content-Type: text/plain; charset=utf-8; format=flowed > Content-Transfer-Encoding: 7bit > > Hello, > > Commit 6f623dfa1ca65698c19ccc6c058cd170e633384e fixing ITS#8427 (Set up > TLS settings on each reconnection) introduce a regression when the proxy > connect to the**Backend ldap server via ldaps:// Thanks for the follow up! It may be useful in the future to participate in the testing calls that are noted on the openldap-devel list as well. Does the issue persist if you set: olcDbStartTLS: ldaps as documented in the slapd-ldap(5) man page? Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Regression after ITS#8427 fix with back-ldap
by a.chelouah＠gmail.com 27 Jun '19

27 Jun '19

This is a multi-part message in MIME format. --------------93F3FA89632EC27DC6224304 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hello, Commit 6f623dfa1ca65698c19ccc6c058cd170e633384e fixing ITS#8427 (Set up TLS settings on each reconnection) introduce a regression when the proxy connect to the**Backend ldap server via ldaps:// The relevent part of my config is: dn: olcDatabase={2}ldap,cn=config objectClass: olcDatabaseConfig objectClass: olcLDAPConfig olcDatabase: {2}ldap olcSuffix: dc=local olcDbURI: ldaps://ldap.local olcDbChaseReferrals: TRUE olcDbRebindAsUser: TRUE olcDbIDAssertBind: bindmethod=none tls_cacert=/etc/pki/tls/certs/ca.crt olcDbIDAssertAuthzFrom: "*" (I also tried by setting LDAPTLS_CACERT env var when starting slapd) On backend ldap server logs, I get the message "TLS negociation failure" Regards --------------93F3FA89632EC27DC6224304 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit <html> <head> <meta http-equiv="content-type" content="text/html; charset=UTF-8"> </head> <body text="#000000" bgcolor="#FFFFFF"> Hello, Commit 6f623dfa1ca65698c19ccc6c058cd170e633384e fixing ITS#8427 (Set up TLS settings on each reconnection) introduce a regression when the proxy connect to the Backend ldap server via <a class="moz-txt-link-freetext" href="ldaps://">ldaps://</a> The relevent part of my config is: dn: olcDatabase={2}ldap,cn=config objectClass: olcDatabaseConfig objectClass: olcLDAPConfig olcDatabase: {2}ldap olcSuffix: dc=local olcDbURI: <a class="moz-txt-link-freetext" href="ldaps://ldap.local">ldaps://ldap.local</a> olcDbChaseReferrals: TRUE olcDbRebindAsUser: TRUE olcDbIDAssertBind: bindmethod=none tls_cacert=/etc/pki/tls/certs/ca.crt olcDbIDAssertAuthzFrom: "*" (I also tried by setting LDAPTLS_CACERT env var when starting slapd) On backend ldap server logs, I get the message "TLS negociation failure" Regards </body> </html> --------------93F3FA89632EC27DC6224304--

1 0

Re: (ITS#8977) Make IDL sizes configurable in back-mdb
by quanah＠symas.com 27 Jun '19

27 Jun '19

--On Thursday, June 27, 2019 8:35 PM +0000 hyc(a)symas.com wrote: > No, because order is irrelevant for these. Cool, thanks! I'll continue on with deeper testing then. :) --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8977) Make IDL sizes configurable in back-mdb
by hyc＠symas.com 27 Jun '19

27 Jun '19

Quanah Gibson-Mount wrote: > --On Tuesday, June 25, 2019 7:07 PM +0000 quanah(a)symas.com wrote: >=20 >> c) That conversion from slapd.conf to cn=3Dconfig be fixed so that it = works. >=20 >=20 > I'm not entirely sure that the fix that went in for this in ec411582d66= 3667d6b638162db51dfa70f5263d3 is correct.=C2=A0 Specifically, unlike ever= ything else, there is > no associated weight.=C2=A0 If in the future other backends (such as SQ= L, LDAP, etc) support server-wide settings via an olcBackend configuratio= n, the weight would > need to exist. >=20 > root@anvil4:/tmp/q/slapd.d/cn=3Dconfig# ls -l > total 64 > -rw------- 1 root root=C2=A0=C2=A0 448 Jun 27 12:19 'cn=3Dmodule{0}.ldi= f' > drwxr-x--- 2 root root=C2=A0 4096 Jun 27 12:19 'cn=3Dschema' > -rw------- 1 root root 39646 Jun 27 12:19 'cn=3Dschema.ldif' > -rw------- 1 root root=C2=A0=C2=A0 435 Jun 27 12:19 'olcBackend=3Dmdb.l= dif' > -rw------- 1 root root=C2=A0=C2=A0 596 Jun 27 12:19 'olcDatabase=3D{-1}= frontend.ldif' > -rw------- 1 root root=C2=A0=C2=A0 584 Jun 27 12:19 'olcDatabase=3D{0}c= onfig.ldif' > -rw------- 1 root root=C2=A0=C2=A0 859 Jun 27 12:19 'olcDatabase=3D{1}m= db.ldif' >=20 >=20 > I.e., I was rather expecting: >=20 > olcBackend=3D{1}mdb.ldif >=20 > or similar. No, because order is irrelevant for these. --=20 -- 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 June 2019