A suggestion for a vain attempt to kill a FAQ:
To teach people to run sbin/slapindex after adding an index to slapd.conf, slapd can refuse to start if an index file is missing but dn2id.bdb exists. Same with other slap tools that need to open/create the index file. (At least slapadd, I don't know if there are others.)
slapindex and slapcat, at least, will need to keep working.
If database recovery can sabotage this feature or vice versa, recovery will of course have to take precedence.
Hallvard B Furuseth wrote:
A suggestion for a vain attempt to kill a FAQ:
To teach people to run sbin/slapindex after adding an index to slapd.conf, slapd can refuse to start if an index file is missing but dn2id.bdb exists. Same with other slap tools that need to open/create the index file. (At least slapadd, I don't know if there are others.)
slapindex and slapcat, at least, will need to keep working.
If database recovery can sabotage this feature or vice versa, recovery will of course have to take precedence.
It may make sense for slapd, but it would require a fair bit of restructuring. Currently we don't create the index file until an attribute actually references it. So it's perfectly valid for an index file to be missing at startup time, just because no entries needed that index yet.
Also, this approach won't detect the problem case of the index definition for an already indexed attribute being changed. (E.g., adding presence to an attribute that already has an eq index.)
Howard Chu writes:
Hallvard B Furuseth wrote:
(...) To teach people to run sbin/slapindex after adding an index to slapd.conf, slapd can refuse to start if an index file is missing but dn2id.bdb exists. (...)
It may make sense for slapd, but it would require a fair bit of restructuring. Currently we don't create the index file until an attribute actually references it.
Whoops. I noticed that we had a displayName index even though there is no displayName in our database, but read operations that write to the database didn't occur to me:-( Seems a bit strange, but it's true it's not worth worrying about just for this.
Also, this approach won't detect the problem case of the index definition for an already indexed attribute being changed. (E.g., adding presence to an attribute that already has an eq index.)
True ehough, thus just "teach" and not "enforce". Anyway, I guess I'll go back to dreaming of a file in the database directory which tracks the various config options needed for that database. Might even implement it someday, once I figure out which config options to deem sufficiently relevant:-)
-
Hallvard B Furuseth -
Howard Chu