Closed Bug 1255591 Opened 10 years ago Closed 10 years ago

AUS support for updating MacOS < 10.9 users to ESR post-45

Categories

(AUS Graveyard :: General, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: benjamin, Unassigned)

References

Details

Part of the larger intent to deprecate MacOS version <10.9, we want to move existing users on those OS versions to ESR45 builds so that they have security updates for the remainder of this year. I'm interested whether we can and should do this without changing their "actual" release channel. That is, they would still ping the "release" channel but would be served ESR updates. The advantage of this is that if they did upgrade their OS, they could switch back to receiving new releases. It also means we wouldn't have to ship a custom MAR to switch release channels. The disadvantage of this is that we might see these users reporting to the wrong release channel in various metrics channels: telemetry, ADI, and crash-stats. But actively switching channel might require building a custom MAR file that actually changes their channel-prefs.js file from "release" to "esr".
As far as Balrog goes, this is easy. Its rules system is configurable enoguh to make this possible. However, I don't think we can do this without custom MARs for each ESR release because MAR_CHANNEL_ID is different for ESR and Release (modulo bug 1255790, where we screwed it up for 45.0.0esr). Release uses "firefox-mozilla-release", but ESR MARs have a channel id of "firefox-mozilla-esr". Because we'd need custom MARs for each release, we'd need to build automation for this (it's way too much error prone work to do by hand every 6 weeks). Hard to say how much work that is - it won't be a small amount though, we'd need something to repack, resign, and rehost MARs, something to submit new data to Balrog, and probably other bits I haven't considered.
If we do this with a channel change, it *should* be relatively easy. We'd need a single custom MAR to switch the update channel and the ACCEPTED_MAR_CHANNEL_IDS, and then they'd look like normal ESR users from there.
ok, let's go with the MAR-switching option then. That will presumably involve an intermediate update to 45.0.1? And then on to the ESR?
(In reply to Benjamin Smedberg [:bsmedberg] from comment #3) > ok, let's go with the MAR-switching option then. That will presumably > involve an intermediate update to 45.0.1? And then on to the ESR? They'd need to go through the custom MAR, but I don't think that MAR needs to be an entire new version - just something that changes update-settings.ini and channel-prefs.js. This is how we've done channel switches in the past IIRC.
I'm probably not going to be the one implementing this, but it looks like the last time we did this was in https://bugzilla.mozilla.org/show_bug.cgi?id=947476. Unfortunately, there's very little information about how the channel switching MAR was constructed. Creating+signing the channel switching MAR is going to be the tricky part - unpacking the MAR from the above bug will probably aid in figuring out what this one should look like. Signing it will be just like signing any other MAR through the signing server. Once that's been published somewhere, a custom release will need to be created in Balrog that points points all locales+platforms to the same MAR, and we'll need a test rule that points at it.
Here is some more prior art, but neither is quite what we want here. Possibly still useful to bootstrap. In bug 657789 we wanted to move users of m-c l10n builds to aurora. The tools patch there contains a script create-channel-switch-mar.py, which takes a complete update from aurora, adds a channel-prefs.js file, munges the update manifest, and recreates the mar with appropriate channel-id and version. It doesn't deal with signing, presumably I did that at the command line. In bug 908134 we wanted to repack release updates so they could be applied by beta users (the RC case). Attachment 829539 [details] details the steps there, but it's repacking release mar files with modifications to update-settings.ini.
We're past the ESR frame, we're just going to EOL old mac versions.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.