Letzten Freitag machten sich drei Späher der Adfinis SyGroup AG am Morgen früh auf den Weg auf den Berner Hausberg, den berühmten Gurten. Jedoch nicht um der schönen Aussicht zu fröhnen, sondern um bei gezogenen Vorhängen in dunklen Räumen die “Future of Web Development” zu sehen: die Jazoon TechDays 2016. Hier ist ihr Bericht:

Die Talks

Die Vorträge wurden von namhaften Stars der JavaScript-Welt präsentiert. So hörten wir viel Interessantes über aktuelle Technologien, wie z.B. über das neue Angular 2, das neue RxJS 5, Ember sowie Gedanken zur Zukunft der Web-Technologien.

Hierbei war für uns als Ember-Entwickler eine Einsicht durch Gerard Sans und Rob Wormald in Angular 2 sehr interessant. Zu unserer Überraschung sind sich diese beiden Frameworks näher, als wir erwartet haben – so konnten wir die eindrucksvolle On-Stage-Coding-Session von Rob Wormald ohne Probleme nachvollziehen.

Der Ember Vortrag von Mike North war für uns ein Heimspiel – bei der Frage, wer Ember schon eingesetzt hat, gingen nebst der Hände der Ad-Sy nur eine weitere Hand hoch – notabene ein ex Adfinisler 😉 Der Vortrag verschuf uns einen schönen Einblick über die erweiterten Vorteile von Ember im Bereich der Mobile- und Desktop-Entwicklung.

Sehr interessant war der Vortrag von Ben Lesh in Hinblick darauf, wie Asynchronität in JavaScript effizienter und sauberer gehandhabt werden kann. Dies ist z.B. für Netflix relevant, um ihre Applikation auf verschiedensten Geräten performancetechnisch wie gewünscht zum Laufen zu bringen. Uns wurde bei diesem Referat schnell klar, dass diese Ansätze nicht nur für solche Einsatzbereiche nützlich sind – noch während dem Vortrag fielen uns Einsatzmöglichkeiten in unseren Projekten ein.

Nicht nur Vorträge waren auf dem Programm: es gab auch Gesprächsrunden, denen wir beiwohnen durften – faszinierend war z.B. zu höhren, wie Ben Lesh und Mike North Alltagsprobleme in ihren erheblich grösseren Entwicklungsteams lösen. Es wurde offensichtlich, dass auch sie mit ähnlichen Problemen wie wir zu kämpfen haben.

Fazit

Generell können wir uns glücklich schätzen, ein Teil dieser zukunftsweisenden Entwicklung der Web-Technologien sein zu können. Schön zu sehen ist auch, wie die lokale Community wächst und aktiv ist. Wir fühlen uns sehr bestätigt, in diesem Bereich aktiv zu sein und sind sehr motiviert, Ember und Co. noch stärker einzusetzen, unser Wissen zu erweitern und unseren Beitrag an die Weiterentwicklung zu leisten.

Das SUSE Manager 3 beta Programm ist Ende Dezember 2015 gestartet worden. Diese Gelegenheit wollten wir nutzen, um uns einen ersten Überblick zu verschaffen, was die kommende Version beinhalten wird. Vorneweg, die wichtigste Änderung ist die Integration von SaltSack als Remote Execution und Configuration Management Framework.
Für diesen Blog Post haben wir uns folgenden Anwendungsfall ausgesucht und ein kurze Anleitung, wie es in der Praxis umgesetzt würde, verfasst.

Szenario

Damit in grösseren IT-Systemlandschaften ein vernünftiges Release und Patch Management durchgeführt werden kann, werden oft identische Systeme in unterschiedlichen Umgebungen (phases oder stages) betrieben. Steht ein neuer Release oder ein Patch zur Verfügung, werden diese zuerst auf den Entwicklungssystemen eingespielt und durchlaufen dann einige Tests und eventuelle Anpassungen, bevor sie auf den produktiven Systemen ausgerollt werden.

Der SUSE Manager liefert für dieses Szenario eine einfache Lösung. Damit einzelne Patches und Pakete von einer Umgebung in die nächste weitergereicht werden können. Zudem ist es möglich einen gesamten Stand oder ein Snapshot eines definierten Zeitpunkts von einer Umgebung in die nächste zu synchronisieren.

Voraussetzungen

Die beschriebenen Konfigurationen setzen voraus, dass ein SUSE Manger 3 installiert und mindestens ein Client System mit SLES11 oder SLES12 als Salt Minion angebunden ist.

Konfiguration

Damit das komplette Setup in der Shell durchgeführt werden kann, müssen die Pakete spacewalk-utils und spacecmd installiert werden.

