Pomiędzy bitami

Wczoraj po krótkiej rozmowe na kanale IRC zostałem przekonany do przejścia na unstable pełną gębą (plus odrobinka testing...). Do tej pory korzystałem ze stable plus backporty plus testing plus unstable, gdzie ok. połowy pakietów było ze stable. Upgrade przebiegł pomyślnie i w sumie dość bezproblemowo: przestała działać karta wifi (kwestia zdjęcia blacklist odpowiednich modułów), odinstalowało fglrx (nie patrzyłem jeszcze czemu, grafika Intela działała od kopa) i... znowu system przestał pozwalać na wyłączenie, wstrzymanie i hibernację.

Piszę znowu, bo temat jest znany i stary, pamiętam odkąd używam Debiana z LXDE, że był z tym problem. Czyli chyba od Lenny'ego. Na pewno było w Squeeze. Do tej pory pomagało ubicie procesu  /usr/lib/policykit-1/polkitd, albo, trwalej, usunięcie pakietu policykit-1. Mało eleganckie, ale proste i skuteczne. Zresztą na żadnym z moich desktopów nie potrzebowałem takich wynalazków.

Problem z PolicyKit jest taki, że może i jest to fajne, ale wygląda na skomplikowane, a dokumentacja jest żenująca - wystarczy spojrzeć na opis PolicyKit na wiki Debina. No i co najgorsze, niespecjalnie są przykłady. Podobnie jest w wielu innych miejscach, a nawet jeśli coś jest, to często są to stare i nieaktualne dane. Ostatecznie pomógł ten wpis nt. PolicyKit i opis PolicyKit na wiki Arch. Po kolei, czyli najpierw wyświetlanie dostępnych w systemie akcji - polecenie pkaction. Jego wynik to u mnie:

com.ubuntu.pkexec.gparted
org.blueman.bluez.config
org.blueman.dhcp.client
org.blueman.hal.manager
org.blueman.network.setup
org.freedesktop.consolekit.system.restart
org.freedesktop.consolekit.system.restart-multiple-users
org.freedesktop.consolekit.system.stop
org.freedesktop.consolekit.system.stop-multiple-users
org.freedesktop.policykit.exec
org.freedesktop.policykit.lockdown
org.freedesktop.udisks.cancel-job-others
org.freedesktop.udisks.change
org.freedesktop.udisks.change-system-internal
org.freedesktop.udisks.drive-ata-smart-refresh
org.freedesktop.udisks.drive-ata-smart-retrieve-historical-data
org.freedesktop.udisks.drive-ata-smart-selftest
org.freedesktop.udisks.drive-detach
org.freedesktop.udisks.drive-eject
org.freedesktop.udisks.drive-set-spindown
org.freedesktop.udisks.filesystem-check
org.freedesktop.udisks.filesystem-check-system-internal
org.freedesktop.udisks.filesystem-lsof
org.freedesktop.udisks.filesystem-lsof-system-internal
org.freedesktop.udisks.filesystem-mount
org.freedesktop.udisks.filesystem-mount-system-internal
org.freedesktop.udisks.filesystem-unmount-others
org.freedesktop.udisks.inhibit-polling
org.freedesktop.udisks.linux-lvm2
org.freedesktop.udisks.linux-md
org.freedesktop.udisks.luks-lock-others
org.freedesktop.udisks.luks-unlock
org.freedesktop.upower.hibernate
org.freedesktop.upower.qos.cancel-request
org.freedesktop.upower.qos.request-latency
org.freedesktop.upower.qos.request-latency-persistent
org.freedesktop.upower.qos.set-minimum-latency
org.freedesktop.upower.suspend
org.kde.kcontrol.kcmremotewidgets.save

Jak widać uprawnienia odpowiedzialne za suspend i hibernację są w jednej grupie (czy też raczej gałęzi drzewa), a restartowanie i zatrzymywanie systemu - w innej. Ostatecznie utworzyłem plik /etc/polkit-1/localauthority/50-local.d/10-my-power-policy.pkla o zawartości:

[Let rozie shutdown]
Identity=unix-user:rozie
Action=org.freedesktop.upower.*;org.freedesktop.consolekit.system.*
ResultAny=yes

Jak widać z wildcardem, bo - jak wspomniałem - niespecjalnie zależy mi na ograniczaniu samego siebie. Ale można podać konkretne uprawnienia, po średniku. Podobnie, można przyznać uprawnienia grupie użytkowników, a nie tylko pojedynczemu. Wówczas linia odpowiedzialna za przyznanie uprawnień dla usera rozie i dodatkowo grupy będzie miała postać:

Identity=unix-user:rozie;unix-group:jakaśgrupa

Na wiki Debiana jest pokazany screenshot policykit-gnome, ale jakoś nie udało mi się na to natknąć, choć pakiet mam zainstalowany. Może Gnome only i dlatego na LXDE nie działa?

UPDATE: Skoro już o naprawianiu błędów po upgrade do unstable, to jeszcze jedna ważna rzecz, którą "zepsuł" upgrade - po odłączeniu zasilania dysk co chwilę zatrzymuje się i rozpędza. Czyli co kilkadziesiąt sekund spin down i spin up. Tradycyjne miejsca (hdparm, apmd itp.) okazały się niewinne, rozwiązaniem okazało się odinstalowanie upower dostarczającego upowerd, który wygląda na słabo konfigurowalny.

Na wstępie wyjaśnienie, skąd ten wpis. Na forum Blox co jakiś czas pojawiają się osoby, które straciły dorobek paru lat życia. Znaczy takie, których blog - z różnych przyczyn - przestał być dostępny. I zniknęły cenne wpisy (pół biedy, bo to ludzie czasem mają zapisane lokalnie) oraz jeszcze cenniejsze komentarze. Widziałem narzekania na administrację Blox, gorzkie żale, próby wyciągania treści z cache Google itp. hardcore, na dodatek nie zawsze skuteczny. Wszystko niepotrzebnie, bo ww. opisanym tragediom^[1] można w prosty sposób zapobiec. Oczywiście problem nie dotyczy tylko Blox, tak samo może zdarzyć się na innych platformach.

Trzeba uświadomić sobie dwie rzeczy. Po pierwsze, blog, a dokładnie jego zawartość jest treścią tworzoną samodzielnie, przez długi okres czasu, trudno odtwarzalną. Szczególnie, jeśli uwzględnimy komentarze. Po drugie, żaden serwis, a już na pewno nie darmowy, nie daje specjalnych gwarancji na to, że dane nie znikną. Jasne, zwykle nie znikają. Co więcej, jeśli nawet znikną, to zwykle administracja serwisu ma backup, który może przywrócić. Jednak awarie i błędy ludzkie (samodzielne skasowanie notki lub bloga) się zdarzały, zdarzają i będą zdarzać.

Przed takimi sytuacjami można w prosty sposób się zabezpieczyć robiąc samemu bakcup swojego bloga. Szansa, że nastąpi awaria krytyczna awaria w dwóch różnych miejscach, jest pomijalna. Tak naprawdę samo jednorazowe skopiowanie to jedno polecenie, jeśli chcemy zautomatyzować, warto skorzystać z prostego skryptu. Wybrałem wariant najprostszy, z użyciem programu [i]wget[/i], dostępnego w każdej dystrybucji Linuksa^[2], który powinien działać na każdej platformie blogowej (udostępniającej wszystkie wpisy bez logowania), a tworzy backup, który można bezpośrednio wgrać na dowolny serwer WWW i treść będzie od razu dostępna i wyglądająca praktycznie identycznie, jak na blogu. Oczywiście po takim przywróceniu działać będzie tylko odczyt, bez możliwości dodawania komentarzy itp. Co prawda średnio da się z tego automatycznie przywrócić w pełnej formie czy przenieść na inny silnik blogowy, ale najważniejsza rzecz, czyli treść, jest zachowana.

