Konfiguracja OpenAFS w Gentoo

1.  Przegląd

O dokumencie

Dokument opisuje wszystkie potrzebne kroki, jakie należy przedsięwziąć by zainstalować serwer OpenAFS w Gentoo Linux. Niektóre części dokumentu zostały zaczerpnięte z AFS FAQ oraz przewodnika "IBM Quick Beginnings guide on AFS". Nie wyważamy otwartych drzwi. :)

Czym jest AFS?

AFS jest rozproszonym systemem plików, który umożliwia współpracującym komputerom (zarówno klientom jak i serwerom) efektywnie współdzielić zasoby dyskowe przez sieć lokalną (LAN) jak i rozległą (WAN). Klienci posiadają pamięć podręczną na często używane obiekty (pliki), by móc szybko się do nich odwoływać.

AFS oparty jest na rozproszonym systemie plików "Andrew File System", nad którym pracowano w Centrum Technologii Informacyjnej na Uniwersytecie Carnegie-Mellon (CMU). "Andrew" było nazwą projektu badawczego na CMU, nadaną na cześć założycieli uniwersytetu. Po założeniu Transarc i tym, gdy AFS stał się produktem, "Andrew" został zarzucony, by zasygnalizować, że AFS wyszedł poza ramy projektu badawczego i stał się wspieranym, produkcyjnym systemem plików. Jednakże istniała znaczna liczba komórek, które swój system plików miały zakorzeniony jako /afs. W tamtym okresie zmiana punktu zaczepienia systemu plików była nietrywialnym przedsięwzięciem, więc by uchronić przed zmianami wczesne ośrodki korzystające AFS, AFS pozostało nazwą i punktem zaczepienia systemu plików.

Czym jest komórka AFS?

Komórka AFS to zbiór serwerów zgrupowanych administracyjnie i prezentujący się jako jeden spójny system plików. Zazwyczaj jest to zbiór komputerów wykorzystujący tę samą domenę internetową (np. gentoo.org). Użytkownicy logują się na maszyny klienckie AFS, które w ich imieniu żądają informacji i plików z serwerów należących do komórki. Użytkownicy nie wiedzą, na której maszynie znajduje się plik do którego próbują się odwołać. Nawet nie zauważą, że serwer będzie przenoszony w inne miejsce, gdyż każdy wolumin może być replikowany i przenoszony na inne serwery, bez potrzeby powiadamiania użytkownika. Pliki są zawsze dostępne. Jest to taki podrasowany NFS :)

Jakie korzyści płyną z używania AFS?

Mocne strony AFS to możliwość cache'owania (po stronie klienta, zazwyczaj od 100M do 1GB), funkcje bezpieczeństwa (bazowany na Kerberos 4, ACL), prostota adresowania (mamy po prostu jeden system plików), skalowalność (w razie potrzeby możliwość dodawania kolejnych serwerów do komórki), protokoły komunikacyjne.

Gdzie można uzyskać więcej informacji?

Lektura AFS FAQ.

Strona główna OpenAFS, www.OpenAFS.org.

AFS był początkowo rozwijany przez Transarc, które obecnie należy do IBM. Więcej informacji o AFS można znaleźć na stronie Transarc.

Jak diagnozować problemy?

OpenAFS posiada wspaniały mechanizm logowania. Jednakże zgodnie z domyślnymi ustawieniami, logi wędrują do odrębnych lokalizacji zamiast do mechanizmów logowania systemowego, które mamy w naszym systemie. Jeśli chcemy, by serwery korzystały z systemowych mechanizmów logowania, to używamy opcji -syslog dla wszystkich komend bos.

2.  Aktualizacja ze starszych wersji

Wprowadzenie

