Skip to content

Raspberry Pi 4 Kiosk - Bildschirmschoner unter Raspberry Pi OS deaktivieren

Der Raspberry Pi ist schon längere Zeit in Version 4 verfügbar, Raspbian heißt nun Raspberry Pi OS und der dazugehörige Imager hat mehr Optionen erhalten (Strg + Shift +X).

Dies sind allerdings nicht die einzigen Neuerungen. Denn eine oft gestellte Frage hat nun ebenfalls eine andere Antwort.

Wie deaktiviere ich den Bildschirmschoner unter Raspberry Pi OS

Um den Bildschirmschoner zu deaktivieren, konnten bisher in einigen Dateien Hand angelegt werden.

So mussten in der Vergangenheit diverse Werte im Autostart eingetragen werden:

/home/pi/.config/lxsession/LXDE-pi/autostart

Beziehungsweise unter:

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

Details dazu findet ihr in einem alten Artikel.

Mit der neuen OS Version, welche auf Debian Buster basiert, ist dies nicht mehr nötig.

Der Hersteller hat diese Option nun direkt im Konfigurationstool versteckt. 

sudo raspi-config

[Menu] --> [Preferences] --> [Screen Blanking]

raspberrypi4-screensaveDie alten Methoden funktionieren nicht mehr.

Ein weiterer Workaround wäre die Installation eines extra Screensavers ( sudo apt-get install xscreensaver ), welcher dann deaktiviert wird. Dieser Schritt sollte im Normalfall allerdings nicht nötig sein.

 

NGINX - Webserver, Load Balancer und Proxy

NGINX ist neben Apache einer der bekanntesten Webserver. Allerdings kann das Tool mehr als nur ein schlichter Webserver sein. Reverse Proxy, Load Balancer, Mail Proxy oder HTTP cache Server sind ein paar wenige Funktionen die Nginx beherrscht.

Ich möchte euch heute ein paar Beispiele zu einzelnen Funktionen zeigen. Den Anfang macht logischerweise die Installation. Als System verwende ich einen Ubuntu 20.04 LTS Server.

 

Nginx

 

Installation Nginx unter Ubuntu/Debian

Die Installation der frei verfügbaren Version (Die kommerzielle Variante nennt sich Nginx Plus) erfolgt über das Nginx Repository.

sudo wget https://nginx.org/keys/nginx_signing.key

sudo apt-key add nginx_signing.key

sudo nano /etc/apt/sources.list.d/nginx.list

  deb https://nginx.org/packages/mainline/ubuntu/ focal nginx
  deb-src https://nginx.org/packages/mainline/ubuntu/ focal nginx
              
sudo apt install nginx

sudo systemctl is-enabled nginx.service

sudo systemctl enable nginx

Nach der Installation erfolgt eine schnelle Kontrolle.

ss -ltn
ubuntu:~$ curl -I http://127.0.0.2

HTTP/1.1 200 OK
Server: nginx/1.19.6
Date: Thu, 17 Dec 2020 22:20:49 GMT
Content-Type: text/html
Content-Length: 612

Nginx selbst kompilieren

Es besteht auch die Möglichkeit, das Nginx Paket selbst zu kompilieren. Dies wird dann nötig, wenn Pakete benötigt werden, die in der Standardvariante nicht enthalten sind. Die war zum Beispiel bei der Verwendung von GeoIP oder LibreSSL mal bzw. ist noch so.

Mit dem folgenden Befehl können die installierten Module eingesehen werden.

Nginx –V

In der Standardinstallation sollte hier das Modul --add-dynamic-module=/build/nginx-5J5hor/nginx-1.18.0/debian/modules/http-geoip2 angezeigt werden. D.h. das eingangs erwähnte Geo IP Modul wird hier bereits geladen.

Einen eigenen Nginx Server unter Debian/Ubuntu einrichten

Nach einer erfolgreichen Installation zeigt Nginx eine Standardseite an. Diese kann gelöscht oder zusätzlich eine eigene virtuelle Seite angelegt werden. Auf einer IP können so mehrere Webseiten gehostet werden.

Folgende Struktur bietet sich unter Ubuntu an:

Konfiguration der einzelnen virtuellen Server.

/etc/nginx/sites-available/xyz

Momentan aktive Server wobei es sich hier um einen Symlink handelt.

/etc/nginx/sites-enabled/xyz

Schritt für Schritt heißt dies für einen Server welche auf Port 80 lauscht:

#config anlegen
touch /etc/nginx/sites-available/itrig

#config schreiben
nano /etc/nginx/sites-available/itrig

server {

        listen 80 default_server;    

        # Make site accessible from http://localhost/

        server_name localhost;
        location / {
            root /usr/share/nginx/html;
            index index.html index.htm;
        }
}

#aktiv setzen
ln -s /etc/nginx/sites-available/itrig /etc/nginx/sites-enabled/itrig

Konfiguration überprüfen

nginx –t

Neustart der Konfiguration mit

#lädt nur die neue Konfiguration
nginx –s reload

oder

sudo systemctl reload nginx


Nginx als Loadbalancer verwenden

Neben der reinen Webserverfunktion bietet NGINX die Möglichkeit den Server, als Loadbalancer zu betreiben. Da heißt der Server sorgt für Ausfallsicherheit bzw. Leistung von Webanwendungen, in dem er die Last verteilt. Vorstellen kann man sich dies wie einen Haupthändler, welcher Daten unter verteilt.

LoadbalancerNginx bietet mehrere Varianten an, wie diese Verteilung geschehen kann.

Round Robin

Das bekannteste dürfte das Round Robin Verfahren sein. Es wird eine Liste von Servern durchgearbeitet und die Last nach und nach verteilt. Ist die Liste zu Ende, fängt der Server wieder am Anfang an.

Im unteren Beispiel werden 3 Server in der Gruppe "itrigloadbalancer" zusammengefasst und der Webserver geht diese Liste nach und nach durch. Unterstützt werden die Protokolle HTTP, HTTPS, FastCGI, uwsgi, SCGI, memcached, und gRPC.

http {
    upstream itrigloadbalancer {
        server srv1.example.com;
        server srv2.example.com;
        server srv3.example.com;
    }

    server {
        listen 80;

        location / {
            proxy_pass http://itrig.de;
        }
    }
}

Least Connected

Eine weitere Lastverteilung ist das Least-Connected-Verfahren. Hier wird auf die aktiven Verbindungen der einzelnen Server geschaut. Der Server, welcher die geringste Anzahl an aktiven Verbindungen hat, bekommt die Anfrage zugeschanzt.

upstream intrigleastload {
        least_conn;
        server srv1.example.com;
        server srv2.example.com;
        server srv3.example.com;
    }

Session-Persistenz - IP Hash

Die dritte Möglichkeit Last zu verteilen, stellt das IP-Hash-Verfahren dar. Hier werden von den zugreifenden Client IPs Hash Werte erstellt. Anhand dieser Werte wird einem Client immer ein bestimmter Server zugewiesen. Damit erhält der Nutzer eine Session Persistenz, da Anfragen immer vom gleichen Server beantwortet werden.

Beim Round-Robin- oder Least-Connected-Load-Balancing kann jede nachfolgende Anfrage eines Clients potenziell auf einem anderen Servern ankommen.

upstream itrighash {
    ip_hash;
    server srv1.example.com;
    server srv2.example.com;
    server srv3.example.com;
}

Weighted load balancing

Alle Varianten lassen sich zusätzlich gewichten. So kann es vorkommen, dass ein Server eine bessere Hardware verbaut hat, als ein anderer. Mit Weighted load balancing lässt sich einzelnen Geräten mehr Last zuschieben.

upstream itrigmitgewicht {
        server srv1.example.com;
        server srv2.example.com weight=3;
        server srv3.example.com;
    }
upstream itrig {
    ip_hash;
    server srv1.example.com weight=2;
    server srv2.example.com;
    server srv3.example.com;
}

Mehr zu der Thematik unter load_balancing.


Nginx als Reverse Proxy verwenden

Den aufmerksamen Lesern dürfte aufgefallen sein, dass in einem Code Beispiel weiter oben eine Zeile mit "proxy_pass" vorhanden ist. Diese Zeile deutet darauf hin, dass NGINX als Reverse Proxy eingesetzt wird und ein Aufruf nicht direkt auf dem Server landet, sondern weitergeleitet wird.

location /webshop {
proxy_pass http://opencart.itrig.local;
}

location /landkarte {
proxy_pass http://192.168.100.99;
}

Es gibt verschiedene "Vorteile" für so eine Weiterleitung.

So kann der Nginx als HTTPS Endpunkt dienen und die Struktur dahinter kann unverschlüsselt agieren. Auch bietet NGINX die Möglichkeit als Reverse Proxy und als Load Balancer gleichzeitig zu arbeiten, die Details sind weiter oben zu lesen.

Weiter erlaubt der vorgeschaltete Server eine Caching Funktion, was zum schnelleren Ausliefern von Webseiten beitragen kann.

Hier ein Beispiel mit gesplittetem Cache aus der offiziellen NGINX Cache Dokumentation.

proxy_cache_path /path/to/hdd1 levels=1:2 keys_zone=my_cache_hdd1:10m
                 max_size=10g inactive=60m use_temp_path=off;
proxy_cache_path /path/to/hdd2 levels=1:2 keys_zone=my_cache_hdd2:10m
                 max_size=10g inactive=60m use_temp_path=off;

split_clients $request_uri $my_cache {
              50%          “my_cache_hdd1”;
              50%          “my_cache_hdd2”;
}

server {
    # ...
    location / {
        proxy_cache $my_cache;
        proxy_pass http://my_upstream;
    }
}

Das Thema Sicherheit spielt ebenso eine Rolle, da durch den vorgeschalteten Server, die Angriffsfläche kleiner gehalten wird.


NGINX mit Regex

Richtig interessant wird es, sobald die aufgerufene URL verschiedene Eigenschaften besitzt bzw. ein besonderes Verhalten zeigen sollte.

Diese Eigenschaften werden mit regulären Ausdrücken umgesetzt.

Hier sind ein paar Beispiele von regulären Ausdrücken für NGINX :

# Die URL ist durch * case insensitive
 location ~* /itrig/ {
    #...
    #...
    }

# Die URL ist case sensitive das ^ sorgt dafür das nur z.B. /itrig/logo.jpg gültig ist und nach dem ersten Match gestoppt wird.
 location ^~ /itrig/ {
    #...
    #...
    }

# Bilder anhand der Endung umleiten
 location ~ \.(gif|jpg|png)$ {
    root /data/images;
    }

# Unnötige Endungen aussperren (case insensitive)
 location ~* "\.(old|orig|original|php#|php~|php_bak|save|swo|aspx?|tpl|sh|bash|bak?|cfg|cgi|dll|exe|git|hg|ini|jsp|log|mdb|out|sql|svn|swp|tar|rdf)$" {
    deny all;
    }

# Einen Alias setzen
 location /_/static {
        alias /path/to/glory;
    }

# Rewrite einer URL,  "pfad" wird entfernt
    location /pfad {
        rewrite ^/pfad(.*)$ $1 break;
        proxy_pass http://splunk-api:8080;
    }

Es bietet sich immer an, eigene Befehle zu testen, bevor sie produktiv eingesetzt werden, denn neben Einschränkungen auf URLs kann ebenso Haus und Hof geöffnet werden.

Ein Regex Test sollte daher immer gemacht werden. Hier findet sich so ein Tool online regex.datahoarder.dev.

Das Tool kann jederzeit auf der eigenen Umgebung gehostet werden und ist auf Github zu finden.

Nginx_Regular_Expression_Tester

 

BlackArch Linux 2020.12.01 und Kali Linux 2020.4

BlackArch Linux 2020.12.01

Das auf Arch Linux basierende Sicherheitswerkzeug enthält nun den Linux-Kernel 5.9.11, aktualisierte Pakete, Konfigurationsdateien und Werkzeuge. Außerdem wurden mehr als 100 neue Hacking-Tools hinzugefügt, sodass sich die Gesamtzahl der Tools in BlackArch auf  über 2000 beläuft.

 

blackarch

Weitere Information beinhaltet der Changelog

  • added more than 100 new tools
  • renamed 'live iso' to 'full iso'
  • updated blackarch-installer to v1.2.16
  • included linux kernel 5.9.11
  • adapted ISO creation to the new archiso version (work in progress)
  • removed unnecessary files from the ISO env
  • QA'ed and fixed a lot of packages (runtime exec, missing dependencies...)
  • updated all vim plugins and improved vim config options
  • updated all blackarch tools and packages including config files
  • updated all system packages
  • updated all window manager menus (awesome, fluxbox, openbox)

BlackArch


Kali Linux 2020.4

Der Platzhirsch hat ebenfalls geliefert und bringt die ZSH Shell für alle, die das Schweizer Messer frisch installieren. Das BASH Terminal hat in diesem Zuge auch ein Makerover erhalten und sieht nun etwas mehr nach ZSH aus.

Kali_Linux

Wer mit ZSH so gar nicht auf einen grünen Zweig kommt, es gibt einen Weg zurück zu BASH:

chsh -s /bin/bash

Zusätzlich hat die Kommandozeile einen neuen Infobereich erhalten, welcher sich je nach Installationsart anders präsentiert.

 

Win-KeX 2.5, der Windows Modus für WSL2 bringt den neuen “Enhanced Session Mode”, was Win-KeX auf Windows on ARM Geräten ermöglicht.

Dieses Feature wird in Zukunft relevanter werden, da Microsoft nun mit Surface X auch ARM Geräte im Portfolio hat. Solange aber WSL2 nicht richtig zusammen mit VirtualBox und Co funktioniert, ist dies weiterhin experimentell. (Siehe ITrig Artikel)

Die Kali-Dokumentation wurde schon vor einiger Zeit von WordPress zu Hugo migriert und ist unter kali.org/docs zu finden. Das Design wurde hier weiter angepasst.

Bei den Tools haben sich ebenfalls einige Neuzugänge eingeschlichen: Apple bleee, CertGraph, dnscat2, FinalRecon, goDoH, hostapd-mana, Metasploit Framework v6 und Whatmask

Weitere Änderungen können dem Changelog entnommen werden.

Download Kali



Übersicht 12/2020

 

Name Version Tools Besonderes Basis GUI
Autopsy 4.17.0 ??? The Sleuth Kit Windows  
BackBox 7.0 100+ AWS Ubuntu Xfce
BlackArch 2020.12.01 1750+ ArchLinux ArchLinux Multi
CAINE 11 100+ WinUFO Ubuntu Mate
DracOS 3.0   veraltet LFS DWM
DEFT Zero 2018.2   offline Lubuntu 14.04 Lxde
Kali Linux 2020.04 300+ ARM Images Debian Testing Multi
Kali AppStore   40+   Android  
LionSec 5.0   veraltet Ubuntu  
Matriux v3 RC1   offline Debian Gnome
NST 32 ??? Server integriert Fedora 32  
NetSecL OS 6.0   veraltet OpenSuse Lxde
Paladin 7.0     Ubuntu  
Parrot OS 4.10 700+ Cloud fähig Debian Buster MATE/KDE
Pentoo 2018.0 RC7.1   veraltet Gentoo Xfce
Ronin     veraltet Lubuntu Lxde
Sans SIFT 3.0   veraltet Ubuntu  

Sailfish OS Kontakte exportieren und auf Android oder iOS importieren

Der Vorgang klingt abstrus, denn wer will schon von Sailfish OS auf Android wechseln, dennoch wurde mir genau diese Frage neulich gestellt.

Sailfish OS Kontakte exportieren

Wie lassen sich Sailfish OS Kontakte zum Beispiel von einem Jolla oder Sony auf Android exportieren?

Die Sailfish Kontakte App bietet keinen direkten Export an, dennoch ich es möglich ein Full Backup des Gerätes zu erstellen und genau damit befinden wir uns schon auf dem richtigen Weg.

Das neueste Sailfish OS (Pallas-Yllästunturi) erlaubt sogar das Erstellen eines vollen Backups direkt in eine Nextcloud, Dropbox oder ownCloud. Die so erstellte TAR Datei muss nur noch entpackt werden. Unter ".\People\data\all.vcf" ist eine VCF Datei mit allen euren Kontakten zu finden, die dann in Android oder iOS importiert werden können.

  1. Datensicherung in Sailfish OS direkt zu Nextcloud erstellen
  2. sailfish_backup_2020-10-28T20-33-00Z.tar entpacken
  3. all.vcf suchen .\People\data\all.vcf
  4. Datei in Android oder iOS importieren

sailfishos-backup

Läuft nicht ganz rund – WSL2 mit Windows 10 2004 und VirtualBox

In der Vergangenheit hatte ich bereits über WSL2 berichtet und die neuen Funktionen, die damit einhergehen. Leider kommt es nach der Aktivierung von WSL2 unter Windows 10 2004 zu Problemen mit VirtualBox.

Microsoft sind Probleme bekannt und listet dies auch auf der betreffenden FAQ Seite auf.

Ich hatte beispielsweise in der Vergangenheit mit aktivem WSL2 Probleme meine vorhandene Linux Server Systeme zu starten, bereits beim Bootvorgang kam es zu Kernel Fehlern, welche das System ausbremsten.

Da waren Fehler wie VERR_NEM_VM_CREATE_FAILED oder VERR_NEM_MISSING_KERNEL_API_2

WSL1 kannte diese Probleme noch nicht, da es Hyper-V (Windows Hypervisor Plattform) nicht verwendete, WSL2 tut aber genau dies, was wiederum zu dubiosen Fehlermeldungen in Verbindung mit VirtualBox führt.

Schlimmer wurde es mit Ubuntu Desktop 20.04 unter VirtualBox, hier war es nicht mehr möglich ein apt update auszuführen, ohne Hash Fehler (Hash sum mismatch) zu erhalten.

Hash_sum_mismatch

WSL2 und VirtualBox entweder oder - Die Lösung

Zunächst solltet ihr für eine aktuelle Umgebung sorgen

  • Aktualisiert VirtualBox, die neueste September Version 6.1.14 hat eines der hier beschriebenen Probleme gelöst. Changelog-6.1#v14
  • Deaktiviert das  Feature Windows Feature "Plattform für virtuelle Computer", damit greift VirtualBox auf seine eigene Engine zurück

PlattformfuervirtuelleComputer

Nach einem Neustart sollten alle Probleme in VirtualBox in Verbindung mit Linux Installation und Fehlern wie "Hash sum mismatch" oder "failed to fetch store" der Vergangenheit angehören. Negativer Effekt, WSL2 funktioniert nun nicht mehr.

Zum besseren Verständnis eine Übersicht der einzelnen Funktionen

  • Hyper-V ist der Hypervisor von Microsoft.
  • Plattform für virtuelle Computer - Ermöglicht Unterstützung für virtuelle Maschinen und ist für WSL2 erforderlich.
  • Windows-Hypervisor-Plattform - Ermöglicht die Ausführung von Virtualisierungssoftware auf dem Windows-Hypervisor. Die Hypervisor-Plattform ist eine API, die Drittanbieter-Entwickler für die Verwendung von Hyper-V verwenden können, beispielsweise Oracle VirtualBox oder Docker.

 

WSL und VirtualBox zusammen verwenden

Wie bereits oben erwähnt ist momentan ein Zusammenspiel von VirtualBox und WSL2 nicht ohne Probleme möglich.

Wer dennoch beide System verwenden möchte, der hat momentan nur die möglich auf WSL1 downzugraden.

WSL-Ubuntu_18.04_LTS_downgrade

dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart

wsl --list –verbose

wsl --set-version kali-linux 1

dism.exe /online /disable-feature /featurename:VirtualMachinePlatform /norestart

 

WSL selbst sollte natürlich weiterhin in den Windows Einstellungen aktiv sein.

WindowsSubsystemfuerLinux