ServerUpgradeTool
Please check the status of this specification in Launchpad before editing it. If it is Approved, contact the Assignee or another knowledgeable person before making changes.
Launchpad entry: https://features.launchpad.net/distros/ubuntu/+spec/server-upgrade-tool
Packages affected:
Summary
We provide a nice and consistant way to upgrade a desktop system with the ReleaseUpgrader. This tool ensures a clean upgrade. It is currently limited to the desktop and requires a runing X. We want to provide a text based frontend too.
Rationale
Sometimes we need to make changes to the system that goes beyond just upgrading packages or we need to work around problems. We want to have a consistent framework for this and just provide different frontends. One of these frontends should be a text based verison for server upgrades.
Use cases
Scope
We need to add a text based frontend for the ReleaseUpgrader. There needs to be commandline options to overwrite the frontend and the default configuration. For the server upgrade the rules are a bit different than for a desktop upgrade because e.g. we do not want to enforce certain packages (like we do with {ubuntu,kubuntu,edubuntu,xubuntu}-desktop on the desktop).
Design
The current ReleaseUpgrader will be used and a new frontend will be added. The configuration for the server upgrades needs to be slightly different than for desktop upgrades because we won't automatically install packages like "ubuntu-minimal" or "ubuntu-standard" if those are missing and it won't comment out 3rd party packages (because we trust the admin to makes this kind of decisions carefully). We will take care of task changes though. Do do this we check for the tasks on the system if if they are complettely installed. If so, we check if they have changed in the new release and add any missing packages.
In order to protect against network failure we need to make sure that a upgrade will continue even if the frontend goes away. We will use the same approach that is used in the new ReleaseUpgrader and run frontend and backend in different process spaces. This way, even if the network goes away the admin can reconnect to the machine and re-attach to the runing upgrade process.
In order to better protect against network failures we may ask at the start of the upgrade to start a ssh process on a different port so that if something goes very wrong, there is still a ssh server to connect to.
We may also check for new messages in /var/lib/update-notifier/user.d/ after the upgrade and show them to the user (maybe).
It should be possible to record/replay all decisions (including conffile questions?) made during the upgrade to replay them on the next upgrade to make it easier to do mass upgrades.
Implementation
The implementation will be done as a new interface to the ReleaseUpgrade that is part of the update-manager package.
Code
No code has been written yet.