[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: (ITS#6482) slapcat doesn't continue with -c after the first corrupted database entry
This is a multi-part message in MIME format.
--------------020204070007000004050507
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
The main point wasn't to tell you how important the data was, but that
tools like ldapsearch or other tools connecting to slapd using port 389
still saw the good data. And slapd never complained about a corrupted
database. As a result of that the data corruption was hidden (all other
programs worked, only three non-important entries were not accessible)
until I tried to use slapcat to export the data for an upgrade.
Regarding "If the underlying database fails, there's little slapcat can
do.": As long as slapd sees the data, because it sends it in responses
to ldap-queries, the database hasn't failed so much, that slapcat
couldn't retrieve those data.
Regarding "any garbage coming out of a corrupted database": slapd never
complained about the database being corrupted, it started without any
problems (except that three entries were unreadable), the entries after
those damaged entries made sense and weren't garbage. Berkeley's
db_tools claimed that there were some errors in the db, but slapd worked
without problems, only slapcat (and ldapdelete when trying to delete
those entries) complained that it couldn't decode them (which seems to
be rather a problem of the application layer than of the database layer,
but might have been caused by some little db corruption).
I tried tools like "db_recover", but they didn't help, so I wanted to
extract the good ldap entries (using slapcat ...) to drop the database
and recreate it with the exported ldif, which failed because slapcat
stopped after the first failure (even with -c). Using the submitted
patch I was able to export all readable data into a ldif-file and to
recreate the database.
summary:
* slapd never complained, ldapsearch listed the data, only few entries
were missing (because for them following was true:
<= entry_decode: slap_str2undef_ad(object�..!p):
AttributeDescription
contains inappropriate characters)
--> it seems that some attribute-values were damaged, but not the dn?
* if ldapsearch is able to retrieve the data, slapcat should also do
* I don't know how you want to recover an corrupted database. I tried to
recover all good entries and then to recreate it. And for that I wanted
to use slapcat (or is there any other tool for exporting data from the
ldap database than slapcat with option -c)?
* maybe the way -c works shouldn't be changed, but there should be an
option for trying data recovery harder without having to patch openldap
(which is complicated for users of other distros not working directly
with the sources, but with precompiled packages)
--------------020204070007000004050507
Content-Type: text/html; charset=ISO-8859-15
Content-Transfer-Encoding: 7bit
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-15">
</head>
<body bgcolor="#ffffff" text="#000000">
The main point wasn't to tell you how important the data was, but that
tools like ldapsearch or other tools connecting to slapd using port 389
still saw the good data. And slapd never complained about a corrupted
database. As a result of that the data corruption was hidden (all other
programs worked, only three non-important entries were not accessible)
until I tried to use slapcat to export the data for an upgrade.<br>
<br>
Regarding "If the underlying database fails, there's little slapcat can
do.": As long as slapd sees the data, because it sends it in responses
to ldap-queries, the database hasn't failed so much, that slapcat
couldn't retrieve those data.<br>
<br>
Regarding "any garbage coming out of a corrupted database": slapd never
complained about the database being corrupted, it started without any
problems (except that three entries were unreadable), the entries after
those damaged entries made sense and weren't garbage. Berkeley's
db_tools claimed that there were some errors in the db, but slapd
worked without problems, only slapcat (and ldapdelete when trying to
delete those entries) complained that it couldn't decode them (which
seems to be rather a problem of the application layer than of the
database layer, but might have been caused by some little db
corruption).<br>
<br>
I tried tools like "db_recover", but they didn't help, so I wanted to
extract the good ldap entries (using slapcat ...) to drop the database
and recreate it with the exported ldif, which failed because slapcat
stopped after the first failure (even with -c). Using the submitted
patch I was able to export all readable data into a ldif-file and to
recreate the database.<br>
<br>
summary:<br>
* slapd never complained, ldapsearch listed the data, only few entries
were missing (because for them following was true:<br>
<pre><= entry_decode: slap_str2undef_ad(object&#65533;..!p):
AttributeDescription
contains inappropriate characters)
--> it seems that some attribute-values were damaged, but not the dn?
</pre>
<span style="visibility: visible;" id="main"><span
style="visibility: visible;" id="search">*</span></span> if ldapsearch
is able to retrieve the data, slapcat should also do<br>
* I don't know how you want to recover an corrupted database. I tried
to recover all good entries and then to recreate it. And for that I
wanted to use slapcat (or is there any other tool for exporting data
from the ldap database than slapcat with option -c)?<br>
* maybe the way -c works shouldn't be changed, but there should be an
option for trying data recovery harder without having to patch openldap
(which is complicated for users of other distros not working directly
with the sources, but with precompiled packages)<br>
</body>
</html>
--------------020204070007000004050507--