Wpisy z tagiem: pakiet
piątek, 21 stycznia 2011
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:
Maszyna druga (mój desktop), Squeeze, za NAT, bez przekierowanych portów. Apt-p2p w wersji 0.1.6:
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.
piątek, 30 lipca 2010
Pisałem o sprzątaniu pakietów w systemie Debian przy okazji upgrade'u. Rozwiązanie tyleż skuteczne, co nieeleganckie, szczególnie ten dpkg, awk, perl, grep i wajig na dokładkę. Dziś, przy okazji innego taska (jak znaleźć pakiety nie z określonej wersji zamiast poprzedniego jak znaleźć pakiety nie mające kandydata w określonej wersji) pokazałem tamto rozwiązanie na kanale IRC i dostałem pytanie czemu nie apt-show-versions? No właśnie, czemu nie? Po prostu wtedy pisałem na szybko, z założeniem, że raz to uruchomię i niech sobie nawet kwadrans działa... Jedynym powodem dla którego nie użyć apt-show-versions jest istnienie managera pakietów wajig, który ma nakładkę na to polecenie, czyli wajig versions (i tak trzeba mieć apt-show-versions zainstalowane, ale łatwiej zapamiętać). Czyli, jeśli chcemy wyświetlić pakiety, które nie są zainstalowane z Debiana Squeeze, wystarczy: wajig versions | grep -v squeeze
sobota, 17 lipca 2010
Narzędzi do zarządzania pakietami w Debianie jest sporo: poczynając od graficznego synaptic, poprzez zalecane, ale niekoniecznie powszechnie używane - szczególnie przez administratorów na serwerach - aptitude, po nieśmiertelnego apta i dpkg. Nie ma co ukrywać, mimo swoich wad apt jest popularny i używany. Jednak nie tylko prędkość ma nienajlepszą, funkcjonalność także pozostawia nieco do życzenia. Nie można korzystać z jego pomocą z lokalnych pakietów deb - wymaga, by były w repozytorium. Oczywiście w takim wypadku można się posiłkować dpkg (to zawsze można), ale... statystyki ilości zużywanego przez pakiety miejsca i inne bajery nadal będą nieosiągalne. No i trzeba pamiętać, czy chcemy skorzystać z apt-get, apt-cache, apt-file czy jeszcze innego polecenia. Dawno, dawno temu odkryłem wajig, czyli nakładkę na apta i przyległości oraz dpkg. Co prawda wymaga Pythona (plus, do niektórych funkcjonalności potrzebne będą inne programy zewnętrzne), co oznacza, że obecnie w wersji podstawowej systemu potrzebne będą Perl i Python, ale za to pozwala na wszystko to, na co apt, plus wiele bonusów. IMO sprawdza się doskonale zarówno na desktopie, jak i na serwerach. Najważniejsze i najciekawsze moim zdaniem możliwości wajig:
Jeśli ktoś do tej pory korzysta z apt, to polecam zainteresować się managerem pakietów wajig - wygodniejszy i znacznie większe możliwości. I oczywiście można korzystać wymiennie z apt lub dpkg, jeśli zajdzie potrzeba. Dla tych, którzy wolą klikać niż pisać, istnieje Gnome JIG (polecenie gjig), czyli graficzna nakładka na wajig. Nie korzystałem, więc tylko sygnalizuję istnienie. Polecana lektura:
sobota, 29 sierpnia 2009
Debian to system, który - na podstawie założeń twórców i moich doświadczeń - bez problemu można zaktualizować do kolejnej wersji, jednak - jak pokazuje praktyka - nie zawsze zostaną przy tym usunięte wszystkie zbędne pakiety. Szczególnie, jeśli korzystamy z dodatkowych, nieoficjalnych repozytoriów. Poniżej quick'n'dirty sposób na półautomatyczne znalezienie i usunięcie pakietów, które nie mają już kandydata do instalacji z repozytorium. |
Ostatnie wpisy
Staty
Nawigacja
O mnie
Kontakt
Linkownia
SMSsender - skrypt do wysyłania SMSów
Przydatne polecenia Linux
Filtry Adblock by rozie
Zasady
Blogroll
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||