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

Naprawa typowego uszkodzenia APC Back-UPS RS 500

Rozpoznanie i podłoże usterki

Ze względu na błędną aplikację układu UC3842B w przetwornicy zasilacza awaryjnego APC Back-UPS RS 500, po dłuższym czasie użytkowania (>3 cykle wymiany baterii, 10 lat od produkcji) ulega uszkodzeniu układ ładowania akumulatora.
Objawy – pulsowanie wszystkich trzech diód – wskazywałyby raczej na konieczność wymiany akumulatora.

Niestety, bez wymiany może się nie obejść – jeżeli reakcja na ten stan nie wystąpi wystarczająco wcześnie, może dojść do głębokiego jego rozładowania, bezpowrotnego uszkodzenia i konieczności zakupu nowego modułu bateryjnego. Zapobiec temu możemy przez monitorowanie stanu zasilacza awaryjnego przez Nagios korzystając z wtyczki check_apcupsd.

Celem naprawy uszkodzonego zasilacza konieczna jest wymiana uszkodzonego kondensatora oznaczonego C7, nie spełniającego już swojej funkcji ze względu na długotrwałą pracę przy wysokiej częstotliwości oraz na granicy parametrów.

Naprawa uszkodzenia

Naprawa wymaga podstawowej umiejętności posługiwania się lutownicą, pewnej ręki oraz dozy zdrowego rozsądku. Ze względu na możliwość kontaktu z napięciem niebezpiecznym dla zdrowia i życia, w przypadku braku jednego z nich – lepiej skorzystać z pomocy serwisu APC bądź pozwolić zasilaczowi przejść na zasłużoną emeryturę i wybrać młodszy model zasilacza awaryjnego o zbliżonych parametrach.
Po uprzednim odłączeniu zasilania sieciowego, podtrzymywanych urządzeń oraz akumulatora (najpierw czarny zacisk) oraz chwili poświęconej przez nas na kontemplacji dalszej części instrukcji, a przez kondensatory na utracie ładunku, możemy przystąpić do otwarcia obudowy przez odkręcenie śrub z tyłu UPS, ostrożne wysunięciu tylnej ścianki i rozchylenie bocznych. Gorąco polecam wykonanie dokumentacji (najłatwiej fotograficznej) połączeń – konieczne do wygodnej pracy będzie odłączenie wszystkich kabli od płyty głównej zasilacza awaryjnego.

\"\"

W rewizji 3 tego zasilacza, jest to czarny kondensator na prawo od układu UC3842B w prawym górnym rogu płyty głównej.
Poniższe zdjęcie, ze względu na wyraźniej widoczną polaryzację przedstawia wymieniony już kondensator.
Wykorzystać do tego powinniśmy przewlekany kondensator elektrolityczny dobrej jakości o pojemności 22 mikrofaradów i napięciu min. 16V.

\"\"

Weryfikacja poprawności naprawy

Przed ponownym podłączeniem akumulatora, a po ponownym zamknięciu obudowy powinno się sprawdzić napięcie ładowania na zaciskach modułu bateryjnego. Korzystając z multimetru mierzymy jego poziom po włączeniu zasilacza – poprawny stan to ok. 14V.

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

Instalacja Piwik z import_logs.py z Nginx

Chcąc z powodzeniem monitorować ruch na stronie warto przyjrzeć się także wizytom automatycznym klientów nie wspierających JavaScript. W tym celu uzupełnimy statystyki Piwik o wizyty importowane z access log Nginx.

W poprzednim wpisie odnośnie Nginx skonfigurowano go jako reverse proxy dla Apache – w tym artykule przyjmujemy te same ścieżki.

Instalacja Piwik

Instalacja nie powinna sprawić większego problemu – ogranicza się do rozpakowania pobranego archiwum, ustawienia odpowiednich uprawnień i podania poświadczeń do bazy danych. W razie trudności chętnie pomożemy z instalacją skryptu zarówno na własnym hostingu jak i u obcego usługodawcy.

Konfiguracja import_logs.py

