> leery of depending on it so much. (Example: I've been bitten by > mismatches in MTU settings that have left LDAP clients hanging and > unable to realize that they should fail over to a backup server.) > > At my current job, I use LDAP. I've got a room full of servers, most > > But even with that redundancy, I've got into the habit of setting up > really important servers so that they're *not* LDAP clients. My > > The tradeoff is that I ensure my account shows up using other means
I, too, have had bad luck with LDAP failing over. The config I use now has been utterly rock solid. Machines participate in Kerberos for authentication against AD, and use NIS for uid/gid mappings. Both AD/Kerberos and NIS do an excellent job of failing over. The worst we have ever seen is a little bit of slowness when the primary AD server is shutdown or rebooted. It is worth mention, there's some hassle needing to create user accounts in both AD and NIS. You could easily enough solve that if you use NIS services inside of AD, but their implementation has some limitations that may or may not be important to you. Such as the fact that you can't have a group name matching a username. That being said, we also have a secure private network, so I'm always able to ssh as root. If you don't have that luxury, I would suggest creating a standardized local user account, something like "localadmin" which isn't easily guessed, but has sudo permissions. That way you're assured you can always login regardless of network authentication. _______________________________________________ Tech mailing list [email protected] http://lopsa.org/cgi-bin/mailman/listinfo/tech This list provided by the League of Professional System Administrators http://lopsa.org/
