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

Zadania Cron wszystkich użytkowników

Czasem pojawia się potrzeba wyświetlenia zadań Cron wszystkich użytkowników w systemie.

for user in $(cut -f1 -d: /etc/passwd); do crontab  -u $user  -l; done

A dla konkretnego użytkownika można zastosować polecenie:

for user in $(cut -f1 -d: /etc/passwd | grep USER); do crontab  -u $user  -l; done

gdzie, USER = nazwa szukanego użytkownika

Tags: cron, Linux

Squid transparent proxy

Squid ( http://www.squid-cache.org ) jest oprogramowaniem umożliwiającym filtrowanie ruchu sieciowego, ale nie był to początkowy zamysł jego twórców. Z założenia Squid miał umożliwić tworzenie pamięci podręcznej treści ( grafik itp. ) pobieranych z Internetu przez użytkowników w czasie serfowania po nim.

Jedną z możliwości oferowanych przez Squid jest filtrowanie stron jakie moga odwiedzać użytkownicy znajdujący się w naszej sieci.

Więc po kolei :)

Zwyczajowo, to znaczy domyślnie, Squid korzysta z portu 3128, ale na nasze potrzeby to nie jest wystarczające. Dlaczego? Oznacza to, że jak już wszystko skonfigurujemy, ustawimy i będzie działało to i tak niewiele nam po tym, bo użytkownicy naszej sieci będą musieli dobrowolnie ustawić w swoich przeglądarkach ustawienia adresu naszego serwera Squid oraz portu. Przyznam szczerze, że jakoś nie widzę u nich zachwytu, kiedy zorientują się, że owocuje to niczym więcej poza ograniczeniami nałożonymi przez nas. I tutaj nadchodzi czas na wytłumaczenie drugiego słowa z tytułu niniejszego artykułu: transparent. Jest to magiczne słowo oznaczające „przezroczysty”. Co to oznacza dla nas? W największym uproszczeniu cały ruch sieciowy WWW zostanie domyślnie przekierowany tak, aby przechodził przez nasz serwer proxy Squid i to w dodatku bez potrzeby żadnej konfiguracji po stronie użytkowników, a co więcej – nie będą mogli nic na to poradzić :)

Oczywiście można ustawić proxy korzystając wyłącznie z domyślnego trybu Squid’a i wymusić na użytkownikach korzystanie z niego ( czyli przymus konfiguracji przeglądarki ) na zasadzie: nie skonfigurujesz – nie masz dostępu do stron WWW. Uważam, że takie rozwiązanie jest nieeleganckie i dużo bardziej kłopotliwe w praktyce. O wiele łatwiej sterować dostępem centralnie, na naszym serwerze, w konfiguracji Squid’a.

Po tym przydługim wstępie zabieramy się do pracy :)

1. Usługę Squid proxy stawiamy najlepiej na serwerze pełniącym rolę bramy ( ang. Gateway ) ale nie koniecznie. Na potrzeby tego artykułu przyjmę, że będzie ona zainstalowana właśnie na serwerze – bramie. Dodam, że

2. Instalacja odbywa się w sposób standardowy, z paczek binarnych właściwych dla naszej dystrybucji Linux’a lub ewentualnie ( czego osobiście nie praktykuję ) dla Windows’a. Instalacja opisana jest dokładnie tutaj i nie wchodzi w zakres tego artykułu, chyba, że zaistnieje taka potrzeba, żeby go o te informacje wzbogacić.

3. Konfiguracja usługi Squid odbywa się poprzez edycje pliku /etc/squid/squid.conf ( dla Debian’a, lub analogicznie w przypadku innych dystrybucji Linux’a ).

UWAGA: opcje są wczytywane po kolei od początku pliku konfiguracyjnego do końca!

Jest to ważne, ponieważ można się łatwo pogubić i doszukiwać przyczyny nie działania zdefiniowanych przez nas filtrów, ale to wyjdzie w praktyce.

