Personal Blog

ASN Based DNS Routing

2022-05-26T00:00:00+00:00

DNS Basiertes Routing

Um seine Services und Dienste Carrier und ISP übergreifend mit der best möglichen Performance dem Endkunden anzubieten. Ist es unerlässlich, seine Server netzwerktechnisch so nah wie möglich an den Kunden heranzubringen.

Um trotz der vielen verteilten Knoten einen Zentralen anlaufpunkt zu behalten ist hier der Einsatz von DNS unerlässlich. Um nun herauszufinden, welcher Knoten dem Kunden am nächsten Gelegen ist, entscheidet der DNS Server beim Eingang einer DNS Anfrage aufgrund der Source IP. Anhand der IP-Adresse lassen sich Informationen wie Netzbetreiber, das Land und die ungefähre Lokation herausfinden.

Mithilfe diese Kriterien lassen sich Regeln definieren die als Entscheidungsgrundlage für die DNS Antwort dienen.

Konfiguration

Als DNS Server für diesen Aufbau dient der OpenSource GeoDNS Server.

Dieser DNS Server wird auf vom NTP Pool Projekt, für das Load Balancing der NTP Anfragen verwendet.

Für die Installation muss das Repository eingebunden werden:

deb [trusted=yes] https://repo.fury.io/ntppool/ /

Danach kann der GeoDNS Server installiert werden:

apt update && apt install geodns

Im Anschluss kann der GeoDNS Server konfiguriert werden. Die nötigen Konfigurationsdateien müssen manuell angelegt werden:

mkdir /etc/geodns

Die Konfigurationsdatei mit dem Standardinhalt unter /etc/geodns/geodns.conf Anlegen.

; GeoDNS configuration file
;
; It is recommended to distribute the configuration file globally
; with your .json zone files.

[geoip]
;; Directory containing the GeoIP2 .mmdb database files; defaults
;; to looking through a list of common directories looking for one
;; of those that exists.
;directory=/usr/local/share/GeoIP/

[querylog]
;; directory to save query logs; disabled if not specified
path = log/queries.log
;; max size per file in megabytes before rotating (default 200)
; maxsize = 100
;; keep up to this many rotated log files (default 1)
; keep = 2

[http]
; require basic HTTP authentication; not encrypted or safe over the public internet
; user = stats
; password = Aeteereun8eoth4

[health]
; directory = dns/health

GeoIP Datenbanken

Um die eingehenden Source IPs nach Herkunft usw. klassifizieren werden die Datenbanken mit den entsprechenden Informationen benötigt.

Diese können hier heruntergeladen werden. https://github.com/P3TERX/GeoLite.mmdb/

Und entsprechend im Ordner /usr/local/share/GeoIP/ gespeichert werden.

DNS Zonen Konfiguration

Um eine Trennung nach ASN Nummern durchzuführen, muss die Zonen Datei wie folgt aufgebaut werden.

{
    "serial": 3,
    "ttl": 600,
    "max_hosts": 2,
    "logging": {},
    "targeting": "country continent @ regiongroup region ip asn",
    "contact": "abuse@example.net",
    "data": {
        "": {
            "ns": [
                "ns1.example.net",
                "ns2.example.net"
            ]
        },
        "www.as3320": {
            "cname": "www.fsn1.example.net.",
            "ttl": 600
        },
        "www": {
            "cname": "www.stg.example.net.",
            "ttl": 600
        }
    }
}

Im obrigen Zonen File bekommen alle Anfragen aus dem DTAG (Deutsche Telekom AG) Netz die CNAME Adresse www.fsn1.example.net als Antwort zurück.

Alle übrigen Anfragen aus anderen Netzwerken bekommen die Adresse www.stg.example.net als Antwort zurück.

DNS Abstraktion

Da DNS ein sehr kritischer Dienst ist und durch eine mögliche CMANE Verkettung bei einem Ausfall auch noch andere Services oder Systeme lahnlegen kann. Empfiehlt es sich hier dem GeoDNS Server nur eine Subdomain zur Verwaltung zu delegierten und nicht gleich die ganze root Domainebene @.

Um dem GeoDNS Server eine Subdomain zu delegierten muss im haupt DNS ein NS Record hinzugeführt werden.

geodns.example.net.	1	IN	NS	ns1.example.net.

In diesem Record wird die Subdomain *.geodns.example.net ab sofort vom DNS Server ns1.example.net verwaltet. Somit werden alle DNS Anfragen wie z.B. srv1.geodns.example.net an den Nameserver ns1.example.net weitergeleitet.

Bei diesem Setup wären durch einen eventuellen Ausfall des NS1 Nameservers nur die geodns Subdomain betroffen.

SQL Transactions

2022-04-16T00:00:00+00:00

SQL Transaktionen

SQL Transaktionen bilden einen Verbund aus mehreren SQL-Statements, die in direktem Zusammenhang stehen. Beispielsweise bei einer Bestellung hier wäre es von Nöten, Einträge in der Tabelle, Bestellungen und Produkte zu erstellen.

Da dies in separaten SQL Statements passiert, diese aber direkt voneinander abhängig sind, könnte es durch einen Fehler in einen der SQL-Statements zu einem inkonsistenten Zustand der Datenbank kommen.

Um dies zu verhindern, werden Transaktionen eingeführt. In Transaktionen werden mehrere voneinander anhängige SQL Statements zusammengefasst. Sollte die Ausführung eines Statements in einer Transaktion fehlschlagen, werden alle bis dahin durchgeführten Änderungen auf der Datenbank rückgängig gemacht. Somit wird verhindert, dass es hier zu einem inkonsistenten Zustand in der Datenbank kommen kann.

Transaktionen sind nach dem ACID-Prinzip aufgebaut. Dies bedeutet, sie besitzen Atomarität, sollte die Transaktion abgebrochen werden, hinterlässt diese keine Änderungen auf dem System. Transaktionen sind konsistent nach dem Commit oder Rollback ist die Datenbank in einem Konsistenten zustand ohne Anomalien oder Redundanzen. Transaktionen sind voneinander isoliert, sie können sich gegenseitig nicht beeinflussen. Transaktionen sind dauerhaft, sie speichern Daten nach erfolgreicher Ausführung persistent ab.

Aufbau einer Transaktion

Start der Transaktion
```
 START TRANSACTION;
```

Ausführen der SQL Statements

 SELECT
     CompanyName
 FROM 
     products p, suppliers s
 WHERE 
     p.SupplierID = s.SupplierID
 AND 
     p.ProductID = 14;

Abschliesen der Transaktion
```
 COMMIT;
```

Rollback

Durch einen Rollback, werden die Änderungen, die in der Transaktion ausgeführt wurden, rückgängig gemacht.

Dies bedeutet, dass die Änderungen, die in einer Transaktion ausgeführt werden, bis zum COMMIT oder ROLLBACK nur in der aktuellen Session bestehen und keine persistenten Auswirkungen auf die Daten haben.

Zum Rollback wird anstatt COMMIT das ROLLBACK Statement ausgeführt.

ROLLBACK;

Savepoints

Sogenannte Savepoints sind Zwischenergebnisse in einer Transaktion. Sie legen fest, bis wohin bei einem Rollback Änderungen zurückgesetzt werden sollen.

Um einen Savepoint anzulegen, genügt es innerhalb einer Transaktion den Befehl und einen Namen für den Savepoint abzusetzen.

SAVEPOINT xyz;

Um zu einem solchen Savepoint zurückzuspringen, muss das Rollback Statement mit dem Zusatz des Savepointnamens aufgerufen werden.

ROLLBACK xyz;

Java JDBC Implementierung

public static void executeTransaction(Connection con) {
    /*
     Create SQL Statement
    */
    try(Statement stmt = con.createStatement();) {
        con.setAutoCommit(false);
        stmt.executeUpdate("INSERT INTO categories(CategoryID, CategoryName, Description) VALUES(3, 'Sweets', 'Desserts and candies')");
        /*
            Create Savepoint
        */
        Savepoint save = con.setSavepoint();
        stmt.executeUpdate("INSERT INTO products(ProductName, SupplierID, CategoryID, QuantityPerUnit, UnitPrice, UnitsInStock, UnitsOnOrder, ReorderLevel, Discontinued) VALUES('Lakritz', 14, 3, 10, 1.2, 100, 0, 10, 0)");
        /*
            Rollback Changes to Savepoint
        */
        con.rollback(save);
        /*
            Commit Changes
        */
        con.commit();
        System.out.println("Transaction succeeded.");
    }
    catch (SQLException ex) {
        ex.printStackTrace();
        try {
            System.out.println("Transaction failed.");
            con.rollback();
        }
        catch (SQLException se) {
            se.printStackTrace();
        }
    }
}

Pure SQL Implementierung

START TRANSACTION;

SET AUTOCOMMIT = OFF;

SELECT 
    @categoryID:=MAX(CategoryID)+1
FROM
    categories;

INSERT INTO categories
    (CategoryID, CategoryName, Description)
VALUES
    (@categoryID, 'Sweets', 'Desserts and candies');

SAVEPOINT s_category;

INSERT INTO products
    (ProductName, SupplierID, CategoryID, QuantityPerUnit, UnitPrice, UnitsInStock, UnitsOnOrder, ReorderLevel, Discontinued)
