Re: MDB_CORRUPTED: Located page was wrong type
by Howard Chu
opensource(a)gmx-topmail.de wrote:
>
> Hello,
>
> We build an Android app with LMDB and are now seeing an error report with the
> following info:
> error -30796: MDB_CORRUPTED: Located page was wrong type
>
> We also logged some general info about the DB:
> entries=25381 depth=3 branch-pages=43 leaf-pages=891 overflow-pages=10
> page-size=4096 last-page-number=4464 last-tx-id=3752 size=536870912
> max-readers=126 readers=4
>
> It is an Android 6.0.1 device, and that's about all the info we have.
> Unfortunately we do not have the DB files etc.
>
> The app runs a LMDB version from mdb.master (45a8827 Howard Chu on 9/1/16 at
> 1:41 AM, ITS#8489 reset cursor EOF flag in cursor_set).
Generally you should not use mdb.master in production, as it's a development
branch.
>
> DB curruption sounds like a rather bad issue. Any idea how this could have
> happend?
Not offhand. We've seen a few corruptions on Windows due to running without
fully synchronous transactions, with OS crashes and/or faulty hard drives.
It's pretty rare for phones to crash though.
> Also, is there any chance to repair this DB (automatically)?
Nothing automated at present. If you had the DB files you could try to scan
the DB using the previous meta-page to see if it's still intact.
> Thanks for your help,
> Markus
>
>
>
>
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
6 years, 9 months
Transform accesslog database to LDIF for ldapmodify or other way
by Michael Wandel
Hey,
I'm searching for a tool which is able to transform an accesslog
Database to an ldif file, what can be used for ldapmodify.
Or is there an alternative way to use the accesslog to rebuild an ldap
database from a backup time to actual ?
Every hint is welcome
best regards
Michael
6 years, 10 months
Re: help troubleshooting
by Quanah Gibson-Mount
--On Monday, January 30, 2017 7:08 PM -0700 scar <scar(a)drigon.com> wrote:
> However, this brings me to the next problem: the contents of slapd.conf
> do not match the slapd.d/cn\=config.ldif file, so it seems the fixes i am
> trying to the ACL's don't have any effect, even when i restart slapd.
> If i try "ldapmodify -nv" it just hangs. When i try to stop slapd and
> remove slapd.d/* and then start slapd, the contents are recreated
> according to the config file, but then users can't login (all i see in
> the logfile is access_allowed and slap_access_allowed but no conn lines)
If you are using the configuration backend for slapd, then you can ignore
the slapd.conf file entirely, and simply use the ldapmodify command to
modify your access rules. I suggest reading the ldapmodify manual page for
information on how to properly execute it. If you are using a distribution
provided build of OpenLDAP, the necessary steps may depend on how they
configured things.
I would note that the rootdn is never subject to ACLs (as documented in the
slapd.access(5) man page). So there is no point in listing it in ACLs.
I would note that your final acl:
"access to *
by dn="uid=ldapadmin,dc=X,dc=Y,dc=Z" read"
will never be applied, since ACL processing stops on the first matching acl
(As noted in the slapd.access(5) man page), and the ACL immediately
preceeding it already covers "access to *".
I would note that your next to last ACL has also has items that would never
be processed, specifically the "by * auth", since the "by * read" takes
precedence. You don't provide any information on what identit(y/ies) you
want to be able to modify the userPassword attribute, so it's difficult to
help you further.
Hopefully this is enough information to help you have forward progress. :)
Regards,
Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
6 years, 10 months
Script for mass updates
by Nick Milas
Hello,
Does anyone have a ready-made script (e.g. bash) that would do the
following:
Loop on all entries in the ou=people branch where ou <> "system" {
If attribute DisplayName does not exist{
Set DisplayName to the value of attibute cn
}
}
I could do it with a bit of work, but it's urgent.
Any help will be appreciated!
Thanks in advance,
Nick
6 years, 10 months
Re: RE24 testing call (2.4.45) LMDB RE0.9 testing call (0.9.20)
by Quanah Gibson-Mount
--On Tuesday, January 31, 2017 12:37 PM -0800 Quanah Gibson-Mount
<quanah(a)symas.com> wrote:
> --On Tuesday, January 31, 2017 12:05 PM -0800 Quanah Gibson-Mount
> <quanah(a)symas.com> wrote:
>
>>> ERROR: Entry 21 not replicated to ldap://localhost:9012/! (32)!
>>> Error found after 1 of 1 iterations
>>>>>>>> test061-syncreplication-initiation failed for mdb
>>> (exit 1)
>>> Makefile:310: recipe for target 'mdb-yes' failed
>>> make: *** [mdb-yes] Error 1
>>
>> Interesting -- Can you tar up the testrun directory, ftp it up, and file
>> an ITS with a pointer to the upload?
>
> I was able to reproduce this as well with back-mdb.
Are you sure you're testing RE24 and not HEAD? I can reproduce this
failure in HEAD easily, but test061 has passed for me approximately 1000
times so far in RE24.
--Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
6 years, 10 months
Re: Script for mass updates
by Ulrich Windl
(forgot to reply to the list)
>>> Ulrich Windl <Ulrich.Windl(a)rz.uni-regensburg.de> schrieb am 06.02.2017 um
08:14
in Nachricht <58983099.ED38.00A1.0(a)rz.uni-regensburg.de>:
>>>> "Ralf Mattes" <rm(a)mh-freiburg.de> schrieb am 01.02.2017 um 17:23 in
Nachricht
> <45d3-58920b80-2b-2963e90@255443456>:
>
> > Am Mittwoch, 01. Februar 2017 16:52 CET, Jephte Clain
> > <jephte.clain(a)univ-reunion.fr> schrieb:
> >
> >> using michaël's filter, you could try this:
> >>
> >> ldapsearch [options]
'(&(ou:dn:=people)(!(ou=system))(!(displayName=*)))'
> >> cn | awk '
> >> /^dn:/ {
> >> print
> >> print "changetype: modify"
> >> print "replace: displayName"
> >> next
> >> }
> >> /^cn:/ {
> >> sub(/^cn/, "displayName")
> >> }
> >> { print }
> >> ' | ldapmodify [options]
> >>
> >> we aren't doing your homework, are we? :-)
> >
> > Danger, Will Robinson!
> > This will only work for dn values that aren't encoded.
> > That's a trivial job for perl or python (or whatever). AWK operates
> > on character streams and that's a bad fit for LDIF.
>
> Zwo questions:
>
> 1: Doesn't /^dn:/ also match "dn::" (likewise /^cn:/ and "cn::"?
> 2: If /^cn:/ matches "cn::", wouldn't the sub() replace "cn::" with
> "displayName::"?
>
> So everything would still work IMHO.
>
> We don't use displayName like that; we only us it if someone with an
> academic title insists on having his "Prof." or "Dr." (or any collection of
> that in his/her name).
>
> Regards,
> Ulrich
>
> Thought of the day: Trump vs. America; who will win?
>
> >
> > Cheers, Ralf Mattes
> >
> >> regards,
> >> Jephté
> >>
>
>
>
>
6 years, 10 months
RE: RE24 testing call (2.4.45) LMDB RE0.9 testing call (0.9.20)
by Quanah Gibson-Mount
--On Friday, February 03, 2017 12:38 PM -0800 "Paul B. Henson"
<henson(a)acm.org> wrote:
>> From: Quanah Gibson-Mount
>> Sent: Thursday, February 02, 2017 1:26 PM
>>
>> quanah@ub16:~/openldap-2.4.45RC/tests$ ./run -l 500 -b mdb test061
>>
>> Will run test061 500 times, using back-mdb as the backend. Instead of a
>> specific test, one can do "all" to run everything through a loop X times.
>
> Ok; to clarify then, if a test fails, make will abort?
Yes.
>> Interesting... it may be worthwhile to look in the testrun directory and
>> see why slapd failed to launch. I'll see if I can reproduce it as well.
>
> Ah, I bet it is this:
>
> Unrecognized database type (ldap)
> 5894e87d
> /user/henson/tmp/openldap-OPENLDAP_REL_ENG_2_4-ab6f04c/tests/testrun/slap
> d.2 .conf: line 16: <database> failed init (ldap)
>
> I configured it the way I run it in production; this test must be using a
> module I don't enable. Sorry for the false alarm. For testing purposes,
> should I just run ./configure with no options? Or a subset of the options
> I would normally use on a production system?
It means I need to fix the regression test to ignore back-ldap. ;)
>> I've not been able to reproduce it.
>
> Hmm, I must have misunderstood you; I thought in this message:
>
> http://www.openldap.org/lists/openldap-technical/201612/msg00108.html
>
> You had indicated you were able to reproduce it.
It turned out to not be related. :/
--Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
6 years, 10 months
Re: RE24 testing call (2.4.45) LMDB RE0.9 testing call (0.9.20)
by Quanah Gibson-Mount
--On Friday, February 03, 2017 2:34 PM +0100 "A. Schulze"
<sca(a)andreasschulze.de> wrote:
>
>
> Am 31.01.2017 um 22:21 schrieb A. Schulze:
>
>> * but last: make test failed
>> ( attached make_test_result.txt )
>
> the failing test was test059
Ah, whoops. That I was able to reproduce at 25/500 runs.
Thanks!
--Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
6 years, 10 months
RE: RE24 testing call (2.4.45) LMDB RE0.9 testing call (0.9.20)
by Quanah Gibson-Mount
--On Thursday, February 02, 2017 1:01 PM -0800 "Paul B. Henson"
<henson(a)acm.org> wrote:
>> From: Quanah Gibson-Mount
>> Subject: RE24 testing call (2.4.45) LMDB RE0.9 testing call (0.9.20)
>>
>> For this testing call, we particularly need folks to test OpenLDAP with
>> startTLS/LDAPS when compiled against OpenSSL (both pre 1.1 series and
>> with the 1.1 series).
>
> Compiled successfully with Gentoo linux and openSSL 1.02j/cyrus-sasl
> 2.1.26, configured as:
>
> --prefix=/usr --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
> --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share
> --sysconfdir=/etc --localstatedir=/var/lib --disable-dependency-tracking
> --disable-silent-rules --libdir=/usr/lib64
> --libexecdir=/usr/lib64/openldap --disable-static --enable-ldap
> --enable-slapd --enable-bdb --enable-hdb --enable-dnssrv=mod
> --enable-ldap=mod --enable-mdb=mod --enable-meta=mod --enable-monitor=mod
> --enable-null=mod --enable-passwd=mod
> --enable-relay=mod --enable-shell=mod --enable-sock=mod --disable-perl
> --disable-sql --disable-crypt --disable-slp --disable-lmpasswd
> --enable-syslog --enable-aci --enable-cleartext --enable-modules
> --enable-rewrite --enable-rlookups --enable-slapi --enable-syncprov=yes
> --enable-overlays=mod --enable-ipv6 --with-cyrus-sasl --enable-spasswd
> --disable-wrappers --with-tls=openssl --enable-dynamic --enable-local
> --enable-proctitle --enable-shared
>
> make test completed successfully, is there any particular way to verify
> all the tests were okay? Does the make itself fail if any of the tests
> do, I did not see a summary at the end. make its was not as happy:
"make test" will do a single pass through the entire test suite, for each
backend. Unfortunately, that does not always catch issues. For example,
the issue Dieter reported against HEAD with test061 only happens to me
occassionaly. To help with that, there is the abilty to run the test suite
in a loop, for a given backend. Like:
quanah@ub16:~/openldap-2.4.45RC/tests$ ./run -l 500 -b mdb test061
Will run test061 500 times, using back-mdb as the backend. Instead of a
specific test, one can do "all" to run everything through a loop X times.
>>>>>> Starting its4326 ...
> running defines.sh
> Running slapadd to build slapd database...
> Starting slapd on TCP/IP port 9011...
> Using ldapsearch to check that slapd is running...
> Starting proxy slapd on TCP/IP port 9012...
> Using ldapsearch to check that proxy slapd is running...
> Waiting 5 seconds for slapd to start...
> Waiting 5 seconds for slapd to start...
> Waiting 5 seconds for slapd to start...
> Waiting 5 seconds for slapd to start...
> Waiting 5 seconds for slapd to start...
> Waiting 5 seconds for slapd to start...
> ldapsearch failed (255)!
> ./data/regressions/its4326/its4326: line 93: kill: (28780) - No such
> process
>>>>>> ./data/regressions/its4326/its4326 failed (exit 255)
Interesting... it may be worthwhile to look in the testrun directory and
see why slapd failed to launch. I'll see if I can reproduce it as well.
> I see the fix for ITS8432 is included in this release (yay); I was
> wondering if you've had any luck tracking down the underlying issue
> behind ITS8444? So far I still haven't seen any corruption or operational
> issues from it, but the rampant noise in the logs and errors being
> generated are quite disconcerting :). Plus they will potentially mask any
> errors that are actually indicative of a real problem.
I've not been able to reproduce it. There's a regression test I wrote for
it included in the RE24 source, but it's never really triggered for me.
Please feel free to look it over and see if I've missed anything obvious in
my reproduction attempts. :)
You can execute it directly with ./run -b mdb its8444
--Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
6 years, 10 months
