Zespół Szkół

Im.

PRACA

DYPLOMOWA

Sieć komputerowa w oparciu o system Linux i protokół Samba.

Wykonali uczniowie klasy Prowadzący:

Spis treści:

1. Wstęp……………………………………………………………………………………....3

1. Cel pracy ………………………………………………………………………………3

2. Historia i opis systemu operacyjnego Linux……………………………………………….4

1. Co to jest Linux?……………………………………………………………………….4

2. Historia Linuksa………………………………………………………………………..5

3. Cechy systemu…………………………………………………………………………6

4. Zastosowanie i schemat rozwoju………………………………………………………7

5. Numeracja jąder i kwestie prawne……………………………………………………..8

3. Informacje dotyczące PLD……………………………………………………………......10

1. Krótka historia PLD…………………………………………………………………..10

2. Informacje o PLD……………………………………………………………………..11

3. Założenia PLD………………………………………………………………………..13

4. Oficjalne wersje PLD…………………………………………………………………15

5. Model rozwoju PLD Linux Distribution.......................................................................16

6. Projekty związane z PLD……………………………………………………………..18

7. Logo…………………………………………………………………………………..19

8. Ważne adresy…………………………………………………………………………19

4. Czym jest Samba?...............................................................................................................20

5. Zastosowanie Samby……………………………………………………………………...21

6. Historia Samby…………………………………………………………………………....23

7. Inne implementacje Samby……………………………………………………………….24

8. Struktura Samby…………………………………………………………………………..25

9. Zarządzanie i konfiguracja Samby………………………………………………………..27

10. Plik smb.conf …………………………………………………………………………….28

1. Przykładowy plik……………………………………………………………………..30

2. Plik dziennika zdarzeń a usuwanie usterek…………………………………………...32

3. Współdzielenie plików………………………………………………………………..33

4. Konfiguracja współdzielenia plików…………………………………………………35

5. Wybór plików………………………………………………………………………...37

11. Udziały typu „gość”………………………………………………………………………39

12. Ograniczenia dostępu do udziału…………………………………………………………40

13. Odwzorowanie praw dostępu do Unika…………………………………………………..44

14. Dostęp Samby z Windows 9x…………………………………………………………….48

15. Bibliografia……………………………………………………………………………….49

1. Wstęp

1. Cel pracy

Celem pracy jest zaprezentowanie serwera plików i drukarek Samba, który może być tanią alternatywą sieci Microsoft Windows

2. Historia i opis systemu operacyjnego Linux

1. Co to jest Linux?

Linux jest to jądro będące podstawą jednej z wersji uniksowych systemów operacyjnych. Nazwa Linux jest też powszechnie używana do określenia całego systemu opartego o to jądro, choć niektórzy (m.in. projekt GNU oraz Debian) używają w tym celu nazwy GNU/Linux.

2. Historia rozwoju

Linux zaczął powstawać w 1991 roku, kiedy to fiński programista, Linus Torvalds stworzył jądro nowego systemu operacyjnego przeznaczonego do pracy z procesorami rodziny 80386 firmy Intel.

Informacje o systemie, opublikowane przez Torvaldsa na internetowej liście dyskusyjnej, spotkały się z dużym zainteresowaniem i wkrótce przy rozwoju systemu pracowała już grupa ludzi. Znacznie przyspieszyło to jego rozwój - otrzymał on później nazwę "Linux". Im bardziej system ten stawał się popularny, tym więcej ludzi wspierało jego rozwój. Proces ten trwa do dziś, a liczbę użytkowników różnych dystrybucji Linuksa szacuje się obecnie na wiele milionów na całym świecie.

Kolejne wersje jądra systemu Linux przynosiły zmiany i wiele nowości:

• jądro 1.0 - 14 marca 1994. Pierwsze stabilne jądro Linuksa. Znalazła się w nim implementacja protokołów internetowych zapożyczona z systemu BSD, dołączono też nowy system plików ext, który usuwał wiele niedogodności z systemu plików Miniksa.

• jądro 1.2 - 6 marca 1995. Linux obsługuje już cztery platformy: Alpha, SPARC, MIPS oraz rodzime i386. Dodano możliwość korzystania z nowej szyny PCI oraz zwiększono liczbę obsługiwanych urządzeń.

• jądro 2.0 - 8 czerwca 1996. Jądro wzbogaciło się o obsługę wielu procesorów (tryb SMP), jednak brakowało w nim obsługi wielobieżności. Znacząco zwiększono też wydajność stosu TCP/IP, wprowadzono obsługę protokołów Appletalk, amatorskich sieci radiowych AX.25 oraz standardu ISDN. Dodano także możliwość montowania sieciowych systemów plików Netware oraz SMB.

• jądro 2.2 - 25 stycznia 1999. Wersja ta przynosi obsługę kolejnych architektur sprzętowych (ARM, IBM S/390 oraz Sparc64). Przepisano też obsługę protokołu TCP/IP oraz wprowadzono możliwość zaawansowanego routingu.

• jądro 2.4 - 4 stycznia 2001. Dodano obsługę procesorów Intel Itanium, oraz IBM S/390 w wersji 64-bitowej, CRIS, HP PA-RISC oraz Hitachi SH. Usunięto ograniczenia poprzednich wersji systemu: pełna 64-bitowość, rozmiar pliku > 2 GB. Ulepszenie obsługi USB, szybkich dysków ATA66 i SCSI, obsługa złączy Firewire oraz kamer cyfrowych. Możliwość korzystania z DevFS i XFS. Do jądra wprowadzono także prosty serwer HTTP (kHTTPd) oraz obsługę LVM (łączenie kilku dysków twardych w jedną wirtualną partycję).

• jądro 2.6 - 18 grudnia 2003. Wprowadzono obsługę architektur H8/300. IBM POWER5, v850 oraz x86-64. Łączna liczba obsługiwanych architektur wzrasta do 22! Do jądra dodano obsługę protokołu IPSec oraz zmieniono scheduler (autorem zmian schedulera był Ingo Molnar). Prace nad jądrem 2.6 mają zwiększyć skalowalność i szybkość systemu, zmniejszenie opóźnień oraz obsługę wielobieżności, dodano także obsługę wspólnego API dla algorytmów kryptograficznych. Znacznie ułatwiono tworzenie nowych modułów jądra. Dodano obsługę nowych systemów plików: IBM JFS, ReiserFS oraz rozbudowano rodzime systemy plików o obsługę list kontroli dostępu, zgodnych ze specyfikacją POSIX. Z jądra usunięto natomiast kHTTPd, jako element zbędny.

1. Cechy systemu

Linux charakteryzuje się dużą zgodnością ze standardami ANSI i POSIX, jest wielozadaniowy, wielowątkowy, wielobieżny, ma monolityczną budowę (choć z obsługą modułów - najczęściej zawierającymi sterowniki urządzeń), a także wsparcie dla klastrów (rozwijany w Izraelu akademicki projekt MOSIX) i architektury SMP (w najnowszych wersjach także NUMA). Jest bardzo wydajny, stabilny i bezpieczny. Wadą jest brak możliwości wywłaszczenia procesów jądra (taka możliwość istnieje w najnowszych jądrach 2.6) oraz korzystanie w małym stopniu z wątków jądra, które w Linuksie nie mogą zajmować się wykonywaniem programów użytkownika.

Działa na wielu platformach sprzętowych:

• IA-32 - 32-bitowe procesory firmy Intel z rodziny x86 (386SX/DX-486SX/DX-Pentium/II/III/IV/EE/Pro/Xeon lub lepsze), AMD (K5/K6/Duron/Athlon/Sempron/Athlon-FX) oraz inne zgodne z pierwotną architekturą,

• IA-64 - procesory Intel z rodziny Itanium oraz 64-bitowe wersje procesora Xeon,

• Opteron i Athlon 64, a także Intel EMT,

• IBM PowerPC - IBM PCs oraz Apple Mac (IBM Power1 - IBM Power5),

• Mainframe - IBM CP S/390 i IBM CP zSeries,

• m68k firmy Motorola (Atari, Amiga oraz Apple),

• MIPS,

• Alpha,

• SPARC,

• SPARC64,

• i wiele innych...

Dzięki Wirtualnemu Systemowi Plików (ang. VFS) obsługuje blisko 50 systemów plików:

• rodzime ext2 i ext3

• SGI XFS

• IBM JFS

• NFS

• SMB

• ReiserFS

• Reiser4

• FAT

• UFS - UFS2 tylko do odczytu

• NTFS - tryb tylko do odczytu/częściowa obsługa zapisu (w jądrze 2.6)

• Minix

• inne...

1. Zastosowanie i schemat rozwoju

Linux przede wszystkim stosowany jest na systemach serwerowych (serwery WWW, FTP, e-mail i inne), jako zapory sieciowe (firewall), a także w systemach osadzonych oraz w niektórych odtwarzaczach DVD.

Ze względu na powstanie i rozwój dystrybucji o łatwej instalacji, graficznym wyglądzie i bogactwie wydajnego oprogramowania przewiduje się szerokie wejście Linuksa na rynek biurowy i domowy. Rządy kilku państw europejskich prowadzą wdrożenia Linuksa na komputerach administracji państwowej. Ponadto z Linuksa korzystają agencje wywiadowcze i kontrwywiad, ze względu na bezpieczeństwo, stabilność oraz możliwość audytu oraz modyfikacji kodu (dostępność kodu źródłowego). Niezawodność tego systemu została doceniona przez niektóre banki i instytucje finansowe korzystające z Linuksa (np. system notowań Wall Street oparty jest na tym systemie operacyjnym).

Rozwój Linuksa można podzielić na dwie gałęzie - stabilną (oznaczaną numerami parzystymi serii, np. 2.6) oraz rozwojową (oznaczaną numerami nieparzystymi np. 2.5).

Wersja stabilna - jak sama nazwa wskazuje - ma być stabilna, autorzy wstrzymują się od wprowadzania do niej rewolucyjnych zmian, jedynie poprawki wykrytych błędów, drobne usprawnienia. Jednym z najpoważniejszych odstępstw od tej reguły była wymiana nieefektywnego podsystemu pamięci wirtualnej w serii 2.4.

