Debian, Huawei E3131 od Play i Aero2

Będzie krótko o tym, jak uruchomić i korzystać z modemu Huawei E3131 od Play na Debianie (unstable). Dokładny opis dotyczący Aero2 z Huawei E3131 jest na DUG, tu najważniejsze rzeczy i parę zmian.

Modem Huawei E3131 od Play

Źródło: http://www.play.pl/telefony/huaweie3131_white/img/gal/big/1_1100x1100.png

Instalacja potrzebnych programów:

wajig install usb-modeswitch wvdial

Ustawienie trybu automatycznego (domyślnie jest tylko Play). Wykonanie na rozłączonym modemie, tylko raz, po kupnie modemu:

echo "AT^SYSCFG=2,0,3FFFFFFF,1,2\r" >/dev/ttyUSB0

Zawartość pliku konfiguracyjnego wvdial.conf:

$ cat /etc/wvdial.conf 
[Dialer aero2]
Modem = /dev/ttyUSB0
Init1 = AT+CGDCONT=1,"IP","darmowy"
Phone = *99#
Stupid mode = yes
Username = "aero"
Password = "aero"
Dial Attempts = 0
Auto DNS = "off"

[Dialer power]
Modem = /dev/ttyUSB0
Init1 = AT+CSQ

Gwoli wyjaśnienia – opcja Auto DNS nie działa. Ani wywołana w powyższy sposób, ani jako Auto DNS = 0 – zawsze ustawia serwery DNS w /etc/resolv.conf. Nadpisuję ręcznie przez

echo "nameserver 127.0.0.1" > /etc/resolv.conf

Aby faktycznie wvdial nie ustawiał serwerów DNS oferowanych przez dostawcę, tylko korzystał ze statycznie ustawionych w /etc/resolv.conf, należy, poza powyższymi ustawieniami, w pliku /etc/ppp/peers/wvdial zakomentować opcję usepeerdns. Info z wpisu static DNS with wvdial.

I tu pierwszy trick – lokalny cache DNS powinien znacznie przyspieszyć odczuwalne działanie sieci, zwł. na tak wolnym łączu.

Trick drugi – używam tunelowania SSH z kompresją (ssh -CND 9000 user@host_z_lepszym_łączem)i socks proxy 5 (localhost:9000) w przeglądarce. Na oko, łącząc się do hosta 1/0,25 Mbps jest minimalnie szybciej, niż na gołym Aero2. W przypadku użycia VPS z porządnym łączem jest znacznie szybciej. Warto zwrócić uwagę, by zapytania DNS nie były tunelowane, jeśli korzystamy z lokalnego cache’ującego serwera DNS.

Połączenie z siecią nawiązuję przez wvdial aero2 – w tym przypadku nie zależy mi na automagicznym wznawianiu w tym przypadku.

Drugi wpis, czyli power służy do określania siły sygnału GSM (znowu sprawdzanie siły sygnału GSM opisane jest szerzej na DUG). Wywołanie to wvdial power, otrzymujemy dwie cyfry oddzielone przecinkiem, interesuje nas pierwsza cyfra. 2 km od nadajnika (strona z rozmieszczeniem nadajników GSM poszczególnych operatorów z możliwością pomiaru odległości od nich), w budynku, na parterze, bez żadnej anteny mam 7-10. To wystarcza do bezproblemowego działania sieci. Ogólnie jestem bardzo zadowolony z Huawei E3131 i jego działania pod Linuksem.

UPDATE: W związku z tym, że od 1 kwietnia 2014 do nawiązania połączenia przez Aero2 wymagane jest rozwiązanie CAPTCHA, należy uważać ze zmianą DNSów. Jeśli zmienimy z serwerów DNS Aero2 na inne, to nie nastąpi automatyczne przekierowanie żądania HTTP na stronę z CAPTCHA. Dla porządku: adres, na który następuje przekierowanie to http://bdi.free.aero2.net.pl:8080/ (uwaga na port!). Resolvuje się to – tylko z sieci Aero2 przed uzyskaniem pełnego dostępu do internetu – na http://10.2.37.78:8080/

UPDATE Jeśli szukasz opisu Linuksa i Huawei E3131 w wersji hilink zajrzyj do tego wpisu.

Aktualizacja Debiana do wersji Wheezy (7.0) z użyciem apt-p2p – HOWTO.

Ponieważ na dniach ma pojawić się nowe stabilne wydanie Debiana (Wheezy), postanowiłem zrobić upgrade na tym desktopie, gdzie jeszcze z niej nie korzystam. Przy okazji postanowiłem skorzystać z dobrodziejstw p2p i odświeżyć sytuację związaną z opisywanym kiedyś apt-p2p, tym bardziej, że nowe wydania są doskonałym momentem na wykorzystanie p2p do aktualizacji systemu (możliwe obciążenie mirrorów z uwagi na ilość zainteresowanych, sporo peerów). Tym bardziej, że pojawiło się trochę głosów na Twitterze/ideni.ca promujących apt-p2p.

Wpis jest w założeniu tylko szczegółowym howto dotyczącym konfiguracji i użycia apt-p2p, bez samego opisu aktualizacji do Wheezy.

Po co to wszystko?

Krótko w punktach, czemu idea p2p do dystrybucji pakietów mi się podoba:

  • Uniezależnienie się od poszczególnych mirrorów
  • Lepsze skalowanie
  • Mniejsze wymagania dotyczące sprzętu i łącz w stosunku do projektu Debian
  • Bezpieczeństwo jest zachowane (sumy kontrolne pakietów, podpisy GPG)

To oczywiście przy większej ilości węzłów. Przy mniejszej może być wręcz wolniej, ale apt-p2p ma zaimplementowany mechanizm fallbacku do tradycyjnego pobierania, więc nawet przy niewielkiej ilości węzłów nic nie przestaje działać.