VALUES
    ('Lakritz', 14, 3, 10, 1.2, 100, 0, 10, 0);

COMMIT;

Optionen

Die bei MySQL als Standard gesetzte Option AUTOCOMMIT speichert nach erfolgreicher Ausführung der Transaktion die Daten in der Datenbank persistent ab.

Um dies abzuschalten, muss in einer Transaktion das folgende Statement enthalten sein, damit wird es nötig, das speichern der Daten manuell zu veranlassen.

SET AUTOCOMMIT = OFF;

Isolations Level

Das Isolationslevel hat keine Auswirkung auf die Sperrung der Datenbank, die durch die eigene Transaktion verursacht wurde. Vielmehr legt es das Verhalten fest, wie auf andere laufende Transaktionen reagiert werden soll.

So ist z. B. bei dem Isolationslevel READ UNCOMMITTED ganz egal, ob die von einer anderen Transaktion gerade bearbeitete Tabelle noch nicht vollständig beschrieben ist. So wird die Transaktion dennoch ausgeführt es kann hier unter Umständen zu Inkonsistenten kommen. Dies wird auch als dirty read bezeichnet.

Im Gegenzug werden aber nicht viele Systemressourcen benötigt, da weder ein Lock noch eine revisionssichere Verarbeitung nötig ist.

Dieses Isolationslevel sollte daher nicht eingesetzt werden, höchstens bei Daten, deren Konsistenz keine Priorität haben.

READ COMMITTED gibt, an das nur Daten verarbeitet werden können, die momentan nicht von anderen Transaktionen verwendet werden. Dabei versucht die Datenbank nur so wenig Entitäten wie nötig zu sperren.

Dies geschieht mit einer Mischung aus Index und Row Locks. Hintergrund ist, dass es ansonsten zu Phantom Einträgen in der Datenbank können könnte. Beider neue Datensätze zwischen den in der Transaktion angefragten Datensätze eingeschleust werden könnten. Somit wären dann in zwei zeitlich voneinander getrennten SELECT Statements jeweils zwei unterschiedliche Datensätze zurückgegeben worden.

Bei UPDATE und DELETE Statements werden die Locks auf die Datenbank durch die parallele Auswertung der WHERE Klausel neben der Ausführung des Queries reduziert indem nicht zu bearbeitende Entitäten werden wieder freigegeben. Dies hat den Hintergrund, die Wahrscheinlichkeit von Deadlocks zu verringern.

Deadlocks treten auf, wenn zwei Transaktionen auf den Abschluss der jeweils anderen Transaktion warten. Da dies aber nicht eintreten wird, da sich die beiden Transaktionen gegenseitig sperren, spricht man in diesem Zusammenhang von einem Deadlock.

Bei REPEATABLE READ werden nur die Datensätze gesperrt, die durch eine eindeutige Suche dem Statement zugeordnet werden können.

Bei der SERIALIZABLE Isolationsstufe können keine Daten gelesen werden, für die noch ein Commit Statement aussteht, auch können andere Transaktionen erst auf die Daten zugreifen, wenn die aktuelle Transaktion vollständig abgeschlossen ist.

Eine Übersicht der einzelnen Isolationsstufen und deren Eigenschaften:

Isolationsstufe	Dirty Read	Non-Repeatable Read	Phantom
Read Uncommitted	Ja	Ja	Ja
Read Committed	Nein	Ja	Ja
Repeatable Read	Nein	Nein	Ja
Serializable	Nein	Nein	Nein

Einführung Docker

2022-04-11T00:00:00+00:00

Docker Container Plattform

Docker ist ein Open Source-Projekt zur Automatisierung der Bereitstellung von Apps als mobile, eigenständige Container, die in der Cloud oder lokal ausgeführt werden können. Docker ist darüber hinaus ein Unternehmen, das diese Technologie fördert und weiterentwickelt und mit Cloud-Anbietern, Linux und Windows kompatibel ist.

Dabei stellen Container eigenständige und abgeschottete Laufzeitumgebungen für Anwendungen verschiedenster Art dar. Container und die dazugehörigen Container Images basieren auf dem OCI (Open Container Initiative) Standard und sind somit nicht nur mit Docker kompatiebel. Docker ist vielmehr nur das zugehörige Verwaltungswerkzeug, um die darunterliegende Container Infrastruktur zu verwalten. Docker bietet dabei die Möglichkeiten, Container anzulegen, zu starten / stoppen oder zu löschen. Es können neue Images erstellt und bestehende Images verwaltet werden, lokal oder remote in sogenannten Container Registries (z.B. hub.docker.com)

Containervirtualisierung

Containervirtualisierung beschriebt eine Form der Virtualisierung beider auf dem Host System mittels PID Namespacing im Linux-Kernel eine eigene Laufzeitumgebung geschaffen wird. Inder Anwendungen abgeschottet vom restlichen System betrieben werden können.

Der Vorteil dieser Virtualisierungesmethode, ist der um ein Vielfaches verringerter Overhead im Vergleich zu KVM. Da bei einer Container Virtualisierung im direkten Vergleich der Kernel des Host OS verwendet wird und die Ressourcen des Systems nur abstrahiert und nicht virtualisiert werden.

Somit kann bei Containern auf ein eigenes Betriebssystem im klassischen Sinne verzichtet werden. Es muss lediglich eine Laufzeitumgebung mitgegeben werden, um die entsprechende Anwendung ausführen zu können. Somit kann die Hardware optimal ausgenutzt und der Wartungsaufwand deutlich reduziert werden.

Technologien, die auf diese Art der Virtualisierung zurückgreifen, sind. LXC und OCI Container.

Bei LXC Containern wird ein leichtgewichtiges Linuxsystem erzeugt, das über traditionelle Methoden administriert / verwaltet wird z.B. SSH.

OCI Container verfolgen einen anderen Weg, hier geht es darum, sehr leichtgewichtige System für die Cloud bereitzustellen. Hier liegt der Fokus auf Sicherheit, Performance und Fehlerminimierung.

Die Container sind weitergehend dazu auch im Hinblick auf die 12 Faktoren im Cloudumfeld designet, sie sind vorzugsweise Stateless, skalierbar und im Fehlerfall schnell austauschbar. Eine manuelle Fehlerbehebung eines einzelnen “bad” Containers ist hier nicht vorgesehen. Vielmehr werden die Container einfach schnell gegen einen neuen funktionsfähigen Container ausgetauscht.

Gerade im Hinblick auf Kubernetes, ist diese Art der Containerverwaltung die Grundlage eines solchen Konzepts.

Moby Project

Das Moby Projekt zu finden auf Github, stellt die Library dar, die von Docker für die Interaktion mit dem System verwendet wird. Hier ist z.B. der Image Build Prozess abgebildet.

ContainerD

ContainerD ist eine OCI standardisierte Container Laufzeitumgebung. Diese ist für den eigentlichen Betrieb der Container verantwortlich und steuert diesen eigenständig.

containerd is an industry-standard container runtime with an emphasis on simplicity, robustness and portability. It is available as a daemon for Linux and Windows, which can manage the complete container lifecycle of its host system: image transfer and storage, container execution and supervision, low-level storage and network attachments, etc.

Zu finden ist das Projekt bei Github

OCI - Open Container Initiative

Die Open Container Initiative verabschiedet Standards im Bereich Containering. Darunter fallen die Spezifikationen der Container und deren Images, damit diese zu den verschiedenen Systemen interkompatibel sind.

runc

runc is a CLI tool for spawning and running containers on Linux according to the OCI specification. Wird von Docker im Hintergrund verwendet, um Container anzulegen und zu verwalten. Zu finden auf Github

Docker Image Erstellen

Um ein Docker Image zu erstellen, wird mit sogenannten Dockerfiles das Image definiert. Dieses Dockerfile wird dann dem Build Agent übergeben, der dann aus dem übergebenen Dockerfile ein OCI Container Image erstellt.

In der Regel sind Dockerfiles in 3 Bereiche aufgeteilt.

Import: Hier werden OS Images (Debian, Alpine, Ubuntu, …) angegeben bzw. Base Images (Frameworks wie Java, dotNet, NodeJS oder Python) damit wird die Laufzeitumgebung festgelegt.

Installation: Hier wird die Installationsroutine der Software angegeben z.B. Download von Artefakten oder Kompilierung der Software.

Entrypoint: Hier wird der Startpunkt der Anwendung festgelegt.

Ein beispielhaftes Dockerfile sieht in etwa so aus:

FROM alpine:3.4

RUN apk update && apk add \
    curl \
    git \
    vim

RUN wget http://myapp.com/run && chmod +x run

ENTRYPOINT['run']

Im Anschluss kann dann das Dockerfile zu einem Image gebaut werden docker build .

Docker Image Verwaltung

Anzeigen der lokal geladenen Images

  [root@host ~]$ docker image ls
  REPOSITORY                   TAG       IMAGE ID       CREATED         SIZE
  ngoduykhanh/powerdns-admin   latest    938d8ef921ab   5 months ago    157MB
  psitrax/powerdns             latest    720c44942097   6 months ago    63.7MB
  redis                        latest    08502081bff6   6 months ago    105MB
  mariadb                      latest    104f4e7cbe83   6 months ago    408MB
  ubuntu                       latest    7e0aa2d69a15   8 months ago    72.7MB
  freinet/powerdns             latest    8fdce2cafa4e   12 months ago   55.5MB
  jorgedlcruz/zimbra           latest    79403a039239   4 years ago     302MB