Ta część dokumentu opisuje proces aktualizacji OpenAFS do wersji 1.4.0 i nowszych (lub 1.2.x zaczynając od 1.2.13. Druga opcja nie zostanie opisana szczegółowo, w związku z tym, że znakomita większość użytkowników i tak wybierze 1.4 ze względu na obsługę jąder 2.6, dużych plików i naprawę wielu błędów poprzednich wydań.

Jeśli dopiero co został zainstalowany OpenAFS w wersji 1.4, można spokojnie pominąć ten rozdział. Jeśli jest to jednak aktualizacja, należy dokładnie go przeczytać. Skrypt zawarty w ebuildzie został zaprojektowany tak, aby możliwe było szybkie zainstalowanie nowej wersji i ponowne uruchomienie. Nie usunie on żadnych plikow konfiguracyjnych ani skryptów startowych. Nie zmieni automatycznie konfiguracji uruchamiania systemu, aby używała nowych skryptów. Warto również zauważyć, że nowsze jądra i stare wersje OpenAFS mogą prowadzić do poważnych błędów. Dlatego naprawdę warto dokonać tej aktualizacji.

Różnice pomiędzy wersjami

W przeszłości OpenAFS korzystał z pewnego schematu nazewnictwa podobnego do tego, z jakiego korzystali ludzie z laboratoriów IBM TransArc. W związku z tym stare instalacje OpenAFS wciąć te schematy wykorzystują. Nowsze wersje są zgodne ze standardem FHS i korzystają ze standardowych ścieżek systemu Linux. Poniższa tabela zawiera zestawienie różnic pomiędzy oboma standardami.

Są również inne niejasności, jak na przykład binaria umieszczane w katalogu /usr/vice/etc w standardzie Transarc. Powyższa lista nie jest dokładna. Jest raczej próbą krótkiego podsumowania najbardziej kluczowych pozycji.

W związku ze zmianami ścieżek, domyślne miejsce cache zmieniło się z /usr/vice/cache na /var/cache/openafs.

Co więcej skrypty startowe zostały podzielone na dwie grupy, te dla serwera i te dla klienta. Kiedyś był po prostu skrypt /etc/init.d/afs, teraz są dwa, /etc/init.d/openafs-client i /etc/init.d/openafs-server. Tak samo pliki konfiguracyjne z /etc/conf.d/afs zostały podzielone na /etc/conf.d/openafs-client i /etc/conf.d/openafs-server. Opcje w pliku, które /etc/conf.d/afs posiadały możliwość włączenia dla klienta i serwera zostały wyłączone.

Kolejna zmiana w skrypcie startowym jest taka, że nie sprawdza on już konfiguracji cache na dysku. Starsze wersje domagały się osobnej partycji ext2 zamontowanej w /usr/vice/cache, co powodowało szereg problemów:

• Chociaż to bardzo rozsądne rozwiązanie, posiadanie cache na osobnej partycji nie powinno być obowiązkowe. Nowa konfiguracja jest w porządku, dopóki ilość miejsca ustawiona w /etc/openafs/cacheinfo jest naprawdę dostępna dla cache. Dlatego nie ma żadnych większych problemów z ustawieniem cache tak, aby znajdowało się na partycji głównej.
• Niektórzy korzystali z miękkich dowiązań wskazujących na prawdziwe miejsce przechowywania cache. Skrypt startowy nie działał wtedy dobrze, ponieważ taka lokacja nie była wyświetlana w /proc/mounts.
• Wiele osób woli ext3 od ext2. Oba systemy plików mogą być używane dla cache. Nie działa żaden inny system plików (Jeśli cache będzie ustawiony na partycję, na przykład, reiserfs, pojawi się ostrzeżenie, a potem seria błędów).

Migracja na nowe ścieżki

Przede wszystkim, instalacja nowej wersji OpenAFS nie usunie żadnych starych plików konfiguracyjnych. Skrypt został zaprojektowany tak, że nie zmienia żadnych plików już obecnych w systemie. Zatem jeśli nawet konfiguracja była całkowicie zmieniona przez użytkownika, były w niej pomieszane nowe i stare ścieżki, skrypt wciąż nie przysporzy żadnych problemów. Jeśli zostanie wykryte, że w systemie wciąż działa serwer OpenAFS, instalacja zostanie przerwana, zapobiegając możliwym uszkodzeniom bazy danych.

Istnieje jednak pewien problem. W Internecie krąży kilka ebuildów, które wyłączają domyślną ochronę jaką Gentoo zapewnia dla /etc. Te ebuildy nie były nigdy dostarczane jako część Gentoo. Przed przystąpieniem do dalszej pracy warto sprawdzić zmienną CONFIG_PROTECT_MASK za pomocą następującego polecenia:

# emerge info | grep "CONFIG_PROTECT_MASK"
CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/texmf/web2c /etc/env.d"

Nic co jest w ebuildzie nie powinno nawet dotknąć plików wewnątrz /etc/afs. Aktualizacja usunie natomiast cały katalog z poprzednią instalacją OpenAFS. Pliki ze zmiennej CONFIG_PROTECT_MASK, które należą do starej instalacji przestaną istnieć.

Każdy użytkownik, który zmieniał konfigurację ręcznie, za pomocą dowiązań symbolicznych (np. kierując /usr/afs/etc do /etc/openafs) będzie miał możliwość korzystania z nowej wersji z użyciem starych plików konfiguracyjnych. W takim przypadku nie dojdzie do żadnego prawdziwego przejścia na nowe ścieżki a wyczyszczenie starej instalacji OpenAFS zepsuje wszystko.

Teraz, gdy już wiemy mniej więcej co nie powinno się zdarzyć, warto dowiedzieć się co stanie się na pewno:

• /usr/afs/etc zostanie skopiowane do /etc/openafs/server
• /usr/vice/etc zostanie skopiowane do /etc/openafs
• /usr/afs/local zostanie skopiowane do /var/lib/openafs
• /usr/afs/local/BosConfig zostanie skopiowane do /etc/openafs/BosConfig, a wszystkie wystąpienia /usr/afs/bin/ zostaną zastąpione przez /usr/libexec/openafs, /usr/afs/etc przez /etc/openafs/server, a /usr/afs/bin (bez / na końcu jak wcześniej) przez /usr/bin
• /usr/afs/db zostanie skopiowane do /var/lib/openafs/db
• Plik konfiguracyjny /etc/conf.d/afs zostanie skopiowany do /etc/conf.d/openafs-client, ponieważ wszystkie stare opcje dotyczą jedynie klienta.

Aktualizacja właściwa

W poprzednich rozdziałach wyjaśniliśmy co się stanie. Jeśli wciąż chcesz to zrobić, do roboty.

Rozpoczynamy proces aktualizacji.

Jeśli serwer wciąż działa, trzeba go teraz wyłączyć.

# /etc/init.d/afs stop

A teraz aktualizacja.

# emerge -u openafs

Ponowne uruchamianie OpenAFS

Zaczynamy od wyłączenia serwera.

# /etc/init.d/afs stop

Czas, kiedy serwer jest wyłączony powinien być możliwie krótki. Dlatego warto go od razu uruchomić ponownie.

# /etc/init.d/openafs-server start

Można sprawdzić czy serwer działa prawidłowo za pomocą następującego polecenia:

# /usr/bin/bos status localhost -localauth

Przed ponownym uruchomieniem klientów OpenAFS, należy spędzić chwilę sprawdzając ustawienia cache. Są one zależne od /etc/openafs/cacheinfo. Aby ponownie uruchomić klienty, należy wpisać:

# /etc/init.d/openafs-client start

Sprzątanie po aktualizacji

Przed przystąpieniem do czyszczenia, należy się upewnić, że serwer działa bez problemów i że został ponownie uruchomiony (w innym wypadku stara instalacja może wciąż działać).

Można bezpiecznie usunąć następujące katalogi:

• /etc/afs
• /usr/vice
• /usr/afs
• /usr/afsws

Następujące pliki nie są już potrzebne?

• /etc/init.d/afs
• /etc/conf.d/afs

# tar czf /root/oldafs-backup.tgz /etc/afs /usr/vice /usr/afs /usr/afsws
# rm -R /etc/afs /usr/vice /usr/afs /usr/afsws
# rm /etc/init.d/afs /etc/conf.d/afs

Jeśli wcześniej korzystano z ebuildów =openafs-1.2.13 lub =openafs-1.3.85, należy usunąć również następujące pliki:

• /etc/init.d/afs-client
• /etc/init.d/afs-server
• /etc/conf.d/afs-client
• /etc/conf.d/afs-server

Zmiany w skryptach startowych

W tym momencie większość użytkowników ma system skonfigurowany tak, aby automatycznie uruchamiał serwer i klienta OpenAFS przy starcie. Ci, którzy nie mają takiej konfiguracji mogą pominąć ten rozdział. Jeśli system był wcześniej skonfigurowany tak, aby uruchamiał te skrypty, teraz trzeba skonfigurować go ponownie, gdyż skrypty te się zmieniły.

# rc-update del afs default
# rc-update add openafs-client default
# rc-update add openafs-server default

Jeśli jest to aktualizacja z =openafs-1.2.13 lub =openafs-1.3.85, konieczne będzie usunięcie afs-client i afs-server z domyślnego poziomu uruchomieniowego zamiast afs.

Problemy, czyli co robić kiedy automatyczna aktualizacja zawiedzie

Przede wszystkim nie panikować. Nie doszło do straty żadnych danych ani plików konfiguracyjnych. Trzeba przeanalizować sytuację, a następnie zgłosić błąd na stronie bugs.gentoo.org z jak największą ilością informacji.

Jeśli pojawią się problemy z uruchomieniem klienta, można zdiagnozować problem w następujący sposób.

• Należy uruchomić dmesg. To tam są wysyłane informacje o błędach klienta.
• Następnie należy sprawdzić /etc/openafs/cacheinfo. Powinien mieć on postać: /afs:{path to disk cache}:{number of blocks for disk cache}. Domyślnie cache znajduje się w /var/cache/openafs.
• Należy również sprawdzić wyjście lsmod w poszukiwaniu linii zaczynających się od słowa openafs.
• pgrep afsd powie czy afsd działa czy nie
• cat /proc/mounts powinien wskazywać, że /afs jest zamontowane

Jeśli pojawią się problemy z uruchomieniem serwera, poniższe wskazówki mogą pomóc:

• pgrep bosserver mówi o tym czy overseer jest uruchomiony czy nie. Jeśli jest uruchomiony więcej niż jeden, coś musiało pójść źle. W takim wypadku należy zamknąć serwer OpenAFS za pomocą polecenia bos shutdown localhost -localauth -wait, sprawdzić rezultat tej czynności za pomocą bos status localhost -localauth, zabić wszystkie pozostałe procesy overseer, a następnie sprawdzić czy nie działa już żaden proces serwera (ls /usr/libexec/openafs wyświetli ich listę). Następnie należy wpisać /etc/init.d/openafs-server zap w celu zresetowania statusu serwera i /etc/init.d/openafs-server start, aby go ponownie uruchomić.
• Jeśli korzysta się z systemu logowania OpenAFS (co jest domyślnym ustawieniem), należy sprawdzić /var/lib/openafs/logs/*. Jeśli natomiast korzysta się z sysloga, należy sprawdzić logi systemowe w celu uzyskania informacji na temat tego co mogło źle pójść.

3.  Dokumentacja

Pobieranie dokumentacji AFS

Istnieje możliwość uzyskania oryginalnej dokumentacji IBM AFS. Jest bardzo dobrze napisana i naprawdę należy się z nią zapoznać, jeśli myślimy o administrowania serwerem AFS.

# emerge app-doc/afsdoc

Istnieje również możliwość korzystania z dokumentacji dostarczanej wraz z OpenAFS. Jest ona instalowana, gdy włączona jest flaga doc. Dokumentacja znajduje się w katalogu /usr/share/doc/openafs-*/. W momencie pisania tego tekstu, dokumentacja ta była wciąż w fazie tworzenia. Z czasem jednak na pewno pojawią się tam opisy najnowszych funkcji, które nie zostały opisane w dokumentacji AFS IBM-a.

4.  Instalacja klienta

Budowanie klienta

# emerge net-fs/openafs

Po zakończonej sukcesem kompilacji, możemy kontynuować.

Prosty sposób na instalację klienta globalnego

Jeśli nie jest się częścią komórki, którą zamierza się przeglądać i jeśli chce się po prostu przejrzeć wszystkie dostępne globalnie zasoby OpenAFS, nie trzeba zmieniać żadnej konfiguracji. Wystarczy po prostu uruchomić /etc/init.d/openafs-client.

Łączenie się z konkretną komórką OpenAFS

Dostęp do konkretnej komórki wymaga tylko kilku drobnych zmian w konfiguracji.

Po pierwsze trzeba zaktualizować /etc/openafs/CellServDB dodając serwery baz danych dla danej komórki. Zwykle informacji o nich dostarcza administrator.

Po drugie, aby móc zalogować się do komórki, należy wpisać jej nazwę w pliku /etc/openafs/ThisCell.

CellServDB:
>netlabs        #Cell name
10.0.0.1        #storage

ThisCell:
netlabs

Wpis CellServDB informuje klienta o tym z którymi komórkami chce się skontaktować. Wpis ThisCell jest jasny. Zwykle używa się tu unikalnej nazwy organizacji. Można też wpisać nazwę swojej domeny.

Później wystarczy uruchomić /etc/init.d/openafs/client i użyć klog, aby się autoryzować i zacząć używać komórki. Automatyczne logowanie omówimy za chwilę.

Konfiguracja cache

Cache może znajdować się zarówno w już istniejącym systemie plików (jeśli jest to ext2/3) lub na osobnej, stworzonej tylko w tym celu partycji. Domyślna lokacja dla cache to /var/cache/openafs, ale można ją zmienić edytując /etc/openafs/cacheinfo. Standardowy rozmiar dla cache to 200 MB, ale więcej miejsca na pewno nie zaszkodzi.

Uruchamianie AFS podczas rozruchu systemu

Następujące komendy utworzą odpowiednie dowiązania, tak by klient AFS uruchamiał się podczas rozruchu systemu.

# rc-update add openafs-client default

5.  Instalacja serwera

Budowanie serwera

Następujące komendy zainstalują binaria niezbędne do uruchomienia serwera i klienta AFS.

# emerge net-fs/openafs

Uruchamianie serwera AFS

Zaczynamy od wpisania bosserver żeby uruchomić serwer Basic Overseer (BOS), który monitoruje i kontroluje inne procesy serwera AFS na maszynie z serwerem. Możemy myśleć o tym jak o rozruchu systemu. Dodajemy flagę -noauth by wyłączyć autoryzację, gdyż jeszcze nie dodaliśmy użytkownika z prawami administratora.

# /usr/afs/bin/bosserver -noauth &

Sprawdzamy czy serwer BOS utworzył pliki /etc/openafs/server/CellServDB i /etc/openafs/server/ThisCell.

# ls -al /etc/openafs/server/
-rw-r--r--    1 root     root           41 Jun  4 22:21 CellServDB
-rw-r--r--    1 root     root            7 Jun  4 22:21 ThisCell

Definiowanie nazwy komórki i przynależności dla procesu serwera

Przypisujemy komórce nazwę.

Nazwę komórki ustawiamy wydając polecenie bos setcellname:

# bos setcellname <serwer> <komórka> -noauth

Uruchamianie procesu serwera bazy danych

Następnie używamy komendy bos create do utworzenie wpisów w pliku /etc/openafs/BosConfig, dla czterech procesów serwerów baz danych. Te cztery procesy działają tylko na maszynach serwerowych.

# bos create <nazwa serwera> kaserver \
simple /usr/libexec/openafs/kaserver \
-cell <cell name> -noauth
# bos create <nazwa serwera> buserver \
simple /usr/libexec/openafs/buserver \
-cell <cell name> -noauth
# bos create <nazwa serwera> ptserver \
simple /usr/libexec/openafs/ptserver \
-cell <cell name> -noauth
# bos create <nazwa serwera> \
vlserver simple /usr/libexec/openafs/vlserver \
-cell <cell name> -noauth

Działanie wszystkich serwerów możemy zweryfikować wydając polecenie bos status:

# bos status <server name> -noauth
Instance kaserver, currently running normally.
Instance buserver, currently running normally.
Instance ptserver, currently running normally.
Instance vlserver, currently running normally.

Inicjalizowanie bezpieczeństwa komórki

Teraz zajmiemy się inicjalizowaniem mechanizmów bezpieczeństwa komórki. Zaczniemy od utworzenia następujących dwóch wpisów w bazie zawierającej dane uwierzytelniające (Authentication Database): główne konto administracyjne, nazwane zgodnie z konwencją admin oraz wpis dla procesów serwera AFS, zwany afs. Żaden użytkownik nie legitymuje się tożsamością afs, za wyjątkiem usługi TGS serwera uwierzytelniającego (Ticket Granting Service - usługa przydzielania biletów), która wykorzystuje to konto do szyfrowania biletów serwera, przyznawanych klientom AFS. Przypomina to bardzo Kerberosa :)

