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.

Apt-p2p – ostateczny test.

Krótko o apt-p2p.

Apt-p2p spodobał mi się od razu, gdy tylko o nim usłyszałem. Jest to bardzo ciekawe podejście, w którym pobieranie pakietów deb odbywa się przy pomocy P2P (protokół bittorrent), zamiast z tradycyjnych centralnych repozytoriów (HTTP, FTP). Centralne repozytoria są wykorzystywane wyłącznie w przypadku, kiedy pakiet nie jest dostępny przez P2P lub nie jest wystarczająco popularny (za mało peerów).

Kiedyś zrobiłem krótki test apt-p2p, ale trudno go nazwać miarodajnym – maszyna była bardzo słaba, demon ma spory apetyt na zasoby i nie udało mi się wtedy zmusić go do działania jako proxy dla innych maszyn, a sam test nie trwał długo. Od tamtej pory minęło trochę czasu. Maszynka robiąca za router została wymieniona na coś bardziej współczesnego, znalazłem sposób na uruchomienie apt-p2p jako lokalnego proxy (brzydki, bo wymaga gmerania w kodzie, ale się da i działa). Program dostał drugą szansę.

Efekty działania.

Demon był testowany (czyli po prostu używany) w sumie na trzech maszynach, przez parę tygodni. Pierwsza maszyna, działająca 24/7, w zasadzie base system + parę pakietów, Lenny, publiczne IP, robiła też za proxy dla kolejnej (desktop, Lenny). Apt-p2p w wersji 0.1.5:

Transport

Mirror Downloads Peer Downloads Peer Uploads
This Session 0.0B 0.0B 0.0B
Session Ratio 0.00% 0.00% 0.00%
All-Time 108MiB 32.5MiB 50.4MiB
All-Time Ratio 76.85% 23.15% 35.86%

 

Maszyna druga (mój desktop), Squeeze, za NAT, bez przekierowanych portów. Apt-p2p w wersji 0.1.6:

Transport

Mirror Downloads Peer Downloads Peer Uploads
This Session 47.4MiB 119KiB 0.0B
Session Ratio 99.75% 0.25% 0.00%
All-Time 1.07GiB 340MiB 0.0B
All-Time Ratio 76.33% 23.67% 0.00%

Statystyk trzeciej maszyny nie zaprezentuję – napotkałem na dziwny problem z pobieraniem plików, być może mający związek z uruchomieniem tunelu IPv6 (MTU? brak wsparcia dla IPv6 w apt-p2p?) i cache był czyszczony przy okazji prób rozwiązania problemu. Jak patrzyłem wcześniej, to nic specjalnie różniącego się od powyższych nie zauważyłem.

Inne uwagi.

Pierwsze, co rzuca się w oczy po zmianie sposobu pobierania, to fakt, że pobieranie jest znacznie wolniejsze, niż normalnie. Widać to szczególnie na szybszych maszynach, z lepszym łączem. Prawda jest taka, że zwykle z tradycyjnych repozytoriów pakiety lecą z pełną prędkością. W przypadku skorzystania z apt-p2p widać przy każdym pliku laga, zapewne chodzi o sprawdzanie, czy peery posiadają dany pakiet. Nie jest to drastyczne dla aktualizacji systemu, ale drażni, jeśli potrzebujemy szybko doinstalować jakiś pakiet.

Jeśli chodzi o pobieranie, to jak widać na tej mizernej próbce, stosunek pakietów pobieranych tradycyjnie do pobieranych przez P2P jest w miarę stały i wynosi około 3 do 1. Całkiem niezły wynik, szczerze mówiąc liczyłem na znacznie mniej pobieranych przez P2P.

Widać też wyraźnie, że przekierowanie portu jest absolutnie niezbędne, jeśli nie chcemy być leecherem. Szczerze mówiąc, liczyłem, że coś tam będzie się wysyłać zza NAT do peerów z publicznym IP, tak jak przy tradycyjnym P2P, ale widocznie implementacja protokołu niestety nie pozwala na to.

Pakiet ma sporo błędów, a autor nie spieszy się z ich usunięciem. Wspomniany wcześniej brak prostego sposobu na uruchomienie apt-p2p jako lokalnego proxy to jeden z przykładów. Do tego dochodzą nieciekawe defaulty związane z miejscem zajmowanym przez logi czy problemy z działaniem przy zmianie IP lub utracie łączności z Internetem.

Na szybką poprawę błędu związanego z możliwym DDoSem przez klientów P2P też pewnie nie ma co liczyć… Nawet nie zgłaszałem tego, bo na inne błędy zero reakcji autora. Taki brak odpowiedzi jest okrutnie demotywujący, fajnie jest usłyszeć choćby, że będzie poprawione w następnej wersji, albo że nie uważa tego za (poważny) błąd.

Ewidentnie brakuje silnego community wokół projektu, najlepiej ze znajomością Pythona (przyznaję, próbowałem nieco z powyższych poprawić przez dodanie opcji, ale prawda jest taka, że ciężko i długo robi się coś w języku, którego się nie zna).

Zapewne wszystko wiąże się z tym, że apt-p2p jest mało popularny. Widać to choćby na kanale IRC poświęconym programowi. Zapewne prędkość pobierania byłaby wyższa, gdyby peerów było więcej, pewnie udałoby się poprawić część błędów, a autor miałby większą motywację do pracy widząc, że program jest popularny.

Podsumowanie.

Uważam, że w tej chwili apt-p2p jest mocno zapuszczony, słabo przetestowany i IMHO nadaje się wyłącznie dla geeków. Jeśli są chętni (najlepiej ze znajomością Pythona) do zabawy z tym programem, to dajcie znać. Jest dobry moment na popularyzację tego rozwiązania, przy okazji pewnie dałoby się odciążyć nieco mirrory przy wydaniu Squeeze’ego (i zapewnić szybszy upgrade do nowego systemu – tak przynajmniej twierdzono w swoim czasie w przypadku Ubuntu). Jeśli chętnych brak, to nie pozostaje nic innego, jak wyłączyć apt-p2p i znowu poczekać parę lat… Może coś się zmieni.

Własna paczka z Javą w Debianie.

Kosciak coś narzekał na aktualizacje Javy w Ubuntu, więc dla tych, którzy mają podobny problem, a chcą nową Javę, szybki przewodnik po tworzeniu własnej paczki z Javą (JRE) dla Debiana (powinno działać dla Ubuntu, ale nie testowałem).

Co jest potrzebne? Dostęp do internetu, przeglądarka, zainstalowany pakiet java-package.

Wchodzimy na stronę Suna z pobieraniem Javy SE. Wybieramy pobieranie najnowszej wersji Java SE Runtime Environment (JRE). Klikamy Download.

Wybieramy wersję dla naszej platformy (jak Linux 32 bit, to po prostu Linux), akceptujemy licencję. Następnie pobieramy plik z rozszerzeniem .bin i zapisujemy go na dysku.

Gdy skończy się pobierać, wchodzimy do katalogu, w którym go zapisaliśmy i wydajemy polecenie:

make-jpkg pobrany_plik

Odpowiadamy na pytania o wersję i akceptujemy licencję. Po chwili (i paru komunikatach) powinniśmy otrzymać gotowy plik .deb z najnowszą Javą, gotowy do eleganckiej instalacji (jak każdy inny pakiet .deb).

Jeśli ktoś zamierza korzystać do zastosowań związanych z kryptografią, to warto przeczytać opis, jak zrobić nielimitowaną siłę szyfrowania w Javie.

Jeśli w Ubuntu wyglądało by to inaczej, to proszę o informacje/poprawki.