今天，幾乎所有的UN*X都包括NIS，而且甚至有它的免費實現版本。壹個是來自BSD的Net-2發行版，源自於Sun捐贈的公眾域參考實現。該版的客戶庫代碼已經存在於GNU的libc中很長時間了，而管理程序只是在最近才由Swen Thümmler [1] 移植到Linux上。在這個參考實現中漏掉了壹個NIS服務器程序。Tobias Reber已經編制出了另外壹個NIS軟件包，其中包括所有的工具和壹個服務器；該軟件包稱作yps。[2]
目前，壹個完全重寫的稱為NYS的NIS代碼已由Peter Eriksson [3]編制出來，它支持普通的NIS和Sun的經過許多修正的NIS+。NYS不僅提供了壹個NIS工具集和壹個服務器，而且還增加了壹個全新的庫函數集，這個庫函數集可能最終會被加入到標準libc中。這包括替換目前使用host.conf的主機名解析的壹個新設置方案。這些函數的特性將在下面討論。
這壹章將集中討論NYS而非另外兩個軟件包，對於這兩個軟件包我將稱它們為“傳統的”NIS代碼。如果妳確實要想運行任何這些軟件包的話，本章中的說明也許已經足夠也許還不夠。要獲取另外的信息，請取得壹本有關NIS的標準（權威）書本，比如象Hal Stern的NFS和NIS（見[Stern92]）。
目前，NYS仍處於開發階段，因此標準的Linux工具如網絡程序或login程序還沒有註意到NYS的配置方案。只有到NYS合並進主流libc中時，如果妳想使得所有這些執行程序使用NYS時，妳才需要重新編譯它們。在任何這些應用程序的Makefiles中，在libc之前，指定-lnsl作為 linker的最後壹個選項。這將有關函數從libnsl—NYS庫中連接過來，取代從標準C庫的連接。
10.1 理解NIS
NIS在所謂的包含鍵-值對的maps中保存數據庫信息。Maps被存儲於運行NIS服務器的中央主機中，從該主機中，客戶可以通過各種RPC調用檢索信息。最頻繁地，maps是存於DBM文件中的。[4]
Maps本身是從主要文本文件（比如/etc/hosts或/etc/passwd）中生成的。對於某些文件，會生成幾個maps，每個搜尋鍵類型對應壹個。例如，妳可以為主機名和IP地址搜查hosts文件。相應地，從中會生成兩個NIS maps，分別稱為hosts.byname和hosts.byaddr。表10.1列出了通用maps和它們生成的文件。
Master File Map(s)
/etc/hosts
/etc/networks
/etc/passwd
/etc/group
/etc/services
/etc/rpc
/etc/protocols
/usr/lib/aliases Hosts.byname hosts.byaddr
Networks.byname networks.byaddr
Passwd.byname passwd.byuid
Group.byname group.bygid
Services.byname services.bynumber
Rpc.byname rpc.bynumber
Protocols.byname protocols.bynumber
Mail.aliases
表10.1 壹些標準的NIS maps以及相應的文件。
在某些NIS軟件包或其它軟件中，還有壹些妳可能會覺得有用的別的文件和maps。這些文件和maps可能含有沒在這本書中討論過的應用程序的信息，比如可能用於某些BOOTP服務器中的bootparams maps，或者在Linux中目前不含有任何函數的文件（就象ethers.byname和ethers.byaddr maps）。
對於某些maps，人們通常使用綽號（nicknames），它們很短因而易於鍵入。要想獲得壹個妳的NIS工具能夠理解的綽號的完整列表，運行下面的命令：
$ ypcat –x
NIS map nickname translation table:
“passwd” -> “passwd.byname”
“group” -> “group.byname”
“networks” -> “networks.byaddr”
“hosts” -> “hosts.byname”
“protocols” -> “protocols.bynumber”
“services” -> “services.byname”
“aliases” -> “mail.aliases”
“ethers” -> “ethers.byname”
“rpc” -> “rpc.bynumber”
“netmasks” -> “netmasks.byaddr”
“publickey” -> “publickey.byname”
“netid” -> “netid.byname”
“passwd.adjunct” -> “passwd.adjunct.byname”
“group.adjunct” -> “group.adjunct.byname”
“timezone” -> “timezone.byname”
NIS服務器傳統地稱為ypserv。對於壹個中等大小的網絡來說，單個服務器通常就足夠了；大型的網絡可能需要在不同的網段以及不同的機器上運行幾個服務器，以減輕服務器機器和路由器的負荷。通過將這些服務器之壹作為主服務器（master server），其它的服務器作為次服務器（slave servers），使得這些服務器同步。Maps將只在主服務器上建立。從主服務器上將它們分發到所有次服務器上。
妳可能已經註意到，我們壹直很含糊地論及“網絡”；當然引用這樣壹個網絡的NIS存在著與眾不同的概念，也即通過NIS***享它們部分系統配置數據的所有主機的壹個集合：NIS域。不幸的是，NIS域與我們在DNS中遇到的域絕對沒有壹點***同之處。為了在本章中避免含糊不清的情況，我將總是指出我說的哪壹類型的域。
NIS域只具有純粹的管理功能。對於用戶來說它們主要是不可見的，除了在域中所有機器之間口令的***享。因此，給NIS域取的名字僅與管理員有關。通常，可以使用任何名字，只要該名字與妳的本地網絡上的其它NIS域名不同就行。例如，虛擬釀酒廠的管理員可以選擇建立兩個NIS域，壹個是給釀酒廠本身用的，另壹個是個葡萄酒廠的，她分別將其命名為brewery和winery。另壹個很普遍的方案是簡單地用DNS域名也作為NIS的域名。為了設置和顯示妳的主機的NIS域名，妳可以使用dommainname命令。當不加任何參數調用時，它打印出當前NIS域名；如要設置這個域名的話，妳必須成為超級用戶並鍵入：
# domainname brewery
NIS域決定了壹個應用程序將查詢哪個NIS服務器。例如，在葡萄酒廠（Winery）的主機上的login程序（當然）將只向葡萄酒廠的NIS服務器（或者是它們其中之壹，如果存在多個服務器的話）查詢用戶的口令信息；而釀酒廠主機上的應用程序將只查詢釀酒廠的服務器。
現在還有壹個疑點要解決，也即壹個客戶如何知道要連接到哪壹臺服務器上去。最簡單的途徑是有壹個配置文件，它給出了要在其上查找服務器的主機名。然而，這個辦法非常不靈活，因為它不允許客戶依據這些服務器存在與否使用不同的服務器（當然是指從同壹個域）。因此，傳統的NIS實現依賴於壹個稱作ypbind 的特殊後臺程序在它們的NIS域中來偵測壹個適當的NIS服務器。在能夠執行任何NIS查詢之前，任何應用程序首先要從ypbind找出要使用哪個服務器。
ypbind通過向本地IP網絡廣播來探測服務器；第壹個響應的服務器假設基本上是最快的壹個並將用於隨後的NIS查詢。在某個間隔時間過去以後，或者如果服務器不工作了，ypbind將再次探測運行著的服務器。
現在，關於動態綁定的爭論點是妳很少需要它，並且它會帶來安全方面的問題：ypbind盲目地相信任何應答者，而這個應答者可能會是壹個謙遜的NIS服務器也可能是壹個懷有惡意的入侵者。不用說如果妳在NIS上管理妳的口令數據庫的話，這將變成特別麻煩的事。為了防範這個問題，NYS缺省地不使用 ypbind，而是從壹個配置文件中取得服務器的主機名。
10.2 NIS與NIS+
NIS和NIS+除了在名字上和有***同的目標以外，很少有相同之處。NIS+是用壹個完全不同的方法構成的。它使用壹個類似於DNS的分級名字空間，而不是壹個平面的名字空間和松散脫節的NIS域。它使用壹個由行和列組成的所謂的表（tables）而不是maps，在NIS+數據庫中表的每壹行表示壹個對象，而列表示NIS+所知所關心的對象的那些屬性。壹個給定的NIS+域的每個表由那些它們的父域組成。另外，表中的壹個條目可以包含到另壹個表的鏈接。這些特性使得用許多方法構造信息成為可能。
傳統的NIS的RPC版本號是2，而NIS+的是版本3。
NIS+至今似乎還沒有被廣泛地使用，而且我實際上對它也知道不多。（唔，幾乎壹竅不通）。由於這個原因，這裏我們將不涉及它了。如果妳對它感興趣並想多學壹點的話，請參閱Sun的NIS+管理手冊（[NISPlus]）。
10.3 客戶邊的NIS
如果妳熟悉編制或移植網絡應用程序的話，妳將會註意到上面所列出的許多NIS maps與C庫中的庫函數相對應。例如，要獲得passwd信息，妳通常使用getpwnam(3)和getpwuid(3)函數，它們分別返回與給定的用戶名或數值用戶id相對應的帳號信息。在通常的環境下，這些函數將在標準文件（比如/etc/passwd）中執行請求的查找。
然而，這些函數的基於NIS（NIS-aware）的實現將更改這種行為，並且會啟用壹個RPC調用讓NIS服務器查詢用戶名或id。對於應用程序來說這個操作是完全透明的。這個函數可以將NIS map“附加”或“替換”掉原始的文件。當然，這並沒有對文件進行實際的修改，它只是讓應用程序看上去好象該文件已經被替換或附加上去了。
對於傳統的NIS實現來講，對於那些maps替換掉以及那些被添加到原始信息中，曾有某些慣例。有些maps（比如passwd maps）需要對passwd文件進行雜湊地修改，當做錯時，就會打開安全方面的缺口。為了避免這個缺陷，NYS常規的配置方案，該方案確定了壹個特定的客戶函數集是否使用原始文件、NIS、NIS+，並且以什麽次序使用。這將在本章後續小節中加以討論。
10.4 運行壹個NIS服務器
在這麽多理論方面的喋喋不休之後，現在開始動手做實際的配置工作。在本節中，我們將討論NIS服務器的配置。如果在妳的網絡上已經有壹個NIS服務器在運行，妳就不必設置妳自己的服務器了；在這種情況下，妳可以安全地跳過本節。
註意，如果妳只是準備對服務器做試驗，請確信妳沒有設置壹個已經在妳網絡上使用的NIS域名。因為這會使整個網絡服務癱瘓並使得許多人不高興和惱怒。
對於Linux目前有兩個現存的免費NIS服務器，壹個包含在Tobias Reber的yps軟件包中，另壹個在Peter Eriksson的ypserv軟件包中。至於妳運行哪壹個是無關緊要的，也不管妳使用NYS還是目前在libc中的標準NIS客戶代碼。在寫作本書時，yps中的NIS次服務器處理的代碼似乎更完善壹些。所以如果妳要涉及到次要服務器的話，yps可能是壹個更好的選擇。
當在/usr/sbin中安裝好服務器程序（ypserv）以後，妳應該建立壹個目錄，用於存放妳的服務器分發的map文件。當為brewery域設置好壹個NIS域時，maps將存於/var/yp/brewery中。服務器通過檢測是否存在壹個map目錄來確定它是否在為壹個特定的NIS域服務。如果妳對某些NIS域禁用了服務，請確信同時也刪除那個目錄。
Maps通常儲存於DBM文件中以加速查詢。它們是用壹個稱為makedbm（對於Tobias的服務器）或dbmload（對於Peter的服務器）的程序從主文件中創建的。它們是不可互換的。將主文件轉換成dbmload可分析的形式通常需要壹些awk或sed技巧，這對於錄入有些乏味並且難於記憶。因此，Perter Eriksson的ypserv軟件包含有壹個Makefile（稱為ypMakefile），它將為妳做所有這些工作。妳應該將它作為Makefile 安裝在妳的map目錄中，並且編輯它，以反映妳要分發的maps。在文件的頭部，妳會發現all目標，它列出了ypserv將要提供的服務。缺省地，該行看上去象這樣：
all: ethers hosts networks protocols rpc services passwd group netid
例如，如果妳不想生成ethers.byname和ethers.byaddr maps，只須簡單地從這條規則中去掉ethers先決條件。為了測試妳的設置，開始只使用壹二個maps，比如services.* maps，就已經足夠了。
在map的目錄裏，在編輯好Makefile以後，鍵入“make”。這將自動地生成並安裝maps。妳必須確信每當妳改變了主文件之後，壹定要更新maps，否則所做的改變對網絡仍然是不可見的。
下壹節解釋如何配置NIS客戶代碼。如果妳的安裝設置不工作的話，妳應該查出有沒有任何請求到達妳的服務器。如果妳對NYS服務器指定-D命令行標誌，它將在控制臺上打印出有關所有進入的NIS查詢的調試信息，並且返回結果。這些將給妳壹個提示來確定問題到底出在哪裏。Tobias的服務器沒有這個選項。
10.5 使用NYS設置壹個NIS客戶
在本章的余下部分，我們將討論NIS客戶的配置。
妳的第壹步應該是告知NYS對於NIS服務使用哪個服務器，並在/etc/yp.conf配置文件中設置好。對於在葡萄酒廠（Winery）網絡上壹臺主機上的簡單樣本文件看上去象這樣：
# yp.conf – YP configuration for NYS library.
#
domainname winery
server vbardolino
第壹條語句告訴所有NIS客戶，他們屬於winery NIS域。如果妳省略這壹行，NYS將使用妳通過domainname命令指派給妳系統的域名。server語句指定所使用的NIS服務器。當然，與vbardolino相應的IP地址必須在hosts文件中設置；另外，妳也可以在server語句中使用IP地址本身。
在上面所示的表單中，server命令告訴NYS使用指定的服務器而不管目前的NIS域是什麽。然而，如果妳頻繁地在不同的NIS域中移動妳的機器的話，妳可能想要在yp.conf文件中保存幾個域的信息。妳可以通過在server語句中增加NIS域名獲得幾個NIS域的服務器的信息。例如，妳可以為壹個便攜機改變上面樣本文件成這樣：
# yp.conf – YP configuration for NYS library
#
server vbardolino winery
server vstout brewery
這允許妳在系統引導時通過domainname命令設置期望的NIS域來在兩個域的任何壹個域中使用便攜機。
在創建了這個基本的配置文件並確信它是可讀的以後，妳應該運行的第壹次測試來檢查妳是否能連接到妳的服務器上。確信選擇妳的服務器分發的任何map，如 hosts.byname，並試著使用ypcat工具來檢索它。ypcat，就象所有其它的NIS管理工具壹樣，應該存在於/usr/sbin中。
# ypcat hosts.byname
191.72.2.2 vbeaujolais vbeaujolais.linus.lxnet.org
191.72.2.3 vbardolino vbardolino.linus.lxnet.org
191.72.1.1 vlager vlager.linus.lxnet.org
191.72.2.1 vlager vlager.linus.lxnet.org
191.72.1.2 vstout vstout.linus.lxnet.org
191.72.1.3 vale vale.linus.lxnet.org
191.72.2.4 vchianti vchianti.linus.lxnet.org
妳所得到的輸出應該與上面顯示的相象。如果妳得到了壹條錯誤信息指出“Can’t bind to server which serves domain”或者某些類似的信息，那麽或者是妳設置的NIS域名在yp.conf中沒有匹配的服務器，或者是由於某些原因服務器找不到。在後壹種情況下，請確信ping到那個主機產生正確的結果，並且它確實正在運行壹個NIS服務器。妳可以使用rpcinfo來驗證後者，它將生成以下輸出：
# rpcinfo –u serverhost ypserv
program 100004 version 2 ready and waiting
10.6 選擇正確的maps
在確信能夠與NIS服務器聯系之後，妳必須決定要用NIS maps替換或添加哪個配置文件。壹般地，妳將會對主機和口令查找函數使用NIS maps。前者對於沒有使用BIND時特別有用。後者允許所有用戶在NIS域的任何系統上登錄進他們的帳號；這通常要求通過NFS在所有的主機之間***享壹個中央/home目錄。這將在10.7節中詳細討論。其它的maps，如同services.byname，並沒有如此有戲劇性的效能，但能為妳省去某些編輯工作如果妳安裝了任何網絡應用程序而該應用程序使用了壹個不在標準services文件中的服務名。
通常，對於壹個查找函數何時使用本地文件、何時詢問NIS服務器，妳會想有某些自由的選擇。NYS允許妳配置函數訪問這些服務的順序。這是通過/etc/nsswitch.conf文件來控制的，該文件名是指名稱服務交換（Name Service Switch），當然其並不限制於名稱服務。對於NYS支持的任何數據查找函數，它都包含指定所用服務的壹行。
服務的正確順序是與數據的類型有關的。並無必要讓services.byname的map壹定要含有與本地services文件中不同的條目；它可以包含更多的條目。所以，壹個好的選擇可以是首先查詢本地文件，並且只有當服務名稱沒有找到時才查找NIS。另壹方面，主機名信息可能會非常頻繁地改變，所以 DNS或NIS服務器應該總是有非常正確的信息，而本地的hosts文件只作為在DNS和NIS不可用時的壹個備份而已。在這種情況下，妳可能想最後查詢本地文件。
下面的例子顯示出了如何以上面描述的方式配置gethostbyname(2)、gethostbyaddr(2)和getservbyname(2)函數。它們將依次試用列出的服務；如果壹個查找成功，結果就返回，否則試用下壹個服務。
# small sample /etc/nsswitch.conf
#
hosts: nis dns files
services: files nis
可以在nsswitch.conf文件中有壹個條目的完整服務的列表如下面所示。實際被查詢的maps、文件、服務器和對象依賴於條目名。
nisplus或nis+
對這個域使用NIS+服務器。服務器的位置從/etc/nis.conf文件中獲得。
nis 使用這個域的當前NIS服務器。被查詢的服務器的位置在yp.conf文件中設置，見前節所示。對於hosts條目，要查詢hosts.byname和hosts.byaddr maps。
dns 使用DNS名字服務器。這個服務類型只對hosts條目有用。要被檢索的名字服務器仍然由標準resolv.conf文件確定。
files 使用本地文件，比如對於hosts條目使用/etc/hosts文件。
dbm 從位於/var/dbm內的DBM文件中查找信息。文件所使用的名字與NIS map相對應。
目前，NYS支持下面這些nsswitch.conf條目：hosts、networks、passwd、group、shadow、gshadow、services、protocols、rpc和ethers。以後還會增加更多的條目。
圖10.1顯示了壹個更完整的例子，它引入了nsswitch.conf的另壹個特性：hosts條目中的[NOTFOUND=return]關鍵字通知 NYS，如果在NIS或DNS數據庫中沒有找到所要的項就返回。也即，只有在向NIS和DNS服務器的呼叫由於某些其它原因失敗時，NYS才將繼續搜尋本地文件。因此，本地文件只在啟動引導期間使用並且當NIS服務器關閉時起壹個備份的作用。
# /etc/nsswitch.conf
#
hosts: nis dns [NOTFOUND=return] files
networks: nis [NOTFOUND=return] files
services: files nis
protocols: files nis
rpc: files nis
圖10.1 nsswitch.conf樣本文件。
10.7 使用passwd和group Maps
NIS的壹個主要應用是在壹個NIS域中的所有主機上同步用戶以及帳目信息。關於這方面，妳通常只保存了壹個小的本地/etc/passwd文件，對於這個文件，從NIS maps獲得的站點範圍的信息被添加了進去。然而，只是簡單地在nsswitch.conf中為這個服務啟用NIS查找還不很夠。
當引用NIS描述的口令信息時，妳必須首先確信在妳本地passwd文件中任何用戶的數值用戶id與NIS服務器的用戶id匹配。同樣對於其它目的妳也會需要這樣的，比如從妳的網絡中其它主機上加載NFS卷時。
如果/etc/passwd或/etc/group中的任何數值id與maps中的相偏離，妳必須為屬於那個用戶的所有文件調整文件的所有權。首先妳必須將passwd和group中的uid和gid改成壹個新值；然後找出屬於剛改變的用戶的所有文件，最後改變這些文件的所有權。假設news曾有壹個id 為9，而okir有壹個id為103，它們將被改成其它值；那麽妳可以發出以下的命令：
# find / -uid 9 –print >/tmp/uid.9
# find / -uid 103 –print >/tmp/uid.103
# cat /tmp/uid.9 | xargs chown news
# cat /tmp/uid.103 | xargs chown okir
必須針對新安裝的passwd文件執行這些命令，並且在改變任何文件的所有權之前收集所有文件的名字，這點很重要。為了更新文件的組所有權，妳將使用壹個類似的命令。
在做完這些工作之後，妳系統上的數值uid和gid將與妳的NIS域中所有其它主機上的相匹配。下壹步將是在nsswitch.conf中增加配置行，它為用戶和組信息啟用NIS查找：
# /etc/nsswitch.conf – passwd and group treatment
passwd: nis files
group: nis files
這使得在壹個用戶試圖登錄時，login命令和所有其它類似命令首先查詢NIS maps，如果這個查找失敗時，再返回使用本地文件。壹般來講，妳將從妳的本地文件中刪除所有的用戶，而只留下root和象mail壹樣的通用帳目。這是因為某些至關重要的系統任務可能需要將uid映射到用戶名上或者反之。例如，管理用的cron作業可能會執行su命令來臨時變成news，或者UUCP子系統可能要郵寄壹個狀態報告。如果news和uucp在本地passwd文件中沒有條目了，那麽在NIS不能使用期間這些作業將糟糕地失敗。
這裏有兩個大告戒：壹方面，上面所描述的設置在這裏只適應於沒有使用影子（shadow）口令的登錄狀況，象那些包括在util-linux軟件包中的。與NIS壹起使用影子口令的復雜問題將在下面論及。另壹方面，登錄命令並不是僅有的訪問passwd文件的命令—請看許多人幾乎壹直使用的ls命令。每當進行壹次長列表時，ls將顯示壹個文件的用戶和組的宿主的符號名；也即，對於它遇到的每個uid和gid，它就要查詢NIS服務器壹次。如果妳的本地網絡受到阻塞時將嚴重地拖延進行的工作，或者更糟糕的是，當NIS服務器不在同壹個物理網絡上時，數據報還必須通過路由器傳輸。
事情還沒結束。想象以下如果壹個用戶想要更改她的口令時會發生什麽情況。通常，她會執行passwd，它將讀入新的口令並更新本地passwd文件。對於 NIS來說，這是不可能的，因為這個文件已不再存在於本地了，但是每當用戶想要改變他們的口令時就讓他們登錄進NIS也不是個選擇。因此，NIS提供了壹個對passwd的混入替換稱為yppasswd，它用來在目前的NIS中做類似的工作。為了改變服務器主機上的口令，它通過RPC聯系那個主機上的 yppasswdd後臺程序，並向它提供更新過的口令信息。通常，妳通過象這樣做在常規程序上安裝yppasswd：
# cd /bin
# mv passwd passwd.old
# ln yppasswd passwd
與此同時妳必須在服務器上安裝rpc.yppasswdd並從rc.inet2中啟動它。這將對妳的用戶有效地隱藏NIS所帶來的任何扭曲。
10.8 使用支持影子（shadow）的NIS
至今還沒有對使用影子登錄程序組的站點的NIS支持。John F. Haugh，影子程序組的作者，最近往comp.sources.misc發布了壹個受GNU庫的GPL保護的影子庫函數的壹個版本。它對NIS已經有了壹些支持，但還不完整，並且這些函數還沒有加入到標準C庫中。另壹方面來講，通過NIS之類公布來自於/etc/shadow中的信息是與shadow組件的目的相違背的。
盡管NYS口令查找函數不使用shadow.byname map或任何這類map，NYS還是支持透明地使用壹個本地/etc/shadow文件的。當getpwnam的NYS實現被調用來查找與給定的登錄名相關的信息時，nsswitch.conf中的passwd條目所指定的設施被檢索。nis服務將簡單地在NIS服務器的passwd.byname map中查找這個名字。而files服務將檢查/etc/shadow是否存在，並且如果存在的話，就試著打開它。如果不存在的話，或者如果用戶沒有 root特權的話，它就返回到只在/etc/passwd中查找用戶信息的傳統的處理方法中。然而，如果shadow文件存在，並且能被打開的話，NYS 將從shadow中抽取用戶的口令。getpwuid 函數也是這樣實現的。在這種方式下，用NYS編譯的執行文件將透明地處理本地影子組件的安裝。
10.9 使用傳統的NIS代碼
如果妳使用目前在標準C庫中的客戶代碼的話，那麽配置壹個NIS客戶就稍微有些不同。壹方面，它使用壹個ypbind後臺程序（daemon）來廣播查詢運行著的服務器而不是從壹個配置文件中取得（服務器）信息的。因此，妳必須確信在啟動期間開始運行ypbind。它必須在NIS域已被設置好並且RPC portmapper已啟動後才被調用。此時，上面所示的調用ypcat進行對服務器測試才能工作。
最近，有許多有關NIS出錯報告（bug reports），出錯信息說“clntudp_create: RPC: portmapper failure – RPC: unable to receive”。這是由於對ypbind與庫函數有關綁定信息的通信（溝通）方式的不兼容的改動。取得最新有關NIS工具的最新源程序並重新編譯之可以解決這個問題。[5]
同樣，傳統的NIS確定是否要和如何將NIS信息與本地文件中的信息合並的方法與NYS中所使用的方法是有偏差的。例如，為了使用NIS口令maps，妳必須在/etc/passwd map中包含下列行：
+:*:O:O:::
這標記出口令查找函數“插入”NIS maps的地方。往/etc/group中插入類似的壹行（去掉最後兩個冒號）會對group.* maps做出同樣的事。為了使用NIS分發的hosts.* maps，只要改動host.conf文件中的order壹行。例如，如果妳要使用NIS、DNS以及/etc/hosts文件（以這個順序），妳必須將這行改成
order yp bind hosts
目前，傳統的NIS實現不支持任何其它的maps。