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