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.
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.
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.
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.
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.
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.
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.
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 »
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.
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, …)
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.
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.
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 ?
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.
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.
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.
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.
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)
-> 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.
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.
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.
Elle vaut surtout le coup !
Wow, franchement, merci pour ce lien, je conseille à tout le monde d'aller voir cette présentation, elle est assez géniale.
Oui mais bon, malheureusement, tu rêves un peu trop.
Et tu as mélangé deux choses : la mobilité IPv6 et le multihoming dans SCTP, qui ont en gros le même but et font la même chose, mais à des niveaux différents. Bref, on aurait eu soit l'un, soit l'autre, ça aurait été, mais on n'en a finalement aucun des deux.
[^] # Re: Je comprends pas
Posté par benoar . En réponse au journal Le TCP keepalive m'a tué. Évalué à -4.
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 bien si ! Il peu y avoir plein de programmes qui tournent. Juste, ils n'envoient pas de données à l'autre bout.
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: Screen
Posté par benoar . En réponse au journal Le TCP keepalive m'a tué. Évalué à -5.
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: man ssh
Posté par benoar . En réponse au journal Le TCP keepalive m'a tué. É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 benoar . En réponse au journal Le TCP keepalive m'a tué. Évalué à 0.
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.
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.
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.
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.
Ça pourrait être une discussion constructive en effet. Ici, c'était un peu un test. Ça n'est pas très concluant.
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: Je comprends pas
Posté par benoar . En réponse au journal Le TCP keepalive m'a tué. Évalué à -2.
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.
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.
Déjà répondu avant ; homme de paille.
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 ».
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.
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 !
Arrête de commencer tes remarques comme ça…
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 benoar . En réponse au journal Le TCP keepalive m'a tué. Évalué à -4.
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.
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.
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.
Ah, un argument massue. Bravo, tu fais bien avancer le débat.
[^] # Re: Je comprends pas
Posté par benoar . En réponse au journal Le TCP keepalive m'a tué. Évalué à -1.
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: man ssh
Posté par benoar . En réponse au journal Le TCP keepalive m'a tué. Évalué à -6.
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: Screen
Posté par benoar . En réponse au journal Le TCP keepalive m'a tué. Évalué à 1.
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: Pourquoi ?
Posté par benoar . En réponse au journal Le TCP keepalive m'a tué. Évalué à -1.
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 ?
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.
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 !
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, …)
[^] # Re: Je comprends pas
Posté par benoar . En réponse au journal Le TCP keepalive m'a tué. Évalué à -1.
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 ?
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.
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 benoar . En réponse au journal Le TCP keepalive m'a tué. Évalué à -1.
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.
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 ?!!
Moi, je n'ai pas de retour visuel quand une connexion déconne. Ça me fait chier.
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 »
Je n'ai pas la main sur tous les serveurs.
[^] # Cas d'usage
Posté par benoar . En réponse au journal Le TCP keepalive m'a tué. É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: Je comprends pas
Posté par benoar . En réponse au journal Le TCP keepalive m'a tué. Évalué à -1.
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.
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.
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.
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).
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 benoar . En réponse au journal Le TCP keepalive m'a tué. Évalué à 0.
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 !
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 !
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: man ssh
Posté par benoar . En réponse au journal Le TCP keepalive m'a tué. Évalué à 0.
Il ne peut pas le savoir.
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.
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: Euh
Posté par benoar . En réponse au journal Le TCP keepalive m'a tué. Évalué à 3.
Exactement, merci de l'éclaircissement.
[^] # Re: Euh
Posté par benoar . En réponse au journal Le TCP keepalive m'a tué. Évalué à 1.
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.
Ç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.
[^] # Re: Je comprends pas
Posté par benoar . En réponse au journal Le TCP keepalive m'a tué. É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: man ssh
Posté par benoar . En réponse au journal Le TCP keepalive m'a tué. Évalué à 0.
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 benoar . En réponse au journal Le TCP keepalive m'a tué. Évalué à 1.
OK, je pense que vous deux n'avez pas compris le problème. J'en suis quasiment sûr quand je lis :
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 benoar . En réponse au journal Le TCP keepalive m'a tué. É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: Encore un relou qui ne sera jamais content
Posté par benoar . En réponse à la dépêche GIMP 2.8 est sorti : une fenêtre unique !. Évalué à 3.
Elle vaut surtout le coup !
Wow, franchement, merci pour ce lien, je conseille à tout le monde d'aller voir cette présentation, elle est assez géniale.
[^] # Re: Le lien pour Microsoft®…
Posté par benoar . En réponse à la dépêche Petites brêves : ODF et Cassandra. Évalué à 1.
Je n'arrive pas non plus à lire ce qu'il y a écrit. Pour un premier test d'inter-opérabilité, c'est raté…
[^] # Re: Mobile IP
Posté par benoar . En réponse à la dépêche Mosh, the Mobile Shell. Évalué à 5.
Oui mais bon, malheureusement, tu rêves un peu trop.
Et tu as mélangé deux choses : la mobilité IPv6 et le multihoming dans SCTP, qui ont en gros le même but et font la même chose, mais à des niveaux différents. Bref, on aurait eu soit l'un, soit l'autre, ça aurait été, mais on n'en a finalement aucun des deux.