SCIENTIFIC-LINUX-USERS Archives

January 2015

SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
David Sommerseth <[log in to unmask]>
Reply To:
Date:
Thu, 8 Jan 2015 13:26:50 +0100
Content-Type:
text/plain
Parts/Attachments:
text/plain (98 lines)
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 <[log in to unmask]> 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.


-- 
kind regards,

David Sommerseth

ATOM RSS1 RSS2