Lemur zaprasza
SAMBA - INSTALACJA, KONFIGURACJA, ADMINISTRACJA© 2001-11-20 Bartek Siębab ver. 1.8 WSTĘPCzym jest Samba? W niniejszym artykule starałem się przedstawić pokrótce serwer plików i drukarek w sieciach TCP/IP zgodny usługami udostępniania w sieciach Windows®. Zamiast ponosić wysokie koszty zakupu Windows NT® lub Windows 2000® możemy zainstalować na serwerze uniksowym darmową Sambę, która dla pecetów w sieci działa i zachowuje się dokładnie jak powyższe oprogramowanie firmy Microsoft. Uzyskujemy jednocześnie środowisko o nieporównanie większych możliwościach rozwoju i skalowalności. Opracowanie ma charakter uniwersalny, w miarę możliwości niezależny od systemu operacyjnego na którym instalujemy i konfigurujemy Sambę w wersji 2.0.9. INSTALACJAKażdy system posiada wsparcie dla instalowania dodatkowych pakietów oprogramowania (np. ports, packages we FreeBSD lub RPM w Linux), tak więc najprościej skorzystać z tego udogodnienia aby zainstalować najnowszą wersję Samby. Jednak chcąc zachować uniwersalność tego artykułu wykonamy to "na piechotkę". Obecnie zalecana wersja Samby to 2.0.9 w której wyeliminowano bug w zapisie tymczasowych plików kolejki wydruku w sposób niekontrolujący istnienia linków do innych plików, co mogło prowadzić do naruszenia bezpieczeństwa. Najnowsza wersja Samby z nowej gałęzi rozwojowej to 2.2.2 i wspiera ona system autoryzacji w domenie NT/Windows 2000. Całość procesu opisanego w artykule wykonujemy jako superużytkownik root. Z polskiego mirrora ściągamy, rozpakowujemy, konfigurujemy i kompilujemy dystrybucję Samby: $>cd /usr/install $>wget -c -o log.txt ftp://giswitch.sggw.waw.pl/pub/unix/samba/samba-2.0.9.tar.gz $>tar -zxvf samba-2.0.9.tar.gz $>cd samba-2.0.9/source $>./configure --localstatedir=/var/log/samba --sysconfdir=/etc $>make && make install && make clean Są dwa sposoby uruchamiania usług Samby, standardowo poprzez inetd lub jako daemony (np. z /usr/local/etc/rc.d/samba.sh). Prostszym i łatwiejszym, a zarazem efektywniejszym dla małych instalacji (rzędu <30 pecetów) jest start usług z /etc/inetd.conf. Po dopisaniu obu linijek musimy powiadomić inetd o zmienionej konfiguracji i sprawdzamy czy usługi zostały uruchomione. Formalnie należy także sprawdzić czy w pliku /etc/services są odpowiednie wpisy (sieć Windows® "okupuje" porty 137, 138, 139). Jest jeszcze trzeci wpis dotyczący usługi konfiguracji Samby poprzez przeglądarkę (Swat) o czym można przeczytać w dokumentacji. Ze względów bezpieczeństwa nie polecam tej usługi, dlatego tutaj nie będziemy jej uruchamiać. Przed startem usług należy jednak stworzyć poprawny plik konfiguracji zasobów Samby, o czym później. $>cd /etc $>cat inetd.conf | grep netbios /etc/inetd.conf: # Enable the following two entries to enable samba netbios startup from inetd # (from the Samba documentation) netbios settings: netbios-ssn stream tcp nowait root /usr/local/samba/bin/smbd smbd netbios-ns dgram udp wait root /usr/local/samba/bin/nmbd nmbd $>killall -HUP inetd $>netstat -a | grep netbios tcp 0 0 *.netbios-ssn *.* LISTEN udp 0 0 venom.netbios-dgm *.* udp 0 0 venom.netbios-ns *.* udp 0 0 *.netbios-dgm *.* udp 0 0 *.netbios-ns *.* KONFIGURACJAPrzystępujemy do stworzenia poprawnej konfiguracji udostępnianych zasobów. Przed tym jednak zmodyfikujemy usługi drukowania serwera pod kątem udostępnienia drukarki sieciowej dla naszych pecetów. W systemach *BSD odpowiednie wpisy muszą się znaleźć w pliku /etc/printcap. $>grep -v ^\# printcap hpdj|lp|Atramentowka HP DeskJet:\ :sh:rw:sf:mx#0\ :lp=/dev/lpt0:sd=/var/spool/output/lpd:lf=/var/log/lpd-errs: Warto tutaj wspomnieć, że pozycja mx#0 jest wymagana do poprawnej pracy drukarki i wyłącza limit wielkości pliku wysyłanego do drukarki (domyślnie 1MB). Większość problemów wynikająca z dziwnego zachowania drukarki przy wydrukach z Windows® wynika z braku tegoż wpisu. Zakładamy, że uniksowy daemon drukowania został zrestartowany i działa poprawnie po dokonaniu zmian w /etc/printcap. Przejdźmy zatem do konfiguracji zasobów udostępnianych przez Sambę. Tworzymy i edytujemy plik /etc/smb.conf dokonując wpisów wymaganych dla poprawnego działania naszej sieci. Po modyfikacjach warto przetestować poprawność składniową pod kątem wystąpienia m.in. literówek itp. (polecenie testparm). Najprościej będzie dostosować do własnych potrzeb poniższy plik konfiguracji. Bogato opatrzonego komentarzami cytuję go tutaj w całości. W dalszej części artykułu omówię wybrane, ważne aspekty tej konfiguracji. Pomoc na temat poszczególnych parametrów jest dostępna w dokumentacji Samby. Obejrzymy ją wydając polecenie "man smb.conf". Podczas instalacji Samby, oprócz dokumentacji i manuala, otrzymujemy doskonałą książkę w postaci stron html. W systemie FreeBSD domyślnie jest ona instalowana w katalogu "/usr/local/samba/swat/using_samba". Nosi ona tytuł "Using Samba" autorami są R.Eckstein, D.Collier-Brown, P.Kelley. Tutaj zamieszczam polskie wydanie tej ksiazki w spakowanym pdf'ie (3MB). Listing pliku konfiguracji Samby (smb.conf) nie zmieścił się w wydaniu Software nr. 11 z powodu jego wielkości, został jednak umieszczony na płycie CD sprzedawanej wraz z numerem. Jest umieszczony wraz z innymi listingami na CD w pliku \Opis\listingi.html a jego najnowsza wersja jest poniżej. $>cat /etc/smb.conf ################################################################### # sekcja globalnej konfiguracji Samby # (c)2000,2001 bs@vt.pl # [global] comment = Polaczenie z venom ... log file = /var/log/samba/%I.log dont descend = /dev,/proc,/root,/stand,/bin,/dist,/etc,/lkm,/mnt,/sbin,/sys,/usr # opcje dla 10/100Mbit Half/Full Duplex # takie ustawienie daje maksymalną szybkość w LAN # w zależności od specyfiki konkretnej sieci, może wymagać modyfikacji socket options = TCP_NODELAY SO_SNDBUF=16384 SO_RCVBUF=16384 IPTOS_LOWDELAY # włączenie tych dwóch opcji zwiększa zwykle szybkość Samby o kilkanaście procent # choć z moich analiz wynika, że praca z bazami danych jest trochę szybsza bez tego read raw = yes write raw = yes # buforowanie katalogów getwd cache = yes # buforowanie zapisu plików zdecydowanie poprawia prędkość # ale stwarza niebezpieczeństwo że Samba "nie zdąży" zrzucić buforów na dysk # przy np. padzie zasilania (bez ups'a) plik taki będzie uszkodzony # coś za coś, stosować z umiarem ;) write cache size = 65536 # nadajemy Sambie nazwę w sieci windows netbios name = venom # chcemy mieć w miarę szczegółowe logi z dostępu do plików i zasobów debug level = 2 debug timestamp = no timestamp logs = True # wielkość logów na peceta w KB, logi automatycznie przycinane przez Sambę # czyli w rzeczywistości mamy zawsze po dwa pliki: oryginał i oryginał.bak max log size = 5000 # chcemy aby Samba "słuchała" tylko na jednej z kilku naszych kart sieciowych bind interfaces only = True interfaces = 10.0.0.1/255.255.255.0 hosts allow = localhost, 10.0.0.0/255.255.255.0 # tutaj konfigurujemy sposób obsługi drukowania printing = bsd printcap name = /etc/printcap map archive = no status = yes public = no read only = no lpq cache time = 10 # tutaj ustawiamy opcje dotyczące konwersji nazw plików, wielkości liter itp. preserve case = yes short preserve case = yes strip dot = no hide dot files = yes # strona kodowa na pecetach client code page = 852 # strona kodowa na uniksie character set = iso8859-2 # tryb poziomu bezpieczeństwa zasobów # (user=wymagane konto na uniksie oraz konto samby) security = user guest ok = no browseable = yes # domyślny tryb tworzenia plików -rw------ create mode = 0700 # to odpowiada za superdostęp którego jednak nie chcemy :) # admin users = root # przydatne unix realname = yes # każdy dozwolony zapis do pliku zmienia timestamp pliku (jak w dos) dos file times = yes # ustawiamy grupę roboczą naszej sieci workgroup = vtest # zrzucamy połączenie po czasie 15minut w przypadku braku otwartych plików # lub braku odpowiedzi z peceta dead time = 15 keep alive = 15 # parametry ilości otwarych plików, zasobów itp. mangled stack = 100 shared mem size = 1048576 max open files = 500 # chcemy aby Samba obsługiwała wyświetlanie wszystkich zasobów sieci, oraz udostępniała # tzw roaming profiles (jak w NT) domain master = yes local master = yes preferred master = yes # ponieważ mamy tylko jedną podsieć, "cross subnet browsing" # nie będzie nam potrzebny. Być może zrobimy drugą podsieć, zatem włączymy usługę WINS wins support = yes os level = 64 # niech nasza Samba działa "prawie" jak NT nt smb support = yes nt pipe support = yes nt acl support = no # Logowanie do domeny dla Windows 3.x, 95, 98, # przechowywanie profili użytkowników na serwerze # włączenie skryptów logowania mapujących np. dyski, drukarki itp. domain logons = yes logon script = startup.bat logon path = \\%L\%U # chcemy żeby wszystkie pecety synchronizowały datę i czas zgodnie # z naszym serwerem (jak w NetWare) time server = True # kolejność w jakiej Samba robi rozwiązywanie nazw netbiosowych pecetów name resolve order = wins bcast hosts lmhosts # nie chcemy, aby hasło windows'a = hasłu uniksa # bowiem wymaga to specyficznego skonfigurowania procedury synchronizacji # zależnej od konkretnego uniksa unix password sync = false update encrypted = no passwd program = /usr/bin/passwd %u passwd chat debug = false passwd chat = *New*password* %n\n *Retype*new*password* %n\n *updating*done* # chcemy, żeby hasła były szyfrowane (jak w Windows 98, NT), # Windows 95 wymaga przestawienia na taką pracę # poprzez modyfikację rejestru. Odpowiednie pliki *.reg są dostępne w źródłach Samby. # Tryb pracy z szyfrowanymi hasłami Samby pozwala na zmianę # hasła sieciowego z poziomu "Panelu sterowania" w Windows. encrypt passwords = yes null passwords = false # Komentarz widoczny w trybie szczegółów w "Otoczeniu sieci" Windows server string = Serwer Venom # Sekcje konfiguracji zasobów Samby ################################################################### [homes] # ta sekcja mapuje uniksowy katalog $HOME użytkownikowi comment = Twoj wlasny katalog # przykładowo, prawa na katalogach domowych użytkowników /home # powinny wyglądać tak: # $>ls -l /home # drwx------ 3 piotrek piotrek 512 22 Sty 2000 piotrek # prawa do plików i katalogów tylko dla właściciela create mode = 0700 directory mode = 0700 public = no writable = yes # ścieżka do zasobu (czyli $HOME z /etc/passwd) path = /home/%u browseable = no # zezwalamy na agresywne buforowanie plików przez Windows co # daje znaczące zwiększenie szybkości Samby. # Bezsensownym jest stosowanie tego na zasobach bazodanowych itp. # "oplock" = "opportunistic lock" oplocks = True level2 oplocks = True # przykładowo zabraniamy oplock'ów na plikach *.dbf i *.DBF # veto oplock files = /*.DBF/*.dbf/ ################################################################### [netlogon] # ta sekcja udostępni zasób dla wszystkich, przy logowaniu do serwera # w którym trzymamy globalny logonskrypt, # pliki założeń Windows Policy (config.pol) - patrz dokumentacja Windows, # a w szczególności program poledit.exe. Windows przy logowaniu nakłada # parametry i ograniczenia pobierane z pliku config.pol na logującego się # użytkownika. Modyfikowany jest rejestr tego użytkownika. # prawa na katalogu powinny być takie: # drwxr-xr-x 2 root wheel 512 14 Sty 2000 netlogon comment = Net Logon Service path = /home/netlogon case sensitive = no create mode = 0755 directory mode = 0770 guest ok = yes # nie potrzebujemy blokowania plików bo zasób jest tylko do odczytu locking = no writable = no share modes = no browseable = yes # pozwalamy jednak na zapis do niego użytkownikom w uniksowej grupie inf, # patrz plik /etc/group write list = @inf ################################################################### [hpdj] # tutaj udostępnimy drukarkę sieciową # nazwa [hpdj] musi być identyczna jak w /etc/printcap # tu wrzucane będą pliki tymczasowe wydruków, następnie kasowane # po przesłaniu na drukarkę przez daemona lpd path = /home/tmp comment = HP Desk Jet 600 writable = yes printable = yes create mode = 0700 read only = yes # ta drukarka jest tylko dla użytkowników uniksowej grupy pub write list = @pub # oraz wyłącznie z serwera i tych pecetów hosts allow = 10.0.0.1 10.0.0.100 10.0.0.110 # tą komendą Samba będzie drukować print command = /usr/bin/lpr -r -h -P %p %s ################################################################### [pub] # Zrobimy zasób dostępny dla wszystkich z naszej sieci Windows, # posiadających konto na serwerze # prawa na tym katalogu powinny być takie: # drwxrwx--- 2 root pub 512 25 Sie 22:59 pub path = /home/pub volume = pub comment = Katalog dla lokalnych browseable = yes # prawa muszą być także dla grupy, bowiem nikt z członków grupy # nie mógłby nic zrobić z plikami innego członka grupy create mode = 0770 directory mode = 0770 write list = @pub oplocks = True level2 oplocks = True # dajemy dostęp do niego tylko z części sieci hosts allow = 10.0.0.1/255.255.255.240 ################################################################### [goscie] # Zróbmy katalog dla innej grupy path = /home/goscie volume = goscie comment = Katalog dla wszystkich browseable = yes create mode = 0770 directory mode = 0770 write list = @goscie oplocks = True level2 oplocks = True ################################################################### [bazy] # Specjalna sekcja na potrzeby systemów bazodanowych, finansowo # księgowych itp. Dostęp współdzielony bez oplock'ów path = /home/bazy volume = bazy comment = Katalog baz danych browseable = yes create mode = 0770 directory mode = 0770 write list = @bazy # zakaz stosowania agresywnego buforowania przez windows oplocks = False dos filetime resolution = True ################################################################### [cdrom] # Czasem trzeba coś zainstalować na pecetach z udostępninego # i podmontowanego cdromu na uniksie :) # drwxr-xr-x 2 root wheel 512 15 Kwi 17:45 cdrom path = /cdrom volume = cdrom comment = Naped CDROM read only = yes fake oplocks = yes locking = no writable = no share modes = no ################################################################### [programy] # a tu trzymamy różne programy dla pecetów path = /home/programy volume = programy comment = Programy uzytkowe i nietylko #read only = yes create mode = 0775 directory mode = 0775 #fake oplocks = yes oplocks = True level2 oplocks = True #locking = yes #writable = no #share modes = no # oczywiście prawo zapisu ma tylko uniksowa grupa programy write list = @programy # czytać pliki może uniksowa grupa pub i goscie read list = @pub, @goscie hosts allow = 10.0.0.0/255.255.255.0 ################################################################### [www] # użytkownicy naszej sieci wolą robić strony www lokalnie, # na swoich komputerach, pracując z zamapowanego dysku serwera i # strasznie nie lubią zabawy z użyciem ftp do wkopiowywania # stron na serwer, tak więc Sambo! Do dzieła! # prawa na tym katalogu powinny być takie: # drwxr-xr-x 4 root pub 512 27 Sie 09:23 www # a wewnątrz katalogi użytkowników dostępne ze świata poprzez # Apache Web Serwer (co wymaga odpowiedniej konfiguracji apacza) # articles 40 root wheel lrwxr-xr-x # ~books 37 root wheel lrwxr-xr-x # ~faq 18 root wheel lrwxr-xr-x # ~handbook 23 root wheel lrwxr-xr-x # ~samba 28 root wheel lrwxr-xr-x # ~sharedoc 20 root wheel lrwxr-xr-x # /tom 1024 tom nobody drwxr-x--- # /www.pit.com.pl 512 mikek nobody drwxr-x--- # index.html 688 webmaster webmaster -rw-rw-r-- # ... # path = /home/www volume = www comment = Dla stron WWW create mode = 0775 directory mode = 0775 write list = @pub oplocks = false level2 oplocks = false ###################### KONIEC KONFIGURACJI ######################## ################################################################### KONFIGURACJA SIECIChcąc wykorzystać zdolność Samby do przechowywania zindywidualizowanych ustawień użytkowników Windows® należy w odpowiedni sposób skonfigurować sieć oraz włączyć profile (Rysunek 1). Konfiguracja sieci w Windows® wymaga zainstalowania protokołu TCP/IP, przyznaniu adresu IP oraz kilku opcji. Adres IP musi być umieszczony, wraz z nazwą peceta bądź w /etc/hosts na uniksie bądź w naszym DNS. Niezbędne jest ustawienie nazwy "Netbios" peceta na zakładce "Identyfikacja" we "Właściwościach Sieci", podanie tej samej grupy roboczej co w pliku /etc/smb.conf, opisu komputera (Rysunek 2), a także logowania do domeny NT. Nazwa domeny jest identyczna jak nazwa grupy roboczej (Rysunek 3). W celu zapewnienia poprawnego wyświetlania zasobów naszych podsieci musimy utrzymywać serwer WINS, którego rolę może pełnić Samba (o ile parametry pliku sbm.conf na to zezwalają). Należy poinformować Windows® o adresie serwera WINS, co musi być wykonane bezwzględnie na wszystkich pecetach we wszystkich podsieciach pod rygorem niepoprawnej obsługi tzw. "cross subnet browsing", czyli prezentacji udostępnianych zasobów przez wszystkie komputery we wszystkich podsieciach (patrz dokumentacja Samby). Bardzo ważne jest poprawne ustawienie maski podsieci w konfiguracji TCP/IP na pecetach. Błędna maska spowoduje błędne rozgłaszanie się Windows gdyż użyją niepoprawnego adresu broadcast. Jest to źródłem problemów powstających w relacji Samba - Windows, nieraz bardzo trudnych do zidentyfikowania. Najprościej rzecz ujmując, maska musi być identyczna jak na interfejsie serwera do którego dana podsieć jest przyłączona (Rysunek 4). Powyższe zasady zagwarantują późniejsze bezproblemowe działanie naszej sieci wraz ze wszystkimi podsieciami. Przy większych instalacjach oraz przy podziale na podsieci względem grup roboczych (np. różne oddziały firmy w różnych miastach), warto zainstalować po jednym z serwerów Samby w każdej jednostce, co zaoszczędzi nam i tak małej przepustowości łącz międzyoddziałowych oraz zwiększy szybkość działania lokalnych grup roboczych. W takiej sytuacji niezbędnym staje się właśnie serwer WINS, z którego lokalne serwery oddziałowe będą pobierać informacje o udostępnianych zasobach. W całej naszej rozległej sieci powinien być wyłącznie jeden taki serwer i nie koniecznie musi być nim Samba, jednak tutaj skupimy się na konfiguracji Samby przystosowanej do tego celu. Pewnym skutkiem ubocznym jest długotrwałe utrzymywanie w otoczeniu sieciowym komputerów udostępniających zasoby, nawet po ich fizycznym wyłączeniu z prądu. Jedyną metodą skracającą ten czas jest ustawienie poniższych parametrów w pliku /etc/smb.conf na serwerach Samby (mogą wystąpić inne uboczne skutki przy zbyt małych czasach tak więc zależne jest to od konkretnej instalacji, poniższe parametry wydają się być optymalne dla kilku serwerów): # skrócenie domyślnych czasów utrzymywania list zasobów w sieci # domyślny czas utrzymywania nazw Netbios przez Sambę max ttl = 10800 # domyślne czasy utrzymywania nazw Netbios przez WINS max wins ttl = 36000 min wins ttl = 18000 Konfiguracja "domain master browser", na którym równocześnie będzie działać serwer WINS, powinna wyglądać jak w poniższym przykładzie: # domain master browser + WINS serwer local master = yes preferred master = yes wins support = yes os level = 64 Konfiguracja "local master browser", powinna wskazywać (jeżeli chodzi o WINS), na nasz główny serwer i wyglądać tak: # lokalny serwer oddziału firmy domain master = no local master = yes preferred master = yes # adres serwera głównego, na którym jest nasz WINS wins server = 10.0.0.1 max ttl = 10800 max wins ttl = 36000 min wins ttl = 18000 os level = 32 name resolve order = wins bcast hosts Takie ustawienia wymuszają synchronizację pomiędzy serwerami lokalnymi, a głównym serwerem, na którym jest WINS. PROFILEWłączenie profili użytkowników wymusza na Windows® utrzymywanie osobnych ustawień dla każdego użytkownika. Są one przechowywane w podkatalogu "C:\WINDOWS\PROFILES\", gdzie tworzone są katalogi o nazwach użytkowników. Każdy zawiera kompletne "MENU START" z zawartością, osobny plik rejestru USER.DAT i inne. Przy pierwszym wylogowaniu się z serwera, zawartość kopiowana jest do katalogu domowego użytkownika (co zresztą określone jest w /etc/smb.conf). Zalogowanie się do sieci powoduje zsynchronizowanie lokalnej i zdalnej zawartości profilu i ewentualne jego skopiowanie z serwera na dysk lokalny. Pozwala to na przesiadkę na innego peceta gdzie po zalogowaniu do sieci (przy włączonych profilach) Windows® udostępni nam nasze menu, ustawienia itd. Ubocznym skutkiem jest kopiowanie tej struktury na lokalne dyski (coś za coś) oraz tworzenie pliku z hasłami (*.pwl, można to wyłączyć odpowiednim wpisem do rejestru, patrz dokumentacja Samby). Logowanie do sieci wymusza na Windows® wykonanie skryptu startowego (co określa odpowiedni wpis w /etc/smb.conf). Jest to zwyczajny plik wsadowy (batch np. startup.bat) koniecznie edytowany w trybie MS-DOS tzn. z CR+LF na końcach linii (np. $>joe -crlf startup.bat). Można także skorzystać z konwersji pliku narzedziami unix2dos oraz dos2unix. Ostatnia linia nie może powodować wywołania programu, z którego nie ma powrotu np. wywołanie Norton Commander® itp. gdyż Windows® po prostu się nam zawiesi. Poniższy przykład demonstruje główny plik startup.bat z którego wywoływany jest plik zindywidualizowany startup.bat z katalogu domowego użytkownika: @echo off REM Główny startup.bat w katalogu netlogon REM \\venom\netlogon\startup.bat powinien mieć np. takie prawa: REM -rw-rw-r-- 1 root wheel 277 4 Sie 10:58 startup.bat REM REM Synchronizacja daty i czasu z serwerem net time \\venom /set /yes REM mapowanie dysków net use u: /home /yes net use p: \\venom\pub /yes net use r: \\venom\programy /yes net use s: \\venom\goscie /yes net use y: \\venom\cdrom /yes REM Jeśli jest prywatny to go uruchamiamy if exist u:\startup.bat call u:\startup.bat Po wykonaniu tego skryptu, zostanie również wykonany skrypt użytkownika "startup.bat" o ile istnieje w jego katalogu domowym na dysku U:. Pozwala to na indywidualne traktowanie użytkowników, na dostosowywanie środowiska pracy użytkowników oraz pozwala im na edycję tych ustawień: @echo off REM Plik startowy indywidualny użytkownika REM powinien być w katalogu $HOME użytkownika i mieć prawa: REM -rw------- 1 pit pit 106 3 Lip 18:51 startup.bat REM mapowania dysków wykonywane w tym pliku, REM przykrywają mapowania wykonane w globalnym startup.bat REM net use k: \\venom\bazy /yes net use w: \\venom\www /yes REM mapowanie drukarki net use LPT3 \\venom\hpdj /yes DOMENY PDCSamba w wersji 2.0.9 potrafi współpracować z domenami Windows NT® jednak z Windows 2000® występują pewne problemy, które mają zostać usunięte w kolejnej wersji Samby. Zakładamy że kontrolerem domeny jest Windows® (NT lub 2000), on też obsługuje serwer WINS, i "domain master browser". Wymagane parametry w pliku konfiguracyjnym /etc/smb.conf wyglądają wtedy następująco: # konfig dla pracy z kontrolerem domeny NT security = domain #password server = password server = 10.0.0.200 10.0.0.201 encrypt passwords = yes socket options = TCP_NODELAY IPTOS_LOWDELAY IPTOS_THROUGHPUT # os level = 0 załatwia sprawę współzawodnictwa z Windows NT master browse # do wymaganego minimum os level = 0 #domain controller = domain controller = 10.0.0.200 #wins server = wins server = <10.0.0.200> dns proxy = no Niezbędne jest także dokładne przestudiowanie dokumentacji Samby, opisującej w jaki sposób należy skonfigurować Windows® i Sambę w celu przystosowania ich do takiego trybu pracy. Ten artykułu ma jedynie zasygnalizować taką możliwość, dlatego nie będziemy się zagłębiać w tym kierunku wyręczając autorów Samby w przekazywaniu nam swojej wiedzy. :-) UŻYTKOWNICYZakładając, że wykonaliśmy instalację i konfigurację Samby, dodajmy teraz użytkowników do naszego serwera. Powinniśmy tutaj posłużyć się standardowym dla naszego uniksa narzędziem, przy czym dla użytkowników wyłącznie sieci Windows, nie przydzielamy shella (bo i po co?). Wyjątkowo dla użytkowników posiadających konto pocztowe na tym samym serwerze, możemy przydzielić zamiast shell'a program "passwd" do zmiany hasła uniksowego. Przydzielanie programu "smbpasswd" jest niecelowe, bowiem użytkownik ma możliwość zmiany hasła sieciowego Windows® z "Panelu Sterowania" (ikona "Hasła"). Jest to także naruszeniem bezpieczeństwa. Podawanie jawnym tekstem nowego hasła sieciowego (jak to jest w przypadku passwd i smbpasswd) może być podsłuchane i wykorzystane do nieuprawnionego dostępu do zasobów serwera. Najlepszym rozwiązaniem jest całkowite wyłączenie shell'a lub udostępnienie bardziej zaawansowanym użytkownikom konta uniksowego, z wyłączną możliwością zalogowania się przy użyciu szyfrowanych protokołów (np. ssh). Polecam tu szczególnie darmowy program terminala dla Windows® - PuTTY SSH. $>smbpasswd -a adam added interface ip=10.0.0.1 bcast=10.0.0.255 nmask=255.255.255.0 New SMB password: Retype new SMB password: User adam does not exist in system password file (usually /etc/passwd). Cannot add account without a valid local system user. Failed to modify password entry for user adam Jak widać Samba wyraźnie zmusza nas do wcześniejszego założenia użytkownika w uniksie. Kiedy Konto uniksowe jest już założone, katalog domowy utworzony a prawa poprawnie ustawione możemy przejść do dodania użytkownika do Samby. $>smbpasswd -a pit added interface ip=10.0.0.1 bcast=10.0.0.255 nmask=255.255.255.0 New SMB password: Retype new SMB password: $> Skutkuje to dopisaniem do pliku użytkowników. Zwykle jest on w katalogu "/usr/local/samba/private/" jednak to może zostać zmienione, na etapie konfiguracji i kompilacji Samby. $>cd /usr/local/samba $> ls -ld private drwx------ 2 root wheel 512 14 Sty 2000 private $>cd private $>ls -l -rw-r--r-- 1 root wheel 41 14 Sty 2000 MACHINE.SID -rw------- 1 root wheel 557 9 Wrz 14:40 smbpasswd $>cat smbpasswd pit:2004:DD02BA4D905304F3AAD3B435B51404EE:BE21EF1208C298133C9CB4AD2791E55A:[U ]:LCT-3989BF65: Narzędzie smbpasswd ma wiele dodatkowych opcji, pozwalających na blokowanie dostępu, zmianę lub usunięcie hasła, usunięcie użytkownika, dodanie do domeny NT itp. Szczególnym trybem działania jest przejście Samby z haseł nieszyfrowanych na szyfrowane, co także opisuje dokumentacja. Samba działając na nieszyfrowanych hasłach posługuje się standardowymi plikami haseł uniksa i nie wymaga dodawania użytkowników do Samby. Pamiętajmy jednak że wtedy z poziomu panelu sterowania Windows® nie można zmienić hasła i trzeba to robić tradycyjnym uniksowym passwd. Pamiętajmy że smbpasswd działa w trybie klient-serwer dlatego wymagane jest aby uniks jako "localhost" miał zezwolenie na dostęp do Samby (polecam zapoznanie się z plikami *.TXT z dokumentacji Samby). Bardzo pomocnym narzędziem w codziennym działaniu Samby jest "smbstatus", pokazujący stan wszystkich połączeń z Sambą, otwarte pliki, blokady itp.: $>smbstatus Samba version 2.0.9 Service uid gid pid machine ---------------------------------------------- pit pit pit 3854 stone (10.0.0.100) Wed May 9 13:48:48 2000 hpdj pit pit 3854 stone (10.0.0.100) Wed May 9 14:10:13 2000 www pit pit 3854 stone (10.0.0.100) Wed May 9 15:15:19 2000 bazy pit pit 3854 stone (10.0.0.100) Wed May 9 15:15:33 2000 Locked files: Pid DenyMode R/W Oplock Name -------------------------------------------------- 3854 DENY_NONE RDWR NONE /home/bazy/mag/MAG_02/ZAM_PART.DBF Wed May 9 15:16:52 2000 3854 DENY_NONE RDWR NONE /home/bazy/mag/MAG_02/OBROTY.DBF Wed May 9 15:16:52 2000 3854 DENY_NONE RDWR NONE /home/bazy/mag/CENNIK1.NTX Wed May 9 15:16:52 2000 3854 DENY_NONE RDWR NONE /home/bazy/mag/CENY_DW3.NTX Wed May 9 15:16:52 2000 3854 DENY_WRITE RDWR EXCLUSIVE+BATCH /home/pit/startup.bat Wed May 9 15:15:27 2000 3854 DENY_NONE RDONLY EXCLUSIVE+BATCH /home/pit/S.TXT Wed May 9 14:16:27 2000 Share mode memory usage (bytes): 1042512(99%) free + 5176(0%) used + 888(0%) overhead = 1048576(100%) total Na powyższym zestawieniu widać, że w przypadku plików bazy danych Samba nie stosuje oplock'a (zezwolenia na agresywne cache'owanie pliku przez windows) natomiast plik S.TXT ma właśnie taki tryb dostępu. Zamknięcie pliku nadal nie jest widoczne bowiem jest on w dyspozycji peceta aż do momentu, gdy jakiś inny komputer poprosi Sambę o otwarcie tego samego pliku. Następuje wtedy negocjacja Samby z obydwoma komputerami, która objawia się dla użytkowników chwilowym zablokowaniem Windows®. W tym czasie, Samba kontaktuje się z klientem który jako pierwszy otrzymał oplock do pliku. Windows po otrzymaniu rozkazu przerwania oplock'a wie, że nie może już korzystać z buforowania pliku i musi czytać go ponownie z serwera. Drugi klient po całej tej "rozmowie" otrzymuje dostęp do pliku. Może to trwać kilka do kilkunastu sekund. W tym czasie obydwa komputery są zablokowane, co czasem ma wpływ na ich właścicieli i kończy się przedwczesnym zresetowaniem komputera, przez zniecierpliwionego użytkownika. Można ten czas regulować jednak domyślne wartości wydają się być optymalne. Najlepiej uprzedzić użytkowników a takich skutkach ubocznych, informując że niestety jest to niezbędne, jeżeli chcemy mieć bardzo wydajny serwer plików. Explorator Windows® ma tendencję do zczytywania początków plików przy przeglądaniu zawartości dysków (np. w celu rozpoznania typu pliku, odczytaniu ikony itp.). Ta cecha powoduje że pliki "hurtowo" zostają otwierane w trybie oplock. Kiedy z takiego katalogu korzysta wielu użytkowników najlepiej jednak będzie zrezygnować z oplock'ów. Częściowo zostało to poprawione w Sambie, poprzez wprowadzenie parametru: "level2 oplocks = True"Z moich doświadczeń wynika, że ten tryb blokowania plików najlepiej sprawdza się w katalogach domowych użytkowników, zapewniając maksymalną wydajność Samby a także w niewielkich grupach roboczych. Tam gdzie z zasobu korzysta duża liczba użytkowników, najlepiej od razu wymusić na Sambie pracę bez oplock'ów. SZYBKOŚĆSamba w przypadku sieci, gdzie ilość stacji roboczych jest niewielka, wykazuje się transferami podobnymi jak Windows® NT czy 2000. Gdy liczba klientów wzrasta, zaczynamy dostrzegać przewagę Samby jako serwera plików i drukarek. Samba doskonale radzi sobie z obciążeniami rzędu kilkudziesięciu pecetów. Wąskim gardłem jest sieć oraz szybkość dysków i tak: Serwerek AMD-K6 233MHz 32MB RAM 20GB HDD IBM 5400rpm FreeBSD 3.5 Samba 2.0.9 Sieć: | 10Mbit Half Duplex | 100Mbit FullDuplex -----------|---------------------|---------------------- Transfery: | 800.000 bajtów/sek. | 3.200.000 bajtów/sek. Test wykonany poprzez zwyczajne kopiowanie około 200MB plików systemu magazynowego. Protokoły CIFS Samby są w stanie uzyskać około 80% przepustowości sieci. Transfer maksymalny na sieci 100Mbit nie został osiągnięty z braku szybszych dysków :) Samba zużywa około 2-3 MB RAM na każdego klienta. Z tym że przy bezczynności klienta, pamięć jest zwalniana -poprzez zrzut do swap'u- o ile jest to konieczne i wymagane przez serwer uniksowy. Nie wszytkie uniksy tak się zachowują. W przypadku braku pamięci robi tak np. FreeBSD, natomiast nie robi tego Linux. Stąd zwyczajny komputer działający jako niewielki serwerek z 32MB RAM oraz z systemem FreeBSD, doskonale obsługuje sieć złożoną z 25 komputerów. ZAKOŃCZENIENiniejszy artykuł został napisany dla miesięcznika "SOFTWARE", do numeru specjalnego poświęconego systemom FreeBSD, NetBSD, OpenBSD. Nie omawiam w nim wielu specyficznych parametrów dla każdego z nich, np. parametrów kernela FreeBSD pozwalających na trzymanie blokad plików przez Sambę w pamięci współdzielonej zamiast w pliku dyskowym, zwiększenia ilości możliwych do otwarcia plików itp. (można o tym przeczytać w dokumentacji twojego systemu uniks - konfiguracja kernela, opcje dotyczące SYSV). Być może wersja online będzie bardziej rozbudowana i poruszy jeszcze wiele innych aspektów działania sieci Windows® z serwerem Samba na pokładzie systemów BSD. Ilość specyficznych parametrów dla każdego z nich jest bardzo duża. Przedstawianie ich tutaj daleko wykracza poza ramy artykułu i mieści się raczej w kategorii "zaawansowana administracja i konfiguracja w systemach uniksowych BSD". Początkujący administrator powinien zaufać programom konfigurującym ("configure" w dystrybucji) i przygotowującym pakiet Samby do kompilacji. Najnowsza wersja tego opracowania jest dostępna pod adresem: http://bofh.vt.pl/Dodatkowe informacje można uzyskać kontaktując się z autorem: Bartek SiębabGrupa dyskusyjna USENET: news://comp.protocols.smb/Oficjalne strony projektu Samba: http://www.samba.org/ |