Naming and Directory Services (DNS, NIS, and LDAP)
Naming and Directory Services (DNS, NIS, and LDAP)
Naming and Directory Services (DNS, NIS, and LDAP)
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
SolarisAttrReserved1=, \SolarisAttrReserved2=, \SolarisAttrKeyValue=Again, the user_attr.org_dir data shares the ou=People container with otheraccount information (from the passwd.org_dir <strong>and</strong> other tables). If an entry in theuser_attr.org_dir table is deleted, you probably do not want to delete the entireou=People entry. Instead, the delete entry above says that when auser_attr.org_dir entry is deleted, the SolarisUserQualifier,SolarisAttrReserved1, SolarisAttrReserved2, <strong>and</strong> SolarisAttrKeyValueattributes (if any) are deleted from the ou=People entry specified by the followingrule.dn=("uid=%s,", name)The rest of the <strong>LDAP</strong> entry is left unchanged.<strong>NIS</strong>+ to <strong>LDAP</strong> Migration ScenariosLikely scenarios for a migration from <strong>NIS</strong>+ to <strong>LDAP</strong> include the following.■■■Convert all <strong>NIS</strong>+ clients to <strong>LDAP</strong> in one operation. You can use the rpc.nisddaemon to upload any <strong>NIS</strong>+ data that does not yet exist in <strong>LDAP</strong>. See “How toConvert All <strong>NIS</strong>+ Data to <strong>LDAP</strong> in One Operation” on page 265.Do a gradual migration from <strong>NIS</strong>+ to <strong>LDAP</strong>. Start by converting <strong>NIS</strong>+ data to <strong>LDAP</strong>(see “How to Convert All <strong>NIS</strong>+ Data to <strong>LDAP</strong> in One Operation” on page 265). Youcould have both <strong>NIS</strong>+ <strong>and</strong> <strong>LDAP</strong> clients sharing the same naming service data, <strong>and</strong>let the rpc.nisd automatically keep <strong>NIS</strong>+ <strong>and</strong> <strong>LDAP</strong> data synchronized. Initially,perhaps, <strong>NIS</strong>+ would be authoritative, <strong>and</strong> the <strong>LDAP</strong> server(s) would maintain aduplicate of the <strong>NIS</strong>+ data for the benefit of <strong>LDAP</strong> clients. At a convenient time,<strong>LDAP</strong> can become the authoritative naming service, <strong>and</strong> <strong>NIS</strong>+ service graduallyphased out, until there are no more <strong>NIS</strong>+ clients.<strong>LDAP</strong> is already used as a naming service, so you need to merge the <strong>NIS</strong>+ <strong>and</strong><strong>LDAP</strong> data. There are three possible ways to perform this merge.■■■Add the <strong>NIS</strong>+ data to <strong>LDAP</strong>. Entries that exist in <strong>NIS</strong>+, but not in <strong>LDAP</strong>, areadded to <strong>LDAP</strong>. Entries that appear both in <strong>NIS</strong>+ <strong>and</strong> <strong>LDAP</strong>, but with differentdata, end up with the <strong>NIS</strong>+ data. See “How to Convert All <strong>NIS</strong>+ Data to <strong>LDAP</strong>in One Operation” on page 265.Overwrite the <strong>NIS</strong>+ data with the <strong>LDAP</strong> data. If there are entries that exist in <strong>NIS</strong>+but not in <strong>LDAP</strong>, they will disappear from <strong>NIS</strong>+. Entries that exist both in <strong>NIS</strong>+<strong>and</strong> <strong>LDAP</strong> end up with the <strong>LDAP</strong> data. See “How to Convert All <strong>LDAP</strong> Data to<strong>NIS</strong>+ in One Operation” on page 265.Merge <strong>NIS</strong>+ <strong>and</strong> <strong>LDAP</strong> data, resolving conflicts on an individual basis. See “Merging<strong>NIS</strong>+ <strong>and</strong> <strong>LDAP</strong> Data” on page 265.264 System Administration Guide: <strong>Naming</strong> <strong>and</strong> <strong>Directory</strong> <strong>Services</strong> (<strong>DNS</strong>, <strong>NIS</strong>, <strong>and</strong> <strong>LDAP</strong>) • January 2005
Change language