Kategoria: Linux

Opublikowane w

Linux i powiadomienia via Telegram – HOWTO

Czemu zdecydowałem się na wysyłanie powiadomień via Telegram? Kiedyś wysyłałem SMSy z powiadomieniami, nawet zrobiłem skrypt do wygodnej wysyłki SMSów z CLI. Czasy trochę się zmieniły, telefony zostały zastąpione smartfonami. Po co płacić za SMSy, kiedy można wysłać powiadomienie inaczej, w dodatku za darmo? Wybrałem powiadomienia wysyłane przez Telegram.

logo Telegram
Źródło: https://www.freepnglogos.com/images/telegram-logo-944.html

Oczywiście istnieją inne metody. Zawsze można było wysyłać maile, które są co prawda darmowe, ale z założenia miewają opóźnienia. No i niekoniecznie chcemy dostawać powiadomienie na telefonie o każdym mailu. Gdy rozpoznawałem temat obiecująco wyglądały natywne powiadomienia push na telefon, ale ich uruchomienie nie jest proste. I nie do końca są darmowe, jak widać.

Znajomi zachwalali Telegram i jego możliwości, jeśli chodzi o tworzenie botów. Nawet kiedyś podchodziłem do uruchomienia bota Telegram, ale wydało mi się to wtedy skomplikowane. I samo stworzenie bota, i sama interakcja. Czyli wysłanie komendy, by coś wykonał i odesłał wynik. Dodatkowo nie ma czegoś takiego jak prywatny bot, a uwierzytelnianie czy też sprawdzanie nadawcy trzeba robić samodzielnie. Przynajmniej tak wyczytałem w necie. Może jestem przewrażliwiony, ale za bardzo to wszystko pachniało mi RCE. No i w końcu stawianie bota, gdy zależy tylko na prostych powiadomieniach, to overkill.

Wczoraj odświeżyłem temat i… okazało się, że wysłanie powiadomienia przez Telegram jest proste. I w sumie nie potrzeba żadnych bibliotek, by wysłać powiadomienie – wystarczy tak naprawdę curl.

Przygotowanie wysyłki powiadomień przez Telegram

Aby wysyłać wiadomości, potrzebne są nam dwie rzeczy: TOKEN oraz CHATID.

  1. Korzystając z bota BotFather w Telegramie stwórz swojego bota[1] (/newbot)
  2. Zapisz otrzymany TOKEN (np. 1234567890:AABBccddeeff-ABCDEFGHIJabcdefghi12)
  3. Znajdź swojego bota, wpis /start
  4. Przejdź na https://api.telegram.org/bot<yourtoken>/getUpdates
    W naszym przypadku na https://api.telegram.org/bot1234567890:AABBccddeeff-ABCDEFGHIJabcdefghi12/getUpdates
  5. Znajdź ciąg „id” dla „from” (np. „id”:723456789). Wartość jest szukanym CHATID.

Wysyłka powiadomień przez Telegram

Najprostszym wariantem wysłania powiadomienia jest wywołanie curl w postaci

curl "https://api.telegram.org/botTOKEN/sendMessage?chat_id=CHATID&parse_mode=Markdown&text=WIADOMOŚĆ"

Czyli na przykład, dla powyższych danych uzyskanych podczas konfiguracji

curl "https://api.telegram.org/bot1234567890:AABBccddeeff-ABCDEFGHIJabcdefghi12/sendMessage?chat_id=723456789&parse_mode=Markdown&text=to jest test śćżń ĄŁĘĆ https://zakr.es/"

Po wydaniu tego polecenia powinniśmy otrzymać na w kliencie Telegram telefonie wiadomość. Dodatkowo z klikalnym linkiem.

Nieco bardziej eleganckie, użyteczne i tylko odrobinę bardziej skomplikowane jest wysyłanie przy pomocy Pythona i biblioteki requests. Zostało ono opisane opisane we wpisie How to create a telegram bot and send messages with Python, który był bezpośrednią inspiracją tego wpisu. Znajdziecie tam również dokładną, ilustrowaną instrukcję konfiguracji bota. A o samych botach Telegram może będzie innym razem.

[1] Owszem, miało być bez bota. Ale się nie da – bot musi być. Nie musi obsługiwać żadnych komend ani wdawać się w interakcje, ale ten twór jest tak naprawdę telegramowym botem.

Opublikowane w

LXDE, laptop, jasność i głośność – HOWTO

