[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: (ITS#5540) Normalization assertion in attr.c
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.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/