Karol „Zal” Zalewski

Wygląda na to, że w kolejnej wersji Ubuntu przeznaczonego na netbooki, czyli Ubuntu Netbook Remix 10.4, pojawi się wsparcie dla usługi Google Docs. Co więcej, domyślnie zastąpi ona aplikację OpenOffice.org. I tutaj moim skromnym zdaniem pojawia się problem, który należałoby ugryźć z nieco szerszej perspektywy.

Usługi z chmur (tj. SaaS) to nie tylko popularna obecnie forma udostępniania oprogramowania (konkretniej - jego funkcjonalności), ale również powrót do korzeni informatyki, kiedy to królowały ogromne maszyny typu mainframe oraz terminale umożliwiające komunikację z nimi. Maszyny takie nie tylko udostępniały oprogramowanie i moc obliczeniową użytkownikom, ale również miejsce na ich prywatne dane. Pomimo wprowadzenia pewnej decentralizacji (zamiast mainframe mamy „chmurę”) i formy komunikacji (sieć lokalna wyparta przez sieć globalną) obecne rozwiązania są bardzo podobne do koncepcji sprzed kilku dekad. Co to oznacza? Przede wszystkim to, iż równie aktualne pozostają problemy, które miały miejsce i wtedy.

Ochrona prywatności i odpowiedzialność za dane użytkowników jest chyba najbardziej palącym problemem. Udostępniając komuś nasze prywatne dane musimy mieć pewność tego, iż powierzamy je w dobre ręce. Nie chcemy, aby ktoś nam w nich grzebał, udostępniał osobom trzecim, czy też utracił i nie był zdolny do ich przywrócenia. Oddając nasze dane osobom trzecim zawsze jesteśmy na to narażeni, nawet jeśli warunki korzystania z usługi dają nam pewną ochronę. Dlaczego? Firma nie stanowi bytu oderwanego od rzeczywistości. Często też korzysta z usług innych firm, a sama w sobie operuje w środowisku, które w dużym stopniu jest podatne na działania ze strony państwa. To, co dla nas jest naturalne może wyglądać zupełnie inaczej w państwie po drugiej stronie globu.

Konieczność działania w trybie online to również istotny problem. Usługa to nie to samo, co samodzielnie działając oprogramowanie. W celu jej wykorzystania konieczny jest dostęp do usługodawcy, a urządzenia, szczególnie te mobilne, pomimo i tak znacznej elastyczności w zakresie dostępu do Sieci nadal mogą działać w oderwaniu od niej. Jak wtedy poradzić sobie z dostępem do danych w chmurze oraz usług?

SaaS to również idealna koncepcja dla producentów oprogramowania. Owszem, wymaga to od nich pewnego nakładu pracy poświęconego na administrację zapleczem udostępniającym moc obliczeniową oraz przestrzeń na dane użytkowników, ale... W zamian otrzymują możliwość pełnej kontroli nad tym, kto i w jaki sposób korzysta z ich oprogramowania. Rynek wtórny lub piractwo? Można o nim spokojnie zapomnieć. Natomiast przy odrobinie chęci i korzystając z nieświadomości użytkowników można doprowadzić do stanu, w którym to użytkownicy zostaną uzależnieni od naszych usług. Vendor lock-in. Brzmi nierealnie? A próbowaliście kiedykolwiek dokonać migracji np. z Google Picasa do innej usługi? A co zrobicie, gdy usługodawca zwiększy ceny swoich usług? Pojawia się tutaj również wolnego i otwartego oprogramowania oraz wykorzystania otwartych standardów. Te ostatnie są szczególnie ważne w przypadku próby integracji kilku usług oraz migracji użytkowników między nimi. Jest to zazwyczaj ta funkcjonalność o której nie myśli się zbyt często przed tym, kiedy to staje się naprawdę konieczna. A co do tego ma wolne oprogramowanie? Wyobraźcie sobie teraz, iż chcielibyście samodzielnie zająć się ochroną własnych danych. Chcielibyście postawić serwer danej usługi korzystając z własnego zaplecza informatycznego i... Niestety, taka opcja nie istnieje. Co więcej, usługodawca nawet, gdy korzysta ze zmodyfikowanego oprogramowania na bazie GPL nie jest zobowiązany do tego, aby je udostępnić. Przecież nie dystrybuuje go.

To, o czym wspomniałem to jedynie szczyt góry lodowej. Można byłoby na ten temat napisać znacznie więcej, wskazać zalety SaaS oraz zaproponować rozwiązanie pewnych problemów związanych z usługami. Nie było to jednak moim celem.

Podsumowując, chciałbym zwrócić uwagę na to, iż rozwiązania oparte o zamknięte oprogramowanie oraz SaaS może i nie są złe, ale budzą pewne obawy i należy mieć do nich dystans. Owszem, pozwalają one firmom zamienić koszta stałe, jakim jest zakup oprogramowania, na koszta zmienne i posiadają szereg innych zaleta, ale... Użytkownicy powinni nie tylko myśleć o tym, co jest „tu i teraz”, ale również o przyszłości. Nikt z nas nie chciałby doprowadzić do utraty swoich danych, ich wycieku, czy też niemożności migracji do innego usługodawcy. A takie zagrożenia niesie ze sobą koncepcja SaaS, gdy korzysta się z niej bez wstępnego jej przeanalizowania.

Wstęp

Wszystko zaczęło się od wpisu, który poczyniłem tydzień temu. Zafascynowała mnie koncepcja małego, bezgłośnego, energooszczędnego i taniego komputera, który mógłby pracować w systemie 24/7 i służyć np. za domowy NAS. Terminal HP Compaq T5520 okazał się być łatwo dostępny. Poniżej znajduje się krótki opis tego, czym jest taki terminal i jakie oferuje możliwości.

Cienki klient HP między popularnym modemem kablowym Motoroli, a routerem Linksysa. Wymiary terminala T5520: około 35 x 10 x 35 centymetrów.

Między bebechami

Na zakupiony przeze mnie model składa się procesor VIA Eden ESP 8000 (rdzeń „Nehamiah” 0,13 µm taktowany 800 MHz, 133 MHz FSB, 64 KiB L2), chipset VIA CLE266, 128 MiB SODIMM (przylutowane do płyty głównej), karta Ethernet 100 Mbit, karta graficzna S3 UniChrome (przywłaszcza sobie 16 MiB z RAM-u) oraz karta muzyczna. Całość dopełniają 4 gniazda USB 2.0, port szeregowy, równoległy, PS/2, VGA, LAN oraz wejście mikrofonowe i wyjście słuchawkowe. Mnie interesowały głównie porty USB, bo i tak większość z pozostałych zostałaby użyta jedynie podczas instalacji systemu operacyjnego. W tym momencie warto od razu odpowiedzieć na pytanie, gdzie taki system można umieścić. Całość dostarczana jest z 64 MB pamięci flash (zawiera ona system Windows CE 5.0) podpiętej przez 2,5" złącze ATA do płyty głównej. Jak łatwo się domyślić, jedną z atrakcji jest możliwość wymienienia jej na 2,5'' dysk twardy z interfejsem ATA - jedyne o czym należy pamiętać to zdobycie odpowiedniej tasiemki IDE (złącza żeńskie-żeńskie). Warto jeszcze wspomnieć, że o ile sam CPU na płycie głównej nie jest zbyt wydajny to całkiem nieźle sprawdza się w przypadku szyfrowania danych cipherem AES ze względu na sprzętowe wsparcie szyfrowania symetrycznego (tzw. VIA Padlock). Przejdźmy teraz do samej kwestii instalacji właściwego systemu operacyjnego.

Instalacja GNU/Linuksa

Pierwsze, co zrobiłem po otrzymaniu sprzętu to jego rozkręcenie oraz wyjęcie na kilka sekund baterii z płyty głównej zasilającej CMOS. W przypadku, gdyby ekran konfiguracji BIOS-u był zabezpieczony hasłem pozwoliłoby mi to na zaoszczędzenie czasu poprzez wcześniejsze usunięcie go w ten sposób. Przy okazji przyjrzałem się wnętrzu urządzenia i sprawdziłem, czy wszystkie kondensatory są w normie. Po złożeniu i podłączeniu peryferiów uruchomiłem terminal trzymając podczas startu klawisz F9 aż do momentu, gdy usłyszałem dźwięk z wbudowanego głośniczka. To oznaczało, że konfiguracja Windowsa CE powróciła do ustawień fabrycznych i będę mógł się z nim nieco pobawić. Zapewniam jednak, że 5 minut w zupełności na to wystarcza. Później pozostało jedynie przejść do konfiguracji BIOS-u i ustawić odpowiednią kolejność bootowania. W moim przypadku koncepcja była prosta.

