Gestern traf ich am Messestand der Firma Digiwell auf Alexej von Lackey.eu der sich spontan dazu entschloss zwei RFID/NFC Implantate setzen zu lassen.

Solche Momente sollte man für die Ewigkeit festhalten. Dürfte einen – ähnlich einem Tattoo – länger begleiten.

Das Implantat ist überschaubar groß und stört nach kurzer Eingewöhnungsphase wohl nicht mehr.

Deutlich respekteinflößender scheint mir hier das Werkzeug zum Einsetzen! Die ganze Prozedur dauert nicht lange und dürfte nur für jene die unter Trypanophobie (Spritzenangst) leiden ein Problem darstellen.

Für Alexej hat der ganze Spass gleich einen praktischen Nutzen, bei lackey.eu können die Türschlösser via NFC geöffnet werden. Ideal also um das eigene Produkt zu präsentieren!

Gegen Ende des Jahres wird es via Crowdfunding finanziert auf den Markt kommen – für ca. 130 Euro gibt es dann das zweiteilige Set zum Öffnen der Eingangstür von Mehrparteienhäusern und der eigenen Wohnung. Dank Blockchain sicher umgesetzt.

Ich bin gespannt wie sich beide Projekte entwickeln, lackey und das Upgrade mittels Implantaten!

Nachdem ich die Cebit 2016 ausgelassen habe, war dies heuer meine 26. Cebit die ich besuchte. Seit 1991 habe ich also nur zwei Stück ausgelassen. Ich habe also quasi den Aufstieg und Fall der Cebit schön miterlebt.

Ich kenne noch die alte Halle 1 in der die Big Player jedes Jahr ihre Neuheiten präsentierten, damals wurden Innovationen noch extra für die Cebit zurück gehalten und dort der Öffentlichkeit präsentiert. Inzwischen hat jedes größere Unternehmen seine eigene Hausmesse oder nutzt das Internet und seine Möglichkeiten.

Zu den Hochzeiten der Cebit waren es 27 prall gefüllte Messehallen und jede Menge Attraktionen – vom Musical über legendäre Messeparties bis hin zur Standing Wave war alles da.

Inzwischen ist da nicht mehr wirklich viel davon übrig geblieben, die Cebit 2017 hat es gerade mal auf 13 gefüllte Messehallen gebracht (exklusive Cebit Global Conferences – Halle 8, die bleibt normalen Cebit Besuchern vorenthalten). Von denen einige teilweise leer standen, großzügig abgesperrt oder von einer einzigen Firma besetzt waren.

Die Anzahl der Aussteller verändert sich in den letzten Jahren nur marginal, was aber jedem Besucher sofort auffällt ist dass die großen Player immer weniger werden und dafür Startups auf Gemeinschaftsständen überhand nehmen. Hier findet man auch die eigentlichen Perlen der Cebit!

Die über 200.000 Besucher die heuer auf der Cebit waren haben sich vermutlich extrem gut verteilt – gefühlt waren es nicht so viele.

Die Pressemitteilung zur nächsten Cebit liest sich irgendwie als würde man jetzt unbedingtdas junge Publikum ansprechen und hip sein wollen… Beim Buzzword „Y-Generation“ kommt mir inzwischen das Kotzen – ich kann’s nicht mehr hören.

Der Ansatz Startups eine Plattform bieten zu wollen liest sich gut, geht meiner Meinung nach aber voll auf Kosten der Alteingesessenen Firmen – da werden sich einige einen Messeauftritt überlegen. Ein Problem bei den Startups ist auch dass die schiere Menge das Angebot unübersichtlich werden lässt – wer hier nach Perlen taucht verliert viel Zeit.

Die meisten haben auch noch kein fertiges Produkt am Start – Entscheidern dürfte das missfallen, Endverbraucher sind hier toleranter und lassen sich auch mal auf eine Crowdfunding Kampagne ein. Für zweitere ist dann auch der Publikumstag gedacht.

Mein Fazit: Ich hatte auf jeden Fall meinen Spaß auf der Cebit und viele Interessante Produkte/Firmen kennen gelernt, das Ausbleiben einiger großer Anbieter war für mich eine herbe Enttäuschung. Der Wert der Cebit ist für mich erneut ein ganzes Stück gesunken – für nächstes Jahr überlege ich, ob für mich nicht die Hannover Messe interessanter ist als die Cebit.

