GuiGui's Show

Version courte : la victoire n'est pas totale (les services spécialisés ne sont pas morts dans la bataille) et n'est pas encore assurée (possible contournement par le congrès).


« The Federal Communications Commission today voted to enforce net neutrality rules that prevent Internet providers—including cellular carriers—from blocking or throttling traffic or giving priority to Web services in exchange for payment.

The most controversial part of the FCC's decision reclassifies fixed and mobile [NDLR : excellent point ! En France, c'est bien sur les accès mobiles que l'on voit le plus d'atteintes en ce moment] broadband as a telecommunications service, with providers to be regulated as common carriers under Title II of the Communications Act. This decision brings Internet service under the same type of regulatory regime faced by wireline telephone service and mobile voice, though the FCC is forbearing from stricter utility-style rules that it could also apply under Title II.

[...]

The vote was 3-2, with Democrats voting in favor and Republicans against.

[...]

The core net neutrality provisions are bans on blocking and throttling traffic, a ban on paid prioritization, and a requirement to disclose network management practices. Broadband providers will not be allowed to block or degrade access to legal content, applications, services, and non-harmful devices or favor some traffic over others in exchange for payment. There are exceptions for "reasonable network management" [NDLR : jusque là, c'est excellent quoi qu'il manque la non surveillance et la non altération des communications] and certain data services that don't use the "public Internet." Those include heart monitoring services and the Voice over Internet Protocol services offered by home Internet providers.

[NDLR : donc la neutraltié des réseaux a été tronquée et les services spécialisés ont gagnés car ils n'ont pas été fermement encadrés (ils sont tolérables seulement si aucune autre offre équivalente techniquement ou en service rendu à l'utilisateur n'existe). Bah oui : des offres VOIP concurrentes, il y'en a d'autres (OVH en France, par exemple). Pourquoi uniquement celle de l'opérateur qui vous fournit l'accès au Net devrait être priorisée au détriment des autres ? Dailymotion est une filiale d'Orange. Le lien (administratif mais aussi au niveau interconnexion réseau) est donc direct entre Orange et Dailymotion, ça ne passe pas par Internet donc Orange pourrait prioriser Dailymotion au détriment de Youtube avec ce régime de régulation. Autrement dit, toute PNI (interconnexion privée entre deux opérateurs) pourra contourner cette régulation àmha.]

The reasonable network management exception applies to blocking and throttling but not paid prioritization. [NDLR : excellent point]

There are additional Title II requirements that go beyond previous net neutrality rules. There are provisions to investigate consumer complaints, privacy rules, and protections for people with disabilities. Content providers and network operators who connect to ISPs' networks can complain to the FCC about "unjust and unreasonable" interconnection rates and practices. There are also rules guaranteeing ISPs access to poles and other infrastructure controlled by utilities, potentially making it easier to enter new markets. [...]

The FCC could have tried to use Title II to require last-mile unbundling, in which Internet providers would have to sell wholesale access to their networks. This would allow new competitors to enter local markets without having to build their own infrastructure. But the FCC decided not to impose unbundling. As such, the vote does little to boost Internet service competition in cities or towns. But it's an attempt to prevent incumbent ISPs from using their market dominance to harm online providers, including those who offer services that compete against the broadband providers' voice and video products. [NDLR : huuum, ça compense un peu les services spécialisés... à voir l'implémentation derrière...]

[...]

Today's order could face both legal challenges and action from Congress. Republicans have proposed legislation that would eliminate Title II restrictions for broadband providers and vowed that the FCC vote is just the beginning of the debate.

Although many ISPs publicly oppose the new rules, the industry is by no means united against the FCC. Sprint and T-Mobile US have each said the FCC's proposal would not hurt their business. And while a good number of small broadband providers oppose the imposition of Title II rules, others support Wheeler. The NTCA Rural Broadband Association, which represents rural ISPs, said yesterday that it supports applying Title II to broadband networks.

Sir Tim Berners-Lee, inventor of the World Wide Web, spoke to the commission via video. He credited the openness of the Internet with allowing him to create the Web 25 years ago without having to ask "permission."

[...]The full net neutrality order has not been published yet. The FCC's majority is required to include the Republicans' dissents in the order and "be responsive to those dissents," Wheeler said. The order will go on the FCC's website after that process. The rules will go into effect 60 days after publication in the Federal Register, with one small exception. Enhancements to the transparency rule must undergo an additional review by the Office of Management and Budget because they make changes to the one part of the 2010 net neutrality order that survived court challenge. [NDLR : attendons donc la publication complète et les analyses qui suivront] »


Un dernier point me laisse dubitatif : on est sur de la régulation télécoms semblable à ce que pourrait faire l'ARCEP si le contexte législatif derrière le lui permettrait. Pour moi (comme pour d'autres comme Benjamin Bayart), la neutralité des réseaux doit relever de la loi avec des sanctions pénales à la clé car le pouvoir des FAI sur le citoyen est monstrueux.


