benoar a écrit 4244 commentaires

• 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.

Je n'ai pas la main sur tous les serveurs.

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.

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.

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.

un présentation qui vaut le cout : http://vimeo.com/36579366

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.

Je n'arrive pas non plus à lire ce qu'il y a écrit. Pour un premier test d'inter-opérabilité, c'est raté…

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.

à force d'aider 'parfois' les autres, j'en oublie que moi aussi je peux demander de l'aide.

Héhé ;-)

Ma question porte sur ces disques qui serviront de base à du raid, mais lequel ?

• logiciel avec mdadm ou
• materiel (fakeraid) sur une carte HP SmartArray B110i

Effectivement, cette B110i c'est du basique, fakeraid : laisse tomber, fait du RAID avec mdadm. Aucun avantage à l'utiliser. (c'est con mais c'est comme ça)

Est-il possible de passer la taille des secteurs logiques de 512 à 4096

afin d'etre en accord avec le hardware ?

Non. Enfin, il me semble. Ce que te rapporte fdisk (au passage, je te conseille plutôt parted), c'est que le disque est fabriqué comme tel. Et de toutes façons, les disques se présenteront encore pendant un bout de temps avec des secteurs de 512, même s'ils sont 4k matériellement. Je ne sais pas s'il existera des disques qui pourront être « bi-mode », et quand des disques 4k seulement arriveront.

J'ai bien trouvé des tutos qui parlent d'alignement, mais les exemples ont des valeurs dans l'autre sens (logical 4096 / physical 512) du coup je ne sais pas si je suis concerné.

Heu… Les valeurs dans l'autre sens, c'est bizarre. Je pense que c'est sur des vieux noyaux qui détectent mal ces paramètres. Au passage, c'est quoi ton noyau ?
Par contre, l'alignement c'est très important, et tu es concerné : aligne à 4k. De toutes façons, ça ne fait pas de mal, même sur un disque 512. Les gestionnaires de partitions pas trop mauvais et pas trop vieux alignent automatiquement aujourd'hui.

Y a-t-il unr reglage particulier de "stripe" pour aller avec l'alignement precedemment mis en place ?

sachant que je compte faire du raid5 avec les 4 disques, soit 9To de stockage.

Je ne pense pas (je ne suis pas un spécialiste là-dedans). En général tes stripes sont > 4k, donc ça ne change rien.

Et combien de routeurs (surtout parmi les modèles grand public) respectent vraiment les RFC ?

Je m'y attendais à celle-là. Si tu pars de ce postulat, effectivement, rien ne va marcher.

Le « cas très spécial » étant que ton FAI te fournit juste un /64. À mon avis, ça risque d'être un cas très répandu (cf. Free[…])

C'est ton FAI qui fait de la merde. Je ne comprends pas pourquoi Free casse à ce point IPv6 alors qu'ils se veulent pionnier.

Si la route par défaut peut être donnée par DHCP, je ne mettrai certainement pas SLAAC en sus sur mes réseaux. Pourquoi faire compliqué quand on peut faire simple et connu ?

Il me semble qu'on peut effectivement l'envoyer par DHCP. Par contre, je ne suis pas sûr qu'une requête DHCPv6 soit envoyée si le SLAAC ne « répond pas » (bon, d'un côté, ça serait un peu con ; mais je n'ai jamais testé de tel setup). Après, quand tu parles de « simple et connu », DHCPv6 ça n'est pas simple, et pour l'instant ça n'est pas utilisé des masses il me semble, en tous cas comparé à SLAAC.

Un patch qui n'a pas encore été appliqué upstream. Désolé, mais je ne suis pas trop chaud pour recompiler des trucs comme dhcpd avec des patches non maintenus sur un serveur de production.

Ça va arriver bientôt. Oui, ça n'est pas normal d'avoir tant de retard, mais je suis un peu la liste, et ça fait à peine 6 mois qu'on commence à voir le nombre d'utilisations de DHCPv6 décoller.

Tu plaisantes ? La machine connectée via PPP peut vouloir être joignable. Et pour ça, elle a besoin d'une adresse globalement routable. Et pour lui en attribuer une, il faut soit IPV6CP (raté), SLAAC (/cf./ ci-dessus la limitation qui tue pour les préfixes > /64) ou DHCP (pas de patch officiel). FAIL.

Ça a été refusé par l'IETF dans IPV6CP parce que ça ferait redondant avec DHCPv6 (qui marche également sur du non-point à point, c'était l'argument contre — plutôt poussé par Cisco, il me semble), le SLAAC tu peux très bien le faire sur un lien PPP en /64, et DHCPv6, bah, c'est la manière recommandée par une RFC qui a à peine un an.

Non, c'est faux. Un pare-feu à maintien d'état se configure aussi vite qu'un NAT (et même plus facilement, tu fais juste tes FORWARD et pas les DNAT).

Je vois pas le rapport avec ce que je disais. Oui, un pare-feu se maintien plus facilement.