Seit Ubuntu 16.04 nutzt die Distribution „predictable names“ für’s Netzwerkinterface, der Vorteil aus User-Sicht ist wohl dass auch beim Hinzufügen neuer Karten die Bezeichnung der vorhandenen gleich bleiben.

Ab und zu stört es mich aber und dann brauche ich mein „eth0“ zurück – das klappt schnell und einfach indem man dem Kernel einen Boot-Parameter anhängt.

Durch Editieren der Datei /etc/default/grub und anschließendem update-grub klappt das unter Ubuntu am schnellsten – diese Zeile hier muss so angepasst werden:

GRUB_CMDLINE_LINUX=“net.ifnames=0 biosdevname=0″

Ein frisch installierter Gigabyte Brix 1900 bleibt bei beinahe jedem Reboot an folgender Stelle hängen: Shutdown target reached

Auch nach einer Nacht warten passiert hier nichts mehr, die für dieses Problem vorgeschlagenen Lösungen aus dem Netz habe ich alle durch probiert – weder das Deaktivieren des Swap vor dem Shutdown noch das aktivieren der Debug Console für den Shutdown hatten was gebracht (Console war bereits tot nachdem das shutdown target erreicht wurde).

Also habe ich nach einer Möglichkeit gesucht am Ende des Shutdowns noch ein Script zu starten, systemd sollte das ja irgendwie hin bekommen…

Warum am Ende des Shutdowns noch ein Script starten?
Weil ich für Systeme die beim Shutdown hängen in einem meinerer früheren Blog Posts bereits eine Lösung gezeigt habe und diese könnte auch hier weiterhelfen!

Als erstes habe ich jetzt eine Datei (/usr/local/sbin/reboot_instantly.sh) erstellt mit folgendem Inhalt befüllt:

#!/bin/bash
echo 1 > /proc/sys/kernel/sysrq
sync && echo b > /proc/sysrq-trigger

Als nächstes habe ich für den systemd eine Service Datei erstellt (/etc/systemd/system/force_reboot.service):

[Unit]
Description=force reboot

[Service]
Type=oneshot
ExecStart=/bin/true
ExecStop=/usr/local/sbin/reboot_instantly.sh

[Install]
WantedBy=multi-user.target

Und mit „systemctl enable force_reboot.service“ aktiviert – leider klappt das so überhaupt nicht! Sondern beim Start wird das ganze ausgeführt und die Kistet resettet sich immer dann wenn sie gestartet ist…

Also zurück zum Start und weitergesucht – es gibt tatsächlich genau für diesen Zweck eine passende Lösung, systemd startet alle Scripte die im Verzeichnis /lib/systemd/system-shutdown/ liegen nachdem der shutdown abgeschlossen ist!

Also einfach das Script „reboot_instantly.sh“ dorthin kopiert und leicht modifiziert:

#!/bin/sh
if [ „$1“ = „reboot“ ]; then
echo 1 > /proc/sys/kernel/sysrq
sync && echo b > /proc/sysrq-trigger
fi

Und damit klappt es jetzt auch wieder mit dem Reboot. Beim Shutdown schaltet sich das System allerdings nicht von selbst ab, das muss manuell erledigt werden.

Eigentlich sollte man das auch mit diesem Script nachrüsten können, die folgenden Zeilen sollten das bewerkstelligen:

if [ „$1“ = „poweroff“ ]; then
echo 1 > /proc/sys/kernel/sysrq
sync && echo o > /proc/sysrq-trigger
fi

Klappt aber leider nicht mit dem Gigabyte Brix 1900…

Der kleine Kasten wäre echt ein nettes Gerät für gewisse Zwecke, seine kleinen Macken machen ihn aber aus meiner Sicht nur zu einer Notlösung!

Nach einem Upgrade von Ubuntu 14.04 auf 16.04 bekomme ich auf einem Kiosk System mit automatischem Login und Start des X11 Servers als nicht root-User in der Xorg.0.log Datei eine Fehlermeldung dass auf /dev/tty1 nicht zugegriffen werden kann.

