Beiträge von tobias.x

Hi,

wir haben hier sehr viele eher weniger leistungsstarke PCs, weil diese schwerpunktmäßig nur als Terminal-Server Client dienen.

Trotzdem aber wird manches auch lokal am PC gemacht, so auch der Besuch bestimmter freigegebener Webseiten, weshalb wir also einen aktuellen sicheren Browser benötigen.

Nach dem Update der 78-er ESR Version auf die 91-er ESR Version erscheint mir der Start von Firefox auf unseren Rechnern ungefähr 3-5 mal so viel Zeit zu benötigen wie bisher (Trotz SSD und überall mind. 8 GB RAM).

Meine Hoffnung / Frage:

Kann ich irgendetwas in about:config deaktivieren, das vielleicht im FF91 hinzugekommen ist?

Sandkasten?

Viele Links im Voraus öffnen

oder andere Sachen?

Vielen Dank,...

Problem gelöst:

Nachdem ich eine neue json Datei erstellt habe, funktioniert die Update-Sperre wieder auf den Rechnern.

Sorry, das hätte ich natürlich auch vorher testen können.

Gibt es hier auch Buttons für "Problem gelöst"? - ich sehe gerade nichts Derartiges..

Jetzt habe ich es doch entdeckt

Hi,

ich wollte gerade hier in der Firma die Updates für FF ESR einspielen und dachte, ich mache dann gleich jetzt den Sprung auf die ganz neue Version.

Aber auf meinen Testrechnern funktionierte anschließend nicht mehr die automatische Update-Sperre, die per Enterprise Policy Generator erstellt wurde und nach dem Update automatisch per Skript wieder in den passenden Ordner kopiert wird.

Kann ich unter FF91 ESR die automatischen Updates nicht mehr deaktivieren? Das wäre sehr schlecht... da die Benutzer keine Adminrechte haben und auch nicht haben sollen und auch kein privilegierter Update-Dienst im Hintergrund laufen soll...

Vielleicht hat sich auch nur irgendein Pfad geändert?

Vielen Dank schon einmal...

Hmm... und wie führe ich nun eine skriptgesteuerte Updateinstallation durch?

Naja, wie im geposteten Skript zu sehen ist, habe ich den Firefox nicht erst deinstalliert, sondern wie seit Jahrzehnten einfach "drüberinstalliert". Ich dachte eigentlich auch immer, dass dies die normale und empfohlene Methode ist, um den FF auf den aktuellen Stand zu bringen?

Das MSI Paket nutze ich nicht, das es beispielsweise eine Deinstallation (-x) des Programms nicht unterstützt. Ich sehe hier von daher das ernsthafte Problem, dass ich ein MSI-Paket nicht mehr ordentlich deinstallieren kann. Und auch andere Vorteile von msi-Paketen, nämlich eine Reparaturinstallation (-f) oder eine Updateinstallation (-p) werden von Mozilla nicht unterstützt. Somit halte ich die Installation per .exe doch für vielseitiger nutzbar.

Gut, dann werde ich einfach den Befehl, der am Ende den Distribution Ordner wieder zurück kopiert, in meinem Skript belassen. Das erscheint mir doch die sinnvollste Variante.

Danke für die Antwort.

P.S.: Warum ist es denn ein erwünschtes Verhalten, wenn beim Drüberinstallieren der distribution Ordner mit den Admin-Einstellungen entfernt wird? Das verstehe ich irgendwie nicht so richtig.

Nun gibt es von Sören ja den praktischen Enterprise Policy Generator, der auch gut funktioniert.

Nur: Auf allen von mir betreuten PCs wird der distribution Ordner einfach gelöscht, nachdem ich vom Firefox 68.0.2 auf 68.1 upgedatet habe.

Kommandozeile:

ff.exe -ms /INI=t:\mozsetup.ini

Inhalt der mozsetup.ini:

[Install]

;

; Remove the semicolon (;) to un-comment a line.

;

MaintenanceService=false

Ich habe mir jetzt damit beholfen, dass ich am Ende des Update-Skriptes den distribution Ordner einfach wieder per Skript in das Mozilla Programmverzeichnis kopiere.

Aber etwas wenig elegant ist das ja schon...

