TS3, SQLite und der Dump

Posted on 22. Dezember 2018 by marius

Es waren einmal: Ein TeamSpeak3 Server, eine SQLite Datenbank und ein Fedora 28 Upgrade. Ja, ich weiß, Ihr habt die Schnauze voll von „da geht schon wieder was mit F28 nicht“ berichten, aber was soll man machen? Irgendwie muß man die beheben, oder?

DatabaseError database disk image is malformed

Nach dem F28 Serverupdate brauchte ich mal meinen TS3 Server, also wollte ich den starten. Ich wollte schon behaupten, daß ich es nicht anders erwartet habe, aber eigentlich war ich optimistisch. Half aber nichts, der TS3 Server gab nur dies zum Besten:

CRITICAL|ServerLibPriv | | Server() DatabaseError database disk image is malformed

Um es kurz zu machen, die SQLite DB war technisch in Ordnung, aber irgendeine Checksumme wollte nicht, wie TS3 das wollte. Eine kurze Recherche im Jahr 2010!!! ergab, daß ein anderer User sowas mal mit einem simplen SQL-Dump gefixt hatte. Eine gute und einfache Möglichkeit, wenn sie denn funktioniert.

echo „.dump“ | sqlite3 ts3server.sqlitedb | sqlite3 new.db

Das funktioniert auch soweit, nur daß new.db am Ende lediglich 0 Byte groß war und es ums verrecken auch nicht anders haben wollte. Das Geheimnis lag im SQL.Dump. Der hatte eine Transaktion aufgemacht, aber nicht mit COMMIT geschlossen. Ergo, nie beendet , ergo 0 Byte Datenbank.

echo „.dump“ | sqlite3 ts3server.sqlitedb > dump.sql
vi dump.sql
sqlite3 new.db < dump.sql
mv new.db ts3server.sqlitedb
chown {tsuser} ts3server.sqlitedb

und schon startet der Teamspeakserver wieder 🙂

Frohe Weihnachten ihr Bugs!

XENServer – Wie man coalesce Probleme los wird

Posted on 20. Dezember 2018 by marius

Es gibt einige echte Knackpunkte im Xen System, an denen der Admin verzweifeln kann. Einer davon ist der Coalesce-Fehler. Dieser wird ausgelöst, wenn auf der Storage kein Platz mehr ist, um das Zusammenführen von Bruchstücken einer VM durchzuführen.

EXCEPTION util.SMException, Timed out

Im SMLog des Xenservers sieht das dann so aus :

Dec 6 02:27:17 xen SMGC: [10357] SR db4c ('Local SATA Storage') (5 VDIs in 4 VHD trees): no changes
Dec 6 02:27:17 xen SMGC: [10357] Removed leaf-coalesce from 67558d6a[VHD](2020.000G//2023.953G|ao)
Dec 6 02:27:17 xen SMGC: [10357] *~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*
Dec 6 02:27:17 xen SMGC: [10357] ***********************
Dec 6 02:27:17 xen SMGC: [10357] * E X C E P T I O N *
Dec 6 02:27:17 xen SMGC: [10357] ***********************
Dec 6 02:27:17 xen SMGC: [10357] leaf-coalesce: EXCEPTION util.SMException, Timed out
Dec 6 02:27:17 xen SMGC: [10357] File "/opt/xensource/sm/cleanup.py", line 1435, in coalesceLeaf
Dec 6 02:27:17 xen SMGC: [10357] self._coalesceLeaf(vdi)
Dec 6 02:27:17 xen SMGC: [10357] File "/opt/xensource/sm/cleanup.py", line 1637, in _coalesceLeaf
Dec 6 02:27:17 xen SMGC: [10357] return self._liveLeafCoalesce(vdi)
Dec 6 02:27:17 xen SMGC: [10357] File "/opt/xensource/sm/cleanup.py", line 2174, in _liveLeafCoalesce
Dec 6 02:27:17 xen SMGC: [10357] return SR._liveLeafCoalesce(self, vdi)
Dec 6 02:27:17 xen SMGC: [10357] File "/opt/xensource/sm/cleanup.py", line 1685, in _liveLeafCoalesce
Dec 6 02:27:17 xen SMGC: [10357] self._doCoalesceLeaf(vdi)
Dec 6 02:27:17 xen SMGC: [10357] File "/opt/xensource/sm/cleanup.py", line 1719, in _doCoalesceLeaf
Dec 6 02:27:17 xen SMGC: [10357] vdi._coalesceVHD(timeout)
Dec 6 02:27:17 xen SMGC: [10357] File "/opt/xensource/sm/cleanup.py", line 690, in _coalesceVHD
Dec 6 02:27:17 xen SMGC: [10357] self.sr.uuid, abortTest, VDI.POLL_INTERVAL, timeOut)
Dec 6 02:27:17 xen SMGC: [10357] File "/opt/xensource/sm/cleanup.py", line 149, in runAbortable
Dec 6 02:27:17 xen SMGC: [10357] raise util.SMException("Timed out")
Dec 6 02:27:17 xen SMGC: [10357] 
Dec 6 02:27:17 xen SMGC: [10357] *~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*
Dec 6 02:27:17 xen SMGC: [10357] Leaf-coalesce failed, skipping
Dec 6 02:27:17 xen SMGC: [10357] Starting asynch srUpdate for SR db4c3909-4b61-e5f6-8548-16dc56780f61

