Artikel mit Tag raspberrypi

Raspberry Pi - Raspbian Update auf Buster und Kioskmodus mit Chrome anpassen

Nicht nur ein neuer Raspberry Pi 4 hat vor kurzem das Licht der Welt erblickt, auch die bekannte Distribution Raspbian, welche auf den Minirechnern gerne läuft, wurde auf Debian Buster umgestellt.

Das neue Betriebssystem hat ein neues Theme erhalten und die üblichen Softwareaktualisierungen.
Nicht mehr dabei ist der Legacy Grafiktreiber Stack, dafür wurde auf Mesa V3 Treiber umgeschwenkt.
Ein Update auf die neue Version ist schnell gemacht, aber auch mir Vorsicht zu genießen, es wird eine Neuinstallation empfohlen.

raspberrypi


Update auf Raspbian (Buster)

sudo apt-get update
sudo apt-get upgrade
sudo apt-get dist-upgrade
sudo sed -i 's/stretch/buster/g' /etc/apt/sources.list
sudo apt-get update
sudo apt-get upgrade
sudo apt-get dist-upgrade

Ich empfehle dringend ein Backup der wichtigen Daten zu ziehen.
Nach einem Testupdate konnte ich das System zwar noch booten, hatte außer einem Mauszeiger kein Bild. SSH funktionierte. Ich habe es allerdings nicht weiterverfolgt, da ich die Anzeigeneinstellungen händisch gesetzt hatte.

Da Debian Buster Tools mitbringt, welche nicht unterstützt werden, könnt ihr diese wieder deinstallieren.

sudo apt purge timidity lxmusic gnome-disk-utility deluge-gtk evince wicd wicd-gtk clipit usermode gucharmap gnome-system-tools pavucontrol


Kioskmodus unter Raspbian 

Was nach dem Update schnell klar war. Der Kiosk Modus mit Chromium ist defekt und muss repariert werden. Das geht allerdings schnell, denn es haben sich nur Pfade geändert.

Anders als noch bei den alten Raspbian Systemen ist das Verzeichnis /home/pi/.config/lxsession/LXDE-pi/autostart des Pi Nutzers nicht mehr vorhanden.
Alternativ kann einfach die globale Konfiguration unter /etc/xdg/lxsession/LXDE-pi/autostart angepasst werden, um den Vollbildmodus von Chromium 74 automatisch zu starten.

sudo nano /etc/xdg/lxsession/LXDE-pi/autostart

@lxpanel --profile LXDE-pi
@pcmanfm --desktop --profile LXDE-pi
# Bildschirmschoner deaktivieren
#@xscreensaver -no-splash
@point-rpi

@xset s off
@xset -dpms
@xset s noblank
#Autostart Chromium Vollbild-Kiosk
@chromium-browser --noerrordialogs --incognito --kiosk https://kiosk.itrig.de


 

HowTo - Einen eigenen SuperTuxKart Server im LAN aufsetzen und gegen Freunde zocken

Vor kurzem wurde eine neue SuperTuxKart Version veröffentlicht.

Wie schon aus der Beta bekannt war, bringt diese neue Version neben diversen Verbesserungen eine Netzwerkunterstützung mit.

Daneben sorgen ca. 20 Rennstrecken und verschiedene Spielmodi für Abwechslung. Der Funracer ist natürlich OpenSource und so hat jeder die Möglichkeit seinen eigenen Server zu betreiben.

Alle Infos findet ihr in den Release Notes.

SuperTuxKart1
Genau diese Netzwerkunterstützung will ich im Folgenden näher anschauen, denn für einen eigenen Server reicht bereits ein RaspberryPi aus.


Eigenen SuperTuxKart Server fürs LAN bauen

Als Basis dient ein Ubuntu 16.04 LTS oder ein Raspbian System, der Vorgang ist jeweils gleich.

Zunächst müssen ein paar Pakete installiert werden, damit der Build auch gelingt.

sudo apt-get install build-essential cmake libbluetooth-dev \
libcurl4-openssl-dev libenet-dev libfreetype6-dev libfribidi-dev \
libgl1-mesa-dev libglew-dev libjpeg-dev libogg-dev libopenal-dev libpng-dev \
libssl-dev libvorbis-dev libxrandr-dev libx11-dev nettle-dev pkg-config zlib1g-dev git subversion

Als nächstes werden die Installationsdateien auf das lokale System geladen.

cd /opt
sudo mkdir stk-code
sudo mkdir stk-asset
git clone https://github.com/supertuxkart/stk-code stk-code
svn co https://svn.code.sf.net/p/supertuxkart/code/stk-assets stk-assets

Der letzte Schritt kann etwas Zeit benötigen, da mehrere 100MB geladen werden müssen.

cd stk-code
sudo mkdir cmake_build
cd cmake_build/
sudo cmake .. -DSERVER_ONLY=ON
sudo make -j$(nproc)

Nun heißt es etwas warten, denn je nach CPU Leistung, kann dies etwas dauern...

stk-server

Schwups ist der fertige Server erstellt, ihr könnt ihn nun bereits ausprobieren oder systemweit mit sudo make install installieren.

Danach findet ihr den installierten Server unter /usr/local/bin/supertuxkart.


In unserem Fall starten wir den Server testweise direkt.

cd bin/

./supertuxkart --lan-server=test --network-console

stk-server-start

[info   ] GrandPrixManager: Loading Grand Prix files from ../../data/grandprix/
[info   ] GrandPrixManager: Loading Grand Prix files from /home/xyz/.local/share/supertuxkart/grandprix/
Fri Apr 26 20:25:41 2019 [info   ] STKHost: Host initialized.
Fri Apr 26 20:25:41 2019 [info   ] STKHost: Server port is 2759
Fri Apr 26 20:25:41 2019 [info   ] main: Creating a LAN server 'test'.
Fri Apr 26 20:25:41 2019 [info   ] ServerLobby: Reset server to initial state.
Fri Apr 26 20:25:41 2019 [info   ] ProtocolManager: A 11ServerLobby protocol has been started.
Fri Apr 26 20:25:41 2019 [info   ] STKHost: Listening has been started.

Nun solltet ihr darauf achten, dass der Port 2759 im lokalen Netz erreichbar ist und Firewalls diesen nicht blockieren.

Ebenfalls ist es wichtig lokal einen Servernamen beim Start anzugeben, da der Server sonst nicht startet.

Zusätzlich wird unter /opt/stk-code/.config/supertuxkart/config-0.10/server_config.xml beim ersten Start eine Konfigurationsdatei angelegt, dort können weitere Einstellungen gesetzt werden.

Für unseren Server muss hier Nichts weiter angepasst werden.

Alternativ könnt ihr eure eigene Konfigurationsdatei beim Start auch gleich mitgeben

supertuxkart --server-config=your_config.xml --network-console

Ob der Server läuft lässt sich mit einem einfachen netstat -lnp oder via ss -ln herausfinden (Artikel).

SuperTuxKart auf eigenen Server spielen

Um auf dem eigenen Server gegeneinander zu spielen, müsst ihr euch zunächst das Spiel installieren, dieses findet ihr hier.


Nach dem Start müssen folgende Schritte durchgeführt werden, um auf den eigenen Server zu gelangen,

stk-server-gui

stk-server-lan

stk-server-findstk-server-test-srv

Alternativ kann auch ein Server direkt aus dem Programm heraus erstellt werden und somit quasi mit jedem PC. Ein kleiner RapsberryPi ist allerdings um einiges praktischer.

Sollte ein STK Server übers Internet erreichbar sein, muss zusätzlich ein STK Account angelegt werden. Dieser Account muss beim Serverstart angegeben werden. Weitere Tipps finden sich hier.

supertuxkart --init-user --login=your_registered_name --password=your_password

Viel Spaß

 

LibreELEC Kodi - Tastenbelegung einer Fernbedienung (HDMI CEC) anpassen

Ich möchte die kleine LibreELEC Serie fortsetzen und heute zeigen, wie sich eine Fernbedienung für die Steuerung von Kodi anpassen lässt.

In unserem Szenario wird LibreELEC über den TV verwendet und somit über die normale TV Fernbedienung angesteuert.

Was ist eine Keymap

Jede Kodi Variante hat sogenannte Keymaps auf dem System hinterlegt. Dabei handelt es sich um XML Dateien in denen Tastenbelegungen verschiedener Eingabegeräte hinterlegt sind.

Diese lassen sich auf das eigene Setup anpassen. (In meinem Fall vermisse ich auf den meisten Fernbedienungen beispielsweise den Rechtsklick bzw. das Kontextmenü, welches ich auf einer extra Taste einrichte.)

Übersicht der Keymap Pfade auf den einzelnen Systemen

Android Android/data/org.xbmc.kodi/files/.kodi/userdata/ (see note)
iOS /private/var/mobile/Library/Preferences/Kodi/userdata/
Linux ~/.kodi/userdata/
Mac /Users/<your_user_name>/Library/Application Support/Kodi/userdata/ (see note)
LibreELEC /storage/.kodi/userdata/keymaps/
Windows Start - type %APPDATA%\kodi\userdata - press <Enter>
   

 

 

 

 

 

 

Unter LibreELEC befinden sich die original Keymaps unter /usr/share/kodi/system/keymaps

Weitere Informationen finden sich hier.

Keymap manuell anpassen

Eine angepasste Keymap würde in unserem Szenario unter /storage/.kodi/userdata/keymaps/gen.xml abgelegt werden.

Ein Eintrag für das Kontextmenü kann ungefähr wie folgt aussehen, wobei der Aufbau immer gleich ist:

<keymap>
    <virtualkeyboard>
        <keyboard>
            <key id="221">contextmenu</key>
        </keyboard>
    </virtualkeyboard>
    <global>
        <keyboard>
            <key id="221">contextmenu</key>
        </keyboard>
    </global>
</keymap>

Hier stellt sich recht schnell die Frage wie man auf die IDs kommt. Diese lassen sich beispielweise über das debug.log herausfinden, was aber Aufwand darstellt, daher würde ich beim Anpassen einer Fernbedienung den Weg über den Keymap Editor wählen.

Keymap mit dem Keymap Editor anpassen

Um sich Arbeit zu sparen, für Schritte wie Tastenbelegung erkunden und XML File anlegen wurde bereits ein einfaches Addon programmiert.

Installation Keymap Editor

Der Keymap Editor erlaubt es mit wenigen Schritten eine CEC Fernbedienung nach euren Wünschen zu programmieren. Praktischerweise ist dieser auch im System bereits vorhanden.

kodi-keymap-editor

Sollte unter den Programm-Addons kein Keymap Editor zu finden sein, dann installiert das Addon manuell über den Download Button weiter unten.

kodi-keymap-editor

Nach der Installation lassen sich Tasten einfach anpassen oder zusätzliche Funktionen auf freie Tasten legen.

kodi-keymap-editor

Fazit

Wie ihr seht ist es relativ einfach sich sein eigenes Bedienkonzept zu erstellen. Wobei die Variante über den Keymap Editor sicherlich die schnellste und einfachste dafür darstellt.

Download Keymap edito

 

LibreELEC Kodi - Screenshot via SSH erstellen und System steuern

LibreELEC oder auch OpenELEC dürfte Fans von freien Medienplayern ein Begriff sein. Ich selbst habe LibreELEC im Einsatz und bin recht zufrieden damit.

Da ich LibreELEC direkt am Fernseher betreibe und lediglich über die Fernbedienung steuere, vermisse ich manchmal Funktionen die über die Tastatur kein Problem darstellen. Allerdings führen viele Wege nach Rom. Dieses gilt zum Beispiel für das Erstellen eines Bildschirm Fotos.

Screenshot via SSH erstellen

Normalerweise kann ein Screenshot mit Strg+s über die Tastatur erstellt werden. Ist allerdings keine vorhanden, geht dies auch fix via SSH.

Dazu muss der Dienst natürlich aktiv sein.

kodi-sshSobald SSH aktiv ist, kann auf der Konsole gearbeitet werden. Kodi bringt dazu den Befehl kodi-send mit. Dieser erlaubt es verschiedene Befehle an das System zu senden unter anderem auch den Bildschirm abzufotografieren:

kodi-send --host=127.0.0.1 -a "TakeScreenshot"

Der Host muss auf dem lokalen Prompt nicht zwingend angegeben werden. Ich habe es der Vollständigkeit mit angegeben.

Kodi via SSH steuern

Dieser wird erst relevant, wenn der Befehl über Netzwerk versendet wird, Beispiel:

ssh root@192.168.10.19 'kodi-send --action="PlayerControl(Stop)"'

SSH sollte somit zwingend mit einem neuen Passwort versehen werden, wenn es aktiv ist. Das Default Passwort wäre übrigens "libreelec"

Das Kommando erlaubt weitere Funktionen. Die Hilfe kann mit --help aufgerufen werden.

kodi-send

Weitere Kommandos wären beispielsweise:

Laufende Wiedergabe anhalten

kodi-send --action="PlayerControl(Start)"

System ausschalten

kodi-send --action="Quit"

Plugin installieren (Zuständiges Repository sollte aktiv sein)

kodi-send --action="InstallAddon(plugin.video.kikamediathek)"

Eine Liste aller möglichen Befehle findet ihr hier.

 

Viel Spaß beim Probieren

checkrestart vs. needrestart - alte Prozesse nach Paketupdates erkennen

