Automatyczny wybór najlepszego mirrora w Debianie

Co prawda pisałem o tym blisko trzy lata temu, ale warto przypomnieć, że jest nowa metoda wyboru najlepszego mirrora pakietów deb w Debianie. Okazja tym lepsza, że z http.debian.net awansowało na httpredir.debian.org. Czyli jest pełnoprawną, oficjalną częścią Debiana. Jest też możliwość wyboru tego repozytorium podczas instalacji, przynajmniej od wersji Jessie.

Wiele się nie zmieniło, więc po szczegóły odsyłam do starego opisu albo na stronę projektu. Ze zmian: pojawił się adres IPv6, debootstrap też nie ma od jakiegoś czasu problemów z redirectorem. Ja korzystałem przez te trzy lata na różnych systemach (także produkcyjnych) i nie zauważyłem większych problemów, przynajmniej w wersji podstawowej, bo z niszami typu debootstrap czy apt-p2p kiedyś problemy były. Polecam.

PUM

Jakiś czas temu zacząłem korzystać z Uptime Monitor. Przyznaję, że jestem zadowolony, do pełni szczęścia brakowało mi czegoś, co wystawi moje uptime’y na WWW. Tzn. jest sporo fajnych narzędzi, rysujących ładnie i live, tzn. z autoodświeżaniem, ale… nie byłem przekonany do pomysłu publikacji kluczy API. Tym bardziej, że w niektórych przypadkach udostępnienie klucza wiąże się z z podaniem danych hosta, loginu i hasła do htpasswd itp.

Wolałbym mieć możliwość ukrycia nazwy/IP i ogólnie nie podawania zbyt wielu informacji, zwł. klucza API. Zauważyłem też, że nie ma (a przynajmniej nie znalazłem) nic do obsługi Uptime Monitora w Perlu. Stwierdziłem, że generowanie statycznego HTML (docelowo) z crona jest zupełnie wystarczające, a ew. autoodświeżanie prosto można załatwić JSem czy IIRC nawet polem META w HTML (koła nie odkrywam, „konkurencja” też tak robi.

I w ten sposób powstał PUM czyli Perl Uptime Monitor. 😉 Jest możliwość nadpisania nazwy, jest możliwość generowania uptime dla danego okresu (ilość dni wstecz). Brakuje opakowania wyniku w HTML (wyniki na STDOUT póki co…), ale to wkrótce… W sumie nie ma problemu z pobraniem danych do wykresu czasu odpowiedz, ale nie planuję póki co. Zachęcam do forkowania i zgłaszania pull requestów, ew. pomysłów w komentarzach.

Docker.io Debian Jessie HOWTO

Parę dni temu pojawiła się nowa wersja Debiana o nazwie Jessie. O upgrade i drobnych i niedrobnych perypetiach napiszę innym razem, dziś krótkie rozwiązanie problemu, który pojawia się dość często na IRCu. Chodzi o to, że pakiet docker.io nie jest dostępny w Jessie. A ludzie chcą dockera używać. Widzę trzy rozwiązania:

1. Pobranie pakietu docker.io w wersji dla Debiana unstable.

Rozwiązanie najprostsze, ale potencjalnie najbardziej problematyczne. Wchodzimy na https://packages.debian.org/sid/docker.io wybieramy architekturę, następnie mirror, pobieramy paczkę deb (akualnie jest to docker.io_1.3.3~dfsg1-2_amd64.deb). Instalujemy ją w systemie, mniej lub bardziej ręcznie spełniając zależności.

2. Dodanie repozytoriów unstable w systemie oraz odpowiedni pinning pakietów.

Po pierwsze czytamy dokładnie i ze zrozumieniem jak działa pinning pakietów (man apt_preferences), żeby nagle nie zaktualizowało systemu do unstable, albo nie pomieszało pakietów ze stable i unstable przy spełnianiu zależności. Następnie dodajemy wpisy dla unstable w sources.list. Aktualizujemy listę pakietów i docker.io powinien być dostępny do instalacji.

3. Samodzielnie robimy backport pakietu docker.io dla Jessie.

Wersja najdoskonalsza, bo nie robi bałaganu związanego z mieszaniem wersji stable i unstable w systemie. Po pierwsze zaopatrujemy się w debianowe źródła pakietu. Można dodać wpisy deb-src dla unstable w sources.list, zaktualizować listę pakietów. Następnie:

cd /usr/srcwajig source docker.iocd docker.io-1.3.3~dfsg1/wajig builddepends docker.iodpkg-buildpackage
cd ..
wajig install docker.io_1.3.3~dfsg1-2_amd64.deb

W tym momencie powinniśmy mieć zainstalowanego dockera w systemie. Nie sprawdzałem, czy działa, ale zarówno metoda druga jak i trzecia powodują, że pakiet instaluje się czysto, więc raczej będzie działać. Przykłady dla wersji 1.3.3, być może z czasem może się coś zmienić.