Warum entfernt das Update den Ordner? Gibt es ein Gegenmittel?

Danke..

Für Downloadaufgaben, die etwas komplexer sind, habe ich mir parallel zu Firefox noch den Waterfox mitsamt DTA Addon auf dem Rechner installiert. Sicherheit hin- oder her: Manchmal ist mir meine Zeit doch auch wichtig.

Ich habe nun eine Lösung gefunden:

Folgende Zeile in meinem Skript deinstallierte die 32-Bit Version vom Firefox tadellos ohne Rückfragen vollautomatisch:

"c:\program files (x86)\mozilla firefox\uninstall\helper.exe" -ms

Da kann sogar DeJaVu noch etwas lernen

P.S.: Die 64-Bit Versionen habe ich nun doch nicht per MSI installiert, denn das bringt mir nicht so viel. Insbesondere ist noch nicht einmal eine Deinstallation per msiexec möglich..

Zitat von https://support.mozilla.org/de/kb/firefox-uber-msi-installationspakete-bereitstellen

Nicht unterstützte MSIEXEC-Optionen

/f
Repariert das Produkt.

/a
Administrative Installation.

/x oder /uninstall
Deinstalliert das Produkt.

/j zusammen mit /t, /g, und /c
Bewirbt das Produkt.

/n
Gibt eine bestimmte Instanz des Produkts an.

/p oder /update
Wendet eine Patchdatei an (.msp)

Alles anzeigen

Also, ich gebe mit dieser Frage jetzt hier im Forum auf.

Ich weiß noch nicht einmal, was SuMo oder WiMo ist, und auf kb.mozillazine.org habe ich mich noch nie wirklich zurechtgefunden.

Ich hatte mir erhofft, dass dieses Forum eine Plattform ist, in der man unkompliziert um Hilfe fragen kann und umgekehrt, wenn man etwas weiß, anderen hilft.

Das scheint ja zumindest bei der Frage, wie man als einfacher Nicht-Entwickler FF automatisch per Skript deinstallieren kann, leider nicht geklappt zu haben.

Schade, aber auch kein Weltuntergang

Ich frage mich nur, was dann der Sinn des Forums ist: Nur Fragen, die nirgendwo anders im Internet bereits beantwortet wurden, dürfen gestellt werden?

Ich weiß jetzt nicht, warum Du so bissig antwortest.

Aber im ersten Link von Dir sehe ich lediglich, wie ich Firefox manuell über die Systemsteuerung entferne und wo sich die Profile befinden.

Im zweiten Link sehe ich lediglich die Optionen für die mozilla.ini, die mir, wie Du ja weißt, auch bekannt sind. Hier sehe ich ebenfalls keine Option für eine automatisierte Deinstallation.

Dein Hinweis mit den MSI-Dateien für Firefox ESR finde ich für die Zukunft interessant, deshalb danke dafür. Dies war mir bisher unbekannt. Aber für die Deinstallation der per .exe installierten Firefoxe nützt mir das ja leider auch nichts.

Ebenso danke für den Hinweis auf die uninstaller.exe. Mal schauen, wo ich sie finde und ob das dann auch per einfachem Aufruf ohne Eingaben möglich ist. Das wäre dann genau das, was ich suche.

Edit: Ich finde im Unterordner /uninstall eine helper.exe. Bisher habe ich noch nicht herausgefunden, wie ich sie ohne Rückfragen zu ihrem Job veranlassen kann. Ein helper.exe /? brachte leider nichts an Kommandozeilenschaltern, ebensowenig ein -? oder ein -help. Auch Google führte mich nicht weiter.

Wenn also hier jemand noch einen Tipp hätte, wie ich mit der /uninstall/helper.exe per Batch Firefox deinstallieren kann?

Vielen Dank.

Zitat

Mein Tipp: Niemals blind irgendwelche Einstellungen vornehmen. Immer erst informieren, was genau jeder einzelne Schalter macht,

Nun, ich stand vor dem Problem, dass nach einem Firefox Update etliche FF Installationen extrem zäh reagierten. Insbesondere der Programmstart dauerte ewig - im Vergleich zur Vorgängerversion.