Po każdej serii stabilnej (a właściwie już w jej trakcie) rozpoczynana jest seria rozwojowa, w której jest miejsce na eksperymenty, przebudowy itd. Z tego powodu wersje rozwojowe nie nadają się do poważnego użytkowania, często nawet nie mogą zostać skompilowane. Po jakimś czasie seria rozwojowa "dojrzewa" i staje się pierwszą wersją nowej serii stabilnej, a poprzednia stabilna seria wchodzi w stan "spoczynku", kiedy wprowadzane są praktycznie tylko poprawki bezpieczeństwa oraz z rzadka porty fragmenty kodu z nowszych serii (np. sterowników urządzeń).

W serii 2.6 Linus w porozumieniu z jej opiekunem, Andrew Mortonem, wprowadzają model nawet dużych, choć stopniowo wprowadzanych modyfikacji, jeszcze w ramach wersji stabilnej. Zmiany zaakceptowane przez Torvaldsa po okresie niezbędnych testów są włączane do głównej gałęzi nadzorowanej przez Mortona.

Ponieważ ten model pracy sprawdza się, jak dotąd nie uznali za konieczne utworzenia gałęzi 2.7. Argumentem na rzecz takiego trybu rozwoju jest fakt, że faktyczna stabilizacja jądra dla końcowych użytkowników od dłuższego czasu odbywa się i tak w ramach poszczególnych dystrybucji.

Od wersji 2.6.11 zaczęto wydawać wersje 2.6.11.x, zawierające mniejsze poprawki. Taki tryb pracy wprowadza na nowo stabilną wersję jądra dla użytkowników niezadowolonych z eksperymentalnego charakteru głównej linii rozwojowej.

2. Numeracja jąder i kwestie prawne

Wersję Linuksa zapisujemy używając 3 lub 4 liczb naturalnych rozdzielonych kropką, na przykład:

2.4.17

Pierwsza liczba - 2 - to numer wydania, aktualnie 2. Następna liczba (u nas 4) oznacza serię. Gdy jest parzysta, mamy do czynienia z serią stabilną, jeśli nie - rozwojową. 17 to już numer wersji w danej serii. Dodatkowa, czwarta liczba w numerze wersji oznacza wersję lekko poprawionej, stabilnej wersji jądra.

Często używa się oznaczeń typu 2.4.18-pre6 - co oznacza szósta przymiarka do wydania 2.4.18

Koordynatorzy projektu dobierają łaty (ang. patch) według swego uznania. Wielu osobom się to nie podoba lub nie wystarcza, więc tworzą swoje gałęzie jądra, w których sami decydują o łatkach jakie zostaną do niego wprowadzone lub odrzucone, przez co mogą wpływać na kierunek i szybkość rozwoju.

Oficjalną gałęzią Linuksa zarządza Linus Torvalds lub osoba przez niego wyznaczona:

2.0 - David Weinehall

2.2 - Marc-Christian Petersen (poprzednio Alan Cox)

2.4 - Marcelo Tosatti

2.6 - Andrew Morton

Często istnieją równoległe, nieoficjalne gałęzie, np. 2.4 Alana Coksa lub Andrei Arcangelego. Oznaczane są poprzez dodanie odpowiedniej końcówki, np.: -ac dla jąder Alana Coksa, -aa dla jąder Andrei itd. Należy zaznaczyć, że niektóre jądra nieoficjalne sprawują się lepiej niż te prowadzone przez samego Linusa Torvaldsa.

Oznaczenie typu 2.4.18-rc1, to tzw. wydanie kandydujące (ang. release candidate), czyli "kandydat" do bycia nową wersją stabilną, o ile nie zostaną w nim znalezione poważniejsze błędy. Gdy ich nie ma, to (w teorii) nowa wersja stabilna nie będzie się niczym różniła (oprócz samej nazwy) od powstałej na jej podstawie wersji stabilnej. Jeśli się znajdą, zostają one poprawione, w wyniku czego powstaje nowe wersja "kandydująca" i cykl się powtarza. Wersje -rc pojawiają się z reguły już po kilku wersjach -pre. Do używania "wersji kandydujących" zobowiązał się obecny opiekun linii 2.4, Marcelo Tosatti.

Odkąd zmiany w kodzie jądra, przechowywane są w repozytorium BitKeeper, na stronach projektu znaleźć można również wersje oznaczane jako np. 2.6.11-rc1-bk8. Są to tak zwane snapshoty, zawierające kod wprowadzony w przeciągu okresu który minął od wydania wersji (w tym wypadku) 2.6.11-rc1. Tworzone są automatycznie w formie patchy, które można nałożyć na kod jądra.

Linux jest wolnodostępnym systemem rozprowadzanym na licencji GNU General Public License, co oznacza, że kod źródłowy jest dostępny dla każdego i każdy może dowolnie go modyfikować wedle własnego uznania. Do gałęzi oficjalnej nie jest włączany żaden zamknięty kod, choć możliwe jest dołączanie do jądra modułów komercyjnych.

Moduły w Linuksie mają automatyczne oznaczenia licencji, tak żeby przypadkiem nie został włączony moduł na licencji niezgodnej z GPL (zgodnymi licencjami są GPL, LGPL, Licencja BSD i kilka innych).

Linux jest zastrzeżonym znakiem towarowym należącym do Linusa Torvaldsa.

3. Informacje dotyczące PLD

1. Krótka historia PLD

Wraz ze wzrostem zainteresowania Linuksem w Polsce, rosy naciski na stworzenie polskiej dystrybucji tego systemu. Niemal wszyscy jej chcieli, a niektórzy nawet mówili, że już takową robią. Nic jednak z tego nie wynikało. Wreszcie, w lipcu 1998, zawiązał się projekt mający na celu stworzenie polskiej dystrybucji Linuxa. Projekt PLD, czyli Polish(ed) Linux Distribution, był na tyle dobrze zorganizowany, by przetrwać trudne początki. Nie obeszło się oczywiście bez burzliwych dyskusji na temat kształtu dystrybucji, doboru oprogramowania jak również wersji jądra, na której projekt ma być rozwijany. W efekcie zdecydowano się prowadzić równolegle dwa projekty. Pierwszy został nazwany PLD-devel i był forpocztą dla obecnego PLD-stable. Prace nad 1.1 PLD (devel) koordynowali przede wszystkim Wojtek Ślusarczyk, Marcin Korzonek i Arek Miśkiewicz. Miała to być pierwsza dystrybucja Linuxa zgodna z nowym, promowanym przez OpenGroup, standardem - Unix98. Równolegle druga grupa, na czele z Tomkiem Kłoczko i Arturem Frysiakiem, pracowała nad podwalinami właściwej PLD-stable.

Nieco później, przede wszystkim z braku wolnego czasu z prac nad projektem wycofali się Wojtek Ślusarczyk, Andrzej Nakonieczny oraz Marcin Korzonek. Tomasz Kłoczko postanowił kontynować prace nad PLD, gromadząc wokół siebie coraz to większą liczbę developerów. Pojawiła się domena pld.org.pl, a wraz z nią liczne adresy "funkcjonalne", takie jak ftp.pld.org.pl, www.pld.org.pl czy cvs.pld.org.pl. Ruch na listach mailingowych stawał się coraz większy, widac było, iż projekt zyskiwał na popularności.

22 listopada 2002 roku światło dzienne ujrzała pierwsza stabilna wersja dystrybucji PLD Linux Distribution 1.0 (Ra). Jeszcze w czasie jej stabilizacji rozpoczęły się prace nad kolejną wersją.

Twórcy projektu zakładali uniwersalność PLD, która pozwalałaby na korzystanie z dystrybucji przez użytkowników z całego świata, jednak pojawiły się obawy, że nazwa Polish(ed) Linux Distribution odstraszy potencjalnych odbiorców z innych krajów. Postanowiono, że zmieniona zostanie nazwa projektu. Pozostawiono charakterystyczny skrót "PLD" w niezmienionej postaci, zmieniono zaś jego rozwinięcie - nazwa "PLD" stała się rekurencyjnym skrótem od PLD Linux Distribution.

2. Informacje o PLD

Podstawowe informacje.

PLD-Linux jest dystrybucją rozwijaną głównie w Polsce. Jest to produkt grupy entuzjastów Linuksa chcącej stworzyć system operacyjny dopasowany do własnych potrzeb. Aktualnie rozwojem dystrybucji interesuje się około 200 osób, z pośród nich najbardziej aktywna jest grupa 50 deweloperów.

PLD jest jednym z najaktywniejszych projektów Open Source na świecie. Dzięki temu powstała jedna z największych dystrybucji Linuksa, w trakcie prac nad drugą wersją systemu (Ac) ilość dostępnych pakietów przekroczyła liczbę dziewięciu tysięcy.

Najistotniejsze cechy:

• Ogromna liczba programów podzielona jest na mniejsze pakiety, pozwalające instalować tylko te elementy systemu, które są akurat potrzebne.

• Pakiety często są wstępnie skonfigurowane i gotowe do działania, ponadto nakładane są na nie istotne łaty.

• PLD posiada najlepszą obsługę przyszłościowego protokołu IPv6 z pośród innych dystrybucji Linuksa.

• W PLD nie są faworyzowane żadne z usług czy programów. To czego używamy zależy tylko od nas.

• W systemie umieszczono silnie zmodularyzowane jądro. Dzięki temu w ogromnej większości wypadków nie trzeba go kompilować na nowo. Wystarczy załadować tylko odpowiednie moduły.

• PLD zawiera rc-inetd - interfejs do zarządzania usługami typu inetd. Pozwala zarządzać takimi usługami (np.: telnetd, cvs-pserver) bez znaczenia jakiego typu demon inetd jest używany.

• Podobną koncepcją do rc-inetd kierowano się w tworzeniu pakietu rc-boot. Pozwala on na łatwe zarządzania bootloaderami.

• PLD jest systemem przyjaznym dla programisty. Dostępne są narzędzia do tworzenia aplikacji w wielu językach programowania. Dotyczy wielu "standartowych" języków programowania takich jak C, C++, Perl czy Python. Dostępne są też kompilatory do nieco mniej znanych języków takich jak SML, Prolog, OCaml jak też eksperymentalne kompilatory: Cyclone, Ksi. Dodatkowo mamy wybór wielu narzędzi programistycznych i bibliotek.

• W dystrybucji używane są pakiety typu RPM, do zarządzania pakietami powstał program o swojsko brzmiącej nazwie Poldek, można też używac klasycznego programu RPM.

• W PLD zastosowano skrypty startowe (rc-skrypty) typu System-V. Pozwoliło to na maksymalne zautomatyzowanie procesu instalacji usług systemowych.

