pixel
Select Page

NETWAYS Blog

Skalierungseffekte von freier Software

Ein beliebtes Argument für den Einsatz von quelloffener (und idealerweise freier) Software ist, dass sie billiger wäre als eine vergleichbare proprietäre Lösung. Diese Annahme erscheint intuitiv richtig, schließlich ist diese Software oft einfach auffindbar und kostet erstmal überhaupt nichts. Seien es Programme zur Bildbearbeitung (gimp, inkscape), Browser (firefox), anständige Emailprogramme (thunderbird, Instant-Messaging-/Chat-Clients (conversations, matrix clients, gajim), Instant-Messagin-/Chat-Server (ejabberd, matrix server oder ganze Betriebssysteme (debian, ubuntu, Arch Linux) (was eigentlich unvorstellbar ist, wenn man den Aufwand der Entwicklung und Wartung in Betracht zieht).

Trotz allem ist natürlich nicht zu übersehen, dass proprietäre Software ein sehr schweren Standpunkt hat, allen voran natürlich das Betriebssystem auf den meisten Desktop-Computern, das immer noch Windows ist. Außerdem gibts es natürlich noch Hunderte und Tausende von Anwendungen, die proprietär sind, aber weniger bekannt sind, vor allem Fachanwendungen, aber auch die kleinen Programme auf den mobilen Endgeräten. Im Folgenden möchte ich deshalb auf ein paar Gedanken meinerseitz eingehen, warum dies so ist, was ich daran kritisieren möchte und was potentielle Lösungsansätze sind.

Der Grundgedanke für diesen Artikel, ist die Idee, dass freie Software sehr gut skaliert. Damit ist erstmal nicht gemeint, dass diese zwangsläufig sehr gut mit großer Last zurechtkommt, sondern dass bei vielen Projekten eine steigende Nutzerzahl mit einer steigenden Qualität der Software korreliert. Mag ein Projekt von ein oder zwei motivierten Personen gestartet werden, kann sich bei ein paar Tausend regelmässigen Nutzern vielleicht die eine oder andere mit entsprechenden Programmierkrenntnissen finden, die wieder etwas beiträgt. Und selbst, wenn es nur fünf oder zehn Personen sind, so ist dort bereits sehr viel Potential vorhanden, falls die Beteiligten motiviert sind, was sie bei einer freiwilligen und oft ehrenahmtlichen Teilnahme dann typischerweise auch sind.

Das heißt natürlich nicht, dass beliebte Projekte endlos größer und immer besser werden, zahlreiche Beispiele belegen das Gegenteil. Schließlich sind auch FOSS-Projekte immer nur Gruppierungen von Menschen, bei denen es leicht zu Problemen kommen kann, zu Streit oder Zwists oder es ändern sich einfach die Umstände, manchen verlieren über Zeit das Interesse, es stehen die benötigten Ressourcen nicht mehr zur Verfügung oder der ursprüngliche Anwendungsfall für die Software schwindet. Nichtsdestotrotz würde ich behaupten, dass, für gewisse Voraussetzungen, ein freies Modell für Software erkennbar vorteilhaft ist.

Warum sind nun noch soviele proprietäre Komponenten vorhanden? Meine Theorie an dieser Stelle ist, dass es schwierig ist, in dieser Gesellschaftsform, damit Geld zu machen und auch wenn das Ziel der meisten Menschen nicht das reich werden ist, so ist natürlich trotzdem immer die Frage im Raum, von was denn die Miete bezahlt werden soll und natürlich auch die Frage ob man Zeit und Motivation hat, die Probleme anderer Leute (oder auch nur die eigenen) zu lösen.

Bei proprietärer Software ist das Modell noch relativ einfach, man verkauft die Software in diskreten Einheiten als Produkt (klassisch wie bei Brot, Tomaten oder Baggern), Abomodell mit zeitbegrenzten Lizenzen oder in diversen anderen abgestuften Modellen, bei denen Geld für weitere Komponenten oder spezielle Features verlangt wird. Alle diese Einnahmemodelle sind meistens für FOSS nicht anwendbar; zwar spricht nichts dagegen auch hier die Software als Produkt zu verkaufen, aber es fällt schon schwerer, wenn die meisten Leute nach kurzer Suche die kostenlose Version im Internet finden, die sich ja nicht verhindern lässt (und auch nicht soll). Bei verschiedenen großen Projekten ist das teilweise kein Problem, so wird die Entwicklung des Linux-Kernels finanziell von großen Firmen getragen, deren Produkte wiederum darauf basieren. Zwar wären vermutlich weder HP, IBM, Intel, NEC, Google, Oracle, Cisco, Huawei oder gar Microsoft auf die Idee gekommen, etwas zu starten, was der Konkurrenz oder gar einfach der Menschheit an sich etwas hilft und was ohne größere Hindernisse von jeder (mit einem Computer) benutzt werden kann, aber konfrontiert mit der Option einen toten Gaul zu starten (und damit haben die Firmen durchaus Erfahrung, Microsoft Google) oder mit knirschenden Zähnen trotzdem noch Geld zu machen, war dann die Wahl einfach.

Für FOSS-Software, die auch in Unternehmen (offensichtlich) wichtig ist, gibt es durchaus die Möglichkeit Consulting oder Support hust anzubieten, aber dies ist für Software für Privatpersonen schwierig, aber auch für die Komponenten die die Infrastruktur weiter hinten bereitstellen, etwa für die dann benutzten Bibliotheken und Werkzeuge. Während man für den Fall der Privatsoftware hauptsächlich auf Enthusiasten zurückgreifen kann oder muss, gibt es bei wichtigen Bibliotheken fast nur die Hoffnung, dass Personen in Firmen dafür abgestellt werden oder Institutionen wie die Apache Software Foundation hier unterstützen. Dies ist zwar nicht direkt das Szenario der Tragik der Allmende, aber eine gewisse Verwandschaft lässt sich schwer leugnen.

Warum sollte das nun eigentlich jemanden interessieren oder etwas vulgärer formuliert: Was geht mich das an? Durch diese Mechanismen, die sicherlich jemand schöner und präziser formuliert hat, werden riesige Mengen an Ressourcen verschwendet. Wobei Ressourcen hier hauptsächlich menschliche Zeit, Nerven und Privatspäre sind. Zusätzlich wird hierbei soviel Potential für eine tatsächlich bessere Zukunft verbrannt, dass bei einer Spekulation über die verlorenen Möglichkeiten die Tränen kommen. Dieser Punkt bedarf wohl ein wenig der Erläuterung, deshalb möchte ich mit einem Beispiel fortfahren:

Beispiel Videokonferenzen

Gerade im Zug der aktuellen Pandemie haben Videokonferenzlösungen riesigen Zulauf erhalten, mittlerweile dürfte fast jede mal irgendein Zoom, Webex, Teams oder etwas in der Form kennen gelernt haben, typischerweise mehrere davon und natürlich mit allen tollen Problemen, inklusive katastrophalem Datenschutz, Sicherheitslücken und vielem mehr. Das Problem daran ist, dass alle diese Systemen nur okayish funktionieren, alle nicht miteinander reden und einem komplett sinnbefreite Hürden in den Weg legen. Ich möchte hier deshalb ein utopisches Gegenszenario formulieren:

Ich habe einen Client (ein Programm) auf dem Computer für Videokonferenzen, ich bekomme einen Link für eine Videokonferenz, der auf irgendeinen Server zeigt, dann fragt es mich nach einem Passwort, einer Nutzername/Passwort-Kombination oder sonst einer Authentifizierung, falls diese denn überhaupt nötig sein sollte. Wenn ich eine Videokonferenz eröffnen wollte, würde ich dort einen Knopf finden und einen Link erhalten, den ich über die üblichen Kanäle (Email, Messenger) dann einer mehreren Personen senden kann und fertig. Das Programm kann mein Video- und Audiosignal aufnehmen, konvertieren und senden, sowie die der anderen Teilnehmer empfangen und darstellen. Dazu kommt ein simpler Chat-Mechanismus und vielleicht Spielereien wie Notizen oder so. Damit wäre dann der allergrößte Teil all dieser anderen System abgedeckt. Im Hintergrund spricht es SIP (ein Protokoll ursprünglich von 1996) und vielleicht noch XMPP für den Chat oder so. Alles kein Hexenwerk, da die Protokolle und Bibliotheken teilweise schon seit Jahrzehnten vorhanden sind und die ganzen, oben erwähnten, Implementationen vermutlich genau diese Techniken ohnehin verwenden(!). Das Programm verfügt über vernünftige Hardware-Beschleunigung, damit ich meinen Computer und den Laubbläser vor dem Fenster noch unterscheiden kann und ist idealerweise kein verkleideter Browser, der nach dem Prinzip “Leerer Speicher ist verchwendeter Speicher” arbeitet.

Nun gut, mag sich die geneigte Leserin denken, die bis hier durchgehalten hat, denken, das klingt doch ganz gut, warum haben wir das denn nicht und meine Antwort wäre lapidar: Es lässt sich mit sinnvollen Dingen einfach schwer Geld machen. Mit den Ressourcen von Microsoft, Google, Cisco und all den anderen Anbietern zusammen wäre so ein Projekt durchaus leicht machbar, man könnte ein sinnvolles Prozedere ausarbeiten für die Protokollverhandlungen, für Erweiterungen, für Best Practices, ein paar hochbezahlte und vielleicht gute Programmierer dafür abstellen und wir hätten alle mehr davon. Jetzt ist aber das Problem, dass jemand die Frage stellen würde, was denn Firma A davon hat, wenn Firma B das auch einfach mitbenutzen kann oder (Schnappatmung) JEDER einfach ihre eigenes System aufsetzen könnte! Keine Kontrolle, vielleicht sogar keine Einnahmung! Unmöglich! So etwas ist heute kaum vorstellbar, was eigentlich obskur ist, schließlich haben sich vor Jahren (oder Jahrzehnten) genau solche Ansätze verbreitet, wie etwa Email. Ich kann mir tatsächlich nicht vorstellen, das so etwas wie Email noch einmal passieren könnte, mal ganz abgesehen davon, dass dieses Ökosystem unter der einseitigen Beeinflussung der großen Spieler auch schon massiv leidet.

Meine Verallgemeinerung dieser Situation ist folgende: Durch das Etablieren großer Monopole in dem Bereich wird die Entwicklung von tatsächlich nützlichen Dingen erheblich gebremst. Die simplistische Theorie des freien Marktes, der das beste Produkt befördert, funktioniert nur für den sehr eingeschränkten Rahmen etwa gleich großer (vieler) Spieler und Kunden mit sehr guten Informationen. Letzteres ist in Zeiten von endemischen absurden Marketingkampagnen und komplexen Thematiken ein Traum und ersteres bei großen Konzernen, die sich an zwei Händen abzählen lassen, auch nicht mehr gegeben. Jedes vielversprechende Startup (also ein Startup das viel Geld verspricht) wird schließlich bei dem geringsten Anzeichen von Erfolg von einem der Großen aufgekauft. Üblicherweise geht dabei dann alles Sinnvolle kaputt und das ganze Produkt wird dann abserviert, aber das ist auch nicht so tragisch, schließlich hat man sich relativ billig einen potentiellen Konkurrenten vom Hals geschafft.

Beispiel ÖPNV

Nehmen wir ein weiteres Beispiel zur Hand: Apps für den öffentlichen Personennah- und -fernverkehr. Nachdem ich sowieso den Miniaturcomputer in der Tasche habe, wäre die Anzeige des Fahrplans, der Ausfälle und Verspätungen und der Kauf der jeweiligen Tickets schon ein ziemliches Feature. Soweit, so gut, das Problem beginnt aber schon beim Umstieg von Nah- auf Fernverkehr, ersteres kann ich hier (im Raum Nürnberg) mit der VGN-App erledigen, für zweiteres bräuchte ich dann den DB Navigator (das hier) und dann in einer Zielstadt potentiell noch eine Dritte. Nun gut, dass sind verschiedene Unternehmen, erscheint zunächst mal logisch. Ich tendiere aber ein bisschen zum Minimalismus und suche deshalb nach der Lösung, die mit kleinstem Aufwand meine Anforderungen erfüllt. Meine Anforderung ist, von A nach B zu kommen, möglichst wenig Zeit und Geld dafür zu verbrauchen plus etwas abstraktere Kriterien wie “Ich möchte wissen von welchem Gleis wann welches Zug in welchem Abteil”. Alles Andere ist Unfug, wie etwa drei Apps dafür zu haben. Nachdem ALLE Personentransportgeschichten fast das gleiche tun, gibt es keinen Grund warum jeder jetzt das Rad nochmal neu erfindet!

Vermutlich gibt es ein paar Hundert Unternehmen weltweit, die fast das exakt gleiche bauen, fast völlig ohne Not. Natürlich sind alle Streckennetze ein wenig unterschiedlich, die Preisstrukturen auch und natürlich sind verschiedene Sprachen und kulture Gepflogenheit zu beachten, aber gibt es wirklich einen guten Grund Tausende halbgare Apps zu haben anstatt drei bis fünf (Monokulturen sind auch in der Software eine schlechte Idee, deshalb mehr eine) Gute? Es gibt Ansätze das Problem zu negieren (wie etwa die Öffi-App), aber das ist wieder mal ein kleines Team (eine Person?) die mühevoller Arbeit die ganzen APIs zusammenstückelt und natürlich ist dann Bezahlen auch keine Option darin.

Warum setzen sich denn die ÖPV-Unternehmen nicht zusammen und bauen das zu einer vollständigen Lösung aus? Mein Softwarewunsche hier wäre eine App mit der ich meine Ziele eingeben kann, die Optionen angezeigt bekomme, sinnvoll bezahlen kann und die mir dann sagt wann ich wo sein muss. Alles andere ist unnötig.

Anmerkung: Ich habe keine der oben erwänten Apps installiert, da alle keine freie Software sind, mit Trackern vollgestopft und nicht in Fdroid verfügbar. Pls fix.

Beispiel CAD-Software

Dies ist nun schon ein Nischenthema, aber durch, zumindest kleine, Einblicke in diese Sparte, bekommt man leicht das Gefühl eines großen Problems. Eine einstellige Anzahl von großen Spielern arbeitet an einer Reihe von mittelschlechten Softwareprodukten die natürlich alle nicht sinnvoll miteinander kompatibel sind. Diese sind dann natürlich extrem kostspielig (und außerdem schwierig zu benutzen). Ganz abgesehen davon, dass eine Firma mit der Wahl der Software sich in dieser Wahl “einschliesst”, sind diese Produkte für Hobbyisten, Startups oder kleine Unternehmen kaum erschwinglich. Ich kann nur darüber spekulieren wieviel Potential an interessanten Ingenieurskreationen dadurch verloren geht. Was wäre wenn ein ambitionierter Hobbyist ein Konzept für eine sinnvolle oder zumindest schöne Konstruktion einfach konstruieren und idealerweise noch simulieren könnte ohne sich sehr tief in die (leider noch qualitativ nicht so guten) freien Lösungen einzuarbeiten oder sehr viel Geld für eine teure Lizenz opfern. Das im Zweifelsfall die Formate auch nicht sinnvoll kompatibel sind, ist dann die Austauschbarkeit und Weitergabe eingeschränkt, was wiederum unnötige Mehrarbeit erzeugt.

Ausblick

Ich habe die Theorie das die Softwarewelt in der aktuellen Situation furchtbar ineffizient, rückständig, unsicher und unnötig schädlich für die Benutzer ist und vor allem, dass dies kein notwendiger Zustand ist, sondern eine Folge eines Denkens und Wirtschaftens, dass nicht den größten Nutzen vieler sondern nur Einzelner anstrebt (vielleicht nicht mal das). Diese Probleme begleiten uns täglich und werden auch absehbar nicht verschwinden, zumal sie sich sehr vertraut anfühlen, wenn man die Ursachen und die mangelnde Reaktion auf die Klimakatastrophe als Vergleich heranzieht. Zu ihrer Überwindung bräuchte es große organisatorische und vor allem willentliche Anstrengunen und ich hoffe, dass ich einen kleinen Beitrag dazu leisten kann, dass diese auch mal angegangen werden. Deshalb gibt es noch ein paar konkretere Vorschläge:

Abschaffung und Einschränkungen von Monopolen
Einzelne Unternehmen dürfen keine signifikanten Anteile an irgendeiner Sparte haben und müssen Schnittstellen für Komponenten von anderen Anbietern bieten. Die Benutzung dieser Schnittstellen darf nicht rechtlich eingeschränkt und künstlich blockiert werden

Öffentliche Gelder, öffentlicher Code
Ist das Motto der Kampagne der FSFE. Öffentliche Gelder dürfen nicht oder nur in sehr eingeschränkten Fällen zur Erstellung von nicht-freier Software benutzt werden

Keine proprietären Softwarekomponenten beschaffen oder verwenden, wenn dies in freier Software umgesetzt werden könnte. Es lohnt sich auf lange Sicht.

Unterstützt freie Software
Lasst den Entwicklern von eurer liebsten freien Software mal ein Dankeschön und etwas Geld da, das kann es einem auch mal wert sein

Zu guter Letzt möchte ich der geduldigen Leserin danken, die bis hierhin durchgehalten hat und möchte dazu einladen ein wenig Feedback dazulassen, falls es hier Zustimmung oder (fast noch wertvoller) Korrekturen und Kritig gibt.

Anschließend gibt es noch eine Sektion mit unbeliebten und unnötig geäußerten Meinungen zur Unterhaltung.

Unbeliebte Meinungen

Diese Sektion drückt meine persönliche Meinung und keine Position der Firma aus, welche dafür doch bitte keine Shitstorm bekommen sollte und bla bla bla. Wer sich angegriffen fühlt, darf mir dass in gewählter Wortwahl mitteilen oder für sich beleidigt sein.

  • Blockchains und Cryptowährungen sind Betrugsmaschen. Sie sind zu (fast) nichts nütze und sollten einfach nicht benutzt werden (Ich scheue hier das Wort “verboten”, aber unsympathisch ist es nicht). Jede Beteilung daran, macht einem zu einem Abzocker oder einem Opfer davon. Cryptowährungen sind ein System um Hoffnung auszunutzen und es ist nicht nur ein Nullsummenspiel, es ist ein Negativsummenspiel. Es macht die Welt insgesamt schlechter. Es ist falsch mitzumachen. Es wird da absehbar nichts Sinnvolles entstehen. Links: The Case against Crypto The Simple English Argument Against Crypto The Complete Argument Against Crypto The Philosophical Argument Against Crypto
  • Das gilt auch für NFTs was noch eine viel absurdere Idee. Das ist keine Verbesserung des Kunstmarktes, es ist ein Paradies für (Ab)Zocker
  • Die “sozialen Netzwerke” oder “sozialen Medien” sind größtenteils keine, sie dienen als Werbeplattform und damit zur Manipulation der Benutzer. In Summe schaden sie meiner Ansicht nach der geistigen Gesundheit schon der zugrunde liegenden Mechanismen wegen

Werbung

  • Es gibt eine neue Auflage des Icinga-Buches!
  • Sinnvolle stabile und bewährte Chat-Lösung gesucht? Wie wäre es mit XMPP? Zum selber hosten oder einfach. DSGVO-kompatibel einfach machbar, interoperabel, stabil, E2E-Verschlüsselung möglich
  • Die Free Software Foundation Europe wirbt im digitalen Raum für Bürgerrechte, freie Software und allgemein sinnvolle Entwicklungen. Kann man mal anschauen
Lorenz Kästle
Lorenz Kästle
Consultant

Lorenz hat seinen Bachelor der Informatik an der FAU gemacht und sich zuletzt mit Betriebssystemen dort beschäftigt. In seiner Freizeit beschäftigt er sich ein wenig mit XMPP und der Programmiersprache Erlang.

Log Management mit dem Elastic Stack

Auch zum Thema Elastic Stack können wir Euch eine Reihe an Unterstützung in Form von Consulting, Support und Trainings anbieten. Daher möchte ich Euch heute als Einstieg kurz vorstellen, was der Elastic Stack für Euch tun kann und wo der Mehrwert darin steckt, dieses Tool für Euer Log Management zu nutzen!

Die auch als ELK-Stack bekannten Tools setzen sich folgendermaßen zusammen:

  • Elasticsearch: performante Search und Analytics Engine basierend auf Apache Lucene
  • Logstash: bietet Pipelines zur Erfassung und Weiterverabeitung von Logs
  • Kibana: die Benutzeroberfläche für angenehmes Arbeiten
  • Beats: leichtgewichtige Data Shipper für viele verschiedene Datenquellen

 

Der Stack kann auch beliebig erweitert werden durch eine Vielzahl an weiteren verfügbaren Komponenten, z. B.:

  • Web-Crawler zum Ingestieren von Webinhalten
  • Content-Connectors als Verbindungstücke zu verschiedenen Produktivitäts- und Collaboration-Tools
  • Elastic Agent zur Anbindung von vielen Datenquellen
  • Elasticsearch Client um Daten direkt an den ELK Stack zu schicken

 

Auch kann Elastic Stack Log-Daten aus den gängigen Cloud-Lösungen ingestieren. Hierunter fallen vor allem AWS, Microsoft Azure und Google Cloud.

Der Mehrwert aus der Nutzung von Elastic Stack ergibt sich vor allem daraus, dass hiermit Daten durchsucht, analysiert und visualisiert werden können. Insbesondere kann auch nach Metadaten wie Geodaten oder Metriken gesucht werden. Weitere Funktionen bietet vor allem das Element Elasticsearch, wie die Aggregation von Daten, Iterationen von Suchergebnissen, Volltextsuchen oder das Ranking von Suchergebnissen.

Wir haben Euer Interesse am Elastic Stack geweckt? Dann kontaktiert uns doch einfach über unser Kontaktformular!

Nicole Frosch
Nicole Frosch
Sales Engineer

Ihr Interesse für die IT kam bei Nicole in ihrer Zeit als Übersetzerin mit dem Fachgebiet Technik. Seit 2010 sammelt sie bereits Erfahrungen im Support und der Administration von Storagesystemen beim ZDF in Mainz. Ab September 2016 startete Sie Ihre Ausbildung zur Fachinformatikerin für Systemintegration bei NETWAYS, wo sie vor allem das Arbeiten mit Linux und freier Software reizt. In ihrer Freizeit überschüttet Sie Ihren Hund mit Liebe, kocht viel Gesundes, werkelt im Garten, liest...

Ein kurzer Abriss über Graylog Sidecar

Graylog Sidecar ist ein Konfigurationsmanagementsystem, ein sogenanntes Framework, für unterschiedliche Log Collectoren, auch Backends genannt. Die Graylog Nodes agieren hier als zentraler Hub und halten die Konfiguration der Log Collectoren. Auf unterstützten Systemen, die Log Messages generieren, kann Sidecar als Service (unter Windows) oder daemon (unter Linux) laufen. Die Kommunikation zwischen Sidecar und Graylog wird durch eine SSL-Verschlüsselung der API gewährleistet. Für die Verbindung zwischen den Collectoren und Graylog sollte als Best Practive TLS aktiviert werden.

Die Log Collector Konfigurationen werden zentral über die Graylog Weboberfläche verwaltet. Periodisch holt sich der Sidecar daemon über die REST API alle relevanten Konfigurationen für das Ziel. Beim ersten Durchlauf oder nach einer Konfigurationsänderung erstellt Graylog Sidecar automatisch die relevanten Backend-Konfigurationsdateien. Im Anschluss werden die neu- oder umkonfigurierten Log Collectoren (neu-)gestartet.

 

Schematische Darstellung

Quelle: Graylog Sidecar

 

Folgende Punkte sind hierbei wichtig zu verstehen und zu beachten:

  • Eine Konfiguration ist die Darstellung einer Log Collector Konfigurationsdatei in der Graylog Weboberfläche. Eine Konfigurationsdatei kann den Sidecars zugewiesen werden, womit auch die entsprechenden Collectoren zugewiesen werden. Es können mehrere Konfigurationen einem einzigen Log Collector zugewiesen werden, jedoch kann ein Kollektor nicht mehreren Sidecars zugewiesen werden.
  • Inputs stellen die Prozesse dar, mit denen die Collectoren Daten sammeln. Ein Input kann z. B. ein Log File sein, das vom Collector in regelmäßgen Abständen gelesen wird, oder eine Verbindung zu einem Windows Event System, das Log Events ausgibt. Ein Input ist verbunden mit einem Output, ansonsten wäre es nicht möglich, die Daten an den näschsten Punkt zu weiterzugeben. Daher muss als erstes ein Output erstellt werden, mit dem danach einer oder mehrere Inputs verknüpft werden.
  • Jede Sidecar Instanz kann Statusinformationen zurück an Graylog senden. Über die Aktivierung der entsprechenden Funktion können Metriken wie Load oder auch die IP Adresse des Hosts, auf dem Sidecar läuft, gesendet werden. Des Weiteren sind auch Metriken enthalten, die für die Stabilität des Systems wichtig sind, z. B. Disk Volumes mit mehr als 75 % Füllstand. Zusätzlich kann per Aktivierung eine Liste mit Directories in der Graylog Weboberfläche angezeigt werden, worüber eingesehen werden kann, welche Dateien zum Sammeln bereit stehen. Diese Liste wird periodisch aktualisiert.
  • Für Sidecar existieren .deb und .rpm Packages sowie entsprechende Windows-Installer.

 

Log Collectors für Sidecar

Graylog umfasst unter anderem per Default Collector Konfigurationen für Filebeat, Winlogbeat oder NXLog (siehe untenstehende Liste). Es können aber auch weitere, eigene Collector Backends eingebracht werden wie z. B. sysmon, auditd oder packetbeat.

  • Beats on Linux: Filebeat und andere Beats
  • Beats on Windows: Im Windows Sidecare Package ist Filebeat und Winlogbeat bereits enthalten.
  • NXLog on Ubuntu
  • NXLog on CentOS
  • NXLog on Windows

 

Wir haben Euer Interesse an Graylog geweckt? Es haben sich Fragen aufgetan zu Eurer bestehenden Graylog-Umgebung? Dann her damit! Schreibt uns einfach über unser Kontaktformular oder an sales@netways.de. Auch per Telefon sind wir für Euch unter der 0911 / 92885-66 zum Thema Graylog erreichbar.

Quelle Titelbild: pixabay.com / Creator: Murmel

Nicole Frosch
Nicole Frosch
Sales Engineer

Ihr Interesse für die IT kam bei Nicole in ihrer Zeit als Übersetzerin mit dem Fachgebiet Technik. Seit 2010 sammelt sie bereits Erfahrungen im Support und der Administration von Storagesystemen beim ZDF in Mainz. Ab September 2016 startete Sie Ihre Ausbildung zur Fachinformatikerin für Systemintegration bei NETWAYS, wo sie vor allem das Arbeiten mit Linux und freier Software reizt. In ihrer Freizeit überschüttet Sie Ihren Hund mit Liebe, kocht viel Gesundes, werkelt im Garten, liest...

Graylog: Basics für eine Best Practice Installation

Graylog hat hier einiges an Best Practice definiert, die Euch dabei hilft, eine stabil und sicher laufende Installation aufzubauen. Ein Hauptaugenmerk liegt dabei auf der Anzahl der Nodes, die für eine produktiv eingesetzte Umgebung folgendermaßen aussieht:

  • mehrere Graylog Nodes mit evtl. vorgeschaltetem Loadbalancer. Hier sollte auch im Nachhinein immer wieder über entsprechende Skalierungen oder Performance-Optimierungen nachgedacht werden.
  • jeder Graylog Node ist an die MongoDB Datenbank angeschlossen. Die MongoDB Instanzen sollten als Replica Set aufgesetzt sein.
  • ein Elasticsearch Cluster bestehend aus mindestens drei Nodes, um hier mit einem Quorum arbeiten zu können. (Vermeidung von Split Brain!)
  • ein Browser Eurer Wahl für den Zugriff auf die Graylog Web GUI

 

Hier eine schematische Darstellung einer Produktivumgebung:

Quelle: https://docs.graylog.org/docs/architecture

Des Weiteren sollten Log-Daten mithilfe der geeigneten Tools, z. B. syslog, GELF oder den Beats in Graylog wandern.  Zusätzlich wird ein Loadbalancer empfohlen, über den die gesamte Kommunikation mit Graylog erfolgt und somit eine Verteilung der Last ermöglicht und die Performance optimiert. Die Kommunikation umfasst hierbei alle Aufrufe über den Browser per HTTP(S) sowie die Weiterleitung der Log-Dateien an die vorhin genannten Graylog Nodes.

Wer hier tiefer einsteigen möchte, dem seien die folgenden Links zur Graylog Dokumentation empfohlen:

 

Natürlich könnt Ihr Euer KnowHow auch mit unserer Unterstützung aufbauen und erweitern! Ihr benötigt z. B. Unterstützung bei der Skalierung Eurer Umgebung? Ihr habt neue Systeme, deren Log Daten in Graylog laufen sollen? Ihr möchtet auf Graylog Enterprise umsteigen und benötigt eine Lizenz? Mit all diesen Fragen könnt Ihr einfach auf uns zukommen über unser Kontaktformular oder per Mail an sales@netways.de.

Infos zu Schulungen und deren Buchung zum Thema Graylog könnt Ihr hier finden: Graylog Schulung

Nicole Frosch
Nicole Frosch
Sales Engineer

Ihr Interesse für die IT kam bei Nicole in ihrer Zeit als Übersetzerin mit dem Fachgebiet Technik. Seit 2010 sammelt sie bereits Erfahrungen im Support und der Administration von Storagesystemen beim ZDF in Mainz. Ab September 2016 startete Sie Ihre Ausbildung zur Fachinformatikerin für Systemintegration bei NETWAYS, wo sie vor allem das Arbeiten mit Linux und freier Software reizt. In ihrer Freizeit überschüttet Sie Ihren Hund mit Liebe, kocht viel Gesundes, werkelt im Garten, liest...

LUKS LVM Resizing

Ever tried to create a Dual Boot Ubuntu AFTER you encrypted your whole hard drive already?
Well don’t worry we got you covered!

My Problem:

I want to shrink my encrypted Ubuntu installation to make room for another OS, which I need for my video editing.
For that I have a SSD 512GB, which is encrypted with LUKS, uses LVM and ist partitioned in ext 4 fs.
But I also have an encrypted LUKS Swap called “vgubuntu-swap_1”, who also uses LVM and is formated in swap fs.

My partition had a size around 475 GiB before shrinking. The swap volume helps to demonstrate that shrinking may lead to gaps between logical LVM volumes.
The plan is to shrink the file system, its volume, the volume group and also the encrypted partition.
I used a Live Ubuntu System from a USB stick, since I could not just take the hard drive out. If you have just one computer available, use either a Live System from a USB stick or a DVD.

Disclaimer: PLEASE MAKE A BACKUP of the whole disk first.
Please read carefully through the steps first before you do anything.
If you are unsure about the commands and what they mean or what consequences they have, do some research on the Internet ahead. Likewise in case of trouble or error messages. It definitely helps to be familiar with partitioning, LVM, dm-crypt and LUKS.

My Solution:

Resizing was a sequence of 14 steps – following the disk layout in reverse order, I started resizing from the filesystem to the LVM structure down to the partition.
You open an encrypted partition with LVM on LUKS just as any dm-crypt/LUKS-partition by:

cryptsetup open /dev/Disk-MAPPING-Name cryptdisk

For the mapping name I used “cryptdisk“. Note that closing the encrypted device requires to deactivate the volume groups in the kernel first; in our case:

vgchange -a n vg1;

cryptsetup close cryptdisk

Otherwise you may not be able to close your device.

 

Step 1: Take a look at your Block Devices

With lsblk you take a look at you partitions

lsblk

For instance for me the disk appeared as “/dev/nvme0n1” – the encrypted partition was located on “/dev/nvme0n1p3”.

 

Step 2: Opening the encrypted partition

ubuntu@ubuntu:~$ cryptsetup open /dev/nvme0n1p3 cryptdisk

Review it so you know the mapping is done correctly by “ls -la /dev/mapper”
Take a look at the “cryptdisk”-device, but keep a close eye on the LVM-volumes inside the encrypted partition. They should appear automatically as distinct devices.

 

Step 3: Let’s take a look at the LVM Structure

Next up we have:

pvdisplay
vgdisplay
lvdisplay

Pvdisplay and vgdisplay show you the PV device:  “/dev/mapper/cryptdisk” and the volume group, like in my case “vgubuntu”.
With lvdisplay you can take a look at the logical volumes, so the path to the devices and LV Size. In this case it was: “/dev/vgubuntu/root” and “/dev/vgubuntu/swap_1”

 

Step 4: Filesystem Integrity check

With fsck we can make sure the filesystem is clean:

ubuntu@ubuntu:~$ sudo fsck /dev/vgubuntu/root
fsck from util-linux 2.36.1
e2fsck 1.46.3 (27-Jul-2021)
/dev/mapper/vgubuntu-root: clean, 530426/13107200 files, 14946582/52428800 blocks

That seems fine, let’s move on!

 

Step 5: Review  filesystem physical block size and used space

Since we need to take a look at the phyisical block size, we can use “fdisk -l”.
There were also a lot of loop devices in my case, but the last entry showed my encrypted drive.

ubuntu@ubuntu:~$ sudo fdisk -l

Disk /dev/mapper/cryptdisk: 475.71 GiB, 510787584000 bytes, 997632000 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Inode count:              13107200
Block count:              52428800
Reserved block count:     2621439
Free blocks:              37482218
Free inodes:              12576774

 

Step 6: Reducing the Volume and filesystem size

For the reduced filesystem I went with 210G, since it should be about 200GiB size at the end.
With lvreduce we work with GiB, so the filesystem size should be 5-10% smaller than the logical volume size. Then we would get 200 * 1024 * 1024 * 1024 Bytes = 214.748.364.800 Bytes.

 

Step 7: Actually shrinking the filesystem

Please check first if the filesystem is mounted somewhere and then proceed with:

ubuntu@ubuntu:~$ sudo resize2fs /dev/mapper/vgubuntu-root 210G
resize2fs 1.46.3 (22-Dez-2021)
Resizing the filesystem on /dev/mapper/vgubuntu-root to <pre style="padding:8px;"> (4k) blocks.
The filesystem on /dev/mapper/vgubuntu-root is now 52428800 (4k) blocks long.

 

Step 8: Shrink the logical volume

With “lvreduce” we can resize the LVM volume, the option parameter “L” together with a “size” determines how big the volume will become.

ubuntu@ubuntu:~$  lvreduce -L 200G /dev/vgubuntu/root
WARNING: Reducing active logical volume to 200 GiB.
THIS MAY DESTROY YOUR DATA (filesystem etc.)
Do you really want to reduce vgubuntu/root? [y/n]: y
Size of logical volume vgubuntu/root changed from 210 GiB (20480 extents) to 200.00 GiB (15360 extents).
Logical volume vgubuntu/root successfully resized.

Since we got the confirmation that it worked, we can now proceed.

 

Step 9: Check for gaps between the volumes of your LVM volume group

That was the trickiest part for me at least since I had a swap with my Ubuntu. The first thing I did was to scan for the Swap, on which Blocks it was located.

I then used “pvmove” to get the swap from the last blocks to the ones after my root volume.

As you can see, my swap moved over and my free space had no further volumes in between.

 

Step 10: Resize/reduce the physical LVM

Next I had to resize and reduce the physical LVM to 200G

ubuntu@ubuntu:~$ sudo pvresize --setphysicalvolumesize 200.96G /dev/mapper/cryptdisk
/dev/mapper/cryptdisk: Requested size <200.96 GiB is less than real size <475.71 GiB. Proceed?  [y/n]: y
WARNING: /dev/mapper/cryptdisk: Pretending size is 421443665 not 997632000 sectors.
Physical volume "/dev/mapper/cryptdisk" changed
1 physical volume(s) resized or updated / 0 physical volume(s) not resized

Since the resize worked, I wanted to make sure everything was fine.

ubuntu@ubuntu:~$ sudo pvdisplay
--- Physical volume ---
PV Name               /dev/mapper/cryptdisk
VG Name               vgubuntu
PV Size               <200.96 GiB / not usable <2.04 MiB
Allocatable           yes (but full)
PE Size               4.00 MiB
Total PE              51445
Free PE               0
Allocated PE          51445
PV UUID               KpzZm…

 

Step 11: Setting up the encrypted regions size

First make sure which Block Size the current drive has:

ubuntu@ubuntu:~$ sudo cryptsetup status cryptdisk
/dev/mapper/cryptdisk is active and is in use.
type:    LUKS2
cipher:  aes-xts-plain64
keysize: 512 bits
key location: keyring
device:  /dev/nvme0n1p3
sector size:  512
offset:  32768 sectors
size:    997632000 sectors
mode:    read/write

Then I had to calculate the new blocksize for the encrypted disk, I used the formula on the Arch Wiki: NEW_LUKS_SECTOR_COUNT = PV_EXTENT_COUNT * PV_EXTENT_SIZE / LUKS_SECTOR_SIZE

From Step 10 (pvdisplay) and the cryptdisk status you can gather all the information needed to get:
(53880 extent + 1 unusable extent) * 4 MiB/extent /512 B/sector = 441393152 sectors

ubuntu@ubuntu:~$  sudo cryptsetup -b 441393152 resize cryptdisk
Enter passphrase for /dev/nvme0n1p3:
ubuntu@ubuntu:~$ sudo cryptsetup status cryptdisk
/dev/mapper/cryptdisk is active and is in use.
type:    LUKS2
cipher:  aes-xts-plain64
keysize: 512 bits
key location: keyring
device:  /dev/nvme0n1p3
sector size:  512
offset:  32768 sectors
size:    441393152 sectors
mode:    read/write

And now we have a smaller LUKS Partition. You came this far, now don’t stop!

 

Step 12: Reduce the size of the physical partition

Here I used parted to get an overview of my drives and resize it to the desired size:

ubuntu@ubuntu:~$ sudo parted /dev/nvme0n1
GNU Parted 3.4
Using /dev/nvme0n1
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) print
Model: PM9A1 NVMe Samsung 512GB (nvme)
Disk /dev/nvme0n1: 512GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:
Number  Start   End     Size   File system  Name                  Flags
1      1049kB  538MB   537MB  fat32        EFI System Partition  boot, esp
2      538MB   1305MB  768MB  ext4
3      1305MB  512GB   511GB

(parted) resizepart

Partition number? 3
End?  [512GB]? 211GB
Warning: Shrinking a partition can cause data loss, are you sure you want to continue?
Yes/No? y
(parted) print
Model: PM9A1 NVMe Samsung 512GB (nvme)
Disk /dev/nvme0n1: 512GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:
Number  Start   End     Size   File system  Name                  Flags
1      1049kB  538MB   537MB  fat32        EFI System Partition  boot, esp
2      538MB   1305MB  768MB  ext4
3      1305MB  211GB   210GB

(parted) q

Information: You may need to update /etc/fstab.

I checked with print in between, to see if the parted resize worked.

 

Step 13: Set new size of the encrypted region

Now we just need to make sure we also have use the full partition size:

ubuntu@ubuntu:~$ sudo cryptsetup resize cryptdisk
ubuntu@ubuntu:~$ sudo cryptsetup status cryptdisk
/dev/mapper/cryptdisk is active.
type:    LUKS2
cipher:  aes-xts-plain64
keysize: 512 bits
key location: keyring

device:  /dev/nvme0n1p3
sector size:  512
offset:  32768 sectors
size:    409526848 sectors
mode:    read/write

 

Step 14: Reset the PV size to the full partition size

Next up we have to use pvresize so the cryptdisk gets also adjusted and then we can take a look at the volumes.

ubuntu@ubuntu:~$ pvresize  /dev/mapper/cryptdisk
Physical volume "/dev/mapper/cryptdisk" changed
1 physical volume(s) resized / 0 physical volume(s) not resized
ubuntu@ubuntu:~$ sudo pvdisplay
--- Physical volume ---
PV Name               /dev/mapper/cryptdisk
VG Name               vgubuntu
PV Size               210.47 GiB / not usable 2.00 MiB
Allocatable           yes
PE Size               4.00 MiB
Total PE              53880
Free PE               2435
Allocated PE          51445
PV UUID               Kpz...

ubuntu@ubuntu:~$ sudo vgdisplay
--- Volume group ---
VG Name               vgubuntu
System ID
Format                lvm2
...
VG Size               <210.47 GiB
PE Size               4.00 MiB
Total PE              53880
Alloc PE / Size       51445 / <200.96 GiB
Free  PE / Size       2435 / 9.51 GiB
VG UUID               dz0...

That’s it!

You can also do a checkup with gparted/disks, but apart from that I was just happy that I had more space for a second OS while also maintaining the encryption for Ubuntu!
(Now I will create another backup, just in case I break something with the new OS Installation.)