On Mon, 29 Jun 2015, Harald Dunkel wrote:
On 06/25/15 17:47, Simo Sorce wrote:
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
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
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
Manage your subscription for the Freeipa-users mailing list:
Go to http://freeipa.org for more info on the project