Tomas Babej wrote: > > On 07/01/2014 12:19 PM, Martin Kosek wrote: >> 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 >> >> _______________________________________________ >> Freeipa-devel mailing list >> Freeipa-devel@redhat.com >> https://www.redhat.com/mailman/listinfo/freeipa-devel > > Issue is not 100% reproducible in my testing. The underlying problem > here is that sometimes the values of nsds5replicalastupdatestart and > nsds5replicalastupdateend attributes are not being set during > replication (intermittent issue) and thus 389 falls back and returns '0' > if any of these attributes were explicitily requested, which is not a > valid value for LDAP Generalized time. > > The reason you're not hitting the conversion errors is probably that > during replication nsds5replicalastupdatestart and > nsds5replicalastupdateend were assigned proper values. You can check > that in the replication log (search for "Replication Update in progress: > %s: status: %s: start: %d: end: %d" in the logs). > > I am checking with Ludvig, but if this behaviour is specific to the > nsds5replicalastupdatestart and nsds5replicalastupdateend I'd go with > the SYNTAX_OVERRIDE solution. > > However, it is worth noting that these conversion errors are harmless > themselves. >
IIRC I also saw this with: ipa-replica-manage list -v `hostname` That may be easier to reproduce/validate. rob _______________________________________________ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
