Wprowadzenie do Samby, Część pierwszaNajpierw przyjrzymy się kilku zrzutom ekranu, które zostały zrobione na jednym z moich komputerów o nazwie "kompressor", na którym pracuje system Windows NT. Ukazują one jak od strony systemu Windows wygląda w pełni skonfigurowany system z Sambą. Pomoże nam to zrozumieć co w rzeczywistości potrafi Samba. Aktualnie w mojej wewnętrznej sieci LAN pracują trzy komputery:
W tym środowisku używam Samby przede wszystkim do udostępniania plików, drukarek, a nawet uruchamiania aplikacji systemu Windows bezpośrednio z komputera freebox (Unix). Oto zrzut ekranu, który ukazuje zawartość Otoczenia Sieciowego komputera kompressor:
Jak widać, zarówno ntbox jak i kompressor są widoczne, co nie powinno nas dziwić, gdyż obydwa komputery pracują pod kontrolą systemu NT Workstation. Bardziej nietypowe jest to, że widzimy także system freebox. Działa na nim Samba, dlatego można go zobaczyć w Otoczeniu sieciowym każdego komputera z systemem Windows, jeśli tylko będzie on należał do mojej grupy roboczej o nazwie "GENTOO". Zobaczmy teraz co kryje się "wewnątrz" komputera freebox. Gdy klikniemy podwójnie na ikonie freebox, pojawi się poniższe okienko:
W oknie widzimy kilka tak zwanych "zasobów udostępnionych" (ang. shares). Dokładniej nazywa się je zasobami SMB/CIFS i są one tą częścią systemu plików komputera freebox, która została udostępniona przez sieć.
Samba na komputerze freebox została specjalnie skonfigurowana, aby udostępniać tylko wyżej widoczne zasoby. Gdy zajrzymy do zasobu o nazwie drobbins, ujrzymy zawartość mojego katalogu domowego. Preferuję przechowywanie wszystkich moich plików na komputerze freebox (pod Uniksem), aby mieć je w jednym miejscu i móc łatwo nimi zarządzać. Jedną z najlepszych cech Samby jest to, że umożliwia administratorom przechowywanie plików użytkowników w jednym miejscu, zamiast dawać im osobne położenia pod Windowsem i Uniksem. Oprócz zwykłych zasobów udostępnionych (które pełnią funkcję wirtualnych katalogów) widzimy także zasób drukarki o nazwie nec. Kolejną znakomitą funkcją Samby jest możliwość udostępnienia drukarek w ten sam sposób jak na dowolnym komputerze z systemem Windows. Nec to moja drukarka laserowa NEC SuperScript 870, która jest podłączona do komputera freebox i skonfigurowana za pomocą lpd jako standardowa drukarka uniksowa. Dzięki Sambie windowsowe klienty mogą używać jej tak samo jak używałyby zwykłej drukarki sieciowej Windows. Można postawić sobie pytanie w jaki sposób rozwiązana jest kwestia sterowników drukarki, skoro działa ona w systemie Unix. W komputerze freebox nec jest skonfigurowana jako standardowa drukarka podłączona do portu równoległego, działająca w trybie "surowym" (ang. raw mode). Innymi słowy, wszelkie przesłane do niej zadania drukowania są obsługiwane bezpośrednio przez nią w postaci nieprzetworzonej. W komputerze kompressor nec jest skonfigurowana jako drukarka sieciowa NEC SuperScript 870. Gdy chcę coś na niej wydrukować, lokalny sterownik NT generuje odpowiednie dla niej dane binarne, które zostają automatycznie przesłane przez sieć do Samby na komputerze freebox. Samba następnie automatycznie przekazuje nietknięte dane do kolejki drukarki, a ta wówczas rozpoczyna wydruk. Muszę zaznaczyć, że moja drukarka nie jest drukarką postscriptową, lecz używa własnościowej technologii PrintGear firmy Adobe. Pomimo iż drukarka ta nie jest w pełni obsługiwana w systemie Unix, to działa idealnie gdy drukuje się spod Windows. Dzieje się tak, gdyż wszystkie dane przeznaczone dla drukarki są generowane po stronie systemu Windows, przez jego sterownik. Tak więc ze względu na brak obsługi technologii PrintGear przez Ghostscript (swobodnie dostępny interpreter PostScript dla systemów Unix) po stronie Uniksa mogę drukować jedynie tekst ASCII lub dokumenty PCL4 w rozdzielczości 300 dpi. Po stronie Windows zaś sterownik Windows NT umożliwia mi drukowanie w pełnej rozdzielczości 600 dpi. Aktualnie nie przeszkadza mi to, ponieważ i tak przez większość czasu drukuję spod systemu Windows. W przyszłości jednak lepiej byłoby posiadać drukarkę z wbudowaną obsługą PostScript aby również w systemach Unix móc w pełni wykorzystać jej funkcjonalność. Czas przyjrzeć się następnemu zrzutowi ekranu. Ukazuje on zawartość zasobu o nazwie drobbins na komputerze freebox. Komputer ten jest skonfigurowany w celu udostępnienia mojego katalogu domowego z systemu Unix. Wszystkie pliki widoczne w oknie w rzeczywistości znajdują się na komputerze freebox, są jednak bezpośrednio dostępne z komputerów klienckich Windows NT. Możliwość integracji systemów Windows i Unix jest nieoceniona.
Aby ukazać wewnętrzne mechanizmy działania Samby, wyjaśnimy najpierw w sposób uproszczony co tak naprawdę się działo, gdy rozglądaliśmy się po Otoczeniu Sieciowym. Najpierw jednak muszę wyjaśnić jedną kwestię dotyczącą mojej aktualnej sesji Windows. Ponieważ używam systemu Windows NT Workstation, musiałem zalogować się w celu uzyskania dostępu do komputera. W tym przypadku logowanie nastąpiło przy użyciu nazwy użytkownika "Administrator" i hasła "mojehasło". Gdybym używał systemu Windows 95 lub 98, standardowe sterowniki sieciowe Windows również spytałyby mnie o nazwę użytkownika i hasło. W tych systemach jednak nie zostałoby użyte do określenia kto może mieć dostęp do komputera. Zamiast tego dane te zostają przechowane w celu późniejszego użycia przy łączeniu się z zasobami sieciowymi. Windows NT jest rzecz jasna nieporównywalnie bardziej bezpieczny od systemów Windows 95 i 98 i nie zezwoli na korzystanie z komputera jeśli podamy nieprawidłową nazwę użytkownika lub hasło. Po sprawdzeniu w lokalnej bazie bezpieczeństwa czy podane przeze mnie dane są prawidłowe, kompressor zezwolił mi na korzystanie z systemu Windows. Dane te także zostaną przez niego użyte do automatycznego uwierzytelnienia się przy łączeniu się z chronionymi hasłem zasobami sieciowymi. Po kliknięciu na Otoczenie Sieciowe ukazało się okno z listą wszystkich kompatybilnych z systemem Windows komputerów podłączonych do mojej sieci. Aby było to możliwe, komputer kompressor skontaktował się za naszymi plecami z komputerem freebox w celu otrzymania listy wszystkich kompatybilnych z Windows komputerów w aktualnej podsieci. Do kontaktu tego doszło, ponieważ skonfigurowałem Sambę na freeboksie jako "główną lokalną przeglądarkę" w mojej sieci, co oznacza, że to freebox zarządza listą zasobów sieciowych, które pojawiają się w oknie Otoczenie Sieciowe. Następną czynnością było podwójne kliknięcie na freebox, dzięki czemu ukazało się okno z zasobami komputera freebox. Aby kompressor mógł otrzymać te informacje musiał połączyć się jako gość ze specjalnym ukrytym zasobem (o nazwie IPC$) na komputerze freebox i pobrać nazwy i typy wszystkich dostępnych zasobów. W następnym artykule, kiedy to zajmiemy się konfigurowaniem Samby, będziemy musieli umieścić opcję w pliku konfiguracyjnym Samby, która określi jakie konto uniksowe odpowiada kontu "guest" (gość) w systemie NT. Jeśli byśmy tego nie wykonali, niemożliwe stałoby się przeglądanie zasobów na maszynie z Sambą. Warto o tym wspomnieć również ze względu na to, że nie potrzebujemy żadnych specjalnych uprawnień aby obejrzeć zasoby SMB/CIFS na serwerze Samby, co jest istotne ze względów bezpieczeństwa. W ten sposób możliwe było wyświetlenie zawartości mojego katalogu domowego poprzez kliknięcie zasobu o nazwie drobbins. Pomimo iż stało się to automatycznie, warto wiedzieć o ukrytej wymianie danych między komputerami freebox i kompressor, dzięki której uzyskaliśmy dostęp do zasobu drobbins. Zanim jednak zagłębimy się w szczegóły, omówmy krótko kilka zagadnień bezpieczeństwa Samby. Konfigurując Sambę zabezpieczyłem zasób drobbins hasłem. Pomimo iż jestem podłączony tylko do prywatnej sieci LAN, wolę utrzymywać pewien podstawowy poziom bezpieczeństwa. Jednocześnie utworzyłem dwóch użytkowników Samby: "drobbins" i "administrator". Ich hasła pokrywają się z tymi, jakie mają na stacjach roboczych NT. Reguły bezpieczeństwa dla zasobu drobbins są następujące: dostęp do zasobu uzyskamy, gdy jesteśmy poprawnym użytkownikiem Samby i podamy właściwe hasło dla tego użytkownika. Tak więc zarówno użytkownik "drobbins" jak i "administrator" uzyskają dostęp gdy zostanie podane prawidłowe hasło. Wróćmy teraz do "rozmowy" pomiędzy komputerami freebox i kompressor. Ponieważ zalogowałem się jako administrator, kliknięcie na zasób o nazwie drobbins spowodowało automatyczną próbę uwierzytelnienia mnie przez Windows NT w Sambie poprzez przesłanie nazwy użytkownika "administrator" i hasła "mojehaslo" do komputera freebox. Samba wówczas porównała te wartości ze swoją bazą bezpieczeństwa (niezależną od zwykłej uniksowej bazy passwd), w ten sposób sprawdzając nazwę użytkownika i hasło. Okazały się one prawidłowe, więc Samba udzieliła mi dostępu. Można zadać sobie pytanie dlaczego Samba ma własną bazę danych z hasłami. Czemu nie użyje po prostu standardowej uniksowej bazy w celu uwierzytelnienia użytkownika "administrator"? Dawniej, gdy Windows przesyłał hasła otwartym tekstem było to możliwe, jednak wszystkie współczesne wersje tego systemu przesyłają hasła SMB/CIFS w postaci zaszyfrowanej, która nie jest kompatybilna ze standardowym szyfrem uniksowym. Innymi słowy Samba nie ma możliwości użycia uniksowej bazy haseł do zweryfikowania hasła przysłanego przez Windows. Na szczęście istnieje wiele sposobów na zsynchronizowanie obu baz danych, co znacznie ułatwia życie administratorom Samby. Zapoznaliśmy się już Sambą od strony systemu Windows, czas więc przyjrzeć się jak jej działanie wygląda z punktu widzenia systemów uniksowych. Najpierw garść ogólnych informacji. Stroną domową projektu Samba jest http://fi.samba.org, zaś aktualna wersja Samby w dniu 25 kwietnia 2000 roku to 2.0.7 i to z niej będziemy korzystać w tej serii artykułów. Możemy mieć do czynienia z pewnym zróżnicowaniem w położeniu plików w systemie, ponieważ Sambę można zainstalować z menadżera pakietów RPM, na systemach FreeBSD lub Solaris (a więc nie tylko pod Linuksem), a także kompilując ją od podstaw ze źródeł. Domyślne położenia plików są konfigurowalne przy kompilacji. W niektórych systemach pewne pliki będą się znajowały w katalogu /usr/local/, w innych zaś w innym miejscu. Od tej pory mówiąc o plikach konfiguracyjnych będziemy podawali jedynie ich nazwy zamiast pełnych ścieżek aby unikać nieścisłości. Kompilując i instalując Sambę przy użyciu oryginalnych źródeł jej plik konfiguracyjny to /usr/local/samba/etc/smb.conf. Natomiast instalując ją za pomocą RPM lub innych linuksowych systemów zarządzania paczkami najpewniej znajdziemy plik smb.conf w katalogu /etc. Szybko można się w tym pogubić. W celu uproszczenia tego wszystkiego, omówię położenia plików przy Sambie skompilowanej ze źródeł i zainstalowanej w domyślnym katalogu /usr/local/samba. Należy jednakże zwrócić uwagę, że celem tej sekcji nie jest opisanie procesu kompilacji, który to zostanie omówiony w następnym artykule. Teraz chodzi jedynie o przybliżenie konfiguracji Samby pod Uniksem w ramach rozgrzewki. Oto domyślne położenia plików zaraz po kompilacji i instalacji Samby: Ścieżka /usr/local/samba/bin zawiera wszystkie binarne pliki wykonywalne Samby. W wersji 2.0.7 podstawowe pliki wykonywalne to smbd i nmbd. Program smbd dostarcza usługi udostępniania plików poprzez SMB/CIFS, zaś nmbd wykonuje czynności związane z WINS, ułatwiając wyszukiwanie adresów IP dla nazw NetBIOS. Inne programy narzędziowe to na przykład smbclient, podobny w działaniu do ftp, którego można użyć w celu połączenia się i interakcji z udostępnionymi zasobami SMB/CIFS, oraz testparm, który sprawdza poprawność składni głównego pliku konfiguracyjnego Samby. W ścieżce /usr/local/samba/etc można znaleźć główny plik konfiguracyjny Samby, smb.conf. Jest on bardzo istotny, gdyż zawiera niemal wszystkie opcje konfiguracji. W tym pliku możemy ustawiać zarówno globalne opcje konfiguracji, jak i skonfigurować udostępnianie konkretnych katalogów i drukarek. W miarę postępów w używaniu Samby będziemy w stanie dodawać kolejne opcje konfiguracji do pliku smb.conf, dostrajając Sambę do konkretnych potrzeb. Jednym z najczęściej spotykanych zarzutów wobec Samby jest to, że trudno jest opanować poprawną edycję pliku smb.conf. To prawda, należy jednak pamiętać, że Samba nie jest tylko prostym programem do udostępniania plików. Ciąży na niej odpowiedzialność za integrację dwóch zupełnie różnych systemów: Windows i Unix. Czasem proces konfiguracji może wydawać się uciążliwy, nie należy jednak się tym przejmować. Gdy wszystko zacznie działać poprawnie przekonamy się, że trud się opłacił. Katalog /usr/local/samba/private zawiera zaszyfrowany plik z hasłami samby, smbpasswd.
Jak już wcześniej wspomniałem, Samba przechowuje hasła niezależnie od standardowej uniksowej bazy passwd. Wszystkie nazwy użytkowników i stacji roboczych (wraz z odpowiadającymi im hasłami), dzięki którym można uzyskać dostęp do zasobów Samby znajdują się w pliku smbpasswd. Dodatkowo dostęp do pojedynczych zasobów można ograniczyć do określonych użytkowników i grup. Modyfikacji pliku smbpasswd dokonuje się za pomocą tak samo nazwanego programu smbpasswd. Ścieżka /usr/local/samba/var zawiera obydwa pliki z logami Samby, log.smb i log.nmb. Jak nietrudno się domyślić, plik log.smb to log programu smbd, zaś log.nmb pełni identyczną funkcję dla programu nmbd. Katalog /usr/local/samba/swat zawiera pliki narzędzia SWAT. SWAT to skrót od Samba Web Administration Tool (narzędzie do administracji Sambą przez sieć). Jest to niewielka, pożyteczna aplikacja sieciowa, za pomocą której administratorzy mogą zdalnie zarządzać Sambą. W tej serii artykułów nie będziemy zajmować się narzędziem SWAT, można jednak dowiedzieć się o nim więcej z jego strony głównej, której adres znajdziemy poniżej, w sekcji Zasoby. Omówiliśmy wiele z kluczowych koncepcji i najważniejsze zagadnienia z funkcjonalności Samby. Przyjrzeliśmy się również uniksowym strukturom plików Samby. W następnym artykule omówimy krok po kroku proces konfiguracji Samby na własnym systemie. Będzie on w większym stopniu przypominał poradnik, zamiast koncentrować się na zagadnieniach. Teraz gdy mamy je już za sobą, pora nieco zwiększyć tempo. Do zobaczenia!
|
|
