[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
slapcat backup with empty DNs
- To: openldap-technical@openldap.org
- Subject: slapcat backup with empty DNs
- From: Samir Cury <eu@samircury.eng.br>
- Date: Thu, 10 Oct 2013 11:23:51 +0200
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=5LWWltt24Y5Bstt4Hetsxh3PN8Z+jJIUXHOTiLGubm4=; b=mNe5Fp6ISNtUhH9PcXyX7a0oVD27TF5Ic33xwvi8tvW+bKLksum/+qAoca83eOnqYJ jnMgqnxkV6mqr6tGkM+LZ3ubFKxp1AX7tG8BNXq+C6kajpH81sKDtMRh46fSm3MLZBtS 8qSHXspfJBteU32bFWd+CNZzw+sMQCmoR7jD2HfkmGeRMozVlLsQT8yQ19Fr4BwADAKI g2ZidpMqRYpHZURZWeBEBdq6HaXSFkmV9jSSbvzj5IyIiL9fVyzPux1W37oRly1cMZ9t 3VN7rOX8sFceU02uqgEcuDVbfHMklcIJqxt9ZlsynRFk8UMuKLenn0ThhkUIn61KHPNa jKGg==
Dear all,
The problem I'm having is simple, although I didn't find much
eplanations for it, once I try to backup the database with :
slapcat -v -l ldap-backup5.ldif
It works nicely, except that _all_ entries have :
dn:
structuralObjectClass: organizationalUnit
dn:
objectClass: organizationalRole
cn: Manager
dn:
structuralObjectClass: inetOrgPerson
entryUUID: e8ef2300-f04c-10fb-9b02-a54a91b9c30b
(empty DNs)
Although the information is still there, if I ldapsearch one of the
entities it comes easily :
ldapsearch -x -LLL '(uid=samir)'
dn: cn=Samir Cury,ou=abc,ou=def,dc=org,dc=edu
cn: Samir Cury Siqueira
objectClass: inetOrgPerson
is this problem obvious to any of you?
The only similar case I found in the history was
:http://www.openldap.org/lists/openldap-technical/201201/msg00160.html
Which doesn't have a clear outcome.
Any hint on where to look at?
Thanks,
Samir
==== Aditional information - just in case ====
My setup is a 1 Master 1 Slave of slapd 2.3.43. Relevant information
is that after the master's hardware died, few days later the slave
started to misbehave and probably got the DB corrupted.
slapd_db_recover seems to have fixed it as now it is working just
fine, log messages from before the error / recovery :
#slapcat -v -l ldap-backup.ldif
bdb_db_open: unclean shutdown detected; attempting recovery.
bdb_db_open: Recovery skipped in read-only mode. Run manual recovery
if errors are encountered.
#slapd_db_recover -v -h /var/lib/ldap
Finding last valid log LSN: file: 2 offset 6078834
Recovery starting from [2][6065934]
Recovery complete at Wed Oct 9 16:42:55 2013
Maximum transaction ID 8000c207 Recovery checkpoint [2][6091589]
-- slapcat now has no warnings/errors --
I suspect slightly of this as I've read that corrupted databases can
cause such effects, but the ldapsearch with full DNs makes me think
that it didn't happen.
==== / Aditional information ====