Backupowane są strony z wpisami (i oczywiście komentarzami), hostowane lokalnie zdjęcia i skrypty JS. W przypadku Blox także te strony statyczne, do których jest "przejście" przy pomocy linków. Nie są bacupowane strony, do których nie ma przejścia, linkowane strony, materiały umieszczone na zdalnym hostingu (np. muzyka umieszczona na soundcloud). Najlepiej i najprościej uruchomić i samemu sprawdzić, co się pobrało. Przy zmianie szablonu i linkowań może rzecz jasna dojść do zmiany zawartości nowych backupów.

Koniec tego przydługiego, ale koniecznego moim zdaniem wstępu. Prawda jest taka, że najsłabszym ogniwem jest człowiek i jeśli nie uruchomi się automatycznego backupu, to w najpotrzebniejszym momencie danych nie będzie. A samo się nie włączy. Czyli klasyczne ludzie dzielą się na tych, którzy robią backupy i tych, którzy będą je robić.

Do rzeczy. Aktualnie korzystam z polecenia:

wget -q -m -p -E -k http://rozie.blox.pl

Opcje (krótko): q - brak wyświetlania wyjścia, m - mirror, p - ignorowanie poziomu rekursji, E - konwersja plików do HTML niezależnie od rozszerzenia, k - konwersja linków na lokalne. Bardziej szczegółowy opis każdej opcji w pomocy programu.

Cały skrypt dla Linuksa, który można dodać do crona, żeby raz na jakiś czas się uruchamiał - poniżej. Wersja moja, trzeba sobie dostosować. Łatwo daje się przerobić na backupowanie kilku blogów.

Mam nadzieję, że będzie parę tragedii mniej. Chętnie usłyszę uwagi do tego sposobu i propozycje poprawy. Jakby ktoś chciał popełnić dokładny opis dla Windows, to zapewne ludziom się to bardziej przyda.

Przydatne linki (stąd wiem, że działa także dla Blogspot i Wordpress, a także podpatrzyłem kilka opcji):

Automatyzacja backupu bloga Blogspot

Automatyzacja backupu bloga Wordpress

[1] Tak, nabijam się. Zawartość bloga, konta na FB czy µbloga nie jest dla mnie tak ważna. Ale wiem, że niektórzy podchodzą do tego inaczej.

[2] Jest też wersja wget dla Windows, kiedyś używałem i działała. Oczywiście cały skrypt wymaga przepisania na platformę Windows, co nie jest trudne. Przydadzą się zapewne gzip dla Widnows oraz tar dla Windows, chyba, że od razu skorzysta się z jakiegoś natywnego archiwizera plików typu rar, zip itp.

Co prawda instalacja systemu przy pomocy debootstrap jest trywialna, opisów są setki, a i man debootstrap niby jest wystarczający, ale zawsze kończy się tak, że o czymś zapominam jak z głowy robię i muszę bootować powtórnie, więc postanowiłem spisać. Tym bardziej, że ostatnio jest to najpopularniejsza dla mnie metoda instalacji - instalator Debiana został wykastrowany z niewolnych firmware'ów, przez co instalacja Debiana na laptopach czy ultrabookach, gdy nie ma przewodowej karty sieciowej jest... powiedzmy delikatnie niefajna. No i parę instalacji znowu w ostatnim czasie było.

Instalację przy pomocy debootstrap można zrobić z dowolnego systemu, nie musi być to Debian. Zwykle korzystam z Debiana live lub - ostatnio - Ubuntu w wersji live (jakoś lepiej sprzęt wykrywa, a nie mam czasu sklikać debianowego live z testing/unstable...), ale z bardziej pamiętnych zdarzało się i Gentoo. Cokolwiek co ma pakiet debootstrap się nada. Kolejne kroki wyglądają tak:

• utworzenie i sformatowanie partycji, na którą ma być zrobiona instalacja
• utworzenie punktu montowania, zamontowanie partycji - mkdir /chrooted; mount /dev/sda3 /chrooted
• debootstrap właściwy - debootstrap squeeze /chrooted http://ftp2.de.debian.org/debian/
• podmontowanie proc- mount proc /chrooted/proc -t proc
• podmontowanie dev i sys - mount --bind /dev/ /chrooted/dev; mount --bind /sys/ /chrooted/sys
• wejście do chroota - chroot /chrooted /bin/bash
• edycja sources.list i aktualizacja listy pakietów
• instalacja kernela, firmware'ów (także niewolne, jeśli wymagane), gruba
• aktualizacja wpisów dla grub - update-grub2
• instalacja dodatkowych programów - apt-get install wajig less mc wicd wpasupplicant wicd-curses
• edycja /etc/fstab, /etc/network/interfaces, /etc/hosts (w sumie bez tego też działa)
• zmiana hasła root, ew. dodanie użytkowników
• wyjście z chroota - exit
• reboot kontrolny - system powinien działać

Jest szansa,  że o czymś zapomniałem, więc pewnie będę uzupełniał.

No i udało się. Szczerze mówiąc myślałem, że będzie trudniej i nie przypuszczałem, że cel jest tak blisko. Blokada IRC przez HE o której pisałem niedawno okazała się świetnym motywatorem do skończenia testu, czyli osiągnięcia poziomu Sage, który pozwala na odblokowanie dostępu do IRC. No i okazuje się, że prawdą jest to, co chciałem sprawdzić, czyli że certyfkiat IPv6 od HE da się zrobić, nie wydając ani złotówki i korzystając wyłącznie z zasobów (domeny, serwery DNS), dostępnych zupełnie za darmo w Internecie.

Nie zamierzam robić tutoriala krok po kroku - sam proces certyfikacji jest prosty i w sumie daje sporo frajdy (pod warunkiem, że nie trzeba powtarzać kroków kilka razy jak w moim przypadku...), poza tym samo HE daje tutoriale video, ale parę wskazówek się przyda, żeby się nie frustrować niepotrzebnie.

Adresację (tunel) IPv6 za darmo dostaniemy na przykład od samego HE. Z kolei domeny (dobra, subdomeny) za darmo daje na przykład afraid.org w ramach usługi FreeDNS. Niestety, ich NSy nie posiadają adresów IPv6 (żaden!). Można to jednak obejść delegując subdomenę na takie NSy, które posiadają obsługę IPv6. Na przykład te od HE.

Żeby nie było za prosto - wygląda, że jest jakiś problem z cache'owaniem(?) wpisów DNS po stronie HE - w pewnym momencie panel żadną miarą nie chciał przyjąć obsługi domeny, mimo, że powinien (support też tak twierdził). Rozwiązaniem jest dodanie delegacji na wszystkie ns1 do ns5 na he.net. Potem, przy którymś teście co prawda trzeba usunąć ns1, bo test wymaga (IMHO błędnie, powinien sprawdzać czy minimum 1 ma), żeby wszystkie NSy miały adresy IPv6, ale to insza inszość.

I tyle. Warto dodać, że ukończenie certyfikatu IPv6 od HE daje nie tylko możliwość odblokowania dostępu do IRC. Dodatkowo (a może przede wszystkim?) każdy, kto uzyska poziom Sage może otrzymać fajną, geekową, unikatową koszulkę za darmo (wysyłka też) - wystarczy podać rozmiar w panelu HE i potwierdzić adres do wysyłki. Taki - podobno bardzo udany - pomysł HE na popularyzację IPv6.

