[Freeipa-devel] [PATCH 0236] ipaldap: Fallback to string if datetime conversion went wrong

[Martin Kosek]

On 06/26/2014 10:44 AM, Jan Cholasta wrote:
> On 26.6.2014 10:39, Petr Viktorin wrote:
>> On 06/26/2014 10:33 AM, Jan Cholasta wrote:
>>> On 26.6.2014 09:40, Petr Viktorin wrote:
>>>> On 06/26/2014 09:33 AM, Jan Cholasta wrote:
>>>>> On 26.6.2014 09:21, Petr Viktorin wrote:
>>>>>> On 06/26/2014 08:30 AM, Jan Cholasta wrote:
>>>>>>> On 25.6.2014 18:25, Petr Viktorin wrote:
>>>>>>>> On 06/25/2014 05:29 PM, Jan Cholasta wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> On 25.6.2014 17:17, Tomas Babej wrote:
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> Our datetime conversion does not support full LDAP Generalized
>>>>>>>>>> time syntax. In the unsupported cases, we should fall back
>>>>>>>>>> to string representation of the attribute.
>>>>>>>>>>
>>>>>>>>>> In particular, '0' is used to denote no value of LDAP generalized
>>>>>>>>>> time attribute.
>>>>>>>>>>
>>>>>>>>>> https://fedorahosted.org/freeipa/ticket/4350
>>>>>>>>>
>>>>>>>>> NACK, this beats the purpose of decoding of the values, because it
>>>>>>>>> requires you to check the type of the value before using it.
>>>>>>>>>
>>>>>>>>> Instead, you should either fix the code that uses the
>>>>>>>>> nsds5ReplicaLastUpdate{Start,End} attributes to access their raw
>>>>>>>>> value
>>>>>>>>> directly, or exclude the attributes from decoding to datetime by
>>>>>>>>> overriding their type in IPASimpleLDAPObject._SYNTAX_OVERRIDE.
>>>>>>>>>
>>>>>>>>> Honza
>>>>>>>>>
>> [...]
>>>>
>>>> The problem is that "unset" is a valid value here,
>>>
>>> It is not, according to Generalized Time syntax (RFC 4517 section
>>> 3.3.13) "0" is an invalid value and we should treat it the same way as
>>> any other invalid value (hence my original suggestion).
>>
>> OK, in that case ignore what I said here.
>>
>> So am I correct that 389-ds storing a value that doesn't comply with the
>> attribute's syntax?  Should we file a DS bug?
>>
> 
> AFAIK syntax checks are done only on LDAP adds and mods, so unless we are
> setting "0" somewhere and DS does not complain, it is not a bug.

What is the final resolution here? Do we plan to ignore the attribute
conversion for these attributes as, fixing DS or are we fixing the framework?

Surprisingly, I did not see the filed failure any more in my
ipa-replica-install tests nor in the latest CI run, I wonder if anything
changed in our code or if the issue is intermittent. Anyway, I am willing to
close this ticket if this is no longer a problem.

Martin