>>> Quanah Gibson-Mount <[email protected]> schrieb am 12.07.2022 um 18:19
in
Nachricht <DF246C4B7CC06679D467B085@[192.168.1.17]>:

> 
> ‑‑On Tuesday, July 12, 2022 1:31 PM +0200 Francesco Malvezzi 
> <[email protected]> wrote:
> 
>> [...]
>>>
>>> Whatever "it works" really means. Without seeing example entries and
>>> their pwdChangedTime values it's impossible to say anything meaningful ‑
>>> except the usual "it works for me".
>>
>> it turns out this malfunctioning is affecting only entries whose password
>> has been changed last time before the upgrade [1].
>>
>> So to be sure that 'it works for you' you should pick a pretty old entry
>> and craft the range pwdChangedTime query accordingly.
>>
>> And of course this applies to you only if you did a in‑place update. If
>> you slapcat‑ed and slapadd‑ed your entries, you are pretty safe,
> 
> This is due to ITS#9513 which changed the generalizedTime indexer.  So any 
> time‑based attributes need to be reindexed (or database exported/imported 
> will fix it too).  This got missed being documented on the OpenLDAP side. 
> Can also affect replication when an in‑place upgrade is done.

Can't that be detected and fixed automatically?

> 
> 
> Regards,
> Quanah


Reply via email to