Kategorien
Linux

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

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

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

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

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

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

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

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

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

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

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

Die Installation erfolgt nach dem Download durch folgenden Befehl:

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

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

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

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

Kategorien
Linux

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

Veeam Recovery mit Ubuntu Live System

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!

Kategorien
Linux

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

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.

Kategorien
Linux

Gigabyte Brix 1900 hängt beim Reboot mit Ubuntu 16.04

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!

Kategorien
Linux

Ubuntu 16.04 – Netzwerk Interface Name eth0 statt enoX bzw. ensX

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″

Kategorien
Allgemein

Owncloud zu Nextcloud Migrationsproblem mit Mysql DB Verbindung

Nachdem sich Nextcloud von Owncloud abgesplittet hat und die Entwicklung dort Fahrt aufgenommen hat, wollte ich heute eine Owncloud 9 Version nach Nextcloud 11 migrieren.

Der Direkte Pfad wird nicht empfohlen – hier die Empfehlung von Nextcloud:

  • ownCloud 8.0.x -> ownCloud 8.1.x -> ownCloud 8.2.x -> Nextcloud 9.0.x -> Nextcloud 10.0.x
  • ownCloud 8.2.x -> Nextcloud 9.0.x -> Nextcloud 10.0.x
  • ownCloud 9.0.x -> Nextcloud 9.0.x -> Nextcloud 10.0.x
  • ownCloud 9.1.x -> Nextcloud 10.0.x -> Nextcloud 11.0.x

In meinem Fall habe ich erst Owncloud auf die Version 9.1.4 hoch gezogen und dann migriert.

Die Migration hat allerdings nicht auf Anhieb geklappt – nach dem Einspielen der Dateien und dem Anpassen der Konfiguration bekam ich folgende Fehlermeldung:

Doctrine\DBAL\DBALException: Failed to connect to the database: An exception occured in driver: SQLSTATE[HY000] [2006] MySQL server has gone away in /var/www/nextcloud/lib/private/DB/Connection.php:59
Stack trace:
#0 /var/www/nextcloud/3rdparty/doctrine/dbal/lib/Doctrine/DBAL/Connection.php(429): OC\DB\Connection->connect()
#1 /var/www/nextcloud/3rdparty/doctrine/dbal/lib/Doctrine/DBAL/Connection.php(389): Doctrine\DBAL\Connection->getDatabasePlatformVersion()
#2 /var/www/nextcloud/3rdparty/doctrine/dbal/lib/Doctrine/DBAL/Connection.php(328): Doctrine\DBAL\Connection->detectDatabasePlatform()
#3 /var/www/nextcloud/3rdparty/doctrine/dbal/lib/Doctrine/DBAL/Connection.php(621): Doctrine\DBAL\Connection->getDatabasePlatform()
#4 /var/www/nextcloud/lib/private/DB/Connection.php(142): Doctrine\DBAL\Connection->setTransactionIsolation(2)
#5 /var/www/nextcloud/3rdparty/doctrine/dbal/lib/Doctrine/DBAL/DriverManager.php(172): OC\DB\Connection->__construct(Array, Object(Doctrine\DBAL\Driver\PDOMySql\Driver), Object(Doctrine\DBAL\Configuration), Object(Doctrine\Common\EventManager))
#6 /var/www/nextcloud/lib/private/DB/ConnectionFactory.php(121): Doctrine\DBAL\DriverManager::getConnection(Array, Object(Doctrine\DBAL\Configuration), Object(Doctrine\Common\EventManager))
#7 /var/www/nextcloud/lib/private/Server.php(415): OC\DB\ConnectionFactory->getConnection(‚mysql‘, Array)
#8 /var/www/nextcloud/3rdparty/pimple/pimple/src/Pimple/Container.php(113): OC\Server->OC\{closure}(Object(OC\Server))
#9 /var/www/nextcloud/lib/private/AppFramework/Utility/SimpleContainer.php(103): Pimple\Container->offsetGet(‚DatabaseConnect…‘)
#10 /var/www/nextcloud/lib/private/ServerContainer.php(89): OC\AppFramework\Utility\SimpleContainer->query(‚DatabaseConnect…‘)
#11 /var/www/nextcloud/lib/private/Server.php(1029): OC\ServerContainer->query(‚DatabaseConnect…‘)
#12 /var/www/nextcloud/lib/private/legacy/db.php(57): OC\Server->getDatabaseConnection()
#13 /var/www/nextcloud/lib/private/User/Database.php(232): OC_DB::prepare(‚SELECT `uid`, `…‘)
#14 /var/www/nextcloud/lib/private/User/Database.php(280): OC\User\Database->loadUser(“)
#15 /var/www/nextcloud/lib/private/User/Manager.php(140): OC\User\Database->userExists(“)
#16 /var/www/nextcloud/lib/private/User/Session.php(197): OC\User\Manager->get(“)
#17 /var/www/nextcloud/lib/private/Log.php(282): OC\User\Session->getUser()
#18 /var/www/nextcloud/lib/public/Util.php(159): OC\Log->log(3, ‚User backend OC…‘, Array)
#19 /var/www/nextcloud/lib/private/legacy/user.php(146): OCP\Util::writeLog(‚core‘, ‚User backend OC…‘, 3)
#20 /var/www/nextcloud/lib/base.php(742): OC_User::setupBackends()
#21 /var/www/nextcloud/lib/base.php(1074): OC::init()
#22 /var/www/nextcloud/console.php(56): require_once(‚/var/www/nextcl…‘)
#23 /var/www/nextcloud/occ(11): require_once(‚/var/www/nextcl…‘)
#24 {main}PHP Warning: call_user_func() expects parameter 1 to be a valid callback, class ‚OC\Log\File‘ not found in /var/www/nextcloud/lib/private/Log.php on line 299

Irgend ein Problem mit der Verbindung zur Datenbank – nachdem Owncloud zuvor mit der gleichen Config funktioniert hat und ich die Zugangsdaten mehrfach geprüft habe, kam ich zu dem Entschluß dass ich es mal mit einer frischen Datenbank versuchen könnte.

Also einfach die config/config.php verschmissen und neue Daten eingetragen. Wenige Sekunden später lief dann eine leere Instanz von Owncloud (keine User) mit den vorhandenen Files.

Als nächstes  habe ich einen Dump der alten Datenbank erstellt und diesen über die neue Datenbank gespielt. Eigentlich würde ich erwarten dass jetzt gleich wie vorher nicht mehr funktioniert. Falsch geraten – das Upgrade auf Nextcloud 10 ließ sich ohne Schwierigkeiten installieren.

Anschließend noch die Kür mit dem Upgrade auf Nextcloud 11 und beendet ist die kleine Upgrade-Orgie.

Warum das Ganze? Weil ich Kalender und Kontakte synchronisieren will… 🙂

PS: Im Zuge der Umstellung habe ich dann auch gleich von mysql zu mariadb gewechselt.