--On Friday, August 17, 2018 12:56 PM +0000 muthaiyan1991(a)gmail.com wrote:
> Full_Name: Muthaiyan Vel
> Version: 2.4.46
> OS: Solaris 10
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (116.197.184.12)
>
>
> I have recently updated openldap to version 2.4.46. After upgrading SLAPD
> is failed to start. Its showing an error "slap_sasl_init: auxprop add
> plugin failed".
> I have compiled the openldap with mdb.
>
> Please help to solve this problem.
Hello Muthaiyan,
The ITS system is for reporting software bugs. Usage questions such as
this belong on the openldap-technical mailing list
(<http://www.openldap.org/lists/mm/listinfo/openldap-technical>) and would
receive a much quicker response time.
I would note that your log was not "full debug" mode as you stated (which
would be -d -1), and the warning you encountered is common and not
indicative of an actual problem.
This ITS will be closed.
Regards,
Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
--On Friday, November 16, 2018 8:26 PM +0000 quanah(a)symas.com wrote:
> The note for the -w argument does not apply to back-mdb, since back-mdb
> uses an isolated snapshot of the database when performing the slapcat.
> Thus the out of order "hot change" issue does not apply (which is the
> problem with using -w with back-bdb/hdb).
<https://github.com/quanah/openldap-scratch/tree/its8902>
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
The note for the -w argument does not apply to back-mdb, since back-mdb
uses an isolated snapshot of the database when performing the slapcat.
Thus the out of order "hot change" issue does not apply (which is the
problem with using -w with back-bdb/hdb).
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
Hi Alexey,
If you are using standard syncrepl (rather than delta-syncrepl), I'm not
sure what you're reporting is out of the ordinary and is not indicative of
a memory link. This is also why the issue "resolves" when ldap2 is
stopped. I.e., the issue is related to how syncrepl functions and what it
stores in memory while the lagging consumer is pulling down the database.
I suggest switching to using delta-syncrepl and seeing if you see the same
issue.
Regards,
Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
--On Wednesday, September 26, 2018 8:40 PM +0000 au(a)hcsd.de wrote:
> Full_Name: Stephan Austerm.hle
> Version: 2.4.46
> messages when the provider has an empty accesslog (because it was freshly
> setup and nothing has been added/updated since then).
Hi Stephan,
Are you positive you tested this with the OpenLDAP 2.4.46 Release? I
already reported this issue via ITS#8100, which was explicitly fixed in
2.4.46.
Regards,
Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
--On Thursday, November 15, 2018 6:51 AM +0000
raghavendra.gadiga(a)capgemini.com wrote:
Hello,
The ITS system is for bug reports. Usage questions, such as how to
properly tune OpenLDAP and its data backends belong on the
openldap-technical(a)openldap.org project list. Please redirect your
questions there.
<http://www.openldap.org/lists/mm/listinfo/openldap-technical>
Regards,
Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
Full_Name: Raghavendra
Version: 2.4.44
OS: Debian GNU/Linux 9
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (203.191.35.25)
Hi Team,
We have noticed the ldap getting crash. Even the ldap process is running, we
cant fetch the data in it, After debugging it we noticed that by removing the
DB_CONFIG and restarting the service it started to work.
1) Can you let us know what was the cause.
2) Whats the ideal memory\cpu to be kept for ldap server.
3) Can you suggest tool which we can install to debug more.
4) More details about log setup for ldap.
-Raghavendra.Gadiga
Full_Name: Quanah Gibson-Mount
Version: 2.4.46
OS: Linux
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (47.208.148.239)
When adding a new entry to cn=config, the code path currently does not check the
value returned by rdnNoramlize. This needs to be fixed in case of a
normalization error.
--On Tuesday, July 17, 2018 5:35 AM +0000 jroose(a)gmail.com wrote:
> This is a significant bug in this module, because it causes the hash
> algorithm to fail to be replicable by outside hash implementations 1 out
> of every 64 hashes on average.
Thanks for the report. This is now fixed in git master:
- Log -----------------------------------------------------------------
commit d40a832db011985d6a6b787a88dd802b02d5d5dc
Author: Ond??ej Kuzn??k <ondra(a)openldap.org>
Date: Thu Nov 8 11:09:38 2018 +0000
ITS#8878 Include the first character in the transformation
-----------------------------------------------------------------------
--Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>