Seite wählen

NETWAYS Blog

Warum OpenSearch? Was ist OpenSearch? OpenSearch VS. Elastic

von | Jun 10, 2021 | , ,

Es fing bereits 2015 an zu brodeln, als AWS seinen neuen SaaS-Dienst „AWS Elasticsearch Services“ veröffentlichte und später dann 2019 das Produkt OpenDistro erschien. Bei zuletzt genanntem Produkt erschließt sich mir bis heute nicht, warum ich dieses der X-Pack Basic von Elastic vorziehen sollte. So lange ich natürlich ein Elasticsearch oder den Elastic Stack nicht als SaaS-Dienst vermarkten möchte. Denn dann bleibt mir nur die bis vor kurzem verfügbare OSS-Variante, welche natürlich entsprechende Features, welche im X-Pack Basic integriert sind, vermissen lässt.

2017 auf der ElasticON in San Francisco wurde das neue offene Lizenz-Modell auf Basis der Apache-2.0-Lizenz und der daraus entstandenen OSS-Variante, so wie die Veröffentlichung einer X-Pack Basic Variante bekannt gegeben. Dieser Weg wird jetzt teilweise verlassen.

Anfang des Jahres war der Höhepunkt einer langen gerichtlichen Auseinandersetzung wohl erreicht. Elastic kündigte im Januar, wohl als letztes Mittel gegen Amazon, dass Ende der OSS mit Version Elasitc Stack 7.11 und den Wechsel zu einem dualen Lizenzmodell aus Server Side Public License (SSPL, wie z.b MongoDB) oder Elastic-Lizenz an. Amazon reagierte darauf und brachte die Community zum kochen, dass Ergebnis ist der Fork von Amazon „OpenSearch“, welcher auf Elastic Stack v 7.10 aufbaut.

Jetzt wollen wir aber mal alles im Detail betrachten und wie es weitergeht.

Spieler 1: Elastic

Was bedeutet dies jetzt für die Nutzer von Elastic Stack Produkten (IMHO):

  1. Die OSS Varianten welche Elasticsearch, Kibana und Beats unter APLv2 frei nutzbar und auch als SaaS-Dienst verkaufbar machten wurden abgekündigt mit Version 7.10
  2. Die X-Pack Basic bleibt bestehen und ist weiterhin frei Verfügbar und nutzbar mit allen Features, die darin enthalten sind
  3.  Lediglich die Vermarktung des Elastic Stack als SaaS-Dienst ist nicht mehr möglich

IMHO: Bisher für mich in der Wertung alles noch kein Beinbruch und viele Reaktionen unverständlich, denn von irgendwas muss ja als Firma gelebt werden. Zudem darf man nicht vergessen, dass mit den Werkzeugen des Elastic Stack, hervorragende Standards für ein modernes Event und Informations-Managment geschaffen wurden.

Was mich aber wirklich aufregt an der ganzen Sache ist der Fakt, dass mit der Filebeat Version 7.13, die Beats nur noch mit Elasticsearch und Kibana mit Versionen ältere als 7.10 sprich 7.11 zusammen spielen. Breaking Change lesen hier.
Dies könnte es schwierig machen die aktuellen Beats bzw. Filebeat mit anderen Werkzeugen wie z.B. Graylog zu nutzen. Aber dies werden wir für euch testen und berichten.

Spieler 2: OpenSearch

Als Antwort auf die Veränderungen des Elastic Stack wurde die Community unter anderem um AWS OpenDistro laut und es brodelte weiter bis es zum Ausbruch kam und Amazon AWS den Fork von Elastic Stack OSS 7.10 bekannt gab. Dies zunächst in Form von „OpenSearch“ als Fork von Elasticsearch und OpenDashboard als Fork von Kibana. Beide kommen bereits mit einer Vielzahl an Plugins und Integrationen, wie Sie es im Elastic Stack gibt. Hier ist schon mal ein guter Grundstock vorhanden.

