map_identityTa opcja mówi serwerowi, by zakładał, że klient używa tych samych wartości uid i gid co serwer...
PokaĹź mi serce nie opÄtane zwodniczymi marzeniami, a pokaĹźÄ ci czĹowieka szczÄĹliwego.
Ta opcja jest ustawiona domyślnie.map_daemon
Ta opcja mówi serwerowi NFS, by zakładał, że klient i serwer nie współdzielą tej samej przestrzeni uid/gid. Dlatego rpc.nfsd tworzy listę, która odwzorowuje ID pomiędzy klientem a serwerem, zadając zapytania demonowi rpc.ugidd na maszynie klienta.
map_static
Ta opcja pozwala na podanie nazwy pliku, który zawiera statyczne odwzorowanie wartości uid i gid. Na przykład map_static=/etc/nfs/vlight.map wskazywałby plik /etc/nfs/vlight.map jako plik zawierający odwzorowania uid/gid. Składnia pliku odwzorowań jest opisana na stronie podręcznika elektronicznego exports(5).
maps_nis
Ta opcja powoduje, że serwer NIS-a realizuje odwzorowania uid i gid.
anonuid i anongid
Te opcje pozwalają na określenie uid i gid kont anonimowych. Jest to przydatne, jeżeli masz publicznie wyeksportowany wolumen.
Wszelkie błędy przy analizie składniowej pliku exports są zgłaszane do funkcji daemon sysloga na poziomie notice, o ile są uruchomione demony rpc.nfsd i rpc.mountd.
Zauważ, że nazwy hostów są uzyskiwane na podstawie adresów IP klienta przez odwzorowanie odwrotne, a więc resolver musi być odpowiednio skonfigurowany. Jeżeli używasz BIND i jesteś świadomy problemów związanych z bezpieczeństwem, powinieneś włączyć w swoim pliku host.conf sprawdzanie podszywania się. Te tematy omawiamy w rozdziale 6, Usługi nazewnicze i konfigurowanie resolvera.
Serwer NFSv2 oparty na jądrze
Tradycyjnie używany w Linuksie serwer NFS działający w przestrzeni użytkownika jest niezawodny, ale sprawia problemy wydajnościowe, jeżeli jest przeciążony. Dzieje się tak głównie ze względu na obciążenie wnoszone przez interfejs wywołań systemowych, ale też dlatego, że musi on dzielić czas z innymi, potencjalnie mniej istotnymi procesami działającymi w przestrzeni użytkownika.
Jądro 2.2.0 obsługuje ekperymentalny serwer NFS oparty na jądrze, stworzony przez Olafa Kircha i dalej rozwijany przez H.J. Lu, G. Allana Morrisa i Tronda Myklebusta. Serwer NFS oparty na jądrze daje zdecydowaną poprawę wydajności.
W obecnych dystrybucjach możesz znaleźć narzędzia serwera w postaci pakietów. Jeżeli ich tam nie ma, możesz je znaleźć pod adresem http://csua.berkeley.edu/~gam3/knfsd/. Aby używać tych narzędzi, musisz skompilować jądro 2.2.0 z demonem NFS opartym na jądrze. Możesz upewnić się, czy twoje jądro ma wbudowanego demona NFS, sprawdzając, czy istnieje plik /proc/sys/sunrpc/nfsd_debug. Jeżeli go nie ma, możesz załadować moduł rpc.nfsd, używając narzędzia modprobe.
Demon NFS oparty na jądrze wykorzystuje standardowy plik konfiguracyjny /etc/exports. Pakiet zawiera zastępcze wersje demonów rpc.mountd i rpc.nfsd, które uruchamiasz prawie tak samo, jak ich odpowiedniki działające w przestrzeni użytkownika.
Server NFSv3 oparty na jądrze
Powszechnie używaną wersją NFS-a jest wersja 2. Jednak technika szybko idzie naprzód i ujawnia niedoskonałości, które może poprawić tylko inna wersja protokołu. Wersja 3 sieciowego systemu plików obsługuje większe pliki i systemy plików, gwarantując znacznie większe bezpieczeństwo i oferując szereg poprawek wydajnościowych, które przydadzą się większości użytkowników.
Olaf Kirch i Trond Myklebust pracują nad eksperymentalnym serwerem NFSv3. Jest on umieszczany w jądrach serii 2.3. Dostępne są łaty dla jądra serii 2.2. Korzysta on z demona NFS w wersji 2, opartego na jądrze.
Łaty są dostępne na stronie macierzystej serwera NFS opartego na jądrze Linuksa, znajdującej się pod adresem http://csua.berkeley.edu/~gam3/knfsd/.
15
IPX i system
plików NCP
Rozdział 15: IPX i system plików NCP
Na długo zanim firma Microsoft zajęła się sieciami i nawet zanim Internet wyszedł poza kręgi akademickie, firmy współdzieliły pliki i drukarki, używając serwerów plików i drukowania opartych na systemie operacyjnym Novell Netware i związanych z nim protokołach*. Wielu z tych użytkowników nadal utrzymuje sieci wykorzystujące te protokoły i chciałoby integrować je z nowszymi sieciami TCP/IP.
Linux obsługuje nie tylko protokoły TCP/IP, ale także zestaw protokołów używanych przez system operacyjny NetWare firmy Novell Corporation. Protokoły te są dalekimi kuzynami TCP/IP i choć pełnią podobną rolę, różnią się pod wieloma względami i niestety nie są ze sobą kompatybilne.
Linux posiada zarówno darmowe, jak i komercyjne oprogramowanie do integracji z produktami Novella.
W tym rozdziale krótko opiszemy same protokoły, a skupimy się na konfigurowaniu i wykorzystaniu darmowego oprogramowania, które pozwala Linuksowi na współpracę z produktami firmy Novell.
Xerox, Novell i historia
Przyjrzyjmy się najpierw, skąd pochodzą protokoły i jak wyglądają. Pod koniec lat siedemdziesiątych w firmie Xerox Corporation opracowano, a następnie opublikowano otwarty standard o nazwie Xerox Network Specification (XNS). Standard ten opisywał szereg protokołów obsługujących ogólnie pojętą komunikację sieciową, ze szczególnym uwzględnieniem sieci lokalnych. Były tam wykorzystane dwa główne protokoły sieciowe: internetowy protokół datagramów (Internet Datagram Protocol - IDP), zapewniający bezpołączeniowe i zawodne przesyłanie datagramów między hostami, oraz protokół komunikacyjny pakietów danych (Sequenced Packet Protocol - SPP) zaadoptowany z IDP, ale połączeniowy i niezawodny. Datagramy w sieci XNS były adresowane indywidualnie. Schemat adresowania opierał się na połączeniu 4-bajtowego adresu sieci IDP (który był unikalnie przypisany do każdego segmentu sieci lokalnej Ethernet) i 6-bajtowego adresu węzła (adresu karty sieciowej). Rutery były urządzeniami, które przekazywały datagramy pomiędzy dwoma lub kilkoma oddzielnymi sieciami IDP. IDP nie obsługuje podsieci. Każdy nowy zbiór hostów wymaga innego adresu sieci. Adresy sieci są dobierane tak, aby były unikalne w obrębie intersieci. Czasem administratorzy tworzą konwencje, przypisujące typy informacji (np. rejon geograficzny) do poszczególnych bajtów adresu, a więc adresy sieci są przydzielane w systematyczny sposób. Nie jest to jednak wymaganie protokołu.