Samba - instalacja, konfiguracja, administracja.






BODY {
FONT-FAMILY: Arial, Helvetica; FONT-WEIGHT: normal; MARGIN-LEFT: 0.5cm
}
P {
FONT-FAMILY: Arial, Helvetica; FONT-SIZE: 10pt; FONT-WEIGHT: normal
}
A {
COLOR: blue; TEXT-DECORATION: none
}






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 [e-mail]
#
[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/