Am 25.5.2021 wurde die Roadmap veröffentlicht  welche besagt, dass der aktuelle RC1 am 12.07.2021 als v1.0 veröffentlicht wird.

Jetzt wollen wir aber auch die Gegenseite Stellung beziehen lassen:

  1.  Am 21.01.2021 wurde der Fork ausgerufen und der heldenhafte Einsatz für ein ehrliches und quelloffenes Elasticsearch erklärt
  2.  Am 12.04.2021 wurde der Fork „OpenSearch“ öffentlich vorgestellt und gestartet.

Was bedeutet das für neue Nutzer oder Nutzer von OpenDistro oder von Nutzern des AWS Saas-Dienstes (IMHO):

  1. Abwarten ist hier angesagt der RC1 welchen wir uns natürlich für euch bereits ansehen und auch demnächst vorstellen werden ist „nur“ ein RC.
  2. Nutzer von OpenDistro sollten mit der Veröffentlichung von Version 1.0 umsteigen. Dennn OpenDistro wird mit Version 1.13 eingestellt!
  3.  „AWS Elasticsearch Service“ Nutzer müssen nicht bangen.
  4. Denn es gibt eine Abwärts-Kompatibilität zu Elasticsearch und Kibana 7.10.2 wie hier besagt und in den FAQs beschrieben.
  5. Diese Abwärts-Kompatibilität bedeutet es ist auch von Elasticsearch-OSS 7.10 oder gar 6.0 auf OpenSearch möglich.
  6. Wer Elasticsearch als SaaS-Dienst oder in SaaS-Dienste oder ähnlichen Produkt-Formaten verwenden will muss auf OpenSearch setzen (oder einfach Solr nutzen)

 

Abschließend bleibt zu sagen…

Nun liebe Lesenden ich weiss, dass war jetzt alles nichts technisches. Aber wir sind bereits den RC1 fleißig für euch am Testen und werden euch so bald es passt davon berichten. Vielleicht sogar passend zur Veröffentlichung von Version 1.0 am 12.07.2021?

Wer bisher auf den „alt“ bewährten Elastic Stack setzen möchte, kann dies in der Zukunft natürlich gerne weiterhin tun. Zu mal auch abzuwarten bleibt, wie es sich bei einer Vielzahl von Anwendungen welche auf Elasticsearch als Speicher setzen, wie z.B Graylog  mit der Integration verhält.

IMHO: Für mich ist klar Amazon in Form von AWS hat, dies bewusst provoziert und ist nicht der faire Spieler in dieser Partie (gewesen). Denn wenn man durchs Leben geht sollte es immer gelten ….

Bei allem, was wir denken, sagen oder tun, sollten wir uns fragen:
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?”

Wer zu den oben erwähnten Themen und Werkzeugen Unterstützung benötigt, darf sich natürlich gerne von uns helfen lassen und bei den Kollegen von Sales nach einem/r Kollegen/Kollegin von Professional Services fragen. Oder in einer unserer Schulungen zu Graylog oder dem Elastic Stack lernen, wie mit den Werkzeugen in der Produktion umgegangen wird.

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...
Lies mehr von Daniel und triff unser Team

Multiline in Grok – Kein schönes Format

von | Jan 7, 2021 |

In einem modernen Log-Management ist das Aufbereiten für die spätere Analyse unverzichtbar. Je schöner das Format ist, in welchem wir eine Information geliefert bekommen, desto einfacher ist deren Verarbeitung.
Das Aufbereiten der Daten ist oft eine große Herausforderung. Doch über die Jahre hinweg habe ich mir beholfen, indem ich mir ein standardisiertes Vorgehen angewöhnt habe. Und das nicht nur weil ich ein großer Fan der RFC5424 bin.

Egal ob ich mit Graylog oder Logstash arbeite, irgendwann kommt der Punkt an dem ein Grok-Filter benötigt wird, weil kein einfaches Key-Value-Format oder noch besser kein JSON-Format vorliegt.

Ein schönes Beispiel sind Stack-Traces einer JAVA-Anwendung in JBOSS:

2020-07-02 23:54:32,979 [severity] [class] [thread]\n
traceline1\n
traceline2\n
traceline3]

Eine solches Ereignis fängt immer mit den Meta-Informationen an und ich würde zuerst aus diesen Felder erzeugen und mich im Nachgang der eigentlichen Information dem Trace als Nachricht zuwenden. Dies erfordert aber das ich mittels Grok das Feld “message” neu belegen kann. Dies ist die Voraussetzung für das weitere verarbeiten der Kern-Nachricht. Hier würde sich zum Beispiel ein Key-Value Filter anbieten.

Hierfür würden wir in der Implementierung von Grok in Logstash folgendes Muster benötigen:

(?m)

Doch nicht so in Graylog. Die Implementierung von Grok in Graylog erfordert einen anderes Muster zumindest für die Filter in den “Pipeline-Processors”

(?s)

Somit sind wir mit diesem Muster in der Lage die mehrzeilige Information als eine Nachricht in einem Grok-Filter in einer “Pipeline-Regel” abzufangen.
Hier ein Beispiel in der gänze für ein mögliches JBoss Server-Log

%{TIMESTAMP_ISO8601:timestamp}%{SPACE}%{WORD:severity}%{SPACE}\[%{HOSTNAME:jboss_class}\]%{SPACE}\[%{HOSTNAME:thread}\]\n(?<message>(?s).*)

Diese Erkenntnis für die Multiline in Grok stammt aus dem folgenden Issue #2465.
Ich hoffe es hilft dem nächsten Suchenden, dem es ergeht wie mir um mit Zeilenumbrüchen in Grok umzugehen.

Wenn Ihr gerne mehr über Graylog oder die spannenden Welt des Informations- und Event-Management wissen wollt zögert nicht ein Training bei NETWAYS Events zu besuchen oder euch direkt Hilfe bei unseren Kollegen von Netways Professional Services zu holen.

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...
Lies mehr von Daniel und triff unser Team

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

von | Aug 14, 2020 | , , , ,

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...
Lies mehr von Daniel und triff unser Team

Jitsi Best Practice und Skalierung

von | Mrz 27, 2020 | , , , , , ,

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...
Lies mehr von Daniel und triff unser Team

Elastic Stack viel neues, aber sicher!

von | Jul 5, 2019 | ,

Mit der Veröffentlichung von Elastic Stack 7 kamen bereits eine Menge Neuerungen in den Stack aber auch in den beiden darauf folgenden Releases Elastic Stack 7.1 und 7.2 wurde es nicht langweilig. Vieles davon wurde aber nicht sonderlich ins Rampenlicht gerückt oder gar groß diskutiert. Ich möchte heute mal zwei Neuerungen erwähnen und damit verbundene Auffälligkeiten.

Elastic Stack 7.1 und Elastic Stack 6.8 Elasticserach Security X-PACK Basic License

Als ich zum ersten mal am 21.05.2019 durch Zufall auf dem Elastic Blog gelesen habe, dass seit dem 20.05.2019 mit dem Release von Elastic Stack 7.1 und Elastic Stack 6.8.0 eine Basis Elasticsearch X-Pack Security verfügbar ist, dachte ich nur so: “OK” und wo ist die Diskussion wo sind die Aufhänger? Fehlanzeige nichts von alle dem.

X-Pack Security Basic License

Folgend will ich euch kurz schildern was in der Basic License möglich ist:

  • Elasticsearch HTTP und Transport TLS Encryption der Kommunikation
  • Index Security und Kibana Security mit Benutzerauthentifizierung und Rechte-Management mittels Rollen. Jedoch kommt die Basic Variante ohne LDAP/AD und Rechte-Management auf Dokumenten-Ebene und Feld-Ebene
  • Alle Komponenten können nun mit TLS und Benutzerauthentifizierung mit Elasticsearch kommunizieren

