www.lnx21.de

Proxmox VE 4/5 und DRBD 9

Für die Virtualisierung von Linux-Servern setzen wir auf der Arbeit Proxmox VE 4 in Kombination mit DRBD 9 ein.
Grundsätzlich eine sehr schöne Kombination, Proxmox nutzt KVM als Basis und setzt darauf eine Web-GUI um die Verwaltung zu erleichtern. DRBD sorgt für die syncrone Replikation zwischen den beiden Nodes.

Auf unseren neuen Systemen wollten wir allerdings direkt Proxmox VE 5 einsetzen. Also flott die Standard-Installation ausgeführt und DRBD installiert. Soweit so gut…
Bei der Initialisierung traf ich allerdings auf folgenden Fehler:

root@XYZ:~# drbdmanage init 172.19.XXX.XXX

 You are going to initialize a new drbdmanage cluster.
 CAUTION! Note that:
 * Any previous drbdmanage cluster information may be removed
 * Any remaining resources managed by a previous drbdmanage installationthat still exist on this system will no longer be managed by drbdmanage

 Confirm:

 yes/no: yes
 Error: External command failed:
 drbdsetup new-resource .drbdctrl 0
 Command output:
 (stdout)
 Command exited with exit_code 20

 Initialization failed
root@XYZ:~#

Ich habe also ein wenig gesucht und feststellen können, dass „drbdmanage“ einen potentiell falschen Aufruf von „drbdsetup“ macht. Das kam mir sehr merkwürdig vor, also habe ich mal auf der Mailing-List gefragt:
Dort kam raus, das in der Standard Installation von Proxmox lediglich das Kernel-Modul für DRBD 8.4 dabei ist. Dort gibt es „drbdmanage“ noch gar nicht…
Zum Glück ist das kein großes Problem denn die Kollegen von Linbit bieten hier in Ihrem Repo ein DKMS-Paket mit an. Also wie folgt schnell zu lösen:

root@XYZ:~# apt install drbd-dkms pve-headers
root@XYZ:~# reboot

Nach dem Neustart wird nun das Modul passend geladen:

root@XYZ:~# modinfo drbd
filename: /lib/modules/4.13.4-1-pve/updates/dkms/drbd.ko
alias: block-major-147-*
license: GPL
version: 9.0.9-1
description: drbd - Distributed Replicated Block Device v9.0.9-1
author: Philipp Reisner <phil@linbit.com>, Lars Ellenberg <lars@linbit.com>
srcversion: EF468AECF68C9A926BB53A7
depends: libcrc32c
name: drbd
vermagic: 4.13.4-1-pve SMP mod_unload modversions
parm: minor_count:Approximate number of drbd devices (1-255) (uint)
parm: disable_sendpage:bool
parm: allow_oos:DONT USE! (bool)
parm: enable_faults:int
parm: fault_rate:int
parm: fault_count:int
parm: fault_devs:int
parm: two_phase_commit_fail:int
parm: usermode_helper:string

Jetzt kann das Cluster gemäß Doku initialisiert werden und verrichtet sauber seinen Dienst.
Die Gründe, warum DRBD aus dem Proxmox VE-Kernel entfernt wurde ist für Interessierte hier nach zu lesen:
https://forum.proxmox.com/threads/drbdmanage-license-change.30404/

Ubuntu DNS-Auflösung Sub-Subdomain

Kürzlich traf ich auf der Arbeit auf ein Problem mit Ubuntu Mate:

Wir arbeiten innerhalb des Unternehmens mit Sub-Subdomains, also z.B. servername.standort.firma.de/eu. Da ich nunmal faul bin, möchte ich gerne die Systeme über servername.standort ansprechen (und brauche auch somit auch meine Searchdomains).
Dies führte aber in der Namensauflösung zu einem Fehler. Also begab ich mich auf die Suche und fand den „Fehler“ in der /etc/nsswitch.conf. Dort sieht der Standard so aus:

hosts:          files resolve [!UNAVAIL=return] mdns4_minimal [NOTFOUND=return] dns

Dies bewirkt, dass zuerst versucht wird den Namen aufzulösen ohne die Searchdomains durchzugehen. Ist die Auflösung nicht erfolgreich, so wird ein Fehler zurückgegeben.
Um nun also das gewünschte Verhalten zu erreichen, ändere ich die Konfiguration wie folgt ab:

hosts:          files dns resolve [!UNAVAIL=return] mdns4_minimal [NOTFOUND=return]

Somit versucht der Client die Namen inkl. Searchdomain zuerst über unseren DNS-Server aufzulösen. Damit habe ich mein gewünschtes Verhalten erreicht.

nginx Access-Logfiles anonymisieren

