Re: (ITS#8427) Incorrect value of tls_reqcert in syncrepl
by mkp37215＠gmail.com
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
4 years, 2 months
(ITS#9045) Crashes in cn=config (test050)
by ondra＠openldap.org
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.
4 years, 2 months
(ITS#9044) fanruan
by leo.li＠fanruan.com
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-...
, 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 ?
4 years, 2 months
Re: (ITS#8875) [Patch] Performance problems in back-mdb with large DITs and many aliases
by quanah＠symas.com
--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>
4 years, 2 months
Re: Regression after ITS#8427 fix with back-ldap
by quanah＠symas.com
--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>
4 years, 2 months
Re: Regression after ITS#8427 fix with back-ldap
by quanah＠symas.com
--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>
4 years, 2 months
Regression after ITS#8427 fix with back-ldap
by a.chelouah＠gmail.com
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">
<p>Hello,</p>
<p>Commit 6f623dfa1ca65698c19ccc6c058cd170e633384e fixing ITS#8427
(Set up TLS settings on each reconnection) introduce a regression
when the proxy connect to the<b> </b>Backend ldap server via
<a class="moz-txt-link-freetext" href="ldaps://">ldaps://</a><br>
</p>
<p>The relevent part of my config is:<br>
</p>
<p>dn: olcDatabase={2}ldap,cn=config<br>
objectClass: olcDatabaseConfig<br>
objectClass: olcLDAPConfig<br>
olcDatabase: {2}ldap<br>
olcSuffix: dc=local<br>
olcDbURI: <a class="moz-txt-link-freetext" href="ldaps://ldap.local">ldaps://ldap.local</a><br>
olcDbChaseReferrals: TRUE<br>
olcDbRebindAsUser: TRUE<br>
olcDbIDAssertBind: bindmethod=none
tls_cacert=/etc/pki/tls/certs/ca.crt<br>
olcDbIDAssertAuthzFrom: "*"</p>
<p> (I also tried by setting LDAPTLS_CACERT env var when starting
slapd)</p>
<p>On backend ldap server logs, I get the message "TLS negociation
failure"</p>
<p><br>
</p>
<p>Regards<br>
</p>
</body>
</html>
--------------93F3FA89632EC27DC6224304--
4 years, 2 months
Re: (ITS#8977) Make IDL sizes configurable in back-mdb
by quanah＠symas.com
--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>
4 years, 2 months
Re: (ITS#8977) Make IDL sizes configurable in back-mdb
by hyc＠symas.com
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/
4 years, 2 months