Was macht man dann mitten in der Nacht, wenn die Leute am nächsten Tag wieder arbeiten wollen? Eben, Tante Google. Da probiert man dann allerhand Tipps, die irgendwo stehen aus, die meisten nützen nichts, und plötzlich hat man einen, da funktioniert wieder alles bestens. Und so war das hier wohl auch gewesen. Vermutlich war die angegebene Lösung nicht nur die eine browser.tabs.... Zeile, sondern gleich das ganze Paket...

Dass ich in Zunkunft lieber erst einmal hier fragen werde, wo so viel geballtes Fachwissen vereint ist, versteht sich von selbst :-))

Aber damals kannte ich dieses Forum nicht, oder vielleicht gab es das auch noch gar nicht...

Zitat

Eine user.js sollte immer dokumentiert werden, dann sucht man nicht so lange...

Na, es geht auch nicht ums Suchen - so groß ist die user.js nun wirklich nicht.

Sondern darum, nicht an 60 prefs.js Dateien händisch herumeditieren zu müssen... Es wäre dann schon hilfreich, wenn beim Laden der user.js der ehemals dadurch in der prefs.js hinzugefügt Eintrag automatisch wieder entfernt werden könnte. Ganz ohne manuelles Zutun...

Gibt es eine Möglichkeit, dass ich Firefox ESR per Skript deinstallieren kann?

Hintergrund:

Bei den Updates im nächsten oder übernächsten Monat möchte ich Firefox ESR gleichzeitig auf die 64 Bit Version umstellen.

Zum Updaten / Installieren benutze ich bisher in meinem Installationsskript einen Eintrag wie diesen:

: Firefox updaten

ff.exe -ms /INI=t:\mozsetup.ini

(ff.exe ist der Dateinameame der jeweils zu installierenden Version, die ich vor dem Verschieben in ff.exe umbenenne, damit ich im Skript keine Dateinamen ändern muss.)

In der mozsetup.ini steht dann zum Beispiel:

[Install]

;

; Remove the semicolon (;) to un-comment a line.

;; The MozillaMaintenance service is used for silent updates and may be used

; for other maintenance related tasks. It is an optional component.

; This option can be used in Firefox 16 or later to skip installing the service.

MaintenanceService=false

Beim Installieren der 64 Bit Version über eine 32 Bit Version habe ich hinterher aber beide Versionen auf dem PC, deshalb suche ich nun nach einem Weg, die 32 Bit Version möglichst einfach loszuwerden, ohne sie an jedem PC über die Systemsteuerung händisch deinstallieren zu müssen. Bei MSI-Paketen wäre das ja einfach. Hier bin ich aber darauf angewiesen, dass dies irgendwie durch Mozilla möglich ist.

Ist es das?

Vielleicht ein Eintrag in der ini-Datei?

Ein Schalter wie /u für uninstall, mit dem ich die 32 Bit Exe aufrufe?

Danke...

> "Welchen Grund glaubst du dafür zu haben, Updates deaktivieren zu müssen? In schätzungsweise 99,99999 Prozent gibt es keinen Grund und es wird nur versucht, vor einem tatsächlichen Problem davonzurennen statt es zu lösen. Vermutlich lässt sich auch dein Problem lösen. Damit würde ich mich befassen…"

Ich bin nun zwar nicht der Ursprungs-Poster, an den die Frage ging. Und eigentlich wollte ich mich jetzt auch mit dem Thema zurückhalten.

Aber drei Anmerkungen möchte ich nun doch noch loswerden, wobei mir die letzte die wichtigste ist:

a) Gerade bei einer ESR-Version, für die nun auch noch Admin-Tools entwickelt werden, sollte es doch nicht schwer sein zu erkennen, warum hier ein Bedarf nach einem gesteuerten Update durch den Admin bestehen könnte.

b) Auch die Möglichkeit, dass man während des Setups von FF den Update-Hintergrunddienst abwählen kann, passt nicht zu der neuen Zwangs-Update-Einstellung. Da bekommen dann die Benutzer ständig Updatehinweise, und wenn sie dann updaten wollen, geht das nicht. Irgendwie ist das Ganze in sich nicht konsistent geplant (Installer mit Abwahlmöglichkeit vs. Zwangs-Updates).