Nie miałem zamiaru bawić się zbyt długo, dlatego uznałem, że skorzystam z Ubuntu 9.10 Server Edition dostępnego na płycie CD oraz mojego napędu DVD znajdującego się w kieszeni z interfejsem USB. Wbudowany w terminal dysk flash miał posłużyć jako miejsce składowe dla jądra (/boot) oraz GRUB-a, a podpięty przeze mnie 4 GB dysk jako miejsce dla całej reszty systemu (/ oraz swap). Jak pomyślałem tak też zrobiłem. W trakcie instalacji zaliczyłem „freeze”, więc szybko zmieniłem początkowe założenia. Ubuntu zostało wyparte przez Debiana „Lenny” 5.04 w wersji „network install”. I to była właściwa decyzja. Debian kolejny raz uratował mi odwłok. Po długotrwałej instalacji (30 minut? 60?) dorzuciłem jeszcze na pokład serwer SSH i wyłączyłem system. To był czas na przejście w „tryb bezgłowy” i zarządzanie z poziomu innego komputera. Kilka wpisów w domowym DNS-ie i Thor (mitologia nordycka rządzi) był gotowy do działania.

Serwer SSH to nie wszystko. Docelowo terminal ten ma służyć do kilku celów, które spełniać mają serwery: NTP, CUPS, NFS, Samba, czy też webowy interfejs Transmission (klient BitTorrenta). Wszystkie dane, które nie są systemem operacyjnym i jego plikami konfiguracyjnymi muszą być również szyfrowane AES-em. Oznacza to m.in. wykorzystanie dysku 2.5" w kieszeni USB oraz DM-Crypta, który do najmniej zasobożernych rozwiązań nie należy. A jak wygląda kwestia zasobów po czystej instalacji systemu? Brak obciążenia procesora, około 16 MiB pamięci (z pominięciem buforów) pożartej przez system i podstawowe usługi oraz niewielka konsumpcja przestrzeni dyskowej. Jest to indywidualna sprawa, ale warto o niej wspomnieć. System wstaje około minuty licząc od zerwania połączenia SSH po wydaniu polecenia reboot do momentu, kiedy możliwe jest ponowne zalogowanie poprzez SSH. Czas na prawdziwą pracę! Tj. zaraz po upgrade do obecnego wydania testing Debiana, czyli przyszłego „Squeeze”.

Wydajność

To, co miało być głównym przeznaczeniem tego miniserwera to przede wszystkim dostęp do zaszyfrowanego (DM-Crypt, LUKS i cipher AES) dysku z wykorzystaniem NFS. Zacznijmy zatem od samego szyfrowania oraz od tego, jak sprawdza się terminal w takich zastosowaniach. Do testów wykorzystałem polecenie hdparm -t. Na początku zastosowałem to polecenie kilkukrotnie na dysku, który nie został poddany szyfrowaniu:

zal@thor:/media$ sudo hdparm -t /dev/sdb

/dev/sdb:
 Timing buffered disk reads:   94 MB in  3.01 seconds =  31.23 MB/sec

Całkiem niezły wynik, najprawdopodobniej maksymalny możliwy do uzyskania transfer w przypadku wykorzystania USB 2.0. Następnie wykonałem standardowe polecenia cryptsetup mające na celu stworzenie utworzenie i zmapowanie zaszyfrowanej partycji po czym wykonałem na niej test z hdparm. Rezultat jest mało zadowalający:

zal@thor:/media$ sudo hdparm -t /dev/mapper/XXX

/dev/mapper/XXX:
 Timing buffered disk reads:   22 MB in  3.28 seconds =   6.70 MB/sec

A teraz najważniejsze. Ponowiłem ww. operację ładując wcześniej do pamięci moduł padlock-aes dzięki któremu możliwe jest wykorzystanie wsparcia sprzętowego (procesor z rozwiązaniem VIA Padlock) dla szyfrowania przy pomocy ciphera AES. Oto i rezultat:

zal@thor:/media$ sudo hdparm -t /dev/mapper/XXX

/dev/mapper/XXX:
 Timing buffered disk reads:   62 MB in  3.02 seconds =  20.51 MB/sec

Wygląda to zdecydowanie lepiej. Niestety, nie byłem w stanie określić obciążenia procesora w tym momencie. Wygląda jednak na to, że nawet na takim sprzęcie szyfrowanie całego dysku może mieć sens.

Reszta testów (m.in. dot. obciążenia procesora podczas przesyłu danych oraz prędkości przesyłania danych) będzie miała sens dopiero, gdy złożę odpowiednie środowisko testowe. W obecnej chwili uważam, że zbyt duży wpływ na wynik takich badań może mieć router (działający w oparciu o DD-WRT) pośredniczący w przepływie danych oraz kwestia tego, że jeden z komputerów przesyła dane za pośrednictwem sieci bezprzewodowej. Gdyby jednak ktoś chciał przeczytać to, co uzyskałem korzystając z ww. środowiska może to zrobić zaglądając w kod XHTML niniejszego wpisu i szukając najdłuższego komentarza w nim zawartego. Wskazówka, znajduje się on pod niniejszym paragrafem.

Podsumowanie

Niniejszy wpis powstał zaledwie w ciągu kilku godzin od momentu uruchomienia przeze mnie opisywanego terminala. Pomimo tego, że sprzętem jestem zachwycony to należy mieć na uwadze to, że tak krótki okres jest niewystarczający do tego by móc polecić tego cienkiego klienta komukolwiek. Dopiero po miesiącu, czy też dwóch, użytkowania mogą wyjść na jaw jego największe wady, jak i zalety. Obecnie uważam, że sprzęt ten ma naprawdę duży potencjał i może stanowić konkurencję dla samodzielnie składanych, domowych NAS-ów opartych o stare podzespoły. Nie jest demonem prędkości, ale jest tani, cichy i energooszczędny.

Ciąg dalszy zapewne nastąpi w bliżej nieokreślonej przyszłości. Mam zamiar wykonać bardziej precyzyjne i wiarygodne testy dot. wydajności.

Jako, iż ostatnio zrobiło się głośno o projekcie Tor, a w repozytorium Ubuntu znaleźć go nie można (jedynie GNUnet trafił do repo) poniżej znajduje się krótka informacja dot. tego, jak uruchomić Tora i powiązać go z Privoxy pod Ubuntu 9.10.

Można to uczynić w dwojaki sposób. Pierwszym z nich jest samodzielna kompilacja Tora ze źródeł. Drugi, który zostanie przeze mnie opisany, wymaga skorzystania ze skompilowanej już wersji Tora z repozytorium twórców projektu. Wystarczy dodać do /etc/apt/sources.list poniższą linię:

deb http://deb.torproject.org/torproject.org karmic main

Później należy wydać polecenia, które pozwolą na instalację Tora i Privoxy z dodanego przed chwilą repozytorium:

gpg --keyserver keys.gnupg.net --recv 886DDD89
gpg --export A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89 | sudo apt-key add -
sudo aptitude update
sudo aptitude install privoxy tor tor-geoipdb torbutton-extension

Od teraz Tor oraz Privoxy będą usługami uruchamianymi wraz ze startem systemu, co można sprawdzić obserwując zawartość katalogu /etc/rc2.d/. Kolejnym krokiem jest wykorzystanie naszego ulubionego edytora w celu otwarcia /etc/privoxy/config (należy pamiętać o uprawnieniach administratora) i dodania na sam koniec pliku następującej linii (kropka na końcu jest ważna):

forward-socks4a / localhost:9050 .

Od teraz Privoxy będzie wykorzystywał Tora do komunikowania się ze światem zewnętrznym. Na sam koniec wystarczy jeszcze włączyć w przeglądarce opcję korzystania z proxy HTTP o następującej lokalizacji - adres localhost, port 8118. W przypadku Firefoksa polecam instalację Torbutton do szybkiej zmiany ww. ustawień oraz w celu zapewnienia wyższej anonimowości. Poprawność działania całości można sprawdzić odwiedzając stronę wykrywającą połączenia wykonywane za pośrednictwem Tora.

