Kategorien
Linux

Unifi Controller – Restore von einem anderen System bzw. Backup

Ein Backup zu haben tut gut, allerdings nur wenn man auch weiß wie man’s wieder einspielt! 🙂

Die Unifi Hilfe und auch das Forum bieten leider relativ wenig Informationen dazu wie man ein mit dem Controller erstelltes Backup (findet sich gewöhnlich unter /var/lib/unifi/backup bzw. /var/lib/unifi/backup/autobackup und hat die Endung .unf) wieder einspielt.

Nach einer frischen Installation der Controller Software kann man am Startbildschirm auswählen eine vorhandene Sicherung ein zu spielen, der upload vom lokalen PC hat bei mir aufgrund der Größe des Backups nicht funktioniert. Und es steht auch nicht immer das gesamte /var/lib/unifi Verzeichnis zur Verfügung – wer also nur die „unf“ Datei hat geht wie folgt vor:

Datei Backup Datei z.B. „autobackup_5.13.32_20200806_2200_1596319200003.unf“ manuell in das Verzeichnis /var/lib/unifi/backup/autobackup/ kopieren und eine passende „autobackup_meta.json“ Datei im selben Verzeichnis erstellen.

Diese hat folgenden Inhalt:

{„autobackup_5.13.32_20200806_2200_1596319200003.unf“:{„version“:“5.13.32″,“time“:1596319200003,“datetime“:“2020-08-01T22:00:00Z“,“format“:“bson“,“days“:90,“size“:6463895536}}

Anschließend erkennt der Unifi Controller das Backup und bietet es direkt für den Restore an!

Bei einer Datenmenge von 6,1 GB kann man sich dann auch auf einem flotten System schon mal eine längere Pause gönnen, besser mit Stunden rechnen…! 🙂

Damit kann man dann auch ein Backup eines Controllers der mit einer älteren Mongo-DB gelaufen ist, problemlos in ein aktuelles Ubuntu System mit Mongo-DB 3.6.9 einspielen.

Zur Installation des Unifi Controllers empfehle ich übrigens das Script von Glenn R.

Kategorien
Linux Sicherheit

Ubuntu 20.04 übersiedelt iptables!

Wer in irgendwelchen Scripten iptables im Einsatz hat, der sollte beim Upgrade von Ubuntu auf die Version 20.04 achtgeben!

Früher fand man iptables unter /sbin/iptables – seit der Version 20.04 findet sich das Selbe im Verzeichnis /usr/sbin/!

Somit sollte man nach Abschluss des Upgrades nicht vergessen entsprechend den Pfad in den eigenen Scripten anzupassen.

Klingt jetzt nach einer echten Kleinigkeit, die Auswirkungen können allerdings fatal sein!!! 🙂

Kategorien
Linux

Die Bash und IFS – Zeilenschaltungen als Feldtrenner

Heute habe ich mal wieder etwas gelernt, wie eigentlich jeden Tag! 🙂

Mit der Variable IFS kann man in der Bash den Feldtrenner angeben, da ich als Feldtrenner die Zeilenschaltung erkennen wollte habe ich ihn auf „\n“ gesetzt.

Das klappt so lange im String kein „n“ enthalten ist!


Sobald aber im String ein „n“ enthalten ist wird dieses auch als Trenner erkannt und entsprechend passt das Ergebnis dann nicht mehr:

Die Lösung des Problems ist folgende:

IFS=$’\n‘

Damit klappt es dann wie gewünscht:

Kategorien
Linux Sicherheit

Nginx User Authentifizierung mit pam_script

Eigentlich wäre pam_script dazu gedacht nach erfolgreicher Anmeldung ein Script auszuführen welches irgendwelche Änderungen oder Anpassungen vornimmt. Zumindest lese ich das so aus der Man-Page… 🙂

Nachdem Nginx in Sachen Authentifizierung dem Apache doch an einigen Stellen hinterher hinkt, habe ich mich nach einer Lösung umgesehen um für eine Web-Applikation ein einfaches Anmeldesystem zu bauen welches in weiterer Folge dann auch die Möglichkeit bieten soll dass der User das Kennwort selbst verwaltet. Die Kennwörter sollen in einer MySQL Datenbank gespeichert werden bzw. nur deren Hashes.

Nach längerer erfolgloser Suche habe ich mir folgende Lösung selbst zusammen gezimmert, zuerst wird in der nginx-Config des betroffenen Webhost folgendes eingefügt:

location ^~ /test/ {
auth_pam „Please specify login and password“;
auth_pam_service_name „nginx-test“;
auth_pam_set_pam_env on;
}

