unix.gurus@gmail.com wrote:

------=_Part_4694_18767492.1212106829556 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Content-Disposition: inline

VGhpcyBiYWNrdHJhY2UgbWF5IHByb3ZpZGUgc29tZSBmdXJ0aGVyIGluZm86CgojMCAgMHgwMDAw N2Y3MjU1OGFhMDk1IGluIHJhaXNlICgpIGZyb20gL2xpYi9saWJjLnNvLjYKIzEgIDB4MDAwMDdm NzI1NThhYmFmMCBpbiBhYm9ydCAoKSBmcm9tIC9saWIvbGliYy5zby42CiMyICAweDAwMDA3Zjcy NTU4YTMyZGYgaW4gX19hc3NlcnRfZmFpbCAoKSBmcm9tIC9saWIvbGliYy5zby42CiMzICAweDAw

Thanks, the original report was sufficient. It surfaces a larger problem, which we've been ignoring up till now. The correct action would be to iterate through all the databases and generate the normalized values for all the affected attributes. There is currently no code to make that happen though. (Likewise, if deleting matching rules, the normalized values must also be deleted.) As such, the only way to progress after such a change would be to dump and reload the DBs (slapcat/slapadd).

We'll probably need to discuss on the -devel list what steps to take from here.