Ce qui rend la chose casse-pieds, c'est les FAI pas cool qui ne te donnent pas un préfixe suffisant, les nouveautés conçues avec les pieds (SLAAC) et les trucs à moitié finis (DHCPv6).

Pour les FAI, oui c'est clair, mais c'est pas comme si ça avait été répété des centaines de fois et que Free disent juste « on s'en branle » : c'est sûr qu'avec ce comportement, ça va faire avancer les choses. Pour les nouveautés « conçues avec les pieds », c'est plutôt que beaucoup de gens ont freiné pour les options dans les RA, peut-être par peur d'un truc qu'ils ne connaissent pas, et du coup, après, bien trop tard, ça a été intégré dans les RFC pour DHCPv6. Mais c'est encore assez récent.

Moi, je « m'y suis mis » (chez moi) depuis que mon FAI (Nerim) a fourni du dual-stack. Je ne pense pas être en retard. En revanche, en entreprise, pas question d'expérimenter avec des machins pas matures. Soit on donne les outils pour une transition simple, soit ça attendra.

Bah justement, à ce séminaire, j'ai vu des boîtes qui te proposent des jolis trucs qui marchent bien, si t'as envie de ça. Le libre traîne un tout petit peu, mais ça arrivera.

Ouais, génial, je n'attendais que ça : des machines avec autant d'IP que j'ai de FAI, des emm…es en perspective lorsque le routeur perd sa connexion WAN mais envoie toujours des RA sur le LAN, etc. Chaque jour, je suis un peu plus persuadé qu'en fait, SLAAC, saylemal !

Je ne sais plus quelle RFC dit qu'il ne faut pas que ton routeur envoie de RA s'il n'a pas de connexion upstream.

Là, on a déjà des ennuis à cause de SLAAC qui ne passe pas sur des préfixes plus petits qu'un /64,

Bah forcément, l'algo n'a pas été fait pour. Et faire moins que /64, à part pour des cas très spéciaux, c'est pas bien.

DHCPv6 qui ne distribue pas le routeur par défaut (apparemment, quelque chose a été fait de ce côté-là),

De toutes façons c'est fait en RA (oui, on va devoir avoir RA + DHCPv6 de toutes façons).

dhcpd qui ne marche pas sur les liens point-à-point,

Ya un patch qui tourne il me semble.

IPV6CP qui ne distribue pas d'adresse globale comme le fait IPCP

Bah, ça n'est pas essentielle à une connexion PPP.

Si c'est pour en plus rajouter des machins qui vont avoir pour effet de rendre les choses plus complexes, c'est pas la peine.

C'est plus complexe parce que tu n'as pas qu'une seule adresse à gérer. Forcément, il faut un tout petit peu plus de boulot que quand on NAT.

Moi, je propose déjà qu'on attende d'avoir un dhcpd qui offre les mêmes fonctions que son pendant v4 histoire de pouvoir faire une transition à peu près tranquille. La suite, on verra un peu plus tard, mmmh ?

Bon, c'est clair qu'il reste des trucs pas tout à fait au point, mais on n'avancera jamais si personne ne s'y met.

L'idée c'est justement de déclarer dans le whois "j'ai telle taille de bloc pour un même luser final", si c'est mal déclaré ou que le luser refourgue à 100 sites différents le même bloc, le caca n'est pas le fait de celui qui blackliste.

Tu juges un peu vite à mon avis. Ce genre de question, de quelle est la légitimité de la personne à mettre pleins de gens derrière son préfixe ou pas, répartis en telle forme d'autorité, c'est la question centrale à étudier. Elle n'est pas évidente du tout, et dire « il n'a qu'à se conformer à ce modèle, point », c'est un peu autoritaire, je trouve. IPv6 permet tout un tas de types d'adressages, dont certains qu'on n'a encore sûrement pas étudié, et ça change pas mal le modèle de responsabilité « une IP = une personne responsable » d'IPv4.

Après, je n'ai pas de solution sous la main, alors forcément, ça ne fait pas beaucoup avancer le schmilblick. Je suis aussi pour un modèle de responsabilitation des gens, mais dans certaines limites, que je n'arrive pas bien à définir.

Pour schématiser, je vois trois solutions (qui peuvent être mélangées) aux problèmes de spam/flood/attaque/bruteforce.. sur Internet :

La solution légale,

Oui, c'est la solution bisounours, mais ça serait quand même bien qu'on s'appuie un peu plus souvent dessus quand on a la possibilité, parce qu'à ne jamais l'employer elle va devenir insignifiante.

La solution "cowboy",

Oui, beaucoup de monde continuera à l'employer, mais j'aimerais bien qu'elle soit vraiment limitée. Plus on favorisera à aller dans ce sens là, plus les autres en face utiliserons de nouvelles méthodes. C'est le chat et la souris : ne courrons pas trop vite, de toutes façons on se fera rattraper.

