Framapic est de retour !

Et on vous explique un peu ce qui s’est passé.

Cela ne vous a peut-être pas échappé, Framapic, notre service de partage d’images, est subitement devenu indisponible le vendredi 17 août. Nous l’avons relancé lundi 24 septembre.

Nous ne l’avons pas coupé de gaieté de cœur, mais c’était soit la coupure du service Framapic, soit la coupure de l’IP du serveur, ce qui aurait entraîné l’arrêt de l’ensemble des services hébergés sur ce dernier.

Responsabilité du fournisseur de service

Nous avons déjà été contactés par diverses institutions ou organisations pour des problèmes de photos de drogue, d’armes ou de pédopornographie déposées sur Framapic.

Et oui, parmi ces institutions figurent des autorités judiciaires.

Il est de notre responsabilité d’hébergeur de réagir promptement aux demandes de suppression (lorsqu’elles sont fondées) ou aux requêtes judiciaires. Le problème est lorsque le demandeur contacte directement notre hébergeur, Hetzner. En effet, lorsque Hetzner nous transmet le signalement, celui-ci s’accompagne d’un délai d’une heure pour réagir avant la coupure de l’adresse IP du serveur.

Escalade

Au mois d’août, alors que jusqu’ici nous n’avions que peu de signalements, nous avons fait face à une vague de plusieurs signalements par semaine. Si nous avons toujours promptement réagi, Hetzner s’est lassé de ces signalements à répétition… et nous a laissé 24 heures pour migrer framapic.org hors de son réseau, avec toujours une menace de coupure.

Il fut donc décidé de mettre Framapic hors-ligne, de déplacer le nom de domaine vers un serveur situé chez un autre hébergeur et de ne fournir qu’une copie statique de la page de l’incident de notre site de statut : notre adminSys avait fini sa journée et commençait ses vacances… (il est quand même revenu sur le pont en urgence).

Toute requête demandant une image renvoyait (normalement) une capture d’écran du message de notre page d’incident.

Délai

Les vacances de l’adminSys se terminent, mais la rentrée ne commence pas par la remise en service de Framapic. Nous avons essayé de convaincre Hetzner de bien vouloir nous laisser remettre Framapic sur leurs serveurs, mais ce fut en pure perte.

Nous avons donc décidé de déplacer Framapic chez un autre hébergeur, avec un compte qui lui sera dédié afin de ne pas mettre en péril d’autres services si le cas se représentait.

Le rattrapage du travail en attente accumulé pendant les vacances a retardé la location du nouveau serveur… et ensuite il fallut attendre plus ou moins 24 heures que celui-ci soit mis à notre disposition (ce qui fut une surprise, habitués que nous sommes au quart d’heure maximum d’attente pour la même opération chez Hetzner).

Remise en service et limitations

Enfin, Framapic est de retour ! Mais pour éviter de nouveaux soucis, nous sommes obligés de mettre en place quelques limitations.

Ainsi, les nœuds de sortie du réseau Tor sont bannis. Il nous est douloureux d’en arriver là, convaincus que nous sommes de l’utilité de Tor pour des usages légitimes, mais comme un nombre conséquent de signalements concernaient des images envoyées via Tor, cette limitation s’est imposée.

Toute IP ayant envoyé une image ayant fait l’objet d’un signalement légitime sera définitivement bannie du service. Nous le faisions déjà quasi-systématiquement mais il nous arrivait d’oublier de le faire : certains signalements arrivaient pendant le weekend ou tard le soir, la priorité était la suppression des images signalées. Nous n’oublierons plus le bannissement.

Nous nous réservons le droit, si cela devenait nécessaire, de mettre en place d’autres types de blocage (geoIP ou autre joyeusetés), même si cela ne nous enthousiasme pas.

De l’intérêt des CHATONS

Framasoft a impulsé le collectif https://chatons.org justement pour éviter que les services proposés par notre association ne deviennent des “points centraux” du réseaux.

Ainsi, pendant la coupure de Framapic, vous pouviez toujours trouver d’autres chatons proposant un service équivalent (la recherche sur le site chatons.org retourne 14 membres proposant un tel service). Même si cette carte n’est pas forcément très à jour (hum), on peut rapidement trouver quelques services alternatifs, par exemple :

CHATONS est un collectif encore en construction, mais on voit ici tout l’intérêt de la décentralisation.

Ne dépendez pas de services tiers

Avant la coupure de Framapic, celui-ci faisait peiner le serveur sous le poids des nombreuses visites. Nous avions alors regardé d’où provenaient les requêtes en loguant les en-têtes Referer (et seulement cela, pour préserver votre vie privée, mais il fallait qu’on sache d’où venait le problème).

Quelle ne fut pas notre surprise lorsque nous nous sommes rendu compte que certains sites utilisaient Framapic pour stocker… les assets de leur site. Autrement dit, les images affichées sur le site web ne proviennent pas de leur hébergement (c’est à dire la machine hébergeant les pages web), mais sont récupérées depuis Framapic.org. Et il ne s’agissait pas que de blogs personnels, hein ! Des sites institutionnels en .gouv.fr utilisaient cette même mauvaise pratique ! (tous créés par la même entreprise qui n’a pas répondu à notre mail de contact leur demandant de ne pas le faire… mais qui a fini par cesser. Forcément, avec plus d’un mois d’images toutes cassées 😁)

Pourquoi cela est-il une très mauvaise pratique ?

  1. si le site tiers est indisponible, comme ce fut le cas de Framapic, le site ne ressemble plus à rien (ce fut assez drôle de voir les sites institutionnels évoqués plus haut remplis de la capture d’écran de l’incident 😁) ;
  2. si vos visiteurs bloquent les sites tiers avec une extension type uMatrix, le site ne ressemble plus à rien ;
  3. dans le cas de Framapic, cela induit une forte charge sur notre serveur : en effet, les images sont déchiffrées (bien que nous ayons un système de cache, celui-ci n’est pas extensible à l’infini) et chaque visite implique des requêtes en base de données ;
  4. sérieusement, mettre ses images sur le serveur du site ne le ralentira pas (à moins que vous n’hébergiez énormément d’images très lourdes).

Framapic a été pensé comme un moyen simple de partager des images (photos de vacances, captures d’écran…), ce n’est pas un CDN.

 

La morale de la fable

Nous espérons que ce petit article aura permis à certain⋅e⋅s d’apprendre au passage quelques petites choses sur les coulisses d’un service d’hébergement d’images et notre pratique à Framasoft :

  • nous respectons la loi si un signalement est justifié ;
  • dépendre d’un hébergeur revient à se soumettre à ses conditions — et à dépendre de sa disponibilité — d’où l’intérêt d’en choisir un avec soin (vive les CHATONS !), ou mieux, lorsque c’est possible, de s’auto-héberger ;
  • notre Framapic n’est pas destiné à héberger des images qui s’affichent sur un site web.