Löschen eines Images

  [root@host ~]$ docker image rm 79403a039239
  Untagged: jorgedlcruz/zimbra:latest
  Untagged: jorgedlcruz/zimbra@sha256:5d2548365fd079ba51e87c7a8f54feacfce23d370f49d66311632eb2a422b026
  Deleted: sha256:79403a039239add5f60084f7ff2203fe145b3f8f86e83a925359e06e38cb437f
  Deleted: sha256:c07d6c55520b0908e868f8a85d2b8928616008a8c26d27bd61f425ce1a2058c6
  Deleted: sha256:e2a75e141e320208ce68299d7f72e1fe46a1c9b8a5702256ea45ef94ae80cca0
  Deleted: sha256:1f0250b6692ee176c5e1978ee2aa921d724873b9c5fa8ec19be04c640660393d
  Deleted: sha256:7f6e10c2ecea8d277d1a8c7c618e7dd93e5e0357e68d6e88f1f1ab26de03e59a
  Deleted: sha256:ec1fd849ff0a8f0aa2fd1acc29ad5dabbc79b89f63b74a4f54e31a7b0a100aa1
  Deleted: sha256:e3f6dffa20cf36460d23bfb22e17be6e5339891f8537f32db79887caf832048b
  Deleted: sha256:c213ffdc9f7032702de5a8e9045fcce2353b7221ef6bf4509e02005cfc858f58
  Deleted: sha256:3fddf55a451aa43707518f2d8788c12ee5eb1f1e3075433f5bcf4d445d5c275d
  Deleted: sha256:0f5ff0cf6a1c53f94b15f03536c490040f233bc455f1232f54cc8eb344a3a368

Herunterladen eines neuen Images

  [root@host ~]$ docker pull alpine:latest
  latest: Pulling from library/alpine
  59bf1c3509f3: Pull complete 
  Digest: sha256:21a3deaa0d32a8057914f36584b5288d2e5ecc984380bc0118285c70fa8c9300
  Status: Downloaded newer image for alpine:latest
  docker.io/library/alpine:latest

Docker Container Verwaltung

Auflistung der Container in auf dem System

  [root@host ~]$ docker container ls -a
  CONTAINER ID   IMAGE                               COMMAND                  CREATED        STATUS                      PORTS      NAMES
  5793bbed585b   mariadb:latest                      "docker-entrypoint.s…"   28 hours ago   Exited (0) 21 hours ago                elastic_agnesi
  13102f675ad0   mariadb:latest                      "docker-entrypoint.s…"   3 months ago   Up 2 hours                  3306/tcp   docker-db-1
  0e98170a7024   ngoduykhanh/powerdns-admin:latest   "entrypoint.sh gunic…"   3 months ago   Exited (0) 3 months ago                powerdns_admin
  a0f8b16bc64a   psitrax/powerdns:latest             "/entrypoint.sh"         3 months ago   Exited (143) 3 months ago              powerdns
  cc6847b3c8a9   ubuntu                              "bash"                   6 months ago   Exited (0) 6 months ago                recursing_mendeleev
  7fc041db6bc6   redis:latest                        "docker-entrypoint.s…"   6 months ago   Exited (0) 6 months ago                lucid_kepler
  be47035dd9d3   mariadb:latest                      "docker-entrypoint.s…"   6 months ago   Exited (0) 2 months ago                mariadb

Mit dem -a Parameter lassen sich auch die abgeschalteten Container anzeigen.

Starten neuer Container

Im Beispiel: Startet einen Nginx Container auf Port 8080

docker run -d -p 8080:80/tcp --name=webserver --restart=always nginx:latest

Die verwendeten Parameter Parameter | Funktion | ——– | ——– | -d | Container im Hintergrund Starten -p 8080:80/tcp | TCP Portfreigabe von 8080 extern nach 80 intern –name | Namen des Containers festlegen –restart=always | Setzt die Restart Policy auf immer starten

Genauere Infos und Referenzen in der Docker Dokumentation

Löschen eines Containers

docker container rm -f 5793bbed585b

Container ID oder Container Name

Verwendeter Paramerter -f (Force) Löscht den Container auch im aktiven Zustand.

Vorhandenen Container Starten / Stoppen / Neustarten

Starten
```
  docker container start [ContainerID]
```
Stoppen
```
  docker container stop [ContainerID]
```

Neustarten

  docker container restart [ContainerID]

Docker Compose

Docker Compose ermöglicht es, mehrere Container in einem Deployment zusammenzufassen und die Ressource in diesem Deployment gegenüber anderen Containern abzuschirmen, die dafür notwendigen Schritte werden alle automatisch von Docker Compose übernommen.

Docker Compose benötigt eine sogenannte docker-compose.yml Datei, diese Datei enthält die Konfiguration des Deployments. Durch Docker Compose werden die folgenden Ressourcen verwaltet:

Container
Overlaynetzwerke
Volumes

Ein typisches Usecase für Docker Compose wäre eine Webanwendung, bei der eine Datenbank, ein Webserver und ein Anwendungsserver benötigt werden. Dabei steuert Docker Compose die Erstellung der Container und deren persistenten Daten, die Erstellung eines Cloudnetzwerks sowie die automatische Zuweisung des Netzwerks an die Container.

Die docker-compose.yml für den oben beschriebenen Usecase sieht wie folgt aus:

version: "3.9"
    
services:
  db:
    image: mysql:5.7
    container_name: db
    volumes:
      - db_data:/var/lib/mysql
    restart: always
    environment:
      MYSQL_ROOT_PASSWORD: dbpasswd
      MYSQL_DATABASE: db
      MYSQL_USER: db
      MYSQL_PASSWORD: db
    
  proxy:
    image: nginx:latest
    container_name: proxy
    restart: always
    volumes:
      - ./nginx.conf:/etc/nginx/nginx.conf
      - ./nginx/error.log:/etc/nginx/error_log.log
      - ./nginx/cache/:/etc/nginx/cache
      - ./ssl/:/etc/letsencrypt/
    ports:
      - 80:80
      - 443:443
  app:
    depends_on:
      - db
      - proxy
    image: registry/myapp
    restart: always
    environment:
       DBL_USER: db
       DB_PASSWORD: db
       DB_HOST: db
    container_name: app
    ports:
        - 3000:3000
volumes:
  db_data: {}

Die Nginx Konfiguration muss noch entsprechend als Reverse Proxy auf den app Container angepasst werden.

Docker Volumes

Docker Volumes bieten die Möglichkeit, anfallende persistente Daten in einem Container zu speichern. Volumes werden komplett durch Docker verwaltet und sind damit der offiziell empfohlene weg persistente Daten abzuspeichern.

Anzeigen bestehender Volumes

  C:\Users\Markus>docker volume ls
  DRIVER    VOLUME NAME
  local     256895275dee26176790078f8470e124671e3f74abf7fb5f84e36aaa8f8e6a78
  local     c3687c2c12df99cfcbb6b725d57facf0e678ae776fdd6009009b7571ca1968cb
  local     telly.config.toml
  local     vscode

Anlegen eines neuen Volumes
```
  docker volume create data
```

Docker bietet auch die Möglichkeit, andere Storage Driver anzusprechen. Somit ist es möglich, die Volumes auf anderen Storage Medien zu speichern. Von Haus aus unterstützt Docker die folgenden Storage Drivers:

Eine Liste mit eingebauten Storage Drivern
Eine Liste mit 3rd-party Storage Drivern

Docker Networking

Um die Container untereinander zu vernetzen, bietet Docker die Möglichkeit, über Bridges auf dem Hostsystem Container miteinander zu verbinden.

Auflisten aller Netzwerke auf dem Host

  C:\Users\Markus>docker network ls
  NETWORK ID     NAME      DRIVER    SCOPE
  fa8c5ca426e1   bridge    bridge    local
  f9f00956c91d   host      host      local
  679b81f531b8   none      null      local

Anlegen eines neues Netzwerks
```
  docker network create --driver bridge new-network
```
Mit dem Parameter --driver | -d kann der Netzwerk Driver angegeben werden.

Konfiguration der Standard Bridge auslesen

  C:\Users\Markus>docker network inspect bridge
  [
      {
          "Name": "bridge",
          "Id": "fa8c5ca426e18372730c1dce298ddf97862c8574cf2e71e58ed9f5a584948158",
          "Created": "2022-01-12T14:58:18.607125133Z",
          "Scope": "local",
          "Driver": "bridge",
          "EnableIPv6": false,
          "IPAM": {
              "Driver": "default",
              "Options": null,
              "Config": [
                  {
                      "Subnet": "172.17.0.0/16",
                      "Gateway": "172.17.0.1"
                  }
              ]
          },
          "Internal": false,
          "Attachable": false,
          "Ingress": false,
          "ConfigFrom": {
              "Network": ""
          },
          "ConfigOnly": false,
          "Containers": {},
          "Options": {
              "com.docker.network.bridge.default_bridge": "true",
              "com.docker.network.bridge.enable_icc": "true",
              "com.docker.network.bridge.enable_ip_masquerade": "true",
              "com.docker.network.bridge.host_binding_ipv4": "0.0.0.0",
              "com.docker.network.bridge.name": "docker0",
              "com.docker.network.driver.mtu": "1500"
          },
          "Labels": {}
      }
  ]

