Koniec moBILETu w Poznaniu.

Od jutra, tj. od 1.05.2013, w Poznaniu nie będzie można korzystać z moBILETu. Przyznaję, że jestem rozczarowany, bo mimo tego, że generalnie przesiadłem się na sieciówkę, zdarzało mi się korzystać. Bardziej dla znajomych czy dzieci, ale jednak. System – mimo paru wad i paru miejsc, które można było poprawić – był całkiem niezły (c’mon, zawsze w razie potrzeby masz bilet, nie musisz szukać kiosku/biletomatu, poza tym, masz ten bilet w wielu miastach) i polecałem go znajomym.

Z oświadczenia na stronie moBILETu wynika, że wygasła umowa, a ZTM ogłosił nowy przetarg. W sumie trochę późno sprawa wyszła na jaw (czyżby negocjacje do końca?), ja po raz pierwszy usłyszałem o tym jakiś tydzień-dwa temu, a niedawno robiłem doładowanie… Pieniądze można odzyskać, ale prościej było nie doładowywać.

Jest szansa, że system wróci do Poznania. Liczę na to, bo wygodny był, a i tak zamierzam z niego korzystać w innych miastach, choćby w Szczecinie.

PS Wpis się pojawił, bo właśnie dostałem SMS od moBILETu w tej sprawie. Co prawda późno, ale i tak szacun za podejście do klienta.

UPDATE: Wyżej linkowany wpis zniknął, w jego miejsce pojawiła się informacja o przedłużeniu funkcjonowania moBILETu w Poznaniu do końca czerwca (czyli zakończenia przetargu).

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.

Data wydania Wheezy’ego podana.

Odbieram dziś pocztę, a tam:

We now have a target date of the weekend of 4th/5th May for the release. We have checked with core teams, and this seems to be acceptable for everyone.  This means we are able to begin the final preparations for a release of Debian 7.0 – „Wheezy”.

Yay!

Jest szansa, że akurat będę u rodziców, co oznacza… Upgrade na desktopie (jedyny desktop bez testing/unstable)! I może na Dockstarze też! I oczywiście wpisik na ten temat. Nie mogę się doczekać. 😉

Z innych ciekawych rzeczy, opisywany kiedyś wajig rozwija się w interesujący sposób. Pojawiły się na przykład opcje update-pciids oraz update-usb-ids, o których wspominano w komentarzu do wpisu o 3 rzeczach, których nie aktualizujesz w Debianie. Co prawda wolałbym mikrokod, ale pożyjemy, zobaczymy… Dotyczy wersji wajig dostępnej we Wheezy.

Blokada portu 25 w Netii.

Netia dołączyła do grona największych[1] (wcześniej, jako pierwsza zrobiła to TPSA, potem – z większych operatorów – port 25 zablokował Dialog) i zablokowała port 25 dla użytkowników. Znowu późno się późno się zorientowałem, bo po blisko miesiącu i pewnie nie napisałbym o tym, gdyby nie to, że jest to zrobione… źle.

Netia wprowadziła blokadę w najgorszy sposób dla użytkownika, tj. bez możliwości usunięcia blokady przez użytkownika. Nie da się jej usunąć ani samodzielnie, w sposób automatyczny (tak można to zrobić w przypadku Neostrady), czy w sposób zupełnie ręczny (telefon na infolinię), jak w Dialogu.

Poza tym, blokowanie portu 25 miało duży sens parę lat temu. TPSA była 3,5 roku temu pionierem, była to reakcja na realny problem spamu (Polska była w światowej czołówce wysyłających spam) i były realne efekty. Taki okres w IT to niemal epoka. Obecnie (niestety) coraz więcej spamu jest rozsyłanych w inny sposób, w szczególności przez soft kradnący hasła do skrzynek pocztowych. Ale lepiej późno, niż wcale.

Po drugie, blokada dotyczy tylko IP przydzielanych dynamicznie. Spam z łącz biznesowych będzie płynął dalej (a zmiana typu łącza na biznesowe to – zdaniem rzecznika – prosta sprawa[2]). Gwoli ścisłości, z tego co pamiętam, to samo zrobiła TPSA, bo – wbrew temu co pisze rzecznik Netii – blokada dotyczyła tylko Neostrady, ale już nie Internet DSL.

Po trzecie, brak możliwości zdjęcia blokady przez użytkownika. Co prawda opinia UKE w tej sprawie była pozytywna (czyli, że wolno tak zrobić – kiedyś wysłałem pytanie; nie oznacza to, że użytkownik nie ma możliwości rozwiązania umowy – tu już powinien wypowiadać się IMO UOKiK lub sąd), ale nie dawanie wyboru użytkownikom, jest słabe (choć prostsze technicznie). Szczególnie, że technicznie jest taka możliwość. W połączeniu z argumentacją usługi z dynamicznym IP nie są stworzone po to, żeby na nich stawiać serwery pocztowe[3] jest żenujące[4]. Uważam, że TPSA podeszła do tematu o dwie klasy lepiej.

[1] Przepraszam, ale ten zwrot mi się bardzo ostatnio spodobał, choć tu akurat bez podtekstu jest. Informacja o blokadzie portu 25 na blogu Netii.

[2] Komentarz nr 18:

12.02.2013, 10:39
@maniek552 Nie ma z taką zmianą żadnego problemu. Przechodzi się na ofertę biznesową nadpisując dane w systemie i sprawa załatwiona. Ceny są praktycznie takie same.
[3] Komentarz nr 29:
@maniek552 Z tym, że TP i Dialog wycięli wszystkim (również stałym IP) a my blokujemy tylko dynamicznym. Jest różnica i to duża. Usługi z dynamicznym IP nie są stworzone po to, żeby na nich stawiać serwery pocztowe.
[4] Stawianie serwerów nie jest podstawowym przeznaczeniem takich łącz – tu zgoda. Ale idąc tym tokiem rozumowania za moment okaże się, że można zablokować możliwość jakichkolwiek połączeń przychodzących na dynamicznych łączach (nawiasem, Orange tak robi z mobilnym internetem), albo w ogóle dopuścić tylko WWW i pocztę (w końcu SSH to „biznesowe” zastosowanie, c’nie? jeszcze NTP by się przydało i DNS, żeby w miarę sensownie działało). A tymczasem coraz częściej w domach pojawiają się „serwery”. Czy to gier, czy WWW. Często są one uruchamiane w taki sposób, że użytkownik nawet nie wie, że są, on po prostu udostępnia muzykę czy zdjęcia…