L'avis de l'EFF (trop optimiste à l'heure actuelle, à mon goût) : https://www.eff.org/fr/deeplinks/2015/02/fcc-votes-net-neutrality-big-win
« That’s great for making sure websites and services can reach ISP customers, but what about making sure customers can choose for themselves how to use their Internet connections without interference from their ISPs? To accomplish this, the FCC has banned ISPs from blocking or throttling their customers’ traffic based on content, applications or services—which means users, hackers, tinkerers, artists, and knowledge seekers can continue to innovate and experiment on the Internet, using any app or service they please, without having to get their ISP’s permission first.

[...]

But now we face the really hard part: making sure the FCC doesn’t abuse its authority.

For example, the new rules include a “general conduct rule” that will let the FCC take action against ISP practices that don’t count as blocking, throttling, or paid prioritization. As we said last week and last year, vague rules are a problem. The FCC wants to be, in Chairman Wheeler’s words, “a referee on the field” who can stop any ISP action that it thinks “hurts consumers, competition, or innovation.” The problem with a rule this vague is that neither ISPs nor Internet users can know in advance what kinds of practices will run afoul of the rule. Only companies with significant legal staff and expertise may be able to use the rule effectively. And a vague rule gives the FCC an awful lot of discretion, potentially giving an unfair advantage to parties with insider influence. That means our work is not yet done.  We must stay vigilant, and call out FCC overreach. »

J'attends l'avis de LQDN/FFDN sur le sujet.

Il suffit de rajouter l'option « -sha256 » lors de la génération de la CSR. Pareil lors de la génération du certificat à partir de la CSR dans le cas d'un cert auto-signé ou d'une AC personnelle.

« Imaginons avoir une infrastructure de notre parc informatique basée sur la virtualisation, ie. chaque service isolé dans son propre conteneur.
A minima, on va vite se retrouver avec les conteneurs suivants : un Bind9, un Postfix, un Nginx, un Apache, un MySQL, un PostgreSQL…
Gestion des rôles

Tout comme dans un vrai code informatique, on voudrait profiter de mécanisme d'héritage, de polymorphisme et d'agrégation pour définir notre infrastructure, afin d'éviter la duplication et de conserver une base robuste à un changement future d'infrastructure.

On doit pouvoir définir une description globale de tous les Apache (installation et configuration de Apache, ouverture des ports 80 et 443 du pare-feu, installation de RPaf…) et faire apparaître la notion de rôle.

On veut quand même vouloir en redéfinir certains morceaux machine par machine (liste des virtualhosts servis, déploiement des certificats SSL…), un peu à la manière d'un héritage

On doit pouvoir agréger les rôles, et signaler qu'un serveur Apache est aussi un serveur de courriel, par composition.
Gestion des relations

Tous les services d'une infrastructure sont inter-dépendants : le Nginx sert de reverse-proxy au serveur Apache, qui sert un site web qui utilise une base de données PostgreSQL, le Nginx a donc besoin de l'adresse IP du serveur Apache et des virtualhosts servis, le Apache a besoin de l'IP du serveur MySQL.
Pire, les dépendances forment des boucles : le serveur Apache a besoin de l'IP du serveur Nginx devant lui pour configurer son module RPaf (qui permet d'avoir l'IP réelle du client dans les logs et non celle du reverse-proxy), le MySQL a besoin de l'IP du serveur Apache pour ouvrir son pare-feu…

On a donc besoin de pouvoir définir son infrastructure d'une manière déclarative (le quoi) et non impérative (le comment), en évitant la redondance de l'information (l'IP d'une machine définie une et une seule fois), la duplication de code, le risque d'incohérence dans la configuration en cas de modification de l'infrastructure…
Dans l'exemple précédent, on veut ne définir les IP que dans la description de l'hôte en question, et ne définir qu'à un seul endroit la relation entre un Apache et son proxy Nginx.

Pour les relations, on aimerait même se minimiser le travail au cas où notre infrastructure soit amenée à évoluer demain, et donc pouvoir les définir de manière complexe, comme par exemple « un Nginx proxite tous les virtualhost des Apaches situés sur la même machine physique », et non se contenter de déclarer le proxy Nginx utilisé dans le descriptif du Apache, ou à l'inverse la liste de tous les Apache proxifiés dans le descriptif du Nginx (mais surtout pas les deux sous peine d'incohérence !)
Gestion des tâches

On doit faire le déploiement et la configuration en elle-même. Installation de paquets, édition de fichiers de configuration, création d'un utilisateur, redémarrage d'un service… L'outil doit fournir des primitives basiques et si possible avec une couche d'abstraction suffisante pour être indépendant de l'OS utilisé (on installe un paquet avec apt sous Debian mais avec yum sous Red-Hat).

