On 27.6.2016 10:18, Martin Babinsky wrote:
> On 06/27/2016 10:04 AM, Petr Vobornik wrote:
>> On 06/27/2016 09:42 AM, Lenka Doudova wrote:
>>> Hi!
>>>
>>> With newly created AD machines in Brno lab, existing trust tests fail on
>>> 'ipa dnsforwardzone-add' command claiming the zone is already present,
>>> as new AD domain is dom-221.idm.lab.eng.brq.redhat.com.
>>>
>>> To prevent these failures I prepared attached patch, that will still
>>> attempt to add the forward zone, but in case of non-zero return code
>>> will check the message if it says that the forward zone is already
>>> configured, and lets the tests continue, if it is so.
>>>
>>>
>>> Lenka
>>>
>>
>>
>> Current approach expects that every error of ipa dnsforward-add here
>> will mean that the zone exists. So it might hide other issues - not very
>> good.
>>
>> On the other hand it is not very robust to parse error message.
>>
>> Question for general audience: What do you think if IPA client's exit
>> status would be the IPA error code instead of "1" for every error. E.g.
>> in DuplicateEntry case it's 4002.
>>
>> Btw, this is not a NACK.
>>
> 
> Well AFAIK the exit status on POSIX systems is encoded into a single byte so
> you cannot have the return value greater that 255. We would have to devise
> some mapping between our XMLRPC status codes and subprocess return codes.
> 
> Some of our exceptions have defined return values outside plain '1', e.g.
> NotFound has return value of 2. It would be possible to extend this concept on
> other common errors.

Even more importantly, the forward zone is completely unnecessary because DNS
when DNS is set up properly. I would simply remove the dnsforwardzone-add.

-- 
Petr^2 Spacek

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Reply via email to