Prąd do budzika za darmo.

W budziku[1] wysiadła bateria. Zwykła bateria R14. Można kupić kolejną baterię i mieć spokój na rok czy dwa, a można pokombinować. Mam w domu trochę akumulatorów R6 (AKA AA), więc wpadłem na szatański – jak mi się wydawało – pomysł użycia akumulatora AA jako zamiennika.

Okazało się, że pomysł miałem dobry, bo jeśli chodzi o długość, to R14 i R6 są dokładnie takie same. Ale okazuje się, że nie jestem pierwszą osobą, która na to wpadła i nie trzeba wcale robić przejściówki pogrubiającej typu DIY (w planie był papier i taśma klejąca), bo za grosze dostępne są gotowe adaptery.

Pozostają dwie sprawy. Różnica napięcia 1,2V w akumulatorach vs. 1,5V w zwykłych bateriach. Nie do końca pomijalne, bo niektóre sprzęty czują różnicę (na różne sposoby, do „nie działa” do np. sygnalizowania rozładowania baterii). Okazuje się, że zegarek działa.

Sprawa druga, to pojemność. R14 nie są grubsze tak po prostu. Mają też większą pojemność, czyli starczają na dłużej, niż R6. Wg wiki, baterie R14 to od 8000 mAh w przypadku baterii alkalicznych, przez 6000 mAh w przypadku akumulatorów NiMH do 3800 mAh w przypadku zwykłych cynkowo-węglowych. Biorąc pod uwagę, że używałem zwykłych, a planuję użyć akumulatorów R6 o pojemności ok. 2000 mAh[2], spodziewać się mogę ok. 50% czasu korzystania, co w zupełności wystarczy.

Na deser jeszcze jedna sprawa. Wszystko jest interesujące tym bardziej, że akumulatory AA (3 sztuki) są używane w lampce z panelem słonecznym Sunnan (sekcja lampki Sunnan z IKEA). Co znaczy, że można je w takiej lampce w stosunkowo prosty i w miarę elegancki sposób[3] ładować za darmo, bez użycia prądu z sieci. Czyli kolejny krok bliżej niezależności energetycznej (taki mój konik, ekonomicznie to specjalnie sensu nie ma, póki co).

Umieszczenie tymczasowej baterii bez stosownej przejściówki okazało się nietrywialne, ale wykonalne. Budzik działa. Dam mu parę dni, żeby sprawdzić czy nie ma ewidentnych niedokładności i – jeśli będzie OK – kupuję przejściówkę i dedykowany akumulator (pewnie komplet od razu).

[1] Casio TQ 313. Aktualnie pełniącym rolę zwykłego zegarka. Jeśli chodzi o budziki, byłem bardzo wybredny i używałem tylko Casio. Powód był prosty – moje budziki musiały być na baterię, wskazówkowe i bardzo ciche. Był więc mniejszy, czyli Casio TQ 110 i większy, czyli Casio TQ 313 (jakoś nie widzę możliwości kupna w sieci, ani na stronie Casio, jeśli wycofany to wielka szkoda). Dość drogie, ale warto – działają latami, są dokładne. Teraz budzik mam w komórce, ale to zupełnie inna historia.

[2] Wiem, są akumulatory R6 o większej pojemności, nawet 2700 mAh, ale od dłuższego czasu korzystam tylko z ogniw nowej generacji, nie tracących szybko pojemności (np. Sanyo Eneloop), a te mają zwykle niższą pojemność od tradycyjnych. Lub są nieprzyzwoicie drogie, w przypadku wariantu znacznie większego od 2000 mAh.

[3] Elegancki optycznie. Rozwiązanie zastosowane w tej lampce jest bardzo prymitywne, jeśli chodzi o regulację napięcia i kontrolę ładowania. Tzn. w zasadzie brak czegokolwiek.

UPDATE: Ostatecznie korzystałem z Sanyo Eneloop 1900 mAh. Budzik przestał działać jakieś 2-3 tygodnie temu, co oznacza, że bateria wystarczyła na jakieś 2,5 roku pracy. Lepiej niż dobrze. 🙂

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.