Chapter 4 Client Setup
This chapter describes how to set up a Solaris client to use the LDAP name service.
Overview
When a Solaris client is made an LDAP client, it operates similar to a Solaris client using NIS/NIS+ or NFS. The client does hard lookups, which means the getXXbyYY() calls wait until they get a response. Normally NIS(YP) has its servers on the local subnet (as they are normally bound to using a broadcast). Since Solaris 2.0 it has been possible (but not often used) to enable the use of NIS(YP) servers off the local subnet (see the ypinit(1M) command) and of course NIS+ is routinely setup without local servers. LDAP is more like NIS+ in it's tendency to deploy non-local servers.
This means that the routers become essential in making your machine work.
You must make sure your clients can always reach at least one of your LDAP servers. Either by making sure your network is properly reliable (most are unless someone cuts the wire or turns off the power to the router) or by making sure a server is on the local subnet (although again even then with subnet no longer being a cable but twisted pairs going to a ethernet server, cutting the cable or the power has the same effect).
The best method to keep your clients operational is to make sure you have multiple servers, keep those servers up to date (so they have the same data) and make sure your clients can reach all of them. Obviously if you are using the server preference feature (to force your clients to bind to certain servers) you need to make sure they meet the same criterion.
Fully Qualified Domain Name
One big difference between an LDAP client and a NIS or NIS+ client is that it always returns a FQDN (fully qualified domain name) (similar to those returned by DNS). For example, if your domain name is engineering.example.net and you lookup the hostname server with getipnodebyname() (as they should in preparation for the conversion to IPv6 even though LDAP in this release only runs over IPv4). Both gethostbyname() and getipnodebyname() return the FQDN version server.engineering.example.net. Also if you use interface specific aliases like server-# you will see a long list of fully-qualified host names returned,
If you are using hostnames to share file systems or have other such checks you need to realize this key difference and account for it. Especially if you assume non-FQDN for local hosts and FQDN only for remote (DNS resolved) hosts. If you setup LDAP with a different domain name from DNS you might be surprised when the same host has two different FQDNs, depending on the lookup source.
ldap_cachemgr Daemon
The ldap_cachemgr(1M) is a daemon that runs on LDAP client machines. It refreshes the information in the configuration files from the LDAP server.
If ldap_cachemgr is not running, the configuration will not be updated.
Besides providing the refresh capability, the ldap_cachemgr provides a robust parsing mechanism that can flag any invalid syntax in the update query.
NIS/NIS+ to LDAP Transition
If you have upgraded a machine to SunOS 5.8 (Solaris 8) that was a NIS/NIS+ client and want to make it an LDAP client, run ldapclient(1M).
To run ldapclient you need to know the profile name and the IP address of at least one server. In the following example the profile name is myprofile and the LDAP server is at IP address 100.100.100.100 that runs on the default LDAP port number of 389.
Create an LDAP Client
-
Become super user.
-
# ldapclient -P myprofile 100.100.100.100
ldapclient creates the configuration files and configures the client to use LDAP for name service lookups by modifying the /etc/nsswitch.conf file.
-
Reboot the client.
login to authenticate using ldap.
ldaplist Command
ldaplist is an LDAP utility to list the naming information from the LDAP servers. See ldaplist(1) for more info.
List the Naming Information from the LDAP Servers
- © 2010, Oracle Corporation and/or its affiliates