suma3:~ # zypper in -y spacewalk-utils spacecmd

Dann lassen wir uns die bestehenden Software Channels anzeigen.

suma3:~ # spacewalk-manage-channel-lifecycle \
-u admin -p $PASSWORD -l

Zum jetzigen Zeitpunkt ist nur ein Channel zu sehen. Im sogenannte Vendor Channel liegen alle Pakete und Patches die vom SCC heruntergeladen werden.
Also ein Mirror der aktuellsten Paketen von SUSE.

Nun werden die vier Umgebungen (phases) erstellt.

suma3:~ # spacewalk-manage-channel-lifecycle \
-u admin -p $PASSWORD \
--channel sles12-sp1-pool-x86_64 --init \
-P devl,test,inte,prod
suma3:~ # for PHASE in devl test inte prod ; do
> spacewalk-manage-channel-lifecycle \
> -u admin -p $PASSWORD \
> --channel $PHASE-sles12-sp1-pool-x86_64 \
> --promote -P devl,test,inte,prod
> done

Werden die Umgebungen (phases) nicht explizit mit-P angegeben, wird als Standard (dev, test, prod) verwendet. Wird der Channel tree jetzt noch einmal mit dem oben genannten Befehl angezeigt, sind die fünf Base Channels zu sehen. Der Vendor- und die vier erstellten Umgebungs-Channels (devl, test, inte, prod).

Damit wir die Konfiguration testen können, weisen wir ein SUSE Manager Client System einer Umgebung zu, in unserem Beispiel der Test-Umgebung.

suma3:~ # spacecmd -u admin -p $PASSWORD -y \
system_setbasechannel suma3-client1.example \
test-sles12-sp1-pool-x86_64

Auf dem Client System kann mit folgendem Befehl überprüft werden, ob die Zuweisung funktioniert hat.

suma3-client1:~ # zypper lr

Es erscheinen nur Repositories der zugeteilten Umgebung.

Ab jetzt ist es möglich, über das WebUI oder das CLI einzelne Pakete oder Patches in eine Umgebung zu importieren, oder eine Umgebung mit einer anderen zu synchronisieren.

Hinter den Kulissen

Sobald ein Client System einem Base Channel zugewiesen ist, wird auf dem SUSE Manager, welcher als Salt Master läuft, eine Datei mit den entsprechenden Repositories erstellt.

suma3:~ # cd /srv/susemanager/salt/channels ; \
> cat channels.repo.044625baad3d49889f067f14d7cae86f
[susemanager:test-sles12-sp1-pool-x86_64]
name=test-sles12-sp1-pool-x86_64
enabled=1
autorefresh=1
baseurl=https://suma3.example/rhn/manager/download/test-sles12-sp1-pool-x86_64?eyJhbGciOiJIUzI1NiJ9.eyJleHAiOjE0ODc4MzU1NDgsImlhdCI6MTQ1NjI5OTU0OCwibmJmIjoxNDU2Mjk5NDI4LCJvcmciOjEsImp0aSI6IlRrYldFQWUwaHZGdzNZUklQQk1aWmcifQ.cmGZyuMU_SJT_fHRmj9X0zP7vM1A2KwWgNRp6m4BDcI
[...]

Das Suffix des Dateinamens entspricht der Salt Minion ID des jeweiligen Client, in unserem Falle der ID von suma3-client1.example.

Anschliessend führt der SUSE Manager den folgenden Befehl aus, welcher die Datei /etc/zypp/repos.d/susemanager:channels.repo auf dem Zielsystem suma3-client1.example neu schreibt, falls es Abweichungen zur lokalen Version gibt.

suma3:~ # salt 'suma3-client1.example' state.apply

Interaktion Spacewalk / SaltStack

Spacewalk übergibt dem Salt Master seine Befehle über dessen Rest API, und als Client Library wird die von SUSE entwickelte salt-netapi-client verwendet.

Fazit

Dieses Setup liess sich dank dem Configuration Management von SaltStack sehr einfach durchführen. Im Vergleich zu Vorgängerversionen des SUSE Manager, die als Client Stack rhns verwendeten, war die Konfiguration um einiges schlanker und die Repository-Quellen wurden schneller den Clients zugeteilt.
Die Integration von SaltStack ist eine Bereicherung für den SUSE Manager, welche nicht nur im beschriebenen Anwendungsfall erhebliche Vorteile mit sich bringt.

Markenhinweise

DRBD® und LINBIT® sind Marken oder eingetragene Marken der LINBIT in Österreich, den Vereinigten Staaten und anderen Ländern.

