Mijający już weekend upłynął mi pod znakiem migracji serwera www.poema.art.pl na FastCgi. Sporo alternatyw, sporo, ale niepełnych informacji - trudno się w tym połapać komuś, kto nie jest zaznajomiony z tą technologią. Ale od początku. Dlaczego warto się przerzucić  na FastCgi? Otóż powody są co najmniej dwa:

1. wydajność
2. bezpieczeństwo

Rozwinięcie wątku wydajności należałoby zacząć od wyjaśnienia w jaki sposób FastCgi działa. Otóż dzięki FastCgi separujemy wykonanie kodu PHP od wątków Apacza. Apacz w modelu FastCgi służy wyłącznie do komunikacji z przeglądarką klienta. W momencie kiedy klient zażąda uruchomienia skryptu PHP - żądanie to przekazywane jest do 'serwera FastCGI' który używając interpretera PHP uruchamia skrypt i odsyła wynik do Apacza. Wygląda to mniej więcej tak:

+----------+  TCP 80  +----------+ Unix socket
|  Klient  | <----->  |  Apache  | <-----+
+----------+          +----------+       |
                       user: http        |
+----------+          +----------+       |      +-------------+        +--------------+
|  Klient  | <----->  |  Apache  | <-----+----> | PHP FastCgi | <----> | Server MySQL |
+----------+          +----------+       |      +-------------+        +--------------+
                       user: http        |        user: john
+----------+          +----------+       |
|  Klient  | <----->  |  Apache  | <-----+
+----------+          +----------+
                       user: http

Przy użyciu spawn-fastcgi uruchamiamy dla każdego z użytkowników własny serwer PHP FastCgi który nasłuchuje na Unixowym sockecie. Apache komunikuje się po sockecie z wybranym zgodnie z ustawieniami (per vhost) serwerem żądając wykonania skryptu. Dzięki temu otrzymujemy izolację wątków PHP od wątków Apache. Dodatkowo PHP FastCgi działając z uprawnieniami użytkownika, nie zaś serwera Apache ma możliwość zapisu do katalogów użytkownika, a także ograniczenia odczytu plików do których posiada uprawnienia.

Ok, ale co z wydajnością?

Po pierwsze Apache, dzięki temu że nie parsuje w każdym swoim wątku PHP zabiera o wiele mniej pamięci. Przy dużej ilości żądań jest  to sprawa kluczowa. Dzięki modelowi FastCgi można w prawidłowy sposób wykorzystać mechanizm database persistent connections (eg. w MySQL). W przypadku wielu wątków Apacza parsujących PHP nawiązywanych jest tyle połączeń ile wątków. Nowe wątki nie potrafią użyć ponownie połączeń utworzonych przez zabite wątki. Dzięki temu w parę minut osiągamy maksymalny limit połączeń z bazą.  W przypadku FastCgi nawiązanych zostaje tyle połączeń ile wątków i połączenia te są cały czas utrzymywane. To jest także sprawa kluczowa dla serwisów o wysokim obciążeniu.

Bezpieczeństwo?

Wspomniałem wcześniej - wykonanie kodu PHP z uprawnieniami użytkownika. Ale nie tylko - separacja cache APC to kolejny element bezpieczeństwa. Dalej: możliwość pozbycia się safe mode w PHP - aktualnie to mechanizm z którego PHP się wycofuje. W wersji 5 ma już go nie być.

fCgi, FastCgi, fCgid?

Jest sporo zamieszania jeśli chodzi o mechanizm FastCgi. Istnieje mnóstwo alternatyw. Osoba zaznajamiająca się z tematem za pomocą poldek search *cgi*   może czyć się nieco zagubiona. Dlatego opiszę co potrzebujemy aby to wszystko właściwie uruchomić.

Zacznijmy od końca, czyli od PHP. Potrzebna będzie paczka zawierająca interpreter fcgi dla PHP - jest to dodatkowy moduł SAPI (oprócz eg. zwyczajnego cli, lub modułu do Apacha) które można skompilować, tudzież zainstalować. Pod PLD jest to pakiet "php-fcgi". Dalej, przyda się coś co będzie potrafiło utworzyć nam serwery FastCgi dla użytkowników. Pakiet "spawn-fcgi" jest całkiem dobry do tego. I wreszcie musimy nauczyć Apache komunikować się z naszymi serwerami. Doinstalujmy moduł "apache-mod_fastcgi".

Wszystkie moduły można bez obaw zainstalować na serwerze który używa modułu "apache-mod_php"  do parsowania kodu PHP. Generalnie można używać obu modeli parsowania jednocześnie - część vhostów i aplikacji parsować modułem Apacza, najbardziej obciążone vhosty puścić przez FastCgi.

Konfiguracja PHP

Nieco problematyczną sprawą w modelu FastCgi jest  konfiguracja PHP per vhost. Nie możemy do tego użyć ani plików .htacess ani dyrektyw php_flag w konfiguracji vhosta. Należy dla każdego z vhostów wymagającego niestandardowego konfigu utworzyć osobny php.ini. Ma to jedną zasadniczą wadę. /etc/php/php.ini który zawiera nasze istawienia PHP nie będzie czytany. Zatem dla każdego z vhostów należy mieć kopię php.ini zawierającą wsztstkie opcje konfiguracyjne które chcemy zmienić. Jeśli którejś z opcji nie ujmiemy w indywidualnym .ini będzie ona miała wartość domyślną, taką, jaka jest wkompilowana w php. Czytany jest za to katalog /etc/php/conf.d, przy czym każda zdefiniowana tam opcja konfiguracyjna nadpisuje tę zdefiniowaną w indywidualnym .ini.

