On 08/01/15 02:26, Konstantin Olchanski wrote:
On Wed, Jan 07, 2015 at 05:27:32PM -0700, Stephen John Smoogen wrote:
On 7 January 2015 at 17:06, Konstantin Olchanski olcha...@triumf.ca wrote:
[...snip...]
And I expect that you had at that point still stories from people saying
NIS broke everything when it went down and we should just use some homebrew
kit (or worse yet.. add each user by hand because lord how are you going to
know it got done.)
Yes, nis broke everything. But this went away since we install secondary
NIS servers
on every critical machine - as long as local ypserv and local ypbind stay up,
no problems with NIS, even survives network outages (alsmost, DNS outages
still cause problems).
Yes, add each user by hand, just happened on one of the systems I built,
because local admins cannot figure out NIS and because ypbind keeps dying
on that machine. Not that adding the user manually did any good, without
ypbind
they lose access to the auto-mounted home directory for that user.
And these things are *exactly* what IPA can provide an *easy* user
interface for. If you would really look at it, instead of shooting it
down. Local admins just need to run *one* *single* command as root
(ipa-client-install), and the system is configured and is ready for use.
This single commands configures everything and the options
ipa-client-install take shouldn't make you able to shoot yourself in the
foot, unless you really do it on purpose - and you would know in advance
that it would be stupid.
With this experience - people cannot figure out service ypbind restart
and vi /etc/auto.home; make -C /var/yp - I am not putting out anything as
complex as LDAP, Kerberos, Web based administration, etc.
If people can't figure out that ypbind needs to be started or manually
modify /etc/auto.home and updating it with a make command, then I'd say
NIS is too complex too. Then doing the single ipa-client-install *is*
simpler from their perspective.
You seem not to have grasped that IPA doesn't need users to understand
LDAP or Kerberos at all. IPA does all that for you, and all you need to
understand is to run ipa-client-install on the clients. And the IPA
admin provides a lot of safe-guards, helping you not doing anything stupid.
Since I deployed FreeIPA on two networks, I have only _once_ needed to
use an LDIF file to update the 389-DS configuration on the servers to
workaround a bug in the replication (which, btw, should be fixed in
newer upstream versions of 389-DS). And that is the only time I needed
to touch more lower-level LDAP pieces. And _not_ _once_ have I needed
to touch kadmin tools.
[...snip]
Yes, so true. And yet, in 10 years, no viable replacement, other than
the light weight 800 poud gorilla of identity management product.
Do you mean server or client side? On my server at home (HP Microserver
with AMD N54L! That's a fairly low performance CPU) the IPA server
(389DS, Kerberos daemons, Apache httpd) spends roughly 130MB of RAM
today. The SSSD daemon which clients needs uses something like 40MB.
And neither server nor client processes uses much CPU time. On todays
computers (even on embedded), the SSSD RAM usage won't be a problem.
Yes, it might be far more than your ypbind setup. But IPA provides a
far more robust and feature rich implementation with far better security
which is better suited for the 21th century.
As Stephen said earlier, it's your shop and you'll do it how you want it
on your site. But please stop spreading FUD about IPA being such
gigantic monster. Such FUD was what kept me away from IPA for far too
long, and I was incredibly surprised to see how easy it was to setup and
configure, and how little intrusive the setup really was. I instantly
regretted not having done this earlier.
Yes, the documentation suggests that IPA servers should provide DNS and
NTP services as well. Those are *optional*. In fact the default
installation of FreeIPA servers *does not* include DNS, you must add
--setup-dns to do get that. NTP can also be ignored by passing --no-ntp
to ipa-{client,server}-install. But, yes, it is *recommended* to
provide these services to your domain.
I tried the IPA DNS setup at home, where I already had my own BIND
server running. I decided to only try DNS on the sub-domain for IPA
clients. It took me less than a week before I had migrated the
complete DNS to IPA, because it just made my life so much easier -
despite I didn't have to do this at all. So now my old DNS server is
mostly a slave DNS to my IPA server instead - and the rest of my boxes
(even DHCP server) didn't need to be updated. At home, things are
definitely in a better state now than before.
For NTP, as long as the clocks on all boxes are in sync, there's really
no need to worry about that. But once clocks are more than 5 minutes
(IIRC) out of sync against the IPA server, authentication may fail. I
even think the time scew tolerance is configurable too.
--
