(ITS#8268) slapd-ldap quarantine, per configuration retries fail
by nvoutsin＠gmai.com
Full_Name: Nikos Voutsinas
Version: 2.4.42
OS: Solaris/Linux
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (62.38.193.214)
Hi,
In a 4-nodes MMR deployment with a 2-nodes LDAP Proxy Front-ends, we have
repeatedly noticed that whenever the connection recovery method falls into the
quarantine code, it fails.
i.e. when all the back-end ldap servers become unavailable, for some reason,
slapd-ldap fails to follow the retry scheme that is dictated by
olcDbQuarantine.
In our case we set olcDbQuarantine to: 10,30;60,+ and when we got a temporary
network timeout from all back-end ldap server this is what we saw in the slapd
logs.
Oct 7 21:30:58 proxy slapd[330]: conn=632725 op=0 ldap_back_retry: retrying
URI="ldap://back01 ldap://back02" DN=""
Oct 7 21:30:58 proxy slapd[330]: conn=632725 op=0: ldap_back_quarantine enter.
Oct 7 21:31:08 proxy slapd[330]: conn=632759 op=0: ldap_back_getconn quarantine
retry block #0 try #0.
After that the only method to recover was either to restart the whole process or
reset the value of olcDbQuarantine.
Thanks,
Nikos
7 years, 5 months
(ITS#8267) contributing a new overlay unicodepw
by ingo.voss＠gmail.com
Full_Name: Ingo Voss
Version:
OS:
URL: ftp://ftp.openldap.org/incoming/contrib-slapd-modules-unicodepw.tar
Submission from: (NULL) (78.53.86.212)
Hello,
I wrote a small overlay, that restricts all LDAP modification requests, so that
only password changes for MS unicodePwd are possible.
All other LDAP requests will not be observed.
If someone needs a read-only proxy (in a e.g. dmz) for an MS Active Directory,
but password changes must be possible, then unicodepw is the right overlay.
For more informations, a manual page is included.
Kindly regards
Ingo Voss
7 years, 5 months
(ITS#8266) empty ldapmodify refused with slapo-unique
by geert＠hendrickx.be
Full_Name: Geert Hendrickx
Version: 2.4.42
OS:
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (212.123.14.2)
When slapo-unique constraints are in effect, it seems empty updates are
no longer allowed:
$ ldapmodify -x -h localhost -D cn=Manager,dc=my-domain,dc=com -w secret
dn: cn=test1,dc=my-domain,dc=com
changetype: modifyA%A
modifying entry "cn=test1,dc=my-domain,dc=com"
ldap_modify: Invalid syntax (21)
additional info: unique_modify() got null op.orm_modlist
Why is this considered invalid syntax? Without slapo-unique constraint,
empty updates like these are accepted.
7 years, 5 months
Re: (ITS#8263) Broken cursor tracking in mdb_cursor_put()
by h.b.furuseth＠usit.uio.no
On 07/10/15 07:37, Howard Chu wrote:
> Note: It's tempting to just merge the new xcursor_init2 function into
> xcursor_init1 since they're very similar, but that's a bad idea. The
> xcursor_init1 function really is meant for init'ing an unused cursor;
> it's expected that immediately after, a full cursor-positioning action
> will occur.
>
> xcursor_init2 is meant for xcursors that have already been positioned,
> in which case their physical position is updated in order to keep their
> logical position unchanged.
Maybe you should document that in the code instead of in a mail message.
7 years, 5 months
Re: (ITS#8263) Broken cursor tracking in mdb_cursor_put()
by hyc＠symas.com
h.b.furuseth(a)usit.uio.no wrote:
> Full_Name: Hallvard B Furuseth
> Version: mdb.master, 8b46dcc26d1e9897ab1da3a4a164cad4a4479a52
> OS: Linux x86_64
> URL: ftp://ftp.openldap.org/incoming/Hallvard-Furuseth-151005.c
> Submission from: (NULL) (81.191.45.5)
> Submitted by: hallvard
>
>
> The test program catches several cursor tracking bugs.
> It works when the DUPSORT sub-DB is created immediately:
Yes, when using a fake page we init the subcursor with the fake page. When
using a full sub-DB we left the subcursor pointing to the sub-DB but otherwise
uninit'd.
>
> $ ./a.out 1500
> mn_flags = 6 <repeated 22 times>
Fixed now in mdb.master.
Note: It's tempting to just merge the new xcursor_init2 function into
xcursor_init1 since they're very similar, but that's a bad idea. The
xcursor_init1 function really is meant for init'ing an unused cursor; it's
expected that immediately after, a full cursor-positioning action will occur.
xcursor_init2 is meant for xcursors that have already been positioned, in
which case their physical position is updated in order to keep their logical
position unchanged.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
7 years, 5 months
(ITS#8265) RFE: resultCode counters in cn=monitor
by michael＠stroeder.com
Full_Name: Michael Str.der
Version: HEAD
OS:
URL:
Submission from: (NULL) (84.181.161.13)
It would be handy especially for security monitoring if one could observe
counters for several result codes in cn=monitor. E.g. correlating the number of
bind requests with 49 counter is much easier and gives better performance than
extracting log lines (if those are available at all).
Maybe a tree like this:
cn=monitor
cn=Results
monitoredResultCode=0
monitoredInfo: <counter>
monitoredResultCode=49
monitoredInfo: <counter>
This should probably configurable because there are so many also custom result
code:
database monitor
monitor_resultcodes 0,49
7 years, 5 months
Re: (ITS#8264) LMDB mdb_del in a cursor causes data loss in certain situations
by hyc＠symas.com
malyn(a)strangeGizmo.com wrote:
> Full_Name: Michael Alyn Miller
> Version: LMDB 0.9.14, Git head
> OS: Windows 8.1 x64, NixOS 14.12 x64
> URL: ftp://ftp.openldap.org/incoming/michael-alyn-miller-151005.c
> Submission from: (NULL) (96.251.78.237)
>
>
> I have a helper library that sits on top of LMDB and testing some of the
> abstractions in that library has exposed a bug in LMDB related to deleting items
> while inside of a cursor. I have reduced the repro down to a test case that
> operates directly against LMDB.
>
> The test in question adds three groups of keys to the database (each with a
> different prefix) and then deletes the third group of keys. The deletion is
> done by scanning all of the keys with that prefix using a cursor.
> mdb_cursor_del works correctly and deletes only the targeted keys, whereas
> mdb_del causes nine extra keys (not in that group/prefix) to be deleted.
> I have tested this code against LMDB 0.9.14 and Git head 8b46dcc. Please let me
> know if you need any additional information. Thank you for your time!
Unable to reproduce.
violino:~/OD/mdb/libraries/liblmdb> gcc -g -c michael-alyn-miller-151005.c
violino:~/OD/mdb/libraries/liblmdb> gcc -o mic michael-alyn-miller-151005.o
-pthread liblmdb.a
violino:~/OD/mdb/libraries/liblmdb> ./mic
Num items after deletion using mdb_cursor_del: 44 (correct)
Num items after deletion using mdb_del: 44 (correct)
violino:~/OD/mdb/libraries/liblmdb> git log
commit 8b46dcc26d1e9897ab1da3a4a164cad4a4479a52
Author: Howard Chu <hyc(a)openldap.org>
Date: Sun Oct 4 01:56:25 2015 +0100
ITS#8258 fix rebalance/split
The tree height can also increase during rebalance, not just shrink.
This can happen if update_key needs to split a parent branch page.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
7 years, 5 months
(ITS#8264) LMDB mdb_del in a cursor causes data loss in certain situations
by malyn＠strangeGizmo.com
Full_Name: Michael Alyn Miller
Version: LMDB 0.9.14, Git head
OS: Windows 8.1 x64, NixOS 14.12 x64
URL: ftp://ftp.openldap.org/incoming/michael-alyn-miller-151005.c
Submission from: (NULL) (96.251.78.237)
I have a helper library that sits on top of LMDB and testing some of the
abstractions in that library has exposed a bug in LMDB related to deleting items
while inside of a cursor. I have reduced the repro down to a test case that
operates directly against LMDB.
The test in question adds three groups of keys to the database (each with a
different prefix) and then deletes the third group of keys. The deletion is
done by scanning all of the keys with that prefix using a cursor.
mdb_cursor_del works correctly and deletes only the targeted keys, whereas
mdb_del causes nine extra keys (not in that group/prefix) to be deleted.
Note that most of my test runs (with different test data) do not exhibit this
behavior: the targeted keys, and only the targeted keys, are deleted as
expected. Something about these specific keys and values triggers the bug. I
assume that other keys will also trigger the bug, but these are the ones that I
have converted into an LMDB-based test.
The referenced test runs twice: once with mdb_cursor_del and once with mdb_del.
You can mdb_dump the data before and after each deletion to see the extra keys
that are being removed. The incorrectly deleted keys are all consecutive and
begin with 02000000000000003a; the nine keys after and including 02...3aa4...
are the ones that are incorrectly deleted. Only keys beginning with
03000000000000003a should have been deleted (so it is interesting to note that
the nine keys immediately preceding the targeted keys were the ones that were
incorrectly deleted).
Is it valid to delete keys with mdb_del while inside of a cursor? If not, then
ignore this bug report and I will modify my helper library. That said, I do
expose more than just delete to my callers during cursor scans (they can mdb_put
new items during a scan), which is why my library uses mdb_del and not
mdb_cursor_del in this scenario.
I have tested this code against LMDB 0.9.14 and Git head 8b46dcc. Please let me
know if you need any additional information. Thank you for your time!
7 years, 5 months