W PHP 5 ma być możliwość używania w globalnym php.ini wpisów [myhost.com], dzięki czemu będzie można nadpisać globalne ustawienia per vhost. Niestety póki co, trzeba robić kopie globalnego php.ini i zmieniać w niej wybrane opcje. Minimalna postać indywidualnego php.ini, tak, aby zachować najważniejsze spersonalizowane dla dystrybucji ustawienia to:

; Safe mode w binarce PHP domyślnie jest on, więc jeśli serwis
; pod nim nie działa trzeba wyłączyć
safe_mode = Off
; To warto podać, ograniczymy możliwość otwierania cudzych katalogów
open_basedir = "/home/webhosts/www.mychost.pl:/home/services/httpd:/tmp"
include_path = ${open_basedir}
error_reporting  =  E_ALL & ~E_NOTICE & ~E_STRICT
display_errors = Off
log_errors = On
; Błedy do sysloga, to php będzie działało z prawami usera, więc nie
; można zapisywać błędów do wspólnego pliku
error_log = syslog
ignore_repeated_errors = On
html_errors = Off
upload_tmp_dir = "/tmp"
expose_php = Off
memory_limit = 32M
date.timezone = "Europe/Warsaw"
browscap = /etc/php/browscap.ini

Konfiguracja spawn-fastcgi

Tu sprawa jest dość prosta, otóż spawn-fastcgi nie ma żadych konfigów, a wszystkie parametry przekazujemy w linii poleceń.

spawn-fcgi -s /var/run/fastcgi/fcgi.myhost.sock -M 0660 \
  -P /var/run/fastcgi/fcgi.myhost.pid -U http -G http \
  -u 10012 -g 10012 -C 2 -- /usr/sbin/php.fcgi -c /etc/php/webapps.d/myhost.ini

Po kolei: -s  /var/run/fastcgi/fcgi.myhost.sock mówi w którym miejscu tworzyć sockety serwerów FastCgi. Ja wybrałem sobie katalog /var/run/fastcgi. Należy go utworzyć nadając prawo do zapisu użytkownikowi, z którego prawami będzie działał serwer oraz prawa do odczytu dla serwera Apache (user http). -M 0660 każe zmienić uprawnienia do utworzonego socketa na 660, -P /var/run/fastcgi/fcgi.myhost.pid mówi gdzie zapisujemy plik z PIDem serwera. Parametry -U http -G http są ważne, i mówią że prawa dostępu do socketa mają być nadane dla użytkownika http. Jako że z socketa będzie korzystał serwer Apache zmiana uprawnień jest konieczna. Dalej -u 10012 -g 10012 - tutaj definiujemy id (bądź nazwę) użytkownika i grupy z uprawnieniami którego ma działać FastCgi. Z uprawnieniami tego użytkownika będzie wykonany kod PHP.  Można tu użyć ID'ów użytkowników wirtualnych. Nie muszą być dodani do /etc/passwd. Idealnie to się wpisuje w model hostingu gdzie użytkowników trzymamy w bazie danych bazie danych. Ważną sprawą jest jedynie, aby wirtualny użytkownik miał prawa do zapisu do katalogu na który wskazuje parametr -s. Można mu nadać prawa 777 lub trzymać sockety w katalogach domowych użytkowników.  -C 2 określa ile instancji FastCgi ma zostać uruchomionych. Wartość trzeba dobrać doświadczalnie. W przypadku zbyt małej ilości Apache będzie podawał klientom bład 500. I wreszcie pora na interpreter: -- /usr/sbin/php.fcgi -c /etc/php/webapps.d/myhost.ini - używamy zainstalowanego wcześniej php-fgi - podając mu parametr -c z indywidualnym plikiem konfiguracyjnym. Jeśli nie podamy parametru -c zostanie użyty domyślny /etc/php/php.ini.

Jeden serwer FastCgi może obsługiwać wiele hostów wirtualnych. W najprostszym przypadku  można uruchomić jedną instancję serwera na prawach użytkownika mającego prawa do odczyty dla plików PHP (może to być http) i uruchomić na nim wszystkie nasze vhosty. Przy czym w oczywisty sposób pozbywamy się w takim przypadku korzyści płynących z separacji uprawnień. Przy hostingu wirtualnym lepiej przyjąć strategię: jedna instancja per 1 użytkownik na której odpalamy wszystkie jego vhosty.

W ogóle fajnie jest napisać sobie jakiś rc.skrypt, który będzie uruchamiał wszystkie zdefiniowane instancje podczas startu, pozwoli nam je zresetować, zatrzymać, etc.

Konfiguracja Apache

Ok, i teraz Apacz. Wszystko co zostało zrobione do tej pory można bez obaw robić na serwerze który obsługuje PHP via moduł Apacza. Operacje poniżej wymagają już zmiany w konfiguracji serwera WWW, a co za tym idzie są ryzykowne. Główne ryzyko, przy pomyłce w konfiguracji to możliwość zaserwowania niesparsowanych skryptów PHP, tak więc na działających serwerach polecam blokadę dostępu dla virtualki via Order deny, allow Allow from my.ad.re.ss Deny from all. Dodatkowo jak wspomniałem wcześnej model parsowania PHP via moduł jak i FastCgi może współistnieć jednocześnie, tak więc możemy przerzucać na FastCgi pojedyncze virtualki.

Ok, zaczynamy od pliku "/etc/httpd/conf.d/90_mod_fastcgi.conf" . Domyślnie jest tam jedynie linijka ładująca moduł fastcgi. Dopiszmy do pliku:

<IfModule mod_fastcgi.c>
  # Domyślne ustawienia serwera FastCgi, -pass-header Authorization jest bardzo ważne
  FastCgiConfig -idle-timeout 20 -maxClassProcesses 1 -pass-header Authorization
  # Zarejestrujmy dwie akcje
  Action php5-fcgi /php-cgi
  Action application/x-fcgi-php /php-cgi
  # Załóżmy że nasz serwer FastCgi będzie znajdował pod wirtualnym adresem /php-cgi
  <Location "/php-cgi">
    php_flag engine off
    Order Deny,Allow
    Deny from All
    Allow from env=REDIRECT_STATUS
    Options ExecCGI FollowSymLinks
    SetHandler fastcgi-script
  </Location>
</IfModule>

Ok, to wystarczy, żeby móc przystąpić do konfigurowania vhostów. Do vhosta, dla którego uruchomiona została już instancja spawn-fcgi i mamy utworzony socket w katalogu /var/run/fastcgi/fcgi.myhost.sock dopiszmy:

<VirtualHost www.myhost.pl:80>
[...]
<IfModule mod_fastcgi.c>
# Tak! wyłączamy engine PHP, dzięki temu moduł PHP, który
# cały czas działa zostawi pliki PHP tej wirtualki w spokoju
php_flag engine off
# Magic! Nadpisujemy handler application/x-httpd-php każąc wszystkim
# plikom php zdefiniowany wcześniej dla modułu zostać sparsowanym via FastCgi
Action application/x-httpd-php /php-cgi
# Definicja serwera, ścieżka musi być taka sama jak doc_root vhosta + /php-cgi
# Nie należy się przejmować faktem, iż /php-cgi nie istnieje w tej ścieżce, tak ma być!
FastCgiExternalServer /home/webhosts/myhost/php-cgi -socket /var/run/fastcgi/fcgi.myhost.sock
</IfModule>
</VirtualHost>

Jeśli mamy jakiekolwiek opcje konfiguracyjne dla php (php_flag, php_admin_value) to należy je usunąć.

Uruchamiamy!

Checklist:

• Sprawdzamy czy  instancja serwera FastCgi uruchomiona przez spawn-cgi działa: ps aux | grep cgi:

  10008   7832  0.0  1.6  71324 34212 ? SN   14:19   0:18 /usr/bin/php.fcgi -c /etc/php/webapps.d/myhost.ini
  10008   7833  0.0  1.4  67408 29276 ? SN   14:19   0:19 /usr/bin/php.fcgi -c /etc/php/webapps.d/myhost.ini
  http   15808  0.0  0.5  72288 11548 ? SN   20:11   0:00 /usr/sbin/fcgi-pm

• Sprawdzamy czy jest socket i czy http ma możliwośc odczytu: ls -la /var/run/fastcgi:

  -rw-r--r--  1 root root    4 09-20 14:19 fcgi.myhost.pid
  srw-rw----  1 http http    0 09-20 14:19 fcgi.myhost.sock

• Sprawdzamy, czy w naszym konfigu apacza nie ma błedów: service httpd configtest

Pora na restart Apache. Po tym kod PHP dla konfigurowanego vhosta powinien być parsowany via FastCgi, co będzie sygnalozowane w wyniku funkcji phpini() wpisem Server API CGI/FastCGI.

Dla kodu parsowanego via moduł Apache Server API  to Apache Handler.

• przypisanie zasobów konkretnych procesorów dla wybranych usług, tak aby nie zajmowały sobie wzajemnie czasu procesora, eg. apache + mysql
• przypisanie procesów wybranego użytkownika do konkretnego procesora
• etc

Dla mnie ciekawym wydało się zastosowanie numer 1, z uwagi na fakt, iż mam Apache i MySql na tej samej maszynie. Postanowiłem zatem przypisać obie usługi do osobnych grup procesorów. Jako, iż dysponuje maszyną 2 x Intel(R) XEON(TM) CPU 2.20GHz każdej usłudze przypadło po 1 procesorze.

Ogólne wnioski są takie, ze przy 2 procesorach nie warto. Apache zżera o wiele więcej czasu procesora niż MySQL, co skutkuje ciągłym przeciążeniem jednego procesora, i co za tym idzie obniżeniem wydajności. Procesor przypisany dla MySQL jest obciążany w tym czasie na poziomie 20-40%.

Jedyną korzyścią, jaką widzę w tej konfiguracji, jest to, że przy dużym ruchu, Apache nie zablokuje całkowicie maszyny, ponieważ pozostałe usługi będą mogły wykonać się na mniej obciążonym procesorze.

Przy większej ilości procesorów miało by to być może sensowne zastosowanie. Linki:

• http://www.bullopensource.org/cpuset/

Konfiguracja:

/etc/sysconfig/system

# Enable cpusets support?
CPUSETS=yes

/etc/sysconfig/cpusets/cpuset-0-httpd

# Name of the cpuset
NAME=cpuset-0-httpd
 
# list of CPUs in that cpuset
CPUS=0
 
# list of Memory Nodes in that cpuset
MEMS=0
 
# If a cpuset is cpu or mem exclusive, no other cpuset, other than a direct
# ancestor or descendent, may share any of the same CPUs or Memory Nodes.
 
# is cpu placement exclusive?
CPU_EXCLUSIVE=1
 
# is memory placement exclusive?
#MEM_EXCLUSIVE=1
 
#
#NOTIFY_ON_RELEASE=0
 
# PIDs of tasks in this cpuset
#TASKS=
 
ONBOOT=yes

/etc/sysconfig/cpusets/cpuset-1-mysql

# Name of the cpuset
NAME=cpuset-1-mysql
 
# list of CPUs in that cpuset
CPUS=1
 
# list of Memory Nodes in that cpuset
MEMS=0
 
# If a cpuset is cpu or mem exclusive, no other cpuset, other than a direct
# ancestor or descendent, may share any of the same CPUs or Memory Nodes.
 
# is cpu placement exclusive?
CPU_EXCLUSIVE=1
 
