GuiGui's Show

« Donc nous sommes en 2015, où après 4 échecs sanglants du modèle telco des vrais spécialistes, les vrais spécialistes reviennent nous expliquer que la neutralité d’Internet, ce n’est pas bien sérieux et ça va empêcher le réseau de se développer pour faire des vraies choses dont nous allons avoir besoin très bientôt.

Alors… vous les croyez encore, vous ? »

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

Ce truc qui commence à circuler partout est du grand n'importe quoi, il faut remettre les pendules à l'heure d'urgence.

1) Oui, les admins de Facebook ont accès à TOUTES les données stockées sur une machine dont le proprio est Facebook. Sans blague ! Il n'y a pas de données privées pour un root (exception faite du chiffrement dont vous contrôlez totalement la clé et encore, c'est pour un laps de temps donné inconnu à l'avance (car ça dépend des avancées cryptanalyse/mathématiques)). En informatique, le root (l'admin) d'une machine a accès à TOUTES les données de la machine. TOUTES. L'admin qui travaille chez un gros hébergeur a accès à TOUTES les données stockées sur TOUTES les machines qui font partie de son périmètre d'intervention au mieux, à TOUTES les données stockées sur TOUTES les machines de la société au pire. Le root d'un réseau (FAI, opérateur) peut avoir accès à TOUTES les données qui circulent sur son réseau. Tout cela à votre insu, sans avoir à vous demander une quelconque autorisation et sans laisser de traces de votre côté (il peut y avoir des logs de leur côté). C'est une ÉVIDENCE. Oui, le POUVOIR des ADMINS est ÉNORME.

2) Si vous n'acceptez pas ce fait : auto-hébergement ou hébergement dans une asso de confiance (les admins auront toujours accès à toutes vos données mais vous les avez choisis, vous les connaissez), ne pas mettre des choses privées (que vous ne voulez pas voir divulger un jour) dans les sections dites "privées" de grosses plateformes centralisées ou alors utiliser une méthode de chiffrement dont vous seul avez la clé !

Plutôt que d'apprendre aux jeunes à coder à l'école, il faudrait déjà leur apprendre les bases : comment fonctionne un ordinateur, un réseau et Internet.

Via https://twitter.com/bortzmeyer/status/572795465030213633

Obtenir la taille d'une paire de clé SSH et son fingerprint : ssh-keygen -lf /chemin/vers/la/partie/publique (exemple  /etc/ssh/ssh_host_rsa_key.pub )

Parfois, on me demande des détails précis sur DNS tout en me demandant la section du RFC kivabien pour argumenter. Cette fois-ci, je me mets ça de côté.

    * Un CNAME dans un domaine A peut pointer sur un label dans un domaine B. C'est l'un des buts de ce RRTYPE, tout comme DNAME pour un sous-arbre. Source : RFC 2181, section 10.1 - « The DNS CNAME ("canonical name") record exists to provide the canonical name associated with an alias name.  There may be only one such canonical name for any one alias. That name should generally be a name that exists elsewhere in the DNS, though there are some rare applications for aliases with the accompanying canonical name undefined in the DNS »

    * Oui, il n'est pas conseillé (mais pas interdit) de chaîner les CNAME. Source : RFC 1034, section 5.2.2 - « Multiple levels of aliases should be avoided due to their lack of efficiency, but should not be signalled as an error. Alias loops and aliases which point to non-existent names should be caught and an error condition passed back to the client. »

    * Il est interdit de mettre un alias comme valeur d'un enregistrement de type MX ou NS. Source : RFC 2181, section 10.3 - « The domain name used as the value of a NS resource record, or part of the value of a MX resource record must not be an alias.  Not only is the specification clear on this point, but using an alias in either of these positions neither works as well as might be hoped, nor well fulfills the ambition that may have led to this approach. »

    * Pareil pour le RRTYPE SRV. Source : RFC 2782, - « The domain name of the target host.  There MUST be one or more address records for this name, the name MUST NOT be an alias (in the sense of RFC 1034 or RFC 2181). »

    * Il faut au moins 2 serveurs qui font autorité par zone même si c'est pas « MUST » mais « require ». RFC 2182, section 4.3.5 - « The DNS specification and domain name registration rules require at least two servers for every zone.  That is, usually, the primary and one secondary. [...] It is recommended that three servers be provided for most organisation level zones, with at least one which must be well removed from the others. »

    * Un paquet DNS n'est pas limité à 512 octets sur UDP. C'est tout l'intérêt de edns(0) normalisé en  1999. Source : RFC 2671, section 2.3 - « DNS Messages are limited to 512 octets in size when sent over UDP. While the minimum maximum reassembly buffer size still allows a limit of 512 octets of UDP payload, most of the hosts now connected to the Internet are able to reassemble larger datagrams. Some mechanism must be created to allow requestors to advertise larger buffer sizes to responders. »

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