PolicyKit w Debianie.

Wczoraj po krótkiej rozmowie 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.*
ResultActive=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. dodanie wpisu w /etc/hdparm.conf:

/dev/sda {
        apm = 254
        apm_battery = 254
}


UPDATE2: We wpisie o policykit był błąd: nie ResultAny=yes a ResultActive=yes (poprawione we wpisie). Po jakimś czasie zauważyłem, że nie działa, ale zwaliłem winę na lxpolkit, który w międzyczasie pojawił się w systemie (uroki unstable). Po bliższym przyjrzeniu – j.w. Nie żebym wnikał, czym to się dokładnie różni.



Jak zrobić backup bloga?

Na wstępie wyjaśnienie, skąd ten wpis. Na forum Blox co jakiś czas pojawiają się osoby, które straciłydorobek 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 robiąc backup bloga. 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 notatki lub bloga) się zdarzały, zdarzają i będą zdarzać.

Przed takimi sytuacjami można w prosty sposób się zabezpieczyć robiąc samemu backup 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 wget, 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. Aby zrobić automatyczny backup bloga 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.

UPDATE Przy okazji zrobieniu backupu starego bloga (zamknięcie Joggera) wyszła pewna wada – przynajmniej w przypadku Joggera braku http:// na początku URLi całość się nieprzyjemnie pętli i puchnie. Pewnie da się to obejść nie robiąc -m, tylko limitując poziom rekursji. Ja wolałem poprawić URLe. Wadliwe wpisy można prosto namierzyć po wielkości katalogów.

Nowy laptop

Dell 1440

Źródło zdjęcia (i recenzja, co prawda trochę inny model, bez grafiki AMD, ale reszta się zgadza): http://www.laptopreviews.com/dell-vostro-1440-review-2011-12

W końcu, po latach kupiłem sobie nowy laptop. Ostatnio jakoś cały czas korzystałem albo ze służbowego, albo z różnych starych. Nie da się ukryć, że stary laptop spisywał się dobrze do zadań podstawowych, ale… Tłumaczenie dla FSF z użyciem virtaal było ciut mało komfortowe, a zupełnie irytujące, gdy dorzuciłem do tego muzykę z YT. Zresztą YT ogólnie średnio działało, przynajmniej w przeglądarce. Bo z użyciem minitube to i owszem, ale jednak znowu – nie ten komfort. Tak więc po dwóch latach przyszła pora na zakup.

Po krótkim wyszukiwaniu w porównywarkach cen stanęło na Dellu Vostro 1440. Czemu taki nowy laptop? Matowy ekran (czemu, ach czemu nie ma tego do wyboru jako kryterium w żadnej porównywarce?!), jest mniejszy niż 15″ (tu miałem dylemat – albo 17″ i całkiem stacjonarnie, albo jednak trochę z zachowaniem mobilności – wybrałem to drugie rozwiązanie). Dużo – szczególnie jak na moje standardy – RAM, duży dysk. Chwilę wahałem się, czy wybrać wersję ze znienawidzoną kartą ATI (obecnie AMD), czy Intel. Ostatecznie stwierdziłem, że ATI gorzej tj. wolniej od Intela działać nie powinien, nawet na otwartych sterownikach, więc wziąłem tę z AMD. No i była wersja bez systemu. Znaczy z Linuksem.

No właśnie, laptop przyszedł z zainstalowanym Ubuntu (IIRC 10.10), które zrobiło naprawdę rewelacyjne wrażenie na pierwszy rzut oka. Wszystko działa: i wifi, i grafika, i dźwięk, i hibernacja. I wyglądało całkiem elegancko. Przeszła mi myśl, czy nie zostawić tego systemu. Niestety, po bliższych oględzinach i próbie aktualizacji wyszły wady: synaptic zawiesił się na aktualizacji pythona (czy też jego modułów). Program do testowania systemu uruchomiony w międzyczasie zawiesił się na sztywno, gdy odmówiłem mu podania hasła do roota i żadną miarą nie dawał się w cywilizowany sposób wyłączyć. W niecywilizowany (kill z konsoli) też nie, bo nie mogłem skorelować nazwy procesu z tymże programem. Czarę goryczy przepełnił Firefox w wersji 3.6 oraz zainstalowany Skype (i pewnie masa innego non-free syfu). Stwierdziłem, że mam gdzieś taki system, nad którym nie panuję, nagrałem płytę rescue na wszelki wypadek i zabrałem się za instalację Debiana przy pomocy debootstrap (stąd m.in. tamten wpis).

