#47831 server restart wipes out index config if there is a default index
Closed: wontfix None Opened 9 years ago by mreynolds.

Steps to reproduce:

[1] Setup a DS instance
[2] Configure the objectclass index for userRoot

dn: cn=objectclass,cn=index,cn=userRoot,cn=ldbm
database,cn=plugins,cn=config
objectClass: top
objectClass: nsIndex
cn: objectclass
nsSystemIndex: true
nsIndexIDListScanLimit: limit=-1 type=eq values=person
nsIndexType: eq

[3] Import 100k user LDIF
[4] Perform an ldapsearch using objectclass=person

ldapsearch -D "cn=directory manager" -w password -b "dc=example,dc=com" -xLLL objectclass=person dn

[5] Access log reports search as unindexed (notes=A)


You don't have to import a 100k ldif - just set the default idlistscanlimit to something really low, so that a search of e.g. (objectclass=top) will hit the limit and be unindexed.

I stop the server, edit dse.ldif, and restart. There seems to be some sort of corruption happening to the inst->inst_attrs avl tree, when the server calls ldbm_instance_create_default_indexes() to add the default indexes to the instance. Before that function is called at startup, inst->inst_attrs looks ok. But sometime during that call, the nodes in the tree start to show some sort of corruption:

(gdb) p (struct attrinfo )inst->inst_attrs->avl_right->avl_right
$94 = {ai_type = 0x989780 "p\221\230", ai_indexmask = 1935764481,
ai_index_rules = 0x989540, ai_dblayer = 0x989860,
ai_dblayer_count = 9933184, ai_idl = 0x21,
ai_attrcrypt = 0x6e6f6870656c6574, ai_key_cmp_fn = 0x7265626d754e65,
ai_dup_cmp_fn = 0x97bf80, ai_substr_lens = 0x21, ai_sattr = {
a_type = 0x6e6f6870656c6574 <error: Cannot access memory at address 0x6e6f6870656c6574>, a_present_values = {num = 1836404325, max = 7497058,

e.g. ai_type should be a string like "objectClass".

The root node looks ok, as well as its immediate children, this may explain why/how the acceptance tests are able to pass.

The problem is here:
{{{
int
ldbm_instance_index_config_enable_index(ldbm_instance inst, Slapi_Entry e)
{
char *index_name;
int rc;

rc=ldbm_index_parse_entry(inst, e, "from DSE add", &index_name);

}}}
The call to ldbm_index_parse_entry will actually replace the existing index, with the new one from e. This is bad.

Looks like the fix is that ldbm_instance_index_config_enable_index should not call ldbm_index_parse_entry but should just get the index using ainfo_get. The index should already exist. If not, then it should call ldbm_index_parse_entry to add it.

The problem is that, when the server restarts, and you have customized an index, and the customized index is also a default index (e.g. objectclass, sn, many more), when the server tries to add and enable any missing indexes, it will overwrite the existing config with the config from the default, wiping out any customizations made.

0001-Ticket-47831-server-restart-wipes-out-index-config-i.patch
0001-Ticket-47831-server-restart-wipes-out-index-config-i.patch

fc67fb8..4bccd2b 389-ds-base-1.2.11 -> 389-ds-base-1.2.11
commit 4bccd2b
Author: Rich Megginson rmeggins@redhat.com
Date: Wed Jun 25 16:49:50 2014 -0600
f86e1a2..e260d9f 389-ds-base-1.3.0 -> 389-ds-base-1.3.0
commit e260d9fd9e680579677007b6466f4e9ad3323eb6
Author: Rich Megginson rmeggins@redhat.com
Date: Wed Jun 25 16:49:50 2014 -0600
e6762cb..18bc3e8 389-ds-base-1.3.1 -> 389-ds-base-1.3.1
commit 18bc3e82c3919867f14747343e452019630b60d0
Author: Rich Megginson rmeggins@redhat.com
Date: Wed Jun 25 16:49:50 2014 -0600
2bae66a..111e11a 389-ds-base-1.3.2 -> 389-ds-base-1.3.2
commit 111e11a
Author: Rich Megginson rmeggins@redhat.com
Date: Wed Jun 25 16:49:50 2014 -0600
b3aae6b..5c5c960 master -> master
commit 5c5c960
Author: Rich Megginson rmeggins@redhat.com
Date: Wed Jun 25 16:49:50 2014 -0600

This needs to go into 1.2.11 branch and all later branches

Metadata Update from @rmeggins:
- Issue assigned to rmeggins
- Issue set to the milestone: N/A

7 years ago

389-ds-base is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in 389-ds-base's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/389ds/389-ds-base/issues/1162

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Metadata Update from @spichugi:
- Issue close_status updated to: wontfix (was: Fixed)

3 years ago

Login to comment on this ticket.

Metadata