Importer dzienników jest uruchamianym cyklicznie skryptem Python dodającym odwiedziny do bazy Piwik.
Jego konfiguracja odbywa się za pomocą licznych przełączników linii poleceń.

Opcję –recorders ustawiamy na pożądaną liczbę wątków (<= ilość rdzeni), –url na pełny URL do instalacji Piwika.

Jeżeli korzystamy z wspólnego access loga dla wielu witryn  (lub uruchamiamy skrypt podając wiele plików)  warto ustawić opcję –add-sites-new-hosts bądź –idsite-fallback aby obsłużyć wizyty dla nieznanych stron.
Jeżeli access log jest oddzielny dla każdej z witryn – możemy wymusić ID strony przełącznikiem –idsite.

Aby śledzić wszystkie wywołania użyliśmy opcji  –enable-http-errors –enable-http-redirects –enable-static –enable-bots  oraz włączyliśmy debug -dd uzyskując finalnie poniższą komendę:

 python /srv/vhosts/aboo.pl/piwik/misc/log-analytics/import_logs.py –url=http://www.aboo.pl/piwik –idsite=3 –recorders=2 –enable-http-errors –enable-http-redirects –enable-static –enable-bots -dd /var/log/nginx/aboo.pl.access.log 

Testowo należy uruchomić ją z powłoki (polecamy opcje –dry-run –show-progress), następnie dodać do crontaba przed wywołaniem logrotate dla Nginx.

Debian – reset hasła root serwera MySQL

Niestety często przejmując pod opiekę serwer, bądź jedną z usług brakuje części haseł dostępowych do uprzywilejowanych użytkowników. W tym przypadku podobny problem napotkaliśmy z serwerem baz danych MySQL. Poniżej publikujemy procedurę postępowania w tym przypadku w dystrybucji Debian.

Droga na skróty – debian-sys-maint

Zanim przystąpimy do ustawienia nowego hasła użytkownika root, a korzystamy z pochodzącego z repozytorium apt pakietu warto sprawdzić, czy użytkownik systemowy \”debian-sys-maint\” którego poświadczenia znajdziemy w /etc/mysql/debian.cnf nie ma wystarczających uprawnień. W domyślnych ustawieniach jego dane powinny wystarczyć nam do zmiany hasła bądź wykonania niezbędnych czynności administracyjnych

Ostatnia szansa – reset hasła MySQL

Aby dokonać zmiany hasła nie posiadając wystarczających uprawnień musimy mieć dostęp do użytkownika root samego serwera. W kolejnych krokach uruchomimy MySQL w trybie, w którym każdemu połączeniu zostaną przypisane pełne uprawnienia – w tym do zmiany hasła roota.

  1. Zatrzymujemy serwer MySQL:
    service mysql stop
  2. Uruchamiamy serwer MySQL bez sprawdzania poświadczeń oraz bez zdalnych połączeń.
    /usr/sbin/mysqld –basedir=/usr –datadir=/var/lib/mysql –user=mysql –pid-file=/var/run/mysqld/mysqld.pid –skip-external-locking –port=3306 –socket=/var/run/mysqld/mysqld.sock –skip-grant-tables –skip-networking
  3. W drugiej sesji SSH logujemy się na serwer MySQL i dokonujemy zmiany hasła roota, przeładowujemy uprawnienia. Kroki te możemy także wykonać przez phpMyAdmin logując się z dowolnym hasłem.
    # mysql -u root
    mysql> UPDATE mysql.user SET Password=PASSWORD(\’Nowe Hasło\') WHERE User=\’root\';
    mysql> FLUSH PRIVILEGES;
    mysql> exit
  4.  W tej samej sesji wyłączamy serwer MySQL (nie reaguje na CTRL+C), uruchamiamy go w normalnym trybie
    # kill $(cat /var/run/mysqld/mysqld.pid)
    # service mysql start
  5. Najważniejszy krok – zapisujemy bezpiecznie nowe hasło. W naszej do generowania, przechowywania i współdzielenia haseł korzystamy z darmowego oprogramowania Keepass