W tym momencie połączenie TCP/IP powinno działać bez zarzutu. Powinna istnieć możliwość pingownia komputerów w całej sieci lokalnej i jeśli masz własciwie skonfigurowaną bramkę być w stanie pingować komputery w internecie. Jak wiemy celem podłączenia komputera do sieci jest dostęp do informacji. Podczas gdy niektórzy podpinają komputery do sieci dla zabawy, wiele osób chce współdzielić zasoby i drukarki. Chcą mieć dostęp do dokumentacji w internecie i grania w gry sieciowe. Nawet jeżeli na maszynie jest zainstalowany i dzialajacy TCP/IP, jej funkcjonalność będzie wciąż bardzo ograniczona. Aby współdzielić pliki należy przemeiszczac je w tę i z powrotem używając czy to FTP czy SCP. Nie można przeglądać plikow na komputerze z Slackware z otoczenia sieciowego lub “Moich Miejsc Sieciowych” w komputerze z Widnowsem. Przydałby się również dostęp do plików na innych maszynach uniksowych.
Tak więc, chcielibyśmy móc używać sieciowego systemu plików (ang. network file system) aby umożliwić zrozumiały dostęp do plików na innych komputerach. Program, którego użyjemy do współpracy z informacjami przechowywanymi na naszym komputerze tak naprawde nie potrzebuje wiedziec na jakim komputerze znajduje sie określony plik; musi wiedziec tylko, że ten plik istnieje i jak sie do niego dostac. Wtedy to na system spada odpowiedzialnosc za umożliwienie dostępu do tego pliku przez lokalny i sieciowy system plików. Dwoma najbardziej rozpowszechnionymi sieciowymi systemami plików są SMB (jako implementacja Samby) i NFS.
SMB (od Server Message Block) jest potomkiem starszego protokołu NetBIOS, który był używany przez IBM w ich LAN Managerze. Microsoft od zawsze był zainteresowany NetBIOSem i jego nastepcami (NetBEUI, SMB i CIFS). Projekt Samba istnieje od 1991, kiedy został napisany aby połączyć IBM PC (z protokołem NetBIOS) z serwerem Uniksowym. Obecnie SMB jest preferowaną metodą współdzielenia plików i drukarek w sieci na calym świecie ponieważ jest obsługiwana przez Windows.
Plikiem konfiguracyjnym samby jest /etc/samba/smb.conf; to jeden z najlepiej skomentowanych plików konfiguracyjnych jaki można znaleźć. Przykładowe wartości zostały ustawione tak by móc je wykorzystac w razie potrzeby. Jeśli potrzebujesz większej kontroli - strony manuala dla smb.conf sa niezastąpione. Samba jest bardzo dobrze udokumenotwana (w miejscach, o których mowa wyżej), nie ma potrzeby przytaczać w tym miejscu manuala. Poniżej przedstawiono podstawy.
smb.conf jest podzielony na kilka sekcji: jedna sekcja na zasoby, i globalna sekcja dla opcji które mają być używane powszechnie. Niektóre opcje obowiazują tylko w sekcji globalnej; niektore tylko poza sekcją globalna. Pamietaj, że ustawienia w sekcji globalnej mogą zostać “podmienione/nadpisane” przez kazda inna sekcje. Odwołaj się do stron manuala po więcej informacji.
Może zajść potrzeba wprowadzenia poprawek w smb.conf by odzwierciedlał on ustawienia twojej sieci LAN. Sugeruję modyfikacje elementów wymienionych poniżej:
[global] # workgroup = NT-Domain-Name or Workgroup-Name, eg: LINUX2 workgroup = MYGROUP |
Zmień nazwę grupy roboczej aby odzwierciedlała nazwę domeny w jakiej się znajdujesz.
# server string is the equivalent of the NT Description field server string = Samba Server |
Bedzie to nazwa twojego komputera ze Slackiem wsyświetlana w katalogu z otoczeniem sieciowym..
# Security mode. Most people will want user level security. See # security_level.txt for details. NOTE: To get the behaviour of # Samba-1.9.18, you'll need to use "security = share". security = user |
W większości przypadków istotne będzie ustawienie poziomu bezpieczeństwa. Z reguły jest to poziom użytkownika (user level).
# You may wish to use password encryption. Please read # ENCRYPTION.txt, Win95.txt and WinNT.txt in the Samba # documentation. # Do not enable this option unless you have read those documents encrypt passwords = yes |
Jeśli nie włączone jest szyfrowanie haseł, nie bedziesz możliwości używać Samby z NT4.0, Win2k, WinXP, i Win2003. Wcześniejsze systemy operacyjne Windows nie wymagały szyfrowania do udostepniania plików.
SMB jest protokolem z uwierzytelnianianiem oznaczajacym, że musisz dostarczyć własciwą nazwę użytkownika i hasło aby skorzystać z usługi. Mowimy serwerowi Samby jakie nazwy użytkowników i hasła sa poprawne używajac komendy smbpasswd. smbpasswd (przy pomocy opcji wywołania) pozwala na dodanie maszyny albo tradycyjnego uzytkownika. (SMB wymaga podania nazwy NETBIOS komputerów które mają zostać dodane
Dodawanie uzytkownika do pliku /etc/samba/private/smbpasswd # smbpasswd -a user Dodawanie komputera do pliku /etc/samba/private/smbpasswd. # smbpasswd -a -m machine |
To bardzo ważne aby dodawana nazwa użytkownika lub komputera istniala w pliku /etc/passwd. Można to osiagnac przez prostą komendę adduser. Zauważ, ze kiedy używasz polecenia adduser aby dodac nazwę komputera musi ona zawierac znak dolara przy nazwie komputera (“$”). Nie powinno być to robione przez smbpasswd. smbpasswd dodaje znak dolara samoczynnie. Nie dodanie tego znaku w przypadku adduser zakończy się błędem dodawania nazwy komputera do Samby.
# adduser machine$ |
NFS (ang. Network File System) został oryginalnie napisany przez Suna dla ich implementacji Uniksa w Solarisie. Mimo, że jest znacznie łatwiej z niego korzystać (w porównaniu do SMB), jest też znacząco mniej bezpieczny. Podstawową luka w bezpieczenstwie NFS jest łatwosc podszycia sie pod ID użytkownika i grupy z jednego komputera na drugi. NFS jest pozbawiony autoryzacji. Przyszłe wersje protokołu NFS bedą miały wzmocnione bezpieczeństwo, ale nie jest to obecne w momencie pisania tego rozdziału.
Za konfigurację NFS odpowiedzialny jest plik /etc/exports. Kiedy załadujesz domyślny plik /etc/exports do edytora, zobaczysz pusty plik z dwiema liniami komentarza u góry. Należy dodać po linijce dla każdego katalogu, który ma zostać wyeksportowany. Dodatkowo w każdej takiej linii trzeba wylistować klienckie stacje robocze, które mają mieć do niego dostęp. Dla przykladu jesli chcemy eksportowac katalog /home/foo do stacji roboczej Bar, musimy tylko dodać linię:
/home/foo Bar(rw) |
do naszego /etc/exports. Poniżej znajdziesz przykład ze strony manuala dla pliku exports:
# sample /etc/exports file / master(rw) trusty(rw,no_root_squash) /projects proj*.local.domain(rw) /usr *.local.domain(ro) @trusted(rw) /home/joe pc001(rw,all_squash,anonuid=150,anongid=100) /pub (ro,insecure,all_squash) |
Jak widać opcji jest dośc dużo, jednak po przeanalizowaniu powyższego przykładu większość z nich powinna być zrozumiała.
NFS działa przy założeniu, że dany użytkownik na jednym komputerze ma te samo ID na
wszystkich komputerach w obrębie sieci. Kiedy próbuje odczytac czy zapisać z klienta NFS
na serwer NFS, przekazuje UID jako część żądania odczytu/zapisu. UID jest traktowany tak
samo jakby żądanie odczytu/zapisu pochodzilo z komputera lokalnego. Jak się można
domyślić, jeżeli ktoś byłby w stanie arbitralnie ustawić sobie UID mógłby dokonać
baaaardzo złych rzeczy. Jako częsciową zaporę przeciw temu, każdy katalog jest montowany
z opcją root_squash
. Zabieg ten powoduje mapowanie UIDów
użytkowników podających się za roota na różne UIDy. Chroni to przed niepożądanym dostępem z prawami roota
do katalogów wyeksportowanych. root_squash
wydaje się być
włączone domyslnie, jednak twórcy zalecają wyszczególnienie tej opcji w /etc/exports.
Możesz także eksportowac katalog bezpośrednio z linii poleceń na serwerze używając komendy exportfs:
# exportfs -o rw,no_root_squash Bar:/home/foo |
Ta linia eksportuje katalog /home/foo do komputera
“Bar” z uprawnieniami odczyt/zapis. Dodatkowo serwer
NFS nie będzie nada opcji root_squash
, co oznacza ze każdy
użytkownik na Bar z UIDem równym “0” (UID roota) bedzie mieć te same prawa
jak root na serwerze. Składnia wygląda dziwnie (normalnie składnia computer:/katalog/plik, oznacza, że odwołujesz się do pliku w katalogu na
danym komputerze).
Wiecej informacji znajdziesz na stronach manuala exportfs .