Der „auth_pam_service_name“ muss mit dem Namen der Datei in /etc/pam.d/ überein stimmen – also nginx-test, dieses sieht wie folgt aus:

auth    required    pam_script.so expose_authtok dir=/usr/share/libpam-script/pam-script.d/test/
account required    pam_permit.so

Im entsprechenden Verzeichnis „/usr/share/libpam-script/pam-script.d/test/
“ findet sich dann das eigentliche Script welches sich um die Authentifizierung kümmert – pam_script_auth und dieses sieht wie folgt aus:

#!/bin/bash

SID=$(echo $PAM_SERVICE|awk -F ’nginx-‚ ‚{print $2}‘)
PASSWORD=$(cat)

MD5USER=$(echo „$PAM_USER“|md5sum|awk ‚{print $1}‘)
MD5PASS=$(echo „$PAM_AUTHTOK“|md5sum|awk ‚{print $1}‘)

AUTHOK=$(mysql -s -u root -pmysqlkennwort testdb01 -e „SELECT count(*) FROM test_users WHERE sid=\“$SID\“ AND md5uname=\“$MD5USER\“ AND md5p
asswd=\“$MD5PASS\““)

if [ „X$AUTHOK“ == „X1“ ]; then
       exit 0
else
       exit 1
fi

Vom Aufbau recht einfach gehalten, „SID“ ist quasi die Service ID – und diese hole ich mir vom „nginx-test“ indem ich „nginx-“ einfach wegschneide (dient der Erkennung von welchem Webhost die Anmeldung kam – es wird für jeden Webhost eine eigene verwendet!). User und Kennwort verarbeite ich als MD5SUM (man könnte hier auch sha256sum oder sha512sum verwenden), dadurch vermeide ich Probleme die es beim Select geben könnte!

Der Select wird dann auf eine Tabelle los gelassen deren Inhalt im einfachsten Fall einfach nur aus drei Feldern besteht – der „SID“, dem Benutzer-Namen als MD5 Hash und dem Kennwort als MD5 Hash. In den entsprechenden Feldern „sid“, „md5uname“ und „md5passwd“.

Wird ein User gefunden und somit 1 zurück gegeben, dann beendet sich das Script mit dem Rückgabewert „0“ welches ein Login zu lässt. In allen anderen Fällen gibt es ein „1“ zurück und somit ist der Login fehlgeschlagen.

Die Lösung habe ich in gut 30 Minuten zusammengezimmert und sie funktioniert soweit mal, mich würde jetzt interessieren ob ihr hier irgendwelche Sicherheitsbedenken habt!?

Kategorien
Linux Sicherheit

Rsync Backup Script mit ZFS/EXT4 Unterstützung und Infomail für Remote und lokale Systeme

Seit Jahren nutze ich eine Rsync Lösung zum Sichern von Servern die in der Cloud liegen oder keinen direkten Zugriff auf meine Sicherungsserver haben. Bis vor kurzem habe ich damit generell alle Linux Systeme gesichert, bei jenen die direkten Zugriff auf ein NFS oder SMB Share haben bin ich inzwischen auf den Veeam Backup Agent Free umgesteigen. Der leistet hier gute Dienste.

Meine Cloud Server sichere ich allerdings mit einem Rsync Script auf meinen zentralen Backup Server, ich habe gerne alle meine wichtigen Daten bei mir in guten Händen und kümmere mich um mein 3-2-1 Backup lieber selbst als dass ich alles einem Hoster anvertraue! 🙂

Jetzt war es mal wieder an der Zeit etwas am Backup Script zu verändern und bei der Gelegenheit habe ich es gleich komplett umgeschrieben. Was mir bei anderen Lösungen die ich gefunden habe gefehlt hat ist das Auswerten der Rückgabewerte vom rsync Befehl und darauf basierend eine entsprechende Info über den Erfolg oder Misserfolg der Sicherung.

Ebenso hat kaum ein Script eine Unterstützung für Medien die mit ZFS formatiert wurden eingebaut, da ich die Kompression von ZFS nutzen wollte habe ich das für mein Script implementiert.

Die Lösung besteht im Grunde aus folgenden Dateien:

Die Datei backup.config beinhaltet die allgemeine Konfiguration, wer soll das Infomail erhalten, Absenderadresse, Backupmedium, Dateisystemtyp,…
Welche Systeme gesichert werden sollen, wohin die Sicherung geht, wie lange die Sicherung vorgehalten wird, welche Dateien nicht gesichert werden und über welchen Port die SSH Verbindung zum System aufgebaut wird – das steht in der Datei backup-source.config.
Das Template File rsync_mail_template.html dient als Vorlage für das Infomail und das eigentliche Backup Script ist die Datei backup-rsync-remote.sh.

