wasil.org

dnsmasq – serwer DNS i DHCP

Dnsmasq jest prostym serwerem udostępniającym usługi DNS i DHCP dla sieci lokalnej ( LAN ) i jak informują jego twórcy będzie się świetnie spisywał w sieciach domowych jak również niedużych środowiskach firmowych, do mniej więcej 1000 stacji roboczych. Więcej informacji o nim na stronie autora: http://www.thekelleys.org.uk/dnsmasq/doc.html

1. Ale po co?
   Dobre pytanie. Z reguły jeśli dorobiliśmy się już sieci lokalnej w domu, to poprzestajemy na poruszaniu się po niej albo za pomocą numerów IP komputerów albo za pomocą otoczenia lokalnego Windows i nazw stacji w grupie roboczej. To drugie jest dość wygodne, ale będzie działało tylko w sieciach z systemami operacyjnymi Windows, no może również z różnymi Unix’ami czy Linux’ami, ale to z kolei wymaga konfiguracji serwera Samba, co wychodzi poza zakres tego tekstu.
   Pomyślmy teraz jak pięknie by było gdyby zamiast numerów IP każdy komputer był rozpoznawany po swojej unikalnej nazwie, zupełnie jak na przykład strony internetowe. Dotyczyłoby to też drukarek sieciowych, routerów i innych urządzeń. To właśnie da nam dnsmasq. Pozwoli znajdywać za pomocą nazw wszystkie urządzenia sieciowe pobierające numery IP automatycznie poprzez DHCP lub dopisane statycznie do konfiguracji serwera. 

   Zamiast wpisywać szukając udziału sieciowego:

   \\192.168.0.4\udzial

   Wpiszemy:
   \\nasz_serwer.domena\udzial

   Łatwiej zapamiętać, prawda? Do tego jeśli się zmieni adres maszyny identyfikowanej jako „nasz_serwer” my nawet nie musimy tego wiedzieć, bo dnsmasq i tak nas do niego bezbłędnie pokieruje.

   Skoro już wiemy po co nam takie cudo… zaczynajmy! :)

2. Instalacja
   Instalacja zależy od środowiska, w którym pracujemy, ja skupię się na środowiskach Linux, a konkretnie na dwóch najpopularniejszych systemach Fedora ( jak również Red Hat, Centos ) oraz Debian ( Ubuntu i podobne ). Do instalacji będą potrzebne uprawnienia root’a. Można albo się zalogować jako root, albo dopisać przed każdym poleceniem podawanym poniżej: sudo
   na przykład: sudo yum update
    
   • Fedora
     należy wykonać polecenia:
     yum update ( na wszelki wypadek aktualizować pakiety w systemie )
     yum install dnsmasq 

   • Debian
     należy wykonać polecenia:
     aptitude update && aptitude safe-upgrade ( na wszelki wypadek aktualizować pakiety w systemie )
     aptitude install dnsmasq
     
3. Plik konfiguracyjny nazywa się dnsmasq.conf i znajduje się w katalogu /etc
   Dodatkowo dnsmasq korzysta z pliku /etc/hosts jako źródła informacji o hostach ze zdefiniowanymi stałymi adresami IP, to znaczy nie pobieranymi przez DHCP, oraz z pliku /etc/resolv.conf – stąd otrzymuje informacje na temat serwerów DNS, z których ma korzystać.
   Jest bardzo dobrze opisany za pomocą komentarzy, więc szczegółową instrukcję pominę, natomiast skupię się na kilku opcjach, które potrzebne są na początek. 
   • domain-needed – oznacza, że dnsmasq nie będzie przekazywał dalej zapytań nie posiadających domeny w adresie
   • bogus-priv – dnsmasq nie będzie przekazywał dalej adresów w nieroutowalnych zakresach adresowych
   • interface={eth0,eth1,…}  – jeśli mamy więcej niż jeden interfejs sieciowy to tutaj możemy powiedzieć dnsmasq, że ma nasłuchiwać jedynie na nim
   • except-interface={eth0,eth1,…} tak samo jak porzednio, ale dnsmasq ma nasłuchiwać na wszystkich interfejsach oprócz podanego
   • expand-hosts – ta zmienna mówi dnsmasq, że ma dodawać nazwę naszej domeny do nazw hostów i działa w połączeniu ze zmienną domain
   • domain - informacja o nazwie naszej domeny
   • dhcp-range=192.168.0.30,192.168.0.40,24h – aktywowanie serwera DHCP i ustawienie jego zakresu przydzielanych adresów na 192.168.0.30-40 i czasu lease ( wynajmu ) na 24 godziny. Jeśli mamy dwie podsieci ( vLAN lub dwie karty sieciowe ) to możemy zdefiniować tę zmienną dwukrotnie, pod warunkiem, że dnsmasq jest skonfigurowany do nasłuchiwania na obu interfejsach
   • dhcp-host=00:11:22:33:44:55,192.168.0.36 – definicja hosta, który przy każdym połączeniu ma posiadać ten sam numer IP. Identyfikacja hosta odbywa się za pomocą adresu sprzętowego jego karty sieciowej MAC. W naszym przypadku host o adresie MAC 00:11:22:33:44:55 będzie zawsze otrzymywał adres 192.168.0.36
