Iptables in Echtzeit monitoren

Ich hatte grade die mal wieder die angenehme Erfahrung iptables in Echtzeit zu debuggen.

Hier ist ein kleiner Einzeiler, der dabei helfen kann.

watch -n 1 "sudo iptables-save -t nat -c"

iptables-save hat den netten Parameter -c, welcher die Counter der getroffenen Regeln in [packet:byte] anzeigt.

Wenn Ihr wie ich eine Menge web Traffic auf vielen VM habt, wollt Ihr vielleicht noch Traffic zu 443 rausfiltern. Außerdem kann es helfen nur Regeln zu listen, die mindestens einmal getriggert haben.

watch -n 1 "sudo iptables-save -t nat -c | grep -v '0:0' |grep -v '443'"

Das gibt euch eine kompakte Übersicht darüber, welche Regeln greifen und kann fürs Echtzeitdebugging helfen.

Happy hacking :)


Monitoring iptables in realtime

I just had the pleasurable experience of debugging iptables again.

Here is a short oneliner that lets you debug your iptables in realtime.

watch -n 1 "sudo iptables-save -t nat -c"

iptables-save has the convienient flag -c, which is showing it's counters as [packet:byte]

If you have a lot of web traffic on vm's like me you might want to filter out 443. Also rules that do not trigger at all [0:0] can be filtered out.

watch -n 1 "sudo iptables-save -t nat -c | grep -v '0:0' |grep -v '443'"

This gives you a good indication as to wich rules get applied in realtime.
A useful tool for debugging.

Happy hacking :)


OpenLDAP auf CentOS 7

In diesem Artikel soll es darum gehen, wie man OpenLDAP auf CentOS 7 installiert und wie man es rudimentär bedient.

Er bedient sich grob an dem offiziellen Quick Start Guide.

Warum CentOS 7 und nicht CentOS 8?

  • CentOS 8 geht 2021 end of life, CentOS 7 hat noch support bis 2024. Click mich für Details.

Warum openLDAP und nicht 389ds / FreeIPA

  • Lernzwecke
  • Es funktioniert und ist relativ einfach handlebar

Basisinstallation

Im Gegensatz zu CentOS8 bei dem man openLDAP selbst bauen muss, ist es bei CentOS7 bereits in den Repos.

yum install openldap openldap-servers

Der server kommt mit dem slapd service daher.
Diesen starten und enablen wir.

systemctl start slapd
systemctl enable slapd

Prüft anschließend, dass der Dienst läuft und port 389 gebunden hat.

[root@openldap ~]# systemctl status slapd
● slapd.service - OpenLDAP Server Daemon
   Loaded: loaded (/usr/lib/systemd/system/slapd.service; enabled; vendor preset: disabled)
   Active: active (running) since Mi 2021-01-13 11:02:31 CET; 1min 59s ago
     [...]


[root@openldap ~]# netstat -tulpen | grep slapd
tcp        0      0 0.0.0.0:389             0.0.0.0:*               LISTEN      0          312156     15731/slapd
tcp6       0      0 :::389                  :::*                    LISTEN      0          312157     15731/slapd

Initiale Konfiguration

Bei der Installation von openLDAP werden einige Tools mitinstalliert.
Diese werden wir nun verwenden um die initiale Konfiguration der openLDAP Instanz vorzunehmen.

Slapcat - exportiert Daten im ldif Format.

Slapcat is used to generate an LDAP Directory Interchange Format (LDIF) output based upon the contents of a slapd(8) database.

slappasswd - hasht passwörter

Slappasswd is used to generate an userPassword value suitable for use with ldapmodify(1), slapd.conf(5) rootpw configuration

Da wir bisher noch kein Passwort gesetzt haben, nutzen wir slappasswd um initial ein Passwort zu setzen.

[root@openldap ~]# slappasswd
New password:
Re-enter new password:
{SSHA}mLWOOC88hfX1HH0l0mZQDhJjqHfgsBqi

Dies wirft euch ein gehashtes Passwort aus, welches wir gleich brauchen werden.

Zunächst aber schauen wir uns an, wie ldif files aufgebaut sind.
LDIF (LDAP Data Interchange Format) Dateien beschreiben den Inhalt eines Directories oder beinhalten Änderungsaufforderungen.

