Kategoria: DSP2017

Opublikowane w

Międzyczas

Zacząłem od opisu założeń i tym podobnych rzeczy nie związanych bezpośrednio z programowaniem, ale ciągnie wilka do lasu i chciałem się w międzyczasie na boku pobawić fragmentami kodu i modułami. Ponieważ już w komentarzach w poprzednim wpisie pojawiły się wzmianki o tym co będzie, nie będzie wielkiej szkody czy niespodzianki, jeśli nieco wybiegnę naprzód.

Na pierwszy ogień poszło pingowanie, bo właśnie w ten sposób chcę mierzyć jakość łącza. Jak można się spodziewać, do korzystania z ICMP wymagane są uprawnienia użytkownika root. Nie jest to dla mnie niespodzianką, bo spotkałem się z tym przy perlowym skrypcie do powiadamiania o konieczności wpisania CAPTCHA dla Aero2. Tym razem postanowiłem nie odpuścić, tym bardziej że w sumie dopuszczam – przynajmniej w pierwszej wersji – uruchamianie skryptu z użytkownika root. W końcu i tak będzie trzeba dotykać routingu, a do tego potrzebne są wyższe uprawnienia niż posiadają zwykli użytkownicy.

Żeby poznać najlepszy i zalecany sposób pingowania, wrzuciłem zapytanie do wyszukiwarki i… włos mi się zjeżył na głowie. Rozwiązań jest wiele, modułów jest wiele, a prostego i działającego jakoś nie widać. Zacząłem od prostego modułu ping, który ma funkcję quiet_ping robiącą to, co potrzebuję, ale o ile dał się bez problemu zainstalować z Python 2, o tyle z Python 3 ma problem:

virtualenv --python=python3 test
Already using interpreter /usr/bin/python3
Using base prefix '/usr'
New python executable in /tmp/abcc3/test/bin/python3
Also creating executable in /tmp/abcc3/test/bin/python
Installing setuptools, pkg_resources, pip, wheel...done.
source test/bin/activate
pip3 install ping
Collecting ping
  Using cached ping-0.2.tar.gz
    Complete output from command python setup.py egg_info:
    Traceback (most recent call last):
      File "", line 1, in 
      File "/tmp/pip-build-qqotvnqc/ping/setup.py", line 23, in 
        from ping import __version__
      File "/tmp/pip-build-qqotvnqc/ping/ping.py", line 196
        except socket.error, (errno, msg):
                           ^
    SyntaxError: invalid syntax
    
    ----------------------------------------
Command "python setup.py egg_info" failed with error code 1 in /tmp/pip-build-qqotvnqc/ping/

Z kolei próba użycia modułu python3-ping wygląda tak:

pip3 install python3-ping
Collecting python3-ping
  Could not find a version that satisfies the requirement python3-ping (from versions: 2014.05.01.022aa83, 2014.05.02.805ee25, 2014.05.02.16245f0)
No matching distribution found for python3-ping

Wgląda więc, że prawdopodobnie w pierwszym etapie, by nie tracić czasu, pozostanę przy Python 2, zachowując zgodność z Python 3, a najwyżej później dostosuję całość. Nie powinno być to trudne – wystarczy wymienić moduł i jego wywołanie, funkcje u mnie i argumenty raczej się nie zmienią. Będę wdzięczny za sugestię działającego modułu do pingowania. Oczywiście zawsze zostaje użycie systemowego polecenia ping i parsowanie wyjścia, ale tego wolałbym uniknąć…

Z innych newsów okołoprojektowych: zakupiłem modem GSM, żeby mieć na czym testować. Jest wbudowana karta w lapka, mam jakieś wifi na USB, dorzucę modem i wygląda, że nawet do pięciu łącz jestem w stanie w środowisku testowym mieć. Pewnie zostanę przy dwóch-trzech, ale dobrze jest mieć perspektywy. 😉

Opublikowane w

Założenia i opis projektu abcc

