Let’s Encrypt Zertifikate sind inzwischen fürs Webhosting weit verbreitet: Die Akzeptanz ist hervorragend, die Erstellung sowie regelmäßigen Verlängerungen sind gut automatisierbar. Außer bei den inzwischen angebotenen Wildcard-Zertifikaten. Hier ist Handarbeit angesagt. Oder doch nicht? (mehr …)
fail2ban ist ein sehr, sehr praktisches Werkzeug (http://www.fail2ban.org). Und jeder, der fail2ban regelmäßig nutzt hat sich selbst schon einmal ausgesperrt. Gut dem, der eine statische IP hat und diese via ignoreip auf die Whitelist gesetzt hat (http://www.fail2ban.org/wiki/index.php/Whitelist). Pech hingegen für mich, der bei der deutschen Tel... unter Vertrag ist, privat einen DSL Anschluss hat und nicht bereit ist die extrem hohen Kosten für einen Vertrag mit statischer IP zu zahlen.
Das Problem dabei ist, dass dynamische IP-Adressen sich so dann und wann ändern. Nur was trägt man in einer Witelist ein die statischer Natur ist? So wie von fail2ban verwendet?
Was ich hingegen habe ist einen passenden Eintrag ins DNS der auf meine wechselnde IP zeigt (DynDNS oder wie auch immer ihr das Kind nennen wollt). Also fix ein Skript erstellt welches im tmp-Verzeichnis die dazugehörige IP puffert. Sobald sich diese ändert wird eine passende fail2ban local Config erstellt und die komplette Config neu eingelesen. Da ich ebenfalls auf eine Leitung mit statischer IP-Adresse zugriff habe wird ignoreip eben mit diesem statischen Teil befüllt und anschließend um den dynamischen Teil erweitert.
#!/bin/bash
#
# Whitelisted eine dynamische IP in Fail2ban
#
IGNALWAYS="127.0.0.1/8 ::1 193.nn.mm.0/24"
IGNDYN="dyn.gehirn-mag.net"
IGNFILE="/etc/fail2ban/jail.d/ignoreip.local"
TMPFILE="/tmp/fail2ban-dynip"
# Suche nach aktueller IP sowie gepufferter IP
CURIP=$($(which dig) +short $IGNDYN)
[ -f $TMPFILE ] && OLDIP=$(cat $TMPFILE) || OLDIP="--unknown--"
echo "aktuelle IP: $CURIP gepufferte IP: $OLDIP"
# Falls IPs verschieden ignoreip neu schreiben
if [ $CURIP != $OLDIP ]; then
echo -n "Ändere ignoreip: "
echo $CURIP > $TMPFILE
echo -e "# written by $0 ad $(date)\\n\\n[DEFAULT]\\nignoreip = $IGNALWAYS $CURIP\\n" > $IGNFILE
$(which fail2ban-client) reload
# Debug
$(which fail2ban-client) --dp | mail -s "$(hostname) fail2ban-dynip $CURIP" ...@gehirn-mag.net
fi
Falls Du weißt welchen DNS-Server Du fragen musst kannst Du Zeile 15 entsprechend ergänzen. Sowie sich die IP ändert lasse ich mir via Email die aktuelle fail2ban Konfig senden (Zeile 26). Wer das nicht will nimmt diese Zeile einfach raus. Was jetzt noch fehlt ist der regelmäßige Aufruf. Ich selbst verwende dazu folgenden cron Eintrag welcher alle 15 Minuten läuft:
# Fail2ban: die private IP auf die Whitelist setzen */15 * * * * /usr/local/bin/fail2ban-ignoreip.sh 2>&1 | /usr/bin/logger -t fail2ban-dynip
Fertig, das war es 🙂
Das Monitoring des Arbeitsspeichers eines Linux-Systems ist mühselig: Der physikalische RAM ist immer voll, die Auslagerungsdatei alleine betrachte keine wirklich genaue Aussage.
Also mal wieder Monitoring. Du merkst schon, dass ist ein Thema das mich immer wieder beschäftigt. Ein Dauerbrenner. Und immer wieder erstaunlich: Es gibt schon so viele Checks. Einige sind richtig gut. Und dennoch können einige davon noch weiter verbessert werden. Vieles fehlt dennoch. Oder die Dinge wurden nicht tief genug ausgewertet. Genauso erging es mir bei der vordergründig simplen Frage: "Wie viel des Arbeitsspeichers eines Linux-Servers ist denn tatsächlich noch frei?"
Es ist nun mal so, dass auf einem Linux Server sobald dieser etwas zu tun hat der physikalische Arbeitsspeicher fast immer voll ist. Buffers und Festplattencache füllen, sinnvollerweise, den eigentlichen freien Speicher fast komplett aus. Eine Betrachtung der noch freien Bytes? Bringt nichts da keine sinnvolle Aussage möglich. Freie Bytes zuzüglich Buffers und Cache als Summe betrachtet? Schon besser. Aber nicht wirklich gut. Den diese Summe könnte immer noch kleiner als der belegte Bereich im Swap sein.
Eine gern genommene Notlösung da der RAM eh immer voll ist: Die reine Betrachtung des Swaps. Wenn dieser sich füllt hat der Server zu wenig RAM. Das mag für viele Systeme soweit ganz gut passen. Aber genau ist was anderes und was ist mit denen wo das so nicht stimmt? Ein Server bei dem zwar der Swap sehr voll ist, die Summe von Buffers, Festplattencache und physikalisch frei aber um etliches größer? Das kommt öfters vor als man zunächst denken mag. Stichwort "swappiness" falls Du danach suchen magst 😉
Dieser Check hat schon ein paar Jahre hinter sich, funktioniert aber immer noch sehr gut. Und da mir vor kurzem eine Frage in genau diese Richtung gestellt wurde habe ich den alten Quellcode genommen, etwas aufgehübscht, MIT-Lizenz rein und frei zur Verfügung gestellt. Und so sieht das Ergebnis in Icinga aus - inkl. dem passenden pnp4nagios Template:
extmem in icingaweb2
extmem performance data
Ok, das rechte Bild mit den Performance-Daten mag nicht ganz perfekt sein: Der obere Bereich des Swaps ist fast leer. Aber als Beispiel reicht es trotzdem: Unten ist der physikalische Teil aufgelistet, darüber der Swap-Bereich. Die Limit-Angabe für Warning und Critical ist möglich und betrachtet das prozentuale Verhältnis zwischen "belegt" sowie "frei" zuzüglich Buffers und Cache.
Auch dieser Check ist sicherlich alles andere als perfekt. Aber er ist deutlich näher dran als die einzelne Betrachtung von RAM und Swap. Vor allem die Darstellung der Performance-Daten in denen die Gesamtsumme des Speichers dargestellt wird lässt über längere Zeiträume betrachtet eindeutige Tendenzen erkennen. Bei den meisten von mir verwalteten Linux-Servern ist inzwischen dieser Check installiert und wird immer wieder gerne hergenommen sobald eine entsprechende Auswertung der Serverlast benötigt wird.
Hier findest Du check_extmem auf GitLab: https://gitlab.com/Gehirn-Mag.net/icinga-and-nagios-plugins/tree/master/linux/check_extmem
Ich habe zuhause an unserem Internet-Router eine USB-Platte angeschlossen welche als einfache Datenablage oder zum Datenaustausch zwischen den Familienmitgliedern dient. Zwar könnte ich mich von Linux aus jedes mal auf diese Platte sehr leicht von Hand über den grafischen Dateibrowser verbinden, dass bringt aber nichts an der Konsole. Hier muss also eine komfortablere Lösung her.
Ich hätte einen entsprechenden Eintrag unter /etc/fstab aufnehmen können für diese Freigabe. Jedoch funktioniert dies nur wenn ich mit meinem Notebook wirklich zuhause bin. Unterwegs gäbe es entsprechende Fehler da die Platte nicht erreichbar ist. Ok, die fstab Option noauto hätte eine Besserung gebracht. Nur müsste ich hierfür die Platte jedes mal vor Benutzung von Hand einbinden. Das geht sicherlich noch besser. So in der Art, dass die Platte nur dann verbunden wird sobald ich tatsächlich zuhause bin. Also die Suchmaschine meines Vertrauens angeworfen um erste Hinweise zur Lösung zu suchen. Fündig geworden bin ich in der man page von mount:
_netdevThe filesystem resides on a device that requires network access(used to prevent the system from attempting to mount these
filesystems until the network has been enabled on the system).
Na das passt doch wunderbar! Die fertige Zeile für die fstab sieht dann wie folgt aus:
# Mein privater Router
//router/nas /media/router cifs rw,vers=1.0,_netdev,user=<user>,password=<password>,uid=steffen,gid=steffen 0 0
Zusätzlich habe ich noch vers=1.0 angegeben um auf die CIFS-Version 1.0 zu wechseln da dies deutlich weniger Probleme bei meinem Router macht. Wer das Passwort für die Freigabe lieber an einer anderen Stelle als in der fstab stehen haben möchte sollte sich in der man page von mount.cifs die Option credentials ansehen. In der selben Datei finden sich auch weitere, ausführlichere Erklärungen zur vorher festgelegten Version.
Diese Lösung funktioniert genauso wie erhofft: Sobald ich zuhause bin ist unter meiner Benutzerkennung die Platte des Routers eingebunden. Bin ich unterwegs fehlt diese - ohne jegliche Fehlermeldungen von nicht erreichbaren Netzlaufwerken. So soll es sein 🙂