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…!

Kategorien
Hardware

Linux und der Datalogic Gryphon GFS 4400 USB

Der Datalogic Gryphon GFS 4400 ist ein recht universeller Barcode Scanner der sich wunderbar in Produktionsanlagen verbauen lässt. Ich steuere ihn mit einem Linux Rechner und binde ihn nicht über die USB-Keyboard Schnittstelle an, sondern nutze die USV-COM Variante.

Per Default wird der Scanner laut Handbuch mit folgenden Einstellungen ausgeliefert:

RS-232: 9600,8,N,1,no handshaking,ACK/NAK disabled

Hier kommt die erste Hürde, das Datenblatt muss nach „stty“ übersetzt werden 🙂

Sobald der Scanner am System angeschlossen ist und auf USB-COM umgeschaltet wurde sieht man folgende Anzeige im Syslog:

Jul 18 15:25:33 e002110 kernel: [322458.030720] usb 1-9: new full-speed USB device number 37 using xhci_hcd
Jul 18 15:25:33 e002110 kernel: [322458.180222] usb 1-9: New USB device found, idVendor=05f9, idProduct=4204
Jul 18 15:25:33 e002110 kernel: [322458.180228] usb 1-9: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Jul 18 15:25:33 e002110 kernel: [322458.180232] usb 1-9: Product: Handheld Barcode Scanner
Jul 18 15:25:33 e002110 kernel: [322458.180236] usb 1-9: Manufacturer: Datalogic ADC, Inc.
Jul 18 15:25:33 e002110 kernel: [322458.180240] usb 1-9: SerialNumber: S/N G17AB1226
Jul 18 15:25:33 e002110 kernel: [322458.181927] cdc_acm 1-9:1.0: ttyACM0: USB ACM device

Der Scanner läuft also auf der Schnittstelle /dev/ttyACM0.

Mittels stty können jetzt die Kommunikationsparameter wie oben erwähnt eingestellt werden:

stty 9600 cs8 -cstopb -parenb ocrnl icrnl -F /dev/ttyACM0

Ein weiteres Problem das ich beim Einrichten hatte war dass der Scanner bei GS1-128 Barcodes den GS1 Code mit schickt – z.B. als Zeichen „+C1“ vor dem Barcode, das kann man abschalten indem man diese drei Barcodes scannt:

Wenn man jetzt via Bash Script die eingescannten Barcodes verarbeiten will, dann klappt das mit folgendem Befehl wunderbar:

head -n1 /dev/ttyACM0

In eine kleine „while“-Schleife verpackt und schon wird jeder eingelesene Barcode nach Wunsch verarbeitet.