Uruchamianie tryby interaktywnego kas.

# /usr/afs/bin/kas -cell <cell name> -noauth
ka> create afs
initial_password:
Verifying, please re-enter initial_password:
ka> create admin
initial_password:
Verifying, please re-enter initial_password:
ka> examine afs

User data for afs
key (0) cksum is 2651715259, last cpw: Mon Jun  4 20:49:30 2001
password will never expire.
An unlimited number of unsuccessful authentications is permitted.
entry never expires.  Max ticket lifetime 100.00 hours.
last mod on Mon Jun  4 20:49:30 2001 by <none>
permit password reuse
ka> setfields admin -flags admin
ka> examine admin

User data for admin (ADMIN)
key (0) cksum is 2651715259, last cpw: Mon Jun  4 20:49:59 2001
password will never expire.
An unlimited number of unsuccessful authentications is permitted.
entry never expires.  Max ticket lifetime 25.00 hours.
last mod on Mon Jun  4 20:51:10 2001 by <none>
permit password reuse
ka>

Użytkownika admin dodajemy do /etc/openafs/server/UserList przez wydanie komendy bos adduser.

# bos adduser <server name> admin -cell <cell name> -noauth

Klucz szyfrujący dla serwera AFS definiujemy w pliku /etc/openafs/server/KeyFile wywołując komendę bos addkey.

