Kategorien
Allgemein

Unifi Controller Firewall Regel-erstell Bug

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 Vorversion
Cloud 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 erlauben
Nach 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

Unifi Chat Transcript – 11.02.2019

Kategorien
Allgemein

Vergessenen Veeam Restore Point aushängen (Linux/cli)

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.

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

Kategorien
Allgemein

Windows 7 Druckerverbindung nicht möglich Fehler 0x00000bc4

Ein PC der über Jahre ohne Probleme mit einem Drucker verbunden ist kann plötzlich nicht mehr drucken, das Löschen und Wiederherstellen der Verbindung über den UNC Pfad \\prod1\pdf schlägt fehl. Eine Verbindung via IP Adresse \\192.168.1.1\PDF ist allerdings noch möglich!

Im Eventlog von Windows findet sich mal wieder überhaupt nichts, auch sonst kein wirklicher Hinweis woher das Problem stammen könnte.

Nachdem ich alle Verweise auf den Drucker in der Registry gelöscht und den PC neu gestartet habe bekomme ich folgenden Fehler zu sehen: 0x00000bc4

Unglaublich aussagekräftig, hier lobe ich mir die Linux Welt – gewöhnlich vernünftige Fehlermeldungen in den Logs und falls das nicht reicht dreht man das Debugging einfach hoch und lässt sich mit Meldungen überfluten. Mit ein wenig Hirnschmalz kommt man dann meist schnell an’s Ziel.

Nicht so bei meinem „Lieblingsbetriebssystem“ – hier muss man sich via trial and error stundenlang quälen und wertvolle Lebenszeit vergeuden.

So geschehen am gestrigen Tag und heute Morgen, immerhin habe ich eine Lösung für das Problem gefunden und möchte es hier für künftige Einsätze und andere Gequälte festhalten:

Diesen Registry Key löschen:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Print\Providers

Und anschließend einmal neu starten, anschließen lässt sich die Druckerverbindung wieder herstellen.

Eine andere vorgeschlagene Lösung hat bei mir nicht funktioniert:

ipconfig /flushdns

Für den Fall der Fälle schadet es aber nicht den mal auszuführen. Die Namensauflösung lief bei mir aber immer sauber durch, ein Ping auf prod1 war immer problemlos möglich und wurde zur korrekten IP aufgelöst.

Kategorien
Linux

Windows 2016 im virsh/qemu virtuell unter Ubuntu 18.04 installieren/betreiben

Dies ist mal wieder so ein Blog Beitrag der in erster Linie mir selbst dient – damit ich beim nächsten Mal etwas weniger Zeit in das Zusammensuchen der einzelnen Teile benötige, side effect könnte sein dass sich der eine oder andere darüber freut dass ich mir hier die Arbeit gemacht habe! 😉

Für die eigentliche Installation benötigt mein Ubuntu folgende Pakete:

apt-get install virtinst libvirt-daemon libvirt-clients libvirt-bin qemu qemu-kvm qemu-user qemu-utils osinfo-db osinfo-db-tools libosinfo-bin bridge-utils

Und natürlich alle abhängigen Pakete die beim Aufruf des Befehls als Dreingabe noch dazu kommen…

Jetzt besorgt man sich noch die passende Windows DVD und das ISO mit den Virt-IO-Treibern – auf der Fedora Projektseite bekommt man folgendes Image zum Download virtio-win.iso

Meine ISOS habe ich im Verzeichnis /srv/samba/isos/ abgelegt und meine künftige virtuelle Maschine soll unter /srv/kvm/ liegen.

Der folgende Befehl startet die Erstellung der virtuellen Maschine, die Variablen $NAME, $MEMORY und $CPUS habe ich wie folgt belegt:

export NAME=win2016srv
export CPUS=6
export MEMORY=16348
virt-install –name $NAME –memory $MEMORY –vcpus $CPUS –cpu host –video cirrus –features hyperv_relaxed=on,hyperv_spinlocks=on,hyperv_vapic=on –clock hypervclock_present=yes –disk /srv/kvm/$NAME.qcow2,bus=virtio,size=200 –disk /srv/samba/isos/w2016.iso,device=cdrom,bus=ide –disk /srv/samba/isos/virtio-win-0.1.141.iso,device=cdrom,bus=ide –graphics vnc,listen=0.0.0.0 –noautoconsole –os-type=windows –os-variant=win2k12r2 –network bridge=br0,model=virtio

Anschließend ist die Virtuelle Maschine via VNC über die IP Adresse des Servers auf dem der Befehl ausgeführt wurde erreichbar.

