Z przyjemnością informujemy, iż dnia 09.01.2012 roku, z inicjatywy dwóch członków Stowarzyszenia Szczecińska Grupa Użytkowników Uniksa i Linuksa ” Rafała Malujdy i Michała Smereczyńskiego – powołana została do życia Fundacja Aegis.

Stowarzyszenie Szczecińska Grupa Użytkowników Uniksa i Linuksa, zgodnie z założeniem swoich działań statutowych, partycypowała w kosztach powołania Fundacji Aegis, pokrywając 1/3 kosztów tego procesu. Tym samym, Stowarzyszenie Szczecińska Grupa Użytkowników Uniksa i Linuksa, głosem jego zarządu, udziela poparcia inicjatywie powstania Fundacji Aegis i planom jej działalności.

Aegis (Egida) to mityczna tarcza Zeusa, wykuta przez Hefajstosa. Według mitologii greckiej, miała ona chronić młodego boga. Zgodnie z frazeologią języka polskiego egida, a właściwie związek frazeologiczny „pod egidą”, oznacza roztaczanie opieki, przewodnictwo, patronat, czy protektorat. Aegis to też element nazwy kodowej systemu ochrony przeciwlotniczej i przeciwrakietowej obszaru działań floty lub wspieranego przez Marynarkę Wojenną USA lądowego teatru działań.

Fundacja Aegis, wzorem Apache Foundation, wpisuje się w ten kontekst i przyjmuje kształt fundacji parasolowej.

Pod parasolem fundacji przygotowane jest miejsce dla projektów związanych nie tylko z wolnym i otwartym oprogramowaniem, ale także dla projektów z dziedziny otwartych standardów, otwartych danych i interoperacyjności.

Fundacja Aegis zajmować się będzie wsparciem technologicznym, prawnym, społecznościowym i biznesowym dla projektów, które znajdą się pod jej
egidą. Fundacja zajmować się będzie także działalnością wydawniczą i stymulacją społeczności zgromadzonej wokół wolnego i otwartego oprogramowania, a także będzie pełnić rolę węzła komunikacyjnego pomiędzy deweloperami i innymi osobami zaangażowanymi w projekty związane z otwartym oprogramowaniem, otwartymi standardami, otwartymi danymi i interoperacyjnością, a światem biznesu i rynkiem zatrudnienia.

Dla członków Stowarzyszenia Szczecińska Grupa Użytkowników Uniksa i Linuksa, którzy znają jej statut, związek Stowarzyszenia Szczecińska Grupa Użytkowników Uniksa i Linuksa i Fundacji Aegis powinien być oczywisty. Na wielu płaszczyznach cele statutowe Stowarzyszenia Szczecińska Grupa Użytkowników Uniksa i Linuksa oraz Fundacji Aegis pokrywają się, zaś w wielu innych miejscach uzupełniają się nawzajem.

Fundacja Aegis będzie starała się zapraszać istniejące już projekty związane z wolnym i otwartym oprogramowaniem, otwartymi standardami, otwartymi danymi i interoperacyjnością pod swoją opiekę, ale także zachęcać będzie do tworzenia nowych projektów, formalizowania społecznych inicjatyw oraz do pielęgnacji inicjatyw, które mają na celu ochronę dóbr społeczności.

Ochrona dóbr społeczności według Fundacji Aegis, to stworzenie w Polsce „zbrojnego ramienia” ruchu wolnego i otwartego oprogramowania, ruchu otwartych standardów, inicjatywy otwartości danych i przyrzeczenia interoparcyjności. Fundacja ma zamiar stać na straży licencji chroniących otwartości i walczyć z wszelkimi przejawami naruszania tych licencji.

Projekty znajdujące się pod parasolem Fundacji Aegis będą mogły liczyć na doradztwo w kwestiach związanych inżynierią programowania, projektowaniem aplikacji i usług, biznesem, zarządzaniem projektami i rozwojem osobistym.

Fundacja Aegis starać się będzie działać w sposób merytokratyczny.
Decyzyjność w sprawach związanych z projektami jest trójstronna i dzieli się między fundatorów i stowarzyszenie Szczecińska Grupa Użytkowników
Uniksa i Linuksa, które reprezentowane jest przez jego władze. Oznacza to, iż Stowarzyszenie Szczecińska Grupa Użytkowników Uniksa i Linuksa ma jeden z trzech głosów decyzyjnych w sprawach związanych z projektami.

