Journal Le TCP keepalive m'a tué

Posté par benoar le 10 mai 2012 à 14:30. Licence CC By‑SA.

Étiquettes :

-8

mai

2012

Bonjour nal,

Je t'écris aujourd'hui un peu énervé, car cette putain d'option de ssh m'a encore bien eu aujourd'hui : je veux parler du « TCPKeepAlive ».

Pour beaucoup de gens, c'est l'option « magique » qui permet de soit-disant garder une connexion active. C'est même activé par défaut dans ssh. Alors qu'en fait pas du tout, ça fait tout pour faire tomber une connexion.

En effet, cette option est faite pour palier les réseaux déficients : DHCP moisis avec des baux courts, NAT ou firewall statefull avec une mémoire anémique, réseau qui part en cacahuète en moins de deux… Bref, soit ça permet de « garder » sa connexion active quand le firewall va l'oublier au bout de 5 minutes sans trafic, soit ça la coupe tout de suite histoire d'éviter d'attendre un timeout qui n'arrive pas très vite parce que DROPer le trafic c'est vachement plus hype que de le REJECTer.

Bref, j'ai la chance (au boulot) d'être dans un réseau pas tout moisi, ou en plus tous les subnets sont aussi adressables en IPv6, donc on n'a pas les galère des adresses privées accessibles de certains endroits seulement, et cette option m'emmerde plus qu'autre chose : je ne peux pas garder des sessions ssh en « sommeil » quand je vais bouger de réseau mais revenir plus tard dans celui de départ, ni mettre ma machine en veille et espérer que la session tienne encore après. Chez moi, dans un réseau bien configuré, les sessions ssh tiennent des jours, sans keepalive.

Tout ça, c'est le résultat du bien connu problème de celui qui s'adaptera le plus à l'autre : ssh a décidé de s'adapter aux réseaux moisis ; conséquence, les réseaux moisis perdurent. On aurait pu choisir de ne pas activer cette option par défaut, et de dire aux admins réseau d'arrêter leurs conneries, mais je suppose que les beuglements des utilisateurs ont eu raison des nerfs des devs d'OpenSSH.

Voilà, au final je pourrai m'amuser à changer la conf de tous les serveurs auxquels je me connecte, mais bien sûr je n'ai pas la main sur tous. Et le man précise bien, à propos de cette option :

However, this means that connections will die if the route is down temporarily, and some people find it annoying.

Mais j'avais envie de dénoncer grave.

# man ssh

Posté par fcartegnie le 10 mai 2012 à 14:37. Évalué à 7.

Bref, soit ça permet de « garder » sa connexion active quand le firewall va l'oublier au bout de 5 minutes sans trafic

ServerAliveInterval
- [^] # Re: man ssh
  
  Posté par Raoul Volfoni (site web personnel) le 10 mai 2012 à 15:13. Évalué à 4.
  
  J'aurais dit man ssh_config plutôt mais je pinaille.
  En plus j'ajouterais ServerAliveCountMax qui est au moins aussi important.
  
  Mais avant de dénoncer grave (ahem) faudrait déjà pas confondre le TCPKeepalive et le SSHKeepalive…