• Dystrybucja jest przystosowana do obsługi wielu języków narodowych, a w tym języka polskiego. Jest to najlepiej przygotowana dystrybucja na potrzeby polskich użytkowników.

3. Założenia PLD

• Rozwojowi PLD Linux Distribution przyświecało kilka założeń, oto niektóre z nich: używanie FHS 2.x jako specyfikacji struktury katalogów

• całkowite odejście od termcap i libtermcap (w PLD nie ma pakietu z libtermcap i samego termcapa; ani jeden pakiet nie jest zwiazany z termcapem),

• ujednolicenie gospodarki zarządzania inet serwisami. W praktyce jest to realizowane poprzez używanie tego co oferuje projekt rc-inetd: jest to bardzo prosty mechanizm, przy tym o wiele bardziej elastyczny od tego, co można znaleźć w konkurencyjnych dystrybucjach, pełne przygotowanie pakietów do automatycznego uaktualnienia. Pakiety z RH kompletnie nie są na to przygotowane. Przygotowanie to wiąże się z restartowaniem serwisów przy ich uaktualnieniu, odpowiednim przygotowywaniem procedur uaktualnienia w taki sposób, by umożliwić automatyczną aktualizację nawet przy zmianie plików konfiguracyjnych,

• brak nastawienia na używanie tylko wybranych aplikacji w danej klasie (np. wśród MTA i różnych innych usług). Założenie jest takie, że w najprostszej wersji istnieją preferowane pakiety (np. finger daemona), ale w praktyce w systemie ma być to, czego sobie użytkownik zażyczy (w przypadku fingerów jest to już sprawnie przygotowane; jest jeszcze kilka innych grup takich aplikacji),

• używanie iproute2 jako podstawowego narzędzia do operowania na interfejsach sieciowych, dzięki czemu np. skrypty startowe z PLD są prostsze i krótsze mimo wiekszej funkcjonalnosci w stosunku do swoich odpowiedników z RH; inną zaletą jest wsteczna kompatybillność z opisem interfejsów sieciowych z tym, co jest stosowane w initscripts z RH; kolejną cechą skryptów startowych jest to, że -- w zależnosci od preferencji użytkownika -- mogą one wyświetlać wszystkie komunikaty po polsku, brak nałożonych z góry ograniczeń co do zestawu pakietów, jakie mogą być w dystrybucji. W praktyce oznacza to, że użytkownik ma do dyspozycji wszystko, co udało się nam zebrać, Jeżeli coś zostanie opracowane i przystosowane do tego, żeby mogło współgrać z resztą pakietów, to znaczy, że komuś było potrzebne, więc może komuś przydać się w przyszłości,

• przystosowanie do łatwego przejścia systemu na alternatywne metody autoryzacji (i -- w zależności od potrzeb -- szyfrowania) komunikacji po sieci, jak PAM, czy GSAPI, TSL/SSL... Jest bardzo prawdopodobne, że już w niedługiej perspektywie dużą rolę zacznie tu odgrywać SASL. W praktyce owo łatwe dostosowywanie do np. kerberyzacji systemu jest realizowane także z użyciem rc-inetd, która to platforma ułatwia znakomicie podmianę róznych serwisów na wersje skerberyzowane czy też wykorzystujące inne mechanizmy jak np. socks5 (tutaj jeszcze jest mało zrobione, ale furtka jest szeroko i jednoznacznie otwarta),

• uzupełnianie opisów pakietów i dokumentacji w różnych językach. W dużej części robi się to niejako przy okazji. Użytkownik może sobie skonfigurować i zainstalować wybrane oprogramowanie ze wsparciem dla preferowanego zestawu języków, np.: angielski i niemiecki czy też angielski i polski (zasoby dla innych języków zostaną pominięte). Tak unikalną możliwość konfiguracji osiągamy dzięki konsekwentnemu oznaczaniu zasobów narodowych makrem %lang() w poszczególnych pakietach.

• maksymalna automatyzacja różnych powtarzalnych czynności (dotyczy to zarówno metodologii bieżącej pracy jak i zawartości pakietów).

Wiele założeń wynika bezpośrednio z procedur przygotowywania pakietów, jak:

• kompresowanie wszystkich plików dokumentacji z użyciem gzip (bzip2 nic w praktyce tu nie wnosi, a dostarcza tylko nowych kłopotów, czego doświadczają od czasu do czasu użytkownicy Mandrake),

• separacja bibliotek statycznych w osobne podpakiety *-static (nie każdy tego potrzebuje), a nagłówków do *-devel.

4. Oficjalne wersje PLD

W PLD oficjalnym wersjom dystrybucji nadawane numery oraz dwuliterowe oznaczenia kodowe, które pochodzą od skrótowych oznaczeń pierwiastków. Pierwszej wersji PLD nadano oznaczenie Ra (Rad), zaś kolejne odpowiadają nazwom pierwiastków poukładanych zgodnie z kolejnością określoną przez ich liczbę atomową.

Zazwyczaj jednych i drugich oznaczeń można używać zamiennie, jednak w niektórych wypadkach używa się jedynie oznaczeń cyfrowych, tak oznacza się uaktualnione wersje dystrybucji. Przykładowo nazwa Ra odnosi się zarówno do PLD 1.0 jak i jej zaktualizowanej wersji - PLD 1.1.

Wersja PLD	Kod PLD	Pierwiastek	Data wydania
1.0	Ra	Rad (88)	22.11.2002
2.0	Ac	Aktyn (89)	Nie ustalono
3.0	Th	Tor (90)	Nie ustalono

5. Model rozwoju PLD Linux Distribution

Rozwój PLD Linux Distribution przebiega w sposób otwarty i elastyczny. Efekt końcowy to wynik nakładu wielu osób, nie tylko developerów posiadających prawo zapisu do repozytorium CVS (o którym poniżej), ale także użytkowników zgłaszających informacje o błędach lub nadsyłających poprawki lub propozycje zmian. Z chęcią przyjmiemy nowych developerów, a osoby chcące być bardziej związane z projektem powinny zapisac się na listę dyskusyjną developerów [e-mail].

Informacje o PLD i sposobie jego rozwoju:

• Repozytorium CVS

