Quel est le risque de mise à niveau sur SSH?
Quand je cours
Sudo do-release-upgrade
sur ssh, je reçois le message suivant.
Cette session semble fonctionner sous ssh. Il n'est pas recommandé D'effectuer une mise à niveau sur ssh actuellement, car en cas d'échec, il est plus difficile à récupérer. Si vous continuez, un démon ssh supplémentaire sera lancé au port '9004'. Voulez-vous continuer?
Quel est le risque réel de mise à niveau sur SSH? Comment le démon ssh supplémentaire aide-t-il à atténuer cela?
Ce que je recommanderais, c’est de lancer une session screen sur le serveur et d’exécuter la mise à niveau dans screen. Ainsi, si votre session SSH est interrompue (pour une raison quelconque), le processus de mise à niveau ne s’arrête pas.
Screen est un programme qui permet de créer un ou plusieurs terminaux persistants sur une machine. Ainsi, vous pouvez démarrer une session d'écran et tant que la machine est sur cette session d'écran (et son historique, les programmes en cours d'exécution, etc.) continueront à fonctionner bien qu'aucun utilisateur ne soit sur la machine. Il a été conçu dans les débuts pour fournir un terminal texte à plusieurs fenêtres avant les jours de X Server. Vous pouvez l'installer en utilisant APT:
Sudo apt-get install screen
Ainsi, vous pouvez faire ssh sur votre serveur, démarrer l'écran, lancer le processus de mise à niveau sans avoir à vous soucier de la mise à niveau parce que vous avez perdu la connexion Internet ou que votre ordinateur est en panne.
La solution de @ Marco-Ceppi est déjà intégrée à do-release-upgrade.
Lorsque vous exécutez do-release-upgrade, une session d’écran démarre automatiquement. Si votre session ssh est déconnectée, vous pouvez reprendre l'installation. Tout ce que vous avez à faire est d'ouvrir une nouvelle session ssh et de relancer do-release-upgrade. Il se reconnectera à votre installation précédente.
Un deuxième risque, souligné par @ sepp2k, est que votre serveur sshd doit peut-être être mis à niveau et qu'il peut ne pas redémarrer correctement. Par conséquent, le programme de mise à niveau exécute un deuxième démon, sur le port spécifié. Vous devez vérifier la configuration de votre réseau pour vous assurer que vous avez un accès via ce port avant de reprendre.
Bonne chance.
De plus, la session d'écran do-release-upgrade commence par elle-même et est exécutée sous le compte root. Si votre propre session d'écran se bloque, vous pourrez récupérer en exécutant Sudo screen -x si, pour une raison quelconque, la commande do-release-upgrade ne le récupère pas. par lui-même, ce qui semble être commun.
Si une nouvelle version du démon ssh est installée dans le cadre de la mise à niveau, le démon sera redémarré. Si la mise à jour interrompt le démon pour une raison quelconque, le redémarrage échouera et vous ne pourrez plus vous connecter à la machine.
En démarrant un sshd distinct, qui n'est pas géré par le système init et ne sera donc pas redémarré lors de la mise à niveau, il est garanti que l'ancienne version de sshd sera toujours en cours d'exécution même si la nouvelle version ne parvient pas à démarrer. Ainsi, vous pouvez toujours vous connecter au système et voir ce qui a provoqué le démon du démon.
Je n'ai jamais (encore) eu de problème à le faire, bien que je n'aie mis à jour qu'une demi-douzaine de boîtes de cette façon. En cas de problème, le démon SSH supplémentaire peut être votre seul espoir d'éviter une visite (ou d'utiliser les options de réinstallation distantes que vous avez).