Keine Rechte – OK, erst mal in der /etc/group Datei den User zu den Gruppen tty und vga hinzugefügt und neu gestartet…

Neue Fehlermeldung, selbes Ergebnis – X11 startet nicht.

Die neue Fehlermeldung lautet:

[ 16.675] (EE) Fatal server error:
[ 16.675] (EE) xf86OpenConsole: Cannot open virtual console 2 (Permission denied)

Nach längerer Recherche im Netz habe ich dann die Lösung gefunden – es muss ein zusätzliches Paket installiert werden.

sudo apt-get install xserver-xorg-legacy

Hat das Problem bei mir beseitigt, das Kiosk System funktioniert wieder.

Der Windows Agent von Veeam liefert nach dem Backup einen recht netten Bericht mit dem Status der gerade durchgeführten Sicherung:

Selbige Funktion fehlt dem Linux Agent leider, dem kann man zwar durch manuelles Aufrufen der Console ähnliche Daten entlocken – wirklich praktisch ist das allerdings nicht…

Als alter Bash Liebhaber findet sich aber fast immer für jedes Problem eine Lösung, ich habe ein kleines Bash Script gebaut welches die Werte vom letzten Veeam Backup Job ausliest und mittels Template File aufbereitet und per Mail versendet.

Das Ergebnis sieht dann wie folgt aus:

Die Unterschiede sind relativ gering, mit den Daten kann man aber auf jeden Fall was anfangen!

Hier gibt es das kleine Script zum Herunterladen:

http://www.grufo.com/veeam_mail.sh.txt

und das dafür nötige Template File:

http://www.grufo.com/veeam_mail_template.html

Ich habe die beiden Datein auf meinem Linux System unter /usr/local/sbin/ abgelegt, der Pfad zur Template Datei ist entpsrechend im Script anzupassen – ebenso wie Absender und Empfänger Mail Adresse und der Name des Backup Jobs.

Man kann das Script als Post-Job Script beim Veeam Job mit angeben, sollte der letzte Job noch nicht fertig sein beendet sich das Script ohne weitere Meldungen.

Fehler werden auch entsprechend farblich gekennzeichnet und mit den Error Meldungen aus dem Logfile versehen:

Mir fehlt im Moment noch eine „Warning“ Mail vom Windows Agent damit ich die auch noch entsprechend anpassen kann, dürfte aber nur eine Frage der Zeit sein.

Ich hoffe ich kann mit dem kleinen Script auch anderen Veeam Nutzern eine Freude bereiten – positives Feedback ist willkommen!

27.09.2017 – Update:

Ein paar kosmetische Änderungen habe ich noch vorgenommen, die Details kommen jetzt mit Zeilenschaltungen daher und nicht mehr in einer Wurst, die Agent Version vom Linux wird mit angegeben und Warnings erscheinen in orange.

Schönes Phänomen bei einer Intel 82599ES 10-Gigabit Karte mit SFP+ Adaptern, ein Interface läuft wie am Schnürchen, das andere bekommt um’s Verrecken den Link nicht hoch.

ethtool enp1s0f1 vermeldet folgendes:

Settings for enp1s0f1:
Supported ports: [ FIBRE ]
Supported link modes: 1000baseT/Full
10000baseT/Full
Supported pause frame use: No
Supports auto-negotiation: Yes
Advertised link modes: 10000baseT/Full
Advertised pause frame use: No
Advertised auto-negotiation: Yes
Speed: Unknown!
Duplex: Unknown! (255)
Port: FIBRE
PHYAD: 0
Transceiver: external
Auto-negotiation: on
Supports Wake-on: d
Wake-on: d
Current message level: 0x00000007 (7)
drv probe link
Link detected: no

Was einen nicht wirklich weiter bringt – das manuelle Setzen von Speed und Dupley mit ethtool geht auch nicht.

Schaut man etwas genau mit ethtool hin (Parameter -m) dann sieht die Ausgabe wie folgt aus:

Identifier : 0x03 (SFP)
Extended identifier : 0x04 (GBIC/SFP defined by 2-wire interface ID)
Connector : 0x07 (LC)
Transceiver codes : 0x10 0x00 0x00 0x01 0x00 0x00 0x00 0x00
Transceiver type : 10G Ethernet: 10G Base-SR
Transceiver type : Ethernet: 1000BASE-SX
Encoding : 0x06 (64B/66B)
BR, Nominal : 10300MBd
Rate identifier : 0x02 (8/4/2G Rx Rate_Select only)
Length (SMF,km) : 0km
Length (SMF) : 0m
Length (50um) : 80m
Length (62.5um) : 30m
Length (Copper) : 0m
Length (OM3) : 300m
Laser wavelength : 850nm
Vendor name : Intel Corp
Vendor OUI : 00:1b:21
Vendor PN : FTLX8571D3BCV-IT
Vendor rev : A
Option values : 0x00 0x3a
Option : RX_LOS implemented
Option : TX_FAULT implemented
Option : TX_DISABLE implemented
Option : RATE_SELECT implemented
BR margin, max : 0%
BR margin, min : 0%
Vendor SN : AKAO01D
Date code : 150211
Optical diagnostics support : Yes
Laser bias current : 7.668 mA
Laser output power : 0.5571 mW / -2.54 dBm
Receiver signal average optical power : 0.0010 mW / -30.00 dBm
Module temperature : 39.20 degrees C / 102.56 degrees F
Module voltage : 3.3007 V
Alarm/warning flags implemented : Yes
Laser bias current high alarm : Off
Laser bias current low alarm : Off
Laser bias current high warning : Off
Laser bias current low warning : Off
Laser output power high alarm : Off
Laser output power low alarm : Off
Laser output power high warning : Off
Laser output power low warning : Off
Module temperature high alarm : Off
Module temperature low alarm : Off
Module temperature high warning : Off
Module temperature low warning : Off
Module voltage high alarm : Off
Module voltage low alarm : Off
Module voltage high warning : Off
Module voltage low warning : Off
Laser rx power high alarm : Off
Laser rx power low alarm : On
Laser rx power high warning : Off
Laser rx power low warning : On
Laser bias current high alarm threshold : 11.800 mA
Laser bias current low alarm threshold : 4.000 mA
Laser bias current high warning threshold : 10.800 mA
Laser bias current low warning threshold : 5.000 mA
Laser output power high alarm threshold : 0.8318 mW / -0.80 dBm
Laser output power low alarm threshold : 0.2512 mW / -6.00 dBm
Laser output power high warning threshold : 0.7079 mW / -1.50 dBm
Laser output power low warning threshold : 0.3162 mW / -5.00 dBm
Module temperature high alarm threshold : 78.00 degrees C / 172.40 degrees F
Module temperature low alarm threshold : 12.00 degrees C / 53.60 degrees F
Module temperature high warning threshold : 73.00 degrees C / 163.40 degrees F
Module temperature low warning threshold : 17.00 degrees C / 62.60 degrees F
Module voltage high alarm threshold : 3.7000 V
Module voltage low alarm threshold : 2.9000 V
Module voltage high warning threshold : 3.6000 V
Module voltage low warning threshold : 3.0000 V
Laser rx power high alarm threshold : 1.0000 mW / 0.00 dBm
Laser rx power low alarm threshold : 0.0100 mW / -20.00 dBm
Laser rx power high warning threshold : 0.7943 mW / -1.00 dBm
Laser rx power low warning threshold : 0.0158 mW / -18.01 dBm

Im direkten Vergleich mit einem funktionierenden Interface fällt folgender Unterschied auf:

Receiver signal average optical power : 0.0010 mW / -30.00 dBm

Das ist einfach zu wenig – es braucht auf jeden Fall mehr als 0.0100 mW!

Somit kann man in dem Fall davon ausgehen dass es was mit dem Kabel hat, es kommt auf jeden Fall zu wenig Signal an!

Ich habe auf einem meiner Systeme einen ZFS zpool (mirror) erstellt, bisher hat das alles wunderbar geklappt – nachdem ich am System eine USB Sicherungsplatte angeschlossen und neu gestartet habe, tritt folgendes Problem auf:

Die USB Platte wird als /dev/sda erkannt und meine eigentlichen Systemplatten verschieben sich zu /dev/sdb und /dev/sdc.

