GitLab quick installation script – Fedora 16
I've managed to prepare Fedora 16 easy installation scripts for GitLab. Use them as root user. Download 2 scripts from bottom of this post and save them on your Linux server.
first, run this script:
gitlab_unattended_install_start.sh
execute these commands:
cd /var/www/gitlabhq source /etc/profile.d/rvm.sh rvm all do rake db:setup rvm all do rake db:seed_fu
to finish, fire up this script, and you're done :)
gitlab_unattended_install_finish.sh
scripts download
gitlab_unattended_install_start.sh
gitlab_unattended_install_finish.sh
GitLab installation on Fedora 16 (with gitolite)
GitLab is a wonderful piece of software made by these guys and I'd like to try and install it on Fedora 16 system, as it is most recent Fedora OS at the time I am writnig this. I will base my tutorial on on found here by Déja. Also on my way to successful install I've stumbled upon this description, so I might have gain some experience from it too.
GitLab is Ruby on Rails application and it takes some experience to get it all working because of many, many, many dependencies and packages it needs. It's nothing like simple PHP on Apache installation. But it works and it's worth it, I assure you :)
Let's begin! (by the way: I perform all as root user - again: test environment)
small edit: For people who only want this to work and not necessarily wish to know how and why, I have prepared easy installation scripts in here
another EDIT: GitLab is under heavy development and now it's stable version is 2.1. This means that my guide might be not entirely accurate. Please be cautious. I'll update it soon.
- First of all: I am working on virtual machine with brand new and fresh Fedora 16 installed. Minimal installation, just to make sure nothing messes with GitLab. Consider this a test environment.
- Once you have your OS ready, update it with yum update and also install some packages you will need on the way:
yum install make openssh-clients gcc libxml2 libxml2-devel \ libxslt libxslt-devel python-devel
- Check what version of ruby is available via yum. GitLab needs at least version 1.9.2
yum info ruby
on mine it says that the only available version for me is 1.8.7.35 so I have to get it somewhere else.
- Method #1.
I will do as it says here. I have tried it before and it works flawlessly. With one or two catches of course ;)Mentioned catches and tips:- you need wget, if you don't have it already use
yum install -y wget
- other needed packages (plus few dependencies) can be obtained by typing:
yum install -y readline-devel ncurses-devel gdbm-devel \ glibc-devel tcl-devel openssl-devel db4-devel byacc
- if you are using virtual machine, like me, you can first make a snapshot of it, then build ruby RPM package, copy it to you host machine (or network share or whatever place outside virtual machine) and then go back in time to you snapshot. Voila! Clean system ready for further installing GitLab. All you need to do is install earlier created ruby RPM. Anyway this is what I'm gonna do today. Keep it clean.
- last step - your RPM will end up somewhere in ~/rpmbuilds/RPMS directory. It will reside in folder named after your system architecture, in my case: i386
And here is how:
yum install -y rpm-build rpmdevtools rpmdev-setuptree cd ~/rpmbuild/SOURCES wget http://ftp.ruby-lang.org/pub/ruby/1.9/ruby-1.9.2-p290.tar.gz cd ~/rpmbuild/SPECS curl https://raw.github.com/imeyer/ruby-1.9.2-rpm/master/ruby19.spec > ruby19.spec rpmbuild -bb ruby19.spec rpm -Uvh ~/rpmbuild/RPMS/x86_64/ruby-1.9.2p290-2.ruby-1.9.2p290-2.i386.rpm
I took my VM about 4 minutes to compile and prepare RPM. Not so bad.
Now I go back in time in my VM and install newly created RPM withrpm -Uvh ruby-1.9.2p290-2.fc16.i386.rpm
- you need wget, if you don't have it already use
- Method #2. ( I prefer this one so far)
EDIT: I have switched to ruby 1.9.3p0 - it works and starts a lot faster, you can use it instead of 1.9.2-p290 in this guide.
I will use RVM, which stands for Ruby Version Manager - brilliant tool, which you can use to install and manage your Ruby with ease. Let's check it out, shall we?
sudo bash -s stable < <(curl -sk https://raw.github.com/wayneeseguin/rvm/master/binscripts/rvm-installer) source /etc/profile.d/rvm.sh rvm install ruby-1.9.2-p290 rvm use ruby-1.9.2-p290 --default
Done. Just like that we have operational Ruby 1.9.2-p290. No RPMs, bo going back in time.. nice, huh? :)
- Good. Small (nice) surprise: our RPM installed ruby gems for us, so now we only have to get rails gem.
first, just to make sure everything is up to date, execute:gem update --system
now install rails with:
gem install rails
- Now we will install apache2 as a webserver and Passenger for ruby apps deployment. I know that most GitLab tutorials use nginx but I really like apache ;)
yum install -y httpd
gem install passenger
as I mentioned: I use apache, so I will need passenger module for it:
first some required packages:yum install gcc-c++ curl-devel openssl-devel zlib-devel \ httpd-devel apr-devel apr-util-devel
an then use
passenger-install-apache2-module
in order to install it.it gives you 2 information on how to proceed with apache configuration:
- add following lines to /etc/httpd/conf/httpd.conf (at the very end):
LoadModule passenger_module /usr/lib/ruby/gems/1.9.1/gems/passenger-3.0.11/ext/apache2/mod_passenger.so PassengerRoot /usr/lib/ruby/gems/1.9.1/gems/passenger-3.0.11 PassengerRuby /usr/bin/ruby
- and then create file named default.conf (or gitlab.conf, or something other you fancy) in /etc/httpd/conf.d/ containing these lines (remember to change to fit your environment):
<VirtualHost *:80> ServerName www.yourhost.com DocumentRoot /somewhere/public <Directory /somewhere/public> AllowOverride all Options -MultiViews </Directory> </VirtualHost>
(don't worry, we'll come back to this one later)
- add following lines to /etc/httpd/conf/httpd.conf (at the very end):
- Now it is time for gitolite. I won't use gitosis because it is not actively developed any more and I found that new GitLab works better with gitolite.install it with
yum install -y gitolite
now, wasn't that quick? :)
- Now we will need to create new gitolite server configuration and in order to do that we have to generate SSH key-pair. But first things first.
To get us started su into gitolite user withsu - gitolite
now try to log into localhost via SSH -> it's small thing which will make our life easier in the future.
ssh localhost
Just make it add localhost to list of known host - no need to actually authenticate. SSH created for us ~/.ssh directory. That's nice.SSH key generation is as easy as:
ssh-keygen -t rsa
use default path for saving key-pair (/var/lib/gitolite/.ssh/id_rsa) and no paraphrase. Test environment. Just a reminder.as for initialization of gitolite repository:
gl-setup .ssh/id_rsa.pub
next hit ENTER and edit will open, change value of
$REPO_UMASK to 0007
as mentioned hereLook like we are done here. Exit gitolite user shell and return to being almighty root himself ;)
- OK, time for next requirements: python Pip, I will go with method from original post and NOT use yum for that.
curl http://python-distribute.org/distribute_setup.py | python
and then
easy_install pip
- Database. We need it. We have it already - it was installed on the way as a dependency. Just to make sure check if you have SQLite at list version 3.6 with:
yum info sqlite
I have 3.7.7.1. All we need is SQLite development package, get it with:
yum install sqlite-devel
-
And now the main event! GitLabHQ!
I like install web apps in /var/www so we will go there and git clone GitLab:
cd /var/www git clone git://github.com/gitlabhq/gitlabhq.git cd gitlabhq/
we need to use pip to install some python dependencies:
pip install pygments
and bundler gem so it can later on do most of the work for us:
gem install bundler
finally (remember to be in GitLab directory):
bundle install
(go get yourself a coffee or other treat - it takes w while)
- DB setup:
EDIT: For GitLab version 2.1 install Redis - without it rake will fail.:
yum install redis libicu-devel service redis start
And now database setup and import:
RAILS_ENV=production rake db:setup RAILS_ENV=production rake db:seed_fu
TIP: if you get errors here, check if you don't have 2 versions of rake installed (I had somehow): 0.8.7 and 0.9.2. If you do, remove older with:
gem uninstall rake
and choose appropriate version. If you still have problems try:
gem install rake
-> don't know why, but if it installs again same version of rake, it works.
- Apache virtual host configuration should look something like this (I told you, we will get back to that):file: /etc/httpd/conf.d/gitlab.conf
<VirtualHost *:80> ServerName www.yourhost.com DocumentRoot /var/www/gitlabhq/public <Directory /var/www/gitlabhq/public> AllowOverride all Options -MultiViews </Directory> </VirtualHost>
- set correct settings in /var/www/gitlabhq/config/gitlab.yml
in my case:# Git Hosting configuration
git_host: system: gitolite admin_uri: gitolite@localhost:gitolite-admin base_path: /var/lib/gitolite/repositories/ host: localhost git_user: gitolite # port: 22
- enable apache user, co you can su into this account:
usermod -s /bin/bash -d /var/www/ apache
also give him permissions to his own home directory with:
chown -R apache:apache /var/www/
(I know this kinda overrides last chown command...)
- do:
su - apache && ssh localhost
(same thing as in step 8. with know_hosts file. )
exit apache's shell and as root copy id_rsa private key from /var/lib/gitolite/.ssh/ to /var/www/.ssh/ and make apache it's owner with:cp -f /var/lib/gitolite/.ssh/id_rsa /var/www/.ssh/ \ && chown apache:apache /var/www/.ssh/id_rsa \ && chmod 600 /var/www/.ssh/id_rsa
- add apache user to gitolite group with:
usermod -a -G gitolite apache
- check if repositories directory has correct permissions, it should be 770. You can set it with
chmod 770 /var/lib/gitolite/repositories/
- double check your firewall (for example iptables) if it allows connections on port 80 to your server.
- start apache server with:
service httpd start
- Now it all should work. Fingers crossed.. go to http://www.yourhost.com
- Now you should be able to log in using these credentials:
user: admin@local.host
pass: 5iveL!feand you're in :)
It wasn't so hard, wasn't it? ;)
Troubleshooting:
- I get error 500 when I enter particular project and try to get into it's "Admin" section. Don't know how to fix it yet.To fix it, check if repositories directory has correct permissions, it should be 770. You can set it with
chmod 770 /var/lib/gitolite/repositories/
- If Passenger insists, that we don't have or he can't see grit library (gem actually, as far as I know) even though we have it.
https://github.com/gitlabhq/grit.git (at master) is not checked out. Please run `bundle install` (Bundler::GitError)
I didn't have gem grit installed, do:
gem install grit
also it won't hurt to update all gems with:
gem update
Only resolution to this problem I have found is to run bundle again as a user who runs apache server: apache.Su into apache account with
su - apache
and try:
gem install grit
you'll get error:
You don't have write permissions into the /usr/lib/ruby/gems/1.9.1 directory.
As root change it's ownership to apache user with:
chown apache:root -R /usr/lib/ruby/gems
I know that is not great resolution but it worked for me. If you'll happen to know better way - please let me know, so I can update this tutorial and my knowledge of course ;)
Edit
I found another solution (instead of changing permissions): after first
bundle install
edit Gemfile and in lines containing "git:" remove everything after first comma, for example:
gem "grit", :git => "https://github.com/gitlabhq/grit.git"
should be
gem "grit"
then do again
bundle install
and now passenger shouldn't complain any more.
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
- 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! :)
- 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
- Fedora
- 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
- Ustawienie tych wartości pozwoli nam rozpocząć używanie dnsmasq w naszej sieci i cieszenie się nazwami zamiast adresów IP.
- 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.
- wpisy w /etc/hosts wyglądają następująco:
Konwersja statycznej strony HTML do WordPress
Coraz częściej pojawia się potrzeba konwersji działającej, statycznej strony napisanej w czystym HTML'u lub za pomocą prostych skryptów PHP, do postaci bardziej skomplikowanej, ale dającej dużo większe możliwości. Mam tutaj na myśli systemy CMS ( Content Management System ). Opiszę taką konwersję na przykładzie WordPress'a.
- Wstęp
Typowa statyczna strona jest napisana w HTML'u. Czasem nie jest do końca statyczna, bo ma powklejane tu i tam fragmenty kodu PHP lub JavaScript. Na potrzeby tego tutoriala przyjmę jednak, że mamy do czynienia ze stroną stworzoną za pomocą jedynie HTML'a.
Taka strona składa się najczęściej z mniej więcej takiej struktury plików, która składa się na całość, którą od tej pory będę w skrócie nazywał template'em:- index.html
- style.css
- katalog z grafiką, np.: img
Plik index.html zawiera całą treść strony, wszystkie tagi HTML oraz odniesienia do lokalizacji pliku z kaskadowymi stylami ( style.css ) oraz lokalizacją grafik. To on jest dla nas najbardziej interesujący i w nim będzie się działa cała "magia" :)
- Dla ułatwienia i lepszej wizualizacji konwersji od tej pory będę przedstawiał całą operację na konkretnym przykładzie. Proponuję użycie jako wyjściowego template'a któregoś z dostępnych na stronie Open Source Web Design ( www.oswd.org ) na przykład: LoadFoO [V2]
- Po ściągnięciu i rozpakowaniu tego template'a widać takie pliki i katalogi:
- css ( katalog zawierający plik style.css - definicję stylów kaskadowych )
- img ( katalog zawierający pliki graficzne )
- js ( katalog zawierający pliki JavaScripts )
- favicon.ico ( plik z ikoną naszej strony pokazującą się w przeglądarce )
- index.html ( szkielet template'u, tak jak opisywałem wcześniej )
- CSS
Konwencja struktury plików dla template'ów w Worpdress wymaga, aby plik style.css znajdował się w głównym katalogu, tzn tam gdzie index.html , więc przenieśmy go teraz z katalogu css o jeden poziom wyżej. Pusty obecnie katalog css można usunąć, żeby nie zaśmiecał przestrzeni.Plik style.css jest jednocześnie opisem template'a, a konkretnie jego nagłówek, który wygląda np tak:
/* Theme Name: nazwa_template'a Theme URI: ścieżka URI Description: Opis Version: wersja, np: 1.0 Author: twoje_imię Author URI: twój adres WWW */Umieść ten nagłówek przed wszystkimi definicjami stylów w style.css.
W naszym przypadku pamiętaj o zmianie ścieżek w pliku css, aby wskazywały na katalog img. Teraz jest to na przykład: ../img/jakis_plik.jpg trzeba je wszystkie zmienić na img/jakis_plik.jpg ( przez usunięcie ../ )
- Opcjonalnie, ale zalecałbym to, można stworzyć obraz - miniaturę template'a. Powinien mieć rozmiar 300x225 pikseli oraz format PNG. Nazwa musi brzmieć: screenshot.png i musi byc umieszczony tam gdzie plik style.css.
- Cięcie/Gięcie
Głównym plikiem naszego template'a jest index.php, ale skąd go wziąć? Zmienić rozszerzenie pliku index.html na php
To jednak nie wystarczy. Trzeba go teraz odrobinę pociąć na kawałki, w najprostszym wypadku będą to pliki:
header.php - plik zawierający definicje nagłówka strony
footer.php - plik zawierający stopkę strony
my dodamy jeszcze sidebar.phpNazwy tych plików są ważne, ponieważ dzięki temu WordPress sam znajdzie te pliki, bez potrzeby ich definiowania. W kolejnych punktach opiszę każdy z nich.
Plik index.php zawiera jeszcze definicje tak zwanego "loop" czyli takiej "karuzeli", która pokazuje odpowiednie posty/wpisy na stronie głównej. O tym również później.
- header.php
Najpierw przykładowy plik header.php:<html <?php language_attributes(); ?>> <head> <meta charset="<?php bloginfo( 'charset' ); ?>" /> <title><?phpglobal $page, $paged; wp_title( '|', true, 'right' ); bloginfo( 'name' ); $site_description = get_bloginfo( 'description', 'display' ); if ( $site_description && ( is_home() || is_front_page() ) ) echo " | $site_description"; if ( $paged >= 2 || $page >= 2 ) echo ' | ' . sprintf( __( 'Page %s', 'twentyten' ), max( $paged, $page ) ); ?></title> <link rel="profile" href="http://gmpg.org/xfn/11" /> <link rel="stylesheet" type="text/css" media="all" href="<?php bloginfo( 'stylesheet_url' ); ?>" /> <link rel="pingback" href="<?php bloginfo( 'pingback_url' ); ?>" /> <?php if ( is_singular() && get_option( 'thread_comments' ) ) wp_enqueue_script( 'comment-reply' ); wp_head(); ?> </head> <body <?php body_class(); ?>>
Jest on pełny znaczników w języku PHP, które rozpoznaje WordPress po czym wypełnia je zawartością dynamiczną, np:
opisuje lokalizację pliku style.css ( nie definiujemy nazwy, bo jest on domyślny dla WordPress'a )
wp_head(); powoduje wyświetlenie nagłówka HTML na stronie
pozostałe zmienne są w większości przypadków dość jasno opisane przez swoje nazwy. - footer.php
Przykładowa zawartość pliku footer.php:<div id="foot"> </div> </div> <?php wp_footer(); ?> </body> </html>
Zawiera on przeważnie definicję stopki zawartej jako jakiś element
oraz wywołanie PHP: wp_footer(); - zawiera ono w sobie zmienne potrzebne przez wiele wtyczek WordPress'a, głównie odnoszące się do kodu JavaScript.
- sidebar.php
W nim umieścimy zawartość prawej kolumny naszego template'a, czyli w naszym przypadku trzeba wyciąć następujący kod z index.php i wkleić do sidebar.php:<ul id="nav"> <li><a href="#Home">Home</a></li> <li><a href="#Archive">Archive</a></li> <li><a href="#Link">Links</a></li> <li><a href="#download">Download</a></li> <li><a href="#support">Support</a></li> <li><a href="#contact">Contact</a></li> </ul> <div> <h2 style="margin-top:17px">Recent Entries</h2> <ul> <li><a href="#">Recent Entries1</a> <i>01 Des 06</i></li> <li><a href="#">Recent Entries2</a> <i>01 Des 06</i></li> <li><a href="#">Recent Entries3</a> <i>01 Des 06</i></li> <li><a href="#">Recent Entries4</a> <i>01 Des 06</i></li> <li><a href="#">Recent Entries5</a> <i>01 Des 06</i></li> </ul> </div>
- index.php
I znowu wracamy do głównego pliku naszego template'a: index.php. Zawiera on w sobie całą resztę kodu naszej strony, oczywiście po wycięciu z niego tych fragmentów, które zawarte są w pozostałych plikach PHP.Nagłówek będzie zdefiniowany w header.php, a więc z index.php można usunąć wszystko od samej góry do znacznika
z nim włącznie. Zamiast tego co wytniemy trzeba wstawić:<?php get_header(); ?>
Kod prawej kolumny już przenieśliśmy do sidebar.php, teraz jest puste miejsce pomiędzy
<div id="right"> i </div>
. Trzeba je wypełnić kodem PHP wordpress:
<?php get_sidebar(); ?>
Stopkę strony utworzymy poprzez usunięcie wszystkiego poczynając od
<div id="foot">
do końca i zastąpienie przez:
<?php get_footer(); ?>
Teraz po otworzeniu panelu sterowania naszej strony WordPress i wejściu w menu Motywy zobaczymy nowy motyw o nazwie jaką mu nadaliśmy, po jego aktywacji zobaczymy nowy template w akcji. Na razie jednak nie wszystko działa tak jak powinno. Na przykład menu, o tym za chwilę.
- Menu stron.
W pliku index.php zmień kod pomiędzy:<div id="menu"><ul> i </ul></div>
na kod PHP WordPress:
<?php wp_list_pages('sort_column=menu_order&title_li='); ?>
W tym przypadku dodałem zmienną sort_column=menu_order aby menu korzystało z kolejności jaką mu narzucimy w panelu sterowania oraz title_li= ( puste), ponieważ nie chcemy aby pokazywał się tytuł "Menu Główne".
Po odświeżeniu strony zobaczymy już Główne menu zawierające pozycje zdefiniowane przez nas w panelu administracyjnym. Reszta na razie nie jest jeszcze aktywna.
- Dodatkowe menu w panelu bocznym.
Dodanie drugiego menu pozwoli na stworzenie drugiego menu, zawierającego inne elementy niż głowne. Najpierw należy stworzyć plik functions.php o zawartości:<?php add_theme_support( 'menus' ); ?>
co doda pozycję "Menu" w dziale "Wygląd" w panelu administracyjnym, w którym to miejscu będzie można zdefiniować i dodać kolejne menu do naszej strony.
W sidebar.php zamień kod:
<li><a href="#Home">Home</a></li> <li><a href="#Archive">Archive</a></li> <li><a href="#Link">Links</a></li> <li><a href="#download">Download</a></li> <li><a href="#support">Support</a></li> <li><a href="#contact">Contact</a></li>
na:
<?php wp_nav_menu( array( 'sort_column' => 'menu_order') ); ?>
gdzie sort_column wymusza kolejność w menu taką jak w panelu administracyjnym.
Dodatkowo, żeby wszystko się tak samo wyświetlało dodaj do style.css następującą linijkę:
#nav ul {list-style-type:none;list-style-image:none;}
gdzieś w okolicy definicji #nav
Po dodaniu elementów z poziomu panelu pojawią się one w wybranym przez nas miejscu w panelu bocznym.
- Panel boczny po raz drugi: box
W dolnej części panelu bocznego znajduje się box zawierający linki do ostatnich wpisów, aby go zrealizować dynamicznie zamień kod:<div class="box"> <h2 style="margin-top:17px">Recent Entries</h2> <ul> <li><a href="#">Recent Entries1</a> <i>01 Des 06</i></li> <li><a href="#">Recent Entries2</a> <i>01 Des 06</i></li> <li><a href="#">Recent Entries3</a> <i>01 Des 06</i></li> <li><a href="#">Recent Entries4</a> <i>01 Des 06</i></li> <li><a href="#">Recent Entries5</a> <i>01 Des 06</i></li> </ul> </div>
na:
<div class="box"> <h2 style="margin-top:17px">Recent Entries</h2> <ul> <?php global $post; $args = array( 'numberposts' => 5, 'offset'=> 0, 'orderby'=>'post_date'); $myposts = get_posts( $args ); foreach( $myposts as $post ) : setup_postdata($post); ?> <li><a href="<?php the_permalink(); ?>"><?php the_title(); ?> </a> <i> <?php the_date(); ?></i></li> <?php endforeach; ?> </ul> </div>
To spowoduje wyświetlenie linków do 5-ciu ostatnich postów, w kolejności chronologicznej ich publikacji.
- Loop
Jest to taka karuzela, czyli sposób w jaki wyświetlane są posty na głównej stronie, jeśli nie jest ona statyczna.
Przykładowy kod, jaki użyję w tym template'cie:
zamiast:<div id="left"> <h2>Welcome to LoadFoO [V1]</h2> <p>Text Content Text <a href="#">Content Text</a> Content Text Content Text Content Text Content Text Content Text Content Text Content Text Content Text Content Text Content Text Content Text Content Text Content Text Content Text Content Text Content Text Content Text Content Text Content Text Content.</p> <ul> <li>ul-li test.</li> <li>ul-li test.</li> <li>ul-li test.</li> <li>ul-li test.</li> <li>ul-li test.</li> </ul> <h2>Functionality or performance</h2> <p>Text Content Text Content Text Content Text Content Text Content Text Content Text Content Text Content Text Content Text Content Text Content Text Content Text Content Text Content Text Content Text Content Text Content Text Content Text Content Text Content Text Content Text Content. </p> </div>
użyj:
<div id="left"> <?php if ( have_posts() ) : while ( have_posts() ) : the_post(); ?> <h2><a href="<?php the_permalink() ?>" rel="bookmark" title="Permanent Link to <?php the_title_attribute(); ?>"><?php the_title(); ?></a></h2> <p> <?php the_content(); ?></p> <?php endwhile; else: ?> <p>Brak postów.</p> <?php endif; ?> </div>
- Szablon wpisu
Musimy jeszcze zdefiniować szablon wpisu ( Post ), a robi się to w pliku: - Drobne poprawki.
a) W przypadku tego tematu postanowiłem usunąć kod odpowiadający za powiększanie/pomniejszanie tekstu:<div style="float: right;"><a href="javascript:ts('body',1)">[+]</a> | <a href="javascript:ts('body',-1)">[-]</a></div>b) dodanie tytułu strony w górnej części poprzez zamianę w index.php:
LoadFoO [V2]
na:
<?php bloginfo( 'name' ); ?>
c) mała zmiana w style.css aby nagłówki wpisów wyglądały tak jak w oryginale:
dodaj:
h2 a {color: #9F9F9F; text-decoration: none; }
To by było na tyle, no przynajmniej na początek. Teraz cały dalszy rozwój i życie template'a zależy od Ciebie drogi czytelniku :)
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
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 )
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:
- 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
- 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 |
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 Manageri 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 SSPi 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 SSPi 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:
- czy jest ustawiona opcja uwierzytelniania poprzez użytkowników a nie udziały, tzn:
security = user
edit: powinno działać również jakosecurity = share, ale polecam ten tryb tylko w przypadku chęci udostępniania udziału publicznego z dostępem dla wszystkich - czy jest ustawiona opcja dotycząca szyfrowania haseł:
encrypt passwords = true - 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 ) - 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.
- z poziomu powłoki systemowej ( jako
rootlub przez poleceniasu/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 ) - drugim krokiem jest aktywacja użytkownika w Sambie poprzez polecenie:
smbpasswd -e nazwa_użytkownika - 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 - 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.
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.