Et comme dans un langage informatique, il doit être possible de combiner ces primitives pour obtenir des résultats plus complexes. Par exemple, créer un administrateur, c'est créer un utilisateur, déployer sa clef SSH sur son compte et la déployer aussi sur le compte root.

[...]

Puppet : ça ne marche pas

[...]

Pour un service donné, l'outil fait clairement bien son job. On peut installer des paquets, déployer des fichiers tout fait ou via un template instancié à la volée avec les valeurs nécessaires. Le DSL est plutôt assez concis et donne des descriptifs faciles à lire une fois passé l'apprentissage des incantations magiques.

Là où ça commence à pécher, c'est pour la gestion des relations… Puppet est basé sur un mécanisme client/serveur, ou plus exactement master/slave. Une machine, le puppet master, contient l'intégralité des descriptifs, rôles, fichiers et autres templates. Sur chaque machine gérée par l'outil tourne en permanence un démon puppet, le puppet agent, qui vient régulièrement vérifier s'il a des choses à faire, une fois par jour par exemple.
Du coup, chaque machine est isolée et ne peut travailler qu'avec ce qui lui est directement destiné. Une machine n'a pas la possibilité d'aller voir ce qu'une autre machine a déployé, par exemple un Nginx ne peut pas lister les Apaches sous sa responsabilité, c'est à l'administrateur de lui indiquer explicitement la liste quelque part, ce quelque part devant obligatoirement être dans le périmètre du Nginx et pas uniquement dans celui des Apaches. Bref, c'est à l'administrateur de gérer manuellement les dépendances, sans aucune assistance de la part de l'outil pour lui dire qu'il a oublié de renseigner le nouvel Apache fraîchement arrivé dans la configuration du Nginx !
[...]

Pour palier à ce problème, il existe quand même un mécanisme de partage d'information, les ressources exportées.
On veut par exemple que chaque installation d'un serveur Apache génère automatiquement une vérification Nagios sur le port 80.

[...]

Déjà, on vient de devoir créer une nouvelle classe de serveurs, nagios::target::apache. Pourtant, un serveur HTTP est juste un serveur HTTP. Pas un serveur HTTP + vérification du port 80. On a introduit de la redondance d'information…
Qui dit redondance dit erreur possible. Je définis un nouveau serveur Apache dans mon infra mais je suis un jeune admin tout fraîchement démoulu de l'école ? Je n'ai pas les 10 ans d'historique et d'expérience de mes collègues ? Ben on m'a demandé d'installer un nouveau serveur Apache, donc j'ai juste mis la classe apache à ma nouvelle machine… et elle n'est donc pas monitorée par Nagios !
Le simple fait d'avoir un port 80 en écoute devrait automatiquement entraîner le monitoring ! Parce que si l'admin sys en chef passe sous un poney demain et qu'il y a toutes les chances du monde qu'il soit le seul à avoir conscience qu'il y a un Nagios mort dans un coin, plus personne ne pensera à le faire !

[...]

La redondance appelant généralement à toujours plus de redondance, que se passe-t-il si on souhaite maintenant monitorer le port 80 et le port 443 ? Pas de soucis, il n'y a qu'à rajouter une vérification du port 443 dans la classe nagios::target::apache. Oh mais attendez, si mon serveur Apache n'a que du HTTP ou que du HTTPS ? Ah mais les tests Nagios vont se mettre à échouer sur le port non présent… Pas grave, il n'y a qu'à faire 2 classes, nagios::target::http et nagios::target::https et le tour est joué ! Ah mais oui, j'ai aussi un Munin tient. Ok, ben disons « munin::target::http » et « munin::target::https ».
On voit bien le risque de fonctionner ainsi : à chaque modification de l'infrastructure, comme les dépendances ont été codées « à la main » dans l'outil, rien ne s'adapte tout seul, et toute modification devient intrusive… Un simple serveur Apache qui devrait n'avoir qu'une seule classe apache va se retrouver avec une foultitude de classes présentes uniquement dans un but technique et non métier.

[...]

En plus, on ne parle ici que d'une dépendance simple qui devrait en réalité s'exprimer ainsi : « j'active une vérification Nagios sur le port 80 si la machine possède la classe apache ou nginx et au moins un virtual-host sur le port 80 ».
Imaginez maintenant devoir régler de cette manière une dépendance plus complexe de type « déploie des virtual-host nginx en reverse proxy pour chaque virtual-host de chaque Apache présent sur la même machine physique que toi, en utilisant comme IP de proxy l'IP du Apache ». Je vous tend déjà le tabouret et la corde…

[...]

Chef : ça ne marche pas non plus

[...]

