Frage zu --allow-downgrade

  • Hallo Zusammen,

    ich bin Admin an einer Schule. Bei uns liegt das Profil-Verzeichnis vom Firefox im Homeverzeichnis: Sprich: Das Profil ist auf h:\firefox-profil umgebogen. Weil wir ca. 300 Rechner haben, findet sich da natürlich nie jeweils die gleiche Version. Um dieses Problem zu minimieren bin ich auf die ESR Version umgestiegen.


    Nun gibt es beim neuen Firefox das Problem: Er beschwert sich, wenn ein Firefox das Profil öffnet, welches schon einmal von einer neueren Version geöffnet wurde.


    Ein erster Workarround ist das Aufrufen von Firefox mit --allow-downgrade zusätzlich im Verknüpfungs-Icon eingetragen.


    Nun habe ich aber festgestellt, dies bewährt sich in der Praxis nicht, weil der Firefox nicht immer über die Verknüpfung auf dem Desktop geöffnet wird.


    Nun habe ich gelesen, es soll noch eine 2. Möglichkeit geben: Man soll die Umgebungsvariable

    MOZ_ALLOW_DOWNGRADE setzten.


    Da benötige ich Hilfe: Ist das eine Umgebungsvariable für Windows, oder müsste das in about:config stehen? Da finde ich aber nichts. Was müsste in dieser Variable stehen?


    Es wäre Klasse, wenn hier jemand etwas näheres weiß.


    Danke und Gruß,

    Markus

  • Hallo,


    zunächst einmal: Dieser Downgrade-Schutz hat einen sehr guten Grund und sollte nicht unüberlegt übergangen werden. Wenn du dir über die möglichen Konsequenzen im Klaren bist und das dennoch umsetzen möchtest, ist alles gut. Ich will nur sichergehen, dass weißt, was du tust, bevor du meinen Tipp befolgst.


    Zum Sinn dieses Schutzes: Wenn du ein Firefox-Profil mit einer älteren Firefox-Version startest und dieses bereits mit einer neueren Firefox-Version aktiv war, ist das technisch betrachtet ein Downgrade. Das ist problematisch, weil es zu Datenverlusten führen kann. Diese Datenverluste sind nicht nur ein theoretisches Szenario, sondern geschehen real. Verschiedene Firefox-Versionen hatten in der Vergangenheit diesbezüglich verschiedene Hinweise in den Release Notes stehen, aber es gibt auch undokumentierte Szenarien.


    Nun zu MOZ_ALLOW_DOWNGRADE: Du hast selbst herausgefunden, dass es eine Umgebungsvariable ist, daher ist das nichts für about:config - was auch gar nicht funktionieren würde, da alles, was in about:config konfiguriert werden kann, erst in Betracht gezogen werden kann, wenn Firefox bereits gestartet ist. Hier brauchen wir aber eine Einstellung, die bereits vor dem Start von Firefox greift.


    Der Inhalt der Umgebungsvariable dürfte in dem Fall gar nicht von entscheidender Bedeutung sein, da seitens Firefox nur die Existenz der Variablen geprüft wird. MOZ_ALLOW_DOWNGRADE=1 sollte in jedem Fall funktionieren, das ist die am häufigsten dokumentierte Form.

  • Den Sinn verstehe ich wohl schon, bloss ist das Zusammenspiel zwischen der Art wie die Versionsnummerierung hier reinspielt und großen Environments mit 1000 oder mehr Rechnern, bei denen die Benutzer oft zwischen mehreren Rechner bzw. Terminalservern wechseln äusserst fatal. Da ist es selbst mit noch so viel Automatik kaum möglich die Versionen immer überall gleich zu halten.


    Das ganze wäre besser erträglich wenn Firefox nicht für jede minimale Änderung eine Hauptversionsnummer hochzählen würde und diese Sperre dann nur bei "Hauptversionsnummern" wirken würde.


    Gerade jetzt in Corona Zeiten, wo die Benutzer nur tageweise an Ihrem Bürorechner sitzen und dann wieder von zu Hause per VPN auf einen Terminalserver gehen trifft uns das richtig hart. Übrigens nicht nur bei Windows, auch bei Linux! Wir haben in beiden Bereichen um die 1000 Desktops mit je nach Standort / Lehrstuhl etc. unterschiedlichen Patchday-Zyklen (bzw. sehr seltenen Patches auf Experimentalsteuerungsrechner).


    Wäre also schon hilfreich, wenn die Entwickler bei Mozilla da etwas Benutzerfreundlicher denken würden, wir haben erheblich mehr verlorene Profile und Bookmarks durch diese Verhaltensweise des Firefox, als wir jemals durch unverträglichkeiten im Profil hatten!


    Aber gut dass ich jetzt diesen Eintrag mit der Environmentvariable gefunden habe !


    Viele Grüße,

    Klaus

  • Zitat

    wenn Firefox nicht für jede minimale Änderung eine Hauptversionsnummer hochzählen würde

    Das kannst du auch belegen? Ich mein, dieses Zählsystem ist ja nun schon einige Jahre aktiv, ich hätte fast behauptet, seit Firefox 4 - davor war es 1.x, 2.x, 3.x. Für Firefox 4 zeigen meine Dateien Mitte 2010 an - "bisschen" spät für Kritik daran.

    Zudem trifft es für die ESR auch nicht zu, deswegen wird die ja für Unternehmen empfohlen, als das die Verantwortlichen 1 Jahr Vorlauf bekommen, was die nächste ESR bringt.

    Zitat


    Er beschwert sich, wenn ein Firefox das Profil öffnet, welches schon einmal von einer neueren Version geöffnet wurde.

    Dann stimmt was am System nicht, wenn so ein Firefox-Mix vorhanden ist oder erzeugt werden darf.

    [ ] Danke [ ] Gehts noch?! [ ] Ich glaub, es hackt!
    Warum ist die "Eigenart" mancher Menschen größer als dieses Universum?

  • Das ganze wäre besser erträglich wenn Firefox nicht für jede minimale Änderung eine Hauptversionsnummer hochzählen würde und diese Sperre dann nur bei "Hauptversionsnummern" wirken würde.


    Für mich ist die einzige Interpretationsmöglichkeit dieser Aussage, dass das ein Witz sein soll. Die erste Stelle der Versionsnummer wird bei Major-Updates erhöht und jedes Major-Update von Firefox beinhaltet zahlreiche Veränderungen und nicht nur "minimale Änderungen". Du kannst ja mal die entsprechenden Artikel auf dieser Seite lesen, um eine ungefähre Vorstellung zu erhalten. Und diese Artikel beinhalten bereits nur eine Auswahl. In Wahrheit tut sich jedes Mal noch mehr.


    Davon abgesehen ist es auch vollkommen korrekt, die erste Stelle zu erhöhen. Vielleicht hast du ja schon einmal etwas von semantischer Versionierung gehört. Auch wenn Firefox nicht der klassischen semantischen Versionierung folgt, entspricht Mozillas Versionierung zumindest in einem ganz entscheidenden Punkt dem Gedanken der semantischen Versionierung: Nämlich, dass die erste Stelle der Versionsnummer bei abwärtsinkompatiblen Änderungen zwingend zu erhöhen ist. Und ob du das nun auf interne Firefox-APIs oder Erweiterungs-Schnittstellen beziehst, dieser Punkt trifft ohne Ausnahme auf jedes Major-Update von Firefox zu.


    Gerade jetzt in Corona Zeiten, wo die Benutzer nur tageweise an Ihrem Bürorechner sitzen und dann wieder von zu Hause per VPN auf einen Terminalserver gehen trifft uns das richtig hart. Übrigens nicht nur bei Windows, auch bei Linux! Wir haben in beiden Bereichen um die 1000 Desktops mit je nach Standort / Lehrstuhl etc. unterschiedlichen Patchday-Zyklen (bzw. sehr seltenen Patches auf Experimentalsteuerungsrechner).


    Das ist für mich nicht nachvollziehbar. Probleme entstehen nicht durch Versionsnummern. Und Downgrades erfolgen unter normalen Umständen keine durch Firefox-Updates. Wenn jedoch ein einziges Firefox-Profil für unterschiedliche Firefox-Installationen verwendet wird, dann ist klar, dass es technisch gesehen Downgrades geben kann. Das ist dann aber ein komplett hausgemachtes Problem. So sollte unter gar keinen Umständen gearbeitet werden. Da braucht man auch nicht Coronoa und die aktuelle Situation ins Spiel bringen, denn das galt schon immer. Und wenn durch eine falsche Arbeitsweise Datenverluste entstehen - wovor der Downgrade-Schutz von Firefox ja schützt! -, dann ist das für die meisten Mitarbeiter vermutlich sehr ärgerlich.


    Wäre also schon hilfreich, wenn die Entwickler bei Mozilla da etwas Benutzerfreundlicher denken würden, wir haben erheblich mehr verlorene Profile und Bookmarks durch diese Verhaltensweise des Firefox, als wir jemals durch unverträglichkeiten im Profil hatten!


    Firefox verliert keine Profile, das ist schonmal sicher. Sollte es zu einem Downgrade-Szenario kommen (was wie gesagt auf eine fehlerhafte Arbeitsweise zurückzuführen ist), hat man bei Erstellung eines neuen Profils auf das alte Profil immer noch Zugriff. Umgekehrt wären Profildaten bei einem Datenverlust durch ein Downgrade unwiderruflich verloren (außer es gibt ein externes Datensicherungssystem). Die Frage, welche der beiden Optionen mehr im Sinne des Anwenders ist, stellt sich für mich in diesem Fall ehrlich gesagt überhaupt nicht.


    Für mich klingt das alles ehrlich gesagt danach, als würde ein Schuldiger für ein Deployment gesucht werden, welches einfach nicht optimal funktioniert.