dn (Distinguished Name) - Ist der ein Objekt eindeutig identifizierende name. Achtung, in kanonischer Schreibweise!

changetype - ist die Art der Änderung der vorzunehmenden Änderung. Möglich sind:

  • add
  • delete
  • modify
  • modrdn (Modify RDN, relative distinguished name)
  • moddn - (Modify DN, distinguished name)

replace: <attribute> - ist die Anweisung den Wert von <attribute> zu ändern

<attribute>: <value> - definiert den Wert des zu ändernden Attributes

Mit diesen Infos solltet Ihr jetzt in der Lage sein folgende dreiÄnderungen zu lesen.

(Tragt hier jeweils eure eigenen Werte ein)

dn: olcDatabase={2}hdb,cn=config
changetype: modify
replace: olcSuffix
olcSuffix: dc=YOURDOMAIN,dc=local

dn: olcDatabase={2}hdb,cn=config
changetype: modify
replace: olcRootDN
olcRootDN: cn=YOURADMINUSER,dc=YOURDOMAIN,dc=local

dn: olcDatabase={2}hdb,cn=config
changetype: modify
replace: olcRootPW
olcRootPW: {SSHA}mLWOOC88hfX1HH0l0mZQDhJjqHfgsBqi

Wir replacen in olcDatabase={2}hdb,cn=config die Werte von:

  • olcSuffix mit dc=YOURDOMAIN,dc=local
  • olcRootDN mit cn=YOURADMINUSER,dc=YOURDOMAIN,dc=local
  • olcRootPW mit {SSHA}mLWOOC88hfX1HH0l0mZQDhJjqHfgsBqi

Was ist dieses OLC?

OLC steht für on-line configuration und ermöglicht es Änderungen an dem LDAP Schema zu machen, ohne den Deamon neu starten zu müssen.

Historically OpenLDAP has been statically configured, that is, to make a change to the configuration the slapd.conf file was modified and slapd stopped and started. In the case of larger users this could take a considerable period of time and had become increasingly unacceptable as an operational method. OpenLDAP version 2.3 introduced an optional new feature whereby configuration may be performed at run-time using a DIT entry called cn=config. The feature is known by a varied and confusing number of terms including on-line configuration (OLC) (our favorite), zero down-time configuration, cn=config and slapd.d configuration.
https://www.zytrax.com/books/ldap/ch6/slapd-config.html

Um diese werte wie in der neu angelegten .ldif Datei beschrieben zu modifizieren, nutzen wir nun ldapmodify.

Ldapmodify - ein Werzeug zum hinzufügen und editieren von LDAP Einträgen

ldapmodify opens a connection to an LDAP server, binds, and modifies or adds entries. The entry information is read from standard input or from file through the use of the -f option.
ldapmodify manpage

Ldapmodify ist Teil des Paketes openldap-clients.

yum install openldap-clients

ldapmodify sagen wir mit -H, mit welcher URI es sich verbinden soll. In diesem Fall nutzen wir den lokalen Unix Socket, welcher laufen sollte.
Prüfen könnt ihr das folgendermaßen.

[root@openldap slapd.d]# ss -l -p |grep ldap
u_str  LISTEN     0      128    /var/run/ldapi 312152                * 0                     users:(("slapd",pid=15731,fd=7))

Mit -f geben wir an, dass es die Änderungen aus einem File eingelesen werden sollen.

Der Output sollte etwa so aussehen:

[root@openldap slapd.d]# ldapmodify -H ldapi:/// -f db.ldif
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
modifying entry "olcDatabase={2}hdb,cn=config"

modifying entry "olcDatabase={2}hdb,cn=config"

modifying entry "olcDatabase={2}hdb,cn=config"

Leseempfehlungen

LDAP for Rocket Scientists

Modifying Entries Using ldapmodify

Oracle® Identity Management User Reference - LDIF Format for Entries

Ubuntu Serverguide ab Seite 112


Flowerberry

Flowerberry ist der von mir frei erfundene Name für dieses Projekt.

Es geht darum Pflanzensensoren über einen Raspberry Pi auszulesen und die Daten in eine InfluxDB zu packen.

Diese wird dann an ein Garafana angeschlossen um die Daten zu visualisieren und Alarm zu schlagen, sollten die Sensoren erkennen, dass der Boden zu trocken ist oder die Pflanze zu kalt.