Bei anderen in diesem Dokument genannten Namen kann es sich um Marken oder eingetragene Marken ihrer entsprechenden Eigentümer handeln.

Lizenzhinweise

Hierbei handelt es sich um ein Handelsdokument der LINBIT und Adfinis SyGroup, für das Vertriebsbedingungen gelten. Weitere Informationen dazu finden Sie unter http://links.linbit.com/t-and-c.

1. Über DRBD
2. Einleitung
   2.1. DRBD Übersicht
   2.2. Galera Cluster Übersicht
3. Vergleich
   3.1. Netzwerkverkehr
   3.2. Commit Verzögerung
   3.3. Replikation
   3.4. Lastverteilung
   3.5. Ausfallsicherung
   3.6. Resynchronisierung
4. Zusammenfassung
5. Weitere Dokumentationen

1. Über DRBD

Bei der DRBD-Software handelt es sich um eine Linux-Kernel Replikationsfunktion auf Datenblock-Ebene, die weit verbreitet als Baustein für Shared-Nothing Cluster eingesetzt wird. Sie ist in Vanilla Kernels ab Version 2.6.33 enthalten und die erforderlichen Dienstprogramme für die Benutzerumgebung werden von den meisten Distributionen mitgeliefert. Darüber hinaus verfügen viele Distributionen über neuere DRBD-Versionen als die im Kernel-Paket enthaltene in Form von Extra-Paketen.

DRBD ist in der Lage, die Replikation über mehrere Netzwerkprotokolle und (gegenwärtig) in drei Modis durchzuführen – von synchroner Replikation für lokale HA Cluster bis hin zu asynchroner Replikation für die Weiterleitung von Daten zu einem Disaster-Recovery-Standort.

DRBD wird von LINBIT entwickelt und weltweit vertrieben; dies schließt die meisten Distributionen und Architekturen ein, mit einigen wenigen SLA Ebenen bis hinzu 24/7 E-Mail und telefonischer Verfügbarkeit.

Bei Galera Cluster handelt es sich um einen synchronen Multi-Master Datenbank-Cluster, der eine hohe Verfügbarkeit durch die Replikation der Transaktionen an alle Knoten im Cluster bereitstellt. Durch die Entfernung des von einem Zwei-Phasen-Commits eingebrachten Overheads und die Weiterleitung an einen Zertifikat basierten Replikationsmechanismus ermöglicht die Lösung eine fast lineare Skalierung bei gleichzeitiger hoher Verfügbarkeit und Konsistenz.

Galera wird von Codership entwickelt und wird vollständig in die Lösungen von MariaDB integriert und unterstützt. Adfinis SyGroup ist ein Partner von MariaDB und bietet Unterstützung bei der Implementierung, Überwachung und Wartung von MariaDB basierten Infrastrukturen.

2. Einleitung

In diesem Tech-Guide werden zwei verschiedene High-Availability Lösungen für MySQL Datenbanken verglichen; Bei der einen Lösung handelt es sich um eine Block-Device basierte Replikationslösung, die andere erweitert MariaDB Internals für die Bereitstellung einer synchronen Replikation.

Es werden einige Unterschiede aufgezeigt sowie Vor- und Nachteile diskutiert.

2.1. DRBD Übersicht

Bei DRBD handelt es sich um eine Block-Device basierte Replikationslösung, die einfach sicherstellt, dass ein Bereich an Speicherblöcken (einer Partition, Festplatte oder eines logischen Laufwerks usw.) an zwei Knoten (oder mit DRBD 9 an weiteren) identisch ist.

Dies bedeutet vollständige Unabhängigkeit von der diesen Speicher nutzenden Anwendung. Sogar das Dateisystem spielt keine Rolle – XFS, ext4, BTRFS usw. funktionieren gleich gut.

DRBD wird gewöhnlich über TCP/IP Verbindungen genutzt; mit DRBD 9 steht ebenfalls ein RDMA-Transport zur Verfügung, der die Netzwerkverzögerung reduziert und somit die Anzahl der verfügbaren IOPs ein wenig erhöht.

2.2. Galera Cluster Übersicht

Galera Cluster arbeitet innerhalb des MariaDB Binärprogramms. Über die Konfigurationseinstellungen lädt das mysql Binärprogramm die von Galera geteilte Bibliothek, die die Netzwerkkommunikation und die Replikation anderer mysql Prozesse an Remote-Netzknoten ermöglicht.

Gegenwärtig ist Galera Cluster nur mit der InnoDB Storage Engine kompatibel, da nur diese Engine die erforderliche Transaktionsunterstützung bereitstellt. Die Unterstützung weiterer Storage Engines ist möglich, sobald von diesen Transaktionen unterstützt werden.