Poza głosami decydującymi, które konieczne są ze względów formalnych, w fundacji powołane zostało ciało nazwane mianem Zgromadzenia Fundatorów.
W zgromadzeniu tym zasiadają fundatorzy oraz osoby, które jako specjaliści w dziedzinach związanych z działalnością fundacji, zostają zaproszone do niego przez zarząd fundacji.

Wszystkie osoby, które są zainteresowane wsparciem Fundacji Aegis w jakikolwiek sposób, zapraszamy i zachęcamy do kontaktu. Fundacja to przede wszystkim ludzie i inicjatywy, ale zapraszamy do współpracy także firmy i organizacje, które w Fundacji Aegis widzą partnera do współpracy na polach swojej działalności.

TLDR: powstała polska fundacja dla otwartych projektów, służąca radą w aspektach technologicznych, prawnych i biznesowych. Jeżeli chcesz zgłosić swój projekt, odwiedź stronę Fundacji.

W poprzednich wpisach opisałem bardziej techniczne szczegóły implementacji podpisywania pakietów i baz danych repozytorium w pacmanie. Można przeczytać je tutaj:

• Podpisywanie pakietów w Arch Linuksie – 1: makepkg i repo-add
• Podpisywanie pakietów w Arch Linuksie – 2: pacman-key
• Podpisywanie pakietów w Arch Linuksie – 3: pacman

