Knowledge Partner
Knowledge Partner
597 views

Bug 1063996 affects eDir 8 as well?

I see this in the eDir 9.1 history:


Issues resolved in eDirectory 9.1
March 2018
NDSD: 40101.29
NICI 3.1
OpenSSL 1.0.2n

NDS Server
- Compound indexes are no longer functional after running ndsrepair -R (Bug 1063996)


I have an eDir 8.8.8.11 server that has (had?) compound indexes that were working. Had to "ndsrepair -R" it. Afterward, simple LDAP searches like "cn=foo" started failing to return any results.

With ndstrace +LDAP +RECM I identified that the search was using compound index "CN-SN", despite having a simple index "CN" and a substring index "CN_SS" to work with. Taking index CN-SN offline, LDAP searches started working normally again.

I don't see that 1063996 has been resolved for eDir 8. I'm not even seeing that this same problem has been reported for eDir 8. Anybody with better search-fu than me confirm this?

Other than delete index and create index, is there any way to repair a broken index? I don't recall ever having run in to a broken index before.
Labels (1)
0 Likes
5 Replies
Knowledge Partner
Knowledge Partner

Re: Bug 1063996 affects eDir 8 as well?

That bug was reported in 2017-10, about the same time that 8.8 officially
left support. While it is possible that something about repair broke the
index, it is also possible that nobody hit it until after that date, or
maybe you were the first.

I, too, cannot find any mention of this bug with eDirectory 8.8, but I do
believe this was a bug introduced with 9.0 SP2. Does that mean that the
same bug was not backported accidentally to 8.8 SP8 Patch 11? Not
necessarily, but it's also possible that fixes to 9.x were also pushed
back to 8.x, and those fixes could have included new bugs. Compound
indexes are newer things, and not defined on most servers (I think IDM is
the only thing that defines them, but do not quote me on that), so it may
just be an infrequently-hit thing when combining IDM, plus a newer version
of eDir, plus the presence of a compound index, plus a repair, plus
noticing that things are now slower with certain queries.

Out of curiosity, how does performance look when you use both attributes
in that compound index?

In the past I've only fixed indexes by recreating them; typically that's
pretty fast with eDirectory, but your mileage may vary depending on DIB
size, hardware performance, box busy-ness, etc.

--
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below.

If you want to send me a private message, please let me know in the
forum as I do not use the web interface often.
0 Likes
Knowledge Partner
Knowledge Partner

Re: Bug 1063996 affects eDir 8 as well?

ab;2482872 wrote:
That bug was reported in 2017-10, about the same time that 8.8 officially
left support. While it is possible that something about repair broke the
index, it is also possible that nobody hit it until after that date, or
maybe you were the first.

I, too, cannot find any mention of this bug with eDirectory 8.8, but I do
believe this was a bug introduced with 9.0 SP2. Does that mean that the
same bug was not backported accidentally to 8.8 SP8 Patch 11? Not
necessarily, but it's also possible that fixes to 9.x were also pushed
back to 8.x, and those fixes could have included new bugs. Compound
indexes are newer things, and not defined on most servers (I think IDM is
the only thing that defines them, but do not quote me on that), so it may
just be an infrequently-hit thing when combining IDM, plus a newer version
of eDir, plus the presence of a compound index, plus a repair, plus
noticing that things are now slower with certain queries.

Out of curiosity, how does performance look when you use both attributes
in that compound index?

In the past I've only fixed indexes by recreating them; typically that's
pretty fast with eDirectory, but your mileage may vary depending on DIB
size, hardware performance, box busy-ness, etc.

--
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below.

If you want to send me a private message, please let me know in the
forum as I do not use the web interface often.


Yeah, as far as I know, compound index is only used (needed) by RBPM 4.6 and newer. This environment went to 4.6 (eDir 8.8.8.9, IDM 4.60), then rolled RBPM back to 4.02, so the compound indexes aren't in use, and aren't needed, as far as I know. Bugs in eDir 8.8.8.9 forced me to eDir 8.8.8.11. I had been ignoring them, until suddenly simple searches (cn=bob) started returning no results. Not slower, it's nice and fast, it immediately claims that cn=bob doesn't exist.

I'm tempted just to delete them and move on. If they ever decide to move off of RBPM 4.02, that'll be a whole new project anyway.
0 Likes
Knowledge Partner
Knowledge Partner

Re: Bug 1063996 affects eDir 8 as well?

Sounds like you definitely have a way forward. If you are not using them,
then even having them working will only negatively impact performance, so
best be rid of them.


--
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below.

If you want to send me a private message, please let me know in the
forum as I do not use the web interface often.
0 Likes
Sabhay1 Absent Member.
Absent Member.

Re: Bug 1063996 affects eDir 8 as well?

ab;2482872 wrote:
That bug was reported in 2017-10, about the same time that 8.8 officially
left support. While it is possible that something about repair broke the
index, it is also possible that nobody hit it until after that date, or
maybe you were the first.

I, too, cannot find any mention of this bug with eDirectory 8.8, but I do
believe this was a bug introduced with 9.0 SP2. Does that mean that the
same bug was not backported accidentally to 8.8 SP8 Patch 11? Not
necessarily, but it's also possible that fixes to 9.x were also pushed
back to 8.x, and those fixes could have included new bugs. Compound
indexes are newer things, and not defined on most servers (I think IDM is
the only thing that defines them, but do not quote me on that), so it may
just be an infrequently-hit thing when combining IDM, plus a newer version
of eDir, plus the presence of a compound index, plus a repair, plus
noticing that things are now slower with certain queries.

Out of curiosity, how does performance look when you use both attributes
in that compound index?

In the past I've only fixed indexes by recreating them; typically that's
pretty fast with eDirectory, but your mileage may vary depending on DIB
size, hardware performance, box busy-ness, etc.



8.8.8 line is end of life now and 9.x line is the way forward. Because of end of life, the fix was not ported back to 8.8.8 line. The fix went in eDir 9.1 which also had other improvements for compund indexes. Compound indexes was mainly done for IDM 4.6 to enable VLV and other features for IDM dashboard.
0 Likes
Knowledge Partner
Knowledge Partner

Re: Bug 1063996 affects eDir 8 as well?

> 8.8.8 line is end of life now and 9.x line is the way forward. Because
> of end of life, the fix was not ported back to 8.8.8 line. The fix went
> in eDir 9.1 which also had other improvements for compund indexes.
> Compound indexes was mainly done for IDM 4.6 to enable VLV and other
> features for IDM dashboard.


VLV is VIrtyal List View, right? Why does a compound index become a
prereq for VLV?

0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.