„Leaf“ , das sind die losen Enden einer Festplatte einer VM, wenn man z.b. einen Snapshot der VM angefertigt hat und diesen wieder löscht. Dann wird das, was im Snapshot war, auf die Festplatte übertragen. Dazu muß aber ggf. in LVM Storage eine neue Zwischenfestplatte mit gemeinsamer Größe gebaut werden, in der die „Leafs“ gemergt werden. Das passiert auch, wenn man eine Festplatte vergrößert. Den Vorgang nennt man „Coalesce“ (Zusammenfügen)

Kein Platz mehr

Sind die Ausgangsfestplatten zu groß oder die Storage zu klein, kann XEN die Daten nicht zusammenführen und obiges passiert. Wie bekommt man jetzt Platz , ohne das man Platz hat?

Da gäbe es zwei Möglichkeiten, wovon eine trivial ist: Neue Platten an das LVM hängen und so mehr Platz in der Storage schaffen. Die zweite Möglichkeit ist auch recht einfach, die VM auf eine andere Storage kopieren und danach wieder zurück kopieren. Bei dem mit der Kopieraktion verbundenen Export werden die Daten von Xen auch aus den Leafs gemergt, nur halt an einer anderen Stelle ( dem Ziel ).

Zwischen den Kopier- oder Export/Import-Aktionen muß man dem System allerdings Zeit geben aufzuräumen. Der Befehl „xen sr-scan …sruuid…“ in der XenServer Konsole, stößt nach dem Kopieren den Coalesce-Prozess an. Nun muß man warten bis Platz ist, dann kann die VM zurück auf Ihren alten Server.

USB oder NFS

Wenn man keine zwei Storages in einem Serverhost hat, muß man kreativ werden. Da bieten sich zwei Optionen an: Externe USB Platte ( dauert ewig und drei Tage ) oder ein NFS Mount auf einem anderen Server.

Es hat sich als gute Taktik erwiesen eine Transfer-VM zu haben, auf der genug Platz ist um die anderen VMs zwischenlagern zu können. Die kann man bei Bedarf hochfahren, mounted einen Pfad per NFS, exportiert die VM da hin, räumt auf und Import sie wieder von dort. Fertig.

Kleiner Tip: Snapshots zügig wieder löschen, bevor das Platzproblem auf der Storage anfängt.

Fröhliche Bugzeit Euch allen

Posted on 18. Dezember 2018 by marius

Fröhliche Bugzeit meine Lieben \o/ .. „Hey, Sie da!“ „ähh, ja?“ „Sollte das nicht Backzeit heißen?“ „Nein, das ist schließlich ein IT-Blog und keine Bäckerei!“

Fröhliche Bugzeit allerseits!

Alle Jahre wieder kommt die Bugzeit über uns. Derzeit sind es besonders viele Bugs in Fedora 28 und seit gestern, habe ich auch noch 4 Bugreports bei EBAY laufen und ich meine echte Anwendungsfehler. Da werden harmlose Bewertungstexte als vulgär bezeichnet, Nachrichten des Supports erreichen uns als HTML-CODE, falsche Fehlermeldungen eingeblendet, die mit der Sachlage nichts zu tun haben, und anderer Krams.

Auf der Fedorafront kommt ein Cinnamon Bug hinzu, der Icons von Programmen in der Leiste verschwinden läßt, Cairo wird für F29/30, aber nicht für F28 aktualisiert, weswegen F28 noch einen Bug mehr hat, als es bräuchte. Zu allem Überfluß hatte Skype dann heute auch einen technischen Ausfall, weil es Anrufe nur simuliert, statt sie durchzuführen 🙁

Der Hohn ist aber ein neues Meldegesetz für IT-Sicherheitslücken des Bundes! Als wenn von denen jemand wüßte wie das geht, geschweige denn, wie langwierig und kräftezehrend so ein Bugreport sein kann 😀

Und da sag noch mal wer, man solle nicht in Sarkasmus verfallen, bei soviel gehäuften Fehlverhalten. Manchmal glaube ich, daß es an ein Wunder grenzt, daß wegen der vielen Softwarebugs keine Leute sterben.