Wie sich Linux Systeme aktualisieren lassen war auf ITrig bereits zu lesen. Doch nur mit Aktualisieren ist es nicht getan, hin und wieder sollten Prozesse neu gestartet werden deren Installationspakete aktualisiert wurden. Dazu bietet Ubuntu neben dem neuen Kernel Live Patching verschiedene Möglichkeiten.

checkrestart

Um Systeme auf anstehende Neustarts zu kontrollieren gibt es verschiedene Tools, eines altbekanntes ist checkrestart. Dieses ist im debian-goodies Paket enthalten.

Das Programm macht Nichts anderes als nach veralteten Libraries bei noch aktiven Prozessen zu suchen.

Findet es welche schlägt es den Neustart mit dem dazugehörigen Befehl vor.

sudo apt-get install debian-goodies
sudo checkrestart
Found 7 processes using old versions of upgraded files
(7 distinct programs)
(5 distinct packages)

Of these, 5 seem to contain systemd service definitions or init scripts which can be used to restart them.
The following packages seem to have definitions that could be used
to restart their services:
lvm2:
        447     /sbin/lvmetad
openssh-server:
        1160    /usr/sbin/sshd
dbus:
        863     /usr/bin/dbus-daemon
accountsservice:
        945     /usr/lib/accountsservice/accounts-daemon
policykit-1:
        1001    /usr/lib/policykit-1/polkitd

These are the systemd services:
systemctl restart accounts-daemon.service
systemctl restart polkitd.service

These are the initd scripts:
service lvm2-lvmpolld restart
service lvm2 restart
service lvm2-lvmetad restart
service ssh restart
service dbus restart

checkrestart

check-enhancements

Ebenfalls praktischer Teil des debian-goodies Pakets ist check-enhancements.

Damit lassen sich Erweiterungen für bereits installierte Pakete finden.

 

check-enhancements postgresql
postgresql => check-postgres:     Installed: (none)       Candidate: 2.24.0-3.pgdg18.04+1
postgresql => pgpool2:    Installed: (none)       Candidate: 3.7.5-2.pgdg18.04+1
postgresql => pgtop:      Installed: (none)       Candidate: 3.7.0-18-gbbf1f12-2.pgdg18.04+1

needrestart

Das debian-goodies Paket hat schon ein paar Jahre auf dem Buckel, daher gibt es inzwischen neuere Varianten, um anstehende Neustarts zu prüfen. 

Eines davon ist needrestart, es funktioniert ähnlich wie checkrestart, wird aber aktiv weiterentwickelt und unterstützt Docker oder LXC. Zusätzlich ist es nicht an Debian gebunden, sondern auch für andere Distributionen verfügbar.

Needrestart wird von Thomas Liske entwickelt und aktuell in der Version 3.1.x ausgeliefert. Es hat eine Unterstützung für systemd an Bord, läuft aber auch unter System V init.

sudo apt install needrestart
sudo needrestart
Scanning processes...
Scanning processor microcode...
Scanning linux images...

Running kernel seems to be up-to-date.

The processor microcode seems to be up-to-date.

No services need to be restarted.

No containers need to be restarted.

No user sessions are running outdated binaries.

needrestart

Wie es sich für aktuelle Tools gehört, hat das Tool auch eine Nagios/CheckMK bzw. Icinga Ausgabe.

sudo needrestart -p -l
OK - Kernel: 4.15.0-36-generic, Microcode: CURRENT, Services: none, Containers: none, Sessions: none|Kernel=0;0;;0;2 Microcode=0;0;;0;1 Services=0;;0;0 Containers=0;;0;0 Sessions=0;0;;0

Konfiguration und Einstellungen können bei Bedarf unter /etc/needrestart/needrestart.conf vorgenommen werden.

Das Tool bietet ebenfalls einen interaktiven Modus. Nach einer Installation prüft das Tool nach jedem apt upgrade automatisch auf Neustarts von Prozessen und liestet diese auf, ohne sie neu zu starten.

needrestart-kernel


Bordmittel

Die einfachste Variante einen nötigen Neustart des Systems zu erkennen besteht im Auslesen des Wertes cat /var/run/reboot-required .

Den Wert *** System restart required *** zeigt Ubuntu im Loginprompt an, wenn ihr über einen SSH Konsole zugreift.

Werden auch die betroffenen Pakete benötigt kann in /var/run/reboot-required.pkgs geschaut werden

cat /var/run/reboot-required                                                                                                                                                                            *** System restart required ***
cat /var/run/reboot-required.pkgs