Zabudnute schopnosti: NIS a.k.a network information service

21.03.2010 23:21 | blackhole_ventYl

Kedysi, ked sa este systemovy software pisal na to, aby vedel to, co sa po nom pozaduje a nie, aby vedel milion 5 inych veci, ale to, na co mal byt, nevedel pre istotu ani nahodou, sa ujovia zo Sunu pasovali s problemom, ako si po dalsej kalbe zapamatat, z ktoreho ze stroja v ITcku sa rsyncuje /etc/passwd na ostatne stroje a tak radsej vymysleli NIS.

Network Information Service, alebo aj Yellow Pages (ale za toto by britska posta stiahla Sun z koze) je dnes sice uz hodne prezita zalezitost, avsak v prostredi, kde je treba s minimalnou snahou rozchodit nejaky druh centralnej spravy uzivatelov, sa moze hodit, pretoze jeho konfiguracia je velmi jednoducha: v podstate netreba konfigurovat skoro nic.

V prvom rade existuje niekolko verzii NIS. Oznacuju sa cca ako NIS, NYS a NIS+. V Linuxe je vsak vyber pomerne lahky, pretoze NIS je tak archaicky, ze ho dnes uz prakticky uplne vytlacil NYS a v dobe, ked sa pre NIS+ pisala podpora, bol pochovany samotnym SUN-om v prospech LDAPu. Nicmene ak by niekto mal chut, client-side podpora pre NIS+ na Linuxe existuje, staci si splasit nejaky server so Solarisom 9.

NIS je klient-server zalezitost, ktora umoznuje centralnu spravu niekolkych databaz bezne sa vyskytujucich na Unixovych strojoch, ako passwd, shadow, groups, hosts, networks, protocols, atd. atd.

Co su vsetko zalezitosti, ktore sa dnes bezne pouzivaju, ale uz po nich nestekne ani pes a polka rychlopecenych adminkov ani netusi, ze wtf.

Vyhoda NIS-u je, ze ak mame glibc, klientsky a serverovy software (slackware ma, neviem ako ine distra), spojazdnenie NIS-u je zalezitostou maximalne niekolkych minut.

Absolutnou podmienkou je spusteny RPC portmapper, podobne ako pri NFS. Na toto by v distribucii mal existovat standardny startovaci skript.

Potom je vcelku vhodne nastavit si nazov NIS domeny, pretoze NIS si svoj server hlada podobne, ako Samba kvakanim broadcastov do siete (aj ked NIS-u uz sa pri tomto da seknut po prstoch)

/bin/nisdomainname mojadedina

Na strane NIS servera treba spravit niekolko malo zakladnych nastaveni:
v prvom rade treba v subore /var/yp/securenets nastavit masky a adresy sieti, v ktorych NIS domena figuruje. Kedze sa jedna este o neautentifikovanu verziu protokolu, ak sa toto nastavenie odflakne, moze si ktokolvek citat akekolvek nis-om exportovane data.
Po druhe je potrebne v subore /var/yp/Makefile nastavit, ake vsetky informacie ma NIS exportovat. Je to klasicky Makefile. Obsahuje target all, ktory obsahuje zoznam pseudotargetov, ktore generuje. Ich nazvy v zasade pomenuvavaju textove unixove databazy, ktore dany pseudotarget generuje (napriklad passwd, group, hosts, etc). Pre pouzitie na centralnu spravu uzivatelov v sieti by standardne nastavenie malo stacit, passwd shadow a group je povoleny takmer vzdy.

Pred prvym spustenim servera, ale aj po kazdej zmene je treba rucne spustit prikaz ypinit (obvykle sedi skryty niekde v /usr/lib/yp/):

/usr/lib/yp/ypinit -m

(to -m tam znamena master, NIS umoznuje skonstruovat master-slave architekturu aj pre servery a tak backupovat pripadny zlozeny server)

Potom uz ostava len nastavit a spustit samotny NIS server. Jedinym pre zaciatok potrebnym nastavenim je povolit resolvovanie domenovych nazvov na serveri voci standardnemu DNS resolveru, co sa vykona zapisanim riadka

dns: yes

(pozor na medzeru) do suboru /etc/ypserv.conf. Potom uz ostava len spustit server (/usr/sbin/ypserv).

Na strane klienta je to s nastaveniami snad este jednoduchsie. Rovnako, ako na serveri je treba nastavit domenu, mat spusteny RPC portmapper a v subore /etc/yp.conf urcit, kto je pre tuto domenu server (alternativne sa da klient spustit v broadcastovom rezime, ale kto by to chcel, ze?):

ypserver 10.20.30.40

Potom ostava iba spustit ypbind (/usr/sbin/ypbind). Overit jeho mozno napriklad pomocou prikazu ypcat (/usr/bin/ypcat passwd.byname by mal vratit databazu passwd tak, ako bola vytvorena na NIS serveri.

Tym je sice NIS rozchodeny, ale ako by jeden zistil, evidentne ho ma system v pazi. Je to tym, ze este je nutne glibc povedat, ze ho ma aj zacat pouzivat. Na to sluzi subor /etc/nsswitch.conf, ktory urcuje, ktorou pristupovou metodou sa ma ktora databaza dotazovat (netrufnem si odhadnut, aky stupen anarchie v ignoracii tohto suboru sposobil PAM a ako velmi bude robit obstrukcie, ked sa zedituje).
Standardne je vsade hodnota files, pripadne compat, pri hostoch aj hodnota dns. Pre centralnu spravu uzivatelov su zaujimave riadky zacinajuce passwd a group. Ich povodnu hodnotu compat, alebo files mozno zmenit na:

* nis - povoli prihlasenie iba uzivatelov, ktorych pozna NIS server. Ak je NIS server nedostupny, nikto sa neprihlasi (ani root)
* nis files - okrem uzivatelov definovanych v NIS databaze je mozne prihlasit sa aj pomocou zaznamu v lokalnom /etc/passwd subore
* files nis - podobne, ako predosle, ale primarnym autentifikacnym tokenom bude subor, az potom NIS databaza

Po ulozeni zmeneneho suboru /etc/nsswitch.conf by malo byt mozne sa prihlasit s loginom definovanym v NIS databaze, ktory nie je v lokalnom /etc/passwd uvedeny. Samozrejme to predpoklada existenciu uzivatelskeho homediru tak, ako je uvedeny na NIS serveri, co je mozne implementovat pomocou NFS sietovych diskov a automountu, ale to je zasa iny pribeh.