Full_Name: Hallvard B Furuseth
OS: Linux x86_64
Submission from: (NULL) (220.127.116.11)
Submitted by: hallvard
The doc for mdb_cursor_put:MDB_CURRENT says "The key parameter is
- key==NULL gives EINVAL after a thinko in the assert cleanup.
5bda3565a9bfaa6cd54053faeafcc06da15bc00c moved assert(key) from
mdb_cursor_set() to the wrong place in the one relevant caller.
- A huge key.mv_size triggers mdb_page_spill().
- If data.mv_size==0, the record's key instead of data is
modified (so you can modify e.g. key:"foo" to key:"bar").
I expect the test should be (mc->mc_flags & C_SUB).
Changing that has a side effect on a non-MDB_CURRENT case:
With a cmp function like strncasecmp, changing "KEY" to "key"
currently works with if old datasize = new datasize = 0.
After this it won't, as with non-empty data of the same size.
Test program enclosed.
Full_Name: Warron French
Version: 2.4.38 LTB Project
Submission from: (NULL) (18.104.22.168)
LTB-Project.org or OpenLDAP.org developers, please help:
I am running CentOS-6.5 (on all machines in my little lab) and attempting to
setup an LDAP server for user-account authentication, which requires TLS. My
CentOS-6.5 machines are all running kernel 2.6.32-431.3.1.el6.x86_64. Also, the
version of OpenLDAP I am running based on a suggestion from a user is
LTB-Project.org's OpenLDAP-2.4.38, because the version that came natively
available with CentOS-6.5's repos was a very old 2.4.23.
I am writing a document in order to successfully repeat the build/configuration
steps from my lab and lessons learned into a production system.
The following is where I am...
I am still having problems with adding (via .ldif file) the following LDIF file
contents of /tmp/LDAP-CONFIG-TLS.ldif:
olcTLSCipherSuite: TLSv1+RSA:\!EXP:\!MD5:\!NULL (<- not sure if that argument
is valid for that CipherSuite selection either)
I use the following ldapmodify command:
ldapmodify -x -D "cn=admin,cn=config" -W -f /tmp/LDAP-CONFIG-TLS.ldif
Because I have debugging turned up (to -d 32768), the results now look like:
modifying entry "cn=config"
52e68423 connection_input: conn=1000 deferring operation: binding
slapd: result.c:813: slap_send_ldap_result: Assertion `!((rs->sr_err)<0)'
ldap_result: Can't contact LDAP server (-1)
I saw a thread on openldap.org on the following link,
http://www.openldap.org/lists/openldap-bugs/201308/msg00066.html , that has the
exact same error. I can see that Howard Chu from Symas fixed the problem for
Symas, did LTB Project fix this problem? I cannot find any threads via
websearch for this issue.
My /var/log/openldap.log file does not show anything extra. In fact a tail of
the log file doesn't even show any errors really.
What do I need to do in order to get my LDAP running with TLS?
Thank you for any help, I am losing my sanity.
-----BEGIN PGP SIGNED MESSAGE-----
On 01/24/2014 11:57 AM, michael(a)stroeder.com wrote:
> Hard to tell what's going on without seeing the configuration.
> I'd disable overlays one by one to check whether one of those causes the seg
> slapo-rwm is one such candidate.
If it really turns out that slapo-rwm is the culprit, consider checking the latest patch in ITS#7723.
Software Engineer, Red Hat
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
-----END PGP SIGNATURE-----
Full_Name: Marvin Mundry
Version: slapd 2.4.38
OS: Ubuntu 12.04
Submission from: (NULL) (22.214.171.124)
i have set up a 3-Way delta MMR replication.
when i add the third machine to the replication (zd-ldap-3) that machine starts
replicating objects but segfaults at some point during replication.
* build openldap slapd 2.4.38 with the configuration shown in build.txt (in the
* slapadd -S 1 -l /usr/local/openldap/etc/openldap/slapd.ldif -F
/usr/local/openldap/etc/openldap/slapd.d -bcn=config (slapd.ldif is contained in
the attached file)
* started up zd-ldap-next-1
* imported ~67'000 objects via ldapadd
* on zd-ldap-next-1: slapcat -bcn=config -F
/usr/local/openldap/etc/openldap/slapd.d/ -l /tmp/configbk.ldif
* scp /tmp/configbk.ldif from zd-ldap-1 --to--> zd-ldap-2 and zd-ldap-3
* on zd-ldap 2 and 3: slapadd -b cn=config -l /tmp/configbk.ldif -F
* started up slapd on zd-ldap-2
* waited for the replication to finish (worked fine)
* started up slapd on zd-ldap-3
* waited for the replication to finish ==> segfault after replication of ~40'000
objects (the number differs when i try to reproduce the bug (i.e. replication
does not always fail at the same object))
Should have enclosed a test program. Here:
process #0: open env
process #1: open env
process #0: write txn, mapsize 204800
process #1: write txn, mapsize 40960
process #2: open env, write txn, mapsize 40960
process #3: open env, write txn, mapsize 204800
Summarizing a reply which got sent privately instead of to ITS:
On 2014-01-24 00:07, Howard Chu wrote:
> The doc says the caller of set_mapsize is required to make sure there
> are no active transactions when it is called. As such, X failed this
> requirement, and this sequence of events is explicitly unsupported.
No, I'm talking about X changing the mapsize when there is no txn,
then afterwards doing a write txn so the mapsize gets written.
> If Y doesn't start its write txn until after X finishes, then Y will
> see the new size.
It doesn't, that's the point. Only txn_commit pays attention,
and it checks the size which existed in the wrong metapage.
Come to think of it, set_mapsize(); env_open(); txn begin/end
should do the same. Y will either way not pay attention to
the new mapsize.
> Full_Name: Hallvard B Furuseth
> Version: LMDB 0.9.11
> OS: Linux x86_64
> Submission from: (NULL) (126.96.36.199)
> Submitted by: hallvard
> Mapsize changes do not work as described, do not reliably store the
> mapsize in the map, and it's hard to see how it is supposed to work.
> - Open an environment twice, in processes X and Y.
> - X grows the map and writes (commits) something to the DB. That
> MDB_meta gets the new mapsize.
> - Y writes to the DB. It does not get MDB_MAP_RESIZED like the doc
> says, nor does it carry forward X's MDB_meta.mm_mapsize change.
The doc says the caller of set_mapsize is required to make sure there are no
active transactions when it is called. As such, X failed this requirement, and
this sequence of events is explicitly unsupported.
If Y doesn't start its write txn until after X finishes, then Y will see the
> - Process Z opens the environment without doing set_mapsize(),
> and gets the original mapsize from the MDB_meta written by Y.
> For that matter, from reading the doc I'd expect a mapsize change to
> commit a txn with the new mapsize. There's no mention that the change
> (and the MDB_MAP_RESIZED) will wait for something to be committed.
> mdb_txn_commit() writes nothing if the txn didn't change anything.
> It needs to notice that there is a mapsize change to write.
> The doc talks about shrinking the map, but reduced mapsizes are not
> written to the datafile. Only increases are written.
> All in all, it looks to me like _changing_ the mapsize should be an
> operation on a write transaction or invoke a write transaction, while
> setting the size or catching up with a mapsize change can be an
> environment operation. That way it would be possible to make sense of
> it. A txn can do it when it has no cursors and no dirty WRITEMAP
> pages (or WRITEMAP could spill all pages first).
> BTW, I don't see the point of conditionally avoiding to write the
> mapsize in mdb_env_write_meta() when full page gets written to disk
> anyway - as long as txn_begin() stashes the mapsize from the original
> meta so it knows what to write. (It need not obey the mapsize at that
> point, but it must carry a change forward.)
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
OS: Solaris 11
Submission from: (NULL) (188.8.131.52)
openldap-2.4.35/servers/slapd/back-ldif root# cc -I/usr/local/include
-I../../../include -I../../../include -I.. -I./.. -I/usr/local/include -c ldif.c
"ldif.c", line 166: warning: no explicit type given
"ldif.c", line 166: syntax error before or at: ldifcfg
This happens because there is a /usr/local/include/config.h from libstdc++ which
is included before openldap-2.4.35/servers/slapd/config.h, according to the -I
include path order. The Makefile sets CFLAGS to "AC_CFLAGS DEFS". DEFS includes
XINCPATH which should precede AC_CFLAGS, not succeed it.
Either the order needs to be fixed, or more usefully config.h renamed to
To have configure work correctly, CPPFLAGS needs to be set to
"-I/usr/local/include" otherwise /usr/local/include isn't searched for db.h, it
picks up /usr/include/db.h which is not the one it needs to link against.
+ print -r -- 'configure:20296: checking for Berkeley DB major version in db.h'
+ /bin/ggrep -E __db_version
+ eval '$CPP $CPPFLAGS conftest.c'
+ cc -E conftest.c
+ set X __db_version 5 none none
You can see it's only using CPP and CPPFLAGS in the eval command. Not CFLAGS
which has the path for the correct db.h to use. To fix that, CPPFLAGS also needs
to point to /usr/local/include.
I'm using these fixes to move past both problems and get a properly working
./configure --prefix=/usr/local \
mv servers/slapd/config.h servers/slapd/slapd_config.h
perl -pe 's#config.h#slapd_config.h#' -i servers/slapd/*.c
perl -pe 's#"config.h"#"slapd_config.h"#' -i servers/slapd/*/*.c
Full_Name: Hallvard B Furuseth
Version: LMDB 0.9.11
OS: Linux x86_64
Submission from: (NULL) (184.108.40.206)
Submitted by: hallvard
Mapsize changes do not work as described, do not reliably store the
mapsize in the map, and it's hard to see how it is supposed to work.
- Open an environment twice, in processes X and Y.
- X grows the map and writes (commits) something to the DB. That
MDB_meta gets the new mapsize.
- Y writes to the DB. It does not get MDB_MAP_RESIZED like the doc
says, nor does it carry forward X's MDB_meta.mm_mapsize change.
- Process Z opens the environment without doing set_mapsize(),
and gets the original mapsize from the MDB_meta written by Y.
For that matter, from reading the doc I'd expect a mapsize change to
commit a txn with the new mapsize. There's no mention that the change
(and the MDB_MAP_RESIZED) will wait for something to be committed.
mdb_txn_commit() writes nothing if the txn didn't change anything.
It needs to notice that there is a mapsize change to write.
The doc talks about shrinking the map, but reduced mapsizes are not
written to the datafile. Only increases are written.
All in all, it looks to me like _changing_ the mapsize should be an
operation on a write transaction or invoke a write transaction, while
setting the size or catching up with a mapsize change can be an
environment operation. That way it would be possible to make sense of
it. A txn can do it when it has no cursors and no dirty WRITEMAP
pages (or WRITEMAP could spill all pages first).
BTW, I don't see the point of conditionally avoiding to write the
mapsize in mdb_env_write_meta() when full page gets written to disk
anyway - as long as txn_begin() stashes the mapsize from the original
meta so it knows what to write. (It need not obey the mapsize at that
point, but it must carry a change forward.)