Wprowadzenie do Samby, Część druga

1.  Kompilowanie, instalowanie i konfigurowanie Samby w naszym środowisku

Pobieranie Samby

Zacznijmy od pobrania źródeł Samby w wersji 2.0.7 lub nowszej ze strony Samba.org (link w dziale Zasoby pod koniec artykułu).

Po pobraniu Samby w wersji 2.0.7 lub nowszej czas rozpakować źródła do dowolnego katalogu. Wydajmy następujące polecenie w wierszu poleceń:

$ tar -xzvf samba-2.0.7.tar.gz

Zostanie utworzony katalog samba-2.0.7. Przejdźmy do niego poleceniem cd i rozejrzyjmy się. Przede wszystkim należy zwrócić uwagę na katalog docs. Wewnątrz znajdziemy podkatalog o nazwie textdocs, który zawiera sporą część dokumentacji Samby. Jednym z najważniejszych plików, jakie można w nim znaleźć to DIAGNOSIS.txt. Poprowadzi on nas przez proces diagnozy ewentualnych problemów z Sambą. Później omówimy część z opisanych w nim procedur.

Kompilowanie i instalowanie Samby

Zauważmy też katalog o nazwie sources w głównym katalogu samba-2.0.7. Wewnątrz znajdziemy skrypt configure, stworzony z myślą o poprawnym utworzeniu wszystkich plików Makefile. Jak w przypadku każdego innego skryptu configure, listę opcji konfiguracji uzyskujemy pisząc:

$ ./configure --help

Aby przejrzeć wszystkie opcje, najlepiej przekierować wyjście do polecenia more:

$ ./configure --help | more

Zwróćmy uwagę na opcje dotyczące katalogów i nazw plików. Domyślną ścieżką instalacji jest /usr/local/samba. Najlepiej będzie zmienić ją na /usr/local, przekazując parametr --prefix=/usr/local do skryptu configure. Na potrzeby niniejszego artykułu użyję następujących ustawień ścieżek:

$ ./configure --prefix=/usr/local --localstatedir=/var/log --sysconfdir=/etc

Powyższe opcje spowodują instalację domyślnego drzewa katalogów Samby do katalogu /usr/local, z wyjątkiem plików konfiguracyjnych, które znajdą się w katalogu /etc oraz logów, których Samba będzie spodziewać się w katalogu /var/log. Jeśli pominiemy powyższe opcje, wszystkie te katalogi znajdą się w drzewie /usr/local/samba (/usr/local/samba/var, /usr/local/samba/etc, itd.).

Nadszedł czas na kompilację. Gdy skrypt configure skończy pracę, napiszmy:

$ make

Po zakończeniu procesu kompilacji należy zainstalować całość, pisząc poniższe polecenie jako użytkownik root:

# make install

Konfigurowanie serwera

W większości sytuacji konfigurowanie Samby sprowadza się do edycji pliku smb.conf, ponieważ jest to jej główny plik konfiguracyjny. Posiada on wiele różnych opcji, dlatego aby uniknąć zamieszania zaczniemy jedynie od tych, które są niezbędne do poprawnego działania oprogramowania. Przede wszystkim musimy dowiedzieć się gdzie powinniśmy umieścić plik smb.conf. Jeśli użyliśmy powyższych parametrów do skryptu configure, należy umieścić go w katalogu /etc. Gdybyśmy jednak użyli domyślnych ścieżek, Samba będzie szukać tego pliku w katalogu /usr/local/samba/etc. Zacznijmy przechodząc do odpowiedniego katalogu, uruchamiając nasz ulubiony edytor tekstu i pisząc następujące linijki. Poniżej dodam komentarz do każdej linijki aby łatwiej było zrozumieć co każda z nich robi.

[global]
workgroup = NASZAGRUPAROBOCZA
security = user
encrypt passwords = yes
guest account = guest

Pierwsza linijka informuje Sambę, że umieszczamy opcje w sekcji "global". Istnieje wiele opcji, które należy definiować tylko w tej sekcji. Opcje te sterują ogólnym zachowaniem Samby.

Druga linijka podaje Sambie nazwę grupy roboczej, którą ma utworzyć. Należy zastąpić NASZAGRUPAROBOCZA właściwą dla nas nazwą.

