Artikelformat

Kaputt gemacht!

Heute gab es bei Debian ein Update auf die Version 3 des Webbrowsers Mozilla Firefox (der bei Debian unter dem Namen „iceweasel“ läuft). Ich habe dieses Update auch auf meinem Rechner in der Arbeit eingespielt und danach hatte ich eine Menge Extra-Arbeit.

Obwohl ich ein Vertreter von Linux und OpenSource bin kommt es doch hin und wieder mal vor, dass ich Windows-Applikationen nutzen muss, z.B. um docx-Dokumente im nativen Format zu erstellen, denn 100% funktionierende Konverter für Libreoffice gibt es noch nicht. In so einem Fall behelfe ich mir mit dem Terminalserver meines Arbeitgebers zu dem ich mich mittels des Citrix-Receivers verbinde. Der bringt ein kleines Plugin mit und wenn ich also meinen „Windows-Desktop“ benötige klicke ich das im Webbrowser auf der entsrpechenden Intranet-Seite an und schon geht ein Fenster auf in dem der virtuelle Windows-Desktop verfügbar ist. Ist an und für sich eine ganz angenehme Methode mit Windows zu arbeiten ohne sich aber um die ganzen Updates kümmern zu müssen, denn das macht ja der Betreiber des Terminalservers.

Soweit so gut. Bis heute morgen ging das auch problemlos. Nach dem Update des Firefox passierte jedoch genau nichts mehr wenn ich meine virtuellen Windows-Desktop starten wollte. Es war mir relativ schnell klar, dass der neue Firefox wohl eine Inkompatibilität mit meinem Citrix-Receiver-Plugin hatte. Also habe ich mal nachgesehen, ob Citrix vielleicht eine neuere Version hat die dieses Probelm beheben könnte. Ja, haben sie…

Mittlerweile gibt es den Citrix-Receiver in der Version 13 als tarball, RPM und DEB-Pakete. Sogar ein DEB für die 64-bit-Architektur ist vorhanden. Die Ernüchterung kommt dann beim Installationsversuch, es installiert nämlich nicht weil in den Dependencies des Paketes drin steht, dass zum Installieren unbedingt die ia32-libs und andere 32bit Laufzeitbibliotheken notwendig sind. Das mag bei Debian 6 noch funktioniert haben, aber mittlerweile haben wir doch schon eine ganze Weile Debian 7 und Debian 7 hat „multiarch“, sprich es gibt keine ia32-libs mehr sondern man kann jede Library neben der 64-bit Version auch in der 32-bit Version installieren. Citrix hat mal wieder nichts anderes gemacht als die Binaries für 32bit in ein angebliches 64-bit-Paket zu packen und dann die nötigen Abhängigkeiten zu 32bit-Laufzeitbibliotheken in die Dependencies zu schreiben, aber eben ohne auf aktuelle Entwicklungen in den darunterliegenden Distributionen Rücksicht zu nehmen! Hallo Citrix, ihr habt den Sourcecode, also schießt den bitte durch den Compiler und nutzt das „-m64“ Flag von GCC, dann kommt hinten auch nativer 64-bit Code heraus der keine 32-bit Laufzeitbilbliotheken mehr benötigt. Dass es geht beweisen ja die für die ARM-Architektur gebauten Pakete.

Egal, man kann natürlich das von Citrix vermurkste Paket manuell zerpflücken, die Dependencies rauswerfen und neu packen. Dann installiert es auch, ohne Rücksicht auf Verluste. Die Probleme bekommt man dann beim Start der Programme um die Ohren gehauen, irgendwelche Libraries fehlen immer. So gibt es eine neue „Kontroll-Applikation“ namens „selfservice“ die auf Debian Wheezy in Ermangelung einer libwebkit-1.0 gar nicht läuft. Egal, der eigentliche Citrix-Receiver läuft, nur das Plugin wird zwar aktualisiert, läuft aber immer noch nicht.

In der resultierenden Verzweiflung habe ich dann die Zuordnungen zum „.ica“-Dateityp gelöscht, dann lädt das Ding die ica-Datei runter und man kann sie manuell an wfica (dem Binary des Receivers) übergeben. Oder in wfica.sh reinfüttern, dann wird man auch gleich eingeloggt und die Bildschirmauflösung passt auch.

Die Frage ist nur, warum das verdammte Plugin nicht mehr will. Diie Erklärung las ich später bei Heise, mit dem neuen Firefox haben die Entwickler die NPAPI-Schnittstelle erst mal abgeschaltet, man könne zwar diese für einzelne Plugins aktivieren, aber bei meiner Fehlersuche habe ich keine solche Option gefunden.

Bravo Mozilla-Team. Dieses Feature ist aus meiner Sicht hochproblematisch, denn

  • ihr verletzt dabei die „rule of the least surprise“ weil eine Funktionalität die vor dem Update ging nach dem Update plötzlich nicht mehr geht, was für den Benutzer eine böse Überraschung darstellt
  • ihr habt die NPAPI-Schnittstelle zwar deaktiviert, aber warum zum Teufel wird unter „about:plugins“ dieses Plugin dann weiterhin als „aktiviert“ ausgewiesen..?
  • Beim ersten Neustart der neuen Firefox-Version wird ein Kompatibilitätscheck für Erweiterungen durchgeführt. An dieser Stelle erwarte ich eigentlich, dass der Browser erkennt dass  ich ein Plugin nutze welches man gerne abschalten möchte, aber dann sollte man doch bitte fragen oder darauf hinweisen, dass hier maneulle Eingriffe (welche das sind habe ich noch nicht herausgefunden) notwendig sind um die Funktionalität auch in Zukunft nutzen zu können. Einfach deaktivieren ohne Meldung ist die denkbar schlechteste Alternative.

Ok, mittlerweile geht mein Citrix-Receiver auch ohne Plugin und das Problem ist gelöst. Aber eigentlich sind solche „nach Update kaputt“-Szenarios genau das was ich nicht brauche.

Autor: Rainer

Diplom-Informatiker, Baujahr 1961, Vater von 2 Kindern, Hundehalter, Sportschütze und Vereinsvorstand, Hobbymusiker (mit zweifelhaftem Erfolg), politisch interessiert, Leseratte, Freizeit-Philosoph und letztlich Blogger.

Kommentare sind geschlossen.