Konfiguracja trunku Sipgate w Trixbox (Asterisk)

Trixbox i Sipgate

Sipgate udostępnia darmowe numery DID (direct inward dialing) z USA, UK oraz DE z których korzystać można za pośrednictwem trunków SIP.

W roli PBX wybrany został Trixbox ze względu na szybką i łatwą konfigurację oraz doświadczenia związane z obecną już w firmie centralną telefoniczną opartą na tej dystrybucji. Doświadczenia zebrane z jej podstawowym zabezpieczeniem zostały już wcześniej zebrane we wpisie bezpieczny Trixbox.

Poprawne działanie opisanej konfiguracji zostało potwierdzone w praktyce – zarówno w nawiązywaniu jak i odbieraniu połączeń. W dalszej części zakładam, że trixbox został świeżo zainstalowany na maszynie dostępnej pod NAT-owanym adresem IPv4 192.168.0.6, a adres publiczny IPv4 to 12.34.56.789;

Konfiguracja Trixbox

Konfiguracji dokonujemy przez wygodne gui dostępne pod http://trixbox/maint z jako \”maint\” z hasełem \”password\”.

Dodajemy SIP extension dla lokalnego telefonu

  1. W PBX Settings -> Basic -> Extensions wybieramy Add an Extension -> Generic SIP device
  2. Wypełniamy pole \”User extension\” wpisując wewnętrzny numer, np. \”100\”, w \”Display Name\” określającą go nazwę, oraz w \”secret\” przypisujemy doń hasło.

Dodajemy SIP trunk od Sipgate

  1. W PBX Settings -> Basic -> Trunks wybieramy Add SIP Trunk
  2. W Outbound Caller ID wpisujemy otrzymany od Sipgate numer
  3. Ograniczamy ilość wychodzących jednocześnie połączeń wpisując w Outbound Caller ID wartość 1
  4. Wypełniamy Outgoing Settings, wpisując w Trunk Name \”sipgate\” oraz w PEER Details poniższą konfigurację, zamieniając \”ID-UŻYTKOWNIKA\” na ID dostępne szczegółach konta na Sipgate oraz \”HASŁO-SIP-UŻYTKOWNIKA\” na dostępne tam hasło SIP różne od hasła używanego do logowania na stronie

    authuser=ID-UŻYTKOWNIKA
    context=ext-did
    dtmfmode=info
    fromdomain=sipgate.co.uk
    fromuser=ID-UŻYTKOWNIKA
    host=sipgate.co.uk
    insecure=very
    qualify=yes
    secret=HASŁO-SIP-UŻYTKOWNIKA
    type=peer
    username=ID-UŻYTKOWNIKA

  5. W Incoming Settings ustawiamy USER Context na \”ext-did\”, a USER Details identycznie jak PEER Details
  6. W Register String ustawiamy \”ID-UŻYTKOWNIKA:HASŁO-SIP-UŻYTKOWNIKA@sipgate.co.uk/ID-UŻYTKOWNIKA\”

Konfigurujemy inbound i outbound route

  1. W PBX Settings -> Inbound Call Control-> Inbound routes wybieramy Add Incoming Route
  2. W DID Number wpisujemy \”ID-UŻYTKOWNIKA\”
  3. W sekcji Set Destination wybieramy utworzony wcześniej numer (extension)
  4. W PBX Settings -> Basic -> Outbound routes wybieramy Add Route
  5. W Route Name wpisujemy np. \”sipgate_outside\”
  6. Aby skierować wszystkie rozmowy do trunku w Dial Patterns wpisujemy \”.\”
  7. W Trunk Sequence wybieramy utworzony trunk: \”SIP/sipgate\”
Konfiguracja NAT
  1. Przekierowujemy porty 12.34.56.789:5060-5070 TCP i UDP na porty 192.168.0.6:5060-5070
  2. Przekierowujemy porty 12.34.56.789:10000:20000 UDP na porty 192.168.0.6:10000:20000

W Vyatta Core 6.2 realizują to polecenia:

for i in 1 2; do set service nat rule 60${i} type destination; set service nat rule 60${i} inside-address address 192.168.0.6; set service nat rule 60${i} inbound-interface eth0; done
set service nat rule 601 protocol tcp_udp
set service nat rule 601 destination port 5060-5070
set service nat rule 602 protocol udp
set service nat rule 602 destination port 10000:20000

Konfiguracja dla trunków USA i DE przebiega analogicznie z dokładnością co do domeny.

Instalacja Xen Cloud Platform na soft-raid1

Niemożliwe, niewspierane, …

Zgodnie z dokumentacją, instalacja Xen Cloud Platform na macierzy RAID1 może odbyć się tylko w przypadku korzystania z wspieranego sprzętowego kontrolera RAID. Ze względu na ograniczoną przestrzeń na karty rozszerzeń w HP Microserver nie pozwalającą na wykorzystanie tanich kontrolerów Dell PERC, zdecydowałem się na instalację systemu na macierzy stworzonej mdadm.

Instalacja XCP 1.5

Instalator XCP nie pozwala nam ani na instalację na macierzy fake-raid ani nawet na modyfikację układu partycji.
Jako, że wykorzystałem dyski 1TB, nie miałem konieczności korzystania GUID Partition Table. Pozwoliło to na uproszczenie procedury i w tej też formie przedstawiam ją tutaj.

W przypadku instalacji z płyty CD wybieramy przy rozruchu opcję \”shell\”, w przypadku instalacji z sieci (PXE) przełączamy konsolę na 3 (ALT+F3) i dokonujemy poniższych modyfikacji, następnie restartując program instalatora (kill).

  1. Wyłączamy GPT – nie wspierane przez dmraid:

    sed \’s/GPT_SUPPORT = True/GPT_SUPPORT = False/\’ -i /opt/xensource/installer/constants.py

  2. Wychodzimy z shell komendą exit
  3. Prowadzeni przez instalator Anaconda dokonujemy instalacji na pierwszym z dysków nie tworząc local storage
Przeniesienie systemu na RAID1
  1. Tworzymy docelową struktury partycji
    Najprościej:

    sfdisk -d /dev/sda | sed \’s/Id=83/Id=fd/g\’ | sed \’s/Id=8e/Id=fd/g\’ | sfdisk –force /dev/sdb

    Lepiej: tworzymy analogiczną strukturę jak na pierwszym dysku, wypełniając go partycjami typu Linux RAID autodetect (w fdisk – typ \”fd\”), przeliczając odpowiednio wielkości w przypadku korzystania z dysków Advanced Format (4kb sektor).

  2. Tworzymy macierze RAID1, zapisujemy konfigurację…

    mdadm –create /dev/md0 –level=1 -n 2 missing /dev/sdb1
    mdadm –create /dev/md1 –level=1 -n 2 missing /dev/sdb2
    mdadm –create /dev/md2 –level=1 -n 2 /dev/sda3 /dev/sdb3
    mdadm –detail –scan | sed -r \’s\\$\\ auto=yes\’ > /etc/mdadm.conf

  3. …systemy plików…

    mkfs.ext3 /dev/md0
    mkfs.ext3 /dev/md1

  4. …oraz local storage.

    xe sr-create content-type=user type=ext device-config:device=/dev/md2 shared=false name-label=\”Local storage\”

  5. Zmieniamy wpis dla / w /etc/fstab, ustawiając urządzenie na /dev/md0
  6. Modyfikujemy initrd:

    mkinitrd -v -f –fstab=/etc/fstab –with=raid1 –preload=raid1 /boot/raid-initrd $(uname -r)
    mkdir /tmp/initrd; cd /tmp/initrd; cat /boot/raid-initrd | gzip -d – | cpio -id
    sed \’s/Scanning and configuring dmraid supported devices/raidautorun \\/dev\\/md0/\’ -i init
    sed \’s/sda1/md0/\’ -i init
    find . -print0 | cpio –null -ov –format=newc | gzip -9 > /boot/raid-initrd

  7. Dodajemy wpisy w /boot/extlinux.conf z opcją z root=/dev/md0 i na końcu /boot/raid-initrd, zmieniamy opcję domyślną
  8. Kopiujemy system na dysk docelowy, instalujemy bootloader i restartujemy system:

    mkdir /mnt/md0; mount /dev/md0 /mnt/md0; rsync -xav / /mnt/md0/
    dd if=/usr/share/syslinux/mbr.bin of=/dev/sdb
    extlinux –install –raid /mnt/md0/boot

  9. Po wyłączeniu komputera uruchamiamy go jedynie z drugim dyskiem.
  10. Jeżeli procedura powiodła się, dodajemy pierwotny dysk jako drugi, ponownie kopiujemy nań tablicę partycji i dołączamy go do macierzy

    sfdisk -d /dev/sda | sfdisk –force /dev/sdb
    mdadm –manage /dev/md0 –add /dev/sdb1
    mdadm –manage /dev/md1 –add /dev/sdb2
    mdadm –manage /dev/md2 –add /dev/sdb3