3. Vergleich

3.1. Netzwerkverkehr

Da DRBD vom Dateisystem und den darüber liegenden Anwendungsebenen nichts mitbekommt, repliziert es alle Schreibvorgänge an den Remote-Netzwerkknoten – dass heißt Anwendungsdaten, Transaktionsprotokolle, Indizes sowie Metadaten des Dateisystems (z. B. Journal des Dateisystems, Inodes, Verzeichnisse).

Galera Cluster sendet einfach die logischen Änderungen, z. B. den Inhalt der Transaktion in Form eines gepackten Galera write-sets über das Netzwerk. Ein mehrere tausend Zeilen umfassendes UPDATE Statement hat ungefähr die Größe der aktualisierten Datensätze. Es existiert kein weiterer Overhead für Indizes oder Transaktionsprotokolle.

Die Galera Cluster Kommunikation kann entweder Unicast (TCP) oder Multicast (UDP) Verbindungen nutzen. Multicast eignet sich insbesondere für ausgedehnte Umgebungen, um den Netzwerkverkehr noch weiter zu reduzieren.

3.2. Commit Verzögerung

Mit DRBD existiert nur ein aktiver Master für diese Datenbank; sobald der endgültige Schreibvorgang auf der Festplatte für das COMMIT abgeschlossen ist, kann DRBD eine Bestätigung an die Anwendung senden. Je nach Stapelspeicher^[1] kann die Verzögerung weniger als 100 μsec betragen.

In Galera Cluster wird der Inhalt einer Transaktion an jeden Knoten im Cluster gesendet. Sobald der Client die Transaktion an einem Knoten bestätigt, sendet dieser Knoten das write-set an die anderen Knoten, die den Empfang bestätigen. Jeder Knoten führt anschließend eine Zertifizierung des ‘write-sets’ durch und nimmt die Transaktion lokal vor. Der Ursprungsknoten bestätigt die Transaktion an den Client, nachdem die lokale Zertifizierung erfolgreich abgeschlossen wurde.

Eine zusätzliche Verzögerung entsteht nur während des Sendeschritts und entspricht der längsten Roundtrip-Zeit zu irgendeinem der Knoten im Cluster. Für die Bereitstellung innerhalb der gleichen Colocation beträgt die Verzögerung normalerweise weniger als 400 μsec.

3.3. Replikation

DRBD unterstützt die synchrone und asynchrone Replikation; Letztere ist für das Disaster-Recovery über große Entfernungen hilfreich. Für diesen Fall gibt es ein separates Produkt (den DRBD Proxy), das die Komprimierung des Datenstroms der Replikation unterstützt und somit die erforderliche Bandbreite reduziert.

Galera Cluster kann nur synchron verwendet werden. Es können jedoch an jeden Galera Cluster Knoten asynchrone Standard MariaDB Replikations-Slaves angebunden werden. Da jedoch mit jedem Commit eine zusätzliche Verzögerungszeit in Verbindung steht, ist die Anzahl der Transaktionen, die über WAN-Bereitstellungen verarbeitet werden können, begrenzt. Eine Faustregel für die maximale Anzahl an Transaktionen lautet 1/RTT trx/s.

3.4. Lastverteilung

DRBD wird normalerweise in einem Aktiv/Passiv Setup verwendet, d. h. jede DRBD Ressource ist nur an einem Knoten aktiv^[2]. Dies bedeutet, dass nur ein Knoten Zugang zum Dateisystem hat, in dem eine Datenbank gespeichert wird ^[3]; dieser Knoten ist für das gesamte Statement Parsing, Abholen der Daten, Treffen von Entscheidungen und Schreiben zuständig.

Galera Cluster ist eine reine Multi-Master Lösung – jeder Knoten stellt seine eigenen Ressourcen bereit. Die einzige Auswirkung auf die Leistung entsteht durch das Senden der Transaktion an alle Knoten. Jeder Knoten kann für schreibgeschützte Anfragen verwendet werden, somit skaliert die Lese-Leistung linear. Optimistisch betrachtet kann ein gewisser Grad an Skalierbarkeit der Schreibvorgänge erreicht werden. Dies hängt jedoch von der Anwendungsstruktur ab^[4], bestenfalls kann die Schreibleistung um ca. 15 % gesteigert werden.

3.5. Ausfallsicherung

In einer HA-Umgebung muss ebenfalls eine Vorausplanung im Falle von Problemen vorhanden sein.