# is memory placement exclusive?
#MEM_EXCLUSIVE=1
 
#
#NOTIFY_ON_RELEASE=0
 
# PIDs of tasks in this cpuset
#TASKS=
 
ONBOOT=yes

Później robimy:

service cpusets start

W katalogu /dev/cpusets powinny pojawić sie dwa katalogi, o nazwach takich jakie podano w opcjach NAME. W następnej kolejności przypisujemy usługi do konkretnych Cpusets, defaultowo robi się to w plikach eg. /etc/sysyconfig/httpd dodając rozumianą przez RC-scripts opcję:

SERVICE_CPUSET="cpuset-0-httpd"

RC-scripts, przypiszą wtedy podczas startu usługi jej proces do wybranego bpuset. W przypadku MySQL to nie działa, skrypt startowy jest napisany w innej konwencji. W tym przypadku standardowo trzeba dodać do /etc/sysconfig/mysql opcję:

SERVICE_CPUSET="cpuset-1-mysql"

i dalej edytować /etc/init.d/mysql, poszukaj poniższy kawałek kodu, i dodaj brakującą linię:

        pid=$!
 
        echo "$pid" > "/dev/cpuset/${SERVICE_CPUSET}/tasks"
 
        sleep 0.1
        mysqlstatus "$clusterdir" start
        # it takes longer for mysqld to start and create pidfile if it has to recover innodb transactions
        if [ "$MYSQL_STATUS" = "starting" ]; the

Dalej, restart obu usług, cat /dev/cpusets/cpuset-0-httpd/tasks i cat /dev/cpusets/cpuset-1-mysql/tasks - w obu powinny być odpowiednie PIDy procesów, dalej htop i warto sprawdzić, czy faktycznie dany proces trzyma się swojego procesora.

Linki:

•  http://wiki.dovecot.org/HowTo/PostfixAndDovecotSASL

Jako zakończenie klienckie użyta została karta PROATM-V155FM firmy Prosum. Jest to doskonała alternatywa do zastosowań sprzetowych typu Cisco, Nortel, etc, szczególnie jeśli chodzi o cenę. W Polsce koszt zakupu tej karty na chwilę obecną to około 2.500 zł. Tak więc przy koszcie ~3k, bazuąc na Linuxie można uruchomić w pełni funkcjonalny punkt dostępowy obsługujący interfejs ATM, routing, firewall, QOS oraz dodatkowe, przydatne usługi takie jak DHCP, lokalny DNS.

Zasadniczo karta ma wsparcie w postaci natywnie dostarczanych wraz z kernelem sterowników - konfiguracja samego ATM jest wspierana przez kernel i oprogramowanie linux-atm - w PLD, którego użyłem jako systemu bazowego - dostępne są nawet rc-scripts które w ładny sposób pozwalają skonfigurować interfejs i resztę rzeczy.

Sama konfiguracja poszła szybko i bezproblemowo - sterownik wykrył kartę bez problemu - skrypty podniosły interfejs - pozostało czekać jedynie na zestawienie łącza.

Niestety po uruchomieniu usługi przez TP sprawa się nieco skomplikowała. Otóż okazało się że całość po prostu nie działa. Po ponad 2 dniowych rozmowach z działem reklamacyjnym POLPAKu skierowano mnie wreszcie do kompetentnej (dziękuję Panie Grzegorzu za okazaną pomoc) osoby, która była mi stanie wyjaśnić mi na czym dokładnie polega problem.

Otóż TP podłącza klientów do dwóch rodzajów przełączników ATM, o ile przełączniki Nortel Passport 4860 nie sprawiają większych problemów, o tyle Nortel Passport 15000/20000 wymagają komunikacji z użyciem protokołu strict SDH.

Problem niestety leży w tym, iż sterownik warstwy ATM w linuxie (suni) domyślnie pracuje z użyciem protokołu SONET - starsze przełączniki są to w stanie obsłużyć - nowsze niestety wymagają obsługi SDH.

Po jakimś czasie grzebania w źródłach sterownika karty i sterowniku suni udało mi się zmusić do inicjalizacji domyślnie w trybie SDH co oczywiście poskutkowało natychmiastowym (na wcześniej przygotowanych konfigach) uaktywnieniem łącza.

Ok, jak to zatem wszystko do kupy uruchomić? Otóż na początek należy od TP uzyskać informacje o adresacji, adresie IP przełącznika, oraz VPI/VCI. Warto równe, po to aby uniknąć kłopotów dowiedzieć się do jakiego przełącznika jest wpięte zakończenie - szczególnie zaś jakiego protokołu wymaga. Jeśli jest to starszy typ przełącznika Nortel, lub taki który obsłuży protokół SONET całość prawdopodobnie ruszy na domyślnym sterowniku, który jest dostępny w paczce z kernelem PLD. Jeśli przełącznik wymaga SDH lub nie powiedzie sie uruchomienie karty na domyślnym sterowniku niestety czeka cię ręczna kompilacja jądra.

Przed kompilacją jądra pobrać należy sterowniki dla karty, które znaleźć można na stronie producenta. Po wymianie listów i wskazaniu problemu producent poprawił sterowniki, tak aby inicjowały suni w trybie SDH, tak więc używając obecnie dostępnych sterowników nie musisz grzebać w suni.

W dalszej kolejności pobieramy paczkę ze źródłami kernela oraz wszystko co przyda sie do kompilacji (mam nadzieję że nie pominąłem niczego, część nie podanych tu pakietów doinstaluje sie jako zależności):

[root@ozi-x proc]# poldek -i patch gcc make glibc-devel ncurses-devel kernel-sources