Diese Anleitung und das Projekt selbst basieren auf diesem Blogbeitrag.

Einkaufsliste

1x Raspberry Pi Zero W

(bis zu) 20x Flower Care Xiaomi Mi Flora 

Vorbereitung

Den Sensor einschalten

Packt die Sensoren aus und öffnet den ersten vorsichtig.

Nehmt einen Fingernagel, eine Plastikkarte oder ein Spezialwerkzeug und hebt den Deckel des Sensors leicht an.

Mi9.jpg

Fahrt dann an der Kante entlang, bis ihr die Kappe abnehmen könnt.

Mi10.jpg

Zieht dann an der Plastiklasche, um den Sensor zu aktivieren.

Mi11.jpg

Raspberry Pi

Gruneinrichtung

Zunächst installiert Ihr das Raspberry Pi OS (ehemals raspbian) Lite image.

dd if if=/Downloads/2020-05-27-raspios-buster-lite-armhf.zip of=/dev/YOUR_SD_CARD bs=1M status=progress

Sorgt dafür, dass er sich mit eurem Wifi verbindet und Ihr euch per SSH mit ihm verbinden könnt.

Wenn Ihr fault seit, schließt einfach einen Monitor und eine Tastatur an den Raspberry an.

Mi3 1.jpg

Mit dem commandlet raspi-config bekommt Ihr eine leicht verständliches pseudo-grafisches Konfigurationsmenü. 

Findet raus, welche IP Adresse der Pi in eurem Netzwerk bekommen hat und gebt ihm einen statischen Lease.

Meldet euch dann per SSH auf dem Gerät an, ändert das Passwort des Users, ladet euren SSH Key hoch, das übliche halt.

Benötigte Software installieren

Wir benutzten den XaiomiMi-Data-Collector um die Daten einzusammeln.

Klont euch also das Repository.

sudo apt update -y ; sudo apt upgrade -y; sudo apt autoremove -y; apt install git openvpn
git clone https://github.com/Zentris/XaiomiMi-Data-Collector

Installiert dann die benötigten Python bibliotheken.

sudo apt install python3-pip
sudo pip3 install paho-mqtt
sudo pip3 install influxdb
sudo pip3 install PyMySQL

Jetzt installieren wir eine lokale Datenbank, mit der das script arbeiten kann.

sudo apt install mariadb-server

SQL Datenbank einrichten

Meldet euch an der Datenbank an legt eine SQL Datenbank, einen User an und gebt dem User Rechte auf die Datenbank.

CREATE DATABASE flowerberry;
CREATE USER 'floweradmin'@'localhost' IDENTIFIED BY 'YOUR_PASSWORD_HERE';
GRANT ALL PRIVILEGES ON flowerberry.* TO 'floweradmin'@'localhost' IDENTIFIED BY 'YOUR_PASSWORD_HERE';
FLUSH PRIVILEGES;

Dafür sorgen, dass der Pi mit der InfluxDB reden kann

Sollten sich die InfluxDB und der Pi im gleichen Netzwerk befinden, kann dieser Punkt übersprungen werden.

Da das bei mir allerdings nicht der Fall ist, dokumentiere ich ihn mit.

An dieser Stelle möchte ich das Geniale Script openvpn-install empfehlen.

Es richtet auf einem Linux Server ein OpenVPN Gateway ein und bringt eine Zertifikatsverwaltung mit.

M13.png

Verschiebt dieses Zertifikat dann auf dem Pi nach /etc/openvpn/ und nennt es client.conf

sudo mv /home/pi/flowerchan.ovpn /etc/openvpn/client.conf

Legt dann die Datei /etc/systemd/system/multi-user.target.wants/openvpn@client.service mit folgendem Inhalt an, um ein systemd unit file zu erzeugen.

[Unit]
Description=OpenVPN connection to %i
PartOf=openvpn.service
ReloadPropagatedFrom=openvpn.service
Before=systemd-user-sessions.service
After=network-online.target
Wants=network-online.target
Documentation=man:openvpn(8)
Documentation=https://community.openvpn.net/openvpn/wiki/Openvpn24ManPage
Documentation=https://community.openvpn.net/openvpn/wiki/HOWTO

