pixel
Seite wählen

NETWAYS Blog

Jitsi Meetings mit Jibri aufzeichen

Trotz scheinbar eintretender Entspannung bei der aktuellen Corona-Krise ist Videoconferencing nicht mehr wegzudenken. Sei es durch das Umdenken bei den Arbeitgebern zu Homeofficeregeleungen oder bei international gewachsene Teams. Alle müssen irgendwie miteinander kommunizieren. Wir von NETWAYS setzen ja schon seit Beginn der Krise auf Jitsi und konnten damit auch viele Kunden überzeugen, datenschutzkonforme Videokonferenzlösungen einzusetzen.

Neben unserer Jitsi-App (JaaS), welche sich übrigens 30 Tage kostenfrei testen lässt und darüber hinaus auch schon Branding nach eigenen Bedürfnissen anbietet, bauen wir auch Jitsi-Lösungen nach Kundenwunsch. Seien es spezielle Anforderungen an besonders viele gleichzeitige Nutzer, ein komplett eigenes Branding, JWT-Auth, Telefoneinwahl oder Datenschutz-Pop-Up’s.

Inzwischen erreichen uns auch immer öfter Anfragen, die den Wunsch äußern, solche Meetings aufzuzeichnen. Also haben wir uns hier auf die Suche gemacht und Jibri gefunden. Nachfolgend beschreibe ich in aller Kürze, wie man seinen Jitsi-Server dazu bringt Videos aufzuzeichnen. Als Basis hierzu dient ein Ubuntu 20.04 LTS-Server mit bereits eingerichtetem Jitsi.

Alle nachfolgenden Schritte werden als root auf dem Jitsi-Meet Server ausgeführt, hingegen zur offiziellen Dokumentation gibt es ein paar Stolpersteine, welche ich euch gern erspare.

Vorbereitung

Zu Beginn installieren wir die erforderlichen Kernel-Module:

apt install linux-modules-extra-$(uname -r)
apt install linux-generic
reboot
echo "snd-aloop" >> /etc/modules 
modprobe snd-aloop

Nun machen wir den Server mittels Chrome Stable als Client fit:

curl -sS -o - https://dl-ssl.google.com/linux/linux_signing_key.pub | apt-key add echo "deb [arch=amd64] http://dl.google.com/linux/chrome/deb/ stable main" > /etc/apt/sources.list.d/google-chrome.list apt-get -y update apt-get -y install google-chrome-stable

Im nächsten Schritt kommen die Chrome managed-policies dazu:

mkdir -p /etc/opt/chrome/policies/managed
echo ‘{ “CommandLineFlagSecurityWarningsEnabled”: false }’ >>/etc/opt/chrome/policies/managed/managed_policies.json

Der Chrome-Treiber darf natürlich auch nicht fehlen, daher führen wir nun aus:

CHROME_DRIVER_VERSION=`curl -sS chromedriver.storage.googleapis.com/LATEST_RELEASE` wget -N http://chromedriver.storage.googleapis.com/$CHROME_DRIVER_VERSION/chromedriver_linux64.zip -P ~/ unzip ~/chromedriver_linux64.zip -d ~/ rm ~/chromedriver_linux64.zip sudo mv -f ~/chromedriver /usr/local/bin/chromedriver sudo chown root:root /usr/local/bin/chromedriver sudo chmod 0755 /usr/local/bin/chromedriver

Noch weitere benötigte Pakete:

apt install ffmpeg curl alsa-utils icewm xdotool xserver-xorg-input-void xserver-xorg-video-dummy

Installation Jibri

Die eigentliche Jibri-Installation machen wir über apt:

apt install jibri

Ohne Rechte geht natürlich nichts, daher kommen diese auch noch dazu:

usermod -aG adm,audio,video,plugdev jibri

In den nächsten Schritten kommt noch das erforderliche Java hinzu:

wget -O - https://adoptopenjdk.jfrog.io/adoptopenjdk/api/gpg/key/public | sudo apt-key add -
add-apt-repository https://adoptopenjdk.jfrog.io/adoptopenjdk/deb/
apt-get -y update
apt-get install adoptopenjdk-8-hotspot

Wir müssen Java8 als default setzen, dazu ändern wir die nachfolgende Datei:

vim /opt/jitsi/jibri/launch.sh

Hier ändern wir das Wort “java” in den folgenden String “/usr/lib/jvm/adoptopenjdk-8-hotspot-amd64/bin/java”. Danach speichern und schließen wir Datei schon wieder.

Prosody benötigt auch noch eine kleine Änderung. Also kommt das nun direkt (Achtung, Pfad weicht auf die eigene Domain am Ende ab):

vim /etc/prosody/conf.avail/your.domain.com.cfg.lua

Dort hängen wir am Ende einfach an (your.domain.com wieder durch eigene Jitsi-Adresse ersetzen):

-- internal muc component, meant to enable pools of jibri and jigasi clients
Component "internal.auth.your.domain.com" "muc"
modules_enabled = {
"ping";
}
storage = "memory"
muc_room_cache_size = 1000

VirtualHost "recorder.your.domain.com"
modules_enabled = {
"ping";
}
authentication = "internal_plain"

Danach speichern und schließen wir die Datei wieder
Nun bekommt Prosody noch 2 neue Nutzer, die Passwörter “JPwd” und “RPwd” ersetzt man durch eigene, sichere Passwörter und notiert diese für später:

prosodyctl register jibri auth.your.domain.com JPwd
prosodyctl register recorder recorder.your.domain.com RPwd

Jicofo will auch noch eine Änderung, diese beginnen wir durch öffnen des Config-Files:

vim /etc/jitsi/jicofo/sip-communicator.properties

Dort fügen wir die Zeilen ein (Achtung, Domainname anpassen):

org.jitsi.jicofo.jibri.BREWERY=JibriBrewery@internal.auth.your.domain.com 
org.jitsi.jicofo.jibri.PENDING_TIMEOUT=90

Jetzt bringen wir Jitsi selbst wirklich noch bei, eine Aufnahme zu starten (!Domainname):

vim /etc/jitsi/meet/your.domain.com-config.js

hier prüfen wir, ob die folgenden Optionen so gesetzt sind, bzw. fügen den Code ein (!Domain):

fileRecordingsEnabled: true, 
liveStreamingEnabled: true, 
hiddenDomain: 'recorder.your.domain.com',

Der Dateispeicherort bekommt nun auch noch die Rechte, die er braucht, um von Jibri beschrieben zu werden:

mkdir /srv/recordings
chown jibri:jibri /srv/recordings

Zu guter Letzt, muss Jibri noch konfiguriert werden. Nachfolgend ein Beispiel hierfür. Man achte bitte auf das Ersetzen mit dem eigenen, korrekten Domainnamen und die korrekt vergebenen Passwörter:

vim /etc/jitsi/jibri/jibri.conf

jibri {
// A unique identifier for this Jibri
// TODO: eventually this will be required with no default
id = ""
// Whether or not Jibri should return to idle state after handling
// (successfully or unsuccessfully) a request. A value of 'true'
// here means that a Jibri will NOT return back to the IDLE state
// and will need to be restarted in order to be used again.
single-use-mode = false
api {
http {
external-api-port = 2222
internal-api-port = 3333
}
xmpp {
// See example_xmpp_envs.conf for an example of what is expected here
environments = [
{
name = "prod environment"
xmpp-server-hosts = ["your.domain.com"]
xmpp-domain = "your.domain.com"

control-muc {
domain = "internal.auth.your.domain.com"
room-name = "JibriBrewery"
nickname = "jibri-nickname"
}

control-login {
domain = "auth.your.domain.com"
username = "jibri"
password = "JPwd"
}

call-login {
domain = "recorder.your.domain.com"
username = "recorder"
password = "RPwd"
}

strip-from-room-domain = "conference."
usage-timeout = 0
trust-all-xmpp-certs = true
}]
}
}
recording {
recordings-directory = "/srv/recordings"
# TODO: make this an optional param and remove the default
finalize-script = "/path/to/finalize_recording.sh"
}
streaming {
// A list of regex patterns for allowed RTMP URLs. The RTMP URL used
// when starting a stream must match at least one of the patterns in
// this list.
rtmp-allow-list = [
// By default, all services are allowed
".*"
]
}
chrome {
// The flags which will be passed to chromium when launching
flags = [
"--use-fake-ui-for-media-stream",
"--start-maximized",
"--kiosk",
"--enabled",
"--disable-infobars",
"--autoplay-policy=no-user-gesture-required"
]
}
stats {
enable-stats-d = true
}
webhook {
// A list of subscribers interested in receiving webhook events
subscribers = []
}
jwt-info {
// The path to a .pem file which will be used to sign JWT tokens used in webhook
// requests. If not set, no JWT will be added to webhook requests.
# signing-key-path = "/path/to/key.pem"

// The kid to use as part of the JWT
# kid = "key-id"

// The issuer of the JWT
# issuer = "issuer"

// The audience of the JWT
# audience = "audience"

// The TTL of each generated JWT. Can't be less than 10 minutes.
# ttl = 1 hour
}
call-status-checks {
// If all clients have their audio and video muted and if Jibri does not
// detect any data stream (audio or video) comming in, it will stop
// recording after NO_MEDIA_TIMEOUT expires.
no-media-timeout = 30 seconds

// If all clients have their audio and video muted, Jibri consideres this
// as an empty call and stops the recording after ALL_MUTED_TIMEOUT expires.
all-muted-timeout = 10 minutes

// When detecting if a call is empty, Jibri takes into consideration for how
// long the call has been empty already. If it has been empty for more than
// DEFAULT_CALL_EMPTY_TIMEOUT, it will consider it empty and stop the recording.
default-call-empty-timeout = 30 seconds
}
}

Das wars, nun startet man die betroffenen Dienste noch neu und der Aufnahme-Button im Meeting zeigt nun auch die gewünschte Funktion:

systemctl restart jitsi-videobridge2 prosody jicofo
systemctl enable --now jibri

Die Aufnahmen sind nun in /srv/recordings zu finden. Sollte hier noch kein Bild und Ton sichtbar sein, hat final folgende Änderung in der Datei /etc/jitsi/jicofo/jicofo.conf noch Abhilfe geschafft

Man suche sich die Zeile:

trusted-domains: recorder.your.domain.com

und passt sie an, auf:

trusted-domains: [recorder.your.domain.com]

Nach einem letzten Dienstneustart läuft nun alles wie gewünscht.

Schlusswort

Bedenken sollte man, dass Videos gespeichert werden und entsprechend viel Platz verbrauchen. Dies sollte man beim Sizing des Systems beachten. Die Daten sind auch nicht einfach für jeden Teilnehmer herunterladbar, sondern liegen auf dem Jitsi-Server unter /srv/recordings.

Alles in Allem ist dies aber eine wunderbare Lösung, um Workshops mit Kollegen aufzuzeichnen und diese später an neue Kollegen weiter zu geben.

Sobald die Aufzeichnung ausgelöst wird, wird dies allen Teilnehmern auch via Text2Speech mitgeteilt. Im Meeting ist oben neben dem Meetingnamen auch ein Recording-Symbol zu sehen.

Wer ein solches Jitsi haben will, sich aber nicht gern selbst darum kümmert, wäre bei uns genau richtig und sollte den Kontakt zu unseren freundlichen Vertriebskollegen suchen. Unsere Server stehen in Nürnberg und ermöglichen so eine vollständig datenschutzkonforme Videokonferenzlösung.

Georg Mimietz
Georg Mimietz
Lead Senior Systems Engineer

Georg kam im April 2009 zu NETWAYS, um seine Ausbildung als Fachinformatiker für Systemintegration zu machen. Nach einigen Jahren im Bereich Managed Services ist er in den Vertrieb gewechselt und kümmerte sich dort überwiegend um die Bereiche Shop und Managed Services. Seit 2015 ist er als Teamlead für den Support verantwortlich und kümmert sich um Kundenanfragen und die Ressourcenplanung. Darüber hinaus erledigt er in Nacht-und-Nebel-Aktionen Dinge, für die andere zwei Wochen brauchen.

Windows 11 Release und was ihr wissen müsst!

 

Windows 11 steht vor der Tür! Seit dem 5. Oktober wird auf ausgewählten Systemen das Upgrade des neuen Betriebssystems angeboten. Ein neues Design sowie weitere Features erleichtern euch die Bedienung und Anpassung eures Systems. Ein Schelm wer die Ähnlichkeit zu MacOs erkennt. Vom neuen Startmenü über Updates zu Microsoft Teams bis hin zu der nativen Unterstützung von Android Apps bietet Windows 11 noch eine Vielzahl an Neuerungen wobei einige Features erst später implementiert werden sollen. Wer bereits vor einigen Wochen eine Preview von Windows 11 geladen hat, wird wohl gemerkt haben, dass die Systemanforderungen auf neuere Systemhardware zielt. Die wichtigsten Anforderungen auf einen Blick:

  • Prozessor: 1 Gigahertz (GHz) oder schneller mit 2 oder mehr Kernen auf einem kompatiblen 64-Bit-Prozessor oder SoC (System on a Chip)
  • RAM: 4 Gigabyte (GB)
  • Speicher 64 GB oder größeres Speichergerät
  • Systemfirmware UEFI, aktiviert für sicheren Start
  • TPM Trusted Platform Module (TPM) Version 2.0
  • Grafikkarte Kompatibel mit DirectX 12 oder höher mit WDDM 2.0-Treiber
  • Außerdem wird eine Internetverbindung mit einem Microsoft-Konto vorausgesetzt

Die komplette Liste der Systemanforderungen und Features seht ihr hier: Windows 11-Spezifikationen, -Funktionen und -Computeranforderungen

 

Features für Entwickler

Windows 11 bietet den neuen PWABuilder3, bei dem Entwickler in kürzester Zeit eine PWA aus ihrer Web-App erstellen können. Für die Erstellung hybrider Webanwendungen, stellt Windows 11 die WebView2-Runtime zur Verfügung. Das Windows Terminal und die neuen Microsoft Edge DevTools können weiterhin verwendet werden, da sie jetzt in Windows 11 enthalten sind. Die Windows App SDK macht es einfacher, Windows 11 Features für Apps zu integrieren. Entwickler können mit dem neuen ARM64 Emulation Compatible ABI Apps erstellen, die nativ unter Windows auf ARM laufen, unabhängig davon, ob als Win32, Universal Windows App oder ein anderes App-Framework.

 

Neuerungen für Gaming-Enthusiasten

Mit der Xbox-Technologie gibt es nun auch AutoHDR für Titel, die DirectX 11 oder DirectX 12 verwenden, selbst wenn diese die HDR-Ausgabe nicht unterstützen. Ebenfalls kommen neue Features wie DirectStorage (auch für Windows 10 verfügbar), die eine mindestens 1 TB große NVMe-SSD voraussetzen, um Ladezeiten zu verkürzen und schneller ins Spielgeschehen eintreten zu können. Bei DirectStorage werden die Daten der schnellen NVMe-SSD direkt an den RAM weitergegeben, so wie es bereits bei der Xbox Series X|S der Fall ist.

 

Weitere Features die zu erwähnen sind, ist die Integration von Microsoft Teams, das ein neues Design erhält und nun wie bei macOS direkt auf der Taskleiste liegt. Zusätzlich können Widgets die wir noch von Windows Vista kennen auch an der Taskleiste fixiert und abgerufen werden.

 

Für alle die noch nicht updaten können oder wollen: Windows 10 wird nach aktuellen Angaben von Microsoft bis 14. Oktober 2025 supported wobei man hier von einem “Retirement Date” spricht.

Aleksander Arsenovic
Aleksander Arsenovic
Junior Consultant

Aleksander macht eine Ausbildung zum Fachinformatiker für Systemintegration in unserem Professional Service. Wenn er nicht bei NETWAYS ist, schraubt er an seinem Desktop-PC rum und übertaktet seine Hardware. Er ist immer für eine gute Konversation zu haben.

Icinga for Windows v1.6.0 – Einfacher. Zentraler. Sicherer.

Die Kollegen von Icinga haben letzte Woche Icinga for Windows in Version v1.6.0 veröffentlicht. Auch wenn diese Version keine neuen Plugins für die Überwachung bietet, hat sich im Bereich des Icinga PowerShell Frameworks einiges getan. Dadurch ist die Lösung nicht nur einfacher zu verwenden, sondern auch noch zentraler verwaltbar und sicherer.

Dürfen wir vorstellen: Die IMC

Die IMC (Icinga Management Console) wurde im Rahmen vergangener Icinga for Windows als experimental eingeführt. Ziel war es, ein einfaches Management zu schaffen, um die meisten Funktionalitäten über eine UI abbilden zu können. Dadurch ist es nicht mehr notwendig, sich alle Befehle von Icinga for Windows zu merken oder diese zu kennen – sondern die Konfiguration erfolgt direkt darüber.

Im Zuge der Einführung der IMC, wurde ebenfalls ein neuer Setup Wizard generiert, welcher nicht nur einfacher und intuitiver ist als der alte, sondern auch noch über eine Hilfe verfügt, welche einem erklärt, welche Eingaben im jeweiligen Bereich notwendig sind und was diese bedeuten. Die Konfiguration ist hierbei im nicht-advanced Modus auf die absoluten Grundlagen beschränkt, um schnell ans Ziel zu kommen. Die restlichen Einstellungen im advanced Teil, können simpel eingesehen und geändert werden, wurden jedoch so ausgewählt, dass man in vielen Umgebungen auf eine Änderung sogar verzichten könnte.

Zentrale Verwaltung mit Repositories

Einer der großen Kritikpunkte an Icinga for Windows war die Komponenten Installation. Bisher musste jede Komponente einzeln heruntergeladen und mit einem Pfad bei der Installation hinterlegt werden. Mit Icinga for Windows v1.6.0 wurde nun ein Repository-Management hinzugefügt. Hierdurch können direkt entweder die offiziellen Repositories von Icinga for Windows auf packages.icinga.com angebunden werden oder ein eigenes, zentrales. Icinga for Windows bietet dabei die Möglichkeit, vorhandene Repositories zu synchronisieren, um diese in seiner lokalen Umgebung zu spiegeln. Dadurch kann die Installation von Systemen, welche nicht in das Internet können, deutlich vereinfacht werden. Ein Beispiel wäre hier, die offiziellen Icinga Repositories auf seinen Icinga 2 Master zu synchronisieren, um dort ein Repository für alle Systeme bereitzustellen.

Im Falle von DMZ Systemen kann das Repository wiederum von zentralen Icinga 2 Master auf Icinga Satellitensysteme synchronisiert oder aber auf zentrale File-Shares abgelegt werden, um von dort die Komponenten zu installieren. Für das Update von Repositories gibt es ebenfalls Kommandos, die eine Aktualisierung ermöglichen.

Der Vorteil des Repositories liegt darin, dass direkt die aktuellen Versionen der jeweiligen Komponenten installiert oder mit einem simplen Befehl die gesamte Umgebung aktualisiert werden kann. Sollte es aus bestimmen Gründen notwendig sein, kann die Version von einzelnen Komponenten auch gelockt werden. Das bedeutet, sofern eine ältere Version installiert ist, wird bis zur gelockten Version aktualisiert. Ist bereits die gelockte Version installiert und eine neue verfügbar, wird diese übersprungen.

Weitere Details hierzu gibt es direkt in der Icinga for Windows Repository Dokumentation.

Mehr Sicherheit durch JEA

JEA steht für Just-Enough-Administration und ist eine Lösung von Microsoft für PowerShell. Durch JEA können einzelne Benutzer, welche keine Administratoren sind, Befehle mit erhöhten Rechten im System Kontext ausführen. Die Funktionalität ist dabei ähnlich wie sudo auf Linux.

In der Vergangenheit gab es des Öfteren Probleme, das diverse Überwachungsmöglichkeiten nicht genutzt werden können, da der Benutzer beispielsweise nicht in der Hyper-V Administrator Gruppe ist und deshalb den Status der virtuellen Maschinen nicht abfragen kann. Ein weiteres Problem ergibt sich auch, wenn man diverse Services oder Tasks überwachen möchte, welchen mit einem normalen Standardbenutzer nicht eingesehen werden können.

Durch ein JEA-Profil wird es erlaubt, dass ein bestimmter Benutzer diese Plugins nun im Systemkontext mit erhöhten Rechten ausführt. Dabei wird von Icinga for Windows ein Profil basierend auf allen installierten Komponenten erstellt. Dieses Profil deckt jedoch nur die notwendigen Befehle zum Ausführen von Plugins und Komponenten ab. Für Icinga for Windows notwendigen Befehle für das Management der Umgebung, werden dabei nicht berücksichtigt.

Um das ganze abzurunden und die Trennung perfekt zu machen, bietet Icinga for Windows die Möglichkeit an, einen Managed User mit dem Namen icinga anzulegen. Dieser Benutzer ist ein lokaler Benutzer auf dem System, ohne Berechtigungen sich lokal oder per RDP anzumelden. Der einzige Zweck ist, dass er als Service Benutzer fungiert und den Icinga Agent sowie den Icinga for Windows Dienst startet. Im Zusammenspiel mit dem von Icinga for Windows generierten JEA-Profil, kann dann das System vollständig überwacht werden. Die Verwaltung des Benutzers obliegt dabei vollständig Icinga for Windows und im Rahmen der Erstellung des Benutzers oder bei diversen Änderungen an den Services während der Icinga for Windows Installation oder Updates, wird jedes Mal ein neues, zufälliges 60-stelliges Password generiert und dem Benutzer zugewiesen. Dieses Password wird nach Ende der jeweiligen Installationsschritte intern wieder verworfen und wird nirgends abgelegt. Hierdurch wird eine Kompromittierung des Systems ohne bereits vorhandene Administratorrechte deutlich erschwert.

Weitere Details sowie Anforderungen, finden sich direkt in der Icinga for Windows JEA Dokumentation.

Performance Gewinn durch API-Check Forwarder

Ein weiteres Thema welches mit Icinga for Windows v1.6.0 von experimental als stabil gilt, ist der API-Check Forwarder, welcher in vergangenen Versionen eingeführt wurde. Hintergrund dieser Lösung ist, dass das Starten sowie die Ausführung von PowerShell Befehlen innerhalb der von Icinga 2 gestarteten Shells vor allem bei Systemen mit weniger Kernen eine erhöhte Systemlast verursachen. Durch den API-Check Forwarder wird zumindest der Ausführungsteil ausgelagert, da alle Befehle für die Plugin-Ausführung innerhalb des Icinga for Windows Dienstes durchgeführt und lediglich das Ergebnis an die lokale Shell weitergereicht wird.

Für diese Lösung werden zwei zusätzliche von Icinga bereitgestellte Komponenten benötigt, um eine REST-Api bereitzustellen sowie die Checks per API auszuführen. Beides kann direkt über die neuen Icinga Repositories installiert werden. Für eine sichere Verbindung werden direkt die Zertifikate des Icinga Agent verwendet. Nach Bedarf können jedoch auch eigene Zertifikate verwendet werden. Wichtig dabei ist, dass eine Erstellung des REST-Api Sockets ohne ein TLS Zertifikat nicht möglich ist.

In der zugehörigen Dokumentation zum API-Check Forwarder von Icinga for Windows gibt es weitere Details.

Was bringt die Zukunft?

Die nächste Version von Icinga for Windows v1.7.0 ist bereits zur diesjährigen OSMC eingeplant. Hier werden wir noch weiter den Schwerpunkt auf Performance sowie eine Vielzahl von Optimierungen für Entwickler legen, um es noch einfacher zu machen eigene Plugins und Komponenten zu entwickeln. Ein entsprechender Talk ist ebenfalls eingereicht.

Wir freuen uns auf eine rege Teilnahme und wünschen bis dahin alles Gute!

Christian Stein
Christian Stein
Lead Senior Account Manager

Christian kommt ursprünglich aus der Personalberatungsbranche, wo er aber schon immer auf den IT Bereich spezialisiert war. Bei NETWAYS arbeitet er als Senior Sales Engineer und berät unsere Kunden in der vertrieblichen Phase rund um das Thema Monitoring. Gemeinsam mit Georg hat er sich Mitte 2012 auch an unserem Hardware-Shop "vergangen".

Die drei großen Fragezeichen

Eine kleine Detektivgeschichte – oder: wer Centos beerbt. Als RedHat entschied, dass Centos 8 nach nur einem Jahr sein EOL (End of Life) erreicht hat, war das relativ umstritten. Wie bei großen reichen Familien versammelten sich alle, um das Erbe zu bekommen. Wie in allen Detektivgeschichten geht es um ein Warum, Wie und Wo. Ähnlich wie in Cluedo, nur dass hier als Protagonist nicht Colonel Mustard mit der Rohrzange jemanden im Salon ermordet. Diese Frage will ich heute an der Stelle hier aber gar nicht ausgraben. Der Täter ist in diesem Fall das Familienoberhaupt mit Namen RedHat Enterprise, die Tatwaffe ist Centos Stream und der Tatort, nunja, virtuell der Cyberspace.

Centos Stream ist halt ein Unstable Branch, der für viele Kunden nicht mehr die Stabilität garantiert, welche Sie vorher hatten. Redhat versucht hier, das lizenzpflichtige Produkt (den erstgeborenen Sohn) zu promoten – was nicht per se schlecht ist. RHEL 8.x ist weiterhin ein funktionierendes OS mit Support. Hingegen das Adoptivkind (Centos8) wird von der Burgzinne geworfen. In der Erbschaftsreihenfolge rückt der ungeliebte Neffe auf (Centos Stream). Allerdings wie sieht es mit den Alternativen aus? Ich habe mir heute 3 herausgepickt, welche ich in einem kurzen Abriss mal versuche mit einer Icinga Installation zu bestücken.

Als ersten im Ring haben wir Cloudlinux, welches sich als RHEL-kompatibel vermarktet und auch direkt die Clouduser ansprechen will. Hier eins vorweg: es ist kostenpflichtig. Nach Einlegen der ISO werden wir von einem Anaconda installer begrüsst, welcher auch durch eine Kickstart beantwortet werden kann. So weit, so gut… Der Abflauf der folgenden Installation ist wie immer unspektakulär. Kernel Version ist beim ersten Start 4.18 ohne Updates. Das initial Update wirft einen nach aktuellen Stand erstmal 141 Updates entgegen. Powertools sind schon von Haus aus dabei. Ein Blick in die SSHD Konfig zeigt, dass initial PasswordAuthentication auf ‘Yes’ steht. Das mögen nicht alle 🙁 – vor allem der Butler (Root) am wenigsten.
Nun gut. Wir gehen über in die Icinga installation (Detektei Simon & Simon), welche ich hier als Benchmark verwende; wie gut, es funktioniert, Stand Juni 2021.

Es erfolgt die Subscription, welche die Cloudlinux Repos freischaltet, das ist auch relativ unspannend. (Beschatten & stundenlang im Auto warten und Screenshots machen). Es kommt an der folgenden Stelle der Punkt, auf den es ankommt. (Der also, an dem unsere Informationsfitzel langsam den Plan offenlegen.)

#> dnf install https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm
#> rpm --import https://packages.icinga.com/icinga.key
#> dnf install https://packages.icinga.com/epel/icinga-rpm-release-8-latest.noarch.rpm

Die Installation erfolgt relativ schmerzlos und wir haben ein laufendes Icinga auf einem Cloudlinux.


===========================================================
[root@localhost ~]# systemctl status icinga2
● icinga2.service - Icinga host/service/network monitoring system
Loaded: loaded (/usr/lib/systemd/system/icinga2.service; disabled; vendor preset: disabled)
Active: active (running) since Tue 2021-06-15 08:11:21 EDT; 9min ago
Main PID: 6298 (icinga2)
Tasks: 13 (limit: 5021) Memory: 14.4M
CGroup: /system.slice/icinga2.service ├─6298 /usr/lib64/icinga2/sbin/icinga2 --no-stack-rlimit daemon --close-stdio -e /var/log/icinga2/error.log ├─6313 /usr/lib64/icinga2/sbin/icinga2 --no-stack-rlimit daemon --close-stdio -e /var/log/icinga2/error.log └─6316 /usr/lib64/icinga2/sbin/icinga2 --no-stack-rlimit daemon --close-stdio -e /var/log/icinga2/error.log Jun 15 08:11:21 localhost.localdomain icinga2[6298]: [2021-06-15 08:11:21 -0400] information/ConfigItem: Instantiated 1 Host. Jun 15 08:11:21 localhost.localdomain icinga2[6298]: [2021-06-15 08:11:21 -0400] information/ConfigItem: Instantiated 2 NotificationCommands. Jun 15 08:11:21 localhost.localdomain icinga2[6298]: [2021-06-15 08:11:21 -0400] information/ConfigItem: Instantiated 12 Notifications. Jun 15 08:11:21 localhost.localdomain icinga2[6298]: [2021-06-15 08:11:21 -0400] information/ConfigItem: Instantiated 2 HostGroups. Jun 15 08:11:21 localhost.localdomain icinga2[6298]: [2021-06-15 08:11:21 -0400] information/ConfigItem: Instantiated 1 Endpoint. Jun 15 08:11:21 localhost.localdomain icinga2[6298]: [2021-06-15 08:11:21 -0400] information/ConfigItem: Instantiated 1 FileLogger. Jun 15 08:11:21 localhost.localdomain icinga2[6298]: [2021-06-15 08:11:21 -0400] information/ConfigItem: Instantiated 235 CheckCommands. Jun 15 08:11:21 localhost.localdomain icinga2[6298]: [2021-06-15 08:11:21 -0400] information/ScriptGlobal: Dumping variables to file '/var/cache/icinga2/icinga2.vars' Jun 15 08:11:21 localhost.localdomain icinga2[6298]: [2021-06-15 08:11:21 -0400] information/cli: Closing console log. Jun 15 08:11:21 localhost.localdomain systemd[1]: Started Icinga host/service/network monitoring system. ===========================================================

Damit haben wir den ersten der drei Erben getestet. In den kommenden Posts werde ich mit den anderen versuchen, Icinga zu installieren.

David Okon
David Okon
Senior Systems Engineer

Weltenbummler David hat aus Berlin fast den direkten Weg zu uns nach Nürnberg genommen. Bevor er hier anheuerte, gab es einen kleinen Schlenker nach Irland, England, Frankreich und in die Niederlande. Alles nur, damit er sein Know How als IHK Geprüfter DOSenöffner so sehr vertiefen konnte, dass er vom Apple Consultant den Sprung in unser Professional Services-Team wagen konnte. Er ist stolzer Papa eines Sohnemanns und bei uns mit der Mission unterwegs, unsere Kunden zu...

P-States selbst schalten? CPU-Performancemanagement unter Linux

Was sind nochmal P-States?

TLDR: P-States sind Performance-States. Wer sich mit der offiziellen Linux-Kernel Dokumentation auseinandersetzt, findet zusammengefasst das moderne Prozessoren in verschiedenen Abständen Frequenz- und Spannungskonfigurationen vornehmen, die auch ‘Operating Performance Points’ oder auch P-States genannt werden (obwohl man hier korrekterweise eigentlich nach CPU-Architektur & Generation unterscheiden müsste), um Leistung und Stromverbrauch zu bestimmen. Im Linux Kernel findet man hierzu das CPUFreq-Subsystem das aus drei Layern besteht: Dem Kern, Scaling-Governorn und Scaling-Treibern. Während Scaling-Governer Algorithmen zur Abschätzung künftiger Leistung da sind, kommunizieren Scaling-Treiber mit der Hardware.

Vorab: Überprüfe bitte, dass Tuned & TLP nicht stören (sollten diese extra installiert worden sein). Unter Linux befindet sich das CPUFreq Verzeichnis unter /sys/devices/system/cpu und für cpu0 unter /sys/devices/system/cpu/cpu0/cpufreq/

Einfach mal ein cat auf die oben gelisteten Dateien werfen und schauen was das eigene Gerät so bietet. Zum Beispiel könnte man sich die scaling_available_governors (das braucht man für später) anschauen. Noch cooler, durch die “Everything is a file”-Philosophie bei Unix ist es jetzt direkt möglich die scaling_min_freq zu überschreiben und sofort hochzutakten! Wichtig ist nur zu wissen, dass die Werte in KHz angegeben werden.

  • Beispiel: Bei mir sind in jenem scaling_min_freq 800000 KHz eingetragen was also 0.8 GHz entspräche.
  • Ich ändere mal den Wert in 2.7 GHz um nicht unter 2.7 GHz zu takten, danach lasse mir im Anschluss das Ergebnis zur Prüfung anzeigen (nur zu Demozwecken):

Als Root:

 echo 2700000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq && cat /proc/cpuinfo | grep MHz

Warum manuell schalten oft besser sein kann:

Die meisten Geräte laufen meiner Erfahrung nach unter einem powersave statt einem performance-Profil was manche Desktop-Erweiterungen anzeigen.

  • Das kann natürlich beim sofortigen Browseröffnen mit mehreren Tabs (plus mehreren Extensions), oder Snaps oft zum Ruckeln führen da es auch für gute Governor Profile sehr schwer ist alles mit einzubeziehen.
  • Selbiges betrifft oft auch Wifi & Bluetooth-Chipsätze, die mit individuelleren Performance-Tweaks sowie dem Abschalten des Anderen (fast immer teilen sich beide den Chip) auf einmal wesentlich besser oder stromsparender laufen.
  • Wenn Du auf längeren Reisen unterwegs bist drehst Du einfach die Frequenz auf ein Minimum runter (ohne irgendeine Chance auf höhere Frequenzen) um auf höhere Batterielaufzeiten zu kommen.
  • Nicht jedes Gerät unterstützt CPU Governor wie ondemand oder conservative wobei ersteres aggressiver, schneller und genauer arbeitet und letzterer entspannter, langsamer und ungenauer. Willst du wirklich nur powersave ausgesetzt bleiben?

Du scheinst zu wissen worauf ich nun hinaus will, es ist gut zu wissen wie man selbst schaltet, und das am besten sicher, ohne dauernd das Root-Passwort einzugeben müssen und mit Hotkey? Hier mein Ansatz:

Der Plan:

  • Teil 1: Du installierst Dir die entsprechenden Distributions-Kernel-Module.
  • Teil 2: Du legst Dir als Root-Benutzer unter /usr/local/bin 6 Dateien an. Somit teilst Du deine CPU Leistung in sinnvolle Profile ein (ein Beispiel folgt), während der eigentliche Nutzer in diese Skripte nicht schreiben darf.
  • Teil 3: Du gibst jenem Benutzer die Möglichkeit diese Skripte ohne Passwortabfrage auszuführen.
  • Teil 4: Du legst dir 6 Hotkeys an: 4 für die Skripte sowie 2 für powersave und performance.

Teil 1

  • Packte installieren:

Fedora:

sudo dnf install kernel-tools

Ubuntu:

sudo apt install linux-tools-5.8.0-63-generic #(Ubuntu will an dieser Stelle die genaue Kernelversion zum Packet wissen, und macht dir einen Vorschlag)

Testen ob es funktioniert, nun solltet du einen Frequenzwechsel der Kerne zurückbekommen:

sudo cpupower frequency-set -g powersave
sudo cpupower frequency-set -g performance

Teil 2

  • Ab jetzt bitte unter Root arbeiten: Hier erstellst und legst Du in einem Benutzerverzeichnis für Skripte 6 zusätzliche Performanz-Profile an (low, medium, high, max, powersave & performance) und machst diese im Anschluss ausführbar.
  • In folgendem Codeabschnitt ersetzt du min und max je pro Profil also 8x: Angenommen deine CPU hätte 4,2 GHZ Maximum, eine sinnvolle Einteilung in 1 GHz Abständen könnte so aussehen. (min=Minimum ist und max=Maximum):
cd /usr/local/bin && touch cpu{low,mid,high,max,performance,powersave}.sh;
echo $'#!/bin/bash\ncpupower frequency-set --min 800000 --max 1500000' > /usr/local/bin/cpulow.sh;
echo $'#!/bin/bash\ncpupower frequency-set --min 1500000 --max 2500000' > /usr/local/bin/cpumid.sh;
echo $'#!/bin/bash\ncpupower frequency-set --min 2600000 --max 3500000' > /usr/local/bin/cpuhigh.sh;
echo $'#!/bin/bash\ncpupower frequency-set --min 3600000 --max 4200000' > /usr/local/bin/cpumax.sh;
echo $'#!/bin/bash\ncpupower frequency-set -g performance' > /usr/local/bin/cpuperformance.sh;
echo $'#!/bin/bash\ncpupower frequency-set -g powersave' > /usr/local/bin/cpupowersave.sh;
cd /usr/local/bin && chmod +x cpu{low,mid,high,max,performance,powersave}.sh

Teil 3

  • Rechte setzen via: visudo
  • Hier ersetzt Du folgendes: Dein_Benutzername=Deinen Benutzernamen

#Eigene CPU-Frequenz Profile für Benutzer: Dein_Benutzername

 Dein_Benutzername ALL=(root) NOPASSWD: /usr/local/bin/cpulow.sh, /usr/local/bin/cpumid.sh, /usr/local/bin/cpuhigh.sh, /usr/local/bin/cpumax.sh, /usr/local/bin/cpuperformance.sh, /usr/local/bin/cpupowersave.sh

Teil 4

Hotkeys legen ist je nach Desktop-Umgebung anders, die Logik dahinter aber gleich: Immer gibt es irgendwo ein Feld oder eine Konfigurationsdatei in die man reinschreibt: Zum Beispiel unter XFCE4  via Keyboard->Application Shortcuts. Ich lege mir hier meine 6 Skripte auf die Windows/Super-Tasten {1-6}.

Super+1 = sudo -u root /usr/local/bin/cpulow.sh
Super+2 = sudo -u root /usr/local/bin/cpumid.sh
Super+3 = sudo -u root /usr/local/bin/cpuhigh.sh
Super+4 = sudo -u root /usr/local/bin/cpumax.sh
Super+5 = sudo -u root /usr/local/bin/cpuperformance.sh
Super+6 = sudo -u root /usr/local/bin/cpupowersave.sh

Lust auf mehr? Meine Ausbilder bei Professional Services bringen mir später in der Ausbildung noch mehr zu Thema Performance-Tuning bei und können Dir helfen das letzte bisschen Leistung aus Deiner Open Source Infrastruktur herauszuholen.

Patrick Dolinic
Patrick Dolinic
Junior Consultant

Nachdem Patrick sein Psychologiestudium abgeschlossen hat, ist er 2020 zu NETWAYS, wo er nun sein Hobby zum Beruf macht: Endlich kann er sich voll und ganz der Linux-Welt widmen und sein Faible für Computersicherheit ausleben. Wenn er nicht gerade arbeitet, arbeitet oder zockt er. Nebenbei versucht er beim Joggen 8 km zu reißen, schafft aktuell aber nicht mal die ersten 7.