Lepiej jest użyć gotowej paczki PLD, gdyż te źródła kernela zawierają nałozone już wszystkie przydatne później łaty takie jak IMQ, Layer7, esfq, etc. W dalszej kolejności przekopiować należy pliki z paczki do katalogu drivers/atm, nałożyć patch odpowiedni dla wersji kernela, wyedytować nicstar.h i uaktywnić opcję NS_SUNI_FULL_SDH  (update: poczytaj dołączony do sterownika plik README, wymuszenie trybu SDH odbywa sie aktualnie poprzez przekazanie parametru  do modułu), zaznaczyć odpowiednie moduły do kompilacji i skompilować jądro. Zajrzyj do README, który znajdziesz w paczce ze sterownikiem - tam jest opisane które moduły należy zaznaczyć przy kompilacji kernela, którego patcha użyć, etc.

Tutaj jedna uwaga - zmiany w sterowniku, wg. tego co mi napisał producent nie zostały jeszcze przetestowane za switchem SDH tak więc nie ma pewności że działają. Producent prosił mnie o przeprowadzenie testów, niestety w tym momencie nie jestem tego w stanie zrobić. Jeśli z jakiegoś powodu sterownik nadal by nie działał potrzebne jest patchowanie suni.c

Po kompilacji otrzymujemy sterownik nicstar - który to najlepiej dopisać do /etc/modules - tak aby się ładował przy starcie.

Sama karta powinna być widoczna via lspci:

[root@ozi-x proc]# lspci
[...]
02:08.0 ATM network controller: Integrated Device Technology, Inc. IDT77222/77252 155Mbps ATM MICRO ABR SAR Controller (rev 05)

Załadowanie sterownika nicstar powinno wrzucić do logu kernela:

NET: Registered protocol family 8
NET: Registered protocol family 20
nicstar0: PHY type detection called.
nicstar0: PHY seems to be 155 Mbps.
nicstar0: SRAM size = 512K x 32bit
nicstar0: vpibase=0, vcibase=0, VPM=0x0
nicstar0: MAC address 00:XX:XX:XX:XX:XX

Załadowanie sterownika idt77252 wygląda nieco inaczej:

NET: Registered protocol family 8
NET: Registered protocol family 20
idt77252_init: at df80d000
ACPI: PCI Interrupt 0000:02:08.0[A] -> GSI 18 (level, low) -> IRQ 169
idt77252-0: ABR SAR (Rev E): MEM f1000000 SRAM f4000000 [2048 KB]
idt77252-0: Linkrate on ATM line : 149760000 bit/s, 353207 cell/s.

W obu przypadkach załadowanie sterownika powinno automatycznie załadować sterowniki atm i suni.

Paczki które należy zainstalować w PLD to:

[root@ozi-x proc]# poldek -i linux-atm linux-atm-rc-scripts

Następnie wyedytuj plik:

[root@ozi-x atm]# cat /etc/sysconfig/atm
ATM=yes
ATM_NICS_NUMBER=1
CLIP=yes
LANE=no
BR2684=no
PPPOA=no
LANE_SERVER_SERVICES=no
ILMI=yes

Konfiguracja samego interfejsu powinna wyglądać tak:

[root@ozi-x atm]# cat /etc/sysconfig/interfaces/ifcfg-atm0
# ip - adres ip przydzielony przez TP
# gw - adres portu routera brzegowego
DEVICE=atm0
IPADDR=80.50.55.ip
PREFIX=30
ATMARP_REMIP=80.50.55.gw
ATMARP_PVC=0.VPI.VCI
ATMARP_QOS="ubr,aal5:pcr=20000"
DEFAULTHANDLING=yes
ARP=yes
ONBOOT=yes
. /etc/sysconfig/network-scripts/ifup-atm.post

Uruchom usługę ATM:

[root@ozi-x atm]# service atm start

I teraz trochę diagnostyki. Użyteczne informacje znajdziesz w /proc/net/atm - w pvc powinieneś zobaczyć wszystkie zestawione kanały PVC - w szczególności ten odpowiadający VPI/VCI twojego łącza:

[root@ozi-x atm]# cat /proc/net/atm/pvc
Itf VPI VCI AAL RX(PCR,Class) TX(PCR,Class)
0 0 5 5 0 UBR 0 UBR
0 0 16 5 0 UBR 0 UBR
0 x xxx 5 0 UBR 0 UBR CLIP, Itf:atm0, Encap:LLC/SNAP

0.5 i 0.16 są zestawiane przez atmsigd i ilmi i służą do sterowania sygnalizacją ATM

Dodatkowo używając atmarp możesz sprawdzić czy poprawnie zestawił się CLIP via PVC:

[root@ozi-x atm]# atmarp -a
----- Itf 0 (80.50.55.ip, netmask 255.255.255.252) -----
Default QOS: ubr,aal5:max_sdu=9188
IP 80.50.55.gw, state VALID, addr <none>, flags 0x4<PERM>
QOS: ubr,aal5:pcr=20000,max_sdu=9188
0.vpi.vci
Send buffer: 109568
----- Unknown incoming connections -----
----- Incoming unidirectional connections -----
----- End of dump -----

Statystyki ramek ATM pokazuje atmdiag:

[root@ozi-x atm]# atmdiag
Itf TX_okay TX_err RX_okay RX_err RX_drop
0 AAL0 0 0 0 0 0
AAL5 103087429 0 131246245 0 0

W przypadku pojawienia się problemów z protokołem SONET/SDH (patrz port switcha ATM i sterownik) interfejs podniesie się bez problemów, otrzymasz również prawidłowe wyniki z atmarp. Zaś admdiag pokaże zmianę liczników TX_okay i RX_drop, RX_okay będzie cały czas pokazywało 0. Próbuj w takim przypadku kompilować sterownik ręcznie.

