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!
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!
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!
Gelegentlich passiert es dass man nach dem Rücksichern von Dateien vergisst den Restore Point wieder auszuhängen. Ein klassischer „umount“ führt hier nicht zum Ziel weil veeam selbst noch auf dem Mount drauf hängt und diesen blockiert.
Es muss also via veeam der umount erfolgen – das klappt wie folgt:
#!/bin/bash
if [ -x „/usr/bin/veeamconfig“ ]; then TIME=$(date „+%H%M“) if [ $TIME -gt 1900 ]; then VEEAMSESSION=$(/usr/bin/veeamconfig session list|grep „Mount“|grep „Running“|awk ‚{print $3}’|tr -d „{}“) if [ „$VEEAMSESSION“ ]; then /usr/bin/veeamconfig session stop –id $VEEAMSESSION fi fi fi
Dieses kleine Script läuft bei mir stündlich ab, wird aber erst nach 19:00 Uhr aktiv und hängt verbliebene Mount-Sessions wieder aus.
Seit inzwischen etwas mehr als einem Jahr setze ich in einigen Netzwerken recht erfolgreich Hardware von Unifi und entsprechend auch deren Controller ein. Ich bin inzwischen ein kleiner Fan von der Unifi Infrastruktur, sie funktioniert gut und ist zu leistbaren Preisen verfügbar – wenn auch zeitweise nur mit längeren Lieferzeiten.
Gestern hatte ich mal wieder das „Vergnügen“ mit dem Unifi Support zu chatten, ich wollte einen vermeintlichen Bug den ich im Interface zum Erstellen von Firewall Regeln gefunden habe melden.
Was soll ich sagen, eine Stunde später war ich am Ende meiner Nerven aber irgendwie habe ich es dann doch geschafft die werte Dame davon zu überzeugen den Fehler weiter zu melden…
Der Fehler ist eigentlich schnell erklärt und nachvollziehbar – bei mir auf zwei unterschiedlichen Cloud Key’s mit ebenfalls zwei Unterschiedlichen Firmware Versionen:
Cloud Key und Controller mit der VorversionCloud Key mit aktueller Firmware und Controller Version
Erstellt man eine einfache Firewall Regel welche den TCP Verkehr zu einem bestimmten Host dessen IP Adresse angegeben wird frei schaltet und speichert diese, dann erscheint nach dem Speichern im selben Dialog beim Editieren keine IP Adresse mehr. Die Regel funktioniert zwar, kann aber nicht mehr zuverlässig verändert werden.
Testregel – sämtlicher TCP Verkehr zum Server 8.8.8.8 erlaubenNach dem Speichern wird unter Address/Port Group der Default angezeigt, IP Address ist leer.
Für den Fall dass jemand langweilig ist kommt hier noch der Mitschnitt vom Chat mit Unifi – ich hoffe es wird verständlich warum ich mich darüber geärgert habe…!
(09:17:35 AM) Manfred: Hello, I think I found a bug! When I crate a firewall rule wich allows all TCP traffic to a specific IP address, the IP address will be removed from the rule management interface after I save the rule. (09:20:37 AM) Customer Service: Sorry to keep you waiting! All of our agents are currently assisting other customers, but we’ll be with you shortly! You’re welcome to explore our help center, which might have a solution for you. Take a look. https://help.ubnt.com/hc/en-us (09:23:37 AM) Customer Service: We are experiencing unusually high support volume. We thank you for your patience and we will be with you shortly. (09:28:25 AM) *** Anna G joined the chat *** (09:28:30 AM) Anna G: Hi there. Let me check it for you. (09:28:41 AM) Manfred: hi anna, please (09:30:08 AM) Manfred: Current Version5.9.29 (Build: atag_5.9.29_11384) (09:33:19 AM) Anna G: Which browser are you using? (09:33:55 AM) Manfred: chrome (09:37:16 AM) Anna G: Have you tried to clear browser history and cache? (09:38:18 AM) Manfred: yes (09:39:58 AM) Anna G: Please try accessing the controller in incognito mode of your chrome browser. (09:40:29 AM) Manfred: ok, one moment… (09:42:19 AM) Manfred: same error – after saving the ip address is empty in the field (09:42:29 AM) Manfred: did you try that on your test system? (09:43:34 AM) Anna G: Not yet. Please give me a moment to check this with my internal team. (09:44:35 AM) Manfred: please create a new „wan out“ rule with accept tcp to an external ip address, save it and edit the rule again – should have an empty ip address field in destination field… (09:50:29 AM) Anna G: On which OS is the controller installed? (09:50:50 AM) Manfred: cloud key (09:51:04 AM) Manfred: UCK.mtk7623.v0.12.2.ac6742e.181220.1824 (09:51:27 AM) Anna G: Have you tried rebooting the CK? (09:52:09 AM) Manfred: no, have you tried to create a rule on your controller? (09:53:13 AM) Anna G: Could you please reboot the CK and let me know if the issue persists? (09:53:52 AM) Manfred: if i reboot the controller this chat will be ended or isn’t it so? (09:54:32 AM) Manfred: to check if it’s bug or a problem on my system you would only have to do 5 clicks in the firewall settings and you could see if it happens on your site too or just on mine… (09:55:03 AM) Manfred: I will check that on a second controller now – if the error is there too I will not have to reboot mine or? (09:57:45 AM) Anna G: Any updates? (09:57:55 AM) Manfred: second controller – same problem there… (09:58:05 AM) Manfred: Visitor uploaded: after_saving.png (09:58:06 AM) Manfred: Visitor uploaded: before_saving.png (09:58:06 AM) Manfred: Visitor uploaded: rule_overview_with_test-rule.png (09:58:37 AM) Manfred: would it be possible for you to check that on your test controller now? (09:59:21 AM) Anna G: on which OS is this second controller installed? (09:59:40 AM) Manfred: uck (09:59:54 AM) Manfred: same version (10:00:17 AM) Anna G: Can you please reboot this second cloud key and let me know if the issue resolves? (10:00:32 AM) Anna G: I need to provide this information to my team. (10:00:45 AM) Manfred: you are joking? (10:02:38 AM) Anna G: Please check out the known issues mentioned in the release note: https://community.ubnt.com/t5/UniFi-Updates-Blog/UniFi-Network-Controller-5-10-12-Stable-has-been-released/ba-p/2665341 (10:03:20 AM) Anna G: Refreshing/rebooting the controller should resolve any display issues reported after upgrading. (10:05:55 AM) Manfred: i make a restart but am not really happy with the situation! actually, i’m trying to help you identify a bug in your product and help you fix it, the easiest way would be to reproduce the problem on a test system. the problem exists exactly the same after the restart as before. for my part i have already spent more time to report the bug here and am a bit annoyed in the meantime. please take this information and pass it on to your team, i will pass it on for my part on my blog.
(10:06:58 AM) Manfred: second cloud key with same problem has this cloud key version: UCK.mtk7623.v0.12.2.ac6742e.181220.1824 (10:07:13 AM) Manfred: and controller version: 5.9.29-11384-1 (10:07:14 AM) Anna G: Thank you for the update! (10:07:49 AM) Anna G: I will escalate this. (10:07:56 AM) Manfred: thank you
Ein seit vielen Jahren mit ADAM 6051 Modulen laufendes MDE/BDE Projekt für das ich extra eine in C/C+ programmierte Sofware geschrieben habe bekommt immer mehr Probleme mit der Hardware – eben den genannten ADAM 6051 Modulen.
In der CT Zeitschrift bin ich über eine Anzeige der Firma Acceed auf das EDAM 9050 Modul gestoßen, welches PIN Kompatibel und auch von der Software fast identisch aufgebaut ist. An manchen stellen kommt uns das EDAM 9050 sogar entgegen – die Kommunikation war in kurzer Zeit komplett auf PHP umgestellt und funktioniert sehr gut.
Dass das EDAM 9050 Modul bei Stromverlust auch den letzten Stand der Zähler verliert und eben diese erst gestartet werden müssen bevor sie zu zählen beginnen, ist zwar nicht ideal konnte aber per Software Design Änderung leicht gelöst werden.
Ein Fehler der sowohl mich als auch den Support ein wenig beschäftigt hat war folgender, das EDAM 9050 Modul konnte von mir zwar via E9KUtility kontaktiert und z.B. die einzelnen IO’s eingestellt werden. Die Netzwerkeinstellungen konnten allerdings nicht verändert werden!
Default IP Adresse des EDAM Moduls ist 10.0.0.1 – ein simples Ändern der IP Adresse auf 10.0.0.3 scheiterte bereits mit der Fehlermeldung „Unable to update Network settings!“.
Support und Hersteller etwas ratlos, ich auch – also erst mal alles was irgendwie in Frage kommt austauschen und testen.
Netzwerkkabel getauscht (von Crossover zu geswitcht)
Netzwerkkarte getauscht
PC getauscht
Betriebssystem getauscht (W7 zu W10)
Firewall deaktiviert
Virenscanner deinstalliert
Mit null Erfolg, der Fehler trat permanent auf…
Die Ursache und somit auch Lösung des Problems war dass der PC zwei Netzwerkkarten verbaut hat, sobald eine zweite Netzwerkkarte aktiv ist kommt die Software durcheinander und kann das EDAM Modul nicht mehr korrekt programmieren!
Nachdem ich die für diesen Zweck nicht benötigte Netzwerkkarte deaktiviert habe, konnte ich ohne Probleme die Netzwerkeinstellungen vom EDAM 9050 Modul verändern!
Jetzt bin ich gespannt wie der Hersteller darauf reagiert und ob es ein neues Software Release geben wird das auch mit mehreren Netzwerkkarten umgehen kann…
Nachdem entfernen eines Laufwerks kann Veeam die Sicherung eines Linux Systems nicht mehr durchführen und „failed“ mit der Fehlermeldung:
14:45:40 [error] Can’t get info for file [/srv/syslog.backup] 14:45:40 [error] Failed to retrieve mount point for [/srv/syslog.backup]
Soweit auch klar, das Verzeichnis gibt es nicht mehr! Allerdings scheitere ich auch daran die zu sichernden Dateien via Veeam Client entsprechend anzupassen.
Die Lösung ist wie immer pragmatisch, einfach mit sqlite3 CLI die Veeam Datenbank öffnen und entsprechend das Verzeichnis in der Datenbank suchen und entfernen.
delete from JobFilters where id=“{df8a1212-ce58-4e28-a866-c5ccaa23ec6c}“;
Und schon funktioniert das Backup wieder wie gewohnt. Da ich auf den Support Seiten von Veeam keine passende Lösung gefunden habe wird’s hier veröffentlicht. Ein entsprechendes Ticket dazu wurde eröffnet.
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.
Gemischte Umgebung mit Windows 7 und Windows 10, Thunderbird in Version 60.6.1 oder 60.9.0, Acrobat Reader in Version 11.0.23. Beim Öffnen von PDF Anhängen gibt es auf manchen PC’s das Problem dass der Anhang erst nach über 10 Sekunden geöffnet wird. Speichert man ihn lokal ab und öffnet ihn von dort ist er sofort offen. Es wird auch sofort beim Klick auf den Anhang die PDF Datei auf der Platte erstellt, die Verzögerung von 10 Sekunden lässt sich nicht wirklich erklären. Sämtliche Reparaturversuche und Programm Neuinstallationen bringen nichts.
Nach längerer Suche habe ich mich mit dem ProzessManager von Sysinternals auf die Suche gemacht und auf einem PC bei dem es problemlos lief einen Trace der Prozesse mit „thunder“ sowie jener mit „acrord“ im Namen gemacht.
Im Trace ist mir dann aufgefallen dass jene Systeme bei denen es nicht funktioniert eine Verbindung wie folgt aufbauen:
Und jene bei denen es Problemlos funktioniert haben hier eine ganze Abfolge TCPSend, TCPReceive stehen statt der Reconnect Meldungen.
Die Host Adresse 1e100.net hat mich dann auf die richtige Fährte gebracht! Diese gehört zu Google (1 hoch 100 = gogol, davon abgeleitet google…). Etwas Recherche im Internet bringt also die SafeBrowsing Funktion von Firefox/Thunderbird zum Vorschein, die greift auf diese Adressen zu und schickt einen SHA256 Hash zur Prüfung ob der jeweilige Anhang koscher ist oder nicht.
Mal davon abgesehen dass es wenn’s um die Privatsphäre geht nicht unbedingt vertrauenerweckend ist, wenn ein Konzern wie Google alle meine jemals geöffneten Datei-Hashes und URL’s bekommen hat, bringt diese Funktion in diesem Fall eine Satte Verzögerung von 10 Sekunden.
Warum tritt das aber jetzt auf manchen PC’s auf und auf anderen nicht?
In meinem Fall steht zwischen dem PC und dem Internet noch eine Firewall und ein Proxy Server, ersterer ist unbeteiligt – aber der Proxy Server verzeichnet keinerlei Zugriffe auf die 1e100.net Domain!
Sollte er eigentlich weil alle Systeme so konfiguriert sind dass sie eine automatische Proxy Konfiguration nutzen.
Die SafeBrowsing Funktion im Thunderbird hat offenbar einen kleinen Bug, sie nutzt nicht die eingestellte Proxy Funktion! Alle Zugriffe erfolgen direkt auf das Zielsystem von Google auf Port 443 also SSL Verschlüsselt, der Proxy Server ist außen vor. Das erklärt dann auch warum er keine Einträge im Protokoll hat.
Die Lösung ist das SafeBrowsing für Downloads ab zu schalten, das erfolgt mittels folgendem Config Werts in der erweiterten Thunderbird Konfiguration:
browser.safebrowsing.downloads.enabled = false
Und schon gehen auf allen PC’s die PDF Anhänge wieder innerhalb einer Sekunde auf!
Fragt nicht wie viel Zeit mich die Suche gekostet hat…
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.
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:
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“:
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.
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 MySQLDatenbank 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:
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:
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!?
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:
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.
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.
Es gibt Tage die sind länger als geplant, heute ist mal wieder so einer!
Wer ist Schuld? In dem Fall ganz einfach, ein Update des Linux File-/Mail-/Gateway Security Virenscanners der Firma ESET. DeJaVu? Ja genau vor vielen Jahren gab’s schon mal so etwas ähnliches, war damals schon ärgerlich – ist es heute ebenso.
Der Eset Prozess stirbt also dank des Signatur oder Engine Updates einfach weg, ein Wiederbeleben klappt leider nicht – die Fehlermeldung beim esets_update --verbose
lautet irgendwie mit „cannot create temp file“.
Wie bekommt man das Ganze am schnellsten wieder zum laufen?
Erstmal die aktuelle Version 4.5.16 von der Webseite des Herstellers nach /tmp/ laden, anschließen wie folgt vorgehen:
/etc/opt/eset sichern apt-get remove --purge esets bash /tmp/esets.amt64.deb.bin enter q y rücksichern von /etc/opt/eset systemctl restart esets esets_update --verbose den letzten schritt eventuell mehrfach ausführen bis keine fehlermeldung mehr kommt, im zweifel die ganze prozedur wiederholen!
Hier ein Auszug meiner Meldungen bis der Scanner wieder lief:
Viel Erfolg beim wiederherstellen eures Virenscanners falls es euch auch erwischt hat, ich hoffe dieser Beitrag erreicht euch rechtzeitig so dass ihr euch etwas Zeit bei der Suche einsparen könnt!
Freue mich über positive Rückmeldungen!
Update 20.11.2020 09:00 Uhr – Das sagt der Support von ESET dazu:
gestern um ca. 15:00 Uhr kam es aufgrund eines fehlerhaften Moduls zu zwei unterschiedlichen Problemen die allerdings nicht in Verbindung zueinander standen:
Segmentation faults False positives with Detection Engine 22346 (erkennung von Mails als Trojan.VBS/Agent.ORM)
Das fehlerhafte Modul wurde gestern um 16:02 von den Update Servern entfernt und ESET arbeitet hat bereits einen Hoftix bereitgestellt. Dazu muss nur das neueste Modulupdate geladen werden:
stop the esets service : systemctl stop esets
delete content of modules directory in /var/opt/eset/esets/lib/
delete content of update cache directory in /var/opt/eset/esets/lib/data/updfiles/
run update manually : sudo /opt/eset/esets/sbin/esets_update --verbose
Deleted modules will be replaced for fresh.
Die Ursache wird aktuell von ESET untersucht, der genaue Auslöser ist leider noch nicht bekannt.
Seit Jahren nutze ich einen DSL Internetzugang von A1 und so wirklich glücklich war ich damit nie! Das lahme A1 Modem mit seiner eigenwilligen Bedienung, regelmäßige Unterbrechungen einhergehend mit einem IP-Adresswechsel und andere Unzulänglichkeiten wie die Verfügbarkeit der Hotline, haben mir das Leben nicht unbedingt immer leichter gemacht.
Eigentlich wollte ich ja zu unserem lokalen Provider wechseln der unsere gesamte Region bereits mit Breitbandanschlüssen via LWL versorgt. Aber wie es das Schicksal für uns so vorgesehen hat endet der Wille zum Anschluss gerade einmal 15 Meter vor unserem Haus.
Seit mehr als zwei Jahren warte ich jetzt bereits darauf dass dieses kurze Stück erschlossen wird, leider vergebens – 2021 dachte ich mir geh ich das mal anders an und schaue mir die Alternativen an.
Erster Gedanke war LTE, warum also nicht einen Internetzugang via LTE? Nachdem ich mit dem LTE Modem eines Freundes und dessen Spusu Vertrag ein paar Tage getestet habe, steht fest – LTE wird es sicher nicht! Konstanz ist bei LTE ein Fremdwort, die Bandbreite schwankt schlimmer als die Wetterbedingungen im April! Einzig der Upload erscheint halbwegs stabil, was mir zum Arbeiten dann doch zu riskant erschien.
Zwei LTE Speedtests – zeitlicher Unterschied nur wenige Sekunden.
Mein weiterer Weg auf der Suche nach einem vernünftigen Internetzugang führte mich zu Fonira. Fonira? Noch nie gehört! Korrekt, ich auch nicht – etwas Googeln machte mich ein wenig schlauer, zumindest scheint es keine wirklich größeren Beschwerden über diesen Zugangsanbieter zu geben.
Ein kurzer Anruf bei der Hotlineschlug definitiv schon mal alle Wartezeiten der A1 Hotline die ich seit Anbeginn der Zeit hatte. Die Auskünfte waren auch alle kompetent und zufriedenstellend, also habe ich kurzerhand bestellt.
Ein Privatprodukt mit angepeilten 150/20 MBit/s sollte es werden, eine fixe IP-Adresse schadet für berufliche Zwecke natürlich auch nicht. Keine Vertragsbindung (lediglich eine Gebühr bei vorzeitiger Auflösung – 24 Monate – von 29,90 €) und natürlich das Wichtigste unlimitierter Traffic! (auch so ein Manko bei LTE, entweder schnell oder limitiert)
Und das Beste am Ganzen – ich bezahle tatsächlich weniger als ich bisher bei A1 für meine 30/5 Mbit/s Leitung löhnen musste!
Da nehme ich doch sogar in Kauf dass ich bei sofortiger Herstellung an A1 den Folgemonat noch weiter bezahlen muss.
Letzte Woche bestellt, diese Woche bereits umgeschaltet – seit heute läuft mein DSL Anschluss über den Provider Fonira und bis jetzt lief alles wie geschmiert! Mitgeliefert wurde auch gleich eine Fritzbox 7530, die ist im Vergleich zum A1 Modem eine Rakete.
Ich hoffe die Beziehung zwischen mir und meinem neuen DSL Anbieter Fonira bleibt sehr lange stabil und frei von Sorgen, der Start war auf jeden Fall schon mal beeindruckend!
Die ESET Linux Version 4 ist jetzt schon länger nicht mehr die aktuellste, daher schadet ein wechsel auf die neuen Versionen 7 oder besser 8 auf keinen Fall!
Mit ESET Protect Cloud Versionen lässt sich ja inzwischen alles zentral via Cloud steuern, auf den Linux Systemen wird also als erstes der ESET Remote Agent installiert und anschließend sieht man das gewünschte Gerät bereits in der ESET Cloud Übersicht.
Vorausgesetzt dass man den Installer für den Agent gefunden hat, der versteckt sich nicht wie alle anderen unter dem Menüpunkt „Installationsprogramme“, sondern findet sich rechts oben unter Quick-Links!! Eine nicht zu unterschätzende Hürde, welcher Logik diese folgt ist unbekannt – es würde mich nicht wundern wenn da mal angepasst wird.
Für Linux kann man dann das im Cloud Manager aufscheinende neue Gerät mit zwei Varianten bestücken, ESET Endpoint Security oder ESET Server Security – für einen klassischen Mail-Server wählt man natürlich die ESET Server Security. Die wird nach Erstellen und Ausführen des entsprechenden Installations-Tasks dann unter /opt/eset/efs installiert.
Den Erfolg der Installation kann man in „/var/log/eset/RemoteAdministrator/Agent/software-install.log“ nachverfolgen. In meinem Fall musste noch ein früherer alter ESET Scanner deinstalliert werden (apt-get remove –purge esets), will man den EFS mal los werden geht das via „apt-get remove –purge efs“.
Nachdem der Scanner installiert ist findet man sein CLI-Tool hier:
/opt/eset/efs/sbin/cls/cls
Jetzt muss es nur noch in Amavis integriert werden, bei meinem Ubuntu System geht das über die Datei /etc/amavis/conf.d/15-av_scanners und zwar mit folgendem Eintrag:
### ESET efs Scanner [‚ESET Software ESETS Command Line Interface‘, ‚/opt/eset/efs/sbin/cls/cls‘, ‚–subdir {}‘, [0], [1, 10, 50, 100], qr/name=“([^“]+)“/ ],
Und zwar direkt im „@av_scanners = “ Block!.
Nach einem Neustart von Amavis greift dieses nicht mehr auf den früheren „/opt/eset/esets/sbin/esets_scan“ zu, sondern auf den „cls“ der aber die gleichen Rückgabewerte (0 no threat found; 1 some files were detected and cleaned; 10 some files could not be scanned (may be threats); 50 some files were detected; 100 error) liefert.
Eine wichtige „Kleinigkeit“ fehlt jetzt noch, das Verzeichnis /var/lib/amavis/tmp muss unbedingt in der Policy vom ESET Server Security ausgenommen werden – sonst löscht der EFS die Datei bereits beim erstellen und der Amavis bekommt keinen Zugriff mehr auf die Datei, was zu einer Schleife führt und die Mail-Queue mit infizierten Mails anwachsen lässt!
Und schon sollte ein erkannter Virus nicht mehr in der Mailbox landen…
Leider wurden ja die Produkte ESET Gateway Security und ESET Mail Security komplett abgekündigt, keine Ahnung was ESET hier für eine Strategie verfolgt und wie sie auf die Idee kommen dass Linux in Sachen Mail- und Gateway Security keine wichtigen Plattformen mehr sind – mit Amavis lässt sich Mail Security zumindest auf diesem Weg nachrüsten. Wenn RSPAMD ins Spiel kommt müsste man das ICAP Protokoll nutzen und die ESET ICAP Schnittstelle entsprechend anzapfen probieren. Mit c-icap-client klappt das grundsätzlich ganz gut: /usr/bin/c-icap-client -i 127.0.0.1 -p 1344 -v -f „/tmp/eicar.com“ -nopreview -o „/tmp/eicar.com.out“.
Den Squid Proxy Server konnte ich aber noch nicht dazu überreden mit dem ESET ICAP Dienst zusammen zu arbeiten, falls das jemand geschafft hat würde ich mich über eine Rückmeldung sehr freuen! 🙂