Źródła PLD Linux Distribution trzymane są w repozytorium CVS (Concurrent Versions System, http://www.cyclic.com/CVS/index.html), wolnodostępnym systemie kontroli wersji dostarczanym wraz z naszą dystrybucją. Serwer CVS PLD Linux Distribution (http://cvs.pld-linux.org/) jest dostępny dla wszystkich w trybie tylko dla odczytu (Read Only), oraz dodatkowo w trybie do odczytu/zapisu (Read/Write) dla developerów. Repozytorium zostało podzielone na kilka modułów w celu ułatwienia pracy osobom doń commitującym (określenie commit pochodzi z podręcznika systemowego cvs).

• Serwer DistFiles

W zamierzchłych czasach wszystkie pliki (a więc kody źródłowe, łatki (patche), poprawki, itp) potrzebne do zbudowania pakietów trzymane były w repozytorium. Niestety CVS nie został zaprojektowany do przechowywania plików binarnych (a archiwum tar.gz takim jest) i próba zmuszenia go do przechowywania takowych dostarczała różnych problemów. A to osoba posiadające stosunkowo wolne łącze zaczęła wrzucać kilkudziesięcio megabajtowy plik, skutecznie blokując możliwość pracy innym developerom na kilka godzin. Uciążliwe były też pozostające tzw. 'locki', czyli blokady na modułach repozytorium (przede wszystkim SOURCES/). Rozwiązaniem tych problemów było wprowadzenie w maju 2003 roku serwera DistFiles, do którego przeniesiono większość plików binarnych z CVS.

• Core Developers Group

Gdyby PLD Linux Distribution było firmą, Core Developers Group najtrafniej możnaby określić jako Radę Nadzorczą. Jej celem jest podejmowanie w sposób demokratyczny krytycznych dla dystrybucji decyzji oraz rozwiązywanie konfliktów, których nie dało się zażegnać w inny sposób. W skład Grupy wchodzą developerzy aktywnie udzielający się w projekcie.

• Lista dyskusyjna [e-mail]

Na liście tej prowadzone są dyskusje na temat bieżących prac nad dystrybucją, jak również ustalane są plany na przyszłość. Jeśli nie posiadasz prawa zapisu do repozytorium, a chciałbyś podzielić się efektami swych prac z innymi, lista ta jest najlepszym miejscem na poinformowanie o tym fakcie.

• Buildery

Mianem builderów określane są specjalnie przygotowane środowiska (często na dedykowanych maszynach), na których budowane są pakiety, które później zostaną umieszczone na serwerach FTP projektu. Każda z linii dystrybucji ma swoje oddzielne buildery, stworzone z pakietów dla niej przeznaczonych.

Nie wszyscy developerzy mają prawo do puszczania zleceń na buildery, czyli rozkazów zbudowania poszczególnych pakietów - przywiliej ten ma ledwie garstka osób, zaznajomionych z automatyką oraz znających potrzeby danej dystrybucji. Rzadko kiedy zachodzi potrzeba bezpośredniego grzebania w strukturze danego środowiska - codzienna praca opiera się na wysyłaniu odpowiednio przygotowanych maili, podpisanych kluczem PGP osoby uprawnionej.

• Nest

Kolejnym istotnym elementem rozwoju projektu jest Nest. Jak samo rozwinięcie skrótu (Never Ending STory) wskazuje, prace nad tą linią nigdy się nia zakończą. Jest to niejako "materialne" odzwierciedlenie bieżących prac w CVS projektu - wszelkie zmiany w rezpozytorium powodują przebudowanie danego pakietu na builderach Nest. Oczywiście, może to doprowadzić do sytuacji, gdy środowisko to będzie niespójne, jednak w przypadku tej "linii" jest to zjawisko całkowicie normalne i akceptowalne, dlatego osoby chcące trzymać rękę na pulsie powinny się dwa razy zastanowić, gdyż przejście na Nesta może (ale nie musi) doprowadzić do sytuacji, gdy po kolejnym upgradzie pakietów system przestanie funkcjonować.

6. Projekty związane z PLD

• Rescue CD

Jest to niewielka dystrybucja startująca z płyty CD, bez konieczności instalacji na twardym dysku. Zawiera zestaw wyspecjalizowanych narzędzi pomocnych w przypadku usuwania awarii systemu. Rescue CD oparto o jądro PLD i wyposażono w zestaw najbardziej niezbędnych programów, dzięki czemu udało się uzyskać niewielkie rozmiary dystrybucji. Pozwala to załadowanie całości do pamięci operacyjnej, a następnie a wyjęcie płyty CD z czytnika. Lista dostępnych programów jest umieszczona na domowej stronie WWW projektu.

• PLD Live CD

Projekt mający na celu stworzenie kompletnej dystrybucji Linuksa startującej z płyty CD, zawiera znaczną ilość narzędzi i programów użytkowych. PLD Live jest przygotowane dla zwykłych użytkowników chcących bliżej poznać PLD, zawiera system X Window i liczne programy użytkowe. Z założenia w PLD Live dokonywano jak najmniej zmian w stosunku do bazowej dystrybucji - PLD, ta cecha, oraz możliwość instalacji całości na dysku twardym, daje nam gotowe, w pełni skonfigurowane PLD.

• NEST (Never Ending STory)

Użytkownicy mogą się zetknąć także z tworem o nazwie NEST. Jego nazwa po rozwinięciu jest dokładnym odzwierciedleniem jego funkcji. Jest roboczą, automatycznie tworzoną "dystrybucją" z najnowszych dostępnych pakietów. Pakiety te nie przeszły okresu testowania, a więc używanie takiej dystrybucji jest praktycznie niemożliwe.

• DC (Devil's Compilation)

Po wydaniu stabilnej wersji Ra, użytkownicy chcieli mieć dostęp do nowych wersji programów, prace nad nową wersją dystrybucji jeszcze nie ruszyły, zaś NEST nie nadawał się do użytku. Kilku deweloperów PLD postanowiło stworzyć coś co zapełni tę lukę - tak oto powstało DC. Mimo że Devil's Compilation było odrębną inicjatywą, to znalazło grono zainteresowanych z pośród użytkowników PLD. Po rozpoczęciu prac nad PLD 2.0 projekt DC przestał być potrzebny i został zaniechany.

7. Logo

Pomysł na logo PLD zrodził się w głowie Agnieszki Sloty. Projekt graficzny został stworzony przez Marcina Mierzejewskiego (Kevin) i Maćka Zielińskiego.

8. Ważne adresy:

Strona główna - http://pld-linux.org

Dokumentacja - http://pl.docs.pld-linux.org

Listy dyskusyjne - http://lists.pld-linux.org

Częściowe archiwa list dyskusyjnych - mail-archive.com, Gmane

Serwer IRC (freenode) http://irc.freenode.net

Serwer IRC (IRCnet) http://ircnet.org

Serwer PLDNet: irc.pld-linux.org

Istniejące kanały:

#pld - kanał przeznaczony dla Developerów.

#pldhelp - kanał użytkowników PLD

#pldlivecd - kanał użytkowników LiveCD

System zgłaszania błędów - http://bugs.pld-linux.org

Rescue CD - http://rescuecd.pld-linux.org

PLD Live CD - http://livecd.pld-linux.org

4. Czym jest Samba?

Samba - jest to darmowy serwer plików i drukarek dostępny dla wielu systemów operacyjnych. Samba rywalizuje bezpośrednio z systemem operacyjnym Microsoft Windows NT i w wielu przypadkach jest od niego lepsza, lecz nie jest jednak pozbawiona wad. Trzeba włożyć dużo wysiłku, by się jej nauczyć, wielu ludzi twierdzi, że trudno z niej korzystać oraz niełatwo nią zarządzać. Pomimo tych wszystkich wad korzystają z niej duże i małe korporacje, organizacje rządowe, organizacje pozarządowe, niewielkie przedsiębiorstwa, a dzięki sukcesowi Linuksa także użytkownicy indywidualni.

5. Zastosowanie Samby

Samba to pakiet o otwartym dostępie do kodu źródłowego (ang. open source software), który przede wszystkim zawiera implementację serwera plików i drukarek dla klientów Windows i Unix. Poniżej pokazany jest przykład dwóch różnych komputerów-klientów używających serwera Samby do udostępniania plików oraz drukowania.

Rys. Serwer plików udostępniający pliki i drukarki.

Dokładniej Samba jest serwerem plików i serwerem drukarek, który zawiera implementację protokoły SMB (ang. Server Message Block). Protokół SMB to ten sam protokół, który leży u podstaw protokołów sieci Microsoft Windows. Oznacza to, że w wielu przypadkach Samba może być niskokanałowym i bardzo wydajnym subtytutem serwera Windows NT.

Jeżeli korzystamy z oprogramowania klientów SMB, dostęp do Samby mogą uzyskać także inne typy klientów. Na przykład klient Thursby Dave dla systemu MacOS umożliwia dostęp do serwerów Samby komputerom Macintosh.

Od swoich początków (w 1991r.) Samba ciągle doskonali funkcjonalność. Obecnie zaimplementowano w niej wiele takich samych funkcji jak w Windows NT Server 4.0, a także zestaw funkcji , których Windows NT po prostu nie ma. Ponadto zespołowi Samby bardzo zależy na tym, aby były one całkowicie zgodne z Windows NT Server.

Oto niektóre tylko z funkcji Samby:

Współdzielenie plików i drukarek - to dla wielu użytkowników istota Samby. Samba pozwala wielu różnym typom klientów dzielić pliki i drukarki z jednego lub wielu serwerów.

• Serwer logowania Sieci Windows - funkcja ta umożliwia komputerom-klientom Win9x zalogowanie się do serwera Samby tam, jak do serwera Windows NT. Mogą one uruchomić własne skrypty logowania i mieć dostęp do profili.

• Podstawowy kontroler domeny - Samba może pracować jako podstawowy kontroler domen.

• Serwer członkowski domen - Samba może być członkiem domeny i obsługuje większość protokołów - kontrolerów domen Windows NT (szyfrowany RPC itp.).

• Serwer przeglądania Windows - Samba obsługuje przeglądanie przez klientów Windows.

• Obsługa WINS - Samba może działać jako internetowy serwer nazw Windows dla klientów systemu Windows

• Obsługa OpLock - Samba obsługuje opcję OpLock. Pozwala to na buforowanie plików w komputerach-klientach.

• Eksperymentalna obsługa LDAP - Samba eksperymentalnie obsługuje protokół LDAP, która umożliwia centralizację informacji konfiguracyjnych.

• Aliasy NetBIOS - Samba umożliwia stosowanie aliasów NetBIOS co pozwala działać pojedynczemu serwerowi Samby jak kilka oddzielnych serwerów.

• Automatyczna instalacja sterowników drukarek w systemach Windows 9x - umożliwia użytkownikom łatwą instalację sterowników drukarek w przypadku, gdy chcą skorzystać nowych drukarek.

• Synchronizacja haseł pomiędzy systemami Windows oraz Unix - pozwala użytkownikom na utrzymanie tego samego hasła dla systemów Windows i Unix.

• Obsługa SSL - za pomocą serwerów proxy SSL można uzyskać bezpieczny dostęp do serwerów Samby w sieci Internet.

Ponadto, Samba zawiera dużo więcej funkcji, których wyżej nie wymieniono.

6. Historia Samby

Początek Samby to prosty programik, który posłużył Andrew Tridgellowi do uzyskania dostępu z komputerów z systemem PATHWORKS dla DOS firmy Digital do plików na komputerze Sun. W końcu 1991 roku Andrew Tridgell, który był wtedy doktorantem na Narodowym Uniwersytecie Australii, zdobył system eXcursion - serwer X dla systemu DOS. Ponieważ eXcursion wymagał systemu PATHWORKS dla DOS, Adrew nie mógł dłużej korzystać z pakietu PCNFS firmy Sun do korzystania z plików w swojej stacji roboczej Sun.

Tridgell pracował nad sposobami korzystania z plików na swojej stacji roboczej Sun, poświęcając mnóstwo czasu na śledzenie pakietów. W ten sposób dowiedział się co działo się z pakietem PATCHWORKS. Następnie napisał serwer dla systemu SunOS, który obsługiwał pakiety przesyłane przez klienta PATCHWORKS.

Kiedy zapytał firmę Digital, czy to co zrobił legalne (implementacja protokołu na podstawie śledzenia pakietów z kabla), powiedziano mu: “legalne, ale głupie”, gdyż protokół był opisany w kilku specyfikacjach. Jak się okazało były to specyfikacje RFC1001 oraz RFC1002 specyfikacje protokołu NetBIOS nad TCP/IP. a także kilka specyfikacji SMB, ponieważ PATCHWORKS był implementacją klienta i serwera SMB.

Na szczęście dla nas, zachęcono Andrew do udostępnienia swojego programu co też uczynił. Dlaczego nazwał swój pakiet Samba? Początkowo nazywał się on po prostu serwer. Później, kiedy dowiedział się, że zaimplementowany protokół to SMB, zmienił mu nazwę na SMBServer. Jednak w 1994 r. firma posiadająca komercyjny serwer SMB poinformowała go, że nazwa SMBServer była zastrzeżona. Andrew Tridgell musiał więc zmienić nazwę swojego pakietu. Podczas wyszukiwania wszystkich słów zawierających s, m oraz b w plikach słownika systemach Unix odkrył, że “Samba” pasuje “najlepiej”. Jest to zdecydowanie lepsza nazwa niż SMBServer.

Można z ironią pomyśleć, że obecnie jest prawdopodobnie więcej implementacji Samby niż pakietu tamtej firmy. Był to Syntax Inc.

Nad Sambą od wielu lat pracuje grupa ludzi z całego świata. Aby poznać członków zespołu albo zostać jednym z nich najlepiej odwiedzić stronę www.samba.org.

7. Inne implementacje SMB

Samba jest jedną z dużej liczny implementacji serwera protokołu SMB. Aby zobaczyć, ile jest innych implementacji serwera SMB, wymienione zostanie kilka z nich, aby określić iż Samba nie jest jedyna. Inne implementacje SMB to:

1. Program PC Network firmy IBM

2. Serwery LAN Server firmy IBM

3. LAN Manager Microsoftu

4. Windows NT

5. Windows for Workgroup i Windows 9x

6. PATCHWORKS wydany przez Compaq

7. LAN Manager dla Uniksa

8. VisionFS wydany przez SCO

9. TotalNet Advanced Server firmy SYNTAX

10. Netlink Server firmy SunOS

8. Struktura Samby

Samba składa się z kilku demonów, wielu programów oraz pliku konfiguracyjnego.

Rys. Samba składa się z kilku demonów, od których klienci uzyskują dostęp za pomocą protokołów TCP oraz UDP.

Niektóre komponenty Samby:

• nmbd(8) - demon usługi nazw NetBIOS - w poprawnie skonfigurowanym serwerze Samby działa co najmniej jeden proces nmbd(8), a jeżeli skonfigurowano Sambę do pracy jako serwer WINS (za pomocą polecenia wins server=yes), będzie utworzona dodatkowa kopia demona nmbd(8) może działać w przypadku, gdy Samba korzysta z systemu DNS do przekształcenia nazw NetBIOS. Demon nmbd(8) obsługuje poszukiwanie nazw NetBIOS, a także żądania WINS. Spełnia również ważną rolę w przeglądaniu.

• smbd(8) - demon protokołu SMB - w poprawnie skonfigurowanym serwerze Samby działa co najmniej jeden demon smbd(8. Demon ten obsługuje dostęp do plików oraz drukarek, a także API programu LAN MANAGER także jak: NetServerEnum, NetShareEnum, NetUserGetInfo itp.

• smb.conf - plik konfiguracyjny Samby - plik ten w większości dystrybucji Linuksa znajduje się w katalogu /etc, natomiast w standardowych instalacjach systemu Unix w katalogu /usr/local/samba/lib. Zawiera on wszystkie informacje o konfiguracji komponentów smbd(8) i nmbd(8).

• smbclient - klient protokołu SMB - program ten umożliwia użytkownikom korzystanie z poziomu systemu Unix z innych serwerów SMB jak np.: Windows NT oraz Windows 9x.

• nmblookup - program przeszukiwania nazw NMB - program ten umożliwia użytkownikom tworzenie zapytań do serwerów o zarejestrowanie nazwy NetBIOS.

• smbstatus - polecenie statusu protokołu SMB - administratorzy wykorzystują je do uzyskania informacji na temat tego, kto korzysta z Samby i z jakich udziałów.

• smbprint - skrypt powłoki do drukowania w systemach Windows z poziomu systemu Unix.

• smbtar - skrypt powłoki do wykonywania kopii archiwalnych w systemach Windows z poziomu systemu Unix.

Komputery-klienty Samby w czasie korzystania z serwera używają zarówno protokołu TCP jak i UDP. Protokołu TCP używają w celu uzyskania dostępu do pliku lub drukarki oraz zalogowania się do sieci. W tym celu ustanawiają połączenie TCP z demonem smbd na porcie 139. Komputery-klienty korzystają z protokołu UDP w celu zarejestrowania lub przekształcania nazw NetBIOS, a także w czasie przeglądania sieci. Datagramy UDP, które przesyłają klienty, trafiają do portu 137 lub 138 w zależności od wykorzystywanej funkcji.

Demona nmbd(8) można uruchomić na 3 różne sposoby:

• w czasie startu systemu

• ręcznie - na życzenie administratora systemu

• za pomocą demona inetd

9. Zarządzanie i konfiguracja Samby

Samba może spełniać wiele funkcji, a między innymi:

• udostępniać usługi serwera plików i drukarek

• pracować jako serwer logowania (ang. logon server)

• pracować jako podstawowy kontroler domeny

• działać jako serwer przeglądania lub główny serwer przeglądania domeny

Ponadto Samba umożliwia całkowitą kontrolę nad wieloma wykonywanymi przez nią funkcjami. Na przykład, można mieć kontrolę nad tym, kto jest właścicielem nowo utworzonego pliku i jakie określono dla niego prawa dostępu. Można także - za każdym razem, kiedy użytkownik połączy się lub rozłączy z określonym zasobem - uruchamiać odpowiednie polecenia na serwerze.

Wielu użytkowników zainteresuje się możliwościami Samby jako serwera plików i drukarek. Szybko jednak będą oni chcieli uzyskać więcej informacji na temat zarządzania Sambą i tego, w jaki sposób wykorzystywać Sambę do wykonywania bardziej skomplikowanych czynności.

10. Plik smb.conf

Sambą steruje plik smb.conf. Większość nowych dystrybucji Linuksa, instalując wersję Samby umieszcza ten plik w katalogu /etc.

Plik smb.conf składa się z ciągu sekcji. Każda z nich zawiera zestaw parametrów, które w określony sposób wpływają na sposób działania Samby. Oprócz trzech sekcji specjalnych: global, names oraz printers istnieje sekcja opisująca pojedynczy udział (ang. share). Komputery-klienty łączą się z udziałem, a następnie uzyskują dostęp do plików w ramach tego udziału.

Sekcje są oznaczone, ujętą w nawiasy kwadratowe, nazwę sekcji. Poniżej pokazany jest przykład oznaczający początek sekcji:

[homes]

Sekcja global, nie musi być oznaczona przez [global], ale zastosowanie takiego oznaczenia jest dobrym zwyczajem.

Parametry podaje się w następującej formie:

nazwa-wartość

gdzie:

• nazwa - określa nazwę parametru. Nazwa może zawierać spacje. Poprawną nazwę parametru jest na przykład os level

• wartość - określa wartość przypisaną do parametru. Może to być ciąg znaków, liczba, słowo takie jak true, false, yes, no, wyrażenie regularne itp.

W tabeli poniżej wyszczególnione zostały sekcje, które mogą znaleźć się w pliku smb.conf:

Sekcja	Opis
[global]	Jedno z trzech specjalnych sekcji zawierająca parametry sterujące ogólnym działaniem Samby. Są to, na przykład parametry dotyczące bezpieczeństwa oraz nazw NetBIOS. Sekcja ta jest jedyną, która nie definiuje udziału.
[homes]	Druga sekcja specjalna. Jest to skrócony sposób określenia faktu, że użytkownikom serwera Samby mają być udostępniane ich katalogi macierzyste. Potencjalnie sekcja ta definiuje użytkownika.
[printers]	Trzecia sekcja specjalna. Skrócony sposób zdefiniowania faktu, że użytkownikom mają być udostępnione wszystkie drukarki podłączone do serwera Samby. Potencjalnie sekcja ta definiuje wiele udziałów.
[nazwa udziału]	Wszystkie pozostałe sekcje w pliku smb.conf określają pojedynczy udział o podanej nazwie. Nazwy udziałów mogą zawierać makropolecenia.

Spacje w wartościach parametrów można wstawiać dowolnie, tam gdzie są one potrzebne. Można także ująć tego typu łańcuchy w cudzysłowy, ale nie jest to wymagane.

Niektóre parametry mogą występować tylko w sekcji global, podczas gdy inne mogą znajdować się w dowolnej sekcji, włącznie w sekcji global. Parametry dla udziału, które znajdują się w sekcji global są wartościami domyślnymi dla tych udziałów gdzie określonego parametru nie zdefiniowano.

W pliku smb.conf ma swoje miejsce inny bardzo ważny mechanizm: makrodefinicje i zmienne. Pozwalają one na pobieranie wartości z wbudowanych zmiennych Samby lub innych informacji, które Samba pobiera w czasie jej działania. Makrodefinicje i zmienne to jeden z kluczowych elementów automatyzacji Samby.

Tabela poniżej pokazuje, niektóre zmienne Samby.

Zmienna	Znaczenie
%S	Nazwa bieżącej usługi
%h	Nazwa serwera - pierwsza część FQDN serwera
%m	Nazwa NetBIOS klienta podłączonego do tego procesu serwera
%L	Nazwa NetBIOS serwera

W czasie instalacji Samby w systemie, co często domyślnie towarzyszy instalacji Linuksa na dysku pojawiają się także strony podręcznika man na temat Samby oraz domyślnego pliku smb.conf. Aby uzyskać informacje na temat określonego zasobu lub parametru, wystarczy sprawdzić stronę podręcznika man wpisując:

man smb.conf

1. Przykładowy plik smb.conf

Poniżej zostanie stworzony przykładowy plik smb.conf wraz z omówieniem poszczególnych pół.

[global]

workgroup = sambanet

server string = Serwer Samby

quest account = pcquest

log file = /var/log/samba/log.%m

password level = 8

[names]

comment = Katalogi macierzyste

browseable = no

writeable = yes

UWAGA: W wielu przypadkach po dokonaniu zmian w pliku smb.conf nie trzeba uruchamiać Samby. Często wystarczy wysłać sygnał HUP do wszystkich demonów smbd(8). można to zrobić za pomocą następującego polecenia:

# killall -HUP smbd

Skorzystanie z tego polecenia to wystarczy do ponownego uruchomienia Samby.

Powyższy plik smb.conf jest dosyć prosty, lecz zawiera pewną liczbę parametrów. Jaką funkcję spełniają te parametry? Ich znaczenia wyjaśnione zostało poniżej:

Parametr	Funkcja
worgroup	Ten parametr określa grupę roboczą lub domową, której członkiem jest nasz serwer Samby.
server string	Parametr ten określa łańcuch znaków, który pojawi się jako opis naszego serwera w czasie przeglądania przez innych użytkowników sieci.
quest account	Parametr ten określa nazwę gościa, jeżeli jest ono potrzebne.
log file	Ten parametr określa położenie i nazwę pliku dziennika demona smbd. Ostatnim elementem nazwy pliku dziennika jako log.%m co oznacza, że każdy klient będzie miał oddzielny plik dziennika z nazwą klienta w nazwie pliku.
password level	Parametr ten definiuje sposób działania w przypadku, gdy nazwa użytkownika i hasło są zgodne. Najpierw Samba próbuje zastosować hasło w taki sposób, w jaki zostało wprowadzone przez klienta. Jeżeli uwierzytelnienie się nie powiedzie, Samba zamienia wszystkie litery na małe. Jeżeli i to nie przyniesie skutku, Samba wypróbuje n kombinacji wielkości liter, gdzie n jest wartością określaną dla parametru password level.
comment	Komentarz do udziału.
browseable	Parametr ten określa, czy udział można przeglądać. Udziały można przeglądać domyślnie, zatem parametr należy zdefiniować tylko dla tych udziałów, dla których chcemy zabronić prawa przeglądania.
path	Parametr ten określa miejsce w systemie plików Linuksa, od którego będą udostępniane pliki. Domyślną wartością tego parametru jest /tmp, dlatego należy koniecznie go zdefiniować.
public	Ten parametr określa, czy goście mogą uzyskać dostęp do udziału.
writeable	Ten parametr określa, czy istnieje prawo zapisu do zasobu. Domyślnie zasoby są tylko do odczytu.

2. Pliki dziennika zdarzeń, a usuwanie usterek

Samba zapisuje komunikaty o błędach oraz niektóre komunikaty informacyjne do dziennika zdarzeń. Wiele dystrybucji Linuksa tworzy swoje pliki dzienników zdarzeń w katalogu /var/log/samba.

Plik	Zawartość
log.smb	W pliku tym rejestruje swoje informacje demon smbd. Jeżeli w pliku smb.conf określono parametr log file, każdy nowy egzemplarz demona smbd w czasie uruchamiania zapisze informacje w dzienniku zdarzeń. W innym przypadku, zapisze te informacje w pliku log.smb
log.nmb	W tym pliku zapisuje swoje informacje demon nmbd.
log.nazwa	Jeżeli określiliśmy parametr log file tak jak pokazano w przykładzie pliku smb.conf, demon smbd zapisze informacje do pliku log.nazwa w momencie połączenia użytkownika. Argument nazwa jest nazwą NetBIOS klienta.

Przykładowe pliki dzienników zdarzeń tworzone przez Sambę w wielu wersjach Linuksa:

Pliki dzienników są nieocenione w rozwiązywaniu problemów z Sambą. w plikach tych, Samba zapisuje bardzo dużą ilość informacji śledzących. Poziom szczegółowości definiuje sam parametr debug level. Domyślna wartość tego parametru to 0. W takim przypadku Samba jest bardzo lakoniczna i zapisuje tylko te błędy, które uniemożliwiają jej działanie. Aby śledzić informacje o problemach, na jakie napotyka Samba próbując wykonać działania dla klientów należy zwiększyć parametr debug level. Problemy te obejmują między innymi błędy uwierzytelniania, brak możliwości transmisji pakietów, niepowodzenia przy otwieraniu lub tworzeniu plików itp.

Aby śledzić te informację, dodany do sekcji global poniższy zapis i ponownie uruchomimy Sambę:

debug level = 6

Zwykle wartość 6 dla parametru debug level jest wystarczająca. Wartość 10 spowoduje, że uzyskamy jeszcze więcej informacji włącznie ze zrzutem w postaci szesnastkowej każdego otrzymanego pakietu.

3. Współdzielenie plików

Współdzielenie plików jest jedną z głównych funkcji Samby, a udziały plików można skonfigurować w dość dowolny sposób. Administrator Samby może tworzyć udziały gości dostępne dla wszystkich użytkowników albo ograniczać dostęp dla określonych użytkowników lub stacji roboczych.

Udziały i ich dostępność

Użytkownik może żądać dostępu do udziału na kilka sposobów:

• za pomocą polecenia net use z okna DOS:

net use h:\\samba1\public

• za pomocą okna dialogowego Mapuj dysk sieciowy w systemie Windows. W większości wersji Windows to okno dialogowe można znaleźć, klikając prawym przyciskiem myszy ikonę Otoczenie sieciowe lub Mój komputer

Aby zrealizować żądanie klienta dostępu do udziału, Samba najpierw sprawdza, czy żądany udział istnieje. W tym celu:

• Przegląda plik smb.conf, poszukuje sekcji dostępu do udziału. Jeżeli taka sekcja istnieje, zwraca jej wartość jako wynik przeszukiwania.

• Jeżeli udział nie istnieje, sprawdza czy w pliki smb.conf znajduje się sekcja [homes]. Jeżeli tak, przegląda plik passwd w celu sprawdzenia czy nazwa żądanego udziału odpowiada nazwie użytkownika. Jeżeli tak jest, udział [homes] jest klonowany i zwracany w wyniku z nową nazwą.

• Jeżeli w dalszym ciągu nie odnaleziono zasobu, Samba sprawdza czy w pliku smb.conf znajduje się sekcja [printers]. Jeżeli tak, sprawdza czy żądana drukarka odpowiada zapisowi w pliku printcap. Jeśli odpowiedź jest twierdząca klonuje udział [printers] i zwraca go w wyniku.

• Jeżeli w dalszym ciągu nie odnaleziono udziału, Samba sprawdza, czy nie jest to usługa domyślna, a jeżeli tak jest, zmienia jej nazwę tak, aby odpowiadała żądanej usłudze i zwraca ją w wyniku.

• Jeżeli po tych czynnościach nie odnaleziono udziału, Samba zwróci klientowi błąd nieznanej nazwy w sieci.

Jeżeli na dowolnym z przedstawionych etapów Samba nie może uzyskać dostępu do katalogu określonego w opisie udziału (parametr path), zwraca klientowi błąd nieznanej nazwy w sieci.

Poniżej wymienione zostaną niektóre powody, dla których Samba nie może odnaleźć katalogu:

• błąd w pisowni katalogu lub jego brak

• użytkownik żądający dostępu do udziału nie posiada praw dostępu do katalogu określonego przez udziałem

Ze względu na omówioną poprzednio kolejność sprawdzania, niektóre nazwy udziałów nie będą dostępne:

• nazwa udziału w pliku smb.conf ma pierwszeństwo przed dowolnym zapisem w pliku passwd lub printcap, nawet jeżeli zdefiniowano sekcje [homes] i [printers]. Tak więc udział będący katalogiem macierzystym użytkownika fred nie będzie widoczny, jeżeli w pliku nie zdefiniowano udziału fred.

• udziały będące katalogiem macierzystym mają pierwszeństwo przed drukarkami. Tak więc, drukarka o nazwie fred (w pliku printcap) nie będzie widoczna, jeżeli w pliku passwd zdefiniowano użytkownika fred i istnieje sekcja [homes] lub jeżeli w pliku smb.conf zdefiniowano zasób fred.

Po sprawdzeniu, że udział istnieje, Samba określa, czy użytkownik żądający dostępu do udziału posiada prawa dostępu. A zatem upewnia się, kto próbuje uzyskać dostęp do udziału, a następnie czy użytkownik jest dopuszczony do korzystania z zasobu.

1. Konfiguracja współdzielenia plików

Samba umożliwia definiowanie kilku parametrów w pliku smb.conf dotyczących podstawowych właściwości udziału. Obejmują one takie same informacje jak ta, czy w ramach udziału istnieje możliwość zapisu, czy jest on widoczny dla innych stacji roboczych, a także tekstowy opis udziału, który znajduje się na liście do przeglądania.

Podstawowe właściwości udziałów:

Nazwa	Typ	Domyślnie	Opis
read only	logiczny	true	Informacje, że w udziale nie można wykonać operacji zapisu. Prawo zapisu mają użytkownicy wymienieni na liście będącej wartością parametru write list.
writeable	logiczny	false	Jeżeli parametr ten ma wartość true, pliki w ramach udziału mogą być modyfikowane. Aby zapis się powiódł użytkownik musi posiadać odpowiednie uniksowe prawa dostępu. Jest to przeciwieństwo parametry read only
comment	łańcuch znaków	brak	Tekst będący treścią parametru comment powinien opisywać przeznaczenie udziału. Użytkownik przeglądający sieć zobaczy tekst obok nazwy udziału.
volume	łańcuch znaków	true	Pozwala na zmianę nazwy woluminu dla udziału. Nazwa woluminu występuje w przypadku odwzorowania udziału jako dysku sieciowego.
browseable	logiczny	logiczny	Jeżeli dla udziału parametr browseable ma wartość true, udział będzie widoczny w czasie przeglądania serwera Samby. Jednakże nadal można uzyskać dostęp do udziału, którego nie można przeglądać, za pomocą nazwy. Tak więc ograniczenie możliwości przeglądania nie zwiększa zbytnio bezpieczeństwa.
fstype	łańcuch znaków	NTFS	W czasie formułowania zapytań o typ systemu plików udziału w wyniku jest zwracana wartość tego parametru. W zasadzie tego parametru nie trzeba definiować.
available	logiczny	true	Jeżeli zasób jest dostępny (wartość tego parametru = true), klienci mogą podłączyć się do udziału i korzystać z jego zasobów. Aby czasowo wyłączyć udział w celu wykonania zadań administracyjnych, należy na czas pracy ustawić wartość available na wartość false. Aby użytkownicy uzyskali dostęp do udziału, wystarczy usunąć ten wiersz.
path, directory	łańcuch znaków	/tmp	Określa uniksową ścieżkę dostępu na serwerze Samby do udziału. Pliki i katalogi poniżej tego poziomu znajdują się w głównym katalogu udziału
time offset	liczba całkowita	0; etykiety czasowe są modyfikowane	Wartość tego parametru to liczba sekund, które Samba dodaje do etykiety czasowej każdego pliku w udziale.

Przykład:

Definicja udziału na przykładzie poniżej tworzy prosty udział o nazwie tymczasowe. Administrator Samby może skonfigurować taki udział w celu udostępnienia użytkownikom miejsca na pliki tymczasowe:

[tymczasowe]

comment = miejsce na pliki tymczasowe

path = /tymcz

browseable = true

writeable = true

2. Wybór plików

W czasie tworzenia udziału plikowego może okazać się przydatne zezwolenie na przeglądanie tylko niektórych plików i katalogów. Samba umożliwia oznaczenie plików jako niedostępne oraz ukryte za pomocą atrybutu DOS - ukryty (ang. hidden). Dla zwiększenia bezpieczeństwa możliwa jest także kontrola korzystania z dowiązań symbolicznych w udziałach plików.

Parametry wybory plików

Nazwa	Typ	Domyślnie	Opis
hide files	łańcuch znaków	brak ukrytych plików	Pozwala administratorowi Samby na określenie listy plików ukrytych. Pliki ukryte są widziane przez klientów tak, jak pliki z atrybutem DOS “ukryty”. Można do nich uzyskać dostęp jeżeli użytkownik zna nazwę pliku lub jego program obsługuje przeglądanie plików ukrytych.
hide dot files	logiczny	true	Definiuje, czy pliki, których nazwa rozpoczyna się od kropki mają mieć ustawiony atrybut DOS “ukryty”. Przydaje się to w odniesieniu do katalogów macierzystych w systemach uniksowych, ponieważ zwykle zawierają one wiele takich plików (z kropką jako pierwszy znak nazwy), co może powodować bałagan w czasie przelądania udziału.
veto files	łańcuch znaków	brak weta dla plików	Zawiera listę nazw plików i katalogów, które są oznaczone przez Sambę jako niewidoczne i nie można do nich uzyskać dostępu. Poszczególne wpisy listy są oddzielone znakiem /. Można stosować znaki specjalne ? oraz *. Aby na przykład udzielić weta dla plików wykonywalnych Windows, wystarczy dla udziału plików ustawić parametr veto files =/*.exe/*.com/*.bat/. Jeżeli parametr case-sensitive ma wartość false, Samba nie będzie rozróżniać małych i wielkich liter w nazwach plików.
delete veto files	logiczny	false	W przypadku żądania usunięcia katalogu - zawierającego pliki z prawem weta ustawionym za pomocą parametru veto files - pliki takie nie będą usunięte chyba, że parametr veto files ma wartość true/. Oczywiście pliki będą usunięte tylko wtedy, gdy użytkownik posiada odpowiednie uniksowe prawa dostępu.
dont descend	łańcuch znaków	wszystkie katalogi w głąb są dostępne	Parametr ten powinien zawierać listę katalogów oddzielonych przecinkami, do których Samba nie powinna udzielać dostępu. Katalogi znajdujące się na tej liście są widzialne przez użytkowników próbujących uzyskać do nich dostęp jako puste. Parametr ten przydaje się do zabezpieczenia nieautoryzowanego dostępu do katalogów systemowych takich jak: /proc lub /dev.
fallow symlinks	logiczny	true	Jeżeli ten parametr ma wartość true, Samba będzie uwzględniać dowiązania symboliczne w obrębie udziału. Ze względu bezpieczeństwa, niektórzy administratorzy Samby wyłączają parametr follow symlinks.
wide links	logiczny	true	Decyduje o tym, czy Samba ma uwzględniać dowiązania prowadzące poza obszar udziału plików, z którego użytkownik korzysta. Jeżeli na przykład parametr wide links ma wartość true, dowiązuje w katalogu macierzystym użytkownika wskazujące miejsce w ramach jego katalogu macierzystego będzie dozwolone podczas, gdy dowiązanie do pliku /etc/passwd nie będzie dozwolone.

11. Udziały typu gość

Aby udzielić dostępu do udziału bez potrzeby zarządzania użytkownikami i kontami, można skonfigurować udział typu gość. Dostęp do takiego udziału nie wymaga nazwy użytkownika i hasła. Każdy, kto ustanowi połączenie sieciowe z serwerem Samby, będzie mógł z niego korzystać.

Parametry sterujące dostępem typu gość

Nazwa	Typ	Domyślnie	Opis
Guest ok,public	logiczny	false	Określa czy udział posiada dostęp typu gość.
Guest account	łańcuch znaków	Wartość domyślna określana w czasie Samby. Zwykle jest to konto nobody. Grupa tego użytkownika to zwykle nogroup.	Jeżeli zgodnie z parametrem quest ok do udziału jest dozwolony dostęp typu gość, wartością tego parametru jest nazwa użytkownika w systemie Unix wykorzystywana przez Sambę do uzyskania dostępu do udziału.
Guest only only guest	logiczny	false	Jeżeli parametr ten ma wartość true, do tego udziału dozwolone są tylko połączenia typu gość. Nazwę użytkownika stosowaną do uzyskania dostępu do udziału określa parametr quest account.

Parametr quest only ma znaczenie tylko wtedy, gdy typ udziału został skonfigurowany jako gość za pomocą parametru quest ok na wartość true.

12. Ograniczenia dostępu do udziału

Utworzenie całkowicie anonimowego udziału za pomocą parametru quest only przydaje się w teorii, ale w praktyce administrator Samby będzie chciał ograniczyć grono użytkowników, którzy mogą uzyskać do niego dostęp. Samba obsługuje kontrolę dostępu do udziałów na poziomie sieci (na podstawie adresu IP stacji roboczej), a także na podstawie nazwy użytkownika próbującego uzyskać dostęp do udziału.

Ograniczenie dostępu ze względu na nazwy stacji roboczych.

Wykonywane jest za pomocą kodu pakietu bezpieczeństwa osłony TCP autorstwa Wiatse Venema - być może znanego, niektórym administratorom Samby systemu Unix. Argumenty parametrów hosts allow oraz hosts deny mają format zbliżony do stosowanego w tym pakiecie.

Parametry ograniczające dostęp do hosta:

Nazwa	Typ	Domyślnie	Opis
hosts allow, allow hosts	łańcuch znaków	Brak: wszystkie hosty mają zapewniony dostęp do udziału.	Lista hostów, które mogą uzyskać dostęp do udziału.
hosts deny, deny hosts	łańcuch znaków	Brak: z hostów nie ma zabronionego dostępu do udziału.	Lista stacji roboczych, które maja dostęp do udziału, o ile nazwę hosta wymieniono w definicji parametru hosts allow. Lista hosts deny ma priorytet przed stacjami roboczymi wymienionymi na liście hosts allow.
use rhosts	logiczny	false	Jeżeli ten parametr ma wartość true, do określenia zaufanych hostów oraz użytkowników mogących uzyskać dostęp do udziału bez hasła można wykorzystać plik .rhosts w katalogu macierzystym użytkownika. Istnieje jednak ryzyko naruszenia bezpieczeństwa, ponieważ zakłada się, że użytkownik poda właściwą nazwę użytkownika. Parametr use rhosts ma charakter globalny i należy zdefiniować go w sekcji global pliku smb.conf.
hosts equiv	łańcuch znaków	Brak zaufanych hostów	Wartość tego parametru określa plik zawierający listę zaufanych hostów i użytkowników. Użytkownicy i hosty, których nazwy znajdują się w tym pliku będą mogli korzystać z udziału bez konieczności podawania hasła. Wykorzystanie tego parametru to poważne ryzyko naruszenia bezpieczeństwa, ponieważ zakłada się , że użytkownik poda właściwą nazwę. Jest to parametr globalny.

Hosty definiuje się według reguł:

• Jeśli wymienimy wiele hostów, możemy ich nazwy określać przecinkami albo spacjami.

• Hosta określamy przez nazwę lub przez jego adres IP

• Zakresy adresów IP mogą być definiowane za pomocą formatu sieć/maska sieci lub za pomocą częściowego adresu IP. Np.: poniższe zapisy oznaczają wszystkie hosty podsieci klasy C 10.1.1.0 oraz 10.1.2.0:

hosts allow = 10.1.1.0/255.255.255.0 10.1.2.

• Jeżeli system obsługuje grupy sieciowe NIS, grupy hostów mogą być określone za pomocą symbolu @.

• Słowo kluczowe ALL odpowiada wszystkim adresom IP

• Aby wykluczyć adresy z zakresu, można użyć słowa kluczowego EXCEPT.

Na przykład, aby umożliwić dostęp do wszystkich hostów w grupach sieciowych stacjerobocze i serwerów z wyjątkiem stacji roboczej stacjarobocza3 i stacjarobocza4 oraz wszystkich hostów w podsieci 10.1.2.0 należy zastosować następujące ustawienie:

hosts allow = @stacje_robocze @Serwery

hosts deny = stacjarobocza3 stacjarobocza4 10.0.1.0/255.255.255.0

Format pliku hosts equiv jest następujący:

• Nazwy hostów wpisywane są po jednej w wierszu. Wszyscy użytkownicy określonego hosta mogą się zalogować bez hasła.

• Po nazwie hosta można opcjonalnie wpisać nazwę użytkownika (oddzielając obie nazwy spacją). W ten sposób ograniczymy zbiór zaufanych tylko do wymienionego użytkownika.

• Można zdefiniować grupy sieciowe za pomocą symbolu @

• Zapisy można negować (co oznacza, że tacy użytkownicy nie są zaufani) poprzez wpisanie przed nazwą hosta znaku minus (-).

Przykład:

Za pomocą parametrów hosts allow oraz hosts deny można skonfigurować dwa rodzaje “polityki bezpieczeństwa” w stosunku do udziałów plików:

• polityka “w większości otwarte”, która polega na ustawieniu parametru hosts allow na wartość ALL i jawnym zabronieniu dostępu wybranym stacjom roboczym poprzez dodanie ich do listy hosts deny.

• polityka “w większości zamknięte”, która polega na zabronieniu dostępu wszystkim stacjom roboczym poprzez ustawienie parametru hosts deny na ALL i jawnym zezwoleniu na dostęp niektórym stacjom poprzez dodanie ich do listy hosts allow.

Ty zastosowanej polityki zależy od specyfiki naszego ośrodka. Polityka “w większości zamknięte” będzie właściwa dla sieci wykorzystujących w biznesie, gdzie na serwerach Samby przechowywane są informacje poufne. Polityka “w większości otwarte” wydaje się właściwsza w ośrodkach edukacyjnych.

Ograniczenie dostępu do udziału na podstawie nazw stacji roboczych:

[tymczasowe]

comment = miejsce na pliki tymczasowe

path = /tymcz

browseable = true

writeable = true

wide links = false

follow symlinks = false

quest account = nobody

quest only = true

hosts deny = ALL

hosts allow = stacjarobocza1, stacjarobocza2, stacjaroocza3

Ograniczenie dostępu na podstawie nazwy użytkownikami.

Ograniczenie dostępu na podstawie nazw użytkowników, a nie nazw stacji roboczych może okazać się łatwiejsze. Może to być konieczne szczególnie tam, gdzie użytkownicy nie korzystają z oddzielnych komputerów przez cały czas, ale często zmieniają miejsce pracy. Samba umożliwia takie skonfigurowanie udziału, aby był dostępny do czytania przez jedną grupę użytkowników oraz do pisania przez inną grupę użytkowników. Samba umożliwia także zezwolenie i zabranianie dostępu do udziału plikowego na podstawie nazwy użytkownika.

13. Odwzorowanie praw dostępu dla Uniksa

Ponieważ pliki w udziale plikowym Samby są przechowywane w uniksowym systemie plików i musi istnieć obsługa praw dostępu do plików. Samba posiada kilka parametrów, które dają administratorom pełną kontrolę nad prawami dostępu do plików przechowywanych w udziałach Samby.

Parametry ograniczenia dostępu na podstawie nazwy użytkownika:

Nazwa	Typ	Domyślnie	Opis
read list	łańcuch znaków	Pusty	Lista użytkowników, dla których określony jest udział tylko do odczytu. Można wprowadzić grupy użytkowników za pomocą prefiksu @ przed nazwą grupy w systemie Unix.
write list	łańcuch znaków	Pusty: status pisania jest zdefiniowany za pomocą parametrów read only oraz writeable	Lista użytkowników, którzy mają prawo do udziału plikowego. Jest to niezależne od ustawień parametrów read only oraz read list. Tak więc, użytkownik, który znajduje się na liście będzie miał prawo zapisu do plików w obrębie udziału. Za pomocą prefiksu @ można określać grupy użytkowników.
valid users	łańcuch znaków	Pusty: wszyscy użytkownicy mają dostęp do usługi	Lista użytkowników, którzy mają dostęp do udziału. Użytkownicy, których nie ma na liście mają zabroniony dostęp. Za pomocą prefiksu @ można określać grupy.
invalid users	łańcuch znaków	Pusty: wszyscy użytkownicy mają dostęp do usługi	Lista użytkowników, którzy maja dostęp zabroniony do udziału. Użytkownicy, których nie ma na liście maja prawo dostępu. Za pomocą prefiksu @ można określić grupy użytkowników. Jeżeli użytkownik jest zarówno na liście valid users i invalid users pierwszeństwo posiada lista invalid users. Tak więc użytkownik ten będzie miał zabroniony dostęp.

Aby włączyć funkcję odwzorowania nazw użytkowników, należy utworzyć plik zawierający informacje o nazwach użytkowników i wstawić parametr username map, tak aby wskazywał na ten plik w następujący sposób:

username map = /etc/username.map

Parametry dotyczące uprawnień dostępu w systemie Unix:

Nazwa	Typ	Domyślnie	Opis
create mask, create mode	łańcuch znaków	0744	Kiedy użytkownik tworzy plik w obrębie udziału, wartość ósemkowa tego parametru używana jest jako maska uniksowych praw dostępu do pliku. Dowolny bit praw nie ustawiony w masce create mask, nie będzie wyzerowany w prawach dostępu nowo utworzonego pliku. Domyślnie usuwane jest prawo pozostałych użytkowników i grupy do zapisu i wykonywania pliku.
directory mask, directory mode	łańcuch znaków	0755	Używane w podobny sposób jak parametr create mask, ale stosowane w odniesieniu do katalogów. Dowolny bit praw nie ustawiony w masce directory mask będzie wyzerowany w prawach dostępu do nowo utworzonego katalogu. Domyślnie usuwanie jest prawo innych grupy do zapisu w katalogu.
force create mode	łańcuch znaków	000	Pliki utworzone w obrębie udziału będą miały ustawione bity praw określone parametrem wyrażonym w postaci liczby ósemkowej. Parametr ten jest przydatny do zezwolenia użytkownikom udziału na dostęp do plików utworzonych przez innych.
force directory mode	łańcuch znaków	000	Katalogi utworzone w obrębie udziału będą miały ustawione bity praw określone parametrem wyrażonym w postaci liczby ósemkowej. Parametr ten jest przydatny w połączeniu z parametrem force create mode, do których dostęp ma mieć określona liczba użytkowników.
force user	łańcuch znaków	brak	Wymusza wykonywanie wszystkich operacji w obrębie udziału jako określona grupa w Uniksie w podobny sposób, jak w przypadku parametru force user.
username map	łańcuch znaków	pusty: nazwy użytkowników nie są odwzorowywane	Umożliwia serwerowi Samby odwzorowanie nazw użytkowników Windows i Unix. Jest to przydatne, jeżeli użytkownik chce uzyskać dostęp do katalogu macierzystego, a jego nazwy użytkowników stosowane w systemie Unix i Windows są różne.

Format informacji o nazwach użytkownikach to pojedyncza nazwa użytkownika, po której następuje znak równości, a następnie lista nazw użytkowników Windows i Unix. W pojedynczym wierszu może znajdować się tylko jeden zapis. Należy zwrócić uwagę na następujące zagadnienia związane z odwzorowywaniem nazw:

• Wiersze rozpoczynające się od znaku # lub ; są ignorowane

• Po prawej stronie można użyć znaku *, która oznacza wszystkich użytkowników

• Plik odwzorowania nazw jest przetwarzany wiersz po wierszu. Jeżeli użytkownik żądający dostępu do udziału odpowiada dowolnemu użytkownikowi po prawej stronie znaku równości, jest zmieniony przez użytkownika znajdującego się po lewej stronie. Przetwarzanie trwa, aż do osiągnięcia końca pliku lub do napotkania wiersza rozpoczynającego się od znaku wykrzyknika (!)

• Po prawej stronie mogą występować grupy systemu Unix - nazwy grup należy poprzedzić prefiksem @. Mogą występować także grupy NIS, jeżeli są obsługiwane. Grupa sieciowa Unix lub NIS jest uwzględniana w odwzorowywaniu nazw w przypadku, gdy użytkownik jest członkiem tej grupy

• Nazwy użytkowników Windows zawierające spacje mogą być wprowadzane poprzez ujęcie takiej nazwy w cudzysłów. Np.: nazwę Alicja Kowalska można odwzorować na uniksową nazwę alicja poprzez dodanie następującego wiersza do pliku odwzorowywania nazw:

alicja = “Alicja Kowalska”

• Liczba odwzorowań nazw użytkowników jest nieograniczona

Jednym z zastosowań tego mechanizmu jest odwzorowanie grupy użytkowników na pojedynczego użytkownika w celu ułatwienia współdzielenia plików w obrębie udziału plikowego Samby.

!projekt = alicja bogdan

gosc = *

Dla tego pliku odwzorowania nazwy użytkowników alicja oraz bogdan będą przekształcone na nazwę projekt. Gdyby w pierwszym wierszu nie było znaku !, nazwa każdego użytkownika uzyskującego połączenie do udziału zastałaby odwzorowana na użytkownika gosc.

Przykład:

Wyobraźmy sobie ośrodek www, który ma kilku administratorów, a każdy z nich jest odpowiedzialny za utrzymanie i dodawanie treści do stron ośrodka. Wszyscy administratorzy należą do grupy wwwgrp i istnieje w systemie Unix wspólna nazwa użytkownika wwwuser, który powinien być właścicielem wszystkich plików w ośrodku www.

Definicja Samby dla takiego ośrodka www jest pokazana poniżej:

[osrodekwww]

commnet = Ośrodek WWW

path = /opt/servers/www

browseable = true

writeable = true

force user = wwwuser

force group = wwwgp

valid users = @wwwgrp

Ta definicja udziału umożliwia dostęp do katalogu /opt/servers/www zawierającego strony ośrodka www. Wszyscy użytkownicy w grupie wwwgrp mają prawo dostępu i zapisu do udziału poprzez użycie nazwy użytkownika i hasła. Parametry force user i force group zdefiniowano po to, aby zabezpieczyć przed sytuacją, w której do plików utworzonych przez jednego użytkownika, inni użytkownicy nie mają prawa zapisu (popularny problem występujący w sytuacji, gdy grupa użytkowników systemu Unix korzysta z tego samego zbioru plików). Dzięki tym parametrom właścicielem wszystkich utworzonych plików jest użytkownik wwwuser.

14. Dostęp Samby z Windows 9x

Konfiguracja Windows 9x posiada wbudowaną obsługę stosu protokołów TCP/IP dlatego, aby korzystać z Samby za pośrednictwem systemu Windows 9x nie trzeba instalować żadnego dodatkowego oprogramowania. Należy jednak odpowiednio skonfigurować system.

Aby skonfigurować Windows 9x do pracy z Sambą, należy wykonać następujące czynności:

• Upewnić się, że zainstalowano sieć Microsoft Windows, że na pulpicie Windows 9x znajduje się ikona Otoczenie sieciowe. Jeżeli tak nie jest, poszukajmy w dokumentacji Windows 95 lub Windows 98 informacji o tym jak zainstalować sieć Microsoft Windows.

• Kliknąć prawym przyciskiem myszy ikonę Otoczenie sieciowe, co spowoduje wyświetlenie menu złożone z kilku pozycji. Należy wybrać ostatnią - Właściwości. Na ekranie pojawi się okno dialogowe Sieć.

• W oknie dialogowym Sieć należy wybrać zakładkę Identyfikacja i wypełnić pole Grupa robocza nazwą grupy roboczej, w której znajduje się serwer Samby. Przykładem może być:

Nazwa komputera: w95vmware

Grupa robocza: sambanet

Opis Komputera: System win95 pod Vmware

• W oknie dialogowym Sieć kliknąć Ok. Windows 95 wyświetli pytanie o to czy ponownie uruchomić komputer. Należy to zrobić. Po ponownym uruchomieniu komputera i zalogowaniu, będziemy gotowi do pracy z Sambą.

Jeżeli wszystko poszło dobrze, powinniśmy uzyskać dostęp do zasobów Samby.

Przeglądanie zasobów sieci

Po skonfigurowaniu systemu Windows 9x do pracy z Sambą powinno być możliwe przeglądanie sieci. Aby to zrobić, wystarczy dwukrotnie kliknąć na Otoczenie sieciowe.

Teraz wystarczy dwukrotnie kliknąć na ikonę dowolnego z wyświetlonych komputerów w oknie Otoczenie sieciowe, aby na ekranie pojawiła się lista udziałów udostępnionych przez ten serwer.

Dostęp do plików udostępnionych przez Sambę

System Windows 9x umożliwia dostęp do plików poprzez przeglądanie serwerów w sieci. Umożliwia to także większość aplikacji. Można również wykonać mapowanie dysków sieciowych na lokalne litery dysków. Aby to zrobić należy kliknąć prawym przyciskiem myszy na ikonę Mój komputer lub Otoczenie sieciowe na pulpicie z menu podręcznego wybrać polecenie Mapuj dysk sieciowy. Na ekranie pojawi się małe okno z nazwą dysku jaki będziemy mapować, ścieżką sieciową do dysku i opcję czy chcemy, by system podłączał go przy każdorazowym logowaniu.

Istnieją pewne przyjęte standardy w nadawaniu oznaczeń literowych dyskom sieciowym. Np.: litera H często przypisywana jest katalogom macierzystym (H jak Home). Można alternatywnie zastosować U - dysk użytkownika, S to często obszar wspólny ( S jak Shared).

15. Bibliografia:

Czasopisma:

Linux+

Linux-Magazine

PC Komputer

Chip

Książki:

Craig Hunt - „Serwery sieciowe Linuksa”

Strony WWW:

http://pl.wikipedia.org

http://linux.pl

http://7thguard.net

http://pld-linux.org

4

---