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
_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
