Firefox Addon Bug geht in Runde 2

Oh ja, Ihr dachtet es wäre vorbei? Der Zertifikatbug bei Mozilla wäre behoben? Weit gefehlt! Muahahar

Gegen 23:10 Uhr MESZ: Rückspiel

kam der Gegenschlag. Mozilla hat seit einigen Stunden signalisiert, daß das Problem behoben wäre. Mozillas Automatismus sollte das Problem genauso leicht beheben, wie es verursacht wurde.

Leider flogen gerade (23:10 Uhr) alle Plugins wieder in den Legacy Modus und liessen sich nur durch das Aktivieren und erneute Deaktivieren des KeySignings wieder zum Laufen bringen!

Also erneuerte Anleitung:

In der about:config einfach die Signaturenprüfung wieder anschalten:
xpinstall.signatures.required = true

und wieder abschalten:
xpinstall.signatures.required = false

Der FireFox braucht nicht neugestartet zu werden, aber die einzelnen Tabs müssen ggf. neu geladen werden.

1.Update: 5.5.2019

FireFox für Android schaltet alle Addons in den Legacy-Modus um, auch hier hilft wieder der Workaround von oben. Spannend daran ist, daß FireFox das erst beim Zweiten Start heute morgen gemacht hat. Aus Entwicklersicht ist das etwas merkwürdig.

2.Update: 6.5.2019

Seit gestern kursiert die FireFox Version 66.0.4 durch die Medien, diese soll das Problem jetzt endgültig lösen.

3.Update: 6.5.2019 15:00 Uhr

Ganz frisch aus dem Build Ofen von Fedora, FireFox 66.0.4-1 FC28 … geht!

Download:

Fedora 28: https://koji.fedoraproject.org/koji/taskinfo?taskID=34672367
Fedora 29: https://koji.fedoraproject.org/koji/taskinfo?taskID=34672363
Fedora 30: https://koji.fedoraproject.org/koji/taskinfo?taskID=34672350

Firefox Bug schaltet Plugins ab

3.UPDATE zum aktuellen Firefox-AddOn-Signing-Problem

\o/ Der Workaround aus Update 1 lässt auch Neuinstallationen wieder zu:

Armagadd-on-2.0 abgewendet 😀

2.UPDATE zum aktuellen Firefox-AddOn-Signing-Problem

Der Discourse Server von Mozilla mit den Infos zum aktuellen Firefoxproblem ist immer noch down bzw. überlastet, aber der Bugtracker ist erreichbar. Da könnt Ihr entnehmen, wenn es wieder „normal“ geht.

Und ich habe gestern, oder wars schon vorgestern, noch über den Umzug von AskFedora zum eigenen Discourseserver erzählt. Soooo belastbar scheinen die nicht zu sein, denn Mozilla kann sich bestimmt einen Cluster davon leisten 😉

1.UPDATE

Man kann doch was machen. In der about:config einfach mal die Signaturenprüfung abschalten:

xpinstall.signatures.required = false

und Firefox neustarten. Im Anschluß sind die Plugins wieder da. Voilà.

Hauptmeldung

Na, heute Morgen auch beim Start von Firefox die Meldung bekommen, daß einige oder alle Plugins nicht mehr zur Verfügung stehen ? Man könnte ihn den Quantum-Bug nennen 🙂

„One or more installed add-ons cannot be verified and have been disabled“

Was ist passiert? Ein Zertifikat für die Plugin und Extentionverwaltung ist abgelaufen und hat damit alle Plugins/Extentions effektiv als Legacy gekennzeichnet. Wer jetzt hofft, daß ein einfach Neuinstallieren der Addons hilft, weit gefehlt. Das führt nur zu weiteren Fehlern.

Wer auf dem Laufenden bleiben will bekommt … „429 Too Many Requests“. genau, die Mozilla Webseiten werden grade mit Anfragen geflutet! \o/ Das Internet im Partymodus!!! Verzweiflung macht sich breit! Die Familienadmins bekommen Anrufe von Leuten, die Sie nicht mal an Weihnachten zu Gesicht bekommen! Wenn Mozilla Mist macht, dann merkt man das richtig!

Mozilla arbeitet an einem Fix, aber bis der verteilt ist, kann es noch eine Weile dauern. Siehe unten.

Impakt

NoScript abgeschaltet! Hacker & Tracker freut Euch! NoScript UMatrix und alle anderen Schutzaddons sind tod!

Was könnt Ihr tun?

Nichts! Laßt es einfach. Das ist von Mozilla verursacht worden, ergo wird es auch dort gelöst.

Infos

Bugtracker: https://bugzilla.mozilla.org/show_bug.cgi?id=1548973
Mozilla Forum: https://discourse.mozilla.org/t/certificate-issue-causing-add-ons-to-be-disabled-or-fail-to-install/39047

merkwürdiger Bug: Fenster springen auf und ab

„Stell Dir vor, Du kommst zu Deinem Desktop und die Fenster springen rum!“ Gibts nicht? Virus!? Root-Kit!? Tja, das werden wir dann mal lüften müssen.

Die Beschreibung

Wir haben Fedora 29 , Gnome-Shell 3.22 und als Programme Firefox & den SimpleScreenRecorder laufen.

Nach ca. 8 Stunden mehr oder minder Dauerbetrieb sprangen die beiden Fenster immer gleichzeitig zwei Pixel rauf und wieder runter. So sah es zumindest aus, in Wirklichkeit sprang das ganze Display als Geflacker rauf und runter. Hat man aber erst beim extrem genauen hinsehen bemerkt, weil der Hintergrund monochromatisch und dunkel war.

Ursache

„Thermale Überhitzung durch 8 Stunden Dauerencoden.“

Merke, wer mit einem Tablet Tutorials aufnimmt, sollte ab und zu eine Pause machen. Oder wenigsten mal auf Energiesparmodus schalten, damit die CPU eine Chance hat abzukühlen. Wieso da die Lüfter nicht stärker liefen, bleibt ein Rätsel.

ein kleines Weihnachtswunder

Oh Binärbaum, Oh Binärbaum,
wie verzweigt sind Deine Äste.

Ein kleines Weihnachtswunder hat sich in der Gemeinde zugetragen: Scott Leigh, mein gelegentlicher Erzfeind im Bugzilla ;), hat einen meiner Bugreports ohne Kampf akzeptiert und ein Update bereit gestellt 😀 Danke, Scott 😉

Zieht Euch die Updates für Fedora 28, dem grade hier viel Gescholtenen, einfach auf Koji und ..

cinnamon-4.0.7-1.fc28
cinnamon-screensaver-4.0.3-1.fc28
cinnamon-translations-4.0.2-1.fc28
muffin-4.0.5-1.fc28

installiert Sie mit : dnf update ./muffin*rpm ./cinnamon*rpm

Natürlich funktioniert der Befehl nur dort, wo die RPMs vom Download liegen, aber das wußtet Ihr ja schon 🙂

Ich wünsche Euch noch ein schönes Restweihnachten und einen gemütlichen Jahreswechsel, jetzt ohne Fehlende-icons-im-Toolbar-Problem 😉

 

TS3, SQLite und der Dump

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!