db_verify

After I import about 1400 accounts to a new database
(ebiRoot, People 
subtree), I get lot of errors when I run verify-db.pl (slapd
has been stopped):

Verify log files in db ... Good
Verify db/ebiRoot/uid.db4 ... Good
Verify db/ebiRoot/mail.db4 ...
DB ERROR: db_verify: Page 37: out-of-order key at entry 247
DB ERROR: db_verify: Page 37: out-of-order key at entry 503
...

Same error for ancestorid.db4, objectclass.db4,
parentid.db4, cn.db4, 
givenName.db4 and sn.db4.

I have run db2index and re-run verify-db.pl but I don't see
any 
difference. Here is what db2index says about ebiRoot:

[29/Mar/2007:12:04:26 +0100] upgrade DB - ebiRoot: Start
upgradedb.
[29/Mar/2007:12:04:26 +0100] - WARNING: Import is running
with nsslapd-db-private-import-mem on; No other process is
allowed to access the database
[29/Mar/2007:12:04:26 +0100] - import ebiRoot: Index
buffering enabled with bucket size 100
[29/Mar/2007:12:04:27 +0100] - import ebiRoot: Workers
finished; cleaning up...
[29/Mar/2007:12:04:28 +0100] - import ebiRoot: Workers
cleaned up.
[29/Mar/2007:12:04:28 +0100] - import ebiRoot: Cleaning up
producer thread...
[29/Mar/2007:12:04:28 +0100] - import ebiRoot: Indexing
complete.  Post-processing...
[29/Mar/2007:12:04:28 +0100] - import ebiRoot: Flushing
caches...
[29/Mar/2007:12:04:28 +0100] - import ebiRoot: Closing
files...
[29/Mar/2007:12:04:29 +0100] - import ebiRoot: Import
complete.  Processed 
1424 entries in 3 seconds. (474.67 entries/sec)


Does that WARNING "No other process is alloed to access
the database" mean 
something is wrong?

How can I locate those "out-of order keys" the
db_verify lists? I tried 
with dbscan but I don't think I'm giving the right entry
id:

$ ./dbscan -K 247 -f db/ebiRoot/mail.db4
Can't set cursor to returned item: DB_NOTFOUND: No matching
key/data pair found

Is there a way to find out which entries are causing the
problem? Can 
there be illegal characters in the entries?

If I import a considerably smaller set of entries (120), I
get no errors. 
I noticed there was a similar thread here but no
conclusion:

ht
tp://www.mail-archive.com/fedora-directory-usersredhat.com/msg04461.html

Sorry for so many questions, I've spent couple of days
trying to 
solve the problem.

If I delete a database with the Console, it leaves behind
couple of index files:

-rw-------  1 w3secure systems 16384 Mar 28 17:05
ancestorid.db4
-rw-------  1 w3secure systems    18 Mar 28 17:03 DBVERSION
-rw-------  1 w3secure systems 32768 Mar 28 17:05
id2entry.db4

These index files don't seem to shrink when new entries are
imported. 
dbscan still shows the deleted entries in id2entry.

I noticed a problem when I import a small set of entries,
delete the 
database, import large set of entries and if I query the
entries, I get 
the entries from the first set (they don't exist in the
second set). I can 
reproduce the problem. If I delete ancestorid.db4 and
id2entry.db4 
manually when I delete the database, I don't have this
problem. Is there a 
reason why those two files are not deleted? Or can this
whole thing be 
caused by corrupted data?


Ville

--
Fedora-directory-users mailing list
Fedora-directory-usersredhat.com
https://www.redhat.com/mailman/listinfo/fedora-dir
ectory-users

Hello, Ville;

Ville Silventoinen wrote:

> After I import about 1400 accounts to a new database
(ebiRoot, People 
> subtree), I get lot of errors when I run verify-db.pl
(slapd has been 
> stopped):
>
> Verify log files in db ... Good
> Verify db/ebiRoot/uid.db4 ... Good
> Verify db/ebiRoot/mail.db4 ...
> DB ERROR: db_verify: Page 37: out-of-order key at entry
247
> DB ERROR: db_verify: Page 37: out-of-order key at entry
503
> ...
>
> Same error for ancestorid.db4, objectclass.db4,
parentid.db4, cn.db4, 
> givenName.db4 and sn.db4.

