Hej hop, Google stop!

W ramach zmniejszania ilości informacji, którą Google gromadzi o ludziach (w tym o mnie), a które wykorzystywane są różnie, po przeczytaniu wpisu o tym, czy groźniejszy jest Facebook, czy ustawa hazardowa, postanowiłem coś zmienić.

Trochę poczytałem, stwierdziłem, że większość rzeczy, które Google może gromadzić o mnie nie dotyczy mnie (albo nie mam wpływu, bo moją pocztę przeglądają na gmailowych kontach ludzi, do których wysłałem), bo zwyczajnie nie mam konta lub już wyłączyłem. Na testowanie rozszerzeń jakoś nie miałem ochoty, więc ostatecznie zmieniłem domyślną wyszukiwarkę w przeglądarce. Nie jest już nią Google, na razie jest to Yahoo. Myślałem też o Bing, ale dodanie do Fx wymaga instalacji pluginu, a Yahoo już było.

Docelowo pewnie będzie to jakiś Dogpile, ale nad tym muszę się jeszcze zastanowić (poczytać warunki użytkowania, politykę prywatności, przemyśleć, czy jest sens, bo taki agregator jednak nadal przekazuje zapytania do Google).

Raport z użytkowania za jakiś czas, a do wcześniejszego wpisu (miałem napisać łącznie z wrażeniami o tym) skłonił mnie news o tym, że Ubuntu zmienia domyślną wyszukiwarkę na… Yahoo właśnie. Nie mam złudzeń, Ubuntu nie chodzi o prywatność, czy zmniejszenie dominacji Google, tylko o kasę, co jest wyraźnie napisane, niemniej coś się ruszyło w sprawie „jedynej” wyszukiwarki. Może początek końca Google?

IPREDatror czyli jak olać ustawę hazardową za 5 euro miesięcznie.

O ustawie hazardowej zrobiło się głośno ostatnio, a tak się złożyło, że wystartował IPREDator, który ma pomóc w zachowaniu anonimowości. Działa na zasadzie tunelu VPN, czyli – przy odrobinie szczęścia – w praktyce pozwoli obejść narzucone ustawą ograniczenia (no chyba, że zablokują domenę ipredator.se, ale pewnie i na to znajdzie się obejście…) i – w przeciwieństwie do darmowego Tor – pozwoli na sensowne transfery (autorzy piszą o transferach rzędu 2-120 Mbit). Aby korzystać z usługi, należy zapłacić 15 euro za kwartał.

Artykuł na Heise Online jest bardzo dobry, zwraca uwagę na różne aspekty (niezupełną anonimowość, bo IP to nie wszystko; zależność od firm trzecich, co poruszył ostatnio reuptake; ładnie widać skomplikowaną i problematyczną – moim zdaniem – konfigurację), dlatego nie przedłużam, tylko zachęcam do przeczytania.

Komputerowo lipa.

Miniony tydzień muszę zaliczyć do komputerowo nieudanych. Z wielu względów.

Chciałem zrobić benchmark encfs w połączeniu z padlock_aes na T5520, ale po pierwsze padlock_aes działa jak chce – na openssl dobre wyniki niezależnie czy moduł załaduję, czy wręcz przeciwnie – usunę.

Z kolei encfs się zbuntowało i jak tworzę katalog, to się montuje i działa, ale po odmontowaniu i próbie kolejnego montowania krzyczy, że błędne hasło, chociaż hasło jak najbardziej poprawne. Z kolei jak utworzę katalog na innej maszynie i skopiuję, to jak najbardziej działa. W obu przypadkach ta sama wersja encfs, ten sam tryb (preconfigured paranoia mode). Podejrzewam zależność od ścieżki, niby jest taka opcja, ale to by bez sensu było lekko…

Na dodatek wygląda, że encfs nie korzysta z dobrodziejstwa padlock_aes, chociaż korzysta z openssl. Nawet patch znalazłem dla openssl i ssh, tyle, że openssh w wersji ubuncianej. I rekompilacja, więc mi się nie chce. Poza tym, niekoniecznie o ssh chodzi (chociaż patch na openssl może pomóc). I tak jakoś się tym wszystkim do testu zniechęciłem.

