LDAP as a replacement for NIS

1
LDAP as a replacement for NIS

• Wolfgang Friebel
• DESY Zeuthen

2
Contents

• Motivation
• The LDAP server
• The LDAP client
• Maintaining the system
• Performance tuning
• Experiences

3
Why LDAP as a NIS replacement?

• Central maintenance of UNIX accounts and groups,
  hosts, ... In addition to or as replacement of
  maintenance local to a machine made NIS a
  successful concept
• Netgroups can be used to structure accounts,
  hosts etc.
• Example netgroup linux contains linux hosts, l3
  contains l3 users
• NIS is one of the more frequent causes for
  instability under Linux
• fallback to other NIS masters sometimes fails
  when ypserv crashes
• varying temporary problems (timeout etc.) in
  daily use
• Modification of NIS contents only locally on
  master
• LDAP allows modification from remote sites after
  authentication
• LDAP is better suited for integration with other
  services than NIS
• Hope for a more scalable and less resource
  intense service

4
LDAP Server Installation

• Any server should work, but we tested only
  OpenLDAP
• We installed OpenLDAP 2.0.7
• LDAP version 3 protocol
• Backend Database Berkeley DB (Sleepycat Version 3
  recommended)
• For NIS functionality authorization required for
  content updates only
• all queries done unauthenticated
• Compiled on a Linux SuSE 6.3 system
• successful tests also with OpenLDAP 1.x on
  Solaris 2.6
• precompiled RPM's should be o.k. as well
• Make sure you use recent versions of OpenLDAP and
  Berkeley DB

5
LDAP Server Configuration (OpenLDAP)

• Specify proper backend, define subtree and
  directory for that tree
• database ldbm
• suffix "dcIFH, dcDE"
• directory /var/openldap/db/nis
• Define columns to be indexed (very important for
  performance)
• index cn,sn,uid,givenname pres,eq,sub
• index objectclass pres,eq
• index uidNumber,gidNumber,memberUid eq
• index oncRpcNumber,ipServicePort eq
• index ipNetworkNumber,ipHostNumber eq
• Too few indexes reduce search performance
• Too much indexes reduce write performance

6
Population of LDAP Server with data

• Loading of data relevant for NIS usually done
  with MigrationTools from http//www.padl.com
  (current version is 37 or above)
• collection of shell and perl scripts for
  populating a running server or for creation of
  ldif files, that can be loaded later using
  ldapadd
• only support for initial loading of LDAP server,
  no tools provided for modification of LDAP server
  contents afterwards (can be done with commandline
  tool ldapmodify or graphical LDAP frontends)
• Loading of data with tool ldapsync developed at
  DESY Zeuthen (ftp//ftp.ifh.de/pub/unix/networking
  /ldapsync) more flexible
• does almost precisely what MigrationTools-37
  would do (single script)
• produces ldif data (running unauthenticated) or
  otherwise updates server
• can be applied several times, resyncs LDAP and
  NIS information
• allows for longer migration period from NIS to
  LDAP

7
ldapsync

• Still in test phase
• works at DESY, but untested at other sites
• configuration info is partly still contained in
  script, i.e. to adapt the script to other sites a
  change of source code might be required
• update process scales only to a few thousand
  items contained in LDAP due to principal
  limitations of LDAP (no directory browsing !!!).
  Could be changed, but then ldapsync has to run
  locally on LDAP server host
• still room for optimization

8
Verifying the LDAP server installation

• Do queries that are relevant for the NIS
  functionality
• ldapsearch -h ldap.ifh.de -x -b "dcifh,dcde" -s
  base
• dn dcifh,dcde
• objectClass domain
• objectClass top
• objectClass domainRelatedObject
• dc ifh
• associatedDomain ifh.de
• ldapsearch -h ldap.ifh.de -x -b "dcifh,dcde"
  "uidfriebel"
• dn uidfriebel,ouPeople,dcifh,dcde
• uid friebel
• cn Wolfgang Friebel
• uidNumber ...

9
LDAP Client installation

• The LDAP Client requires the nsswitch mechanism
• contained at least in Linux and Solaris
• nsswitch.conf determines the method to fetch data
  (nis, ldap, file)
• libnss_xxx.so provides the functionality for
  method xxx
• vendors usually provide libnss_ldap.so
• Source code to build a libnss_ldap.so library is
  available from http//www.padl.com (current
  version 150 or higher)
• works at least for Linux and Solaris
• we installed libnss_ldap.so from source (version
  149)
• recommended, as it might fix bugs that come with
  the vendor version
• DESY Hamburg experiments with vendor supplied
  mechanisms on Solaris 2.8 and IRIX 6.5 (does
  work, little experience up to now)

10
LDAP Client configuration

• The client requires the proper /etc/nsswitch.conf
• we installed nsswitch.ldap and moved
  nsswitch.conf to nsswitch.nis
