Tag: debian

Opublikowane w

Grub2, memmap i problemy z upgrade do Squeeze.

Ostatni upgrade systemu (z prywatnych, głównie desktopy) do Squeeze’ego zakończony. Zasadniczo bez zgrzytów, poza tym, że wyglądał trochę inaczej niż inne, a pakietów było mnóstwo. Naprawdę mnóstwo, apt-cacher wiele nie pomógł, choć inny desktop też z niego korzysta. KDE4 robi swoje, niestety. Łącze 1Mbps to przeżytek. No i jeszcze szopka z upgrade do grub2 była.

Desktop ma uszkodzony RAM, więc korzystam ze sposobu na uszkodzoną pamięć RAM, który opisywałem wcześniej. W grub miałem wpis:

/boot/vmlinuz-2.6.32.11 root=/dev/hda2 ro memmap=2M$311M

Przy dist-upgrade wszytko wykrył poprawnie, łącznie z dodatkowymi opcjami. Oczywiście skorzystałem z proponowanej opcji chainload (i całe szczęście…). Po reboocie wchodzę do grub2, tam wybieram nowy kernel (dystrybucyjny) i… reboot. Bez żadnego komunikatu. Niefajnie. Niestety to samo powtórzyło się przy wybraniu z grub2 kernela własnej roboty, którego używałem na Lenny.

Za to – ku mojemu zdziwieniu – ze starego gruba nowy kernel zadziałał. Co ciekawe, w przeciwieństwie do wersji z Lenny’ego, obsługiwał poprawnie wpis dla memmap – przy szybkim teście podlinkowanym wyżej nie było błędów.

Chwila zabawy i jasne było, że coś się skopało. Zamiast memmap=2M$311M było widoczne… memmap=2M11M. WTF? A po usunięciu opcji memmap wszystko ładowało się poprawnie (tyle, że korzystając ze skopanego obszaru RAM). Chwila googlania i wydało się, że do /etc/default/grub trafiła linia

GRUB_CMDLINE_LINUX="memmap=2M$311M"

która po przetworzeniu przez *sh będzie faktycznie wyglądała tak, jak wyglądała, bo $3 zostanie uznane za zmienną… Grub2 dodatkowo wymaga w swoim menu postaci memmap=2M\$311M czyli ostatecznie poprawna wersja w pliku /etc/default/grub to:

GRUB_CMDLINE_LINUX="memmap=2M\\\$311M"

Jutro zgłaszam buga.

Opublikowane w

BitlBee czyli ostateczny klient CLI do… wszytkiego.

BitlBee to multikomunikator czyli klient… wszystkiego (o czym dalej), działający jak stary, dobry IRC. Filozofia jest specyficzna, bo multikomunikatorem jest demon, z którym komunikujemy się jak z serwerem IRC. Czyli bierzemy dowolnego klienta IRC (np. konsolowe irssi), którym podłączamy się do serwera BitlBee. Potem już w zasadzie analogicznie – mamy kanał (z użytkownikiem @root, który z systemowym root nie ma nic wspólnego), a kontakty dodane przez serwisy są nickami na tymże kanale. Rozmowa jak z każdym innym użytkownikiem IRC – można w osobnym oknie (domyślne i IMO najwygodniejsze), można w oknie wspólnym…

Rozstrzał wersji jest ogromny – w nowowydanym Squeeze jest bitlbee jest w wersji 1.2.8-1, w unstable – 3.0.1-1. Szybka lektura changeloga na stronie projektu i okazuje się, że zaliczyli przeskok numeracji z 1.3 na 3.0, przy czym wersja 1.3 zaliczyła całkowite przepisanie kodu IRC i tyle zmian, że w changelogu nie wymieniają. Dodatkowo, zarówno bitlbee-libpurple, czyli transport do innych sieci, jak i bitlbee-plugin-otr, czyli implementacja OTR, nie występują w wersji dla Squeeze, więc wybór był prosty – 3.0.1.

Oczywiście nie jest idealnie – już na starcie zgłosiłem buga z nieustawianiem haseł domyślnie, ale to łatwo poprawić samodzielnie. Poza tym, ma to średni wpływ, bo domyślnie demon dostępny jest tylko lokalnie, a do dostępu do samych serwisów i tak wymagane jest kolejne uwierzytelnianie.

Kolejny bug, również zgłoszony (w sumie do upstreamu), to korzystanie jedynie z niesolonych MD5 (i jedynie z nich) do przechowywania skrótów haseł. Okazało się, że błędnie, bo MD5 są solone (ale nadal tylko z MD5 można korzystać, co zbyt fajne nie jest, ale wystarczy mocne hasło do głównego konta).

