NIS/YP
1. Co to jest? NIS formalnie znany jest jako Yellow Pages (yp lub po polsku Żółte strony aczkolwiek żadko używa się tę nazwę), ale z powodu naruszeń praw autorskich, SUN forsował zmianę nazwy. Jest to system bazujący na technologi RPC i technologi client/server, który pozwala maszynom znajdującym się w tej samej domenie co NIS sharować wspólne ustawienia plików konfiguracyjnych. Pozwala to administratorowi ustawić kliencki system NIS z minimalną konfiguracją, oraz dodawać, usuwać lub modyfikować dane konfiguracyjne z pojedyńczej lokacji. Jest to rozwiązanie podobne do systemu domen Windows NT; chociaż wewnętrzna implementacja tych dwóch nie jest jednakowa, postawowa funkcjonalność może być porównywana. 2. Warunki/Procedury które powinienneś znać Opisane jest tutaj kilka warunków i ważnych procesów które będzie trzeba wykonać podczas przygotowań do implementacji NIS'a na FreeBSD, niezależnie czy będziesz chciał stworzyć serwer czy też uaktywnić tylko klienta. Nazwa domenowa NIS. Na głównym serwerze NIS i na wszyskich jego klientach ( włączając w to zapasowe serwery) musi być nazwa domenowa NIS. Podobnie do NT, nazwy domenowe NIS'a nie mają nic wspólnego z DNS'em. portmap. Musi być uruchomiony z rozkazem odblokowania RPC ( Remote Procedure Call, który jest sieciowym protokołem używanym przez NIS). Jeżeli portmap nie jest uruchomiony, nie będzie możliwe uruchomienie ani klienta ani serwera NIS. ypbiond. Ypbind podłącza klienta NIS do serwera. Pobiera z systemu nazwę domenową, i używająć RPC podłącza go do serwera. Ypbind jest podstawą komunikacji pomiędzy klientem a serwerem w środowisku NIS; jeżeli u klienta ypbind nie będzie działał, nie będzie możliwy dostęp do serwera NIS. ypserv. Ypserv, powinien być uruchamiany jedynie na serwerze. Jeżeli ypserv przestanie działać, serwer nie będzie mógł dłużej odpowiadać na zapytania (miejmy nadzieje, że istnieje zapasowy serwer który przejmie je na siebie). Uwaga: Istnieją pewne implementacje NIS'a (ale FreeBSD nie jest jedną z nich), które nie będą próbowały ponownie łączyć się z innym serwerem jeżeli wcześniej łączyły się z innym. Często, jedynym pomocnym wyjściem z takiej sytuacji jest restart procesu serwera (lub całego serwera) lub też procesu ypbind na stacji klienckiej. rpc.yppasswdd. Rpc.yppasswdd, jest kolejnym procesem, który powienien być uruchamiany jedynie na serwerze. Jest to daemon który pozwala stacjom klienckim na zmiane ich haseł NIS. Jeżeli ten daemon nie będzie uruchomiony, użytkownicy będą musieli logować się do serwera i tam zmieniać swoje hasło. 3. Jak to działa? Istnieją trzy typy hostów w środowisku NIS: główny serwer, zapasowy serwer i klient. Serwer działa jako centralne repozytorium dla informacji konfiguracyjnych hostów. Główne serwery przetrzymują kopie tychże informacji, a zapasowe serwery mirrorują te informację aby zapewnić redundancję. Klienci mają zaufanie do serwerów że te dostarczą im wymagane informacje. 3.1. Typy maszyn Główny serwer NIS. Serwer ten, analogicznie do Windows NT, utrzymuje pliki używane przez wszyskich klientów. Passwd, group i inne różne pliki używane przez klienta NIS żyją na głównym serwerze. Uwaga: Jest możliwe aby jedna maszyna była głównym serwerem dla więcej niż jednej domeny NIS. Aczkolwiek nie jest to zawarte w tym wprowadzeniu, które zajmuje się relatywnie środowiskami NIS o małej skalowalności. Zapasowy serwer NIS. Analogiczny dla zapasowego kontrolera domen NT, zapasowy serwer NIS utrzymuje kopie danych z głównego serwera. Zapasowy server NIS dostarcza redundancji, któta jest ważną składową środowiska. Pomaga także zrównoważyć wykorzystanie głównego serwera: Klienci zawsze podłączają się do serwera, który odpowie pierwszy, i obejmuje zapasowy-serwer-odpowiedź. Klient NIS. Klient NIS, jak większość stacji roboczych NT, autoryzuje poprzez serwer NIS aby móc się zalogować do systemu. 4. Używanie NIS/YP Sekcja ta będzie traktować o ustawieniach prostego środowiska dla NIS. Uwaga: Sekcja ta zakłada że używasz wersji systemu FreeBSD 3.3 lub późniejszej. Instrukcje zawarte tutaj powinny prawdopodobnie działać w każdej wersji systemu powyżej 3.0, ale nie ma żadnych gwarancji że tak będzie naprawdę. 4.1. Planowanie Załóżmy że jesteś administratorem w małym labolatorium uniwersyteckim. Labolatorium to, zawieta 15 komputerów z systemem FreeBSD, i nie posiada obecnie centralnego punktu administracyjnego; każda maszyna ma własne pliki /etc/passwd i /etc/master.passwd. Pliki te są utrzymywane w zgodności pomiędzy maszynami dzięki manualnym interwencjom; obecnie gdy dodasz użytkownika do labolatorium musisz uruchomić polecenie adduser na wszystkich 15 maszynach. Jasno mówiąc, wymaga to zmiany, więc zdecydowałeś się zacząć używać w labolatorium NIS, używając dwóch komputerów jako serwery. Więc, teraz konfiuracja w labolatorium wyglądać będzie mniejwięcej tak: Jeżeli ustalisz schemat NIS za pierwszym razem, dobrze jest dokładnie przemyśleć jak chcesz go wykonać. Nie ma znaczenia rozmiar twojej sieci, jest kilka decyzji które będziesz musiał podjąć. 4.1.1. Wybór nazwy domenowej NIS Nie musi to być nazwa domeny które używasz. Bardziej trafnym określeniem jest `` nazwa domenowa NIS''. Gdy klient wysyła zapytanie o informacje, zawiera ona domenę NIS która jest jej częścią. Mówi nam to o tym który z wielu serwerów w jednej sieci powinien odpowiedzieć na to zapytanie. Myśląc o nazwie domenowej NIS myśl jako o grupie hostów którę będziesz z nią kojarzył. Niektóre organizacje wybierają ich domene internetową jako nazwę domenową dla NIS. Nie jest to zalecanym rozwiązaniem, ponieważ może przysparzać problemów, podczas rozwiązywania problemów w sieci lokalnej. Nazwa domenowa NIS powinna być unikalna w Twojej sieci i jest pomocne gdy opisuje ona grupę komputerów którą reprezentuje. Dla przykładu departament sztuki w Acme Inc. może znajdować się w domenie "acme-art". Dla przykładu, przyjmujemy że wybrałeś nazwę test-domain. Aczkolwiek niektóre z systemów operacyjnych (zwłaszcza SunOS) używają ich nazwy domenowej NIS jako ich domeny internetowej. Jeżeli jedna lub więcej maszyn w twojej sieci będzie posiadała tę restrykcję, będziesz musiał używać domeny internetowej jako twojej nazwy domenowej NIS. 4.1.2. Wymagania sprzętowe serwera Oto kilka rad dotyczących wyboru komputera na serwer NIS. Jedną z niefortunnych myśli na temat NIS jest poziom zależności klienta od serwera. Jeżeli klient nie będzie mógł się połączyć z serwerem jego domeny, bardzo często komputer taki staje się bezużyteczny. Btak informacji na temat użytkowników i grup powoduje iż większość systemów tymczasowo zamraża się. Wiedząc o tym powinienneś mieć pewność że wybierasz komputer który nie jest często restartowany. Idealnym rozwiązaniem jest wybranie maszyny która działać będzie tylko jako serwer NIS i będzie do tego celu dedykowana. Jeżeli twoja sieć nie jest mocno wykorzystywana, jest dopuszczalne aby umieścić serwer NIS na komputerze na którym działają inne serwisy, wiedząc jednak że w przypadku niedostępności serwera NIS, klienci staną się bezużyteczni. 4.2. Serwery NIS Kanoniczne kopie wszystkich informacji używanych przez NIS są przetrzymywane na jednej maszynie nazywanej głównym serwerem NIS. Baza danych używana do przetrzymywania informacji nazywa się mapą NIS. W FreeBSD, mapa ta przetrzymywana jest w /var/yp/[nazwa domenowa] gdzie [nazwa domenowa] jest nazwa domeny NIS którą obsługuje. Pojedyńczy serwer nis może obsługiwać kilka domen naraz, jest to możliwe poprzez posiadanie kilku katalogów, po jednym dla każdej obsługiwanej domeny. Każda domena musi posiadać swoją niezależną mapę. Główny i zapasowy serwer NIS obsługuje wszystkie zapytania z daemona ypserv. Ypserv jest odpowiedzialny za otrzymywanie przychodzących zapytań od klientów, translacje domen i naz map na ścieżki do odpowiednich baz danych i plików oraz za transmisję danych z baz spowrotem do klientów. 4.2.1. Ustawienia głównego serwera NIS Ustawiając główny server NIS może on być relatywnie prosto cofnięty, w zależności od Twoich potrzeb. FreeBSD dostarcza ci wspatcie dla NIS out-of-the-box. Wszystko czego potrzebujesz to dodać następujące linie do pliku /etc/rc.conf, a FreeBSD resztę zrobi za Ciebie. Linia ta ustawia nazwę domenową NIS na test-domain w konfiguracji sieci ( po restarcie ). Ta linia przekaże systemowi aby uruchomił serwer NIS podczas następnego podnoszenia sieci. Ta linia uruchamia daemona rpc.yppasswdd, który pozwala na zmianę haseł użytkowników z każdej maszyny klienckiej. Teraz wszystkim co musisz zrobić to uruchomić polecenie /etc/netstart jako superuser. Ustawi ono wszystko dla Ciebie, używając wartości zdefiniowanych w /etc/rc.conf. 4.2.2. Inicjalizacja mapy NIS Mapy NIS są bazami, która przetrzymywane są w katalogu /var/yp. Są one generowane z plików konfiguracyjnych z katalogu /etc na głównym serwerze NIS, z jednym wyjątkiem: plikiem /etc/master.passwd. Dobrą odpowiedzią na pytanie dlaczego jest: nie chcesz propagować hasła do twojego konta root ani do żadnego innego konta administracyjnego do wszystkich serwerów w domenie NIS. Dlatego, przed inicjalizacją map NIS powinienneś: Powinienneś usunąc wszystkie wpisy dotyczący kont systemowych (bin, tty, kmem, games, etc), najlepiej usunąć wszystkie konta które nie chcesz aby były propagowane do klientów NIS ( dla przykładu konto root i wszystkie inne konta o UID=0). Uwaga: Upewnij się że plik /var/yp/master.passwd ma odpowiednie prawa i może być czytany jedynie przez właściciela (mode 600). Użyj polecenia chmod jeżeli jest to konieczne. Gdy już skończysz, nadejdzie czas inicjalizacji map NIS. FreeBSD zawiera skrypt o nazwie ypinit, który zrobi to dla Ciebie. Skrypt ten znajduje się w większości systemów UNIX, ale nie we wszystkich. W Digital Unix/Compaq Tru64 Unix nazywa się on ypsetup. Ponieważ będziemy generować mapy dla głównego serwewa, użyjemy opcji -m dla ypinit. Aby wygenerować mapy NIS, zakładamy że juz wykonałeś kroki poniżej, uruchom: ypinit powinien stworzyć /car/yp/Makefile z /var/yp/Makefile.dist. Gdy stworzy, plik ten zakłada że operujesz w środowisku z jednym serwerem NIS. Jeżeli chcesz aby w domenie test-domain istniał zapasowy serwer NIS musisz wyedytować plik /var/yp/Makefile: Następnie powinienneś zakomentować linię w której jest napisane 'NOPUSH = "True"' (jeżeli nie jest ona zakomentowana). 4.2.3. Konfiguracja zapasowego serwera NIS Konfiguracja zapasowego serwera NIS jest jeszcze bardziej prosta niż konfiguracja serwera głównego. Zaloguj sie do zapasowego serwera i wyedytuj plik /etc/rc.conf tak jak to było robione poprzednio. Jedyną różnicą jest to że teraz musimy uruchomić ypinit z opcją -s. Opcja ta wymaga podania nazwy głównego serwera NIS, więc nasza komenda powinna wyglądać mniejwięcej tak: Teraz powinienneś mieć katalog o nazwie /var/yp/test-domain. Copia mapy NIS z głównego serwera powinna znajdować się w tym katalogu. Powinienneś mieć pewność że dane będą zawsze aktualne. Poniższe wpisy w /etc/crontab na zapasowym serwerze będą wykonywały te zadanie: Te dwie linie zmuszają zapasowy serwer do synchronizacji map z mapami NIS głównego serwera. Chociaż nie jest to obowiązkowe, ponieważ główny serwer próbuje mieć pewność że wszystkie zmiany w jego mapach NIS są komunikowane do serwerów zapasowych, informacje o hasłach są konieczne dla systemu są niezależne dla serwera, dlatego dobrym pomysłem jest wymuszanie uaktualnień. Jest to bardzo ważne w zapchanych sieciach gdzie uaktualnienia map nie zawsze są kompletne. Teraz uruchom polecenie /etc/netstart na zapasowym serwerze, które uruchomi serwer NIS. 17.7.4.3. NIS Clients Klient NIS ustanawia połączenie z serwerem NIS używając daemona ypbind. Sprawdza on standardową nazwę domenową systemu, i zaczyna rozgłaszać zapytania RPC w sieci lokalnej. Zapytania te specyfikuje nazwa domeny dla której ypbind stara się ustanowić połączenie. Jeżeli serwer który został skonfigurowany do obsługi zapytań dla danej domeny, odpowie do ypbind, który poszukuje adresu serwera. Jeżeli istnieje kilka dostępnych serwerów( serwer główny i kilka serwerów zapasowych dla przykładu), ypbind będzie używał połączenia z adresem od którego odpowiedź przyjdzie jako pierwsza. Od tego momentu, wszystkie zapytania wysyłane przez klienta do serwera NIS będą kierowane właśnie do tego serwera. Ypbind będzie sporadycznie pingował serwer aby upewnić się iż działa on nadal. Jeżeli przestanie otrzymywać odpowiedzi od dotychczasowego serwera, w określonym czasie, ypbind zamarkuje używany dotychczas serwer jako 'unbound' i rozpocznie ponowne rozgłaszanie w nadziei na znalezienie innego serwera. 4.3.1. Konfiguracja klienta Konfiguracja komputera z FreeBSD aby był klientem NIS może on być relatywnie prosto cofnięta. Wyedytuj plik /etc/rc.conf i dodaj następujące linie aby ustawić nazwę domenową NIS i uruchomić daemona ypbind podczas podnoszenia sieci: Aby zaimportować wszystkich użytkowników z serwera NIS, dodaj poniższą linie do pliku /etc/master.passwd , używając polecenia vipw: Uwaga: Linia ta powinna pozwolić wszystkim z poprawnym kontem w mapie haseł na serwerze NIS na dostęp do konta. Istnieje wiele możliwości konfiguracji klienta NIS poprzez zmianę tej lini. Więcej informacji znajduje się w sekcji netgroups. Dla większej ilości informacji przeczytaj książkę wydawnictwa O'Reilly "Managing NFS and NIS". Aby zaimportować wszystkie wpisy dotyczące grup z serwera NIS dodaj poniższą linie do pliku /etc/group: Po zakończeniu tych czynności, powinienneś móc uruchomić ypcat passwd i zobaczyć hasła z serwera NIS. 5. Bezpieczeństwo NIS Generalnie, każdy zdalny użytkownik może użyć RPC i otrzymać zawartość mapy NIS, zakładając że zdalny użytkownik zna nazwę domenową. Aby zabezpieczyć się przed nieautoryzowanymi transakcjami, ypserv obsługuje securenets, który może być użyty do wprowadzenia restrykcji w dostępie ustalanych dla hostów. Podczas startu, ypserv próbuje ładować informacje dla securenets z pliku /var/yp/securenets. Uwaga: Ścieżka ta może zostać zmieniona poprzez podanie jej w opcji -p. Plik ten zawiera wpisy stałe dla specyfikacji sieci i maski sieci oddzielone białymi spacjami. Linie zaczynające się od znaku "#" są uważane za komentaż. Prosty plik może wyglądać tak: Jeżeli ypserv otrzymuje zapytanie z jednego z adresów znajdujących się w pierwszej regule, obsłuży je normalnie. Jeżeli adres nie zgadza się z tą tegułą, zapytanie to zostanie zignorowane a ostrzeżenie zostanie zapisane w pliku dziennika. Jeżeli plik /var/yp/securenets nie istnieje, ypserv będzie pozwalał na połączenie od wszystkich komputerów. Ypserv obsługuje także pakiet tcpwrapper'a Wietse Venema. Pozwala to administratorowi na używanie pliku konfiguracyjengo tcpwrappera dla kontroli dostępu zamiast /var/yp/securenets. Uwaga: Dopóki obydwa te mechanizmy kontroli dostępu dostarczają pewnego bezpieczeństwa, one, jak test uprzywilejowanych portów, są podatne na ataki metodą IP spoofing. Wszystkie porty obsługiwane przez NIS powinienneś blokować na swoim firewall'u. Serwery używające /var/yp/securenets mogą nieprawidłowo legitymować klientów NIS z starszymi implementacjami protokołu TCP/IP. Niektóre z tych implementacji ustawiają wszyskie bity hostów na zero podczas rozgłaszania i/lub żle zauważają maskę podsieci gdy obliczają adres broadcastowy. Gdy niektóre z tych problemów mogą być poprawione poprzez zmianę konfiguracji klienta, inne z nich mogą ustąpić dopiero po opuszczeniu /var/yp/securenets. Używanie /var/yp/securenets na serwerach z starą implementacją TCP/IP jest naprawdę złym pomysłem, i może doprowadzić do straty funkcjonalności NIS w dużej części twojej sieci. Aby używać pakietu tcpwrapper podnieść bezpieczeństwo serwera NIS. Standardowe ustawienia opóźnień mogą być niewystarczające dla programów klientów, zwłaszcza podczas dużego nasycenia sieci lub wolnych serwerów NIS. Jeżeli jeden lub więcej twoich klientów posiada takie symptomy powinienneś przekształcić jedną z maszyn na kolejny zapasowy serwer NIS i zmusić go do bindowania dla samego siebie. 6. Zabranianie dostępu niektórym użytkownikom W twoim labolatorium, znajduje się komputer nazwany basie przeznaczony jedynie jako stacja robocza dla wydziału. Nie chcemy aby ta maszyna znajdowała się poza naszą domeną NIS, obecnie passwd na głównym serwerze NIS zawiera konta zarówno dla wydziału jak i konta dla studentów. Co możemy zrobić? Istnieje sposób aby zablokować dostęp wybranym użytkownikom logującym się do systemu,nawet jeżeli ich wpis znajduje się w bazie głównego serwera NIS. Aby to zrobić, wszystko co musisz wykonać to dodanie lini -username na koniec pliku /etc/master.passwd na stacji klienta NIS, gdzie username to nazwa użytkownika któremu chcesz zabronić dostępu. W tym celu najlepiej użyć narzędzia vipw, ponieważ vipw sprawdzi wprowadzone przez ciebie zmiany w pliku /etc/master.passwd i automatycznie przebuduje bazę haseł gdy skończysz edycję. Dla przykładu, jeżeli chcielibyśmy zabronić użytkownikowi bill dostępu do stacji basie powinniśmy wykonać następujące czynności:
NIS, z ang. Network Information Service, został stworzony przez Sun Microsystems aby scentralizować administrowanie systemami UNIX'owymi (orginalnie SunOS). Teraz zasadniczo staje się on standardem; wszystkie ważniejsze systemy (Solaris, HP-UX, AIX, Linux, NetBSD, OpenBSD, FreeBSD, etc) wspierają NIS.
Informacje z wielu plików mogą być sharowane w następujący sposób. master.passwd, group i pliki hosts są wspólnie sharowane poprzez NIS. Kiedy tylko klient potrzebuje jakiś informacji, które normalnie znajdowałyby się w jego plikach lokalnuch, wysyła zapytanie do serwera z którym jest połączony aby te informacje otrzymać.
Nazwa Komputera Adres IP Rola maszyny
ellington 10.0.0.2 NIS master ( główny serwer NIS )
coltrane 10.0.0.3 NIS slave ( zapasowy serwer NIS)
basie 10.0.0.4 Faculty workstation
bird 10.0.0.5 Client machine
cli[1-11] 10.0.0.[6-17] Other client machines
nisdomainname="test-domain"
nis_server_enable="YES"
nis_yppasswdd_enable="YES"
# cp /etc/master.passwd /var/yp/master.passwd
# cd /var/yp
# vi master.passwd
ellington# ypinit -m test-domain
Server Type: MASTER Domain: test-domain
Creating an YP server will require that you answer a few
questions. Questions will all be asked at the beginning
of the procedure.
Do you want this procedure to quit on non-fatal errors?
[y/n: n] n
Ok, please remember to go back and redo manually whatever
fails. If you don't, something might not work.
At this point, we have to construct a list of this domains
YP servers. rod.darktech.org is already known as master
server. Please continue to add any slave servers, one per
line. When you are done with the list, type a
ellington# vi /var/yp/Makefile
coltrane# ypinit -s ellington test-domain
Server Type: SLAVE Domain: test-domain Master: ellington
Creating an YP server will require that you answer a few
questions. Questions will all be asked at the beginning
of the procedure.
Do you want this procedure to quit on non-fatal errors?
[y/n: n] n
Ok, please remember to go back and redo manually whatever
fails. If you don't, something might not work.
There will be no further questions. The remainder of
the procedure should take a few minutes, to copy the
databases from ellington.
Transferring netgroup...
ypxfr: Exiting: Map successfully transferred
Transferring netgroup.byuser...
ypxfr: Exiting: Map successfully transferred
Transferring netgroup.byhost...
ypxfr: Exiting: Map successfully transferred
Transferring master.passwd.byuid...
ypxfr: Exiting: Map successfully transferred
Transferring passwd.byuid...
ypxfr: Exiting: Map successfully transferred
Transferring passwd.byname...
ypxfr: Exiting: Map successfully transferred
Transferring group.bygid...
ypxfr: Exiting: Map successfully transferred
Transferring group.byname...
ypxfr: Exiting: Map successfully transferred
Transferring services.byname...
ypxfr: Exiting: Map successfully transferred
Transferring rpc.bynumber...
ypxfr: Exiting: Map successfully transferred
Transferring rpc.byname...
ypxfr: Exiting: Map successfully transferred
Transferring protocols.byname...
ypxfr: Exiting: Map successfully transferred
Transferring master.passwd.byname...
ypxfr: Exiting: Map successfully transferred
Transferring networks.byname...
ypxfr: Exiting: Map successfully transferred
Transferring networks.byaddr...
ypxfr: Exiting: Map successfully transferred
Transferring netid.byname...
ypxfr: Exiting: Map successfully transferred
Transferring hosts.byaddr...
ypxfr: Exiting: Map successfully transferred
Transferring protocols.bynumber...
ypxfr: Exiting: Map successfully transferred
Transferring ypservers...
ypxfr: Exiting: Map successfully transferred
Transferring hosts.byname...
ypxfr: Exiting: Map successfully transferred
coltrane has been setup as an YP slave server without any
errors. Don't forget to update map ypservers on ellington.
20 * * * * root /usr/libexec/ypxfr passwd.byname
21 * * * * root /usr/libexec/ypxfr passwd.byuid
nisdomainname="test-domain"
nis_client_enable="YES"
+:::::::::
+:*::
# allow connections from local host -- mandatory
127.0.0.1 255.255.255.255
# allow connections from any host
# on the 192.168.128.0 network
192.168.128.0 255.255.255.0
# allow connections from any host
# between 10.0.0.0 to 10.0.15.255
# this includes the machines in the testlab
10.0.0.0 255.255.240.0
basie# vipw
[dodać -bill na końcu lini,zakończyć edycję]
vipw: rebuilding the database...
vipw: done
basie# cat /etc/master.passwd
root:[password]:0:0::0:0:The super-user:
/root:/bin/csh
toor:[password]:0:0::0:0:The other super-user:
/root:/bin/sh
daemon:*:1:1::0:0:Owner of many system processes:
/root:/sbin/nologin
operator:*:2:5::0:0:System &:
/:/sbin/nologin
bin:*:3:7::0:0:Binaries Commands and Source,,,:
/:/sbin/nologin
tty:*:4:65533::0:0:Tty Sandbox:
/:/sbin/nologin
kmem:*:5:65533::0:0:KMem Sandbox:
/:/sbin/nologin
games:*:7:13::0:0:Games pseudo-user:
/usr/games:/sbin/nologin
news:*:8:8::0:0:News Subsystem:
/:/sbin/nologin
man:*:9:9::0:0:Mister Man Pages:
/usr/share/man:/sbin/nologin
bind:*:53:53::0:0:Bind Sandbox:
/:/sbin/nologin
uucp:*:66:66::0:0:UUCP pseudo-user:
/var/spool/uucppublic:/usr/libexec/uucp/uucico
xten:*:67:67::0:0:X-10 daemon:
/usr/local/xten:/sbin/nologin
pop:*:68:6::0:0:Post Office Owner:
/nonexistent:/sbin/nologin
nobody:*:65534:65534::0:0:Unprivileged user:
/nonexistent:/sbin/nologin
+:::::::::
-bill
basie#
7. Używanie netgroups
The netgroups part was contributed by Udo Erdelhoff
Metoda pokazana w poprzednim rozdziale zdaje egzamin tylko w przypadku gdy chcesz stosować specjalne zasady dla małej ilości użytkowników. W większych sieciach, zapomnisz o blokadzie dostępu dla niektórych użytkowników na strategicznych komputerach, lub będziesz musiał modyfikować ich konfigurację osobno, tracąc większość korzyści jakie daje NIS czyli scentralizowaną administrację.
Rozwiązanie twórców NIS dla tego problemu nazywa się 'netgroups'. Ich propozycja i semantyka może być porównywana z normalnymi grupami używanymi w systemach Unix. Podstawową różnicą jest brak oznakowania numerycznego i zdolność definiowania 'netgroup' zawierających zarówno nazwy użytkowników jak i inne 'netgrupy'.
Netgroups zostały zaprojektowane obsługiwać duże, kompleksowe sieci z setkami użytkowników i komputerów. Z jednej strony sa one świetnym rozwiązaniem dla takiej sytuacji. Z drugiej strony, kompleksowość ta prawie zawsze uniemożliwia wytłumaczenie (stworzenie) netgroups na naprawdę prostym przykładzie. Przykład używany w tym rozdziale demonstruje ten problem.
Załóżmy że wprowadzenie NIS do twojego labolatorium ujmuje twoje wyższe interesy. Twoim następnym zadaniem jest rozszerzyć domenę NIS aby objęła ona niektóre z innych komputerów w kampusie. Dwie tablice zawierają nazwy nowych użytkowników i komputery oraz ich opisy.
User Name(s) Description alpha, beta Normal employees of the IT department charlie, delta The new apprentices of the IT department echo, foxtrott, golf, ... Ordinary employees able, baker, ... The current interns Machine Name(s) Description war, death, famine, pollution Your most important servers. Only the IT employees are allowed to log onto these machines. pride, greed, envy, wraith, lust, sloth Less important servers. All members of the IT department are allowed to login onto these machines. one, two, three, four, ... Ordinary workstations. Only the real employees are allowed to use these machines. trashcan A very old machine without any critical data. Even the intern is allowed to use this box.
Jeżeli starałbyś się implementować te restrykcje blokując osobno każdego z użytkowników, musiałbyś dodać jedno linię -user dla każdego użytkownika z systemu który nie jest dopuszczony do zalogowania się do danego systemu. Jeżeli zapomniałbyś chociaż jednego wpisu, mógłbyś mieć problemy. Może to być wykonywane poprawnie podczas inicjacji, aczkolwiek jeżeli ewentualnie zapomnisz dodać linię dla nowego użytkownika w czasie codziennych operacji. Po wszystkim, Muprhy był optymistą.
Na podstawie tej sytuacji możemy przedstawić zalety oferowane przez netgroups. Każdy użytkownik nie musi być traktowany oddzielnie; przypisujesz użytkownika samego lub do grupy i pozwalasz lub zabraniasz wszystkim użytkownikom danej grupy możliwości zalogowania się do danego systemu. Jeżeli dodajesz nowy komputer, musisz jedynie zdefiniować restrykcje dotyczące grup mogących logować się do systemu. Jeżeli dodajesz nowego użytkownika, musisz go jedynie dodać do jednej lub kilku grup. Zmiany te są niezależne od innych; nigdy więcej `` dla każdej kombinacji użytkownika i komputera zrób...''. Jeżeli twoja konfiguracja NIS jest zaplanowana uważnie, będziesz musiał jedynie modyfikować główny plik konfiguracyjny aby przyznaż lub odebrać prawa dostępu do komputerów.
Pierwszym krokiem jest inicjacja mapy netrgoup NIS. Program ypinit dla FreeBSD nie tworzy jej standardowo, ale implementacna NIS obsługuje je jeżeli je stworzymy. Aby stworzyć pustą mapę, wpisz poprostu
ellington# vi /var/yp/netgroup
i zacznij dodawać zawartość. Dla przykładu, stworzymy cztery grupy: IT employees, IT apprentices, normal employees i interns.
IT_EMP (,alpha,test-domain) (,beta,test-domain)
IT_APP (,charlie,test-domain) (,delta,test-domain)
USERS (,echo,test-domain) (,foxtrott,test-domain) \
(,golf,test-domain)
INTERNS (,able,test-domain) (,baker,test-domain)
IT_EMP, IT_APP etc. są nazwami grup. Każdy nawias dodaje jeden lub więcej kont użytkowników. Kolejne wpisy w nawiasach mają następujące znaczenie:
Nazwa hosta gdzie podany wpis jest prawidłowy. Jeżeli nie sprecyzujesz hostname, wpiś będzie poprawny dla wszystkich hostów. Jeżeli go podasz, będzie to horrorem i zupełnym zamieszaniem.
Nazwa konta które należy do netgroup.
Domena NIS dla konta. Możesz importować konta z innych domen NIS do twojej netgrupy jeżeli jesteś jednym z nieszczęśliwych kolegów z więcej niż jedną domeną NIS.
Każde z tych pól może zostać puste. Zobacz stronę podręcznika netgroup(5), aby dowiedzieć się więcej.
Uwaga: Nazwy netgrup dłuższe niż 8 znaków nie powinny być używane, a zwłaszcza jeżeli posiadasz komputery pracujące na innym systemie operacyjnym w obrębie twojej domeny NIS. Nazwy te rozróżniają wielkość liter; używanie dużych liter dla nazw grup jest najprostszym sposobem odróżniania użytkowników, komputerów i nazw grup.
Niektóre klienty NIS (inne niż FreeBSD) nie mogą posługiwać się netgrupami z dużą ilością wpisów. Dla przykładu, niektóre starsze wersje SunOS mają problemy jeżeli zawartość netgrup przewyższa 15 wpisów. Możesz obejść ten limit poprzez stworzenie kilku pod-netgrup z 15-stoma lub mniej użytkownikami i w prawdziwej netgrupie zawrzeć pod-netgrupy:
BIGGRP1 (,joe1,domain) (,joe2,domain) (,joe3,domain) [...] BIGGRP2 (,joe16,domain) (,joe17,domain) [...] BIGGRP3 (,joe32,domain) (,joe33,domain) BIGGROUP BIGGRP1 BIGGRP2 BIGGRP3
Możesz powtarzać ten proces jeżeli potrzebujesz więcej niż 255 użytkowników w obrębie jednej netgrupy.
Aktywowanie i dystrybucja nowej mapy NIS jest proste:
ellington# cd /var/yp
ellington# make
Wygeneruje to trzy mapy NIS netgroup, netgroup.byhost i netgroup.byuser. Użyj ypcat(1) do sprawdzenia jeżeli nowe mapy są dostępne:
ellington% ypcat -k netgroup
ellington% ypcat -k netgroup.byhost
ellington% ypcat -k netgroup.byuser
Wynik pierwszej komendy powinien być podobny do zawartości pliku /var/yp/netgroup. Drugie polecenie nie powinno wyświetlić wyniku jeżeli nie zdefiniowałeś hosta netgrupy. Trzecie polecenie może być użyte aby zdobyć listę netgrup dla użytkownika.
Konfiguracja klienta jest bardzo prosta. Aby skonfigurować wymianę z serwerem, musisz jedynie za pomocą vipw(8) zastąpić linię
+:::::::::
na
+@IT_EMP:::::::::
Teraz tylko dane użytkowników z netgrupy IT_EMP są importowane i tylko ci użytkownicy mogą się zalogować.
Niestety, istnieją także ograniczenia w działaniu funkcji ~ w shellu i wszystkich procedur konwertujących nazwy użytkownika na jego ID i odwrotnie. Innymi słowy, komenda cd ~user nie będzie działać a komenda ls -l spowoduje wyświetlenie zamiast nazwy użytkownika jego systemowego ID oraz komenda find . -user joe -print zakończy się niepowodzeniem wyświetlając komunikat ``No such user''. Aby to naprawić, będziesz musiał importować wszystkie wpisy użytkowników bez pozwolenia zalogowania się do systemu.
Może to być osiągnięte poprzez dodanie lini do pliku /etc/master.passwd. Linia ta powinna zawierać wpis +:::::::::/sbin/nologin, co znaczy ``Zaimportuj wszystkie wpisy ale zastąp wartość zmiennej SHELL na /sbin/nologin''. Metodą tą możesz zastępować każde pole z pliku /etc/master.passwd podczas jego importowania.
Ostrzeżenie: Upewnij się że linia +:::::::::/sbin/nologin znajduje się po lini +@IT_EMP:::::::::. W innym przypadku wszystkie konta importowane z serwera NIS będą miały wartość SHELL = /sbin/nologin.
Po dokonaniu tych zmian, będziesz musiał zmianiać tylko jedną mapę NIS jeżeli dojdzie nowy pracownik w dziale IT. Możesz używać podobnych ustawień dla mniej ważnych serwerów zastępując stary wpis +::::::::: w ich lokalnym /etc/master.passwd na wpis wyglądający mniejwięcej tak:
+@IT_EMP:::::::::
+@IT_APP:::::::::
+:::::::::/sbin/nologin
Odpowiednia linia dla swykłej stacji roboczej może wyglądać tak:
+@IT_EMP:::::::::
+@USERS:::::::::
+:::::::::/sbin/nologin
I wszystko będzie dobrze jeżeli za kilka tygodni nie nastąpi zmiana polityki: Departament IT rozpoczyna wewnętrzną dzierżawę. IT interns dostają pozwolenie na używanie normalnych stacji roboczych i mniejważnych serwerów, IT apprentices mogą logować się do głównych serwerów. Dodajesz nową grupę IT_INTERN, dodajesz nowych IT interns do tej grupy i rozpoczynasz zmiany konfiguracji na każdym komputerze...Jak mówi stare powiedzenie: ``Błędy podczas centralnego planowania prowadzą do globalnego nieładu''.
Zdolność do tworzenia netgrup z innych netgrup może być użyta aby powstrzymać sytuacje takie jak ta. Jedną możliwością jest stworzenia role-based netgrup. Dla przykładu, możesz stworzyć netgrupę nazwaną BIGSRV aby zdefiniować restrykcje dla ważnych serwerów i inną nazwaną SMALLSRV dla mniej ważnych serwerów oraz trzecią netgrupę nazwaną USERBOX dla normalnych sracji roboczych. Każda z tych netgrup zawietać będzie netgrupy które mogą logować się do tych komputerwów. Nowe wpisy w mapach netgrup NIS powinny wyglądać mniejwięcej tak:
BIGSRV IT_EMP IT_APP
SMALLSRV IT_EMP IT_APP ITINTERN
USERBOX IT_EMP ITINTERN USERS
Metoda definiowania restrykcji logowania działa dobrze w przypadku gdy możesz zdefiniować grupy komputerów z identycznymi restrykcjami. Niestety, jest to wyjątek, nie reguła. Większość razy, będziesz musiał definiować restrykcje te na każdym komputerze oddzielnie.
Definiowanie konkretnych maszyn dla netgrup jest inną możliwościa rozwiązania problemu opisanego powyżej.W tym przypadku plik /etc/master.passwd dla każdego box'a zawiera dwie linie zaczynające się od znaku ``+''. Pierwsza z nich dodaje netgrupę z kontami na które można się zalogować na tym komputerze, druga natomiast dodaje inne konta z wartością zmiennej SHELL=/sbin/nologin. Jest to dobry pomysł do użycia dużych liter w nazwach maszyn jako nazw netgrup. Innymi słowy, linie powinny wyglądać tak:
+@BOXNAME:::::::::
+:::::::::/sbin/nologin
Kiedy już zakończysz to zadanie na wszystkich komputerach, nie będziesz musiał już modyfikować lokalnych plików /etc/master.passwd. Wszystkie przyszłe zmiany, mogą być wprowadzane poprzez modyfikowanie mapy NIS. Poniżej znajduje się przykładowa mapa netgrup dla tego scenariusza z dodatkowymi opisami.
# Najpierw definiujemy grupy użytkowników
IT_EMP (,alpha,test-domain) (,beta,test-domain)
IT_APP (,charlie,test-domain) (,delta,test-domain)
DEPT1 (,echo,test-domain) (,foxtrott,test-domain)
DEPT2 (,golf,test-domain) (,hotel,test-domain)
DEPT3 (,india,test-domain) (,juliet,test-domain)
ITINTERN (,kilo,test-domain) (,lima,test-domain)
D_INTERNS (,able,test-domain) (,baker,test-domain)
#
# Teraz definiujemy grupy odgrywające kluczowe role
USERS DEPT1 DEPT2 DEPT3
BIGSRV IT_EMP IT_APP
SMALLSRV IT_EMP IT_APP ITINTERN
USERBOX IT_EMP ITINTERN USERS
#
# I grupy dla specjalnych zajęć
# Pozwalamy komputerom echo i golf na dostęp do naszego
# komputera antywirusowego
SECURITY IT_EMP (,echo,test-domain) (,golf,test-domain)
#
# netgrupy bazujące na komputerach
# Nasze główne serwery
WAR BIGSRV
FAMINE BIGSRV
# Użytkownik undia potrzebuje dostępu do tego serwera
POLLUTION BIGSRV (,india,test-domain)
#
# Ten jest naprawdę ważny i wymaga większego ograniczenia
# dostępu
DEATH IT_EMP
#
# Komputer antywirusowy wymianiany powyżej
ONE SECURITY
#
# Ogranicz maszynę dla jednego użytkownika
TWO (,hotel,test-domain)
# Więcej grup
Jeżeli używasz niektórych rodzajów baz danych do zarządzania kontami użytkowników, powinienneś być zdolny do stworzenia pierwszej części mapu z twoim narzędziem raportującym bazy danych. Wtedy nowy użytkownik będzie automatycznie dostawał dostęp do box'u.
Ostatnie ostrzeżenie: Niezawsze wskazane jest używanie netgrup bazujących na maszynach. Jeżeli dostarczasz kilka tuzinów lub setek identycznych komputerów dla labolatoriów studenckich, powinienneś używac netgrup role-basen w miejsce netgup bazujących na komputerach aby utrzymywać wielkość bazy NIS w rozsądnej wielkości.
8. Ważne żeczy do zapamiętania
Nadal istnieje jednak kilka żeczy, które będziesz musiał wykonywać inaczej gdy będziesz pracował w środowisku NIS.
Za każdym razem gdy będziesz chciał dodać użytkownika do labolatorium, musisz dodawać go na głównym serwerze NIS, i musisz pamiętać o przebudowie mapy NIS. Jeżeli zapomnisz o tym, nowy użytkownik nie będzie mógł zalogować się gdziekolwiek za wyjątkiem głównego serwera NIS. Dla przykładu, gdy chcemy dodać nowego użytkownika ``jsmith'' do labolatorium, powinniśmy:
# pw useradd jsmith
# cd /var/yp
# make test-domain
Mógłbyś także zamiast polecenia pw useradd jsmith wykonać polecenie adduser jsmith
Trzymaj konta administratorskie poza mapa NIS. Nie chcesz przecież aby były one propagowane wraz z hasłami do nich w całej sieci, i aby inni użytkownicy mieli do nich dostęp.
Trzymaj główny serwer i serwery zastępcze NIS jak najkrócej nieaktywne. Jeżeli ktoś włamie się do którego kolwiek z nich lub poprostu wyłączy go, może spowodować to iż wiele osób nie będzie mogło sie zalogować do labolatorium.
Jest to przedewszyskim słabość wszystkich scentralizowanych systemów administracji, i prawdopodobnie jest to ich największą słabością. Jeżeli nie będziesz chronił swoich serwerów NIS, będziesz miał wielu wściekłych użytkowników.
9. Kompatybilność z v1 NIS
FreeBSD ypserv posiada pewne wsparcie dla klientów posiadających wersję protokołu v1. Obecnie FreeBSD używa jednak tylko implementacji protokołu NIS v2, aczkolwiek inne implementacje w tym także wsparcie protokołu v1 jest zgodne z starszymi wersjami protokołu. Daemon ypbind dostarcza z tymi systemami prób nawiązywania połączenia serwer NIS v1 nawet jeżeli one tego obecnie nie potrzebują.
10. Używanie maszyny na której równocześnie działą serwer i klient NIS
Musisz zachować ostrożność gdy uruchamiasz multi-serwer domenowy, gdzie jest on zarazem klientem NIS. Jest to generalnie dobry pomysł aby zwiększyć ilość serwerów łączących się z samymi sobą, i pozwalając im rozgłaszać się i prawdopodobnie tworzyć połączenia z innymi. Groźne może być gdy jeden z serwerów zostanie wyłączony, a inne niezależne maszyny są do niego podłączone. Ewentualnie wszyscy klienci przekroczą limit dostępnego czasu na połączenie i będą próbowały połączyć się z innym serwerem, ale mogą pociągnąć za sobą spore opóźnienia i błąd może występować nadal mimo iż serwer mógł sie połączyć z innym.
Możesz zmusić hosta aby łączył się z określonym serwerem używając flagi -S podczas uruchamiania ypbind.
17.7.11. libscrypt kontra libdescrypt
Jednym z najczęstszych problemów który spotyka się podczas uruchamiania polega na różnicach w implementacjach bibliotek kryptujących i ich zgodności.Jeżeli twój serwer NIS używa bibliotek dla standardu DES, będzie współpracował dobrze jedynie z klientami którzy także używają DES. Aby sprawdzić które biblioteki używa twój serwer i klient zobacz na symlinki w katalogu /usr/lib. Jeżeli system skonfigurowany jest do używania bibliotek DES, powinny one wyglądać następująco:
% ls -l /usr/lib/*crypt*
lrwxrwxrwx 1 root wheel 13 Jul 15 08:55
/usr/lib/libcrypt.a@ -> libdescrypt.a
lrwxrwxrwx 1 root wheel 14 Jul 15 08:55
/usr/lib/libcrypt.so@ -> libdescrypt.so
lrwxrwxrwx 1 root wheel 16 Jul 15 08:55
/usr/lib/libcrypt.so.2@ -> libdescrypt.so.2
lrwxrwxrwx 1 root wheel 15 Jul 15 08:55
/usr/lib/libcrypt_p.a@ -> libdescrypt_p.a
-r--r--r-- 1 root wheel 13018 Nov 8 14:27
/usr/lib/libdescrypt.a
lrwxr-xr-x 1 root wheel 16 Nov 8 14:27
/usr/lib/libdescrypt.so@ -> libdescrypt.so.2
-r--r--r-- 1 root wheel 12965 Nov 8 14:27
/usr/lib/libdescrypt.so.2
-r--r--r-- 1 root wheel 14750 Nov 8 14:27
/usr/lib/libdescrypt_p.a
Jeżeli natomiast system skonfigurowany jest tak jak w standardzie dla FreeBSD czyli do obsługi bibliotek MD5, powinny one wyglądać mniejwięcej tak:
% ls -l /usr/lib/*crypt*
lrwxrwxrwx 1 root wheel 13 Jul 15 08:55
/usr/lib/libcrypt.a@ -> libscrypt.a
lrwxrwxrwx 1 root wheel 14 Jul 15 08:55
/usr/lib/libcrypt.so@ -> libscrypt.so
lrwxrwxrwx 1 root wheel 16 Jul 15 08:55
/usr/lib/libcrypt.so.2@ -> libscrypt.so.2
lrwxrwxrwx 1 root wheel 15 Jul 15 08:55
/usr/lib/libcrypt_p.a@ -> libscrypt_p.a
-r--r--r-- 1 root wheel 6194 Nov 8 14:27
/usr/lib/libscrypt.a
lrwxr-xr-x 1 root wheel 14 Nov 8 14:27
/usr/lib/libscrypt.so@ -> libscrypt.so.2
-r--r--r-- 1 root wheel 7579 Nov 8 14:27
/usr/lib/libscrypt.so.2
-r--r--r-- 1 root wheel 6684 Nov 8 14:27
/usr/lib/libscrypt_p.a
Jeżeli będziesz miał problemy z autentykacją klientów, jest to pierwsza rzecz a zarazem najpopularniejszy błąd który należy sprawdzić. Jeżeli będziesz chciał używać serwera NIS w sieciach heterogenicznych, będziesz musiał najprawdopodobniej używać algorytmu DES na wszystkich swoich systemach ponieważ jest on najczęstszym standardem.
Tłumaczenie paolo.
mlodszy, pt., 18/07/2008 - 21:37