- [^] # Re: man ssh
  
  Posté par benoar le 10 mai 2012 à 15:26. Évalué à -2.
  
  Tu peux détailler ? Cette option n'a rien à voir avec la choucroute, car comme l'indique le man, c'est pour les keepalive dans le tunnel ssh, ce qui est différent du keepalive tcp.
  - [^] # Re: man ssh
    
    Posté par Raoul Volfoni (site web personnel) le 10 mai 2012 à 15:44. Évalué à 6.
    
    Bon je vais détailler pour lui because je me sens un peu coupable pour la news à laquelle je n'ai pas vraiment participé…
    
    Il faut bien comprendre que coté serveur il est important de savoir si une connection existe toujours ou a été coupée pour éviter d'avoir des tonnes de connections fantômes à la longue…
    Pour ça on dispose de 2 techniques de keepalive: le TCP et le SSH. Pour la première c'est effectivement au niveau de l'OS et de sa pile IP que tout se passe et on ne maîtrise donc pas grand chose.
    Alors les gentils devs d'OpenSSH on rajouté le keepalive dans le SSH qui a exactement la même fonction si ce n'est que tu disposes de 2 options pour paramétrer le temps entre 2 paquets et le nombre de paquets non acquittés avant de clore la connection.
    
    Alors si ton réseau est vraiment aussi bon je ne vois pas vraiment où est le pb hormis le fait de ne pas vouloir changer des fichiers de config.
    - [^] # Re: man ssh
      
      Posté par benoar le 10 mai 2012 à 17:50. Évalué à 1.
      
      Alors si ton réseau est vraiment aussi bon je ne vois pas vraiment où est le pb hormis le fait de ne pas vouloir changer des fichiers de config.
      
      OK, je pense que vous deux n'avez pas compris le problème. J'en suis quasiment sûr quand je lis :
      
      Il faut bien comprendre que coté serveur il est important de savoir si une connection existe toujours ou a été coupée pour éviter d'avoir des tonnes de connections fantômes à la longue…
      
      Je ne veux pas de keepalive. Je veux pouvoir garder des sessions plusieurs jours alors que ma machine est en veille. Je ne veux pas que le serveur considère cette connexion comme « fantôme ». C'est ainsi qu'a été inventé TCP, pour pouvoir garder des sessions longtemps.
      
      Avoir des keepalive niveau ssh ou tcp ne change rien à cet état de fait. Ça fout la merde. Les sessions, il n'y a que toi qui peut définir si elles sont fantômes. Et donc c'est à toi de les tuer s'il y a eu une merde quelque part dans le réseau assez grave pour que ça coupe toute possibilité de reprise.
      - [^] # Re: man ssh
        
        Posté par Zenitram (site web personnel) le 10 mai 2012 à 17:59. Évalué à 5.
        
        Je veux pouvoir garder des sessions plusieurs jours alors que ma machine est en veille. Je ne veux pas que le serveur considère cette connexion comme « fantôme ».
        
        Et comment il sait que tu es toujours vivant et reviendra?
        Je comprend rien : le serveur doit bien un jour purger ses connexions fantômes sous peine de crouler sous le nombre de connexion fantômes, et je ne vois pas ta proposition pour gérer le bordel?
        
        Comment savoir que tu vas revenir (dans plusieurs jours) ou pas (tu meurs violement dans un accident avec ton PC alors que tu as dit que tu revenais)?
        
        [^] # Re: man ssh
        
        Posté par benoar le 10 mai 2012 à 18:54. Évalué à 0.
        
        Et comment il sait que tu es toujours vivant et reviendra?
        
        Il ne peut pas le savoir.
        
        Je comprend rien : le serveur doit bien un jour purger ses connexions fantômes sous peine de crouler sous le nombre de connexion fantômes, et je ne vois pas ta proposition pour gérer le bordel?
        
        Non, en disant ça tu assumes un certain nombre d'idées préconçues fausses.
        
        Déjà, comment définir une connexion « fantôme » ? Certains disent que c'est une connexion qui n'a pas eu d'activité depuis 5 minutes. Moi je trouve ça naze. La RFC définissant TCP ne défini explicitement pas de telle chose.
        
        Notons, au passage, qu'une connexion qui ne répond plus d'un côté ou d'un autre sera considérée morte après le timeout classique (30s je crois avant première retransmission, puis vraiment morte peu après, avec éventuellement d'autres retransmissions). Mais une connexion qui n'a pas de donnée à transférer n'a pas à mourir. Ces cas sont détaillés dans le paragraphe 4.3.3 de la RFC 675, définissant TCP [http://tools.ietf.org/html/rfc675#section-4.3.3].
        
        Ensuite, il existerait un danger de ces connexions « fantômes » (en plus, c'est un mot qui fait peur). Oui, ton serveur va garder le contexte de ces sessions un certain temps ; et alors ? Si tu as perdu des connexions, c'est à dire si tu as eu un plantage, ou que tu n'as pas pu fermer ces connexions quand tu étais sur le réseau duquel elle venait, c'est à toi de les tuer à la prochaine connexion.
        
        Si tu veux vraiment « gérer » le bordel, purges régulièrement les connexions TCP qui ont plus de X jours, par exemple. Ça correspond à mettre un keepalive de X jours, mais ça n'est pas de cette manière dont il est utilisé aujourd'hui.
        
        En fait, j'ai l'impression que tout le monde imagine que c'est un « problème ». Avoir des sessions ssh qui tombent toutes seules toutes les 5 minutes est pour moi un problème plus grand.
        
        Comment savoir que tu vas revenir (dans plusieurs jours) ou pas (tu meurs violement dans un accident avec ton PC alors que tu as dit que tu revenais)?
        
        Il ne se saura pas. Mais s'il purge ma connexion 30 jours après ma mort par exemple, je ne lui en voudrais pas trop.
        
        Tout le problème est là : vous voulez absolument contrôler quelque chose sur lequel vous ne devriez pas avoir le contrôle.
        
        [^] # Re: man ssh
        
        Posté par Zenitram (site web personnel) le 10 mai 2012 à 19:05. Évalué à 5.
        
        Déjà, comment définir une connexion « fantôme » ?
        
        Chacun le définit, suivant ses envies et aussi les ressources du serveur.
        
        Mais une connexion qui n'a pas de donnée à transférer n'a pas à mourir
        
        Si tu payes les ressources…
        
        c'est à toi de les tuer à la prochaine connexion.
        
        Gni? Tu es du coté du client, mais… Le serveur, il sait comment que tu vas venir les tuer plus tard? Il sait comment que tu ne reviendra jamais?
        
        En fait, j'ai l'impression que tout le monde imagine que c'est un « problème ».
        
        Ca l'est, ne t'en déplaise.
        
        Avoir des sessions ssh qui tombent toutes seules toutes les 5 minutes est pour moi un problème plus grand.
        
        Je ne sais pas comment c'est chez toi, mais chez moi elles ne tombent pas toutes les 5 minutes.
        
        Il ne se saura pas. Mais s'il purge ma connexion 30 jours après ma mort par exemple, je ne lui en voudrais pas trop.
        
        Donc en fait, ce qui te dérange, ce n'est pas le principe, mais la valeur par défaut.
        Le serveur te dit : "tu me les brises, j'ai autre chose à faire que de garder des connexions mortes pendant 30 jours, alors à par si tu me payes plus pour ce genre de conneries, va te faire voir". Et il a raison, c'est à lui de décider de comment il gère ses ressources.
        
        Déjà, tu te contredis bien comme il faut : tu dis qu'il ne doit jamais purger, et puis la tu acceptes une purge (la valeur 5 minutes ou 30 jours n'a aucune importance, c'est du détail de conf')
        
        Tout le problème est là : vous voulez absolument contrôler quelque chose sur lequel vous ne devriez pas avoir le contrôle.
        
        Gérer mes ressources sur mon serveur est mon problème.
        
        [^] # Re: man ssh
        
        Posté par Marotte ⛧ le 10 mai 2012 à 20:12. Évalué à 6.
        
        Avoir des sessions ssh qui tombent toutes seules toutes les 5 minutes est pour moi un problème plus grand.
        
        Je ne sais pas comment c'est chez toi, mais chez moi elles ne tombent pas toutes les 5 minutes.
        
        Je crois qu'il a dit que chez lui aussi ça marchait mais qu'à son taff il avait pas la main sur tous les serveurs donc j'imagine que sur certains il ne peut pas changer ces keepalive, TCP ou SSH, donc il est pas content.
        
        D'un autre coté, un serveur que tu n'administres pas il a bien le droit d'être configuré ainsi et de couper ta session au bout de cinq minutes d'inactivité si c'est le souhait de son admin, pour des raisons de sécurité ou de performance ?
        
        [^] # Re: man ssh
        
        Posté par Zenitram (site web personnel) le 10 mai 2012 à 20:34. Évalué à 4.
        
        si c'est le souhait de son admin, pour des raisons de sécurité ou de performance ?
        
        C'est tout le sens de ma critique : il veut être admin à la place de l'admin, et l'admin est idiot car il ne configure pas comme lui voudrait que ce soit configuré. Ben non, l'admin a juste d'autres priorités (comme tu dis : perfs, sécu) que le confort du monsieur (qui est secondaire), et l'admin (et les mainteneurs SSH) feraient bien une autre option par défaut plus confortable si elle n'avait pas quelques défauts (genre les ressources bouffées même avec un super-méga-réseau génial).
      - [^] # Re: man ssh
        
        Posté par William Steve Applegate (site web personnel) le 10 mai 2012 à 19:34. Évalué à 3.
        
        Je ne veux pas de keepalive. Je veux pouvoir garder des sessions plusieurs jours alors que ma machine est en veille.
        
        Solution 1 : ne pas mettre sa machine en veille (une babasse éteinte, c'est triste ;-)
        Solution 2 : utiliser un truc comme autossh pour remonter les connexions automatiquement (plus screen/tmux pour garder leur état)
        
        De rien.
        
        Envoyé depuis mon PDP 11/70
      - [^] # Re: man ssh
        
        Posté par Kerro le 11 mai 2012 à 00:13. Évalué à 10.
        
        Je ne veux pas de keepalive
        
        Ben c'est facile. Si tu ne veux pas de keepalive, comme c'est toi l'admin du serveur et l'admin de ton poste, tu as juste à désactiver cette option (man ssh_config et man sshd_config).
        
        Si tu n'es pas admin du serveur, figures toi que ce n'est pas à toi de décider si la machine accepte les sessions sans trafic pendant 10 ans. Tout comme ce n'est pas à toi de décider d'ouvrir tel port, d'installer telle version de tel logiciel, etc.
        Si tu n'es pas admin de ton poste de travail, pareil.
        
        Donc la vie est belle.
        
        [^] # Re: man ssh
        
        Posté par benoar le 11 mai 2012 à 12:01. Évalué à -6.
        
        Si tu n'es pas admin du serveur, figures toi que ce n'est pas à toi de décider si la machine accepte les sessions sans trafic pendant 10 ans. Tout comme ce n'est pas à toi de décider d'ouvrir tel port, d'installer telle version de tel logiciel, etc.
        Si tu n'es pas admin de ton poste de travail, pareil.
        
        Je penses que si mon admin me parlait comme ça, j'irai direct lui pourrir toutes les bécanes auquel j'ai accès.
        
        Je ne comprends pas cette violence. Oui, je sais que c'est comme ça, toussa, mais est-on obligé de prendre ses utilisateurs pour des cons et de les prendre de haut pour leur répondre et leur expliquer ça ? J'apporte des arguments, qu'on discute de s'ils sont bons ou pas, mais qu'on ne vienne pas me dire « tu n'as rien à dire parce que ça n'est pas toi qui a le pouvoir, petite merde »
        
        [^] # Re: man ssh
        
        Posté par Larry Cow le 11 mai 2012 à 12:16. Évalué à 6.
        
        Je ne comprends pas cette violence.
        
        Nous non plus, pour tout te dire.
        
        [^] # Re: man ssh
        
        Posté par Zenitram (site web personnel) le 11 mai 2012 à 12:29. Évalué à 7.
        
        J'apporte des arguments, qu'on discute de s'ils sont bons ou pas
        
        On a déjà répondu que oui le problème fait chier, mais que non, on n'a pas de meilleure solution.
        
        mais qu'on ne vienne pas me dire « tu n'as rien à dire parce que ça n'est pas toi qui a le pouvoir, petite merde »
        
        A partir du moment où tu n'écoutes pas la réponse qui se place elle avec les problématiques de l'admin, ben… Dur de ne pas le dire.
        Comprend les contraintes de l'admin d'en face, et argumente que ta "solution" ne va pas faire écrouler la machine plutôt que de continuer à parler de ton confort.
        
        Tu n'argumentes pas avec en tête les problèmes de l'admin, l'admin t'envoie chier, normal. Pose-toi, comprend les contraintes de l'admin, démontres-lui que changer ce paramètre ne va pas le tuer. Ensuite, va sur la liste de discussion SSH (ou de ta distro) pour leur prouver que tu t'es mis en situation réelle, et que aujourd’hui on peut motner le time out (à combien?).
        
        Mais balancer un "je veux qu'on ne tue jamais une connexion" fait juste rire l'admin de la machine.
        
        [^] # Re: man ssh
        
        Posté par benoar le 11 mai 2012 à 14:24. Évalué à 0.
        
        On a déjà répondu que oui le problème fait chier, mais que non, on n'a pas de meilleure solution.
        
        Heu… J'ai bien entendu que vous n'aviez pas de meilleure solution, mais je vous ai entendu au contraire dire que ça n'est pas un problème pour vous.
        
        A partir du moment où tu n'écoutes pas la réponse qui se place elle avec les problématiques de l'admin, ben… Dur de ne pas le dire.
        
        En quoi je n'ai pas écouté la réponse ? J'ai dit que je ne voyais pas de problème à avoir des sessions « fantômes » sur des machines, et on me rétorque que c'est le mal absolu, alors que je n'ai jamais vu un seul admin se plaindre de ça. Pour moi, ils utilisent le keepalive sans se poser de questions. Je ne vois aucun argument valable sur la trop grande consommation de ressources.
        
        Comprend les contraintes de l'admin d'en face, et argumente que ta "solution" ne va pas faire écrouler la machine plutôt que de continuer à parler de ton confort.
        
        Tu veux que j'apporte quoi comme argument ? Quelques connexions tcp qui vont faire écrouler la machine ? Ça ne me semble pas assez solide comme menace.
        
        Tu n'argumentes pas avec en tête les problèmes de l'admin, l'admin t'envoie chier, normal. Pose-toi, comprend les contraintes de l'admin, démontres-lui que changer ce paramètre ne va pas le tuer.
        
        Je l'énonce : ça ne va pas tuer sa machine. Tu dis à tes utilisateurs de bien se comporter (c'est des gens à qui tu files des shells, c'est pas des neuneux non plus), et tout va rouler. Le problème des sessions « fantômes » est un problème que je trouve assez imaginaire.
        
        Ensuite, va sur la liste de discussion SSH (ou de ta distro) pour leur prouver que tu t'es mis en situation réelle, et que aujourd’hui on peut motner le time out (à combien?).
        
        Ça pourrait être une discussion constructive en effet. Ici, c'était un peu un test. Ça n'est pas très concluant.
        
        Mais balancer un "je veux qu'on ne tue jamais une connexion" fait juste rire l'admin de la machine.
        
        J'ai pourtant mis la forme pour réfléchir à ce problème de manière sereine, je trouve. Je ne balance pas ça comme tu le dis.
        
        [^] # Re: man ssh
        
        Posté par allcolor (site web personnel) le 11 mai 2012 à 14:31. Évalué à 4.
        
        Je l'énonce : ça ne va pas tuer sa machine.
        
        Je l'énonce, ça va pas te tuer d'utiliser screen… et l'avantage c'est que tu peux couper la connexion ssh de ton laptop, aller sur une autre machine, te reconnecter en ssh sur le serveur et récupérer ta session entamée depuis ton laptop…
        
        [^] # Re: man ssh
        
        Posté par Zenitram (site web personnel) le 11 mai 2012 à 16:07. Évalué à 2.
        
        Je l'énonce : ça ne va pas tuer sa machine.
        
        Tu veux changer un comportement par défaut.
        Toi.
        Donc : fait des benchs, dans diverses situations, et va le dire aux mainteneurs, ce sera plus utile que de pleurer sur LinuxFr.
        En attendant, ça a été choisi pas pour rien.
        
        Tu dis à tes utilisateurs de bien se comporter
        
        A partir du moment où tu racontes des conneries sur les utilisateurs (tu crois qu'ils vont bien se comporter parce que tu le demandes?), forcément on ne peut que rire à ton "ça ne va pas tuer sa machine" qui n'a aucune crédibilité avec la phrase qui démontre que tu crois toujours que les bisounours existent.
        
        [^] # Re: man ssh
        
        Posté par benoar le 11 mai 2012 à 19:02. Évalué à 0.
        
        Donc : fait des benchs, dans diverses situations, et va le dire aux mainteneurs, ce sera plus utile que de pleurer sur LinuxFr.
        
        Ça serait bien effectivement de « faire des benchs », mais ça n'est pas évident de tester une situation qui est un ensemble de facteurs très divers (qualité du réseau, gestion des serveurs, comportement des utilisateurs,…). Mais une étude sur une sorte d'échantillon pourrait être sympa.
        
        En attendant, ça a été choisi pas pour rien.
        
        Bah justement, je me demande. En regardant le CVS d'OpenSSH, je vois que cette option est active par défaut depuis le début (premier commit de Théo). Ça se trouve, personne ne s'est vraiment posé la question. Et personne ne l'a vraiment testé en conditions réelles, dans les personnes que je connais.
        
        A partir du moment où tu racontes des conneries sur les utilisateurs (tu crois qu'ils vont bien se comporter parce que tu le demandes?),
        
        Ah oui, c'est vrai, tous les utilisateurs sont des cons, j'avais oublié.
        
        forcément on ne peut que rire à ton "ça ne va pas tuer sa machine" qui n'a aucune crédibilité avec la phrase qui démontre que tu crois toujours que les bisounours existent.
        
        Bah riez si vous voulez, mais c'est clair que c'est pas avec des réactions comme ça qu'on essayera d'améliorer notre environnement de travail.
        
        [^] # Re: man ssh
        
        Posté par Zenitram (site web personnel) le 11 mai 2012 à 19:04. Évalué à 4.
        
        Bah riez si vous voulez, mais c'est clair que c'est pas avec des réactions comme ça qu'on essayera d'améliorer notre environnement de travail.
        
        Tu ne propose pas de l'améliorer, vu que tu ne prend pas en compte une chose : la réalité. Les utilisateurs ne sont pas des cons, ils sont juste des gens, normaux, qui ne se font pas chié à nettoyer leur connexion SSH à la main vu qu'il ont autre chose à faire de leur temps. Tu as du temps à perdre, ça ne veut pas dire que les autres en ont.
        
        [^] # Re: man ssh
        
        Posté par Kerro le 11 mai 2012 à 13:08. Évalué à 7.
        
        Je penses que si mon admin me parlait comme ça, j'irai direct lui pourrir toutes les bécanes auquel j'ai accès.
        
        C'est bien le problème: tu n'acceptes pas que les autres pensent de manière différente.
        En fait, TU es le problème. Pour les autres.
        Si tu te retrouves dans une boîte avec un admin droit dans ses bottes, tu vas te prendre un bon recadrage de sa part. Et si ça ne suffit pas, un recadrage bis avec ton supérieur. L'étape 3 étant la porte.
        
        [^] # Re: man ssh
        
        Posté par benoar le 11 mai 2012 à 14:27. Évalué à -5.
        
        OK. Je sais que tu es génial, que tu administres des milliers de bécanes dans ton taf, que tu adores le libre, toussa, mais s'il te plaît, on est là pour discuter, pas pour prendre les gens de haut comme tu le fais.
  - [^] # Re: man ssh
    
    Posté par fcartegnie le 10 mai 2012 à 16:23. Évalué à 2.
    
    Le but n'est pas d'avoir un double keepalive..
    Le ServerKeepalive x de ssh est implémenté d'une manière qui envoie une demande de réponse au serveur ssh toutes les X secondes.
    
    -> Ton firewall ne peut donc fermer la connexion car du trafic sera généré.
    - [^] # Re: man ssh
      
      Posté par benoar le 10 mai 2012 à 17:51. Évalué à 0.
      
      -> Ton firewall ne peut donc fermer la connexion car du trafic sera généré.
      
      Je n'ai pas de firewall statefull, nulle-part. J'ai juste une machine qui est parfois partie de son réseau d'origine, ou en veille, mais qui va revenir. Je ne veux pas de keepalive, cf ma réponse au-dessus.
      - [^] # Re: man ssh
        
        Posté par Gof (site web personnel) le 10 mai 2012 à 18:12. Évalué à 4.
        
        Ce qu'il te faut c'est Mosh alors.
        http://mosh.mit.edu/
        https://linuxfr.org/news/mosh-the-mobile-shell
# tu as fait une énorme faute ...

Posté par manatlan (site web personnel) le 10 mai 2012 à 15:16. Évalué à 10.

normalement, c'est "Le TCP keepalive m'a tuer" !
# Toi, tu vas avoir des problèmes avec Ghislaine Marchal !

Posté par windu.2b le 10 mai 2012 à 15:17. Évalué à 9.

Le TCP keepalive m'a ~~tué~~tuer

Quitte à faire une citation (surtout celle-là), autant la faire jusqu'au bout !
- [^] # Re: Toi, tu vas avoir des problèmes avec Ghislaine Marchal !
  
  Posté par Marotte ⛧ le 10 mai 2012 à 20:20. Évalué à 2.
  
  C'est beau un langue qui évolue !
  
  J'imagine les dictionnaires étymologiques dans quelques centaines d'années : Quelque chose m'a tuer est une exception de la langue française, en effet le participe passé du verbe tuer s'écrit comme son infinitif. Ceci en mémoire d'un certain Omar Raddad qui aurait vécu au XXème siècle mais et qui aurait dessiné avec son sang. L'usage est attesté sur linuxfr.org depuis le XXIème sièce.
  
  Je regarde trop Futurama ?
  - [^] # Re: Toi, tu vas avoir des problèmes avec Ghislaine Marchal !
    
    Posté par lesensei le 10 mai 2012 à 20:29. Évalué à 7.
    
    Pour Futurama, je ne saurais dire. Mais si Omar a dessiné quoi que ce soit avec son sang, on n'a fait que nous mentir dans toute cette histoire, depuis le début ! On ne nous dit pas tout !
    - [^] # Re: Toi, tu vas avoir des problèmes avec Ghislaine Marchal !
      
      Posté par Marotte ⛧ le 10 mai 2012 à 21:24. Évalué à 3. Dernière modification le 10 mai 2012 à 21:26.
      
      Anéfé :) On va dire que c'était volontaire de ma part, pour exprimer la perte d'information et la modification de l'histoire qui arrivent certainement, d'accord ;)
  - [^] # Re: Toi, tu vas avoir des problèmes avec Ghislaine Marchal !
    
    Posté par windu.2b le 10 mai 2012 à 23:12. Évalué à 1.
    
    Ceci en mémoire d'un certain Omar Raddad qui aurait vécu au XXème siècle mais et qui aurait dessiné avec son sang. L'usage est attesté sur linuxfr.org depuis le XXIème sièce.
    
    L'emploi du conditionnel (sur la première partie en gras) est inutile : Omar Raddad existe !
    Quant au deuxième passage en gras, "son sang" est incorrect, vu qu'il s'agissait du sang de Ghislaine Marchal et d'un autre (mais pas celui d'Omar). On ne peut même pas dire que "son" renvoie à Ghislaine, vu qu'à aucun moment auparavant, tu n'as parlé d'elle.
# Euh

Posté par gnumdk (site web personnel) le 10 mai 2012 à 15:45. Évalué à 2. Dernière modification le 10 mai 2012 à 15:47.

Il dit qu'il a rien compris…

Alors qu'en fait pas du tout, ça fait tout pour faire tomber une connexion.

et après:

Chez moi, dans un réseau bien configuré, les sessions ssh tiennent des jours, sans keepalive.

T'as pas l'impression de dire l'inverse? Pourquoi ca tiendrait pas avec si ton réseau est bien configuré ?

Moi je comprend l'option comme: "Couper la connexion si un truc foire entre le serveur et le client", et je trouve ce comportement tout à fait normal, non ?
- [^] # Re: Euh
  
  Posté par barmic le 10 mai 2012 à 16:38. Évalué à 4.
  
  Je crois (mais j'y connais pas grand chose) que c'est une histoire de quand il ne se passe rien pendant un certain temps le serveur ssh détruit la connexion car il crois qu'elle a était droppée et/ou que le lien physique est tombé.
  
  Du coup lui quand il fait rien de sa connexion pendant des plombes, il se retrouve avec une connexion détruite.
  
  Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
  - [^] # Re: Euh
    
    Posté par benoar le 10 mai 2012 à 17:57. Évalué à 3.
    
    Du coup lui quand il fait rien de sa connexion pendant des plombes, il se retrouve avec une connexion détruite.
    
    Exactement, merci de l'éclaircissement.
- [^] # Re: Euh
  
  Posté par benoar le 10 mai 2012 à 17:56. Évalué à 1.
  
  T'as pas l'impression de dire l'inverse? Pourquoi ca tiendrait pas avec si ton réseau est bien configuré ?
  
  La machine peut par exemple être partie temporairement autre part, ou être en veille. TCP a été fait pour garder les connexions très longtemps.
  
  Moi je comprend l'option comme: "Couper la connexion si un truc foire entre le serveur et le client", et je trouve ce comportement tout à fait normal, non ?
  
  Ça dépend de ton interprétation de « un truc foire » : si tu estimes que le système a à répondre dans les 10ms 24h/24, alors pour moi ça n'est pas un comportement normal.
# Je comprends pas

Posté par Anthony Jaguenaud le 10 mai 2012 à 17:04. Évalué à 1.

Si tu changes de réseau, de toute façon TCP à toujours envoyé des ÇAVA ? pour vérifier que la connexion est toujours active, non ?
- [^] # Re: Je comprends pas
  
  Posté par benoar le 10 mai 2012 à 17:54. Évalué à 2.
  
  Non, justement, TCP est fait de manière à ce que quand il n'y a rien à envoyer, il n'envoie rien, mais garde la connexion. Le protocole est fait de manière à pouvoir les garder très longtemps (indéfiniment ?). C'est juste « l'usage » et ce genre de paramètre par défaut qui fait penser aux gens le contraire. C'est très dommage. (cf les réponses légèrement condescendantes ci-dessus qui montre que ce genre d'idée fausse est assez répandu)
  - [^] # Re: Je comprends pas
    
    Posté par Anthony Jaguenaud le 10 mai 2012 à 18:19. Évalué à 2.
    
    Ce qui me choque, c’est que c’est a l’appli côté serveur d’implémenter son timeout.
    Car au final, rien n’empêche quelqu’un d’ouvrir une connexion, et de ne jamais la fermer. Le serveur finira par se retrouver sans possibilité de réouvrir une connexion faute de ressource parce qu’il aura n connexion inactive…
    
    Dis-je une connerie ?
    - [^] # Re: Je comprends pas
      
      Posté par ckyl le 10 mai 2012 à 18:48. Évalué à 3.
      
      TCP fonctionne comme ca et c'est pas plus mal qu'il laisse ca aux couches du dessus. À ce niveau t'as aucune idée des attentes de l'applicatif donc ce que tu vas faire tu vas le faire mal.
      
      En fait c'est le TCP keep alive qui n'aurait pas du exister, il est assez bâtard et t'es toujours obliger de refaire un truc propre au niveau applicatif.
    - [^] # Re: Je comprends pas
      
      Posté par benoar le 10 mai 2012 à 19:00. Évalué à 0.
      
      Ce qui me choque, c’est que c’est a l’appli côté serveur d’implémenter son timeout.
      
      WTF ? Et c'est quoi le keepalive TCP ou ssh d'après toi ?! C'est implémenté par l'appli ! Ça n'est pas du tout la stack TCP qui gère ça !
      
      Car au final, rien n’empêche quelqu’un d’ouvrir une connexion, et de ne jamais la fermer. Le serveur finira par se retrouver sans possibilité de réouvrir une connexion faute de ressource parce qu’il aura n connexion inactive…
      
      Et ? Limite le nombre de connexions par utilisateur. Même avec une keepalive de 5min, je peux te faire un déni de service en moins de temps que ça. Je ne comprends pas cette « peur ».
      
      Après, on se met à réimplémenter du statefull (des sessions en PHP/Java/whatever) sur un protocole stateless (HTTP pour l'exemple) sur un protocole statefull qu'on n'utilise pas comme tel (TCP), et je peux te dire que les ressources bouffées par la mémorisation de ce genre d'empilement pourri est bien pire que garder une connexion TCP !
      
      Dis-je une connerie ?
      
      Je pense que beaucoup de gens ont dans la tête que « garder » une connexion TCP est dangereux, alors que c'est ce qui est fait à plus haut niveau pour tellement d'autres trucs… Je pense que c'est assez irrationnel. En tous cas, tu n'es pas le seul.
      - [^] # Re: Je comprends pas
        
        Posté par Zenitram (site web personnel) le 10 mai 2012 à 19:09. Évalué à 1.
        
        Je pense que c'est assez irrationnel. En tous cas, tu n'es pas le seul.
        
        Ou alors les gens ont des contraintes (de ressources) et optimisent leur ressources.
        Ce n'est pas parce que toi tu ne voit pas d’intérêt que 99% des gens n'en n'ont pas un intérêt (d'où la valeur par défaut).
      - [^] # Re: Je comprends pas
        
        Posté par ckyl le 10 mai 2012 à 19:39. Évalué à 7.
        
        WTF ? Et c'est quoi le keepalive TCP ou ssh d'après toi ?! C'est implémenté par l'appli ! Ça n'est pas du tout la stack TCP qui gère ça !
        
        T'étais presque crédible sur ton couplet TCP-c-est-trop-génial-moi-j-ai-tout compris
        
        sshd.c line 1796
        
        /* Set SO_KEEPALIVE if requested. */ if (options.tcp_keep_alive && packet_connection_is_on_socket() && setsockopt(sock_in, SOL_SOCKET, SO_KEEPALIVE, &on, sizeof(on)) < 0) error("setsockopt SO_KEEPALIVE: %.100s", strerror(errno));
        
        http://tools.ietf.org/html/rfc1122#page-101
        
        que les ressources bouffées par la mémorisation de ce genre d'empilement pourri est bien pire que garder une connexion TCP !
        
        C'est pas tant que ca la connexion TCP qui bouffe de la ressource. Ce sont les données associée à la session et les processus.
        
        En plus comme dit plus haut, d'un point de vue applicatif. Il doit y avoir plus de gens qui préfèrent voir visuellement que leur connexion est tombé (plutôt que d'attendre de taper quelque chose) que de gens comme toi. Dans tout les cas tu as le choix. T'as passé plus de temps sur ce journal qu'il t'en aurait fallu pour faire ta config.
        
        [^] # Re: Je comprends pas
        
        Posté par benoar le 11 mai 2012 à 11:30. Évalué à -1.
        
        T'étais presque crédible sur ton couplet TCP-c-est-trop-génial-moi-j-ai-tout compris
        
        Et t'es obligé d'être si agressif ? OK, c'est géré par la stack, méa culpa, mais c'est demandé par l'appli.
        
        C'est pas tant que ca la connexion TCP qui bouffe de la ressource. Ce sont les données associée à la session et les processus.
        
        OK. Et donc, que me préconises-tu ? De relancer mon « contexte » à chaque fois que je me connecte ? Vive l'automatisation des tâches… Ou alors que j'utilise screen/tmux ? Ah mais alors, niveau ressources, c'est encore pire…
        
        Je ne comprends pas que des mecs s'inquiètent des ressources en socket que pourraient bouffer un utilisateur à qui ils ont donné un shell sur une bécane. Je peux te bouffer des ressources de 50000 autres manières ! Pourquoi limiter artificiellement celle-là et pas les autres, alors qu'elle est si pratique ?!!
        
        En plus comme dit plus haut, d'un point de vue applicatif. Il doit y avoir plus de gens qui préfèrent voir visuellement que leur connexion est tombé (plutôt que d'attendre de taper quelque chose) que de gens comme toi.
        
        Moi, je n'ai pas de retour visuel quand une connexion déconne. Ça me fait chier.
        
        Dans tout les cas tu as le choix.
        
        C'est facile de dire ça quand c'est une option par défaut. « Ferme-là, tu n'as rien à critiquer, le monde a décidé pour toi »
        
        T'as passé plus de temps sur ce journal qu'il t'en aurait fallu pour faire ta config.
        
        Je n'ai pas la main sur tous les serveurs.
        
        [^] # Re: Je comprends pas
        
        Posté par Zenitram (site web personnel) le 11 mai 2012 à 11:44. Évalué à 2.
        
        Je ne comprends pas que des mecs s'inquiètent des ressources en socket que pourraient bouffer un utilisateur à qui ils ont donné un shell sur une bécane. Je peux te bouffer des ressources de 50000 autres manières ! Pourquoi limiter artificiellement celle-là et pas les autres,
        
        Parce que c'est un problème classique.
        
        alors qu'elle est si pratique ?!!
        
        bof.
        
        C'est facile de dire ça quand c'est une option par défaut. « Ferme-là, tu n'as rien à critiquer, le monde a décidé pour toi »
        
        Ben oui, les gens font des choix. Mais toi tu as le meilleur choix par défaut, il faut t'écouter, c'est évident, car c'est toi qui a décidé!
        Ou alors : non, ton choix n'est pas le meilleur choix par défaut.
        
        Je n'ai pas la main sur tous les serveurs.
        
        Donc ce n'est pas à toi de décider de la politique de gestion de la machine.
        
        [^] # Re: Je comprends pas
        
        Posté par benoar le 11 mai 2012 à 12:10. Évalué à -4.
        
        Parce que c'est un problème classique.
        
        Quel argument ! Là, tu m'as convaincu…
        Tu peux détailler plus ? Il y a mille moyens de faire chier un admin. Mettre des restrictions artificielles comme le keepalive est déjà un mauvais signe envers ses utilisateurs.
        
        Ben oui, les gens font des choix. Mais toi tu as le meilleur choix par défaut, il faut t'écouter, c'est évident, car c'est toi qui a décidé!
        
        Mais pourquoi tu le prends tout de suite comme ça ? J'expose mon avis, j'argumente, et on me réponds en m'agressant. J'essaye juste de comprendre.
        
        Ou alors : non, ton choix n'est pas le meilleur choix par défaut.
        
        Très bien, mais j'aurais aimé qu'on me convainque mieux que ce que j'ai vu jusque là. Le seul argument convainquant que j'ai vu, c'est qu'à priori, pour les gens, ssh est vu comme un outil à utilisation courte.
        
        Donc ce n'est pas à toi de décider de la politique de gestion de la machine.
        
        Ah, un argument massue. Bravo, tu fais bien avancer le débat.
        
        [^] # Re: Je comprends pas
        
        Posté par allcolor (site web personnel) le 11 mai 2012 à 14:21. Évalué à 7.
        
        ssh est vu comme un outil à utilisation courte.
        
        Ce qu'on comprends c'est que tu te barres du réseau et tu veux que ta connexion ssh ouverte qui ne fait absolument plus rien ne soit pas coupée… alors que ça ne sert absolument à rien qu'elle reste ouverte vu que tu ne fais rien (et que dedans tu ne fais rien non plus, y a pas de prog qui tourne). Tu veux vraiment qu'on te plaigne parce que quand tu reviens (et que tu veux utiliser la connexion ssh) tu dois taper ssh lamachine ??
        
        [^] # Re: Je comprends pas
        
        Posté par benoar le 11 mai 2012 à 14:33. Évalué à -4.
        
        Ce qu'on comprends c'est que tu te barres du réseau et tu veux que ta connexion ssh ouverte qui ne fait absolument plus rien ne soit pas coupée… alors que ça ne sert absolument à rien qu'elle reste ouverte vu que tu ne fais rien
        
        Alors, reprenons les bases : tcp est fait de manière à ce que quand rien ne se passe sur une connexion, il n'y a rien à faire. Magique, non ? C'est la manière dont a été fait ce protocole. Déjà, j'ai l'impression que peu de personnes comprennent ça.
        
        (et que dedans tu ne fais rien non plus, y a pas de prog qui tourne).
        
        Et bien si ! Il peu y avoir plein de programmes qui tournent. Juste, ils n'envoient pas de données à l'autre bout.
        
        Tu veux vraiment qu'on te plaigne parce que quand tu reviens (et que tu veux utiliser la connexion ssh) tu dois taper ssh lamachine ??
        
        J'ai tout un contexte qui accompagne cette session. Après, il existe le workaround screen/tmux, effectivement, mais j'ai déjà détaillé pourquoi je trouvais ça pas optimal.
        
        [^] # Re: Je comprends pas
        
        Posté par allcolor (site web personnel) le 11 mai 2012 à 14:36. Évalué à 7.
        
        Après, il existe le workaround screen/tmux, effectivement, mais j'ai déjà détaillé pourquoi je trouvais ça pas optimal.
        
        Ben alors râle, gratte le sol avec tes pieds et hurle… ou bien ravale ton orgueil et utilise screen (qui est bien plus pratique que juste des sessions tcp longues).
        
        [^] # Re: Je comprends pas
        
        Posté par ckyl le 11 mai 2012 à 12:19. Évalué à 6.
        
        Et t'es obligé d'être si agressif ? OK, c'est géré par la stack, méa culpa, mais c'est demandé par l'appli.
        
        Je suis agressif ? Je suis juste factuel.
        
        OK. Et donc, que me préconises-tu ? De relancer mon « contexte » à chaque fois que je me connecte ? Vive l'automatisation des tâches… Ou alors que j'utilise screen/tmux ? Ah mais alors, niveau ressources, c'est encore pire…
        
        Je ne comprends pas que des mecs s'inquiètent des ressources en socket que pourraient bouffer un utilisateur à qui ils ont donné un shell sur une bécane. Je peux te bouffer des ressources de 50000 autres manières ! Pourquoi limiter artificiellement celle-là et pas les autres, alors qu'elle est si pratique ?!!
        
        C'est une protection contre les leaks involontaires. Quand tu es en utilisation interactive tu veux que quand y'a un problème, ca garbage automatiquement, pas devoir revenir tuer tes shells, et les admins ne veulent pas non plus avoir à gérer ca. Quand tu es en utilisation batch, les utilisateurs savent qu'ils ont leurs processus en background a gérer puisqu'ils l'ont choisi. Dans ton les cas ton shell se termine.
        
        Faut vraiment vivre à bisounours land pour penser que les utilisateurs reviennent tuer les processus quand une session interactive foire et qu'ils ont envi de s'amuser à retrouver les processus.
        
        Moi, je n'ai pas de retour visuel quand une connexion déconne. Ça me fait chier.
        
        Bien sur que si ton client SSH se termine avec un 255 comme exit value que se soit avec le TCP keepalive (bon la on est sur un temps de ~2h) ou le server alive.
        
        Dans clientloop.c
        
        Pour le server alive
        
        static void server_alive_check(void) { if (packet_inc_alive_timeouts() > options.server_alive_count_max) { logit("Timeout, server %s not responding.", host); cleanup_exit(255); } packet_start(SSH2_MSG_GLOBAL_REQUEST); packet_put_cstring("keepalive@openssh.com"); packet_put_char(1); /* boolean: want reply */ packet_send(); /* Insert an empty placeholder to maintain ordering */ client_register_global_confirm(NULL, NULL); }
        
        Pour le TCP keepalive
        
        static void client_process_net_input(fd_set *readset) { int len, cont = 0; char buf[8192]; /* * Read input from the server, and add any such data to the buffer of * the packet subsystem. */ if (FD_ISSET(connection_in, readset)) { [...] if (len < 0) { /* * An error has encountered. Perhaps there is a * network problem. */ snprintf(buf, sizeof buf, "Read from remote host %.300s: %.100s\r\n", host, strerror(errno)); buffer_append(&stderr_buffer, buf, strlen(buf)); quit_pending = 1; return; } packet_process_incoming(buf, len); } int client_loop(int have_pty, int escape_char_arg, int ssh2_chan_id) { while (!quit_pending) { [...] client_process_net_input(readset); if (quit_pending) break; [...] } }
        
        C'est tout l'intérêt du truc.
        
        C'est facile de dire ça quand c'est une option par défaut. « Ferme-là, tu n'as rien à critiquer, le monde a décidé pour toi »
        
        Oui c'est facile à dire quand le choix est pertinent et qu'en plus on peut le modifier.
        
        [^] # Re: Je comprends pas
        
        Posté par benoar le 11 mai 2012 à 14:42. Évalué à -1.
        
        C'est une protection contre les leaks involontaires. Quand tu es en utilisation interactive tu veux que quand y'a un problème, ca garbage automatiquement, pas devoir revenir tuer tes shells, et les admins ne veulent pas non plus avoir à gérer ca.
        
        Oui, mais ça ta machine le fait aussi normalement si tu ne l'éteins pas comme un barbare. Tu peux tuer tous tes processus, c'est ton OS qui fermera tranquillement tes sessions tcp. Les piles tcp sont quand même vachement bien pensées pour ça !
        
        Faut vraiment vivre à bisounours land pour penser que les utilisateurs reviennent tuer les processus quand une session interactive foire et qu'ils ont envi de s'amuser à retrouver les processus.
        
        Mais c'est quoi une session interactive qui foire ?! Le seul cas que je vois, c'est le plantage de l'OS (même pas du programme !), ou le redémarrage alors qu'on est déconnecté du réseau. Ça arrive si souvent que ça ?
        
        Bien sur que si ton client SSH se termine avec un 255 comme exit value que se soit avec le TCP keepalive (bon la on est sur un temps de ~2h) ou le server alive.
        
        Le keepalive TCP est actif par défaut, pas le server alive. C'est la conf utilisée partout. Du coup je suis un peu emmerdé.
        
        Oui c'est facile à dire quand le choix est pertinent et qu'en plus on peut le modifier.
        
        J'ai lancé ce journal pour discuter de la pertinence de ce choix. Je n'ai pour l'instant pas été très convaincu des arguments pour justifier ce choix.
        
        Après, oui, il est modifiable, mais c'est comme tout : c'est très facile d'envoyer balader quelqu'un en lui disant qu'il peut faire autrement. Les choix par défaut sont une composante essentielle du fonctionnement global d'une technologie. Je trouve que ce choix par défaut est dommage car il pénalise les gens qui utilisent toutes les possibilités du réseau.
        
        [^] # Re: Je comprends pas
        
        Posté par Larry Cow le 11 mai 2012 à 14:47. Évalué à 5.
        
        Le seul cas que je vois, c'est le plantage de l'OS (même pas du programme !), ou le redémarrage alors qu'on est déconnecté du réseau.
        
        Et la mise en veille, manifestement. Ou alors je ne comprends vraiment plus pourquoi tu râles.
        
        [^] # Re: Je comprends pas
        
        Posté par benoar le 11 mai 2012 à 14:52. Évalué à -1.
        
        Et la mise en veille, manifestement. Ou alors je ne comprends vraiment plus pourquoi tu râles.
        
        Et bien non, justement. À la mise en veille, ton OS garde bien sûr l'état actuel de ses connexions TCP. Quand tu vas le réveiller, et que tu réutiliseras tes connexions, elles vont soit reprendre (sans keepalive, normalement le serveur en face les aura gardé), soit se prendre un timeout parce que le serveur en face a eu un problème.
        
        [^] # Re: Je comprends pas
        
        Posté par ckyl le 11 mai 2012 à 15:10. Évalué à 3.
        
        Les piles tcp sont quand même vachement bien pensées pour ça !
        
        Oui. Par contre t'as développé et gérés combien de systèmes au dessus de TCP en prod ? Tu serais surpris de ce qu'il se passe dans la vraie vie.
        
        ou le redémarrage alors qu'on est déconnecté du réseau. Ça arrive si souvent que ça ?
        
        Cf mon autre message. Tout les laptops sous linux qui ont une mise en veille pourrie et qui crash au resume ? Tout les laptops qui arrivent à cours de batterie ? Toutes les coupures de courant ? Avec des VM je suis sur qu'il y a des choses intéressantes aussi.
        
        Oui la prod est pétée de sale truc et on a pas envie de gérer ces conneries à la main.
        
        C'est un peu comme dire que TCP assure l'intégrité des messages et que t'as pas besoin de le faire niveau applicatif. La théorie te dit ok, la pratique te montre que des corruptions de segment alors que le checksum est valide ca arrive. La couche réseau n'est qu'une base pour monter un service. C'est un boulon.
        
        [^] # Re: Je comprends pas
        
        Posté par benoar le 11 mai 2012 à 15:22. Évalué à -1.
        
        Oui. Par contre t'as développé et gérés combien de systèmes au dessus de TCP en prod ? Tu serais surpris de ce qu'il se passe dans la vraie vie.
        
        Je n'ai effectivement pas l'expérience des très gros systèmes avec des milliers de gens dessus. Je sais bien qu'il arrive des choses étranges dans la vraie vie. On essaye de se protéger comme on peut. Mais killer une session qui ne répond pas après 5 minutes (timeout par défaut, il me semble), c'est vraiment court.
        
        Cf mon autre message. Tout les laptops sous linux qui ont une mise en veille pourrie et qui crash au resume ? Tout les laptops qui arrivent à cours de batterie ? Toutes les coupures de courant ? Avec des VM je suis sur qu'il y a des choses intéressantes aussi.
        
        Bien sûr que ce genre de problème arrive, j'en suis tout à fait conscient. Mais est-ce assez courant pour que ça mérite d'avoir un paramètre par défaut dans un soft comme ssh ? Si ça l'est, ça m'inquiète beaucoup sur l'état de certaines machines ou certains réseaux. Il faut essayer d'y remédier. Si c'est exceptionnel, traiter ces cas par des mécanismes plus doux (genre une sorte de keepalive d'une semaine par exemple) serait beaucoup plus intelligent.
        
        La théorie te dit ok, la pratique te montre que des corruptions de segment alors que le checksum est valide ca arrive. La couche réseau n'est qu'une base pour monter un service. C'est un boulon.
        
        Et ça arrive avec quelle occurrence ? Est-ce que tous les protocoles réimplémentent des checksums au-dessus ? Est-ce que ça les rend tout pourris ? Et à partir de quel niveau tu fais confiance au protocole ?…
        
        [^] # Re: Je comprends pas
        
        Posté par gnumdk (site web personnel) le 11 mai 2012 à 15:35. Évalué à 4.
        
        après 5 minutes (timeout par défaut, il me semble), c'est vraiment court.
        
        Moi, je trouve cela trop long, comme quoi et ca me gonfle régulièrement de me trouver avec des shells bloqués à cause d'une connexion ssh bloquée, et je viens pas faire chier mon monde sur linuxfr pour dire que les devs d'openssh sont des boulets… Parce que effectivement, parfois ca le fait de voir la session repartir toute seule après reconnexion…
        
        Donc un juste milieu me semble correct….
        
        [^] # Re: Je comprends pas
        
        Posté par benoar le 11 mai 2012 à 15:45. Évalué à 1.
        
        Moi, je trouve cela trop long, comme quoi et ca me gonfle régulièrement de me trouver avec des shells bloqués à cause d'une connexion ssh bloquée,
        
        Intéressant. As-tu déjà essayé de diagnostiquer pourquoi ça déconne ? Ça serait intéressant de trouver la source du problème, je trouve, plutôt que d'avoir à trouver un workaround. Parce que je suppose que ça t'embêtes d'avoir à modifier cet intervalle sur les serveurs sur lesquels tu te trouves, non ? Quoique dans ton cas, tu pourrais aussi le raccourcir niveau client, déjà.
        
        et je viens pas faire chier mon monde sur linuxfr pour dire que les devs d'openssh sont des boulets…
        
        Heu… Déjà, je n'ai jamais dit que c'était des boulets (déjà précisé dans un autre commentaire), et ensuite, je vais « faire chier mon monde sur linuxfr » ? Qu'est-ce que j'ai fait de mal pour t'énerver ainsi ? J'ai émis des critique sur le choix par défaut d'un soft, afin de lancer le débat… j'ai le droit, non ?
        
        Parce que effectivement, parfois ca le fait de voir la session repartir toute seule après reconnexion…
        
        Je ne suis pas sûr de comprendre : tu parles dans le cas avec keepalive ?
        
        Donc un juste milieu me semble correct….
        
        Le problème, comme je l'ai déjà dit, c'est que normalement, tcp devrait très bien s'accommoder des problèmes de réseau « classiques ». Et que pour les problèmes dûs à des réseaux mal configurés, ça serait bien d'essayer de corriger le réseau, plutôt. D'où ma suggestion plus haut de voir ce qui ne va pas. Car avec ce workaround, le problème, c'est qu'il n'y a pas vraiment de « juste milieu » : effectivement, si tu considères qu'une machine doit répondre tout le temps aux sollicitations (ce que je n'aime pas comme supposition), autant mettre l'intervalle de keepalive à 5 secondes, comme ça tu vois direct quand ça déconne.
        
        [^] # Re: Je comprends pas
        
        Posté par claudex le 11 mai 2012 à 15:53. Évalué à 3.
        
        Ça serait intéressant de trouver la source du problème, je trouve, plutôt que d'avoir à trouver un workaround.
        
        Trouver la source du problème ne veut pas dire pouvoir la corriger.
        
        « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
        
        [^] # Re: Je comprends pas
        
        Posté par gnumdk (site web personnel) le 11 mai 2012 à 15:54. Évalué à 2.
        
        As-tu déjà essayé de diagnostiquer pourquoi ça déconne ?
        
        Désolé, je ne fais pas que du ssh sur mon lan…
        
        [^] # Re: Je comprends pas
        
        Posté par ckyl le 11 mai 2012 à 16:03. Évalué à 3.
        
        Mais killer une session qui ne répond pas après 5 minutes (timeout par défaut, il me semble), c'est vraiment court.
        
        sysctl -a 2> /dev/null | grep keep net.ipv4.tcp_keepalive_time = 7200 net.ipv4.tcp_keepalive_probes = 9 net.ipv4.tcp_keepalive_intvl = 75
        
        2H comme spécifié par la RFC.
        
        Mais est-ce assez courant pour que ça mérite d'avoir un paramètre par défaut dans un soft comme ssh ?
        
        Oui. Des laptops qui freezent, j'en vois 4x par jour. Sans compter les autres problèmes.
        
        Et ça arrive avec quelle occurrence ? Est-ce que tous les protocoles réimplémentent des checksums au-dessus ?
        
        Fréquence aléatoire. Ca peut arriver très fréquemment quand tu as un switch qui déconne, une carte réseau defectueuse etc. Quand ca arrive ca peut donner 12 heures de coupure sur Amazon S3 à cause d'un bit flip dans un gossip protocol…
        
        Je pense que tu as deux problèmes. Tu considères que les cas d'erreurs sont suffisamment rare pour être ignorés, ne sont pas graves et que les utilisateurs préfèrent réparer les erreurs. Et d'autre part tu sembles supposer que les choix fait par TCP sont applicables aux couches du dessus. TCP n'offre que le sous ensemble commun nécéssaire à tout les protocoles de couche supérieur. Le keep-alive est vraiment un truc litigieux, qui est d'ailleurs dans une RFC annexe. Ca a été inclus car détecter les pannes est un besoin très courant mais le faire au niveau TCP est assez moisi.
        
        Ta vision est envisageable dans des environnements très particuliers. Pas pour la majorité des systèmes.
        
        [^] # Re: Je comprends pas
        
        Posté par benoar le 11 mai 2012 à 16:25. Évalué à 2.
        
        2H comme spécifié par la RFC.
        
        Ah, pardon, merci de l'info. J'avais l'impression que c'était plus court, et j'avais 300s dans la tête pour je ne sais quelle raison. Mais ça le fait effectivement en général pour des temps d'absence assez longs.
        
        Oui. Des laptops qui freezent, j'en vois 4x par jour. Sans compter les autres problèmes.
        
        Et qui freezent avec des connexions ssh ouvertes ? C'est du windows, ou pas ? Ça mettrait tant de sessions fantômes que ça qu'un keepalive à une semaine ne serait pas assez ?
        
        Fréquence aléatoire. Ca peut arriver très fréquemment quand tu as un switch qui déconne, une carte réseau defectueuse etc.
        
        Et ça te coupe des sessions tcp si souvent que ça ? C'est des switchs qui font firewall statefull ? La carte réseau défectueuse ça arrive vraiment très fréquemment ? Comme j'ai déjà dit, je n'ai pas travaillé dans de très gros environnements, mais que ce problème ce conjugue avec des sessions ssh qui passaient par là à ce moment, de manière assez récurrente, ça me paraît tellement pas assez probable pour que ça soit un problème d'envergure. Mais je dois peut-être me tromper.
        
        Quand ca arrive ca peut donner 12 heures de coupure sur Amazon S3 à cause d'un bit flip dans un gossip protocol…
        
        C'est quoi cette histoire ?
        
        Je pense que tu as deux problèmes. Tu considères que les cas d'erreurs sont suffisamment rare pour être ignorés, ne sont pas graves et que les utilisateurs préfèrent réparer les erreurs.
        
        Effectivement, je considère, peut-être à tort, qu'ils sont assez rares pour être ignorés. Que ça soit aux utilisateurs de le réparer, on peut envisager de mettre une sort de keepalive à une semaine (je ne sais pas si c'est réaliste avec un mécanisme de keepalive ; peut-être envisager un système de nettoyage de socket inactives pendant une semaine) afin d'automatiser ça. Mais responsabiliser les utilisateurs, c'est déjà pas mal : tu leurs dis déjà de fermer leur session web correctement, pourquoi pas la même chose avec ssh ? (remarquons au passage que c'est le même problème : ça fait chier les utilisateurs qui ont des sessions http qu'ils veulent faire durer longtemps, quand un site te déco après X minutes d'inactivité)
        
        Et d'autre part tu sembles supposer que les choix fait par TCP sont applicables aux couches du dessus.
        
        Bah, ssh est quand même pour moi vachement lié à tcp, je pense que c'est normal qu'il « subisse » ses choix.
        
        TCP n'offre que le sous ensemble commun nécéssaire à tout les protocoles de couche supérieur. Le keep-alive est vraiment un truc litigieux, qui est d'ailleurs dans une RFC annexe. Ca a été inclus car détecter les pannes est un besoin très courant mais le faire au niveau TCP est assez moisi.
        
        Effectivement. Mais même niveau au-dessus, je ne suis pas fan.
        
        Merci pour ce commentaire constructif en tous cas.
        
        [^] # Re: Je comprends pas
        
        Posté par ckyl le 11 mai 2012 à 17:01. Évalué à 2.
        
        Et qui freezent avec des connexions ssh ouvertes ? C'est du windows, ou pas ?
        
        Les problèmes hard ca arrive. Surtout avec les portables qui chauffent. Mais ce n'est qu'un exemple. Les problèmes ca arrive tout le temps pour des milliards de raisons. L'univers est très inventif.
        
        Franchement c'est marrant de voir tout ce qu'il peut arriver. En étant plus large que ce problème j'ai déjà rencontrer des cas que je n'explique toujours pas même avec les dump réseau en main. Tout ce que j'ai découvert c'est que ca pouvait arriver.
        
        C'est quoi cette histoire ?
        
        http://status.aws.amazon.com/s3-20080720.html
        
        je pense que c'est normal qu'il « subisse » ses choix.
        
        Non. Tu choisis TCP (ou un autre) pour les services qu'il fourni et tu les complètes si besoin. Par exemple tu vas devoir heartbeater si tu as besoin de découvrir en un temps raisonnable que ton lien à un problème avant que le buffer d'émission soit plein et que le kernel te jette.
        
        Bref c'est très bien que TCP ait ce design. Mais c'est le fonctionnel de l'applicatif qui décide de ce qu'il faut faire.
        
        [^] # Re: Je comprends pas
        
        Posté par Psychofox (Mastodon) le 11 mai 2012 à 15:10. Évalué à 5.
        
        Je ne comprends pas que des mecs s'inquiètent des ressources en socket que pourraient bouffer un utilisateur à qui ils ont donné un shell sur une bécane. Je peux te bouffer des ressources de 50000 autres manières ! Pourquoi limiter artificiellement celle-là et pas les autres, alors qu'elle est si pratique ?!!
        
        Parce que c'est plus facile pour un admin de faire un su - benoar -c "kill -9 -1" si tu commences à le faire chier à pomper ses ressources plutôt qu'à aller fouiller dans les sessions tcp lesquelles sont légitimes et lesquelles il peut killer de façon safe.
        
        [^] # Re: Je comprends pas
        
        Posté par benoar le 11 mai 2012 à 15:16. Évalué à -3.
        
        Parce que c'est plus facile pour un admin de faire un su - benoar -c "kill -9 -1" si tu commences à le faire chier à pomper ses ressources plutôt qu'à aller fouiller dans les sessions tcp lesquelles sont légitimes et lesquelles il peut killer de façon safe.
        
        Heu… Tu sais qu'avec ton kill (qui ne va pas distinguer les processus « légitimes » non plus…) tu vas également tuer toutes les connexions TCP associées à mon compte ? Tu vas donc exactement arriver au résultat que tu voulais, sans besoin de keepalive.
        
        [^] # Re: Je comprends pas
        
        Posté par Psychofox (Mastodon) le 11 mai 2012 à 17:59. Évalué à 2.
        
        je sais bien mais au moins je n'ai pas à trier parmi les connexions tcp ouvertes par tous les comptes.
        
        Alors qu'en général si c'est un problème d'engorgement cpu ou mémoire, le coupable est super vite trouvé. J'ai raccourci un peu vite avec le kill -9 -1 mais en général c'est une mauvaise pratique de faire tourner une appli en prod avec un user "jean dupont" qui peut se logger via ssh donc sur les machines que je gère je me permets allègrement de killer toutes les sessions d'un user "humain" si je soupçonne qu'il ait lancé un truc un peu dangereux (le cas typique du push du contenu d'un gros fichier en perl par exemple). Au pire je lui flingue un batch ponctuel, mais au moins j'ai le temps de l'appeler avant que la machine soit en rade ou qu'il le relance.
        
        [^] # Re: Je comprends pas
        
        Posté par benoar le 11 mai 2012 à 18:40. Évalué à 2.
        
        je sais bien mais au moins je n'ai pas à trier parmi les connexions tcp ouvertes par tous les comptes.
        
        Je ne suis pas sûr d'avoir bien compris ta réponse, mais je parlais justement du fais que le kill était également la solution au cas où tu te retrouves avec des sessions tcp en grand nombres qui te bouffent des ressources, puisque c'est l'inconvénient qu'on essayait de mitiger dans le cas où on n'active pas le keepalive. L'abus de connexions tcp se corrige donc de la même manière que l'abus de ressources CPU/mémoire, et se traite aussi facilement ! C'est pas beau, ça ?
        
        Donc, je ne vois pas en quoi désactiver le keepalive poserait plus de problèmes dans la gestion des cas de congestion que l'abus « classique » d'autres types de ressources. C'est là où je voulais en venir.
        
        [^] # Re: Je comprends pas
        
        Posté par ckyl le 11 mai 2012 à 18:56. Évalué à 4.
        
        Ce qu'il dit c'est qu'un mec qui abuse volontairement tu lui shoots tout voir tu lui bloque l'accès. Un mec qui à un truc qui déconne, tu lui buttes son processus, tu le préviens et tu reviens à la solution 1 si ça recommence trop souvent.
        
        Si SSH te laisse traîner des shells, tu peux pas vraiment blâmer les utilisateurs. Tu te rappels pas forcément qu'une cnx à déconnée et ils ont pas que ça a faire que de tout vérifier. Faut pas oublier que pas mal de machines ont plusieurs centaines d'utilisateurs, et que les utilisateurs peuvent avoir beaucoup de machines remote (pendant un moment je devais accès sur 5 à 10K machines).
        
        C'est un peu comme imaginer que le système puisse ne pas nettoyer la mémoire quand un process crash et qu'on doivent le faire à la main.
        
        [^] # Re: Je comprends pas
        
        Posté par benoar le 11 mai 2012 à 19:08. Évalué à 0.
        
        Ce qu'il dit c'est qu'un mec qui abuse volontairement tu lui shoots tout voir tu lui bloque l'accès. Un mec qui à un truc qui déconne, tu lui buttes son processus, tu le préviens et tu reviens à la solution 1 si ça recommence trop souvent.
        
        Effectivement.
        
        Si SSH te laisse traîner des shells, tu peux pas vraiment blâmer les utilisateurs. Tu te rappels pas forcément qu'une cnx à déconnée et ils ont pas que ça a faire que de tout vérifier.
        
        Effectivement, c'est reulou à faire à la main. On pourrait imaginer un keepalive à une semaine, ça pourrait être raisonnable et nettoyer automatiquement les sessions « fantômes ».
        
        C'est un peu comme imaginer que le système puisse ne pas nettoyer la mémoire quand un process crash et qu'on doivent le faire à la main.
        
        Oui, sur des systèmes de grande envergure, il faut trouver un système automatique. L'avantage avec les processus, c'est qu'on peut détecter quand ils crashent, et il y a l'oom-killer en cas de dérapage. Pour les sockets tcp, une période d'inactivité d'une semaine me semble pas mal.
        
        [^] # Re: Je comprends pas
        
        Posté par Zenitram (site web personnel) le 12 mai 2012 à 11:12. Évalué à 3.
        
        On pourrait imaginer un keepalive à une semaine, ça pourrait être raisonnable
        
        Raisonnable pour toi. Les autres peuvent aussi trouver une autre valeur raisonnable (genre le défaut d'OpenSSH).
        Chacun son raisonnable, tu es libre de changer sur les machines sous ta responsabilité, et les autres sont libres de ne pas changer sur les machines de leur responsabilité.
        
        Les autres admins sont libres de ne pas être d'accord avec toi.
  - [^] # Re: Je comprends pas
    
    Posté par ckyl le 10 mai 2012 à 18:35. Évalué à 9.
    
    Oui enfin bon ta condescendances sur "TCP est prévu pour ca, les mecs d'OpenSSH sont des cons moi je sais ce qu'il faut faire" est pire.
    
    Cette fonctionnalité de TCP c'est cool, le problème c'est que si tu n'émets pas de trafic, la connexion à une durée de vie illimitée et tu ne peux jamais libérer les ressources. Dans le monde réel ca pose comme un tout petit problème. Donc OpenSSH prend une très bonne approche, utiliser une configuration par défaut qui convient à 99% des configs (que leur réseau soit bon ou mauvais, ils ne veulent pas que ca leak) et fournissent une option pour ceux qui préfère l'autre comportement. En plus ils fournissent un heartbeat applicatif au dessus de TCP, qui est aussi nécessaire par ce que beaucoup de gens n'ont pas envie de devoir taper une commande pour se rendre compte que la connexion est tombée ou pour éviter de tomber dans la lenteur des timeouts TCP.
    
    Bref les choix par défaut sont très raisonnables, et tu as toutes les options nécessaires pour faire ce que tu veux. Pourquoi venir pleurer pour qu'ils passent en mode "tire toi dans le pied" par défaut ?
    - [^] # Re: Je comprends pas
      
      Posté par Zenitram (site web personnel) le 10 mai 2012 à 18:59. Évalué à 2.
      
      Pourquoi venir pleurer pour qu'ils passent en mode "tire toi dans le pied" par défaut ?
      
      Parce que chaque personne pense que sa façon de voir est celle que tout le monde devrait avoir, combien même sa façon n'est pas la même que celle du voisin (oui, c'est du vécu "il faudrait x par défaut, c'est évident t'es trop stupide de ne pas le faire")
    - [^] # Re: Je comprends pas
      
      Posté par benoar le 10 mai 2012 à 19:13. Évalué à -1.
      
      Oui enfin bon ta condescendances sur "TCP est prévu pour ca, les mecs d'OpenSSH sont des cons moi je sais ce qu'il faut faire" est pire.
      
      Je n'ai jamais dit ça. J'ai regretté qu'ils l'aient activé par défaut, mais je pense qu'ils l'ont fait pour accommoder beaucoup d'utilisateurs qui blâmaient ssh alors qu'ils avaient un réseau pourri.
      
      Cette fonctionnalité de TCP c'est cool, le problème c'est que si tu n'émets pas de trafic, la connexion à une durée de vie illimitée et tu ne peux jamais libérer les ressources. Dans le monde réel ca pose comme un tout petit problème.
      
      Le nombres de ressources que tu gaspilles à gérer la persistance plus haut… Et si ce timeout était de plusieurs jours/semaines par défaut, ça serait déjà moins problématique. Mais non, c'est fait pour killer les sessions très rapidement.
      
      Donc OpenSSH prend une très bonne approche, utiliser une configuration par défaut qui convient à 99% des configs (que leur réseau soit bon ou mauvais, ils ne veulent pas que ca leak) et fournissent une option pour ceux qui préfère l'autre comportement.
      
      C'est ce que j'ai expliqué dans mon journal : oui, ils ont voulu s'adapter aux réseaux pourris, et donc aujourd'hui, quand on a un réseau qui marche bien, ça fait plus chier qu'autre chose, du coup personne n'a l'envie d'avoir un réseau qui marche. Ça te fait plaisir d'avoir des sessions ssh qui tombent régulièrement ? Pas moi.
      
      En plus ils fournissent un heartbeat applicatif au dessus de TCP, qui est aussi nécessaire par ce que beaucoup de gens n'ont pas envie de devoir taper une commande pour se rendre compte que la connexion est tombée ou pour éviter de tomber dans la lenteur des timeouts TCP.
      
      Le hearbeat applicatif a exactement le même but que le keepalive tcp. Ça n'a pas de rapport avec s'il y a du trafic ou non. L'avantage, disent-ils, c'est qu'on ne peut pas spoofer le keepalive applicatif, contrairement au keepalive tcp (même si ça me paraît un cas un peu maigre pour mériter une telle option, mais pourquoi pas).
      
      Bref les choix par défaut sont très raisonnables, et tu as toutes les options nécessaires pour faire ce que tu veux. Pourquoi venir pleurer pour qu'ils passent en mode "tire toi dans le pied" par défaut ?
      
      Parce que les choix par défaut font que ça pourrit les utilisations « modernes » d'une pile TCP. Ça n'est pas se tirer dans le pied, c'est comme ça qu'a été imaginé TCP. On en réduit les fonctionnalités parce que une bonne partie des gens ont des réseaux pourris, mais on ne fait surtout rien pour inciter à corriger ça.
      
      Tu vas me dire « c'est pas leur rôle », toussa, le genre d'argument classique pour ne surtout pas chercher à améliorer la situation actuelle. Je ne pourrai qu'acquiescer en regrettant.
      - [^] # Re: Je comprends pas
        
        Posté par Zenitram (site web personnel) le 10 mai 2012 à 19:21. Évalué à 2.
        
        Et si ce timeout était de plusieurs jours/semaines par défaut, ça serait déjà moins problématique.
        
        Pourquoi? Comment tu fais pour gérer toutes tes connexions mortes qui te bouffent des ressources? Tu évites toujours de répondre à la question…
        
        Mais non, c'est fait pour killer les sessions très rapidement.
        
        Par défaut. Pour un problème de ressources.
        Et c'est configurable (miracle!)
        
        Ça te fait plaisir d'avoir des sessions ssh qui tombent régulièrement ? Pas moi.
        
        Tu peux expliquer cette partie : mes sessions SSH tombent uniquement quand je change d'@IP (toutes les 24h), le keep alive sert justement à ce que ta connexion ne coupe pas!
        
        Parce que les choix par défaut font que ça pourrit les utilisations « modernes » d'une pile TCP.
        
        En quoi ça pourrit la chose?
        
        Un truc que je ne comprend pas, c'est ce qui te dérange dans la conf par défaut, qui fonctionne très bien que ton réseau soit "pourri" ou pas.
        
        [^] # Re: Je comprends pas
        
        Posté par Zenitram (site web personnel) le 10 mai 2012 à 19:49. Évalué à 3.
        
        Tu peux expliquer cette partie : mes sessions SSH tombent uniquement quand je change d'@IP (toutes les 24h), le keep alive sert justement à ce que ta connexion ne coupe pas!
        
        Argh. J'avais oublié effectivement que tu veux pouvoir mettre en veille ta machine (et la : bam, ça coupe, effectivement).
        
        Mais : utilisation spéciale. Avec un serveur qui lui ne sait toujours pas si tu vas revenir. La valeur par défaut est toujours faite pour la majorité des admins qui ne veulent pas se faire chier avec un emmerdeur qui ne peut pas dire si il va revenir ou pas.
        
        Ce n'est pas la valeur par défaut qui est mauvaise, mais ton utilisation qui n'est pas classique.
        Deux solutions :
        - Tu as la main sur le serveur et tu assumes la charge en plus du fait de mettre un time out plus long.
        - Tu n'as pas la main et il y a des logiciels qui savent très bien faire (à coup de reco automatique + screen), pour peanuts en charge réseau par rapport à la charge serveur de gestion de connexions fantôme où personne ne reviendra car la machine a planté entre temps (ce n'est pas un problème réseau).
        
        Bref, tu vois ton petit centre et refuse de prendre en compte les autres, l'admin du serveur, lui, gère pour plus de monde que toi, avec des stats d'utilisation et des stats de connexions fantôme. Les gens ne mettent pas des valeurs par défaut juste pour te faire chier, mais pour un besoin "classique".
        
        [^] # Re: Je comprends pas
        
        Posté par Kerro le 11 mai 2012 à 00:21. Évalué à 3.
        
        La valeur par défaut est toujours faite pour la majorité des admins qui ne veulent pas se faire chier avec un emmerdeur qui ne peut pas dire si il va revenir ou pas.
        
        Je lance un truc qui va tourner 3 mois… merde j'ai rebooté mon portable 2 jours avant la fin. Il me faut tout relancer.
        
        Si l'emmerdeur en question est un poil malin, il utilise screen et c'est réglé.
        Il peut même se faire voler son portable, la session est toujours ok après 3 mois (si le serveur n'a pas rebooté, ce sont des choses qui arrivent).
        
        [^] # Re: Je comprends pas
        
        Posté par Psychofox (Mastodon) le 11 mai 2012 à 08:18. Évalué à 3.
        
        Si l'emmerdeur en question est un poil malin, il utilise tmux et c'est réglé.
        
        corrigé.
        
        [^] # Re: Je comprends pas
        
        Posté par Kerro le 11 mai 2012 à 13:05. Évalué à 2.
        
        Et zut, encore un truc à tester…
        
        Je viens de tester rapidos avec Debian.
        Je suis habitué à screen, et je l'utilise de manière très basique.
        La FAQ de tmux m'indique qu'à première vue les deux sont très équivalents pour mon usage modeste (pas besoin de le scripter par exemple).
        
        Tu préfères peut-être tmux, saurais-tu me dire pour quelle(s) raison(s) ?
        
        [^] # Re: Je comprends pas
        
        Posté par Frank-N-Furter le 12 mai 2012 à 13:40. Évalué à 5.
        
        http://me.veekun.com/blog/2012/03/21/tmux-is-sweet-as-heck/
        
        Depending on the time of day, the French go either way.
        
        [^] # Re: Je comprends pas
        
        Posté par benoar le 11 mai 2012 à 11:41. Évalué à -1.
        
        Tu as la main sur le serveur et tu assumes la charge en plus du fait de mettre un time out plus long.
        
        Ce coup de la « charge », je ne comprends vraiment pas. (cf mes autres commentaires)
        
        Et la charge réseau pour faire transiter tes keepalive ?
        Et, vu que tu as sûrement des firewall statefull pour devoir utiliser cette option, la charge en mémoire des firewall qui doivent garder l'association ? (qui doit être équivalente à la charge mémoire d'une session tcp sur ton host, minus le numéro de séquence et une ou deux autres conneries, peut-être, et ça sur tous les firewall entre tes machines)
        Et la charge de ton screen/tmux si tu veux garder tes sessions ?
        Et la charge « humaine » à devoir passer son temps à rétablir des sessions ssh ?
        
        Tu n'as pas la main et il y a des logiciels qui savent très bien faire (à coup de reco automatique + screen), pour peanuts en charge réseau par rapport à la charge serveur de gestion de connexions fantôme où personne ne reviendra car la machine a planté entre temps (ce n'est pas un problème réseau).
        
        Voilà, donc on a un système qui marchait bien, qu'on a pourri, et on trouve des workaround au-dessus pour palier le problème. Je sais que l'informatique est blindée de choses comme ça, et j'essaye de faire avec. C'est juste que des fois, ces workaround sont tellement foireux que ça m'énerve. D'où ce journal. Vu les commentaires, je ne suis pas prêt de faire changer les mentalités, mais sinon, oui, je m'adapte.
        
        Quant à l'histoire de quel est le plus lourd entre la charge réseau ou la charge serveur, je pense que c'est parce que tu ne fais pas beaucoup de réseau (c'est mon domaine, c'est peut-être pour ça qu'on a des avis divergents là-dessus). Je ne dis pas que c'est absolument plus lourd, je dis juste qu'il faut le prendre en compte. Et la « charge » des sessions fantômes, c'est comme la charge des screen que t'as oublié, en moins pire.
        
        Bref, tu vois ton petit centre et refuse de prendre en compte les autres, l'admin du serveur, lui, gère pour plus de monde que toi, avec des stats d'utilisation et des stats de connexions fantôme. Les gens ne mettent pas des valeurs par défaut juste pour te faire chier, mais pour un besoin "classique".
        
        Arrête ton char. L'admin du serveur il n'a aucune idée de la charge de ce genre de session : il a gardé l'option par défaut sans se poser la question, point. Je pourrai lui pourrir la machine de plein d'autres manières. Alors oui, c'est un besoin « classique », c'est plus pratique que d'essayer de faire que son réseau soit moins pourri, mais ça casse les pieds des gens qui aimeraient bien que des fois, l'informatique soit plus pratique pour eux.
        
        [^] # Re: Je comprends pas
        
        Posté par Zenitram (site web personnel) le 11 mai 2012 à 11:51. Évalué à 4.
        
        Vu les commentaires, je ne suis pas prêt de faire changer les mentalités,
        
        Ben… On ne peut pas dire que tu as de super arguments pour dire que ce que tu proposes (sic) est mieux. Au contraire.
        Mais sinon, le fait qu'on te dise "tous" la même chose, ça ne te remet pas en question? Juste les autres qui sont nuls.
        
        L'admin du serveur il n'a aucune idée de la charge de ce genre de session : il a gardé l'option par défaut sans se poser la question, point.
        
        Et ceux qui ont choisi l'option par défaut sont des gros nuls, c'est ça?
        
        c'est plus pratique que d'essayer de faire que son réseau soit moins pourri
        
        Tu ne m'as pas convaincu que ton réseau serait moins pourri à cause de keep alive qui ne transiterait pas (le pauvre réseau qui doit souffrir avec son keep alive…)
        
        mais ça casse les pieds des gens qui aimeraient bien que des fois, l'informatique soit plus pratique pour eux.
        
        Tu as des solutions pour faire ce que tu veux, donc tu peux!
        Perso, je comprend tout à fait que par défaut, on gère 99.9% des gens qui laisseraient des connexions fantôme de partout et que le 0.1% des gens qui veulent garder une conenxion longue utilise screen. C'est rentable vu la différence de pourcentage, c'est tout.
        A noter que SSH est très utilisée pour des taches automatisées, et garder un connexion morte pendant 30 jours à la place de 5 minutes peut foutre une bonne grosse charge si le script merde.
        
        Mais d'ailleurs, tu n'as pas réagi, je suis étonné : tu dis que tu ne veux pas de keep alive, mais accepte de te faire jeté au bout de 30 jours. Donc tu acceptes le principe en fait. Juste que la valeur par défaut ne te plait pas (mais elle a été choisie pas pour rien tu sais…)
        
        [^] # Re: Je comprends pas
        
        Posté par benoar le 11 mai 2012 à 14:13. Évalué à -2.
        
        Ben… On ne peut pas dire que tu as de super arguments pour dire que ce que tu proposes (sic) est mieux. Au contraire.
        
        Je trouve étrange qu'on ne trouve pas ça avantageux de pouvoir garder une session tcp longtemps. Et que les gens préfèrent des workaround pourris au dessus. Je pensais que c'était un argument convainquant.
        
        Mais sinon, le fait qu'on te dise "tous" la même chose, ça ne te remet pas en question? Juste les autres qui sont nuls.
        
        Si, je me pose des questions. Mais vu la manière dont tu écris tes phrases, ça ne me donne pas vraiment envie d'essayer d'argumenter plus : tu as déjà un avis complètement forgé, et on dirait que tu veux juste m'attaquer.
        
        Et ceux qui ont choisi l'option par défaut sont des gros nuls, c'est ça?
        
        Déjà répondu avant ; homme de paille.
        
        Tu ne m'as pas convaincu que ton réseau serait moins pourri à cause de keep alive qui ne transiterait pas (le pauvre réseau qui doit souffrir avec son keep alive…)
        
        Mhh… je ne comprends pas tout à fait cette remarque. J'ai déjà dit que normalement, on n'aurait pas besoin de keepalive dans un réseau « correct ».
        
        Perso, je comprend tout à fait que par défaut, on gère 99.9% des gens qui laisseraient des connexions fantôme de partout et que le 0.1% des gens qui veulent garder une conenxion longue utilise screen. C'est rentable vu la différence de pourcentage, c'est tout.
        
        Non, je ne pense pas que 99,9% des gens laisseraient des connexions fantômes. Il faut d'abord réfléchir à qu'est-ce qui provoque ces sessions fantômes ? Si c'est à cause de la trop grande présence d'état dans le réseau, qu'on peut corriger ça en arrêtant de faire du réseau n'importe comment. Le keepalive est une solution aux réseaux pourris, mais améliorer son réseau est aussi une solution, qui éviterait l'usage du keepalive.
        
        A noter que SSH est très utilisée pour des taches automatisées, et garder un connexion morte pendant 30 jours à la place de 5 minutes peut foutre une bonne grosse charge si le script merde.
        
        Mais je ne veux pas que tout le monde garde ses sessions tout le temps, bien sûr ! Quand tu fermes une connexion ssh comme il faut (99% du temps pour mon cas), tu ne laisses pas de connexion fantôme derrière toi ! Et c'est quoi « le script merde » ? Si ton processus est tué, la pile tcp va fermer la connexion pour toi. Le seul moyen qu'il garde la connexion, c'est que le programme reste actif. Et s'il reste actif, le keepalive ne changerait rien puisque justement, le programme continuerai de répondre à ses sollicitations !
        
        Mais d'ailleurs, tu n'as pas réagi, je suis étonné :
        
        Arrête de commencer tes remarques comme ça…
        
        tu dis que tu ne veux pas de keep alive, mais accepte de te faire jeté au bout de 30 jours. Donc tu acceptes le principe en fait. Juste que la valeur par défaut ne te plait pas (mais elle a été choisie pas pour rien tu sais…)
        
        Effectivement, on pourrait dire ça comme ça. Un keepalive de 30 jours m'irait. Mais ça n'est pas du tout la manière dont il a été pensé. Si tu veux, je critique le keepalive « tel qu'il est employé aujourd'hui ». Je ne vois pas en quoi ça change mes arguments, parce que tu utiliserais selon moi les même contre moi avec une telle durée.
        
        [^] # Re: Je comprends pas
        
        Posté par ckyl le 11 mai 2012 à 14:52. Évalué à 5.
        
        Mhh… je ne comprends pas tout à fait cette remarque. J'ai déjà dit que normalement, on n'aurait pas besoin de keepalive dans un réseau « correct ».
        
        Tu n'as pas l'air d'arriver à comprendre que la couche transport et la couche application ne sont pas la même chose. Entrée numéro 1 du Fallacies of Distributed Computing: The network is reliable.
        
        Le seul moyen qu'il garde la connexion, c'est que le programme reste actif. Et s'il reste actif, le keepalive ne changerait rien puisque justement, le programme continuerai de répondre à ses sollicitations !
        
        Non:
        - une machine qui crash
        - Un arrêt brutal
        - Un câble réseau débranché
        - Réinitialisation de la table d'état d'un firewall statefull et va tout dropper
        - Un laptop qui passe en veille et ne reprendra jamais l'IP qu'il avait
        - La liste peut être très longue
        
        Y'a la théorie et la pratique. C'est pour ca qu'on implémente des système qui au minimum survivent aux erreurs et au mieux supportent les pannes byzantines.
        
        [^] # Re: Je comprends pas
        
        Posté par benoar le 11 mai 2012 à 15:00. Évalué à -1.
        
        Tu n'as pas l'air d'arriver à comprendre que la couche transport et la couche application ne sont pas la même chose. Entrée numéro 1 du Fallacies of Distributed Computing: The network is reliable.
        
        Je suis d'accord qu'il y a un choix à faire sur où tu fais la persistance. Le choix de tcp me conforte dans le fait qu'on veut le faire à ce niveau, même si on abuse beaucoup de ce protocole aujourd'hui.
        
        Par contre, dire que comme le réseau n'est pas fiable ça va foirer est faux_ : justement, tcp est _fait pour supporter les pertes de paquets, et sans keepalive, on peut très bien s'accommoder de pertes temporaires de réseau. La connexion reprendra bien comme il faut quand le réseau aura été réparé.
        
        C'est étrange comme vous utilisez le keepalive comme un moyen de se parer des problèmes du réseau alors que justement, tcp est fait pour ça !
        
        Non:
        - une machine qui crash
        - Un arrêt brutal
        
        C'est les cas que j'ai cité. J'ose espérer qu'ils sont rares.
        
        Un câble réseau débranché
        
        TCP s'en accommodera très bien.
        
        Réinitialisation de la table d'état d'un firewall statefull et va tout dropper
        
        Un laptop qui passe en veille et ne reprendra jamais l'IP qu'il avait
        
        Ça c'est les signes d'un réseau pourri. C'est ici qu'il faudrait agir pour résoudre les problèmes. Alors après, bisounours, toussa, mais ça pourrait améliorer beaucoup de choses de régler ce genre de problème.
        
        Y'a la théorie et la pratique. C'est pour ca qu'on implémente des système qui au minimum survivent aux erreurs et au mieux supportent les pannes byzantines.
        
        Mais je suis tout à fait d'accord. Et ssh sans keepalive se démerde très bien comme ça !
        Après, si tu changes de réseau ou si un firewall statefull a merdé au milieu, ta session bloque, tu le remarques, tu coupes. Mais dans le premier cas c'est la faute de l'utilisateur, dans le deuxième c'est le signe d'un réseau pourri.
        
        [^] # Re: Je comprends pas
        
        Posté par Larry Cow le 11 mai 2012 à 11:59. Évalué à 4.
        
        Ce coup de la « charge », je ne comprends vraiment pas. (cf mes autres commentaires)
        
        Une connexion TCP - même "vide" - est une ressource limitée sur une machine, non?
        
        [^] # Re: Je comprends pas
        
        Posté par benoar le 11 mai 2012 à 12:05. Évalué à -1.
        
        La valeur par défaut est toujours faite pour la majorité des admins qui ne veulent pas se faire chier avec un emmerdeur qui ne peut pas dire si il va revenir ou pas.
        
        Ah oui, là-dessus : pourquoi tout de suite me traiter d'emmerdeur ? Je dis que je tue mes sessions qui sont mortes, mais de toutes façons, la très grande majorité du temps, vu que mes sessions survivent à des coupures réseau / veille / déplacement, je termine mes sessions proprement quand il faut !
        
        Alors forcément, si on commence d'abord par prendre les gens pour des cons, en se disant qu'ils ne vont jamais couper proprement leurs sessions et en mettant un keepalive, ça commence mal la relation avec son admin.
        
        [^] # Re: Je comprends pas
        
        Posté par Zenitram (site web personnel) le 11 mai 2012 à 12:30. Évalué à 5.
        
        Je dis que je tue mes sessions qui sont mortes,
        
        Tu n'es pas l'unique utilisateur. Difficile à comprendre?
        
        [^] # Re: Je comprends pas
        
        Posté par gnumdk (site web personnel) le 11 mai 2012 à 13:44. Évalué à 7.
        
        Désolé, mais moi, ca m'arrive de débrancher le cable réseau puis de fermer les 10 onglets de mon terminal… Donc, pas envie de laisser des connexions fantomes tous les jours sur mes serveurs…
        
        C'est juste logique…
        
        [^] # Re: Je comprends pas
        
        Posté par benoar le 11 mai 2012 à 14:50. Évalué à -3.
        
        Désolé, mais moi, ca m'arrive de débrancher le cable réseau puis de fermer les 10 onglets de mon terminal… Donc, pas envie de laisser des connexions fantomes tous les jours sur mes serveurs…
        
        Est-ce que l'ordre des étapes est volontaire ou non ? Si ça l'est, tu pourrais peut-être en changer ? Si tu fermes tes 10 onglets, même à la barbare, et que ton câble est branché, pas de problème, elles seront bien fermées.
        
        Si ça ne l'est pas… Je trouve que c'est une utilisation étrange. Par exemple, pourquoi dois-tu fermer tous tes onglets ? Tu rebootes souvent ta machine ? Je trouve ça tellement peu pratique… (et je ne dois pas être le seul, la veille est l'option par défaut dans Gnome 3… bon OK, je sens que je n'ai pas choisi le bon argument…)
        
        C'est juste logique…
        
        Bah, je ne trouve pas. À priori, je suis plutôt minoritaire sur ce thread, mais j'espère que les utilisations pourront évoluer. Je pense que le choix historique de TCP est dû au fait qu'à l'époque, les machines étaient tout le temps connectées, et allumées, et qu'on n'éteignait rarement une machine à l'arrache. Certes, ça a évolué, mais ça ne me paraît pas aberrant aujourd'hui que la gestion de l'état des connexions tcp soit « persistante » à travers l'utilisation de la mise en veille, par exemple.
        
        [^] # Re: Je comprends pas
        
        Posté par Larry Cow le 11 mai 2012 à 15:12. Évalué à 4.
        
        Est-ce que l'ordre des étapes est volontaire ou non ?
        
        Si tu remplaces "câble" par "réseau sans fil", il se pourrait bien que ce ne soit pas spécialement volontaire. Si?
      - [^] # Re: Je comprends pas
        
        Posté par ckyl le 10 mai 2012 à 19:45. Évalué à 3.
        
        Le hearbeat applicatif a exactement le même but que le keepalive tcp.
        
        Dans l'idée oui. Maintenant le keepalive tcp ca sert absolument à rien tellement c'est pas configurable et adaptable aux besoins applicatifs. Donc tu te fais un truc qui marche et qui correspond exactement aux besoins de ton protocole. Ça part de ne rien faire du tout, jusqu'à faire des heartbeat bidirectionnels très agressifs dès que tu as un trou de trafic pour détecter tout problème dans la seconde.
# Pourquoi ?

Posté par madhatter (site web personnel) le 10 mai 2012 à 18:47. Évalué à 2.

Salut,

j'ai bien compris ta démarche sur le fait que TCP est prévu pour des connexions longues durées, mais je me demande tout simplement pourquoi tu souhaites garder une (ou plusieurs) connexions ssh actives (mais sans nécessairement de trafic) pendant plusieurs jours ?

There is no spoon...
- [^] # Re: Pourquoi ?
  
  Posté par allcolor (site web personnel) le 10 mai 2012 à 19:33. Évalué à 4. Dernière modification le 10 mai 2012 à 19:33.
  
  connexions ssh actives (mais sans nécessairement de trafic) pendant plusieurs jours ?
  
  Il perd 5 seconde à chaque fois, sa vie étant d'un temps limité, l'accumulation de ces 5 secondes d'attentes lui enlève en fin de vie 2 ans et demi de fun avec les zamis.
- [^] # Re: Pourquoi ?
  
  Posté par Sylvain Decremps le 10 mai 2012 à 19:44. Évalué à 4.
  
  Je suis assez d'accord. Pour moi une connexion ssh sert le temps de taches ponctuelles : transfert de fichiers, etapes d'administration
  
  Et quand on sait que screen (ou autre clone) te permet de garder une consistence dans ce que tu effectues si dans l'intervalle tu t'es fais surprendre par le chat qui grignote le cable reseau ou ta machine qui part en veille comme elle aime si bien le faire.
  
  Donc je ne comprends pas ton soucis, meme si effectivement c'est toujours mieux de vivre dans un monde qui nous permet de faire telle ou telle chose (peut etre une idee d'ajout, enfin si tu veux t'y coller ;)
  
  Pour ma part je reste conscient que openSSH a ete fait a une epoque (bien plus 10 ans) ou les reseaux n'etaient pas aussi "propres" que maintenant.
  - [^] # Re: Pourquoi ?
    
    Posté par benoar le 11 mai 2012 à 11:54. Évalué à -1.
    
    Je suis assez d'accord. Pour moi une connexion ssh sert le temps de taches ponctuelles : transfert de fichiers, etapes d'administration
    
    C'est intéressant : pour moi, c'est plus que ça. Je pense que c'est de là que viennent pas mal des divergences avec les commentateurs de ce journal.
    
    Les étapes d'administrations, ça n'est peut-être effectivement pas censé durer des heures, mais je bosse dans la recherche : j'expérimente pas mal de trucs, et j'ai souvent des sessions qui durent longtemps, et je fais d'autres trucs à côté, etc. TCP m'offre la possibilité de garder mes sessions longtemps, pourquoi ne pas en profiter ?
    
    Et quand on sait que screen (ou autre clone) te permet de garder une consistence dans ce que tu effectues si dans l'intervalle tu t'es fais surprendre par le chat qui grignote le cable reseau ou ta machine qui part en veille comme elle aime si bien le faire.
    
    Alors oui, il y a des workaround, mais pour moi, ne pas casser le mécanisme « de base » en premier lieu est toujours préférable. Quant à la mise en veille, c'est volontaire, comme lorsque je me balade avec le laptop pour revenir plus tard récupérer mes sessions.
    
    Donc je ne comprends pas ton soucis, meme si effectivement c'est toujours mieux de vivre dans un monde qui nous permet de faire telle ou telle chose (peut etre une idee d'ajout, enfin si tu veux t'y coller ;)
    
    Oui, voilà, j'aime bien que quand quelque chose a été prévu pour accommoder tout un tas d'utilisations différentes, on ne vienne pas au-dessus limiter artificiellement et par défaut ces possibilités. Et il n'y a rien à ajouter : c'est comme ça de base, c'est le keepalive qui a été rajouté après !
    
    Pour ma part je reste conscient que openSSH a ete fait a une epoque (bien plus 10 ans) ou les reseaux n'etaient pas aussi "propres" que maintenant.
    
    Heu… Je dirais que c'est plutôt l'inverse ! Il a été fait à une époque où les réseaux étaient beaucoup moins filtrés, et où les réseau conservaient beaucoup moins d'état ! (NAT, firewall statefull, …)
- [^] # Cas d'usage
  
  Posté par benoar le 11 mai 2012 à 11:20. Évalué à 2.
  
  OK, j'ai l'impression que pas beaucoup de monde comprend comment j'utilise ssh, alors je vais montrer des exemples.
  
  Au taf, j'ai un laptop, branché en ethernet. Ça consomme pas trop d'énergie, ça se met bien en veille quand on n'est pas dessus, et ça se transporte facilement. Depuis mon bureau, je vais faire des ssh à droite à gauche sur différentes machines. Parfois, je dois partir ; des fois, je le laisse allumé, des fois, je le met en veille. J'avais peut-être à ce moment-là un vim lancé dans un ssh quelque part, ou tout autre genre de session. J'aime bien le retrouver quand je reviens.
  
  Parfois, je suis en train de faire un truc en ssh, j'utilise peut-être même une machine comme rebond, j'ai l'historique de mes commandes dans mon shell, bref, j'ai un certain « contexte » de mes sessions. Mais je dois aller en réunion ; hop, je ferme le laptop (qui se met en veille), je vais dans la salle de réunion, là je me connecte en wifi pour faire mes trucs de réunion (je ne touche pas aux sessions ssh), le réseau wifi est adressé différemment mais c'est pas grave, et quand je reviens à mon bureau, je peux reprendre tranquille mes sessions ssh.
  
  Dans d'autres cas, je commence à bosser sur un serveur, mais je laisse la session de côté parce que je suis amené à faire autre chose, pendant plusieurs jours. Je reviens après, j'ai tout mon contexte, encore une fois.
  
  Après, on va me dire qu'il faut utiliser screen/tmux : OK, mais alors cette excuse de soit-disant « bouffer des ressources » avec mes sessions, c'est exactement pareil, voire moins pire, que de les garder avec un soft comme screen ! Je ne comprends pas du tout la critique. Mais c'est le classique « pourquoi ne pas réinventer ce qui existe déjà sur des couches supérieures, c'est tellement plus fun » ! On commence par casser un principe qui marche bien (la persistance des sessions tcp) pour le réimplémenter en plus chiant (il faut se reconnecter) au-dessus. En plus, j'utilise déjà tmux en local, et ça s'emboîte assez mal (si quelqu'un a une solution pour ça, je suis preneur ; je connais celle de binder une touche pour envoyer le préfixe au tmux dans le ssh, mais ça fait étrange, je trouve).
  
  Bref, je pense que les gens ne comprennent pas mon problème parce qu'ils ont tellement l'habitude de tout recommencer (rebooter la machine, redémarrer les sessions ssh) que c'est devenu « naturel » pour eux, alors qu'avec un peu de bon sens et quelques efforts pour corriger les lacunes actuelles dans les OS/réseaux, ça pourrait aller vachement mieux. Bon, oui, ça n'est pas un si petit effort que ça, mais il faut toujours continuer à améliorer les choses, non ?
  - [^] # Re: Cas d'usage
    
    Posté par Zenitram (site web personnel) le 11 mai 2012 à 11:57. Évalué à 4.
    
    Je ne comprends pas du tout la critique.
    
    Elle n'est pourtant pas compliquée : Pour te faire plaisir, on va garder en stock des milliers de connexions fantômes de gens qui ne font pas comme toi. Ben non. Pas rentable. Question de calculs statistiques.
    
    Donc :
    - Ceux qui s'en foutent vont se faire couper au bout de x minutes. La majorité
    - Ceux qui veulent du persistant peuvent. Ils sont rares, donc la charge de screen va.
    
    alors qu'avec un peu de bon sens et quelques efforts pour corriger les lacunes actuelles dans les OS/réseaux,
    
    Propose une solution géniale alors.
    Tu n'en a pas proposé. La solution que tu proposes ne tient pas compte de plein de contraintes, juste de ton confort personnel. L'admin du serveur te dit juste "va te faire voir, j'ai d'autres priorité que ton confort".
    
    Bon, oui, ça n'est pas un si petit effort que ça, mais il faut toujours continuer à améliorer les choses, non ?
    
    Propose une vraie amélioration, et pas un paramètrage de time out (passer de 5 minutes à 30 jours?) qui a été choisie pour certaines raisons qui sont toujours la.
# ssh vraiment adapté aux réseaux moisis?

Posté par Guillaume Knispel le 10 mai 2012 à 21:24. Évalué à 2.

De mon côté j'ai l'impression que OpenSSH n'est pas du tout adapté aux réseaux moisis. Si je me souviens bien il inclut un contrôle de flux perso qui interagit très très mal avec TCP lorsqu'on a un paquet loss à partir de quelques pourcents, rendant la connexion totalement inutilisable en pratique très rapidement.
- [^] # Re: ssh vraiment adapté aux réseaux moisis?
  
  Posté par Zenitram (site web personnel) le 10 mai 2012 à 22:05. Évalué à 5. Dernière modification le 10 mai 2012 à 22:05.
  
  euh… Vu que c'est TCP qui gère le paquet loss, que vient faire OpenSSH dans l'histoire? A ma connaissance, c'est tout l’intérêt de TCP de ne perdre aucun paquet (demande de ré-émission si perte IP)
  - [^] # Re: ssh vraiment adapté aux réseaux moisis?
    
    Posté par ckyl le 10 mai 2012 à 22:39. Évalué à 4.
    
    Il est assez facile de designer un protocole ne prenant pas en compte la couche du dessous et de faire un truc qui rame plus qu'il ne devrait (hello HTTP !). Un exemple très simple est de tunneler du TCP dans du TCP. La gestion de congestion de TCP ayant été entièrement conçue en utilisant la perte de paquet, ça donne des résultats bien pourri par ce que la connexion tunnelée ne voit jamais de perte de paquet puisqu'elle est elle même dans un flux TCP. Tiens on peut ca avec SSH d'ailleurs ! Après je connais pas les détails sur ce sujet. Le fait de multiplexer plusieurs chanels dans une seule connexion TCP comme le fait SSH peut aussi poser des problèmes quand il y a des pertes de paquets, à chaque paquet perdu TCP prend ca pour une congestion et ralenti; tout les chanels multiplexés sont ralenti.
    
    Un autre exemple concret avec SSH c'est qu'il effectue son propre flow control. Celui ci étant assez simpliste il bride complètement TCP (qu'on doit déjà configurer) sur des "long fat pipes", des liens au produit Bandwidth-delay élevé). Cf. http://www.psc.edu/networking/projects/hpn-ssh/
    
    Bref c'est pas impossible, mais dans ce cas c'est intéressant d'avoir les références :p
    - [^] # Re: ssh vraiment adapté aux réseaux moisis?
      
      Posté par FReEDoM (site web personnel) le 11 mai 2012 à 02:29. Évalué à 2.
      
      Pour les liens à haut produit bandwidth-délay on peut soit configurer la pile TCP de l'OS, soit utiliser des PEP en coupure sur la liaison.
      
      Au passage également, il y a de grosses restrictions sur les derniers OS microsoftiens depuis Vista sur les possibilités de parametrages du TCP (très accessibles pour tous les autres OS dignes de ce nom).
# Screen

Posté par Michaël (site web personnel) le 11 mai 2012 à 07:44. Évalué à 2. Dernière modification le 11 mai 2012 à 07:45.

cette option m'emmerde plus qu'autre chose : je ne peux pas garder des sessions ssh en « sommeil » quand je vais bouger de réseau mais revenir plus tard dans celui de départ, ni mettre ma machine en veille et espérer que la session tienne encore après.

Si tu as accés à une machine qui es toujours up, tu peux t'en servir comme proxy de connection. Au lieu d'ouvrir une connection host → server tu ouvres une session host → connection-proxy puis tu ouvres un screen(1) d'où tu ouvres ta connection connection-proxy → server.

Ainsi tu peux détacher ton screen et terminer ta connection au connection-proxy tandis que la connection connection-proxy → server reste en vie, autant que les configurations le permette.

Au fait, l'utilisation de screen(1) sur server ne fournirait-elle pas une solution acceptable à ton problème — ou bien c'est l'existence même de la connection qui est importante dans ton problème?
- [^] # Re: Screen
  
  Posté par benoar le 11 mai 2012 à 11:57. Évalué à 1.
  
  Au fait, l'utilisation de screen(1) sur server ne fournirait-elle pas une solution acceptable à ton problème — ou bien c'est l'existence même de la connection qui est importante dans ton problème?
  
  C'est une alternative, mais pour moi ça n'est pas pratique : il faut remonter une session, avoir une machine dédiée pour ça, etc. J'aurais aimé (dans mes rêves, toussa) que ça marche bien de base, comme c'est prévu.
  - [^] # Re: Screen
    
    Posté par Zenitram (site web personnel) le 11 mai 2012 à 12:32. Évalué à 1.
    
    il faut remonter une session
    
    Tu es doué pour tuer des sessions fantomes, tu ne vas pas me dire que tu ne sais pas remonter automatiquement?
    
    avoir une machine dédiée pour ça,
    
    Chez moi, screen tourne sur le serveur visé, pas besoin de machine intermédiaire dédiée. Comprend pas le problème.
  - [^] # Re: Screen
    
    Posté par Raoul Volfoni (site web personnel) le 11 mai 2012 à 12:36. Évalué à 4.
    
    avoir une machine dédiée pour ça
    
    Que veux-tu dire ? J'ai lu tes autres commentaires et franchement je ne vois pas ce que tu peux reprocher à un outil comme screen. Pour moi l'avantage c'est que justement je n'ai pas de machine dédiée et que même si j'ai oublié de couper ma connection depuis une machine je peux forcer une autre à reprendre la main sur ma session (screen -rd).
    Mais une machine dédiée, là je ne vois vraiment pas désolé.
    - [^] # Re: Screen
      
      Posté par benoar le 11 mai 2012 à 14:30. Évalué à -5.
      
      J'ai lu tes autres commentaires
      
      Comme Zenitram juste au-dessus, tu n'as pas lu le commentaire auquel je réponds. En fait j'en ai marre de discuter avec des gens qui lisent le thread de travers.
      - [^] # Re: Screen
        
        Posté par Raoul Volfoni (site web personnel) le 11 mai 2012 à 15:24. Évalué à 5.
        
        Franchement je suis resté très correct avec toi jusqu'ici mais la vérité m'obliges à te le dire: tu commences à nous les briser menu !!!
        Demandes à ton admin de monter le MaxSessions à 10000 (il est à 10 par défaut t'es au courant?) ou de mettre ton keepalive dans un Match User mais arrêtes un peu de geindre à propos d'un des tous meilleurs outils libres du moment qui permet de faire exactement ce dont tu te plains depuis des heures.
        
        [^] # Re: Screen
        
        Posté par benoar le 11 mai 2012 à 15:35. Évalué à -1.
        
        Franchement je suis resté très correct avec toi jusqu'ici mais la vérité m'obliges à te le dire: tu commences à nous les briser menu !!!
        
        Hein ? On me prend de haut, j'essaye d'argumenter calmement, je te dis quand tu es à côté de la plaque (relis le commentaire auquel je réponds !), et ça n'est pas correct ?
        
        Demandes à ton admin de monter le MaxSessions à 10000 (il est à 10 par défaut t'es au courant?)
        
        Ça n'est pas le problème. Je n'ai jamais parlé d'exhaustion de session.
        
        ou de mettre ton keepalive dans un Match User
        
        Ça serait bien en effet.
        
        mais arrêtes un peu de geindre à propos d'un des tous meilleurs outils libres du moment qui permet de faire exactement ce dont tu te plains depuis des heures.
        
        Alors, ssh est un très bon outil, et j'en conviens totalement, mais je ne devrais surtout pas le critiquer ?…
        
        [^] # Re: Screen
        
        Posté par Raoul Volfoni (site web personnel) le 11 mai 2012 à 15:46. Évalué à 2.
        
        Hein ? On me prend de haut,
        
        Non pas moi, jamais. Relis tout le journal, 10 fois s'il le faut… Et puis reviens t'excuser ensuite.
        
        je te dis quand tu es à côté de la plaque (relis le commentaire auquel je réponds !), et ça n'est pas correct ?
        
        Pardon ? Tu veux faire un concours de mauvaise foi ou quoi ? On te dis que t'as pas besoin de machine dédiée pour utiliser screen contrairement à ce que tu as écris et tu nous dis qu'on est à coté de la plaque ? Dis t'as bien pris tes pilules ou quoi ?
        
        mais je ne devrais surtout pas le critiquer ?
        
        Je n'ai ABSOLUMENT pas vu la moindre critique constructive venant de ta part dans ce journal. Par contre si tu crois encore qu'il existe des admins qui mettent en route sshd sans avoir modifié son fichier de config et ses options par défaut alors tu as besoin d'encore pas mal d'expérience.
        
        [^] # Re: Screen
        
        Posté par benoar le 11 mai 2012 à 16:05. Évalué à -1.
        
        Non pas moi, jamais. Relis tout le journal, 10 fois s'il le faut… Et puis reviens t'excuser ensuite.
        
        Alors, je n'avais effectivement pas vu ce comportement de ta part jusqu'à ce message (« me les briser ») qui m'a passablement énervé, vu le ton, alors j'ai utilisé le « on » sans discerner ; excuse-moi pour ça. Mais…
        
        Pardon ? Tu veux faire un concours de mauvaise foi ou quoi ? On te dis que t'as pas besoin de machine dédiée pour utiliser screen contrairement à ce que tu as écris et tu nous dis qu'on est à coté de la plaque ? Dis t'as bien pris tes pilules ou quoi ?
        
        Je ne sais pas combien de fois il faut que tu relises le message de Michaël, à l'origine de ma réponse, pour que tu comprennes. Que tu insistes sans chercher à comprendre me fait dire que tu as une idée toute faite sur mon cas et que ça ne sert à rien de continuer.
        
        Je n'ai ABSOLUMENT pas vu la moindre critique constructive venant de ta part dans ce journal.
        
        Ah bah forcément, on ne doit vraiment pas se comprendre alors.
        
        [^] # Re: Screen
        
        Posté par allcolor (site web personnel) le 11 mai 2012 à 16:22. Évalué à 3. Dernière modification le 11 mai 2012 à 16:22.
        
        il faut que tu relises le message de Michaël, à l'origine de ma réponse
        
        On a bien lu le message de Michaël, mais ce qu'on comprends pas c'est l'intérêt d'un screen sur une machine proxy qui garde up une connexion ssh du proxy vers le serveur au lieu d'un screen directement sur le serveur… donc du coup argumenter pour dire non pas screen car j'ai pas de machine qui peut me servir de proxy est ridicule.
        
        Utilises screen sur le serveur directement et yabasta problème résolu, ton screen il restera sur le serveur et tu auras tous les progs que tu as lancé dedans, tu pourras récupérer cette session screen de n'importe où. Alors à part être un chieur de base, je vois pas ce qui t'en empêche… oui dans le meilleur des mondes, ta connexion ne couperait pas… mais ici c'est pas le meilleur des mondes, c'est le vrai monde et dans le vrai monde, y a screen et c'est caisse.
        
        [^] # Re: Screen
        
        Posté par benoar le 11 mai 2012 à 18:45. Évalué à -1.
        
        ce qu'on comprends pas c'est l'intérêt d'un screen sur une machine proxy qui garde up une connexion ssh du proxy vers le serveur au lieu d'un screen directement sur le serveur… donc du coup argumenter pour dire non pas screen car j'ai pas de machine qui peut me servir de proxy est ridicule.
        
        Je n'utilise pas cet argument pour dire pas screen, c'est encore une incompréhension. J'ai trouvé cette solution non idéale, point, ce thread parlait de ça uniquement.
        
        Utilises screen sur le serveur directement et yabasta problème résolu
        
        En ce qui concerne cette utilisation, j'ai déjà répondu plus haut que ça n'était pas une utilisation optimale pour moi.
        
        oui dans le meilleur des mondes, ta connexion ne couperait pas… mais ici c'est pas le meilleur des mondes, c'est le vrai monde et dans le vrai monde, y a screen et c'est caisse.
        
        Le but de ce journal est justement de discuter de comment faire pour y tendre, vers ce monde meilleur. Car je pense que cette option de keepalive n'est pas si bonne qu'elle en a l'air.
        
        J'espère que c'est plus clair.
        
        [^] # Re: Screen
        
        Posté par allcolor (site web personnel) le 11 mai 2012 à 18:58. Évalué à 1.
        
        En ce qui concerne cette utilisation, j'ai déjà répondu plus haut que ça n'était pas une utilisation optimale pour moi.
        
        Tu peux pointer le commentaire ? En quoi ça te convient pas ? C'est mieux que tes longues sessions ssh… Tu peux récupérer ta session de partout au lieu de juste ton laptop avec lequel tu es partis.
        
        [^] # Re: Screen
        
        Posté par benoar le 11 mai 2012 à 19:11. Évalué à 1.
        
        Tu peux pointer le commentaire ? En quoi ça te convient pas ?
        
        https://linuxfr.org/nodes/94082/comments/1349431
        https://linuxfr.org/nodes/94082/comments/1349403
        
        C'est mieux que tes longues sessions ssh… Tu peux récupérer ta session de partout au lieu de juste ton laptop avec lequel tu es partis.
        
        Effectivement, c'est un avantage de screen/tmux. Mais personnellement, je n'ai, dans mon cas, qu'une machine, que j'utilise tout le temps. J'ai rarement besoin de ce cas d'usage. Comme quoi, on a tous des usages différents.
        
        [^] # Re: Screen
        
        Posté par allcolor (site web personnel) le 11 mai 2012 à 20:05. Évalué à 3. Dernière modification le 11 mai 2012 à 20:06.
        
        Commentaire 1:
        
        Alors oui, il y a des workaround, mais pour moi, ne pas casser le mécanisme « de base » en premier lieu
        
        C'est pas un argument comme quoi ça te convient pas, c'est du poildecutage de chieur, ça fait ce dont tu as besoin ici et maintenant.
        
        Commentaire 2:
        
        OK, mais alors cette excuse de soit-disant « bouffer des ressources » avec mes sessions, c'est exactement pareil, voire moins pire, que de les garder avec un soft comme screen !
        
        Ce n'est toujours pas un argument comme quoi ça te convient pas… ça fait ce que tu veux ici et maintenant.
        
        Tu râles pour un truc qui n'existe pas dans le vrai monde, dans la réalité ce que tu veux n'est possible que si tu contrôles tout… tu ne contrôles pas tout, donc arrêtes de râler… le meilleur des mondes tu l'auras pas aujourd'hui ni demain (si tant est qu'avoir une connexion ssh qui ne coupe pas après deux semaines d'avoir laissé son laptop en veille ai un quelconque intérêt et serais un monde meilleur).
        
        [^] # Re: Screen
        
        Posté par Zenitram (site web personnel) le 12 mai 2012 à 11:13. Évalué à 2. Dernière modification le 12 mai 2012 à 11:14.
        
        Comme quoi, on a tous des usages différents.
        
        Comme tu dis. Mais tu proposes une "amélioration" qui ne répond qu'à ton usage, et fou la merde pour les autres usages.
        Fail.
        
        [^] # Re: Screen
        
        Posté par Michaël (site web personnel) le 12 mai 2012 à 11:31. Évalué à 2.
        
        On a bien lu le message de Michaël, mais ce qu'on comprends pas c'est l'intérêt d'un screen sur une machine proxy qui garde up une connexion ssh du proxy vers le serveur au lieu d'un screen directement sur le serveur… donc du coup argumenter pour dire non pas screen car j'ai pas de machine qui peut me servir de proxy est ridicule.
        
        Je n'ai jamais dit connection_proxy ≠ server :P blague à part, je me demande aussi ce qui m'est passé par la tête en écrivant ça, c'était viteuf avant d'aller travailler je crois…
        
        [^] # Re: Screen
        
        Posté par Raoul Volfoni (site web personnel) le 11 mai 2012 à 16:30. Évalué à 5.
        
        (« me les briser »)
        
        J'avais dit 'menu' mais il s'agissait d'une référence à un film en N&B qui n'est visiblement pas connu de ta génération…
        
        me fait dire que tu as une idée toute faite sur mon cas et que ça ne sert à rien de continuer.
        
        Mon expérience m'a permis d'apprendre à ne pas avoir d'idée préconçue. Mais concernant 'ton cas' je dois quand même bien admettre que tu as tout fait pour aggraver le diagnostic initial.
        Aller tciao, j'ai une vie moi.
        
        [^] # Re: Screen
        
        Posté par madhatter (site web personnel) le 12 mai 2012 à 18:57. Évalué à 2.
        
        Je m'insurge !
        
        Comment ça "de ta génération" ? Je suis probablement de sa génération et en tout cas pas de celle de ce film que je connais pourtant très bien (faut dire, on touche au cultissime quand même).
        
        Retire-ça vite fait, parce que je te préviens, moi quand on m'en fait trop, j'correctionne plus. J'dynamite, j'disperse. J'ventile.
        
        ;)
        
        There is no spoon...
        
        [^] # Re: Screen
        
        Posté par Raoul Volfoni (site web personnel) le 13 mai 2012 à 00:55. Évalué à 3.
        
        Ah ben tu me rassures, j'avais peur que les Volfoni's brothers aient passé l'arme à gauche. ;)
        
        [^] # Re: Screen
        
        Posté par gnumdk (site web personnel) le 11 mai 2012 à 15:49. Évalué à 2. Dernière modification le 11 mai 2012 à 15:50.
        
        Tu vas faire des bons, mais sur beaucoup de serveurs un peu sécurisés, y'a une variable en read only qui s'appelle TMOUT et qui dit que au bout de n minutes, toute session inactive est tuée…
        
        [^] # Re: Screen
        
        Posté par allcolor (site web personnel) le 11 mai 2012 à 15:49. Évalué à 2.
        
        Alors, ssh est un très bon outil, et j'en conviens totalement, mais je ne devrais surtout pas le critiquer ?…
        
        Il te parle de screen ou tmux.
        
        [^] # Re: Screen
        
        Posté par gnumdk (site web personnel) le 11 mai 2012 à 15:43. Évalué à 3.
        
        Non, mais ca fait 50 commentaires qu'il essaye de convaincre tout le monde que ca façon de travailler est la meilleur parce que monsieur à un workflow adapté au keepalive…
        
        Mais bon, l'important, c'est bien sur que le comportement par défaut actuel est adapté à la majorité, pas à ses besoins.
# Merci

Posté par Anthony Jaguenaud le 11 mai 2012 à 22:37. Évalué à 3.

Grâce à toi j’ai appris un truc aujourd’hui. C’est que le keepalive est une option moi qui croyait que c’était de base.

Sinon, je rejoins les autres pour dire utilise screen ou tmux.

Je sais, il existe une implementation possible de ce que tu as besoin. Mais elle n’est pas utilisée. Alors essaye d’être pragmatique.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.