# bos addkey  <server name> -kvno 0 -cell <cell name> -noauth
input key:
Retype input key:

Wydajemy polecenie pts createuser, by dla użytkownika admin utworzyć wpis w bazie bezpieczeństwa (Protection Database).

# /usr/afs/bin/pts createuser -name admin -cell <cell name> [-id <AFS UID>] -noauth

Wydajemy komendę pts adduser, by dodać użytkownika admin do grupy system:administrators, zaś polecenia pts membership, by zweryfikować przynależność.

# pts adduser admin system:administrators -cell <cell name> -noauth
# pts membership admin -cell <cell name> -noauth
Groups admin (id: 1) is a member of:
system:administrators

Prawidłowe ponowne uruchamianie serwera AFS

W tym momencie prawidłowa autoryzacja jest możliwa i serwer OpenAFS może się normalnie uruchomić. Dla prawidłowej autoryzacji należy również uruchomić klienta OpenAFS. Opis jego konfiguracji znajduje się w poprzednim rozdziale.

# bos shutdown <server name> -wait -noauth
# killall bosserver

# /etc/init.d/openafs-server start
# /etc/init.d/openafs-client start

# rc-update add openafs-server default

# klog admin

Uruchamianie serwera plików, woluminów i serwera Salvager

Uruchamiamy proces fs, który składa się z serwera plików, serwera woluminów i serwera Salvager (procesy fileserver, volserver i salvager).