Połączenie Tora z Privoxy sprawdza się tam, gdzie zależy nam na zachowaniu resztek anonimowości. Na przykład podczas zostawiania komentarzy na blogach z polskiej platformy blogowej Blox. Należy jednak mieć świadomość tego, że nie jest to rozwiązanie idealne i może się nie sprawdzać w przypadku, gdy komuś naprawdę zależy na odkryciu naszej tożsamości. Co więcej, zachowanie anonimowości zależy również od kilku innych czynników takich, jak np. włączona obsługa JavaScriptu w przeglądarce, ciasteczek itp.

Podstawowa konfiguracja Tora umożliwia nam korzystanie z sieci utworzonej z funkcjonujących już przekaźników, ale nie powoduje dołączenia do niej jako kolejny przekaźnik. Oznacza to, że tylko użytkownicy naszego komputera są w stanie wykorzystywać go w roli bramy do anonimowego Internetu. Do konfiguracji Tora można wykorzystać aplikację Vidalia posiadającą graficzny interfejs, lub skorzystać z edytora tekstowego i pliku konfiguracyjnego.

Urządzenia zgodne z grupą standardów 802.11 stają się coraz popularniejsze. O ile kiedyś stanowiły rzadkość, tak teraz zarówno bezprzewodowe karty sieciowe w komputerach, jak i routery bezprzewodowe na biurkach, to standard. To, co mnie jednak zaczęło interesować to sposób, w jaki realizowany jest w nich przesyłanie danych. Scentralizowany tryb infrastruktury oraz zdecentralizowany, oparty na dynamicznym routingu, tryb „ad hoc”. Moje pytanie jest stosunkowo proste - dlaczego współczesne routery bezprzewodowe na rynek SOHO oferują zazwyczaj jedynie tryb infrastruktury? Pytanie szczególnie interesujące, gdy przeanalizuje się wady i zalety trybów „ad hoc” oraz „infrastructure”.

Przykład sieci Wi-Fi opartej o tryb infrastruktury. Komunikacja między klientem 1 i 2 zachodzi za pośrednictwem Access Pointa. Jeden z klientów nie może się komunikować z siecią - jest poza zasięgiem AP (pomimo obecności w zasięgu innych klientów).

Należy zauważyć, że w najprostszym przypadku sieci bezprzewodowej z wykorzystaniem trybu infrastruktury tworzona jest sieć o topologii gwiazdy. Rozwiązanie to, jak każde inne, ma swoje wady i zalety. Zacznijmy od zalet:

• łatwa kontrola dostępu do sieci (np. WPA2-Enterprise),
• ustalone punkty dostępu do sieci,
• przewidywalny zasięg sieci,
• niski koszt routingu (nawet w przypadku zastosowania roamingu),
• niskie zapotrzebowanie na energię oraz moc obliczeniową klientów sieci.

Wszystkie te trzy punkty sprawdzają się w rzeczywistości, o ile w sieci nie pojawi się agresor. Załóżmy jednak, że niewątpliwą zaletą takiej sieci jest właśnie jej ustalona struktura umożliwiająca stosunkowo łatwe zarządzanie nią. A wady?

• wysoki koszt budowy,
• niewielki zasięg sieci (ograniczony elementami architektury),
• ograniczona przepustowość w przypadku połączeń peer-to-peer,
• zawodność.

Scentralizowany charakter sprawia, że funkcjonowanie takiej sieci jest ściśle związane z prawidłową pracą elementów jej architektury. W przypadku sieci złożonej z jednego AP, jego awaria oznacza awarię całej sieci. Problemem jest również jej wąskie gardło, które objawia się w dwojaki sposób. Po pierwsze, zasięg takiej sieci jest ograniczony przez umiejscowienie elementów architektury. Po drugie, podczas komunikacji między użytkownikami sieci wszystkie dane są przesyłane za pośrednictwem AP. Oznacza to, iż w przypadku jednoczesnej wymiany danych przez kilku użytkowników, prędkość przesyłania może drastycznie spać.

Przykład sieci Wi-Fi opartej o tryb „ad hoc”. Klienci 1 i 2 mogą się ze sobą komunikować pomimo tego, iż są poza zasięgami swoich anten. AP jest tutaj nazwany umownie - jest to urządzenie, które dostarcza takie usługi, jak np. dostęp do Internetu.

Przyjrzyjmy się teraz sieciom tworzonym „ad hoc”. Ich niewątpliwymi zaletami są:

• niski koszt budowy,
• zasięg sieci zależny od liczby i rozmieszczenia jej członków,
• wysoka prędkość komunikacji między sąsiadującymi ze sobą klientami,
• odporność na awarie.

Zdecentralizowany charakter ww. trybu sprawia, że jest to sieć idealna do zestawiania jej tam, gdzie nie ma elementów infrastruktury. Każdy jej element jest równie ważny i każdy zajmuje się przesyłaniem danych do innych (dynamiczny routing). Dzięki temu pozbywamy się wąskiego gardła jakim są elementy infrastruktury oraz zyskujemy wyższą niezawodność jej działania. Z łatwością można wyobrazić sobie linię złożoną z klientów sieci, w której to osoby znajdujące się na skrajnych jej brzegach nadal są w stanie się ze sobą komunikować. Niestety, takie rozwiązanie ma swoje wady:

• trudność w ograniczeniu dostępu do sieci,
• brak możliwości zastosowania rozwiązań pokroju WPA2-Enterprise,
• narzut związany z działaniem algorytmu routingu dynamicznego,
• wyższe zapotrzebowanie na moc obliczeniową i energię członków sieci.

Jak widać powyżej, wady sieci „ad hoc” najprawdopodobniej uniemożliwiają stosowania jej w większych organizacjach (np. przedsiębiorstwach posiadających kilkunastu pracowników). A już z pewnością nie jako sieci o stałym charakterze. A co z domami i małymi firmami?

Uważam, że w przypadku małych sieci, których zabezpieczenie oparte jest o WPA, lub WPA2 Personal i filtrowanie MAC-ów, dobrym rozwiązaniem byłoby zastosowanie routera bezprzewodowego pracującego w trybie „ad hoc”. Patrząc z punktu widzenia udostępnianej funkcjonalności i tak byłby on elementem nadrzędnym sieci (DNS, DHCP, dostęp do Internetu itp.), ale dzięki wykorzystaniu „ad hoc” byłyby możliwym poszerzenie zasięgu sieci oraz zwiększenie wydajności komunikacji między jej klientami (w sprzyjających warunkach).

Co ciekawe, nie widziałem na rynku routerów, które umożliwiałyby pracę w trybie innym, niż „infrastructure”. Sugerowane przeze mnie rozwiązanie jest jednak możliwe do realizacji przy pomocy bezprzewodowego routera pracującego w oparciu o oprogramowanie DD-WRT. W najbliższym czasie mam zamiar przetestować moją koncepcję. Nim jednak to się stanie oczekuję na Wasze komentarze i sugestie. Możliwym jest, iż moja niewiedza z zakresu funkcjonowania sieci bezprzewodowych sprawiła, że wysnułem nieprawidłowe wnioski.

Czy praca w trybie „ad hoc” może być dobrym rozwiązaniem w przypadku routerów przeznaczonych na rynek SOHO?

Collect. Process. Organize. Review. Do.

O metodzie Getting Things Done pisało już wielu. Również i ja nie będę tego robić pierwszy raz. W telegraficznym skrócie - GTD jest metodą organizacji czasu, której celem jest odciążenie naszej pamięci przy jednoczesnym zachowaniu wysokiej efektywności. W artykule na Wikipedii znajduje się opis tego, z jakich procesów się ona składa. Co ciekawe, jej wdrożenie nie wymaga żadnego urządzenia elektronicznego, ale trzeba przyznać, iż wykorzystanie właściwego oprogramowania zdecydowanie ułatwia korzystanie z niej. Z tego też względu poniżej znajduje się krótki opis mojej przygody z wdrażaniem GTD w życie oraz aplikacji (w świecie Linuksa), która okazała się być rozwiązaniem bliskim ideałowi.