4. Ustawienie tych wartości pozwoli nam rozpocząć używanie dnsmasq w naszej sieci i cieszenie się nazwami zamiast adresów IP.
5. Dodatkowe informacje
   • wpisy w /etc/hosts wyglądają następująco:
     adres_IP    nazwa_hosta
     na przykład:  192.168.0.21    serwer
   • wpisy w /etc/resolv.conf mają postać:
     nameserver   adres_IP
     na przykład: nameserver 194.204.152.34
   • w przypadku błędów dnsdomainname przy restarcie usługi dnsmasq należy sprawdzić plik /etc/hosts.
     Wpis dla 127.0.0.1 powinien zawierać oprócz localhost wpis nasz_serwer.nasza_domena, na przykład:
     127.0.0.1   localhost   serwer.domena.com
     Po tym może być potrzebny restart systemu lub usług sieciowych.
   • w przypadku Fedory i podobnych w /etc/sysconfig/network powinien się znajdować wpis:
     HOSTNAME=nasz_serwer.nasza_domena.com
   • aby hosty z adresami IP zdefiniowanymi statycznie również mogły korzystać z zalet dnsmasq należy zamienić ich dotychczasowe adresy serwerów DNS na adres IP naszego serwera, na którym jest zainstalowany dnsmasq.

Tags: Debian, Fedora, Linux

Samba i Windows 7

Windows 7 ma często kłopoty z połączeniem z udziałami Samby na serwerze z zainstalowanym Linux’em i nie pozwala nam się zalogować do udziału Samby ( lub np. mapować dysku sieciowego ).

Aby temu zaradzić należy ustawić dwie opcje ( jako użytkownik z uprawnieniami administratora ):

• Panel Sterowanie \ Narzędzia administracyjne \ Zasady Zabezpieczeń Lokalnych i następnie: Zasady Lokalne -> Opcje Zabezpieczeń -> Zabezpieczenia Sieci: poziom uwierzytelniania LAN Manager i opcja: Wyślij odpowiedzi LM i NTLM
• Panel Sterowanie \ Narzędzia administracyjne \ Zasady Zabezpieczeń Lokalnych i następnie: Zasady Lokalne -> Opcje Zabezpieczeń -> Zabezpieczenia Sieci:minimalne zabezpieczenie sesji dla klientów opartych na NTLM SSP i odznaczyć opcję: Wymagaj szyfrowania 128-bitowego
• Panel Sterowanie \ Narzędzia administracyjne \ Zasady Zabezpieczeń Lokalnych i następnie: Zasady Lokalne -> Opcje Zabezpieczeń -> Zabezpieczenia Sieci:minimalne zabezpieczenie sesji dla serwerów opartych na NTLM SSP i odznaczyć opcję: Wymagaj szyfrowania 128-bitowego

To powinno umożliwić pełną współpracę serwera Samba z systemem Windows 7

Mapowanie dysku sieciowego odbywa się przez adres: \\nazwa_serwera\nazwa_udzialu i następnie poprzez podanie nazwy użytkownika i hasła.

Jeśli jednak nadal nie działa to sprawdź czy wszystko masz ustawione wg. tego schematu:

Przypuśćmy, że mamy taki udział zdefiniowany w Sambie:


[nazwa_udzialu]
path = /sciezka/do/udzialu
comment = komentarz
available = yes
browseable = yes
public = no
writable = yes
valid users = samba-user
write list = samba-user
read list = samba-user


Użytkownicy systemu Windows 7 będą widzieli ten udział, ale nie będą mogli się z nim połączyć pomimo podawania hasła. W takiej sytuacji należy sprawdzić kilka zmiennych w pliku smb.conf:

1. czy jest ustawiona opcja uwierzytelniania poprzez użytkowników a nie udziały, tzn:
   security = user
   edit: powinno działać również jako security = share, ale polecam ten tryb tylko w przypadku chęci udostępniania udziału publicznego z dostępem dla wszystkich
2. czy jest ustawiona opcja dotycząca szyfrowania haseł:
   encrypt passwords = true
3. czy jest ustawiona opcja przechowywania danych o użytkownikach:
   passdb backend = tdbsam
   ( może być również opcja przechowywania tych danych w pliku /etc/samba/smbpasswd, ale jej nie polecam )
4. oraz czy ustawiona jest opcja synchronizacji haseł Samby z hasłami systemowymi:
   unix password sync = yes