Najpierw należy definiować zasady szczegółowe, a potem ogólne, ponieważ Squid bierze pod uwagę pierwszą regułę jaką napotka i nie szuka dalej, więc jeśli najpierw umieścimy pozwolenie na dostęp dla wszystkich, a potem zasady szczegółowe, to zostaną one zignorowane, ponieważ Squid „zadowoli” się regułką ogólną, którą napotkał wcześniej w pliku konfiguracyjnym.

4. Pierwszą rzeczą jaką należy ustawić jest kto z naszej sieci będzie miał dostęp do usługi Squid, czyli inaczej mówiąc czyj ruch będzie filtrowany i kto nie zostanie zablokowany całkowicie :)

acl moja_siec src X.X.X.0/24
http_access allow moja_siec

gdzie X.X.X.0/24 to nasza sieć, np. 10.0.1.0/24

Ten zapis pozwoli wszystkim komputerom w naszej sieci na korzystanie ze Squid’a. To nie do końca jest nasz cel, ponieważ na tym etapie konfiguracji wszystko będzie śmigało bez żadnych ograniczeń w tę i z powrotem bez żadnej kontroli.

5. Teraz pora na kilka ograniczeń :)

Najlepiej ustawiać ograniczenia za pomocą odpowiednich plików konfiguracyjnych z listami domen WWW, np:

domeny zabronione: /etc/squid/domeny_zabronione

domeny w tym pliku umieszczamy po jednej w każdej linijce.

w pliku konfiguracyjnym Squid przed ( czyli wyżej, jak kto woli ) poprzednimi wpisami definiującymi dostęp dla całej sieci, dodajemy linijki:

acl domeny_zabronione dstdomain -i "/etc/squid/domeny_zabronione"
http_access denydomeny_zabronione

to spowoduje, że żaden komputer w naszej sieci nie będzie mógł otworzyć stron zdefiniowanych w tym pliku.

6. A teraz troszkę dokładniejszej konfiguracji :)

Załóżmy, że mamy w sieci jakiś komputer, który ma mieć inne zasady dostępu do sieci niż pozostałe, np. nie móc wejść na konkretną stronę, powiedzmy www.strona1.com, wtedy jeszcze wcześniej niż poprzednia definicja należy dodać:

acl blokowany_komputer src X.X.X.21
 
acl lista_domen dstdomain -i "/etc/squid/lista_domen"
 
http_access deny blokowany_komputer lista_domen

a adres www.strona1.com umieścić w pliku /etc/squid/lista_domen

i już :)

przypominam jeszcze raz o kolejności wpisów w pliku konfiguracyjnym Squid’a.

7. Ostatnie szlify ( prawie )

Aby sprawić by Squid zachowywał się jako transparent, czyli przezroczysty należy dopisać jeszcze te opcje:

http_port 127.0.0.1:3128 transparent
http_port X.X.X.X:3128  transparent

gdzie X.X.X.X jest adresem naszego serwera, na którym zainstalowany jest Squid

8. Teraz już naprawdę ostatnie ustawienia :)

Pozostało ustawienie reguły iptables, tak aby kierowała cały ruch z portu 80 i 443, domyślnych dla stron WWW, na port 3128 Squid’a.

W moim przypadku trzeba skonfigurować ShoreWall, który zarządza regułami iptables:
w /etc/shorewall/rules

ACCEPT	$FW	net	tcp	www
REDIRECT	loc	3128	tcp	www

w przypadku zwykłego iptables:

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 3128
 
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 443 -j REDIRECT --to-port 3128

9. No i restart usługi: /etc/init.d/squid restart ( lub analogicznie dla innych dystrybucji )

Tags: iptables, Linux, squid

iptables i blokowanie stron WWW

Dzisiaj zajmiemy się kwestią czasem bardzo potrzebną, to znaczy blokowaniem użytkownikom sieci lokalnej dostępu do konkretnych serwisów internetowych. Chodzi o sytuację, kiedy chcemy zablokować możliwość „wchodzenia” tylko na niektóre strony a nie odwrotnie, to znaczy zezwolić tylko na niektóre, a zablokować domyślnie wszystkie.

Dodatkowym założeniem naszego projektu będzie to, że ruch zostanie przekierowany i użytkownik zamiast trafić na stronę typu chomikuj.pl trafi na inną, zdefiniowaną przez nas, np. google.pl lub naszą stronę firmową.