Mein exclude-File schaut wie folgt aus:

/proc
/dev
/media
/lost+found
/mnt
/sys
/var/cache
/var/games
/srv/backup
/var/lib/lxcfs/

Die brauche ich zum Rücksichern nicht wirklich und machen beim Sichern mehr Probleme als ein Backup der Dateien lösen kann. /srv/backup ist der Pfad in dem ich mein Sicherungsmedium einhänge, darum schließe ich das ebenfalls aus.

Ich kopiere die vier Dateien immer nach /usr/local/sbin/ und mache mit „chmod +x backup-rsync-remote.sh“ das Backup Script ausführbar. Nach ein paar Anpassungen des Backup Scripts kann es dann schon losgehen.

Wer z.B. einen Cloud Server einfach nur in ein lokales Verzeichnis auf seinem Backup Server sichern möchte (also kein externes Medium im Spiel), der fügt folgende Zeile in backup-source.config ein:

cloudserver1.example.domain|/srv/backup.cloud|30|/usr/local/sbin/excludeliste-rsync|22

Es wird also mit dem fqdn (full qualified domain namen) des Servers gestartet, anschließend folgt das Verzeichnis in dem die Sicherung abgelegt wird, die 30 sind die Anzahl an Sicherungen die vorgehalten werden, dann noch ein exclude-File mit Verzeichnissen die nicht gesichert werden sollen und am Schluss der SSH Port unter dem der Server ohne Passwort Abfrage erreichbar ist. 

Die Sicherung eines Cloud Server kann jetzt bereits gestartet werden, sofern die backup.config mit passenden Werten versehen wurde bekommt man nach der ersten erfolgreichen Sicherung ein entsprechendes Mail angeliefert.

Soll die Sicherung auf ein externes Medium erfolgen muss man noch ein paar Vorarbeiten leisten:

Will man mit ZFS arbeiten reicht es aus eine externe Festplatte ans System zu stecken, den Device Namen zu ermitteln (z.B. /dev/sdd) und anschließen die Platte mit dem Befehl „backup-rsync-remote.sh –init-zfs“ zu initialisieren. Anschließen kann direkt darauf gesichert werden. Vorausgesetzt wird dass das Paket „zfsutils-linux“ installiert ist!

Bei ext4 weise ich via Udev Regel meinen Sicherungsplatten einen eindeutigen Device Namen zu, damit ich im Backup Script nur /dev/backup_disk als Verweis zum Sicherungsmedium eingeben muss.

Eine solche Regel sieht wie folgt aus und steckt in der Datei „/etc/udev/rules/10-local.rules“:

KERNEL==“sd?1″,SUBSYSTEM==“block“,DRIVER==““,ATTR{partition}==“1″,ATTR{start}==“2048″,ATTR{size}==“7814035086″,

SYMLINK=“backup_disk“

Die passenden Werte für meine Sicherungsplatten bekomme ich vom Befehl:

udevadm info -a -p $(udevadm info -q path -n /dev/sdf1)

Wobei /dev/sdf1 entsprechend durch den Devicenamen eurer Sicherungsplatte zu ersetzen ist – am einfachsten findet man der heraus indem man die Sicherungsplatte ansteckt und sich mit „dmesg|tail“ die letzten Kernel Meldungen anzeigen lässt. 

Hat man die Udev Regel entsprechend erstellt/angepasst muss man den udev Dienst neu starten und triggern, das passiert mit folgender Befehlsabfolge:

systemctl restart udev
udevadm trigger

Anschließend sollte /dev/backup_disk existieren. Jetzt muss man die Platte nur noch für die Sicherung initialisieren:

backup-rsync-remote.sh –init-ext4

Zugegeben etwas mehr Aufwand als mit ZFS! 🙂
Jede Sicherungsplatte muss einmal initialisiert werden und bekommt dabei eine eindeutige ID zugewiesen (steht in der Datei HDID auf der Platte).

