[Freeipa-devel] Design document: Integration Improvements

Rob Crittenden rcritten at redhat.com
Fri Nov 11 17:33:37 UTC 2016


Martin Basti wrote:
> 
> 
> On 11.11.2016 15:25, Christian Heimes wrote:
>> Hello,
>>
>> I have released the first version of a new design document. It describes
>> how I'm going to improve integration of FreeIPA's client libraries
>> (ipalib, ipapython, ipaclient, ipaplatform) for third party developers.
>>
>> http://www.freeipa.org/page/V4/Integration_Improvements
>>
>> Regards,
>> Christian
>>
>>
>>
> 
> Hello, I have a few questions:
> 
> 1) dynamic platform files
> 
> Currently all RHEL/fedora-derived platforms work with the same
> rhel/fedora packages. How do you want to achieve this with dynamic
> platform files, do you want to keep mappings between platforms and
> platform file? What about distributions that have in /etc/release just mess?

He is proposing using /etc/os-release which is a more structured file.

I don't think he's proposing a mapping so much as walking through the ID
and ID_LIKE values to find a match. It is unclear what would happen in
the case no match was found.

On CentOS it looks like:

ID="centos"
ID_LIKE="rhel fedora"

So it would try to open the centos platform file and fail, then the rhel
platform file and succeed and then proceed with initialization.

> 2) if I understand correctly, you want to separate client installer code
> and client CLI code. In past we had freeipa-admintools but it was
> removed because it was really tightly bounded to installed client. Do
> you want to revive it and make it independent?

The admintools package consisted only of the ipa command so I don't see
the relevance.

This should have no impact on the installers. I think the only proposal
is to ignore the IPA_CONFDIR variable in all installer contexts. I think
I'd prefer it if it were simply wiped from the environment on startup of
*install commands prior to bootstrap so it can't leak it at all.

> 3) why instead of environ variable we cannot have specified paths with
> priority where IPA config can be located?
> For example:
> 1) ./.ipa.conf
> 2) ~/.ipa.conf
> 3) /etc/ipa/default.conf  <-- as last resort

Because it's not flexible enough. Just consider all the places that
KRB5_CONFIG is used and imagine having only a few, fixed places to use
instead. An environment variable is a standard way of configuring a
library, which for all intents and purposes ipalib/ipapython are.

rob




More information about the Freeipa-devel mailing list