Bei einem durch Docker verwalteten Netzwerk erfolgt die IP-Adressvergabe eigenständig durch Docker. Ebenso wie eine DNS Namensvergabe jeder Name eines Containers ist im Docker Netzwerk per DNS auflösbar. Somit ist es möglich, Container nach ihrem Namen im Netzwerk aufzurufen.

Es existieren auch noch einige andere Netzwermodelle, diese können hier eingesehen werden.

Mit Docker Swarm, lassen sich mehrere Docker Dienste zu einem Verbund zusammenschalten und somit können die Container auch Hostübergreifend miteinander kommunizieren.

Übersicht Overlay Netzwerke: https://docs.docker.com/network/overlay/

Beispielkonfiguration: https://docs.docker.com/network/network-tutorial-overlay/

Container Orchestrierung

Mit Container Orchistration lassen sich die Container in Clustern organisieren. In diesem Modus wird ein Cluster aus mehreren Containern einer Anwendung erstellt. Dieses Cluster ist dank Hostübergreifenden Netzwerk und Speicher in der lage eine Hochverfügbare Clusterumgebung zu schaffen.

In dieser konstelation ist der einzelne Container nicht mehr von großer bedeutung, dieser kann durch die Beachtung der 12 Faktoren einer Cloud Anwendung. Im Laufenden betrieb ohne störungen zu verursachen ausgetauscht werden.

Ein kleiner Überklich über die wichtigesten Eigenschaften einer Cloud Nativen Anwendung.

Die Anwendung selbst darf keinen Status im Arbeitsspeicher halten.
Persistente Daten dürfen nicht im Container gespeichert werden.
Die Konfguration der Anwendung erfolgt über Umgebungsvariablen oder zentralisiertem Konfigurationsmanagenemt.
Persistente Daten werden nur in Datenbanken gespeichert.
Container mit Persistenten Daten speichern diese in Volumes.
Volumes werden nicht auf dem Pod gespeichert sondern auf zentralisierten Storage Systemen z.B. S3 oder Ceph

Somit lassen sich im Live Betrieb wartungen und aktualisierungen durchführen, die die Verfübgarkeit der Anwendung in keinster weise beeinträchtigen.

Vielmehr lassen sich in einem solchen Cluster auch ganze Update oder Change Prozesse einbinden. Durch die eingebaute Versionierung in die Container Images ist es möglich. Das Cluster in Production, Staging, Test und Development zu unterteilen und entsprechend den eingehenden Traffic an die gewünschten stellen zu Routen. Hierdurch lässt sich der Grundgedanke von continuous deployment sehr gut umsetzen.

Verbreitete Container Orchestration Tools:

Kubernetes
RedHad OpenShift
Apache Mesos
HashiCorp Nomad
Docker Swarm

SQL Views

2022-04-10T00:00:00+00:00

Database Views

Views sind SQL Queries die in auf dem DB Server gespeichert werden und somit mit einem einfachen Aufruf der View wiederverwendet werden können.

Beispiel View:

CREATE VIEW customerPayments
AS 
SELECT 
    customerName, 
    checkNumber, 
    paymentDate, 
    amount
FROM
    customers
INNER JOIN
    payments USING (customerNumber);

Vor und Nachteile von Views

Pro:

Komplexe SQL Queries können in Views gespeichert werden somit kann der erneute Aufruf vereinfacht werden.
Business Logik zentralisieren, greifen mehrere Programme auf die gleiche Datenbank zu und benötigen die selben Daten. So kann eine View dabei helfen die Queries Programmübergreifend konsistent zu halten.
Zugriffsbeschränkung man kann einem Benutzer gestatten nur die View ausführen zu können, somit ist dieser nicht in der Lage andere Informationen aus der Datenbank zu extrahieren.
Bei Schemaänderungen kann eine View mit dem alten Namen der Tabelle erstellt werden, somit funktionieren Queries die auf das alte Schema referenzieren noch.

Con:

Auf Views können keine Indexes erstellt werden.
Views mit Sub-Queries, Joins oder Aggregatsfunktionen können nicht angepasst werden.

Views Verwalten

Views Erstellen

Syntax:

CREATE [OR REPLACE] VIEW [db_name.]view_name [(column_list)]
AS
  select-statement;

Beispiel:

CREATE VIEW salePerOrder AS

Mit dem WITH CHECK OPTION Parameter wird der Scope der View auf die Daten die die View (dessen WHERE Klausel) ausgibt beschränkt. Somit können keine Datensätze außerhab diese Scopes ausgegeben, gelöscht oder bearbeitet werden.

Da Views auch verschachtelt werden können, gibt es die Möglichkeit die WITH CHECK OPTION weiter zu Bearbeiten mit den Parametern LOCAL und CASCADED ist es Möglich den Scope der Checks einzuschränken.

Mit der WITH LOCAL CHECK OPTION Option werden nur Bedingungen in der Aufgerufenen View beachtet. Mit der WITH CASCADED CHECK OPTION Option dagegen werden alle Bedingungen aller verschachtelten Views beachtet.

Algorithm

Der Algorithmus Parameter bestimmt wie die View beim Aufruf durch MySQL verarbeitet werden soll. Zur Auswahl stehen MERGE, TEMPTABLE und UNDEFINDE. Syntax:

CREATE [OR REPLACE][ALGORITHM = {MERGE | TEMPTABLE | UNDEFINED}] VIEW 
   view_name[(column_list)]
AS 
   select-statement;

Bei einem Merge Aufruf wird der Query String vor dem Ausführen auf der Datenbank vereinfacht.

Aus der View

CREATE ALGORITHM=MERGE VIEW contactPersons(
    customerName, 
    firstName, 
    lastName, 
    phone
) AS
SELECT 
    customerName, 
    contactFirstName, 
    contactLastName, 
    phone
FROM customers;

mit dem SQL Query Aufruf

SELECT * FROM contactPersons
WHERE customerName LIKE '%Co%';

werden die Parameter und der Tabellenname angepasst und eine WHERE Klausel angefügt (falls vorhanden). Das follständige Query sieht dann so aus:

SELECT 
    customerName, 
    contactFirstName, 
    contactLastName, 
    phone
FROM
    customers
WHERE
    customerName LIKE '%Co%';

Der Temptable Algorithmus erstellt eine temporäre Tabelle auf der der SELECT Query dann aufgeführt wird. Dies ist weniger effizient. Auf solch eine View kann auch kein UPDATE Query angewendet werden. Einziger Vorteil ist, dass sich durch die temporäre Tabelle die Lock Dauer auf die Datenbank verringert.

Undefined Beschreibt die Standardauswahl von MySQL, sollte kein Alorithmus angegeben werden. Dabei verwendet MySQL den bevorzugten Merge Algorithmus.

Views Entfernen

Syntax:

DROP VIEW [IF EXISTS] view_name;

Beispiel:

DROP VIEW IF EXISTS customerPayments;

Auflisten aller Views

SHOW FULL TABLES 
WHERE table_type = 'VIEW';

Da SHOW FULL Tables alle Tabellen der Datenbank zurückgibt wird die WHERE Klausel benötigt um die Views zu Filtern.

Views Umbenennen

Syntax:
RENAME TABLE original_view_name 
TO new_view_name;

Beispiel:

RENAME TABLE productLineSales 
TO productLineQtySales;

View Update Queries

Um ein UPDATE Query auf einer View auszuführen, darf die View keine Sub-Queries, Joins oder Aggregatsfunktionen enthalten. Sollte die der Fall sein kann ein UPDATE Query auf der View ausgeführt werden.

Beispiel:

UPDATE officeInfo 
SET 
    phone = '+33 14 723 5555'
WHERE
    officeCode = 4;

Nextcloud Skalierung

2022-02-15T00:00:00+00:00

Nextcloud Skalierungsoptionen

In diesem Beitrag halte ich meine Erfahrungen und Erkentnisse im Zusammenhang mit der Skalierung einer Nextcloud Instanz fest.

Mit einer Standardmäßigen Nextcloud Installation ist man in der ausgangsposition eines Webservers mit PHP-FPM Integration (Nginx/Apache2) einer Datenbank (MariaDB/MySQL/PostgresSQL) und einem Caching Layer (RedisDB).

Worker Skalierung

Die eine Möglichkeit der Skalierung ist die Ebene der PHP-FPM Prozesse zu replizieren. Dazu ist es nötig einen Reverse Proxy / Load Balancer aufzuspannen und vor die PHP Worker zu plazieren.

Dabei teilen sich die PHP Worker die darunterliegenden Ressourcen wie WWW Root und die Datenbank.

Durch die Skalierung auf 3 PHP Worker, wurde die Performance im vergleich zu einem single Worker setup etwas gesteigert.

Für den Benchmark wurde ein eigenes Tool erstellt, welches über WebDAV auf dem Nextcloud Server eine Menge X an Dateien erstellt.

Das Projekt zum Benchmarktool ist hier zu finden.