Wenn der aktive Knoten in einer DRBD Umgebung (aus welchen Gründen auch immer) ausfällt, muss der Cluster Stapel (normalerweise Pacemaker mit Heratbeat oder Corosync) das Problem erkennen und den Dienst auf einen anderen Knoten umschalten. Im schlimmsten Fall zieht dies eine Überprüfung des Dateisystems, eine Datenbankwiederherstellung und anschließend die Wartezeit nach sich, die erforderlich ist, um die Cachespeicher wieder verfügbar zu machen^[5].

Wenn bei Galera Cluster ein einziger Knoten ausfällt, arbeiten die verbleibenden Knoten im Cluster ohne Unterbrechung weiter. Ein Client, der gerade mit dem ausgefallenen Knoten verbunden ist, versucht die Verbindung über einen Loadbalancer^[6] wiederherzustellen. Die anderen Clients sind keiner Unterbrechung ausgesetzt. Wenn der ausgefallene Knoten wieder in Betrieb ist, kann eine Überprüfung des Dateisystems und eine Wiederherstellung der Datenbank erforderlich sein, wodurch dieser Knoten innerhalb dieser Zeit nicht für den Lastausgleich zur Verfügung steht.

3.6. Resynchronisierung

Nach einem Ausfall muss der ausgefallene Knoten sicherstellen, dass er die neuesten Daten erhält.

Das sich in der Block-Device Ebene befindende DRBD hält eine Bitmap der Dirty Datenböcke bereit und übernimmt diese einfach, sobald die DRBD Verbindung nach dem Ausfall wiederhergestellt ist. Der Kopiervorgang erfolgt in der auf der Festplatte vorliegenden Reihenfolge; die Leistung wird nur durch die Speicher- und Netzwerkhardware begrenzt. Bei einem 10 GBit Netzwerk und FusionIO Karten sollten 1,2 GByte/Sek. erreicht werden können.

Galera Cluster verfügt über zwei Wege für die Aktualisierung eines sich anschließenden Knotens. Wenn der Knoten bereits zuvor ein Mitglied des Clusters war und den Cluster nur für kurze Zeit verlassen hat^[7], versucht der Knoten einen Incremental State Transfer (IST) durchzuführen, indem er die Änderungen aus dem ‘write-set’ Cache eines anderen Knotens im Cluster herunterzieht.

Wenn kein anderer Knoten im Cluster die für den IST erforderlichen Änderungen aus seinem ‘write-set’ Cache zur Verfügung stellen kann oder wenn ein neuer Knoten dem Cluster hinzugefügt wird, wird ein Snapshot State Transfer (SST) durchgeführt. Dies bedeutet, dass alle Daten aus der Datenbank an den sich anschließenden Knoten übertragen werden. Galera wählt einen sogenannten Donor Knoten, der die Quelle für den Transfer darstellt. Da ein Donor einen großen Einfluss auf die Leistung haben kann, werden Donor-Knoten häufig aus dem Lastausgleich ausgeschlossen, um eine konsistente Lese- und Schreibleistung innerhalb des Clusters zu gewährleisten.

4. Zusammenfassung

Es folgt eine abschließende Tabelle auf Grundlage der oben diskutierten Themen.

	DRBD	Galera Cluster	Vorteil
Netzwerkverkehr	Alle geänderten Datenblöcke	nur Transaktionsinhalte	Galera
Verzögerung	μsec bis msec, je nach Speichersystem	msec, aufgrund von Userspace/Kernel Übergängen	DRBD
Replikation	synchron oder asynchron (Disaster-Recovery)	synchron oder asynchron	DRBD/Galera
Lastausgleich	Daten auf Datenblockebene können von anderen Knoten gelesen werden	vollständiger Multi-Master	Galera
Ausfallsicherung	Über Cluster-Stapel; Ausfallzeit Sekunden oder Minuten	andere Knoten arbeiten ohne Unterbrechung weiter	Galera
Resynchronisierung	Nur geänderte Datenblöcke, Datenblockgerät Reihenfolge	IST/SST	–

 

5. Weitere Dokumentationen

Die DRBD Projektseite. Unter der Adresse http://drbd.linbit.org, mit einer Menge an Informationen einschließlich eines Benutzerhandbuchs mit einem Umfang (bei der letzten Zählung) von 172 Seiten im PDF-Format – eine der umfangreichsten Projektdokumentationen in der Open Source Welt!

Die LINBIT Home Page. Die Website http://www.linbit.com beantwortet alle Ihre Fragen über den zahlungspflichtigen Support von den Entwicklern. Eine Übersicht über die unterstützten Plattformen, SLAs und Preise finden Sie unter http://www.linbit.com/en/products-and-services/drbd-support/pricing?id=358