c) Warum eigentlich neigen Softwarehersteller so oft dazu, den Benutzern das aufzwingen zu wollen, was sie selbst für sinnvoll halten?

Die sinnvollen Sachen voreinstellen - gerne. Aber warum muss man die Benutzer, die das nicht möchten, egal aus welchen Gründen auch immer, derart bevormunden? Warum sich nicht einfach zurücklehnen und den Benutzer die Freiheit lassen, sich (aus fremder Sicht) auch unvernünftig zu verhalten?

OK, schade dass es die Löschmöglichkeit per user.js nicht gibt.

Ein Herumwurschteln in allen Benutzerprofilen ist einfach schon zeitlich gar nicht praktikabel.

Dann werde ich die prefs.js doch einfach per Skript löschen. Passworte, Lesezeichen usw. bleiben ja erhalten - und mit den restlichen fehlenden Einstellungen muss man dann halt leben, so furchtbar viel wird man wahrscheinlich gar nicht merken. Ansonsten packe ich noch ein paar der fehlenden Einstellungen in die user.js..

Was mich ja noch einmal interessieren würde:
Wenn der verantwortliche Eintrag für die nicht funktionierenden Dropdownboxen etwas mit der Aufteilung auf Threads zu tun hat (habe ich das richtig verstanden?), wie kommt dadurch ein Fehler in fehlenden Dropdown-Elementen zustande? Das hat doch eigentlich überhaupt nichts miteinander zu tun (?). Oder wird da innerhalb eines einzigen HTML-Dokumentes die Darstellung der verschiedenen Elemente auf mehrere Kerne aufgeteilt - und der Kern, der den Inhalt der Dropdown-Box darstellen soll, ist dann nicht verfügbar? Das kann ich mir so ja eigentlich nicht wirklich vorstellen...

Also auf Deine Frage nach dem warum:

Ich kann mich ehrlich gar nicht mehr erinnern, aber wenn Du etwas von Multiprozess schreibst, dann kommt eine schwache Erinnerung hoch, dass Firefox nach irgendeinem Update an vielen PCs praktisch unbenutzbar geworden war. Dann ich suchte ich halt im Internet - und offenbar waren es diese tab.remote. Einträge, die sofortige Abhilfe brachten. Klar, man sollte das gelegentlich mal checken... aber solange alles gut läuft... die np-Plugin Einträge habe ich jetzt auch mal rausgenommen, ich denke, dass diese Art von Plugins ja sowieso nicht mehr funktioniert und zumindest Quicktime und Mediaplayer Addons, die einem nervigerweise immer untergejubelt wurden, wind ja nun auch glücklicherweise Schnee von gestern .-). Wenn ich mir die prefs.js anschaue, das ist noch viel lustiger.. all die Einträge, die sich dort seit teilweise über 10 Jahren angesammelt haben .. Vielleicht werde ich beim Umstieg auf 64 Bit mal einen Schnitt mit der prefs.js machen bzw. mit den gesamten Benutzerprofilen..

BTW: Ich habe nun die browser.tabs.remote-Einträge für die ersten Benutzer manuell aus der prefs.js entfernt, was aber doch etwas mühselig ist. Ich will aber nicht zuviele individuelle Einstellungen, die es möglicherweise gibt, löschen, und deswegen auch die prefs.js nicht einfach löschen.

Gibt es eigentlich auch eine Methode, (eine Art Befehl), wie ich über die user.js einen Eintrag in der prefs.js vom Firefox löschen lassen kann? Ähnlich wie beim Registry-Editor für Windows mit den .reg Dateien?

Ich habe nun die Ursache des Problems gefunden:

Nachdem nach Löschen der prefs.js das Problem scheinbar gelöst war, trat es nach dem nächsten Login gleich wieder auf.

Somit war nun klar, dass die Ursache in der user.js liegen muss, die bei jedem Windows-Login in das FF-Profil des Benutzers kopiert wird.

Nach einiger weiterer Suche habe ich nun die Einstellung, welche das Aufklappen der Dropboxen verhindert, in der user.js (und somit später dann auch in der prefs.js) gefunden:

Sobald ich folgende Zeile auskommentiere (und anschließend die prefs.js lösche), funktionieren die Dropdownboxen wieder:

user_pref("browser.tabs.remote.desktopbehavior", false);

Das Problem ist nun also glücklicherweise gelöst..

Lösung des Dropdownlisten Problems:

Ich hatte mir nun vorgenommen, an einem PC nach und nach Ordner und Dateien eines Benutzerprofils durch Umbenennen zu deaktivieren und anschließend wieder zu aktivieren und mit dem nächsten Element fortzufahren.

Gleich mein erster Versuch war ein Volltreffer:

Die prefs.js

Sobald ich diese lösche und der FF sie aus der user.js usw. neu erstellt hat, klappen die Dropdown-Menüs wieder auf.

Notfalls werde ich also nur diese Datei löschen.

Trotzdem war ich natürlich neugierig, welche Einträge innerhalb dieser Datei nun die Ursache sind.

Zunächst fiel auf, dass in der Datei praktisch sämtliche Drucker und Addons, die jemals in dem Firefox auf dem PC installiert waren, ihre Spuren hinterlassen haben, und zwar nicht zu knapp.... So ist die historisch gewachsene prefs.js 60 kByte groß, während die vom FF neu erstellte nur 8 kByte groß ist..

Vermutlich ist die Ursache also irgendein Eintrag, den irgendeines der Addons, die ich so gut fand, dass ich sie irgendwann einmal praktisch überall installiert hatte, dort hinterlassen hatte - obwohl es gar nicht mehr installiert ist..

Den "Schuldigen" habe ich aber leider immer noch nicht gefunden, obwohl ich mir einbilde, die Einträge aller Addons, die ich gerne mal benutzt hatte, gelöscht zu haben.

Überhaupt habe ich bei dieser Aktion Lust bekommen, mal die kompletten Profile zu entrümpeln. Was hier an ur-ur-uralten Dateien herumliegt, ist nicht mehr feierlich...

Zitat

Zitat

weil einfach ein Cache auf einem Netzlaufwerk in meinen Augen nicht sehr produktiv sein kann.

Aber das Profil schon, oder?

Naja, wenn da nur ein paar Initialisierungen und Addons ausgelesen werden, klar. Natürlich ist das Profil vom Firefox immer schreibintensiver geworden im Laufe der Zeit mit all den Listen und Datenbanken, die dort mittlerweile liegen. Trotzdem ist ein Cache nach meinem Verständnis wesentlich besser auf einem lokalen Laufwerk aufgehoben.

Und das Profil auf dem Server ist halt für die Funktionsweise zwingend notwendig.

Oder ich müsste es bei jedem Einloggen auf den Client-PC kopieren und nach dem Ausloggen wieder zurück.

Aber das war bisher nicht nötig.

Zitat

Zitat

Mittlerweile gibt es im Firefox noch weitere Caches

Kein Cache im eigentlichen Sinne. Was meinst du konkret?

Na zum Beispiel:

die Ordner "startup-Cache", "jump-ListCache"... die tragen das Wort ja sogar im Namen..

Zitat

Was spricht eigentlich dagegen, Firefox im Ganzen auf dem Server zu lassen und per Remote-Session nutzbar zu machen? Warum hat MS den zuletzt das gesamte Hyper-V Geraffel aufpoliert ?

Dagegen spricht, dass kein Terminalserver zur Verfügung steht... Ebensowenig die Lizenzen. Und auch, dass es Overkill wäre, jedenfalls in meinen Augen. Zumal der Firefox nicht gerade das Haupt-Arbeitsmittel an den Arbeitsplätzen ist, sondern eher selten genutzt wird.

Zitat von .DeJaVu

Ich hab zwar keinen Server zur Hand, aber das Profil liegt unter %appdata% und der Cache unter %localappdata%.

Wenn du schon den Cache umlegst, dann wäre doch %temp% bzw %localappdata%\Temp\ sinnvoller, oder nicht?

Das wäre eine Überlegung wert ... aber kann Firefox das denn überhaupt umsetzen, wenn ich dort in der entsprechenden user.js ein %localappdata% als Pfad eintrage?

Wobei %temp% ohnehin wieder in C:\temp landen würde, denn das habe ich auf den Windows-Clients so eingestellt, um es bei Logins regelmäßig "putzen" zu können