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.

Jak nie zainstalowałem Google Hangouts w Debianie Wheezy

Z własnej nieprzymuszonej woli bym z Google Hangouts nie skorzystał, bo jeśli już muszę korzystać z niewolnych wynalazków, to mam Skype od Microsoftu, ale w pracy była potrzeba skontaktowania się grupowo, grupa już ma wybrane rozwiązanie i używa Hangouts, więc… co może pójść źle? System to Debian Wheezy plus backporty, czyli nic nietypowego czy niestabilnego. Skype od Microsoft daje gotową paczkę deb, co prawda multiarch, a nie natywne amd64, ale działa bez problemu, po dodaniu architektury i386. Google ma opinię firmy bardziej przyjaznej Linuksowi, poza tym na rynek weszli później, więc pewnie bardziej się starają.

Oczywiście wszedłem na stronę Google Hangouts z Iceweasel, czyli Firefoksa. Są wersje dla mobilków, jest pobierz na swój komputer. Klikam… i komunikat, że ta przeglądarka się nie nadaje, pobierz sobie Chrome. Czyli nie wersja Hangouts na komputer, tylko jako dodatek do przeglądarki. Pod pewnymi względami może to mieć nawet sens, zresztą mam Chromium (opensource’owa wersja Chrome), co mi szkodzi wrzucić tam Hangouts? Odpalam Chromium, strona Google Hangouts i… link do wersji „stacjonarnej” nie jest aktywny.

No dobrze, wiem, że dają działającą paczkę z Chrome, więc chociaż nie potrzebuję tej przeglądarki, to mogę ją zainstalować i tylko do tego jednego celu mogę jej używać. Instalacja Chrome bez problemu (nie, nie będzie domyślną przeglądarką w systemie…), wchodzę na stronę Hangouts, dodał appkę. Uruchamiam i… chat działa, ale w momencie kliknięcia rozmowy video (znaczy audio/video, samego audio chyba się nie da, choć by wystarczyło…) nie uruchamia jej w Chrome, tylko… próbuje uruchomić w Iceweasel, który jest domyślną przeglądarką. Tym razem jednak proponuje pobranie pluginu w postaci paczki deb. Nie można tak było od razu? Pobieram oferowany plugin, instaluję i…

dpkg: problemy z zależnościami uniemożliwiają skonfigurowanie pakietu google-talkplugin:
google-talkplugin zależy od libc6 (>= 2.14); jednakże:
Wersją libc6:amd64 w systemie jest 2.13-38+deb7u8.

Brawo Google!

Źródło: http://gifrific.com/wp-content/uploads/2012/04/joker-clap-hq.gif

Oczywiście problemu pewnie by nie było, gdyby Chrome był domyślną przeglądarką w systemie, ale nie ze mną te numery, Brunner^HGoogle. Skończyło się odinstalowaniem i Chrome, i nieszczęsnego pluginu na podstawowym systemie. Oczywiście za tydzień problemu pewnie nie będzie, bo najprawdopodobniej Jessie będzie stable, ale póki co – nie da się w rozsądny sposób korzystać z Hangouts pod stabilnym Debianem.

Oczywiście z tym nie zainstalowałem z tytułu lekko przesadzam[1], bo nie kijem go, to pałką i skończyło się szybkim postawieniem osobnej wirtualki (AQEMU, KVM) tylko pod Hangouts. Ale faktem jest, że w podstawowym systemie poległem.

Pozytyw całej akcji jest taki, że przetestowałem instalator Jessie (rc2). Jest parę fajnych opcji, choćby wybór, które dokładnie środowisko chcemy zainstalować (jest LXDE i działa w zasadzie od kopa – jedyna rzecz, która wymagała interwencji to wyciszony mikrofon – musiałem doinstalować jakiś xfce4-mixer, który chyba zresztą jakoś nie zapamiętuje ustawień. Potem się przyjrzę dokładniej, podobnie jak udostępnieniu wbudowanej kamery do wirtualki…

[1] Pierwotnie w tytule nie było nic o wersji Debiana.

Powtarzalne budowanie pakietów w Debianie

Dyskusji nt. zgodności pakietów binarnych z dostarczanymi źródłami teraz nie znajdę (podrzucenie mile widziane), ale Półtora roku temu pisałem o braku weryfikacji, czy kod źródłowy jest zgodny z wersją binarną. Pamiętam, że w różnych dystrybucjach wyglądało to różnie, a chyba w żadnej dobrze. IIRC na testowanym pakiecie różnice w Debianie były minimalne, bo dotyczyły tylko timestampu ale… były. W praktyce dla użytkownika końcowego oznacza to brak możliwości łatwego zweryfikowania, czy dostarczony (bardziej: deklarowany) kod źródłowy odpowiada dostarczonej wersji binarnej pakietu[1].

Implikacje są oczywiste: możemy uruchamiać co innego, niż sądzimy, że uruchamiamy. Z jednej strony może dojść do naruszenia licencji (zwł. GPL) i użytkownik może mieć problemy z modyfikacją oprogramowania, z drugiej, bardziej praktycznej: mogą pojawić się problemy z bezpieczeństwem. Nie tylko developer może dołożyć coś od siebie (developerom ufamy),. Także atakujący może w wyniku włamania przejąć klucze jakiegoś developera i wprowadzić zmodyfikowaną wersję binarną pakietu do repozytorium.

Wiadomo, że dokładna i systematyczna kontrola podstawą zaufania, w związku z tym w Debianie ogłoszono projekt Reproducible Builds. Ma on na celu dostarczenie narzędzi i środowisk do kontroli. Oraz poprawę pakietów tak, aby można było w prosty sposób sprawdzić zgodność pakietu binarnego ze źródłem. Czyli każdy będzie mógł łatwo odpowiedzieć na pytanie: czy dany pakiet powstał z deklarowanego źródła?

Projekt dotyczy raczej przyszłych wersji Debiana, ale na pewno jest krokiem w kierunku zwiększenia wolności użytkowników i bezpieczeństwa.

Wg danych projektu Reproducible Builds w chwili obecnej udało się potwierdzić powtarzalność budowy ponad 83% pakietów z repozytorium main dla Debiana unstable.

[1] Nie miejsce na dyskusję nad wyższością dystrybucji pakietów w źródłach nad wersją binarną i odwrotnie.