Bananian, czyli Linux dla Banana Pi

O Banana Pi pisałem już jakiś czas temu. Jeszcze wcześniej narzekałem na Raspbiana, że dziwne opcje ma, że bloat… Cóż, posiadacze Raspberry Pi nie mają specjalnie wyboru, natomiast w przypadku Banana Pi nie ma przeciwskazań, by korzystać z normalnej architektury armhf w Debianie. No dobrze, jest jeden wyjątek, czyli kernel…

Niedawno, po dłuższej, bo blisko dwumiesięcznej przerwie zajrzałem na forum producenta Banana Pi, a tam rzuciła mi się w oczy informacja o wydaniu dystrybucji Linuksa dla Banana Pi o nazwie Bananian. Wesoła nazwa, pomyślałem i stwierdziłem, że może faktycznie na popularności Raspberry Pi przesadnie bazują, skoro nawet Raspbiana przechrzcili… Potem wszedłem na stronkę dystrybucji, doczytałem i… jestem bardzo zaskoczony i zadowolony. Tak naprawdę autorzy poszli w tę stronę, w którą sam planowałem iść.

Czym jest Bananian? Bananian nie ma wiele wspólnego z Raspbianem, poza nazwą. To minimalna wersja (base system, zero raspbianowego bloatu!) Debiana, tuningowana pod Banana Pi (głównie kernel, plus skrypty pomocnicze). Dla pakietów (poza kernelem) korzysta z wyłącznie oficjalnych repozytoriów Debiana, czyli koniec z opóźnieniami w aktualizacjach pakietów (także security). Tuning polega na poprawieniu wydajności i bezpieczeństwa. Normalny swap (niestety włączony domyślnie), bez cudacznych skryptów. Tuning SSH pod kątem zwiększenia bezpieczeństwa zgodnie z wytycznymi z bettercrypto.org. Więcej o zmianach, ficzerach itd. na stronce.

Do tego obraz jest bardzo mały (spakowany poniżej 230 MB, po rozpakowaniu wchodzi na kartę 2GB), a developerzy sprawili na mnie znacznie lepsze wrażenie, niż ci od Raspbiana (bardziej przyjaźni i otwarci na propozycje/wiedzę).  Załapałem się na wydanie nowej wersji i nawet jakieś zgłoszone bugi na forum zostały naprawione (lub dodane do bugtrackera). Zdecydowanie Bananian mi się podoba. Taki minimalny (stronka też). 🙂

UPDATE: Projekt został zakończony, Bananian nie jest już rozwijany.

One apt to rule them all

Zdarza się, że mamy więcej niż jednego czy dwa hosty do zarządzania. Zdarza się, że wykonując aktualizację na desktopie zapomnimy o innych hostach. Albo, po prostu chcemy sobie uprościć aktualizacje i nie musieć się ręcznie logować w kilka(naście, -dziesiąt) miejsc.

Jest przyjemne, konsolowe narzędzie, które ułatwi takie zadanie. Chodzi o apt-dater, czyli narzędzie do automatycznej aktualizacji wielu hostów, działające w ncurses. Działa z pochodnymi Debiana, ale również z systemami wykorzystującymi managery pakietów rug czy yum. Zasada działania jest prosta i nieco podobna do rozwiązań typu clusterssh. Na systemie docelowym dodajemy (dla pochodnych Debiana) użytkownika, który ma dodane w /etc/sudoers:

user ALL=NOPASSWD: /usr/bin/apt-get, /usr/bin/aptitude

Dodatkowo należy umożliwić temu użytkownikowi logowanie po kluczach (pamiętamy o używaniu kluczy z hasłem!) z maszyny, z której będziemy zarządzać. No i oczywiście skonfigurować hosty, którymi apt-dater będzie zarządzać. Domyślna konfiguracja znajduje się w plikach w katalogu:

$XDG_CONFIG_HOME/apt-dater/