Można to osiągnąć za pomocą tablicy PREROUTING w iptables:

iptables -t nat -A PREROUTING -p tcp -s JAKAŚ_SIEĆ_LOKALNA \
-d ADRES_DOCELOWY --dport 80 -j DNAT --to ADRES_PRZEKIEROWANIA:80

i teraz tak:

JAKAŚ_SIEĆ_LOKALNA – nasza siec lokalna, np. 192.168.1.0/24
ADRES_DOCELOWY – adres IP strony, na która chce wejść użytkownik
ADRES_PRZEKIEROWANIA – adres IP, na jaki dostanie się użytkownik w wyniku działania naszej regułki

Wszystko pięknie i w ogóle, ale jak to zrobić jeśli adres, np rapidshare.com ma więcej niż jeden adres IP? tutaj z pomocą przychodzi BASH i skrypt w nim napisany, który wykonuje 2 rzeczy:

1. zamienia adres domeny ( taki słowny ) na adres IP ( lub więcej adresów, jeśli takowe występują ). Czyni tę magię za pomocą polecenia host -t a NAZWA_DOMENY oraz pętli FOR
2. dla każdego odnalezionego adresu stosuje regułkę, którą opisałem wcześniej, również za pomocą pętli FOR

Żeby Was nie męczyć postanowiłem taki skrypt w BASH’u przygotować. Nie jest może perfekcyjny, ale z pewnością spełnia swoje przeznaczenie i jest wygodny w użyciu :) ( dla chętnych skrypt można ściągnąć tutaj ). Skrypt zamieszczam do wglądu poniżej, ale radzę nie kopiować ( albo robić to rozważnie), ponieważ mogą powstać nieścisłości wynikające z operacji kopiuj/wklej…

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64

#!/bin/bash
 
TRYB=$1
 
#zmienne skryptu
SIEC="192.168.1.0/24" #siec lokalna, ktora ma nie meic dostepu do nizej wymienionych stron
PORT="80"
#port 80 = WWW
 
PRZEKIEROWANIE_NA="209.85.135.147" #ustawilem domyslne przekierowanie na strone Google
PORT_NA="80" #jak wyzej
LISTA_STRON="chomikuj.pl wrzuta.pl rapidshare.com megaupload.com" #lista oddzielona spacjami
 
#domyslnie nie sa wyswietlane reguly w czasie dzialania programu
VERBOSE="0"
 
if [ -n $2 ]; then
VERBOSE=$2
fi
 
case $TRYB in
"on")
if [ -n "$LISTA_STRON" ]; then
for STRONY in ${LISTA_STRON}; do
if [ "$VERBOSE" = "1" ]; then
echo $STRONY
fi
ADRESY=$(host -t a $STRONY | awk '{ printf "%s ", $4 }')
 
if [ -n "$ADRESY" ]; then
for STRONY_IP in ${ADRESY}; do
if [ "$VERBOSE" = "1" ]; then
echo "iptables -t nat -A PREROUTING -p tcp -s $SIEC -d $STRONY_IP --dport $PORT -j DNAT --to $PRZEKIEROWANIE_NA:$PORT_NA"
fi
iptables -t nat -A PREROUTING -p tcp -s $SIEC -d $STRONY_IP --dport $PORT -j DNAT --to $PRZEKIEROWANIE_NA:$PORT_NA
done
fi
if [ "$VERBOSE" = "1" ]; then
echo ""
fi
done
fi
;;
"info")
iptables --list PREROUTING -t nat
;;
"off")
iptables --flush PREROUTING -t nat
;;
"-h")
echo "Program przyjmuje zmienne: "
echo "-h pomoc"
echo "on wlaczenie regul"
echo "off wylaczenie regul"
echo "info informacje o regulach"
echo "0/1 w trybie 'on' ukrywanie/wyswietlanie komunikatow"
echo "usage: ./blokowanie_stron on 1"
;;
 
*)
echo "Nie podano zmiennej trybu. (on/off/info)"
exit
;;
esac

Tags: iptables, Linux, strony www

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