[Freeipa-devel] Design document: Integration Improvements

[Christian Heimes]

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

> 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20161111/88a6e350/attachment.sig>