Projekt abcc składa się z demona, napisanego w Pythonie, który czyta plik konfiguracyjny, a następnie na podstawie jego zawartości dokonuje cyklicznej kontroli jakości dostępnych łącz względem określonych w konfiguracji IP docelowych. Przeprowadzane operacje zapisywane są do logu (syslog?), podobnie jak oceny poszczególnych łącz.

Zakładam wykorzystanie Pythona w wersji 3, przestrzeganie PEP8 i programowanie funkcyjne. Całość ma być możliwie prosta koncepcyjnie i możliwie konfigurowalna przy pomocy pliku konfiguracyjnego za pomocą wag poszczególnych wskaźników, wag IP. Rozwiązanie ma też zapewniać użytkownikowi pełną przejrzystość działania, wybór poziomu logowania i możliwość uruchomienia w wersji „na sucho”, w celu przetestowania, jak uruchomienie z daną konfiguracją wpłynęłoby na zmiany routingu.

Aby to osiągnąć, zmienia na czas pomiaru routing do docelowych IP na dane łącze, dokonuje pomiaru jakości łącza, a następnie, po zebraniu danych dla wszystkich łącz, określa, które z nich jest najlepsze i – jeśli zachodzi taka potrzeba, dokonuje zmiany routingu.

Do zmiany routingu wykorzystywane są zewnętrzne skrypty bashowe – pozwala to na dostosowanie działania demona do różnych platform i potrzeb – np. dodanie zmiany NATowanaia, wywołanie zmian na zdalnym systemie (router sprzętowy) – bez zmian w samym silniku.

Teoretycznie można by to napisać w czystym Bashu i wywoływać z crona, ale po pierwsze, chcę potrenować Pythona, po drugie tak będzie łatwiej, bardziej elegancko i będzie otwarta droga np. do zwiększenia częstotliwości próbkowania przez zrównoleglenie pomiarów.

Z racji wymogów konkursowych dotyczących ilości postów, tworzenie projektu będzie trochę przegadane, i spowolnione, przynajmniej na początku. Zaleta jest taka, że będzie lepiej widać sposób rozumowania, gdyby ktoś chciał coś skomentować lub się przyłączyć. Commity kodu i dokumentacji będą się pojawiały w miarę równolegle z wpisami na blogu, pierwszy właśnie poszedł.

Opublikowane w

Geneza, nazwa i zastosowania

Projekt, który mam zamiar zrealizować w ramach DSP2017 nazywa się abcc (Automatic Best Connection Chooser). Pierwotnie miał się nazywać abpppcc i działać dla połączeń PPP, ale w sumie nie ma to sensu. Pomysł narodził się, gdy kiedyś znajomy z FB napisał, że jest w drodze, ma 2 czy 3 połączenia GSM i przełącza się między nimi, bo raz lepiej działa to, raz tamto. Oczywiście przełącza się ręcznie.

Stwierdziłem, że gdyby miał Linuksa, to uruchomienie wszystkich naraz, sprawdzanie automatem i przełączanie ruchu na najlepsze nie powinno być trudne. Sprawę wstępnie przemyślałem, zacząłem nawet zabawę z dwoma modemami GSM, ale wkrótce pojawiły się ważniejsze sprawy i projekt trafił do szuflady. Znaczy na dysk. Nawet nie tyle projekt, co krótko spisane wstępne założenia i wymyślona nazwa.

Potem stwierdziłem, że rozwiązanie można zastosować też w innych okolicznościach, nie tylko przy laptopie w podróży. Może służyć do przełączania ruchu na łącze zapasowe w przypadku sieci i routera na Linuksie i pogorszeniu parametrów łącza podstawowego, a nawet… do sterowania ruchem operatorskim.

W tym ostatnim zastosowaniu oczywiste jest podobieństwo do rozwiązania firmy Border6 omówionego na PLNOG13, przy czym to co zamierzam napisać jest o wiele bardziej prymitywne, więc mam nadzieję, że klientów nie odbierze. Choć IMO ma szansę być opensource’ową namiastką.