Der Benchmark ist in der hinsicht sehr syntetisch, da hier nur die Auslastung eines Benutzers in betracht gezogen wird. Die Worker Skalierung spielt ihre Vorteile aber erst richtig in einer multi User umgebung aus.

Datenbank Skalierung

Eine weitere Möglichkeit der Skalierung wäre es die Datenbank zu Skalieren.

Hierbei gibt es zum einen die Möglichkeit die Datenbank in mehrere Instanzen zu Skalieren. Dies lässt sich mit MariaDB oder MySQL aber nicht umsetzen. Hier müsste auf eine Distributed Databases umgestiegen werden.

Beispiele hierfür wären CockroachDB oder eine MySQL kompatibel akternative TIDB

Eine weitere Möglichkeit der Datenbankskalierung ist das Sharding der Datenbank entwerder durch Datenbankproxies wie Apache Shardingsphere oder Datenbankintegrationen wie Postgres Extension Citus.

SQL Stored Procedures

2022-01-10T00:00:00+00:00

Stored Procedures

Stored Procedures sind SQL Queries die auf dem Server abgespeichert sind. Vorteile und Funktionalitäten von Stored Procedures sind:

Funktionalitäten

Es können Übergabeparamter übergeben werden
Es können Statements eingebaut werden wie IF CASE oder LOOP
Es können andere Stored Procedures aufberufen werden. (Modularität)

Vorteile

Schnellere Ausführung, da das Query Kompiled im Cache gehalten wird
Weniger Traffic zum SQL Server, da nur der Name der Funktion und nicht das Query selbst übertragen werden muss
Business Logik zentral im SQL Server
Security, es können nur festgelegte Queries auf der Datenbank ausgeführt werden.

Nachteile

Erhöhter Ressourcenverbrauch auf dem Server, durch die Verarbeitung der Queries.
Schlechte Debugging Möglichkeiten
Der Betrieb und die Wartung der Queries erfordert geschultes Personal.

Aufbau

In der Datenbank:

CREATE PROCEDURE GetCustomers()
BEGIN
	SELECT 
		customerName, 
		city, 
		state, 
		postalCode, 
		country
	FROM
		customers
	ORDER BY customerName;    
END

Im Client:

CALL GetCustomers()

Parameter

IN Der IN Parameter ist der Standardparameter, dabei werden den Procedure Parameter die in das Query eingebau werden übergeben.

Wird im Stored Procedure der IN Parameter verändert, geschiet dies nur zur Laufzeit die eventuellen Änderungen werden nicht zum Anfrager zurückübertragen.

Statement:

CREATE PROCEDURE GetOfficeByCountry(
	IN countryName VARCHAR(255)
)
BEGIN
	SELECT * 
 	FROM offices
	WHERE country = countryName;
END

Call:

CALL GetOfficeByCountry('USA');

OUT Der OUT Parameter kann zur Laufzeit im Stored Procedure abgeändert werden, dabei werden die Änderungen auch an den Client zurückgemeldet. Der OUT Parameter kann nicht im Query verwendet werden, er dient lediglich zum extrahieren von Daten.

Statement:

CREATE PROCEDURE GetOrderCountByStatus (
	IN  orderStatus VARCHAR(25),
	OUT total INT
)
BEGIN
	SELECT COUNT(orderNumber)
	INTO total
	FROM orders
	WHERE status = orderStatus;
END

Call:

CALL GetOrderCountByStatus('Shipped',@total);
SELECT @total as total_in_process;

INOUT Der INOUT Parameter bietet zum einen die Möglichkeit Übergabeparameter an das Query zu übergeben und zum anderen lässt sich der veränderte Parameter nach ausführung des Queries mit den veränderten Werten an den Client zurückügertragen.

Statement:

CREATE PROCEDURE SetCounter(
	INOUT counter INT,
    IN inc INT
)
BEGIN
	SET counter = counter + inc;
END

Call:

SET @counter = 1;
CALL SetCounter(@counter,1); -- 2
CALL SetCounter(@counter,1); -- 3
CALL SetCounter(@counter,5); -- 8
SELECT @counter; -- 8

Statements

IF Statements haben einen Bash ähnlichen Syntax

CREATE PROCEDURE GetCustomerLevel(
    IN  pCustomerNumber INT, 
    OUT pCustomerLevel  VARCHAR(20))
BEGIN
    DECLARE credit DECIMAL(10,2) DEFAULT 0;
    SELECT creditLimit 
    INTO credit
    FROM customers
    WHERE customerNumber = pCustomerNumber;
    IF credit > 50000 THEN
        SET pCustomerLevel = 'PLATINUM';
    END IF;
END

Erweiterungen ELSE und ELSEIF

CASE

SQL Switch Case Statement

    CASE customerCountry
		WHEN  'USA' THEN
		   SET pShipping = '2-day Shipping';
		WHEN 'Canada' THEN
		   SET pShipping = '3-day Shipping';
		ELSE
		   SET pShipping = '5-day Shipping';
	END CASE;

Es können auch vergleiche als CASE Statment verwendert werden.

CASE 
		WHEN waitingDay = 0 THEN 
			SET pDeliveryStatus = 'On Time';
        WHEN waitingDay >= 1 AND waitingDay < 5 THEN
			SET pDeliveryStatus = 'Late';
		WHEN waitingDay >= 5 THEN
			SET pDeliveryStatus = 'Very Late';
		ELSE
			SET pDeliveryStatus = 'No Information';
	END CASE;

LOOP

Endlosschlefe mit Austiegsbedingung

CREATE PROCEDURE LoopDemo()
BEGIN
	DECLARE x  INT;
	DECLARE str  VARCHAR(255);
        
	SET x = 1;
	SET str =  '';
        
	loop_label:  LOOP # <-- Start Loop
		IF  x > 10 THEN 
			LEAVE  loop_label; # <-- Break
		END  IF;
            
		SET  x = x + 1;
		IF  (x mod 2) THEN
			ITERATE  loop_label;
		ELSE
			SET  str = CONCAT(str,x,',');
		END  IF;
	END LOOP; # <-- End Loop
	SELECT str;
END

WHILE

While Loop in SQL

CREATE PROCEDURE LoadCalendars(
    startDate DATE, 
    day INT
)
BEGIN
    
    DECLARE counter INT DEFAULT 1;
    DECLARE dt DATE DEFAULT startDate;
    WHILE counter <= day DO # <-- While loop mit Bedingung
        CALL InsertCalendar(dt);
        SET counter = counter + 1;
        SET dt = DATE_ADD(dt,INTERVAL 1 day);
    END WHILE; # <-- End Loop
END

LEAVE

SQL equivalent zu Break

CREATE PROCEDURE sp_name()
sp: BEGIN
    IF condition THEN
        LEAVE sp; # <-- Leave sp Label
    END IF;
    -- other statement
END

Error Handling

CREATE PROCEDURE InsertSupplierProduct(
    IN inSupplierId INT, 
    IN inProductId INT
)
BEGIN
    -- exit if the duplicate key occurs
    DECLARE EXIT HANDLER FOR 1062
    BEGIN
 	SELECT CONCAT('Duplicate key (',inSupplierId,',',inProductId,') occurred') AS message;
    END;
    
    -- insert a new row into the SupplierProducts
    INSERT INTO SupplierProducts(supplierId,productId)
    VALUES(inSupplierId,inProductId);
    
    -- return the products supplied by the supplier id
    SELECT COUNT(*) 
    FROM SupplierProducts
    WHERE supplierId = inSupplierId;
    
END

Aufbau & Ablauf

Exemplarischer Aufbau eines Stored Procedures.

Variablen Deklaration

Die Variablendeklaration leitet den gebinn eines Stored Procedures ein. Variablen sollten zu allererst deklariert werden.

Beispielhafte Variablendeklaraion:

DECLARE test VARCHAR(256);
DECLARE test1 INTEGER;
DECLARE test2 BOOLEAN DEFAULT TRUE;

Cursor

Unter die Variablendeklaration fält auch die CURSOSR Deklaration. Diese ist für den Loop eine Liste an werden die iteriert werden kann.

Beispieldeklaration:

DECLARE iterator CURSOR FOR
    SELECT id
    FROM tabelle
    WHERE wert1 = wert2;

Um den CURSOR später verwenden zu können, muss dieser erst geöffnet werden:

OPEN iterator;

Im Anschluss kann dieser in einer Schleife verwendet werden.

DECLARE testVar VARCHAR(256);
schleife: LOOP
    FETCH iterator INTO testVar;
END LOOP;

Continue Handler

Handler sind Ereignese / Fehler die abgefangen werden. Für eine Schleife ist es nötige einen NOT FOUND Handler zu erstellen, damit das ende einer Schleife detektiert werden kann.

Beispiel einer Handlerdeklaration:

DECLARE CONTINUE HANDLER
    FOR NOT FOUND SET weitermachen = FALSE;

Beispiel einer Handlerabfrage:

IF weitermachen = FALSE THEN
    LEAVE schleife;
END IF;

Umsetzung einer Cloud HA Infrastruktur mit Keepalived

2021-05-19T00:00:00+00:00

Konfiguration einer HA Struktur in der Cloud mithilfe von Floating-IPs und Keepalived