Der zpool wird folglich nicht mehr korrekt erkannt und gemountet.

Damit das jetzt wieder klappt müssten die Partitionen via /dev/disk/by-id gemountet bzw. der zpool entsprechend importiert werden.

Um mir künftig das Suchen zu ersparen hier ganz kurz der Ablauf:

• alle betroffenen Partitionen unmounten
• zpool export pool-name
• System mit angeschlossener USB Platte starten
• zpool import -d /dev/disk/by-id pool-name
• System neu starten

Anschließend sollte der Pool zuverlässig über die /dev/disk/by-id geladen werden.

Mit dem von Veeam erstellen Custom Recovery ISO Image hatte ich Probleme beim Rücksichern eines älteren HP Servers – die Broadcom Netzwerkkarten wurden nicht erkannt und ohne Netzwerk schaut’s mau aus mit der Rücksicherung!

Als einfach Lösung bietet sich ein klassisches Live System an, in meinem Fall habe ich einfach ein Ubuntu 14.04 Live System vom USB Stick gestartet und dort in der Konsole folgende Befehle ausgeführt:

echo ‚deb [arch=amd64] http://repository.veeam.com/backup/linux/agent/dpkg/debian/public stable veeam‘ > /etc/apt/sources.list.d/veeam.list
apt-get update
apt-get install veeam -y –allow-unauthenticated
echo -e ‚\n[recoveryui]\nenableOnLiveSystem= true‘ >> /etc/veeam/veeam.ini
service veeamservice restart
echo -e ‚ACTION==“add|change“, SUBSYSTEM==“block“, ENV{UDISKS_IGNORE}=“1″‚ > /etc/udev/rules.d/10-myudisks2.rules
veeamconfig recoveryui

Mit dem letzte Befehl startet die Kommandozeilen GUI über die ich dann meine Samba Freigabe mit der Sicherung gemountet habe, von dort lässt sich dann das letzte Backup ohne Probleme wiederherstellen!

Letzte Woche hatte ich während einer Umstrukturierung meines WLAN’s zwei meiner Kameras von fixer IP Adresse auf DHCP umgestellt. Im Zuge dessen habe ich einen Access Point (Cisco Meraki) aktiviert und getestet.

Dieser liefert auch eine recht schöne und detaillierte Statistik über den Traffik den die WLAN Clients generieren mit.

Mit der Traffic Übersicht die der Meraki AP für die Clients liefert fällt einem dann eines schnell auf, die China Kamera belastet die Leitung über Gebühr – in nicht einmal einer Woche fast 32 GB an Upload, das ist auf jeden Fall zu viel!

In meinem Fall sollte das eigentlich deutlich weniger sein, da ich die Bilder intern abgreife und selbst nach dem Weiterbearbeiten auf meinen Webserver lade.

Was geht hier also vor?
Ganz einfach die Kamera liefert einen Live Stream auf das Portal des Kamera Herstellers, ähnliches war ja bereits vor geraumer Zeit in der CT zu lesen.

Und wie löst man das Problem am einfachsten – man verpasst der Kamera wieder eine fixe IP Adresse und einen DNS Server der nicht antwortet. Schon findet die Kamera ihr Zuhause nicht mehr und sendet keinen Videostream dorthin…

Schön zu erkennen am sofort abfallenden Datenvolumen!

Mit dem Unifi Controller lässt sich Unifi Hardware wunderbar managen, das Ding läuft auch unter Linux sehr gut und integriert die Netzwerkverwaltung an einer Stelle – eigentlich alles wunderbar. Einzig hinter einem Proxy Server mit restriktiven Einstellungen bei der Firewall hat das Ding seine Probleme – hier hat die Firma Ubiquiti aus unbekannten Gründen keine Proxy Unterstützung integriert.

Im Controller kann man unter Maintenance für alle Firmware Versionen die Dateien cachen – ein Klick auf den „Cache“ Button sollte eigentlich im Hintergrund einen Download starten.

Sobald kein direkter Zugriff auf das Internet möglich ist erscheinen im unifi Logfile folgende Meldungen:

<webapi-126> ERROR system – Error in downloading https://dl.ubnt.com/unifi/firmware/US24P250/3.9.6.7613/firmware.bin