Zachęcam do zabawy. Mi pozostało wymaksowanie punktów. Osobną kategorią zabawy jest znalezienie błędów (implementacyjnych, nie rzeczowych) w samym teście (można udawać, że się zrobiło pewne rzeczy, nie robiąc ich, ale nie o to oczywiście chodzi). ;-)

UPDATE: Szczerze mówiąc, myślałem, że Sage jest więcej, szczególnie, że sporo spotkałem na IRCu. Tymczasem na PLNOG dowiedziałem się, że jest raptem 87 osób w Polsce i ok. 4600 na całym świecie. Więcej statystyk.

Jakiś czas temu Sun zmienił politykę dotyczącą wydawania swojej wersji Javy, w wyniku czego wyleciała ona zarówno z Ubuntu, jak i Debiana. Użytkownicy zostali z niezaktualizowanymi wersjami, więc obie dystrybucje skierowały swoje zainteresowanie w stronę OpenJDK, która teoretycznie ma zapewnić wystarczającą funkcjonalność. Więcej o sprawie można poczytać tu w przypadku Debiana, oraz tu w przypadku Ubuntu. Ten drugi link zawiera instrukcję co zrobić, żeby mieć bezpieczny system, czyli opis migracji do OpenJDK na Ubuntu (IIRC dokładnie to samo należy zrobić w przypadku Debiana).

Fajnie, że jest wolne rozwiązanie, fajnie, że pewnie projekt OpenJDK dostanie niezłego kopa, jeśli chodzi o rozwój, ale jednak nie wszystkim w tej chwili wystarcza OpenJDK, które jest wolniejsze i... nie zawsze działa poprawnie (ja miałem problem z appletami VNC, które przydają się przy administracji sprzętem, zwłaszcza w przypadku rozwiązań typu KVM...). Wybór był trojaki: instalacja ręczna Javy od Sun, stara, dziurawa wersja albo niedziałanie aplikacji.

Pierwszy wybór jest męczący, jeśli ktoś lubi mieć wszystko w systemie spaczkowane (ja lubię), pozostałe dwa są niezbyt dopuszczalne w praktyce... Cieszy mnie więc reaktywacja projektu java-package (aktualnie dostępny w unstable, jeśli wszytko pójdzie dobrze, będzie we Wheezy), czyli prymitywnego skądinąd narzędzia pozwalającego na zrobienie w prosty sposób pakietu deb z Javą od Sun. Sam fakt spaczkowania oczywiście nie wpływa na działanie w żaden sposób, ale na pewno ułatwi utrzymanie porządku w systemach poprzez włącznie Javy od Sun do systemu zarządzania pakietami, wrzucenie do swojego repozytorium pakietów itp.

Jeśli w Debianie Squeeze (i zapewne nowszych) po wywołaniu np. snmpwalk dostajemy wszystko mówiący komunikat:

Unknown Object Identifier (Sub-id not found: (top) -> mib-2)

to należy:

• zainstalować pakiet snmp-mibs-downloader (wajig install snmp-mibs-downloader)
• zakomentować linię mibs : w pliku /etc/snmp/snmp.conf
• podziękować polityce Debiana, która pozwala mieć zupełnie wolny, choć niekoniecznie wystarczający do pracy z urządzeniami sieciowymi, system ;-)

Wiem, raczej proste do wygooglania. Zapisuję, bo z trzeci raz dziś tego szukałem, przy czym za pierwszym był gigantyczny WTF?!, bo zawsze działało...

Wygląda, że WPS (włączony domyślnie w wielu routerach) jest w tej chwili porównywalnie słaby, jak WEP. Niezależnie od użytego WPA/WPA2 możliwe jest - przy włączonym WPS - stosunkowo szybkie poznanie hasła do sieci WiFi ofiary, dodatkowo są gotowe narzędzia do tego celu (np. reaver-wps spaczkowany niedawno dla Debiana). Spodziewać się można niebawem aktualizacji firmware'ów dla routerów z dodaniem/wydłużeniem czasu dla funkcji lock down, ale to nie jest rozwiązanie, tylko drobne utrudnienie. Do szczegółów, w tym czasu brute force na WPS odsyłam do krótkiego, ale treściwego pdf ze strony.