Jest taka rzecz w laptopach z Linuksem, która często nie działa zaraz po instalacji. Przynajmniej nie na środowiskach korzystających z Openbox, np. LXDE. Chodzi o sterowanie jasnością ekranu oraz głośnością dźwięku, czyli klawisze multimedialne.

Nie pamiętam, czy coś się ostatnio zmieniło, czy zawsze tak było, tylko miałem skonfigurowane, ale ostatnio konfigurowałem laptopa z LXDE i jak wszystko działało, tak sterowanie głośnością i jasnością ekranu – nie. Wydaje mi się, że kiedyś obsługa tzw. klawiszy multimedialnych była robiona przez ACPI i skrypty (zob. linki na końcu wpisu), ale teraz można prościej.

W obu przypadkach wykorzystywany będzie plik ~/.config/openbox/lxde-rc.xml.

Jasność

Na początek kontrola jasności. W przypadku karty intela, bo taką miałem, kontrola jasności odbywa się z wykorzystaniem programu xbacklight, który musiałem doinstalować. Rozwiązanie powinno działać także dla innych kart. Dodatkowo musiałem utworzyć plik /etc/X11/xorg.conf.d/20-intel.conf o następującej zawartości:

Section "Device"
    Identifier "Intel Graphics"
    Driver "intel"
    Option "Backlight" "intel_backlight"
EndSection

W pliku XML zaś dodałem:

<keybind key="XF86MonBrightnessDown">
  <action name="Execute">
    <command>xbacklight -5</command>
    <startupnotify>
      <enabled>yes</enabled>
      <name>Decrease screen brightness</name>
    </startupnotify>
  </action>
</keybind>
<keybind key="XF86MonBrightnessUp">
  <action name="Execute">
    <command>xbacklight +5</command>
    <startupnotify>
       <enabled>yes</enabled>
       <name>Increase screen brightness</name>
    </startupnotify>
  </action>
</keybind>

Głośność

Trzeba oczywiście mieć zainstalowane programy, które będziemy wykorzystywać – w przypadku instalacji pełnego środowiska LXDE i Debiana 10 wszystko już było zainstalowane. Natomiast w pliku konfiguracyjnym XML wystarczy dodać:

  <keybind key="XF86AudioRaiseVolume">
    <action name="Execute">
      <execute>pactl set-sink-volume 0 +10%</execute>
    </action>
  </keybind>
  <keybind key="XF86AudioLowerVolume">
    <action name="Execute">
      <execute>pactl set-sink-volume 0 -10%</execute>
    </action>
  </keybind>
  <keybind key="XF86AudioMute">
    <action name="Execute">
      <execute>pactl set-sink-mute 0 toggle</execute>
    </action>
  </keybind>

Istnieją warianty wykorzystujące inne polecania pamixer czy amixer (zob. linki).

Oczywiście w ten sposób można zmieniać zachowanie dowolnych skrótów i wykorzystywać dowolne klawisze, nie tylko te wymienione. Pełna lista w źródłach (zob. linki)

Linki:

UPDATE: Skoro już konfigurujemy klawisze multimedialne, warto też pod Print Screen dodać robienie screenshotów. Podobno jest domyślnie, nie potwierdzam, ale może „zasługa” unstable.

    <keybind key="Print">
      <action name="Execute">
        <command>gnome-screenshot -i</command>
      </action>
    </keybind>
Opublikowane w

Aktualizacja Debiana do Buster

Parę dni temu Debian ogłosił wydanie nowego stabilnego wydania o nazwie kodowej Buster. Skoro aktualizacja do Buster stała się możliwa, zacząłem ją natychmiast, ale dopiero teraz mogę nieco o niej napisać.

Przede wszystkim, pospieszyłem się. Szóstego lipca tylko zerknąłem na newsy i… pomyliłem poprzedniego newsa, dotyczącego wydania wersji 9.9 z wydaniem Bustera. Co prawda rzecz działa się już w trakcie wydawania (co widać było na Twitterze), ale zrobiłem lekki falstart.

Lekko zdziwił mnie brak release notes (zasługa falstartu). Ale większość rzeczy mam odseparowanych w kontenerach LXC, więc aktualizacje powinny proste, poza tym, który to już raz? Wziąłem na warsztat przy kawie jedną maszynkę fizyczną i kontenery LXC na niej. Kontenery poszły od kopa w stylu apt-get update && apt-get upgrade && apt-get update && apt-get dist-upgrade. Nie jest to zalecany sposób – w release notes jest napisane, by korzystać z apt. Nie wiedziałem o tym i… nie miało to znaczenia.

