Stacja robocza z głównym systemem plików z sieci.
Stacja robocza z głównym systemem plików z sieci.
Autor: Ofer Maor,
ofer@hadar.co.il
v3, 5 Grudnia 1996
Wersja polska: Bartosz Maruszewski
B.Maruszewski@zsmeie.torun.pl
v1.02, 26 Lipca 1997
Celem tego dokumentu jest wyjaśnienie jak stworzyć główne katalogi
na serwerze, który obsługuje klientów z montowanym głównym systemem
plików. Najnowszą wersję oryginału możesz znaleźć pod adresem
www.hadar.co.il.
Dokument ten został napisany w standardzie ISO-8859-2.
Odnośnie nowszych wersji tłumaczenia zobacz sekcję
Od tłumacza.
1. Prawa autorskie.
Prawa autorskie należą do Ofera Maora <
ofer@hadar.co.il>.
O ile nie stwierdza się inaczej, dokumenty HOWTO są chronione
prawami autorskimi ich autorów. Mogą one być rozprowadzane w
całości lub w części, w jakiejkolwiek postaci fizycznej czy
elektronicznej tak długo, dopóki znajduje się w nich ta wzmianka.
Dystrybucja komercyjna jest dozwolona, a nawet zachęca się do
niej; chociaż autor chciałby być poinformowany o takowej.
Wszelkie tłumaczenia, prace pochodne, prace zebrane zawierające
dokumenty HOWTO muszą zawierać tę notatkę o prawach autorskich.
Oznacza to, że nie możesz stworzyć pracy pochodzącej z HOWTO i
nałożyć na jej dystrybucję dodatkowych ograniczeń. Wyjątki od tej
zasady mogą być uczynione pod pewnymi warunkami; skontaktuj się z
koordynatorem programu Linux HOWTO pod niżej podanym adresem.
Krótko mówiąc, chcemy promować szerzenie tych dokumentów przez
wszelkie dostępne kanały. Chcielibyśmy także utrzymać prawa
autorskie nałożone na te dokumenty, i być powiadomieni o planach
dotyczących redystrybucji HOWTO.
Jeśli masz jakieś pytania, skontaktuj się z
Oferem Maorem pod adresem
<ofer@hadar.co.il> - autorem tego dokumentu, albo
Gregiem Hankinsem -
koordynatorem projektu Linux HOWTO pod adresem
<gregh@sunsite.unc.edu>.
Jeśli masz coś do dodania, skontaktuj się proszę z autorem (
Ofer Maor
<ofer@hadar.co.il>). Szczególnie mile widziane są informacje
o pojawieniu się nowszych narzędzi.
1.1 Podziękowania.
Chciałbym wyrazić podziękowania autorowi NFS-Root Howto, Andreasowi
Kostyrce (htmlurl url="mailto:andreas@medman.ag.or.at"
name="andreas@medman.ag.or.at"). Jego dokument pomógł mi w
pierwszych krokach przy tworzeniu stacji bezdyskowych. Moje
mini-howto nie próbuje w żaden sposób zamienić jego pracy, ale
rozszerzyć ją posługując się moimi doświadczeniami.
Chciałbym także podziękować Markowi Kushinsky (htmlurl
url="mailto:mark026@ibm.net" name="mark026@ibm.net") za
"wypolerowanie" stylu i sprawdzenie poprawności językowej tego Howto,
co znacznie poprawiło jego czytelność.
2. Przedmowa.
Dokument ten został napisany, aby pomagać ludziom, którzy chcą
używać montowania głównego systemu plików z sieci, żeby stworzyć
katalogi klienta. Zauważ, że jest wiele sposobów na zrobienie tego,
zależnie od twoich potrzeb i intencji. Jeśli klienci są
indywidualni a każdy z nich ma własnych użytkowników i
administratora konieczne będzie, aby znaczące katalogi klienta nie
były współdzielone z innymi klientami. Z drugiej strony, jeśli klient
jest przeznaczony dla wielu użytkowników i wszystkie są
administrowane przez tę samą osobę (na przykład, klasa
komputerowa), tyle plików ile się tylko da musi być wspołdzielone, aby
uczynić zarządzanie prostszym. Dokument ten skupi się na tym drugim
zagadnieniu.
2.1 Przegląd ogólny.
Podczas tworzenia katalogu głównego dla klienta oraz prób
limitowania do minimum rozmiaru tego katalogu, głównie skupiamy się
na tym, które pliki możemy współdzielić albo montować z serwera. W
tym Howto będę zalecał konfigurację klienta na podstawie moich
doświadczeń. Ale zanim zaczniemy zapamiętaj:
Dokument ten nie wyjaśnia jak właściwie zamontować główny system
plików. Jeśli chcesz więcej informacji, to odwołaj się do
NFS-Root mini-howto.
Większość mojej konfiguracji jest zrobiona poprzez montowanie i
symboliczne dołączenia. Wiele z tym dołączeń może zostać zastąpiona
dołączeniami stałymi. Wybierz w zależności od własnych
upodobań. Robienie dołączenia stałego poprzez montowanie czy
dołączenie symboliczne ma swoje zalety, ale może też powodować
problemy. Plik nie zostanie skasowany dopóki wszystkie stałe
dołączenia do niego nie zostaną zlikwidowane. Przez to, jeśli
będziesz uaktualniał jakiś plik, dowiązania będą ciągle wskazywały
na stary plik. Musisz więc sprawdzać za każdym razem wszystkie
dołączenia, które zrobiłeś.
Podczas montowania informacji z serwera można użyć dwóch
sposobów. Pierwszy (bardziej popularny), to zamontować cały katalog
główny serwera pod jakiś lokalny katalog a następnie zmienić
ścieżkę albo dołączyć tam odpowiednie katalogi. Osobiście nie lubię
montowania katalogu głównego serwera na stacji roboczej. Dlatego,
poniższy dokument sugeruje montowanie odpowiednich podkatalogów z
serwera na odpowiadające im katalogi na stacji.
Dokument ten jest zrobiony na podstawie moich doświadczeń
dotyczących robienia katalogów klienta na dystrybucji Slackware
3.1. Poszczególne pliki mogą się różnić (szczególnie rc.*), ale
ogólna idea powinna pozostać ta sama.
3. Tworzenie głównego katalogu klienta.
3.1 Tworzenie drzewa katalogów.
Przede wszystkim musisz stworzyć strukturę katalogów. Ja stworzyłem
wszystkie katalogi w /clients/hostname i będę używał tego
katalogu do przykładów. Chociaż jeśli chcesz, to możesz sobie
zmienić ten katalog na inny. Pierwszym krokiem jest zrobienie
odpowiednich katalogów. Powinny to być następujące:
bin, dev, etc, home, lib, mnt, proc, sbin, server, tmp, usr, var
i wszelkie inne katalogi jakie chcesz mieć na stacji.
Katalogi local, proc i dev będą użyte oddzielnie dla każdej
stacji, a reszta będzie współdzielona.
3.2 Tworzenie minimalnego systemu plików potrzebnego do startu.
Tworzenie katalogu dev.
Właściwie katalog dev może być współdzielony, ale lepiej jeśli
nie jest. Zawartość tego katalogu możesz stworzyć odpowiednim
skryptem, chcociaż prościej jest go po prostu skopiować z serwera:
cp -a /dev /clients/hostname
Musisz pamiętać, że /dev/mouse, /dev/cdrom i /dev/modem są
symbolicznymi dowiązaniami to właściwych urządzeń, i dlatego
powinieneś się upewnić, że wskazują one na poprawne urządzenia
zgodnie ze sprzętem w stacji.
Kopiowanie potrzebnych binariów.
Pomimo, iż montujemy wszystko z serwera jest pewna minimalna ilość
plików, które musimy skopiować do każdego klienta. Przede wszystkim
potrzebujemy init-a, nasz system nie będzie w stanie uruchomić
czegokolwiek przed uruchomieniem init-a (czego autor
doświadczył na własnej skórze ;) ). Tak więc najpierw skopiuj
/sbin/init do katalogu sbin klienta, potem skopiuj
/bin/sh do katalogu bin klienta, żeby skrypt rc.S
mógł się wykonać. Żeby wszystko zamontować potrzebujesz także
programu mount - skopiuj go do katalogu sbin klienta. To
jest zupełne minimum zakładając, że pierwszą linijką w rc.S
jest
mount -av
Zalecam jednak skopiowanie jeszcze kilku plików: update, ls,
rm, cp oraz umount, tak żebyś miał podstawowe narzędzia w razie
gdyby klientowi nie powiodło się montowanie. Jeśli zostawisz linię
właczającą swap przed linią montującą katalogi, to musisz także
skopiować program swapon.
Ponieważ większość z tych programów jest dynamicznie łączona z
bibliotekami, będziesz też potrzebował sporej części katalogu /lib:
cp -a /lib/ld.* /lib/libc.* /lib/libcursses.* /client/hostname/lib
Rozważ też możliowość stałego dowiązania zamiast
kopiowania. Przeczytaj mój komentarz na ten temat w sekcji
Przegląd ogólny.
Zauważ, że powyższe informacje zakładają, że parametry sieciowe
zostały przekazane do jądra podczas startu. Jeśli masz zamiar użyć
RARP lub BOOTP, będziesz także potrzebował odpowiednich binariów.
Ogólnie potrzebujesz minimum te programy, które pozwolą ci
skonfigurować sieć i uruchomić skrypt rc.S do momentu
zamontowania wszystkich katalogów z serwera.
Katalog var.
W większości przypadków katalog var powinien być osobny dla
każdego klienta. Chociaż wiele danych może być
współdzielonych. Stwórz w katalogu głównym stacji katalog var.
Zamontujemy tam katalog var z serwera. Aby stworzyć katalog
var napisz:
cp -a /var /clients/hostname/
Teraz możesz wybrać co chcesz współdzielić, a co chcesz mieć osobne
dla każdego klienta. Każdy plik/katalog, który chcesz współdzielić
usuń i stwórz symboliczne dołączenie do /serwer/var. Zauważ,
że musisz dołączyć go albo do katalogu /serwer/var albo do
../serwer/var, ale NIE do
/clients/hostname/serwer/var ponieważ nie będzie to
działało kiedy zmieni się katalog główny.
Ogólnie polecałbym oddzielić katalogi /var/run, /var/lock, /var/spool,
oraz /var/log.
Reszta katalogów.
etc jest wyjaśniony dokładnie w następnej sekcji
mnt i proc są przeznaczone do celów lokalnych
usr i home są tylko katalogami do zamontowania
tmp zależy od ciebie. Możesz stworzyć różne katalogi
tmp dla klientów, albo stworzyć kilka katalogów
/clients/tmp i zamontować je dla każdego klienta pod
/tmp. Ja zalecałbym osobne katalogi tmp dla każdego
klienta.
3.3 Tworzenie katalogu etc oraz konfiguracja klienta.
Zapamiętaj - sekcja ta odnosi się do tworzenia katalogu etc,
który w większości przypadków jest współdzielony między
klientami. Jeśli twoi klienci mają osobnych administratorów,
najlepiej zrobić osobne katalogi etc dla każdego klienta.
Tworzenie katalogu dla wszystkich klientów.
Pomimo, iż oddzielamy katalogi etc, to i tak większą część
stamtąd chcemy współdzielić. Ogólnie sądzę, że współdzielenie
katalogu etc z serwerem nie jest dobrym pomysłem, dlatego
zalecam stworzenie katalogu /clients/etc, w którym będą
przechowywane informacje dla klientów. Na początek po prostu
skopiuj katalog etc serwera do katalogu dla klientów.
Powinieneś dodać do tego katalogu wszystkie pliki konfiguracyjne
nie związane z konkretnym komputerem, np.: motd, issue itp.,
ale nie specyficzne dla komputera (fstab czy inittab).
Najważniejsze zmiany będą w katalogu rc.d. Najpierw powinieneś
zmienić rc.inet1, tak aby odzwierciedlał twoją lokalną
sytuację. Ja przekazuję parametry sieciowe do jądra podczas startu,
dlatego wyrzuciłem prawie wszystko z tego pliku. Jedynymi
poleceniami jakie tam zostawiłem, to ifconfig i route
konfigurujące urządzenie loopback (localhost). Jeśli używasz RARP-a
albo BOOTP, to będziesz musiał je stosowanie zrobić.
Po drugie powinieneś wyedytować swój plik rc.S. Najpierw
wyrzuć stamtąd wszystko co dotyczy sprawdzania dysku (polecenia
fsck) ponieważ będzie to robione przy starcie serwera. Potem
powinieneś znaleźć linię, która montuje twoje katalogi; powinna
wyglądać mniej więcej tak:
mount -avt nonfs
Parametr -t nonfs jest dlatego, że normalne stacje robocze
najpierw wykonują skrypt rc.S a potem rc.inet1, aby
skonfigurować Ethernet. Ponieważ to spowodowałoby, że żaden
system NFS nie zamontowałby sie linia ta powinna zostać
usunięta. Zmień ją na:
mount -av
Jeśli musisz uruchomić RARP/BOOTP, aby skonfigurować swoją sieć,
zrób to w rc.S (albo wywołaj odpowiedni skrypt z rc.S)
przed montowaniem i upewnij się, ze twoje fizyczne katalogu bin
i sbin zawierają potrzebne programy.
Po poleceniu mount -av będziesz miał działający system
plików. Stwórz ogólny plik fstab, tak żebyś mógł go skopiować
dla każdego klienta. Powinien on wyglądać mniej więcej tak:
server/nfs default 1 1
server:/bin /bin nfs default 1 1
server:/usr /usr nfs default 1 1
server:/sbin /sbin nfs default 1 1
server:/home /home nfs default 1 1
server:/lib /lib nfs default 1 1
server:/clients/etc /server/etc nfs default 1 1
server:/clients/var /server/var nfs default 1 1
none /proc proc default 1 1
Upewnij się także, że plik /etc/exports na serwerze
wygląda tak:
/clients/hostname hostname.domainname(rw,no_root_squash)
/clients/etc hostname.domainname(ro,no_root_squash)
/clients/var hostname.domainname(ro,no_root_squash)
/usr hostname.domainname(ro,no_root_squash)
/sbin hostname.domainname(ro,no_root_squash)
/bin hostname.domainname(ro,no_root_squash)
/lib hostname.domainname(ro,no_root_squash)
/home hostname.domainname(rw,no_root_squash)
We wszystkich liniach oprócz pierwszej powinieneś wstawić jakąś
maskę, do której pasują wszystkie komputery będące klientami
(np. pc*.twoja.domena). Sugeruję, żeby większość katalogów była
tylko-do-odczytu, ale to zależy od ciebie. Parametr
no_root_squash spowoduje, że użytkownicy "root" na kliencie
będą także mieli przywileje "root-a" na serwerze. Sprawdź man
exports. Jeśli chcesz, żeby użytkownicy na klientach mogli
uruchamiać passwd , to sprawdź czy katalog etc jest
zamontowany z prawem zapisu, chociaż osobiście tego nie polecam.
Zauważ jeszcze jedno dotyczące skryptu rc.S. Domyślnie w
Slackware pliki /etc/issue i /etc/motd są tworzone od nowa
po każdym resetwoaniu serwera. Jeśli pliki te są montowane bez
zapisu, to funkcja ta MUSI zostać wyłączona a ja zalecałbym
wyłączyć ją na zapas.
I ostatnia sprawa. Jeśli chcesz mieć tę samą bazę użytkowników na
kliencie i na serwerze, to musisz wybrać między:
używaniem NIS-a (Yellow Pages, sprawdź
NIS-HOWTO, a potem każdy klient będzie miał osobne pliki
/etc/passwd i /etc/group jak je otrzyma od serwera.
w większośći wypadków, proste symboliczne dołączenie
wystarczy. Dlatego będziesz musiał, albo dołączyć na stałe
/clients/etc/passwd do /etc/passwd, albo jeśli
wolisz dołączenia symboliczne to dołączyć /etc/passwd do
/clients/etc/passwd (nie w drugą stronę, ponieważ klienci
nie montują katalogu etc serwera). To samo dla /etc/group.
Tworzenie katalogu etc dla klienta.
Ogólnie, większość plików w katalogu etc klienta powinna być
dołączona symbolicznie do plików z katalogu etc serwera. Ale
niektóre z nich są różne dla każdej maszyny, a niektóre po prostu
muszą się tam znajdować kiedy ładuje się jądro. Oto minimalna
zawartość katalogu etc:
resolv.conf
hosts
inittab
rc.d/rc.S
fstab
Ponieważ te pięć plików może być identyczne dla każdego klienta,
możesz je skopiować, albo dołączyć na stałe. Chociaż zaleca się
żeby pliki rc.S i fstab były osobne dla każdego
klienta. Będziesz także potrzebował osobnego pliku HOSTNAME
dla każdego klienta. Osobiście uważam, że cały podkatalog rc.d
powinien być osobny dla każdego klienta ponieważ konfiguracja i
sprzęt mogą się różnić.
Dla każdego klienta dodaj do fstab odpowiednią linię dla
swapa:
/dev/swap_prttn swap swap default 1 1
Reszta plików z etc klienta może być albo dołączona na stałe
do plików /clients/etc/* albo podłączona symbolicznie do
/serwer/etc (który jest punktem do montowaina dla
/clients/etc).
Upewnij się, że twój klient umie poprawnie rozwiązywać nazwy
kanoniczne poprzez named albo etc/hosts. Nie jest złym
pomysłem trzymanie IP serwera w pliku etc/hosts, zamiast
liczyć na rozwiązywanie nazw. Jeśli będziesz liczyć tylko na to, to
problem z named-em spowoduje, że twoi klienci nie będą mogli
wystartować.
3.4 Startowanie.
Teraz wszystko, co musisz zrobić to zrestartować komputer, trzymać
kciuki i mieć nadzieję, że wszystko pójdzie gładko. :)
4. Tworzenie większej ilości klientów.
Jeśli przestrzegałeś moich instrukcji, to powinno to być proste:
cd /clients/
cp -a hostname1 hostname2
a potem upewnij się, że sprawdziłeś to:
pliki rc.d/* odpowiadają sprzętowi i konfiguracji
oprogramowania
linia dotycząca swap-a w fstab jest poprawna
symboliczne dowiązania dev/mouse, dev/modem oraz
dev/cdrom są poprawne.
Powodzenia ...
4.1 Od tłumacza.
Tłumaczenie to jest chronione prawami autorskimi © Bartosza
Maruszewskiego.
Dozwolone jest rozprowadzanie i dystrybucja na prawach takich
samych jak dokument oryginalny.
Jeśli znalazłeś jakieś rażące błędy ortograficzne, gramatyczne,
składniowe, techniczne to pisz do mnie:
B.Maruszewski@zsmeie.torun.plOficjalną stroną tłumaczeń HOWTO jest
http://www.jtz.org.pl/Aktualne wersje przetłumaczonych dokumentów znajdują się na
tejże stronie. Dostępne są także poprzez anonimowe ftp pod adresem
ftp.ippt.gov.pl w katalogu /pub/Linux/JTZ/.
Przetłumaczone przeze mnie dokumenty znajdują się także na
mojej stronie WWW. Są tam też odwołania do Polskiej Strony
Tłumaczeniowej.
Kontakt z naszą grupą, grupą tłumaczy możesz uzyskać poprzez listę
dyskusyjną jtz@ippt.gov.pl. Jeśli chcesz sie na nią zapisać, to
wyślij list o treści subscribe jtz Imię Nazwisko na adres
listproc@ippt.gov.pl
Wyszukiwarka
Podobne podstrony:
nfs root client pl 1NFS Root Client plnfs root client pl 4nfs root client pl 2nfs root client plnfs root client pl 3nfs root client jb7d4ijeoxt5nsr4tjqjyxetxaxhgew6fsuywfi jb7d4ijeoxt5nsr4tjqjyxetxaxhgew6fsuywfinfs root pl 5NFS Root plnfs root pl 1nfs root pl 2nfs root pl 3NFS Root pl (2)nfs root pl 4nfs root pl 6nfs root plnfs root 2 kz5wszui24iee4hdudlvapjuh2nz4jthzoaolcq kz5wszui24iee4hdudlvapjuh2nz4jthzoaolcqnfs root 3gj7prowkt75rf3asoqka3okydpr477ncbfls6q 3gj7prowkt75rf3asoqka3okydpr477ncbfls6qnfs root 1 ho5t4yj5mrzjojtc5uuwo5s52i6ri5stkwobmni ho5t4yj5mrzjojtc5uuwo5s52i6ri5stkwobmniwięcej podobnych podstron