In diesem Tutorial wird die Einrichtung eines Cloud HA Clusters mithilfe von Keepalived und Floating-IPs beschrieben.

Zu beachten ist das diese form der Hochverfügbarkeit nicht von allen Anwendungen unterstützt wird. Dies sollte im ersten Schritt geprüft werden.

Voraussetzungen

min. 2 Cloud Server
Eine Floating-IP

Empfehlung

Für den HA Service sollte ein eigenes Cloud Projekt angelegt werden, da auf den Servern kritische Zugangsdaten im klartext abgelegt werden müssen. Mit einem seperaten Projekt kann bei einer möglichen kompromitierung der Schaden minimiert werden.

Schritt 1 - Einrichtung des automatischen IP Rerouting

In diesem Schritt geht es um das automatische Failover, dabei soll die Floating-IP automatisch dem anderen Server zugewiesen werden. Damit dieser unter der gleichen Adresse den ausgefallenen Dienst wieder aufnehmen stellen kann.

Schritt 1.1 - Erstellung eines Cloud API Tokens

Dieser Token wird benötigt um später vom Server aus die Floating-IP zuordnung zu steuern.

In der Cloud Console muss unter “Sicherheit” –> “API-Tokens” ein Lese/Schreib API Token angelegt werden.

Hinweis: Da der Token nur einmal ausgelesen werden kann empfiehlt es sich diesen zwischenzuspeichern.

Schritt 1.2 - Anlegen eines Cloud Netzwerks

Für den VRRP Heartbeat wird ein privater Netzwerkkanal benötigt dieser wird über die Funktion der Cloud Netzwerke realisiert.

Solche ein Cloud Netzwerk kann in der Cloud Console unter “Netzwerke” angelegt werden.

Hier kann ein Netzwerk mit beliebiger größe (größer 32) angelegt und den beiden Server auch gleich zugewiesen werden.

Schritt 1.3 - Installation der IP Failover Software

In diesm Schritt wird die Software installiert, die für die Provisionierung der Floating-IP zuständig ist.

Dabei handelt es sich um die Open Source Software hcloud-ip um die Software zu installieren kann entweder auf die prebuilt-Binaries zurückgegriffen werden oder man kompiliert die Software selbst.

Für eine installation mit den prebuilt-Binaries sind folgende Schritte notwendig

wget -O /opt/hcloud-ip https://github.com/FootprintDev/hcloud-ip/releases/download/v0.0.1/hcloud-ip-linux64
chmod +x /opt/hcloud

Um die Software selbst zu kompiliert sind folgende Schritte notwendig

Installation der Abhängigkeiten

Ubuntu / Debian:

apt install git wget

CentOS / RHEL:

yum install git wget

Fedora:

dnf instal git wget

openSUSE / SLES:

zypper install git wget

Golang Installation

wget https://golang.org/dl/go1.16.2.linux-amd64.tar.gz
tar xfvz go1.16.2.linux-amd64.tar.gz
export PATH=$(pwd)/go/bin:$PATH

Clonen des Repositories

git clone https://github.com/FootprintDev/hcloud-ip /tmp/hcloud-ip && cd /tmp/hcloud-ip

Projekt Bauen

go build

Nun sollte sich im aktuellen Ordner ein Programm mit dem Namen hcloud-ip befinden, dies kann entsprechend ausführbar gemacht und abgespeichert werden.

chmod +x hcloud-ip
mv hcloud-ip /opt

Schritt 1.4 - Konfiguration der Floating-IP

Damit die Floating-IP bei einem Failover auf allen Servern funktioniert, muss diese in die Netzwerkkonfiguration aufgenommen werden. Eine Anleitung hierfür befindet sich auf docs.hetzner.com

Schritt 2 - Einrichtung von Keepalived

Keepalived ist ein Linux Daemon der Systeme oder Dienste überwacht und im Fehlerfall ein Failover anstößt.

Schritt 2.1 - Installation von Keepalived

Ubuntu / Debian:

apt install keepalived

CentOS / RHEL:

yum install keepalived

Fedora:

dnf instal keepalived

openSUSE / SLES:

zypper install keepalived

Schritt 2.2 - Keepalived autostart aktivieren

Systemd basierte Systeme:

systemctl enable keepalived

CentOS / RHEL

chkconfig keepalived on

Schritt 2.3 - Konfiguration von Keepalived

Die hier gezeigte Konfiguration entspricht einem Beispiel anhand eines HA Webservers (nginx).

Konfiguration des Master Servers

/etc/keepalived/keepalived.conf

vrrp_script chk_nginx {
    script "/usr/bin/pgrep nginx"
    interval 2
}

vrrp_instance VI_1 {
    interface [cloud_network_adapter]
    state MASTER
    priority 200

    virtual_router_id 30
    unicast_src_ip [master_private_IP]
    unicast_peer {
        [slave_private_IP]
    }

    authentication {
        auth_type PASS
        auth_pass [password]
    }

    track_script {
        chk_nginx
    }

    notify_master /etc/keepalived/failover.sh
}

Hinweis: Die umrandeten Werte [] sind durch eigene Angaben auszutauschen.

Konfiguration des Slave Servers

/etc/keepalived/keepalived.conf

vrrp_script chk_nginx {
    script "/usr/bin/pgrep nginx"
    interval 2
}

vrrp_instance VI_1 {
    interface [cloud_network_adapter]
    state SLAVE
    priority 100

    virtual_router_id 30
    unicast_src_ip [slave_private_IP]
    unicast_peer {
        [master_private_IP]
    }

    authentication {
        auth_type PASS
        auth_pass [password]
    }

    track_script {
        chk_nginx
    }

    notify_master /etc/keepalived/failover.sh
}

Hinweis: Die umrandeten Werte [] sind durch eigene Angaben auszutauschen.

Inhalt der failover.sh

Das Script beinhaltet die Aktionen die bei einem Failover ausgeführt werden sollen.

#!/bin/bash
IP='[Floating-IP-Name]'
TOKEN='[CloudToken]'
n=0
while [ $n -lt 10 ]
do
    if [ "$(/opt/hcloud-ip -ip $IP -key $TOKEN)" == "Server called $HOSTNAME was found" ]; then
        break
    fi
    n=$((n+1))
    sleep 3
done

Hinweis: Die umrandeten Werte [] sind durch eigene Angaben auszutauschen.

Schritt 3 - Testen der Konfiguration

Im Normalbetrieb übernimmt der Master Webserver alle Anfragen.

Sobald dieser ausfällt gibt es ein Failover auf den Slave Webserver.

Sobald der Master Webserver wieder erreichbar ist wird wieder auf diesen gewechselt.

Fazit

In diesem Beitrag wird beschreiben wie man eine High Availability Cloud Umgebung mithilfe von keepalived erstellt.

UNIX Berechtigungen

2020-10-26T00:00:00+00:00

Datei Berechtigungen

Allgemeines

In Linux: einfaches Rechtekonzept > 50 Jahre alt, Benutzernamen und Gruppen basiert.

Jede Datei (auch Geräte - „everything is a file“) und jedes Verzeichnis gehört genau einem Nutzer (user: u) und einer Gruppe (group g).

Der Besitzer gilt als u, andere Mitglieder der Besitzergruppe gelten als g. Alle anderen gelten als sonstige Nutzer (others: o).

Beim Anlegen einer Datei gehört sie zunächst der primären Gruppe des Anlegenden. Will man mehr Berechtigungen? ACL (Access Control List): erlauben die Vergabe komplexer Rechtestrukturen ähnlich zu NTFS-Berechtigungen.

root@PCITBMR:/tmp/tmp.tP7iSWSie9# ls -ltsa
total 0
drwxrwxrwt 1 root root     512 Oct 26 11:42 ..
drwx------ 1 root root     512 Oct 26 11:41 .
-rw------- 1 root www-data   0 Oct 26 11:41 tmp.c4x2xSSTNk
-rw------- 1 root www-data   0 Oct 26 11:41 tmp.RR1cd1Rzz0
-rw------- 1 root www-data   0 Oct 26 11:41 tmp.ffCLHbTpoh
-rw------- 1 root www-data   0 Oct 26 11:41 tmp.2ykfAZO1O3
-rw------- 1 root www-data   0 Oct 26 11:41 tmp.LsAW89CTtO
-rw------- 1 root www-data   0 Oct 26 11:41 tmp.lHaxyGeRJQ

Programme zum Ändern der Berechtigungen

chgrp ändert Besitzergruppe Aber: Nur Besitzer und root können chgrp ausführen

Parameter -R ändert Gruppe rekursiv (in allen Dateien und Unterverzeichnissen des Ziels) chown (“change owner”) kann Besitzer, aber auch die Besitzergruppe ändern. Nur Besitzer: chown neuuser datei Besitzer und Gruppe: chown neuuser:neugruppe datei Nur Gruppe: chown :neugruppe datei

Berechtigungs Kategoriern

Für jede der drei Kategorien u, g und o lassen sich folgende drei Dateirechte vergeben:

Leserecht (read r)
Schreibrecht (write w)
Ausführungsrecht (execute x) Bei Verzeichnissen gilt: r: Dateinamen im Verzeichnis (aber keine Details) anschauen w (nur in Kombination mit x) Dateien löschen / anlegen x mit cd “betreten”