Wymagania:

  • możliwość otwarcia/przekierowania portu na routerze do komputera, gdzie uruchomiony będzie apt-p2p
  • dwa razy więcej wolnego miejsca na pakiety .deb, niż przy zwykłej aktualizacji (apt-p2p ma swój katalog na cache, niezależny od /var/cache/apt)

Krok 1 – przekierowanie portów na routerze

Przekierowanie portów jest wymagane. Bez tego nie będziemy w stanie udostępniać pobranych pakietów, a taka jest idea p2p. Przekierowujemy zarówno protokoły TCP, jak i UDP.

Krok 2 – instalacja apt-p2p

wajig install apt-p2p

Domyślna konfiguracja jest OK, jedyne co warto zrobić, to pomyśleć nad zmianą portu na inny, niż domyślny 9977, jeśli mamy taką potrzebę. Paranoicy mogą wyłączyć zdalny podgląd statystyk.

Uwaga: jeśli chcemy, aby nasz apt-p2p posłużył jako proxy dla większej ilości maszyn w LAN (działa bez problemu, także dla różnych architektur na pojedynczej instancji apt-p2p), należy, zgodnie ze zgłoszonym bugreportem, zmodyfikować linię w pliku /usr/share/pyshared/apt_p2p/HTTPServer.py[1]:

if request.remoteAddr.host != "127.0.0.1:

na

    if not (request.remoteAddr.host == "127.0.0.1" or            request.remoteAddr.host.startswith("192.168.")):

gdzie 192.168 to początek (pierwsze 2 oktety) adresacji z naszej sieci LAN.

Krok 3 – edycja plików z repozytoriami (/etc/apt/sources.list)

Załóżmy prosty przypadek (jeśli ktoś grzebał w /etc/apt/preferences, lub ma więcej repozytoriów to zakładam, że wie, co zrobił i umie się dostosować), czyli, że mieliśmy wpisy:

deb http://http.debian.net/debian/ squeeze main contrib non-free
deb http://security.debian.org/ squeeze/updates main contrib non-free

zmieniamy je na

deb http://localhost:9977/ftp2.de.debian.org/debian/ wheezy main contrib non-free
deb http://localhost:9977/security.debian.org/ wheezy/updates main contrib non-free

Uwaga: jeśli zmienialiśmy port z domyślnego 9977, lub łączymy się do maszyny w sieci LAN, na której działa apt-p2p, to stosownie modyfikujemy localhost:9977

Zauważmy, że nie korzystamy z http.debian.net, tylko podajemy wprost adres repozytorium. Niestety apt-p2p nie działa za http.debian.net, wkrótce zgłoszę buga.

Krok 4 – sprawdzenie działania apt-p2p

Łączymy się przeglądarką z hostem, na którym działa apt-p2p i sprawdzamy statystyki. W przypadku uruchomienia lokalnie wpisujemy w pasku adresu http://localhost:9977/

Sprawdzamy czy adres IP w Contact jest taki sam, jak adres IP, z jakiego jesteśmy widoczni w sieci. Jeśli jest, to OK.

W DHT statistics sprawdzamy wartość Reachable. Jeśli poprawnie przekierowaliśmy porty, to będzie True.

Ostatnia rzecz do sprawdzenia w statystykach to Number of nodes. Wiadomo, że im więcej, tym lepiej (domyślnie apt-p2p nie pobiera przez p2p, jeśli ilość węzłów z danym plikiem jest mniejsza niż 3), po paru minutach powinniśmy widzieć tam ok. 30 węzłów (co nie znaczy, że wszystkie z nich mają potrzebne nam pakiety!). Wydaje mi się, że to minimalna sensowna wartość, by zacząć korzystać z apt-p2p.

Na koniec możemy zrobić wajig update i zobaczyć, czy pliki są pobierane bez błędów ze wskazanego źródła[2].

Uwaga: jeśli jesteśmy za NAT i zmieni się IP, to pole Contact nie ulegnie zmianie. Nadal będziemy mogli pobierać pakiety (choć nie dam głowy, czy z użyciem p2p), natomiast nic nie wyślemy. Do odświeżenia wymagany jest restart demona apt-p2p.

W tym momencie jesteśmy gotowi do aktualizacji systemu z użyciem technologii p2p.

[1] Tak, brzydkie grzebanie na żywca w plikach przychodzących w paczce; okolice linii 266.

[2] Stosunkowo często widziałem 500 internal server error w pierwszym przebiegu i poprawne działanie przy kolejnych. Proponuję najpierw wykonać aktualizację w trybie samego pobierania pakietów.

Debian Wheezy i Zabbix.

Dziś nieco się zdziwiłem, a raczej rozczarowałem. Okazuje się, że w nadchodzącym stabilnym wydaniu Debiana nie będzie Zabbiksa. W ogóle. Co prawda bardzo łatwo zrobić paczkę z publikowanych źródeł – i tak właśnie robię, bo serwer Zabbiksa czyli zabbix-server warto mieć w najnowszej wersji – ale wersja zabbix-agent  ma już niewielkie znaczenie, gdyż starsze wersje agenta zwykle współpracują ze znacznie nowszymi serwerami bez żadnych problemów. A jednak jest wygodnie było mieć agenta dostępnego w oficjalnym repozytorium pakietów.

Rozwiązań jest kilka: można pakiety robić samodzielnie, być może pojawią się też w backportach, ale dziś dowiedziałem się, że istnieje też repozytorium pakietów prowadzone przez twórców Zabbiksa. Znaleźć w nim można wersje dla Debiana (tylko stable), Ubuntu oraz RHEL.