Da auch unser Controller ohne Proxy nicht auf’s Internet zugreifen darf klappt auch das Cachen der Firmware Dateien auf dem Controller nicht.

<webapi-88> WARN system – failed to get firmware update info: connect timed out

Mein Ansatz das Problem zu lösen bzw. zu umgehen ist folgender:

Ich übernehme den Download der Firmware Dateien und lege sie dort ab wo sie der Controller anschließend laden kann, dafür überarbeite ich die „bundles.json“ Datei in der der Pfad der Firmware Datei für den Download hinterlegt ist.

Folgendes Bash-Script erledigt dies:

https://www.grufo.com/get_unifi_firmware.sh.txt

Einfach herunterladen, unter get_unifi_firmware.sh abspeichern und mittels „chmod +x get_unifi_firmware.sh“ ausführbar machen.

Für den Download habe ich einfach am Controller einen nginx Server installiert und die Dateien in dessen Default Ordner abgelegt. Die Pfad müssen im Script entsprechend angepasst werden, ebenso der Proxy Server.

Nach dem Ausführen des Scriptes sollten die Firmware Dateien im angegebenen Ordner zu finden sein und über die Server URL erreichbar sein.

Die bundles.json Datei wurde nach dem Download mit den lokalen Pfaden versorgt, der Controller sollte am Ende des Scripts automatisch neu gestartet worden sein. Im Controller Webinterface kann man sich jetzt neu anmelden und unter Maintenance den Cache der Firmware Dateien aktualisieren.

Nach nur wenigen Klicks sollte die Firmware im Cache geladen sein und die Unifi Endgeräte können direkt darauf zugreifen und das Firmware Upgrade einspielen…

Was mich etwas nachdenklich macht ist dass Unifi es seit längerer Zeit nicht für nötig befunden hat ihren Controller Proxy tauglich zu machen – für Unternehmen sollte ein direkter Internet Zugriff ohne Kontrolle eigentlich tabu sein!

Der Unterschied zwischen günstigen und teuren RAID Controller Karten stellt sich oft erst in seltenen Momenten dar – aktuell bei mir gerade mal wieder bei einem 3-Ware RAID Controller Modell 9750-4i. Ein RAID 1 aus zwei 1 TB Platten wurde etwas zu klein und musste durch größere 4 TB Platten erweitert werden.

In der Theorie wäre meine Vorgehensweise so:
– Die 1. Platte mit 4 TB Platte tauschen
– RAID Rebuild mit neuer Platte starten und abwarten
– Die 2. Platte mit 4 TB Platte tauschen
– RAID Rebuild erneut starten und abwarten
– anschließend Volumes und Filesysteme vergrößern und fertig…

In der Praxis scheitert das Ganze beim Vergößeren der RAID1 Unit – der 3Ware Controller kennt zwar theoretisch einen Befehl dafür, das klappt aber wohl nur wenn man z.B: bei einem RAID5 eine weitere Platte ins System hängen will. Mit einem RAID1 funktioniert es schlicht so nicht. Die Hilfe von tw_cli ist nicht wirklch sehr hilfreich, oder wer kann mit „[disk=<p:-p..>]“ wirklich viel anfangen?

Der Trick mit dem es funktioniert ist das komplette RAID1 zu zerpflücken und ein Laufwerk zu entfernen bevor die Daten auf die neue Platte kopiert werden:

1. RAID1 Array aufteilen. Es entstehen zwei Arrays mit dem gleichen Inhalt und der gleichen Größe.

   tw_cli /c0/u1 migrate type=single
   

   Die bisherige Partitionen /dev/sd* welche auf das RAID1 Einheit /u1 zeigen bleiben erhalten. Man bekommt eine neue Einheit /u2 welche aus der zweiten Platte besteht.

2. Jetzt können wir die zweite Platte/Einheit /u2 komplett vom Controller entfernen und anschließend die größere Platte einbauen.

   tw_cli /c0/u2 del
   

3. Die neue Platte im Controller anlegen, das geht im BIOS oder im fertig gestartetem System mit folgendem Befehl:

   tw_cli /c0 add type=single disk=1
   

   die neue Platte/Einheit /u2 sollte jetzt die volle Plattengröße anzeigen (4 TB).