Là où tout change c'est que Chef fournit de base une base de données Solr qui va stocker l'intégralité de la description d'une machine. Cette base est bien entendue requétable depuis les descriptions, ce qui permet de faire des choses assez sympathiques pour régler les problèmes précédents. [...] Par rapport à Puppet, on a aussi la notion de databags, qui permettent de séparer proprement la partie données de la partie traitement. Une telle séparation est très difficile à atteindre avec Puppet.

[...]

J'ai uniquement éditer les fichiers de données (databag), qui ne sont pas liés à une recette et peuvent donc contenir pas mal d'information, pour y ajouter les clefs SSH à déployer ainsi que les IP autorisées pour les accès SSH.
Et la recette ssh va utiliser exactement le même jeu de données que la recette users, pour déployer tout ça proprement et remplir les fichiers de clefs et la config SSH. Impact sur la recette users : 0 ! Impact sur les anciennes classes des serveurs : 0 ! Ce qui n'aurait très clairement pas été le cas avec du Puppet (ajout d'une ressource exportée toute moche ou refacto lourde de l'infra pour introduire des classes fantômes) ! On obtient donc des configurations bien plus claires d'un point de vue sémantique avec Chef qu'avec Puppet.
Tout ça grâce à la primitive search, qui va interroger la base de données Solr pour récupérer l'état de la configuration. Ce truc est extrêmement utile et fait toute la différence avec Puppet, l'intégralité de la configuration est accessible depuis n'importe quelle recette, ce qui évite la duplication d'information et/ou la création de classes fantômes pour gérer les dépendances. La recette Nginx passera par search pour lister les Apache de sa machine hôte (search(:node, "apache:* AND physical:#{node[:physical]}")), ou encore la recette DNS l'utilisera de la même manière pour récupérer l'IP du DNS tournant sur le même réseau pour renseigner resolv.conf.
Chef, vainqueur par KO…

[...]

Le problème avec search, c'est que les données sont publiées dans la base Solr non pas quand vous les publiez sur le serveur Chef mais après l'exécution de l'agent Chef… Et ça change tout…
Chef utilisant un agent sur chaque machine, on n'a aucun moyen de garantir l'ordre d'exécution du déploiement. Si par malheur le Nginx passe avant les Apaches, la config vue par Nginx est l'ancienne config et ne tient pas compte des potentielles modifications introduites par l'admin ! Pire, Chef a tendance à effacer toutes les configs existantes quand un admin publie ses modifications, le prochain passage sur le Nginx va donc virer tous les virtualhost de proxy et les Apaches vont se retrouver coupés du monde !
On pourrait résoudre ce problème en désactivant tous les agents et en exécutant le passage de Chef « à la main », via un script qui ordonne correctement les machines à déployer et s'y connecte dans l'ordre via SSH par exemple. Ça ne résoud qu'une partie du problème car dans le cas d'une boucle de dépendances (Nginx proxite les Apaches qui ont besoin de l'IP du Nginx), il faudrait passer plusieurs fois sur chaque machine et avec des recettes différentes pour parvenir à avoir le bon résultat.

[...]

Ansible : et ben… ça ne marche pas mieux…

[...]

D'abord, je n'ai pas trouvé comment définir des méta-taches, ie. une tache réutilisable qui appelle plusieurs sous-taches. Typiquement, ma tache de création d'un utilisateur (humain) est décomposable en création d'un utilisateur (UNIX) et déploiement de sa clef SSH. La création d'un administrateur est la création d'un utilisateur (humain) et déploiement de sa clef SSH pour root.

[...]


Bon, continuons… Les groupes maintenant… J'ai dit un peu plus haut que les variables pouvaient être héritées via les variables de groupe. Mais Ansible a un concept d'héritage somme toute assez intéressant. [...] Naïvement, j'ai voulu faire des choses comme ça. Naïvement hein, vu que c'est juste une description de ce qu'est réellement mon infra…
Toutes mes machines qui ont du SSH doivent avoir le port SSH d'ouvert. Toutes les machines qui font du Apache doivent avoir le port HTTP et HTTPS d'ouvert, ont pour adresse mail de contact une certaine chose commune et servent leur contenu depuis /srv/www. Et enfin, toutes les machines Apache derrière le même proxy Nginx seront configurées toutes pareilles niveau RPAF.

[...]

Voilààààààààà… L'héritage au sens Ansibli-ien du terme, c'est « Zyva, pourquoi j'ai déjà une valeur moi ? Allez zou, fait pas suer, j'écrase ! ». Du coup, j'en suis réduit à calculer moi-même le résultat du merge que j'aurais envie d'avoir eu, et à le coller dans le hosts_var/www.yml et à supprimer tous les groups_var. Très pratique le jour où il y a un paramètre commun à changer…

[...]

Dans mon déploiement, le service fail2ban restart nécessaire à la prise en compte des nouvelles règles de blocage de fail2ban est en réalité fait via un service firewall restart, vu que le firewall doit déployer des règles avant celle de fail2ban. J'ai donc besoin de faire [...] Question à 10 balles : où et comment je peux faire pour mutualiser le Restart firewall et ne définir sa tache associée qu'à un seul et unique endroit (principes KISS et DRY) ? [...] Bam… Ça passe très bien à l'exécution de la tache firewall mais ça plante violemment à celle de fail2ban, comme quoi le handler est manquant. Bon ok, j'ai peut-être été un peu vache avec toi Ansible, j'vais quand même te mettre le handler dans un truc un peu plus commun et pas directement dans le role firewall…

[...]

Mais en fait, non, j'ai fait une erreur, je n'ai pas tous mes serveurs qui déploient du fail2ban, mais juste ceux avec ssh. Gros naïf va… [...] Wait ? Wat ‽ J'ai bien lu ? C'est une blague à ce niveau-là, non ? Elle est où la caméra ? J'vais quand même pas devoir déclarer dans chaque groupe/rôle/whatever le role common juste pour avoir des handlers qui sont déjà théoriquement communs à toutes les machines, si ?

Bref… Pour conclure, alors que Ansible me semblait assez prometteur et intéressant sur ses concepts (agentless + ssh + DSL pas trop dégeu), je me retrouve à devoir quasiment réfléchir à la place de l'outil pour lui prémâcher tout le travail, un peu comme si vous aviez une super machine sensée faire le café mais où vous deviez la remplir avec du café déjà tout fait qu'elle n'a plus qu'à réchauffer pour servir…

[...]

Ansible n'est qu'un outil pour orchestrer séquentiellement des tâches d'administration et non pas un outil de gestion de configurations comme prétendent l'être chef et puppet. »

De la conf' BIRD utilisée en prod' chez Gitoyen.

Oooouuch, un bon cas pratique qui démontre qu'Orange est une société toute-puissante et que les clauses de non-discrimination du secteur télécoms (cf, par exemple : http://shaarli.guiguishow.info/?TdLuaw) sont loin d'être toujours appliquées. Bien joué la veille citoyenne, igwan.net ! :)