Na osłodę niemal kupiłem sobie do domu T5710, bo Tora na OpenWRT jednak chyba stawiać nie będę, choć paczka jest (nie znaczy, że działa) – niby to Linux, ale jakiś biedny, no i zasoby „nieco” do życzenia pozostawiają. Niemal, bo nie znalazłem wyniku cat /proc/cpuinfo dla TM8600 z taktowaniem 1200 MHz. Inne wersje procesora jak najbardziej znalazłem i całkiem ciekawie ten model wygląda. Może nawet jeszcze zrobiłbym na nim – poza netem – szafę grającą (czytaj: komputer nadający audio z mp3 oraz radia internetowego podpięty do wieży). Tylko dysk trzeba by podpiąć, ale to w sumie nie problem. No i pytanie, czy dysk, czy zainwestować całe 5 zł w czytnik SD i do tego karty microSD stosować…

Dołóżmy do tego, że na na lapku miłej (test będzie, kiedyś) w Debianie w wersji testing Nvidia zaczęła stroić fochy. Wróć, nie zaczęła. Po upgrade nie daje się zainstalować moduł do Nvidii łącznie z Xorg (albo rybka, albo akwarium). Nie żebym jakoś walczył specjalnie, bo nie mam kiedy – komp nie mój, a system tylko awaryjnie, ale do porażek doliczyć trzeba. Ostatecznie starczy stable, na którym działa od kopa (za to nie działa ściemnianie klawiaturą i w sumie tylko po to upgrade do testinga miał być). Czyli szybki reinstall, bo downgrade’u w Debianie nie ma (a gdzie jest? ;-)).

Czarę goryczy przepełnił niedziałający z niewiadomych przyczyn na mojej podstawowej przeglądarce (Iceweasel) blipowy asystent. Podejrzewam podkręcone ustawienia prywatności, bo w Operze działa, ale sprawdzać mi się nie chciało.

No i okazuje się, że nawet z pomocą blipowego asystenta nie jestem w stanie przypomnieć sobie nazw rozszerzeń do Fx, dzięki którym edycja notatek w Blox ma być milsza. Wbudowane edytory ssą niemiłosiernie – albo nie ma podglądu strony, albo korzystamy z powalonego TinyMCE. Oczywiście nie jest powiedziane, że za sieczkę z ostrymi nawiasami odpowiada edytor, a nie paranoiczne zabezpieczenia Blox.

Z pozytywów – Folksr spięty z Blox, zrobiony opis integracji na bloksowym wiki. Tylko to nijak się ma do komputerów.

Spięcie folksr i blox – praktyczne wykorzystanie tagów.

Od zawsze brakowało mi na Bloksie tagów. Niedawno pojawiły się i tagi, i miejsce na kod HTML pod wpisem. Na dodatek „programowalne”, czyli pozwalające na użycie zmiennych. 1+1=2, czyli pora na praktyczne wykorzystanie tagów, czyli automagiczne robienie odnośników do innych wpisów o podobnej treści na innych blogach za pośrednictwem serwisu Folksr. Folksr aktualnie wspiera platformę Jogger, wszystkie blogi oparte na WordPressie, oraz daje się spiąć z Blox. Poniżej opis spięcia.

Krok pierwszy – rejestrujemy się w serwisie Folksr. Od razu uprzedzam, że ostatnimi czasy było trochę zamieszania z mailami wysyłanymi do .pl – obecnie dochodzą, ale różnie z tym ostatnio było, więc proponuję cierpliwość.

Krok drugi – dodajemy bloga w serwisie. Podajemy adres, tytuł, podstawowy język z wpisami na blogu, określamy, ile ma być odnośników pod każdym wpisem. Jest też możliwość zawężenia grupy blogów, do których linkujemy (domyślnie korzysta tylko z tagów).

