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.



Wypożyczalnia rowerów w Poznaniu – kolejny fail.

Pisałem już o rzucie oka na nowopowstałe wypożyczalnie rowerów miejskich w Poznaniu oraz słabych zabezpieczeniach poznańskich rowerów miejskich. Niestety, wygląda, że system stworzony przez nextbike.pl ma większego pecha, a przynajmniej źle to wygląda z mojego punktu widzenia. Po paru tygodniach od uruchomienia automaty wyglądają w ten sposób (tu: automat koło dworca w Poznaniu w dniu 01.05.2012):

Automat nextbike Poznań.

Źródło: fot. własna.

Jak widać oznaczenia, czyli farba/nadruk elegancko zeszły z przycisków na automacie. Zakładam, że w trakcie zwykłego użytkowania. Jeśli tak dalej pójdzie, to za parę tygodni będą totalnie niewidoczne, a automaty nie będą się nadawały do użytku, chyba, że ktoś zna układ przycisków na pamięć (fakt, w przypadku cyfr nie jest trudno zapamiętać, ale reszta?). Pieniądze wyrzucone w błoto.

Ciekawy jest też sposób rejestracji w automacie. Bo nie ma co ukrywać, system kusi prostą rejestracją. Najpierw podajemy numer telefonu, następnie sześciocyfrowy PIN, a następnie… numer karty kredytowej. Czyli znowu dwa punkty wykonane na darmo.

Nie zmienia to faktu, że sam pomysł rowerów miejskich bardzo mi się podoba. Jak widać, znowu próbowałem się zarejestrować – liczyłem, że rejestracja i wypożyczenie roweru pójdzie szybciej, niż czekanie na tramwaj i przejazd tramwajem. Ale ilość błędów w systemie mnie drażni, bo te błędy przekładają się na koszt. Czyli mogło być taniej albo więcej wypożyczalni i rowerów, zamiast naprawiania takich usterek.

UPDATE: Zarejestrowałem się. 2. maja. Po rejestracji otrzymałem maila:

Po wpłynięciu środków pieniężnych Państwa konto będzie od razu aktywne. Zostanie również przesyłana wiadomość e-mail i SMS. Od tej chwili będziecie Państwo mogli wypożyczać rowery.

No i czekałem. I czekałem. I dziś chciałem wziąć rower. Ale nie wziąłem, bo konto nieaktywne. Ile można czekać na aktywację konta? Postanowiłem sprawdzić. Zalogowałem się tam i widzę:

Mój aktualny status: aktywne

Z jednej strony fajnie, że aktywne, z drugiej, gdzie powiadomienie o aktywacji, hę?



Jak zainstalować Debiana przy pomocy debootstrap – HOWTO

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…). Niemniej 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. Zatem jeśli coś się przypomni albo zmieni w nowszych wersjach systemów, to będę aktualizował instrukcję.

UPDATE: Może okazać się, że zainstalowana przy pomocy debootstrap maszyna, dostępna tylko po sieci nie pinguje się. Wtedy, jeśli skonfigurowaliśmy sieć, warto sprawdzić okolice /etc/udev/rules.d/70-persistent-net.rules czy MAC nie został przypisany do kolejnego interfejsu.