Jak sprawdzić, czy sieć obsługuje WPS (czyli czy dana sieć jest podatna)? Najprościej (na Linuksie) przy pomocy wpa_supplicant - Przemek w komentarzach na tej stronie opisał jak, a wygląda, że da się prościej i wystarczy (Debian Squeeze z wicd jako helperem do WiFi):

wpa_cli scan

wpa_cli scan_results | grep WPS

Jeśli okaże się, że mamy włączonego WPS, a go nie potrzebujemy, to wypadałoby zmienić hasło do sieci WiFi oraz poszukać, czy WPS nie da się wyłączyć. Często (zwykle?) się da, przynajmniej na Linksysach.

Ostatni wpis traktujący o tym jak sprawdzić IP komputera zaowocował sporą ilością zapytań o to, jak sprawdzić IP komentującego na blogu albo forum. Sprawa może być utrudniona, bo adres IP bywa uznawany za daną osobową, a poza tym dobra praktyką jest ukrywanie przynajmniej części adresu przed osobami postronnymi. Zasadniczo wyróżnić można dwa przypadki:

Sprawdzanie IP komentarza przez osoby postronne

Wariant gorszy, bo dostęp jest bardzo ograniczony. W tym wariancie mamy trzy przypadki:

• Komentarz zamieszczony jest z zarejestrowanego konta - w takim przypadku adres IP ukryty jest całkowicie. Niewiele można zrobić, ale - patrząc z drugiej strony - wiemy dokładnie, kto (jaki nick) zamieścił dany komentarz, co zwykle lepiej określa osobę, niż adres IP.
• Jeśli komentarz dodawany jest bez logowania do serwisu, wygwiazdkowany. Również niewiele można zrobić, chyba, że ukrywanie części adresu jest zrobione bez głowy, np. schowana jest dokładnie jedna cyfra. Także schowanie jednego bloku adresu IP (np. wyświetlone 100.101.102.*) może pomóc w określeniu, kto dany komentarz zamieścił.
• Komentarz z widoczną nazwą hosta. Z niewiadomych przyczyn (zapewne chodzi o głęboką wiedzę w temacie, szerokie spojrzenie i konsekwencję) urzędnicy nie uznają - w przeciwieństwie do adresu IP - nazwy hosta za daną osobową, przez co pojawia się ona w wielu serwisach/forach zamiast IP komentującego, więc możemy zobaczyć np. adaa194.neoplus.adsl.tpnet.pl. Sprawdzenie IP w takim przypadku to zwykłe uruchomienie polecenia ping adaa194.neoplus.adsl.tpnet.pl (tak, ping nie jest do tego, ale jest dostępny na wszystkich systemach, popularny, jednolity...). Jeśli ktoś woli wersję online lub nie wie, jak dobrać się do wiersza poleceń w systemie, to pomoże strona hostname IP lookup. 

Sprawdzanie IP komentarza przez właściciela serwisu

Wariant lepszy, bo obok wszystkich środków dostępnych w poprzednim przypadku, możemy:

• Sprawdzić IP po zalogowaniu do systemu. Wiele systemów udostępnia w takim wypadku wprost IP komentującego właścicielowi bloga.
• Sprawdzić IP przy blokowaniu komentarzy z danego IP. Nawet jeśli adresy IP komentujących nie są widoczne wprost, to często pojawiają się podczas blokowania możliwości komentowania, czy to wprost, czy w linku do blokowania, czy wreszcie na liście adresów zablokowanych (blokujemy możliwość komentowania autorowi komentarza na moment, patrzymy jaki adres, odblokowujemy).
• Sprawdzić IP w systemie statystyk, jeśli korzystamy z takiego na stronie. Szczególnie przydatne przy niewielkim ruchu - łatwo wtedy skorelować dane wejście odnotowane w statystykach z czasem zamieszczenia komentarza. Na pewno ładnie widać to w stat4u, z którego korzystam.

