Provozujete-li lokální Síť, budete chtít poskytovat uživatelům takové prostředí, které by jim připadalo transparentní. Jedním z důležitých kroků, které vedou k tomuto cíli, je zajištění synchronizace důležitých dat, jako jsou informace o účtech uživatelů, mezi všemi hostiteli. Ukázali jsme si, že pro rozlišení názvů hostitelů existuje mocná a propracovaná služba, konkrétně systém DNS. Pro ostatní úkoly žádná taková speciální služba neexistuje. Kromě toho, pokud spravujete pouze malou lokální Síť, která nemá žádné spojení s Internetem, nebude se mnoho administrátorů namáhat s nastavováním systému DNS.
Tato situace vedla k tomu, že firma Sun vyvinula systém NIS, Síťový informační systém. Systém NIS poskytuje prostředky pro obecný přístup k databázím, které lze využít k šíření informací všem hostitelům ve vaší síti. Těmito informacemi mohou být například informace obsažené v souborech passwd a group. To umožňuje, aby Síť vypadala jako jediný systém se stejnými účty na všech hostitelích. Podobným způsobem můžete používat systém NIS k šíření informací o hostitelích, které jsou uloženy v souboru /etc/hosts, na všechny počítače v síti.
Systém NIS je založen na balíku RPC a skládá se ze serveru, z knihovny na straně klienta a z několika administrativních nástrojů. Původně se systém NIS nazýval Yellow pages (Žluté stránky), neboli YP. Toto označení se ještě stále používá jako informativní odkaz na tuto službu. Na druhou stranu jsou Yellow pages ochrannou známkou společnosti British Telecom, která požadovala po firmě Sun, aby tento název přestala používat. I s odstupem času však zůstaly některé názvy zakořeněny a zkratka YP se proto stále používá jako prefix názvů většiny příkazů, které se vztahují k sytému NIS, například ypserv, ypbind apod.
Dnes je systém NIS dostupný snad ve všech verzích Unixu a existují dokonce i jeho volné implementace. Jednu z těchto implementací obsahuje balík BSD verze Net-2. Je odvozena z veřejně dostupné implementace, kterou poskytla firma Sun. Již dlouhou dobu je kód knihovny klienta z této verze umístěn v knihovně GNU libc, zatímco administrativní nástroje teprve nedávno portoval na platformu Linuxu pan Swen Thümmler.
Server systému NIS nemá žádnou referenční implementaci. Tobias Reber napsal další balík systému NIS, který obsahuje všechny nástroje i server; tento balík se nazývá yps.
V současné době dokončil Peter Eriksson kompletní přepis kódu systému NIS pod názvem NYS, který podporuje jak holý systém NIS, tak i mnohem dokonalejší systém NIS+ od firmy Sun. Balík NYS neposkytuje pouze množinu nástrojů a server, ale přidává do knihovny také celou novou sadu funkcí, které se časem zřejmě stanou součástí standardní knihovny libc. Tyto funkce obsahují nové konfigurační schéma pro rozlišování názvů hostitelů, které nahrazuje současné schéma používající soubor host.conf. Přínosy těchto funkcí budou rozebrány níže.
Tato kapitola se bude více soustřeďovat na balík NYS, než na další dva konkurenční balíky, které budeme označovat jako tzv. "tradiční" kód systému NIS. Chcete-li pracovat s některým z těchto balíků, pak vám možná nebudou informace obsažené v této kapitole stačit. Chcete-li o nich získat více informací, sežeňte si prosím knihu o systému NIS, například publikaci NFS and NIS od Hala Sterna (viz [Stern92]).
Balík NYS se v současné době stále ještě vyvíjí, a proto standardní linuxové utility, jako jsou Síťové programy nebo program login, zatím neovládají konfigurační schéma balíku NYS. Než se balík NYS stane součástí hlavní knihovny libc, budete si muset všechny tyto binární soubory aplikací sami překompilovat, aby byly schopny podporovat balík NYS. Při kompilaci libovolné z těchto aplikací pomocí programu Makefile zadejte sestavovacímu programu jako poslední parametr před knihovnou libc parametr -lnsl. Tento parametr vloží na místo standardních funkcí z knihovny C odpovídající funkce z knihovny libnsl, knihovny NYS.
Systém NIS uchovává databázové informace v tzv. mapách, které obsahují páry klíčových hodnot. Mapy jsou uloženy na centrálním hostiteli, na němž běží systém NIS a z něhož mohou klienti získávat informace pomocí různých volání procedur RPC. Poměrně často bývají mapy uloženy v souborech DBM.
Vlastní mapy jsou obvykle generovány z hlavních textových souborů, jako jsou například soubory /etc/hosts nebo /etc/passwd. Pro některé soubory se vytvoří několik map, pro každý typ vyhledávacího klíče se vždy vytvoří jedna mapa. Například v souboru hosts můžete hledat jak název hostitele, tak i IP-adresu. Z tohoto souboru budou takto odvozeny dvě mapy, které se budou nazývat hosts.byname, resp. hosts.byaddr. Tabulka 10.1 uvádí běžně se vyskytující mapy společně se soubory, ze kterých byly vygenerovány.
Hlavní soubor Mapa (Mapy)
/etc/hosts hosts.byname hosts.byaddr
/etc/networks networks.byname networks.byaddr
/etc/passwd passwd.byname passwd.byuid
/etc/group group.byname group.bygid
/etc/services services.byname services.bynumber
/etc/rpc rpc.byname rpc.bynumber
/etc/protocols protocols.byname protocols.bynumber
/usr/lib/aliases mail.aliases
Tabulka 10.1 Některé standardní mapy systému NIS a jim odpovídající soubory
Možná se setkáte s tím, že některé balíky systému NIS nebo některé další programy podporují i jiné soubory a mapy. Tyto soubory a mapy mohou obsahovat informace o aplikacích, které nejsou v této knize probírány (například mapa bootparams) a mohou využívat některé servery BOOTP, anebo tyto soubory a mapy nemají v současné době v Linuxu žádnou funkci (příkladem jsou mapy ethers.byname nebo ethers.byaddr).
Pro některé mapy lidé obecně používají přezdívky, které jsou kratší a z tohoto důvodu se lépe píší. Chcete-li získat kompletní seznam přezdívek, kterým vaše nástroje systému NIS rozumí, spusšte následující příkaz:
$ ypcat -x
NIS map nickname translation table:
"passwd" -> "passwd.byname"
"group" -> "group.byname"
"networks" -> "networks.byname"
"hosts" -> "hosts.byname"
"protocols" -> "protocols.byname"
"services" -> "services.byname"
"aliases" -> "aliases.byname"
"ethers" -> "ethers.byname"
"rpc" -> "rpc.byname"
"netmasks" -> "netmasks.byname"
"publickey" -> "publickey.byname"
"netid" -> "netid.byname"
"passwd.adjunct" -> "passwd.adjunct.byname"
"group.adjunct" -> "group.adjunct.byname"
"timezone" -> "timezone.byname"
Server NIS se tradičně nazývá ypserv. Pro protřeby průměrné sítě zpravidla postačuje jediný server; rozsáhlé sítě možná dají přednost provozování několika těchto serverů na různých počítačích, čímž různé segmenty sítě odlehčí celkové zatížení serverových počítačů a směrovačů. Tyto servery jsou vzájemně synchronizovány tak, že některý z těchto serverů je nastaven jako řídící server a ostatní servery jsou nastaveny jako řízené servery. Mapy budou vytvořeny pouze na hostiteli s řídícím serverem. Odtud jsou distribuovány na všechny řízené servery.
Možná jste si všimli, že po celou dobu jsme o "sítíchio hovořili značně neurčitě; samozřejmě, že v systému NIS existuje přesný koncept týkající se dané sítě, kterou tvoří skupina všech hostitelů sdílejících pomocí systému NIS část jejích systémových konfiguračních dat: tímto konceptem je doména systému NIS. Bohužel domény systému NIS nemají nic společného s doménami systému DNS, s nimiž jsme se již setkali. Abychom se v této kapitole vyhnuli dvojsmyslnostem, bude vždy uváděn typ příslušné domény.
Domény systému NIS nabízí jen velmi slabé administrativní funkce. Ty jsou, kromě sdílení hesel mezi všemi počítači příslušné domény, většinou pro uživatele neviditelné. Proto má název poskytnutý doméně systému NIS význam pouze pro správce sítě. Zpravidla bude fungovat jakýkoliv název, který bude odlišný od všech názvů domén systému NIS vyskytujících se ve vaší lokální síti. Například správci ve společnosti Virtual Brewery mohou vytvořit dvě domény systému NIS, jednu z nich pro vlastní společnost Virtual Brewery a jednu pro společnost Virtual Winery, kterým přiřadí názvy brewery, resp. winery. Dalším poměrně běžným schématem je použití stejného názvu jak pro doménu systému DNS, tak i pro doménu systému NIS. K nastavení a zobrazení názvu domény systému NIS na vašem hostiteli můžete použít příkaz domainname. Když tento příkaz vyvoláte bez argumentů, zobrazí název aktuální domény systému NIS; budete-li chtít nastavit název domény, přihlaýte se jako superuživatel a napište:
# domainname brewery
Domény NIS určují, na který server se budou aplikace dotazovat. Například program login se na hostiteli ve Virtual Winery může dotazovat na informace o uživatelských heslech pouze serveru NIS v této společnosti (nebo jednoho ze serverů v této společnosti, pokud je jich více); zatímco aplikace na hostiteli ve Virtual Brewaery může komunikovat pouze se serverem v této společnosti.
Teď ještě zbývá vyřešit jednu záhadu, konkrétně jak klient zjistí, se kterým serverem se má spojit. Nejjednodušší by bylo použít konfigurační soubor, v němž bude uveden hostitel, na kterém se server má hledat. Avšak tento přístup je poměrně nepružný, protože neumožňuje klientům používat různé servery (samozřejmě z téže domény) v závislosti na jejich dostupnosti. Proto spoléhají tradiční implementace systému NIS na speciálního démona nazývaného ypbind, který detekuje vhodný server NIS v jejich doméně systému NIS. Dříve, než může nějaká aplikace předat systému NIS jakýkoliv dotaz, si musí nejprve od démona ypbind zjistit, jaký server má k tomuto účelu použít.
Démon ypbind prozkoumává servery za pomoci vysílání do místní sítě IP; první, kdo odpoví, je považován za potenciálně nejrychlejší server, a proto bude použit pro všechny následující dotazy systému NIS. Po uplynutí určité doby nebo dojde-li k přerušení spojení se serverem, začne démon ypbind znovu prozkoumávat aktivní servery.
A nyní se dostáváme ke spornému bodu použití dynamické vazby, který spočívá v tom, že ji budete potřebovat pouze zřídka a její použití s sebou navíc přináší jisté bezpečnostní problémy: Démon ypbind slepě uvěří každému, kdo mu odpoví, což může být jak prostý server NIS, tak i zlomyslný vetřelec. Netřeba ani říkat, že tato vlastnost je zvláště nepříjemná, spravujete-li pomocí systému NIS své databáze s hesly. Abyste tomuto předešli, nepoužívá balík NYS implicitně démona ypbind, ale název hostitele serveru přebírá z konfiguračního souboru.
Systémy NIS a NIS+ toho mají společného více, než jen svůj název a cíl. Systém NIS+ je strukturován zcela odlišným způsobem. Místo přímého jmenného prostoru s oddělenými doménami systému NIS používá hierarchický prostor s názvy, který je podobný jmennému prostoru systému DNS. Místo map jsou používány tzv. tabulky, které jsou složeny z řádků a sloupců, kde každý řádek reprezentuje objekt databáze systému NIS+, zatímco sloupce obsahují vlastnosti objektů, které systém NIS+ zná a o něž se stará. Každá tabulka příslušné domény systému NIS+ v sobě zahrnuje i tabulky svých rodičovských domén. Mimoto může položka v tabulce obsahovat spojení na další tabulku. Tyto vlastnosti umožňují strukturovat informace mnoha způsoby.
Tradiční systém NIS má číslo verze balíku RPC rovno 2, zatímco systém NIS+ používá verzi 3.
Zatím to vypadá tak, že systém NIS+ není příliš používán a ani já toho vlastně o něm příliš nevím. (Ve skutečnosti o něm nevím skoro nic.) Proto ho zde nebudeme rozebírat. Pokud se o tento systém zajímáte hlouběji, nahlédněte prosím do administrativního manuálu systému NIS+ od firmy Sun ([NISPlus]).
Ovládáte-li psaní a portování Síťových aplikací, pak si jistě všimnete, že většina výše uvedených map systému NIS odpovídá funkcím, které jsou obsaženy v knihovně C. Chcete-li například získat informace ze souboru passwd, budete k tomuto účelu běžně používat funkce getpwnam(3) a getpwuid(3), které vrací informace o účtu sdružené s příslušným jménem uživatele, resp. s číselným id uživatele. Za normálních okolností provedou tyto funkce požadované vyhledání ve standardním souboru, což je soubor /etc/passwd.
Avšak implementace těchto funkcí v systému NIS toto chování upraví a vloží takové volání procedury RPC, aby server NIS, vyhledal příslušné uživatelské jméno nebo jeho id. Toto chování bude pro aplikaci zcela transparentní. Funkce může buď k danému souboru "připojit" mapu systému NIS nebo může touto mapou původní soubor "nahraditit. Neznamená to samozřejmě skutečnou úpravu daného souboru, pouze to znamená, že se aplikaci bude takový soubor jevit, jako by k němu byla daná mapa připojena nebo jakoby byl touto mapou nahrazen.
V tradičních implementacích systému NIS existovala jistá pravidla týkající se map, které mají nahrazovat původní informace a které se mají připojovat k původním informacím. Některé z těchto map, například mapy ze skupiny passwd, vyžadovaly úpravy souboru passwd, které mohly při nesprávném postupu dát vzniknout bezpečnostním dírám. Aby se tomu zabránilo, používá balík NYS obecné konfigurační schéma, které určuje, zda bude konkrétní množina funkcí klienta používat původní soubory systému NIS nebo systému NIS+ a v jakém pořadí. Toto konfigurační schéma bude náplní dalších statí této kapitoly.
Po přehrýli teoretických technických informacích přišel čas věnovat se skutečné konfigurační praci. V této stati si probereme konfiguraci serveru NIS. Pokud už ve vaší síti běží nějaký server NIS, nebudete zřejmě chtít nakonfigurovat další vlastní server; v tom případě můžete tuto staš přeskočit.
Při experimentování se serverem se nezapomeňte ujistit, že jste mu nepřiřadili název domény systému NIS, který je již ve vaší síti používán. To by totiž mohlo narušit všechny Síťové služby a rozzlobit spoustu lidí.
V současné době jsou v Linuxu volně dostupné dva servery NIS, jeden je obsažen v balíku yps od Tobiase Rebera a druhý v balíku ypserv od Petera Erikssona. Nemělo by záležet na tom, který z těchto balíků si pro provozování zvolíte, ani na tom, zda budete používat balík NYS nebo standardní kód klienta NIS, který je v současnosti součástí knihovny libc. Při psaní této knihy se zdálo, že kód pro správu řízených serverů NIS je dokonalejší v balíku yps.
Tedy pokud budete muset používat řízené servery, bude možná vhodnější použít balík yps.
Po nainstalování programu serveru (ypserv) do adresáře /usr/sbin byste měli vytvořit adresář, v němž budou uloženy soubory map, které bude váš server distribuovat. Bude-li nastavena doména systému NIS na název domény brewery, měly by být mapy umístěny v adresáři /var/yp/brewery. Server zjistí, zda spravuje konkrétní doménu systému NIS tak, že ověří přítomnost adresáře s mapami. Pokud zakážete službu některé domény NIS, ujistěte se, že jste odstranili také odpovídající adresář.
Mapy jsou zpravidla kvůli rychlejšímu vyhledávání uloženy v souborech DBM. Tyto soubory jsou vytvořeny z hlavních souborů za pomoci speciálního programu s názvem makedbm (pro server od Tobiase) nebo dbmload (pro server od Petera). Tyto programy se nesmí zaměňovat. Převod hlavního souboru do formy analyzovatelné programem dbmload obvykle vyžaduje jistý trik typu awk nebo sed, který je poměrně obtížné popsat a navíc je hůře zapamatovatelný. Proto obsahuje balík ypserv od Petera Erikssona program pro vytvoření tohoto souboru (nazvaný ypMakefile), který všechnu potřebnou práci udělá za vás. Měli byste ho nainstalovat jako soubor Makefile do svého adresáře s mapami a upravit ho tak, aby obsahoval vámi distribuované mapy. Směrem k začátku souboru naleznete položku all, ve které jsou uvedeny služby nabízené programem ypserv. Tento řádek vypadá zhruba následovně:
all: ethers hosts networks protocols rpc services passwd group netid
Pokud například nechcete vytvořit mapy ethers.byname a ethers.byaddr, odstraňte z výše uvedené položky volbu ethers. Chcete-li si své nastavení otestovat, budou vám stačit pouze jedna nebo dvě mapy, například mapy services.*.
Po úpravě souboru Makefile napište v adresáři s mapami příkaz make. Tento příkaz požadované mapy automaticky vygeneruje a nainstaluje. Je třeba zajistit, aby se při každé změně hlavních souborů aktualizovaly i soubory s mapami, v opačném případě by Síť provedené změny nezjistila.
Další stať popisuje, jak nakonfigurovat kód klienta systému NIS. Pokud vaše nastavení nefunguje, pak je třeba zjistit, zda na váš server přichází nějaké požadavky. Pokud serveru z balíku NYS zadáte jako příznak příkazové řádky-d, budou se na konzole vypisovat všechny příchozí dotazy systému NIS včetně vrácených odpovědí. Takto možná zjistíte v čem je kámen úrazu. Server od Tobiase žádnou takovou volbou nedisponuje.
Až do konce této kapitoly se budeme zabývat konfigurací klienta systému NIS.
Nejprve byste měli sdělit balíku NYS, který server se bude pro službu NIS používat, což provedete za pomoci konfiguračního souboru /etc/yp.conf. Velice jednoduchý vzorový soubor pro hostitele v síti Virtual Winery by mohl vypadat asi takto:
# yp.conf - konfigurační soubor pro systém NIS
#
domainname winery
server vbardolino
První příkaz sdělí všem klientům systému NIS, že jsou přiřazeni k doméně systému NIS s názvem winery. Pokud na tento řádek zapomenete, použije balík NYS název domény, který jste vašemu systému přidělili za pomoci příkazu domainname. Příkaz server označuje server NIS, který se bude používat. Samozřejmě, že v souboru hosts musí být nastavena IP-adresa odpovídající názvu hostitele vbardolino; popřípadě můžete v příkazu server použít vlastní IP-adresu.
Ve výše uvedeném příkladu sděluje příkaz server balíku NYS, aby použil označený server pokaždé, když je dostupná aktuální doména systému NIS. Pokud však svůj počítač často přemísšujete v rámci různých domén systému NIS, budete možná chtít mít v souboru yp.conf informace o několika doménách. V souboru yp.conf můžete mít informace o serverech pro různé domény systému NIS. Stačí pouze přidat k příkazu server název požadované domény systému NIS. Například pro laptop můžete výše uvedený vzor změnit následujícím způsobem:
# yp.conf - konfigurační soubor pro systém NIS
#
server vbardolino winery
server vstout brewery
Takto upravený soubor yp.conf vám umožní přenášet laptop mezi libovolnými dvěma doménami. Při procesu zavádění systému pouze stačí příkazem domainname nastavit požadovanou doménu systému NIS.
Po vytvoření tohoto základního konfiguračního souboru a ujištění se, že je tento soubor všem dostupný, byste měli spustit svůj první test a zjistit, zda se můžete spojit se svým serverem.
Vyberte si nějakou serverem distribuovanou mapu, například hosts.byname, a pokuste se ji získat pomocí utility ypcat. Nástroj ypcat by se měl, stejně jako všechny ostatní administrativní nástroje, nacházet v adresáři /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
Získaný výstup by měl vypadat podobně jako výše uvedený výpis. Pokud místo tohoto obdržíte chybovou zprávu "Can‚t bind to server which serves domainiu nebo nějakou podobnou zprávu, pak buď vámi zadaný název domény systému NIS nemá v souboru yp.conf definovaný odpovídající server, nebo je server z nějakého důvodu nedostupný. V druhém případě se ujistěte, že příkaz ping směrovaný na příslušného hostitele vrátí přijatelné výsledky, a že daný hostitel má skutečně spuštěn server NIS. Přítomnost serveru NIS na daném hostiteli můžete ověřit pomocí příkazu rpcinfo, který by měl vrátit následující výstup:
# rpcinfo -u serverhost ypserv
program 100004 version 2 ready and waiting
Abyste zajistili dosažitelnost daného serveru NIS, musíte rozhodnout, které konfigurační soubory nahradíte mapami systému NIS a ke kterým konfiguračním souborům mapy systému NIS připojíte. Mapy systému NIS budete zpravidla používat u funkcí, které vyhledávají hostitele a hesla. Funkce vyhledávající hostitele mají význam tehdy, pokud nemáte spuštěnu službu BIND. Funkce vyhledávající hesla povolují všem uživatelům přihlášení ke svému účtu z libovolného systému v příslušné doméně systému NIS; tato funkce obvykle vyžaduje sdílení centrálního adresáře /home pomocí systému NFS mezi všema hostiteli. Tato funkce je podrobně probrána v následující stati. Ostatní mapy, jako například mapa service.byname, nejsou příliš užitečné, ale mohou vám ušetřit část konfiguračních prací v případě, kdy instalujete nějaké Síťové aplikace, které používají název služby, jenž není uveden ve standardním souboru services.
V případech, kdy vyhledávací funkce používá místní soubory nebo kdy se dotazuje serveru NIS, si budete zpravidla chtít zachovat určitou možnost volby. Balík NYS dovoluje nastavit pořadí, ve kterém daná funkce k těmto službám přistupuje. Toto pořadí je řízeno konfiguračním souborem /etc/nsswitch.conf, který nahrazuje přepínač názvových služeb (Name Service Switch). Tento konfigurační soubor se samozřejmě neomezuje pouze na jmenné služby. Pro každou funkci, která je podporována balíkem NYS a vyhledává určitá data, obsahuje konfigurační soubor řádek s výčtem služeb, které se budou používat.
Správné pořadí služeb závisí na typu dat. Je málo pravděpodobné, že by mapa services.byname obsahovala položky, které se liší od položek uvedených v místním souboru services; tato mapa jich jen může obsahovat o něco více. Bylo by tedy dobré, kdyby se dotazování odehrávalo nejdříve v místních souborech a teprve v případě, že by název požadované služby nebyl nalezen, pokračovalo pomocí služby NIS. Na druhou stranu se informace o názvu hostitele mohou velmi často měnit, takže by server DNS nebo server NIS měl mít vždy nejaktuálnější informace, zatímco místní soubor hosts je uchováván pouze jako záložní kopie, kdyby systém DNS nebo systém NIS selhal. V tomto případě budete chtít prozkoumat místní soubor až jako poslední.
Následující příklad ukazuje způsob nastavení funkcí gethostbyname(2), gethostbyaddr(2) a getservbyaddr(2) tak, aby se chovaly výše popsaným způsobem. Tyto funkce postupně zkouší uvedené služby; je-li vyhledávání úspěšné, vrátí výsledek, v opačném případě se bude zkoušet další služba.
# jednoduchý příklad /etc/nsswitch.conf
#
hosts: nis dns files
services: files nis
Dále následuje kompletní seznam služeb, které mohou být použity jako položky konfiguračního souboru nsswitch.conf. Jaké mapy, soubory a servery budou ve skutečnosti dotazovány závisí na názvu položky.
hosts, networks, passwd, group, shadow, gshadow, services, protocols, rpc a ethers.
Časem budou pravděpodobně přidány další.
Obrázek 10.1 ukazuje o něco složitější příklad, který ukazuje novou vlastnost konfiguračního souboru nsswitch.conf: Klíčové slovo [NOTFOUND=return], které je uvedeno v položce hosts, sděluje balíku NYS, aby se v případě, že nelze požadovanou položku nalézt v databázi systému NIS nebo systému DNS, vrátil zpět k dříve uvedeným volbám. To znamená, že balík NYS bude pokračovat v prohledávání místních souborů pouze v případě, kdy volání serveru NIS nebo serveru DNS ztroskotá z nějakého jiného důvodu. Potom budou místní soubory použity pouze při procesu zavádění nebo jako záložní kopie v případě, že server NIS není spuštěn.
# /etc/nsswitch.conf
#
hosts: nis dns [NOTFOUND=return] files
networks: nis [NOTFOUND=return] files
services: files nis
protocols: files nis
rpc: files nis
Obrázek 10.1 Vzorový soubor nsswitch.conf
Jednou z hlavních aplikací systému NIS je synchronizace informací o uživatelích a účtech mezi všemi hostiteli v rámci příslušné domény systému NIS. V důsledku toho se používá pouze malý soubor /etc/passwd, ke kterému se připojují informace z map systému NIS, které obsahují data od ostatních hostitelů. Obvykle ale nestačí pouze povolit v souboru nsswitch.conf vyhledávání dané služby pomocí systému NIS.
Spoléháte-li se na informace s hesly šířené pomocí systému NIS, musíte se nejprve ujistit, že číselné uživatelské id libovolného uživatele, které máte umístěno ve svém lokálním souboru passwd, odpovídá představě serveru NIS o uživatelském id daného uživatele. Totéž budete požadovat i pro jiné účely. Příkladem může být připojení k vlastní síti svazků systému NFS ostatními hostiteli.
Pokud se některé z číselných id v souboru /etc/passwd nebo v souboru /etc/group liší od číselných id, které jsou uvedeny v mapách, musíte upravit vlastnictví všech souborů, které se vztahují k danému uživateli. Nejprve byste měli přiřadit nové hodnoty všem uid a gid v souborech passwd a group; potom byste měli vyhledat všechny soubory, které patří změněným uživatelům, a nakonec byste měli změnit vlastnictví těchto souborů. Předpokládejme, že účet news měl uživatelské id rovno 9 a účet okir měl uživatelské id rovno 103. Tato uživatelská id se změnila na jinou hodnotu; pak byste měli spustit následující příkazy:
# 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
Je důležité, abyste tyto příkazy spustili s nově nainstalovaným souborem passwd a abyste si zjistili názvy všech souborů dříve, než začnete měnit vlastnictví kteréhokoliv z nich. K aktualizaci vlastnictví souborů skupiny použijte obdobnou sekvenci příkazů.
Jakmile provedete tyto změny, budou ve vašem systému souhlasit číselná uid a gid s těmi, které jsou uvedeny na všech ostatních hostitelích ve vaší doméně systému NIS. V dalším kroku přidáme do souboru nsswitch.conf další konfigurační řádky, které povolí vyhledávání informací o uživatelích a skupinách pomocí systému NIS:
# /etc/nsswitch.conf - passwd a group
passwd: nis files
group: nis files
Tyto příkazy zajistí, že program login a všechny jeho příbuzné programy se budou při pokusu o přihlášení uživatele nejprve dotazovat map systému NIS a pokud vyhledávání pomocí systému NIS neuspěje, bude vyhledávání pokračovat v místních souborech. Ze svých místních souborů většinou odstraníte záznamy většiny uživatelů a ponecháte v nich pouze záznamy pro uživatele root a obecné účty, jako například účet mail. To proto, že některé důležité systémové úkoly mohou vyžadovat mapování uživatelských id na jména uživatelů a naopak.
Například administrativní úkoly cron mohou spustit příkaz su, aby dočasně přešly na účet news nebo může podsystém protokolu UUCP poslat zprávu o svém současném stavu na účet uucp. Pokud místní soubor passwd neobsahuje položky pro účty news a uucp, pak tyto úkoly skončí výpadem při použití systému NIS.
Zde se vynoří dvě závažné námitky: na jednu stranu bude dosud popsané nastavení fungovat pouze s přihlašovacími příkazy, které neobsahují stínová hesla. Jako příklad těchto přihlašovacích příkazů můžeme uvést programy z balíku util-linux. Nesnáze spojené s použitím stínových hesel společně se systémem NIS budou probrány dále. Na druhou stranu nepřistupují k souboru passwd pouze přihlašovací příkazy - podívejte se na příkaz ls, který používá většina lidí takřka permanentně. Kdykoliv provádíte nějaké dlouhé výpisy, zobrazí příkaz ls symbolické názvy vlastníků souboru (uživatelů a skupin); to znamená, že kdykoliv příkaz ls narazí na nějaké uid nebo gid, bude se muset dotazovat serveru NIS. To velmi podstatně zpomalí chod programu v případě, že je vaše místní Síť ucpaná nebo, v horším případě, není server NIS ve stejné fyzické síti, takže musí datagramy procházet přes směrovač.
Zde však celé povídání zdaleka nekončí. Představte si, co se stane, když si chce uživatel změnit své heslo. Obvykle spustí příkaz passwd, který přijme nové heslo a aktualizuje místní soubor passwd. Tento postup není možný s využitím systému NIS, protože tento soubor již není lokálně dostupný. Chce-li si uživatel změnit heslo, nepomůže mu ani přihlášení k serveru NIS.
Proto systém NIS poskytuje náhradu k příkazu passwd, a to příkaz yppasswd, který provádí analogickou změnu hesla, avšak při spuštěném systému NIS. Chcete-li změnit heslo na hostiteli serveru, spojí se příkaz yppasswd za pomoci volání RPC s démonem yppasswdd, který již na tomto hostiteli běží, a poskytne mu aktualizované informace o heslu. Příkaz yppasswd se obvykle nainstaluje místo klasického příkazu passwd za pomoci následující sekvence příkazů:
# cd /bin
# mv passwd passwd.old
# ln yppasswd passwd
Současně musíte na serveru nainstalovat démona rpc.yppasswdd a spustit ho ze skriptu rc.inet2. Tyto úpravy efektivně skryjí před vašimi uživateli všechny změny, které vyžaduje systém NIS.
Zatím neexistuje žádná podpora systému NIS pro systémy, které používají balík pro stínová hesla. John F. Haugh, autor stínového balíku, teprve nedávno uvolnil na adrese comp.sources.misc verzi knihovny se stínovými funkcemi, kterou vložil do knihovny GPL, jež je součástí projektu GNU. Tato knihovna již obsahovala určitou podporu pro systém NIS, ale ta stále ještě není kompletní a její soubory zatím nebyly přidány do standardní knihovny C. Na druhou stranu může uveřejnění informací ze souboru /etc/shadow pomocí systému NIS určitým způsobem zmařit účel použití stínového balíku.
I když funkce pro vyhledávání hesel v balíku NYS nepoužívají mapu shadow.byname nebo nějakou podobnou mapu, podporuje balík NYS použití souboru /etc/shadow. Když je zavolána příslušná implementace příkazu getpwnam z balíku NYS, který má vyhledat informace vztahující se k danému přihlašovacímu jménu, budou dotazovány ty prostředky, které jsou uvedeny v záznamu passwd v souboru nsswitch.conf. Služba nis jednoduše vyhledá název na serveru NIS v mapě passwd.byname. Avšak služba files zkontroluje, zda je přítomen soubor /etc/shadow, a pokud ano, pokusí se ho otevřít. Jestliže takový soubor neexistuje nebo pokud nemá uživatel práva root, vrátí se služba files k tradičnímu chování a informace o uživateli se budou vyhledávat v souboru /etc/passwd. Pokud však soubor shadow existuje a jde-li otevřít, vytáhne si z něho balík NYS uživatelovo heslo. Funkce getpwuid je implementována obdobným způsobem. Tímto způsobem se binární soubory zkompilované pomocí balíku NYS zřetelně vypořádají s místní instalací stínového balíku.
Používáte-li kód klienta, který je v současné době součástí standardní knihovny libc, bude konfigurace klienta systému NIS nepatrně odlišná. K vysílání směrem k aktivním serverům se používá démon ypbind, takže se informace nezískávají z konfiguračního souboru. Z toho důvodu je třeba se ujistit, že při zavádění systému dochází ke spouštění démona ypbind.
Tento démon musí být spuštěn po nastavení domény systému NIS a po spuštění mapovače portů RPC. Použití příkazu ypcat pro otestování serveru by pak mělo fungovat výše popsaným způsobem.
Nedávno byl hlášen velký počet chyb, při kterých systém NIS selhal a vypsal chybovou zpsávu "clntudp_create: RPC: portmapper failure - RPC: unable to receive". Tato zpráva se objevovala z důvodu nekompatibility ve způsobu, jakým démon ypbind sděluje funkcím v knihovně informace o vazbách. Obstarání posledních zdrojových kódů utilit systému NIS a jejich následná rekompilace by měly tento problém vyřešit.
Také způsob, jakým se tradiční systém NIS rozhoduje, zda a jak má připojit informace systému NIS k informacím z místních souborů, se liší od způsobu, který používá balík NYS. Chcete-li například, aby systém NIS používal mapy s hesly, je třeba do souboru své mapy /etc/passwd přidat následující řádek:
+:*:0:0:::
Tento výraz označuje místo, kam mají funkce pro vyhledávání hesla "vložit" mapy systému NIS. Vložíte-li podobnou řádku (bez závěrečných dvojteček) do souboru /etc/group, zjistíte stejnou funkci pro mapy group.*. Chcete-li používat mapy hosts.* distribuované pomocí systému NIS, změňte řádek order v souboru host.conf. Když chcete používat například systémy NIS, DNS a soubor /etc/hosts (v tomto pořadí), musíte změnit řádek order následovně:
order yp bind hosts
V současné době nepodporuje tradiční implementace systému NIS žádné další mapy.