On Tue, 25 Aug 2015, Petr Viktorin wrote:
On 08/25/2015 12:38 PM, Alexander Bokovoy wrote:
On Tue, 25 Aug 2015, Michael Šimáček wrote:



On 2015-08-24 20:29, Robbie Harwood wrote:
Michael Šimáček <msima...@redhat.com> writes:

On 2015-08-24 17:49, Simo Sorce wrote:

On Mon, 2015-08-24 at 17:18 +0200, Michael Šimáček wrote:

On 2015-08-24 14:50, Jan Cholasta wrote:

On 23.8.2015 23:27, Michael Šimáček wrote:

3) ipa-adtrust-install fails with:

admin password:

Unrecognized error during check of admin rights:
ad...@abc.idm.lab.eng.brq.redhat.com: user not found

Apparently there is a "user-show
ad...@abc.idm.lab.eng.brq.redhat.com"
call where a "user-show admin" call should be.

Fixed. python-gssapi has a display_as method that could pull the name
from it, but it doesn't work in current version, therefore using
partition to split on '@'

It's actually a bug in MIT Krb5, as we noted in your bug[0].  So this:

-        user = api.Command.user_show(unicode(principal[0]))['result']
+        user =
api.Command.user_show(principal.partition('@')[0])['result']

is working around a bug in specific Kerberos versions.  If people are
okay with merging such code, then I guess this is fine; I would
personally not do so because there is not a clear point at which it can
be removed.  At the very least, we should wait until we see what
versions of krb5 MIT is going to fix.

Otherwise, looks good.

[0]: https://github.com/pythongssapi/python-gssapi/issues/79


python-krbV migration is blocking support for Python 3. The bug
doesn't have any fix upstream yet and there are two bugs actually, the
second one is in python-gssapi, which I've just reported [1]. Waiting
for two bugs to be fixed could be detrimental to py3 migration as we
don't have much time left. And I'm no longer sure that display_as
I don't buy this.

We have plenty of time for solving these bugs. Remember, that Samba
DCE RPC bindings aren't migrated to Python 3 either and will not be
before release of Samba 4.4. For Samba 4.3 it is simply too late.

That is no no reason to delay our ability to start testing Python3
support in FreeIPA.
You can test that without deploying IPA as a part of a distribution.

Only trusts depend on Samba. Most of FreeIPA does not.
Just demonstrate via COPR repo that you can actually provide packages
this way and they do work.

Let me be clear: I don't want to see feature set crippled in Fedora
release because of Python 3 switch, for the sake of switching to Python
3 only. The work on migration can and should continue but not at an
expense of dropping off sizeable part of our functionality.

--
/ 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

Reply via email to