Ubuntu Wiki

• Launchpad Entry: foundations-lucid-stop-the-line-for-update-manager/

• Created: MichaelVogt

• Contributors:

• Packages affected: update-manager, apt

Summary

In some rare situations a bad update is pushed that then needs to be blocked from users. We should provide some explaination when this happens. Currently it will just display a 403 error without further details. So its unclear to the user if its a intentional blocked update or a problem on the server.

Release Note

TBD

Rationale

The current approach of chmod 000 results in 403 errors. This is confusing for our users as no further information is conveyed.

User stories

Jill is a ubuntu user and wonders why the machine suddenly returns 403 errors on upgrade (she does not know what this means). Instead a proper explanation should be given.

Design

We need to cover two cases:

• individual package problems (e.g. bad xorg)
• development archive in the middle of a transition (e.g. boot reorg work)

To cover the individual package problems we continue with the "chmod 000" approach. But we also add a $name.busted (or broken?) file so that apt can check for this and offer a different error message in this case that explains that its a temporary problem.

For the archive-in-bad-shape state we add a new key "Broken" key to the meta-release file that update-manager will read. If it encounters it it will abort the upgrade with a explaination. If update-manager auto-opens and the archive is in broken state it should just exit silently.

Implementation

See work items in the blueprint.

Test/Demo Plan

We need to add a meta-release test file on a different location that contains a "Broken: yes" key to test the update manager integration. We also need a test archive that contains some deb packages with chmod 000 and .busted files so that apt can be tested and integration with the higher level tools (software-center, synaptic).

BoF agenda and discussion

Bad updates in Ubuntu

• Bad Xorg updates
• update that made shells not run
• bad mailman security advisory
• OpenSSL security problems
• aptoncd
• pygtk problem that prevented Update Manager from launching

Issue for this session

The main issue for this session is when the repository is inconsistent

• usually this happens early in the development cycle
• or around transitions (like boot re-ordering)

Maybe have a meta-file on changelogs.ubuntu.com supported flag or new key in meta-release "busted"

You get an HTTP 403 error message and you're not sure why

• maybe we could use a different HTTP code
• maybe use a .busted version of the file [elmo] - would allow a more useful error message

What happens if we catch the error after it's been mirrored? [james_w]

• Any solution that works only for users of the main server is not a good solution

Show the error only if people are actively trying to do something that would harm them

If Update Manager would open automatically but it knows the updates it would install won't work, then ... it shouldn't open automatically, but instead exit silently if the archive is not doing well (because it does not know before it was not started)

If someone launches it manually ... just say "Updates aren't available at the moment. Try again later."

Problem space

• package specific issues (chmod 000)
• distro specific issues (boot update flux)

Solutions

• on the server, chmod 000 and create .busted file
• apt: on 403 do a lookup on $filename.busted file and show the error message from it (or better) show a generic error message "There is a problem with the archive. Its under investigation"
• add meta-release key "Broken: " that u-m looks at when it does its meta release check
• change update-manager to look for this key in that file
• procedure to ensure that someone is actively trying to fix the problem whenever the archive contains a .busted file

CategorySpec