Następnie w Blox wchodzimy w Ustawienia -> Pozostałe i w Pole na dodatkowe tagi META wklejamy podany we Folksr kod weryfikacyjny. Po zatwierdzeniu zmian, możemy kliknąć Zweryfikuj, aby potwierdzić Folksrowi, że to naprawdę nasz blog.

Mnie poprosił jeszcze o wgranie pliku o określonej nazwie i zawartości (Notki -> Pliki), ale chyba zostało to wyłączone aktualnie.

Pora na skorzystanie z dobrodziejstwa zmiennych na Blox: wchodzimy w Ustawinia -> Pozostałe i w polu Dodaj pod każda notką wstawiamy kod:

[div id="folksr"] [/div]
[script type="text/javascript"
src="http://folksr.com/script.php?title={tytul}&tags={tagi_a} "][/script]

Oczywiście zamiast nawiasów kwadratowych muszą być ostre, ale znając Blox, znów mi je wytnie przy każdej edycji, więc wolę napisać tak.

Od tej chwili każde wejście (czyjekolwiek z włączoną obsługą JS) na stronę z wpisem będzie powodowało po pierwsze dodanie tegoż wpisu do bazy Folksr, po drugie, powinny pojawić się odnośniki do wpisów o podobnych tagach.

Jeśli chodzi o wygląd wpisów, to ustawiamy go w serwisie Folksr w Skin Editor (mam angielski jako podstawowy w przeglądarce, więc nie wiem, czy to się nie spolszczy). Ja używam:

[div]
[p]
Podobne wpisy:[br/]
{entry}
[a href="@@link"]@@title[/a] by [b][a href="@@profile"]@@author[/a][/b][br /]
{/entry}
[/p]
[/div]

Oczywiście ponownie zamieniamy wszystkie nawiasy kwadratowe na ostre.

Tyle jeśli chodzi o szybkie howto. Zakładam oczywiście, że nasze wpisy na Blox są już otagowane.

Folksr to młody, polski projekt (więcej o nim można poczytać na blogu autora, a tutaj o algorytmie szukania podobnych wpisów).

Sam projekt nie jest bez wad/błędów/niedoróbek (na razie wyszło skopane kodowanie pl-znaków przy wpisach z Blox – któż by spodziewał się ISO-8859-2? – ma być poprawione). Ja zachęcam do zgłaszania błędów za pośrednictwem Blip (użytkownik folksr oraz tag folksr) no a przede wszystkim do korzystania z serwisu – mi się pomysł bardzo podoba. Autor co prawda jest zajęty, ale może da się go rozruszać. 😉

UPDATE: Blox przy każdym wejściu w edycję w Ustawienia -> Pozostałe radośnie zmienia ciąg &tags na &tags (shift-7 amp dwukropek na shift-7 tags), co – jeśli nie poprawimy tego, a klikniemy Zapisz, powoduje niedodawanie się nowych wpisów do Folksr. Należy mieć na to baczenie za każdym razem w przypadku zmian w tej zakładce.

UPDATE2: Opis integracji dodany do Blox wiki.

Root tylko do odczytu (flash).

Trochę czasu minęło, odkąd pisałem o kluczu USB jako partycji root i tylko do odczytu. Oczywiście, jak się spodziewałem, nie wyczerpałem tematu i parę rzeczy wyszło w praniu.

Pierwsze – i w sumie najważniejsze – co wyszło – po przemontowaniu / w RW, instalacji nowych pakietów – nie daje się przemonotować w RO. Winnych było dwóch – blkid.tab oraz usunięte pliki nadal używane przez proces.

Szczęśliwie w trakcie poszukiwań rozwiązania wpadłem na ReadonlyRoot na Debian Wiki, gdzie opisane jest, co zrobić. W przypadku blkid.tab należy zrobić symlinka i ustawić zmienną środowiskową. W przypadku używania usuniętych plików – zrestartować odpowiednie serwisy (polecenie checkrestart z pakietu debian-goodies). Poza tym, skorzystałem z patentu na mtab.

Na koniec potwierdzenie pierwszego spostrzeżenia – jest stabilnie. Bez UPSa 14 dni było.

 

Przepisy o retencji danych wchodzą w życie.