4. Jetzt werden alle Daten von der alten Platte /u1 auf die neue /u2 übertragen


   dd if=/dev/sdc of=/dev/sdd bs=64k
   

   Wer in einer zweiten Konsole watch -n60 "kill -USR1 $(pgrep ^dd)" startet, bekommt alle 60 Sekunden beim dd Befehl den aktuellen Fortschritt angezeigt. Bei 183 MB/s waren meine knapp 1TB an Daten in etwas mehr als 1,5 Stunden kopiert. Von den gelegentlichen Neustarts die nötig sind ist dies die einzige längere Downtime die man hinnehmen muss.

5. Die verbliebene alte Festplatte kann jetzt aus dem Controller entfernt und durch die neue 4TB Platte ersetzt werden.

   tw_cli /c0/u1 del
   

6. Und jetzt kommt der spannende Teil, wir erstellen aus einer Platte die noch nicht in Verwendung ist und der 4 TB Platte mit den Daten /u2 ein neues RAID

   tw_cli /c0/u2 migrate type=raid1 disk=1
   

   Der Rebuild sollte jetzt in Kürze starten:

   watch „tw_cli /c0 show“

   beobachtet den Rebuild Prozess…

7. Anschließend muss man nur noch die Partitionen vergrößern
   

   parted /dev/sdd resizedisk 3 2000G

   Vergrößert die 3. Partition wobei die 2000G nicht die Größe sondern den Endpunkt der Partition darstellen!

8. Und das Filesystem anpassen
   

   resize2fs -p /dev/sdd3

   Der Parameter „-p“ vergrößert das Filesystem auf das maximal mögliche – je nach Größe der Partition.

Ich hoffe dem einen oder anderen Hilft diese Anleitung weiter, mir wird sie künftig auf jeden Fall etwas Zeit einsparen!

Auf einem frisch installiertem Linux System hat mir heute beim Einrichten von Veeam ein früher auf der Platte installiertes BTRFS einen Strich durch die Rechnung gemacht!

Veeam Meldet beim Einrichten eines Backup im „Entire Machine“ Modus dass es kein BTRFS unterstützt. Schön und gut, aber auf meine System gibt es nur ext2, swap und ext4 Partitionen…

Das Übel liegt in Master Boot Record – hier hat BTRFS früher mal etwas hinterlegt was veeam beim Einrichten der Sicherung abfrägt und somit durchaus korrekt zum Schluss kommt dass hier ein BTRFS im Einsatz ist (bzw. war).

Die Idee den MBR von Grub neu schreiben zu lassen ist wohl die naheliegendste – allerdings scheitert man hier mit folgender Meldung:

Installing for i386-pc platform.
grub-install: warning: Attempting to install GRUB to a disk with multiple partition labels. This is not supported yet..
grub-install: warning: Embedding is not possible. GRUB can only be installed in this setup by using blocklists. However, blocklists are UNRELIABLE and their use is discouraged..
grub-install: error: will not proceed with blocklists.

Abhilfe schafft man hier indem man den MBR erst mal mit Nullen überschreibt und anschließend Grub wieder einen bauen lässt.

dd if=/dev/zero of=/dev/sda seek=1 count=2047
grub-install /dev/sda

Damit wurde der MBR auf meiner Platte /dev/sda erst mit Nullen überschrieben und dann von Grub neu erstellt.

Anschließend klappt es auch mit veeam!

Auf der Webseite von paccoin.net wird eine vorcompilierte Version ihrer Wallet für den $PAC Coin angeboten – wohl gemerkt für Ubuntu 16.04. Allerdings läuft das Ding nicht wirklich out of the box.

Folgende Schritte waren bei mir nötig um das Wallet zum Laufen zu bekommen:

sudo apt-get install libprotobuf9v5 libevent-pthreads-2.0-5 libevent-2.0-5
sudo add-apt-repository ppa:bitcoin/bitcoin
sudo apt-get update
sudo apt-get install libdb4.8 libdb4.8-dev libdb4.8++

Damit klappt dann der Aufruf von paccoin-qt ohne Fehlermeldung!

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.

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

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“.

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

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.

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