# bos create <server name> fs fs /usr/libexec/openafs/fileserver /usr/libexec/openafs/volserver /usr/libexec/openafs/ salvager -cell <cell name> -noauth

Sprawdzamy czy wszystkie procesy działają.

# bos status <server name> -long -noauth
Instance kaserver, (type is simple) currently running normally.
Process last started at Mon Jun  4 21:07:17 2001 (2 proc starts)
Last exit at Mon Jun  4 21:07:17 2001
Command 1 is '/usr/libexec/openafs/kaserver'

Instance buserver, (type is simple) currently running normally.
Process last started at Mon Jun  4 21:07:17 2001 (2 proc starts)
Last exit at Mon Jun  4 21:07:17 2001
Command 1 is '/usr/libexec/openafs/buserver'

Instance ptserver, (type is simple) currently running normally.
Process last started at Mon Jun  4 21:07:17 2001 (2 proc starts)
Last exit at Mon Jun  4 21:07:17 2001
Command 1 is '/usr/libexec/openafs/ptserver'

Instance vlserver, (type is simple) currently running normally.
Process last started at Mon Jun  4 21:07:17 2001 (2 proc starts)
Last exit at Mon Jun  4 21:07:17 2001
Command 1 is '/usr/libexec/openafs/vlserver'

Instance fs, (type is fs) currently running normally.
Auxiliary status is: file server running.
Process last started at Mon Jun  4 21:09:30 2001 (2 proc starts)
Command 1 is '/usr/libexec/openafs/fileserver'
Command 2 is '/usr/libexec/openafs/volserver'
Command 3 is '/usr/libexec/openafs/salvager'