Die einzelnen Sicherungen landen dann jeweils im Verzeichnis „daily.X“ beginnend mit 0 für die aktuelle Sicherung, der Rest dürfte fast selbsterklärend sein. Wer mit „du -sch pfad-zum-sicherungsverzeichnis/*“ die Größen der Verzeichnisse prüft, der sieht wie viel sich nach jeder Sicherung verändert hat. Gesichert wird mit hard-links – in jedem daily.X Verzeichnis stecken also alle Daten vom Zeitpunkt der Sicherung drinnen.

Ich hoffe dem einen oder anderen hilft die Anleitung und mein Script dabei seine Daten zu sichern, ich würde mich über Feedback freuen und falls noch Fragen auftauchen ergänze ich den Blog-Beitrag sehr gerne und helfe weiter.

Das Script wird auch immer wieder erweitert und verbessert, wer also auf dem Laufenden bleiben möchte meldet sich am besten rechts oben mit seiner E-Mail Adresse unter „EMAIL SUBSCRIPTION“ an.

Kategorien
Linux

Ubuntu 18.04 interface rename Problem nach Update von systemd/udev auf Version 237-3ubuntu10.26

Heute Morgen wie gewöhnlich die letzten Sicherheitsupdates von Ubuntu 18.04 installiert und einen System-Neustart eingeleitet. Was bei vielen meiner betreuten Systeme gestern ohne irgendwelche Wehwehchen über die Bühne gegangen ist, machte bei einem Firewall-System sofort Schwierigkeiten.

Keinerlei Netzwerkverbindungen waren mehr möglich, nach ein wenig Suche im System stelle sich heraus dass die interfaces nicht mehr korrekt zugeordnet waren!

Bis heute Morgen lief auf dem System systemd und udev mit folgender Versions Nummer:
237-3ubuntu10.25
Nach dem Update waren diese und ein paar weitere Pakete auf die Version
237-3ubuntu10.26
angehoben worden.

Der Fehler äußert sich im Logfile durch folgenden Meldung:

fehlerhaftes System (/var/log/syslog):
systemd-udevd[423]: Error changing net interface name ‚eth1‘ to ‚eth0‘: File exists

und hier der Log vom funktionierenden System (/var/log/syslog):
Sep 4 13:10:09 brutus kernel: [ 4.518507] igb 0000:04:00.0 rename2: renamed from eth0
Sep 4 13:10:09 brutus kernel: [ 4.565081] igb 0000:07:00.0 eth0: renamed from eth1

Ganz eindeutig fehlt hier der Rename des Interfaces eth0 bevor eth1 zu eth0 umbenannt wird, daher gibt es einen Konflikt der nicht aufgelöst werden kann und die Zuordnung der vier Netzwerkschnittstellen wird dann nicht korrekt durchgeführt.

Einen entsprechenden Bug-Report habe ich bei Canonical bereits auf gemacht:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1842651
Ihr dürft ihn gerne upvoten damit der Fehler schneller behoben wird! 🙂

In der Zwischenzeit habe ich mir durch Installation der älteren Pakete geholfen, folgende musste ich manuell herunterladen und installieren:

libacl1_2.2.52-3_amd64.deb
libsystemd0_237-3ubuntu10.25_amd64.deb
libudev1_237-3ubuntu10.25_amd64.deb
systemd_237-3ubuntu10.25_amd64.deb
systemd-sysv_237-3ubuntu10.25_amd64.deb
udev_237-3ubuntu10.25_amd64.deb

Die Installation erfolgt nach dem Download durch folgenden Befehl:

dpkg -i libacl1_2.2.52-3_amd64.deb libsystemd0_237-3ubuntu10.25_amd64.deb libudev1_237-3ubuntu10.25_amd64.deb systemd_237-3ubuntu10.25_amd64.deb systemd-sysv_237-3ubuntu10.25_amd64.deb udev_237-3ubuntu10.25_amd64.deb

Bei i386’er Systemen bitte entsprechend das amd64 durch i386 austauschen!

Anschließend lief nach einem Neustart mein System wieder korrekt, von weiteren Updates sehe ich erstmal bis zur Behebung des Bugs ab.

05.09.2019 Inzwischen wird an einem Bugfix gearbeitet, ich hoffe er funktioniert und wird bald ausgerollt!

Kategorien
Linux

Mit RSPAMD Spam und Anhänge aussortieren

Mein altes Setup hatte Amavis/Spamassassin im Einsatz und über Jahre gute Dienste in Sachen Spamfilter geleistet, ich fand es allerdings an der Zeit mal etwas Neues auszuprobieren!

Also Manuals gelesen und mich ans Werk mit rspamd gemacht, bisher hatte ich mein Mail Setup so gestaltet dass Spam Mails an ein eigenes Postfach gingen in dem sich diese Sammelten und das zentral abgearbeitet wurde. Ebenso handhabe ich unerwünschte Anhänge (EXE-Dateien, VB-Scripte, Srceensaver,…) – diese gingen ebenfalls in ein eigens Postfach, wurden manuell geprüft und gegebenenfalls per Umleitung zugestellt (Thunderbird Plugin – Mail Redirect).

Beim rspamd gibt es keine direkten Ziele die man definieren kann wenn ein Anhang als „BAD_ATTACHMENT“ gekennzeichnet wurde, ebenso sieht es beim X-SPAM-Flag aus.

Für das Aussortieren der Spam Mails wird gewöhnlich sieve genutzt, ich habe mich damit ein wenig gespielt und bin zu folgender sieve-Regel gekommen:

require [„mailbox“, „fileinto“, „envelope“, „copy“];
if allof (header :contains „X-Spamd-Result“ [„FILENAME_BLACKLISTED“, „MIME_BAD_ATTACHMENT“],
not envelope „To“ „banned@example.com“) {
redirect :copy „banned@example.com“;
discard;
stop;
}
if allof (header :contains „X-Spam-Flag“ „YES“,
not envelope „To“ „spam@example.com“) {
redirect :copy „spam@example.com“;
discard;
stop;
}
if allof (header :contains „X-Spam“ „Yes“,
not envelope „To“ „spam@example.com“) {
redirect :copy „spam@example.com“;
discard;
stop;
}

Damit werden entsprechende Mails in die Postfächer von banned@example.com und spam@example.com ausgefiltert.

Die sieve Regel wird im Dovecot als „sieve_before“ Regel ausgeführt, obiges Beispiel setzt natürlich eine funktionsfähige dovecot/sieve Integration voraus!

Kategorien
Linux

Can’t load …/RRDs.so‘ for module RRDs

Nach einem Upgrade von Ubuntu 16.04 auf 18.04 LTS bekomme ich beim Aufruf von rrdtool oder einem Perl Programm welches RRD nutzt folgende Fehlermeldung:

rrdtool: symbol lookup error: /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0: undefined symbol: g_date_copy

Can’t load ‚/usr/lib/x86_64-linux-gnu/perl5/5.26/auto/RRDs/RRDs.so‘ for module RRDs: /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0: undefined symbol: g_date_copy at /usr/lib/x86_64-linux-gnu/perl/5.26/DynaLoader.pm line 187

Das Problem hängt mit einer veralteten Version der Datei libglib-2.0.so.0 zusammen welche sich auf diesem System unter /lib/x86_64-linux-gnu befand.

„dpkg -S libglib-2.0.so“ lieferte mir das folgende Ergebnis:
libglib2.0-0:amd64: /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
libglib2.0-0:amd64: /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.5600.3

Jene Dateien im /lib/x86_64-linux-gnu waren also Altlasten – nach dem Löschen der Datei /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.5600.3 und dem Symlink /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0 starteten meine Perl Programme die RRD nutzen wieder ohne Probleme!

Kategorien
Linux

OMD/Check-MK Installation auf Ubuntu 18.04 LTS Server

Meine bevorzugte Monitoring Lösung ist OMD (Open Monitoring Distritbution) mit check_mk, Nagios, WATO & Co an Bord.

Nachdem es auf der OMD Webseite noch keine passenden Pakete für Ubuntu 18.04 LTS gibt, habe ich jene von Debian „Buster“ verwendet.

Hier gibt es nur eine unerfüllte Abhängigkeit – „libicu57“. Diese lässt sich recht schnell lösen – einfach das libicu57 Paket von Ubuntu 17.10 herunterladen und mit

sudo dpkg -i libicu57_57.1-6ubuntu0.3_amd64.deb

installieren.

Anschließend klappt die Installation mit den „Buster“-Paketen wie’s in der Installationsanleitung von OMD angegeben ist ohne Probleme!

Kategorien
Linux

Unifi Controller auf Ubuntu 18.04 installieren

Die aktuelle Unifi Controller Software 5.8.28 lässt sich unter Ubuntu 18.04 LTS derzeit leider nicht so einfach installieren, die mitgelieferte Mongo-DB Version von Ubuntu entspricht nicht jener die der Controller verlangt.

Ergo muss man die passende Mongo-DB Version installieren um den Controller zum Laufen zu bekommen, ein Upgrade von 16.04 auf 18.04 scheint zu funktionieren.

Für die Installation des Controllers hat sich ein Unifi Benutzer die Arbeit gemacht und ein Script gebaut welches die komplette Installation quasi automatisiert, hierfür ist ein frisch installiertes Ubuntu System die beste Basis – wurden bereits Versuche unternommen die Controller Software zu installieren, sollte man alle Überreste vorher entfernen.

Der Link zum Download der Software führt über einen Beitrag im Unifi Forum:

https://community.ubnt.com/t5/UniFi-Wireless/UniFi-Installation-Scripts-UniFi-Easy-Update-Scripts-Works-on/td-p/2375150