Historia zaczęła się od zabawy z moim ulubionym edytorem tekstu, czyli Emacsem oraz dodatkiem Org-mode. Org-mode jest godny polecenia - świetnie nadaje się do tego, do czego został stworzony. Pomimo wysokiego początkowego kosztu związanego z nauką jego obsługi warto się nim zainteresować z tego względu, iż minimalizuje późniejszy koszt (czas to pieniądz) np. tworzenia notatek. Pod tym względem jest podobny do LaTeX-a, którego nauka również potrafi na początku odstraszyć osoby przyzwyczajone do Microsoft Worda, lub OpenOffice.org Writera. Nie zmienia to jednak faktu, że przystosowanie Org-mode do GTD jest pracochłonne i do tego akurat zadania nie nadaje się on najlepiej. Zależy nam przecież na wydajnym działaniu, a nie na przyjemności wynikającej z samej możliwości zarządzania czasem.

Kolejnym moim krokiem były poszukiwania czegoś, co przypominałoby systemy typu Wiki. Jak się okazuje, dużą popularność pośród zwolenników takich rozwiązań zyskały modyfikacje TiddlyWiki, czyli Wiki mieszczącej się w pojedynczym pliku będącym połączeniem HTML-a, JavaScriptu oraz danych użytkownika. Ma to taką zaletę, że jest to rozwiązanie zupełnie niezależne od systemu operacyjnego. Wystarczy jedynie posiadać przeglądarkę WWW. Natomiast synchronizację między wieloma komputerami można uzyskać korzystając np. z DropBoksa, Ubuntu One, lub serwisu TiddlySpot. Samo TiddlyWiki może służyć do GTD, ale lepiej skorzystać z czegoś, co zostało stworzone do współpracy z tą metodą, a bazuje na wspomnianym systemie Wiki. Mowa m.in. o MonkeyGTD. Całość nie przypadła mi jednak do gustu - narzędzia tego typu są stosunkowo trudne w obsłudze i mało przejrzyste. A przecież nie tego oczekuje się od rozwiązania, które samo w sobie ma ułatwiać życie.

Przez chwilę zastanawiałem się również nad zastosowaniem ThinkingRock. Szybko jednak uznałem, że pomimo dużej sympatii do Javy niekoniecznie chcę korzystać z takiego molocha przy zabawach z organizacją mojego czasu. Nie wspominając o tym, iż przejrzystością ThinkingRock przypomina raczej węgiel, niźli diament.

I tutaj pojawiła się myśl - może jakaś aplikacja webowa? Najlepiej coś należącego do świata FLOSS, ale na tyle popularnego, aby można było znaleźć darmowy serwis udostępniający ją jako SaaS. Remember the Milk odpadał w przedbiegach ze względu na kryterium wolności oprogramowania. Okazało się jednak, że warunki te spełnił tytułowy Tracks (Ruby on Rails) oraz portal GTDify (można też skorzystać z Tracks.tra.in). I w tym oto momencie doszedłem do rozwiązania, z którego korzystam od jakiegoś już czasu i chwalę je sobie.

Otwarta (GPL), prosta w obsłudze i, co najważniejsze, praktyczna aplikacja. Do każdego miejsca można dostać się przy pomocy maksymalnie trzech kliknięć. Co więcej, posiada wsparcie wsparcie nie tylko dla kontekstów oraz projektów, ale również tagów. Jedno spojrzenie wystarcza do tego, aby szybko stwierdzić, co i na kiedy należy zrealizować, a dodawanie zadań jest przede wszystkim szybkie. Gdyby przeglądarka WWW nie wystarczała to zawsze istnieje możliwość skorzystania z różnego rodzaju feedów XML, iCal, lub tekstowych. Istnieje również możliwość eksportu danych (chociaż z importem jest już nieco gorzej).

Dobrze wdrożony GTD naprawdę ułatwia życie.

Tak, jak ostatnio wspominałem, zabrałem się za napisanie prostego narzędzia do migracji z Joggera (wymagany plik XML z eksportem) do WordPressa (wymagany dostęp do bazy danych) w wersji 2.8.*. JoggerLaunch, bo o nim mowa, pozwala obecnie na przeniesienie do WP wszystkich swoich wpisów oraz komentarzy do nich. Niestety, nie obsługuje jeszcze przenoszenia tagów oraz kategorii do jakich należały wpisy. Funkcjonalność ta z pewnością niedługo się pojawi.

Do napisania skryptu wykorzystałem Rubiego. Powodem, dla którego wybrałem ten język jest fakt tego, iż nigdy wcześniej nie miałem z nim do czynienia. Bo czemu nie? Kod wygląda upiornie, ale przetestowałem go na ponad 5 mebibajtowym XML-u i daje poprawne rezultaty.

Gdyby ktoś miał ochotę dorzucić do niego funkcjonalność, lub poprawić kod i efektywność działania to gorąco zapraszam - jest na licencji BSD.

Na obecną chwilę istnieje naprawdę dużo rozwiązań pozwalających na szyfrowanie danych. Wystarczy wspomnieć chociażby o TrueCrypt, DM-Crypt+LUKS, OpenGPG itp. Wszystkie one opierają się mniej, lub bardziej popularnych algorytmach kryptografii symetrycznej (np. AES) i asymetrycznej (np. RSA). I wszystkie one są naprawdę dobre do momentu, kiedy to okazuje się, że nie mamy dostępu do komputera. Co zrobić, gdy mamy dostęp jedynie do kartki i ołówka?

Dlaczego w ogóle o tym piszę? Przykładowa sytuacja z życia wzięta. Marta znajduje się w Ekwadorze. Ja zaś jestem tam, gdzie zawsze byłem, czyli w Polsce. Z różnych powodów Marta nie posiada przy sobie zarówno komputera, jak i telefonu komórkowego. Jedyny działający telefon w okolicy należy do koleżanki Marty i bez problemu może służyć do odbierania SMS-ów. Chcąc jednak zachować prywatność, przesyłany tekst należałoby w jakiś sposób zaszyfrować. Szyfry wykorzystujące XOR-y oraz bardziej zaawansowane operacje arytmetyczne są zbyt skomplikowane przy szyfrowaniu/deszyfrowaniu wykonywanym przez człowieka. Zatem jaki szyfr wykorzystać?

Założenie jest proste - szyfr musi być prosty do stosowania i w miarę bezpieczny, czyli wymagający uwagi osoby obeznanej w temacie by zostać złamanym. Szyfry przestawieniowe oraz tradycyjny ROT13 odpadają już na samym wstępie, ale można wykorzystać m.in. szyfry podstawieniowe. Przeszukałem Internet pod kątem klasycznych metod szyfrowania i wybrałem najbardziej interesujące w moim mniemaniu rozwiązania. Oto i one:

• wariacja szyfru Vigenère'a z kluczem jednorazowym,
• wariacja szyfru Vigenère'a z autokluczem,
• szyfr Ottendorfa.

Każdy z wyżej wymienionych szyfrów ma swoje wady. Pierwszy wymaga tego, aby po obu stronach uczestniczących w komunikacji pojawiła się książka z identycznym ciągiem losowych znaków, która będzie pełnić rolę klucza jednorazowego. Dodatkowo potrzebna jest „tabula recta” (widoczna powyżej). Jednakże można ją samodzielnie wygenerować w ciągu 2-3 minut. Efekt? Szyfr, do którego złamania należy zdobyć wspomniany klucz. Bez niego uzyskanie tekstu jawnego jest niemożliwe. Przy okazji jest on też bardzo niewygodny w stosowaniu. Odpada.

Wersja z autokluczem wygląda na znacznie bardziej interesującą. Po pierwsze - wymaga jedynie wspomnianej już tabeli ze wszystkimi możliwymi przesunięcia alfabetu. Po drugie - szyfrowanie/deszyfrowanie jest stosunkowo proste, a próba odczytania bez znajomości pierwszych kilku znaków klucza wymaga nieco czasu i pewnej wiedzy. Wady? Jego złamanie jest tylko kwestią czasu.

Co do ostatniego szyfru to jest on interesujący chociażby z tego względu, iż kluczem jest w tym przypadku książka. Każdą literę tekstu jawnego przekształca się do postaci XXYYZZ, gdzie XX to numer strony danej książki, YY to wiersz na danej stronie, a ZZ to kolejny znak będący znakiem z tekstu jawnego. Niestety, szyfrowanie/deszyfrowanie jest długotrwałe, a powstały w ten sposób kryptogram jest kilka razy dłuższy od tekstu jawnego. Przy okazji jest mniej bezpieczny, niż szyfr Vigenère'a z kluczem jednorazowym.