In einer Unterhaltung mit meinem Kollegen kamen wir auf das Thema der Logfile-Anonymisierung zu sprechen. Uns war beiden die Vorgehensweise für den Apache2 bekannt, wussten jedoch nicht wie die Logfiles des nginx zu anonymisieren sind.

Nach etwas Suche im Internet bin ich dazu auf einen interessanten Artikel bei stackoverflow.com gestoßen:

http://stackoverflow.com/questions/6477239/anonymize-ip-logging-in-nginx

In diesem Artikel werden die ersten 24 Bit der IPv4-Adresse (auch /24) und die ersten 32 Bit der IPv6-Adresse ( auch /32) gespeichert. Dies möchte ich allerdings etwas verändern und nur ein /16 der IPv4-Adresse sehen. Das /32 der IPv6-Adresse reicht hingegen aus.
Also musste ich die Konfiguration an meine Wünsche anpassen. Hier der Ausschnitt aus meiner Datei ( /etc/nginx/conf.d/anonymized.conf )

map $remote_addr $ip_anonym1 {
default 0.0.0;
"~(?P<ip>(\d+)\.(\d+))\.(\d+)\.\d+" $ip;
"~(?P<ip>[^:]+:[^:]+):" $ip;
}

map $remote_addr $ip_anonym2 {
default .0.0;
"~(?P<ip>(\d+)\.(\d+)\.(\d+))\.\d+" .0.0;
"~(?P<ip>[^:]+:[^:]+):" ::;
}

map $ip_anonym1$ip_anonym2 $ip_anonymized {
default 0.0.0.0;
"~(?P<ip>.*)" $ip;
}

log_format anonymized '$ip_anonymized - $remote_user [$time_local] '
'"$request" $status $body_bytes_sent '
'"$http_referer" "$http_user_agent"';

Damit lege ich den Grundstein, um das Loglevel ( nur für die access-logs! ) in den Einstellungen der vServer anzupassen. Es muss lediglich das Schlüsselwort „anonymized“ angegeben werden.

server {
......
access_log  /var/log/nginx/access.log anonymized;
......
}

Nachdem der Server nun einmal reloaded wurde, ist der Unterschied innerhalb der Logfiles sofort zu erkennen.

78.94.0.0 - - [24/Jan/2017:19:51:48 +0100] ....
2a02:908:: - - [24/Jan/2017:19:51:57 +0100] ....

Bei einem abschließenden „whois“ auf die Adressen kann ich nun nur noch erkennen, dass es sich um einen Unitymedia-Anschluss handelt. Eine genaue Benutzerzuordnung ist nun nicht mehr möglich.

DNS Certification Authority Authorization (DNS CAA)

Nachdem ich letzte Woche meine Website vom Apache2 auf den nginx-Webserver migriert habe, hatte ich wie immer einmal meine SSL-Parameter auf https://www.ssllabs.com/ssltest/index.html gecheckt:

Als ich meine Zertifikat prüfte fiel mir auf, dass ich keinen DNS CAA Record für meine Domain habe:

Über diesen Typ Record hatte ich vorher noch nie etwas gehört. Also machte ich mich auf die Suche und fand das passende RFC (RFC 6844) von Januar 2013.
Dort wird definiert, dass der Record dafür gedacht ist den Certificate Authorities (CAs) mitzuteilen, welche CA ein Zertifikat für meine Domain ausstellen darf. Damit soll also der Missbrauch mit unautorisierten Zertifikaten eingedämmt werden.

Der CAA-Record ist in den meisten DNS-Servern (z.B. BIND oder PowerDNS) implementiert und sieht wie folgt aus:

CAA <flags> <tag> <value>

flags: Ein vorzeichenloser Integer zwischen 0 – 255
tag: String, definiert welchen Typ von Zertifikat die CA ausstellen darf. Zulässige Typen sind „issue“ (normales Zertifikat) ,“issuewild“ (Wildcard Zertifikat) oder „iodef“ (URL für Missbrauchsmeldungen).
value: String, Name bzw. URL der CA

Hier sind einmal zwei Beispiele:

lnx21.de.    CAA 0 issue "letsencrypt.org"

lnx21.de.    CAA 0 issuewild "thawte.com"

Mit Hilfe dieser beiden Records ist es Let’s Encrypt erlaubt normale, einfache Zertifikate auszustellen. Thawte hingegen darf Wildcard-Zertifikate ausstellen.

Das ganze klingt also auf den ersten Blick sehr sinnvoll. Leider wird der Record aber noch nicht von allen CAs überprüft bzw. beachtet. Daher ist der Einsatzzweck momentan noch recht begrenzt. Sollten sich aber weitere CAs anschließen, so ist dies denke ich ein sehr wirkungsvolles und zugleich einfaches Mittel gegen den Missbrauch mit Zertifikaten.