Naming and Directory Services (DNS, NIS, and LDAP)
13.07.2015 • Views
Share Embed Flag

Naming and Directory Services (DNS, NIS, and LDAP)

Naming and Directory Services (DNS, NIS, and LDAP)

Naming and Directory Services (DNS, NIS, and LDAP)

SHOW MORE
SHOW LESS
ePAPER READ
DOWNLOAD ePAPER
menehune.opt.wfu.edu

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

START NOW

11. (Optional) Modify the /lib/svc/method/nisplus file as needed.■If the rpc.nisd daemon uses the <strong>LDAP</strong> repository, specify an appropriatemapping file with the -m mappingfile option, if the default/var/yp/<strong>NIS</strong>+<strong>LDAP</strong>mapping file is not used.■ If the rpc.nisd daemon provides <strong>NIS</strong> (YP) emulation, specify the -Y optionby using svcprop or by modifying the /lib/svc/method/nisplus file .See “<strong>NIS</strong>+ to <strong>LDAP</strong> Tools <strong>and</strong> the Service Management Facility” on page 253 formore information.12. Start the <strong>NIS</strong>+ service.# svcadm enable network/rpc/nisplus:defaultMasters <strong>and</strong> Replicas (<strong>NIS</strong>+ to <strong>LDAP</strong>)Only <strong>NIS</strong>+ masters are allowed to write data to <strong>LDAP</strong>. <strong>NIS</strong>+ replicas can obtainupdates either from the <strong>NIS</strong>+ master (which might or might not have obtained it from<strong>LDAP</strong>), or they can read data directly from an <strong>LDAP</strong> server. A combination of the twois also possible. Therefore, there are two principal ways to arrange for <strong>NIS</strong>+replication.■■Leave <strong>NIS</strong>+ replicas unchanged, <strong>and</strong> let them obtain their data updates from the <strong>NIS</strong>+master.This arrangement has the advantage of configurational simplicity (only the <strong>NIS</strong>+master need have a connection to an <strong>LDAP</strong> server), <strong>and</strong> also maintains the oldreplication relationship (master knows about new data first, replicas later). It isprobably the most convenient solution while <strong>NIS</strong>+ remains authoritative fornaming service data. However, it also lengthens the path between <strong>LDAP</strong> <strong>and</strong> <strong>NIS</strong>+replica servers.Let <strong>NIS</strong>+ replicas obtain their data directly from <strong>LDAP</strong> instead of from the <strong>NIS</strong>+ master.In this case, replicas could have updated data before or after the <strong>NIS</strong>+ master,depending on lookup traffic <strong>and</strong> TTLs for data derived from <strong>LDAP</strong>. Thisarrangement is more complicated, but can be convenient when <strong>LDAP</strong> is theauthoritative naming services repository, <strong>and</strong> few or no updates are made directlyto <strong>NIS</strong>+ data.Replication TimestampsWhen an <strong>NIS</strong>+ replica is obtaining data for at least one object in a particular <strong>NIS</strong>+directory from <strong>LDAP</strong>, the update timestamps printed by nisping(1M) do notnecessarily indicate the degree of data consistency between the <strong>NIS</strong>+ master <strong>and</strong> the268 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

logo

products

Resources

Company

Terms of service
Privacy policy
Cookie policy
Cookie settings
Imprint
Change language
Made with love in Switzerland
© 2024 Yumpu.com all rights reserved

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!