Skip Navigation Links | |
Exit Print View | |
System Administration Guide: Naming and Directory Services (DNS, NIS, and LDAP) |
Part I About Naming and Directory Services
1. Naming and Directory Services (Overview)
2. The Name Service Switch (Overview)
Part II DNS Setup and Administration
3. DNS Setup and Administration (Reference)
Part III NIS Setup and Administration
4. Network Information Service (NIS) (Overview)
5. Setting Up and Configuring NIS Service
Part IV LDAP Naming Services Setup and Administration
8. Introduction to LDAP Naming Services (Overview/Reference)
9. LDAP Basic Components and Concepts (Overview)
10. Planning Requirements for LDAP Naming Services (Tasks)
11. Setting Up Sun Java System Directory Server With LDAP Clients (Tasks)
12. Setting Up LDAP Clients (Tasks)
13. LDAP Troubleshooting (Reference)
14. LDAP General Reference (Reference)
15. Transitioning From NIS to LDAP (Overview/Tasks)
16. Transitioning From NIS+ to LDAP
NIS+ to LDAP Tools and the Service Management Facility
When Not to Use SMF With NIS+ to LDAP
Modifying the /lib/svc/method/nisplus File
Creating Attributes and Object Classes
Getting Started With the NIS+ to LDAP Transition
Default Location in LDAP and NIS+
Timeout/Size Limits and Referral Action for LDAP Communication
General LDAP Operation Control
nisplusLDAPdatabaseIdMapping Attribute
nisplusLDAPattributeFromColumn Attribute
nisplusLDAPcolumnFromAttribute Attribute
NIS+ to LDAP Migration Scenarios
How to Convert All NIS+ Data to LDAP in One Operation
How to Convert All LDAP Data to NIS+ in One Operation
How to Merge NIS+ and LDAP Data
The Directory Server (NIS+ to LDAP)
Configuring the Sun Java System Directory Server
Assigning Server Address and Port Number
Mapping NIS+ Objects Other Than Table Entries
NIS+ Entry Owner, Group, Access, and TTL
How to Store Additional Entry Attributes in LDAP
Principal Names and Netnames (NIS+ to LDAP)
client_info and timezone Tables (NIS+ to LDAP)
client_info Attributes and Object Class
timezone Attributes and Object Class
Adding New Object Mappings (NIS+ to LDAP)
Storing Configuration Information in LDAP
A. Solaris 10 Software Updates to DNS, NIS, and LDAP
Only NIS+ masters are allowed to write data to LDAP. NIS+ replicas can obtain updates either from the NIS+ master (which might or might not have obtained it from LDAP), or they can read data directly from an LDAP server. A combination of the two is also possible. Therefore, there are two principal ways to arrange for NIS+ replication.
Leave NIS+ replicas unchanged, and let them obtain their data updates from the NIS+ master.
This arrangement has the advantage of configurational simplicity (only the NIS+ master need have a connection to an LDAP server), and also maintains the old replication relationship (master knows about new data first, replicas later). It is probably the most convenient solution while NIS+ remains authoritative for naming service data. However, it also lengthens the path between LDAP and NIS+ replica servers.
Let NIS+ replicas obtain their data directly from LDAP instead of from the NIS+ master.
In this case, replicas could have updated data before or after the NIS+ master, depending on lookup traffic and TTLs for data derived from LDAP. This arrangement is more complicated, but can be convenient when LDAP is the authoritative naming services repository, and few or no updates are made directly to NIS+ data.
When an NIS+ replica is obtaining data for at least one object in a particular NIS+ directory from LDAP, the update timestamps printed by nisping(1M) do not necessarily indicate the degree of data consistency between the NIS+ master and the replica. For example, assume that the NIS+ directory dir1 contains the tables table1 and table2. When the replica is obtaining data for both table1 and table2 from the NIS+ master, you might see an output like the following.
# nisping dir1
Master server is "master.some.domain." Last update occurred at Mon Aug 5 22:11:09 2002 Replica server is "replica.some.domain." Last Update seen was Mon Aug 5 22:11:09 2002
The above indicates that the master and replica have exactly the same data. However, if the replica is getting data for either or both of table1 and table2 from LDAP, the output only shows that the replica has received an NIS_PING from the master, and updated its resynchronization time stamp for housekeeping purposes. The data in the table or tables mapped from LDAP might differ from that on the NIS+ master if either of the following are true.
The LDAP data differs from that on the NIS+ master.
The replica has data in its cache (its local version of the NIS+ database) that has not expired, but that is not up to date with LDAP.
If you cannot accept this type of data inconsistency, let all NIS+ replicas obtain their data from the NIS+ master only. Once you have configured the NIS+ master to get data from LDAP, you do not need to make modifications to the replicas.