Die Adfinis SyGroup Home Page. “We are the Linux Engineers” lautet der stolze Slogan auf https://adfinis.com. Mit mehr als 15 Jahren Linux-Erfahrung ist Adfinis SyGroup die erste Adresse in der Schweiz.

Die MariaDB Home Page. Die MariaDB Corporation https://mariadb.com ist die treibende Kraft hinter der Entwicklung von MariaDB und stellt zusammen mit ihren Partnern den Support und die Betreuung für MariaDB Produkte bereit.

---

1. RAID Controller mit BBU, FusionIO Karten und einige SSDs ↩

2. Die Verfügbarkeit eines Aktiv/Aktiv Cluster durch Aufteilen der aktiven Ressourcen auf die Knoten wird empfohlen. ↩

3. Das Aufteilen einer Datenbank funktioniert nicht. Sie können jedoch mehrere MySQL-Prozesse in einem DRBD-Cluster ausführen, bei dem jeder über eine eigene Datenbank und separate Service-IP-Adressen verfügt. ↩

4. z. B. Datenbank Hot Spots ↩

5. All dies kann von einem guten Speichersystem migriert werden. Einer unserer Kunden konnte diese Zeit durch den Wechsel der Speicherung von Festplatten auf FusionIO Karten von ca. 45 Minuten auf 30 Sekunden reduzieren. ↩

6. z. B. MariaDB MaxScale ↩

7. Zum Beispiel aufgrund eines Neustarts oder Upgrades und anschließendem Neustart von MariaDB. ↩

Heutzutage sind Hacker-Attacken keine Seltenheit mehr. Um so wichtiger ist es, Daten gut zu schützen ohne den Aufwand für Datenzugriff massiv zu erhöhen.

Security sollte für alle (Private und Firmen) ein Thema sein. Ein grosses Problem ist, dass oft nur ein (1) Passwort oder Zertifikat/Key verwendet wird. Wenn diese Information gestohlen wird, kann sich der Dieb an sämtlichen Systemen authentisieren. Genau hier kommt eine Multi-Factor, oft auch Two-Factor genannte, Authentifizierung ins Spiel. Das Ziel ist es, mehrere Faktoren zu haben, die möglichst nie zusammen aufbewahrt werden. Ist einer der Faktoren dabei zusätzlich noch dynamisch (One-Time Passwort oder Challenge-Response Verfahren) sollte dies auch sogenannte Replay-Attacken verhindern.

Grundsätzlich kann eine Multi-Factor Authentication auch mit Passwort und Zertifikat realisiert werden. Bei SSH z.B. mit Passwort und RSA Key, im Web mit Passwort und x509 Zertifikaten. Im Nachfolgenden wird aber auf One-Time Passwörter und Challenge-Response Verfahren eingegangen, welche eine zusätzliche Hardware-Komponente voraussetzen. Die Idee dabei ist, dass ein Passwort (den Faktor Wissen) und eine Hardware (den Faktor Besitzen) im Spiel sind was den einfachen Diebstahl verhindert.

FIDO U2F

FIDO U2F ist ein sehr junges Protokoll, welches auf public Key Kryptographie aufbaut. Ein nativer Support im Browser (aktuell nur in Chrome / Chromium und per Addon in Firefox) ist Voraussetzung. Theoretisch kann es auch für SSH und andere Dienste verwendet werden. Auch hier ist die Voraussetzung, dass die Programme dies nativ unterstützen. Entsprechende Patches für den OpenSSH Client sind bereits verfügbar.
Nach erfolgreicher Authentifizierung per Passwort oder Zertifikat, schickt der Server dem Client eine einmalige Challenge worauf der Client dem Server eine, mit dem eigenen privaten Key signierte Response, zurück schickt.

OATH

Bei OATH gibt es zwei Protokolle, der Time-based One-time Password Algorithm TOTP (RFC6238) und der HMAC-based One-time Password Algorithm HOTP (RFC4226).

Zuerst wird ein Shared Secret zwischen Server und Client ausgetauscht. Oft wird dies durch einen QR-Code realisiert.

TOTP

Bei TOTP wird die Uhrzeit als Basis genutzt. Die Voraussetzung ist, dass bei Server und Client die Uhrzeit synchronisiert ist.
Der Authentication Code wird mit folgender Funktion generiert: HMAC(sharedSecret, timestamp) und ist für 30 Sekunden gültig.

HOTP

HOTP funktioniert gleich wie TOTP, nutzt aber an Stelle der Uhrzeit einen Counter, welcher Server- und Client-Seitig immer synchron sein müssen.
Der Authentication Code wird durch folgende Funktion generiert: HMAC(sharedSecret, counter) und ist für das nächste Login gültig (Zeitunabhängig).

