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