Re: [Freeipa-devel] Q: dnsclient portability
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. Martin ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Q: dnsclient portability
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... -- / Alexander Bokovoy ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Q: dnsclient portability
On Mon, 2011-12-05 at 18:09 +0200, 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... RHEL can ship a version that bundles dnspython, we just need a conditional on import so that we import from ipasomething.dnspython if regular dnspython is not available. Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Q: dnsclient portability
On Mon, 05 Dec 2011, Simo Sorce wrote: 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... RHEL can ship a version that bundles dnspython, we just need a conditional on import so that we import from ipasomething.dnspython if regular dnspython is not available. Ok. From my perspective it is also much simpler to turn around and fix usage of ipapython.dnsclient rather than mimic it on top of dnspython. -- / Alexander Bokovoy ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Q: dnsclient portability
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
[Freeipa-devel] Q: dnsclient portability
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. What do you think? -- / Alexander Bokovoy ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
Re: [Freeipa-devel] Q: dnsclient portability
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. -- John Dennis jden...@redhat.com Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel
