Ansible Host-Gruppen: Wer gehört zu wem?

Immer wieder kommt es vor, dass ich in größeren Ansible-Umgebungen arbeite. Diese enthalten eine Vielzahl von verschiedenen Gruppen im Inventory, die sich auch mal aus anderen Host-Gruppen zusammen setzen. Da ist es nicht immer leicht den Überblick zu behalten.
Da kommt es schon mal vor, prüfen zu wollen oder zu müssen ob alle Gruppen richtig aufgebaut sind oder korrekt interpretiert werden.
Nach ein wenig Recherche war auch schnell mit einem einfachen Ein-Zeiler eine Lösung gefunden, um sich anzeigen zu lassen in welcher Gruppe die einzelnen Server einsortiert sind oder wie sich die Gruppe im Ansible-Inventory zusammen setzt

ansible -i <inventory> localhost -m debug -a 'var=groups'

Dabei lässt sich entweder das Inventory-Verzeichnis oder eine konkrete Inventory-Hostdatei angeben.
Und weil es mit einem Beispiel immer besser ist:

ansible -i hosts localhost -m debug -a 'var=groups'
localhost | SUCCESS => {
    "groups": {
        "all": [
            "maja42310",
            "maja42444",
            "willy1334",
            "willy24242",
            "koenigin_blau"
        ],
        "drohnen": [
            "willy1334",
            "willy24242"
        ],
        "honigbienen": [
            "maja42310",
            "maja42444"
        ],
        "honigbienenvolk": [
            "maja42310",
            "maja42444",           
            "willy1334",
            "willy24242",
            "koenigin_blau"
        ],
        "koenigin": [
            "koenigin_blau"
        ],
        "ungrouped": []
    }
}

Da ich mir das nun mehr als ein mal nicht merken konnte, dachte ich mir ich schreib das mal hier auf. Vielleicht hilft es ja dem ein oder anderen und ich kann es mir jetzt besser merken:)

Wenn Ihr noch mehr über Ansible erfahren wollt, dann besucht doch einfach eines unserer Trainings bei Netways Events. Sollte es schon etwas konkreter sein und Ihr benötigt gezielt Hilfe, fragt doch gerne unsere Kollegen vom Sales Team ob Ihr nicht Unterstützung von Netways Professional Service bekommt.

Daniel Neuberger
Daniel Neuberger
Senior Consultant

Nach seiner Ausbildung zum Fachinformatiker für Systemintegration und Tätigkeit als Systemadministrator kam er 2012 zum Consulting. Nach nun mehr als 4 Jahren Linux und Open Source Backup Consulting zieht es ihn in die Welt des Monitorings und System Management. Seit April 2017 verstärkt er das NETWAYS Professional Services Team im Consulting rund um die Themen Elastic, Icinga und Bareos. Wenn er gerade mal nicht um anderen zu Helfen durch die Welt tingelt geht er seiner...

NETWAYS ist offizieller Nextcloud-Partner

Nextcloud bietet die branchenführende lokale Plattform für Zusammenarbeit.

„Nextcloud – a safe home for all your data“, das Unternehmensmotto von Nextcloud, überzeugte uns bei NETWAYS Web Services von Anfang an, sodass wir stolz sind, unsere bisher schon sehr gute Zusammenarbeit ab sofort als offizieller Nextcloud-Partner fortführen zu dürfen.

Mit seiner Technologie kombiniert Nextcloud den Komfort und die Benutzerfreundlichkeit von Consumer-Lösungen wie Dropbox und Google Drive mit den im geschäftlichen Bereich unerlässlichen Anforderungen an Sicherheit, Datenschutz und Kontrolle. Keine andere Zusammenarbeitsplattform kommt an die Zahl der auf mehr als 250.000 geschätzten Nextcloud-Installationen im Netz heran.

NETWAYS Web Services bietet als offizieller Service Provider für Nextcloud ein zuverlässiges und GDPR-konformes Hosting in ISO 27001-zertifizierten Rechenzentren in Deutschland an. Mit unserem MyEngineer bieten wir darüber hinaus einen persönlichen Ansprechpartner, der unsere Kunden bei Ihrer IT unterstützt. Für den Zugang zu einer breiten Palette von Nextcloud-Anwendungen sowie zuverlässige Updates und Backups: NETWAYS Web Services ist der kompetente und persönliche Ansprechpartner, wenn es um den sicheren Betrieb von Nextcloud geht.

Als Gegenstück zu zentralen Cloud-Diensten bietet Nextcloud Software für dezentrale und föderierte Clouds. Viel Wert legt das Unternehmen dabei unter anderem auf Prinzipien wie Open Source, Community, Privatsphäre und Sicherheit, benutzerzentriertes Design und Barrierefreiheit.

Mit mittlerweile über 40 Mitarbeitern hat Frank Karlitschek in Zusammenarbeit mit einem Dutzend erfahrener Open-Source-Unternehmer und Ingenieuren ein Unternehmen ins Leben gerufen, das den Usern die Möglichkeit bietet, die Kontrolle über ihre Daten und Kommunikation zurückzugewinnen.

Mehr zu den Nextcloud-Produkten und Standards auf der offiziellen Nextcloud-Webseite.

Pamela Drescher
Pamela Drescher
Head of Marketing

Pamela hat im Dezember 2015 das Marketing bei NETWAYS übernommen. Sie ist für die Corporate Identity unserer Veranstaltungen sowie von NETWAYS insgesamt verantwortlich. Die enge Zusammenarbeit mit Events ergibt sich aus dem Umstand heraus, dass sie vor ein paar Jahren mit Markus zusammen die Eventsabteilung geleitet hat und diese äußerst vorzügliche Zusammenarbeit nun auch die Bereiche Events und Marketing noch enger verknüpft. Privat ist sie Anführerin einer vier Mitglieder starken Katzenhorde, was ihr den absolut...

tooltip httrack

Bild der httrack WeibseiteIch stand letzte Woche vor einem kleinen Problem. Ein Freund von mir möchte seine WordPress-Seite aufgeben. Allerdings möchte er auch gerne ein Backup haben um, wie in einem Photoalbum, die schönsten Momente seines Blogs Revue passieren zu lassen.

Mit einem einem normalen “hier, DB-dump” war diesem Freund kein stück weitergeholfen und auch ein “Dann fahr dir das Setup doch in nem Docker hoch” stellte sich als nicht so zielführend heraus.

Also brauche ich ein Original-Weibseiten-Abbild, dass auch ohne DB, webserver und php schön aussieht und in weiten Teilen funktioniert.

Die einfache Lösung war für mich httrack. Ein tool das einfach genau das kann.

Kurzanleitung:

  1. installieren
  2. mkdir myExample; cd myExample
  3. httrack http://example.org

Für mich war noch der schalter –language de hilfreich. Um meine Wunschseite auch in der Wunschsprache herunterzuladen.

Christoph Niemann
Christoph Niemann
Senior Consultant

Christoph hat bei uns im Bereich Managed Service begonnen und sich dort intensiv mit dem internen Monitoring auseinandergesetzt. Seit 2011 ist er nun im Consulting aktiv und unterstützt unsere Kunden vor Ort bei größeren Monitoring-Projekten und PERL-Developer-Hells.

Wie ich meine Open Source-Apps und MyEngineers zu schätzen gelernt habe

Corona-Lockdown: Und plötzlich sind fast alle im Homeoffice… So war das zumindest bei uns. Und sicher auch bei vielen von euch!

Für mich hatten die Apps, die mir auch vorher schon die tägliche Zusammenarbeit mit Kolleg*innen erleichtert haben, schlagartig einen noch viel höheren Stellenwert. Das gute Rocket.Chat, in dem ich mich in verschiedenen Kanälen mit departmentübergreifenden Teams auf kurzem Weg zum jeweiligen gemeinsamen Projekt austausche oder in dem ich der Kollegin im privaten Channel schreibe. Normalerweise würde sie neben mir sitzen, jetzt sitzt sie am anderen Ende der Welt im indischen Lockdown fest… Jitsi, mit dem wir unsere täglichen “Telkos” abhalten. Notiz an mich: Nicht vergessen, die Frisur zurecht zu rücken, bevor ich die Kamera aktiviere! Oder der Request Tracker, mit dem ich meine täglichen ToDo’s verwalte, der aber viel mehr ist: Projektmanagement-Tool, das mich via E-Mail benachrichtigt und außerdem alle anderen, die mit auf dem Ticket sind und vom Status und Fortschritt einer Aufgabe erfahren sollen. Die gesamte Kommunikation mit Kunden oder Kollegen an einem Ort gesammelt: Da geht keine Info stiften. Und weil ich ja meine coolen NETWAYS Web Services-Kollegen habe, die sich um die Technik kümmern, kann ich ganz entspannt die Dienste nutzen und muss mir keine Gedanken machen über Sicherheit, Updates, Backups, Betrieb und so: Das läuft einfach!

Das sind sie übrigens:

Vielleicht seid Ihr im Rahmen unserer Aktion #StayAtHome ja auch in den Genuss gekommen…

Manche von Euch werden sicher noch länger mit veränderten Arbeitsbedingungen zu tun haben, die plötzlich viel digitaler sind als jemals zuvor. Lehrer*innen zum Beispiel. Andere arbeiten wahrscheinlich schon immer viel am PC, jetzt aber fast ausschließlich, so wie ich. Ich weiß meine Apps jetzt jedenfalls viel mehr zu schätzen und will die zusätzlich gewonnenen Feinheiten in Kommunikation und Arbeitsabläufen nicht mehr missen. Vielleicht seid ihr aber auch dafür verantwortlich, dass die IT einer Organisation, einer Firma oder öffentlichen Einrichtung funktioniert. Wir unterstützen Euch gerne! Wir bieten professionelle IT-Dienstleistungen auf allen Ebenen. (Ja, auch wenn da oben eine Micky Maus auf diesem Pulli ist! Homeoffice halt.)

Neben den fertigen Open Source-Apps gibt es mit der NETWAYS Cloud eine individuelle “Infrastructure as a Service” oder mit NETWAYS Managed Kubernetes Deine private Container-Plattform. Mit dem MyEngineer sind wir zudem immer persönlich für unsere Kund*innen da. Egal ob IT-Beratung, Betrieb inklusive aller Sicherheitsstandards und Backups, Migration oder Troubleshooting: Wir unterstützen Dich!

Flexibel. Passioniert. Open Source. Überzeuge Dich selbst!

Open Source-Apps

Starte Deine Lieblings-Open-Source-Apps in wenigen Minuten. Wir helfen Dir gerne, sie nahtlos in Deine Arbeitsumgebung zu integrieren!

Unsere Apps:

  • Nextcloud – Ein sicherer Platz zum Ablegen & Teilen Deiner Daten
  • Rocket.Chat – Kommunikation multimedial & in mehreren Kanälen
  • Jitsi – Dein Open Source Videoconferencing Tool
  • GitLab – Projektmanagement, nicht nur für Entwickler*innen
  • Request Tracker – Verwaltung von Anfragen & Aufgaben, perfekt ins E-Mail-System integrierbar

und viele weitere Open Source Apps

NETWAYS Cloud

Du brauchst Online-Ressourcen? Die NETWAYS Cloud ist ideal zum Erstellen oder Erweitern Deiner IT-Infrastruktur. Wir helfen Dir, Deine Infrastruktur maßzuschneidern und die passenden Komponenten zu finden: Virtuelle Maschinen, Betriebssysteme, flexible Datenspeicher und Netzwerke. Gemeinsam bauen wir Deine IT, die Du mit ein bisschen Übung ganz leicht selbst erweitern und umbauen kannst.

Jetzt in die NETWAYS Cloud starten!

NETWAYS Managed Kubernetes

Du willst mit Containern arbeiten? Kubernetes ist klarer Sieger im Kampf um die Container-Orchestrierung. Dabei geht es um viel mehr, als nur Container auf einer Vielzahl von Nodes zu starten. Wir empfehlen unsere Blog-Serie “Kubernetes – so startest Du durch!” Der einfachste Weg zum funktionalen Kubernetes-Cluster ist sicherlich unser NETWAYS Managed Kubernetes-Angebot.

NETWAYS MyEngineer

Mit unseren MyEngineers startest Du durch – Dank persönlichem, direktem Kontakt und kompetenter Unterstützung. Gemeinsam finden wir Deine beste Lösung!

Erfahre mehr über unseren MyEngineer!

Fragen? Kontaktiere uns!

Wir haben einen Live-Chat auf unserer Webseite!
Außerdem:
+49 911 92885 0
info@netways.de
nws.netways.de

Wir freuen uns, von Dir zu hören!

Julia Hornung
Julia Hornung
Senior Marketing Manager

Julia ist seit Juni 2018 Mitglied der NETWAYS Family. Vor ihrer Zeit in unserem Marketing Team hat sie als Journalistin und in der freien Theaterszene gearbeitet. Ihre Leidenschaft gilt gutem Storytelling, klarer Sprache und ausgefeilten Texten. Privat widmet sie sich dem Klettern und ihrer Ausbildung zur Yogalehrerin.

Jitsi Best Practice und Skalierung

Seit nun mehr als zwei Wochen wird dort wo es möglich ist von Zu Hause aus gearbeitet. Home-Office für ALLE! Naja mindest für die die es können.

Damit ist auch von einem Tag auf den anderen der Bedarf an Kommunikations-Werkzeugen vor allem für Video-Konferenzen gestiegen.
Hierfür gibt es einige Plattformen welche mittels Jitsi Video- und Audiokommunikation als Service anbieten. Darunter auch NETWAYS Web Services
Jitsi ist eine Freie Software welche auch selbst betrieben werden kann.
Beim Betrieb von Jitsi jedoch zeigt sich das Jitsi sehr schwierig in der Skalierung ist. Es benötigt die richtigen Ressourcen und die richtigen Clients für die Nutzung, um nicht ab einer zweistelligen Zahl von Nutzern in einen reinen Ton- und Bildsalat zu enden. Die technischen Dokumentationen jedoch sind nicht sehr ausgeprägt und durch ihre Zerstreuung sehr schwer zu einem ganzen zusammen zu fügen.

Daher werden wir uns folgend mit den Punkten Anforderungen, Skalierung und Nutzung auseinander setzen.

Empfehlung für einen eigenen Jitsi Server/Videobridge

Nach meinen Tests und der Güte an vorhandenen Quellen zur Hilfe und Dokumentation komme ich zu folgendem Ergebnis:

  • Betriebssystem: Debian 10 oder Ubuntu 18.04.4 LTS
  • Soviel CPU wie geht
    (klingt komisch ist aber so)
    CPU: bei durchschnittlich 10 Teilnehmer pro Konferenz kommen ich mit 2vCPU für die Videobridge ganz gut klar. Mehr zur Skalierung der CPU findet ihr hier:
  • jitsi-videobridge-performance-evaluation

  • CPU Jitis/Jifico/Prosody: Hier würde auch eine (v)CPU ausreichen, hängt jedoch auch wieder von der Frequentierung ab.
  • RAM: 4-8 GB für beide Server-Varianten
  • Speicherplatz: max. 50 GB SSD für beide Server-Varianten
  • Eine hohe Bandbreite
  • Die Unstable Version von Jitsi:
# install the key
wget -qO - https://download.jitsi.org/jitsi-key.gpg.key | apt-key add -
# add the unstable repo
sh -c &quot;echo 'deb https://download.jitsi.org unstable/' &gt; /etc/apt/sources.list.d/jitsi-unstable.list&quot;
apt update

Eine gute Installations-Anleitung dazu gibt es zum einen von Jan Doberstein auf seinem Blog jalogisch.de
oder auch sehr hilfreich und weiterführend auf der Seite lw1.at guides

Skalierung einer Jitsi Infrastruktur

Ausgangslage

Wir haben einen vollständig installierten Jitsi Server Namens jitsi.example.com auf Basis von Debian. Jetzt wollen wir mehr mehr Ressourcen bereit stellen, so müssen wir weitere jitsi-videobridge Instanzen aufsetzen.
In der vollständigen Installation eines Jitsi-Servers auf Basis von Debian 10 sind folgende Pakete installiert:

ii jitsi-meet 1.0.4314-1 all WebRTC JavaScript video conferences
ii jitsi-meet-prosody 1.0.3914-1 all Prosody configuration for Jitsi Meet
ii jitsi-meet-web 1.0.3914-1 all WebRTC JavaScript video conferences
ii jitsi-meet-web-config 1.0.3914-1 all Configuration for web serving of Jitsi Meet
ii jitsi-videobridge2 1132-1 amd64 WebRTC compatible Selective Forwarding Unit (SFU)

Der Part jitsi-videobridge ist der Teil der den jtisi-meet mit der Video und Audio Übertragung versorgt. Er schließt sich an jitsi-meet und dem verwendeten prosody (XMPP-Server) an.

Anbindung einer Videobridge

Dazu binden wir die die Paketquellen auf dem zweiten Server vb1.example.com ein und installieren die Videobridge:

# install the key
wget -qO - https://download.jitsi.org/jitsi-key.gpg.key | apt-key add -
# add the unstable repo
sh -c &quot;echo 'deb https://download.jitsi.org unstable/' &amp;gt; /etc/apt/sources.list.d/jitsi-unstable.list&quot;
apt update
apt install jitsi-videobridge2

Sollte eine Firewall auf dem Server jitsi.example.com aktiviert sein so müssen wir den Port 5222 für eingehende Kommunikation öffnen.

Auf dem zweiten Server vb1.example.com passen wir jetzt die Datei “/etc/jitsi/videobridge/config” an:

# Jitsi Videobridge settings

# sets the XMPP domain (default: none)
JVB_HOSTNAME=jitsi.example.com

# sets the hostname of the XMPP server (default: domain if set, localhost otherwise)
JVB_HOST=jitsi.example.com
....

Dann kommen wir zu Datei für die SIP-Kommunikation. Diese sollte vom Hauptserver jitsi.example.com übernommen werden und die UUID sollte hierbei auf jedem Server unterschiedlich gesetzt sein.
Die Datei “/etc/jitsi/videobridge/sip-communicator.properties” wird wie folgt eingestellt:

org.jitsi.videobridge.DISABLE_TCP_HARVESTER=true
org.jitsi.videobridge.ENABLE_STATISTICS=true
# Notwendig falls der Server hinter einem NAT steht.
org.ice4j.ice.harvest.NAT_HARVESTER_LOCAL_ADDRESS=local-ip
org.ice4j.ice.harvest.NAT_HARVESTER_PUBLIC_ADDRESS=public-ip
org.jitsi.videobridge.STATISTICS_TRANSPORT=muc
org.jitsi.videobridge.xmpp.user.shard.HOSTNAME=jitsi.example.com
org.jitsi.videobridge.xmpp.user.shard.DOMAIN=auth.jitsi.example.com
org.jitsi.videobridge.xmpp.user.shard.USERNAME=jvb
org.jitsi.videobridge.xmpp.user.shard.PASSWORD=
org.jitsi.videobridge.xmpp.user.shard.MUC_JIDS=JvbBrewery@internal.auth.jitsi.example.com
#UUID am besten mit &quot;uuidgen&quot; neu gernieren muss auf beiden Servern Einzigartig sein.
org.jitsi.videobridge.xmpp.user.shard.MUC_NICKNAME=9a6187f0-6d3f-46df-b1ff-ce7d2d69513a
org.jitsi.videobridge.xmpp.user.shard.DISABLE_CERTIFICATE_VERIFICATION=true

Auf Debian 10 tritt mit Java 11 folgender Fehler auf:

VB 2020-03-21 19:29:23.687 SEVERE: [16] org.jitsi.utils.concurrent.RecurringRunnableExecutor.log() The invocation of the method org.jitsi.videobridge.stats.StatsManager$StatisticsPeriodicRunnable.run() threw an exception.
java.lang.reflect.InaccessibleObjectException: Unable to make public long com.sun.management.internal.OperatingSystemImpl.getTotalPhysicalMemorySize() accessible: module jdk.management does not &quot;opens com.sun.management.internal&quot; to unnamed module @54ca3634
at java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:340)
at java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:280)
at java.base/java.lang.reflect.Method.checkCanSetAccessible(Method.java:198)
at java.base/java.lang.reflect.Method.setAccessible(Method.java:192)
at org.jitsi.videobridge.stats.OsStatistics.getTotalMemory(OsStatistics.java:138)
at org.jitsi.videobridge.stats.VideobridgeStatistics.generate0(VideobridgeStatistics.java:703)
at org.jitsi.videobridge.stats.VideobridgeStatistics.generate(VideobridgeStatistics.java:450)
at org.jitsi.videobridge.stats.StatsManager$StatisticsPeriodicRunnable.doRun(StatsManager.java:321)
at org.jitsi.utils.concurrent.PeriodicRunnableWithObject.run(PeriodicRunnableWithObject.java:87)
at org.jitsi.utils.concurrent.RecurringRunnableExecutor.run(RecurringRunnableExecutor.java:216)
at org.jitsi.utils.concurrent.RecurringRunnableExecutor.runInThread(RecurringRunnableExecutor.java:292)
at org.jitsi.utils.concurrent.RecurringRunnableExecutor.access$000(RecurringRunnableExecutor.java:36)
at org.jitsi.utils.concurrent.RecurringRunnableExecutor$1.run(RecurringRunnableExecutor.java:328)

Dieser kann beseitigt werden mittels folgender Ergänzung am Ende der Java System Properties in der Datei “/etc/jitsi/videobridge/config”:

JAVA_SYS_PROPS=&quot;-Dnet.java.sip.communicator.SC_HOME_DIR_LOCATION=/etc/jitsi -Dnet.java.sip.communicator.SC_HOME_DIR_NAME=videobridge -Dnet.java.sip.communicator.SC_LOG_DIR_LOCATION=/var/log/jitsi -Djava.util.logging.config.file=/etc/jitsi/videobridge/logging.properties --add-opens jdk.management/com.sun.management.internal=ALL-UNNAMED&quot;

Nun können wir die Videobridge starten:

systemctl enable jitsi-videobridge &amp;&amp; systemctl start jitsi-videobridge

An der Stelle geht auch ein Dank an Jan Doberstein der mich auf diese Spur gebracht hat und in seinem Blog-Folge Artikel zu Scaling Jitsi

Nutzung

Das Protkoll WebRTC, welches Jitsi nutzt, wird zur Zeit nur sauber von Google Chrome unterstützt. Somit sollte allen Nutzern dieser Browser, für die Anwendung am Notebook empfohlen werden. Für Androide und iOS Geräte gibt es Applikationen den jeweiligen App-Stores. Sehr schöne Zusammenfassung und eine ausführliche Benutzer-Anleitung hierzu gibt es auch auf der Seite des Freifunk München.

Sicherheit

Zum Thema Sicherheit empfiehlt es sich am Besten zuerst die Stunning-Server von Google in der Datei “/etc/jitsi/meet/jitsi.example.com-config.js zu ersetzen. Eine geeignete Stunning-Server Konfiguration kann wie folgt lauten:

stunServers: [
{ urls: 'stun:stun.schlund.de:3478' },
{ urls: 'stun:stun.t-online.de:3478' },
{ urls: 'stun:stun.1und1.de:3478' },
{ urls: 'stun:stun.hosteurope.de:3478' },
{ urls: 'stun:stun.gmx.de:3478' },
],

Zustätzlich wenn Ihr nicht eine gänzlich freie Plattform, sondern eine mit Moderaten oder sogennante Host per Raum gestützte Instanz betreiben wollt, empfiehlt es sich in prosody und jitsi-meet die Benutzerauthentifzierung für das erstellen von Räumen zu aktivieren.
In der Datei für die prosody-Konfiguration “/etc/prosody/conf.avail/jitsi.example.com.cfg.lua”, setzen wir den Wert für “authentication” auf “internal_plain” und fügen einen neuen VirtualHost darunter ein ein:

VirtualHost &quot;jitsi.yourdomain.example&quot;
-- enabled = false -- Remove this line to enable this host
authentication = &quot;internal_plain&quot;
-- Properties below are modified by jitsi-meet-tokens package config
-- and authentication above is switched to &quot;token&quot;
--app_id=&quot;example_app_id&quot;
--app_secret=&quot;example_app_secret&quot;
-- Assign this host a certificate for TLS, otherwise it would use the one
-- set in the global section (if any).
-- Note that old-style SSL on port 5223 only supports one certificate, and will always
-- use the global one.
ssl = {
key = &quot;/etc/prosody/certs/jitsi.yourdomain.example.key&quot;;
certificate = &quot;/etc/prosody/certs/jitsi.yourdomain.example.crt&quot;;
}
-- we need bosh
modules_enabled = {
&quot;bosh&quot;;
&quot;pubsub&quot;;
&quot;ping&quot;; -- Enable mod_ping
}
c2s_require_encryption = false

VirtualHost &quot;guest.jitsi.example.com&quot;
authentication = &quot;anonymous&quot;
c2s_require_encryption = false

In der Datei “/etc/jitsi/meet/jitsi.example.com-config.js” geben wir nun den neuen VirtualHost an:

var config = {
hosts: {
// XMPP domain.
domain: 'jitsi.yourdomain.example',

// When using authentication, domain for guest users.
anonymousdomain: 'guest.jitsi.yourdomain.example',
}
}

Nun müssen wir noch jifico dazu veranlassen auch eine Authentifizierung durchzuführen und die Klasse in der “/etc/jitsi/jicofo/sip-communicator.properties” laden:

org.jitsi.jicofo.auth.URL=XMPP:jitsi.example.com

Danach müssen die Dienste neu gestartet werden:

sudo systemctl restart prosody.service
sudo systemctl restart jicofo.service

Für die Anbindung einer Authentifizierung in Prosody gibt es auch Enterprise fähige Funktionen für LDAP und Co. Die obige Lösung beschreibt es für ein überschaubares Setup, denn die Benutzer hier müssen dann im Anschluss mit der prosodctl generiert werden:

prosodyctl register  jitsi-meet.example.com

Abschließend bleibt zusagen…

Es ist nicht leicht gute Dokumentationen zu Jitsi und dessen Betrieb zu finden, eben so wie für das Scalling. Eine einheitliche Dokumentation gibt es nicht und somit macht es einen Gesamtüberblick nicht sehr leicht.
Neben der Jitis-Community und der Docs auf GitHub gibt es eine paar bereits schon erwähnte Artikel aber auch die sind rah. Daher die Bitte wenn jemand verbesserungen hat, meldet euch gerne!

Wenn Ihr eine Instanz dringend benötigt und euch nicht mit dem Betrieb ausseinandersetzen könnt oder naja vielleicht nicht wollt, dann schaut doch einfach bei unseren Kollengen von NWS vorbei. Dort bekommt Ihr aktuell mit dem Code #StayAtHome eine kostenlose Jitsi-Instanz für drei Monate und das ganz ohne Abo-Falle!

Also bleibt Zuhause und fragt euch gerade in diesen Tagen doch mindestens einmal am Tag:

1. Ist es wahr?
2. Ist es fair für alle Beteiligten?
3. Wird es Freundschaft und guten Willen fördern?
4. Wird es dem Wohl aller Beteiligten dienen?”

(Das sollten wir uns bei allem Fragen, was wir denken, sagen oder tun IMHO!)

Daniel Neuberger
Daniel Neuberger
Senior Consultant

Nach seiner Ausbildung zum Fachinformatiker für Systemintegration und Tätigkeit als Systemadministrator kam er 2012 zum Consulting. Nach nun mehr als 4 Jahren Linux und Open Source Backup Consulting zieht es ihn in die Welt des Monitorings und System Management. Seit April 2017 verstärkt er das NETWAYS Professional Services Team im Consulting rund um die Themen Elastic, Icinga und Bareos. Wenn er gerade mal nicht um anderen zu Helfen durch die Welt tingelt geht er seiner...

Icinga for Windows 1.0 – Eine neue Ära

Seit heute ist der erste offizielle, stabile Release des Icinga für Windows Pakets in Version 1.0 verfügbar. Das Paket besteht aus drei individuellen Komponenten – dem Icinga PowerShell Framework, dem Icinga PowerShell Service und den Icinga PowerShell Plugins. In Kombination bilden sie den Grundbaustein für die künftige Überwachung von Windows Systemen – inklusive Software, Hardware und alles was dazugehört.

Neben der klassischen Überwachung der Windows Systeme geht das Framework aber noch einen Schritt weiter: Mit über 200 Cmdlets wird nicht nur das Monitoring an sich sichergestellt, sondern auch das Deployment der einzelnen Komponenten inklusive Icinga 2 Agent. Darüber hinaus wird die Verwaltung des Agents, die Konfiguration, aber auch das Troubleshooting auf Windows System deutlich vereinfacht: Für die gängigsten Befehle wurden Wrapper-Cmdlets entwickelt, mit denen neben dem Logfile-Tracing auch Features aktiviert und deaktiviert werden können, Icinga 2 Objects auslesbar und durchsuchbar gemacht wurden oder die Funktionsfähigkeit der Icinga 2 Installation auf dem lokalen System überprüft werden kann.

Vereinfachte Installation

Folgt man der Installationsanleitung, dann stellt man fest, dass die meisten Schritte vereinfacht über einen Installations-Wizard durchgeführt werden können. Der große Vorteil dabei ist, dass die Grundinstallation nur auf einem System vollständig manuell durchgeführt werden muss. Ist der Wizard erst einmal durchgeklickt, erhält man einen Konfigurations-String, der auf einem anderen System einfach ausgeführt werden kann, nachdem dort das Framework über den Kickstart installiert worden ist. Somit ist der künftige Rollout der Systeme einfacher denn je.

Standardisiertes Monitoring

Plugins bieten die Möglichkeit, schnell und effizient einzelne Komponenten zu überwachen. Die Schwierigkeit liegt darin, den Output der Plugins richtig zusammen zu bauen und Performance-Metriken sauber zu kapseln. Zum Schluss bleibt dann nur noch das Einpassen in das standardisierte Threshold-Verhalten der Icinga Plugins sowie die Ausführung der bekannten Prüfung, ob ein Wert nun Ok, Warning, Critical oder vielleicht doch Unknown ist.

All das wird mit dem Icinga PowerShell Framework deutlich vereinfacht, denn es werden einige Funktionen bereitgestellt, die sich genau um diese Tasks kümmern. Am Ende des Tages holt man sich einfache seine Daten über PowerShell Cmdlets und packt diese in ein Icinga Check-Objekt. Mit den Informationen, die das Objekt erhält, kann anschließend geprüft werden, welchen Status das Objekt hat und mittels einem Check-Result Objekt in ein gültiges Icinga 2 Format gebracht werden. Der Output ist anschließend für alle Plugins standardisiert.

Zeitintervall-Metriken

In der Vergangenheit lag der große Vorteil von Lösungen wie NSClient++ darin, dass diese als Dienst gestartet werden konnten und dabei Metriken gesammelt haben. Hierdurch konnte man auch auf Windows beispielsweise die CPU-Load in Intervallen von 1, 3, 5 und 15 Minuten in den Performance-Daten abbilden. Installiert man das PowerShell Framework als Dienst, ist dieser Zustand für jedes Plugin ebenfalls abbildbar. Hierfür ist lediglich der Background-Daemon für den Service Check mittels

Register-IcingaBackgroundDaemon -Command ‘Start-IcingaServiceCheckDaemon’

zu registrieren. Anschließend können einzelne Service-Checks für die regelmäßige Ausführung konfiguriert werden. Möchte man für die CPU-Load alle 30 Sekunden Metriken für die Intervalle 1, 3, 5 und 15 Minuten sammeln, registriert man den Service-Check entsprechend

Register-IcingaServiceCheck -CheckCommand ‘Invoke-IcingaCheckCPU’ -Interval 30 -TimeIndexes 1, 3, 5, 15;

Anschließend startet man den PowerShell Dienst neu und erhält alle Metriken in den gewünschten Intervallen:

Administrationsunterstützung

Wer den Icinga 2 Agent auf Windows administriert, muss auch hier öfter einmal die Konsole zur Hand nehmen und das Icinga 2 Binary mit diversen Befehlen starten. Das PowerShell Framework bietet auch hierfür einige Lösungen, da – wie bereits erwähnt – gängige Befehle in einem Wrapper-Cmdlet hinterlegt sind. Ein einfaches Parsen und stetiges Lesen der Logfiles erfolgt damit über einen einzigen Befehl – ohne am Ende in das Icinga Verzeichnis navigieren oder die Logdatei suchen zu müssen:

PS> Use-Icinga; Read-IcingaAgentLogFile
[2020-02-19 14:40:31 +0100] information/RemoteCheckQueue: items: 0, rate: 0/s (6/min 30/5min 90/15min);
[2020-02-19 14:40:41 +0100] information/RemoteCheckQueue: items: 0, rate: 0/s (12/min 60/5min 180/15min);

Sucht man mittels icinga2 object list nach bestimmten Check-Commands oder generellen Einträgen, gibt es auch hierfür eine elegante Lösung:

PS> Use-Icinga; Find-IcingaAgentObjects -Find ‘*CheckMemory*’
Line #4948 => “Object ‘Invoke-IcingaCheckMemory’ of type ‘CheckCommand’:”
Line #4950 => ” * __name = “Invoke-IcingaCheckMemory””
Line #4955 => ” * value = “Use-Icinga; exit Invoke-IcingaCheckMemory””
Line #4958 => ” * value = “$IcingaCheckMemory_String_CriticalBytes$””
Line #4961 => ” * value = “$IcingaCheckMemory_Object_CriticalPercent$””
Line #4964 => ” * set_if = “$IcingaCheckMemory_Switchparameter_NoPerfData$””
Line #4967 => ” * value = “$IcingaCheckMemory_Int32_Verbosity$””
Line #4970 => ” * value = “$IcingaCheckMemory_String_WarningBytes$””
Line #4973 => ” * value = “$IcingaCheckMemory_Object_WarningPercent$””
Line #4986 => ” * name = “Invoke-IcingaCheckMemory””
Line #4994 => ” * templates = [ “Invoke-IcingaCheckMemory”, “plugin-check-command”, “PowerShell Base”, “plugin-check-command”, “plugin-check-command” ]”

Damit wird die generelle Administration nicht nur einfacher, sondern mittels PowerShell Remote-Execution können auch mehrere Systeme gleichzeitg abgefragt und Statusinformationen eingesammelt werden.

Um sicherzustellen, dass der Agent korrekt ausgeführt wird, der Dienst gestartet werden kann und alle notwendigen Komponenten vefügbar sind, gibt es einen simplen Test, der alle Funktionalitäten überprüft:

Einfache Erweiterbarkeit

Alles in allem ist das Framework so gebaut, dass es eine solide Basis für weitere Entwicklungen bietet – sei es direkt von Seiten Icinga, NETWAYS oder aus der Community. Der Developer Guide bietet schon jetzt grundlegende Erklärungen und Erläuterungen und wird in den nächsten Wochen noch erweitert. Wer sein eigenes PowerShell Modul entwickeln möchte, um Plugins für die Überwachung oder eigene Background-Daemons bereitzustellen, der findet mit diesem Framework das nötige Werkzeug.

Live Webinar

Wer sich einen eigenen Eindruck über das Icinga PowerShell Framework und dessen zahlreiche Möglichkeiten machen möchte, der sei herzlich zu unserem Icinga for Windows – Einstieg” Webinar am 11. März 2020 um 10:30 Uhr eingeladen. Wir freuen uns wie immer auf eine rege Teilnahme.

Wer Unterstützung bei der Installation und Konfiguration oder bei der Entwicklung eigener Plugins benötigt, kann natürlich gerne Kontakt mit uns aufnehmen. Ansonsten freuen wir uns natürlich über Feedback und breite Unterstützung aus der Community!

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".