Open Bug 1553604 Opened 3 months ago Updated 2 months ago

New Profile System Problematic On Linux Servers

Categories

(Toolkit :: Startup and Profile System, defect, P3)

67 Branch
Unspecified
Linux
defect

Tracking

()

UNCONFIRMED
Tracking Status
firefox-esr60 --- unaffected
firefox67 --- wontfix
firefox68 --- affected
firefox69 --- affected

People

(Reporter: drichard, Unassigned)

References

(Blocks 1 open bug, Regression)

Details

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:66.0) Gecko/20100101 Firefox/66.0

Steps to reproduce:

We are running a massive multi-user Linux deployment with Firefox. When a new version of Firefox is released, we install the tarballs into a few folder and then move users to the new binary. If there is a problem we can immediately rollback, and we keep old versions for this very reason. We upgraded to Firefox 67 just minutes ago, and many users started to pick up the new binary.

Actual results:

In some way, it perceived we wanted to run multiple versions of Firefox and built them brand new profiles and all of their passwords and profiles were "lost" from their view and of course we received support calls. I immediately did a rollback to FF 66 and it located their previous profiles.

Expected results:

In our case, this new feature is not desired and we are seeking a way to not have Firefox attempt to create new profiles for each detected version. I don't see an about:config way to do this.

I am not sure what mechanism is used to figure out if you have multiple versions of Firefox installed, but this seems faulty when installing this package via tarball to a new folder. Ideally, we'd like a way to just tell Firefox to work the old way and make no attempt to support multiple FF versions. We won't ever use it.

We have no way to have 900 users use the Firefox sync account, the data must be stored here and end users would never be able use this feature.

A bit more information, each FF version is installed in a new folder in /u and then a soft link is pointed to the "live" version. The old versions are needed in case we discover a vendor issue or bug in a web page which requires us to check previous versions. This happens quite often, sometimes months after a new release is out.

Component: Untriaged → Startup and Profile System
Flags: needinfo?(dtownsend)
OS: Unspecified → Linux
Product: Firefox → Toolkit
Regressed by: 1474285

I made my way through some more of the documentation, and found that FF is now using the runtime folder as the way to detect if you are using multiple versions of the software, as noted in this report that won't work in some enterprise solutions. We're running multi-user Linux with hundreds of people.

  1. We keep previous versions of Firefox on disk for rollbacks and debugging. Very often users will find bugs in web based software and the vendor will say it's the FF upgrade. This is our way to test to see if that is really the case. We can move back and forward through previous versions and do testing to resolve these types of issues.

  2. If FF is introducing new features that might be impactful, we sometimes run the new version for a period of time for a few beta testers. The two versions co-exist but the users will continue to use their one profile.

  3. Sometimes we have crappy web based solutions that need an older version of Firefox, and we keep some users on an older version of FF until the vendor can make a repair to their software.

So either a command line flag or about:config type setting would be fine for deployments such as this, and allow the System Administrator to be able to optimize as needed. We want it to work like it did previously, we will not be using multiple profiles by version.

In case anyone has a similar multi-user server running, and is using Firefox from different folders. I have developed a work around.

The file "compatibility.ini" in each users profile folder contains the location of the last used Firefox binary. Before Firefox is launched, I overwrite this file with the desired settings and Firefox then does not generate a new profile with each upgrade.

Similar to this:

cp /u2/local/lib/compatibility.ini $HOME/.mozilla/firefox/$profile_path/

Flags: needinfo?(dtownsend)

The priority flag is not set for this bug.
:mossop, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(dtownsend)

For the time being this is

Flags: needinfo?(dtownsend)
Priority: -- → P3
Blocks: 1557125
You need to log in before you can comment on or make changes to this bug.