How about id2entry.db4?  Is it broken?  (It's a primary db
file.)

>
> I have run db2index and re-run verify-db.pl but I don't
see any 
> difference. Here is what db2index says about ebiRoot:
>
> [29/Mar/2007:12:04:26 +0100] upgrade DB - ebiRoot:
Start upgradedb.
> [29/Mar/2007:12:04:26 +0100] - WARNING: Import is
running with 
> nsslapd-db-private-import-mem on; No other process is
allowed to 
> access the database
> [29/Mar/2007:12:04:26 +0100] - import ebiRoot: Index
buffering enabled 
> with bucket size 100
> [29/Mar/2007:12:04:27 +0100] - import ebiRoot: Workers
finished; 
> cleaning up...
> [29/Mar/2007:12:04:28 +0100] - import ebiRoot: Workers
cleaned up.
> [29/Mar/2007:12:04:28 +0100] - import ebiRoot: Cleaning
up producer 
> thread...
> [29/Mar/2007:12:04:28 +0100] - import ebiRoot: Indexing
complete.  
> Post-processing...
> [29/Mar/2007:12:04:28 +0100] - import ebiRoot: Flushing
caches...
> [29/Mar/2007:12:04:28 +0100] - import ebiRoot: Closing
files...
> [29/Mar/2007:12:04:29 +0100] - import ebiRoot: Import
complete.  
> Processed 1424 entries in 3 seconds. (474.67
entries/sec)
>
>
> Does that WARNING "No other process is alloed to
access the database" 
> mean something is wrong?

No, that's just a warning not to access the backend
ebiRoot.

>
> How can I locate those "out-of order keys"
the db_verify lists? I 
> tried with dbscan but I don't think I'm giving the
right entry id:

Right.  247 is the Berkeley DB's internal id.

>
> $ ./dbscan -K 247 -f db/ebiRoot/mail.db4
> Can't set cursor to returned item: DB_NOTFOUND: No
matching key/data 
> pair found

What happens if you just run dbscan for all the keys in
mail.db4 
(without the -K option)? 
E.g., ./dbscan -n -r db/ebiRoot/mail.db4
Do you get any errors?

> Is there a way to find out which entries are causing
the problem? Can 
> there be illegal characters in the entries?

Could it be possible to share your data with us?  (sample
data would be 
good.)
Thanks,
--noriko

>
> If I import a considerably smaller set of entries
(120), I get no 
> errors. I noticed there was a similar thread here but
no conclusion:
>
> ht
tp://www.mail-archive.com/fedora-directory-usersredhat.com/msg04461.html 
>
>
> Sorry for so many questions, I've spent couple of days
trying to solve 
> the problem.
>
> If I delete a database with the Console, it leaves
behind couple of 
> index files:
>
> -rw-------  1 w3secure systems 16384 Mar 28 17:05
ancestorid.db4
> -rw-------  1 w3secure systems    18 Mar 28 17:03
DBVERSION
> -rw-------  1 w3secure systems 32768 Mar 28 17:05
id2entry.db4
>
> These index files don't seem to shrink when new entries
are imported. 
> dbscan still shows the deleted entries in id2entry.
>
> I noticed a problem when I import a small set of
entries, delete the 
> database, import large set of entries and if I query
the entries, I 
> get the entries from the first set (they don't exist in
the second 
> set). I can reproduce the problem. If I delete
ancestorid.db4 and 
> id2entry.db4 manually when I delete the database, I
don't have this 
> problem. Is there a reason why those two files are not
deleted? Or can 
> this whole thing be caused by corrupted data?
>
>
> Ville
>
> -- 
> Fedora-directory-users mailing list
> Fedora-directory-usersredhat.com
> https://www.redhat.com/mailman/listinfo/fedora-dir
ectory-users



--
Fedora-directory-users mailing list
Fedora-directory-usersredhat.com
https://www.redhat.com/mailman/listinfo/fedora-dir
ectory-users

