[Freeipa-devel] Is Backend.krb part of API?
Hi, I'm working on porting FreeIPA away from python-krbV. Backend.krb and KRB5_CCache classes are mere wrappers around krbV bindings, so it would make sense to remove them. But I found the former used in the example in doc/examples/python-api.py. Is it part of FreeIPA's API? Shall I provide some partial compatibility layer for it? (only partial because some methods can take krbV objects as arguments) Thank you, Michael Simacek -- 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
Re: [Freeipa-devel] Is Backend.krb part of API?
On 07/28/2015 10:57 AM, Michael Šimáček wrote: Hi, I'm working on porting FreeIPA away from python-krbV. Backend.krb and KRB5_CCache classes are mere wrappers around krbV bindings, so it would make sense to remove them. But I found the former used in the example in doc/examples/python-api.py. Is it part of FreeIPA's API? Shall I provide some partial compatibility layer for it? (only partial because some methods can take krbV objects as arguments) Thank you, Michael Simacek Does the replacement offer API which has all the methods as the wrappers? If so we can remove them. Imho we can remove Backend.krb aka ipalib/plugins/kerberos.py. It's used only in 2 files, both are not in production. But I'm not sure about KRB5_CCache, the wrapper has some exception logic which might be wanted to be kept. -- Petr Vobornik -- 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
Re: [Freeipa-devel] Is Backend.krb part of API?
On Tue, 28 Jul 2015, Simo Sorce wrote: On Tue, 2015-07-28 at 13:55 +0300, Alexander Bokovoy wrote: On Tue, 28 Jul 2015, Petr Vobornik wrote: On 07/28/2015 10:57 AM, Michael Šimáček wrote: Hi, I'm working on porting FreeIPA away from python-krbV. Backend.krb and KRB5_CCache classes are mere wrappers around krbV bindings, so it would make sense to remove them. But I found the former used in the example in doc/examples/python-api.py. Is it part of FreeIPA's API? Shall I provide some partial compatibility layer for it? (only partial because some methods can take krbV objects as arguments) Thank you, Michael Simacek Does the replacement offer API which has all the methods as the wrappers? If so we can remove them. Imho we can remove Backend.krb aka ipalib/plugins/kerberos.py. It's used only in 2 files, both are not in production. But I'm not sure about KRB5_CCache, the wrapper has some exception logic which might be wanted to be kept. Backend.krb can go if you provide something similar to KRB5_CCache. We need to be able to initialize ccache with that class -- either by using existing ccache (we often marshall ccache content to memcached and then unmarshall it when the same session comes back) or by using a keytab. After ccache is provided, we need to be able to query default principal of the existing ccache. We should be able to do all this with python-gssapi and the store extensions. Yep. It would be good to have a helper, though. -- / Alexander Bokovoy -- 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
Re: [Freeipa-devel] Is Backend.krb part of API?
On Tue, 28 Jul 2015, Petr Vobornik wrote: On 07/28/2015 10:57 AM, Michael Šimáček wrote: Hi, I'm working on porting FreeIPA away from python-krbV. Backend.krb and KRB5_CCache classes are mere wrappers around krbV bindings, so it would make sense to remove them. But I found the former used in the example in doc/examples/python-api.py. Is it part of FreeIPA's API? Shall I provide some partial compatibility layer for it? (only partial because some methods can take krbV objects as arguments) Thank you, Michael Simacek Does the replacement offer API which has all the methods as the wrappers? If so we can remove them. Imho we can remove Backend.krb aka ipalib/plugins/kerberos.py. It's used only in 2 files, both are not in production. But I'm not sure about KRB5_CCache, the wrapper has some exception logic which might be wanted to be kept. Backend.krb can go if you provide something similar to KRB5_CCache. We need to be able to initialize ccache with that class -- either by using existing ccache (we often marshall ccache content to memcached and then unmarshall it when the same session comes back) or by using a keytab. After ccache is provided, we need to be able to query default principal of the existing ccache. -- / Alexander Bokovoy -- 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
Re: [Freeipa-devel] Is Backend.krb part of API?
On Tue, 2015-07-28 at 13:55 +0300, Alexander Bokovoy wrote: On Tue, 28 Jul 2015, Petr Vobornik wrote: On 07/28/2015 10:57 AM, Michael Šimáček wrote: Hi, I'm working on porting FreeIPA away from python-krbV. Backend.krb and KRB5_CCache classes are mere wrappers around krbV bindings, so it would make sense to remove them. But I found the former used in the example in doc/examples/python-api.py. Is it part of FreeIPA's API? Shall I provide some partial compatibility layer for it? (only partial because some methods can take krbV objects as arguments) Thank you, Michael Simacek Does the replacement offer API which has all the methods as the wrappers? If so we can remove them. Imho we can remove Backend.krb aka ipalib/plugins/kerberos.py. It's used only in 2 files, both are not in production. But I'm not sure about KRB5_CCache, the wrapper has some exception logic which might be wanted to be kept. Backend.krb can go if you provide something similar to KRB5_CCache. We need to be able to initialize ccache with that class -- either by using existing ccache (we often marshall ccache content to memcached and then unmarshall it when the same session comes back) or by using a keytab. After ccache is provided, we need to be able to query default principal of the existing ccache. We should be able to do all this with python-gssapi and the store extensions. Simo. -- Simo Sorce * Red Hat, Inc * New York -- 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
