Re: (ITS#8977) Make IDL sizes configurable in back-mdb
by quanah＠symas.com
--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>
4 years, 5 months
(ITS#9043) Improve loglevel sync logging
by ondra＠openldap.org
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
4 years, 5 months
Re: (ITS#8977) Make IDL sizes configurable in back-mdb
by quanah＠symas.com
--On Monday, May 06, 2019 9:28 PM +0000 quanah(a)symas.com wrote:
To further document the issues after further testing with OpenLDAP master
as of 6/25/2019
a) If a value for idlexp is set in a slapd.conf file that is not allowed (<
16 or > 31), converting to cn=config using slaptest will incorrectly report
that the target "slapd.d" directory doesn't exist, like:
/usr/local/etc/openldap# /usr/local/sbin/slaptest -f slapd.conf -F
/tmp/slapd.d
slaptest: bad configuration directory!
ls -ld /tmp/slapd.d
drwxr-xr-x 2 root root 40 Jun 25 17:59 /tmp/slapd.d
b) If the idlexp value is corrected to be within the allowed range, the
converted cn=config database loses the backend configuration and the idlexp
setting:
/usr/local/sbin/slaptest -f slapd.conf -F /tmp/slapd.d
config file testing succeeded
cd /tmp/slapd.d/
find . -type f | xargs grep -i idlexp
./cn=config/cn=schema.ldif:olcAttributeTypes: ( OLcfgBkAt:12.1 NAME
'olcBkMdbIdlExp' DESC 'Power of 2 u
./cn=config/cn=schema.ldif: onfiguration' SUP olcBackendConfig STRUCTURAL
MAY olcBkMdbIdlExp )
No olcBackend... file exists, etc.
Suggested remedies:
a) The man page documentation be updated to note the limitations on valid
ranges for the idlexp setting (16<=x<=31), at least for 64-bit systems.
b) slaptest provides a valid error if the idlexp setting is not within the
valid range (as opposed to complaining the target directory does not exist,
when in fact it does).
c) That conversion from slapd.conf to cn=config be fixed so that it works.
--Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
4 years, 5 months
Re: (ITS#9042) loglevel setting that allows seeing attribute values for MOD operations
by quanah＠symas.com
--On Tuesday, June 25, 2019 5:04 PM +0000 quanah(a)openldap.org wrote:
> Currently there is no way to see what values a client is providing for a
> MOD operation outside of the "packets" debug level. It would be helpful
> for debugging purposes where one does not have control of the client to
> be able to set a loglevel that would expose this information.
STATS2 would be the appropriate loglevel setting.
--Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
4 years, 5 months
Re: (ITS#9041) cyrus.c includes limits.h twice
by quanah＠symas.com
--On Friday, June 21, 2019 10:58 PM +0000 quanah(a)openldap.org wrote:
> This should be cleaned up.
Fixed in b02807ea2f5eaf85e57e67e5851931a116947b94
--Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
4 years, 5 months
Re: (ITS#7996) Tighten race in ldap_int_initialize
by Armin.Tueting＠tueting-online.com
Am Freitag, den 21.06.2019, 13:31 +0200 schrieb Ond=C5=99ej Kuzn=C3=ADk:
[...]
> Hi Armin,
Hi Ondrej,
> thank you very much for your report, this should now be fixed in master
> with commit b2f4cacd4783cfe49370accc712863f9537f9924.
I'm not following 'master' - I'm afraid! But, the commit has been
merged into 'OPENLDAP_REL_ENG_2_4' and slapd is now serving our
requests! So far, so good!
Thanks for your effort!
>=20
> Regards,
Regards,
Armin.
4 years, 5 months
(ITS#9041) cyrus.c includes limits.h twice
by quanah＠openldap.org
Full_Name: Quanah Gibson-Mount
Version: RE24
OS: N/A
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (47.208.128.44)
There appear to have been dueling commits on April 10, 2005 and April 9, 2005,
so that we get:
3e800f20bd (Kurt Zeilenga 2005-04-10 19:32:14 +0000 28)#ifdef
HAVE_LIMITS_H
3e800f20bd (Kurt Zeilenga 2005-04-10 19:32:14 +0000 29)#include
<limits.h>
3e800f20bd (Kurt Zeilenga 2005-04-10 19:32:14 +0000 30)#endif
3e800f20bd (Kurt Zeilenga 2005-04-10 19:32:14 +0000 31)
bc0cc3272c (Kurt Zeilenga 2003-02-21 17:48:03 +0000 32)#include
"ldap-int.h"
bc0cc3272c (Kurt Zeilenga 2003-02-21 17:48:03 +0000 33)
bc0cc3272c (Kurt Zeilenga 2003-02-21 17:48:03 +0000 34)#ifdef
HAVE_CYRUS_SASL
bc0cc3272c (Kurt Zeilenga 2003-02-21 17:48:03 +0000 35)
eca819d866 (Howard Chu 2005-04-09 06:41:39 +0000 36)#ifdef
HAVE_LIMITS_H
eca819d866 (Howard Chu 2005-04-09 06:41:39 +0000 37)#include
<limits.h>
eca819d866 (Howard Chu 2005-04-09 06:41:39 +0000 38)#endif
This should be cleaned up.
4 years, 5 months
Re: (ITS#9037) observing crash in mdb_cursor_put()
by myk＠mykzilla.org
After stepping through the test program in a debugger, I see that
mdb_page_search returns MDB_NOTFOUND if mc->mc_db->md_root is P_INVALID
because the tree is empty. And mdb_cursor_put sets rc to MDB_NO_ROOT if
mc->mc_db->md_root is P_INVALID.
So that can't be related to the crash, at least not in the instances I'm
investigating, because insert_key and insert_data (and hence rc) is
always MDB_NOTFOUND in their minidumps when the crash occurs, which
can't happen when rc is set to MDB_NO_ROOT.
-myk
4 years, 5 months
Re: (ITS#7996) Tighten race in ldap_int_initialize
by ondra＠mistotebe.net
On Tue, Jun 18, 2019 at 07:33:48AM +0000, Armin.Tueting(a)tueting-online.com wrote:
> Am Montag, den 17.06.2019, 15:40 -0700 schrieb Quanah Gibson-Mount:
>> --On Monday, June 17, 2019 7:16 PM +0200 Armin T=C3=BCting=20
>> <Armin.Tueting(a)tueting-online.com> wrote:
>>>> I.e., it started and then got as far as reading your ldap.conf file.
>>>> What is the contents of ldap.conf?
>>> Attached 'ldap.conf'. Nothing unusual...
>>>
>>>> Have you run the test suite (make test)? Does it pass? fail?
>>> Attached 'make_test.txt'. As far as I can see - it has been passed.
>>
>> Ok, so make test passes without issue, so it would appear there's something
>> specific with your configuration that is triggering the problem. Would you
>> be able to provide your slapd configuration (minus any passwords and the
>> like)?
> I'll privately send it to you in a seperate email.
>
>>
>> Additionally, if you could get a full gdb backtrace of the hung slapd=20
>> process that would be useful as well. I.e.:
>>
>> start up slapd
>> gdb /path/to/slapd <pid #>
> (gdb) thr apply all bt full
> #3 0x00007ffa4a92a135 in ldap_pvt_thread_mutex_lock
> #4 0x00007ffa4a944e6e in ldap_set_option
> #5 0x00007ffa4a943ed3 in openldap_ldap_init_w_conf
> #6 0x00007ffa4a944318 in openldap_ldap_init_w_sysconf
> #8 0x00007ffa4a944e38 in ldap_set_option
> #9 0x0000000000413cd6 in main ()
Hi Armin,
thank you very much for your report, this should now be fixed in master
with commit b2f4cacd4783cfe49370accc712863f9537f9924.
Regards,
--
Ondřej Kuzník
Senior Software Engineer
Symas Corporation http://www.symas.com
Packaged, certified, and supported LDAP solutions powered by OpenLDAP
4 years, 5 months