Jeśli wszystko jest prawidłowo, pingując IP portu switcha ATM powinieneś otrzymać odpowiedź. IP switcha oraz twoje IP powinno również odpowiadać na ping z zewnątrz. Tutaj uwaga: jeśli nie podniesiesz interfejsu ATM, lub wystąpią problemy w komunikacji karta->przełacznik ATM IP portu switcha nie odpowiada na ping z zewnątrz.

Po uruchomieniu interfejsu należy ustawić jeszcze domyślną bramę:

[root@ozi-x atm]# route del default
[root@ozi-x atm]# route add default gw $ATMARP_REMIP

Można do dopisać do /etc/sysconfig/network-scripts/ifup-atm.post, nie ma chyba lepszej metody bo skrypty nie ustawiają domyślnej bramy same.

Trochę teorii.

Największą bolączką powszechnie dostępnych tanich łącz klasy TPSA Internet DSL jest ich niesymetryczność. Jeśli cały ruch z wewnętrznej sieci puścimy przez niesymetryczne łącze, to nawet pomimo stosowania QOS istnieje duże prawdopodobieństwo, że użytkownicy programów p2p szybko zapchają upload, co skutkuje skutecznymi opóźnieniami na łączu niezależnymi od wysycenia downloadu. Warto zauważyć również, iż zwykły użytkownik relatywną prędkość jego łącza ocenia poprzez jakość działania najpopularniejszych usług takich jak poczta czy WWW. Interesującym zatem, z punktu widzenia jakości usługi jest priorytetyzacja/izolacja pewnych usług, które mają bezpośredni wpływ na zadowolenie klientów z posiadanego łącza.

Założenia:

• trzy lub więcej łącz zewnętrznych (InternetDSL)
• PLD Linux 2.4 jako NAT+HTB. Kernel 2.4 jest z mojego doświadczenia stabilny dla proponowanego rozwiązania. Z kernelami 2.6 nie udało mi się tego uruchomić (być może to jakiś PLD specyfic) nie mniej jednak powszechnie znane są problemy dla tego kernela z HTB.
• dwie wewnętrzne klasy adresowe

Rozważmy taki układ:

• eth0, ip: 80.0.0.2, gw: 80.0.0.1: ruch domyślny dla klasy 192.168.1.0/24
• eth1, ip: 80.0.1.2, gw: 80.0.1.1: ruch domyślny dla klasy 192.168.2.0/24
• eth2, ip: 80.0.2.2, gw: 80.0.2.1: łącze na wyizolowane usługi dla obu klas
• eth3, ip: 192.168.1.254: klasa adresowa wewnętrzna
• eth4, ip: 192.168.2.254: klasa adresowa wewnętrzna

Poprzez ruch domyślny rozumiem wszystkie, nie oznaczone specjalnie pakiety, ruch izolowany to WWW, POP3, SMTP

Implementacja:
Poniższa implementacja jest słuszna właściwie dla każdego systemu wspierającego iproute2 i iptables. Konfigurujemy standardowo 5 interfejsów sieciowych przypisując im właściwe adresy. Nie definiujemy w pliku /etc/sysconfig/network bramy ustawiając parametry na:

GATEWAY=""
GATEWAYDEV=""

Zestaw magicznych komend do skonfigurowania ręcznego routingu.

Przypisujemy kazde łacze do osobnej tablicy routingu:

ip route add default via 80.0.0.1 table 10
ip route add 192.168.1.0/24 via 192.168.1.254 table 10
ip route add 192.168.2.0/24 via 192.168.2.254 table 10           

ip route add default via 80.0.1.1 table 20
ip route add 192.168.1.0/24 via 192.168.1.254 table 20
ip route add 192.168.2.0/24 via 192.168.2.254 table 20           

ip route add default via 80.0.3.1 table 30
ip route add 192.168.1.0/24 via 192.168.1.254 table 30
ip route add 192.168.2.0/24 via 192.168.2.254 table 30

Następnie definiujemy która klasa powinna być routowana przez którą tablicę, przez 10 i 20 puszczamy ruch w całości per klasa adresowa, przez 30 tylko ruch znaczony:

ip rule add from 192.168.1.0/24 table 10
ip rule add from 192.168.2.0/24 table 20
ip rule add from 192.168.1.0/24 fwmark 0x41 table 30
ip rule add from 192.168.2.0/24 fwmark 0x42 table 30           

ip rule add from 80.0.0.2 table 10
ip rule add from 80.0.2.2 table 20
ip rule add from 80.0.3.2 table 30

Definiujemy routing prywatny: domyślna brama, używając wszystkich łącz. Używane będzie dowolne dostępne (wszystko jako jedna komenda):

ip route add default scope global
  nexthop via 80.0.0.1 dev eth0 weight 1
  nexthop via 80.0.1.1 dev eth1 weight 1
  nexthop via 80.0.2.1 dev eth2 weight 1

Tyle z routingiem, komendy można wpisać do własnego skryptu uruchamianego zaraz po podniesieniu interfejsów sieciowych lub po prostu do rc.local

Dalej konfiguracja /proc Opcję rp_filter trzeba ustawić na 0 i uaktywnić ip_forward:

for f in /proc/sys/net/ipv4/conf/*/rp_filter; do echo "0" > $f; done
sysctl -n -e -w net.ipv4.conf.all.rp_filter="0"
sysctl -n -e -w net.ipv4.ip_forward="1"

Jak wyżej, warto to wpisać razem z komendami konfigurującymi routing.

Teraz iptables:

Standardowo NAT:

iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -o eth0 -j SNAT --to 80.0.0.2
iptables -t nat -A POSTROUTING -s 192.168.2.0/24 -o eth0 -j SNAT --to 80.0.0.2
iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -o eth1 -j SNAT --to 80.0.1.2
iptables -t nat -A POSTROUTING -s 192.168.2.0/24 -o eth1 -j SNAT --to 80.0.1.2
iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -o eth2 -j SNAT --to 80.0.2.2
iptables -t nat -A POSTROUTING -s 192.168.2.0/24 -o eth2 -j SNAT --to 80.0.2.2

I znaczymy pakiety które mają iść izolowanym łączem (wcięcie linii to kontunuacja poprzedniej):

iptables -t mangle -A PREROUTING -j CONNMARK --restore-mark
iptables -t mangle -A PREROUTING -i eth3 -p tcp -m mport --dports 25,80,110,443 
   -j MARK --set-mark 0x41
iptables -t mangle -A PREROUTING -i eth4 -p tcp -m mport --dports 25,80,110,443 
   -j MARK --set-mark 0x42
iptables -t mangle -A PREROUTING -m mark ! --mark 0x0 -j RETURN

I tyle.

Jak łatwo zauważyć konfiguracja jest nadmiarowa (np nie trzeba NATować wszystkich klas) ale w przypadku awarii np łącza 80.0.1.2 możemy szybko przełączyć cały ruch na łącze 80.0.0.2 puszczając go przez tablicę 10:

ip rule add from 192.168.2.0/24 table 20 -> ip rule add from 192.168.2.0/24 table 10

Pakiety można znaczyć (mark) wg dowolnych reguł, np. adresu docelowego, dla serwerów gier czy np. GG, adresu źródłowego: można wyizolować ruch dla poszczególnych klientów. Pewnym rozwiązaniem może być także przypisanie do każdej z tablic znacznika (tak jak dla tablicy 30) i znaczenie via iptables całego ruchu. Z doświadczenia: problematycznym jest znaczenie pakietów p2p przez moduł ipp2p ponieważ nie klasyfikuje on wszystkich pakietów poprawnie i występują problemy. Ruch p2p lepiej zostawić nieoznaczony i puścić domyślnym łączem. Nie pokusiłem się również o priorytetyzację VoIP czy eg. Skype. Można do tego użyć modułu Layer7 (??) niedostępnego standardowo w PLD.

Przypuszczalnie całość można, a nawet trzebaby zrobić "koszerniej", routing do /etc/sysconfig/static-routes  /etc/sysconfig/static-rules, konfig /proc do /etc/sysctrl, iptables via jakaś nakładka. Wszystkie udoskonalenia mile widziane w komentarzach.

Na pierwszy ogień poszedł bot GG. Założenia:

1. boot powinien pracować jako pooler wiadomości dokładanych do bazy danych przez zewnętrzne aplikacje.
2. boot powinien obsługiwać komunikaty wysłane do niego od innych użytkowników.
3. bot powinien mieć możliwośc dołożenia dodatkowych protokołów (Jabber)

Implementacja obsługi GG poszła szybko za sprawą linuxowej biblioteki LibGadu oraz perlowej nakładki na nią czyli Net::Gadu. Problemy pojawiły się później. Po zaimplementowaniu obsługi GG postanowiłem zabrać się za wątki, gdyż jest to jedyny sensowny sposób oprogramowania moich założeń. Niestety okazało się, iż nie sposób wymieniać dane między wątkiem głównym a wątkami potomnymi. Przypuszczam, że spowodowane jest to właściwościami samego obiektu klasy Net::Gadu. Postanowiłem zatem wspomóc się mechanizmami pamięci współdzielonej. Implementacja poszła bezproblemowo, niestety okazało się, iż iterujące w pętli nieskończonej oczekiwanie na komunikat przez obiekt GG niemiłosiernie obciąża system kiedy odwołuje się do obiektu w pamięci współdzielonej.

Przyznam, że nie wiem jak rozwiązać ten problem. W chwili wolnego czasu spróbuję nad tym popracować.

Do w/w integracji często stosuje się następujące oprogramowanie:

• pDNS jako serwer DNS (1)
• Postfix wraz z SASL jako MTA
• Dovecot jako serwer usług POP3/IMAP
• Apache
• pureFTPd (2)

1) Bind jest najczęściej stosowanym serwerem DNS, jednakże pDNS oferuje natywne wsparcie MySQL oraz bardzo łatwą (gotowe programy) migrację

2) Zazwyczaj stosuje się proFTPd, którego przez długi czas i ja byłem zwolennikiem - jednakże z uwagi na problematyczną konfigurację z MySQL (problemy z quota) zrezygnowałem z niego.

Dodatkowo stosuję oprogramowanie
- GPS - wspierający MySQL grey-list policy server dla Postfixa
- Amavis jako SMTP proxy wspierające skanowanie antyvirusowe (clamav) i antyspamowe (spamassasin)

Integracja całości jest przedmiotem wielu FAQ oraz całej masy dokumentacji którą można znaleźć w googlach, tak więc nie na tym będę się skupiał. Skupie się na samej strukturze bazy danych.

Otóż zauważyć można podczas integracji pewną nadmiarowość i duplikowanie informacji w wielu tabelach podczas konfigurowania różnych usług dla tego samego klienta.

I tak aby zgodnie z większością znanych opisów integracji metodą dodać klientowi pełną obsługę wszystkich usług musimy:

• dodać wpisy w 2 tabelach pDNS
• dodać wpisy w 3 tabelach postfixa
• dodać wpisy w tabeli dla Dovecot jeśli nie używamy tabeli Postfixa
• dodać 1 wpis w tabeli pureFTPd
• dodać 2(?) wpisy w tabeli amavis

Większość z informacji, które dodajemy do tych tabel jest duplikowana. W przypadku potrzeby zarządzania tą informacją mamy problem. Co zrobić aby nie duplikować niepotrzebnie informacji. Otóż z pomocą przychodzą nam tutaj mechanizmy view (w dalszej części będę używał nazwy widok) dostępne w MySQL od wersji 5.

Przyjrzyjmy się najpierw tabelą pDNS. Tutaj uwaga. Wszystkie tabele mają format zgodny z powszechnie stosowanymi opisami integracji usługi z MySQL. Różnią się tylko nazwą, którą dla własnej wygody prefixowałem nazwą usługi.

mysql> desc pdns_domains;
+-----------------+------------------+------+-----+---------+----------------+
| Field           | Type             | Null | Key | Default | Extra          |
+-----------------+------------------+------+-----+---------+----------------+
| id              | int(11)          | NO   | PRI | NULL    | auto_increment |
| name            | varchar(255)     | NO   | UNI |         |                |
| master          | varchar(20)      | YES  |     | NULL    |                |
| last_check      | int(11)          | YES  |     | NULL    |                |
| type            | varchar(6)       | NO   |     |         |                |
| notified_serial | int(11) unsigned | YES  |     | NULL    |                |
| account         | varchar(40)      | YES  |     | NULL    |                |
+-----------------+------------------+------+-----+---------+----------------+
7 rows in set (0.00 sec)

mysql> desc pdns_records;
+-------------+--------------+------+-----+---------+----------------+
| Field       | Type         | Null | Key | Default | Extra          |
+-------------+--------------+------+-----+---------+----------------+
| id          | int(11)      | NO   | PRI | NULL    | auto_increment |
| domain_id   | int(11)      | YES  | MUL | NULL    |                |
| name        | varchar(255) | YES  | MUL | NULL    |                |
| type        | varchar(6)   | YES  |     | NULL    |                |
| content     | varchar(255) | YES  |     | NULL    |                |
| ttl         | int(11)      | YES  |     | NULL    |                |
| prio        | int(11)      | YES  |     | NULL    |                |
| change_date | int(11)      | YES  |     | NULL    |                |
+-------------+--------------+------+-----+---------+----------------+
8 rows in set (0.01 sec)

Otóż tabel pDNS zmieniać nie możemy z tej oto przyczyny, iż pDNS zapisuje samodzielnie informacje do obu tabel, tak więc nie mogą być one przekonwertowane do widoku. Tabela pdns_domains zawiera jednakże istotne informacje, mianowicie AKTYWNE w naszym systemie domeny podstawowe i zapasowe.

Rzućmy okiem na tabele używane przez Postfixa:

mysql> show tables like 'postfix%';
+------------------------------+
| Tables_in_vserver (postfix%) |
+------------------------------+
| postfix_alias                |
| postfix_domains              |
| postfix_mailbox              |
+------------------------------+
3 rows in set (0.00 sec)

mysql> desc postfix_domains;
+----------+--------------+------+-----+---------+-------+
| Field    | Type         | Null | Key | Default | Extra |
+----------+--------------+------+-----+---------+-------+
| domain   | varchar(255) | NO   |     |         |       |
| backupmx | tinyint(1)   | NO   |     | 0       |       |
+----------+--------------+------+-----+---------+-------+
2 rows in set (0.01 sec)

mysql> desc postfix_mailbox;
+----------+--------------+------+-----+---------+-------+
| Field    | Type         | Null | Key | Default | Extra |
+----------+--------------+------+-----+---------+-------+
| username | varchar(255) | NO   | PRI |         |       |
| password | varchar(255) | NO   |     |         |       |
| maildir  | varchar(255) | NO   |     |         |       |
| quota    | int(10)      | NO   |     | 0       |       |
| domain   | varchar(255) | NO   | MUL |         |       |
| active   | tinyint(1)   | NO   | MUL | 1       |       |
+----------+--------------+------+-----+---------+-------+
6 rows in set (0.00 sec)

Otóż w tabeli postfix_domains znajduje się lista domen obsługiwanych przez nasz system. Dodatkowo znajdują się tam domeny których backup MX utrzymujemy. Z dużym prawdopodobieństwem założyć można, iż będzie to lista domen których DNS utrzymujemy w pDNS. W tabeli postfix_mailbox znajdują się konta użytkowników, tabela ta może być współdzielona przez SASL oraz Dovecot, aczkolwiek jest to nieefektywne z uwagi do różnego sposobu podejścia do tematu blokowania kont.
Zazwyczaj blokada tymczasowa ma na celu zablokowanie możliwości wysyłania i odbierania poczty przy jednoczesnym braku blokady na pocztę przychodzącą.

Tabela serwera FTP, poniższy schemat jest schematem pochodzącym z dokumentacji:

mysql> desc ftpd_users;
+----------+--------------+------+-----+---------+-------+
| Field    | Type         | Null | Key | Default | Extra |
+----------+--------------+------+-----+---------+-------+
| User     | varchar(16)  | NO   | PRI |         |       |
| Password | varchar(64)  | NO   |     |         |       |
| Uid      | int(11)      | NO   |     | -1      |       |
| Gid      | int(11)      | NO   |     | -1      |       |
| Dir      | varchar(128) | NO   |     |         |       |
+----------+--------------+------+-----+---------+-------+
5 rows in set (0.01 sec)

Do rzeczy: założenia:

• projektowany schemat danych ma mieć zastosowanie w serwerze wirtualnym, który może obsługiwać sporą ilość domen i być punktem wyjścia do zarządzania przy pomocy interfejsu WWW.
• podstawową jednostką przyporządkowania użytkowników do grup będzie domena
• Chcemy mieć na tyle elastyczny system, aby jednym wpisem w odpowiedniej tabeli dało się uaktywnić użytkownikowi cały zestaw usług.
• Chcemy dodatkowo zapewnić minimalną duplikację danych w całym systemie oraz pewne mechanizmy weryfikacji danych na poziomie bazy.

Cdn...