One-Time Passwort (OTP)

One-Time Passwörter (OTP) sind ein einfaches Verfahren von Yubico, welches im Hintergrund zusätzliche Infrastruktur benötigt. Nach erfolgreicher Authentifizierung per Passwort oder Zertifikat, verlangt der Server noch ein OTP. Wird dieses gesendet, muss es der Server an einen Validation-Server weiterleiten für die Überprüfung der Einmaligkeit.

Drei OTPs sehen vom selben Yubikey zum Beispiel wie folgt aus:
<b>rjvrllbbckhe</b>flnbdhnbdgluhedfneecjrluudknuecu
<b>rjvrllbbckhe</b>nrvblgfvkcbdhbtnjegvdicnhcutundg
<b>rjvrllbbckhe</b>lvrdjdrjccrvkrlbiijictlullglfglj
Die ersten 12 Zeichen der Sequenz sind dabei der Publicname und die restliche Sequenz wird anhand eines AES-Keys und einem Counter generiert. Der AES-Key muss dabei dem Yubikey und dem Validation-Server (spezifisch dem yubikey-ksm) bekannt sein.
Bei jedem OTP wird der Counter mitgegeben, damit der Server seinen Counter synchronisieren kann.

Validation-Server

Die Validation-Server Software von Yubico yubikey-val und yubikey-ksm kann unkompliziert selber gehostet werden. Man kann aber auch die YubicoCloud, welche von Yubico selber gehostet und angeboten wird, verwenden.
Bei kritischer Infrastruktur ist das selber hosten Sicherheitstechnisch sicher sinnvoller. Dabei geht es weniger um den Datenschutz, sondern eher um die Verfügbarkeit. Wenn, als Beispiel, die Internet Anbindung unterbrochen wird und für die Reparatur der Firewall ein Login über Two-Factor Authentifizierung mit OTP nötig wäre, ist man in einem deadlock und hat keine Verbindung zum Internet mehr.

Stellen Sie sich vor, Sie erhalten ein Login auf einem Unixrechner, der auf einer esoterischen Hardware läuft. Auf diesem Rechner finden Sie ein 10-mloc C++/C/Java-Projekt, mit vielen einsatzspezifischen Sprachen und Dateiformaten.
Sie dürfen den Quellcode nicht auf Ihren Rechner kopieren, da dieser dem Kunden gehört. Sie dürfen den Quellcode anpassen und auf dem Rechner kompilieren. Sie dürfen nichts installieren.

Wie soll man sich hier zurechtfinden? Sie können grep versuchen, aber Sie werden an Alterschwäche sterben, bevor Sie alle Stellen gefunden haben, wo das Symbol, für das Sie sich interessieren, vorkommt. Vielleicht haben Sie Glück und GNU-Idutils ist installiert, aber natürlich kommt das Symbol auch in Dateien vor die Idutils nicht kennt und nicht indexiert.

Aber glücklicherweise finden Sie auf dem Rechner Python 2.6 und Sie können die Hilfe eines Ninja in Anspruch nehmen.

Und ja, solche Dinge kommen bei uns vor.

Finja

Finja ist ein Indexer der nur Python 2.6+ (3.4+) benötigt. Anders als viele der grossartigen Alternativen zu Finja, ist Finja generisch. Es weiss nicht, was es indexiert. Finja erreicht gute Qualität durch mehrere Durchgänge in denen der Text auf unterschiedliche Art in Tokens zerlegt wird. Deshalb ist es langsamer und der Index ist grösser als bei spezialisierten Indexern, aber es indexiert Ihren Kram und lässt keine unbekannten Dateien aus.

Finja Benutzen

Ich rufe finja -i im Verzeichnis in dem ich diesen Artikel schreibe auf.

$> finja -i
Makefile: indexed 87/147 (0.592) new: 38 UTF-8
finja-blog.html: indexed 4370/10492 (0.417) new: 1126 UTF-8
finja-blog.rst: indexed 487/1517 (0.321) new: 73 UTF-8
Indexing done

Im Makefile hat es 87 einmalige Tokens gefunden. Tatsächlich hat es in allen Durchläufen 147 Token gefunden, im ersten Durchlauf benutzt es zum Beispiel Leerzeichen als Trennzeichen, in einem zweiten Durchlauf benutzt es Satzzeichen der natürlichen Sprache als Trennzeichen und im dritten Durchlauf benutzt Finja Trennzeichen die in gängigen Programmiersprachen vorkommen. Damit zeigt 0.592 den Zusatzaufwand durch die Durchläufe an (1.0 wäre perfekt, tiefer Kennzahlen sind schlechter). Es hat 38 neue Tokens gefunden und UTF-8 als Kodierung der Datei erkannt. Jawohl, Finja kann die Kodierung erkennen. Um die Effizienz zu steigern, nimmt Finja einfach an, dass die Datei in UTF-8 kodiert ist. Erst wenn es zu einem Dekodierungsfehler kommt, wird die Kodierung detektiert.