« En 2011, l'ARCEP décide que Orange doit accepter de dégrouper ses sous-répartiteurs si certaines conditions sont remplies. En résumé, si la collectivité qui souhaite dégrouper un sous-répartiteur coule une dalle béton, amène l'électricité et paye l'abonnement, tire 6 paires de fibre entre le NRA d'origine et le sous-répartiteur à dégrouper, paye la fourniture et l'installation des armoires et s'engage à ne pas faire de FttH dans le coin pendant 3 ans - rien que ça - Orange est contrainte et forcée d'accepter le dégroupage.

En contrepartie pour tous ces services, Orange verse une redevance symbolique à la collectivité qui varie selon la taille (le nombre de lignes) du répartiteur dégroupé, de l'ordre de 500 à 1200 euros par an. Une somme ridicule, on va le voir, au regard des investissements de la collectivité.

[...]

A Saint-Barthélemy, on a décidé qu'il devenait urgent, en prévision des élections de 2017, de soulager deux quartiers particulièrement mal desservis par l'ADSL du fait de lignes trop longues. Au lieu d'y déployer le FttH ("on va le faire promis, c'est juste que là pour 2017, c'est un peu juste") on demande aux PTT à Orange dans leur grande bontée de bien vouloir améliorer un peu leur réseau. Pour faire classe, et imprégner les esprits de la magie de la fibre optique, on a appelé ça le FttN.

Au terme d'une procédure de marché public, c'est donc une entreprise locale qui va tirer le câble et aménager les sites d'accueil.

    Fourniture et tirage du câble : 108 500 € (17 € par mètre).
    Aménagement des sites : 188 620 € (94310 € par site).

Il faut également payer à Orange une prestation pour l'installation des armoires. Dans le cas de Saint-Barthélemy (deux armoires d'environ 400 lignes) cette somme s'éleve à 110 500 euros.

Pour installer le câble optique, il a fallu de plus sortir la pelleteuse : casser les routes et y poser des fourreaux. Oui, ces mêmes fourreaux dont l'absence était invoquée comme excuse pour ne pas déployer le FttH dans ces quartiers.

Investissement total (hors génie civil routier, dont on considère qu'il n'est pas dédié et sera réutilisé pour le réseau FttH) : 407 620 euros pour 800 lignes, soit environ 500 euros par ligne "montée-en-débit".

Mais tout n'est pas perdu pour la collectivité, car Orange va payer pour toutes ces fibres et la mise à disposition des sites, pas vrai ?

2300 euros par an : c'est la somme que va débourser Orange pour la mise à disposition de 6 paires de fibres sur un linéaire de 6380 mètres (en plus de la mise à dispo des sites d'accueil, de leur entretien, de l'énergie électrique, ...).

