La session SSH ne se ferme jamais lors de l'exécution de «apt-get install»

14

Problème

Lors de l'exécution apt-get installdans une session SSH non interactive, la session ne se ferme jamais. Exemple:

ssh user@target "sudo apt-get -y install my_package"

Le my_packagene s'installe pas correctement, mais la session SSH ne fait que s'ouvrir.

Question

Existe-t-il un drapeau pour passer SSH pour se rendre apt-getau travail?

Information additionnelle

Le contexte

L'installation à distance est utilisée pour le déploiement automatisé d'un package sur un serveur d'intégration. Dès que nous transmettons des modifications de code à un référentiel, un travail extrait le code, crée le package et le déploie lors de l'intégration pour vérifier que tout fonctionne bien (en ce qui concerne le déploiement).

Déjà essayé et notes

  • La même session SSH en cours d'exécution se apt-get updateferme proprement. Notez que ce apt-get updaten'est pas interactif, alors que l' apt-get installest. Cela peut suggérer que l'interactivité est un problème.
  • Une commande comme ssh user@target "sudo apt-get install my_package && echo Hello"n'atteint jamais le echo.
  • debconf se plaint qu'il ne peut pas trouver un bon frontend (Display, Readline), et il retombe sur Teletype (bien que Readline soit disponible).
  • En ce qui concerne le frontend de debconf, passer -tpour forcer TTY avec SSH n'aide pas. Ni l'un ni l'autre DEBIAN_FRONTEND=noninteractive.
  • Tout a été fait sur Ubuntu 12_04 LTS.
ubuntu ssh debian apt Eric Platon
la source
Si vous exécutez la commande d'installation manuellement (c'est-à-dire ssh user@targetensuite les commandes du shell) cela fonctionne-t-il correctement?
Anneau Ø
La commande d'installation fonctionne très bien lorsqu'elle est effectuée manuellement (ce qui conduit à penser qu'il y a un problème avec les types de session non connectés / interactifs).
Eric Platon

Réponses:

6

La réponse suivante sur SF a fait l'affaire:

ssh ne parvient pas à exécuter la commande à distance lors de l'exécution à partir du script cron bash

Le -tdrapeau force une allocation pseudo-tty, sauf peut-être lorsqu'il n'y a pas de téléscripteur localement. Mais passer le drapeau deux fois comme en -t -tfait semblant de le faire. Et cela a résolu le problème.

Voir la documentation SSH:

-t Force l'allocation de pseudo-tty. Ceci peut être utilisé pour exécuter des programmes arbitraires sur écran sur une machine distante, ce qui peut être très utile, par exemple lors de la mise en œuvre de services de menu. Plusieurs options -t forcent l'allocation de tty, même si ssh n'a pas de tty local.

Maintenant, pourquoi cela a-t-il fonctionné? Il s'avère que cela debconfne se plaint plus de l'interface dans les journaux. Je crois donc que les doubles -tsets (leurres?) Au debconfbesoin, ce qui permet apt-get installde terminer la session SSH proprement.

Eric Platon
la source
Je pense que c'est une bonne réponse, mais je ne la marquerai pas immédiatement telle quelle. D'abord parce que j'ai répondu moi-même, et ensuite, il pourrait y avoir de meilleures réponses / plus génériques. Revenons à ce sujet à l'avenir.
Eric Platon
1

En le parcourant, cela pourrait faire l'affaire. L'appel de n'importe quelle commande doit être suivi de exit et heredoc. J'ai trouvé la solution, mais je ne l'ai pas essayée personnellement.

ssh user@myremotemachine <<-EOF
free -m
exit
EOF

La réponse originale vient d'ici: http://www.thetechrepo.com/main-articles/529-execute-a-command-remotely-over-ssh-and-then-close-the-connection

koressak
la source
Merci, koressak. Je suppose que cela dépend du shell et de la distribution du système d'exploitation. Je viens d'essayer ssh user@host free -mdans mon environnement cible, et cela fonctionne comme un charme. Je vais essayer la recommandation ensuite.
Eric Platon
Je viens d'essayer un run complet avec l'approche heredoc. Cela n'a pas résolu le problème. La session SSH se bloque de la même manière que celle présentée dans la question. Merci encore pour la réponse et le pointeur!
Eric Platon
1

Sous debian / jessie, j'ai réussi avec cette commande:

ssh user@host "TERM=READLINE sudo apt-get install --reinstall less && echo done"

Mais vous devriez peut-être envisager d'utiliser ansible pour cela et d'autres tâches à venir http://docs.ansible.com/ansible/apt_module.html

ThorstenS
la source
Intéressant, bonne idée. Quant à Ansible, peut-être maintenant. Je ne sais pas quand la question m'est venue à l'esprit. Quoi qu'il en soit, je pense qu'il est bon de savoir "ce qui se passe à l'intérieur" (c).
Eric Platon