Od tamtego czasu, pacman-4.0 został wydany i dodany do repozytorium [testing]. To znaczy, że nasza implementacja zaczyna mieć większą ilość użytkowników. Przez ten czas, nie znaleziono poważnych błędów, chociaż są pewne miejsca, które mogłyby być poprawione (n.p. instalacja niepodpisanych pakietów za pomocą -U ” FS#26520 i FS#26729). Nowy pacman poprawnie wykrył „zły pakiet” w moim repozytorium… (cóż, nie dosłownie zły, ze złym podpisem. Wniosek: nie tworzyć podpisów dla wielu plików jednocześnie, gnupg to śmieć…).

Repozytoria w Arch Linuksie powoli przygotowują się do sprawdzania podpisów w pacmanie-4.0. Możliwość wysyłania podpisów z pakietami została dodana w kwietniu, a stało się to obowiązkowe z początkiem listopada. Na dzisiaj, wszystkie pakiety w [core] zostały podpisane, około 71% pakietów w [extra] oraz 45% w [community].

Więc wszystkie elementy ze sobą współdziałają poprawnie. Ale jak to działa od strony praktycznej? Zacznę od ustawiania bazy kluczy PGP pacmana i pacman.conf.

Po instalacji nowego pacmana, powinieneś stworzyć bazę kluczy przy użyciu pacman-key --init. To polecenie tworzy niezbędne pliki (pubring.gpg, secring.gpg) z odpowiednimi uprawnieniami dostępu, aktualizuje bazę z zaufanymi kluczami (oczywiście pustą) i tworzy podstawowy plik konfiguracyjny. Generuje także główny klucz bazy pacmana. Możesz zmienić domyślny serwer kluczy w /etc/pacman.d/gnupg/gpg.conf ” część użytkowników miała problemy z podłączeniem się do domyślnego.

Ustawienia w pacman.conf są bardziej kwestią osobistych preferencji, ale uważam swoje za całkiem rozsądne. Ustawiłem globalnie sprawdzanie podpisów (Optional TrustedOnly). Ustawienie to nie wymaga obecności podpisu, jeżeli jednak takowy jest, to musi pochodzić z zaufanego źródła. W manie dot. pacman.conf można znaleźć więcej szczegółów. Dla repozytoriów z podpisanymi wszystkimi pakietami ustawiłem PackageRequired, które wymaga podpisanej paczki, ale nie podpisanej bazy. (Dla swojego repozytorium używam Required; zarówno pakiety jak i baza są podpisane.)

Zobaczmy jak wygląda output podczas instalacji podpisanego pakietu:

# pacman -S gcc-libs
warning: gcc-libs-4.6.2-3 is up to date -- reinstalling
resolving dependencies...
looking for inter-conflicts...
 
Targets (1): gcc-libs-4.6.2-3
 
Total Installed Size: 2.96 MiB
Net Upgrade Size: 0.00 MiB
 
Proceed with installation? [Y/n]
(1/1) checking package integrity [######################] 100%
error: gcc-libs: key "F99FFE0FEAE999BD" is unknown
:: Import PGP key EAE999BD, "Allan McRae ", created 2011-06-03? [Y/n] y
(1/1) checking package integrity [######################] 100%
error: gcc-libs: signature from "Allan McRae " is unknown trust
error: failed to commit transaction (invalid or corrupted package (PGP signature))
Errors occurred, no packages were upgraded.

Jak widać, pacman przerwał instalację pakietu, który został podpisany nieznanym kluczem i zapytał użytkownika, czy chce zaimportować go do bazy. Wyświetlony fingerprint zgadza się z tym opublikowanym w kilku miejscach, więc z czystym sumieniem użytkownik może dodać go do swojej bazy. Wtedy pacman przerywa instalację przez to, że klucz jest niezaufany. Cóż, ten Allan wygląda na godnego zaufania, więc można zmienić poziom zaufania jego klucza za pomocą pacman-key --lsign EAE999BD i pakiety podpisane przez Allana będą instalowane bez problemu.

Sprawdzanie wiarygodności każdego developera i zaufanego użytkownika może być dosyć uciążliwe (35 devów oraz 30 TU). Aby to ułatwić (chociaż trochę), 5 głównych kluczy jest używanych w repozytoriach. Cały pomysł polega na tym, że klucze developerów i zaufanych użytkowników muszą być podpisane wcześniej wspomnianymi głównymi kluczami, więc w bazie kluczy potrzebujesz tylko ich, aby zaufać pozostałym. Odciski kluczy zostaną udostępnione w wielu miejscach, aby można im zaufać (na dole wpisu można znaleźć listę kluczy niezależną od tej ze stron Archa).

Aby skonfigurować bazę z głównymi kluczami, możesz skorzystać z poniższego skryptu:

for key in FFF979E7 CDFD6BB0 4C7EA887 6AC6A4C2 824B18E8; do
    pacman-key --recv-keys $key
    pacman-key --lsign-key $key
    printf 'trust\n3\nquit\n' | gpg --homedir /etc/pacman.d/gnupg/ \
        --no-permission-warning --command-fd 0 --edit-key $key
done

W efekcie odpowiednie klucze powinny znaleźć się w bazie i zostać podpisane lokalnym kluczem pacmana. To jednak nie wystarczy ” przecież pakiety nie są podpisywane tymi kluczami. Należy jeszcze zmienić poziom zaufania ” skrypt ustawia go na marginalny. Warto zauważyć, że robi to za pomocą gpg, nie pacman-key, który nie obsługuje parametru --command-fd. Można użyć pacman-key --edit-key, do ustawienia zaufania ręcznie. Domyślnie, nasza sieć zaufania uznaje klucz za zaufany, gdy jest podpisany co najmniej 3 głównymi kluczami. (Jest ich 5, więc nawet jeśli unieważnimy 2 z nich, wtedy pakiety dalej będą uznane za bezpieczne.) Niski poziom zaufania głównych kluczy jest zarazem zabezpieczeniem ” kilka kluczy musi być skompromitowanych, aby wprowadzić zaufany pakiet do repozytorium z zewnątrz.

Teraz, gdy klucze są już w bazie pacmana, za każdym razem gdy pacman będzie pobierał pakiet z nieznanym podpisem, będzie automatycznie oznaczany jako zaufany. Przynajmniej taki jest pomysł. W dalszym ciągu nie wszyscy developerzy/TU mają klucze podpisane głównymi, ale już niewiele brakuje. W przyszłości może pojawi się pakiet pacman-keyring, który usprawni proces konfiguracji, albo chociaż uchroni użytkownika przed pobieraniem każdego klucza samodzielnie.

Jedyne, co pozostaje do zrobienia, to kwestia podpisywania bazy danych repozytorium, ale to historia na inną okazję.

–
Allan McRae – AB19 265E 5D7D 2068 7D30 3246 BA1D FB64 FFF9 79E7
Dan McGee – 27FF C476 9E19 F096 D41D 9265 A04F 9397 CDFD 6BB0
Ionuț Mircea Bîru – 44D4 A033 AC14 0143 9273 97D4 7EFD 567D 4C7E A887
Pierre Schmitz – 0E8B 6440 79F5 99DF C1DD C397 3348 882F 6AC6 A4C2
Thomas Bächler – 6841 48BB 25B4 9E98 6A49 44C5 5184 252D 824B 18E8

Nadszedł czas na ostatni element sagi podpiswania pakietów… Poprzednio opisałem podpisywanie pakietów oraz baz danych i zarządzanie bazą kluczy, niezbędne elementy weryfikowania podpisów w pacmanie.

Większość użytkowników nie zauważy procesu sprawdzania podpisów, dopóki nie pójdzie coś źle (nie licząc konfiguracji). Widoczny będzie stary komunikat checking package integrity podczas którego będą sprawdzane sumy kontrolne oraz weryfikowany podpis, jeżeli będzie taki dostępny. Implementacja tego wymagała znacznych zmian w libalpm, w tym dodaniu weryfikacji podpisów przy użyciu biblioteki gpgme, opcji konfiguracyjnych do kontrolowania weryfikacji repozytoriów i pakietów oraz sprawdzenia jak i kiedy baza repozytorium jest ładowana (dzięki czemu można wcześnie powiadomić użytkownika o wadliwym podpisie repo), a to dopiero początek listy. Większość z niej zostało zrobione przez Dana McGee, głównego programisty pacmana.

$ git shortlog -n -s --no-merges maint..
   296  Dan McGee
   128  Dave Reisner
   124  Allan McRae
   ...

(w tym 18 innych autorów z 11 commitami bądź mniej). Dan bez wątpienia jest autorem prawie połowy wszystkich commitów, poczas gdy o drugie miejsce trwała zaciekła rywalizacja.

Jakie są efekty naszej pracy? Moje zdanie jest lekko stronnicze, ale sądzę, że udało nam się stworzyć jedną z najbardziej kompletnych i elastycznych implementacji. Inne menadżery pakietów zwyczajnie wywołują gpgv, który ufa każdemu podpisowi z bazy kluczy. Dzięki bardziej skomplikowanemu rozwiązaniu z użyciem gpgme, pacman ma kompletną realizację sieci zaufania, pozwalającą na bardzo dokładnie zarządzanie kluczami. Nie tylko podpisujemy pakiety ” bazy danych repozytoriów również. Co najważniejsze, można dodać czas wygaśnięcia do tych kluczy, dzięki czemu niegroźne są złośliwe mirrory ze starymi wersjami pakietów albo wcale wcale nie dostarczające aktualizacji. Dodatkowo, zabezpieczyliśmy użytkownika przed tzw. endless data attack, w którym atakujący wysyła niekończony strumień danych zamiast żądanego pliku. Wszystkie te rozwiązania pokrywają najczęściej zgłaszane i spotykane ataki na menadżery pakietów. (Wstrzymałem się od powiedzenie „wszystkie” ” ktoś natymiast udowodnił by, że jestem w błędzie.)

Wracając do sprawdzania podpisów w pacmanie. Głównym ustawieniem jest dyrektywa SigLevel w pacman.conf, którą można ustawić globalnie i odrębnie dla każdego repozytorium. Przyjmuje trzy wartości:

• Required, która wymusza sprawdzenie podpisu przed instalacją
• Optional (domyślnie), która sprawdza podpis, jeżeli jest dostępny i akceptuje niepodpisane pakiety/bazy
• Never, która wyłącza sprawdzanie podpisów

Bardziej szczegółowe ustawienia można uzyskać dodając prefiksy do powyższych wartości. Na przykład, posiadam repozytorium z podpisaną bazą, lecz nie wszystkie pakiety są podpisane. Używam więc SigLevel = Optional jako ustawienie domyślne oraz SigLevel = DatabaseRequired, aby wymusić weryfikowanie podpisu bazy. Alternatywnie mogę ustawić globalnie SigLevel = DatabaseRequired PackageOptional aby uzyskać dokładnie taki sam efekt. Można również określić wymagany poziom zaufania za pomocą opcji TrustedOnly (domyślnie) oraz TrustAll. Ten pierwszy akceptuje tylko klucze, które mają pełne zaufanie w bazie kluczy. Drugi wymaga tylko obecności klucza w bazie (tak jak gpgv).

Jak pisałem wcześniej, po konfiguracji z perspektywy użytkownika jest widoczna bardzo mała zmiana. Zauważalne jest to, że pacman pobiera podpis bazy danych, gdy SigLevel ma wartość Required i Optional.

# pacman -Syu
:: Synchronizing package databases...
 allanbrokeit           1464.0B  540.5K/s 00:00:00 [######################] 100%
 allanbrokeit.sig        287.0B    7.0M/s 00:00:00 [######################] 100%
...

Poza tym, sprawdzanie podpisu wykonywane jest w trakcie sprawdzania integralności paczki, więc prawdopodobnie zostanie to niezauważone, dopóki nie pójdzie coś źle. Jest to jednocześnie zaleta (w końcu lubimy pacmana ze względu na jego prostotę) i wada (duża część wykonywanych zadań jest niewidoczna dla użytkownika). Jeśli wszystko związane z podpisywaniem pakietów i baz danych działa, pamiętaj, by podziękować najbliższemu deweloperowi pacmana (a jeśli nie działa, to nie była nasza wina…).

W drugiej części serii wpisów dotyczących implementacji podpisywania pakietów w w pacmanie przybliżę zarządzanie kluczami oraz nowe narzędzie pacman-key.

Sposób, w jaki baza kluczy pacmana, jest zasadniczym aspektem bezpieczeństwa systemu. Baza kluczy (w połączeniu z ustawieniami pacmana) będzie zarządzać którym pakietom i podpisów baz baz danych zaufa użytkownik i w ten sposób, które pakiety wpuści do swojego systemu. Wciąż nie jestem do końca przekonany w jaki sposób ustawić bazę kluczy w zakresie ważności kluczy i ich poziomie zaufania ” jedyne repozytorium z którego korzystam i w pełni korzysta z podpisywania pakietów jest moje własne. Dodawanie mojego klucza z absolutnym zaufaniem może nie być najlepszą rzeczą do zrobienia dla innych użytkowników, jednak może być to akceptowalne w bazie kluczy pacmana, nie całego systemu. Mimo wszystko jest to społeczne zagadnienie używania PGP, więc zostawię dyskusję na ten temat na inną okazję.

Zakładając, że baza kluczy jest już ustawiona, narzędzie do zarządzania nią może być pomocne. Co prawda można to zrobić korzystając z gpg i parametru --homedir, jest kilka problemów związanych z pacmanem, dzięki którym powstało odrębne narzędzie ” pacman-key. Początkowo pacman-key był portem debianowego apt-key autorstwa Denisa A. Altoé Falquet, ale powoli stawał się nakładką na gpg z dodatkowymi funkcjami. Swoje zasługi mieli także Ivan Kanakarakis i Pang Yan Han, którzy wnieśli wiele poprawek do skryptu oraz Guillaume Alaux, autora początkowej strony man.

Baza kluczy pacmana (domyślnie) będzie znajdywać się w /etc/pacman.d/gnupg (aczkolwiek może to zostać zmienione za pomocą dyrektywy GPGDir w pacman.conf). Baza powinna być stworzona z użyciem pacman-key --init, aby mieć pewność, że pliki mają odpowiednie uprawnienia i sprawdzanie podpisów będzie działać. Na przykład, aby zweryfikować podpis pakietu (pacman -Qip ), użytkownik musi mieć uprawnienia do odczytania plików bazy kluczy, przy czym gnupg nie może tworzyć pliku blokady (obecnie jest to ustawione globalnie, biblioteka gpgme użyta w pacmanie nie ma funkcji kontrolującej tworzenie plików blokady…).

Klucze mogą zostać dodane do bazy na kilka różnych sposób. Mogą zostać importowane z lokalnego pliku bądź plików przy użyciu pacman-key -a/-add albo z publicznego serwera za pomocą pacman-key -r/--receive . Można również zaimportować cały zestaw kluczy z innej bazy kluczy GnuPG. Klucze można usunąć za pomocą opcji -d/--delete. Istnieje również możliwość dla dystrybucji albo innego dostawcy repo udostępnienia bazy zawierającej klucze wszystkich packagerów, ale ten mechanizm ciągle podlega pracom.

Gdy w bazie znajdują się klucze, można nimi zarządzać za pomocą pacman-key i częścią parametrów GnuPG (--edit-key, --export, --list-keys, --list-sigs). Opcja umożliwiająca modyfikowanie klucza jest istotna ze względu na możliwość ustawienia poziomu zaufania i podpisywania innych kluczy. W przypadku bardziej zaawansowanych operacji, konieczne jest bezpośrednie użycie gpg, ale jestem pewien, że jeżeli będzie to często używane polecenie, zostanie dodane do pacman-key na prośbę.

I to by było wszystko na temat pacman-key. Jest dosyć proste, jednak zostało najmniej przetestowane jako narzędzie, które nie jest używane codziennie. Jeżeli chciałbyś pomóc przy testach bez naruszania pacmana zainstalowanego w systemie, możesz zbudować i uruchomić go bezpośrednio z gita.

$ git clone git://projects.archlinux.org/pacman.git
$ cd pacman
$ ./autogen.sh
$ ./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var
$ make -C scripts
$ ./scripts/pacman-key

Sprawdź tworzenie nowej bazy, dodawanie i usuwanie kluczy, modyfikowanie ich, weryfikowanie pakietów i oczywiście, zgłoś wszystkie błędy, które napotkasz.

Jeżeli jest ktoś niezorientowany w temacie podpisywania pakietów w pacmanie, konieczne jest wygenerowanie lokalnego klucza, do podpisywania (i uwierzytelnienia) kluczy zewnętrznych. Korzystając więc z polecenia znalezionego w dokumentacji/podpowiedzianego przez pacmana, uzyskałem taki efekt:

[root@marlowe ~]# pacman-key --init
gpg: Generating pacman keychain master key...
Not enough random bytes available.  Please do some other work to give
the OS a chance to collect more entropy! (Need 300 more bytes)

Gdybym miał zainstalowane środowisko graficzne, wystarczyłoby pomachać myszką. Ale nie miałem, bo przecież uparłem się na testowanie pacmana.
Bezsensowne walenie w klawiaturę nic nie dało. To samo z przekierowaniem /dev/random i /dev/urandom na terminal. W żaden sposób nie przybliżyło mnie też wymuszenie instalacji mplayer2 i odsłuchanie kilku piosenek Morphine. Wymusiłem jeszcze instalację Linksa i przystąpiłem do przeszukiwania Internetu.

Po chwili trafiłem na rng-tools, które okazało się remedium na ów problem. Po instalacji, zmieniłem TIMEOUT w pliku /etc/conf.d/rngd na 10. Potem wystarczyło odpalić rngd -f -r /dev/urandom i spróbować ponownie wygenerować klucz. Tadam!

Oczywiście, można było wymusić instalacje wszystkich pakietów, wyłączyć sprawdzanie podpisów albo tymczasowo zrobić downgrade pacmana, ale po co, skoro cała zabawa polega na rozwiązywaniu problemów. ;)

Poniższy kod należy wstawić do tablicy globalkeys w pliku rc.lua. Umożliwia przywrócenie wszystkich zminimalizowanych okien za pomocą skrótu Mod4+N.

    -- all minimized clients are restored
    awful.key({ modkey, "Shift"   }, "n",
        function()
            local tag = awful.tag.selected()
                for i=1, #tag:clients() do
                    tag:clients()[i].minimized=false
                    tag:clients()[i]:redraw()
            end
        end)

Sfrustrowało mnie to wystarczająco bardzo, bym zaczął rozglądać się za alternatywnym menedżerem okiem bądź środowiskiem graficznym, ale o tym innym razem.

• Nowa domena

Od teraz blog, jak i większość rzeczy związanych ze mną, można znaleźć pod adresem bpiotrowski.pl. Stary adres nadal będzie działał, ale zostawiłem go głównie dla wyszukiwarek. Leniwi nie muszą oczywiście uaktualniać kanału RSS, on również powinien działać bez problemów.

• Miniblog

Wszystkie wpisy mniej techniczne, bądź mniej związane z tematyką bloga trafiają do bocznej kolumny; ergo do minibloga. Użyta wtyczka ma jednak pewne mankamenty, których (póki co) nie umiem naprawić: wpisy z minibloga nie trafią do głównego kanału RSS. Osoby zainteresowane relacjami, bądź zaproszeniami na konferencje są zmuszone czytać samodzielnie kategorię Miniblog, albo dodać kolejny kanał do swojego czytnika.

• Menu

Na górze strony pojawiło się menu z kilkoma odnośnikami. Na daną chwilę jest to odnośnik na moją stronę, na stronę główną (a w rozwijanym menu do kanałów RSS), podstronę dot. mojej osoby, klucz GPG oraz Github. Niewykluczone, że pojawi się ich więcej albo któryś zniknie.

• Żegnaj Blipie, witaj Identi.ca!

Osoby śledzące mojego Blipa już pewnie zauważyły, że od sierpnia mało się tam udzielam. Zebrałem tam sporą kolekcję linków, więc ciągle męczę się, aby wyeksportować Blipy za pomocą API, ale w międzyczasie przeniosłem się na Identi.ca, otwartoźródłową alternatywę dla Twittera. Na tym ostatnim też mam konto, ale trafia na nie dokładnie ta sama treść co na konto na Identi.ca.
Przy okazji zmiany, pozbyłem się także widgetu wyświetlającego ostatnie blipnięcia, a dodałem analogiczny dla nowego serwisu.

• Reklamy

Co prawda dosyć dawno, bo już od 6 miesięcy temu, pojawiły się reklamy na blogu i prawdopodobnie nie znikną, dopóki będą przynosić dochody (nieduże, ale zawsze). Są nieinwazyjne, zupełnie niezwiązane z tematyką bloga i prawdopodobnie łatwo je wyciąć AdBlockiem.

• Optymalizacja

Ostatni punkt, który sprawił mi najwięcej frajdy. W końcu skończyłem poprawiać czas ładowania strony. Od strony WordPressa wykorzystałem wtyczki WP Minify, WP Super Cache oraz HeadJS Plus. Za wyświetlanie strony odpowiada nginx z włączoną kompresją.

To chyba wszystko z najważniejszych rzeczy. Pewnie za kilka miesięcy znów pojawi się tego typu lista. ;)

1 i 2 grudnia 2011 roku odbędzie się konferencja Open Radar 2011. Konferencja ma na celu połączenie przedstawicieli branży IT, naukowców i przedsiębiorców ze społecznością Open Source z Polski i Niemiec. Pierwszego dnia konferencji przewidziano wykłady (Hotel Silver), a drugiego warsztaty (Technopark Pomerania) oraz giełdę kooperacyjną projektu Fames Artium Magistra, organizowaną przez Szczeciński Park Naukowo-Technologiczny (Hotel Silver). Pierwszego dnia konferencji spotykamy się także wieczorem w pubie Stara Komenda, aby zacieśniać więzi z zachodnim sąsiadem ” wszystko oczywiście przez pryzmat otwartego oprogramowania. Konferencja Open Radar 2011 jest organizowana po raz pierwszy, a jej organizatorami są Stowarzyszenie Klaster ICT Pomorze Zachodnie/Technopark Pomerania oraz Stowarzyszenie Szczecińska Grupa Użytkowników Uniksa i Linuksa. Projekt jest dofinansowany przez Unię Europejską ze środków Europejskiego Funduszu Rozwoju Regionalnego oraz budżetu państwa (Fundusz Małych Projektów INTERREG IV A Euroregionu Pomerania).

Oczywiście też się pojawię, w miarę możliwości będę zajmował się polskimi prelegentami spoza Szczecina i podawał ciepłe napoje. Tym razem nie będę prowadził żadnego wykładu. ;) Więcej informacji można znaleźć na stronie konferencji.

O projekcie

Alpine Linux to mała dystrybucja przeznaczona do instalacji na routerach, firewallach, lub zwyczajnych serwerach. Czym się różni od innych serwerowych dystrybucji? Wszelkie oprogramowanie jest skompilowane z uClibc (które w teorii powinno być używane w systemach wbudowanych), zamiast glibc. Korzysta także z PaX i SSP. Zamiast własnych skryptów startowych, korzysta z OpenRC zapożyczonego z Gentoo. Menedżer pakietów apk dla odmiany jest własny, chociaż pomysł na skrypt do budowania pakietu jest ewidentnie wzorowany na Archu, co sugeruje nawet jego nazwa → APKBUILD.

Instalacja i użytkowanie

Jako że interesowała mnie instalacja na pendrive, użyłem na początku UNetbootin, aby przerzucić Alpine na jednego pendrive’a. Po zalogowaniu się na konto root w pierwszym Alpine, podłączyłem drugiego pendrive i podążając za poleceniami skryptu setup-bootable zainstalowałem na tym właściwym (ergo drugim).
Dlaczego tak? Co prawda system zainstalowany przez UNetbootin jest w pełni używalny, ale znajduje się na jednej partycji FAT32. Skrypt instalacyjny tworzy natomiast partycje /boot oraz systemową, do tego swap. Pozwala także na szybką konfigurację systemu: układ klawiszy, hostname, hasło roota, bądź serwer SSH (swoją drogą polecam Dropbear). Warto także przejrzeć /etc, /etc/conf.d oraz /etc/rc.conf.

Menedżer pakietów

Menedżer pakietów (a raczej zestaw narzędzi apk-tools) ciężko nazwać wybitnym. Jest porównywalnie szybki z pacmanem, obsługuje podpisywanie pakietów, ma także jasną składnię. Idealnie sprawdza się na takim sprzęcie, jakim jest thinclient.
Najważniejsze polecenia apk to add do instalowania pakietów, del do usuwania ich, update do aktualizowania bazy pakietów oraz upgrade do aktualizowania systemu. Przydatny jest jeszcze search (nazwa jak sądzę nie pozostawia wątpliwości co do zastosowania), ale o wiele wygodniejsza jest wyszukiwarka pakietów dostępna na stronie projektu.

Zarządzanie demonami

Użytkownicy Gentoo mogą poczuć się jak w domu ” jak już wspomniałem, Alpine korzysta z dobrze znanego OpenRC. Do dyspozycji oddano użytkownikom polecenia rc-service, rc-update oraz rc-status. Pierwsze służy do zarządzania demonem (rc-service demon start/stop/restart), drugie do uruchamiania demona przy starcie lub wyłączania systemu (rc-update add/del demon boot/default/shutdown/sysinit), ostatnie do sprawdzenia, czy wszystkie demony uruchomiły się poprawnie. Prawda, że proste?

Statystyki

• uname -a

Linux thinclient 3.0.8-grsec #5-Alpine SMP Fri Nov 11 14:26:52 UTC 2011 i586 Linux

• free -m

             total         used         free       shared      buffers
Mem:           241            8          232            0            0
-/+ buffers:                  8          233
Swap:            0            0            

• ps_mem.py

 Private  +   Shared  =  RAM used	Program
 64.0 KiB +   0.0 KiB =  64.0 KiB	klogd
 68.0 KiB +   0.0 KiB =  68.0 KiB	syslogd
 68.0 KiB +   0.0 KiB =  68.0 KiB	acpid
 88.0 KiB +   0.0 KiB =  88.0 KiB	udhcpc
 88.0 KiB + 432.0 KiB = 520.0 KiB	crond
 80.0 KiB + 528.0 KiB = 608.0 KiB	getty
 76.0 KiB + 544.0 KiB = 620.0 KiB	init
216.0 KiB + 808.0 KiB =   1.0 MiB	ash (2)
356.0 KiB + 752.0 KiB =   1.1 MiB	dropbearmulti (2)

• df -h

Filesystem                Size      Used Available Use% Mounted on
mdev                      1.0M         0      1.0M   0% /dev
shm                     120.7M         0    120.7M   0% /dev/shm
/dev/sda3                 2.7G    269.5M      2.3G  10% /
tmpfs                   120.7M         0    120.7M   0% /run
rc-svcdir                 1.0M     48.0K    976.0K   5% /lib/rc/init.d
/dev/sda1                96.8M     13.9M     78.0M  15% /boot

Podsumowanie

Jaki koń jest każdy widzi. System idealnie sprawdza się w ciężkich warunkach dla systemów operacyjnych. Jest lekki, responsywny, uruchamia się poniżej minuty, instalowanie pakietów także przebiega sprawnie; wszystko to, czego nie uświadczyłem w Debianie. Oczywiście nie sprawdzi się wszędzie (chociaż według zapewnień deweloperów można bez problemów zainstalować środowisko graficzne), to jest świetnym rozwiązaniem użytkowania mniej wydajnego sprzętu. I prawdopodobnie zagości u mnie na dłużej, chyba, że zacznie działać niestabilnie.