[Freeipa-devel] Q: dnsclient portability

[Rob Crittenden]

Alexander Bokovoy wrote:
> On Mon, 05 Dec 2011, Martin Kosek wrote:
>> On Fri, 2011-12-02 at 10:20 -0500, John Dennis wrote:
>>> On 12/02/2011 07:58 AM, Alexander Bokovoy wrote:
>>>> Hi,
>>>>
>>>> I'm working on ticket https://fedorahosted.org/freeipa/ticket/1837
>>>> which concerns portability of ipapython.dnsclient module.
>>>>
>>>> ipapython.dnsclient module uses acutil module to perform 'res_send(3)'
>>>> call provided by libresolv. acutil implements bindings to two system
>>>> calls (res_send() and getusershell()) and belongs to authconfig
>>>> package. The total size of acutil module source code is ~100 lines of
>>>> C code.
>>>>
>>>> Now, authconfig package is not available beyond Fedora/RHEL
>>>> distributions and, in particular, it is not available in
>>>> Ubuntu / GNU/Debian Linux. It means ipapython.dnsclient will fail on
>>>> those platforms and a way of getting around the issue needs to be
>>>> found.
>>>>
>>>> So far, there are two options:
>>>>
>>>> 1. Extract acutil module from authconfig and supply it with
>>>> freeipa-python in a manner similar to default_encoding module. This is
>>>> 'cheapest' solution in a sense we only interested in bindings to
>>>> res_send(3). FreeIPA client code then will be self-contained and would
>>>> not depend on authconfig availability (platform portability code
>>>> already allows to re-implement authconfig implementation).
>>>>
>>>> 2. Port ipapython.dnsclient to use dnspython module if acutil is not
>>>> available. This module, available from http://www.dnspython.org/, can
>>>> be found in Fedora, GNU/Debian Linux, Ubuntu and many other
>>>> distributions. It is python-only resolver providing a super-set of
>>>> ipapython.dnsclient features.
>>>>
>>>> The downside of the first approach is a need to distribute and
>>>> maintain another CPython extension. Though the code is straight
>>>> forward and simple enough, it is still a separate maintenance burden.
>>>>
>>>> The downside of the second approach is to write a bridge code between
>>>> ipapython.dnsclient API and dnspython API. They are different enough
>>>> so that remapping of fields in objects resulting from a query is
>>>> needed.
>>>>
>>>> I've started to implement the bridge code myself but it is quickly
>>>> getting to the level of effort original ipapython.dnsclient has
>>>> (due to API differences in attributes names) and that means it is
>>>> probably not worth it.
>>>
>>> I think the second approach is better, here is my reasoning:
>>>
>>> * If we rebuilt acutil it would make more sense to package it an actual
>>> package, not just another IPA CPython module, this would be more
>>> flexible and other could use it, but ...
>>>
>>> * acutil seems incomplete and an odd mix of just 2 functions, probably
>>> the minimum needed but not general (I don't know the API's so I might be
>>> wrong on that score)
>>>
>>> * We really don't want to maintain YAP (Yet Another Package)
>>>
>>> * dnspython seems more complete, widely used, has other maintainers and
>>> support we can leverage. (Should we have used it in the first place)
>>>
>>> * Since dnspython is a superset and once we get ipapython.dnsclient
>>> ported to it maybe we'll discover we can then easily user other features
>>> dnspython provides.
>>>
>>> Anyway, tough call, the right answer is not entirely obvious, just my 2
>>> cents.
>>>
>>>
>>
>> I like second approach more too. Although I think the best solution here
>> would be to discard ipapython.dnsclient as is and use dnspython directly
>> in our code. ipapython.dnsclient is not used on that many places in our
>> code anyway.
>>
>> This way, we wouldn't have use our artificial dnsclient API in the
>> proposed bridge but rather use (more standard) dnspython API and have
>> access to all its native functionality.
> Hm. Good idea. This though will have a toll for platforms where
> dnspython is not yet available like various Red Hat Enterprise Linux
> versions...
>

I think this is why we stuck with acutil.

rob