Decyzja zapadła. Ze względu na komfort stosowania oraz stosunkowo wysoki stopień bezpieczeństwa wybrałem szyfr z automatycznym generowaniem klucza. Jak zatem szyfrować z jego wykorzystaniem? To proste, spójrzcie na przykład.

JAWNY: zaszyfrowanyxtekst
KLUCZ: haslozaszyfrowanyt
KRYPT: 

Jak widać, klucz tworzony jest poprzez umieszczenie na jego początku nieznanej nikomu frazy (np. haslo) oraz tekstu jawnego, który będzie szyfrowany. Teraz należy przystąpić do szyfrowania - będzie nam potrzebna wcześniej wspomniana „tabula recta”. Odnajdujemy w niej kolumnę „z” oraz wiersz „h” (lub na odwrót, nie ma to znaczenia) i do kryptogramu wpisujemy literę leżącą na ich przecięciu, czyli „g”. Dla „a” i „a” będzie to „a” itd. Otrzymamy następujący wynik.

JAWNY: zaszyfrowanyxtekst
KLUCZ: haslozaszyfrowanyt
KRYPT: gakkmergvysplpexqm

Proste, prawda? Deszyfrowanie kryptogramu polega na odnalezieniu kolumny, lub wiersza oznaczonego literą z klucza, a następnie w danej kolumnie/wierszu odnajdujemy literę z kryptogramu. Litera tekstu jawnego to litera oznaczająca wiersz w przypadku, gdy na początku wybraliśmy kolumnę, lub oznaczająca kolumnę, gdy wybraliśmy na początku wiersz, w którym znajduje się odnaleziona litera. Na początku klucz nie jest w pełni znany, aby go wygenerować osoba deszyfrująca kryptogram musi znać jedynie wspomnianą wcześniej frazę (np. haslo) i umieszczać w kluczu kolejne litery odszyfrowanego tekstu jawnego.

Proste, łatwe i prawie przyjemne. Trzeba mieć jedynie świadomość tego, iż jest to szyfr podatny na złamanie. M.in. w przypadku długich tekstów, krótkich fraz początkowych oraz stosowania tej samej frazy początkowej do szyfrowania większej liczby wiadomości. Warto zapoznać się z informacjami zawartymi na Wiki oraz z narzędziem do jego łamania.

Szukałem prostego i lekkiego odtwarzacza o dużych możliwościach. Na stabilną i w pełni funkcjonalną wersję fooaudio zarówno wtedy, jak i teraz, trzeba było jeszcze poczekać. Aż w pewnym momencie pojawił się pomysł, aby zastosować najprostsze ze wszystkich rozwiązań - MPD.

MPD jest znany chyba każdemu użytkownikowi Linuksa z kilkuletnim stażem. Jest to mały i elastyczny odtwarzacz muzyczny działający w formie daemona. Idealny do pracy bez X-ów, czy też jako dodatek do minimalistycznych środowisk graficznych - zajmuje zaledwie około 8 mebibajtów w RAM-ie. Komendy można mu przesyłać bezpośrednio na gniazdko (np. dzięki programowi netcat), na którym nasłuchuje, lub korzystając z prostych nakładek graficznych. Z tych mniej zasobożernych warto wymienić pracującego pod konsolą ncmpc++ (2 MiB w pamięci).

Instalacja zarówno samego odtwarzacza, jak i interfejsu jest prosta, jak budowa cepa. Następnie wystarczy dodać odpowiednie symlinki odnoszące się do folderów z muzyką (aby nie grzebać się z plikiem konfiguracyjnym), zmienić prawa dostępu do własnego zbioru muzycznego oraz wykonać aktualizację bazy MPD. Voilà!

Proste, łatwe i przyjemne. A do tego ile możliwości.

Najpopularniejsze obecnie środowiska graficzne przeznaczone dla Linuksa trudno nazwać lekkimi. Zarówno KDE, jak i GNOME pożerają sporą ilość zasobów już przy samym starcie. Xfce, które do niedawna stanowiło lekką alternatywę, coraz bardziej się do nich upodabnia. Co zatem wybrać, aby móc komfortowo pracować na netbooku, starszym komputerze, czy też nawet stosunkowo nowej maszynie, która przy GNOME/KDE traci na prędkości?

Można samemu złożyć własne środowisko opierając się o takie menadżery okien, jak Openbox, IceWM, Fluxbox, FVWM i innych. Nic też nie stoi na przeszkodzie temu, aby skorzystać z gotowego już środowiska stworzonego na bazie Openboksa. Mowa oczywiście o tytułowym LXDE, czyli „Lightweight X11 Desktop Environment”. Na LXDE składa się kilka komponentów. Są to m.in.:

• Openbox - lekki menadżer okien,
• PCManFM - menadżer plików,
• LXPanel - prosty i łatwy w konfiguracji panel,
• i inne.

W tym miejscu warto też zacytować Billa Andersona prowadzącego bloga „Low Cost Computing”, który miał okazję porównać zasobożerność Xfce z LXDE pod Xubuntu i z którym mogę zgodzić się w tej kwestii:

LXDE wins the lightweight contest hands down. Now, it is time for the Xfce community to get back in the game.

Użytkownicy Ubuntu (GNOME) powinni wiedzieć, że niedługo obok istniejących już wariacji na temat tej dystrybucji - Kubuntu (KDE) oraz Xubuntu (Xfce) - pojawi się Lubuntu, czyli Ubuntu bazujące na środowisku LXDE. Główna część komponentów niezbędnych do skorzystania z LXDE znalazła się już w repozytorium pakietów.

Od niedawna i ja stosuję LXDE. Co prawda, nie tak czyste (gdzieniegdzie ukrywają się fragmenty GNOME), jakbym tego oczekiwał, ale nadal jest zdecydowanie lżejsze, niż Xfce - 100 mebibajtów różnicy w zużyciu pamięci, czyli 160 MiB zajętej pamięci po załadowaniu systemu. Podczas ostatnich porządków zainstalowałem 64-bitową wersję Xubuntu 9.04 (wystarczy standardowa edycja Ubuntu), zaktualizowałem oprogramowanie, doinstalowałem metapaczkę lxde i przy kolejnym logowaniu wybrałem sesję z LXDE. Na sam koniec należało jeszcze dodać aplet Network Manager (nm-applet) do listy aplikacji automatycznie uruchamianych podczas startu LXDE, gdyż ten dostarczony przez LXDE, o nazwie LXNM, nie najlepiej sobie radził pod Ubuntu. Instalacja pod Debianem powinna wyglądać podobnie. Całość, jak sami widzicie, jest prosta do wykonania i przynosi zauważalne efekty. Polecam!

Po zmianie środowiska na lżejsze zastanawiam się również nad zmianą oprogramowania, z którego korzystam. Mowa tutaj przede wszystkim o takich narzędziach, jak przeglądarka WWW (obecnie Firefox), czy też klient pocztowy (Thunderbird). Do lekkich z pewnością nie należą.

Wczoraj doszedł do mnie pocztą odtwarzacz multimedialny, o którym jakiś czas temu wspominałem. Nad samym jego wyglądem oraz funkcjonalnością w wersji standard nie będę się rozwodzić. Wystarczy powiedzieć, że pomimo tego, iż jest to wersja „refurbished” to wygląda on naprawdę nieźle ze względu na fabrycznie wymienioną obudowę. Całość posiada 2 gigabajty wbudowanej pamięci oraz czytnik na karty microSD (do 2 GB przy standardowym firmware). Koszt? Poniżej 100 złotych przy zakupie na Allegro. Jak zamienić go w odtwarzacz bazujący na wolnym oprogramowaniu?

Standardowy firmware nie pozwala na zbyt wiele. Na pewno nie potrafi odtwarzać plików skompresowanych przy pomocy kodeków Ogg Vorbis, lub Ogg FLAC. Nie radzi sobie również z kartami microSD większymi, niż 2 GB. Aby to zmienić wystarczy zainstalować Rockboksa (na licencji GPL) przy pomocy łatwej w obsłudze aplikacji. Składa się on z dwóch elementów - bootloadera oraz właściwego firmware. Dzięki zastosowaniu bootloadera oraz dzięki temu, że zarówno oryginalny firmware, jak i bootloader nie są nadpisywane, zawsze można do nich powrócić (np. gdyby Rockbox nie spełniał oczekiwań). A jakie korzyści płyną z zastosowania Rockboksa?