Następne kroki zależą od tego czy kiedykolwiek uruchamialiśmy w obrębie komórki serwer plików AFS:

Jeśli instalujemy po raz pierwszy serwer AFS w komórce, to tworzymy pierwszy wolumin AFS, root.afs.

# vos create <server name> <partition name> root.afs -cell <cell name> -noauth

Jeśli istnieją maszyny z serwerem plików AFS oraz woluminy w komórce, to wydajemy polecenia vos sncvldb oraz vos syncserv, by zsynchronizować VLDB (baza danych woluminów) ze stanem woluminów na lokalnej maszynie. W efekcie wszystkie niezbędne dane zostaną skopiowane na nowy serwer.

Jeśli polecenia zakończy się komunikatem "partition /vicepa does not exist on the server", to musimy się upewnić, że partycja jest montowana przed uruchomieniem serwerów OpenAFS lub montujemy katalog i ponownie uruchamiamy procesy używając bos restart <server name> -all -cell <cell name> -noauth.

# vos syncvldb <server name> -cell <cell name> -verbose -noauth
# vos syncserv <server name> -cell <cell name> -verbose -noauth

Uruchamianie fragmentów serwera update

# bos create <server name> \
upserver simple "/usr/libexec/openafs/upserver \
-crypt /etc/openafs/server -clear /usr/libexec/openafs" \
-cell <cell name> -noauth