Możemy też oczywiście sprawdzić IP połączenia, z którego zamieszczono komentarz w logach serwera WWW, jeśli działa na naszym hostingu lub mamy dostęp do logów.

HTH i wyczerpuje temat ustalania adresu IP.

W poprzednich wpisach było parę przemyśleń i sugestii poprawy komfortu pracy na desktopie wyposażonym w niewielką ilość pamięci RAM, bez finalnego rozwiązania choć z paroma trickami poprawiającymi pracę, więc pora na podejście trzecie do tematu, inspirowane przez kumpla z IRC, który sprzedał mi "newsa" o zram.

Od pewnego czasu (okolice kernela 2.6.37, jeśli dobrze widzę) w kernelu Linuksa obecny jest moduł zram, pozwalający na tworzenie kompresowanych urządzeń blokowych w pamięci RAM. Wykorzystać to można podobnie jak compcache, czyli do tworzenia kompresowanego obszaru pamięci, używanego przez system przed przeniesieniem danych na swap na dysku. Idea jest prosta - swap na dysku jest tragicznie wolny i obciąża I/O, procesor zwykle się trochę nudzi, zresztą nie będzie miał dużo więcej pracy, a ilość wolnej pamięci się zwiększy.

Ogólnie zram jest ideowym spadkobiercą compcache, ale wygląda mi na prostszy i ideowo, i w użyciu. No i jest obecny w kernelu. Idea działania jest prosta: tworzymy swap z wyższym priorytetem, niż swap na dysku, na urządzeniu blokowym umieszczonym w kompresowanym obszarze pamięci. Początkowo dane tradycyjnie są w RAM, w przypadku, gdy system musi korzystać z przestrzeni wymiany, umieszcza je najpierw na swapie w RAM, a dopiero później - tradycyjnie - na swapie na dysku.

Prosty skrypt realizujący powyższe:

#!/bin/bash
modprobe zram
echo $((200*1024*1024)) > /sys/block/zram0/disksize # 200 MB
mkswap /dev/zram0
swapon -p 60 /dev/zram0

Kolejno: załadowanie modułu zram (można korzystać z parametrów), określenie rozmiaru dysku dla urządzenia /dev/zram0 na 200 MB (i jest to rozmiar swap, będący jednocześnie maksymalną wielkością zużytej pamięci, nie rozmiarem przeznaczonej pamięci na swap!), utworzenie swapu na urządzeniu  /dev/zram0, włączenie utworzonego swap z priorytetem 60.

Podobno efekty są świetne - zaczynam testy u siebie, wstępnie nie wygląda źle, na pewno niebawem podzielę się wrażeniami (jako update do tego wpisu) po dłuższym teście. Jeśli chodzi o rozmiar swap dla modułu zram, to zacząłbym od 10-20% całości RAM (u mnie 200 MB przy 1 GB RAM). Z tego co zauważyłem, skompresowane dane zajmują w praktyce ok. 40-50% oryginalnych.

Parę przydatnych poleceń diagnostycznych:

• cat /sys/block/zram0/compr_data_size - rozmiar danych po kompresji
• cat /sys/block/zram0/orig_data_size - rozmiar nieskompresowanych danych
• cat /sys/block/zram0/mem_used_total - całkowita ilość zużytej pamięci
• swapon -s - rozmiar i wykorzystanie poszczególnych swap (inna jednostka!)

Linki w temacie, które zdecydowanie warto przejrzeć, jeśli ktoś jest bardziej zainteresowany:

• http://www.webupd8.org/2011/10/increased-performance-in-linux-with.html
• http://unix.stackexchange.com/questions/17879/cleancache-vs-zram
• https://lwn.net/Articles/454795/
• http://en.gentoo-wiki.com/wiki/Zram_disks
• http://crunchbanglinux.org/forums/topic/15344/zram-a-good-idea/

Szczególnie ostatni wpis zawiera fajny, uwzględniający ilość procesorów skrypt startowy. Można rozważyć użycie po przeanalizowaniu. IMHO dla 1-2 procesorów trochę kosmiczne wartości będą, uzależnianie wielkości swap od ilości procesorów też jest średnie, ale poprawienie to nic trudnego. Za to obsługą utworzonego urządzenia blokowego zajmie się w tamtym wariancie więcej, niż jeden procesor. Z drugiej strony kto ma więcej niż dwa rdzenie i mało RAM?

Miałem obawy co do działania hibernacji (z użyciem pm-utils, z uswsusp miałem problem...) w takiej konfiguracji. Niepotrzebnie, bo wygląda, że działa OK - zapewne hibernacja jest na tyle inteligentna, że rozpoznaje, czy ma do czynienia z fizycznym urządzeniem blokowym.

Oczywiście swap to nie jedyne możliwe zastosowanie modułu zram - więcej przykładów w linku do wiki Gentoo.

Ten wpis to takie małe HOWTO i przegląd zagadnienia dla mniej zaawansowanych. Zagadnienie ogólne to jak sprawdzić IP? Można to rozumieć przynajmniej na dwa sposoby. Pierwszy to z jakim IP jesteśmy widoczni w sieci, drugi to jakie IP ma ustawiony mój komputer.

Sprawdzenie IP widocznego w Internecie.

Generalnie, jeśli po drodze nie ma jakiejś zaawansowanej magii typu serwer proxy czy kreatywne przekierowania lub równie kreatywny routing, to do wszystkich serwisów w Internecie łączymy się z takiego samego IP. Z jakiego? Najprościej sprawdzić w logach dowolnego serwera, jeśli taki posiadamy. Jeśli nie, wystarczy skorzystać z którejś ze stron do sprawdzania IP:

• http://twojeip.wp.pl/ (łatwiej zapamiętać mojeip.wp.pl, który przekieruje w to samo miejsce)
• http://www.whatsmyip.org/
• http://whatismyipaddress.com/
• http://www.whatismyip.com/
• http://www.mojeip.net/

Ostatnia ze stron umożliwia również sprawdzanie w sposób automatyczny, przyjazny programistom raz na 5 minut (szczegóły w FAQ na stronie).

Spawdzanie swojego IP pod Linuksem

Konfiguracja sieci w Debianie i Ubuntu znajduje się w /etc/network/interfaces, ale niekoniecznie znajdziemy tam nasz adres IP, szczególnie, jeśli jest on pobierany z serwera DHCP. Bieżącą, działąjącą konfigurację sieci z przydzielonymi adresami pozwoli nam za to zobaczyć polecenie ifconfig (w Debinanie przez zwykłego użytkownika należy wywołać z pełną ścieżką, czyli /sbin/ifconfig). Inna metoda, o ile mamy zainstalowany pakiet iproute, to wpisanie ip address. Albo, krócej ip a.

Sprawdzanie IP komputera pod Windows

Metoda najdoskonalsza, czy w wierszu poleceń. Wybieramy Start -> Uruchom wpisujemy cmd i naciskamy klawisz Enter. Pojawi się czarne okno w którym możemy pisać. Wpisujemy ipconfig i naciskamy enter. Jeśli chcemy więcej danych, wpisujemy ipconfig /all (znowu zatwierdzając enterem). Dla porządku jeszcze niezawodne polecenie diagnozujące sieć opartą o DHCP - ipconfig /renew. Na pewno działa pod Windows 2000, Windows XP, Vistą i zapewne pod Windows 7 (tego ostatniego nie sprawdzałem).