[Freeipa-devel] [PATCHES] 0191-0195 Use ipaldap in the client installer & password migration

Rob Crittenden rcritten at redhat.com
Thu Mar 7 18:28:54 UTC 2013


Petr Viktorin wrote:
> On 03/07/2013 06:01 PM, Rob Crittenden wrote:
>> Jan Cholasta wrote:
>>> On 6.3.2013 16:29, Petr Viktorin wrote:
>>>> Hello,
>>>> These patches move ipaldap to ipapython, and make the client installer
>>>> use it. Also password migration web-app is made to use ipaldap; they
>>>> both called a shared a utility function that is converted to use
>>>> ipaldap.
>>>>
>>>> This should fix https://fedorahosted.org/freeipa/ticket/3446
>>>> (freeipa-client-install KeyError in 'namingcontexts') and similar
>>>> errors.
>>>>
>>>> https://fedorahosted.org/freeipa/ticket/3487
>>>>
>>>
>>> Patch 191:
>>>
>>> The patch is missing the ipapython/ipaldap.py file.
>
> It's there, it's just copied from ipaserver/ipaldap.py with a small
> change at the bottom.
>
> I'll respond to the other comments tomorrow.
>
>>>
>>> I think it should go into ipalib instead of ipapython. <rant> It doesn't
>>> make sense to keep ipapython and ipalib separate if they depend on each
>>> other. We should either merge them or clean up the mess by removing
>>> ipalib imports from ipapython. I'm not saying we should do it now, just
>>> please don't add new modules to ipapython which import from ipalib.
>>> </rant>
>>
>> There have been platforms in the past that we do not ship the framework
>> on (e.g. RHEL 5). ipapython is supposed to be platform agnostic, though
>> it clearly isn't, to allow a bridge for those systems that can't or
>> won't have the framework. So I think removing the imports from ipapython
>> is the way to go.
>>
>
> Then we need to move errors and text to ipapython, those need to be
> imported pretty much everywhere.

Yup, that too is a bit of a violation, at least for errors as we really 
want to publish those as part of the framework. This is why I didn't 
raise a fuss when we starting doing minor mixing of things (and I really 
felt the pain when trying to do certain things in RHEL 5).

The client is now using more and more from the framework (SSH uploads, 
for example). So maybe it is time to revisit how we package things.

If we decide to go whole hog and merge ipapython and ipalib I think 
there'd be no going back. We'd have to carefully consider all the 
consequences. I tend to be rather conservative in this regard, but 
perhaps I'm just living in the past.

rob




More information about the Freeipa-devel mailing list