Jakiś czas temu pisałem o rozporządzeniu w sprawie retencji danych, jak można się było spodziewać, weszło ono w życie.

VaGla komentuje sprawę szerzej, natomiast mnie interesują zmiany, które zostały wprowadzone, z punktu widzenia administratora sieci ethernetowej.

Przede wszystkim pojawiło się piękne, wieloznaczne słowo lub. Chodzi o §6 rozporządzenia. Port sieciowy (na dodatek o zmienionej definicji), został przeniesiony z dotychczasowego punktu 1 d) w brzmieniu adres IP i numer wykorzystywanego portu sieciowego do punktu 1 f) w brzmieniu identyfikator zakończenia sieci, w którym użytkownik końcowy uzyskał dostęp do Internetu, w szczególności identyfikator cyfrowej linii abonenckiej DSL (Digital Subscriber Line), numer wykorzystywanego portu sieciowego lub adres MAC urządzenia końcowego inicjującego połączenie.

Czyli jeśli logujemy MAC adres (oczywiście nikt nie bierze pod uwagę, że po pierwsze to się zmienia, po drugie sporo kart zintegorwanych nie ma swojego natywnego MAC, po trzecie, że MAC adresy potrafią się – nawet sprzętowo – powtórzyć, ale nie wymagajmy za wiele), to nie trzeba logować portu.

Kolejna sympatyczna (w zasadzie nieunikniona) zmiana, to §14, mówiący o sześciomiesięcznym okresie dostosowawczym dla tych, którzy w dniu wejścia w życie nie spełniają wymagań rozporządzenia. Wejście w życie nie zostało zmienione – był nim 1 stycznia 2010 r.

Czyli ci, którzy nie spełniają wymogów rozporządzenia, mają przed sobą pracowite pół roku.

Szkoda tylko, że rozporządzenie nadal nie jest jasne. Część rzeczy wyjaśnia (albo zaciemnia) dopiero uzasadnienie. Przykładowo, jeśli chodzi o pocztę elektroniczną napisano Odnośnie usługi poczty elektronicznej podkreślić należy, że ustawa zalicza do usług telekomunikacyjnych przekazywanie poczty elektronicznej, a nie usługę poczty elektronicznej.

Zapraszam do uwag, szczególnie prawników i administratorów „osiedlówek” i sieci radiowych, zarówno tych większych, jak i tych mniejszych.

Jak bezpiecznie korzystać z uszkodzonej pamięci RAM bez BadRAM.

BadRAM był fajny, ale jest nieutrzymywany. Ostatnią działająca u mnie wersja była do kernela 2.6.25.x, późniejsze, choć istniały (np. dla 2.6.29), to nie udało się ich – wbrew wcześniejszej radości – zmusić do poprawnego działania – nadal pojawiały się błędy np. na liczeniu sum kontrolnych.

Winny w tej maszynie jest ewidentnie RAM, co zostało już dawno stwierdzone, ale maszyna na tyle niekrytyczna, że inwestować się nie opłaca (poza tym, szkoda środowiska), a ze starszym (tj. 2.6.25.x) kernelem spokojnie i poprawnie działa. Poza tym, przecież to Linux, więc da się poprawić. I jaki uroczy temat do notek jest. 😉 Z okazji świątecznej wizyty w domu, postanowiłem jednak zerknąć, czy nie pojawiły się patche BadRAM do jakichś nowszych kerneli (serii 2.6.3x, znaczy).

Nie pojawiły się, ale zamiast tego, trafiłem na pierwszej stronie wyników na sposób radzenia sobie z uszkodzoną pamięcią pod Ubuntu, który w ogóle z BadRAM nie korzysta. Chwilę później trafiłem na ten wpis. Okazuje się, że za pomocą parametrów, które można przekazać kernelowi, w szczególności mem=XX oraz memmap=X$YY, można wyłączyć obszary pamięci z użytkowania, co przekłada się w praktyce, na możliwość bezpiecznego korzystania z uszkodzonej i dotychczas powodującej błędy pamięci. Więcej o parametrach w kernelowym Documentation/kernel-parameters.txt, ale na potrzeby tego zagadnienia wystarczą te dwa.

