On 21.11.2016 10:32, Christian Heimes wrote:
On 2016-11-21 10:26, Jan Cholasta wrote:
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:
I have released the first version of a new design document. It
how I'm going to improve integration of FreeIPA's client libraries
(ipalib, ipapython, ipaclient, ipaplatform) for third party developers.
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
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"
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
do you support FreeIPA on Debian variants with SysV init?
This is not an issue of what is supported now, but rather what is
supportable in the future. Even if Debian with SysV init is not
supported ATM, someone might want to add support for it in the future,
and the design should not prevent them from doing so.
Manage your subscription for the Freeipa-devel mailing list:
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code