Quand je cours
sudo do-release-upgrade
sur ssh, je reçois le message suivant.
Cette session semble fonctionner sous ssh. Ce n'est pas recommandé pour 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é sur le 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?
Réponses:
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 aux 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 premiers jours pour fournir un terminal de texte multi-fenêtré 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 tombé en panne.
do-release-upgrade(depuis précis) s'exécute automatiquement screen.
screen -dmS do-release-upgrade-> screen -rpour passer à l'écran en cours d'exécution -> Ctrl + A, Ctrl + D pour laisser l'écran fonctionner en arrière-plan et revenir à l'écran principal
@ La solution de Marco-Ceppi est déjà intégrée à do-release-upgrade.
Lorsque vous l'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 l'exécuter à do-release-upgradenouveau. 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-upgradedémarrant d'elle-même est exécutée sous le compte root. Par conséquent, si votre propre session d'écran se bloque, vous pourrez le récupérer en exécutant sudo screen -x, si (pour une raison quelconque) la commande do-release-upgradene le récupère pas par lui-même. ce qui semble être commun.
sudo do-release-upgrade) et répondu "Oui", je peux me connecter à ssh sur le port 9004 mais aucune screensession n'est répertoriée lors de la tentative sudo screen -list . (PS je n'ai pas encore passé le téléchargement.)
do-release-upgradeaucune session écran n’a été démarrée), je passe maintenant de la version 10.04 LTS à la version 12.04 LTS et do-release-upgradelance maintenant une session écran automatiquement.
do-release-upgradeprenez soin de tout ce qui vous attend, puis: 1) vous pouvez vous reconnecter à partir d’un fichier SSH endommagé en le relançant do-release-upgradeaprès la réenregistrement et 2) vous pouvez vous reconnecter à partir d’une mise à niveau de sshd ayant échoué via le port spécifié au début par do-release-upgrade. Est-ce que c'est ça ?
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).