Hi Noriko, thanks for you reply.

On Thu, 29 Mar 2007, Noriko Hosoi wrote:

> Ville Silventoinen wrote:
>
>> Same error for ancestorid.db4, objectclass.db4,
parentid.db4, cn.db4, 
>> givenName.db4 and sn.db4.
>
> How about id2entry.db4?  Is it broken?  (It's a primary
db file.)

No, id2entry.db4 is Good.


>> How can I locate those "out-of order
keys" the db_verify lists? I tried 
>> with dbscan but I don't think I'm giving the right
entry id:
>
> Right.  247 is the Berkeley DB's internal id.

OK, so there's no way to use it to locate which entry is
causing the problem?


>> $ ./dbscan -K 247 -f db/ebiRoot/mail.db4
>> Can't set cursor to returned item: DB_NOTFOUND: No
matching key/data pair 
>> found
>
> What happens if you just run dbscan for all the keys in
mail.db4 (without the 
> -K option)? E.g., ./dbscan -n -r db/ebiRoot/mail.db4
> Do you get any errors?

I assume you meant "dbscan -n -r -f
db/ebiRoot/mail.db4". I see lot of 
numbers, no errors as far as I can tell.


>> Is there a way to find out which entries are
causing the problem? Can there 
>> be illegal characters in the entries?
>
> Could it be possible to share your data with us? 
(sample data would be 
> good.)

I asked my manager but he doesn't think it's a good idea for
security 
reasons. The problem is that the data is our NIS
mail.aliases and passwd, 
and we don't want to distribute them to the internet. He
suggested I'll 
modify the data, so I can send a sample to you. I'll do that
next week.

What would you be looking for in the data? Perhaps I could
do it here?

Today I have been trying to narrow down which entries in our

mail.aliases cause the problem. We have about 8400 aliases
(includes 
majordomo and mailman aliases) and if I sort them
alphabetically and 
import only entries 250-500, I get following errors from
verify-db.pl:

Verify log files in db ... Good
Verify db/ebiRoot/ancestorid.db4 ...
DB ERROR: db_verify: Page 2: out-of-order key at entry 254
DB ERROR: db_verify: DB->verify:
db/ebiRoot/ancestorid.db4: DB_VERIFY_BAD: 
Database verification failed
Secondary index file ancestorid.db4 in db/ebiRoot is
corrupted.
Please run db2index(.pl) for reindexing.
Verify db/ebiRoot/objectclass.db4 ...
DB ERROR: db_verify: Page 2: out-of-order key at entry 255
DB ERROR: db_verify: DB->verify:
db/ebiRoot/objectclass.db4: DB_VERIFY_BAD: Database
verification failed
Secondary index file objectclass.db4 in db/ebiRoot is
corrupted.
Please run db2index(.pl) for reindexing.
Verify db/ebiRoot/nsuniqueid.db4 ... Good
Verify db/ebiRoot/parentid.db4 ...
DB ERROR: db_verify: Page 1: unsorted duplicate set in
sorted-dup database
DB ERROR: db_verify: DB->verify: db/ebiRoot/parentid.db4:
DB_VERIFY_BAD: Database verification failed
Secondary index file parentid.db4 in db/ebiRoot is
corrupted.
Please run db2index(.pl) for reindexing.
Verify db/ebiRoot/cn.db4 ...
DB ERROR: db_verify: Page 2: unsorted duplicate set in
sorted-dup database
DB ERROR: db_verify: Page 6: unsorted duplicate set in
sorted-dup database
DB ERROR: db_verify: Page 8: unsorted duplicate set in
sorted-dup database
DB ERROR: db_verify: Page 11: unsorted duplicate set in
sorted-dup database
DB ERROR: db_verify: Page 3: unsorted duplicate set in
sorted-dup database
DB ERROR: db_verify: Page 12: unsorted duplicate set in
sorted-dup database
DB ERROR: db_verify: Page 4: unsorted duplicate set in
sorted-dup database
DB ERROR: db_verify: Page 10: unsorted duplicate set in
sorted-dup database
DB ERROR: db_verify: Page 5: unsorted duplicate set in
sorted-dup database
DB ERROR: db_verify: Page 7: unsorted duplicate set in
sorted-dup database
DB ERROR: db_verify: DB->verify: db/ebiRoot/cn.db4:
DB_VERIFY_BAD: Database verification failed
Secondary index file cn.db4 in db/ebiRoot is corrupted.
Please run db2index(.pl) for reindexing.