[Service]
Type=notify
PrivateTmp=true
WorkingDirectory=/etc/openvpn
ExecStart=/usr/sbin/openvpn --daemon ovpn-%i --status /run/openvpn/%i.status 10 --cd /etc/openvpn --config /etc/openvpn/%i.conf --writepid /run/openvpn/%i.pid
PIDFile=/run/openvpn/%i.pid
KillMode=process
ExecReload=/bin/kill -HUP $MAINPID
CapabilityBoundingSet=CAP_IPC_LOCK CAP_NET_ADMIN CAP_NET_BIND_SERVICE CAP_NET_RAW CAP_SETGID CAP_SETUID CAP_SYS_CHROOT CAP_DAC_OVERRIDE CAP_AUDIT_WRITE
LimitNPROC=100
DeviceAllow=/dev/null rw
DeviceAllow=/dev/net/tun rw
ProtectSystem=true
ProtectHome=true
RestartSec=5s
Restart=on-failure

[Install]
WantedBy=multi-user.target

Anschießend starten wir den service und schauen uns seinen Status an.

sudo systemctl start openvpn@client.service
sudo systemctl status openvpn@client.service

M14.png

Zuletzt müsst Ihr noch in /etc/default/openvpn die Zeile "AUTOSTART=ALL" einkommentieren:

Damit ist sichergestellt, dass der Pi sich wieder ins VPN einwählt, sollte er neu gestartet werden.

Konfiguration anpassen

Den Sensor finden

Meldet euch bei eurem Raspberry an und sucht nach der MAC Adresse eures Sensors.

1 sudo hcitool lescan

Mi12.png

Schreibt euch diese MAC auf und markiert euch den Sensor, damit ihr ihn später irgendwie zuordnen könnt.

Wiederholt diesen Vorgang für alle Sensoren.

Konfigurationsdatei anpassen

Ändert in der Datei /home/pi/XaiomiMi-Data-Collector/Raspi/config.cfg folgende Werte:

Eine IP die in eurem LAN erreichbar ist und die MAC Addressen der Sensoren.

pingip = <pinable address into our home network>
sens_1 = <mac of first sensor>
sens_2 = <mac of second sensor>
...

Die InfluxDB Zugangsdaten:

influxHost = <IP of your influx DB>
influxUser = <our admin user>
influxPassword = <our admin password>
influxDbName = <our influx db name for the measurement data>
influxDbUser = <our influx db user for the measurement data>
influxDbPassword = <our influx db password for the measurement data>
influxMeasurement = <our influx measurement section name>

Die Datenbank Zugangsdaten:

DbHost = 127.0.0.1
DbUser = floweradmin
DbPassword = YOUR_PASSWORD_HERE
DbName = flowerberry
DbTableName = Sensordaten

Sensordaten manuell auslesen

Geht nach /home/pi/XaiomiMi-Data-Collector/Raspi/ und ruft das python script XiaomiMiReader.py auf.

Mi15.png

ACHTUNG: es ist wichtig, dass ihr vorher in das Verzeichnis wechselt. Das script ist da sehr penibel und ihr könnt keinen absoluten oder relativen Pfad verwenden.

M16.png

Sensordaten automatisiert auslesen

Wegen der grade beschrieben Problematik, wenden wir allerdings einen kleinen Hack an.

Erzeugt die Datei /home/pi/XaiomiMi-Data-Collector/Raspi/hack.sh mit folgendem Inhalt.

#!/bin/sh

cd /home/pi/XaiomiMi-Data-Collector/Raspi
python3.7 XiaomiMiReader.py

Dann fügen der Datei /etc/crontab eine Zeile hinzu, mit der das Script einmal pro Minute ausgeführt und unsere Daten in die InfluxDB gepusht werden.

#Get all the flowery data :)

*<nowiki>*     * * *   root    /home/pi/XaiomiMi-Data-Collector/Raspi/hack.sh > /dev/null 2>&1</nowiki>

Grafana

Daten auslesen

Um die Daten nun anzeigen zu lassen, bauen wir uns ein Board in Grafana.

Hier wäre mal eine View die alle verfügbaren Daten für zwei Sensoren ausliest.

Bachtet, dass in der Fusszeile ein Zeitintervall von 1m ausgewählt ist.

M17.png

Für eine Vergleichsübersicht ist das ganz nett.

Hier mal die Daten über eine Woche.

M18.png

Allerdings vergleichen wir hier, wie mein Mathelehrer immer sagte "Äpfel mit Birnen".