Jetzt möchte ich ein paar Ninjas finden.

$> finja ninja
.:
finja-blog.html:    7:<title>Finja - Your friendly finding ninja</title>
finja-blog.html:  696:<div class="document"
finja-blog.html:  697:<h1 class="title">Finja - Your friendly finding ninja</h1>
finja-blog.rst:    1:Finja - Your friendly finding ninja
finja-blog.rst:   16:a ninja.

Die Resultate aus der HTML-Datei interessieren mich nicht.

$> finja -p html ninja
.:
finja-blog.rst:    1:Finja - Your friendly finding ninja
finja-blog.rst:   16:a ninja.

Wir finden also im Order ‘.’ Ninja zwei mal auf Linie 1 und 16. Aber halt, dass ist nicht aktuell.

$> finja -u
finja-blog.rst: indexed 939/2897 (0.324) new: 111 UTF-8

Mit finja -u werden nur Dateien die sich verändert haben neu indexiert.

$> finja -p html ninja
.:
finja-blog.rst:    1:Finja - Your friendly finding ninja
finja-blog.rst:   16:a ninja.
finja-blog.rst:   61:   $> finja ninja
finja-blog.rst:   63:   finja-blog.html:    7:<title>Finja - Your friendly
finja-blog.rst:   65:   id="finja-your-friendly-finding-ninja">
finja-blog.rst:   66:   finja-blog.html:  697:<h1 class="title">Finja - Your
finja-blog.rst:   67:   finja-blog.rst:    1:Finja - Your friendly finding ninja
finja-blog.rst:   68:   finja-blog.rst:   16:a ninja.
finja-blog.rst:   74:   $> finja -p html ninja
finja-blog.rst:   76:   finja-blog.rst:    1:Finja - Your friendly finding ninja
finja-blog.rst:   77:   finja-blog.rst:   16:a ninja.

“Yo dawg, I hear you like searching ninjas, we put ninjas in your search, so you can search ninjas while you search.” Hmm, das Resultat ist etwas Rekursiv, aber wir haben bewiesen, dass der Index aktualisiert wurde.

Wir können auch in Unterverzeichnissen suchen:

$> cd dir/
$> finja -u -p html punctuation
..:
finja-blog.rst:   51:second pass it uses punctuation marks from natural

SQLite kann Ihr Freund sein

Natürlich haben wir mit einem 10 mloc Projekt schnell Leistungsprobleme gefunden. Es stellt sich heraus, dass der Anfrageoptimierer von SQLite dumm ist, dumm ist das richtige Wort, den er ist nicht schlecht, aber nicht so ausgeklügelt wie wir es uns von PostgreSQL gewohnt sind. Standardmässig wird keine Histogrammanalyse gemacht und deshalb werden die Tabellen in einer schlechten Reihenfolge vereinigt. Jedoch wenn man SQLite mit SQLITE_ENABLE_STAT4 kompiliert, was Histogrammanalyse aktiviert, werden die Tabellen immer noch in einer schlechten Reihenfolge vereinigt. Ich mache SQLite keinen Vorwurf, es ist eben nicht PostgreSQL. Wir haben die Anfragen also in Finja optimiert.

SELECT
    COUNT(id) count
FROM
    finja
WHERE
    token_id = ?

Wir überprüfen zu erst wie oft ein Token im Index vorkommt, also sozusagen eine manuelle Histogrammanalyse. Dann vereinigen wir den Index mit dem seltensten Token zuerst.

def search_term_cardinality(term_id):
    db         = get_db(create = False)
    con        = db[0]

    curs = con.cursor()
    res = curs.execute(_token_cardinality, [term_id]).fetchall()
    return res[0][0]

def order_search_terms(search):
    res = sorted(search, key=search_term_cardinality)
    return res

Dies basiert natürlich auf der Annahme, dass die Tokens über mehrere Dateien und Zeilen verteilt sind. Wenn es eine Datei gibt in der sich das Token auf der selben Zeile eine Million mal wiederholt, werden wir eine falsche Entscheidung treffen. Aber in den meisten Fällen ist es viel besser als SQLite entscheiden zu lassen.

Schlusswort

Bitte installieren Sie Finja, nutzen es und falls Sie ein Problem finden eröffnen Sie doch bitte ein Ticket auf Github.

Besten Dank!