W czasie testu opierałem się na tych dwóch opisach BitlBee. Nie twierdzę, że są najlepsze, ale mi wystarczyły w zupełności. Do wyboru jest sporo innych w sekcji External docs na stronie projektu. Tak naprawdę sam program posiada bardzo dobry, dostępny w każdej chwili tutorial i pomoc.

I to w zasadzie tyle. Korzystanie jest równie dobre i wygodne, na jakie wygląda z opisu. Oczywiście, jeśli komuś pasuje ircowy sposób rozmowy i obsługi. Obsługiwany jest nie tylko Jabber, ale także Twitter (czyli też identi.ca), MSN, OSCAR (AIM/ICQ). Wygląda, że BitlBee potrafi korzystać z libpurple, więc liczba protokołów raczej będzie szybko rosnąć. Teoretycznie obsługiwane są także GG, IRC (trochę nie widzę sensu, ale jest…), bonjur i wiele innych protokołów.

Na deser smaczek: BitlBee jest leciutkie. Lżejsze od centerim (dawniej centericq), z którego korzystałem do tej pory. Testy na laptopie zdane na piątkę (tylko jabber), jak tylko zrobię upgrade routera do Squeeze, to na pewno zmieniam centerim na BiltBee + irssi.

PS. Dla nieangielojęzycznych: mój krótki tutorial konfiguracji BitlBee po polsku.

Opublikowane w

T(A)ILS czyli jak zachować anonimowość w Internecie.

Dawno temu pisałem o pomyśle na dystrybucję anonimizującą. Miało to działać na zasadzie liveCD uruchamianego – głównie dla wygody – z maszyny wirtualnej, wyposażonego w domyślne ustawienia utrudniające identyfikację użytkownika i domyślnie wysyłającego wszystkie dane WWW za pośrednictwem sieci TOR. Już samo użycie liveCD w znacznym stopniu utrudnia identyfikację – po uruchomieniu gubione są wszelkie informacje zawarte w ciasteczkach, LSO, historii odwiedzanych stron, cache, jak również cechy charakterystyczne systemu/przeglądarki są wspólne dla wszystkich instancji systemów bootowanych z jednego obrazu.

Projekt Anonymix nie wyszedł poza fazę planów (żaden build nie był w pełni działający i nie został opublikowany), ale znalazłem coś, co nie tylko jest praktycznie dokładnym odpowiednikiem tego, co chciałem realizować, ale bardzo ładnie rozwija tę ideę. Mowa o T(A)ILS, czyli The (Amnestic) Incognito Live System.

T(A)ILS to dystrybucja rozpowszechniania w postaci liveCD i liveUSB skonfigurowana tak, by cała komunikacja odbywała się przez sieć TOR i aby nie zostawiać żadnych śladów użycia danego systemu i przeprowadzanych operacji na dyskach (dopóki wyraźnie o to nie poprosimy). Oczywiście w przypadku uruchomienia z poziomu maszyny wirtualnej tak dobrze nie będzie – przykładowo dane mogą zostać – i zapewne zostaną – przekazane do hosta gospodarza i mogą zostać zapisane na dysku np. w pliku swap, ale dokładnie taką samą wadą obarczony był Anonymix. Warto podkreślić, że tak naprawdę nie wpływa to na anonimowość – jeśli chodzi o identyfikację zdalną jest to bez znaczenia. Klasyczne bezpieczeństwo vs. wygoda – bootowanie fizycznej maszyny z liveCD jest mniej wygodne, ale bezpieczniejsze.

Warto zauważyć, że T(A)IlS nie tylko pomaga zachować anonimowość, ale pomaga zabezpieczyć przed przechwyceniem danych na różne sposoby – od zabezpieczenia przed keyloggerami za sprawą wirtualnej klawiatury, przez zapewnia komunikację Jabberem z użyciem OTR i szerokie wsparcie dla GPG. Do tego T(A)ILS wyposażony jest narzędzia do obróbki dźwięku, skanerów obróbki obrazów, wspólnej edycji tekstów i wykonywania tłumaczeń… Wygląda na niezłe zaplecze dla Wikileaks czy Anonimowych.

Projekt wygląda na aktywnie rozwijany, więc nie pozostało mi nic innego, jak definitywne pogrzebanie Anonymiksa, przekazanie pomysłów (o ile już nie są wdrożone; patrząc na listę błędów – większość jest) i ew. pomoc przy rozwoju T(A)IlS. Na tę chwilę dostępna jest wersja 0.6.2 oparta na Debianie Lenny, więc z testem poczekam raczej na coś opartego o Squeeze, bo sporo się pozmieniało.