Ostatnio udało mi się okiełznać składnik systemu Windows o którym głośno jest od dawna. Są to Services For Unix, element mający na celu dostosowanie Okien spod igły Microsoftu do wymanagań standardu POSIX.
O ile wersja umieszczona na płytach instalacyjnych jest praktycznie nie do użytku ze względu na ubogi zasób narzędzi oraz totalny brak mechanizmów zarządzających, o tyle najnowsza edycja robi wrażenie. Zarządzanie z poziomu MMC, składniki WMI oraz prawie pełne odwzorowanie API znane z Linux/Unix’ów umożliwia praktycznie pozbycie się z dysku Cygwina. Do obszernych możliwości tego podsystemu, bo całość architektury jest bardzo podobna do bardzo dobrze znanych mechanizmów emulacji systemów 16bitowych, jeszcze powrócę. Dzisiaj chciałbym zwrócić szczególną uwagę na jeden ważny element tego pakietu, mianowicie na Klienta NFS.
Ma on dwie bardzo ważne zalety – ogólnodostępność oraz podobieństwo zarówno do narzędzi znanych z linuxa (wykorzystanie polecienia mount) jak i windowsa (możliwość operowania na ścieżkach przypominających NetBios). A więc do rzeczy.
Instalacja wszystkich składników jest bardzo przydatna, uważam że nie ma sensu oszczędzać niczego z tych 450MiB jakie zajmuje pakiet. Z całą pewnością będzie to dobrze spożytkowana powierzchnia dysku. Dlatego nie rozwodzę się zbyt długo nad samą instalacją.
Następnym krokiem jest konfiguracja mapowania użytkowników, jednak w najbardziej podstawowym zastosowaniu, gdy możemy sobie pozwolić na autoryzację jedynie za pomocą adresu IP (podstawowa metoda identyfikacji klienta przez serwer NFS) można to pominąć. Więcej szczegółów na ten temat w doskonały sposób opisał Ashish.Tak więc teraz powinniśmy się zająć konfiguracją naszego serwera nfs. Piszę o tym, ponieważ jednym z częstszych zastosowań tego mechanizmu są sytuacje przejściowe – wszelkiego typu migracje, przenosiny, i inne podobne im operacje. A w ferworze walki często można coś zapomnieć, czy przeoczyć, czego jestem najlepszym przykładem.
Tak więc, po pierwsze należy zwrócić uwagę na plik /etc/exports (lokalizacja na pewno sprawdzona na systemie Gentoo, w innych powinna być podobna), w którym zapisujemy wszystkie katalogi które chcemy udostępnić przez nfs. Koniecznie upewnijmy się, że stacja kliencka należy do podsieci uwzględnionej we wpisach share’ów! W tym momencie możemy ustanowić faktyczne połączenie do serwera:
1
| mount \\<em>servername</em>\<em>sharename</em> Z: |
gdzie servername – nazwa naszego serwera nfs, sharename – jeden z udostępnionych katalogów (widniejący w /etc/exports), a Z: – litera dysku pod którą chcemy ujrzeć podmontowany zasób. Od tego momentu powinniśmy ujrzeć drzewo katalogów podmontowane pod określoną literę dysku. Powinniśmy, ponieważ to nie koniec.
Jeśli to się nie powiedzie, należy spojrzeć do konfiguracji SFU w mmc. Potrzebujemy zmodyfikować opcję „Prevent use of low port numbers”. Chodzi w tym o to, iż klient windowsowy domyślnie operuje na dowolnych wolnych portach powyżej 1024, co często jest przyczyną konfliktu ze starszymi wersjami serwerów nfs, które oczekują połączeń na „klasycznych” portach.
Trzecim, wcale nie oczywistym problemem jest kwestia praw dostępu. Jak pamiętamy, dla prostoty pominęliśmy konfigurację mapowania nazw użytkowników. Zagadnienie które pochłonęło mi dużo czasu brzmiało „to w takim razie z jakimi poświadczeniami uzyskuję dostęp do plików” ? Jak się okazało, z pomocą przyszły dobrodziejstwa unixowego systemu plików. Wystarczy jedynie nadać uprawnienia w trzeciem „triplecie” rwxrwxrwx odpowiednie dla naszych potrzeb. Kwestię bezpieczeństwa i fakt że większość adminów unixowych podniosła by wielkie larum widząc coś w stylu rw-r–rw- pozostawiam na boku, jako że w zamierzeniu było szybkie skopiowanie danych i nic więcej. Ta sztuczka pozwala przestać się przejmować jakimikolwiek poświadczeniami. Wykorzystujemy triplet „others”.
Te trzy proste ustawienia nie wyglądają groźnie. Ale wiedziony doświadczeniem, podpowiadam, że najciemniej jest zawsze pod latarnią.
O innych dobrodziejstwach SFU już wkrótce.