Konfigurowanie najwyższego poziomu w systemie plików AFS

Na początek musimy ustawić kilka ACL-i, tak by użytkownik mógł przeglądać /afs.

# fs setacl /afs system:anyuser rl

Następnie tworzymy główny wolumin, montujemy go jako /afs/<cell name> w trybie tylko do odczytu i jako /afs/.<cell name> w trybie do odczytu i zapisu.

# vos create <server name><partition name> root.cell
# fs mkmount /afs/<cell name> root.cell 
# fs setacl /afs/<cell name> system:anyuser rl
# fs mkmount /afs/.<cell name> root.cell -rw

# vos create <server name> <partition name> <myvolume>
# fs mkmount /afs/<cell name>/<mymountpoint> <myvolume>
# fs mkmount /afs/<cell name>/.<mymountpoint> <myvolume> -rw
# fs setquota /afs/<cell name>/.<mymountpoint> -max <quotum>

Nareszcie skończyliśmy! Powinniśmy posiadać działający serwer plików AFS w naszej sieci lokalnej. Czas na duży kubek kawy i drukowanie dokumentacji AFS!

6.  Podstawy administracji

Ostrzeżenie

OpenAFS jest rozległą technologią. Prosimy o przeczytanie dokumentacji AFS w celu uzyskania większej ilości informacji. W tym rozdziale wymieniamy tylko kilka administracyjnych zadań.