W trzeciej linijce instruujemy Sambę aby pracowała w trybie bezpieczeństwa użytkownika. Dzięki tej opcji Samba poinformuje wszystkie klienty Windows o konieczności podania właściwej nazwy użytkownika i hasła w celu uzyskania dostępu do jakiegokolwiek zasobu sieciowego. Jest to bardzo dobre rozwiązanie. Bezpieczeństwo w trybie użytkownika jest najczęściej wykorzystywanym trybem bezpieczeństwa Samby, ponieważ najlepiej odpowiada większości scenariuszy udostępniania plików. Dostępne są jednakże inne tryby. W jednym z nich Samba uwierzytelnia użytkowników na podstawie bazy danych bezpieczeństwa z istniejącej instalacji Windows NT lub 2000 Server. Nie będziemy jednak omawiać go w tym artykule. Więcej informacji na jego temat można znaleźć w sekcji "security" podręcznika systemowego man do pliku smb.conf.

Kolej na czwartą linijkę. W tym miejscu konfigurujemy Sambę tak, aby wymiana haseł odbywała się w trybie szyfrowanym. Z tej opcji należy korzystać w każdej sytuacji, chyba że wszystkie nasze komputery są bardzo stare (na przykład z systemami z czasów Windows for Workgroups). Włączenie szyfrowanych haseł powoduje, że Samba oprócz standardowej uniksowej bazy danych passwd potrzebuje własnego pliku z hasłami. Nie należy jednak sądzić, że wyłączenie tej opcji ułatwi nam życie, ponieważ będziemy musieli zajmować się tylko jednym plikiem. Wyłączenie szyfrowanych haseł spowoduje problemy z udostępnianiem zasobów nawet pod relatywnie starymi systemami Windows NT 4.0, nie wspominając o Windows 2000. Samba dostarcza nam wiele sposobów na synchronizowanie obu baz danych, jeśli nie chcemy się opiekować nimi osobno. Jest to zdecydowanie lepsze rozwiązanie niż wyłączanie szyfrowania.

Kolejna linijka podaje konto użytkownika systemu Unix, które zostanie wykorzystane do dostępu gościa. Mimo iż częstą praktyką jest podawanie "guest account=nobody", sugeruję dodanie użytkownika "guest" do systemu, o ile jeszcze go nie ma. Konto to nie potrzebuje hasła i nie trzeba umożliwiać interaktywnego logowania się na nie (aczkolwiek nic się nie stanie jeśli nadamy mu hasło i domyślną powłokę systemową).

Teraz można już dodać obsługę WINS. W tym celu należy dodać jedną z poniższych linijek w sekcji "global" pliku smb.conf.

wins support = yes

LUB

wins server = adres IP serwera WINS

Jeśli posiadamy już serwer WINS w naszej podsieci (na przykład WINS działający pod systemem Windows NT Server), będziemy chcieli użyć drugiej opcji i podać adres IP tego serwera po prawej stronie znaku równości. Wewnętrzna usługa WINS Samby zostanie wówczas wyłączona i zostanie użyty podany serwer WINS.

Jeśli nie posiadamy osobnego serwera WINS lub konfigurujemy Sambę w domu i nie orientujemy się nawet czym jest serwer WINS, powinniśmy wybrać pierwszą opcję. Samba wówczas sama będzie pełnić funkcję takiego serwera w naszej sieci LAN.

Być może zadajemy sobie pytanie jaką funkcję pełni serwer WINS. Ogólnie rzecz biorąc jest to lokalna dynamiczna baza danych DNS. Gdy Samba pracuje jako serwer WINS, każdy komputer kompatybilny z Windows w naszej podsieci zarejestruje w Sambie swój adres IP i nazwę NetBIOS (czyli potocznie "nazwę komputera"). Dzięki temu komputery Windows będą korzystać z bazy danych WINS w Sambie w celu uzyskania adresu IP komputera o danej nazwie NetBIOS. WINS to kluczowy składnik przeglądania sieci i to właśnie z niego korzystamy, gdy rozglądamy się po Otoczeniu Sieciowym systemu Windows.

Możemy teraz dodać kilka kolejnych opcji do globalnej sekcji:

local master = yes
os level = 99
domain master = yes
preferred master = yes