Kompilacja Custombuild PHP z Percona Server

O Percona Server

Używamy jest Percona Server w wersji 5.5 jako serwera baz danych MySQL rozszerzając tym samym funkcjonalność standardowego serwera MySQL od Oracle o NoSQL-owy sposób komunikacji przez HandlerSocket oraz silnik składowania XtraDB.
Zoptymalizowany do korzystania z dysków SSD dla cache pozwala na znaczne zwiększenie wydajności bazy danych oraz dzięki dodatkowym INFORMATION_SCHEMA nadzorowanie wydajności i obciążenia per użytkownik bazy danych. W czasie restartów po aktualizacji oprogramowania Percona przechowuje indeksy i cache nie pozwalając nawet na tymczasową utratę wydajności.

Instalacja Percona Server

  1. Konfiguracja repozytorium
    Na Debianie Squeeze serwer został zainstalowany z pakietów pochodzących z repozytorium Percona:

    deb http://repo.percona.com/apt/ squeeze main

    Dostępne są również pakiety pod inne wersje systemu – Hardy, Lenny – jak i inne dystrybucje – np. Ubuntu.

  2. Zatrzymanie i wyłączenie obecnego serwera MySQL

    service mysqld stop
    mv /etc/init.d/mysqld /etc/init.d/mysqld-dis

  3. Instalacja pakietów, w tym pakietu deweloperskiego na potrzeby kompilacji PHP

    apt-get install percona-server-server-5.5 libmysqlclient18 libmysqlclient-dev

  4. Podmiana baz danych na pochodzące ze starego serwera MySQL

    service mysql stop
    rm -Rf /var/lib/mysql/*
    echo \”/home/mysql /var/lib/mysql none bind\” >> /etc/fstab
    mount /var/lib/mysql
    service mysql start

  5. Stworzenie lokalnej kopii konfiguracji pakietu custombuild

    cd /usr/local/directadmin/custombuild
    mkdir -p custom/suphp
    cp configure/suphp/configure.php5 custom/suphp/configure.php5

  6. Zmiana przełączników konfiguracji PHP
    /usr/local/directadmin/custombuild/custom/suphp/configure.php5

    \”–with-mysql\” \\
    \”–with-mysqli=/usr/bin/mysql_config\” \\
    \”–with-pdo-mysql=/usr/bin/mysql\” \\

  7. Rekompilacja PHP

    ./build php n

  8. Ustawienie danych debian-sys-maint. Tworzymy w bazie użytkownika z pełnymi uprawnieniami o poświadczeniach z /etc/mysql/debian.cnf

Konfiguracja Vyatta na serwerach OVH

Wykorzystując serwery OVH do wirtualizacji sprzętowej VMware ESXi pojawia się problem konfiguracji sieci na maszynach wirtualnych korzystających z IP failover. Prezentujemy kilka podejść, przy czym obecnie stosujemy równolegle dwa ostatnie z nich.

Podejście 1 – routing OVH bezpośrednio na maszynę

  1. Tworzymy adres MAC wirtualny w Usługi -> MAC wirtualny ustawiając typ \”vmware\” i ustawiamy go konfigurując adres sprzętowy interrface\’u sieciowego maszyny w vSphere Client.
  2. Konfigurujemy go z maską /32 jako adres IP hosta, dodajemy statyczne trasy do oraz przez gw serwera fizycznego (jego IP z końcówką .254)

    ip addr add 178.32.231.141/32 dev eth0
    route add  172.31.223.254 via eth0
    route add default gw 172.31.223.254

Podejście 2 – routing przez Vyatta, DNAT+SNAT

  1. Podobnie jak w 1, przypisujemy IP failover, ale do istniejącego adresu MAC interface\’u WANowego Vyatty (eth0).
  2. Konfigurujemy podsieć NATowaną na interface\’ie LANowym, NAT i DNS forward.

    set interfaces ethernet eth1 address 192.168.0.1/24
    set service nat rule 1 type destination
    set service nat rule 1 inbound-interface eth0
    set service nat rule 1 destination address 178.32.231.141
    set service nat rule 1 inside-address address  192.168.0.100
    set service nat rule 2 type source
    set service nat rule 2 outside-address 178.32.231.141
    set service nat rule 2 source address 192.168.0.100
    set service dns forwarding system

  3. Konfigurujemy sieć na serwerze wirtualnym podpiętym do LAN

    ip addr add 192.168.0.100/24 dev eth0
    ip route add default gw 192.168.0.1
    echo \”nameserver 192.168.0.1\” >> /etc/resolv.conf

Podejście 3 – routing przez Vyatta, static route

  1. Podobnie jak w 1, przypisujemy IP failover, ale do istniejącego adresu MAC interface\’u WANowego Vyatty (eth0).
  2. Konfigurujemy na obu interface\’ach Vyatty ten sam IP routera

    set interfaces ethernet eth0 address 178.33.137.225/32
    set interfaces ethernet eth1 address 178.33.137.225/32

  3. Ustawiamy domyślną trasę dla routera

    set protocols static route 0.0.0.0/0 next-hop 176.31.233.254

  4. Tworzymy trasę statyczną do serwera wirtualnego (directly connected)

    set protocols static interface-route 178.32.231.141/32 next-hop-interface eth1

  5. Konfigurujemy sieć na serwerze wirtualnym podpiętym do LAN

    ip addr add 178.32.231.141/32 dev eth0
    ip route add 178.33.137.225/32 dev eth0
    ip route add default via 178.33.137.225

Podejście 4 – routing przez Vyatta, failover RIPE

  1. Podobnie jak w 1, przypisujemy IP failover, ale do istniejącego adresu MAC interface\’u WANowego Vyatty (eth0).
  2. Konfigurujemy na obu interface\’ach Vyatty ten sam IP routera – z zewnątrz z maską /32, wewnątrz z maską podsieci

    set interfaces ethernet eth0 address 178.33.137.225/32
    set interfaces ethernet eth1 address 178.33.137.225/29

  3. Ustawiamy domyślną trasę dla routera

    set protocols static route 0.0.0.0/0 next-hop 176.31.233.254

  4. Konfigurujemy sieć na serwerze wirtualnym podpiętym do LAN

    ip addr add 178.33.137.226/29 dev eth0
    ip route add default via 178.33.137.225

Wiele wersji PHP w DirectAdmin używając mod_suphp i mod_macro

Integracja z Directadmin

Od strony DirectAdmina użyliśmy modułu phpsv specjalnie zaadaptowanego dla potrzeb używanej konfiguracji.
Pozwala on na ustawianie osobno wersji PHP dla każdej domeny.

Jeżeli taka możliwość okaże się dla klienta niewystarczająca, możliwe jest ustawienie dla każdej subdomeny, a nawet katalogu osobnej wersji używając opisanego poniżej makra.

 Instalacja wielu wersji PHP

Poszczególne wersje PHP zostały ręcznie skompilowane z różnymi prefiksami, np.:

\”–prefix=/usr/local/php52\”
\”–with-config-file-path=/usr/local/etc/php52/cgi\”

oraz podlinkowane z wygodnymi nazwami w celu uproszczenia używania zadań cron

/usr/local/bin/php-5.2 -> /usr/local/php52/bin/php

Dostępne są php-4.4.9, php-5.2.17, php-5.3.14, php-5.4.4, php-6.0.0.

Każda z nich została zlinkowana z bibliotekami libmysql dla Percona Server oraz w miarę możliwości wyposażona w Zend Optimizer albo Zend Guard Loader oraz ionCube Loader.

Instalacja mod_macro

Dla Apache/2.2.22 używamy modułu w wersji 1.1.11.
Instalacja ogranicza się do pobrania pliku ze strony mod_macro Fabiena Coelho i kompilacji przez apxs zgodnie z plikiem INSTALL.

Dla potrzeb konfiguracji wersji PHP udostępniamy dla użytkowników globalnie następujące macro.

/home/.htaccess:

<Macro php $version>
<FilesMatch \”\\.(inc|php|php3|php4|php5|php6|phtml|phps)$\”>
AddHandler x-httpd-php$version .inc .php .php3 .php4 .php5 .phtml
</FilesMatch>
</Macro>

Którego można użyć w pliku .htaccess wybierając stosowną wersję PHP:

Use php 4
Use php 52
Use php 53
Use php 54
Use php 6

 Konfiguracja mod_suphp

Po standardowej instalacji mod_suphp z custombuild dodajemy stosowne handlery.
W pliku /usr/local/suphp/etc/suphp.conf:

[handlers]
;Handler for php-scripts
x-httpd-php4=\”php:/usr/local/php4/bin/php\”
x-httpd-php52=\”php:/usr/local/php52/bin/php-cgi\”
x-httpd-php53=\”php:/usr/local/php53/bin/php-cgi\”
x-httpd-php54=\”php:/usr/local/php54/bin/php-cgi\”
x-httpd-php6=\”php:/usr/local/php6/bin/php-cgi\”

/etc/httpd/conf/extra/httpd-suphp.conf:

<IfModule mod_suphp.c>
Use php 53
<Location />
suPHP_Engine on
#suPHP_ConfigPath /usr/local/etc/php5/cgi/
suPHP_AddHandler x-httpd-php4
suPHP_AddHandler x-httpd-php52
suPHP_AddHandler x-httpd-php53
suPHP_AddHandler x-httpd-php54
suPHP_AddHandler x-httpd-php6
</Location>
</IfModule>

 

Nginx jako reverse proxy dla Apache z Zend Platform

Na naszych serwerach hostingowych  powszechnie wykorzystujemy wysokowydajny serwer http Nginx do serwowania treści statycznych. Zapytania o treści dynamiczne są kierowane przez tzw. reverse proxy do serwera Apache (tutaj: na porcie 8080).

Podstawowa konfiguracja vhosta Nginx dla tych potrzeb będzie wyglądać podobnie do poniższej.
Domyślnie kieruje ona zapytania na adres 127.0.0.1:8080 przekazując dane o kliencie oraz domenę z żądania.
Treści potencjalnie statyczne są serwowane bezpośrednio z odpowiedniego katalogu, przy czym zostało zablokowane hotlinkowanie.

server {
server_name aboo.pl *.aboo.pl

access_log /var/log/nginx/aboo.pl.access.log;
error_log /var/log/nginx/aboo.pl.error.log;
location ~ /\\.ht {
deny all;
}

location / {
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $remote_addr;
client_max_body_size 1000m;
client_body_buffer_size 512k;
proxy_send_timeout 90;
proxy_read_timeout 90;
proxy_buffer_size 32k;
proxy_buffers 16 32k;
proxy_busy_buffers_size 64k;
proxy_temp_file_write_size 64k;
proxy_connect_timeout 60s;
proxy_pass http://127.0.0.1:8080;
}

location ~* ^.+.(jpg|jpeg|gif|png|ico|zip|tgz|gz|rar|bz2|iso|doc|
xls|exe|pdf|ppt|txt|tar|mid|midi|wav|bmp|rtf|mp3|ogv|ogg|
flv|swf|mpeg|mpg|mpeg4|mp4|avi|wmv|js|css)$ {
expires 24h;
root /srv/vhosts/aboo.pl;
valid_referers none blocked aboo.pl *.aboo.pl;
if ($invalid_referer) {
return 403;
}
}

W konfiguracji Apache (/etc/apache2/ports.conf) zmieniamy port, po czym ew. poprawiamy konfigurację vhostów:

NameVirtualHost 127.0.0.1:8080
Listen 8080

Przy tej konfiguracji access log Nginx trafi do /var/log/nginx/aboo.pl.access.log.