Konfiguracja PAM do uzyskiwania tokena AFS przy logowaniu

By korzystać z AFS musimy się uwierzytelnić na serwerze KA, jeśli korzystamy z implementacji AFS i Kerberos 4 lub w Kerberos 5 KDC, jeśli korzystamy z MIT, Heimdal lub ShiShi Kerberos5. Jednakże, by zalogować się na maszynę, potrzebujemy konta użytkownika. Może to być konto lokalne w /etc/passwd, NIS, LDAP (OpenLDAP) lub bazie Hesiod. W Gentoo PAM pozwala na powiązanie uwierzytelniania AFS z logowaniem na konto użytkownika.

Musimy zaktualizować /etc/pam.d/system-auth, które jest używane przez inne konfiguracje. "use_first_pass" sygnalizuje, że najpierw sprawdzany jest login użytkownika, zaś "ignore_root" sprawia, że super użytkownik jest ignorowany (podobnie jak każdy użytkownik z UID 0) w przypadku, gdy zawiedzie AFS lub sieć.

auth       required     pam_env.so
auth       sufficient   pam_unix.so likeauth nullok
auth       sufficient   pam_afs.so.1 use_first_pass ignore_root
auth       required     pam_deny.so

account    required     pam_unix.so

password   required     pam_cracklib.so retry=3
password   sufficient   pam_unix.so nullok md5 shadow use_authtok
password   required     pam_deny.so

session    required     pam_limits.so
session    required     pam_unix.so

By zapobiec uzyskaniu dostępu AFS przez lokalnych użytkowników i by sudo zachowywało token rzeczywistego użytkownika, zmieniamy /etc/pam.d/su i następujący sposób:

# W tym przykładzie, użytkownicy z uid > 100 są traktowani jako
należący do AFS, zaś użytkownicy z
# uid <= 100 są ignorowani przez pam_afs.
auth       sufficient   /usr/afsws/lib/pam_afs.so.1 ignore_uid 100

auth       sufficient   /lib/security/pam_rootok.so

#Jeśli chcemy ograniczyć listę użytkowników, którzy mogą wykonywać
# polecenie su, to tworzymy plik /etc/security/suauth.allow zapisywalny jedynie
# przez roota i dodajemy w nim listę uprawnionych użytkowników. Każdy w osobnej
# linii.
#auth       required     /lib/security/pam_listfile.so item=ruser \
#       sense=allow onerr=fail file=/etc/security/suauth.allow

# Następującą linię należy odkomentować, by pozwolić użytkownikom z grupy
# 'wheel' na wykonywanie komendy su bez wprowadzania hasła.
#auth       sufficient   /lib/security/pam_wheel.so use_uid trust

# Alternatywę dla powyższego stanowi lista użytkowników, którzy nie muszą
# wprowadzać hasła przy wykonywaniu komendy su.
#auth       sufficient   /lib/security/pam_listfile.so item=ruser \
#       sense=allow onerr=fail file=/etc/security/suauth.nopass

# Poniższa linię należy zakomentować, by pozwolić dowolnemu użytkownikowi, nawet
# takiemu nie należącemu do grupy 'wheel', na wykonywanie komendy su.
auth       required     pam_wheel.so use_uid

auth       required     pam_stack.so service=system-auth

account    required     pam_stack.so service=system-auth

password   required     pam_stack.so service=system-auth

session    required     pam_stack.so service=system-auth
session    optional     pam_xauth.so

# W tym miejscu zapobiegamy zrzuceniu tokena rzeczywistego id przez użytkownika
session    optional     pam_afs.so.1 no_unlog

Materiał udostępniany na podstawie licencji Creative Commons - Attribution / Share Alike.