La solution débile,

C'est débile, certes, mais ça ne marche « pas trop mal ». Et le fait d'amener les gens vers les plateformes centralisées… je ne suis pas sûr que ça marche vraiment : ils retrouvent des spammeurs là-bas aussi, sauf qu'ils sont « légaux »… Vis à vis de la perception des gens, ça ne change donc pas grand chose.

Mais pour ma part j'aimerais pouvoir conseiller aux gens de "juste faire" "aptitude install postfix apache2" quand ils aimeraient savoir comment s'auto-héberger, sans qu'ils aient à passer l'étape du "et maintenant t'as 2H de config pour l'antispam sur tes mails et sur ton blog, fais gaffe y'en a tjs qui passe à travers."

Moi aussi. Mais pousser des solutions qui peuvent se retourner contre nous plus tard (éventuellement), ça n'aide pas.

C'est marrant, j'ai essayé de retrouver le thread qui en parlait chez FDN, et il était initié par… toi :-)

Une proposition avait été faite à ce sujet : les ISP fournissant IPv6 devraient indiquer la taille du préfixe attribué à chaque utilisateur final, dans le whois.

Le contre-argument à ça, si je me rappelle bien, c'était que ça incite encore plus les gens à blacklister, puisqu'ils ont maintenant une « indication », alors que derrière il peut y avoir plein de raisons pour lesquelles on peut avoir un paquet d'utilisateurs différents. Bref, c'est souvent décriés par ceux qui sont contre le principe de blacklist en général.

Bon, on dirait qu'ils s'en foutent tous, Free y compris. Et c'est les mêmes qui ne vont pas activer IPv6 sur leurs serveurs SMTP à cause de la difficulté à blacklister le spam..

Ça c'est le deuxième problème de ce système : si quasi-personne ne le fait, effectivement, ça ne servira pas à grand chose.

La lenteur de mise en place d'IPv6, et ce genre de détails, me donnent l'impression qu'on est vraiment sorti du bel esprit coopératif qui a fondé Internet. J'ai peur pour l'avenir du réseau si les FAI se mettent à adopter automatiquement l'attitude "Ceci pourrait aider à lutter contre le spam de nos lusers, mais ça ne nous apporte rien, donc on ne le fait pas."

Ça montre qu'IPv6 ne s'est pas encore frotté à toutes les « merdes » de la pratique, en effet. Sur l'attitude coopérative, ça n'est aussi pas bon signe. Mais à mon avis, on peut trouver des solutions pour qu'IPv6 marche même sans ça.

Honnêtement, il faudrait surtout qu'un admin ait envie de s'y coller…

Perso, je veux bien m'y coller, bien que je ne sois pas admin.

Et la fondation Free peut fournir de l'IPv6.

Ça c'est nouveau, je ne savais pas. Tant mieux.

Dans l'immédiat, on a fini par traiter le souci noyau sur le second serveur, ça ouvre des perspectives.

Mmhh… si tu le dis (j'avoue que je ne sais pas de quoi tu parles).

Un des éventuels soucis, aussi, c'est la compatibilité du site lui-même, en rails ; il faudrait demander à Nono. Normalement, si rien de spécifique à l'IP n'est touché, je suppose que ça doit marcher sans trop de problèmes. Après, j'ai souvenir de l'ancien linuxfr qui gardait des sessions séparées par IP ; je ne retrouve pas ça dans le nouveau.

Après un rapide coup de grep dans les sources, le seul endroit où on utilise une IP, pour les votes, est fait (il me semble ; j'y connais pas grand chose à ruby) de manière assez générique pour gérer les deux versions du protocole. Par contre, je vois un bon moyen d'abuser du système de vote limité à une voix par IP… (oui, c'est le problème en général pour IPv6 : il y a de grandes discussions en cours sur quel taille de préfixe blacklister pour le spam, en particulier)

C'est toujours la même réponse : linuxfr est hébergée par la Fondation Free, qui ne propose pas d'IPv6… ce qui est très dommage pour une boîte qui se veut à la pointe là-dessus. En tous cas, administrateurs de linuxfr, ça n'est pas en attendant qu'ils vous le proposent que ça va les faire bouger : faudrait peut-être leur demander de manière un peu plus insistante (oui, je sais, hébergement gracieux, pas gueuler, toussa).

C'est encore à confirmer, mais je ferai peut-être un « témoignage » pour FDN lors de ce séminaire. Pour rappel, on propose de l'IPv6 depuis début 2009 https://linuxfr.org/news/lipv6-d%C3%A9barque-chez-fdn (activé par défaut pour tout le monde depuis juin dernier) et toujours avec des nouveautés à venir, pour bientôt, j'espère.

Explique ce que tu veux, pas comment tu veux le faire. « il y a des dépendances, mais j'en veut pas »… forcément, ça va pas vraiment marcher.

Je crois que tu n'as pas deviné les balises « ironie »…