openldap-bugs

openldap-bugs@openldap.org

21001 discussions

(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

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

27 Jun '19

--On Tuesday, June 25, 2019 7:07 PM +0000 quanah(a)symas.com wrote: > c) That conversion from slapd.conf to cn=config be fixed so that it works. I'm not entirely sure that the fix that went in for this in ec411582d663667d6b638162db51dfa70f5263d3 is correct. Specifically, unlike everything else, there is no associated weight. If in the future other backends (such as SQL, LDAP, etc) support server-wide settings via an olcBackend configuration, the weight would need to exist. root@anvil4:/tmp/q/slapd.d/cn=config# ls -l total 64 -rw------- 1 root root 448 Jun 27 12:19 'cn=module{0}.ldif' drwxr-x--- 2 root root 4096 Jun 27 12:19 'cn=schema' -rw------- 1 root root 39646 Jun 27 12:19 'cn=schema.ldif' -rw------- 1 root root 435 Jun 27 12:19 'olcBackend=mdb.ldif' -rw------- 1 root root 596 Jun 27 12:19 'olcDatabase={-1}frontend.ldif' -rw------- 1 root root 584 Jun 27 12:19 'olcDatabase={0}config.ldif' -rw------- 1 root root 859 Jun 27 12:19 'olcDatabase={1}mdb.ldif' I.e., I was rather expecting: olcBackend={1}mdb.ldif or similar. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

(ITS#9043) Improve loglevel sync logging
by ondra＠openldap.org 26 Jun '19

26 Jun '19

Full_Name: Ondrej Kuznik Version: master OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.10.24.68) The existing replication logs are quite hard to follow. In syncprov, messages about different sessions mingle with no indication where they belong and many important replication decisions are not logged at all. And what is logged is very hard to follow and understand why the provider/consumer does what it does. The following could be done to improve matters: - prepend the request information to syncprov messages - add information to existing messages, especially human-readable commentary that can be followed as a story, giving context in terms of "X happened so doing Y" - log when checkpoints happen, what cookies are generated and why, ... Most of the above is drafted here: https://github.com/mistotebe/openldap/tree/its9043

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