Also bauen wir uns für alle Werte eigene Boards. 

Daten interpretieren

Hier mal beispielhaft die Query für Feuchtigkeit.

Auf der Linken Seite ist der Reiter "Visualsation" ausgewählt und ich habe die Achsbeschriftung auf "percent(0-100) gestellt.

Damit ergibt der Graph auch Sinn. Er zeigt den Feuchtigkeitsgehalt des Bodens in Prozent an. 

Lesenswerte Links zu dem Thema "was für Daten bekomme ich da eigentlich"

https://blog.endaq.com/how-light-sensors-work
https://www.lampenwelt.de/ratgeber/lux-einfach-erklaert.html
http://citrusindustry.net/2017/07/10/understanding-soil-moisture-sensor-data/

Alarme definieren

Damit Ihr eine Mail bekommt, wenn eure Blumen durstig sind, könnt Ihr folgendermaßen einen Alarm definieren.

Das sind Erfahrungswerte. Ich habe bei den Werten bereits mehrfach nachjustiert.

M20.png

Cheers,
Ori


Externe mit LUKS vollverschlüsselte Festplatte unter Ubuntu 20 mounten

Komfortabler Weise nimmt einem Ubuntu die meiste Arbeit bereits ab, wenn es um das Mounten verschlüsselter Platten geht.
Schließt man eine solche an, so begrüßt einen ein Passwort prompt und mountet dann die /boot partition

Die anderen Partitionen werden allerdings nicht gemountet.

Darum sehr Ihr auf der Platte erstmal nur den Kernel, die InitRD, Grub etc.
Um die anderen Partitionen zu mounten, macht zunächst ein lvscan um auf angeschlossenen Block Devices nach logical volumes zu suchen.

Ihr könnt sehen, dass es aktive, nicht gemountete LVMs gibt.
Mit vgchange -ay könnt Ihr die aktiven Volumegroups listen, dadurch bekommt Ihr die namen der LGs raus.

In /dev/mapper sind softlinks, die auf devices pointen.
Mountet dann das Device, dessen Softlink vom Namen her zu der Partition Passt, die Ihr mounten wollt.

Jetzt könnt Ihr auf die Daten der Partition zugreifen :)

Cheers,
Ori


Mounting external LUKS encrypted drive on Ubuntu 20

Conveniently in Ubuntu Desktop OS's if you connect an external whole disk encrypted drive, it will ask you to input a password and mount it.

So far so convenient.
However it does not mount all partitions, but ony the boot partition.

This is why you can only see the the kernel, the init ramdisk, grub etc.
To mount the other partitions first use lvscan to scan for logical volumes on all connected block devices.

You can see that one LG (logical group) is currently mounted, the other is not. Using vgchange -ay you can list the active volumegroups to get thier label.

The label is a softlink for a device. You need the devicename to mount the partition. Then check the content of /dev/mapper to see the device name.
Then create a mountpoint and mount the partition.

And now you can access the content of that partition :)

Cheers,
Ori


Daten per InfluxDB in Grafana abbilden

In diesem Artikel soll es darum gehen, wie man mit InfluxDB Daten in Grafana abbilden kann. Ich gehe davon aus, dass Ihr bereits eine bestehende Grafana Installation und eine InfluxDB habt, in die Ihr Daten kippen könnt.

Zum einsammeln der Daten benutzen wir Telegraf.
Die Installationsanleitung ist relativ straight forward.

Telegraf kommt mit diversen Plugins zum erheben von Daten daher.
Wir sehen uns das Modul input.exec an.

Die Daten die wir einsammeln werden sind Statistiken darüber, wieviele Karten in einem Kanboard in welchen Spalten eines Projektes liegen.

Kanboard kommt von Hause aus schon mit einem Tool zum erfassen dieser Daten namens CLI daher. Ein Beispiel Output von CLI wäre:

2020-03-20,3,9,1,0,0,13

Komma separiert stehen hier das Datum der Messung und die Werte wie viele Tickets sich in den einzelnen Spalten befinden.

Jetzt brauchen wir nur noch ein Script, welches diese Daten im InfluxDB Stil bereitstellt. InfluxDB arbetiet mit Series, also serien von Daten.

Eine Serie besteht dabei aus Messwerten.
Zusammen mit einem Zeitstempel bilden diese Daten dann einen Datenpunkt. Nähere Details dazu finden sich hier.

