Poniższy artykuł opisuje jak skonfigurować AmigaOS 3.x, AmiTCP oraz ch_nfs, tak aby dostęp do plików znajdujących się na systemach rodziny UNIX był bardzo wygodny. Z pewnością temat zainteresuje każdego, kto oprócz Amigi używa np. PC z Linuksem.
Ostatnią "darmową" wersją AmiTCP jest 3.0b2. Mało kto wie, iż wraz z pakietem AmiTCP dostarczony jest klient sieciowego systemu plików. NFS, bo o nim mowa, jest niejako standardem wymiany plików miedzy systemami UNIX-owymi. Przede wszystkim do jego działania potrzebny jest stos IP i przyznam, że nie sprawdzałem działania klienta ch_nfs z innym stosem niż AmiTCP. Dokumentacja sugeruje, że AmiTCP jest wymagany. Dlatego w dalszej części tego artykułu będę zakładał, że posługujemy się AmiTCP 3.0b2. Nie będę opisywał jego konfiguracji, gdyż jest to temat, który był już wielokrotnie poruszany (także na łamach PPA). Pierwszym krokiem do uzyskania klienta NFS jest instalacja oraz konfiguracja AmiTCP.
Gdy uzyskamy działające środowisko z AmiTCP, należy zaktualizować ch_nfs do wersji 1.02 (pobrać można stąd). Instalacja sprowadza się do podmiany plików na wersje znajdujące się w archiwum 1.02.
Konfiguracja serwera na UNIX-ie
Konfiguracja serwera jest zależna od konkretnej implementacji, dlatego też będziesz musiał odwołać się do dokumentacji swojego systemu operacyjnego. Niezależnie od tego z jakiego UNIX-a korzystasz, serwer NFS wykorzystuje trzy komponenty: portmapper RPC, daemon montowania zasobów NFS oraz serwer plików NFS. Wszystko sprowadza się do ich odpowiedniej konfiguracji. W dokumentacji mogą pojawić się wzmianki o różnych wersjach protokołu NFS, ale nas interesuje jedynie wersja 2, gdyż taką zaimplementowano w ch_nfs. Dla przykładu załączam opis konfiguracji serwera dla systemów Fedora Linux oraz NetBSD.
AmigaOS nie zna konceptu UNIX-owego użytkownika, więc zalecane jest skonfigurowanie mapowania żądań z klienta na konkretnego użytkownika po stronie UNIX-a (co też w poniższych przykładach uczyniono).
NetBSD
W przypadku systemu NetBSD sprawa jest bardzo prosta, gdyż serwer NFS jest częścią standardowej instalacji. Operacje opisane poniżej wykonywane są z poziomu roota.
Do pliku /etc/rc.conf dopisać należy:
rpcbind=YES
mountd=YES mountd_flags="-N"
nfs_server=YES
Następnie w pliku /etc/exports definiujemy zasoby, które chcemy udostępnić. W pliku tym można zdefiniować szereg opcji, więc warto skonsultować się z dokumentacją (exports(5)).
/home -mapall=1000:100 192.168.0.10
Taki wpis oznacza, że katalog /home zostanie udostępniony dla maszyny o IP 192.168.0.10 (tzn. naszej Amigi), a na dodatek każde żądanie z tego IP będzie mapowane na lokalnego użytkownika o UID 1000 i GID 100. Najlepiej tutaj wstawić UID i GID użytkownika, którego normalnie używamy do pracy na UNIX-ie. Wartości te można uzyskać na przykład poleceniem id (będąc zalogowanym na tego użytkownika):
$ id
uid=1000(rkujawa) gid=100(rkujawa)
Następnie uruchamiamy usługi:
# /etc/rc.d/rpcbind start
# /etc/rc.d/mountd start
# /etc/rc.d/nfsd start
Warto obserwować logi systemu, mogą się tam pojawić informacje o ewentualnych błędach.
Fedora Linux
Serwer NFS nie jest częścią typowej instalacji, więc należy go doinstalować.
# yum install nfs-utils rpcbind
Konfigurujemy usługi, aby były uruchamiane wraz ze startem komputera:
# chkconfig rpcbind on
# chkconfig nfs on
Na Fedorze usługa nfs uruchamia, tak naprawdę, kilka usług (w tym daemon montowania i sam serwer NFS).
Edytujemy plik /etc/exports celem określenia udostępnianych zasobów. Składnia jest bardzo podobna do tej w NetBSD, lecz nie identyczna (po dokładny opis odsyłam do dokumentacji (exports(5))). Podobnie jak w poprzednim przykładzie konfigurujemy dostęp do katalogu /home dla 192.168.0.10 i mapowanie na użytkownika o UID 1000, GID 100.
/home 192.168.0.10(rw,all_squash,anonuid=1000,anongid=100)
Następnie uruchamiamy usługi:
# /etc/init.d/rpcbind start
# /etc/init.d/nfs start
Warto przejrzeć logi w poszukiwaniu ewentualnych błędów.
Konfiguracja klienta na Amidze
Przed przystąpieniem do dalszej konfiguracji, musimy upewnić się czy odpowiednio skonfigurowane są przypisania. Polecenie:
list AmiTCP:db
powinno zwrócić zawartość katalogu db, znajdującego się wewnątrz lokalizacji, w której zainstalowaliśmy AmiTCP. W niej też powinien się znajdować plik ch_nfstab. Plik zawiera listę woluminów oraz odpowiadających im zdalnych zasobów NFS. Wszystkie linie zaczynające się od # są oczywiście komentarzami. W pliku tym definiujemy zdalny zasób, który chcemy montować w formie:
adres_serwera:/katalog wolumin: USER lokalny_user MNT_USER lokalny_user UMASK maska
Gdzie adres_serwera to naturalnie adres serwera NFS, a katalog jest bezwzględną ścieżką do udostępnionego zasobu (identyczną jak podana w pliku /etc/exports). Natomiast wolumin: to nazwa woluminu, pod którym zasób będzie widoczny na Amidze. Parametr USER i MNT_USER określa lokalnego użytkownika z pliku passwd AmiTCP - domyślnie jest tam utworzony użytkownik amiga_user, ale można stworzyć własnego. Nie ma to większego znaczenia w naszym przypadku, gdyż i tak mapujemy wszystkie żądania na jednego użytkownika po stronie UNIX. Wartość UMASK określa uprawnienia dla tworzonych plików. Ustawienie 002 będzie powodowało, że utworzone pliki będą miały na UNIX-ie uprawienia do odczytu i zapisu dla użytkownika oraz grupy podstawowej, do której należy, a także do odczytu przez wszystkich innych użytkowników (po szczegóły odsyłam do dokumentacji (umask(2))).
Przykład:
192.168.0.2:/home mynfs: USER strim MNT_USER strim UMASK 002
W pliku ch_nfstab można określić jeszcze więcej parametrów, jednak nie są one niezbędne.
Zanim zamontujemy zdalny zasób, warto sprawdzić z Amigi czy w ogóle jest on dostępny. Można tego dokonać na przykład narzędziem showmount:
showmount -e 192.168.0.2
Taka komenda spowoduje wyświetlenie listy zasobów NFS na serwerze 192.168.0.2. Powinna zwrócić wynik w rodzaju:
Exports list on 192.168.0.2:
/home 192.168.0.10
W przypadku problemów z wykonaniem tego polecenia, należy przyjrzeć się konfiguracji po stronie serwera - czy uruchomiony jest portmapper, serwer NFS oraz czy połączeń nie blokuje firewall.
Montowanie zdalnego woluminu odbywa za pomocą polecenia ch_nfsmount:
ch_nfsmount mynfs:
Gdzie mynfs: jest nazwą woluminu zdefiniowaną w ch_nfstab. Jeżeli wszystko przebiegnie poprawnie, wówczas w systemie (a co za tym idzie, na blacie Workbencha) pojawi się nowy wolumin. Montowanie można dodać do user-startup zaraz za skryptem uruchamiającym AmiTCP.
Zasób widoczny jest jako typowy wolumin w systemie operacyjnym (tak samo jak widoczne są partycje na dyskach twardych, dyskietki, CD-ROM). Co z tego wynika? Każdy program, który używa systemowych funkcji dostępu do systemu plików, będzie współpracował także z NFS-em. Zachowanie sieciowego woluminu nie odbiega od lokalnego. Można używać go z poziomu Workbencha, AmigaShella itd. Poprawnie działają funkcje tworzenia plików, kasowania, tworzenia katalogów oraz wszelkie inne, których należałoby wymagać od systemu plików. Oczywiście, są pewne subtelne różnice między Amigą a UNIX-em, które mogą spowodować błędne działanie programów w sytuacji, gdy na przykład próbujemy go uruchomić bezpośrednio ze zdalnego zasobu.
Należy mieć na uwadze, że na zdalnym systemie istnieją UNIX-owe uprawnienia, które muszą być odpowiednio ustawione (dla użytkownika, którego zdefiniowaliśmy podczas mapowania w /etc/exports). W innym wypadku będziemy napotykali problemy z tworzeniem nowych plików lub/i ich usuwaniem. Błędnie ustawione uprawnienia mogą nawet uniemożliwić zamontowanie woluminu.
W skład ch_nfs wchodzą też różne narzędzia, które mogą okazać się przydatne podczas użytkowania NFS z Amigi. Na przykład ch_chmod do zmiany uprawnień plików, czy też rpcinfo, które pozwala na uzyskanie informacji o zarejestrowanych w portmapperze usługach.
Zalet przedstawionego rozwiązania nad FTP nie trzeba chyba wymieniać. Zasoby na zdalnej maszynie dostępne są na Amidze, tak jakby znajdowały się na dysku wewnątrz niej. NFS jest też dość wydajnym rozwiązaniem. Nie przeprowadzałem benchmarków, lecz praca jest naprawdę komfortowa nawet w przypadku A1200 z kartą PCMCIA. Jako ciekawostkę dodam, że nie tak dawno kod ch_nfs został otwarty. Jest dostępny na SourceForge w projekcie "anfs".