Zalet jest naprawdę wiele, ale nas interesuje przede wszystkim to, iż po instalacji Rockboksa nasz odtwarzacz będzie w stanie odtwarzać m.in. pliki zakodowane przy pomocy Ogg Vorbis. W ten sposób zyskujemy „Ogg playera”! Co więcej, firmware ten pozwala na obsługę kart microSDHC przez co nie jesteśmy ograniczeni tylko i wyłącznie do kart o pojemności 2 GB. Za około 65 złotych (stan na dzień obecny) jesteśmy w stanie rozszerzyć pojemność odtwarzacza o 8 GB, czyli za niecałe 160 złotych otrzymujemy odtwarzacz o pojemności 10 GB i potrafiący odtwarzać ogromną liczbę formatów. Miło, prawda?

W moim przypadku wskazana okazała się być ręczna instalacja ze względu na trudności z dostępem do Internetu. Jednakże nawet ta czynność okazała się być niezwykle prosta ze względu na istnienie przystępnie napisanej dokumentacji (ponad 170 stron, z czego tylko sześć o instalacji). Już po niespełna 3 minutach Rockbox odtwarzał Vorbisa i FLAC-e Machinae Supremacy.

Czy warto? Sądzę, że warto. Jest to chyba najtańszy i najłatwiejszy sposób na zdobycie odtwarzacza o ogromnej pojemności zdolnego do odtwarzania nie tylko MP3, ale również Ogg Vorbis. Oczywiście, Rockbox posiada swoje wady np. problem z ładowaniem baterii w niektórych modelach odtwarzaczy, czy też mało intuicyjny interfejs i mnogość opcji wymagająca wcześniejszego zapoznania się z nimi. Trzeba jednak nadmienić, iż Rockbox jest aktywnie rozwijany już od ponad 8 lat i można liczyć na to, iż pojawiające się błędy będą szybko usuwane.

Scarky.com to nowy serwis (jeszcze w fazie testów), którego autorami są twórcy SPOJ-a - popularnego systemu do przeprowadzania konkursów programistycznych.

Zatem dla kogo został stworzony Scarky? Jest to rozwiązanie przeznaczone dla wszelkiego rodzaju miłośników zagadek, łamigłówek, gier logicznych oraz problemów algorytmicznych. Dzięki Scarkiemu każdy, kto jest tym zainteresowany, jest w stanie stworzyć własną łamigłówkę i umieścić ją na własnej stronie, czy też blogu. Przykład widzicie poniżej.

Przedstawione powyżej zadanie jest niezwykle proste i pochodzi ze SPOJ-a. Idealnie nadaje się na przykład. Planowałem umieścić tutaj zadanie, które polegałoby np. na stworzeniu najkrótszego kodu w BrainFucku (patrz „Literature List”), czy też Whitespace, ale sami rozumiecie, że nie byłby to najlepszy pomysł.

Zachęcam do zabawy!

[EDIT] Ponoć pod IE nie widać widgetu. W takim przypadku proponuję wykorzystać coś, co można nazwać przeglądarką WWW np. Firefoksa, czy też Operę.

Wspomniane jakiś czas temu tokeny kryptograficzne doszły do mnie w całości. Tak, jak sądziłem, ich życie zakończyło się już ponad dwa lata temu - haseł jednorazowych już nie generują. Natomiast całkiem nieźle sprawdzają się w roli, do której miały mi posłużyć, czyli jako kontenery na klucze prywatne RSA oraz certyfikaty X.509. Przynajmniej pod Windowsem. Odpowiednia biblioteka udostępnia interfejs PKCS#11, więc bez problemu można korzystać z SecurID 800 pod Firefoksem, czy też Thunderbirdem.

A pod Linuksem? Cóż... Obecnie nie odniosłem jeszcze sukcesu. Co nie zmienia faktu, iż myślałem nad dwoma sposobami rozwiązania problemu.

Pierwszym z nich jest instalacja na tokenie, który ukrywa w sobie JavaCard, appletu o nazwie MuscleCard. Trochę już na ten temat przeczytałem i niestety, w przypadku SID800 niewiele osób miało z nim do czynienia. Wielce możliwym jest również to, iż instalacja appletu będzie niemożliwa ze względu na brak dostępu z mojej strony do kodów dostępowych do tokena. Nawet nie wiem, czy konieczne są kody uniwersalne będące własnością firmy RSA (obecnie część EMC), czy też te znajdujące się na płycie, która do mnie nie dotarła. Komenda open_sc programu GPshell kończy się fiaskiem.

Drugie rozwiązanie polega na zaprzęgnięciu do pracy następującego łańcuszka:

Aplikacja wspierająca PKCS#11 (np. Firefox) -> OpenSC (np. /usr/lib/opensc-pkcs11.so) -> PC/SC Lite (pcscd) -> Sterownik (libccid)

Daemon pcscd wykrywa inteligentną kartę, a następnie ładuje odpowiedni sterownik (np. libccid) dla danego jej rodzaju i umożliwia komunikację z kartą poprzez wykorzystanie standardu PC/SC. Problem pojawia się w przypadku wykorzystania OpenSC, które wymaga, aby JavaCards wykorzystywały stosowny applet (np. wspomniany MuscleCard). Oznacza to, iż albo zainstaluję na SID800 applet MuscleCard (jest to właściwie rozwiązanie pierwsze), lub zdobędę zamiennik dla OpenSC. Przyszłość pokaże, które rozwiązanie jest prawidłowe, o ile którekolwiek z nich jest możliwe do wykonania przy moim aktualnym stanie wiedzy.

Abstrahując od samego SecurID - najłatwiejszym rozwiązaniem byłby zakup tokena z prawdziwego zdarzenia z funkcjonalnością karty inteligentnej. Coś otwartego i dostępnego bez ograniczeń, posiadającego możliwość zmiany ziarna na podstawie, którego generowane są hasła jednorazowe (np. na bazie czasu). Orientujecie się, czy istnieją takie produkty?

Wstęp

Już wiele razy wspominałem o możliwości szyfrowania dysków twardych z wykorzystaniem DM-Crypt oraz LUKS. Całość działa całkiem sprawnie zarówno pod Linuksem, jak i Windowsem (ten ostatni wymaga FreeOTFE), a do tego wiele dystrybucji Linuksa (m.in. Ubuntu) umożliwia utworzenie zaszyfrowanych partycji już podczas instalacji systemu. Po tej ostatniej operacji każda próba uruchomienia systemu zostanie poprzedzona prośbą o podanie hasła. I tutaj pojawia się pytanie.

A co gdyby tak zamiast mozolnego podawania hasła, wystarczyło podłączyć do komputera odpowiedni pendrive pełniący rolę sprzętowego klucza? Oto i rozwiązanie przeznaczone dla systemu Ubuntu 9.04 z zaszyfrowanym już dyskiem (DM-Crypt + LUKS)!

Przygotowanie klucza

Z powyższym problemem poradzimy sobie umieszczając na pamięci Flash plik będący kluczem umożliwiającym odszyfrowanie danych. Zacznijmy zatem od przygotowania dysku USB.

Na samym początku dzielimy dysk na partycje, lub tworzymy jedną dużą partycję przy pomocy programu cfdisk, lub fdisk. Jest to konieczne ze względu na sposób działania skryptu, który zostanie pokazany w późniejszej części wpisu. Następnie formatujemy wybraną partycję z wykorzystaniem systemu plików Ext2. Mój dysk USB ma obecnie oznaczenie /dev/sdb i na nim wykonuję wszystkie operacje.

sudo cfdisk /dev/sdb
sudo mkfs.ext2 /dev/sdb1

Co dalej? Przygotujmy klucz!

sudo mkdir /media/Crypto
sudo mount /dev/sdb1 /media/Crypto
sudo dd if=/dev/urandom of=/media/Crypto/klucz bs=512 count=4

Plik nie powinien być ukryty (np. poprzez dodanie "." na początku jego nazwy), ani zawierać liter spoza ASCII. Teraz wystarczy dodać obsługę naszego klucza do wcześniej zaszyfrowanej partycji. W moim przypadku mowa o partycji /dev/sda3. Poniżej znajduje się komenda, którą należy wykonać. Należy pamiętać, iż do jej wykonania są potrzebne nie tylko uprawnienia administratora, ale również jedno z haseł LUKS-a, które posłużyły do zaszyfrowania dysku twardego.

