Cron i Gnome

Pod koniec dnia pracy mam potrzebę przesłać sobie katalog roboczy na serwer. Niby proste. Można użyć scp, można użyć rsync, tylko trzeba o tym pamiętać, a zdarza mi się zapomnieć.

Skoro taki jestem zapominalski, to zrobiłem sobie crony.

16 16 * * 1-5 /usr/bin/rsync -vaxAXHSz --delete /home/lukasz/wazny_katalog/ login@domena.pl:/home/lukasz/dane/wazny_katalog/ &> /home/lukasz/programy/rsync/rsync.log

19 16 * * 1-5 cd /home/lukasz/programy/rsync ; /usr/bin/python3 powiadomienie.py &>/dev/null

Cron z godziny 16:16 to jest jeszcze proste. Rsync kopiuje (lub nie, jak mu coś nie wyjdzie) zawartość katalogu. Komunikaty zapisuje w pliku rsync.log.

O godzinie 16:19 do akcji wchodzi skrypt Pythona, który uruchamia komunikaty pulpitu Gnome.

#!/usr/bin/env python3

from gi.repository import Notify
Notify.init('Rsync plików')

with open('rsync.log','r') as rsync_log:
  rsync_log_txt = rsync_log.read()
  if 'failed' not in rsync_log_txt:
    Notify.Notification.new('Przesyłanie plików OK').show()
  else:
    Notify.Notification.new('BŁĄD PRZESYŁANIA plików').show()

Rsync ma to do siebie, że nieudane przesyłanie plików opatruje komunikatem zawierającym słowo kluczowe „failed”, jaki ten błąd by nie był. Jeżeli przesyłanie plików pójdzie dobrze, a tak zazwyczaj jest, pojawi się komunikat „Przesyłanie plików OK”. Jeżeli tak się nie stanie i zobaczę „BŁĄD PRZESYŁANIA PLIKÓW”, muszę powtórzyć rsynca ręcznie w terminalu i tyle. Może i to taka pierdoła, ale od tego w końcu komputer jest, żeby o nich pamiętać.

Aktualizacja Debiana

Od jakiegoś czasu jest dostępny Debian 10, zarówno oficjalny, jak i Raspbian dla komputerków Pi. Aktualizacja tego systemu do nowej wersji jest, zdaje się, najprostsza ze wszystkich dystrybucji.

W Raspbianie należy wyedytować dwa pliki:

  • /etc/apt/sources.list,
  • /etc/apt/sources.list.d/raspi.list.

W obydwu przypadkach trzeba zmienić słówka „stretch” na „buster”. Potem, jak przy każdej aktualizacji, standardowe:

sudo apt update
sudo apt full-upgrade

Jak to w Debianach bywa, podczas aktualizacji zostaniemy poproszeni o podjęcie kilku decyzji co do plików konfiguracyjnych. Mi zależało jedynie na zachowaniu mojej konfiguracji Samby. Resztę pozwoliłem nadpisać, używając plików z nowych wersji programów. Aktualizacja była płynna i bezstresowa. Tylko na chwilę klienty nie mogły znaleźć udziałów smb, co po chwili wróciło do normy. Po aktualizacji przyda się restart, bo mamy nowe kernele. Zarówno Samba, jak i Pihole działają po restarcie, jakby nic się nie stało. Ot uroki Debiana.

Linux dla leworęcznych

Mamy kilka naprawdę dziwacznych skrótów klawiaturowych: alt+F4, ctrl+c, ctrl+v i kilka innych. co w nich dziwnego? Spróbuj przełożyć myszkę o lewej ręki i spróbować ich użyć.

Jako, że cały czas używam Serwera X, mam do dyspozycji kilka programów, które są tym bardzo pomocne. przygotowałem sobie mały skrypt, który uruchamiam po zalogowaniu:

#!/usr/bin/sh
# mapowanie klawiatury dla lewej reki

# numpad 0
xmodmap -e "keycode 90 = Super_L"

# numpad 1
xmodmap -e "keycode 87 = c"

# numpad 2
xmodmap -e "keycode 88 = v"

# numpad 3
xmodmap -e "keycode 89 = Control_R"
xmodmap -e "add control = Control_L Control_R" 

# numpad 4
xmodmap -e "keycode 83 = Tab ISO_Left_Tab Tab ISO_Left_Tab"

# numpad 7
xmodmap -e "keycode 79 = F4 F4 F4 F4 F4 F4 XF86Switch_VT_4"

# numpad 8
xmodmap -e "keycode 80 = Alt_L"

# numpad .
xmodmap -e "keycode 89 = z"

Po kilka dniach przyzwyczajenia działa to rewelacyjnie. co prawda nie mam cyfr na klawiaturze numerycznej, ale nie jest to jakoś szczególnie uciążliwe.

Bash dla każdego

Większość języków programowania ma jakoś zaimplementowane pętle for. Bash nie jest tu wyjątkiem, chociaż składnia jest po Bashowemu trochę udziwniona. Najpierw podam najprostszy przykład sprawdzający wielkość plików w katalogu:

for plik in `ls /home/lukasz/katalog` ; do du -h $plik ; done

Najpierw wymyślamy nazwę zmiennej, do której będziemy podstawiać kolejne wartości podawane przez ls, a potem wykonujemy du -h na każdej jednej z tych wartości. Sztuczka polega na tym, że lista ma być po prostu ciągami znaków oddzielonymi spacją, lub znakiem nowej linii. Może to być więc lista domen zapisana w pliku:

for linia in `cat domeny.txt` ; do echo $linia ; host $linia ; echo '------------------' ; done

Inny przykład: oglądanie plików hosts.

for i in `cat hosty` ; do echo $i; ssh -o PreferredAuthentications=publickey -o PasswordAuthentication=no -l lukasz $i "cat /etc/resolv.conf" ; echo '------------------' ;
done

Dzięki PrefferedAuthentications oraz PasswordAuthentication unikniemy zapytań o hasło i, nawet jeżeli nasza lista hostów będzie bardzo długa, możemy wrócić do komputera po minucie i sktypt zakończy działanie, informując gdzie nie mógł logować się po kluczu.

Linux dla leworęcznych

Nauczyłem się obsługiwać myszkę lewą ręką. Prawa czasem pobolewa mnie po pracy, więc pomyślałem, że czas na zmianę. Wszystko generalnie działa, ale skróty klawiszowe, których Gnome ma coś około osiemdziesięciu i są naprawdę przydatne, są zaprojektowane pod używanie ich lewą ręką. Z pomocą przyszły stare, dobre Xsy. Podawany przeze mnie sposób nie zadziała na Waylandzie.

Najpierw sprawdzam jak wygląda moja klawiatura w Xsach:

xmodmap -pke

Następnie zmapowałem klawisze:

  • NUM7 jako F4,
  • NUM8 jako lewy ALT,
  • NUM4 jako TAB,
  • NUM0 jako WINDOWS,
  • NUM2 jako c,
  • NUM3 jako v.

Zapisałem to sobie w krótkim skrypcie shella, który z czasem będzie pewnie rozbudowywany:

#!/usr/bin/sh
# mapowanie klawiatury dla lewej reki
xmodmap -e "keycode 79 = F4 F4 F4 F4 F4 F4 XF86Switch_VT_4"
xmodmap -e "keycode 90 = Super_L"
xmodmap -e "keycode 88 = c"
xmodmap -e "keycode 89 = v"
xmodmap -e "keycode 80 = Alt_L"
xmodmap -e "keycode 83 = Tab ISO_Left_Tab Tab ISO_Left_Tab"

Po dwóch dniach przyzwyczajania pracuje mi się z tym wspaniale. Lewa ręka jest na myszcze, a prawa na klawiaturze numerycznej. Jednego, czego brakuje to lewego CRTL, którego chcę mieć pod jedynką, ale nie mogę go prawidłowo zmapować. Dopiszę, kiedy mi się to uda.

Flathub i CentOS i Gnome

CentOS ma swoje zalety, podobnie jak wszystkie inne klony Red Hata i sam RHEL oczywiście. Ma też swoje wady, takie jak niewielka ilość oprogramowania w repozytorium. Tak jak lubię mieć sprawdzone i wolne od dziur oprogramowanie, tak czasami potrzebuję po prostu oprogramowanie, a tu go nie ma.

Poniżej przedstawiam scenariusz instalacji najnowszej wersji rewelacyjnego Gnome-Calendar, który widzi moje kalendarze z Nextcloud. Jak dotąd nie widziałem bardziej czytelnego, lepiej zintegrowanego z resztą pulpitu oraz sieciowymi serwisami programu, oprócz Lotus Organizer 5, który jest klasą sam dla siebie. 🙂

Najpierw zainstalujemy flatpak, czyli coś pomiędzy RPM, a kontenerem. Razem ze konkurencyjnymi Snap oraz AppImage wnosi powiem świeżości w nieco staroświecki sposób dystrybucji oprogramowania na Linuskie i pozwala programistom rozprowadzić gotowe, skompilowane oprogramowanie bez pośrednictwa dystrybucji. Oczywiście zawsze coś za coś. Jeżeli program wymaga jakiś zależności, programista musi je dostarczyć, co wiąże się często z dublowaniem tych samych bibliotek w działającym systemie, co jest antytezą klasycznie linuksowego, czystego i bardzo wydajnego podejścia „jedna wersja biblioteki do wszystkiego i umawiamy się, że używamy właśnie tej”. Czasami jednak poszukiwany przez nas program wymaga nowszej, i co wtedy? Wtedy pomaga flatpak. A więc:

yum install flatpak
flatpak remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo

co da nam zarówno samego flatpaka, jak i dostęp do zasobów flathuba, zawierającego wiele już przygotowanych programów. Flathub generalnie nie jest wymagany i ma się do Flatpaka mniej więcej jak Github do Gita, ale jest na nim wiele Gnomowych programów. Instalujemy więc nasz kalendarz:

 flatpak install flathub org.gnome.Calendar

Po kilku pytaniach i potwierdzeniach możemy uruchomić kalendarz jak każdy inny program.

Robimy klucz GPG

Co jakiś czas mam potrzebę coś zaszyfrować, a potem odszyfrować. Posługuję się programem gpg. Nie wdając się w technikalia:

gpg --gen-key

uruchomi prosty kreatorek do generowania plików kluczy. Na trzy pierwsze pytania: rodzaj klucza, rozmiar klucza i czas przedawnienia nie odpowiadam, wciskając enter i pozostawiając ustawienia domyślne, czyli RSA and RSA, 2048, 0. Następnie podaję swoje imię i nazwisko (w zasadzie można wpisać cokolwiek). Tutaj radzę unikać polskich znaków, gdyż nigdy nie wiadomo jakie locale się trafi na jakiej maszynie i prędzej czy później będziemy oglądać krzaczki. Dalej podaję email (prawdziwy, lub nie). Potem gpg prosi o krótki komentarz do klucza, którego nie wpisuję i naciskam enter.

Teraz zaczyna się magia. 🙂 Powinniśmy dać komputerowi coś do roboty, by uzbierał sobie dużą ilość losowych danych, na których gpg będzie mógł pracować. Ja akurat miałem Pythona do skompilowania, ale może to być cokolwiek. Po kilku minutach nasz błyszczący klucz prywatny oraz publiczny znajdzie się w katalogu ~/.gnupg. Dobra… ale jeżeli mam więcej niż jeden komputer? Nie mogę wygenerować nowego klucza, podpisać się na nim tym samym imieniem oraz nazwiskiem oraz oczekiwać, że będzie identyczny.

Gpg przewiduje eskport oraz import kluczy. Eksport klucza publicznego i prywatnego:

gpg -a --export > publiczny.asc
gpg -a --export-secret-keys > prywatny.asc

Pliki te należy przenieść na drugi komputer w bezpieczny sposób, na przykład przez scp. Importujemy je tak:

gpg --import publiczny.asc
gpg --import prywatny.asc

Od teraz mamy identyczne klucze na dwóch różnych komputerach. Możemy się upewnić, że są na miejscu za pomocą:

gpg --list-keys

dnf makecache

Fedora, podobnie zresztą jak kilka innych dystrybucji, ma pewną upierdliwą właściwość: menedżer pakietów co jakiś czas pobiera informacje o tym, co się zmieniło w repozytoriach. Na szybkim łączu i z szybkim procesorem nawet bym tego nie zauważył, ale na laptopie od razu wiem kiedy dnf się włącza. Szczęśliwie można się tego pozbyć:

sudo systemctl mask dnf-makecache
sudo systemctl mask dnf-makecache.timer

a dla Red Hata, CentOSa, Scientifica i starych wersji Fedory:

sudo systemctl mask yum-makecache
sudo systemctl mask yum-makecache.timer

i już. Nie to, żeby makechache nie był całkiem sensownie zrobiony: nie uruchamia się podczas pracy na baterii oraz przy pracy bez wifi. Dnf i tak będzie odświeżał cache przy okazji ręcznej instalacji, aktualizacji oraz szukania pakietów, czyli dokładnie wtedy, kiedy tego potrzebuję.

Aktualizacja Fedory

Lubię, kiedy coś po prostu działa. Jest proste, zrozumiałe i niemagiczne. Dlatego przy aktualizacji Fedory do nowego wydania posługuję się czystym dnf, bez żadnych pomagaczy i wtyczek. Wystarczy zaktualizować pakiety z plikami *.repo i dnf dalej sobie poradzi.

 

mkdir 28
cd 28
wget ftp://ftp.icm.edu.pl/pub/Linux/fedora/linux/releases/28/Workstation/x86_64/os/Packages/f/fedora-release-28-1.noarch.rpm
wget ftp://ftp.icm.edu.pl/pub/Linux/fedora/linux/releases/28/Workstation/x86_64/os/Packages/f/fedora-repos-28-1.noarch.rpm
wget https://download1.rpmfusion.org/free/fedora/rpmfusion-free-release-branched.noarch.rpm
wget https://download1.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-branched.noarch.rpm
wget ftp://ftp.icm.edu.pl/pub/Linux/fedora/linux/releases/28/Workstation/x86_64/os/Packages/f/fedora-release-workstation-28-1.noarch.rpm
wget ftp://ftp.icm.edu.pl/pub/Linux/fedora/linux/releases/28/Workstation/x86_64/os/Packages/f/fedora-gpg-keys-28-1.noarch.rpm
sudo dnf clean all
sudo rpm -Uvh *rpm
sudo dnf update -y
reboot

Działa tak samo dobrze, jak system-upgrade, ale widzę i wiem, co się po kolei dzieje.