Sam zakup też nie jest trywialny w naszym pięknym kraju. Pierwszy sklep, po potwierdzeniu dostępności towaru, wymaganej obowiązkowej rejestracji (nie lubię) i złożeniu zamówienia skontaktował się… W celu poinformowania, że nie obsługują osób fizycznych, wyłącznie firmy i instytucje. Nie rozumiem idei takiego postępowania (przychodzi mi jedynie na myśl chęć uniknięcia 10 dni na zwrot towaru przy zakupie zdalnym), ale drugi sklep, z ceną o kilka zł wyższą nie miał takiego problemu. Warto jedynie odnotować, że w sumie zakup zajął mi tydzień.

Po dość długiej synchronizacji danych (uroki karty wifi bez anteny w starym laptopie, kabla nie chciało mi się szukać…) system w zasadzie działał. Istnieje parę przyjemniejszych rzeczy, niż migracja z 32 bit na 64 bit. Chodzi o parę pakietów, którym zmieniają się nazwy. I całkiem sporo pakietów (w tym Bloxer2), które nie są popaczkowane, a które trzeba było przeinstalować na wersję 64 bit. Niemniej ostatecznie wszystko działało OK. Sprzęt działa praktycznie od kopa na kernelu 3.2.x , włączając wifi i hibernację (po konfiguracji, którą musiałem sobie odświeżyć). Akceleracja 3D w karcie AMD też działała po instalacji fglrx, ale stabilność pozostawiała nieco do życzenia. Znaczy raz się zwiesił (ale podczas gry w Nerdquiz!), więc fglrx poszły w odstawkę. Na chwilę, bo później do nich wróciłem i było OK.

Żeby nie było za fajnie – przy lspci okazało się, że laptop ma dwie karty graficzne. Wspomnianą AMD oraz… zintegrowanego Intela. Co ciekawe, domyślnie korzysta ze zintegrowanego Intela. I działa to całkiem wystarczająco – YT jest płynne. Tym bardziej wystarczająco, że zabawa z vgaswitcheroo to jakaś masakra i rzeźba. I nie działa. I są zwisy (podobnie, jak przy fglrx).

Dowiedziałem się też, że kernele serii rt w ogóle z fglrx nie działają. A sterowanie prędkością wiatraka to zupełna abstrakcja. Niby i8kfan pozwala na coś, ale to coś działa po chwili mocno losowo i zupełnie niezgodnie z konfigiem. Nie wiem, czy ACPI się wdaje w paradę czy o co chodzi, ale ustawienie do którego przywykłem korzystając ze starego laptopa, czyli totalna cisza, a w okolicy bliskiej gotowania totalne wycie chwilowo wydaje mi się nieosiągalne. Przy okazji – osiągnięcie temperatury bliskiej gotowania nie było tam takie proste… Być może chodzi o kartę graficzną? W każdym razie będzie nad czym posiedzieć.

Z innych wad, które ma nowy laptop: spacja jest przesunięta trochę w prawo, co powoduje, że odruchowo naciskałem spację, zamiast prawego alt przy pisaniu pl-znaków. Na szczęście przesunięcie jest minimalne, a trochę głębsze podwijanie kciuka weszło mi już w krew. Dokładniejszy opis jak działa Debian na tym sprzęcie pewnie pojawi się za jakiś czas. Generalnie wygląda całkiem dobrze. No i skoro mam sprawną baterię, to mogę korzystać bardziej mobilnie. Ale jeszcze się nie przestawiłem mentalnie i nadal klikam przy biurku.