sudo cryptsetup luksAddKey /dev/sda3 /media/Crypto/klucz

I to właściwie koniec zabawy po stronie dysku USB. Możemy go odmontować i na jakiś czas schować w bezpiecznym miejscu.

Przygotowanie systemu operacyjnego

Problem z Ubuntu polega na tym, iż twórcy dystrybucji dostarczają jedynie skrypt niezbędny do deszyfrowania dysków przy pomocy hasła podanego przez użytkownika. My zaś chcemy uzyskać możliwość automatycznego pobrania pliku z hasłem z dysku USB, a w przypadku jego braku - podać je ręcznie. W tym celu wykorzystamy skrypt stworzony przez Wejna.

Nim to jednak nastąpi - ostrzegam! Zmiany, które teraz wprowadzamy mają istotny wpływ na sposób funkcjonowania systemu operacyjnego. Błędy w ich wprowadzaniu mogą doprowadzić nie tylko do problemów z jego uruchomieniem, ale również do zniszczenia danych na dysku! Wszystko, co tutaj zawarłem zostało przeze mnie przetestowane i funkcjonuje w moim systemie. Nie oznacza to jednak, iż biorę odpowiedzialność za straty spowodowane poniższym opisem. Wybrany system plików, stworzenie partycji na dysku USB, czy też nawet nazwa pliku mają znaczenie. I to duże, o czym sam się przekonałem w ciągu kilku godzin zabawy z tym rozwiązaniem.

cd /usr/local/sbin
sudo wget http://blog.4zal.net/files/beckman-crypto-usb-key.sh
sudo mv beckman-crypto-usb-key.sh keyscript
sudo chmod 755 keyscript

Skrypt ten jest o tyle interesujący, iż sam wykrywa podłączone do komputera dyski USB w trakcie uruchamiania systemu operacyjnego, a następnie usiłuje pobrać z nich plik z kluczem o podanej przez użytkownika nazwie. Jego nazwę określa się poprzez edycję pliku /etc/crypttab. Poniżej widać poprawną zawartość tego pliku tekstowego. "Klucz" oznacza nazwę pliku z kluczem (normalnie znajduje się tam wartość "none"), a dodatkowy atrybut "keyscript" pokazuje lokalizację ww. skryptu.

# [target name] [source device] [key file] [options]
sda3_crypt /dev/disk/by-uuid/54f....-751a3a4f239a klucz luks,keyscript=/usr/local/sbin/keyscript

Jesteśmy już prawie na końcu. Należy teraz jeszcze dodać do pliku /etc/initramfs-tools/modules informację o jednym module, który będziemy chcieli załadować jeszcze przed uzyskaniem dostępu do głównego systemu plików. Jest on odpowiedzialny za obsługę dysków USB.

usb_storage

Po wykonaniu wszystkich powyższych czynności czas na stworzenie nowego pliku initrd.img odpowiedzialnego za tworzenie podczas bootowania systemu pierwotnego, najprostszego środowiska w którym funkcjonuje jądro. Należy pamiętać, iż błędy w ww. skrypcie, czy też w pliku crypttab mogą w znaczący sposób uniemożliwić nam dostęp do naszych danych, a w skrajnych przypadkach nawet je zniszczyć. Przed wykonaniem poniższego polecenia zalecam zrobienie kopi zapasowej obecnego pliku initrd.img z folderu /boot, gdyż zostanie on nadpisany. Co ważniejsze - warto przygotować GRUB-a do wykorzystania jego starej wersji na wypadek porażki przy uruchamianiu systemu przy obecności nowej wersji tego pliku.

sudo update-initramfs -u ALL

Po ponownym uruchomieniu system powinien samodzielnie przeszukać podłączone dyski USB pod kątem opisanego pliku z kluczem, a w przypadku jego nieodnalezienia - poprosi o podanie hasła przez użytkownika.

Należy pamiętać, iż wprowadzone w ten sposób ustawienia są stałe i nie znikną wraz z aktualizacją jądra systemu Linux z tego względu, iż initrd.img, w którym znajdują się wprowadzone zmiany, jest generowany na komputerze użytkownika nawet przy aktualizacji kernela.

Podsumowanie

Jeżeli wszystko poszło po naszej myśli, od teraz system możemy uruchamiać tradycyjnie, podając hasło przy starcie, lub podłączając na czas startu pendrive zawierającego klucz umożliwiający dostęp do dysku. LUKS obsługuje bodajże do ośmiu różnych kluczy przypadających na jeden zaszyfrowany wolumen.

Mam nadzieję, iż opis ten okaże się przydatny i zachęci Was do samodzielnych eksperymentów. Nic nie stoi przecież na przeszkodzie, aby wspomniany skrypt pobierał dane tylko i wyłącznie z jednego, konkretnego dysku USB (korzystając z informacji o jego numerze seryjnym, czy też UUID), co mogłoby stanowić dodatkowe utrudnienie przy próbie dostępu do komputera. Powodzenia!

Wstęp

Chyba nikt obecnie nie wyobraża sobie uzyskania dostępu do osobistego konta bankowego poprzez Internet bez wykorzystania protokołu HTTPS (nie tylko szyfrowanie, ale też dowód autentyczności). Z pocztą elektroniczną (S/MIME), dokumentami (np. ODF, PDF itd.) oraz programami (np. podpisane javowe JAR-y) jest już nieco inaczej, ale hierarchiczna PKI i standard X.509, wraz ze wzrostem świadomości użytkowników oraz tworzeniem nowych regulacji prawnych, powoli zyskują na znaczeniu. Po drugiej stronie znajduje się rozwiązanie bardzo podobne, ale w przeciwieństwie do PKI, zdecentralizowane - Web of Trust (ang. sieć zaufania) z wykorzystaniem m.in. standardu OpenPGP. Oczywiście, na bazie PKI można stworzyć zdecentralizowany system (patrz CAcert) i odwrotnie, ale nie jest to istotą tego, o czym chcę napisać.

To, co mnie interesuje to możliwość wykorzystania podpisu elektronicznego przy tworzeniu współczesnych serwisów internetowych opartych na treści dostarczanej przez samych użytkowników.

Dlaczego nie HTTPS?

Podpis elektroniczny i strony internetowe to nie jest coś, co dobrze ze sobą współgra. HTTPS pozwala, z wykorzystaniem kwalifikowanych certyfikatów, na określenie autentyczności wyświetlanej strony. Rozwiązanie to ma jednak szereg wad, które ujawniają się w momencie, gdy nie zależy nam na szyfrowaniu danych, lecz jedynie na ich podpisie. Przykładem mogą być blogi, czy też fora (HTML/XHTML) i próba złożenia podpisu elektronicznego przez autora pod napisanym przez siebie wpisem. Jakie wady posiada HTTPS w takiej sytuacji? Na przykład:

• wymaga dostępu do konfiguracji serwera WWW,
• wymaga umieszczenia klucza prywatnego po stronie serwera,
• nie posiada możliwości określenia tego, które dane zostały wygenerowane przez serwer, a które przez użytkowników (np. nie można podpisać się jedynie pod wpisem na blogu, a pominąć cudze komentarze),
• nie pozwala na określenie kilku autorów przesłanego tekstu (np. w przypadku agregatora treści),
• itp.

Oczywistym jest, iż HTTPS został zaprojektowany zupełnie do innych celów, niż te o których obecnie myślę. Potrzebne jest zatem inne rozwiązanie powyższego problemu.

Sugerowane rozwiązanie

W celu rozwiązania problemu należałoby określić w jaki sposób można byłoby dodać do kodu w (X)HTML-u podpis elektroniczny zapisany w formie ASCII (np. kodowanie Base64) i w jaki sposób powiązać go bezpośrednio z daną gałęzią w kodzie (X)HTML. Warto byłoby, aby istniało wsparcie zarówno dla OpenPGP, jak i dla X.509.

Sądzę, iż dałoby się to zrobić na co najmniej trzy sposoby. Jednym z nich byłoby rozwinięcie standardu (X)HTML o nowe znaczniki związane bezpośrednio z podpisem elektronicznym. Drugi sposób polegałby na wykorzystaniu istniejących znaczników (X)HTML oraz RDF/RDFa w celu dodania do dokumentów odpowiednich metadanych umożliwiających maszynowe sprawdzanie poprawności podpisów. Trzeci sprowadzałby się do stworzenia odpowiedniego mikroformatu.