Aktualizacja hypervisora również gładka, kontrolny reboot i… kontenery się nie podnoszą. Co prawda apt-listchanges (polecam!) pisał, że LXC 3 got some significant changes from LXC 2, ale pozwoliłem zmienić konfigurację do nowej wersji, stosowane brakujące linie też były dodane. Wyszukiwarka nie pomagała, ludzie na kanale też nie. Z szybkiego upgrade od kawy zrobiła się godzinna walka z debugiem. Okazało się, że czyste, nowe kontenery z Busterem z minimalnym konfigiem także nie startują (error w loglevel INFO, hmm…):

# create
lxc-create -n test3 -t download -- -d debian -r buster -a amd64

# run
lxc-start -n test3 -l debug -o /tmp/debuuug.txt

# logs
tail -n 8 /tmp/debuuug.txt
lxc-start test3 20190706132233.984 NOTICE   start - start.c:start:2037 - Exec'ing "/sbin/init"
lxc-start test3 20190706132233.985 NOTICE   start - start.c:post_start:2048 - Started "/sbin/init" with pid "8584"
lxc-start test3 20190706132233.985 NOTICE   start - start.c:signal_handler:430 - Received 17 from pid 8582 instead of container init 8584
lxc-start test3 20190706132233.985 DEBUG    lxccontainer - lxccontainer.c:wait_on_daemonized_start:830 - First child 8580 exited
lxc-start test3 20190706132233.999 DEBUG    start - start.c:signal_handler:447 - Container init process 8584 exited
lxc-start test3 20190706132233.999 INFO     error - error.c:lxc_error_set_and_log:49 - Child <8584> ended on error (255)
lxc-start test3 20190706132233.999 DEBUG    network - network.c:lxc_delete_network:3180 - Deleted network devices
lxc-start test3 20190706132234.152 INFO     conf - conf.c:run_script_argv:356 - Executing script "/usr/share/lxcfs/lxc.reboot.hook" for container "test3", config section "lxc"

O dziwo kontenery w wersji ze Squeeze startowały. Doraźnie wróciłem w kontenerach do Squeeze (z backupu, nie downgrade) i na pewien czas zostawiłem sprawę. Mimo, że okazało się, że startują dość kulawo. Nie podnosiła się sieć ani nie uruchamiały usługi, trzeba to było robić ręcznie po każdym restarcie kontenera. Niefajne, ale do czasu znalezienia rozwiązania docelowego można wytrzymać, tym bardziej, że restarty są rzadkością.

Ostatecznie właśnie problemy ze startem i porównanie działania LXC na innym, świeżym hypervisorze z Buster, gdzie wszystko działało bez problemu naprowadziły mnie na rozwiązanie. Przy diagnostyce przy pomocy systemctl status otrzymywałem komunikat:

System has not been booted with systemd as init system (PID 1). Can't operate

Rozwiązaniem okazało się przejście na systemd i odinstalowanie pakietów związanych ze starym systemem init (niestety nie zapisałem nazw). IIRC na hypervisorze i w kontenerach. Po tym zabiegu wszystko działa poprawnie i startuje automatycznie, zarówno ze Squeeze w kontenerach, jak i po aktualizacji do Bustera.

Nie zaktualizowałem jeszcze wszystkich maszyn[1], ale z godnych odnotowania zmian – kontener generujący Planetę Joggera dostał aktualzację do Bustera bezpośrednio z Jessie zresztą[2]. Z działaniem na Squeeze był problem, na wersji testowej czy unstable także wtedy nie działało. Na szczęście jest już poprawione, co oznacza, że planeta ma szansę istnieć kolejne parę lat.

Ogólnie póki co aktualizacja całkiem przyjemna i prosta, o ile się ma systemd.

UPDATE: Na ostatnim serwerze napotkałem kolejny problem – skrypty w Pythonie korzystające z virtualenv przestały działać. Rozwiązanie łatwe do znalezienia po wpisaniu komunikatu – trzeba usunąć i utworzyć virtualenv na nowo. Dotyczyło zarówno Pythona 2 jak i Pythona 3.

[1] Został jeden serwer i jakieś desktopy na których akurat nie mam unstable i RPi robiące za router. Trochę boję się go zdalnie aktualizować, bo to zdalny system i nie mam żadnej alternatywnej łączności.

[2] Aktualizacja z przeskokiem wersji nie jest zalecanym sposobem. Jednak skoro to tylko okrojony kontener, który mogę w każdej chwili przywrócić z backupu, to czemu by nie spróbować?