Kategorie: Linux

HomeOffice – mit OBS und Chroma Key

Aktuell (Corona-Schule, Schulschließung, Osterferien,…) sitze ich viel zu Hause und nehme an Webinaren oder Videokonferenzen teil. Außerdem muss auch der Fernunterricht vorbereitet werden.

Aber noch ein Arbeitsplatz mit „Wohnzimmer-Flair“ wollte ich nicht erschaffen.

Version 1 – Der Arbeitsplatz mit Webcam.

So will aber keiner vor seine Schüler treten. Natürlich gibt es Konferenztools wie zum Beispiel Zoom.us die den Hintergrund „verwischen“ können. Aber mein Lieblingstool JitsiMeets kann das nicht (nur als Beta). Und das in unser Moodle angeflanschte BigBlueButton welches ich für mein Unterricht benutze auch nicht.

Version 2 – Der geschönte Arbeitsplatz

Mit etwas Tuch und Stangen, wird eine kleine blaue Kammer draus.

Blau, da war doch was mit Chroma Key. Wenn der Hintergrund in einer Farbe ist, kann der Rechner/ die Software diese Farbe „weg nehmen“, auf transparent stellen. Dann kann man seine Hintergrund mit einem anderen ersetzen. So wie es die großen und kleinen Fernsehstudios oder Youtuber machen.

Dass der Kreis auf dem Bild ist liegt an der WebCam die hat einen Defekt und „Corona sei Dank“ sind die WebCams in den Online-Läden entweder sehr teure oder ausverkauft.

Was muss gemacht werden? Zwischen das Bild der Webcam muss eine Software, die den Hintergrund wegrechnet und austauscht und dann das neue Bild an das Konferenztool weiter reicht. Die Suche ergab, dass OBS-Studio das kann.

Für die Windowsnutzer gibt es dazu ein fertiges VirtualCam-Plugin für mich als Linux-Anwender hieß das einfach mal weitersuchen. Bei https://srcco.de/ wurde ich fündig. Der Artikel „USING OBS STUDIO WITH V4L2 FOR GOOGLE MEET“ beschreibt diesen Ansatz für google-meet aber es geht auch Jitsimeets und BigBlueButton.

Installation von OBS Studio

Da OBS Studio eine „kostenlose Open-Source-Software für Videoaufnahmen und Live-Streaming“ ist und es für Ubuntu ein ppa gibt, folge ich diese Anleitung. (Vorsicht, Zusätzliche Fremdquellen können das System gefährden!)
Originalquelle: https://obsproject.com/wiki/install-instructions#linux

Als Voraussetzung wird ffmpeg benötigt.

sudo apt install ffmpeg

Dann folgt die Installation von OBS-Studio über das ppa.

sudo add-apt-repository ppa:obsproject/obs-studio
sudo apt update
sudo apt install obs-studio

Für die virtuelle Kamera wird der V4L2 loopback driver benötigt, der auch mittels

sudo apt install v4l2loopback-dkms

geholt wird.
Jetzt muss die virtuelle Kamera angelegt werden.

sudo modprobe v4l2loopback devices=1 video_nr=10 card_label="OBS Cam" exclusive_caps=1 

Dieser Befehl legt ein Device namens /dev/video10 an, auf das man später mittels OBS-Tools zugreifen kann.
Da es kein fertiges OBS-Plugin gibt muss es selbst kompiliert werden.

sudo apt install qtbase5-dev 
git clone --recursive https://github.com/obsproject/obs-studio.git 
git clone https://github.com/CatxFish/obs-v4l2sink.git
cd obs-v4l2sink 
mkdir build && cd build

Und nun noch diese Zeile – das sollte alles zusammen hinter dem ‚cmake‘ stehen

cmake -DLIBOBS_INCLUDE_DIR="../../obs-studio/libobs" 
-DCMAKE_INSTALL_PREFIX=/usr .. make -j4 sudo make install


Ich musste noch den CMAKE nachinstallieren.
Bei Debian 10 musste ein Lehrer-Kollege noch eine Bibliothek nachinstallieren

apt install libobs-dev


Nach dem Starten von OBS kann man unter Tools / Werkzeuge die V4l2 Videoausgabe konfigurieren.
Hier wählt man als V4l2-Gerät das oben erstellte /dev/video10 und startet das Gerät.

  • Bei Quellen die Webcam aus suchen.
  • Dann einen Filter auf diese Quelle gesetzt und die Chroma Key Einstellungen so gewählt, dass es halbwegs gut aussieht.
  • Eine weiter Quelle mit dem Hintergrundbild anlegen. (Als Hintergrund-Bild habe ich mich hier für ein bisschen Karibik [von Pixabay] entschieden.

Version 3 – mein schöner Arbeitsplatz

Das Ergebnis lässt einen die nächste Konferenz leichter ertragen.

pi3 – Installations Guide: Teil 2 – absichern

Voraussetzung

Im gestrigen Beitrag  pi3 – Installations Guide: Teil 1 wurde der RPi vorbereitet bis zum ersten ssh-Login, jetzt geht es weiter.

Man sollte denken, dass nun als erstes das System aktualisiert wird, aber dem ist nicht so. Der Standard-Benutzer Pi mit dem Passwort raspberry ist zu bekannt, und das ssh-Login haben wir erlaubt. Darum muss das als erstes geändert werden. Nachdem ich viele Seiten zum Absichern des Servers gelesen habe komme ich zu diesem Vorgehen.

  • neuer USER1 anlegen, dieser bekommt sudo Rechte
  • noch einen USER2 anlegen, (nur) dem wird der ssh-Login ermöglicht.
  • der user Pi wird gelöscht.

Neuer USER1 anlegen

Auf Linux-Systemen gibt es adduser und useradd als Programm/Befehl um einen User anzulegen. Dabei ist useradd ein sehr einfacher Befehl, der seinen Job macht aber nicht komfortable. Komfortabler ist adduser. Dennoch haben beide ihre Berechtigung.

Mit sudo useradd USER1 -G sudo legt man einen Benutzer USER1 an, der der Gruppe sudo zugeordnet ist, das ist wichtig, da wenn Pi gelöscht ist sonst niemand mehr root-Rechte haben könnte. Unser USER1 hat noch kein Passwort, das wird nun festgelegt.

sudo passwd USER1 fordert uns auf für den USER1 ein Passwort zu setzen.

USER2 anlegen

Diesen User legen wir mir adduser an. sudo adduser USER2 und sehen auch gleich, was sich unterscheidet. Der Befehl adduser verlangt Infos zum Benutzer und ein Passwort.

ssh-Login absichern

Damit ein ssh-Zugang klappt, muss auf dem Server, hier der RPi ein ssh-Dienst laufen, den kann man konfigurieren. Unter Linux-Systemen findet man die Konfigurationsdateien im Verzeichnis /etc und nur root kann sie bearbeiten. Zum Bearbeiten benutzen wir den Editor nano.

Ein sudo nano /etc/ssh/sshd_config öffnet die Konfig-Datei in der folgende Anpassungen gemacht werden sollten.

  • #PermitRootLogin prohibit-password – daraus machen wir ein PermitRootLogin no # root darf sich nicht einloggen
  • LoginGraceTime 2m wird zu
    LoginGraceTime 30 # das Login muss innerhalb von 30 Sekunden
  • AllowUsers USER2 # Vorsicht! jetzt kann sich nur noch USER2 anmelden.

Jetzt muss das System neu gestartet werden

sudo shutdown now -r.

Ein Login ist nur noch mit USER2 möglich also ssh USER2@IP und das Passwort.

Ich habe meinen kleinen auch mal am Internet und bin deshalb noch vorsichtiger. USER2 ist der einzige der von außen auf das System darf/kann! Mein USER2 bekommt nun noch in .bashrc den Eintrag kein große History anzulegen

nano .bashrc, hier kommt der Eintrag HISTSIZE=0 hinzu,

Außerdem soll beim logout die history gelöscht werde, damit keine Zeugnisse auf dem System beleiben.

nano .bash_logout
Diese Datei bekommt die Inhalte:

history -c
rm ~/.bash_history

User Pi löschen

Noch gibt es den Bentzer Pi, der wird nun gelöscht, dazu müssen wir ein sudo-Berechtigter USER werden.

su USER1 und jetzt Pi entferen

sudo systemctl stop autologin@tty1

sudo deluser -remove-home pi

Und in der Konfig-Datei des graphischen Login
sudo nano /etc/lightdm/lightdm.conf

wird aus autologin-user=pi ein #autologin-user=pi.

Das Kommentarzeichen # sorgt dafür, dass diese Zeile nicht bearbeitet wird.