[Freeipa-devel] [PATCH] 4 (1) ipa-client-install complains about non-existing nss_ldap

Alexander Bokovoy abokovoy at redhat.com
Tue Jul 19 13:36:45 UTC 2011


On 06.07.2011 17:26, Rob Crittenden wrote:
>>>>> ipa-client-install should be usable on non-RH platforms (see
>>>>> https://fedorahosted.org/freeipa/ticket/1374), so you shouldn't use
>>>>> /bin/rpm, as that's platform-specific. Wouldn't just rephrasing the
>>>>> warning message (as suggested in the ticket) be sufficient?
>>>> If you want to support non-rpm-based platforms, you'll need to do much
>>>> greater work than not depend on rpm. For example, /sbin/service and
>>>> chkconfig might not be there.
>>>
>>> I'm not sure adding even more complexity is helpful, especially when
>>> it's used just to print a warning message. But I'd like a second opinion
>>> on this.
>>
>> I think it is time we start renaming ipautil.py to ipautil-rh.py and do
>> ourselves, or invite someone to write ipautil-debian.py, then have code
>> that loads the right module at runtime.
>>
>> Simo.
>>
> 
> I believe that nss-pam-ldapd uses a different configuration file than
> nss_ldap, I think I'd rather use the existence of that to determine what
> is being used. Calling out to rpm seems heavy-weight.
In continuation of the same story, ticket 1368 asks for propagating
hostname into static configuration (/etc/sysconfig/network, HOSTNAME
variable on Red Hat systems). This is an example of system-specific
common code where we want to ensure configuration is made and backed up
but we don't care what is configuration's location and format. I.e.
perfect example to write platform-specific support.

I'm going to rework ipautil into providing common functions and loading
platform-specific ones from separate files so that we can have Red Hat
or Fedora (or LSB) platforms, Debian-based platforms and so on. Remeber,
this is for ipa-client-install so some flexibility is welcomed here.

I'll try to avoid using package management tools in such
platform-specific code as much as possible also to avoid lock conflicts
(if something is being installed in background you might get locked when
asking a package database).

We don't need to do platform detection at runtime as that is could be
deferred to package maintainers. After all, IPA most likely will be
packaged and ipa-client-install will come from such a package. Thus,
providing proper ipautil-system.py file can be done as packaging effort.

-- 
/ Alexander Bokovoy




More information about the Freeipa-devel mailing list