• then we have a symlink nsswitch.conf to switch
  between NIS and LDAP
• Our nsswitch.ldap contains (some entries left
  out)
• passwd compat ldap
• group files ldap
• hosts files dns ldap
• services files ldap
• netgroup files nis
• The library libnss_ldap needs additional info in
  /etc/ldap.conf
• OpenLDAP clients expect the file in
  /etc/openldap, therefore symlink it
• ldap.conf contains info on ldap servers, ldap
  version etc.
• specifying more than one server makes the
  mechanism (more) failsafe

11
Our /etc/ldap.conf

• ldap.ifh.de ldap2.ifh.de
• host 141.34.1.149 141.34.27.20
• The distinguished name of the search base.
• base dcifh,dcde
• The LDAP version to use (defaults to 2)
• ldap_version 3

12
Testing the LDAP client

• Activate the proper nsswitch.conf
• For testing purposes shut down the name service
  cache daemon nscd
• Issue commands that do name resolution
• ls -l
• id
• if protocols and services are resolved by LDAP do
  further tests (ping, ...)
• The output should contain names, not numbers for
  user, group etc.
• you can modify nsswitch.conf temporarily to force
  LDAP name resolution
• Watch the activity on the LDAP server if possible

13
Maintaining the system

• More than one LDAP server should be available
• Do replication of the directory tree
• setting up slurpd that propagates changes from
  the master server to replica server
• advantages consistency of data, use standard
  methods
• disadvantage still single point of failure - no
  updates, if master is down
• using multiple master servers and keep them in
  sync
• advantages updates of data can be done as long
  as at least one server is up
• disadvantages additional mechanisms required to
  enforce data consistency
• Maintenance software has to be integrated with
  LDAP
• enhance your tools to also update the LDAP tree
  (ldapadd, ldapmodify, ..)
• or
• use ldapsync to maintain NIS as before and
  synchronize with LDAP

14
Performance tuning

• Choice of platform and software influences
  performance
• after initial tests with Solaris and LDAP v2
  switched to Linux and v3
• easy access to fast PC's with large memory at
  DESY
• impression from reading the mailing list Linux
  is less problematic
• Watch your server for resource usage
• server forks additional processes for listening
• server becomes slow when doing a lot of
  syslogging (especially on Linux), therefore we
  started slapd with -s 0
• Ensure that proper indexes requested and really
  been built
• see also man slapindex
• Make sure the name service caching daemon nscd is
  running

15
Experiences

• Migration can be done without rebooting
• ldconfig might be required however
• if done with running nscd then LDAP lookups will
  not occur instantly
• User does not notice change from NIS to LDAP
• initially we had some problems due to missing
  entries in services and using "files ldap"
  instead of "compat ldap" in passwd resolution
• As stated in the NEWS of the nss_ldap library
  netgroup name resolution is still missing, but
  "This is a lot easier now ..."(to write)
• until this is done either rely on NIS for
  netgroups or use /etc/netgroups
• Some programs need recompilation (if linked
  against LDAP1.xx)
• httpd(SuSE 6.3), maybe pine

16
Integration with Windows

• Active directory could be used in principle to
  host the name service information, then a
  separate LDAP server would not be needed
• To store the relevant data the scheme definitions
  need to be known to active directory.
• Procedure for adding a new scheme fairly
  complicated
• attributes and classes with the same name may
  have different definitions
• attributes and classes with different names may
  mean the same
• not managed to do this first step up to now
• Given the above complications integrating LDAP
  for NIS with the Active directory seems not to be
  of advantage

17
Statistics

• Primary LDAP server is on a 233Mhz Intel PIII
  machine running SuSE6.3 and kernel 2.2.18, a
  second server is also running
• 85 Linux clients with LDAP use presently our
  primary server
• load can be neglected (typically around 0.01)
• total CPU time accumulated by slapd processes
  about 2 minutes/day (40 minutes during 20
  days)
• on average about 250 -300 established LDAP
  connections are served from up to 36 server
  processes simultaneously.
• No difference in application speed as compared to
  NIS seen
• ls -ld /afs/ifh.de/user// took about 1.5s
  (around 1200 name lookups, both for NIS and LDAP
  with running nscd)
• Very preliminary tests with Ultra1 Solaris
  machine in Hamburg were less promising

18
Outlook

• We will continue to migrate from NIS to LDAP
• 30 new clients added last week without any
  complications
• could switch all Linux machines instantly (except
  web server), but we will look first for long term
  effects (months) before a full migration
• Further services can make use of this LDAP
  branch, we will investigate whether this has
  advantages for us
• mail aliases for mail server
• automounter maps
• Some day we will need to integrate the
  maintenance of the NIS data in LDAP into a
  central tool (that is not yet existing)