A small domain may have a single LDAP server, and a few clients. The server commonly runs slapd, which will serve LDAP requests and update data. The client software is comprised of system libraries translating normal libc calls (gethostbynam, getpwuid via NameserviceSwitch) into LDAP data requests and providing some form up update functionality (i.e. password update via PAM). Larger domains may have several LDAP slaves (read-only replicas of a master read/write LDAP server). For large installations, the domain may be divided into subdomains, with refferals to 'glue' the subdomains together.
A simple LDAP domain is structured on the surface in a manner simmilar to an NIS domain; there are masters, slaves, and clients. The clients may query masters or slaves for information, but all updates must go to the masters. The 'domain name' under LDAP is slightly different than that under NIS (commonly the DNS domain, as registered by internic). LDAP domains may use an organization name and country, such as 'O=Acme Widgets,C=US', or a heirarchal domain format such as 'dc=acme,dc=com'.
The clients may or may not authenticate themselves to the server when performing operations, depending on the configuration of the client and the type of information requested. Commonly access to nonsensitve information (such as port to service mappings) will be unathenicated requests, while password information requests or any updates are authenticated.
Larger organizations may subdivde their LDAP domain into subdomains. LDAP allows for this type of scalability, and uses 'refferals' to allow the passing off of clients from one server to the next (the same method is used by slave servers to pass modification requests to the master). Thus 'dc=eng,dc=acme,dc=com' or 'OU=Engineering,O=Acme Widgets,C=US' may be subdomains in Acme Widgets' network.
First download and install your LDAP server of choice; for Linux this means installing the OpenLDAP server. The server is available in source or RPM format. After installing edit your /etc/slapd.conf file. You must change the organization name, the binddn, and password. You should then create some sort of database. If you are planning to use LDAP as a network information service, see the 'Populating the LDAP database' section below. Otherwise you will have to generate your own LDIF file and use ldif2ldbm to convert that file to the LDAP database format. Once you have data, you can start the database. If you used the RPM, do this by running '/etc/rc.d/init.d/ldap start', otherwise just running '/usr/sbin/slapd' should do the trick. You should check to see if your database is up. You can do this using the 'ldapsearch' command. Use "ldapsearch -b'YOUR_ORG_STRING' 'objectclass=*'" to see all of the objects in your database.
If your site has a large degree of LDAP traffic you may wish to set up more than one ldap server on the network. The UofM software provides a tool (slurpd) that performs this function.
First install the ldap servers on the replica machine. Once they have been installed edit your /etc/slapd.conf file. It should look like the basic config that came out of the box, with the appropriate changes to organization name, rootdn and password. Add a line with binddn="cn=replicator,o=SomeOrgName', which matches the replica entry your about to put in the master /etc/slapd.conf Also make sure your slave has a 'referral' line pointing to the master.
On the master you'll want to specify a replica log file (you only have to do this once, not for each replica). you would include a replogfile directive such as:
replogfile /var/ldap/replica.log
Now, for each replica host, you will have to add a replica line in the master's slapd.conf. The line specifies the host, the user to bind as, and the credentials to use. This should all be on one line (although its shown here on multiple lines for readability).
replica host=slavehostname binddn="cn=replicator,o=SomeOrgName" bindmethod=simple credentials=binddn_password
Now you will have to shutdown the database, then copy the original database files (found in your 'directory' setting). to the slave. Then start up slapd on both the master and the slave. Start slurpd on the Master. Slurpd should monitor changes on the master and propigate them to the slaves. You can check this by changing something on the master and doing the approprate lookup on the slave's LDAP server.
Another option for scaling your LDAP database is by using a hierarchal format. This may work well if you have a naturaly partitioned organization, such that different departments will each have their own LDAP server. The organization will still have a 'root' LDAP server, and this server will have referrals to the internal departments. For example, lets suppose you have a department called engineering, which you wish to partition from your root LDAP server. You would set up your Engineering LDAP server's suffix as: ou=Engineering,o=SomeOrgName". You would also set it up to referr clients to your root ldap server. On your root server, you would set up a referral in the database itself:
dn: ref="ldap://engineeringserver/ou=Engineering,o=SomeOrgName",\
ou=Engineering,o=SomeOrgName objectclass: referral
Thus any request the root server gets for engineering data will be reffered to the engineering server, and any requests the engineering server does not have data for will be reffered to the root server.