Die Rechtesuche geht von links nach rechts: u-Eigenschaft sticht g (selbst wenn g höhere Rechte hat) g-Eigenschaft sticht o (selbst wenn o höhere Rechte hat)

----r--rw- 1 go go 0 Okt 10 15:52 datei1

User go hat gar keine Rechte auf die Datei datei1, selbst wenn er Mitglied der Gruppe go ist.

Ungeachtet dessen ist go als Eigentümer der Einzige, der diese Berechtigungen ändern darf (außer root natürlich). Alle Mitglieder von go (außer go) haben Leserechte. Alle anderen (nicht go, nicht Mitglied von go) haben Lese- und Schreibrechte.

Beispiel

Gegeben sind folgende Rechte:

drwxr-xr-x 9 root  root  4096 Okt 10 16:09 /
drwxr-xr-- 3 root  root  4096 Okt 10 16:01 /a
-rwxrwxrwx 1 user1 user1 254  Okt 10 15:52 /a/y

Welche Rechte hat user1 auf /a/y in der Praxis?

Gar keine, denn es fehlt das x-Recht für /a – somit kommt der User gar nicht in das nötige Verzeichnis hinein! Wer darf sich den Inhalt von /a mit ls /a anzeigen lassen?
Alle, denn dazu reicht das r-Bit auf /a in Kombination mit dem x-Bit auf / - allerdings sehen nur Mitglieder der root-Gruppe Details zu den Inhalten wegen des x-Bit auf /a

Einführung IPTables

2020-06-17T00:00:00+00:00

Einrichtung eines Paketfilters auf Linux

In diesem Beitrag geht es um die Einführung in iptables um die Funktionen zu verstehen und anwenden zu können.

Achtung: Vorsicht ist geboten, durch unüberlegte Änderungen an der Firewall kann man sich schnell aus dem System aussperren.

Voraussetzungen

root Zugriff auf eine Linux Shell mit installiertem iptables

Abschnitt 1 - Was ist iptables?

iptables ist ein Userspace Programm das zur Konfiguration der Netfilter Firewall im Linux Kernel verwendet wird. Somit ist iptables nur ein Werkzeug um die im Linux Kernel integrierte Firewall zu konfigurieren.

iptables teilt sich in zwei bereiche auf jeweils für IPv4 und IPv6 gibt es eigene Tools. Für IPv4 verwendet man iptables und für IPv6 ip6tables alle nachfolgenden Befehle können aber mit beiden Tools gleich verwendet werden.

Durch den Netfilter ist es Möglich:

Eingehende Pakete zu Filtern bevor diese an die Zielanwendung geleitet werden.
Ausgehende Pakete zu Filtern bevor diese den Rechner verlassen.
Durch den Rechner geleitete (Router) Pakete zu prüften.
Paketmanipulation durchzuführen.

Abschnitt 1.1 - Funktionsweise

Die Paketprüfung mit iptables ist dreistufig aufgebaut (von oben nach unten):

Tabellen
“Chains” (Ketten)
Filterregeln

Trifft eine der definierten Filterregeln in den Tabellen / Chains zu wird diese ausgeführt, sollte keine Regel hinterlegt sein oder keine der definierten Regeln zutreffen wird auf die hinterlegte Policy angewendet (Später mehr dazu).

Tabellen

In den Tabellen sind verschiedene Chains zu Gruppen nach der grundsätzlichen Aufgabe zusammengefasst.

Tabelle	Beschreibung
filter	Die Standardtabelle hier werden alle Filterregeln hinterlegt
nat	Diese Tabelle wird für NAT (Network Address Translation) und Port Forwarding verwendet.
mangle	Diese Tabelle wird bei Paketmanipulationen verwendet.
raw	Diese Tabelle wird eingesetzt um Ausnahmen vom Connection Tracking zu definieren.

Chains

Die Chains legen fest, wann ein Paket geprüft wird z.B. bevor es versendet wird. Eine Chain kann dabei in mehreren Tabellen vorkommen.

Chain	Tabelle	Beschreibung
INPUT	filter, mangle	Wird auf alle Pakete angewendet, die an die lokalen Adresse gerichtet sind.
OUTPUT	filter, nat, mangle, raw	Wird auf alle Pakete angewendet, die von der lokalen Adresse stammen.
FORWARD	filter, mangle	Wird auf alle Pakete angewendet, die geroutet werden.
PREROUTING	nat, mangle, raw	Wird auf alle Pakete angewendet, bevor diese geroutet werden.
POSTROUTING	nat, mangle	Wird auf alle Pakete angewendet, nachdem diese geroutet wurden.

Abschnitt 2 - Definition von Filterregel

Hier sind die gängigsten CLI Parameter für das erstellen der Filterregeln aufgelistet.

Option	Beschreibung
-t Tabelle	Diese Filterregel gilt für die genannte Tabelle.
-I Chain (Position)	Regel wird an gewählte Position der Chain hinzugefügt. Standardmäßig wird die Regel am Anfang der Chain eingefügt.
-A Chain	Regel wird an die Chain angehängt.
-D Chain	Regel wird aus der Chain gelöscht.
-F Chain	Alle Regeln der Chain löschen.
-L Chain	Liste alle Regeln der Chain.
-p Protokoll	Das Paket wird nur geprüft, wenn es dem Protokoll entspricht (z.B. TCP, UDP, ICMP).
-s IP-Adresse	Das Paket wird nur geprüft, wenn es von der definierten IP-Adresse / IP-Netz stammt.
-d IP-Adresse	Das Paket wird nur geprüft, wenn es an die definierte IP-Adresse gesendet wird.
-i Netzwerkschnittstelle	Das Paket wird nur geprüft, wenn es über die entsprechende Netzwerkschnittstelle eingegangen ist.
-o Netzwerkschnittstelle	Das Paket wird nur geprüft, wenn es über die entsprechende Netzwerkschnittstelle versendet wird.
–sport (Port) oder –source-port (Port)	Das Paket wird nur geprüft, wenn es von dem definierten Port stammt. Muss zwingend in Verbindung mit -p benutzt werden!
–dport (Port) oder –destination-port (Port)	Das Paket wird nur geprüft, wenn es an den definierte Port gesendet wird. Muss zwingend in Verbindung mit -p benutzt werden!
-j Aktion	Legt fest, welche Aktion auf das Paket angewendet werden soll.

Abschnitt 2.1 - Definition von Aktionen

Aktion	Beschreibung
ACCEPT	Das Paket wird akzeptiert und angenommen.
DROP	Das Paket wird nicht angenommen, der Sender erhält keine Nachricht.
REJECT	Das Paket wird nicht angenommen, der Sender wird benachrichtigt.
LOG	Die Paketdaten werden im System-Log festgehalten, anschließend wird die nächste Regel der Chain geprüft und ggf. angewendet.

Abschnitt 2.2 - Definition von Policies

Eine Policy ist wie eine Grundsatzregel zu sehen sie greift also immer, wenn keine andere Filterregel zutrifft.

Eine Policy setzt sich aus der Chain und einer Aktion zusammen:

iptables -P INPUT DROP

Achtung: Diese Policy Blockiert den eingehenden Traffic soweit keine Regeln definiert wurden.

Hier im Beispiel werden alle eingehenden Pakete in in der Filter Tabelle durch die Policy verworfen.

Abschnitt 3 - Loopback Interface (127.0.0.1)

Auf jedem Linux System befindet sich ein Lokaler Netzwerkadapter dieser trägt den Namen lo Hierrüber laufen interne Host anwendungen, diese Kommunizieren mitunter per IPC (Inter Process Communication) über diesen Adapter. Daher ist es ratsam auf diesen Adapter keinerlei Filterregeln anzuwenden, da dies zu Kommunikationsproblemen führen kann.

Diesem Adapter sollte die Kommunikation ohne Einschränkungen erlaubt werden:

iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT

Abschnitt 4 - Praktische Beispiele

Erstellen einer Paket Filterregel

Diese Regel erlaubt eingehenden HTTPS Traffic:

iptables -A INPUT -p tcp --dport 443 -j ACCEPT

Erstellen einer Host Filterregel

Diese Regel erlaubt eingehenden Traffic vom angegebenen Host:

iptables -A INPUT -s 10.0.0.1 -j ACCEPT

Diese Regel verbietet eingehenden Traffic vom angegebenen Host.:

iptables -A INPUT -s 10.0.0.1 -j DROP

Regeln können auch an einer bestimmten Stelle hinzugefügt werden:

iptables -I INPUT 2 -s 10.0.0.1 -j DROP

Diese Regel steht z.B. an zweiter Stelle.

Löschen aller Regeln

Löscht alle Regeln in allen Chains:

iptables -F

Löscht alle Regeln in der INPUT Chain:

iptables -F INPUT

Löschen einer Regel

Hiermit werden die Regeln mitsamt den entsprechenden Nummern angegeben:

iptables -L --line-numbers

Chain INPUT (policy ACCEPT)
num  target     prot opt source               destination
1    ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:https
2    ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:ssh
Chain FORWARD (policy ACCEPT)
num  target     prot opt source               destination
Chain OUTPUT (policy ACCEPT)
num  target     prot opt source               destination

Mithilfe dieser Nummer kann nun die gewünschte Regel gelöscht werden:

iptables -D INPUT 1