So there's a new error "unsorted duplicate set in
sorted-dup database". 
What does it mean?

Curious thing is that I cannot narrow down the problematic
entries any 
further. I've tried importing entries 300-450 and 275-475,
but there's no 
error. Also tried with two different sets from various
ranges, but no 
success yet. It only seems to happen when I import at least
250 entries.

This is how a single entry looks like:

dn: cn=foobar-dev-local,ou=Aliases,dc=ebi,dc=ac,dc=uk
cn: foobar-dev-local
objectClass: top
objectClass: nisMailAlias
rfc822MailMember: "|/homes/majordom/wrapper
stripmime.pl|/homes/majordom/wra
  pper resend -l foobar-dev  foobar-dev-outgoing"

I also tried skipping all entries with double quotes, but I
still got 
errors. There can be several rfc822MailMember attribute
values, as you 
probably know.

Thanks for your time, I really appreciate it.


Ville

--
Fedora-directory-users mailing list
Fedora-directory-usersredhat.com
https://www.redhat.com/mailman/listinfo/fedora-dir
ectory-users

Hi Noriko,

sorry it took so long to reply, I've been busy with other
work.

On Fri, 30 Mar 2007, Noriko Hosoi wrote:

> Ville Silventoinen wrote:
>> I asked my manager but he doesn't think it's a good
idea for security 
>> reasons. The problem is that the data is our NIS
mail.aliases and passwd, 
>> and we don't want to distribute them to the
internet. He suggested I'll 
>> modify the data, so I can send a sample to you.
I'll do that next week.
> That would be great. Thanks! I'm interested in what
type of characters your 
> data contain. E.g., character set is UTF-8? Some of
your DNs could contain 
> any special characters such as ''? etc...

The character set should be plain ASCII. I created an
imaginary 
mail.aliases file. You can download it from here:

ht
tp://www.ebi.ac.uk/systems-srv/mp/file-exchange/

Type in "fedorads" to the Pass Phrase input box
and click Go. You should 
see three files: mail.aliases, mail.aliases.ldif and
99user.ldif.

I can reproduce my problem with the above files, for
example, I've tested 
like this:

1. Delete existing ebiRoot database (you could use
userRoot).
2. Delete db/ebiRoot directory.
3. Create ebiRoot database.
4. Shutdown slapd.
5. Run db2index and verify-db.pl. No errors.
6. Start slapd.
7. Import mail aliases. I've tried with the Console and my
own CLI, which 
can import LDIF and add entries one-by-one. The method
doesn't seem to matter.
8. Shutdown slapd.
9. Run db2index and verify-db.pl, verify gives errors:

Verify log files in db ... Good
Verify db/ebiRoot/ancestorid.db4 ...
DB ERROR: db_verify: Page 2: out-of-order key at entry 254
DB ERROR: db_verify: DB->verify:
db/ebiRoot/ancestorid.db4: DB_VERIFY_BAD: Database
verification failed
Secondary index file ancestorid.db4 in db/ebiRoot is
corrupted.
Please run db2index(.pl) for reindexing.
Verify db/ebiRoot/objectclass.db4 ...
DB ERROR: db_verify: Page 2: out-of-order key at entry 255
DB ERROR: db_verify: DB->verify:
db/ebiRoot/objectclass.db4: DB_VERIFY_BAD: Database
verification failed
Secondary index file objectclass.db4 in db/ebiRoot is
corrupted.
Please run db2index(.pl) for reindexing.
Verify db/ebiRoot/nsuniqueid.db4 ... Good
Verify db/ebiRoot/parentid.db4 ...
DB ERROR: db_verify: Page 1: unsorted duplicate set in
sorted-dup database
DB ERROR: db_verify: DB->verify: db/ebiRoot/parentid.db4:
DB_VERIFY_BAD: Database verification failed
Secondary index file parentid.db4 in db/ebiRoot is
corrupted.
Please run db2index(.pl) for reindexing.
Verify db/ebiRoot/cn.db4 ...
DB ERROR: db_verify: Page 10: out-of-order key at entry 249
DB ERROR: db_verify: DB->verify: db/ebiRoot/cn.db4:
DB_VERIFY_BAD: Database verification failed
Secondary index file cn.db4 in db/ebiRoot is corrupted.
Please run db2index(.pl) for reindexing.
Verify db/ebiRoot/id2entry.db4 ... Good
Verify db/ebiRoot/entrydn.db4 ... Good
Verify db/ebiRoot/rfc822mailmember.db4 ...
DB ERROR: db_verify: Page 2: unsorted duplicate set in
sorted-dup database
DB ERROR: db_verify: Page 3: unsorted duplicate set in
sorted-dup database
DB ERROR: db_verify: DB->verify:
db/ebiRoot/rfc822mailmember.db4: DB_VERIFY_BAD: Database
verification failed
Secondary index file rfc822mailmember.db4 in db/ebiRoot is
corrupted.
Please run db2index(.pl) for reindexing.

> So, in your ldif data, the mail attribute also has this
type of value: 
> "|/homes/majordom/wrapper
stripmime.pl|/homes/majordom/wrapper resend -l 
> foobar-dev foobar-dev-outgoing"?

No, the People entries have a simpler mail value, like
"fooebi.ac.uk".

> And your mail index has the default indexing type:
presence, equality, and substring?

Yes.

> What type of indexing does the rfc822MailMember
attribute have?

I've tried without any indexing, with presence and equality
and with 
presence, equality and substring. The above errors are from
verify-db.pl 
when I have presence and equality indeces. If I have
presence, equality 
and substring, I get these errors for rfc822MailMember:

Verify db/ebiRoot/rfc822mailmember.db4 ...
DB ERROR: db_verify: Page 13: unsorted duplicate set in
sorted-dup database
DB ERROR: db_verify: Page 6: unsorted duplicate set in
sorted-dup database
DB ERROR: db_verify: Page 8: unsorted duplicate set in
sorted-dup database
DB ERROR: db_verify: Page 12: unsorted duplicate set in
sorted-dup database
DB ERROR: db_verify: Page 3: unsorted duplicate set in
sorted-dup database
DB ERROR: db_verify: Page 7: unsorted duplicate set in
sorted-dup database
DB ERROR: db_verify: Page 10: unsorted duplicate set in
sorted-dup database
DB ERROR: db_verify: Page 15: unsorted duplicate set in
sorted-dup database
DB ERROR: db_verify: Page 4: unsorted duplicate set in
sorted-dup database
DB ERROR: db_verify: Page 14: unsorted duplicate set in
sorted-dup database
DB ERROR: db_verify: Page 5: unsorted duplicate set in
sorted-dup database
DB ERROR: db_verify: Page 9: unsorted duplicate set in
sorted-dup database
DB ERROR: db_verify: Page 11: unsorted duplicate set in
sorted-dup database
DB ERROR: db_verify: DB->verify:
db/ebiRoot/rfc822mailmember.db4: DB_VERIFY_BAD: Database
verification failed
Secondary index file rfc822mailmember.db4 in db/ebiRoot is
corrupted.
Please run db2index(.pl) for reindexing.

> Have we already heard what platform you are running the
FDS on?

CentOS release 4.4, Linux 2.6.9-42.ELsmp. Pentium III
2x1266MHz CPUs, 2GB 
memory, SCSI disks. I'm using FDS 1.0.4.

I'm away this week Wed-Fri, so I'll get back to you next
week.

Thanks for the help!

Ville

--
Fedora-directory-users mailing list
Fedora-directory-usersredhat.com
https://www.redhat.com/mailman/listinfo/fedora-dir
ectory-users

Thanks Noriko, that explains a lot!

I still have that other problem to solve, related to
re-creating the 
database (see the end of my first email). I will try to
reproduce this 
problem and create some test data this week.

Thanks,
Ville