Kleine Anmerkung am Rand, die Config des Interface br0 sieht wie folgt aus (/etc/network/interfaces):

auto eth0

auto br0
iface br0 inet static
bridge_ports eth0
address 192.168.1.123
netmask 255.255.255.0
gateway 192.168.1.1

 

Und schon zeigt sich im VNC die Windows Installation – bei der Auswahl der Festplatte muss man den passenden Treiber von der eingehängten CD auswählen, anschließend ist diese nutzbar.

Damit die virtuelle Maschine künftig automatisch startet fehlt noch dieser Aufruf:

virsh autostart win2016srv

 

Kategorien
Linux

X11 Autologin startet nach Upgrade von Ubuntu 16.04 auf 18.04 nicht mehr

Auf einem Ubuntu System mit installierter Version 16.04 habe ich heute ein Upgrade auf 18.04 gemacht und musste leider feststellen dass der bis dahin wunderbar funktionierende Autologin eines Users mit Start der X11 Oberfläche nicht mehr funktioniert.

„Leider“ bekomme ich beim Fehlersuchen immer mehr Übung, ähnliches hatte ich beim Upgrade von 14.04 auf 16.04 auch bereits…

Zuerst musste ich dieses Mal allerdings ein paar Probleme mit dem Systemd umschiffen, mein User hat sich bisher durch ein selbst gebasteltes Config File von Systemd auf tty7 mittels „rungetty“ automatisch angemeldet.

Diese Vorgehensweise hat leider nicht mehr funktioniert, die einfachste Lösung war das Unterverzeichnis /etc/systemd/system/getty@tty7.service.d mittels

mkdir /etc/systemd/system/getty@tty7.service.d

neu zu erstellen und darin die Datei autologin.conf mit folgendem Inhalt abzulegen:

[Service]
ExecStart=
ExecStart=-/sbin/agetty –autologin pirlo –noclear %I 38400 linux

anschließend folgende Befehle ausführen:

systemctl enable getty@tty7.service
systemctl start getty@tty7.service

und schon klappt der Autologin – ein Blick in die Datei „~/.local/share/xorg/Xorg.0.log“ brachte folgende Fehlermeldung zu tage:

[ 1654.298] (EE) modeset(0): drmSetMaster failed: Permission denied
[ 1654.298] (EE)
Fatal server error:
[ 1654.298] (EE) AddScreen/ScreenInit failed for driver 0

Der User gehörte bereits zur Gruppe tty und auch sonst schienen alle Berechtigungen.

Gelöst habe ich das Problem indem ich dem X-Server in der Datei “ /etc/X11/Xwrapper.config“ folgende Parameter hinzugefügt habe:

allowed_users=console
needs_root_rights=yes

Somit wird der X-Server mit root-Rechten gestartet und kann den modeset ausführen. Ab jetzt findet sich die Xorg.0.log Datei wieder am gewohnten Ort unter „/var/log“.

 

Kategorien
Linux

Bounced Mails am IMAP Server finden und erneut versenden

Was tun wenn durch einen Fehler jede Menge Mails vom Mailserver gebounced wurden und man es nicht allen Leuten zumuten möchte dass sie die Mails erneut versenden müssen?

Alle an diesem Tag gesendeten Mails finden und via Script erneut in die Mail-Queue einordnen – was so einfach klingt ist im Grunde auch so einfach! (fast) 😉

Angenommen die gesendeten Mails liegen alle im Verzeichnis /srv/imap/{benutzer}/Maildir/.Sent/cur/ – dann könnte man anhand des Dateinamens schon mal ein wenig eingrenzen, alle Mails vom 19. und 20. Juli beginnen mit 1532… (Unix Timestamp).

Wir suchen also alle Mails die mit 1532 beginnen und prüfen dann mit „ls -al“ und grep ob sie an besagtem Tag versendet wurden – es interessieren uns nur die vom 20. Juli.

Alle Mails die gefunden werden injizieren wir dann unserem Postfix mit dem „sendmail“ Kommando.

#!/bin/bash

cd /srv/imap/

IFS=“

for I in $(ls);do

if [ -d „$I/Maildir/.Sent“ ]; then
for F in $(ls -al $I/Maildir/.Sent/cur/1532* 2>&1 |grep -v „No such file or directory“);do
TOSEND=$(echo $F|grep „Jul 20″|awk ‚{print $9}‘)
if [ $TOSEND ]; then
echo „$TOSEND“
cat „$TOSEND“||sendmail -t
fi
done
fi

done

Damit werden alle Mails erneut an den Mailserver übergeben und ausgeliefert.

Kann einem schon mal helfen, besser wär’s natürlich man kommt erst nicht in die Situation…!