Definiujemy tam grupy hostów, użytkowników na poszczególnych systemach, hosty (IP lub FQDN) oraz port. Przykładowa zawartość pliku hosts.conf:

[GRUPA1]
Hosts=localhost;pi@mojeraspberry:222

[GRUPA2]
Hosts=user1@serwer.www;user2@serwer.db:222;user3@serwer.poczty:222

[GRUPA3]
Hosts=user1@kolejny.serwer,user1@kolejny.serwer2

Jednym przyciśnięciem klawisza można wywołać aktualizację listy pakietów lub instalację aktualizacji w całej grupie hostów lub na pojedynczym hoście. Oczywiście jest możliwość podłączenia się do wybranego hosta i dokładnego sprawdzenia sytuacji.

Korzystanie nie jest oczywiste – trzeba się chwilę pobawić i przywyknąć. Nie podoba mi się też wykorzystanie aptitude, którego nie trawię i który AFAIK korzysta z innego algorytmu ustalania zależności, niż apt-get[1]. Wolałbym wajig albo gołego apt-get. Domyślnie wykorzystywany jest apt-get, ale można zmienić go na aptitude w pliku /etc/apt-dater-host.conf. Niemniej rozwiązanie jest ciekawe i mało znane, więc informuję i polecam wypróbowanie. A nuż komuś się spodoba. Ja używam pół na pół – czasem aktualizacje przy pomocy apt-dater, czasem po prostu aktualizuję tradycyjnym wajig daily-upgrade.

PS Dzięki K. za informację o tym programie.

[1] Z tego powodu kiedyś był zalecany przy aktualizacji wersji Debiana. Od jakiegoś czasu zalecany jest apt-get.

UPDATE: Poprawione błędy w nazwach plików, dodana informacja o wyborze programu używanego do aktualizacji.

Czy to naprawdę kod źródłowy tego programu?

Polecam cały artykuł Is that really the source code for this software? a dla niecierpliwych lub niespikających krótkie streszczenie. Wiele wolnego oprogramowania przychodzi w postaci binarnej, do której dołączony jest kod źródłowy w teorii odpowiadający dokładnie temu, z którego zostały zbudowane wersje binarne. Zagadnienie jest ważne zarówno z punktu widzenia wolności oprogramowania, jak i bezpieczeństwa.

Autor ww. artykułu postanowił sprawdzić, jak to wygląda w praktyce dla popularnych dystrybucji Linuksa (Debian, Fedora, OpenSUSE) na przykładzie tak prostego oprogramowania jak tar. Wykorzystał do tego celu minimalne instalacje systemu, korzystał ze źródeł dostarczonych w dystrybucjach i metod budowania zalecanych przez dystrybucje.

Wyniki są dość zaskakujące ani razu nie udało mu się uzyskać dokładnej (bit w bit) kopii tego prostego przecież pakietu.

W przypadku Debiana różnice były minimalne (data i id buildu w plikach wykonywalnych), w przypadku OpenSUSE było gorzej – powstałe pliki binarne były 5 razy większe od oryginału, ale po stripnięciu wersji binarnych sytuacja wyglądała już podobnie jak w przypadku Debiana. Najgorzej wypadła Fedora – nie tylko różnic było najwięcej, ale autorowi artykułu nie udało się ustalić przyczyn wszystkich rozbieżności i „niełatwo stwierdzić, czy samodzielny build ze źródeł będzie funkcjonował identycznie, jak opublikowana wersja binarna z dystrybucji”.

W przypadku skomplikowanych pakietów i projektów luźniej podchodzących do kwestii wolności oprogramowania, niż dystrybucje Linuksowe (np. firmware routerów z wykorzystaniem wolnego oprogramowania – często zamieszczają kernel, ale zwykle jest to wersja waniliowa wzięta na żywca z kernel.org…) różnice będą jeszcze większe. Gdyby ktoś znalazł komentarz RMS do sprawy, proszę o linka – bardzo jestem ciekaw, co ma do powiedzenia w tej sprawie.

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.