On Thu, 12 Apr 2007, Noriko Hosoi wrote:

> Thank you, Ville, for the test data.  I could reproduce
the db_verify 
> problem.
>
> I have good news and bad news.   Good
news, first...  Your db is not 
> corrupted.  The error report from verify-db.pl is
bogus.
>
> Bad news, next.  Please take a look at this bug.  We
are going to provide a 
> fixed utility some time soon.
>
> Summary: verify-db.pl (db_verify) does not work on a
little endian machine
>
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=
236256
>
> Sorry about this inconvenience, and thank you for
reporting the problem!
> --noriko
>
> Ville Silventoinen wrote:
>> Hi Noriko,
>> 
>> sorry it took so long to reply, I've been busy with
other work.
>> 
>> On Fri, 30 Mar 2007, Noriko Hosoi wrote:
>> 
>>> Ville Silventoinen wrote:
>>>> I asked my manager but he doesn't think
it's a good idea for security 
>>>> reasons. The problem is that the data is
our NIS mail.aliases and passwd, 
>>>> and we don't want to distribute them to the
internet. He suggested I'll 
>>>> modify the data, so I can send a sample to
you. I'll do that next week.
>>> That would be great. Thanks! I'm interested in
what type of characters 
>>> your data contain. E.g., character set is
UTF-8? Some of your DNs could 
>>> contain any special characters such as ''?
etc...
>> 
>> The character set should be plain ASCII. I created
an imaginary 
>> mail.aliases file. You can download it from here:
>> 
>> ht
tp://www.ebi.ac.uk/systems-srv/mp/file-exchange/
>> 
>> Type in "fedorads" to the Pass Phrase
input box and click Go. You should 
>> see three files: mail.aliases, mail.aliases.ldif
and 99user.ldif.
>> 
>> I can reproduce my problem with the above files,
for example, I've tested 
>> like this:
>> 
>> 1. Delete existing ebiRoot database (you could use
userRoot).
>> 2. Delete db/ebiRoot directory.
>> 3. Create ebiRoot database.
>> 4. Shutdown slapd.
>> 5. Run db2index and verify-db.pl. No errors.
>> 6. Start slapd.
>> 7. Import mail aliases. I've tried with the Console
and my own CLI, which 
>> can import LDIF and add entries one-by-one. The
method doesn't seem to 
>> matter.
>> 8. Shutdown slapd.
>> 9. Run db2index and verify-db.pl, verify gives
errors:
>> 
>> Verify log files in db ... Good
>> Verify db/ebiRoot/ancestorid.db4 ...
>> DB ERROR: db_verify: Page 2: out-of-order key at
entry 254
>> DB ERROR: db_verify: DB->verify:
db/ebiRoot/ancestorid.db4: DB_VERIFY_BAD: 
>> Database verification failed
>> Secondary index file ancestorid.db4 in db/ebiRoot
is corrupted.
>> Please run db2index(.pl) for reindexing.
>> Verify db/ebiRoot/objectclass.db4 ...
>> DB ERROR: db_verify: Page 2: out-of-order key at
entry 255
>> DB ERROR: db_verify: DB->verify:
db/ebiRoot/objectclass.db4: DB_VERIFY_BAD: 
>> Database verification failed
>> Secondary index file objectclass.db4 in db/ebiRoot
is corrupted.
>> Please run db2index(.pl) for reindexing.
>> Verify db/ebiRoot/nsuniqueid.db4 ... Good
>> Verify db/ebiRoot/parentid.db4 ...
>> DB ERROR: db_verify: Page 1: unsorted duplicate set
in sorted-dup database
>> DB ERROR: db_verify: DB->verify:
db/ebiRoot/parentid.db4: DB_VERIFY_BAD: 
>> Database verification failed
>> Secondary index file parentid.db4 in db/ebiRoot is
corrupted.
>> Please run db2index(.pl) for reindexing.
>> Verify db/ebiRoot/cn.db4 ...
>> DB ERROR: db_verify: Page 10: out-of-order key at
entry 249
>> DB ERROR: db_verify: DB->verify:
db/ebiRoot/cn.db4: DB_VERIFY_BAD: Database 
>> verification failed
>> Secondary index file cn.db4 in db/ebiRoot is
corrupted.
>> Please run db2index(.pl) for reindexing.
>> Verify db/ebiRoot/id2entry.db4 ... Good
>> Verify db/ebiRoot/entrydn.db4 ... Good
>> Verify db/ebiRoot/rfc822mailmember.db4 ...
>> DB ERROR: db_verify: Page 2: unsorted duplicate set
in sorted-dup database
>> DB ERROR: db_verify: Page 3: unsorted duplicate set
in sorted-dup database
>> DB ERROR: db_verify: DB->verify:
db/ebiRoot/rfc822mailmember.db4: 
>> DB_VERIFY_BAD: Database verification failed
>> Secondary index file rfc822mailmember.db4 in
db/ebiRoot is corrupted.
>> Please run db2index(.pl) for reindexing.
>> 
>>> So, in your ldif data, the mail attribute also
has this type of value: 
>>> "|/homes/majordom/wrapper
stripmime.pl|/homes/majordom/wrapper resend -l 
>>> foobar-dev foobar-dev-outgoing"?
>> 
>> No, the People entries have a simpler mail value,
like "fooebi.ac.uk".
>> 
>>> And your mail index has the default indexing
type: presence, equality, and 
>>> substring?
>> 
>> Yes.
>> 
>>> What type of indexing does the rfc822MailMember
attribute have?
>> 
>> I've tried without any indexing, with presence and
equality and with 
>> presence, equality and substring. The above errors
are from verify-db.pl 
>> when I have presence and equality indeces. If I
have presence, equality and 
>> substring, I get these errors for
rfc822MailMember:
>> 
>> Verify db/ebiRoot/rfc822mailmember.db4 ...
>> DB ERROR: db_verify: Page 13: unsorted duplicate
set in sorted-dup database
>> DB ERROR: db_verify: Page 6: unsorted duplicate set
in sorted-dup database
>> DB ERROR: db_verify: Page 8: unsorted duplicate set
in sorted-dup database
>> DB ERROR: db_verify: Page 12: unsorted duplicate
set in sorted-dup database
>> DB ERROR: db_verify: Page 3: unsorted duplicate set
in sorted-dup database
>> DB ERROR: db_verify: Page 7: unsorted duplicate set
in sorted-dup database
>> DB ERROR: db_verify: Page 10: unsorted duplicate
set in sorted-dup database
>> DB ERROR: db_verify: Page 15: unsorted duplicate
set in sorted-dup database
>> DB ERROR: db_verify: Page 4: unsorted duplicate set
in sorted-dup database
>> DB ERROR: db_verify: Page 14: unsorted duplicate
set in sorted-dup database
>> DB ERROR: db_verify: Page 5: unsorted duplicate set
in sorted-dup database
>> DB ERROR: db_verify: Page 9: unsorted duplicate set
in sorted-dup database
>> DB ERROR: db_verify: Page 11: unsorted duplicate
set in sorted-dup database
>> DB ERROR: db_verify: DB->verify:
db/ebiRoot/rfc822mailmember.db4: 
>> DB_VERIFY_BAD: Database verification failed
>> Secondary index file rfc822mailmember.db4 in
db/ebiRoot is corrupted.
>> Please run db2index(.pl) for reindexing.
>> 
>>> Have we already heard what platform you are
running the FDS on?
>> 
>> CentOS release 4.4, Linux 2.6.9-42.ELsmp. Pentium
III 2x1266MHz CPUs, 2GB 
>> memory, SCSI disks. I'm using FDS 1.0.4.
>> 
>> I'm away this week Wed-Fri, so I'll get back to you
next week.
>> 
>> Thanks for the help!
>> 
>> Ville
>> 
>> -- 
>> Fedora-directory-users mailing list
>> Fedora-directory-usersredhat.com
>> https://www.redhat.com/mailman/listinfo/fedora-dir
ectory-users
>
>

--
Fedora-directory-users mailing list
Fedora-directory-usersredhat.com
https://www.redhat.com/mailman/listinfo/fedora-dir
ectory-users