Connection State

Damit bei bereits hergestellten Verbindungen nicht jedes Paket durch den Filter muss, können Connection State Filter eingesetzt werden.

Eingehende Pakete für existierende Verbindungen zulassen:

iptables -A INPUT -i eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT

Ausgehende Pakete für existierende Verbindungen zulassen:

iptables -A OUTPUT -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT

Hinweis: Die Connection State Regeln sollten weit oben in der Firewall Liste stehen da diese sonst ihren nutzen verlieren.

Verwerfen von invaliden Paketen

Mit diesem Befehl werden alle eingehende Pakete die nicht dem TCP / IP Format entsprechen verworfen:

iptables -A INPUT --ctstate INVALID -j DROP

Syn-Flood Protection

Mit diesen Einträgen wird der Überlastung des Servers durch zu viele Anfragen vorgebeugt:

iptables -N syn_floodiptables -A INPUT -p tcp --syn -j syn_floodiptables -A syn_flood -m limit --limit 1/s --limit-burst 3 -j RETURN
iptables -A syn_flood -j DROP
iptables -A INPUT -p icmp -m limit --limit 1/s --limit-burst 1 -j ACCEPT
iptables -A INPUT -p icmp -m limit --limit 1/s --limit-burst 1 -j LOG --log-prefix PING-DROP:
iptables -A INPUT -p icmp -j DROP
iptables -A OUTPUT -p icmp -j ACCEPT

Abschnitt 5 - Persistenz

Die konfigurierten Firewall Regeln sind nicht automatisch persisten gespeichert um dies zu ändern muss das Paket iptables-persistent nachinstalliert werden.

Danach kann mit dem Befehl:

iptables-save > /etc/iptables/rules.v4   # Für IPv4

ip6tables-save > /etc/iptables/rules.v4   # Für IPv6

Die aktuelle Konfiguration gespeichert werden.

Abschnitt 6 - Länder Blockierung

Mit dem beigefügten Script lassen sich IP Drop Regeln für ganze Länder erstellen.

Hinweis: Die Blockierung beschränkt sich auf IPv4 Adressen.

#!/bin/bash
###PUT HERE SEPARATED LIST OF COUNTRY CODE###
COUNTRIES=(de at)
WORKDIR=$(mktemp -d)
#######################################
for i in "${COUNTRIES[@]}"; 
do
curl http://www.ipdeny.com/ipblocks/data/countries/$i.zone >> $WORKDIR/iptables-blocklist.txt;
done
if [ -f $WORKDIR/iptables-blocklist.txt ]; then
  iptables -F
  BLOCKDB="$WORKDIR/iptables-blocklist.txt"
  IPS=$(grep -Ev "^#" $BLOCKDB)
  for i in $IPS
  do
    echo iptables -A INPUT -s $i -j DROP >> input.sh
    echo iptables -A OUTPUT -d $i -j DROP >> output.sh
  done
fi
rm -r $WORKDIR

Im oben aufgeführten Script lassen sich die Variablen COUNTRIES entsprechend der Länder kürzel abändern. Bei ausführung des Scripts erstellt dieses zwei Dateien input.sh und output.sh darin enthalten sind die benötigen iptables Befehle um die IP Adressen der Länder zu blockieren.

Zusammenfassung

In diesem Beitrag wurde die Funktionsweise von iptables erläutert. Auserdem wurde mit praktischen Beispielen auf die verschiedenen Möglichkeiten eingegangen um iptables optimal zu nutzen.

Installieren von Windows ohne KVM

2020-06-07T00:00:00+00:00

Installieren von Windows auf Dediziertem Server ohne KVM Konsole

In diesem Tutorial geht es um die Installation eines Windows Betriebssystems auf dedizierter Hardware ohne den gebrauch einer KVM Konsole.

Voraussetzungen

Einen Dedizierten Server im Rescue System
Mehr als 8 GB RAM im Server

Schritt 1 - Server Vorbereiten

Sobald sich der Server im Rescue System befindet (Linux x64), muss folgende Software installiert werden.

apt update && apt install qemu-kvm

Als nächstes muss eine Windows ISO auf den Server übertragen werden. Mögliche Optionen wären:

Hochladen per sFTP
Einbinden eines SMB / NFS Speichers (Storage Box)
Das Herunterladen der ISO von Microsoft / Hetzner

Auf dem Hetzner Mirror befinden sich auch Windows ISOs (diese können nur vom Hetzner Netz aus heruntergeladen werden): Windows Server 2019 (ENG): http://mirror.hetzner.de/bootimages/windows/SW_DVD9_Win_Server_STD_CORE_2019_64Bit_English_DC_STD_MLF_X21-96581.ISO

Windows Server 2016 (ENG): http://mirror.hetzner.de/bootimages/windows/SW_DVD9Win_Svr_STD_Core_and_DataCtr_Core_2016_64Bit_English-2_MLF_X21-22843.ISO

Windows Server 2012 R2 (ENG): http://mirror.hetzner.de/bootimages/windows/SW_DVD5_Windows_Svr_Std_and_DataCtr_2012_R2_64Bit_English_Core_MLF_X19-05182.iso

Anschließend muss die Systemfestplatte noch vorbereitet werden. Hier muss eine Partitionstabelle angelegt werden.

Achtung Dabei werden alle Daten der Festplatte gelöscht. Starten von parted auf der gewünschten Festplatte:

parted /dev/sdb

Erstellen der Partitionstabelle bei Festplatten kleiner 2 TB:

mklabel msdos

Erstellen der Partitionstabelle bei Festplatten größer 2 TB:

mklabel gpt

Das ganze sollte dann in etwa so aussehen:

root@rescue ~ # parted /dev/sda
GNU Parted 3.2
Using /dev/sda
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) [mklabel msdos]
Warning: The existing disk label on /dev/sda will be destroyed and all data on this disk will be
lost. Do you want to continue?
Yes/No? [yes]
(parted) [quit]
Information: You may need to update /etc/fstab.

Alle Eingaben sind mit [ ] umrandet

Schritt 2 - Herstellen eines SSH Tunnels

Um später die installation per VNC durchzuführen wird ein SSH Tunnel benötigt. Andernfalls ist die installation frei im Internet aufrufbar.

Unter Linux und Windows mit installiertem OpenSSH genügt es den folgende Befehl lokal auszuführen und sich am Server anzumelden.

ssh -L 8888:127.0.0.1:5901 root@your_host

Schritt 3 - Starten der Windows Installation

Jetzt kann mit der eigentlichen Windows Installation gestartet werden. Dazu muss nun folgender Befehl (entsprechend abgeändert) auf dem Server ausgeführt werden.

qemu-system-x86_64 -enable-kvm -smp 4 -m 4096 -boot d -cdrom en_windows_server_2019_updated_sept_2019_x64_dvd_199664ce.iso -drive file=/dev/sda,format=raw,media=disk -vnc 127.0.0.1:1

Optionen
-smp	Anzahl der CPU Kerne
-m	Große des verwendeten RAMs
-cdrom	Pfad zum ISO Image
-drive	Festplatte auf der das System installiert werden soll
-vnc	VNC Server Einstellungen

Als nächstes kann die Installation per VNC gestartet werden, dazu muss man sich mit einem VNC Viewer der wahl zur folgenden Adresse verbinden.

127.0.0.1:8888

Schritt 4 - Automatische IP Konfiguration

Damit wenn der Server von der Windows installation Bootet auch die richtige Netzwerkkonfiguration bekommt, muss ein Scheduled Task angelegt werden der das folgende PowerShell Script ausführt.

foreach($Adapter in Get-NetAdapter)
{
    New-NetIPAddress –IPAddress [IPAdresse] -DefaultGateway [Gateway] -PrefixLength [CIDR] -InterfaceIndex $Adapter.InterfaceIndex
}

Die Werte in den Klammern müssen entsprechend angepasst werden und das Script sollte dann unter C:\script.ps1 abgelegt werden.

Die Einrichtung des Scheduled Tasks erfolgt anhand dieser Schritte:

Startoptionen festlegen.

Aktion Festlegen.

PowerShell optionen eintragen -ExecutionPolicy Bypass -File C:\script.ps1.

Task optionen Übersicht.

Sicherheitsoptionen hier sollte Eingestellt werden, dass das Script auch ohne eine Benutzeranmeldung startet.

Schritt 5 - RDP Aktivieren & Firewall Deaktivieren

Um später per RDP auf den Server zu verbinden muss diese aktiviert werden:

Um weitere Fehlerquellen zu minimierern macht es sinn die Windows Firewall vor dem Neustart zu deaktivieren (dies ist aber optional).

Nun kann Windows heruntergefahren werden und im anschluss der Server neugestartet werden. Nach ein paar minuten sollte es möglich sein sich per RDP zum Server zu verbinden.

Schritt 6 - Script Deaktivieren

Nun sollte der Scheduled Task wieder Deaktiviert werden und die Firewall entsprechend überprüft und wieder eingeschlatet werden. In den Netzwerkeinstellungen sollten auch noch DNS Server hinterlegt werden, da diese mit dem Script nicht gesetzt wurden.

Fazit

In diesem Tutorial wurde die Installation eines Windows Betriebssystems ohne den einsatz einer KVM Konsole behandelt.