Besonders interessant dabei ist der Punkt “Index Security und Kibana Security”. Einfach ausgedrückt kann man damit Namensschemata für Indices angeben, auf die User Zugriff haben oder nicht. Auch wenn feldbasierte Rechte schön wären, reicht das meist aus, um effektiv User einzuschränken. z.B. können dann Webmaster auf alle logstash-webserver-* , DBAs auf alle logstash-db-* und Security-Leute auf alle logstash-* Indices und die darin gespeicherten Events zugreifen.

Nun noch ein kleiner Hinweis:

Ihr könnt einem User nur Rechte auf bereits vorhandene Index Pattern/Schema im Kibana geben, welche bekanntlich nur erstellt werden können wenn ein Index bereits besteht. Somit müsst ihr zum Beispiel einem User den Ihr in Logstash für das Schreiben via “logstash-output-elasticsearch” verwenden wollt, für die initiale Erstellung Superuser-Rechte vergeben. Dies ist zugegebener maßen etwas umständlich.

Bei Gelegenheit aber mehr zu diesem Thema in einem neuen Blog-Post.

Beats Logging

Die oben genannte Änderung fand in Beiträgen von Elastic auf Ihrem Blog einen Platz oder in den Breaking Changes. Jedoch gab es auch Änderungen welche weder in den Breaking Changes zu Elastic Stack 7.0 noch in einem Blogeintrag erwähnt wurden. Jedoch ist für mich die Neuerung das Logging für alle Beats über stderr in den journald zu schreiben, eine Erwähnung in den Breaking Changes wert und nicht nur in den Release Notes. So kommt es, dass jede Beats Variante unweigerlich in das System-Log schreibt und eine Option wie `logging_to_syslog: true` keine Wirkung zeigt. Denn die Einstellung wird über eine Umgebungsvariable im Systemd-Unit File als Default gesetzt, welche Einstellungen in einer Beats-Konfiguration hinfällig macht.

Nicht jeder aber möchte die Logs eines Beats in seinem System-Logs haben. Um dies zu verhindern ist eine Änderung des Unit-Files notwendig. Diese nimmt man wie folgt:

systemctl edit elasticsearch
[Service]
Environment="BEAT_LOG_OPTS="
systemctl daemon-reload
systemctl start

Die neuen Releases des Elastic Stack seit 7.x haben noch wesentlich mehr neues zu Entdecken wie z.B eine SIEM Lösung in Kibana oder das ILM im Stack welches nun auch in den Beats und Logstash vollständig integriert ist. Jedoch alles in einem Blog-Post zu verarbeiten wäre zu viel. Darum werden wir uns bemühen für euch in weiteren Blog-Posts das ein oder andere vorzustellen.

Kurz erklärt soll aber “ILM” werden, das Regeln in Elasticsearch hinterlegt, wann ein Index rotiert oder gelöscht werden soll. Das ersetzt Cronjobs mit REST-Calls oder den Curator und bietet eine einfache Möglichkeit Hot/Warm-Architekturen umzusetzen.

Auch spannend wird es für uns unsere Trainings für euch anzupassen so das diese dem neuen Elastic Stack 7.x gerecht werden. Da ich mich schon seit mehren Jahren mit dem Elastic Stack auseinander setze, finde ich gerade die Entwicklung im Kibana und dem Management des Stacks als sehr interessant. Diese bringt doch für viele eine große Erleichterung in der Wartung eines Stacks. Ich bin gespannt wie sich das entwickelt.

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...
Lies mehr von Daniel und triff unser Team

Veranstaltungen

Mi 16

stackconf online

Juni 15 - Juni 17
Di 29

Foreman Training | Nürnberg

Juni 29 @ 09:00 - Juni 30 @ 17:00
NETWAYS Headquarter | Nürnberg
Jul 01

Foreman Tech-Day

Juli 1
Jul 06

Icinga 2 Advanced Training | Online

Juli 6 @ 09:00 - Juli 8 @ 17:00
Jul 13

GitLab Advanced | Online

Juli 13 @ 09:00 - Juli 15 @ 17:00

Mehr anzeigen …