Mais attendez, il nous semblait que la collectivité avait déjà voté les tarifs de mise à disposition de fibre optique aux opérateurs télécom ! Les voici : [...] Si ces tarifs lui étaient appliqués, Orange devrait régler une redevance annuelle de 53 592 euros ainsi que de frais d'accès au service "sur devis", car le câble optique n'était pas préexistant.

La collectivité est-elle en droit de pratiquer des tarifs différents selon les opérateurs ? L'article 1425-1 du Code général des collectivités territoriales semble bien répondre par la négative [...]

Suivant ce constat, et si on vivait dans un état de droit, il resterait aux élus trois possibilités :
    * appliquer à Orange les tarifs votés par le conseil territorial ;
    * appliquer à tous les opérateurs les tarifs dont bénéficie Orange ;
    * rayer du fronton de l'hôtel de la collectivité le mot "égalité". »

Via http://shaarli.cafai.fr/?XjkCyA

« D'abord il n'y a pas de "discours type de la haine" (diapos 3 et 4). A quelques rares exceptions qui font l'unanimité, comme la diffusion de ces vidéos de décapitation ou les insultes ouvertement racistes, la plupart des cas qui posent problème ne sont des discours de haine qu'au regard de certains contextes ou de certaines communautés : c'est le cas des caricatures du prophète, c'est aussi le cas de certaines "blagues" accolées au hashtag #UnBonJuif.

La question est alors de savoir "qui décide" de laisser diffuser ces contenus (diapos 5 et 6), et surtout sur quels critères : 4 possibilités : la justice, nous-mêmes, le code (les algorithmes) ou les plateformes elles-mêmes.

[...]

Il faut remettre en perspective, à l'échelle du web-média, les bouleversements qui ont eu lieu dans notre perception (ou nos aspirations) de la légitimité d'un discours (diapos 8 à 11). Avec ces 3 grandes étapes qui furent, en 1996, la déclaration d'indépendance du cyberespace ("il n'y a pas de lois ici"), l'article "Code is Law" de Lessig en janvier 2000, et la récente déclaration de Mark Zuckerberg qui place, de facto, sa plateforme au-dessus et à l'extérieur des lois ("nous ne laissons jamais un pays ou un groupe de gens dicter ce que les gens peuvent partager à travers le monde"). Vous noterez l'emploi du présent dans la déclaration de Zuckerberg qui indique qu'il a déjà "acté" cette pratique et qu'il la considère comme parfaitement légitime (culture du 1er amendement de la constitution américaine), toute la question étant de savoir ce que devient cette pratique "libertarienne" si on la déplace dans un contexte moins "unanimiste" que celui de la réaction aux attentats contre Charlie Hebdo.

Il faut ensuite acter l'état actuel des législations (américaines, françaises, etc.) qui disposent en l'état d'un arsenal de textes déjà largement suffisant (diapo 13) pour encadrer, pour "surveiller et punir" dirait Foucault, l'expression des discours de haine. Des lois certes controversées, mais des lois existantes et directement applicables. A condition de ne jamais zapper la case justice.

[...]

Il faut, enfin, accepter, reconnaître et comprendre un certain nombre de principes "simples" qui caractérisent les modes d'expression sur le réseau : le premier d'entre eux (diapo 13) est la "tyrannie des agissants" décrite par Dominique Cardon ("Internet donne une prime incroyable à ceux qui font"). Comprendre également la nature des processus d'engagement en ligne (diapos 18 à 21), lequel "engagement" déterminera ensuite la portée et le risque réel associé aux discours de haine qu'il sous-tend. Or en la matière, il faut constater, comme l'a rappelé l'affaire du "soutien au bijoutier de Nice", que 1 million de like n'équivaut pas à un million de soutiens, qu'une personne "soutenant" en ligne un certain type de discours n'est pas nécessairement prête à "s'engager" derrière ce discours, fut-il un discours de haine ou, d'ailleurs, un discours de paix. L'engagement en ligne est le plus souvent une forme de désengagement ("slacktivisme").

A propos de l'engagement, Merleau-Ponty écrivait :

    "Tout engagement est ambigu puisqu’il est à la fois l’affirmation et la restriction d’une liberté : je m’engage à rendre ce service, cela veut dire à la fois que je pourrai ne pas le rendre et que je décide d’exclure cette possibilité."

Or précisément, sur les internets, le "like" ou le slacktivisme est une forme d'engagement monoface : "liker" une "cause" ou un "discours" c'est exclure la possibilité de rendre réellement un service. Et la plupart du temps ... c'est tout.