Od razu nasuwają się pytania dot. tego, pod czym należałoby się podpisywać. Czy tylko i wyłącznie pod kodem (X)HTML, a może również brać pod uwagę zawartość obiektów zewnętrznych? W pierwszym przypadku możliwa byłaby sytuacja w której to uległaby zmianie zawartość dodanego obrazka, lecz nie jego adres - podpis nadal byłby prawidłowy, a "treść" uległaby zmianie. I co z CSS-em, JavaScriptem itp.? Gdzie należałoby postawić granicę?

Forma zapisu takich danych to tylko część problemu, równie ważna byłaby ich obsługa przez przeglądarki WWW. Zapewne nie byłby to szczególnie kłopotliwe w przypadku wykorzystania standardu X.509 (przeglądarki posiadają już część koniecznych narzędzi). Nieco trudniej byłoby z OpenPGP. Jednak to, co najważniejsze w Internecie mogłoby stanowić największą barierę dla wdrożenia tego rozwiązania. Człowiek. Jak przeglądarka miałaby wskazać odbiorcy, iż tylko część treści na stronie jest prawidłowo podpisana? Jak można byłoby uchronić użytkownika przed złudzeniem autentyczności strony, gdyby stanowiła jedynie zlepek danych (artykułów, zdań, czy też nawet pojedynczych wyrazów i liter) z innych, podpisanych cyfrowo źródeł? Sporo pytań, a o satysfakcjonujące odpowiedzi trudno.

Jestem ciekaw, czy istniałoby również zapotrzebowanie na takie rozwiązanie. Nie na szyfrowanie danych wymienianych między użytkownikiem, a serwerem, lecz na możliwość łatwego sprawdzenia, kto się pod danym tekstem podpisał. Osiągnięcie autentyczności zapewnianej nie przez login wykorzystywany w danym serwisie, czy też poprzez OpenID, a poprzez np. Centrum Certyfikacji, co byłoby jeszcze bardziej uniwersalnym rozwiązaniem.

Oczywiście, to tylko zarys pomysłu. Mniej, czy bardziej błędny. Wszelkie komentarze są mile widziane (POK).

PS. Przy okazji przeglądam XEP-y i znalazłem kilka związanych z szyfrowaniem, które mi się spodobały: XEP-0027 (OpenPGP, implementacja w Psi), XEP-0102 (PKI) oraz XEP-0188 (ala Off-the-record w Pidgina). I coś z innej beczki - XEP-0237, mój telefon błaga o implementację tego.

Wstęp

Pisałem niedawno o możliwości zamiany telefonu z wewnętrznym GPS-em w zewnętrzny moduł z interfejsem Bluetooth (np. ExtGPS, J2ME GPSd, czy też GPSd4SE) i wykorzystaniu go np. z TangoGPS oraz darmowymi mapami z projektu OpenStreetMap. Teraz czas na opis tego, jak sobie poradzić, gdy chcielibyśmy skorzystać z telefonu i GPS-a w roli interaktywnej mapy.

TrekBuddy

TrekBuddy ta aplikacja napisana w J2ME przeznaczona na telefony komórkowe, a służąca do obsługi GPS-u. Współpracuje zarówno z wewnętrznymi, komórkowymi GPS-ami, jaki tymi zewnętrznymi. Posiada naprawdę bogate możliwości. M.in. elektroniczny kompas, obsługę atlasów, nanoszenie i zarządzanie POI oraz tras, wsparcie dla zewnętrznych i wewnętrznych GPS-ów oraz logowanie odczytów do plików w formatach GPX/NMEA. Wszystko to oczywiście za darmo. Szkoda tylko, że nie posiada otwartego kodu źródłowego.

Warto jedynie wspomnieć, iż osoby chcące skorzystać z logowania, a posiadające GPS wbudowany w komórkę powinny uważać na logowanie w formacie NMEA. W przypadku niektórych telefonów (np. Sony Ericsson) tak wygenerowane dane będą niekompletne np. nie będą zawierać informacji o szerokości i długości geograficznej. Zaleca się zatem stosowanie formatu GPX. Konwersja formatu GPX do innych jest stosunkowo prosta i możliwa z wykorzystaniem m.in. programu GPSBabel. Same pliki z logami można znaleźć na karcie pamięci telefonu w folderach TrekBuddy/tracks-gpx oraz TrekBuddy/tracks-gpx.

Mapy

Sam TrekBuddy i GPS do niczego nam się nie przydadzą. Określenie szerokości, czy też długości geograficznej daje nam niewiele bez dostępu do mapy. Jak zatem zdobyć darmową i w pełni legalną mapę terenu?

Wystarczy skorzystać z programu napisanego w Javie i udostępnianego na licencji GPL. Mowa o TrekBuddy Atlas Creator. Dzięki niemu jesteśmy w stanie w prosty sposób określić teren, którego atlas chcemy stworzyć, a on sam pobierze odpowiednie zdjęcia z wybranego źródła (m.in. Google Maps, czy też OpenStreetMap) i stworzy dane dla TrekBuddy. Jak pewnie zauważyliście, wspomniałem o atlasie, a nie o mapie. Dlaczego? Atlas jest to zbiór map różnego typu i o różnej skali. W przypadku TrekBuddy atlas zawiera warstwy, a one zaś zawierają mapy. Warstwa jest odpowiedzialna za skalę, a mapy to np. mapa satelitarna, czy też topograficzna.

Mapy zajmują nieco miejsca, szczególnie te z wieloma wielkoskalowymi (szczegółowymi) warstwami. Warto zatem przygotować sobie jeden atlas na dany kraj np. Polski z warstwami od 0 do 12 z Google Maps (zajmujący około 150 MiB) oraz kilka innych, bardziej szczegółowych dla konkretnych miast. Tak wygenerowane mapy należy następnie przenieść na kartę pamięci telefonu np. do folderu TrekBuddy/maps.

Points of interest

Mapy to jedna rzecz. Drugą, równie ważną, są tzw. POI będące punktami zainteresowań, czy też użyteczności publicznej określającymi położenie np. aptek, restauracji, stacji benzynowych itp. Mapy nie posiadające stosownych POI są raczej mało przydatne w przypadku turystycznych zastosowań. Jak zatem zdobyć te dane? Czy będą pasować do naszych darmowych map i TrekBuddy?

Wspomniane punkty składają się z nazwy, opisu i położenia geograficznego. Oznacza to, iż dobrze przygotowane punkty powinny pasować do każdej dobrze skalibrowanej mapy. Zaś w celu pozyskania zbioru POI można skorzystać z darmowych baz rozwijanych przez społeczność użytkowników. Mowa m.in. o PoiPoint.pl, czy też tej dostępnej na forum TrekBuddy.

Same zbiory punktów są odczytywane przez TrekBuddy w formacie GPX. Oznacza to, iż pliki z POI należy skopiować do folderu TrekBuddy/wpts na karcie pamięci telefonu. Podczas korzystania z atlasu, czy też mapy można je wyświetlać w zależności od aktualnych potrzeb. TrekBuddy umożliwia sortowanie takich punktów po nazwie, opisie, czy też odległości od naszego obecnego położenia na mapie. Nic też nie stoi na przeszkodzie, aby dodawać własne POI, w tym celu TrekBuddy stworzy osobny plik GPX we wspomnianym folderze.

Podsumowanie

Tak opisane rozwiązanie nie jest, co prawda idealne i należy mieć to na uwadze podczas podróży, ale z pewnością jest bardzo pomocne. Szczególnie, gdy nie ponosimy kosztów podczas korzystania z nich. Istnieją również komercyjne mapy dla TrekBuddy dostępne wraz ze zbiorami POI, ale ich opis nie był moim celem. Mam nadzieję, że podane przeze mnie informacje okażą się przydatne dla osób zainteresowanych wykorzystaniem GPS-ów w codziennym życiu.

Sama obsługa TrekBuddy nie powinna nikomu nastręczyć problemów. Całość jest stosunkowo dobrze opisana i nie widzę potrzeby opisywania tego. Znacznie ciekawszy jest natomiast temat tworzenia dobrych map, włącznie z uczestnictwem w projekcie OpenStreetMap, czy też zabawa w tzw. geocaching. Ale o tym nieco później, jak już lepiej poczuję się w temacie amatorskiej kartografii.