[Date Prev][Date Next] [Chronological] [Thread] [Top]

(ITS#1650) -- reproducible index corruption 2.0.23 db3



Well, it's official. I can reproduce the index corruption problems I 
have seen using
a simple Net::LDAP script. I am working from a small directory (fewer 
than 5000
entries) and using the following script I add the posixAccount 
objectClass to a set
of entries (specified by the filter in the 3 argument). I am using a 
stock rh7.2 for my
tests which uses db3 version 3.2.9. I am running OpenLDAP 2.0.23.

use Net::LDAP;

my $ldap = Net::LDAP->new('localhost');
my $res = $ldap->bind($ARGV[0],password=>$ARGV[1]);
$res->code && die $res->error;

$res = $ldap->search(filter=>$ARGV[2],['uid']);
$res->code && die $res->error;

my $e;
my $n = 0;
while ($e = $res->pop_entry())
  {
    my @oc = $e->get_value('objectClass');
    next unless grep /eduPerson/is,@oc;
    next if grep /posixAccount/is,@oc;

    my $uid = $e->get_value('uid');
    # Set random values for uidNumber and gidNumber
    $e->replace(uidNumber=>int rand 65535);
    $e->replace(gidNumber=>int rand 65535);
    # Set faked home directory and shell, just to make the entry complete
    $e->replace(homeDirectory=>"/home/$uid");
    $e->replace(mail=>"$uid\@su.se");
    $e->replace(loginShell=>'/bin/false');
    push(@oc,'posixAccount');
    $e->replace(objectClass=>\@oc);
    my $res = $e->update($ldap);
    $res->code && die $res->error;
    $n++;
  }

print STDERR "Modified $n entries\n";

Before each test I reloaded the directory. Each test consists of running 
5 parallell
instances of the test script against the directory server. During the 
test process I
run the following commands at intervals:

ldapsearch -x -h localhost 'objectClass=eduPerson' uid | grep dn: | wc -l

Since I am not modifiying adding or removing the eduPerson objectClass 
value this
command should always return the same number of entries. Note that the 
script modifies
subsets of the <em>entries</em> which are of eduPerson objectClass. 
After a while
(I believe it may be related to each parallell instance of the script 
finishing) the eduPerson
count begins to fluctuate. After the tests finish I can "fix" the 
problem by running slapindex.
This is what a test-run looks like:

[leifj@klapautius leifj]$ ldapsearch -x -h localhost 
'objectClass=eduPerson' uid | grep dn: | wc -l
   4618
[leifj@klapautius leifj]$ ldapsearch -x -h localhost 
'objectClass=eduPerson' uid | grep dn: | wc -l
   4618
[leifj@klapautius leifj]$ ldapsearch -x -h localhost 
'objectClass=eduPerson' uid | grep dn: | wc -l
   4618
[leifj@klapautius leifj]$ ldapsearch -x -h localhost 
'objectClass=eduPerson' uid | grep dn: | wc -l
   4097
[leifj@klapautius leifj]$ ldapsearch -x -h localhost 
'objectClass=eduPerson' uid | grep dn: | wc -l
   4100
[leifj@klapautius leifj]$ Modified 26 entries
Modified 46 entries
Modified 79 entries
[leifj@klapautius leifj]$ ldapsearch -x -h localhost 
'objectClass=eduPerson' uid | grep dn: | wc -l
   4111

Next I will try this with different databases. I don't believe the 
database has anything
to do with it though. I will also try this with REL_ENG_2 If you guys 
think it might be interesting.
I will try to find another os to try (to elliminate thread-related 
problems). Any other thoughts?

    Cheers Leif