Please find attached my proposal for the release notes to cover bug #990069.
Disclaimer: I (or somebody else) still have (has) to verify that the procedure works as intended. One can clearly start a very limited
upgrade with only openssh-server, but what needs checking is that:
a) ssh login works after the partial upgrade
b) with openssh-server upgraded, the downtime for accepting new
connections is greatly reduced.
+ <section id="ssh-not-available">^^^
+ <title>No new ssh connections possible during upgrade</title>
+ <para>
+ Due to unfortunate circumstances it's not possible to establish
+ new <command>ssh</command> connections for a bigger part of the
+ upgrade than during previous release upgrades. As usual,
+ existing connections should continue to work, but if the upgrade
+ is done over <command>ssh</command> and the
+ <command>ssh</command> connection is not trusted to last for the
+ full upgrade period, it's adviced to upgrade <systemitem^
+ role="package">openssh-server</systemitem> before upgrading the
+ full system.
+ </para>
+ </section>
Thinking about the overall structure, it might work better to move the
"good news" part to the start...
<section id="ssh-not-available">
<title>No new SSH connections possible during upgrade</title>
<para>
Although existing Secure Shell (SSH) connections should continue to
work through the upgrade as usual, due to unfortunate circumstances
the period when new SSH connections cannot be established is longer
than usual. If the upgrade is being carried out over an SSH
connection which might be interrupted, it's recommended to upgrade
<systemitem role="package">openssh-server</systemitem> before
upgrading the full system.
</para>
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 381 |
Nodes: | 16 (2 / 14) |
Uptime: | 53:51:02 |
Calls: | 8,146 |
Calls today: | 2 |
Files: | 13,098 |
Messages: | 5,858,914 |