Czas na wyjaśnienia. Wszystkie te opcje są związane z przeglądaniem sieci. Już wspomnieliśy że WINS jest kluczowym składnikiem tego zagadnienia, istnieje jednak kolejny element wymagany do poprawnego działania przeglądania sieci. Musi istnieć główna lokalna przeglądarka (ang. local master browser). Brzmi to dość dziwnie, czas więc na wyjaśnienia.

Aby przeglądanie sieci działało poprawnie, musi istnieć jakieś główne miejsce, w którym zapisane jest jakie komputery i grupy robocze są przyłączone do lokalnej podsieci. Taka lista określana jest mianem listy przeglądania (ang. browse list). Na podstawie tej listy konstruowana jest lista grup roboczych, domen i komputerów, które zobaczymy, gdy po raz pierwszy klikniemy na ikonie Otoczenia Sieciowego. Każdy komputer ze współczesnym systemem Windows może pełnić funkcję głównej lokalnej przeglądarki, my chcielibyśmy jednak aby w naszej sieci tę rolę pełniła Samba.

Jak tego dokonamy? Ujmując rzecz jak najprościej, wszystkie komputery z systemem Windows w naszej podsieci toczą ze sobą bitwy wysyłając pakiety tam i z powrotem między sobą, próbując określić który z nich stanie się główną lokalną przeglądarką. Proces ten nazywa się "wyborami przeglądarki" (ang. browser election).

Zwycięzca tej "wojny" na pakiety zostaje lokalną główną przeglądarką. Możemy spowodować każdorazowe zwycięstwo Samby w tych zmaganiach dzięki opcji os level = 99. Dzieje się tak, gdyż każda wersja systemu Windows (od Windows 95, przez NT, aż po 2000) posiada zapisany na stałe numer systemu operacyjnego, dzięki czemu przeglądarką powinna zostać najnowsze wydanie tego systemu. Ustawienie tej opcji na 99 spowoduje pokonanie przez Sambę każdego produktu firmy Microsoft, dzięki czemu za każdym razem zostanie ona główną lokalną przeglądarką.

Opcje bezpieczeństwa

Zanim opuścimy sekcję globalną, powinniśmy zainteresować się kilkoma opcjami bezpieczeństwa. Opcja allow hosta pozwala nam ograniczyć adresy IP, którym zezwalamy na połączenia z Sambą:

hosts allow = 192.168.1. 127.

Dzięki tej opcji jedynie komputery z podsieci o adresie 192.168.1, oraz 127 (localhost) będą mogły nawiązać połączenie z Sambą. Pamiętajmy, że zawsze należy dodać 127. na końcu linijki hosts allow.

Opcja "interfaces" jest przydatna jeśli nasz komputer posiada wiele interfejsów sieciowych. Dzięki niej możemy podać dla jakich interfejsów Samba ma być dostępna. Używa się jej następująco:

interfaces = eth1

Łatwo w ten sposób ograniczyć Sambę jedynie do tych interfejsów, na których jest potrzebna. Dzięki temu możemy zminimalizować ryzyko ewentualnych prób włamań przez niepożądanych użytkowników.

Zasób testowy

Skoro skonfigurowaliśmy już globalne opcje Samby, czas utworzyć testowy zasób, dzięki któremu będziemy mogli uzyskać dostęp do katalogu /tmp. Dodajmy następujące linijki do pliku smb.conf:

[tmp]
path=/tmp
writeable=yes

Gdy uruchamiamy Sambę, ustawienia te utworzą zasób dzielony o nazwie tmp. W zasobie tym znajdziemy zawartość katalogu /tmp na serwerze Samby. Dodatkowo jeśli dany użytkownik posiada uprawnienia zapisu w katalogu /tmp, a prawie każdy posiada, będzie możliwe tworzenie i modyfikowanie plików przez tego użytkownika w tym katalogu.

Skoro dodaliśmy już to wszystko do pliku smb.conf, czas na sprawdzenie czy nasza konfiguracja jest poprawna. Aby tego dokonać, wykorzystamy narzędzie testparm:

$ testparm

Zaraz po naciśnięciu klawisza enter na ekranie ukaże się lista wszystkich naszych opcji konfiguracyjnych. Jeśli w pliku smb.conf były jakieś błędy, również zostaniemy o tym poinformowani. W tym przypadku wystarczy stosować się do instrukcji w celu ich poprawienia. Jesteśmy teraz gotowi do skonfigurowania użytkowników i próbnego uruchomienia Samby.

