[Freeipa-devel] Design document: Integration Improvements

[Jan Cholasta]

On 11.11.2016 18:28, Christian Heimes wrote:
> On 2016-11-11 17:46, 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?
>
> I don't use /etc/releases but /etc/os-release. There is no mapping
> involved. If a distribution has no /etc/os-release or a messed up
> /etc/os-release, then it needs to be fixed by the distribution. It's a
> common standard and all relevant distributions support this standard.
>
> RHEL has ID=rhel and no ID_LIKE -> ipaplatform.rhel
>
> Fedora has ID=fedora and no ID_LIKE -> ipaplatform.fedora
>
> CentOS has ID=centos and ID_LIKE="rhel fedora"
> -> ipaplatform.rhel
>
> Even my Raspberry has an /etc/os-release with ID=raspbian and
> ID_LIKE=debian -> error, soon ipaplatform.debian

There is more to ipaplatform than /etc/os-release offers. How do you 
differentiate between e.g. "Debian with SysV init" and "Debian with 
systemd"?

>
>> 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?
>
> My proposal does not affect distribution packaging (rpm, deb) at all. It
> is purely about Python packaging.
>
> The client installer and client CLI code are already separated. The
> Python wheels will only contain what 'python setup.py bdist_wheel' spits
> out for ipaclient, ipalib, ipaplatform and ipapython. The 'ipa' CLI is
> part of the ipaclient Python package.
>
>> 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
>
> For Ansible, testing etc. I need an arbitrary amount of config
> *directories* and full control. I don't like the idea that the current
> working directory affects how commands work. It has too many security
> implications, e.g. we have to verify that the file belongs to the
> current user. The check must be TOCTOU safe, too. Env vars are easier to
> control, more secure and less fragile.
>
> Christian
>
>
>


-- 
Jan Cholasta