FreeBSD na www.malisz.eu.org

SAMBA - INSTALACJA, KONFIGURACJA, ADMINISTRACJA

WSTĘP

Czym 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.

INSTALACJA

Każ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          *.*

KONFIGURACJA

Przystę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 pdf'ie (3,6MB).

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 Opislistingi.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
 *Retype*new*password* %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 SIECI

Chcą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).

Rysunek 1. Grupa

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.

Rysunek 2. Hasła

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.

Rysunek 3. Klient

PROFILE

Włączenie profili użytkowników wymusza na Windows® utrzymywanie osobnych ustawień dla każdego użytkownika. Są one przechowywane w podkatalogu "C:WINDOWSPROFILES", 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).

Rysunek 4. Profile

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
etlogonstartup.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: venompub /yes
net use r: venomprogramy /yes
net use s: venomgoscie /yes
net use y: venomcdrom /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: venomazy /yes
net use w: venomwww /yes

REM mapowanie drukarki
net use LPT3 venomhpdj /yes

DOMENY PDC

Samba 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ŻYTKOWNICY

Zakł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ŃCZENIE

Niniejszy 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ębab
Grupa dyskusyjna USENET: news://comp.protocols.smb/
Oficjalne strony projektu Samba: http://www.samba.org/