Tworzenie użytkowników

Aby użytkownik "mójużytkownik" z hasłem "mojehasło" mógł korzystać z Samby, muszą zostać spełnione następujące warunki:

1. Musi istnieć konto uniksowe mójużytkownik. Nie jest wymagana możliwość logowania się na nie, również hasło tego użytkownika nie jest używane przez Sambę, dlatego możemy dowolnie je ustawić. Oczywiście w niczym nie przeszkadza jeśli mójużytkownik może się logować do systemu.
2. W pliku smbpasswd musi być dopisany użytkownik mójużytkownik. Plik ten można znaleźć w katalogu o nazwie private, który znajduje się w domyślnym katalogu instalacyjnym Samby (w naszym przykładzie będzie to /usr/local/private). Użytkownik mójużytkownik może zostać dodany do pliku smbpasswd za pomocą polecenia smbpasswd. Dokonamy tego pisząc następujące polecenia z konta użytkownika root:

# smbpasswd -a mójużytkownik
New SMB password: <tutaj należy wpisać "mojehasło">
Retype new SMB password: <i jeszcze raz "mojehasło">
Added user mójużytkownik.

Te kroki należy powtórzyć dla każdego nowego użytkownika Samby. Jeśli chcemy aby już istniejące konto uniksowe działało w Sambie, należy pamiętać o dodaniu nazwy użytkownika i hasła do pliku smbpasswd. Jeśli dodajemy użytkownika, który istnieje tylko w systemie Windows, powinniśmy pamiętać, że oprócz dodania go do pliku smbpasswd musimy także dodać konto uniksowe o identycznej nazwie użytkownika. Co więcej, konto uniksowe musimy utworzyć jako pierwsze, ponieważ dodanie użytkownika do pliku smbpasswd nie będzie możliwe, jeśli konto nie będzie już istniało.

Konieczne jest istnienie obu kont, ponieważ Samba wykorzystuje konto uniksowe do sprawdzania uprawnień dostępu do plików na dysku, natomiast plik smbpasswd jest wykorzystywany do uwierzytelniania. Jeśli będziemy łączyć się z systemu Windows NT, powinniśmy dodać użytkownika o nazwie "administrator".

Ostateczna konfiguracja serwera

Jesteśmy już prawie gotowi do uruchomienia Samby i konfigurowania komputerów klienckich. Najpierw jednak musimy upewnić się czy komputer z Sambą jest w stanie pingować każdy komputer z Windowsem w sieci, posługując się jego nazwą. Jeśli tak nie jest, konieczne będzie dodanie odpowiednich wpisów do pliku /etc/hosts lub uaktualnić naszą usługę DNS.

Warto też zaznaczyć, że Samba działa najlepiej gdy w pliku /etc/hosts do adresu 127.0.0.1 przypisana jest tylko nazwa "localhost". Wpis FQDN dla naszego komputera powinien być przypisany do głównego adresu IP używanego w naszej sieci LAN. Na przykład:

fragment pliku /etc/hosts

127.0.0.1       localhost
192.168.1.1   mójkomputer mójkomputer.mojadomena.com

Uruchamianie Samby

Samba jest już skonfigurowana i gotowa do pracy. Uruchomimy ją i skupimy się na prawidłowej konfiguracji komputerów z systemem Windows. Aby uruchomić Sambę, jako root wydajmy następujące polecenia:

# smbd
# nmbd

Uruchomi to dwa główne procesy Samby, smbd i nmbd. Będą one logować wszelkie komunikaty informacyjne i komunikaty błędów odpowiednio do plików /var/log/log.smb i /var/log/log.nmb. Teraz skoro część uniksowa działa, czas zająć się klientami i prawidłowo je skonfigurować.

Konfigurowanie komputerów klienckich

Aby skonfigurować komputer z systemem Windows w celu korzystania z naszej Grupy Roboczej z Samby, należy upewnić się, że protokół TCP/IP został na nich prawidłowo skonfigurowany. Powinniśmy także upewnić się, że:

1. Możliwe jest pingowanie serwera uniksowego spod Windows przy użyciu jego nazwy (pisząc w wierszu poleceń ping mójserwer).
2. Nasz komputer z systemem Windows został skonfigurowany do korzystania z serwera WINS. Jeśli Samba pełni rolę takiego serwera, należy podać w konfiguracji adres IP serwera Samby. Jeśli nie, należy podać adres IP działającego serwera WINS. Zwykle konfiguruje się to w oknie ustawień TCP/IP.
3. Nasz komputer z systemem Windows należy do grupy roboczej NASZAGRUPAROBOCZA.

Testowanie

Nadeszła chwila prawdy. Gdy tylko komputery z systemem Windows zakończą proces ponownego uruchamiania się, zalogujmy się do nich, używając nazwy użytkownika i hasła, które zostaną zaakceptowane przez Sambę. Jeśli korzystamy z systemów Windows 95/98, nasza nazwa użytkownika i hasło zostaną przechowane w pliku i wykorzystane, gdy będziemy chcieli połączyć się z jakimś zasobem sieciowym.

Jeśli zaś korzystamy z systemu Windows NT Workstation, nazwa użytkownika i hasło muszą istnieć także w lokalnej bazie danych bezpieczeństwa, inaczej nie będziemy mogli się zalogować do systemu. Jeśli tak nie jest, musimy zalogować się jako administrator i utworzyć konto za pomocą menadżera użytkowników. Następnie powinniśmy się wylogować i zalogować się ponownie jako nowo utworzony użytkownik.

Po prawidłowym zalogowaniu się kliknijmy dwukrotnie na Otoczeniu Sieciowym i zajrzyjmy do grupy roboczej o nazwie NASZAGRUPAROBOCZA. Sprawdźmy czy znajduje się w niej nasz serwer Samby. Kliknijmy dwukrotnie na nim i zobaczmy czy widać zasób /tmp. Jeśli tak, to gratuluję, Samba działa! Jeśli nie, oto co możemy zrobić:

1. Spróbujmy uruchomić program testparm. Czy z plikiem smb.conf jest wszystko w porządku? Jeśli nie, to należy poprawić błędy i uruchomić ponownie Sambę.
2. Czy działają procesy smbd i nmbd? Jeśli nie, przejrzyjmy logi pod kątem błędów, poprawmy ewentualne problemy i zrestartujmy procesy smbd i nmbd.
3. Czy skonfigurowaliśmy komputery z systemem Windows tak, aby używały odpowiedniego serwera WINS? Jeśli nie, nie będą one potrafiły odczytać adresów IP komputerów w naszej sieci.
4. Czy możliwe jest pingowanie komputerów z systemem Unix spod Windows i odwrotnie? Jeśli nie, powinniśmy skonfigurować plik /etc/hosts lub serwer DNS aby poprawnie działała translacja nazw.

Jeśli wszystko to się zgadza, ale Samba nadal nie działa, należy uważnie przeczytać każdy krok wyszczególniony w pliku DIAGNOSIS.txt, który znajduje się w katalogu docs/textdocs. Powinniśmy w krótkim czasie odnaleźć i rozwiązać problem z konfiguracją lub z siecią. Pamiętajmy jednak, że jeśli choć nieznacznie zmodyfikujemy zawartość pliku smb.conf, powinniśmy wysłać procesom smbd i nmbd sygnał HUP, aby zmusić je do ponownego odczytania tego pliku. Dokonamy tego w następujący sposób:

# kill -hup <pid procesu smbd>
# kill -hup <pid procesu nmbd>

Innym sposobem będzie zabicie procesów smbd i nmbd i uruchomienie ich ponownie.

W następnym odcinku

W kolejnym artykule o Sambie mojego autorstwa przybliżę bardziej zaawansowane opcje Samby. Wówczas będziemy potrafili skonfigurować zasoby dzielone dokładnie tak jak chcemy. Przyjrzymy się też kilku zaawansowanym funkcjom, jak na przykład drukowaniu przez Sambę. Do zobaczenia w następnym odcinku!

Zasoby

• Strona główna Samby.
• Lista dyskusyjna Amiga Samba.
• Samba według Eda Weinberga.
• Książka Samba Unleashed. Autor: Steve Litt, współautor: Daniel Robbins.
• Książka Using Samba (Wydawnictwo O'Reilly Publishing; 1999).
• Samba Notes o Sambie i dystrybucji RedHat.
• Strona główna narzędzia SWAT.