[NDLR : voilà pourquoi je déteste les pétitions en ligne qui sont du pur bullshit ! Envoyer des mails à nos représentants (ou aux responsables des actions auxquelles on s'oppose) ou organiser une soirée de réflexion (AFK ou non) apportera infiniment toujours plus de valeur qu'une pétition web débile.]

[...]

Ceci étant posé, oui, il y a bien un discours de haine présent sur internet. Comme d'ailleurs dans le PMU du coin. C'est vouloir les traiter de la même manière, c'est leur accorder la même importance qui serait une erreur. Car ces discours de haine sur internet obéissent à des logiques propres qui tournent autour de 4 effets contre-intuitifs
    * L'effet petit pois (comme dans le conte de la princesse au petit pois) fait que l'on se focalise souvent - et particulièrement dans le cadre de l'analyse des discours de haine - sur des phénomènes relevant de l'infinitésimal. Il s'agit d'une erreur sur "l'ordre de grandeur" de ces phénomènes ou de ces discours. Pour s'en convaincre on pourra relire ces deux illustrations de l'effet petit pois que furent le traitement du hashtag #jesuiskouachi ou celui de #jenesuispascharlie.

    * L'effet miroir consiste à interpréter ces mêmes phénomènes à l'inverse de ce qu'ils signifient réellement. Là encore, en termes d'ordre de grandeur, pour 100 000 "je suis charlie" on dénombrait à peine 100 "je ne suis pas charlie", et sur ces 100 "je ne suis pas charlie", 99 reprenaient le hashtag mais pour condamner celui qui l'avait utilisé.

    * L'effet Streisand, le plus connu et le plus ancien à l'échelle du web, consiste à croire que supprimer ces contenus serait "la" solution alors que chaque suppression ne fait qu'accélérer la duplication et l'audience des contenus, des propos ou des discours visés.

    * L'effet cigogne, enfin, qui est le résultat de la somme des 3 effets précédents et qui consiste à confondre corrélation et causalité. En gros "il y a beaucoup d'appels à la haine sur internet, donc internet incite à la haine". Ben non.

Le problème est que la plupart des approches visant à lutter contre ces discours de haine, qu'il s'agisse du discours politique ou de l'action législative ignorent presque totalement ces 4 effets.

[NDLR : à part l'effet Streisand/Flamby (selon le contexte / la valeur accordée globalement aux données censurées), les autres vices de raisonnement s'appliquent justement parfaitement au PMU du coin ! Internet n'est pas différent du PMU, de la rue, ... C'est les mêmes gens, les mêmes humains derrière qui font société, qui interagissent, qui échangent différemment, c'est tout ! Il faut différencier la manière d'échanger, de faire société des propos échangés. Un like/retweet de colère c'est juste assimilable à un "je suis bien d'accord, tous des pourris toute façon et on peut rien y faire" après quelques binouzes, rien de plus ! ]

[...]

On constate que tout le débat sur "comment lutter contre les discours de la haine" ne concerne pas "internet" mais concerne ses jardins fermés, c'est à dire les "plateformes" que sont Facebook, Twitter mais aussi de plus en plus Google en tant qu'écosystème de services (via Youtube notamment). Donc on agit au niveau des plateformes et pas au niveau d'internet (pour lequel, je répète, y'a déjà suffisamment de lois qui fonctionnent et s'appliquent).

[...]

On constate que ce sont les algos des plateformes qui ont à la fois pouvoir de police et de justice, dans la plus totale opacité, et qui décident de publier telle ou telle vidéo, de laisser passer tel ou tel #hashtag. Bref on constate que les algorithmes sont ces nouvelles "corporations du filtre" (l'expression est d'Umberto Eco) comme l'étaient hier les éditeurs et les rédactions de médias "papier".

On constate que ces choix (laisser passer, laisser publier, etc.) relèvent d'un processus d'éditorialisation classique. On constate que les algorithmes font des choix d'éditorialisation classique.

[NDLR : Nul ne peut ignorer le code ? Boarf, pas que. La censure automatisée est un problème certain mais : 1) la loi s'applique (si l'on ne laisse pas des multinationales être au dessus des lois des états, ce qui est un autre problème). 2) les algos, ce n'est pas encore Skynet, il y a des humains derrière, voir 1). 3) les actes de censure par des algos sont un vrai problèmes mais beaucoup de décision de censure sur les gros silos ne sont pas encore automatisée. ]

Via https://twitter.com/Calimaq/status/569544085603627009

« Par décision 14-DCC-160 du 30 octobre 2014, l'Autorité de la concurrence a autorisé, sous réserve de plusieurs engagements, la prise de contrôle exclusif par Numericable Group de la Société Française de Radiotélephone (ci-après, « SFR »). Dans le cadre de ces engagements, Numericable s'est engagé à soumettre à l'agrément de l'Autorité de la concurrence des offres de référence relatives à l'accès de son réseau câblé et du réseau DSL de SFR et Completel.

[...]

Numericable s'est engagé à proposer à tout opérateur qui le souhaite deux offres d'accès à son réseau câblé. Une première offre, sous « marque blanche », doit permettre aux opérateurs MVNO qui ne déploient pas de réseau FttH et ne disposent pas de leur propre box d'accéder au câble. Une deuxième offre, dite « bitstream », doit permettre à tous les fournisseurs d'accès internet d'utiliser l'accès au câble pour proposer des offres très haut débit en utilisant leurs propres box et leurs propres interfaces clients.

