PVA: Cluster & Netflix & Streaming zusammen

Ich habe da mal ein Video für euch, aber nicht weiter erzählen 😉

PVA: Cluster & Netflix & Streaming zusammen

Kleine Demo, was man mit PVA so alles machen kann:

Wir haben hier jetzt das Netflixplugin, das Clusterplugin und das Streamingplugin kombiniert.

Die Geräte waren alle in einer Videokonferenz versammelt, damit man das Ergebnis sehen konnte. Die „Küche“ war ein Intel ATOM Tablet, das Wohnzimmer ein alter Laptop. Die Latzenzen bis man etwas sieht, sind jetzt nicht dem Netzwerk geschuldet, sondern dem Umstand, daß wir Livestreaming über FFMPEG machen, wozu FFMPEG erstmal ein paar Sekunden braucht. Es sind aber natürlich andere Wege denkbar: Temporäre Filezugriffe von den Geräten auf einen Share, Netzwerkpipelines usw. da geht noch was 😉

PVA: Clusterplugin für Carola

Netflix Plugin für Carola

Was ich Euch damit aber zeigen möchte ist, daß die Technik da ist. Baut Euch daraus die Wohnungs-KI, die ihr schon immer haben wolltet. KI? War da jetzt KI im Spiel? Nein, natürlich nicht, aber .. da wäre noch was …

KI, or not KI?

JETZT haben Ihr eine KI im Spiel 😀

Ihr merkt, daß ChatGPT hier im Freetalkmodus lief, weshalb alle Anfragen an Carola zu einem „Fehler“ geführt haben. Betreibt man das im Lückenfüllermodus, reagiert es nur auf den PVA Namen. Die Fehler in der Spracherkennung nerven, sind aber im Bereich des vertretbaren. ChatGPT holt da einiges richtig raus.

PVA: Carola trifft auf ChatGPT 4

 

 

Remote Desktop: eigene Desktopsession mit XRDP

Im ersten Teil der Remote-Desktop Serie geht es um XRDP. Damit kann ein entfernter Benutzer eine eigenständige Desktopsession zum Server aufbauen. Andere Benutzer des gleichen Servers können parallel dazu eine eigene Verbindung aufbauen, ohne das sich die Benutzer in die Quere kommen. Allerdings darf ein User nur einmal eingeloggt sein.

Remote Desktop: eigene Desktopsession mit XRDP

Da es sich bei der Lösung um eine eigenständige Desktopumgebung abseits vom Monitor handelt, gibt es hier keine Probleme mit Waylanddesktops. XRDP bietet eine Xorg Verbindung ohne GPU Support an, was die Auswahl der eigentlichen Desktopumgebung einschränkt.

Die Installation

Debian & Ubuntu:

sudo apt-get update && sudo apt-get upgrade && sudo apt install xrdp

Fedora:

sudo dnf install xrdp-selinux xrdp

Die Desktopumgebung

Jetzt müssen wir uns für eine Desktopumgebung entscheiden, weil es bei RDP leider keine Vorauswahl seitens des Clienten gibt. Es bieten sich GPU unabhängige Desktops wie GNOME oder XFCE4 an. Zum Glück ist das total einfach:

echo „gnome“ > ~/.xsession

oder

echo „xfce4-session“ > ~/.xsession

Dies muß jeder Benutzer selbst machen oder durch den Superuseraccount regel lassen. Was nicht funktioniert ist Cinnamon, soweit ich das bisher erlebt habe.

Die Firewall öffnen

Da sich die eingesetzten Firewalls pro Distribution stark unterscheiden, hier einige Vorschläge:

Debian & Ubuntu: sudo ufw allow 3389/tcp
Fedora: sudo firewall-cmd –permanent –add-port=3389/tcp
IP-Tables: sudo iptables -A INPUT -j ACCEPT -m tcp -p tcp –dport 3389

Von Fedora abgesehen, müßtet Ihr die Regeln permanent hinzufügen z.B. also in /etc/sysconfig/iptables eintragen.

XRDP Starten

In einer Idealen Welt, würde man nun „systemctl enable –now xrdp“ ausführen und es geht. Da leben wir aber nicht 🙂

In /etc/xrdp/sesman.ini müßtet Ihr sicherstellen, daß folgendes so drinsteht:

[Xorg]
; Specify the path of non-suid Xorg executable. It might differ depending
; on your distribution and version. Find out the appropriate path for your
; environment. The typical path is known as follows:
;
; Fedora 26 or later : param=/usr/libexec/Xorg
; Debian 9 or later : param=/usr/lib/xorg/Xorg
; Ubuntu 16.04 or later : param=/usr/lib/xorg/Xorg
; Arch Linux : param=/usr/lib/Xorg
; CentOS 7 : param=/usr/bin/Xorg or param=Xorg
; CentOS 8 : param=/usr/libexec/Xorg
; FreeBSD (from 2022Q4) : param=/usr/local/libexec/Xorg
;
param=/usr/libexec/Xorg
; Leave the rest parameters as-is unless you understand what will happen.
param=-config
param=xrdp/xorg.conf
param=-noreset
param=-nolisten
param=tcp
param=-logfile
param=.xorgxrdp.%s.log

[Xvnc]
param=Xvnc
param=-bs
param=-nolisten
param=tcp
param=-localhost
param=-dpi
param=96

Damit erklärt sich auch, wieso es kein Waylandproblem mit XRDP gibt, es wird ja nicht benutzt 😉

Jetzt können wir das starten: systemctl enable –now xrdp

Mein Tip

… Ja, ich bin alt, ich schreibe Tip noch einem p :þ… können wir dann? Mein Tip für Euch: enabled es nicht per se.

Ihr könnt den Server auf 127.0.0.1 binden lassen, dann kommt Ihr nur per SSH-Tunnel oder lokal drauf. Letzteres wäre für ein „REMOTE“ Desktoptool ja eigentlich völlig unsinnig, aber es gibt Spezialfälle:

Wenn man z.B. Desktopprogramme für Spezialuser, wie einen spezialisierten Online-Bankingaccount, benutzen möchte, dann kann man sich per RDP einfach einloggen ohne den Benutzer wechseln zu müssen. Das kann z.b. auch nützlich sein, wenn man eine kleine Linux Internetshow betreibt und mit einem Nicht-Admin-User mal was zeigen will oder auch, um als Root mit einem Desktoptool etwas zu machen. Möglichkeiten dies zu verwenden gibt es viele.

Im Normalfall sollte man sich von außen auch nicht direkt per RDP einloggen können, sondern immer über einen sicheren SSH Tunnel gehen, denn RDP authentifiziert gegen PAM und das benutzt im Vergleich zu OpenSSH-Schlüsseln, schwache Passwörter als Schutz. Da ist ein OpenSSH-Schlüssel jederzeit vorzuziehen.

Vermeiden lässt sich eine direkte Erreichbarkeit nicht, wenn man im Netz einen Server betreibt, der für Benutzer per RDP erreichbar sein muß. XRDP kann hier insofern für etwas Sicherheit sorgen, wenn Rootzugriffe verboten sind. Aber auch im Netz kann ich allen Beteiligten nur dazu raten, z.b. auf VPNs zu setzen oder einen SSH-Tunnel zu nutzen. Bei den ganzen Kriminellen da draußen, muß man wirklich jede Schutzschicht aktivieren, die geht.

Blog-Stats seit Einführung des Trafficcache

Ich hatte ja letztes Jahr einen Apache Trafficserver vor das Blog geschaltet, damit die Aufrufzeit des Blogs besser wird. Das hat auch funktioniert, führte aber in den Statstools der Webseite, dazu, daß weniger angezeigt wird, weil weniger im WordPress ankommt.

Blog-Stats seit Einführung des Trafficcache

Schauen wir doch mal rein, was im März 2023 wirklich gewesen ist… 😀

Die Liste mit den TOP 30 URLS habe ich um Seiten wie Javascript, CSS, FEEDS usw. bereinigt. Da die bei allen Seiten beteiligt sind, ist klar, daß die mehr Aufrüfe als die echten Seiten haben. Daher die komischen Positionen in der TOP-Liste 😉 An Platz ein war die XMLRPC, weil die Hacker die mit Forenspam bombardieren 😀

Der Anfang des Jahres ist seit Bestehen des Blogs eher schwach besetzt, was ein Blick in die letzten 6 Monate bestätigt:

Die Zahlen für April sind logischerweise noch nicht relevant.

Falls Ihr auch ein Cache haben wollt

Gibt es da mehrere Möglichkeiten: Ihr geht zu CloudFlare, zu meiner Firma, oder setzt Euch das Cache selbst auf. Letzteres ist eine tolle Kompetenzübung in Sachen Web, weil Ihr alle den Spaß erfahren werdet, den ich auch hatte 🙂 Da Ihr den ganzen Loggingkram dann selbst bauen müßt, könnte das den einen oder anderen überfordern. Ist echt nicht für jeden was. Zum Auswerten habe ich Webalizer nutzen müssen, weil alle anderen noch komplizierter Anzubinden waren oder gar nicht erst funktioniert hätten.

Den Apache Trafficserver könnt Ihr aus dem Fedora Repo bekommen, oder bei apache.org .