Oczywiście ważne jest aby połączeń z serwerem Samba nie blokował ani firewall zainstalowany w tym serwerze ( np. iptables ) ani firewall w systemie Windows 7 ( wbudowany, lub oprogramowanie zewnętrzne ).

Dodawanie użytkowników do Samby jest proste, trzeba tylko pamiętać, że użytkownik Samba musi najpierw istnieć w systemie, ale jeśli ma dostęp tylko do udziałów samby to nie musi mieć swojego katalogu domowego ani dostępu do powłoki.

1. z poziomu powłoki systemowej ( jako root lub przez polecenia su/sudo ) należy wpisać:
   smbpasswd -a nazwa_użytkownika
   , a następnie podać ( i powtórzyć ) hasło, tylko należy pamiętać, aby było ono takie samo jak hasło tego użytkownika w systemie ( serwerze, na którym znajduje się Samba )
2. drugim krokiem jest aktywacja użytkownika w Sambie poprzez polecenie:
   smbpasswd -e nazwa_użytkownika
3. przeładowanie ustawień Samby przez polecenie:
   /etc/init.d/samba reload
   lub inne polecenie służące do zarządzania usługami systemowymi, np. service samba restart
4. usuwanie użytkowników odbywa się za pomocą polecenia:
   smbpasswd -x nazwa_użytkownika

Można zobaczyć listę użytkowników dodanych do Samby poprzez polecenie:
pdbedit -w -L
lub jeśli używamy pliku /etc/samba/smbpasswd – poprzez jego edycję/podgląd.

Tags: Debian, Linux, Samba, Windows 7

Instalacja Symfony Framework – Debian

Postanowiłem spróbować szczęścia z Symfony na moim serwerze z systemem Debian Linux, ale okazało się, że to nie jest takie proste. Stąd pomysł, żeby to opisać dla potomnych :)

Założenie: używam Symfony w wersji 1.2 oraz ORM Doctrine a nie Propel

1. najpierw trzeba ściągnąć cały framework ze strony Symfony na swój serwer ( lub tak do, którego masz dostęp z poziomu powłoki ), a następnie:

a) stwórz katalog z nazwą swojego projektu, a następnie w nim stwórz katalog lib/vendor, czyli:

mkdir -p NAZWA_PROJEKTU/lib/vendor

b) rozpakuj plik tgz za pomocą poleceń:

cd lib/vendor
tar zxpf symfony-1.2.9.tgz
mv symfony-1.2.9 symfony
rm symfony-1.2.9.tgz

2. teraz czas sprawdzić, czy mamy zainstalowane całe oprogramowanie wymagane przez Symfony:

cd ../..
php lib/vendor/symfony/data/bin/check_configuration.php

3. i tutaj zaczęły się problemy.

zmiany w php.ini to nie problem, ale trzeba pamiętać, że ( tak jak skrypt nas uprzedza ) plik php.ini, który jest sprawdzany przez skrypt może nie być tym samym plikiem, który „obsługuje” serwer WWW – u mnie właśnie tak było.

Większy problem pojawił się w momencie kiedy chciałem zająć się instalacją PDO, a dokładniej jak chciałem sobie poradzić z komunikatem o braku sterowników do rzeczonego PDO. Potrzebowałem sterownik do mysql, ale szukając przez aptitude nic nie udało mi się znaleźć w pakietach Debian’a. Wyjściem okazało się użycie systemu instalacji dodatków do PHP: pecl.

a) aby z niego skorzystać najpierw należy wykonać polecenie ( jako root ):


aptitude install php-pear

b) a potem zainstalować PDO wraz ze sterownikami do np mysql, lub innymi dostępnymi:

pecl install pdo
pecl install pdo_mysql
pecl install pdo_sqlite

c) potem pozostaje tylko dodanie odpowiednich wpisów do php.ini lub jak w moim przypadku do /etc/php5/pdo.ini:

extension=pdo.so
extension=pdo_mysql.so
extension=pdo_sqlite.so

d) i na koniec restart serwera WWW, np:

/etc/init.d/apache2 restart

To u mnie zadziałało bez problemu z wyjątkiem jednego błędu przy kompilacji pdo_mysql. W trakcie przeprowadzania sprawdzania przed kompilacją okazało się, że nie mam mysql_config i bez tego nie da rady przejść dalej. Aby to naprawić trzeba zainstalować jedną paczkę przez aptitude:

aptitude install libmysqlclient15-dev

i sprawa załatwiona.

Potem dopiero się dowiedziałem, że istnieje o wiele prostszy sposób na instalacje brakujących sterowników do PDO:

aptitude install php5-common php5-mysql php5-sqlite

a samo PDO jest zawarte w pakiecie php5-common

I to by było na tyle: Symfony jest zainstalowane i gotowe do stworzenia aplikacji w tym framework’u.

Tags: Debian, Linux, php, symfony