Pierwszy parametr (mem=) ogranicza wykorzystaną pamięć. Jeśli uszkodzenie jest w okolicy 312 MB (memtest+ prawdę powie), to mem=310M co prawda obniży dostępną pamięć do 310 MB, za to system będzie działał bez problemów. Tyle tylko, że stracimy 200 MB pamięci. Trochę sporo, zwłaszcza, jeśli całość do dyspozycji to tylko 512 MB.

Drugi (memmap=) jest ciekawszy, bo rezerwuje X pamięci od adresu YY. Przykładowo memmap=10M$305M oznaczy pamięć od  305 MB do 315 MB jako wykorzystaną. Czyli stracimy raptem 10 MB, a zyskamy niezawodny system. Tyle teorii. W praktyce na dystrybucyjnym 2.6.26 z Lenny’ego, mem=300M działało poprawnie (najprościej sprawdzić przez free -m), natomiast memmap=10M$305M był radośnie olewany – nadal pokazywało dostępną całą pamięć.

Przyczyny tego stanu rzeczy nie udało mi się ustalić (podejrzewam limit 4GB zamiast 1GB, błąd w kernelu lub korzystanie z initrd – jeśli ktoś zna odpowiedź, to proszę o info), natomiast skompilowanie własnego 2.6.32.2 na podstawie konfiga od 2.6.25.x (z którego spatchowanego BadRAM korzystałem do tej pory) rozwiązało problem – memmap=2M$311M, czyli wyłączenie tylko 2 MB spowodowało, że system działa poprawnie.

Ponieważ najłatwiej zaobserwować błędy było dotychczas na sumach kontrolnych, to testowanie wykonałem prostym skryptem (brzydki bash napędzany perlem – pewnie dałoby się prosto przespisać na gołego basha, ale kto tam ma czas…; skrypt na końcu wpisu). Stosunkowo duży plik (większy, niż dostępna pamięć RAM, mój tworzony przez dd if=/dev/urandom of=random.dat bs=1MB count=1024), z losową zawartością (tworzony raz, bo czasochłonne), liczenie sum kontrolnych. Jeśli błąd pojawi się w buforze dyskowym, to przy braku wielkiego pecha suma kontrolna będzie się różnić przed i po skopiowaniu. Zapuszczone w pętli, z logowaniem do pliku – nawet przy uszkodzonej pamięci nie wystarczy 1 przebieg – błąd nie pojawia się za każdym razem. Natomiast choćby jeden błąd oznacza, że coś jest nie tak jak być powinno.

Podstawą jest jednak free -m. Jeśli on nie widzi mniej pamięci, to można nie zaczynać nawet ze skryptem.

Jeśli po dłuższym teście brak błędów (pojedynczy błąd oznacza, że nie jest dobrze), to wystarczy dopisać linię do konfigu gruba, by przy każdej aktualizacji kernela dodawał do parametrów określony argument:

#kopt=root=/dev/hda2 ro memmap=2M$311M

Dzięki temu możemy korzystać z dowolnej (najnowszej!) wersji jądra, bez upierdliwego patchowania (cóż, patche badram były dość kijowe, włączenie z tym, że zdarzało im się mieć literówki uniemożliwiające kompilację).

Na koniec wspomniany skrypcik:

#!/usr/bin/perl
$src="/random.dat";
$dst="/tmp/memtest_tmp.dat";
$log="memtest_copy.log";
if (-f $dst){
   system (" rm $dst ");
}
system (" date >> $log ");
while (1){
  system (" cp $src $dst ");
  $res = `md5sum $dst`;
  $res2 = `sha1sum $dst`;
  $res_ = `md5sum $src`;
  $res2_ = `sha1sum $src`;
  $check = "ERROR";
   if (($res == $res_) && ($res2 == $res2_)){
     $check="OK";
   }
system (" echo \"$check $res $res_ $res2 $res2_ \" >> $log ");
system ("rm $dst");
}

Podsumowując: żegnaj BadRAM!