[...]

Elles doivent donc être proposées à un prix excluant tout effet de ciseau tarifaire et laissant un espace économique suffisant aux concurrents pour se développer. Elles doivent également être proposées à des conditions transparentes, objectives et non-discriminatoires.
[NDLR : non-discriminatoire avec des FÀS en centaines (par ligne) voire milliers (porte de collecte) d'euros sur la partie services de collecte DSL de Completel et SFR à destination des entreprises [NDLR : donc uniquement les liens ADSL/SDSL avec GTR et garantie de débit pour l'instant, pas les accès grand-public] et inconnus sur la partie offres d'accès au réseau câblé (l'annexe A n'est pas disponible sur le site de l'Autorité). De telles conditions n'excluent pas du tout les FAI associatifs et les TPE/PME locales, noooon, c'est sûr. Mais on n'a pas la même définition de la discrimination « L'engagement de non-discrimination doit permettre en particulier de garantir que les tiers disposeront de conditions identiques à celles appliquées par la nouvelle entité pour ses besoins internes. ».]

Numericable s'est engagé à céder le réseau DSL de Completel pour permettre l'apparition d'un nouvel opérateur sur le marché des services de télécommunications fixes spécifiques entreprises. Dans l'attente de la réalisation de cet engagement, Numericable s'est également engagé à mettre à disposition les services de collecte DSL de Completel et SFR à destination des entreprises sur l'intégralité des NRA couverts par SFR  et Completel.

Numericable s'est engagé à proposer cette offre d'accès à des conditions objectives, transparentes et non discriminatoires, pour permettre aux opérateurs de détail de disposer d'une offre leur permettant d'être compétitifs sur le marché de détail. L'engagement de non-discrimination doit permettre en particulier de garantir que les tiers disposeront de conditions identiques à celles appliquées par la nouvelle entité pour ses besoins internes.

Les offres de référence communiquées par Numericable relatives à l'accès de son réseau câblé et du réseau DSL de SFR et Completel n'engagent pas, à ce stade, l'Autorité de la concurrence. Ils constituent des projets soumis à consultation et sont susceptibles de faire l'objet de modifications.

[...]

Afin d'éclairer l'examen de l'Autorité, les tiers intéressés sont invités à présenter leurs observations sur les propositions d'offres de référence communiquées par Numericable Group. Les observations pourront être adressées au service des concentrations de l'Autorité de la concurrence, au plus tard le 9 mars 2015 par voie postale ou électronique, à l'adresse suivante
[NDLR : la FFDN a-t-elle un rôle à jouer dans cette histoire ? Est-ce pertinent ?] »

ServerAliveInterval (dans ssh_config) ou ClientAliveInterval (dans sshd_config) permettent d'envoyer un keepalive à l'autre partie après un timer d'inactivité.

Super utiles face à un intermédiaire (entre un client SSH et un serveur SSH) qui a un suivi de connexion / NAT un peu stressé (exemple : trop de clients subitement (heure de pointe) donc durée de vie d'une entrée dans la table diminue pour préserver l'équité) ou zélé de base (implémentation douteuse) qui vire trop vite les états en cas d'inactivité.

« En effet, avec une seule route par défaut, tous les paquets IP ressortiront via la même interface, pour ma part eth0. Auparavant il fallait jouer avec ip rules, créer plusieurs tables de routage et composer avec tout ça. Si cela vous intéresse, vous pouvez regarder sur lartc.org comment procéder. Pour ma part je trouve que ça fait un peu mal aux cheveux.

Et bien depuis la version 3.12 du kernel Linux et la clause from, il suffit de deux commandes : ip -6 route add default dev tun0 from 2a00:5881:4008:400::/56 et ip -6 route add default dev eth0 from 2001:470:1f13:138::/64 si je veux répondre sur une IP dans chacun de ces réseaux, sur leur interface respective. Nous obtenons alors une table de routage du genre de :

default from 2001:470:1f13:138::/64 dev eth0  metric 1024
default from 2a00:5881:4008:400::/56 dev tun0  metric 1024
2001:470:1f13:138::/64 dev eth0  proto kernel  metric 4
2a00:5881:4008:400::/64 dev tun0  proto kernel  metric 256
fe80::/64 dev eth0  proto kernel  metric 256
default via fe80::250:fcff:fe4d:c3a4 dev eth0  metric 1024

Ainsi, mon serveur saura quelle interface utiliser en fonction de l’adresse source. »

Plus besoin de ip rule et table de routage multiples (voir http://shaarli.guiguishow.info/?xT-HMA), en v6 uniquement avec Linux >= 3.12 \o/