[Freeipa-users] hesitate to deploy freeipa

[Alexander Bokovoy]

On Mon, 29 Jun 2015, Harald Dunkel wrote:
>Hi Simo,
>
>On 06/25/15 17:47, Simo Sorce wrote:
>>
>> Harald,
>> the reason I (and others) started this project many years ago is that
>> trying to set up all components myself was boring and highly error
>> prone, and you would always end up with a bag of parts that had a lot of
>> mismatches, and some functionality was always missing or poor or
>> incomplete, due to the imperfect integration.
>>
>> Yes, the whole project is complex, but not because we like complexity,
>> it is complex because the problem space is complex and we are bound to
>> use existing protocols, which sometimes add in complexity, and we want
>> to offer useful features to admins, so they can think about managing
>> stuff and not about the plumbing all the time.
>>
>
>Sorry to say, but this part is not in yet. ipa-client-install is
>included in RedHat/Fedora/Centos. On Debian it is improving (meaning
>I have to backport it from Testing to Jessie and Wheezy and hope), but
>for my other Unixes (Solaris, AIX, Suse, all designed more than 5
>years ago) I have to do the plumbing on my own. Its a lot of work, but
>I can live with that.
One way to improve support for other operating systems is by
contributing. I'd certainly look forward to patches coming to support
these other clients.

>Missing client support is not the problem. The problem is that I do
>have a working environment (using NIS). NIS is deeply integrated
>everywhere for +20 years. I understand that NIS is not safe to use,
>but it is rock solid and *extremely* easy to manage and repair. If
>something goes wrong, then I can edit a file, run make -C /var/yp
>and its done.
>
>If something goes wrong with freeipa, then in the best case I have to
>find the bad component and fix it, as for NIS. Worst case is that
>2 or more components "disagree somehow". There would be several
>options to solve this:
>
>a) use low level component tools to manipulate their data, hoping to
>   not make incompatible changes breaking things in other components
>   of freeipa
>b) ask for help on the mailing list, which might imply a downtime of
>   several hours and then option a)
>
>Both options don't appear very attractive to me.
Do you have specific problems with slapi-nis support for NIS services?
Do you mind filing bugs with details?
https://fedorahosted.org/slapi-nis/ is where you should file those bugs.

>> The best option is to study the individual components and how they are
>> integrated,
>
>Thats the point: It is not sufficient to study the individual components.
>You have to know how they work together. For example, you have to know
>the constructs you should avoid in component A to make sure that you
>don't break other components of Freeipa.
This is not really different for other complex environments. What we are
trying with FreeIPA is to get defaults right for majority of cases where
people who don't know all details need to start quick and efficient,
including security aspects.

-- 
/ Alexander Bokovoy