Hier wäre, wie der Datensatz für im InfluxDB Stil aussehen kann.

 kanban-project-23,host=kanban backlog=3,blocked=0,done=13,ready=9,review=0,wip=1 1584685951000000000

"kanban-project-1" ist die Serie
"host=kanban" ist ein der Serie zugeordneter Tagset (die selbe Serie kann für unterschiedliche Dinge gemessen werden.
Eine leerstelle, gefolgt von Key=Value pairs.
Eine leerstelle, gefolgt von einem epoch Zeitstempel (Millisekunden seit dem 01.01.1970)

Jetzt bräuchte man nur noch ein script, welches die Daten in diesem Format bereitstellt.

Gestatten, project-column-stats.sh, welches als ersten Parameter die Projekt ID erwartet.

Telegraf kann dieses script jetzt ausführen, indem Ihr der /etc/telegraf/telegraf.conf auf dem Client folgende Zeilen hinzufügt.

 [[inputs.exec]]
    commands = ["/path/to/project-column-stats.sh <PROJECT ID>"]
    data_format = "influx"

ACHTUNG: Das Script muss für den User Telegraf ausführbar sein!

Wenn Ihr alles richtig gemacht habt, könnt Ihr jetzt in Grafana eine Query für eure Daten schreiben.

SELECT mean("backlog") as backlog, mean("wip") as wip, mean("blocked") as blocked, mean("ready") as ready, mean("review") as review, mean("done") as done FROM "autogen"."kanban-project-14" WHERE $timeFilter GROUP BY time($__interval) fill(null)

Das Ergebnis sieht dann so aus.


[regex] SED's gierige kleine quantifier

Ein Problem über das ich im Kontext REGEX öfter gestoßen bin.

Sed beherscht leider keine non greedy quantifiers.
Bedeutet, dass mit sed kein suchmuster geschrieben werden kann, welches nur auf den ersten Treffer eines Suchmusters wirkt. Es wird immer der letzte treffer des Suchmusters greifen.

In perl würde das Suchmuster ^.*?XYZ alles von Beginn der Zeile bis zum ersten auftauchen von XYZ treffen.
Ich suche noch eine Passende AWK Syntax dafür...


3 node cluster mit pacemaker CentOS Minimal

In diesem Atrikel möchte ich die Einrichtung und Verwaltung eines Pacemaker / Corosync 3 Node Cluster erklären.

Die Idee von Pacemaker ist es, Ressourcen auf mehreren Servern hochverfügbar zu halten. Ressourcen können hier sowohl Dienste wie ein Webserver oder eine Datenbank, aber auch eine IP Adresse sein.

In diesem Beispiel ist die Ressource ein Apache Webserver auf Ubuntu 18.04.

Installation

(Führt die Schritte auf allen nodes aus)
Zunächst installieren wir das die Pakete pacemaker, pcs und crmsh.

yum install -y pcs

Startet pcsd (pacemaker corosync daemon) und aktiviert ihn, damit er auch nach einem Neustart wieder zur Verfügung steht.

sudo systemctl start pcsd
sudo systemctl enable pcsd

Pacemaker kommt mit dem user hacluster daher.
Diesen könnt ihr in euerer /etc/passwd sehen.

Dieser user wird verwendet um den Node in einem Cluster zu authentifizieren. Gebt ihm daher mit passwd ein neues passwort.

Damit der Pacemaker Cluster eingerichtet und alle Nodes zum Cluster werden können müssen ein paar Dingege gegeben sein:
- Die Nodes müssen sich sich gegenseitig per DNS auflösen können
- Die nodes müssen sich erreichen können
- Die Nodes müssen traffic auf Port 2224 zulassen

Tragt also zunächst die IPs und Hostnames die /etc/hosts Datei ein…

... und prüft, dass Ihr die anderen Hosts erreichen könnt.

Fügt jetzt noch eine IP Tables Regel hinzu, welche 2224 für eingehenden Traffic öffnet.

sudo iptables -A INPUT -p tcp -m tcp --dport 2224 -j ACCEPT
sudo iptables -A INPUT -p tcp -m tcp --dport 3121 -j ACCEPT
sudo iptables -A INPUT -p udp -m udp --dport 5404 -j ACCEPT
sudo iptables -A INPUT -p udp -m udp --dport 5405 -j ACCEPT
sudo iptables -A INPUT -p tcp -m tcp --dport 21064 -j ACCEPT

Cluster einrichten

Wir werden nun erstmal die Nodes untereinander authentifizieren.

sudo pcs cluster auth [node1] [node2] [node3]

(Sollte hierbei was schief gehen, könnt ihr mit pcs pscd clear-auth [node] auths wieder aufheben)

Diese Autentifizierungen sind unidirektional, die Nodes sind also untereinander authentifiziert. Das könnt ihr sehen, wenn ihr auf einem anderen Node versucht die Authentifizierung vorzunehmen.

Die Authorizierungen unseres 3 Node Clusters untereinander verhalten sich jetzt ungefähr so.

Das macht aber noch keinen Cluster, sondern erstmal nur drei untereinander mit pcs authorizierte Nodes. Also erstellen wir jetzt einen Cluster.

sudo pcs cluster setup --name [name] [node] [node] [node]

Solltet ihr meldungen erhalten, ein node wäre bereits in einem cluster, führ auf diesem pcs cluster destroy aus.

 


3 node cluster mit pacemaker/corosync Ubuntu

In diesem Atrikel möchte ich die Einrichtung und Verwaltung eines Pacemaker / Corosync 3 Node Cluster erklären.

Die Idee von Pacemaker ist es, Ressourcen auf mehreren Servern hochverfügbar zu halten. Ressourcen können hier sowohl Dienste wie ein Webserver oder eine Datenbank, aber auch eine IP Adresse sein.

In diesem Beispiel ist die Ressource ein Apache Webserver auf Ubuntu 18.04.

Installation

(Führt die Schritte auf allen nodes aus)
Zunächst installieren wir die Pakete pacemaker, pcs und crmsh.

sudo apt install -y pacemaker pcs crmsh

Startet pcsd (pacemaker corosync daemon) und aktiviert ihn, damit er auch nach einem Neustart wieder zur Verfügung steht.

sudo systemctl start pcsd
sudo systemctl enable pcsd

Pacemaker kommt mit dem user hacluster daher.
Diesen könnt ihr in euerer /etc/passwd sehen.

Dieser user wird verwendet um den Node in einem Cluster zu authentifizieren. Gebt ihm daher mit passwd ein neues passwort.

Damit der Pacemaker Cluster eingerichtet und alle Nodes zum Cluster werden können müssen ein paar Dingege gegeben sein:
- Die Nodes müssen sich sich gegenseitig per DNS auflösen können
- Die nodes müssen sich erreichen können
- Die Nodes müssen traffic auf Port 2224 zulassen

Tragt also zunächst die IPs und Hostnames die /etc/hosts Datei ein…

... und prüft, dass Ihr die anderen Hosts erreichen könnt.

Fügt jetzt noch eine IP Tables Regel hinzu, welche 2224 für eingehenden Traffic öffnet.

sudo iptables -A INPUT -p tcp -m tcp --dport 2224 -j ACCEPT
sudo iptables -A INPUT -p tcp -m tcp --dport 3121 -j ACCEPT
sudo iptables -A INPUT -p udp -m udp --dport 5404 -j ACCEPT
sudo iptables -A INPUT -p udp -m udp --dport 5405 -j ACCEPT
sudo iptables -A INPUT -p tcp -m tcp --dport 21064 -j ACCEPT

Cluster einrichten

Wir werden nun erstmal die Nodes untereinander authentifizieren.

sudo pcs cluster auth [node1] [node2] [node3]

(Sollte hierbei was schief gehen, könnt ihr mit pcs pscd clear-auth [node] auths wieder aufheben)

Diese Autentifizierungen sind unidirektional, die Nodes sind also untereinander authentifiziert. Das könnt ihr sehen, wenn ihr auf einem anderen Node versucht die Authentifizierung vorzunehmen.

Die Authorizierungen unseres 3 Node Clusters untereinander verhalten sich jetzt ungefähr so.

Das macht aber noch keinen Cluster, sondern erstmal nur drei untereinander mit pcs authorizierte Nodes. Also erstellen wir jetzt einen Cluster.

sudo pcs cluster setup --name [name] [node] [node] [node]

Solltet ihr meldungen erhalten, ein node wäre bereits in einem cluster, führ auf diesem pcs cluster destroy aus.