September 1, 2004

SysAdmin to SysAdmin: NIS end-of-life and LDAP

Author: Brian Jones

Last week we talked about the challenges of replacing Red Hat Linux 9. This week we'll look at another instance of how changing infrastructure options challenge adminstrators. Sun, the inventor of Network Information Service, has announced the
end-of-life for NIS. This is a more heterogenous problem than the end of a single Linux distribution.

Almost none of us work in a 100% Linux
environment. We have EMC and NetApp appliances that authenticate users
in order to get access to the files stored on them. We have Cisco switches
and access points that authenticate users to get access to the network. We have
groupware applications, Web servers, and mail servers which need a whole host
of user information. Last but not least, we have Solaris, AIX, HP-UX, and
possibly other systems that need to authenticate users. All of these platforms work well with NIS. What happens now?

Sun is pushing LDAP as the replacement, but no two LDAP
clients are implemented the same way. Sun doesn't talk to an LDAP server like a
Linux machine does, or an AIX or HP-UX machine does for that matter. Every one
of these platforms has one issue or another. For Linux, nobody appears to have
written the client-side code to properly handle netgroups for all the things
you might use netgroups for. For Sun, there's no start_tls
implementation. NetApp just barely knows what LDAP is.

For simple servers, the best we can do is try to consolidate and move to one
operating system and squeeze everything we can out of it. This would at least provide us with
a single set of issues to deal with; one configuration to troubleshoot, which
is then applicable across most of the machine room. Which OS wins that
battle? Hint: it's probably not Sun. It's probably not a proprietary Unix,
period. But I digress.

The bottom line is we administrators, again, have a choice to make: Implement
an NIS server on another platform, or move to some other service. Since NIS+
is probably overkill and a gross increase in administrative overhead, this is
probably not what most of us will go with (not to mention that NIS+ is next on Sun's
chopping block). For those who can clearly see the writing on the wall, the
answer is "find an LDAP server that'll run on the platforms we're using, and
start figuring out how to get all of your systems and applications to play
nicely with it." But do you go with OpenLDAP, IBM SecureWay, Novell's
eDirectory, or Sun's SunONE directory server? There are others, too!

No implementation is perfect. Novell appears to assume that you're in a
NetWare environment, and that your user home directories are on NetWare
volumes. Reports I've received on SecureWay seem to indicate that there is a
notable decrease in performance when compared with almost any other solution,
as well as NIS. OpenLDAP suffers from a somewhat complex implementation, and a
cold-as-ice mailing list which makes getting through the learning curve
difficult. SunONE is a good LDAP implementation, but it's commercial, so
there's no support if your environment is using the free license, which
is good for something like 200,000 entries. Novell eDirectory has a similar
license, but the forum help at Novell is rather nice, and eDirectory runs
pretty well under Linux in my experience. What's an admin to do?

Personally, I went with OpenLDAP. OpenLDAP is a pretty rock-solid server
implementation. However, the various LDAP client implementations have
kept LDAP out of production for over a year now. LDAP touches pretty much
everything (ugh). Anything that needs a password needs to get it from LDAP, unless
you're gonna sync NIS and LDAP (double-ugh). For services that check group
memberships, user or host-based netgroup memberships, or that use tcp_wrappers,
configuration can be interesting.

Did you pick a different LDAP implementation? Are you sticking with NIS on a
different platform? Are you just gonna build it on Solaris using
third-party-packages? What has your experience been with the clients? Have you
moved to commercial versions of some client services in order to get the LDAP
integration you need? In some cases, moving to LDAP makes doing more with user
data easier. In other cases, it makes some things harder. Share your thoughts!

Click Here!