Fournisseurs d’emails, arrêtez de faire de la merde ! (#PasMonCaca)

Cet article fait écho à mon précédent article sur le pouvoir de nuisance des silos de mail.

Dans cet article, je pestais contre le pouvoir ahurissant que confère une grosse base d’utilisateurs à certains fournisseurs de mail (Gmail, Yahoo, etc).

En effet, il est quasiment impensable pour quiconque envoie des mails de passer outre leurs façons de faire, sous peine de se couper d’une grande partie des internautes.

Quand bien même on se conforme à leurs desiderata, quand bien même on met en place toutes les bonnes pratiques existantes, certains fournisseurs de mail ne font pas leur travail correctement…

Nota Bene : Framasoft n’est pas la seule structure à rencontrer les problèmes décrits ci-dessous. Des universités aux entreprises en passant par les google groups, on trouve des témoignages un peu partout sur le Web de mails qui n’arrivent pas à destination, et les administrateurs systèmes échangent souvent entre eux pour savoir si ça vient d’eux ou du serveur d’en face (vous aurez déjà deviné, d’après le titre de cet article, d’où vient généralement le problème).

“Postman.” par Alexander, William (1767-1816) licence CC0 1.0

Florilège

À tout seigneur, tout honneur, commençons par laposte.net.

laposte.net

La Poste avait tout pour fournir un service de mail propre et performant : son histoire dans les communications remonte à loin (on peut faire remonter sa généalogie au XVe siècle avec la première poste d’État de Louis XI) et si nous avons tous eu une lettre ou un colis qui s’est perdu dans les méandres des centres de tri, force est de constater que ça fonctionnait quand même très bien. En 2000, la Poste, encore entreprise publique, devait pouvoir fournir une adresse électronique à tous les Français⋅e⋅s.

Comment ne pas lui faire confiance ? Nous-mêmes, libristes avons, pendant longtemps, conseillé laposte.net à qui nous demandait un fournisseur de mail « propre », qui n’espionne pas les conversations, ne met pas de publicité…

Les choses ont bien changé.

Le prestataire de la Poste (ah bah oui, c’est un sous-traitant, vous n’imaginiez quand même pas que la Poste allait avoir des compétences en interne à l’heure des suppressions de postes de fonctionnaires ?) semble être, excusez le terme, un vrai branquignol : nous avons souvent des messages d’erreur comme 421 4.3.2 All server ports are busy (les serveurs ne sont pas correctement dimensionnés), 550 5.5.0 Service refuse. Veuillez essayer plus tard. service refused, please try later. LPN007_510 (« nope, on veut pas, revenez plus tard ») ou mon préféré, 451 4.7.1 Service unavailable – try again later (tout est vautré).

Ça fait des mois que les serveurs de laposte.net plantent régulièrement, avec en point d’orgue une panne qui a duré plusieurs jours en avril et une communication qui a mis plusieurs jours à arriver (un message pour dire qu’il y a un problème serait-il un aveu de faiblesse pour eux ?).

Résultat :

  • les mails s’accumulent sur nos serveurs, et comme on retente de les envoyer pendant quelques jours, eh bien ça ralentit le traitement des autres mails (bon, maintenant, j’ai mis en place des mailqueues séparées, mais ce n’est pas quelque chose que je devrais avoir à mettre en place !) ;
  • les utilisateurs ne reçoivent pas leurs mails de confirmation d’inscription à nos services ;
  • qui les utilisateurs contactent-ils ? Ah bah non, pas le support de la Poste, ce serait trop simple. Non, non, c’est nous. Et c’est usant. Non pas de vous répondre, mais le fait que ce soit 95 % du temps la faute à votre fournisseur de mail qui ne fait pas correctement son boulot.

Orange (wanadoo)

Ah, Orange. Tout un poème…

L’opérateur historique qui, lui aussi, a bénéficié de son aura d’ancien service public pour capter une grande majorité des internautes français lorsque vint l’heure de se choisir son premier FAI. Du coup, beaucoup de personnes ont encore une adresse wanadoo. Et comme Orange est le FAI majoritaire en France, encore plus de personnes ont une adresse orange.

J’avais déjà parlé dans mon précédent article de sa sale manie de ne pas accepter qu’on lui envoie trop de mails en une seule connexion. Imaginez un quidam qui refuse que son facteur lui apporte plus de trois lettres par tournée. Le facteur doit donc se représenter plusieurs fois s’il a plus de trois lettres à délivrer. C’est débile. Orange fait ça, mais pour le mail.

C’est le seul fournisseur que je connaisse qui impose ce genre de limite (qu’on ne vienne pas me dire que c’est pour lutter contre le spam : comment font les autres ? Hein ? Orange n’aurait pas les capacités financières et techniques de lutter plus proprement contre le spam ?).

Heureusement, ça se règle facilement, mais tout de même.

Et puis, de temps en temps, pouf, il rejette nos mails à coup de 550 5.2.0 Mail rejete. Mail rejected. ofr_506. Pourquoi ? Va savoir. Et ça se débloque tout seul au bout d’un temps.

Free

Après l’opérateur historique, voici celui qu’on surnomme le trublion du net. De temps en temps, celui-ci semble modifier les règles de son antispam, et nous voilà avec des mails 550 spam detected, quand bien même c’est le 300e mail quasi identique que nous envoyons de la journée. Et puis ça s’en va et ça revient.

Pareil avec 451 too many errors from your ip, ça bloque de temps en temps et ça repart comme c’est venu… alors qu’il s’agit majoritairement de mails de notification (framapiaf, framasphere, framagit…) et donc que les adresses ont été vérifiées ! Certes, il peut y avoir des erreurs, mais tellement peu dans le volume de mails que nous envoyons à Free… Ça arrive vraiment de façon aléatoire. Grmpf.

Facebook

On l’oublie, mais Facebook, en 2010, a proposé d’avoir une adresse mail @facebook.com (bon, ils ont arrêté les inscriptions en 2014, ce qui explique l’oubli). Et certaines personnes utilisent encore ces adresses.

Nos mails étaient bloqués de temps à autre avec un code 554 5.7.1 POL-P4 Connection refused, ce qui veut dire en gros « Revenez dans 24 ou 48 heures ». En soi, ce n’était pas forcément délirant, si jamais nous avions, pour une raison ou pour une autre, envoyé beaucoup de mails d’un coup à leurs serveurs. Mais depuis quelques semaines, il n’y a plus de déblocage : nos mails ne partent plus pour facebook.com, même en les faisant partir d’un autre serveur ou en diminuant la vitesse d’envoi.


Voilà pour les fournisseurs de mails qui font n’importe quoi avec leurs serveurs. Ils présentent tout de même l’avantage de nous permettre de comprendre pourquoi les destinataires n’ont pas reçu leurs mails, fût-ce pour de stupides raisons. Mais il y en a de plus vicieux…

Ceux qui n’amènent pas les mails à leurs destinataires (ou qui les cachent)

On ne les connaît pas bien, ce n’est que lorsque l’on nous contacte pour et que nous voyons que le mail est bien parti qu’on les repère : les fournisseurs de mails qui acceptent nos mails mais, pour une raison ou pour une autre, les envoient rejoindre le grand rien.

Eh oui, nos mails disparaissent parfois sur le serveur de votre fournisseur de messagerie. Vous ne les trouverez dans aucun dossier, pas même dans les spams.

Il s’agit le plus souvent de choix algorithmiques du fournisseur : l’antispam est vraiment sûr que ce message est frauduleux ? Bah, pas la peine d’embêter l’utilisateur, on le jette ! (ce qui est stupide car ne permettant pas la correction des faux positifs par les utilisateurs).

Encore mieux, Gmail. Comme expliqué dans notre FAQ, si vous recevez un mail identique à un que vous avez envoyé, comme un message à une framaliste à laquelle vous êtes inscrit, Gmail cachera le mail reçu de la liste. Vous l’avez envoyé, vous en connaissez le contenu, non ? Ah, vous vouliez voir quand le message arriverait, histoire d’être sûr qu’il a bien été traité par notre serveur de listes ? Pas de bol.

Ceux qui proposent une application pourrie

Les personnes qui utilisent l’application de mail Orange sur leur téléphone ont des soucis pour envoyer des messages à des framalistes. Après investigation, nous nous sommes rendus compte que l’application met l’adresse de la liste (enfin un dérivé, elle met l’adresse dédiée à la réexpédition des mails reçus par la liste) dans l’en-tête Sender.

Que cela veut-il dire et pourquoi est-ce un problème ? Cela fait croire que le mail provient du serveur des framalistes. Comme notre serveur n’est pas stupide, voyant un mail provenant soit-disant de lui-même mais passant par un serveur non-autorisé à envoyer des mails framalistes, celui-ci refuse le mail. Tout simplement. C’est une des techniques classiques de lutte contre le spam que d’agir ainsi.

“cow dung patties” par mary jane watson licence CC BY 2.0

Conclusion

Les problèmes face aux gros silos de mail sont nombreux, et sont loin d’être tous dus à une mauvaise configuration de votre serveur mail que vous chouchoutez vous-même (ou de ceux que nous configurons… Non vraiment, c’est pas nous qui pondons de telles bouses ! D’où ce joli hache-tague : c’est #PasMonCaca).

Je pense personnellement et sincèrement qu’il y a une part d’incompétence de la part de ces silos dans un certain nombre de cas. Si tout le monde jouait le jeu correctement, le mail ne serait pas aussi compliqué qu’aujourd’hui.

Que pouvez-vous faire ? Eh bien, à part changer de fournisseur de mail (connaissez-vous les CHATONS ?), vous pouvez contacter le support de votre fournisseur actuel, lui expliquer la situation et lui dire que ce n’est pas normal. Nous pouvons vous fournir, le cas échéant, les codes d’erreur retournés par son serveur pour les mails que nous vous envoyons. Peut-être qu’en étant suffisamment nombreux à râler, la situation évoluera.

Fun fact : combien des fournisseurs de mail évoqués dans cet article permettent de contacter leur serveur de mail en IPv6 ? Un seul — je vous laisse chercher lequel 😁

(Et si vous vous posez la question, oui, les serveurs de framasoft.org et framalistes.org sont accessibles en IPv6, comme toute l’infrastructure de Framasoft. Quand on veut, on peut.)

Image d’en-tête par barefootcollege, source.




Le transit, c’est important 🙂

Non, nous n’allons vous parler de fibres (quoique). C’est du transit d’Internet que nous allons parler. Ou plutôt, nous allons laisser Stéphane Bortzmeyer en parler.

Son article nous a séduits, aussi bien par la thématique abordée (on ne se refait pas, quand les GAFAM menacent l’avenir d’Internet, on aime bien que ce soit dit 😃) que par son aspect didactique, truffé d’hyperliens permettant à tout un chacun de le comprendre. Nous le reproduisons ici, avec son aimable permission et celle de la licence (libre, bien sûr) de l’article, la GFDL et avec quelques photos en plus (dont un chaton, je viens de dire qu’on ne se refaisait pas 😁).

Stéphane Bortzmeyer est bien connu du milieu technique pour ses articles sur les RFC (Request For Comments) et autres articles techniques plutôt que pour des textes à destination de la famille Dupuis-Morizeau mais ses fiches de lecture pourraient bien les intéresser.

Carte de l’Internet : vous êtes ici.

Le transit Internet est-il vraiment mort ?

À la réunion APRICOT / APNIC du 20 février au 2 mars, à Hô-Chi-Minh-Ville, Geoff Huston a fait un exposé remarqué, au titre provocateur, « The death of transit ». A-t-il raison de prédire la fin du transit Internet ? Et pourquoi est-ce une question importante ?

Deux petits mots de terminologie, d’abord, s’inscrivant dans l’histoire. L’Internet avait été conçu comme un réseau connectant des acteurs relativement égaux (par exemple, des universités), via une épine dorsale partagée (comme NSFnet). Avec le temps, plusieurs de ces épines dorsales sont apparues, l’accès depuis la maison, l’association ou la petite entreprise est devenu plus fréquent, et un modèle de séparation entre les FAI et les transitaires est apparu. Dans ce modèle, le client se connecte à un FAI. Mais comment est-ce que les FAI se connectent entre eux, pour que Alice puisse échanger avec Bob, bien qu’ils soient clients de FAI différents ? Il y a deux solutions, le peering et le transit. Le premier est l’échange de trafic (en général gratuitement et informellement) entre des pairs (donc plus ou moins de taille comparable), le second est l’achat de connectivité IP, depuis un FAI vers un transitaire. Ces transitaires forment donc (ou formaient) l’épine dorsale de l’Internet. Le modèle de l’Internet a été un immense succès, au grand dam des opérateurs téléphoniques traditionnels et des experts officiels qui avaient toujours proclamé que cela ne marcherait jamais.

Mais une autre évolution s’est produite. Les utilisateurs ne se connectent pas à l’Internet pour le plaisir de faire des ping et des traceroute, ils veulent communiquer, donc échanger (des textes, des images, des vidéos…). À l’origine, l’idée était que l’échange se ferait directement entre les utilisateurs, ou sinon entre des serveurs proches des utilisateurs (ceux de leur réseau local). Le trafic serait donc à peu près symétrique, dans un échange pair-à-pair. Mais les choses ne se passent pas toujours comme ça. Aujourd’hui, il est de plus en plus fréquent que les communications entre utilisateurs soient médiées (oui, ce verbe est dans le Wiktionnaire) par des grands opérateurs qui ne sont pas des opérateurs de télécommunication, pas des transitaires, mais des « plates-formes » comme les GAFA (Google, Apple, Facebook, Amazon). La communication entre utilisateurs n’est plus pair-à-pair mais passe par un intermédiaire. (On peut parler d’un Minitel 2.0.)

Non, on n’a pas trop envie d’un Internet à la Minitel 2.0

Bon, mais quel rapport avec l’avenir de l’Internet ? Mes lect·eur·rice·s sont très cultivé·e·s et savent bien que le Web, ce n’est pas l’Internet, et que le fait que deux utilisateurs de Gmail passent par Gmail pour communiquer alors qu’ils sont à 100 mètres l’un de l’autre n’est pas une propriété de l’Internet. (Les ministres et la plupart des journalistes n’ont pas encore compris cela, mais ça viendra). L’Internet continue à fonctionner comme avant et on peut toujours faire du BitTorrent, et se connecter en SSH avec un Raspberry Pi situé à l’autre bout de la planète (notez qu’il s’agit de l’Internet en général : dans la quasi-totalité des aéroports et des hôtels, de nombreux protocoles sont interdits. Et ces malhonnêtes osent prétendre qu’ils fournissent un « accès Internet »).

C’est là qu’on en arrive à l’exposé de Huston. Il note d’abord que les sites Web qui ne sont pas déjà chez un GAFA sont souvent hébergés sur un CDN [un réseau de diffusion de contenu, Note du Framablog]. Ensuite, il fait remarquer que les GAFA, comme les CDN, bâtissent de plus en plus leur propre interconnexion. À ses débuts, Google était une entreprise comme une autre, qui achetait sa connectivité Internet à un fournisseur. Aujourd’hui, Google pose ses propres fibres optiques (ou achète des lambdas) et peere avec les FAI : encore un peu et Google n’aura plus besoin de transit du tout. Si tous les GAFA et tous les CDN en font autant (et la plupart sont déjà bien engagés dans cette voie), que deviendra le transit ? Qui pourra encore gagner sa vie en en vendant ? Et si le transit disparaît, l’architecture de l’Internet aura bien été modifiée, par l’action de la minitélisation du Web. (Je résume beaucoup, je vous invite à lire l’exposé de Huston vous-même.)

Notez que Huston n’est pas le premier à pointer du doigt cette évolution. Plusieurs articles moins flamboyants l’avaient déjà fait, comme les déjà anciens « The flattening internet topology: natural evolution, unsightly barnacles or contrived collapse? » ou « Internet Inter-Domain Traffic ». Mais Huston réussit toujours mieux à capter l’attention et à résumer de manière percutante un problème complexe.

Alors, si Huston a raison, quelles seront les conséquences de la disparition du transit ? Huston note qu’une telle disparition pourrait rendre inutile le système d’adressage mondial (déjà très mal en point avec l’épuisement des adresses IPv4 et la prévalence du NAT), voire le système de nommage mondial que fournit le DNS. Le pair-à-pair, déjà diabolisé sur ordre de l’industrie du divertissement, pourrait devenir très difficile, voire impossible. Aujourd’hui, même si 95 % des utilisateurs ne se servaient que des GAFA, rien n’empêche les autres de faire ce qu’ils veulent en pair-à-pair. Demain, est-ce que ce sera toujours le cas ?

Mais est-ce que Huston a raison de prédire la mort du transit ? D’abord, je précise que je suis de ceux qui ne croient pas à la fatalité : ce sont les humains qui façonnent l’histoire et les choses peuvent changer. Décrire la réalité, c’est bien, mais il faut toujours se rappeler que c’est nous qui la faisons, cette réalité, et que nous pouvons changer. Essayons de voir si les choses ont déjà changé. Huston aime bien provoquer, pour réveiller son auditoire. Mais il faut bien distinguer l’apparence et la réalité.

Les observateurs légers croient que tout l’Internet est à leur image. Comme eux-mêmes ne se servent que de Gmail et de Facebook, ils expliquent gravement en passant à la télé que l’Internet, c’est Google et Facebook. Mais c’est loin d’être la totalité des usages. Des tas d’autres usages sont présents, par exemple dans l’échange de données entre entreprises (y compris via d’innombrables types de VPN qui transportent leurs données… sur Internet), les SCADA, BitTorrent, la recherche scientifique et ses pétaoctets de données, les réseaux spécialisés comme LoRa, les chaînes de blocs, et ces usages ne passent pas par les GAFA.

Peut-on quantifier ces usages, pour dire par exemple, qu’ils sont « minoritaires » ou bien « un détail » ? Ce n’est pas facile car il faudrait se mettre d’accord sur une métrique. Si on prend le nombre d’octets, c’est évidemment la vidéo qui domine et, à cause du poids de YouTube, on peut arriver à la conclusion que seuls les GAFA comptent. Mais d’autres critères sont possibles, quoique plus difficiles à évaluer (le poids financier, par exemple : un message d’une entreprise à une autre pour un contrat de centaines de milliers d’euros pèse moins d’octets qu’une vidéo de chat, mais représente bien plus d’argent ; ou bien le critère de l’utilité sociale). Bref, les opérateurs de transit sont loin d’être inutiles. L’Internet n’est pas encore réduit à un Minitel (ou à une télévision, l’exemple que prend Huston qui, en bon australien, ne connaît pas ce fleuron de la technologie française.)

La photo d’un chaton est-elle plus utile socialement qu’un contrat de plusieurs milliers d’euros ? Vous avez deux heures.

Merci à Antoine Fressancourt, Jérôme Nicolle, Pierre Beyssac, Raphaël Maunier, Olivier Perret, Clément Cavadore et Radu-Adrian Feurdean pour leurs remarques intéressantes. Aucune de ces conversations avec eux n’est passée par un GAFA.

Cet article est distribué sous les termes de la licence GFDL

Stéphane Bortzmeyer

Crédits :




Les Gitlab Pages débarquent dans Framagit !

La création d’un site web depuis votre compte Framagit est beaucoup plus souple, et c’est une belle victoire pour le libre !

Attention : ce billet comporte des éléments techniques… Si vous avez un compte Framagit et/ou si vous vous intéressez à la création d’un site web statique depuis un dépôt Git, il est fait pour vous ! Si vous n’avez pas tout compris à cette phrase, la suite va vous paraître délicieusement absurde :p !
NB : l’édition communautaire de Gitlab est la version libre de la forge logicielle Gitlab, qui existe aussi en version non-libre, appelée version entreprise. Bien évidemment, nous utilisons la version libre pour fournir le service Framagit 🙂

Qu’est‐ce que GitLab Pages ?

À l’instar des pages Github, les pages GitLab permettent à toute personne possédant un dépôt sur une instance de GitLab de créer un site Web via un générateur de site statique (Jekyll, Middleman, Hexo, Hugo, Pelican…) et de l’héberger sur l’infrastructure dudit GitLab.

La compilation du site est effectuée lors du push vers le dépôt GitLab, via le système d’intégration continue de GitLab, puis le résultat est publié à l’endroit idoine pour être accessible via le Web. Il est possible d’utiliser un nom de domaine personnel (il n’est pas obligatoire d’utiliser une adresse du style https://username.gitlab.io), ainsi qu’un certificat personnel.

Et ça sert ?

Oui !

Les pages GitHub sont très souvent utilisées par les développeurs pour fournir une page de présentation de leurs projets, même les plus gros : Ruby on Rails, Django, React…

Les pages GitLab sont donc susceptibles d’être tout autant utilisées que les pages GitHub. La demande est là.

Mais on avait pas déjà un truc comme ça ?

Tout à fait ! J’avais créé Fs Pages pour fournir un service similaire mais plus limité que les Gitlab Pages car Gitlab ne souhaitait pas les intégrer à leur édition communautaire.

Il était possible de publier un site statique via Fs Pages mais la génération du site devait se faire avant de pousser le code : point de génération automatique. De plus, il n’était pas possible d’utiliser un nom de domaine personnel. Votre site statique répondait uniquement via l’adresse https://votre_utilisateur.frama.io.

Le long chemin de la libération

Nous n’allons pas refaire l’historique complet de la libération des Gitlab Pages, surtout que celui-ci est disponible sur LinuxFr. Mais un petit résumé succinct ne fera pas de mal.

Tout a commencé par un tweet de votre serviteur demandant à Gitlab s’il était envisageable d’avoir les Gitlab Pages dans l’édition communautaire de Gitlab (pas la peine de chercher les tweets en question, j’ai fermé mon compte twitter). Gitlab a ouvert un ticket pour discuter de cela.

Gitlab a exposé au fil du temps trois arguments :

  • seules les fonctionnalités utiles aux instances de moins de 100 utilisateurs peuvent aller dans l’édition communautaire (et pour eux, cela n’était pas le cas de Gitlab Pages)
  • https://gitlab.com, qui utilise la version entreprise — donc avec les Gitlab Pages — est libre d’utilisation pour tout un chacun, et contrairement à Github, les dépôts privés sont gratuits
  • les Gitlab Pages sont une fonctionnalité qui ajoute une réelle plus-value à l’édition entreprise : comment vendre leur produit si une des fonctionnalités majeures est déjà dans l’édition communautaire ?

Il est à noter que Gitlab nous a proposé d’utiliser la version entreprise avec un rabais, ce qui est tout à leur honneur, mais comme nous ne souhaitons utiliser que du logiciel libre, nous avons décliné (évidemment 😀)

La communauté a fait valoir que Gitlab Pages n’intéressait pas que les grandes instances, qu’utiliser https://gitlab.com ou Github revenait au même puisque cela équivaut à utiliser du logiciel propriétaire, proposa un financement participatif pour financer la libération et enfin avança que les Gitlab Pages feraient une bonne publicité à Gitlab, les développeurs utilisant de plus en plus fréquemment ce genre de solution pour héberger leurs sites ou leurs blogs. Et même si j’ai horreur de cet argument de notoriété, force m’est d’avouer qu’il a su faire mouche (ainsi que les plus de 100 « 👍 » du ticket) : la libération fut annoncée peu de temps après celui-ci !

En tout, la discussion a duré près de onze mois. Les échanges furent cordiaux et la communauté, opiniâtre, a su faire valoir ses arguments.

Bref, une bien belle victoire pour le libre qui voit là un logiciel apprécié se doter d’une nouvelle fonctionnalité très attendue !

Bon, et maintenant ?

Depuis la mise à jour de Framagit du 2 mars dernier, toute personne possédant un dépôt sur Framagit peut, via les Gitlab Pages, créer et héberger un site sur notre infrastructure, que ce soit en sous-domaine de frama.io (comme moi 😊) ou avec un domaine privé (auquel cas il faudra faire pointer un enregistrement DNS vers les IPs de frama.io : 144.76.206.44 et 2a01:4f8:200:1302::44 ou créer un enregistrement DNS de type CNAME vers frama.io.), avec ou sans certificat.

La documentation de Gitlab sur l’utilisation des Gitlab Pages (en anglais) est très complète et propose même un grand nombre de modèles sur lesquels vous baser. D’Hugo à Pelican en passant par des pages statiques développées à la main, il y en a pour tous les goûts !

Il n’y a que deux ombres au tableau :

  • l’utilisation de certificats Let’s Encrypt n’est pas aisée mais un ticket est ouvert chez Gitlab pour intégrer directement Let’s Encrypt aux Gitlab Pages
  • il n’y a pas de redirection automatique vers la version sécurisée (https) de votre site, quand bien même vous fourniriez un certificat ou que vous utilisiez un sous-domaine de frama.io (ce qui vous fournit automatiquement une version https de votre site grâce à notre achat d’un certificat wildcard (certificat valant pour le domaine et tous ses sous-domaines)). Un ticket est cependant ouvert chez Gitlab à ce sujet. En attendant, pour rediriger vos visiteurs vers la version https de votre site, vous pouvez néanmoins inclure ce petit bout de JavaScript dans vos pages :
    <script>
    var loc = window.location.href+'';
    if (loc.indexOf('http://')==0){
        window.location.href = loc.replace('http://','https://');
    }
    </script>

Le framablog n’étant pas un blog technique, nous ne étendrons pas plus sur les ficelles de Gitlab Pages : on va laisser ça pour notre site dédié à la documentation de nos services.

Au 20 mars, nous sommes déjà 31 (oui, bon, ok, sur 7 560 utilisateurs, ça fait peu) à avoir commencé à bidouiller sur les Gitlab Pages de Framagit (contre 53 quand nous proposions FsPages). Continuez comme ça ! 🙂

Crédits image :




Notre gitlab évolue en Framagit. C’est très efficace !

Warning : cet article parle de forge logicielle qui sert à développer collaborativement du code. Il est donc un peu velu et technique, mais il fera plaisir aux plus « barbu-e-s » d’entre vous !

Préviousselaid, chez Framasoft : nous avions besoin d’une forge logicielle comme outil interne à l’asso… parce que même si nous ne développons pas (ou exceptionnellement) de logiciel libre ; les mettre en avant, les améliorer (parfois), les promouvoir et ouvrir des services au monde, ben ça demande de créer, maintenir, échanger et améliorer du code !

Nous nous étions donc installé Gitlab à la main, sur un coin de serveur, juste pour nous…  Étant les seuls utilisateurs, on s’est dit que ce ne serait pas grave s’il n’était pas toujours à jour, à traquer la dernière version… (oui : nous sommes moins exigeants sur nos outils internes que pour les services que nous ouvrons au grand public ^^).

Franchement, merci Google !

Merci, parce qu’à chaque fois que vous prenez des décisions unilatérales aux dépens de vos utilisateurs-produits, vous nous offrez l’occasion de prouver que le Libre offre des alternatives bien plus respectueuses des personnes qui vous ont confié leur vie numérique (et leur code).

Le jour où nous avons appris que Google Code fermait ses portes, nous avons donc décidé d’ouvrir les nôtres. Cela nous a aussi permis de sensibiliser au fait que, dans le mode des codeurs et développeuses, GitHub est devenu un point central et monopolistique assez inquiétant.

githubdown L’excuse n°1 des programmeurs pour se lâcher sans scrupules : « GitHub est en panne » — Hé, au boulot les gars ! — Github est en panne ! — Ah bon, continuez alors.
L’excuse n°1 des programmeurs pour se lâcher sans scrupules :
« GitHub est en panne »

— Hé, au boulot les gars ! — Github est en panne !
— Ah bon, continuez alors.

 

Forcément, l’ouverture à tous de notre git et les nouvelles fonctionnalités des nouvelles versions de Gitlab (une nouvelle version tous les 22 du mois) nous ont incités à mettre à jour plus régulièrement, ce qui prend plusieurs heures à chaque fois… et plusieurs fois par mois, car des versions correctives sont régulièrement publiées.

Améliorer le Framagit… une priorité

Ceci, ajouté à l’utilisation grandissante de notre forge qui allait bientôt poser des problèmes de taille de disques, nous a amenés à migrer (le 17 mars dernier) notre Gitlab vers une machine avec plus de disque et surtout avec une installation utilisant les paquets dits « omnibus ».

Ces paquets omnibus nous ont permis d’installer Gitlab à l’aide d’un simple apt-get install gitlab-ce plutôt que de suivre la longue procédure d’installation manuelle. Non seulement l’installation est simplifiée, mais — et c’est surtout là la plus-value que nous en attendions — mettre à jour Gitlab devient tout aussi simple avec une seule commande apt-get dist-upgrade.

Résultat : notre Gitlab suit scrupuleusement la publication des nouvelles versions, avec leur lot de nouvelles fonctionnalités !

GitPourTous

Pour fêter cela, nous avons étrenné un nouveau nom de domaine… inspiré par vous ! Avouons-le, «Git point Framasoft point orrrrrrrgueh », ça accroche un peu en bouche. De partout, nous avons entendu parler du « Framagit » : alors tant qu’à faire, autant l’appeler comme vous le faites déjà. Bien entendu, il n’est nul besoin de modifier vos URL, elles restent valides… mais la nouvelle est à votre disposition !

Et si on ajoutait de l’intégration continue ?

Derrière ce terme barbare se cache une fonctionnalité très pratique : on crée une « recette » qui sera exécutée dans une machine virtuelle à chaque push. Cela peut par exemple permettre de lancer une suite de tests pour vérifier que l’on n’a rien cassé. 🙂

Pour utiliser cette fonctionnalité, il faut disposer de ce que l’on appelle un runner, c’est à dire un logiciel qui va récupérer la recette et l’exécuter. Il est possible d’installer un runner sur n’importe quel ordinateur, même votre ordinateur de bureau.

Pour ceux qui ne souhaitent pas gérer leur runner eux-mêmes, Framasoft met à disposition deux runners partagés entre tous les utilisateurs de Framagit, que vous pouvez utiliser comme bon vous semble. Notez toutefois que Gitlab indique que quiconque utilise un runner partagé peut accéder aux informations des projets utilisant ce runner : il vaut mieux monter votre propre runner pour vos projets sensibles.

De plus, en utilisant les runners partagés de Framasoft, il est possible que votre projet soit mis en file d’attente, en attendant que les recettes précédentes aient fini de s’exécuter… à vous de voir !

Pouhiou-le-moldu-du-code lisant cet article, allégorie.
Pouhiou-le-moldu-du-code lisant cet article, allégorie.

Vous voulez des pages Gitlab ? Nous aussi !

Github permet à tout un chacun d’héberger un site statique. Gitlab propose une fonctionnalité similaire mais hélas, uniquement dans sa version entreprise… Nous utilisons pour notre part la version communautaire qui est la version libre de Gitlab… donc sans les pages Gitlab.

Nous avons donc ouvert un ticket pour demander que cette fonctionnalité soit incluse dans la version communautaire. Si vous aussi vous aimeriez voir cela arriver, aidez-nous tout simplement en votant sur https://gitlab.com/gitlab-org/gitlab-ce/issues/14605.

En attendant, profitez d’une forge logicielle à jour et libre sur Framagit.org !

 

Mise à jour du 5/08/2016 :
Le tutoriel d’installation de Gitlab est -enfin- disponible sur le Framacloud.
Notez que cette installation est conjointe à celle de Mattermost (Framateam) puisque c’est ainsi que nous avons procédé 😉



Le poivre, la carotte et la sorcière : une interview de David Revoy

Trouver des auteurs de logiciels libres, c’est relativement simple. Il n’y a qu’à se pencher sur un paquet Debian pour en trouver. Trouver des artistes qui mettent leurs productions sous licence libre, c’est déjà un peu plus rare.

Connaissez-vous David Revoy ? Non ? Et pourtant, vous avez sans doute déjà vu des projets auxquels il a contribué. Il a en effet travaillé (entre autres) à plusieurs projets de la fondation Blender : Sintel, Tears of Steel

Mais c’est plutôt son webcomic Pepper & Carrot qui nous a poussés à l’interviewer. D’une rare qualité, les aventures de cette jeune sorcière et de son chat nous ont séduits, tant par les dessins magnifiques que par son humour.

Un auteur Open-Source

Bonjour David. Tu peux te présenter un peu ? Ton parcours, ton travail, tes projets…

Bonjour, j’ai 34 ans et je suis un Montalbanais passionné de dessin et d’informatique depuis l’enfance. Au cours de ces quinze dernières années, j’ai eu un parcours de freelance passant par l’illustration (couverture de livre et jeu de société), par le concept-art (décors/engins et persos dans les jeux vidéos) et parfois par la direction artistique de projets.
L’an dernier, j’ai créé Pepper&Carrot, un projet de webcomic libre et open-source financé grâces au mécénat des lecteurs. Peu après et grâce au succès de la série, j’ai décidé d’arrêter le freelance pour me consacrer à plein temps à la création de nouveaux épisodes et aux extras (traductions, tutoriaux, wiki, téléchargements gratuits…).

Tu expliques sur ton site pourquoi tu as choisi l’Open Source. Tu peux nous faire un petit résumé pour nos lecteurs qui ne maîtrisent pas la langue de Shakespeare ?

Je vais essayer de résumer ça mais tout d’abord je tenais à vous remercier, car j’ai abordé le libre entre 2003 et 2005 grâce au portail de Framasoft d’il y a dix ans. A l’époque j’utilisais Windows XP et cela m’a permis d’adopter Blender, Inkscape, Firefox, LibreOffice et FileZilla. Mon abandon total des logiciels propriétaires s’est fait peu de temps après. Je venais d’acheter un nouveau PC livré avec ‘Windows Vista’ pré-installé. J’avais une licence ‘XP pro’ en boîte et je comptais réinstaller ce système car tous mes logiciels dépendaient de ce système. Malheureusement pour moi, la carte mère du PC Vista n’avais pas de pilote pour XP disponible et mes licences logicielles professionnelles (Photoshop, Painter, Manga Studio; plusieurs milliers d’euros) était toutes instables avec Windows Vista. Mettre tout à jour était très coûteux et n’apportait aucunes nouvelles fonctionnalités.

Cette stratégie de mise à jour forcée me paraissait injuste. Je ne voulais pas alimenter les créateurs d’un tel système avec mon argent. C’est donc cet événement qui m’a poussé vers le 100% GNU/Linux. Voici une vidéo d’époque :

Cliquez sur l'image pour accéder à la vidéo (Viméo)
Cliquez sur l’image pour regarder la vidéo (Viméo)

Tu as travaillé sur pas mal de jeux vidéos. Pourquoi faire une BD ? C’était quelque chose qui te trottait dans la tête ou ça t’est arrivé comme ça ?

J’aime beaucoup les jeux vidéos et le cinéma d’animation, mais être auteur de bande-dessinée c’est mon rêve d’enfance. C’est la passion que j’ai toujours essayé de préserver. La BD, c’est l’art qui me touche le plus et celui dans lequel je m’exprime avec le plus de liberté. Pour la création de Pepper&Carrot, c’est vrai que c’est arrivé un peu « comme ça ». Tout a commencé un dimanche soir d’avril 2014 particulièrement calme, j’ai fait un speedpainting (une peinture numérique à la tablette graphique). J’ai enregistré ce qui ce passait à l’écran par coïncidence ce jour-là :

Cliquez sur l'image pour accéder à la vidéo (youtube)
Cliquez sur l’image pour voir la vidéo (Youtube)

J’avais là une petite sorcière, un chat, une scène… La semaine qui a suivi j’ai ajouté d’autres cases et cela a formé une petite histoire. L’épisode 1 est né ainsi.

Ce petit projet personnel a eu beaucoup de succès, alors j’ai décidé de faire un épisode 2. Puis 3, puis 4… Ce mois-ci, je fais l’épisode 14. L’audience me porte par son enthousiasme. C’est ainsi qu’est né et continue de grandir Pepper&Carrot; un pas devant l’autre, très connecté au présent.

Tu utilises des logiciels libres ou open-source, mais lesquels ? Et qu’est-ce qui t’as décidé à libérer tes œuvres ?

J’utilise essentiellement Krita sur Linux Mint. Mes outils secondaires sont Inkscape, Blender, Gimp, Mypaint, G’Mic et Imagemagick.

J’ai commencé à libérer mes œuvres à la Blender Foundation quand je travaillais sur la direction artistique du court-métrage Sintel. C’était dans le cahier des charges de mettre tous les dessins préparatoires en Creative Commons Attribution. J’ai pu donc faire l’expérience directe de travailler avec cette licence très ouverte au sein d’une grande audience. L’expérience fût très positive. C’est ainsi que j’ai appris à connaître, et ensuite adopté les licence Creatives Commons.

Tes projets sont sous licence CC-BY, CC-BY-SA, CC-BY-NC-ND, copyright classique… Qu’est-ce qui détermine la licence que tu utilises ?

C’est déterminé par des préoccupations juridiques. D’abord il y a les dessins qui sont tellement « copyrightés » par mes clients que je ne peux ni en parler et ni même les montrer. Ce sont les contrats de jeux-vidéos, de cinémas sous NDA (Non Disclosure Agreement : accord de non-divulgation) que j’ai remplis durant mes années freelance. Les dessins « copyrightés » simplement sont ceux où je reçois l’autorisation d’afficher le dessin en basse résolution sur mon site.

La licence CC-By-NC-ND encourage le partage Internet mais empêche les travaux dérivés, les modifications et l’utilisation commerciale. J’ai longtemps utilisé ceci pour mes travaux personnels plus activistes comme pour le « Yin-Yang de la faim dans le monde ». Des groupements politiques m’ont déjà démarché pour détourner ou s’approprier ce dessin. Leur donner l’autorisation d’office serait trop dangereux.

La licence CC-By-Sa, c’est celle qui offre tout, mais demande la mise à disposition des sources de l’œuvre sur une licence également libre. Une façon de forcer l’évolution du libre à rester libre.

La licence CC-By, c’est quand je décide de tout partager, et de ne garder que le crédit participatif à l’élaboration du dessin. C’est la licence que je trouve la plus libre et aussi la licence que j’ai choisie pour tout Pepper & Carrot.

Pepper & Carrot Holiday special

Il y a des personnes qui ne connaissent pas (encore) Pepper&Carrot… Comment tu les présenterais ?

Je les présenterais en BD, tel qu’ils le sont mais si je devais le faire avec que du texte, je passerais la main à ce petit texte issu de l’article de LinuxFr, par l’auteur Eingousef (édité par ZeroHeure, Yvan Munoz, BAud, M5oul, Benoît Sibaud et palm123 et modéré par ZeroHeure / Licence CC by-sa) :

Des personnages mignons, des chats, une influence manga/anime, de l’héroic-fantasy, des clins d’œil au logiciel libre, de l’humour décalé et de la poésie dans un univers épique, des licences libres et des sources complètes, des contributions à des logiciels libres et jeux libres… David Revoy a tout pour plaire aux geeks. Ce dessinateur aux multiples talents, qui s’est fait connaître dans la communauté du libre surtout par son impressionnant travail de concept artist sur les trois derniers Open Movies de la Blender Foundation (Sintel, Tears of Steel et le projet Gooseberry), s’est lancé l’année dernière dans la réalisation d’un webcomic libre, « Pepper & Carrot ». Celui-ci met en scène les aventures décalées de Pepper, une petite sorcière courageuse et casse-cou, mais qui a tendance à sous-estimer ses capacités, et de Carrot, son chat à l’intelligence quasi-humaine, mais éternel esclave de ses instincts, dans l’univers féerique du Royaume d’Hereva, avec ses villes volantes, ses fées, ses phénix, ses dragons-vaches, ses canards-drakes et ses sorcières rivales…

Le mode de financement de Pepper & Carrot est basé sur l’économie participative (Tipeee, Patreon, les dons…). Comment y es-tu venu ? Ça marche bien ?

J’y suis venu car je ne voulais pas proposer Pepper&Carrot aux éditeurs papier. L’édition est un milieu en crise que je connais assez bien grâce à mes années de travail dans l’illustration. Un univers ou la loi du marché prime sur tout. Pepper&Carrot aurait été sans doute dénaturé, standardisé, aseptisé et réduit au bon vouloir des commerciaux, des distributeurs, des actionnaires… du pognon pour le pognon. Quand on élimine la voie de l’édition classique, il ne reste plus grand chose pour exercer la BD à plein temps. Je ne suis ni riche ni « fils de » pour vivre de la BD sans en demander une contrepartie financière. J’ai un loyer mensuel à payer, un corps à nourrir, un matériel informatique à entretenir, donc solliciter le mécénat des lecteurs était ma seule possibilité.
De nos jours, ça marche grâce à la générosité des lecteurs. Financièrement, je suis loin de mes années freelance. Je gagne un petit SMIC pour autant d’heures de travail par semaine qu’il en est humainement supportable (sans congé, sans arrêts maladies, sans retraite). Mon projet en 2016 : arriver à maîtriser la production des épisodes et réduire les heures pour retrouver une vie personnelle en dehors de Pepper&Carrot (une coquetterie que je me suis refusée au cours des 15 derniers mois).

Tu as plein de rêves pour Pepper&Carrot… Comment t’es venue l’idée d’afficher ces douces ambitions ? Cette liste avance bien ?

Pour l’idée, je me suis dit que d’afficher clairement mes rêves et mes motivations aiderait les visiteurs du site à me connaître.

Est ce que ça avance ? Difficile à évaluer pour certain rêves. Par exemple pour le rêve numéro 1 : « Donner une conférence au Japon dans une convention Manga à propos de Pepper&Carrot » c’est super difficile à quantifier l’avancement de ce rêve. Mais j’ai déjà une piste ; j’ai reçu un email d’un lecteur Japonais avec les coordonnées d’un événement Manga qu’il connaît. Je vais donc bientôt constituer un beau dossier pdf pour essayer de démarcher cet événement. Quand au rêve « Atteindre l’épisode 100 ! », ce rêve est très quantifiable et avec la publication le mois dernier de l’épisode 13, j’en suis exactement à 13% !

Un petit mot de la fin ? Ou un dessin ? 😀

Un dessin bien sûr ! Merci pour l’interview !

Dessin de David Revoy pour Framasoft

Toutes les illustrations de l’article sont bien évidemment de David Revoy, en CC-BY 🙂




Bye bye Gmail !

Nous l’avions dit lors de notre campagne de don 2013 : 2014 sera l’année du « Moins de Google et plus de Libre »

Un semblant de planning a été dévoilé dans le récent billet intitulé « Manger la pâtée de son chien ». C’est le 1er février que nous devions nous séparer de Gmail, et nous l’avons fait !

L'enregistrement MX de framasoft.org

Nous sommes maintenant complètement autonomes pour la gestion de nos mails. Comme annoncé précédemment, nous avons choisi la solution BlueMind.

Il nous fallait un groupware pour remplacer Gmail : nous avions besoin de la gestion des mails, mais aussi de celle des agendas et des contacts, le tout en permettant le partage de ceux-ci, au moins entre nous.

Pendant notre recherche du Graal du groupware libre kivabien, nous en avons testé un bon nombre. Si certains n’étaient pas sans attraits, aucun n’avait la simplicité d’installation, de configuration et de maintenance de BlueMind tout en proposant une interface sympa et une synchronisation Exchange Active Sync[1] sans devoir allonger la monnaie[2].

Après avoir choisi BlueMind, un tweet de ma part nous a réservé une belle surprise : la souscription — facultative — auprès de BlueMind est offerte pour les associations du libre.
Même si nous étions partis pour nous débrouiller seuls, cette nouvelle était bienvenue car la souscription apporte un outil permettant de faire les mises à jour aussi simplement que l’installation[3] (qui tient en deux lignes de commande).

Du temps en moins pour des mises à jour, c’est autant de temps en plus pour nos projets :D.

Les framasoftiens au travail

Bref, séduits par Bluemind, nous l’avons installé sur une machine virtuelle de notre nouvelle infrastructure[4].

La formation des utilisateurs framasoftiens à la nouvelle interface ainsi que leur migration fut longue et pleine de mails de questions, de réponses, d’incompréhension… mais couronnée de succès.
La possibilité (récente) de pouvoir exporter sa boîte Gmail au format mbox a même donné lieu à une petite séance de modification d’un script python, IMAP Upload pour l’adapter aux labels de Gmail : les labels deviennent des dossiers lorsqu’ils passent dans gmail-mbox-to-imap et les mails y sont consciencieusement rangés. Peut-être ce script vous sera-t-il utile ?

Ce fut une belle migration. L’adminsys et le serveur se portent bien 😉 Nous pouvons donc aujourd’hui vous annoncer fièrement que nos mails sont libres et nous espérons que vous aurez envie de nous suivre dans cette voie.

Ce premier jalon dans notre entreprise de libération ne fait qu’ouvrir la voie à la ribambelle de changements que nous opérerons cette année.
Le prochain épisode sera celui du passage des Google Groups à notre propre serveur de listes de diffusion basé sur Sympa (1er mars si tout se passe comme prévu).

Librement,
Sky, pour Framasoft

Crédits photo:

Notes

[1] Oui, le protocole a été inventé par Microsoft, mais c’est le meilleur protocole de synchronisation avec les téléphones et on peut implémenter son propre serveur Exchange Active Sync.

[2] Nous vous rappelons que Framasoft ne vit que par vos dons (déductibles des impôts). Merci d’avance pour votre soutien.

[3] Ainsi que d’autres choses, mais dont nous n’avions pas besoin. Un connecteur Outlook par exemple :p

[4] Notre nouvelle infrastructure de virtualisation repose sur Ganeti, comme évoqué dans le billet « Manger la pâtée de son chien »




Lolix, ou la communauté invisible

Logo de Lolix

Lolix est LE site francophone d’offres d’emploi tournant autour du Logiciel Libre. Un site incontournable, au style un peu vieillot certes, mais qui a contenté beaucoup de geeks, de nerds, de barbus, reconnaissants de trouver des entreprises où le libre n’est pas qu’un terme marketing.

Tout récemment, le 5 décembre, Lolix est tombé, après 15 ans de bons et loyaux services. Thom a alors averti LinuxFr dans un journal sobrement intitulé « Lolix » et qui, s’il n’a pas suscité de montagnes de commentaires, a toutefois affolé un peu les moules sur leur bouchot.

À la suite de cela, Rodolphe Quiédeville, l’auteur/mainteneur/modérateur de Lolix a reçu de nombreuses de marques de soutien l’encourageant à continuer avec une campagne de financement participatif. Voyons un peu ce qu’il a à nous raconter de cette histoire…

Bonjour Rodolphe, tu peux un peu te présenter à nos lecteurs ? Car si j’ai appris récemment que c’était toi qui était derrière Lolix et que tu t’es un peu dévoilé dans ton article de blog « Lolix de 1998 à 2013 », on ne peut pas dire qu’on te connaît beaucoup.

On peut dire que je ne suis pas un jeune gnou de la dernière portée, je suis admin/sys tendance DevOps comme on dit aujourd’hui. Je travaille dans l’info depuis 97 et j’ai vite migré vers le libre en 1998 en entrant chez Ecila.
Dans mes activités libristes je suis plutôt tendance Gnu et publie mes travaux en GPLv3, aprilien non pas de la première heure mais fidèle tout de même depuis le siècle dernier. Outre Lolix j’ai aussi été à l’origine de Dolibarr, qui est est né sur le backoffice de Lolix, seule solution à l’époque pour émettre des factures et faire un peu de compta de logiciel libre.
Aujourd’hui je suis Freelance et travaille essentiellement sur des prestations de test de charge de sites webs avec Tsung, en parallèle de missions orientées cartographie. Je contribue tant que faire se peut par des patchs aux outils que j’utilise, ma principale contribution en ce moment étant orientée autour d’OpenStreetMap en tant que contributeur données.

Je vais essayer de ne pas te faire répéter le contenu de ton billet — j’encourage nos lecteurs à aller le lire. Lolix, codé en 1998… Les frameworks ne devaient pas être légion à l’époque. Tu as tout fait à la main ? Ça t’a pris combien de temps ?

Je n’ai pas souvenir qu’il en existait un, en fait il en existait quasi autant que de projets. On a bien essayé de me refourguer celui de LinuxFr à l’époque mais j’ai résisté et oui j’ai tout codé seul, aucune idée du temps que cela a pris. J’ai toujours été adepte du release soon, release often, chaque nouvelle fonctionnalité codée était mise aussitôt en ligne, et je n’ai jamais tenu de compte sur mes heures de travail.

En 15 ans, il y a eu combien d’offres d’emploi déposées ? Combien de CV ? Tu aurais un ordre d’idée ?

Là par contre j’ai des stats, dans la base à ce jour on est à 18639 offres et 17488 CV. Avec respectivement 12 millions et 1,5 millions de consultations depuis le début des stats que j’ai commencé à gérer en 2000.

Tu dis que tu as lu toutes les offres d’emploi. Toutes ? Vraiment ? Ça te prenait combien de temps par jour ?

Oui ça c’est le principe de base, aucune offre ne passe en ligne sans être modérée, ce n’est pas trés fastidieux, avec le temps on prend vite des réflexes et en lecture diagonale tu vois tout de suite si l’offre est cohérente ou pas. En moyenne je n’y passe pas plus de 15 minutes par jour je pense.

Il n’y avait que toi qui modérait les annonces ? Pourquoi ne pas avoir posté une petite annonce de recrutement sur LinuxFr ou autre ?

Oui, Lolix contrairement à Dolibarr est un projet que j’ai plus incarné, j’aurai pu évidemment laisser la modération ouverte (ce qui va probablement évoluer) mais j’ai toujours eu peur de voir Lolix dévier de sa route. Un temps j’avais lancé également joinux.com pour les offres un peu plus borderline, mais cela n’a pas été convaincant, cela brouillait un peu la lecture.

Est-ce qu’il y avait une communauté autour de Lolix quand même ? Un lieu d’échange comme un forum, ou même juste quelques personnes qui venaient boire une bière et coder un peu ?

Non, par ma faute probablement je n’ai jamais fait d’effort pour créer cela. Il faut dire aussi qu’en 2000 avec Lolix SA j’ai essayé de développer une offre commerciale pour générer un revenu, cela n’a pas incité les contributeurs à rejoindre le projet. Et après la fermeture de l’entreprise j’ai été occupé à d’autres activités.

Je crois parler pour bon nombre d’entre nous qui te devons un emploi ou un stage si je dis que l’annonce de la fermeture de Lolix a été un choc. Pour moi, c’était un site qui traverserait vents et marées la tête haute, sans frémir. Est-ce que tu t’attendais un peu à ce que sa fermeture fasse des vagues ?

Pas à cette hauteur c’est évident, mais je ne suis pas naïf au point de penser que cela aurait pu passer inaperçu.

Parlons un peu des vagues. Ce sont « toutes les marques de soutien » qui t’ont incité à faire une campagne de financement participatif pour te permettre de recoder Lolix (nom de code : Lolyx). Tu t’attendais à ça ? Il y en avait tant que ça ?

Non pas autant c’est évident et surtout pas si vite, si la campagne a réussi aussi vite c’est parce qu’elle a aussi été très bien relayée. Ce qui a été également très plaisant c’est de retrouver des gens que j’avais un peu perdu de vue depuis les années.

La campagne de financement, qui a duré 42 jours a atteint le but de 4 200€ en 24h chrono ! C’est pas aussi geek que 42h (même si on peut écrire 42 avec 24), mais c’est classe ! Comment as-tu réagi en apprenant ça ?

Je sautais partout tout simplement 🙂

Soupçonnais-tu une telle communauté invisible[1] derrière Lolix ?

Non, je savais que Lolix était important pour les gens qui l’utilisent régulièrement mais je ne pensais pas que le site pouvait fédérer autant de gens. J’ai été assez étonné aussi de voir une telle diversité dans les gens qui ont participé à la campagne, on n’est pas encore dans un registre de 7 à 77 ans mais on s’en approche.

Pour le coup, tu pourrais peut-être utiliser cette communauté pour t’aider dans la modération des offres d’emploi, non ? Ou le code ?

Pour le code bien évidemment, le code de Lolix a toujours été libre et publié sur Savannah, seulement avec le temps je n’ai plus mis à jour le repo, et ça c’est mal. Lolyx est dès à présent ouvert en tant que projet public sur Gitlab et tout un chacun est libre d’y contribuer.
Pour la modération des offres c’est à l’étude, j’avoue que l’enthousiasme de la campagne m’a donné cette idée d’ouvrir la modération des offres, formellement je ne sais pas encore comment mais je sais déjà que les gens ayant participé au financement auront un traitement de faveur sur ce point.

Est-ce que tu vas ajouter des trucs différents dans la nouvelle version ? Et pourquoi utiliser Python ? Il y a quand même mieux comme langage. Perl par exemple[2].

Oui il y aura des nouveautés, je veux cette nouvelle version déjà plus en phase avec ce qui se fait aujourd’hui en terme d‘API, de responsive design, ou d’OpenData, et il y aura surtout tout ce que j’ai pas encore pensé et qui sera apporté par les contributeurs ingénieux. Après pourquoi Python, parce que Django[3].

Capture d'écran de la deuxième version de Lolix

Un dernier mot ?

15 ans de nouvelles aventures ça fait frémir un peu, mais 15 ans de nouvelles rencontres ça fait rêver !

À l’heure de la mise au propre de cette interview sur le Framablog, la campagne de financement est terminée et a généré plus de 200% de la somme demandée.Toutes nos félicitations à Rodolphe, à Lolix et à tous ceux qui ont contribué à un tel succès !

Notes

[1] Fallait bien que je justifie le titre du billet.

[2] Je voulais au départ publier cette interview un trolldi (le jour où le troll est permis — et encouragé sur LinuxFr —, c’est à dire le vendredi).

[3] Framework web populaire écrit en Python.




Manger la pâtée de son chien

Le titre de ce billet vient de l’expression « Eating your own dog food » signifiant qu’il est bon de suivre ses propres recommandations.

Crédit photo : Birhanb – CC by-sa
Crédit illustration : Framasoft Campagne 2013 – Simon Gee Giraudot – CC by-sa

Lors de notre campagne de dons 2013, nous avions proclamé « Moins de Google et plus de Libre ». En effet, cela fait un bout de temps que l’actualité tourne autour du géant du Web pour son côté « Don’t be Evil [mais un peu (beaucoup ?) quand même] » et que nous vous encourageons à vous méfier de lui et de ses semblables… sans que nous suivions pour autant nos propres recommandations !

Un chiot en train de manger du yaourt

Google Analytics pour nos statistiques, Google Groups pour nos listes de diffusion, Google Mail pour nos adresses mail associatives, etc. La liste est longue et nous accable chaque jour un peu plus. Nous ne comptons d’ailleurs plus le nombre de fois où l’on nous reproche — avec raison — d’utiliser les services Google.
Le cas de Google Groups est particulièrement parlant : si on peut s’abonner librement à une liste de diffusion de ce service, le faire sans disposer d’un compte Google relève du parcours du combattant.

Google nous a séduit à l’époque par sa facilité d’emploi, ses nombreux outils disponibles et son slogan que nous aimions croire. Notre croissance a été peut-être un peu rapide et nous avons choisi des solutions de facilité.
Il faut cependant noter, à notre décharge, que ces solutions présentaient au moins le mérite d’être gratuites, et ne nécessitaient aucune maintenance particulière si ce n’était un peu d’organisation. Pouvoir “compter” sur les serveurs de la Firme était clairement une question de confort et de disponibilité de main d’œuvre. Il faut aussi se souvenir qu’il y a peu de techniciens purs et durs dans nos rangs.

Google devient chaque jour de plus en plus omniprésent, intrusif et laissant de moins en moins de choix à ses utilisateurs, comme l’obligation récente d’avoir un compte Google+ pour commenter des vidéos Youtube. Sans parler de sa soumission à la NSA (#Prism, #Snowden), Voilà qui n’est vraiment pas dans l’esprit de Framasoft 🙁

Mais en 2014, nous nous libérons de nos chaînes ! Tel le fils prodigue, nous revenons à la maison. Nous quittons cette cathédrale si confortable pour rajouter de nouvelles pièces à notre auberge espagnole, ce joyeux bazar.

Framasoft Campagne 2013 - Simon Gee Giraudot - CC by-sa

Au menu de cette grande campagne de migration, nous remplacerons :

  • Google Mail par Bluemind ;
  • Google Groups par Sympa ;
  • Google Docs par un mélange d’Etherpad, d’Owncloud et peut-être aussi de WebODF ;
  • Google Analytics par Piwik ;
  • Github par GitLab (parce qu’il n’y a pas que Google qui n’est pas libre)[1].

Le calendrier de cette migration, s’il n’est pas gravé dans le marbre est tout de même plus ou moins déjà écrit.
Ainsi, le 1er février, nous aurons effectué la migration de nos boîtes mail vers notre propre infrastructure.

Chacune des étapes de notre libération fera l’objet d’un billet dédié pour vous tenir au courant de nos avancées et — pourquoi pas ? — vous donner envie de suivre notre exemple.

Cette année sera aussi celle du grand ménage dans nos serveurs. Un grand bric-à-brac monté au fil des années, pas forcément maintenu comme il faudrait, mélangeant les applications critiques et moins critiques. Nous allons nous doter d’outils nous permettant une plus grande souplesse d’utilisation, comme Ganeti[2] pour monter une infrastructure virtualisée.
Cette souplesse nous permettra par exemple d’expérimenter facilement de nouveaux services à vous proposer (Sneak preview) tout en réduisant le temps — relativement conséquent aujourd’hui — à consacrer à la maintenance de notre infrastructure.

Nous tenions à vous l’annoncer non seulement dans un souci de transparence, mais aussi pour vous permettre de suivre et vous montrer — au fil de nos avancées — comment nous répondons à notre défi « Quitter Google ». Peut-être cela pourra-t-il inspirer votre entreprise, votre administration, votre association… à se lancer ce même défi.

C’est en grande partie grâce à vos dons que nous pouvons dégager le temps et trouver les talents pour atteindre cet objectif. Si vous trouvez la démarche intéressante, n’hésitez pas à nous soutenir afin de nous permettre de continuer notre action.

L’équipe Framasoft

Notes

[1] Nous conserverons toutefois un miroir de nos projets sur Github, pour la visibilité

[2] Arrh, oui, on sait que c’est un outil développé par Google, mais c’est un outil libre quand même




Framablog brisé ! Framablog martyrisé ! Mais Framablog libéré !

Chers lecteurs du Framablog,

Vous avez été nombreux mercredi soir, 15 janvier 2014, à nous signaler — par mail ou par twitter — une alerte de sécurité concernant le Framablog. En effet, dès 22h, Firefox a commencé à signaler le Framablog comme « site malveillant », suivi une demi-heure plus tard par Chrome.

Malheureusement, ceci n’était pas un exercice. Plusieurs fichiers javascript avaient été touchés et nous avons retrouvé le fichier php infectieux à l’origine du problème.

Drapeau du pirate Henry Every

Un grand merci à FramaSky et JosephK qui ont passé leur nuit sur le problème pour que le blog revienne au plus vite à la normale et garantir votre sécurité, fût-ce au mépris de leur sommeil — et d’un épisode de Sherlock pourtant redoutablement tentant. À tous ceux qui hésitent entre un coup fumeux de la NSA, une revanche de Mountain View quant à notre campagne « moins de Google, plus de libre » ou un happening des Connards Professionnels, nous répondons que nous ne pensons pas être si importants que ça.

Une nouvelle attaque a eu lieu dès le lendemain jeudi vers 17h, redirigeant les visiteurs vers un site bien évidemment douteux. Aussitôt alertés, nous avons placé le Framablog en maintenance afin d’éviter d’exposer nos lecteurs et pour nous permettre d’examiner le problème plus sereinement. Échaudés par la première attaque, nous savions déjà quoi chercher pour nettoyer le site, et Pyg a trouvé puis comblé la faille dans notre système. Le blog a été remis en ligne dans la soirée, sans tambours ni trompettes, tout fatigués que nous étions.

Par ailleurs, on nous a signalé ce vendredi que des commentaires avaient disparu de certains billets. Comme quelques uns de ces commentaires étaient critiques vis-à-vis des billets concernés, il aurait été facile de penser à de la censure. Sachez qu’il n’en est rien : cette attaque a visiblement eu des conséquences que nous n’avions pas repérées de prime abord. Nous remercions les commentateurs concernés, car ceux-ci ont très rapidement fait le rapport avec nos problèmes.

Cet incident nous a confortés dans le constat que nous avions déjà fait : la plateforme qui accueille le Framablog est vétuste, elle héberge d’autres sites et des expérimentations non supprimées après abandon, qui sont potentiellement autant de failles de sécurité. De plus, le moteur du blog est bardé de plug-ins collectionnés au fil des années et des collaborateurs. Il devient difficile de garantir la sécurité du blog de manière satisfaisante. Nous allons donc entériner et accelérer le choix — évoqué lors de l’Assemblée générale qui s’est tenue début janvier — d’abandonner la forme actuelle du Framablog, de ne le conserver « que » comme mémoire des anciens articles et repartir à zéro pour un Framablog tout beau tout propre que nous installerons sur une machine virtuelle tout neuve. Pour l’instant, nos choix se porteraient sur un wordpress flambant neuf avec un des thèmes natifs légèrement remanié — ou une solution qui soit techniquement simple et qui ne pose pas de problème de maintenance — tout en optant pour une politique minimaliste en ce qui concerne l’ajout d’extensions sous le regard inquisiteur de FramaSky.

Ce changement sera effectué en ayant à cœur de respecter votre confort, votre sécurité et vos données (en instaurant par exemple un partage en deux clics comme c’est actuellement testé sur www.connard.pro)

Bien entendu, une migration se fait rarement sans heurts. Il se peut donc, au cours des prochaines semaines, que quelques perturbations adviennent lorsque vous naviguerez sur le Framablog. Nous promettons de faire de notre mieux pour qu’elles soient réduites au minimum.

Nous espérons que vous prendrez toujours autant de plaisir à lire et à participer à cet outil d’information du Libre francophone.

L’équipe du Framablog

Crédit image couverture : Drapeau du pirate Henry Every… (CC-0 par “Eugene Zelenko”)