July 20, 2016

Carl Chenet

Tribulations d’une migration depuis WordPress.com

wordpress-evil

Depuis quelques temps, la nécessite de renouveler l’infrastructure de mon blog se faisait de plus en plus pressante. Le billet d’aujourd’hui évoque les tribulations autour de cette aventure/galère/pt1cable et la nouvelle infrastructure du blog en espérant que cela puisse servir de leçon à d’autres tentés par l’aventure.

1. Pourquoi

Mon blog était clairement vieillissant. Hébergé chez WordPress.com, il devenait mystérieusement de plus en plus long à charger. Étant un client payant chez WordPress.com, j’étais donc fortement insatisfait du service, mais j’ai mis beaucoup trop de temps à me décider à corriger le problème. Pourquoi ? La raison principale est que j’avais souscrit mon nom de domaine carlchenet.com chez WordPress.com.

Une migration de DNS d’un hébergeur vers un autre ? Rien de plus facile se dit le néophyte. Mais quand tout faire pour compliquer la tâche au client fait qu’il se décourage de partir, c’est donc un outil de monétisation. Et là les ennuis commencent.

2. L’option existe dans l’interface, ça va être simple

Je commence donc à regarder via l’interface d’administration WordPress de mon blog comment transférer ma zone DNS. L’option existe. Cool, ça va être vite réglé. HAHAHA.

fuyez

Plein de bonnes volontés je suis les différentes étapes indiquées dans leur documentation. À la fin on me signale qu’un e-mail de confirmation va être envoyé à l’adresse de contact de la zone DNS. Ok, envoie.

Une semaine plus tard et tel un poisson rouge, je constate de nouveau la lenteur de mon blog. Je rage de nouveau et je me souviens que j’ai jamais reçu le fameux e-mail. J’enquête donc et constate que j’ai une erreur dans l’adresse e-mail de contact de ma zone DNS. Je corrige via l’interface de WordPress, attend une journée, et redemande l’envoi du fameux e-mail de confirmation de transfert de la zone. Pause pop-corn.

Plusieurs mois plus tard, je pète de nouveau un câble face à la lenteur de mon blog que je commence à délaisser car je n’arrive pas à le faire évoluer. Je plante des couteaux dans une poupée vaudou à l’effigie de WordPress.com et j’ouvre un ticket auprès de leur support. On me recontacte sous 24 ou 48 heures.

24 heures plus tard, la personne du support WordPress.com identifie le problème : il y a une erreur dans l’adresse de contact de ma zone DNS. Merci, c’est en effet l’un des problèmes, mais le principal est que je ne peux pas la changer moi-même. J’en informe cette personne qui me dit qu’elle revient vers moi.

24 heures plus tard, le support m’annonce que l’adresse a été changée. Très bien ! Enfin ! Je me connecte à l’interface pour renvoyer le fameux e-mail contenant le code de transfert.

Plusieurs heures plus tard je reçois l’e-mail en question qui me demande une confirmation de ma volonté d’effectuer cette manoeuvre et le fameux code de transfert. Je commande un transfert de zone chez OVH qui me demande le fameux code et se met en attente du retour du serveur DNS de WordPress.com.

Je reçois un e-mail de WordPress.com qui m’annonce qu’ils sont très tristes de me voir partir (surtout mon abonnement mensuel) et pour me donner un délai de réflexion, vont m’infliger 4 jours d’attente pour annuler au cas où, comme si ça n’était pas déjà suffisamment compliqué comme procédure. Je passe au fusil à pompe sur la poupée vaudou pour prendre mon mal en patience.

4 jours plus tard et la date annoncée dans l’e-mail expirée, j’ouvre une nouvelle demande au support WordPress.com pour leur préciser que, bon, j’ai décidé de me barrer, j’ai confirmé 20 fois, j’en suis à deux demandes de support et ça commence à bien faire, en fait. 24 heures plus tard, sans réponse du support, je reçois enfin la confirmation de transfert de la zone et au même moment la confirmation d’OVH qu’ils ont bien rapatrié ma zone.

L’e-mail final de WordPress.com est hilarant :

Dear Carl Chenet,

We're sorry you transferred your domain name(s) away from WordPress.com.
We are committed to providing quality services and products
and hope that we met your needs.

Tout cela est au final un peu trop long et un peu trop fastidieux.

3. Le nouveau blog WordPress avec un certificat Let’s Encrypt

Sur mon serveur propulsé par une Debian Jessie, j’ai donc installé un blog WordPress en version 4.5.3 avec deux plugins : l’importateur WordPress et WP-Super-Cache. J’ai fait pointer le cache généré par ce plugin vers un tmpfs sur mon serveur afin que le cache du blog soit donc en RAM. Et ça bourrine ! Bien, le principal problème qui a entraîné la migration est donc résolu.

Mon ancien blog WordPress de WordPress.com proposant une fonctionnalité de migration. Migrer les données a donc été un jeu d’enfant. Que ce soit donc bien clair, je n’ai rien à reprocher au moteur de blog WordPress, c’est plutôt avec la société commerciale WordPress.com que j’ai eu du mal.

letsencrypt

Niveau certificat SSL et afin d’économiser quelques euros par an, je décidais de mettre en place les certificats Let’s Encrypt avec un renouvellement automatique. Rien de plus facile avec le programme client de Let’s Encrypt certbot présent dans les dépôts officiels backports de Debian. Installer certbot est aussi simple que de taper la commande suivante sur votre serveur :

# apt-get install python-certbot-apache -t jessie-backports

La documentation officielle de Certbot est on ne peut plus limpide et vous est présentée en fonction de votre système d’exploitation et votre serveur Web. Le renouvellement automatique se fait à l’aide d’un cron installé automatiquement et se lançant tous les jours pour vérifier la validité de votre certificat.

4. Les leçons à retenir

Lorsqu’on souscrit à un moteur de blog, la première vérification doit être pour le système d’import/export de vos données. Cela va lourdement vous handicaper si vous souhaitez changer de moteur de blog. Avec WordPress, j’étais tranquille à ce niveau-là.

Ma grande erreur a été de sous-estimer le risque lié à mon nom de domaine. Aveuglé par l’offre faite pour coupler le moteur de blog et le nom de domaine, je me suis retrouvé très dépendant de WordPress.com pour migrer vers un autre système de blog. Il aurait donc fallu souscrire ma zone DNS chez un autre prestataire indépendant de celui gérant le moteur de blog.

Enfin cette aventure a été un grand décrassage pour moi et l’occasion de reprendre sous mon aile une partie de mes données afin de les présenter à l’aide d’un moteur de blog désormais propulsé via mon infrastructure. Et j’espère de vous faire un retour d’expérience avec quelques leçons à en tirer 😉

20 July, 2016 10:01PM by Carl Chenet

July 11, 2016

hackergotchi for Raphaël Hertzog

Raphaël Hertzog

Mes activités libres en juin 2016

Mon rapport mensuel couvre une grande partie de mes contributions au logiciel libre. Je l’écris pour mes donateurs (merci à eux !) mais aussi pour la communauté Debian au sens large parce que cela peut donner des idées aux nouveaux venus et que c’est également un des moyens les plus effectifs de trouver des volontaires pour travailler sur les projets qui me tiennent à cœur.

Empaquetage Debian

Django et Python J’ai poussé la version 1.9.7 de Django, et créé auprès de l’amont le ticket n°26755, concernant l’échec aux tests DEP-8.

J’ai empaqueté/parrainé python-django-modeltranslation et python-paypal. J’ai ouvert une demande de pull pour model-translation, afin de corriger les échecs des tests de compilation de paquet Debian.

J’ai empaqueté une nouvelle version de python-django-jsonfield (la 1.0.0), créé un rapport de bug et découvert une régression dans le support PostgreSQL. J’ai apporté mon aide sur le ticket amont, et me suis vu accorder les droits de commit. J’ai profité de cette opportunité pour faire un peu de tri dans les bogues, et pousser quelques corrections. J’ai également discuté du futur du module et fini par lancer la discussion sur la liste de diffusion des développeurs Django, concernant la possibilité d’ajouter un champ JSONField au noyau.

CppUTest J’ai poussé une nouvelle version amont (3.8), contenant plus d’un an de travail. J’ai découvert que « make install » n’installait pas un des header requis, et j’ai donc créé le ticket correspondant, accompagné d’un patch. Le paquet ayant échoué à la compilation pour plusieurs architectures, j’ai créé un autre rapport de bogue et préparé un correctif pour certaines de ces erreurs, avec l’aide des développeurs amont. J’ai également ajouté un test DEP-8 après avoir envoyé un paquet cassé (et non testé)…

Support de systemd pour net-snmp et postfix J’ai travaillé à l’ajout de service units systemd natifs pour net-snmp (n°782243) et postfix (n°715188). Dans les deux cas, les mainteneurs n’ont pas été très réactifs jusqu’à présent, en conséquence de quoi j’ai poussé mes modifications en tant que non-mainteneur.

Équipe pkg-security Lancée doucement il y a quelques mois, l’équipe que j’ai créée est maintenant en croissance, que ce soit du point de vue du nombre de membres ou de celui du nombre de paquets. J’ai créé la page wiki Teams/pkg-security obligatoire, et parrainé les paquets xprobe et hydra. Enfin, j’ai poussé une mise à jour de medusa, pour incorporer les changements en provenance de Kali dans Debian (et soumettre le patch à l’amont dans le même temps).

fontconfig Après avoir lu l’analyse de Jonathan McDowell au sujet du bogue que de nombreux utilisateurs de Kali et moi-même ont rencontré à de multiples reprises, j’ai créé le ticket n°828037, afin que celui-ci soit corrigé une bonne fois pour toutes. Malheureusement, rien n’a changé à ce jour.

DebConf 16

Ce mois-ci, une partie de mon temps a été consacré à la préparation des deux conférences et de la table ronde que je vais présenter/animer à Cape Town entre le 2 et le 9 juillet :

Distro Tracker

J’ai continué le parrainage de Vladimir Likic, qui a réussi à terminer son premier patch. Il travaille maintenant sur la documentation à destination des nouveaux contributeurs, sur la base de son expérience récente.

J’ai amélioré la configuration tox pour pouvoir lancer des tests sur Django 1.8 LTS avec les avertissements bloquants (python -Werror) activés. De la sorte, je serai sûr de ne pas me baser sur une fonctionnalité abandonnée, et donc que la base de code sera fonctionnelle avec la prochaine version LTS Django (1.11). Cela m’a permis de découvrir les quelques endroits où j’utilisais effectivement des API obsolètes, et où j’ai mis à jour le code pour ne plus en dépendre (la mise à jour de JSONField vers la 1.0.0 dont j’ai parlé plus haut en est un parfait exemple).

J’ai également corrigé quelques problèmes supplémentaires avec les en-têtes d’emails « repliés », qui ne peuvent pas être réutilisés dans un nouvel objet Message, à qui il manque le champ Objet. Tous ces soucis ont été détectés via des exceptions déclenchées par une activité de spam, exceptions qui m’ont ensuite été transmises par email.

Travaux relatifs à Kali

j’ai poussé un nouveau live-boot (5.20160608) vers Debian, pour corriger un problème où le processus de boot était bloqué à cause d’un timeout.

J’ai transféré un bogue Kali affectant libatk-wrapper-java (n°827741), qui s’est trouvé être finalement un bogue OpenJDK.

J’ai créé le rapport de bogue n°827749 concernant reprepro, et demandant une méthode de suppression des références à des fichiers internes sélectionnés. C’est nécessaire si l’on souhaite pouvoir faire disparaître un fichier, et si ce dernier fait partie d’une sauvegarde que l’on veut garder malgré cela. En vérité, je souhaite avant tout pouvoir remplacer le fichier .orig.tar.gz utilisé par Kali par le orig.tar.gz utilisé par Debian… ces conflits cassent les scripts de réplication/import.

Salt

J’ai utilisé salt pour déployer un nouveau service, et j’ai développé plusieurs patchs pour quelques problèmes rencontrés dans les formules salt. J’ai également créé une nouvelle formule letsencrypt-sh pour la gestion des certificats TLS avec le client letsencrypt.sh ACME.

Merci

Rendez-vous au mois prochain pour un nouveau résumé de mes activités !

Ceci est une traduction de mon article My Free Software Activities in June 2016 contribuée par Weierstrass01.

Aucun commentaire pour le moment | Vous avez aimé ? Cliquez ici. | Ce blog utilise Flattr.

11 July, 2016 12:02PM by Raphaël Hertzog

July 09, 2016

hackergotchi for Charles Plessy

Charles Plessy

Félicitations, Marga !

Pour la première fois dans notre histoire, une femme rejoint le Comité Technique. Félicitations, Marga, et merci d'avoid donné ta candidature.

09 July, 2016 12:43PM

June 28, 2016

hackergotchi for Tanguy Ortolo

Tanguy Ortolo

J'ai testé pour vous UltraViolet (c'est de la merde)

Après avoir acheté un beau coffret de la trilogie cinématographique Le Hobbit, j'ai eu la surprise d'un trouver des instructions pour « récupérer une copie numérique » pour regarder ces films « sur tous mes écrans » grâce à un machin appelé UltraViolet. Les instructions indiquées sont les suivantes :

  1. allez sur warnerbros.fr/uv ;
  2. entrez un code d'activation.

S'agissant d'un machin développé par la MAFIAA, je pouvais déjà prédire le résultat, mais par acquit de conscience, j'ai tout de même essayé, avec un navigateur Web Firefox sous Debian GNU/Linux, plugin Flash installé et à jour, JavaScript et cookies activés sans restriction. Après tout, il est bien indiqué sur le papier que c'est censé marcher « sur tous mes écrans », avec de beaux petits schémas représentant un téléphone, une tablette, un ordinateur portable et un téléviseur.

Logo UltraViolet

Étape 1, Warner Bros

Deux étapes, on pourrait difficilement faire plus simple ! Sauf qu'évidemment, ça se complique. Sur la page UltraViolet de Warner Bros, il n'y a pas d'endroit où saisir un code ; au lieu de cela, il est proposé deux sites partenaires où on doit pouvoir l'entrer : Nolim films et Flixter.

Étape 1, deuxième partie, premier essai, Nolim films

Lorsque j'ai essayé, hier, la page de Nolim films affichait seulement « chargement en cours ». Après quelques minutes, j'ai donc renoncé et été voir chez Flixter.

Étape 1, deuxième partie, deuxième essai, Flixter

Côté Flixter, ça commence bien, on arrive sur un site en anglais. Une fois passé en français, il y a un bouton pour « Utiliser un code ». On tape le code et… ça dit qu'il n'y a aucun résultat. En fait, il faut saisir le titre du film, et ensuite seulement, saisir le code d'activation.

Étape 2, (essayer de) regarder ou télécharger le film

Il faut alors créer un compte, qui demande de fournir des renseignements personnels, c'est à dire des informations qui ne devraient certainement pas les concerner : pour regarder un film qu'on a acheté, il est anormal de devoir donner son nom, prénom et date de naissance. Personnellement, j'ai renseigné mon nom, mais une date de naissance bidon.

Enfin, on peut regarder son film. Enfin, essayer, parce que ça ne marche pas : ça lance une page avec Flash, qui affiche… du noir, puis un indicateur de chargement, et qui finit par planter le lecteur Flash.

On peut aussi télécharger son film avec un logiciel propriétaire proposé pour cela. Il est prévu pour Windows, et ne s'installe pas sous Wine.

Étape 3, ripper son DVD

Comme prédit, ça ne fonctionne pas. Il est donc temps de faire un peu chauffer mon processeur pour ripper mes DVD : ça au moins, ça fonctionne, et sans la moindre restriction. Autrement, ces flims doivent également être disponibles sur les réseaux de contrefaçon : contrairement à l'UltraTropLaid, ça aussi, ça fonctionne.

28 June, 2016 11:34AM by Tanguy

June 17, 2016

hackergotchi for J. Fernando Lagrange

J. Fernando Lagrange

La brique en voyage

La situation

Il se trouve que j’ai déménagé récemment. J’en ai profité pour demander un abonnement Internet à l’association de la Fédération FDN de mon coin: Rézine. J’ai donc mis ma brique Internet chez quelqu’un, le temps que l’accès Internet soit en place.

Le problème

Quand j’ai connecté la brique depuis un autre accès Internet, plus rien n’a fonctionné : pas de nouvelles de la brique sur Internet, ni sur le réseau local ! :-(

La solution

Note pour les avocats: cette solution a fonctionné chez moi, mais il y a un risque de perdre des données. Rien ne garanti qu’elle fonctionnera chez vous ! Je ne peux pas être tenu pour responsable des actions que vous faites. En cas de doute, demandez de l’aide au membre FFDN le plus proche de chez vous !

 

« Malheureusement », j’ai un modèle de brique datant de juillet 2015 (avec la migration du blog sur la brique fin 2015). Et une fois fonctionnelle, je ne me suis pas occupé de son entretien: ne pas toucher à quelque chose qui fonctionne me semble un bon conseil à suivre en informatique.

Mais là, je n’avais pas vu qu’il y avait des erreurs sur le disque. Ces erreurs n’ont été gênantes qu’une fois la brique éteinte et rallumée. J’ai donc pris le disque dur de la brique (la carte microSD) et je l’ai mis dans mon PC.

Puis, avec la commande lsblk j’ai vu que la partition de ce disque était /dev/sdc1; j’ai alors pu lancer une vérification du disque avec la commande suivante:

# fsck /dev/sdc1
[…là, ça défile et des fois ça pose des questions…]

Quand la question était posée de corriger les erreurs, j’ai répondu oui. Une fois toutes les erreurs corrigées, j’ai relancé la commande pour vérifier qu’il n’y avait plus d’erreur:

# fsck /dev/sdc1
fsck de util-linux 2.25.2
e2fsck 1.42.12 (29-Aug-2014)
/dev/sdc1 : propre, 93335/917568 fichiers, 848399/3859968 blocs

C’est alors, plein d’espoir que j’ai remis le disque dur dans la brique pour la brancher et l’allumer: ça marchait à nouveau ! :-)

Deuxième problème

Tout content que la brique refonctionne, j’ai payé un coup à boire à la personne qui l’héberge et je suis rentré chez moi. C’est avec un peu de déception que j’ai réalisé le lendemain que la brique ne fonctionnait plus ! :’-(

Ce deuxième problème est aussi lié au fait que j’ai mis en place ma brique en juillet 2015: à partir du moment où l’application vpnclient mettait en place le tunnel chiffré, la brique n’avait plus accès aux DNS (dont on parle dans cette superbe conférence) !

Après demande d’information à mon fournisseur de tunnels, c’est normal pour pleins de raisons diffèrentes, bref je dois utiliser leur DNS.

Deuxième solution

Une fois le problème identifié, la solution n’est pas loin ! Ici, j’ai mis à jour l’application vpnclient et le tour était joué: la dernière version de cette application prends en compte les DNS ! \o/

Je peux donc maintenant bloguer à nouveau, par exemple pour indiquer comment j’ai déplacé ma brique ! :-)

Prochaines étapes: mise en place de sauvegardes… Stay tuned for more info

 

17 June, 2016 09:13AM by fernando

June 16, 2016

hackergotchi for Raphaël Hertzog

Raphaël Hertzog

Mes activités libres en mai 2016

Mon rapport mensuel couvre une grande partie de mes contributions au logiciel libre. Je l’écris pour mes donateurs (merci à eux !) mais aussi pour la communauté Debian au sens large parce que cela peut donner des idées aux nouveaux venus et que c’est également un des moyens les plus effectifs de trouver des volontaires pour travailler sur les projets qui me tiennent à cœur.

Debian LTS

Du fait de départs dans l’équipe et de l’augmentation de la charge de travail, j’ai souhaité trouver quelques nouveaux contributeurs rémunérés pour Debian LTS. Pour se faire, j’ai envoyé un email à la liste debian-jobs@lists.debian.org et, a contrario de la fois dernière (où je n’avais posté l’annonce que sur mon blog), j’ai reçu beaucoup de réponses en retour… Ce qui m’a permis de recruter six nouveaux contributeurs. J’ai du refuser trois candidatures, dont le profil ne correspondait pas.

Chaque nouveau contributeur devait gérer sur son temps libre au moins une mise à jour LTS, afin de s’approprier le processus. Mais des six nouveaux, seuls trois contributeurs ont effectué leur « mise à jour d’entraînement » en mai. 🙁

J’ai consacré beaucoup de temps ce mois-ci à guider les premiers pas des nouveaux contributeurs, tant sur la liste debian-lts que via emails.

J’ai également passé en revue une mise à jour xen, pour laquelle j’avais (à raison) quelques doutes sur la qualité du travail réalisé.

Travaux d’empaquetage

fonts-cantarell Après avoir diagnostiqué le problème le mois dernier, l’absence d’un paquet corrigé m’a suffisamment ennuyé pour que je réussisse à empaqueter une nouvelle version amont de fonts-cantarell qui ne requiert aucune mise à jour de fontforge… mise à jour qui va très vraisemblablement prendre du temps. J’ai donc préparé et envoyé la version 0.0.24-1.

cpputest Le bogue n°823711 faisait état de soucis de licence avec quelques fichiers. J’ai immédiatement remonté cela à l’amont (ticket 961) et corrigé le problème dans Debian, en ré-empaquetant l’archive d’origine. Heureusement, l’amont a rapidement traité le souci, et une nouvelle version (3.8) démunie des fichiers problématiques est disponible.

live-boot Les images live de Kali ne bootaient plus (bloquées dans l’initrd) et, avec l’aide de Ben Hutchings, nous avons remonté les causes du problème jusqu’au ticket n°823069, que j’ai corrigé dans live-boot 20160511.

udev J’ai créé le rapport de bogue n°824025 demandant l’isolation dans son propre fichier de la règle de gestion pilotant le nom (basé sur l’adresse MAC) des interfaces réseau USB, de sorte à ce qu’elle puisse facilement être désactivée (nous procédons de la sorte dans Kali).

Travaux divers J’ai empaqueté Django 1.8.13 dans jessie-backports, corrigé le n°824165 concernant l’échec de sbuild avec “$apt_allow_unauthenticated = 1;” dans .sbuildrc, créé la demande d’amélioration n°824168 suggérant qu’apt-listchanges ignore les news des paquets installés automatiquement, et créé le rapport n°825923 pour rapporter une régression dans python-nltk (découverte dans Kali en premier lieu).

Travaux d’infrastructure

packages.debian.org J’ai écrit, il y a de cela quelques mois, un patch pour packages.debian.org, afin que ce dernier transmette les emails vers tracker.debian.org, en lieu et place de packages.qa.debian.org. A cette époque, j’étais en contact avec Rhonda, et j’espérais qu’elle l’applique assez rapidement (le patch n’est pas très long). Après quelques relances, elle m’a fait remarqué qu’elle n’était pas seule et que je ferais mieux de soumettre la demande en bonne et due forme, de sorte à ce que quelqu’un d’autre s’en charge. Ce qui fut fait : ticket n°824085. J’ai essayé de trouver « quelqu’un d’autre » pour traiter ma demande, mais la plupart des membres de pkg_maint m’ont répondu qu’ils n’appartenaient à ce groupe que par implication générique des webmasters. Aussi ils ne souhaitaient pas toucher à cette partie. Martin Zobel, heureusement, fut plus réceptif à ma demande et m’a aidé à déployer les modifications. J’ai poussé ma modification et Martin l’a intégré dans le checkout live de picconi.debian.org.

Cette mise à jour constitue également le premier pas vers une possible utilisation de foo@packages.debian.org et/ou teams+foo@tracker.debian.org dans le champ « Mainteneur » du paquet. Nous pourrions nous débarrasser, avec cela, des listes de diffusion dédiées, qui ne font que dupliquer le travail du suiveur de paquets. Et nous n’aurions plus besoin de nous soucier du fait que le champ « Mainteneur » est géré différemment du champ « Uploader », dans la mesure où tous les co-mainteneurs (humains) seraient listés dans le champ « Uploader » uniquement (et le suiveur de paquets gèrerait correctement les emails envoyés au mainteneur).

Distro Tracker J’ai amélioré le processus d’import afin d’être en mesure de relancer le traitement de paquets source ayant déjà été importés. C’est en particulier utile pour prendre en compte les architectures récemment ajoutées dans la base de données (et qui étaient du coup ignorées et donc non affichées jusqu’à maintenant).

J’ai également revu une première fois le patch AppStream soumis par Matthias Klump dans le ticket n°806740.

Merci

Rendez-vous au mois prochain pour un nouveau résumé de mes activités !

Ceci est une traduction de mon article My Free Software Activities in May 2016 contribuée par Weierstrass01.

Aucun commentaire pour le moment | Vous avez aimé ? Cliquez ici. | Ce blog utilise Flattr.

16 June, 2016 09:06PM by Raphaël Hertzog

May 17, 2016

Mes activités libres en avril 2016

Mon rapport mensuel couvre une grande partie de mes contributions au logiciel libre. Je l’écris pour mes donateurs (merci à eux !) mais aussi pour la communauté Debian au sens large parce que cela peut donner des idées aux nouveaux venus et que c’est également un des moyens les plus effectifs de trouver des volontaires pour travailler sur les projets qui me tiennent à cœur.

Debian LTS

J’ai pris en charge une nouvelle proposition de sponsoring, de la part d’une société souhaitant voir Wheezy continuer à supporter les architectures armel et armhf. Cela ne faisait pas partie de nos plans initiaux (arrêtés lors de la dernière DebConf) et, en conséquence, j’ai envoyé un message à toutes les équipes impactées de sorte à ce que ce changement, s’il devait survenir, soit approuvé collectivement. Alors que je m’attendais à recevoir une réponse claire assez rapidement, il s’est avéré que nous ne sommes jamais parvenus à obtenir un retour de la part de toutes les parties impliquées. La discussion a dérivé, à la place, sur la question plus générale de savoir comment nous devions traiter le sponsoring/donation au sein du projet LTS.

Fort heureusement, les mainteneurs de buildd ont confirmé être d’accord avec ce changemement, tandis que les ftpmasters n’y voyaient pas d’objections, ce qui a implicitement acté cette décision. Ansgar Burchardt a conservé les architectures armel/armhf dans le dépôt wheezy/updates lorsque le support a basculé du côté de l’équipe LTS, et Aurélien Jarno a configuré wanna-build de sorte à ce qu’il continue de compiler armel/armhf pour la suite. L’équipe DSA n’a pas confirmé que ce changement n’entrait pas en conflit avec l’un de leurs projets de mise hors service de matériels. Quoi qu’il en soit, les démons de compilation constituent des ressources partagées, et un seul serveur gère généralement la compilation des paquets pour plusieurs versions de Debian.

DebConf 16

Je me suis inscrit ce mois-ci pour la DebConf 16, et soumis plusieurs propositions de sujets pour des présentations/tables rondes :

  • Retour d’expérience de Kali Linux en tant que distribution dérivée de Debian, basée sur Testing (présentation);
  • Deux années de travail, réalisées par des contributeurs rémunérés, au sein du projet Debian LTS (présentation);
  • Utiliser l’argent de Debian pour financer les projets Debian (table ronde).

Je souhaite partager la configuration que nous utilisons dans Kali, dans la mesure où elle pourrait être utile à d’autres distributions dérivées, mais aussi à Debian elle-même, afin de faciliter les échanges avec les distributions dérivées.

Je souhaite également rouvrir le débat concernant l’utilisation de l’argent au sein de Debian. C’est un sujet difficile que nous devrions vraiment aborder, afin d’arrêter officiellement une position sur ce qu’il est possible de faire, ou de ne pas faire, avec cet argent. Debian LTS a permis de démontrer que l’argent pouvait être utilisé dans une certaine mesure, sans que cela n’affecte le projet Debian en tant que tel. Est-ce que cela peut être transposé à d’autres équipes ou projets ? Quelles sont les limites ? Pouvons-nous définir un cadre d’utilisation et clarifier les règles ? je m’attends à une table ronde très intéressante. Mehdi Dogguy a accepté d’animer cette table ronde avec moi.

Empaquetage

Django J’ai poussé la version 1.8.12 vers jessie-backports, ainsi que la version 1.9.5 vers unstable. J’ai créé deux rapports de bogue auprès de l’amont (n°26473 et n°26474) pour des problèmes repérés grâce à lintian.

Malheureusement, lorsque j’ai voulu faire de même vers unstable, la suite de tests n’a pas fonctionné. Après analyse, j’ai attribué cela à une régression dans SQLite. Chris Lamb a créé le rapport de bogue n°820225, et j’ai contacté les développeurs amont Django et SQLite par email, pour leur indiquer le souci. J’ai aidé l’auteur amont SQLite (Richard Hipp) à reproduire le problème, après quoi il a soumis très rapidement un patch, qui a atterri dans la version 3.12.1.

J’ai réalisé plus tard dans le mois un autre envoi, pour corriger un bogue de mise à jour (cf. le n°821789).

GNOME 3.20 Comme pour chaque nouvelle version, j’ai mis à jour gnome-shell-timer, de sorte à ce qu’il fonctionne avec le nouveau GNOME. J’y ai passé cette fois-ci un peu plus de temps qu’à l’habitude, afin de corriger une régression (cf. le n°805347) datant d’il y a bien longtemps déjà, et qui n’aurait jamais été corrigée autrement, l’auteur amont ayant déclaré orpheline cette extension (n’utilisant lui-même plus GNOME).

J’ai également rencontré des problèmes d’affichage, à savoir que les caractères accentués étaient affichés sous les caractères suivants. Avec l’aide de membres de l’équipe GNOME, nous avons découvert qu’il s’agissait d’un problème spécifique à la police cantarell, et n’était déclenché qu’avec Harfbuzz 1.2. C’est consigné dans Debian via le bogue n°822682 en ce qui concerne harfbuzz, et n°822762 pour ce qui est de fonts-cantarell. Une nouvelle version amont (incluant le correctif) est prête à être empaquetée, mais reste malheureusement bloquée par l’absence d’une version récente de fontforge dans Debian. J’ai donc contacté debian-mentors dans l’espoir de trouver des volontaires qui pourraient aider l’équipe pkg-fonts à en empaqueter une version plus récente…

Travaux divers Debian/Kali

Distro Tracker J’ai commencé à parrainer Vladimir Likic, qui m’a contacté dans le but de contribuer au Distro Tracker. Je l’ai aidé à mettre en place son environnement de développement, et nous avons corrigé quelques problèmes ce faisant.

Rapports de bogues J’ai créé de nombreux rapports de bogue, la plupart du fait de mon travail pour Kali :

  • n°820288: requête demandant le maintien d’un paquet WordPress installable sur les versions anciennes (du fait du renommage de nombreux paquets php);
  • n°820660: requête demandant le support des index by-hash dans reprepro;
  • n°820867: possibilité de surcharger la priorité de paquets déjà installés dans reprepro;
  • n°821070: problème de samba-vfs-modules lors de la mise à jour de jessie vers stretch;
  • n°822157: python-future masque et casse python-configparser;
  • n°822669: dh_installinit ajoute des autoscript inutiles pour les scripts System V, lorsque le paquet n’en contient aucun;
  • n°822670: dh-systemd devrait être fusionné avec debhelper, car nous disposons de systemd par défaut, et debhelper devrait le supporter correctement par défaut.

J’ai également étudié le n°819958 qui affecte testing, dans la mesure où il a été remonté dans Kali également. J’ai réalisé un envoi de dh-make-golang en tant que non-mainteneur, afin de corriger le problème du n°819472, que j’avais rapporté auparavant.

Merci

Rendez-vous au mois prochain pour un nouveau résumé de mes activités !

Ceci est une traduction de mon article My Free Software Activities in April 2016 contribuée par Weierstrass01.

Aucun commentaire pour le moment | Vous avez aimé ? Cliquez ici. | Ce blog utilise Flattr.

17 May, 2016 10:07AM by Raphaël Hertzog

May 02, 2016

hackergotchi for Vincent Bernat

Vincent Bernat

Petit traité empirique de l'empaquetage Debian

Bien que la création de paquets Debian soit abondamment documentée, la plupart des tutoriaux ciblent les paquets respectueux de la charte Debian. De plus, leur création a longtemps eu la réputation d’être particulièrement difficile1 et beaucoup se sont tournés vers des outils moins contraignants2 tels que fpm ou CheckInstall.

Toutefois, je vais montrer que la construction de paquets Debian en utilisant les outils officiels est plutôt simple en appliquant ces quelques concessions :

  1. Aucun paquet source ne sera généré. Les paquets seront construits directement depuis une copie propre issue du système de versions.

  2. Des dépendances supplémentaires peuvent être téléchargées pendant la construction. Empaqueter individuellement chaque dépendance est un travail ingrat, notamment avec certains environnements tels que Java, Javascript et Go.

  3. Les paquets produits peuvent combiner et inclure des dépendances tierces. Cela peut lever certaines objections liées à la sécurité et à la maintenance à long terme, mais c’est une concession courante dans certains écosystèmes tels que Java, Javascript et Go.

Ceinture blanche§

Deux types de paquets coexistent dans l’archive Debian : les paquets sources et les paquets binaires. Un paquet source produit un ou plusieurs paquets binaires. Chaque paquet doit porter un nom.

Comme indiqué lors de l’introduction, aucun paquet source ne sera construit. Nous allons travailler directement sur sa représentation décompressée : une arborescence de fichiers incluant le répertoire debian/. Les exemples qui suivent utilisent une arborescence composée uniquement du répertoire debian/, mais ce dernier peut être inclus dans n’importe quel project existant.

Comme point de départ, nous allons empaqueter memcached, un cache mémoire distribué. Il nous faut créer quatre fichiers :

  • debian/compat,
  • debian/changelog,
  • debian/control et
  • debian/rules.

Le premier contient uniquement 9 :

echo 9 > debian/compat

Le second contient ceci :

memcached (0-0) UNRELEASED; urgency=medium

  * Fake entry

 -- Happy Packager <happy@example.com>  Tue, 19 Apr 2016 22:27:05 +0200

La seule information d’importance est le nom du paquet source, memcached, sur la première ligne. Toutes les autres informations sont sans influence sur les paquets créés.

Le fichier de contrôle§

debian/control décrit les méta-données à propos du paquet source et des paquets binaires. Un bloc est dédié à chacun d’eux.

Source: memcached
Maintainer: Vincent Bernat <bernat@debian.org>

Package: memcached
Architecture: any
Description: high-performance memory object caching system

Le paquet source est memcached. Il faut utiliser le même nom que dans le fichier debian/changelog.

Un seul paquet binaire est créé : memcached. Par la suite, si vous voyez memcached, il s’agit du nom du paquet binaire. The champ Architecture doit être soit any, soit all. Ce dernier est utilisé exclusivement si tous les fichiers sont indépendants de l’architecture matérielle. Dans le doute, il suffit de mettre any.

Le champ Description contient une courte description du paquet binaire.

La recette§

Le dernier fichier à rédiger est debian/rules. Il s’agit de la recette du paquet. Nous avons besoin de télécharger memcached, le construire et installer son arborescence dans debian/memcached/ :

#!/usr/bin/make -f

DISTRIBUTION = $(shell lsb_release -sr)
VERSION = 1.4.25
PACKAGEVERSION = $(VERSION)-0~$(DISTRIBUTION)0
TARBALL = memcached-$(VERSION).tar.gz
URL = http://www.memcached.org/files/$(TARBALL)

%:
    dh $@

override_dh_auto_clean:
override_dh_auto_test:
override_dh_auto_build:
override_dh_auto_install:
    wget -N --progress=dot:mega $(URL)
    tar --strip-components=1 -xf $(TARBALL)
    ./configure --prefix=/usr
    make
    make install DESTDIR=debian/memcached

override_dh_gencontrol:
    dh_gencontrol -- -v$(PACKAGEVERSION)

Les cibles vides override_dh_auto_clean, override_dh_auto_test et override_dh_auto_build permettent de s’assurer que debhelper ne fera rien de « magique ». La cible override_dh_gencontrol permet de spécifier la version3 sans avoir à tenir à jour debian/changelog. Cette recette est très similaire à ce qui aurait été écrit pour fpm :

DISTRIBUTION=$(lsb_release -sr)
VERSION=1.4.25
PACKAGEVERSION=${VERSION}-0~${DISTRIBUTION}0
TARBALL=memcached-${VERSION}.tar.gz
URL=http://www.memcached.org/files/${TARBALL}

wget -N --progress=dot:mega ${URL}
tar --strip-components=1 -xf ${TARBALL}
./configure --prefix=/usr
make
make install DESTDIR=/tmp/installdir

# Build the final package
fpm -s dir -t deb \
    -n memcached \
    -v ${PACKAGEVERSION} \
    -C /tmp/installdir \
    --description "high-performance memory object caching system"

Vous pouvez lire le résultat final sur GitHub et le construire avec la commande dpkg-buildpackage -us -uc -b.

Ceinture jaune§

À partir de là, il est possible d’inclure quelques améliorations. Aucune n’est essentielle mais le gain est suffisamment intéressant pour justifier l’effort.

Les dépendances sources§

Notre recette initiale ne fonctionne que si nous disposons déjà de wget et de libevent-dev. Ces paquets ne sont pas présents sur tous les systèmes. Il est assez aisé de spécifier ces dépendances en ajoutant un champ Build-Depends dans debian/control :

Source: memcached
Build-Depends: debhelper (>= 9),
               wget, ca-certificates, lsb-release,
               libevent-dev

Il faut toujours spécifier debhelper (>= 9) car son utilisation est centrale dans debian/rules. Il n’y a pas besoin de dépendre de make ou d’un compilateur C car le paquet build-essential est considéré comme toujours présent et il les fournit indirectement. dpkg-buildpackage se plaindra si une des dépendances est manquante. Pour installer sans peine ces paquets, vous pouvez utiliser la commande suivante4 :

mk-build-deps \
    -t 'apt-get -o Debug::pkgProblemResolver=yes --no-install-recommends -qqy' \
    -i -r debian/control

Il est aussi intéressant de se pencher sur des outils tels que pbuilder et sbuild qui permettent de construire des paquets dans un environnment minimal et isolé.

Les dépendances binaires§

Si le paquet ainsi construit est installé sur une machine vierge, memcached refusera de démarrer en raison de l’absence de libevent. Il est possible d’exprimer cette dépendance en ajoutant un champ Depends dans le fichier debian/control. De plus, dans le cas des bibliothèques dynamiques, ces dépendances peuvent être générées automatiquement en utilisant des variables de substitution :

Package: memcached
Depends: ${misc:Depends}, ${shlibs:Depends}

Le paquet construit contiendra les informations suivantes :

$ dpkg -I ../memcached_1.4.25-0\~unstable0_amd64.deb | grep Depends
 Depends: libc6 (>= 2.17), libevent-2.0-5 (>= 2.0.10-stable)

Intérgration avec un système de démarrage§

La plupart des paquets fournissant un démon incluent une intégration avec le système de démarrage afin de démarrer le démon au boot ou de le redémarrer après une mise à jour. Pour les distributions basées sur Debian, il existe plusieurs systèmes de démarrage. Voici les trois plus courants.

  • System-V est le système historique. Ces scripts de démarrage peuvent être réutilisés par les autres systèmes. Il s’agit donc du plus petit dénominateur commun.
  • Upstart est le système popularisé par Ubuntu. Il est utilisé jusqu’à la version 14.10, incluse.
  • systemd est le système par défaut pour Debian depuis Jessie et pour Ubuntu depuis la version 15.04.

Écrire un script de démarrage pour System-V est une tâche ardue. Habituellement, je préfère donc simplement fournir un script pour le système de démarrage par défaut de la distribution visée (Upstart et systemd).

System-V§

Si vous voulez écrire un script de démarrage pour System-V, adaptez5 le script /etc/init.d/skeleton de la distribution la plus ancienne que vous souhaitez supporter. Mettez le résultat dans le fichier debian/memcached.init. Il sera installé au bon endroit et invoqué lors de l’installation, mise à jour ou retrait du paquet. Habituellement, l’utilisateur peut personnaliser les options du démon en modifiant le fichier /etc/default/memcached. Pour en fournir un, placez son contenu dans le fichier debian/memcached.default.

Upstart§

Fournir un script pour Upstart est similaire : son contenu doit être placé dans debian/memcached.upstart. Par exemple :

description "memcached daemon"

start on runlevel [2345]
stop on runlevel [!2345]
respawn
respawn limit 5 60
expect daemon

script
  . /etc/default/memcached
  exec memcached -d -u $USER -p $PORT -m $CACHESIZE -c $MAXCONN $OPTIONS
end script

La directive la plus importante à surveiller est expect. Ici, nous utilisons expect daemon et memcached est démarré avec l’option -d.

systemd§

Fournir un script pour systemd est un tout petit peu plus compliqué. Le contenu doit se placer dans debian/memcached.service. Par exemple :

[Unit]
Description=memcached daemon
After=network.target

[Service]
Type=forking
EnvironmentFile=/etc/default/memcached
ExecStart=/usr/bin/memcached -d -u $USER -p $PORT -m $CACHESIZE -c $MAXCONN $OPTIONS
Restart=on-failure

[Install]
WantedBy=multi-user.target

Bien que cela ne soit pas considéré comme une bonne pratique6, nous réutilisons /etc/default/memcached. Comme pour Upstart, la directive Type est particulièrement importante. Nous utilisons forking car memcached est démarré avec l’option -d.

Il est également nécessaire d’ajouter une dépendance source sur dh-systemd dans debian/control :

Source: memcached
Build-Depends: debhelper (>= 9),
               wget, ca-certificates, lsb-release,
               libevent-dev,
               dh-systemd

Il faut également modifier la règle par défaut dans debian/rules :

%:
    dh $@ --with systemd

Cette complexité supplémetaire est regrettable et est dû au fait que l’intégration de systemd ne fait pas partie de debhelper7. Sans ces modifications, le script sera installé mais l’intégration n’aura pas lieu et il ne sera pas lancé au démarrage de la machine.

Utilisateur dédié§

De nombreux démons n’ont pas besoin de s’exécuter en tant que root et c’est souvent une bonne idée de fournir un utilisateur dédié. Dans le cas de memcached, nous allons fournir l’utilisateur _memcached8.

Ajoutez un fichier debian/memcached.postinst avec le contenu suivant :

#!/bin/sh

set -e

case "$1" in
    configure)
        adduser --system --disabled-password --disabled-login --home /var/empty \
                --no-create-home --quiet --force-badname --group _memcached
        ;;
esac

#DEBHELPER#

exit 0

Lorsque le paquet est désinstallé, aucun ménage n’est effectué :

  • moins de code à écrire, moins de bugs,
  • l’utilisateur peut toujours posséder quelques fichiers sur le système.

L’utilitaire adduser effectuera toujours la bonne action que l’utilisateur demandé existe déjà ou non. Il faut penser à l’ajouter comme dépendance binaire dans debian/control :

Package: memcached
Depends: ${misc:Depends}, ${shlibs:Depends}, adduser

Le marqueur #DEBHELPER# indique le point d’insertion pour des scripts d’intégration supplémentaires.

Le résultat final est disponible sur GitHub et peut être testé avec la commande dpkg-buildpackage -us -uc -b.

Ceinture verte§

Il est possible d’exploiter certaines capacités de debhelper pour réduire la taille du fichier debian/rules et pour le rendre plus déclaratif. Cette section est totalement optionnelle : vous pouvez la sauter si besoin.

Banalités§

Il y a quatre étapes dans la construction d’un paquet Debian :

  1. debian/rules clean va nettoyer l’arborescence pour revenir dans son état initial.

  2. debian/rules build doit construire le logiciel. Pour quelque chose de basé sur autoconf, comme memcached, il s’agit essentiellement d’exécuter ./configure && make.

  3. debian/rules install doit installer l’arborescence de chaque paquet binaire dans le répertoire approprié. Pour des logiciels basés sur autoconf, il s’agit d’exécuter make install DESTDIR=debian/memcached.

  4. debian/rules binary doit empaqueter les différentes arborescences en paquets binaires.

Il ne faut pas écrire directement chacune de ces cibles. L’utilitaire dh, un composant de debhelper, va faire la majeure partie du boulot. Le fichier debian/rules minimaliste suivant suffit pour accomplir cette tâche pour de nombreux paquets sources :

#!/usr/bin/make -f
%:
    dh $@

Pour chacune des quatre cibles décrites ci-dessus, vous pouvez exécuter dh --no-act pour voir les utilitaires invoqués. Par exemple :

$ dh build --no-act
   dh_testdir
   dh_update_autotools_config
   dh_auto_configure
   dh_auto_build
   dh_auto_test

Chacun de ces utilitaires dispose d’une page de manuel. Ceux commençant par dh_auto sont un peu « magiques ». Par exemple, dh_auto_configure va tenter de configurer automatiquement le logiciel avant l’étape de construction. Selon les cas, il peut invoquer ./configure, cmake ou Makefile.PL.

Si un des utilitaires dh_ ne fait pas ce qu’il faut, il est possible de le remplacer en déclarant une cible nommée de manière adéquate :

override_dh_auto_configure:
    ./configure --with-some-grog

Chaque utilitaire est également configurable via des options. Ainsi, il est possible de modifier leurs comportements en définissant la cible correspondante et en invoquant l’utilitaire manuellement :

override_dh_auto_configure:
    dh_auto_configure -- --with-some-grog

Ainsi, ./configure sera appelé avec l’option --with-some-grog mais aussi avec des options par défaut telles que --prefix=/usr.

Dans l’exemple initial de memcached, ces cibles « magiques » sont surchargées. dh_auto_clean, dh_auto_configure et dh_auto_build ont été neutralisées pour éviter tout comportement inattendu. dh_auto_install a été détournée pour exécuter l’intégralité de la construction de l’arborescence cible. De plus, le comportement de dh_gencontrol a été modifié en lui fournissant le numéro de version désiré plutôt que de le laisser regarder dans debian/changelog.

Construction automatique§

memcached utilisant autoconf, dh sait comment le construire : ./configure && make && make install. Il est donc possible de laisser dh faire la majeure partie du boulot avec le fichier debian/rules suivant :

#!/usr/bin/make -f

DISTRIBUTION = $(shell lsb_release -sr)
VERSION = 1.4.25
PACKAGEVERSION = $(VERSION)-0~$(DISTRIBUTION)0
TARBALL = memcached-$(VERSION).tar.gz
URL = http://www.memcached.org/files/$(TARBALL)

%:
    dh $@ --with systemd

override_dh_auto_clean:
    wget -N --progress=dot:mega $(URL)
    tar --strip-components=1 -xf $(TARBALL)

override_dh_auto_test:
    # Don't run the whitespace test
    rm t/whitespace.t
    dh_auto_test

override_dh_gencontrol:
    dh_gencontrol -- -v$(PACKAGEVERSION)

La cible dh_auto_clean est détournée pour effectuer le téléchargement et la mise en place de l’arborescence9. Ni dh_auto_configure, ni dh_auto_build ne sont modifiés. dh appellera ./configure avec les options appropriées puis make. dh_auto_test doit exécuter la suite de tests de memcached. Toutefois, un des tests échoue en raison d’un fichier dans le répertoire debian/. Nous supprimons ce test récalcitrant et invoquons manuellement dh_auto_test. dh_auto_install n’est pas surchargé et dh exécutera alors une variante de make install.

Afin de mieux apprécier la différence, la voici sous forme de patch :

--- memcached-intermediate/debian/rules 2016-04-30 14:02:37.425593362 +0200
+++ memcached/debian/rules  2016-05-01 14:55:15.815063835 +0200
@@ -12,10 +12,9 @@
 override_dh_auto_clean:
-override_dh_auto_test:
-override_dh_auto_build:
-override_dh_auto_install:
    wget -N --progress=dot:mega $(URL)
    tar --strip-components=1 -xf $(TARBALL)
-   ./configure --prefix=/usr
-   make
-   make install DESTDIR=debian/memcached
+
+override_dh_auto_test:
+   # Don't run the whitespace test
+   rm t/whitespace.t
+   dh_auto_test

Vous avez le choix de laisser dh faire une partie du travail ou non. Il est généralement possible de partir d’un debian/rules minimal et de surcharger uniquement quelques cibles.

Fichiers supplémentaires§

Bien que make install ait installé les fichiers essentiels pour memcached, il est parfois nécessaire de copier quelques fichiers supplémentaires dans le paquet binaire. Pour se faire, il est possible d’utiliser cp ou encore de déclarer les fichiers à copier :

  • les fichiers listés dans debian/memcached.docs seront copiés dans /usr/share/doc/memcached par dh_installdocs,
  • les fichiers listés dans debian/memcached.examples seront copiés dans /usr/share/doc/memcached/examples par dh_installexamples,
  • les fichiers listés dans debian/memcached.manpages seront copiés dans le sous-répertoire approprié de /usr/share/man par dh_installman,

Voici un exemple pour debian/memcached.docs :

doc/*.txt

Si vous avez besoin de copier des fichiers à un endroit arbitraire, il est possible de lister ceux-ci ainsi que leur répertoire cible dans le fichier debian/memcached.install. dh_install se chargera de la copie. Par exemple :

scripts/memcached-tool usr/bin

L’utilisation de ces fichiers permet une description plus déclarative de la recette. Il s’agit d’une histoire de goût et vous pouvez tout à fait utiliser cp à la place. Le résultat final est visible sur GitHub.

Autres exemples§

Le dépôt GitHub comprend d’autres exemples. Ils suivent tous le même schéma et mettent en œuvre les techniques décrites dans les sections précédentes.

Il y a notamment des exemples de démons en Java, Go, Python et Node.js. Le but de ces exemples est de démontrer que l’utilisation des outils Debian est relativement simple. Mission accomplie ?


  1. La mémoire collective est toujours marquée par la glorieuse époque précédant l’introduction de debhelper 7.0.50 (circa 2009). La création du fichier debian/rules était alors particulièrement laborieuse. Toutefois, de nos jours, le squelette est devenu minimal. 

  2. La complexité n’est pas la seule raison de ce choix : les outils alternatifs proposent également la création de paquets RPM, ce que les outils Debian ne permettent pas. 

  3. Il y a différentes façons de numéroter les versions d’un paquet. La façon proposée ici n’est pas plus mauvaise qu’une autre pour Ubuntu. Pour Debian, elle ne couvre pas les mises à jour entre deux versions de la distribution. De nos jours, il est cependant plutôt courant de réinstaller un système plutôt que de le mettre à jour. 

  4. Les paquets devscripts et equivs sont alors nécessaires. 

  5. Il est également possible d’utiliser le script fourni en amont. Toutefois, il n’existe pas de script universel fonctionnant sur toutes les distributions. Il est donc important de vérifier que ce script est adapté à Debian en le comparant au squelette et en vérifiant qu’il utilise bien start-stop-daemon et le fichier /lib/lsb/init-functions. Si c’est le cas, vous pouvez le copier vous-même dans debian/memcached/etc/init.d. debhelper ajoutera les scripts nécessaires à son intégration. 

  6. Un utilisateur désireux de modifier certaines options doit plutôt utiliser systemctl edit

  7. Voir #822670 

  8. La charte Debian ne se prononce pas sur la convention à utiliser. Il est courant de préfixer le nom du démon avec un tiret bas (comme dans les BSD). Un autre usage courant est d’utiliser Debian- comme préfixe. Cette dernière méthode a l’inconvénient de produire un nom d’utilisateur trop long pour être visible dans les utilitaires comme top et ps

  9. Il aurait été possible d’appeler dh_auto_clean à la fin de la cible. Toutefois, nous nous plaçons dans l’hypothèse que chaque construction est faite sur une nouvelle copie issue du système de version. 

02 May, 2016 07:25PM by Vincent Bernat

April 28, 2016

hackergotchi for Tanguy Ortolo

Tanguy Ortolo

Pour des cartes restaurant anonymes

Contexte

Dans les années 2000, la RATP et la SNCF on progressivement imposé le remplacement des tickets de papier anonymes par des cartes à puce nommées Navigo, pour les utilisateurs d'abonnements. Le problème, c'est que ces cartes à puces étaient nominatives, et que dans un pays libre, « aller et venir librement, anonymement, est l’une des libertés fondamentales. » La CNIL a donc imposé la création d'une carte Navigo anonyme.

L'histoire bégaie un peu. Dans les années qui viennent, sous la pression de l'État, les opérateurs de titres restaurant vont progressivement imposer le remplacement des titres de papier anonymes par des cartes à puce, qui permettent un plus grand contrôle des usages, afin d'en limiter les utilisations détournées. Le problème, c'est que ces cartes à puce sont nominatives, et que dans un pays libre, se nourrir, et plus généralement consommer librement, anonymement, est l'une des libertés fondamentales. La CNIL devrait donc imposer la création de cartes restaurant anonymes.

C'est possible

Les opérateurs de titres restaurant objecteront peut-être que c'est techniquement impossible. Pour les aider ainsi que la CNIL, voici une description d'un système qui rendrait possible l'utilisation de cartes restaurant anonymes. Comme pour les cartes de transport, choisir l'anonymat peut impliquer de renoncer à certains avantages.

L'entreprise distribuant des titres restaurant à ses salariés dispose d'un stock de quelques cartes anonymes, seulement identifiées par leur numéro. Comme toute carte restaurant, chacune est associée à un compte initialement vide.

Lorsqu'un salarié demandé à disposer d'une carte anonyme, l'entreprise lui fournit une de ces cartes. Elle peut noter et transmettre à l'opérateur le fait que cette carte est maintenant attribuée, mais a interdiction de relever le nom du salarié qui l'utilise. Si le salarié disposait déjà d'une carte nominative, son numéro doit être relevé afin de cesser d'alimenter le compte correspondant, ce qui peut être traité de la même façon qu'un retrait de l'offre de titres restaurant. Évidemment, l'entreprise a interdiction de tenter de dissuader les salariés de choisir l'anonymat, et de pénaliser ceux qui feraient ce choix.

Chaque mois, lors de la distribution des titres restaurant, le salarié utilisateur d'une carte anonyme se présente en personne, comme cela se fait pour des titres en papier. Le responsable approvisionne le compte correspondant au numéro indiqué sur la carte, et note sur un registre séparé que ce salarié a bien bénéficié de la distribution. L'entreprise a interdiction de noter sur ce registre le numéro de la carte créditée, et, d'une façon générale, de noter ou de transmettre tout ce qui pourrait permettre d'associer les noms des salariés avec les numéros des cartes anonymes. Encore une fois, l'entreprise a interdiction de pénaliser les salariés qui se présentent pour une distribution anonyme.

Le salarié utilise sa carte restaurant de façon normale pour régler ses consommations et achats éligibles dans les conditions prévues. Les restaurateurs de enseignes acceptant les paiements par carte restaurant ont interdiction de pénaliser les utilisateurs de cartes anonymes. Seules les fonctionnalités annexes de gestion peuvent être affectées par le caractère anonyme de la carte : ainsi, en cas de perte, l'opposition sur cette carte ne pourra pas être effectuée avec le seul nom du bénéficiaire, mais nécessitera la connaissance de son numéro, faute de quoi elle ne pourra être réalisé, et le crédit restant devra être considéré comme non récupérable. De telles restrictions doivent être justifiées par une raison technique : ainsi, il ne serait pas admissible de restreindre une opération de promotion chez un restaurateur partenaire aux seuls titulaires de cartes nominatives.

28 April, 2016 05:47PM by Tanguy

April 25, 2016

Parking Méditerranée - Gare de Lyon : attention, hostile aux vélos

Parking Méditerranée

La Gare de Lyon est une grande gare parisienne, qui est desservie à la fois par le réseau régional et par plusieurs grandes lignes nationales. On y trouve donc :

  • des riverains, qui habitent ou travaillent près de la gare ;
  • des usagers quotidiens ;
  • des voyageurs occasionnels, qui partent ou reviennent par exemple de week-end ou de vacances en province.

Le parking Méditerranée, opéré par la SAEMES, est situé sous la gare de Lyon, et accueille le même type de clients :

  • des usagers quotidiens, qui y parquent leur véhicule tous les jours ou toutes les nuits ;
  • des voyageurs occasionnels, qui parquent ponctuellement leur véhicule pour quelques jours, voire quelques semaines.

Cet usage est indépendant du type de véhicule, qu'il s'agisse d'une voiture, d'une moto ou d'une bicyclette.

Théoriquement, un accès vélo

Sur sa page Web, le parking Méditerranée - Gare de Lyon affiche un joli logo vélo, qui suggère la possibilité d'y garer sa bicyclette (qu'est-ce que ça pourrait bien vouloir dire d'autre ?).

De surprise en surprise

La réalité est toute autre. Le voyageur qui arrive à vélo au parking Méditerranée va de surprise en surprise (et de pire en pire) :

  1. L'espace vélo n'est pas indiqué, les panneaux donnant seulement le choix entre l'espace voiture et l'espace moto. Faute de mieux, autant choisir l'espace moto, c'est ce qui se fait de plus approchant.
  2. On est censé prendre un ticket, mais la machine n'en distribue pas aux vélos : on a beau appuyer sur le bouton prévu pour cela, rien ne sort et la barrière reste fermée. Qu'à cela ne tienne, un vélo est suffisamment maniable pour contourner la barrière, mais ça commence mal (et ça va mal finir, mais pour le moment, on a un train à prendre)…
  3. Une fois arrivé dans l'espace moto, comme on peut s'y attendre, rien n'est prévu pour fixer des vélos. Peu importe, un cycliste urbain est de toute façon habitué à stationner comme il le peut, une barrière fera donc l'affaire, en vérifiant bien qu'on ne gêne pas le passage ou le stationnement des autres usagers.
  4. Une fois rentré de voyage, et de retour à la gare de Lyon, on constate que l'exploitant du parking a enchaîné la bicyclette, sans un mot d'explication, sans doute parce qu'elle était mal garée, mais comment pourrait-elle être bien garée puisque l'espace vélos n'est pas indiqué ?
  5. À l'accueil, l'exploitant exige un paiement pour libérer le vélo. Pourquoi pas, mais 15 €, c'est un peu cher pour trois jours de stationnement en occupant zéro emplacement.

Un parking hostile aux vélos

Le parking Méditerranée - Gare de Lyon, qui s'affiche sur le Web avec un espace vélo, est en réalité hostile à ce type de véhicule. Le fait d'afficher un espace vélo, qui s'avère en réalité indisponible, pourrait d'ailleurs relèver de la publicité mensongère.

Suite à cette désagréable expérience, j'ai commencé une enquête sur le stationnement vélo dans les parkings publics des grandes gares parisiennes, dont certains indiquent ainsi disposer d'un espace vélo, qui peut s'avérer inexistant. Affaire à suivre.

25 April, 2016 05:01PM by Tanguy

April 18, 2016

hackergotchi for Raphaël Hertzog

Raphaël Hertzog

Debian 8 Jessie publié chez Eyrolles

Ca y est, une nouvelle édition de mon Cahier de l’Admin Debian vient de paraître aux éditions Eyrolles… couvrant cette fois-ci Debian 8 Jessie et quittant la collection « Cahier de l’Admin » pour intégrer la « Collection Blanche » des livres de référence.

Couverture Debian 8 Jessie

Le livre est disponible chez tous les bons libraires et sa version électronique est toujours disponible gratuitement sur le site officiel du livre. Rappelons que le livre est publié sous licence libre (au choix CC-BY-SA 3.0 ou GPL 2+) et qu’il est co-écrit par deux développeurs Debian (moi même et Roland Mas).

6 commentaires | Vous avez aimé ? Cliquez ici. | Ce blog utilise Flattr.

18 April, 2016 06:47PM by Raphaël Hertzog

Mes activités libres en février et mars 2016

Mon rapport mensuel couvre une grande partie de mes contributions au logiciel libre. Je l’écris pour mes donateurs (merci à eux !) mais aussi pour la communauté Debian au sens large parce que cela peut donner des idées aux nouveaux venus et que c’est également un des moyens les plus effectifs de trouver des volontaires pour travailler sur les projets qui me tiennent à cœur.

J’ai fait l’impasse sur le rapport mensuel de mes activités du mois de février, celui-ci couvrira donc les mois de février et mars. Pour ne pas faire trop long, je vais tâcher de ne lister que les points les plus importants :-).

Cahiers de l’Admin Debian

J’ai travaillé avec Ryuunosuke Ayanokouzi à la préparation d’une version papier de la traduction japonaise de mon livre. Grâce aux efforts de chacun, il est maintenant disponible. Lulu a malheureusement décliné sa prise en charge dans le programme « distribution »; il ne sera donc pas disponible dans les librairies « habituelles » (telles qu’Amazon). La raison étant qu’ils ne supportent pas les ensembles de caractères non-latin dans les métadonnées.

J’ai essayé de feinter le système en entrant la description en anglais (tout en expliquant que le livre était écrit en japonais), mais ils l’ont quand même refusé, arguant que le titre en anglais pouvait induire les gens en erreur. lulu.com est donc la seule option pour se procurer le livre. Les frais de ports restent heureusement raisonnables, en choisissant l’option la plus économique.

A la suite de quoi j’ai enjoint les traducteurs espagnols, brésiliens, italiens et portugais à finir leurs traductions, afin que nous puissions publier des versions papier pour ces langues également. Ils étaient déjà proches du but, toutes les chaînes de caractères étant traduites. Manquaient principalement la localisation des captures d’écran et quelques contenus des première et quatrième de couverture. On y est presque maintenant, j’espère que cela sera fini le mois prochain.

Distro Tracker

Début févier j’ai modifié la configuration, de sorte que les exceptions générées par les emails entrants et les tâches de routine soient maintenant envoyées par email. Elles étaient auparavant simplement enregistrées, mais sans que je prenne le temps de les analyser. Cela a rapidement mis en lumière plusieurs problèmes, que j’ai corrigés au fur et à mesure de leurs apparitions. Par exemple, la gestion des rebonds était défaillante lorsque la casse n’était pas respectée, et il est apparu que certains emails nous revenaient après avoir été passés en minuscule. Le code de contrôle des emails entrants était également défaillant lorsque le champ « References » utilisait plus d’une ligne.

Cela a également fait apparaître tout un ensemble de problèmes liés à la base de données stockant deux fois le même email avec des casses différentes. J’ai du effectuer un nettoyage de la base pour rassembler toutes les entrées en doublon derrière un seul email.

Plus tard les fichiers Source expérimentaux ont changé, ce qui m’a amené à modifier le code pour gérer la suppression du champ « Files » (en me basant à la place sur Checksums-* pour trouver les divers fichiers liés à l’entrée concernée).

J’ai également corrigé le formulaire de connexion, afin qu’il ne génère pas d’exception lorsque l’utilisateur soumet un formulaire vide.

De plus, j’ai décidé de ne plus supporter Django 1.7 dans distro tracker, car Django 1.8 est la version long-terme supportée. J’ai demandé aux administrateurs système Debian de mettre à jour le paquet sur tracker.debian.org avec la version disponible dans jessie-backports. Cela m’a permis de me débarrasser des avertissements qui étaient déclenchés par le code Django 1.7.

Un de ces avertissements était généré par django-jsonfield, et je n’ai pas pu le corriger immédiatement. J’ai préparé à la place une demande de pull que j’ai soumise à l’auteur amont.

Dernière chose : j’ai modifié la feuille CSS pour densifier la mise en page de la page présentant le paquet. C’était l’une des évolutions les plus demandées par les personnes préférant encore packages.qa.debian.org à tracker.debian.org.

Kali et la nouvelle équipe pkg-security

Parmi les différentes tâches effectuées pour Kali, je corrige les bogues critiques pour la publication affectant les paquets Debian que nous utilisons dans Kali. Mais dans la plupart des cas, je suis confronté à des paquets dont les mainteneurs sont aux abonnés absents (MIA, missing in action). Jusqu’à présent, nous n’effectuions que des uploads en tant que non-mainteneur (NMU, non-maintainer upload), mais je souhaite pouvoir maintenir ces paquets de manière plus efficace. C’est pourquoi nous avons créé l’équipe pkg-security . Nous ne sommes que deux à l’heure actuelle, et n’avons aucune documentation disponible. Mais vous êtes les bienvenus si vous souhaitez participer, tout particulièrement si vous maintenez un paquet utilisé dans le domaine de la sécurité.

Travaux liés à l’architecture arm64 Les trois premiers paquets que nous avons pris en charge (ssldump, sucrack, xprobe) ne disposaient pas de binaires compilés pour arm64. Nous venons juste de lancer notre portage Kali sur arm64, et nous avons donc corrigé cela pour cette architecture. Dans la mesure où ces paquets n’étaient plus maintenus correctement, la correction s’est résumée à l’utilisation de dh_autoreconf afin d’obtenir des fichiers config.{sub,guess} à jour.

Quelques paquets sont encore manquants sur arm64 : vboot-utils (que nous récupèrerons très certainement bientôt, puisqu’il est proposé à l’adoption), ruby-libv8 et ruby-therubyracer, ntopng (nous devons attendre le nouveau luajit, qui n’est présent que dans experimental pour l’instant). Nous avons également constaté que dh-make-golang n’était pas disponible pour arm64 et, après quelques discussions sur #debian-buildd, j’ai créé deux rapports de bogue : le n°819472 concernant dh-make-golang et le n°819473 concernant dh-golang.

Corrections de bogues critiques pour la publication De multiples bogues critiques pour la publication affectaient hdparm, et les responsables de la publication ont essayé de le retirer de testing. Ce qui a provoqué le retrait de nombreux paquets utilisés par Kali et ses utilisateurs. J’ai donc analysé la situation dans laquelle se trouvait ce paquet, convaincu les mainteneurs actuels de le déclarer orphelin, ai lancé un appel à de nouveaux mainteneurs sur debian-devel, passé en revue des mises à jours préparées par les volontaires et parrainé leurs travaux. hdparm est maintenant de nouveau exempt de bogues critiques, et au niveau de la dernière version amont. Nous avons également mis à jour jsonpickle vers la version 0.9.3-1 pour corriger le bogue critique n°812114 (que j’avais en premier lieu rapporté à l’auteur).

Support de préréglages Systemd dans init-system-helpers J’ai essayé de trouver quelqu’un pour implémenter (moyennant rémunération) la fonctionnalité de préréglages système que j’avais demandée dans le n°772555, sans y parvenir. Andreas Henriksson a eu l’amabilité de s’y essayer et d’envoyer un premier patch. Je l’ai essayé et trouvé quelques erreurs. Je l’ai donc amélioré et continué à le simplifier… J’ai soumis une mise à jour du patch et fais signe à Martin Pitt. Il m’a renvoyé vers les erreurs que mon patch créait dans la suite de tests DEP-8, que j’ai rapidement corrigés après coup. Ce patch est utilisé dans Kali et nous permet de désactiver les services réseaux par défaut. Je souhaiterais le voir intégrer dans Debian, de sorte que tout-un-chacun puisse configurer de tels préréglages systemd, et qu’ils soient respectés au moment de l’installation.

Rapports de bogues divers J’ai créé le rapport n°813801 pour demander une nouvelle version amont de kismet. De même que pour masscan dans le n°816644 et wkhtmltopdf dans le n°816714. Nous avons empaqueté (avant Debian) une nouvelle version amont de ruby-msgpack, et nous sommes aperçus que la compilation échouait pour armel/armhf. En conséquence de quoi nous avons créé deux tickets amont (avec une proposition de correction). Dans le n°814805, nous avons demandé au mainteneur de pyscard de réintégrer python-pyscard. Seule la version Python3 avait été conservée, la version python2 ayant été abandonnée. C’est pourtant cette dernière que nous utilisons dans Kali.

Et ce n’est pas fini : j’ai créé les rapports n°816553 (erreur de segmentation) et n°816554 concernant cdebootstrap. J’ai demandé que dh-python voit son comportement amélioré, après avoir été induit en erreur par le résultat de « dh –with python3 », qui n’avait pas fait ce que j’attendais (cf. le n°818175). J’ai également rapporté le n°818907 concernant live-build, qui ne gère pas les paquets dont le nom comporte une majuscule (ce qui est effectivement contraire à la règle, mais que dpkg supporte toutefois).

Empaquetages divers

J’ai poussé Django 1.9.2 vers unstable et 1.8.9 vers jessie-backports. J’ai fourni les informations supplémentaires qui m’avaient été demandées par Julien Cristau dans le rapport de bogue n°807654 mais, malgré cela, cette version a été ignorée pour la deuxième mise à jour de Jessie consécutive. Elle est maintenant obsolète jusqu’à ce que j’incorpore les correctifs de sécurité qui ont été publiés entretemps, mais je ne suis pas sûr de le faire…le manque de coopération dont fait preuve l’équipe responsable de la publication pour ce type de requête est décourageant.

J’ai parrainé plusieurs uploads de dolibarr (concernant des mises à jour de sécurité notablement) et tcpdf (correction d’un bogue critique pour la publication).

Merci

Rendez-vous au mois prochain pour un nouveau résumé de mes activités !

Ceci est une traduction de mon article My Free Software Activities in February and March 2016 contribuée par Weierstrass01.

Aucun commentaire pour le moment | Vous avez aimé ? Cliquez ici. | Ce blog utilise Flattr.

18 April, 2016 08:25AM by Raphaël Hertzog

April 17, 2016

Florent Gallaire

Mehdi Dogguy élu DPL pour 2016

C’est Mehdi Dogguy qui vient d’être élu Debian Project Leader (DPL) pour l’année 2016, succédant ainsi au mandat de Neil McGovern, contre qui il avait perdu en 2015.

Mehdi Dogguy

Ce n’est bien sûr pas une surprise puisque Mehdi était le seul candidat, et qu’il n’y avait aucune raison valable de lui préférer « None of The Above » et ainsi de provoquer de nouvelles élections. Voici une représentation du résultat du scrutin qui utilise la méthode Condorcet :

Vote DPL 2016

Ce vote confirme cependant la place importante prise par la France dans le projet Debian ces dernières années, après les trois mandats de Stefano Zacchiroli et les deux mandats de Lucas Nussbaum.

Bravo à toi Mehdi, et bonne chance dans la mise en œuvre de ton programme !

17 April, 2016 02:39PM by fgallaire

April 11, 2016

Carl Chenet

Richard Stallman ce samedi à Choisy-le-roi

Pour information j’ai découvert ce week-end que Richard Stallman sera présent à la médiathèque de Choisy-le-roi ce samedi 16 avril 2016 à 17h.

Pour information des Parisiens indécrottables, c’est en très proche banlieue parisienne :p Comptez par exemple entre 20 et 30 mn depuis le centre de Paris en passant par le RER C pour y arriver.

saint-stallman

Bref si vous n’avez jamais vu le monsieur et ses célèbres conférences ou que vous aimeriez une mise-à-jour sur ses positions, c’est l’occasion de le voir. Pour ma part j’y serai.

Peut-être à samedi donc 😉

11 April, 2016 06:53AM by Carl Chenet

April 10, 2016

hackergotchi for Vincent Bernat

Vincent Bernat

Test d'un applicatif réseau avec pytest et les espaces de noms Linux

Initié en 2008, lldpd est une implémentation en C du standard IEEE 802.1AB-2005 (aussi connu comme LLDP). Bien qu’il soit accompagné de quelques tests unitaires, comme beaucoup d’autres applicatifs réseaux, la couverture de ceux-ci est assez restreinte : il sont plutôt difficile à écrire en raison de l’aspect impératif du code et du couplage fort avec le système. Une réécriture (itérative ou complète) aiderait à rendre le code plus simple à tester, mais cela nécessiterait un effort important et introduirait de nouveaux bugs opérationnels.

Afin d’obtenir une meilleure couverture des tests, les fonctionnalités les plus importantes de lldpd sont désormais vérifiées à travers des tests d’intégration. Ceux-ci se reposent sur l’utilisation des espaces de noms Linux pour mettre en place des environnements isolés légers pour chaque test. pytest est utilisé comme outil de test.

pytest en bref§

pytest est un outil de tests pour Python dont la versatilité permet son usage dans de nombreuses situations. Il dispose de trois fonctionnalités remarquables :

  • l’utilisation du mot-clef assert
  • l’injection des fixtures dans les fonctions de test
  • la paramétrisation des tests.

Les assertions§

Avec unittest, l’outil de tests unitaires fourni avec Python, les tests sont encapsulés dans une classe et doivent faire appel à des méthodes dédiées pour les assertions. Par exemple :

class testArithmetics(unittest.TestCase):
    def test_addition(self):
        self.assertEqual(1 + 3, 4)

Avec pytest, il est possible d’exprimer ceci plus naturellement :

def test_addition():
    assert 1 + 3 == 4

pytest va analyser l’AST et afficher des messages d’erreur appropriés en cas d’échec. Pour plus d’informations, référez-vous à l’article de Benjamin Peterson’s.

Les fixtures§

Une fixture est un ensemble d’actions à effectuer afin de préparer le système à exécuter une série de tests. Avec les outils classiques, il n’est souvent possible de définir qu’une seule fixture pour une ensemble de tests :

class testInVM(unittest.TestCase):

    def setUp(self):
        self.vm = VM('Test-VM')
        self.vm.start()
        self.ssh = SSHClient()
        self.ssh.connect(self.vm.public_ip)

    def tearDown(self):
        self.ssh.close()
        self.vm.destroy()

    def test_hello(self):
        stdin, stdout, stderr = self.ssh.exec_command("echo hello")
        stdin.close()
        self.assertEqual(stderr.read(), b"")
        self.assertEqual(stdout.read(), b"hello\n")

Dans l’exemple ci-dessus, nous voulons tester quelques commandes sur une machine virtuelle. La fixture démarre la VM et initie la connexion SSH. Toutefois, en cas d’échec de cette dernière, la méthode tearDown() ne sera pas appelée et la VM continuera de tourner.

Avec pytest, il est possible de faire les choses différemment :

@pytest.yield_fixture
def vm():
    r = VM('Test-VM')
    r.start()
    yield r
    r.destroy()

@pytest.yield_fixture
def ssh(vm):
    ssh = SSHClient()
    ssh.connect(vm.public_ip)
    yield ssh
    ssh.close()

def test_hello(ssh):
    stdin, stdout, stderr = ssh.exec_command("echo hello")
    stdin.close()
    stderr.read() == b""
    stdout.read() == b"hello\n"

La première fixture démarre une VM. La seconde va fournir une connexion SSH vers la VM fournie en argument. Les fixtures sont utilisées à travers un système d’injection des dépendences : la seule présence de leur nom dans la signature d’une fonction de test ou d’une autre fixture suffit à l’utiliser. Chaque fixture ne gère le cycle de vie que d’une seule entité. Peu importe si une autre fixture ou une fonction de tests dépendant de celle-ci réussit ou non, la VM sera démantelée en fin de test.

La paramétrisation§

Si un test doit être exécuté plusieurs fois avec des paramètres différents, la solution classique est d’utiliser une boucle ou de définir dynamiquement les fonctions de test. Avec pytest, vous pouvez paramétriser une fonction de test ou une fixture :

@pytest.mark.parametrize("n1, n2, expected", [
    (1, 3, 4),
    (8, 20, 28),
    (-4, 0, -4)])
def test_addition(n1, n2, expected):
    assert n1 + n2 == expected

Tester lldpd§

Tester une fonctionnalité de lldpd se fait en cinq étapes :

  1. Mettre en place deux espaces de noms.
  2. Créer un lien virtuel entre ceux-ci.
  3. Démarrer un processus lldpd dans chaque espace.
  4. Tester la fonctionnalité dans un des espaces.
  5. Vérifier avec lldpcli le résultat attendu dans l’autre espace.

Voici un test typique utilisant les fonctionnalités les plus intéressantes de pytest :

@pytest.mark.skipif('LLDP-MED' not in pytest.config.lldpd.features,
                    reason="LLDP-MED not supported")
@pytest.mark.parametrize("classe, expected", [
    (1, "Generic Endpoint (Class I)"),
    (2, "Media Endpoint (Class II)"),
    (3, "Communication Device Endpoint (Class III)"),
    (4, "Network Connectivity Device")])
def test_med_devicetype(lldpd, lldpcli, namespaces, links,
                        classe, expected):
    links(namespaces(1), namespaces(2))
    with namespaces(1):
        lldpd("-r")
    with namespaces(2):
        lldpd("-M", str(classe))
    with namespaces(1):
        out = lldpcli("-f", "keyvalue", "show", "neighbors", "details")
        assert out['lldp.eth0.lldp-med.device-type'] == expected

Tout d’abord, ce test ne sera exécuté que si le support de LLDP-MED a été inclu dans lldpd. De plus, le test est paramétré : quatre tests distincts seront effectués, un pour chaque rôle que lldpd doit être capable d’assumer en tant que terminaison LLDP-MED.

La signature du test comporte quatre paramètres non couverts par le décorateur parametrize() : lldpd, lldpcli, namespaces et links. Il s’agit des fixtures.

  • lldpd est une fabrique qui permet de lancer des instances de lldpd. Elle assure la configuration de l’espace de noms (mise en place de la séparation de privilèges, unformisation de certains fichiers, …) puis appelle lldpd avec les paramètres additionnels fournis. Les messages émis par le démon sont enregisrés dans le rapport en cas d’erreur. Le module se charge aussi de fournir un objet pytest.config.lldpd qui contient les fonctionnalités supportées par lldpd afin de sauter les tests qui nécessitent une fonctionnalité non disponible. Le fichier fixtures/programs.py contient davantage de détails.

  • lldpcli est également une fabrique, mais pour lancer des instances de lldpcli, le client pour interroger lldpd. De plus, la sortie produite est traitée pour obtenir un dictionnaire et faciliter l’écriture des tests.

  • namespaces est la fixture la plus intéressante. Il s’agit d’une fabrique pour les espaces de noms Linux. Elle va créer un nouvel espace de nom ou référencer un espace existant. Il est possible d’entrer dans un espace donné avec le mot-clef with. La fabrique maintient pour chaque espace une liste de descripteurs de fichiers sur lesquels exécuter setns(). Une fois le test fini, les espaces de noms sont détruits naturellement du fait de la fermeture de tous les descripteurs de fichiers. Le fichier fixtures/namespaces.py contient davantage de détails. Cette fixture est réutilisable par d’autres projets1.

  • links contient des fonctions pour gérer les interfaces réseau : création d’une paire d’interfaces Ethernet entre deux espaces de noms, création de ponts, d’aggrégats et de VLAN, etc. Il se repose sur le module pyroute2. Le fichier fixtures/network.py contient davantage de détails.

Vous pouvez découvrir un exemple d’exécution de ces tests en regardant le résultat obtenu avec Travis pour la version 0.9.2. Chaque test étant isolé, il est possible de les lancer en parallèle avec pytest -n 10 --boxed. Afin de dépister encore plus de bugs, à la compilation, l’address sanitizer (ASAN) et le undefined behavior sanitizer (UBSAN) sont activés. En cas de problème détecté, comme par exemple une fuite mémoire, le programme s’arrêtera avec un code de sortie non nul et le test associé échouera.


  1. Il y a trois principales limitations concernant l’usage des espaces de noms avec cette fixture. Tout d’abord, lors de la création d’un user namespace, seul root est lié avec l’utilisateur actuel. lldpd nécessite deux utilisateurs (root et _lldpd). Aussi, il n’est pas possible de se reposer sur cette fonctionnalité pour faire tourner les tests sans être root. La seconde limitation concerne les PID namespace. Il n’est pas possible pour un process de changer de PID namespace. L’appel de setns() ne sera effectif que pour les descendants du process. Il est donc important de ne monter /proc que dans les descendants. La dernière limitation concerne les fils d’exécution : ils doivent tous être dans le même user namespace et PID namespace. Le module threading doit donc être remplacé par l’utilisation du module multiprocessing

10 April, 2016 04:22PM by Vincent Bernat

April 07, 2016

Carl Chenet

“La” communauté du Logiciel Libre, ça n’existe pas

J’avais depuis quelques temps envie d’écrire un billet de blog au sujet de la soi-disant communauté du Logiciel Libre et le dernier article de Frédéric Bezies , où il regrette le manque de coordination et d’unité de cette communauté, m’a donné la motivation pour finalement expliquer pourquoi tant de gens se désillusionnent quant à “cette” communauté.

“La” communauté du Logiciel Libre, ça n’existe pas

Il est en effet vain dans la plupart des cas de parler de “la” communauté du Logiciel Libre. On peut – et je le fais souvent moi-même – parler de la communauté du Logiciel Libre pour regrouper dans un même sac tous les acteurs touchant de près ou de loin au Logiciel Libre, mais c’est une dénomination vague, peu précise et que l’on ne doit pas employer à tort et à travers.

Et pour cause, car aussi bien d’un point de vue technique que d’un point de vue idéologique, nous, les acteurs de cette soi-disant communauté, sommes profondément et sûrement irrémédiablement divisés.

Les communautés techniques

Rappelons-le car beaucoup de personnes même proches du Logiciel Libre ont tendance à l’oublier. 99% du temps, un projet du Logiciel Libre, c’est au départ un individu isolé non rémunéré qui se motive et prend son courage à deux mains pour écrire du code et porter seul – au moins au début – un projet pour répondre à un besoin existant qui le dérange lui.

Ce faisant, il s’insère dans une communauté technique, celle des outils qu’il utilise pour régler son problème, puis le jour où son projet est prêt, s’il fait le choix de le rendre public, dans une communauté idéologique répondant aux critères que l’on verra au chapitre suivant.

python-logo-master-v3-TM

La communauté Python, avec sa propre licence : la PSF, sa propre vision, ses propres objectifs

Au premier niveau, le développeur du Logiciel Libre, c’est donc un utilisateur des outils qui sont mis à disposition par une communauté technique. Il adhère souvent aux idées derrière les outils qu’ils utilisent au quotidien parce qu’il y voit un avantage direct et ressent la cohérence des choix techniques et idéologiques faits par la communauté l’ayant précédé.

Maintenant si on parle de “la” communauté du Logiciel Libre, ça sous-entend que le premier niveau dont je parlais à l’instant se fond  dans un deuxième niveau, un niveau plus vaste, plus abstrait, plus global. Donc plus éloigné du développeur au quotidien, touchant des problématiques qu’il ne ressent peut-être pas tous les jours.

Alors qu’au quotidien pour lui, “sa” communauté, c’est par exemple le langage Python et ses membres, pas Perl. Ou la distribution Debian et les buts du projet Debian, pas les systèmes BSD. On se construit donc aussi en opposition à d’autre communautés techniques et idéologiques.

freebsd

FreeBSD, système d’exploitation et suite d’outils qui privilégient la licence BSD

Les développeurs contribuent donc – le plus souvent dans le cadre de leur temps libre, le plus souvent de façon non-rémunérée, et dans ce domaine seule la motivation permet d’avancer – aux sujets qui nous intéressent et nous motivent au sein d’une communauté technique et idéologique et pas sur les sujets dont “la communauté du Logiciel Libre” aurait besoin.

La diversité des acteurs et de leurs idées, de leurs approches techniques et des solutions qu’ils trouvent au quotidien  sont les éléments qui rendent aussi attractif pour beaucoup d’entre nous ce milieu technique et idéologique.

GPL contre BSD/MIT

J’ai évoqué et développé ce point dans l’un de mes précédents articles le danger Github : d’un point de vue idéologique, principalement deux idées du Logiciel Libre coexistent.

La vision incarnée par la licence GPL peut être résumée à une notion fondamentale intégrée par ses défenseurs et ses détracteurs : contaminante.  La GPL va nourrir d’elle-même la communauté en réinjectant automatiquement dans le parc logiciel sous GPL tous les dérivés des logiciels eux-mêmes sous GPL. La communauté sert la communauté. Les utilisateurs de la GPL trouvent cohérents de n’utiliser que du Logiciel Libre pour ne pas nourrir l’ennemi , c’est-à-dire le logiciel privateur.

Les licences BSD/MIT sont pour leur part plus permissives, permissives à l’extrême. Rappelons qu’un logiciel dérivé d’un logiciel sous licence  BSD/MIT peut être déposé sous une licence propriétaire. Les licences BSD/MIT sont donc non-contaminantes. On a donc la liberté de rendre un logiciel – libre à la base – privateur. Ce qui se fait beaucoup et l’on retrouve les systèmes d’exploitation BSD dans nombre de système d’exploitation propriétaires. voir à ce sujet la liste à couper le souffle des produits commerciaux reposant sur FreeBSD.

Les défenseurs des licences BSD/MIT parlent de liberté réelle face à la GPL, ses détracteurs de la liberté de se tirer une balle dans le pied. Étant donné que les défenseurs de ces licences permissives type BSD/MIT trouvent normal la coexistence du Logiciel Libre et du logiciel privateur, ils utilisent eux-mêmes les deux sans problème, ce qui est cohérent idéologiquement.

bsdvsgpl

Donc au final deux visions très différentes du Logiciel Libre – la GPL plus conquérante, les BSD/MIT plus flexibles – coexistent.

Des communautés constituent le Logiciel Libre

On l’a vu, il serait donc plus précis de parler des communautés qui constituent le Logiciel Libre. Elles sont à la fois techniques et idéologiques et apportent des outils concrets à leurs membres. Elles se définissent par rapport à ce qu’elles construisent, à leurs contributions, mais aussi par opposition aux autres communautés techniques et idéologiques. Il est donc impossible de parler d’une communauté du Logiciel Libre, à moins de la réduire au peu d’idées transverses aux différentes communautés techniques et idéologique la constituant.

J’ai pu remarquer que de nombreux intervenants parlent souvent de la communauté du Logiciel Libre pour parler en fait d’un sous-ensemble de celle-ci, en fait de leur communauté.Par exemple un défenseur de la GPL va parler de la communauté du Logiciel Libre en omettant l’idée de liberté complète derrière les licences BSD/MIT. Ou un idéologue auto-proclamé du Logiciel Libre va déclarer de grandes directions que “le Logiciel Libre” devrait prendre dans une approche top-down alors que, comme nous l’avons vu, tous les contributeurs techniques du Logiciel libre intègrent avant tout une communauté technique et idéologique précise, un sous-ensemble de “la” communauté du Logiciel libre.

troll

Les trolls, une activité prisée des Libristes

Au final il est peut-être rageant de voir au quotidien des projets s’affronter, se troller, de voir des projets réinventer ce qui existent déjà au lieu de l’améliorer. Il semble même incompréhensible de voir des projets entièrement recoder pour des questions de licences ou parfois juste d’ego entre membres de ce qu’on croit être une même communauté. Mais cela tient à une incompréhension de l’organisation et des interactions des projets du Logiciel Libre entre eux.

L’explication tient au fait que le Logiciel Libre est constitué de nombreuses communautés, qui partagent quelques grandes idées communes certes, mais qui portent chacune des solutions techniques, une vision et une identité propres. Elles arrivent à se rejoindre très ponctuellement autour d’un effort commun sur un point extrêmement consensuel, mais il sera tout simplement impossible de les faire toutes et en permanence converger vers des grands objectifs qui bénéficieraient (ou pas) à  une vague communauté globale dans laquelle se reconnaîtraient tous les acteurs du Logiciel Libre.

La diversité des communautés qui le compose fait la force du Logiciel Libre, nous partageons quelques grandes idées et nous inventons au quotidien nos propres solutions. Et c’est de cette façon que nous avons avancé jusqu’à aujourd’hui.

07 April, 2016 10:00PM by Carl Chenet

hackergotchi for Charles Plessy

Charles Plessy

Les entrées FreeDesktop entrent dans la charte Debian.

Après une longue pérégrination qui a duré près de trois ans, l'utilisation des entrées de menu FreeDesktop est enfin décrite dans notre Charte.

En bonus, cette nouvelle version 3.9.8 de la Charte rappelle aussi qu'il faut enregistrer les nouveaux types de média chez l'IANA.

Merci à tous ceux qui ont rendu ceci possible.

07 April, 2016 01:03PM

April 03, 2016

Carl Chenet

Nouveau forum pour l’emploi dans la communauté du Logiciel Libre et opensource

Un rapide message pour annoncer le lancement d’un forum dédié à l’emploi dans la communauté du Logiciel Libre et opensource, Le forum de LinuxJobs.fr : https://forum.linuxjobs.fr

forum-small

Devant le succès de LinuxJobs.fr , le site d’emploi de la communauté du Logiciel Libre et opensource, et la communauté d’utilisateurs qui s’est constitué autour, il était dommage de s’arrêter à l’échange d’offres d’emplois. C’est pourquoi LinuxJobs.fr créé un lieu d’échange et de discussions pour sa communauté, avec des catégories comme les rémunérations, le droit du travail, les questions des jeunes diplômés, des les étudiants ou l’entrepreunariat.

banieres linux vert

Ce nouveau forum est fièrement propulsé par le nouveau moteur de forums Flarum, un logiciel libre sous licence MIT.

Au plaisir de discuter bientôt avec vous sur le forum de LinuxJobs.fr.

Quelques liens pour finir :

03 April, 2016 10:00PM by Carl Chenet

March 31, 2016

Le danger Github (revu et augmenté)

Alors que le projet CPython (implémentation historique du projet Python) a annoncé son passage chez Github (avec quelques restrictions, nous reviendrons là-dessus), il est plus que jamais important de s’interroger sur les risques encourus d’utiliser un logiciel propriétaire dans notre chaîne de création du Logiciel Libre.

Des voix critiques s’élèvent régulièrement contre les risques encourus par l’utilisation de Github par les projets du Logiciel Libre. Et pourtant l’engouement autour de la forge collaborative de la startup Californienne à l’octocat continue de grandir.

codercat

L’octocat, mascotte de Github

Ressentis à tort ou à raison comme simples à utiliser, efficaces à l’utilisation quotidienne, proposant des fonctionnalités pertinentes pour le travail collaboratif en entreprise ou dans le cadre d’un projet de Logiciel Libre, s’interconnectant aujourd’hui à de très nombreux services d’intégration continue, les services offerts par Github ont pris une place considérable dans l’ingénierie logicielle ces dernières années.

Quelles sont ces critiques et sont-elles justifiées ? Nous proposons de les exposer dans un premier temps dans la suite de cet article avant de peser le pour ou contre de leur validité.

1. Points critiques

1.1 La centralisation

L’application Github appartient et est gérée par une entité unique, à savoir Github, inc, société américaine. On comprend donc rapidement qu’une seule société commerciale de droit américain gère l’accessibilité à la majorité des codes sources des applications du Logiciel Libre, ce qui représente un problème pour les groupes utilisant un code source qui devient indisponible, pour une raison politique ou technique.

github-logo

De plus cette centralisation pose un problème supplémentaire : de par sa taille, ayant atteint une masse critique, elle s’auto-alimente. Les personnes n’utilisant pas Github, volontairement ou non, s’isolent de celles qui l’utilisent, repoussées peu à peu dans une minorité silencieuse. Avec l’effet de mode, on est pas “dans le coup” quand on n’utilise pas Github, phénomène que l’on rencontre également et même devenu typique des réseaux sociaux propriétaires (Facebook, Twitter, Instagram).

1.2 Un logiciel privateur

Lorsque vous interagissez avec Github, vous utilisez un logiciel privateur, dont le code source n’est pas accessible et qui ne fonctionne peut-être pas comme vous le pensez. Cela peut apparaître gênant à plusieurs points de vue. Idéologique tout d’abord, mais peut-être et avant tout pratique. Dans le cas de Github on y pousse du code que nous contrôlons hors de leur interface. On y communique également des informations personnelles (profil, interactions avec Github). Et surtout un outil crucial propriétaire fourni par Github qui s’impose aux projets qui décident de passer chez la société américaine : le gestionnaire de suivi de bugs.

windows

Windows, qui reste le logiciel privateur par excellence, même si d’autres l’ont depuis rejoint

1.3 L’uniformisation

Travailler via l’interface Github est considéré par beaucoup comme simple et intuitif. De très nombreuses sociétés utilisent maintenant Github comme dépôt de sources et il est courant qu’un développeur quittant une société retrouve le cadre de travail des outils Github en travaillant pour une autre société. Cette fréquence de l’utilisation de Github dans l’activité de développeur du Libre aujourd’hui participe à l’uniformisation du cadre de travail dudit développeur.

L'uniforme évoque l'armée, ici l'armée des clones

L’uniforme évoque l’armée, ici l’armée des clones

2. Validité des points critiques

2.1 Les critiques de la centralisation

2.1.1 Taux de disponibilité du service

Comme dit précédemment, Github est aujourd’hui la plus grande concentration de code source du Logiciel Libre. Cela fait de lui une cible privilégiée.  Des attaques massives par dénis de service ont eu lieu en mars et août 2015. De même, une panne le 15 décembre 2015 a entraîné l’indisponibilité de 5% des dépôts. Idem le 15 novembre. Et il s’agit des incidents récents déclarés par les équipes de Github elles-mêmes. On peut imaginer un taux d’indisponibilité moyen des services bien supérieur.

githubdown

2.1.2 Blocage de la construction du Logiciel Libre par réaction en chaîne

Aujourd’hui plusieurs outils de gestion des dépendances comme npm dans le monde javascript, Bundler dans le monde Ruby ou même pip pour le monde Python sont capables d’aller chercher le code source d’une application directement depuis Github. Les projets du Logiciel Libre étant de plus en plus intriqués, dépendants les uns des autres, si l’un des composants de la chaîne de construction vient à manquer, c’est toute la chaîne qui s’arrête.

Un excellent exemple de cet état de fait est la récente affaire du npmgate (voir l’article Du danger d’un acteur non-communautaire dans votre chaîne de production du Logiciel Libre). Github peut très bien demain être mis en demeure par une entreprise de retirer du code source de son dépôt, ce qui pourrait entraîner une réaction en chaîne menant à l’impossibilité de construire de nombreux projets du Logiciel Libre, comme cela vient d’arriver à la communauté Node.js à cause de la société Npm, inc. gérant l’infrastructure de l’installeur automatisé npm.

2.2 Un peu de recul historique : SourceForge

Même si l’ampleur du phénomène n’a pas été la même, il est bon de rappeler que Github n’est pas apparu ex-nihilo et avait un prédécesseur ayant joui en son temps d’un engouement important : SourceForge.

Fortement centralisé, reposant également sur de fortes interactions avec la communauté, SourceForge est un SAAS fortement vieillissant  ces dernières années et subit une véritable hémorragie de ses utilisateurs au profit de Github. Ce qui signifie beaucoup d’ennuis pour ceux qui y sont restés. Pour le projet Gimp, il s’agit tout d’abord d’abus publicitaires trompeurs indignes, qui entraînent également le départ du projet VLC , puis l’apparition d’installeurs comprenant des adwares se faisant passer pour l’installeur officiel Windows de Gimp. Et enfin purement et simplement le piratage du compte SourceForge du projet Gimp par… les équipes de SourceForge elle-même.

Nous voyons ici des exemples récents et très concrets des pratiques dont sont capables les sociétés commerciales lorsqu’elles sont sous la pression de leurs actionnaires. D’où la nécessité de bien comprendre l’enjeu représenté par le fait de leur confier une centralisation des données et des échanges ayant de fortes conséquences sur le fonctionnement et les usages de la communauté du Logiciel Libre et opensource.

 

2.3 Les critiques relatives à utiliser un logiciel privateur

2.3.1 Une communauté, différents rapports au logiciel propriétaire

Cette critique, avant tout idéologique, se heurte à la conception même que chacun des membres de la communauté se fait du Logiciel Libre et opensource, et en particulier d’un critère : contaminant ou non, qu’on résume en général par GPL versus MIT/BSD.

 

bsdvsgpl

Les défenseurs du Logiciel Libre contaminant vont être gênés d’utiliser un logiciel propriétaire car ce dernier ne devrait pas exister. Il doit être assimilé, pour citer Star Trek,  car il est une boîte noire communicante, qui met en danger la vie privée, détourne nos usages à des fins commerciales, gêne ou contraint la liberté de jouir entièrement de ce qu’on a acquis, etc.

gplv3

Les pendants d’une totale liberté sont moins complexés dans leur utilisation des logiciels privateurs puisqu’ils acceptent l’existence desdits logiciels privateurs au nom d’une liberté sans restriction. Ils acceptent même que le code qu’ils développent aboutissent dans ces logiciels, ce qui arrive bien plus souvent qu’on ne le croit, voir à ce sujet la liste à couper le souffle des produits commerciaux reposant sur FreeBSD. On peut donc voir dans cette aile de la communauté du Logiciel Libre une totale sérénité à utiliser Github. Et ce qui est cohérent vis-à-vis de l’idéologie soutenue. Si vous êtes déjà allé au Fosdem, un coup d’œil dans l’amphithéâtre Janson permet de se rendre compte de la présence massive de portables Apple tournant sous MacOSX.

FreeBSD, principal projet des BSD sous licence MIT

FreeBSD, principal projet des BSD sous licence BSD

2.3.2 Les pertes de données et obstructions liées à l’usage d’un logiciel privateur

Mais au-delà de cet aspect idéologique pur et pour recentrer sur l’infrastructure de Github elle-même, l’utilisation du gestionnaire de suivi de bugs de Github pose un problème incontournable. Les rapports de bugs sont la mémoire des projets du Logiciel Libre. Il constitue le point d’entrée des nouveaux contributeurs, des demandes de fonctionnalités, des rapports de bugs et donc la mémoire, l’histoire du projet qui ne peut se limiter au code seul. Il est courant de tomber sur des rapports de bugs lorsque vous copiez/collez votre message d’erreur dans un moteur de recherche. Mémoire précieuse non seulement pour le projet lui-même, mais aussi pour ses utilisateurs actuels et à venir.

Github propose d’extraire les rapports de bugs via son API, certes, mais combien de projets anticiperont une éventuelle défaillance de Github  ou un retournement de situation arrêtant brusquement le service ? Très peu à mon avis. Et comment migrer vers un nouveau système de suivi de bugs les données fournies par Github ?

L’exemple de l’utilitaire de gestion de listes de choses à faire (TODO list) Astrid, racheté par Yahoo! il y a quelques années reste un très bon exemple de service ayant grandi rapidement, largement utilisé et qui a fermé du jour au lendemain, proposant pendant quelques semaines seulement d’extraire ses données. Et il s’agissait là d’un simple gestionnaire de tâches à faire. Le même problème chez Github serait dramatiquement plus difficile à gérer pour de très nombreux projets, si on leur laisse la possibilité de le gérer. Certes le code reste disponible et pourra continuer de vivre ailleurs, mais la mémoire du projet sera perdue, alors qu’un projet comme Debian approche aujourd’hui les 800000 rapports de bugs. Une vraie mine d’or d’informations sur les problèmes rencontrés, les demandes de fonctionnalités et le suivi de ces demandes. Les développeurs du projet CPython passant chez Github ont anticipé ce problème et ne vont pas utiliser le système de suivi de bugs de Github.

mastering-issues

Issues, le suivi de bug propriétaire de Github

Autre perte si Github disparaît ou devient inaccessible : le travail de revue des “push requests” (abrégées par PRs) en cours. Pour les lecteurs qui ne connaîtraient pas cette fonctionnalité de Github, il s’agit d’adresser de cloner le dépôt Github d’un projet, de modifier ce clone pour l’adapter à vos besoins, puis ensuite de proposer vos modifications au dépôt d’origine. Le propriétaire du dépôt d’origine va alors étudier les modifications qui lui ont été proposées et si elles lui conviennent les fusionner à son propre dépôt. Il s’agit donc d’une fonctionnalité très importante offerte de Github, qui propose de réaliser les différentes opérations graphiquement via son interface.

Toutefois le travail de revue des modifications proposées peut être long et il est courant d’avoir, pour un projet qui marche bien, plusieurs PRs en cours. Et il est également courant d’échanger des commentaires via ces PRs et/ou via le système de suivi de bugs propriétaires de Github dont nous avons parlé plus haut.

Le code en lui-même n’est donc pas perdu si Github devient inaccessible (quoique, voire plus bas un cas spécifique), mais le travail de revue matérialisée par les éventuels demandes et commentaires présents dans les PRs et les suivis de bugs associés l’est bien, lui. Rappelons également que Github permet de cloner des projets via son interface web propriétaire, puis d’y apporter toujours via la même interface des modifications et ensuite de générer des PRs sans télécharger aucunement le code sur son poste. Dans ce cas de figure, si Github devient indisponible, la perte du code et du travail en cours est totale.

Enfin certains utilisateurs se servent de Github entre autre comme d’une application de favoris, afin de suivre l’activité de leurs projets préférés en s’abonnant à ces projets par la fonctionnalité “Watch”.  Ce travail de réunion de données pour la veille technologique est perdu  en cas d’indisponibilité du service Github.

Proposed Debian Logo

Debian, l’un des principaux projets du Logiciel Libre avec autour de 1000 contributeurs officiels

 

2.4 L’uniformisation

La communauté du Logiciel Libre oscille sans cesse entre un besoin de normes afin de réduire le travail nécessaire pour l’interopérabilité et l’attrait de la nouveauté, caractérisée par l’intrinsèque besoin de différence vis-à-vis de l’existant.

Github a popularisé l’utilisation de Git, magnifique outil qui aujourd’hui touche des métiers bien différents des programmeurs auxquels il était initialement lié. Peu à peu, tel un rouleau compresseur, Git a pris une place si centrale que considérer l’usage d’un autre gestionnaire de sources est quasiment impossible aujourd’hui, particulièrement en entreprise, malgré l’existence de belles alternatives qui n’ont malheureusement pas le vent en poupe, comme Mercurial.

git-logo

Un projet de Logiciel Libre qui naît aujourd’hui, c’est un dépôt Git sur Github avec un README.md pour sommairement le décrire. Les autres voies sont totalement ostracisées. Et quelle est la punition pour celui qui désobéit ? Peu ou pas de contributeurs potentiels. Il semble très difficile de pousser aujourd’hui le contributeur potentiel à se lancer dans l’apprentissage d’un nouveau gestionnaire de sources ET une nouvelle forge pour chaque projet auquel on veut contribuer. Un effort que fournissait pourtant tout un chacun il y a quelques années.

Et c’est bien dommage car Github, en proposant une expérience unique et originale à ses utilisateurs, taille  à grands coups de machette dans les champs des possibles. Alors oui, sûrement que Git est aujourd’hui le meilleur des système de gestion de versions. Mais ça n’est pas grâce à cette domination sans partage qu’un autre pourra émerger. Et cela permet à Github d’initier à Git les nouveaux arrivants dans le développement  à un ensemble de fonctionnalités très restreint, sans commune mesure avec la puissance de l’outil Git lui-même.

3. Centralisation, uniformisation, logiciels privateurs et bientôt… fainéantise ?

Le combat contre la centralisation est une part importante de l’idéologie du Logiciel Libre car elle accroît le pouvoir de ceux qui sont chargés de cette centralisation et qui la contrôlent sur ceux qui la subissent. L’aversion à l’uniformisation née du combat contre les grandes firmes du logiciel souhaitant imposer leur vision fermée et commerciale du monde du logiciel a longtemps nourri la recherche réelle d’innovation et le développement d’alternatives brillantes. Comme nous l’avons décrit, une partie de la communauté du Libre s’est construit en opposition aux logiciels privateurs, les considérant comme dangereux. L’autre partie, sans vouloir leur disparition, a quand même choisi un modèle de développement à l’opposé de celui des logiciels privateurs, en tout cas à l’époque car les deux mondes sont devenus de plus en plus poreux au cours des dernières années.

 

L’effet Github est donc délétère au point de vue des effets qu’il entraîne : la centralisation,  l’uniformisation, l’utilisation de logiciels privateurs comme leur système de gestion de version, au minimum. Mais la récente affaire de la lettre “Cher Github…” met en avant un dernier effet, totalement inattendu de mon point de vue : la fainéantise. Pour les personnes passées à côté de cette affaire, il s’agit d’une lettre de réclamations d’un nombre très important de représentants de différents projets du Logiciel Libre qui réclament à l’équipe de Github d’entendre leurs doléances, apparemment ignorées depuis des années, et d’implémenter de nouvelles fonctionnalités demandées.

Mais depuis quand des projets du Logiciel Libre qui se heurtent depuis des années à un mur tentent-ils de faire pleurer le mur et n’implémentent pas la solution qui leur manquent ? Lorsque Torvald a subi l’affaire Bitkeeper et que l’équipe de développement du noyau Linux n’a plus eu l’autorisation d’utiliser leur gestionnaire de versions, Linus a mis au point Git. Doit-on rappeler que l’impossibilité d’utiliser un outil ou le manque de fonctionnalités d’un programme est le moteur principal de la recherche d’alternative et donc du Logiciel Libre ? Tous les membres de la communauté du Logiciel Libre capable de programmer devrait avoir ce réflexe. Vous n’aimez pas ce qu’offre Github ? Optez pour Gitlab. Vous n’aimez pas Gitlab ? Améliorez-le ou recodez-le.

gitlab

Logo de Gitlab, une alternative possible à Github

Que l’on soit bien d’accord, je ne dis pas que tout programmeur du Libre qui fait face à un mur doit coder une alternative. En restant réaliste, nous avons tous nos priorités et certains de nous aiment dormir la nuit (moi le premier). Mais lorsqu’on voit 1340 signataires de cette lettre à Github et parmi lesquels des représentants de très grands projets du Logiciel Libre, il me paraît évident que les volontés et l’énergie pour coder une alternative existe. Peut-être d’ailleurs apparaîtra-t-elle suite à cette lettre, ce serait le meilleur dénouement possible à cette affaire.

Finalement, l’utilisation de Github suit cette tendance de massification de l’utilisation d’Internet. Comme aujourd’hui les utilisateurs d’Internet sont aspirés dans des réseaux sociaux massivement centralisés comme Facebook et Twitter, le monde des développeurs suit logiquement cette tendance avec Github. Même si une frange importante des développeurs a été sensibilisée aux dangers de ce type d’organisation privée et centralisée, la communauté entière a été absorbée dans un mouvement de centralisation et d’uniformisation. Le service offert est utile, gratuit ou à un coût correct selon les fonctionnalités désirées, confortable à utiliser et fonctionne la plupart du temps. Pourquoi chercherions-nous plus loin ? Peut-être parce que d’autres en profitent et profitent de nous pendant que nous sommes distraits et installés dans notre confort ? La communauté du Logiciel Libre semble pour le moment bien assoupie.

cat-sleeping-fireplace

Le “lion” devant la cheminée

Texte sous licence Creative Commons CC BY-ND 3.0 FR

31 March, 2016 09:00PM by Carl Chenet

March 17, 2016

hackergotchi for Aurélien Jarno

Aurélien Jarno

(Pseudo-)virtualizing Intel USB controllers

I own a motherboard an Intel 8-Series Lynx Point chipset, with an Intel Haswell CPU supporting VT-d. This allow me to use Linux’s VFIO features and assign PCIe devices to a KVM-based virtual machine. High-end network controllers goes even further with the Single Root I/O Virtualization (SR-IOV) capabilities, allowing them to be shared between to multiple virtual machines.

The Lynx Point chipset provides a total of 14 USB ports arranged in 6 USB 3.0 ports and 8 USB 2.0 ports. It would be nice to be able to assign USB ports to virtual machines. QEMU already allows to assign a USB device to a virtual machine, but it works emulating a USB controller, and the traffic goes through userland. In addition it only works for a specific known device, a random device plugged to a given port is not automatically assigned to the guest (though I guess it can be scripted using the libvirt API). The xHCI specification, the one behind USB 3.0, has been designed to also support SR-IOV, to the best of my knowledege none of them actually support it. We’ll see that with some hacks it is possible to actually assign a set of USB ports to a virtual machine, with the restrictions that running ports in SuperSpeed mode is allowed only on one side, host or virtual machine.

First let’s look at how the USB controllers appears on a Lynx Point chipset using lscpi:
00:14.0 USB controller [0c03]: Intel Corporation 8 Series/C220 Series Chipset Family USB xHCI [8086:8c31] (rev 04)
00:1a.0 USB controller [0c03]: Intel Corporation 8 Series/C220 Series Chipset Family USB EHCI #2 [8086:8c2d] (rev 04)
00:1d.0 USB controller [0c03]: Intel Corporation 8 Series/C220 Series Chipset Family USB EHCI #1 [8086:8c26] (rev 04)

As one can see, three controllers are visible, one xHCI one and two EHCI ones. Let’s now look at how the USB ports are arranged using lsusb -t
/: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/3p, 480M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/8p, 480M
/: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/3p, 480M
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/6p, 480M
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/6p, 5000M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/15p, 480M

explain EHCI/OHCI/XHCI

http://www.intel.com/content/www/us/en/chipsets/8-series-chipset-pch-datasheet.html

the kernel in the VM might move back the devices to the xHCI controller. This is always the case for old kernels (like the 3.2 in Debian Wheezy), but for recent kernel it only happens if there is an intel EHCI controller available (either passed through VFIO or emulated by QEMU).

add table

Add warning

17 March, 2016 04:34PM by aurel32

March 14, 2016

Florent Gallaire

Quel DPL pour 2016 ?

Le temps passe vite, et cela fait déjà presque un an que Neil McGovern a été élu Debian Project Leader (DPL). Chaque développeur Debian pouvait donc se porter candidat entre le 6 et le 12 mars à la suite du traditionnel appel à candidatures.

Dès le 7 mars, Neil exprimait le souhait de ne pas se représenter :

Just for avoidance of doubt, I do /not/ intend on re-standing for my post. I would encourage any candidates to put themselves forward.

Malheureusement, peu de développeurs semblent motivés par la charge de DPL comme l’exprimait Lars Wirzenius :

After some serious thinking, I’ve decided not to nominate myself in the Debian project leader elections for 2016. […] Why not run? I don’t think I want to deal with the stress. I already have more than enough stress in my life, from work.

et il n’y aura donc finalement qu’un candidat cette année :

La question de la légitimité d’un scrutin avec un seul candidat a été posée par Paul Wise, mettant en avant le fait qu’il ne s’agissait pas cette fois de renouveler sa confiance à un DPL déjà en poste comme c’était le cas de Zack en 2011.

Cependant, il est important de préciser que Mehdi avait fait un très bon résultat l’année dernière en finissant deuxième pour sa première tentative, et qu’il se positionnait ainsi comme un candidat très sérieux pour cette année.

Les presque mille développeurs Debian seront libres de voter du 3 au 16 avril lors d’un vote utilisant la méthode Condorcet.

Vous pouvez retrouver tous les débats de la campagne sur la mailing list debian-vote.

14 March, 2016 05:20AM by fgallaire

March 08, 2016

hackergotchi for Tanguy Ortolo

Tanguy Ortolo

Bien rouler à vélo en ville

Alors que la bicyclette s'impose comme un moyen de transport de choix pour se déplacer en ville, il faut reconnaître qu'un cycliste est bien vulnérable, et doit adopter une conduite spécifique. Voici donc quelques conseils, dont certains pourront sembler évident, mais d'autres étant parfois contre-intuitifs.

Règle numéro 1 : la priorité, c'est la sécurité

Tout d'abord, rappelons que pour un cycliste, la priorité n'est pas la rapidité, ni le confort des autres usagers, mais la bien sécurité : gardez à l'esprit cette règle fondamentale, dont découlent ces conseils, et qui vous permettra bien souvent de déterminer la conduite à adopter.

Choisir son itinéraire

Avant même de partir, préparez un itinéraire approprié. Si vous utilisez un calculateur d'itinéraire, vérifiez qu'il est adapté au vélo, et oubliez les ceux qui sont conçus pour les automobilistes, qui vous feraient passer par des voies dangereuses, voire interdites, comme le boulevard périphérique à Paris.

Il est normalement utile de privilégier les pistes et bandes cyclables, mais certaines n'apportent pas d'avantage en matière de sécurité, et sont plutôt conçues pour faciliter un trajet court et précis : ainsi, ne cherchez pas à traverser une ville en empruntant exclusivement des contresens cyclables, ce serait très long et passablement dangereux.

Enfin, rien ne valant l'expérience du terrain, souvenez-vous de vos trajets !

Prendre sa place dans le trafic

Hors des pistes et bandes cyclables, on croit parfois qu'il est plus sûr de rouler le plus à droite possible, pour ne pas gêner les automobilistes. Ce faisant, on encourage en fait les chauffards à dépasser en frôlant le cycliste sans prendre la peine de changer de voie.

Rappelons donc qu'un cycliste n'est en aucun cas un gêneur qui devrait faire profil bas, et qu'il faut au contraire prendre sa place dans le trafic, en occupant convenablement la voie de circulation qu'on utilise. Il est normal que les automobilistes ne puissent pas dépasser sans changer de voie, la loi leur imposant d'ailleurs de laisser un écart d'un mètre en ville, et un mètre cinquante hors agglomération, pour dépasser un cycliste.

Si vous êtes confronté à un chauffard modéré qui s'agacerait de ne pas pouvoir conduire dangereusement à sa guise, souvenez-vous de la règle numéro 1 : la priorité n'est pas son bien-être, mais votre sécurité. Si toutefois vous sentez qu'il s'agit d'une brute prête à provoquer un accident, mettez-vous à l'abri dès que possible.

Signaler ses changements direction

À vélo, comme en voiture, il est obligatoire de signaler ses changements de direction, en tendant un bras dans la direction correspondante. Ce n'est toutefois pas toujours possible, et comme dit l'adage, à l'impossible, nul n'est tenu : lorsque vous pédalez en danseuse pour démarrer, ou dans une côte, n'allez pas chuter en essayant de lâcher une main pour signaler un tournant à droite ! De même, si vous devez ralentir ou vous arrêter, ne relâchez pas un frein pour la même raison !

Si vous voulez vous équiper parfaitement, sachez qu'il existe des clignotants, et même des feux stop pour vélo !

Utiliser la bonne voie

De même, dans les rues à plusieurs voies, on imagine parfois que les cyclistes sont censés utiliser celle de droite. C'est là un raccourci rapide et dangereux : quand un cycliste veut tourner à gauche, sa place est évidemment dans la voie de gauche !

Utilisez donc la voie adaptée à votre déplacement :

  • si vous allez tout droit ou à droite, restez dans la voie de droite, ou dans la bande cyclable s'il y en a une ;
  • si vous allez tourner à gauche, anticipez et déboîtez vers la voie de gauche : s'il y a une bande cyclable, quittez-la, et s'il y a trois voies ou plus, préparez-vous bien à l'avance pour effectuer un déboîtement multiple.

Les sas cyclables

Certains feux de circulation sont précédés d'un sas cyclable, un espace réservé aux cyclistes, qui permet notamment aux cyclistes venant d'une bande cyclable de pouvoir se placer à gauche au feu rouge. Cet aménagement pratique ne dispense pas de préparer à l'avance son changement de direction, étant donné que :

  • ce n'est utilisable que si le feu est rouge, et s'il le reste assez longtemps pour pouvoir se placer à gauche ;
  • de nombreux automobilistes, ainsi que la quasi totalité des motocyclistes, ne connaissent pas les sas cyclables ou refusent volontairement de les respecter…

Ne pas slalomer à droite

En temps normal, on roule plutôt sur la voie de droite, ou sur la bande cyclable quand il y en a une… sauf quand des automobilistes y sont (mal) stationnés, auquel cas on déboîte à gauche pour continuer à rouler. Que faire si, un peu plus loin, la voie de droite est à nouveau occupée ? Certains cyclistes, notamment débutants, essaient de rester à droite autant que possible, en déboîtant uniquement quand c'est strictement nécessaire, pensant sans doute moins gêner ou se mettre ainsi mieux en sécurité. Il faut pourtant tenir compte du fait qu'en zigzaguant ainsi entre deux voies ce sont ces déboîtements à répétition qui sont les plus dangereux !

Lorsque la voie de droite ou la bande cyclable est à plusieurs reprise occupée par des voitures mal garées, la prudence impose donc de déboîter, puis de rester sur la voie de gauche jusqu'à constater que celle de droite est à nouveau libre sur une distance convenable.

Utiliser intelligemment les aménagements cyclables

Les aménagements cyclables sont généralement utiles, mais certains souffrent de défauts de conception qui les rendent dangereux. Les exemples sont multiples : bande cyclable rasant une file de stationnement sans zone neutralisée pour l'ouverture des portières, bande en bordure de route défoncée, piste cyclable passant d'un côté d'une route à l'autre en franchissant toutes les voies sans aménagement pour cela, piste cyclable sans entrée ou sans sortie, ou encore coupant une bretelle d'entrée de voie rapide, etc.

Face à un aménagement cyclable manifestement dangereux, souvenez-vous de la règle numéro 1, et passez votre chemin en empruntant la chaussée principale. Plus tard, quand vous aurez le temps, vous pourrez signaler le problème à la mairie concernée.

Se méfier des autres usagers

De nombreux usagers, qu'ils soient piétons, cyclistes, motards, automobilistes ou conducteurs de poids-lourds, commettent des erreurs ou des fautes de conduite plus ou moins graves : piétons et cyclistes traversant au rouge, motards sur les bandes ou sas cyclables, automobilistes tournant sans prévenir ou garés n'importe comment, etc.

Compte tenu de cela, il serait dangereux de conduire en supposant que tous les usagers respectent le code de la route. Au contraire, la prudence impose de se méfier a priori des autres usagers : ainsi, à un feu rouge passant au vert, il faut prévoir le cas où un automobiliste tournerait à droite sans prévenir ni tenir compte de la présence d'un cycliste à sa droite.

En cas de danger imprévu, il faut savoir qu'une sonnette de vélo est insuffisante pour se faire remarquer par un automobiliste. Mieux vaut donc simplement crier.

Face à un chauffard, se mettre à l'abri

Parmi les nombreux usagers des routes, on compte malheureusement quelques individus dangereux, qu'il s'agisse de chauffards, de conducteurs ivres ou de véritables criminels parfois prêts à utiliser leur véhicule comme une arme pour blesser ou tuer quiconque se mettrait en travers de leur route.

Confronté à une telle situation, vous serez peut-être dans votre droit, et le chauffard méritera probablement une amende, un retrait de permis, voire un séjour en prison pour tentative d'homicide, mais conformément à la règle numéro 1, ne cherchez surtout pas à lui tenir tête. Cherchez plutôt un endroit où vous mettre à l'abri, que ce soit entre des voitures en stationnement, dans une voie de bus ou sur le trottoir.

Si le chauffard était un professionnel, comme un radio-taxi, un bus ou un livreur, vous pouvez noter son numéro ou son immatriculation, et vous plaindre auprès de son opérateur, qui pourra le rappeler à la loi et le sanctionner en conséquence afin d'éviter que cela se reproduise.

Signaler les problèmes

Lorsque vous avez été confronté à une infrastructure inadaptée, et Dieu sait qu'il en existe, n'hésitez pas à la signaler à la mairie correspondante. Elle n'en tiendra pas forcément compte, mais qui ne tente rien n'a rien : si rien n'est signalé, rien ne bougera ! Vous pouvez également signaler les problèmes sur le site de l'initiative J'ai mal à ma route ! (oui, c'est fait par une association d'automobilistes, et alors ?).

08 March, 2016 06:08PM by Tanguy

February 26, 2016

Florent Gallaire

[MàJ] Txt2tags en JavaScript et avec Pandoc

Grâce aux nombreux efforts d’Eric Forgeot, il existe maintenant txt2tags.js, une implémentation de la syntaxe de Txt2tags en JavaScript avec une démo parfaitement fonctionnelle des possibilités de rendu côté client en temps réel.

Matthew Pickering a quant à lui écrit un reader Txt2tags pour Pandoc, ce qui permet d’utiliser votre syntaxe préférée avec cet excellent logiciel.

Ces deux informations ont été ajoutées dans le tableau de classement par syntaxe de Comparaison des langages de balisage (markup) léger (lightweight) : Txt2tags, Pandoc, Docutils, AsciiDoc, Deplate, Stx2any, AFT, Markdown et Textile.

26 February, 2016 03:45AM by fgallaire

February 25, 2016

Stéphane Blondon

Des graphiques à la Xkcd

Ou comment faire des graphiques dans le légendaire style de XKCD (une finesse du trait plus tranchante que Michel-Ange, des couleurs plus contrastées que Léonard de Vinci).

graphique à la xkcd

Les développeurs de Matplotlib l’ont fait et intégré à la bibliothèque. Globalement, il suffit d’initialiser le script python avec la fonction xkcd(). Cette fonction initialise des paramètres pour le rendu des graphiques.

with plt.xkcd():
    #le code pour produire le graphique

Installation

Dans Debian, le paquet de base de Matplotlib est python-matplotlib pour python2 et python3-matplotlib pour python3.

Pour que le graphique ait une police similaire à ceux de xkcd, la police Humor Sans doit être installée. Dans Debian, elle se trouve dans le paquet fonts-humor-sans.

Il est possible d’avoir encore une erreur signalant que la police n’est pas trouvée :

/usr/lib/python2.7/dist-packages/matplotlib/font_manager.py:1288: UserWarning: findfont: Font family [u'Humor-Sans'] not found. Falling back to Bitstream Vera Sans

En réalité, elle est bien accessible par matplotlib mais la bibliothèque a construit un cache des polices disponibles lors de la création d’un autre graphique par le passé. Ce cache n’est pas vidé après l’installation de la police. L’erreur survient car matplotlib regarde dans son cache et non les polices actuellement installées sur le système. Il suffit donc de supprimer ce cache (fontList.cache pour python2 ou fontList.py3k.cache pour python3) et d’exécuter à nouveau le script.


stephane@foehn:~$ ls .cache/matplotlib/
fontList.cache fontList.py3k.cache tex.cache
stephane@foehn:~$ rm .cache/matplotlib/fontList.cache #si script lancé avec python2

Et là, ça marche !:-)

Évitez tout de même de mettre des accents, la police ne dispose pas de ces caractères et un « ? » est affiché à la place.

Versions des logiciels utilisés, code source

paquet python-matplotlib : 1.5.1-1
paquet fonts-humor-sans : 1.0-1

Le code source qui a permis de produire le magnifique graphique inséré au début de l’article :

from matplotlib import pyplot as plt
import numpy as np

with plt.xkcd():
    fig = plt.figure()
    ax = fig.add_subplot(1, 1, 1)
    ax.spines['right'].set_color('none')
    ax.spines['top'].set_color('none')
    plt.xticks([])
    plt.yticks([])
    ax.set_ylim([-1, 2])

    x = np.linspace(0, 10)
    plt.plot(x, np.sin(x) + 0.3, '--')

    plt.xlabel('abscisses')
    plt.ylabel('ordonnees')
    plt.title("c'est le plus beau graphique du monde !")

    plt.savefig("/tmp/graph_xkcd.png")

25 February, 2016 10:26PM by ascendances

February 23, 2016

hackergotchi for Aurélien Jarno

Aurélien Jarno

10 years ago…

… I joined the Debian GNU libc team and did my first glibc upload. At that time source-only upload were far from exiting, and I was using a HP 9000 model 715/80 HPPA workstation for my Debian builds.

Still it seems to me like yesterday.

23 February, 2016 09:43PM by aurel32

January 13, 2016

hackergotchi for Tanguy Ortolo

Tanguy Ortolo

Réprimander un pollueur

Je n'aime pas les incivilités, et parmi celles-ci, le dépôt d'ordures sur la voie publique. Ce sentiment est aujourd'hui largement partagé, et certaines villes commencent d'ailleurs à réprimer ces comportements.

Il est toutefois un type particulier d'ordure que beaucoup de gens jettent sur la route sans même y penser : les mégots de cigarettes. Il s'agit bien d'ordures, de surcroît très polluantes, et leur place est dans un cendrier ou une poubelle. Leur dépôt sur la voie publique est passible d'une amende de 68 euros.

Mégots de cigarette

4 × 68 = 272 euros d'amende

Réprimander un fumeur-pollueur

J'étais à vélo. Un feu est passé au rouge, la voiture devant moi s'y est arrêtée, et son conducteur a jeté un mégot par la fenêtre. Je me suis avancé à son niveau, ai ramassé ce mégot, et l'ai remis dans la voiture par la fenêtre toujours ouverte : « C'est interdit de jeter des ordures sur la voie publique, Monsieur. »

Il n'y a pas à dire, ça défoule. Et ça énerve beaucoup le malappris concerné : « Ça [ne] va pas non, connard ? Petite bite ! » Prévoyant, j'avais déjà commencé à m'éloigner.

Conseils

Dans certaines villes, la police commence tout juste à réprimer le dépôt de mégots par des piétons, mais à ma connaissance, rien n'est encore fait pour les automobilistes, bien qu'ils n'aient aucune excuse, leur véhicule pouvant être muni d'un cendrier. Il est donc utile de les réprimander soi-même, mais sans jamais se livrer à des dégradations, parce qu'il s'agit de promouvoir le respect et non de rendre justice : une phrase et une restitution du mégot suffit.

Le pollueur étant par définition un être peu civilisé, cette action peut l'énerver et le conduire à tenter d'exercer des représailles. Il est donc important de faire cela dans des conditions qui permettent d'éliminer ce risque :

  • À vélo ou patins à roulettes, afin qu'il ne puisse pas vous rattraper s'il descend de sa voiture dans le but de vous frapper (c'est un comportement assez fréquent, qui mérite une amende pour tentative de coups).
  • Dans une rue bordée de trottoirs plantés d'arbres ou munis de barrières anti-stationnement, afin de pouvoir se mettre à l'abri s'il décide d'utiliser sa voiture dans le but de vous percuter (j'ai déjà vu ce genre de comportement après avoir réprimandé un chauffard pour un autre motif, et ça mérite un emprisonnement pour tentative d'homicide).
  • Pour un pollueur qui n'a pas l'air d'une brute trop décérébrée pour être récupérable pour la société, qui pourrait être vraiment dangereux.

En cas de problème, souvenez-vous que contrairement à vous, le pollueur a une voiture, donc une immatriculation qui permet de l'identifier ; n'hésitez pas à le lui rappeler.

Conclusion

Bien que le pollueur lui-même puisse être considéré comme une ordure pour son comportement, il peut être recyclé pour avoir une seconde vie, respectueuse de la société et de l'environnement.

13 January, 2016 12:26PM by Tanguy

October 15, 2015

hackergotchi for Charles Plessy

Charles Plessy

La pente glissante.

Étape par étape, on glisse vers le fond :

  1. Il faut s'exprimer durement avec ceux qui ont tort.
  2. On s'exprime durement quand on a raison.
  3. Quand on pense qu'on a raison, on est s'exprime durement.
  4. On a tort et on s'exprime durement.

Notons tout de même qu'on peut toucher le fond sans être vulgaire ou insultant. Dans tout grand projet comme Debian, on finit par trouver quelques gens qui savent être très oppressants, tout en restant très « corrects ». Debian est vaste, et il est facile de les éviter, mais dès que l'on s'essaye à des contributions qui collent à des mots-clés tels que « comité », « code », « charte », « délégation », etc., il vaut mieux ressortir la bonne vielle peau dure du placard où on l'avait rangée après l'adoption de notre nouveau code de conduite...

15 October, 2015 12:57PM

October 06, 2015

Florent Gallaire

Erlang passe sous licence Apache 2.0

Le langage de programmation Erlang est passé sous licence Apache 2.0, à l’occasion de la sortie de sa version 18.0 le 24 juin dernier.

Au commencement un logiciel propriétaire, Erlang avait été libéré par Ericsson en 1998 sous Erlang Public License, une version modifiée de la licence Mozilla.

L’abandon total d’un Copyleft déjà faible me semble anecdotique dans ce changement de licence. En revanche, le passage d’un important logiciel libre d’une licence spécifique à une licence très populaire participe d’un mouvement de consolidation des licences de logiciel libre, permettant une compréhension plus claire des obligations y afférentes et donc une meilleure sécurité juridique.

Pour le choix d’une licence sans Copyleft, ou « permissive », la licence Apache 2.0 est à recommander, tout comme le fait la Free Software Foundation, car elle est plus complète que ses concurrentes, en particulier concernant les brevets.

La consolidation des licences libres est une évolution positive à mon sens, et l’exemple d’Erlang pourrait peut-être inspirer Python ou d’autres logiciels libres ayant leur propre licence…

06 October, 2015 01:44AM by fgallaire

September 30, 2015

hackergotchi for Charles Plessy

Charles Plessy

\"Debian

# SOME DESCRIPTIVE TITLE # Copyright (C) YEAR Free Software Foundation, Inc. # This file is distributed under the same license as the PACKAGE package. # FIRST AUTHOR , YEAR. # #, fuzzy msgid "" msgstr "" "Project-Id-Version: PACKAGE VERSION\n" "POT-Creation-Date: 2015-09-30 02:04+0000\n" "PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" "Last-Translator: FULL NAME \n" "Language-Team: LANGUAGE \n" "Language: \n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8bit\n" #. type: Plain text #, no-wrap msgid "\n" msgstr "" #. type: Plain text #, no-wrap msgid "\n" msgstr "" #. type: Plain text #, no-wrap msgid "\n" msgstr "" #. type: Plain text #, no-wrap msgid "\n" msgstr "" #. type: Plain text msgid "" "La semaine dernière, un collègue me demandait si j'avais abandonné Debian et " "Linux, car il me voyait utiliser un ordinateur portable VAIO. En effet, " "cette marque a la réputation de ne pas être un terrain fertile pour y " "installer Linux. Je m'étais d'ailleurs promis il y a quelques années de ne " "jamais en rachter après avoir découvert que le BIOS de mon Sony VAIO " "VGC-LT71DB (un ingégré tout-dans-l'écrant de bureau) était volontairement " "bridé pour empêcher l'activation de la virtualisation. Mais depuis, VAIO " "est devenu indépendant de Sony. Alors, encouragé par la lecture du [blog de " "Norbert " "Preining](https://www.preining.info/blog/2014/03/debian-linux-sony-vaio-pro-13/) " "j'ai décidé de re-tenter l'aventure avec un [VAIO Pro13 | " "mk2](https://vaio.com/products/pro_mk2/). Il faut dire que la machine était " "très tentante, sutout pour son poids léger, d'environ 1 kg seulement." msgstr "" #. type: Plain text msgid "" "La machine est livrée avec Windows 8 pré-installé en japonais. En premier, " "j'ai démarré Windows pour repartitionner la mémoire de masse. Je n'ai pas " "réussi à changer la langue alors une partie de l'opération s'est faite à " "moitié à l'aveuglette, mais j'ai réussi à éviter de devoir créer un compte " "utilisateur chez Microsoft. Ensuite le repartitionnement avec les outils de " "base de Windows s'est très bien passé grâce aux multiples tutoriels " "disponibles en ligne. Merci Microsoft pour cette agréable surprise, qui " "pourrait presque me faire oublier que sur un ordinateur neuf avec un Core i7 " "et 8 GiB de mémoire vive, Internet Explorer a planté net à la première " "visite de site web du journal [Le Monde](http://lemonde.fr)..." msgstr "" #. type: Plain text msgid "" "Ensuite, je suis rentré dans le BIOS en appuyant sur F3 et F4 en même temps " "(il m'a fallu éplucher tout le manuel pour trouver comment faire), et j'y ai " "activé la virtualisation, désactivé le lancement sécurisé (_Secure Boot_) et " "permis le démarrage sur port USB. J'ai ensuite [installé " "Jessie](https://bugs.debian.org/797311) avec l'installeur `20150422+deb8u1`, " "sans rencontrer aucun problème. Résutlat: un multi-boot Debian / Windows en " "UEFI en place sans aucun effort ; je suis très impressionné. Je n'utilise " "pas Windows mais je vais le garder quelques temps au cas où un problème " "matériel arriverait dans les premiers mois." msgstr "" #. type: Plain text msgid "" "Au final, je suis très satisfait. Il reste néanmois quelques petits ennuis " "qui de l'espère vont s'améliorer au fil des mises à jour. En premier lieu, " "[le clavier ne se réveille pas après " "hibernation](https://bugs.debian.org/797392). Ça veut dire que si je rabat " "l'écrant, je ne peut plus rien faire. En attendant une solution, l'outil de " "personnalisation de GNOME permet de remplacer l'hibernation par une simple " "extintion de l'écran. Pour le moment, la batterie se vide en quatre heures, " "probablement parce que [la platforme Broadwell n'est pas encore bien prise " "en charge](http://mjg59.dreamwidth.org/34868.html). L'écran a une bonne " "résolution, trop bonne pour mes yeux myopes et certains logiciels ne " "respectent pas la taille par défaut des fontes, que j'ai augmentée pour mon " "confort. À part ça, j'adore cette machine et j'espère la garder longtemps." msgstr ""

30 September, 2015 02:05AM

August 15, 2015

Stéphane Blondon

DebConf15 à Heidelberg

Je suis à la DebConf15 et j’ai des preuves :

club_mate

La photo a été prise dans l’auberge de jeunesse. Le Club-Mate, c’est un peu la baguette des Allemands, avec la bière et la porte de Brandebourg. (La porte est un peu plus difficile à boire.)

Le logo compatible Club-Mate :
Dc15going1


15 August, 2015 05:30PM by ascendances

May 27, 2015

hackergotchi for Vincent Bernat

Vincent Bernat

Correction sans redémarrage de la faille VENOM de QEMU

La faille CVE-2015-3456, aussi connue sous le nom VENOM, exploite une faiblesse dans l’implémentation du contrôleur de disquettes de QEMU:

Le contrôleur de disquettes (FDC) de QEMU, tel qu’utilisé dans Xen […] et dans KVM permet aux systèmes invités de provoquer un déni de service (écriture hors limite suivie du crash du processus invité) ou éventuellement d’exécuter du code arbitraire à travers les commandes FD_CMD_READ_ID, FD_​CMD_​DRIVE_​SPECIFICATION_​COMMAND ou d’autres commandes non spécifiées.

Même lorsque QEMU a été configuré pour ne pas exposer de lecteur de disquettes, le contrôleur est toujours actif. La vulnérabilité est facile à tester1 :

#define FDC_IOPORT 0x3f5
#define FD_CMD_READ_ID 0x0a

int main() {
    ioperm(FDC_IOPORT, 1, 1);
    outb(FD_CMD_READ_ID, FDC_IOPORT);
    for (size_t i = 0;; i++)
        outb(0x42, FDC_IOPORT);
    return 0;
}

Une fois le correctif installé, tous les processus doivent être redémarrés pour que la mise à jour prenne effet. Il est possible de minimiser le temps de coupure en utilisant virsh save.

Une alternative serait de modifier le processus en cours d’exécution. Le noyau Linux a suscité beaucoup d’intérêt dans ce domaine avec des solutions telles que Ksplice, kGraft et kpatch, ainsi que par l’inclusion d’une structure commune dans le noyau. L’espace utilisateur ne dispose cependant pas de solutions aussi élaborées2.

Je présente ici une solution simple et sans dépendance pour corriger une instance de QEMU en cours d’exécution. Voici une courte démonstration :

Prototype§

Essayons d’abord de trouver une modification simple à implémenter : bien qu’il soit possible de modifier du code en cours d’exécution, il est bien plus simple de modifier une variable.

Concept§

En examinant le code du contrôleur de disquettes et le correctif, une façon d’éviter la vulnérabilité est de n’accepter aucune commande sur le port FIFO. Chaque requête aura comme réponse « Invalid command » (0x80). L’utilisateur ne pourra plus pousser aucun octet avant de lire la réponse, ce qui provoquera une remise à zéro de la queue FIFO. Bien sûr, le contrôleur de disquette deviendra alors inopérant.

La liste des commandes acceptées par le contrôleur sur le port FIFO se trouve dans le tableau handlers[] :

static const struct {
    uint8_t value;
    uint8_t mask;
    const char* name;
    int parameters;
    void (*handler)(FDCtrl *fdctrl, int direction);
    int direction;
} handlers[] = {
    { FD_CMD_READ, 0x1f, "READ", 8, fdctrl_start_transfer, FD_DIR_READ },
    { FD_CMD_WRITE, 0x3f, "WRITE", 8, fdctrl_start_transfer, FD_DIR_WRITE },
    /* [...] */
    { 0, 0, "unknown", 0, fdctrl_unimplemented }, /* default handler */
};

Pour éviter de parcourir ce tableau pour chaque commande reçue, un autre tableau associe une commande à la fonction adéquate :

/* Associate command to an index in the 'handlers' array */
static uint8_t command_to_handler[256];

static void fdctrl_realize_common(FDCtrl *fdctrl, Error **errp)
{
    int i, j;
    static int command_tables_inited = 0;

    /* Fill 'command_to_handler' lookup table */
    if (!command_tables_inited) {
        command_tables_inited = 1;
        for (i = ARRAY_SIZE(handlers) - 1; i >= 0; i--) {
            for (j = 0; j < sizeof(command_to_handler); j++) {
                if ((j & handlers[i].mask) == handlers[i].value) {
                    command_to_handler[j] = i;
                }
            }
        }
    }
    /* [...] */
}

Notre modification consiste à changer le tableau command_to_handler[] pour associer toutes les commandes à la fonction fdctrl_unimplemented() (celle en dernière position dans le tableau handlers[]).

Test avec gdb§

Pour vérifier que cette modification fonctionne correctement, nous la testons avec gdb. À moins d’avoir compilé QEMU manuellement, il est nécessaire d’installer le paquet contenant les symboles de débogage. Malheureusement, chez Debian, ils ne sont pas encore3 disponibles. Chez Ubuntu, il suffit d’installer le paquet qemu-system-x86-dbgsym après avoir activé les dépôts appropriés.

La fonction suivante pour gdb implémente le correctif :

define patch
  set $handler = sizeof(handlers)/sizeof(*handlers)-1
  set $i = 0
  while ($i < 256)
   set variable command_to_handler[$i++] = $handler
  end
  printf "Done!\n"
end

Il suffit alors de s’attacher au processus vulnérable (avec attach), d’appeler cette fonction (avec patch) et de se détacher (avec detach). Cette procédure est simple à automatiser.

Limitations§

L’usage de gdb comporte principalement deux limitations :

  1. gdb doit être installé sur toutes les machines à corriger.
  2. Les paquets de débogage doivent également être présents. Il est de plus difficile de récupérer d’anciennes versions de ceux-ci.

Industrialisation§

Pour contourner ces limitations, nous allons écrire un programme utilisant l’appel système ptrace() et qui ne nécessite pas les symboles de débogage pour fonctionner.

Trouver l’emplacement mémoire§

La première étape est de localiser le tableau command_to_handler[] en mémoire. Le premier indice se trouve dans la table des symboles que l’on peut interroger avec readelf -s :

$ readelf -s /usr/lib/debug/.build-id/09/95121eb46e2a4c13747ac2bad982829365c694.debug | \
>   sed -n -e 1,3p -e /command_to_handler/p

Symbol table '.symtab' contains 27066 entries:
   Num:    Value          Size Type    Bind   Vis      Ndx Name
  8485: 00000000009f9d00   256 OBJECT  LOCAL  DEFAULT   26 command_to_handler

Habituellement, cette table a été retirée pour économiser de l’espace disque, comme on peut le voir ci-dessous :

$ file -b /usr/bin/qemu-system-x86_64 | tr , \\n
ELF 64-bit LSB shared object
 x86-64
 version 1 (SYSV)
 dynamically linked
 interpreter /lib64/ld-linux-x86-64.so.2
 for GNU/Linux 2.6.32
 BuildID[sha1]=0995121eb46e2a4c13747ac2bad982829365c694
 stripped

Si votre distribution fournit un paquet de débogage, les symboles sont alors installés dans le répertoire /usr/lib/debug. La plupart des distributions modernes utilisent désormais le build ID4 pour lier un exécutable à ses symboles de débogage, comme c’est le cas dans l’exemple ci-dessus. Sans paquet de débogage, il est nécessaire de recompiler le paquet dans un environnement minimal5 sans supprimer les symboles. Sur Debian, cela peut se faire en affectant nostrip à la variable d’environnement DEB_BUILD_OPTIONS.

Il y a ensuite deux cas possibles :

  • le cas facile,
  • le cas difficile.

Le cas facile§

Sur x86, la mémoire d’un processus Linux normal est organisée comme ceci6 :

Organisation mémoire d'un processus normal sur x86

L’espace aléatoire introduit entre les différentes zones (ASLR) permettent de rendre la tâche d’un attaquant plus difficile quand il veut référencer une fonction particulière. Sur x86-64, l’organisation est similaire. Le point important est que l’adresse de base de l’exécutable est fixe.

L’organisation mémoire d’un processus peut être consultée à travers le fichier /proc/PID/maps. Voici une version raccourcie et annotée sur x86-64 :

$ cat /proc/3609/maps
00400000-00401000         r-xp 00000000 fd:04 483  not-qemu [text segment]
00601000-00602000         r--p 00001000 fd:04 483  not-qemu [data segment]
00602000-00603000         rw-p 00002000 fd:04 483  not-qemu [BSS segment]
[random gap]
02419000-0293d000         rw-p 00000000 00:00 0    [heap]
[random gap]
7f0835543000-7f08356e2000 r-xp 00000000 fd:01 9319 /lib/x86_64-linux-gnu/libc-2.19.so
7f08356e2000-7f08358e2000 ---p 0019f000 fd:01 9319 /lib/x86_64-linux-gnu/libc-2.19.so
7f08358e2000-7f08358e6000 r--p 0019f000 fd:01 9319 /lib/x86_64-linux-gnu/libc-2.19.so
7f08358e6000-7f08358e8000 rw-p 001a3000 fd:01 9319 /lib/x86_64-linux-gnu/libc-2.19.so
7f08358e8000-7f08358ec000 rw-p 00000000 00:00 0
7f08358ec000-7f083590c000 r-xp 00000000 fd:01 5138 /lib/x86_64-linux-gnu/ld-2.19.so
7f0835aca000-7f0835acd000 rw-p 00000000 00:00 0
7f0835b08000-7f0835b0c000 rw-p 00000000 00:00 0
7f0835b0c000-7f0835b0d000 r--p 00020000 fd:01 5138 /lib/x86_64-linux-gnu/ld-2.19.so
7f0835b0d000-7f0835b0e000 rw-p 00021000 fd:01 5138 /lib/x86_64-linux-gnu/ld-2.19.so
7f0835b0e000-7f0835b0f000 rw-p 00000000 00:00 0
[random gap]
7ffdb0f85000-7ffdb0fa6000 rw-p 00000000 00:00 0    [stack]

Dans le cas d’un exécutable normal, le nombre fourni dans la table des symboles est une adresse absolue :

$ readelf -s not-qemu | \
>   sed -n -e 1,3p -e /command_to_handler/p

Symbol table '.dynsym' contains 9 entries:
   Num:    Value          Size Type    Bind   Vis      Ndx Name
    47: 0000000000602080   256 OBJECT  LOCAL  DEFAULT   25 command_to_handler

Ainsi, dans l’exemple ci-dessus, l’adresse du tableau command_to_​handler[], est simplement 0x602080.

Le cas difficile§

Pour améliorer la sécurité, il est possible de placer certains exécutables à un emplacement aléatoire en mémoire, comme c’est le cas pour une bibliothèque. Un tel exécutable est appelé un Position Independent Executable (PIE). Un attaquant ne pourra pas se baser sur une adresse fixe pour rebondir sur une fonction particulière. Voici à quoi ressemble l’organisation mémoire d’un processus dans ce cas :

Organisation mémoire d'un processus PIE sur x86

Dans le cas d’un processus PIE, le nombre indiqué dans la table des symboles est relatif à l’adresse de base du processus.

$ readelf -s not-qemu-pie | sed -n -e 1,3p -e /command_to_handler/p

Symbol table '.dynsym' contains 17 entries:
   Num:    Value          Size Type    Bind   Vis      Ndx Name
    47: 0000000000202080   256 OBJECT  LOCAL  DEFAULT   25 command_to_handler

En regardant le contenu de /proc/PID/maps, il est possible de calculer l’emplacement mémoire du tableau :

$ cat /proc/12593/maps
7f6c13565000-7f6c13704000 r-xp 00000000 fd:01 9319  /lib/x86_64-linux-gnu/libc-2.19.so
7f6c13704000-7f6c13904000 ---p 0019f000 fd:01 9319  /lib/x86_64-linux-gnu/libc-2.19.so
7f6c13904000-7f6c13908000 r--p 0019f000 fd:01 9319  /lib/x86_64-linux-gnu/libc-2.19.so
7f6c13908000-7f6c1390a000 rw-p 001a3000 fd:01 9319  /lib/x86_64-linux-gnu/libc-2.19.so
7f6c1390a000-7f6c1390e000 rw-p 00000000 00:00 0
7f6c1390e000-7f6c1392e000 r-xp 00000000 fd:01 5138  /lib/x86_64-linux-gnu/ld-2.19.so
7f6c13b2e000-7f6c13b2f000 r--p 00020000 fd:01 5138  /lib/x86_64-linux-gnu/ld-2.19.so
7f6c13b2f000-7f6c13b30000 rw-p 00021000 fd:01 5138  /lib/x86_64-linux-gnu/ld-2.19.so
7f6c13b30000-7f6c13b31000 rw-p 00000000 00:00 0
7f6c13b31000-7f6c13b33000 r-xp 00000000 fd:04 4594  not-qemu-pie [text segment]
7f6c13cf0000-7f6c13cf3000 rw-p 00000000 00:00 0
7f6c13d2e000-7f6c13d32000 rw-p 00000000 00:00 0
7f6c13d32000-7f6c13d33000 r--p 00001000 fd:04 4594  not-qemu-pie [data segment]
7f6c13d33000-7f6c13d34000 rw-p 00002000 fd:04 4594  not-qemu-pie [BSS segment]
[random gap]
7f6c15c46000-7f6c15c67000 rw-p 00000000 00:00 0     [heap]
[random gap]
7ffe823b0000-7ffe823d1000 rw-p 00000000 00:00 0     [stack]

L’adresse de base est 0x7f6c13b31000, le décalage relatif est 0x202080 et donc le tableau se trouve à l’adresse mémoire 0x7f6c13d33080. Il est possible de vérifier cette valeur avec gdb : with gdb:

$ print &command_to_handler
$1 = (uint8_t (*)[256]) 0x7f6c13d33080 <command_to_handler>

Modifier un emplacement mémoire§

Une fois l’emplacement du tableau command_to_handler[] connu, le modifier est relativement simple. Il convient d’abord de s’attacher au processus cible :

/* Attach to the running process */
static int
patch_attach(pid_t pid)
{
    int status;

    printf("[.] Attaching to PID %d...\n", pid);
    if (ptrace(PTRACE_ATTACH, pid, NULL, NULL) == -1) {
        fprintf(stderr, "[!] Unable to attach to PID %d: %m\n", pid);
        return -1;
    }

    if (waitpid(pid, &status, 0) == -1) {
        fprintf(stderr, "[!] Error while attaching to PID %d: %m\n", pid);
        return -1;
    }
    assert(WIFSTOPPED(status)); /* Tracee may have died */

    if (ptrace(PTRACE_GETSIGINFO, pid, NULL, &si) == -1) {
        fprintf(stderr, "[!] Unable to read siginfo for PID %d: %m\n", pid);
        return -1;
    }
    assert(si.si_signo == SIGSTOP); /* Other signals may have been received */

    printf("[*] Successfully attached to PID %d\n", pid);
    return 0;
}

Ensuite, récupérons le tableau command_to_handler[], modifions le et réécrivons le en mémoire7.

static int
patch_doit(pid_t pid, unsigned char *target)
{
    int ret = -1;
    unsigned char *command_to_handler = NULL;
    size_t i;

    /* Get the table */
    printf("[.] Retrieving command_to_handler table...\n");
    command_to_handler = ptrace_read(pid,
                                     target,
                                     QEMU_COMMAND_TO_HANDLER_SIZE);
    if (command_to_handler == NULL) {
        fprintf(stderr, "[!] Unable to read command_to_handler table: %m\n");
        goto out;
    }

    /* Check if the table has already been patched. */
    /* [...] */

    /* Patch it */
    printf("[.] Patching QEMU...\n");
    for (i = 0; i < QEMU_COMMAND_TO_HANDLER_SIZE; i++) {
        command_to_handler[i] = QEMU_NOT_IMPLEMENTED_HANDLER;
    }
    if (ptrace_write(pid, target, command_to_handler,
           QEMU_COMMAND_TO_HANDLER_SIZE) == -1) {
        fprintf(stderr, "[!] Unable to patch command_to_handler table: %m\n");
        goto out;
    }
    printf("[*] QEMU successfully patched!\n");
    ret = 0;

out:
    free(command_to_handler);
    return ret;
}

Comme ptrace() ne permet de lire et d’écrire qu’un mot à la fois, ptrace_read() et ptrace_write() sont des enrobages pour lire et écrire une quantité arbitraire de mémoire. Voici par exemple le code de ptrace_read() :

/* Read memory of the given process */
static void *
ptrace_read(pid_t pid, void *address, size_t size)
{
    /* Allocate the buffer */
    uword_t *buffer = malloc((size/sizeof(uword_t) + 1)*sizeof(uword_t));
    if (!buffer) return NULL;

    /* Read word by word */
    size_t readsz = 0;
    do {
        errno = 0;
        if ((buffer[readsz/sizeof(uword_t)] =
                ptrace(PTRACE_PEEKTEXT, pid,
                       (unsigned char*)address + readsz,
                       0)) && errno) {
            fprintf(stderr, "[!] Unable to peek one word at address %p: %m\n",
                    (unsigned char *)address + readsz);
            free(buffer);
            return NULL;
        }
        readsz += sizeof(uword_t);
    } while (readsz < size);
    return (unsigned char *)buffer;
}

Assembler les morceaux§

Le programme prend en paramètre :

  • le PID du processus à modifier,
  • le décalage issu de la table des symboles pour le tableau command_to_handler[],
  • le build ID de l’exécutable utilisé pour obtenir ce décalage (à des fins de sécurité).

Les principales étapes sont alors les suivantes :

  1. S’Attacher au processus avec ptrace().
  2. Obtenir le nom de l’exécutable depuis /proc/PID/exe.
  3. Lire le fichier /proc/PID/maps afin de trouver l’adresse de base.
  4. Effectuer certaines vérifications supplémentaires:
    • vérifier qu’il y a bien un entête ELF à l’adresse de base (via quatre octets magiques),
    • vérifier le type de l’exécutable (ET_EXEC pour les exécutables normaux, ET_DYN pour les PIE),
    • récupérer et comparer le build ID avec celui attendu.
  5. À partir de l’adresse de base et du décalage fourni, calculer l’emplacement du tableau command_to_handler[].
  6. Modifier le tableau.

Les sources du programme sont disponibles sur GitHub.

$ ./patch --build-id 0995121eb46e2a4c13747ac2bad982829365c694 \
>         --offset 9f9d00 \
>         --pid 16833
[.] Attaching to PID 16833...
[*] Successfully attached to PID 16833
[*] Executable name is /usr/bin/qemu-system-x86_64
[*] Base address is 0x7f7eea912000
[*] Both build IDs match
[.] Retrieving command_to_handler table...
[.] Patching QEMU...
[*] QEMU successfully patched!

  1. Le code complet pour ce test est disponible sur GitHub

  2. Un projet qui semble intéressant est Katana. Mais il existe aussi un quelques papiers perspicaces sur le sujet. 

  3. Certains paquets fournissent également un paquet -dbg contenant les symboles de débogage. D’autres non. Une initiative pour produire automatiquement des paquets de débogage est actuellement en cours. 

  4. Le wiki de Fedora explique les raisons derrière cette décision

  5. Si la construction ne se fait pas à l’identique du paquet original, les build ID seront différents. L’information fournie par les symboles de débogage peut alors être ou non correcte. Une initiative pour s’assurer de la reproductabilité de la construction de tous les paquets est en cours. 

  6. « Anatomy of a program in memory » explique plus en détail cette organisation. 

  7. En étant une variable statique non initialisée, la variable se situe dans la section BSS qui se retrouve accessible en écriture en mémoire. Si ce n’était pas le cas, sous Linux, l’appel système ptrace() permet tout de même d’écrire dessus. Linux va copier la page correspondante et la marquer comme privée. 

27 May, 2015 03:52PM by Vincent Bernat

May 19, 2015

Olivier Berger (pro)

Présentation du projet Debian par Nicolas Dandrimont lors de la Debian release party de Jessie

Nicolas (olasd) Dandrimont est venu présenter le projet Debian à Télécom SudParis lundi 18 mai 2015, pour la petite fête de sortie de la version majeure “Jessie” que nous avions organisé avec MiNET.

Les transparents de Nicolas sont disponibles sur son site.

Updated : Voici l’enregistrement de la conférence sur YouTube :

Merci aux membres de MiNET qui ont joyeusement participé à cette petite fête.

Voici quelques photos :




Vous pouvez aussi revisionner l’enregistrement de la conférence de Stefano il y a 4 ans.

19 May, 2015 02:52PM by Olivier Berger

May 13, 2015

Avec MiNET, première Debian release party française de Jessie le 18 mai à Télécom SudParis

Vous étiez frustrés de ne pas pouvoir fêter Jessie en France dignement ?

On a pensé à vous, avec MiNET.

Le 18 mai entre 17h et 18h30, nous fêterons ça à Évry (Essonne) à Télécom SudParis, avec la participation de Nicolas Dandrimont en guest star, pour présenter le projet.

Attention, inscription gratuite par avance en contactant les organisateurs, compte-tenu des contraintes de sécurité pour l’accès au site (vigipirate).

Plus de détails sur : https://wiki.debian.org/ReleasePartyJessie/France/Évry

13 May, 2015 01:23PM by Olivier Berger

May 06, 2015

hackergotchi for Charles Plessy

Charles Plessy

Longue vie à Jessie !

Debian a publié Jessie le mois dernier. Toutes mes félicitations à l'équipe de publication et tous les contributeurs; la qualité est encore au rendez-vous !

Cette fois-ci, je n'ai pas pu contribuer grand chose, étant accaparé par des activités parentales (coucou mon fils, si tu me lis), si ce n'est de m'assurer que mes paquets soient en bon état pour le Jour J. Ce travail a été grandement facilité par le système de radiation automatique des paquets buggés, mis en place par l'équipe de publication. Un grand bravo pour ce développement.

J'espère utiliser Jessie longtemps sans avoir besoin de mettre à jour vers la version de test. Pour le moment j'ai tout ce qui me faut, y compris la cohabitation entre la saisie du Japonais et le basculement entre agencements japonais (ou américain) et canadien multilingue, ce qui n'était plus possible facilement sous Wheezy.

Encore merci.

06 May, 2015 05:57AM

May 03, 2015

Stéphane Blondon

Colorer une sortie dans un terminal : highlight, pygmentize et ccze

highlight et pygmentize servent à colorer du code source, ccze à colorer des logs.

Affichage de la sortie de cat, highlight et pygmentize

Pour utiliser ces outils, voici les paquets à installer sur une distribution Debian ou dérivée :

commande paquet
highlight highlight
pygmentize python-pygments ou python3-pygments
ccze ccze

highlight et pygmentize

De nombreux langages disponibles

La liste des langages disponibles pour les deux outils est longue comme un jour sans compilation :
highlight colore 159 langages selon sa documentation.
pygmentize en colore 235 d’après un grep Lexer$ sur le texte de la page listant les lexeurs disponibles.

Plutôt que de tous les lister, voici un comparatif sur les 20 langages ayant le plus de lignes de code dans Jessie (la nouvelle version stable de Debian).

  1. C : les deux
  2. C++ : les deux
  3. Java : les deux
  4. XML : les deux
  5. sh : les deux
  6. Python : les deux. pygmentize a plusieurs lexeurs (python 2, python3, sortie console et la pile d’erreurs).
  7. Perl : les deux
  8. Lisp : les deux
  9. Asm : les deux. highlight colore aussi l’assembleur PowerPC.
  10. Fortran : highlight traite spécifiquement fortran77, pas pygmentize (qui gère la version 90).
  11. C# : les deux
  12. PHP : les deux
  13. Fortran90 : les deux
  14. Pascal : les deux. pygmentize nécessite d’utiliser Delphi lexer, avec option spécifique.
  15. Makefile : highlight (make, QMake), pygmentize (Makefile, CMake)
  16. Ruby : les deux. pygmentize colore le langage mais aussi la sortie console.
  17. SQL : highlight (MSSQL, SPIN SQL, PL/SQL, Sybase), pygmentize (MySQL, PgSQL, PL/PgSQL, console Postgres, SQL, console Sqlite)
  18. ML : les deux (Standard ML ainsi qu’Ocaml)
  19. Tcl : les deux

À cette liste, voici le comparatif sur les 20 premiers langages selon l’indice TIOBE en mars 2015 (sans juger de l’intérêt profond du classement en lui-même, ou son absence) :

  1. C : cf. liste précédente
  2. Java : cf. liste précédente
  3. Objective-C : les deux
  4. C++ : cf. liste précédente
  5. C# : cf. liste précédente
  6. PHP : cf. liste précédente
  7. JavaScript : les deux
  8. Python : cf. liste précédente
  9. Visual Basic .NET : ? (je ne connais pas les environnements Microsoft donc j’ai tout mis à la ligne suivante)
  10. Visual Basic : highlight colore les fichiers avec les extensions de fichiers .bas, .basic, .bi et .vbs. pygmentize colore ceux en .vb et .bas.
  11. F# : les deux
  12. Perl : cf. liste précédente
  13. Delphi/Object Pascal : pyg
  14. Transact-SQL : aucun des deux
  15. Pascal : cf. liste précédente
  16. ABAP : les deux
  17. PL/SQL : highlight uniquement
  18. Ruby : cf. liste précédente
  19. MATLAB : les deux. pygmentize colore le langage et la sortie console.
  20. R : les deux. pygmentize colore le langage (avec SLexer, ce n’est pas intuitif), la sortie console et la documentation.

pygmentize et highlight permettent la coloration syntaxique de nombreux autres langages comme Applescript, Awk, Bbcode, Clojure, Haxe, Lua et bien d’autres.

Les fichiers de configuration d’Apache sont colorés par les deux outils. pygmentize colore aussi la configuration de Lighttpd et Nginx mais aussi d’autres fichiers de configuration comme Docker ou CFEngine.

Contrairement à highlight, pygmentize permet aussi de colorer des logs IRC, les fichiers CMake ou du code spécifique aux moteurs de template (django, smarty, mako, genshi, erb).

hightlight colore COBOL ou graphviz, pas pygmentize.

Facile à utiliser

Les deux outils sont triviaux à installer. L’usage est facile aussi car ils déterminent le lexeur à utiliser en fonction de l’extension du fichier. Il est possible de forcer l’utilisation d’un lexeur (utile si les données viennent d’un pipe par exemple).

Par contre (et par défaut), highlight sort la coloration en html et non pour la console. Ce qui oblige à préciser la sortie terminal souhaitée. Il y en a deux possibles : ansi (16 couleurs) et term256 (256 couleurs). Ansi serait-il à réserver aux plus nostalgiques ? Ce choix cornélien s’impose aussi avec pygmentize (sortie par défaut contre console256).
Dans les faits, les différences ont peu d’intérêt.

highlight et pygmentize, période ansi et période 256 couleurs

Colorer de nouveaux langages

Les deux outils permettent d’ajouter de nouveaux lexeurs :
– en Lua pour highlight
– en Python pour pygmentize (qui est lui-même écrit en Python)

Autres usages

highlight et pygmentize permettent d’avoir d’autres sorties :

sorties highlight pygmentize
HTML oui oui
XHTML oui non
SVG oui oui
RTF oui oui
ODT oui non
Images bitmap non oui (bmp, gif, jpeg et png)

highlight est compatible avec source-highlight du projet GNU (outil que je n’ai jamais testé).

Que choisir ?

Si vous avez besoin d’un langage qui est disponible que sur l’un des deux outils, choisissez celui-là.
Si vous comptez écrire des greffons pour ajouter des langages, choisissez si vous préférez écrire en Lua ou en Python.
Si les deux règles précédentes ne permettent pas d’emporter la décision, je conseillerai plutôt pygmentize qui a plus de langages et qui gère des trucs plus récents (les moteurs de template par exemple). Évidemment, si c’est pour maintenir du code COBOL sur une base logicielle de 15 ans d’âge, ça ne sera pas très déterminant non plus…

ccze

ccze n’est pas concurrent des deux outils précédents car il colore des journaux, pas du code.

Affichage de la sortie de cat et ccze

Les remarques et usages de http://www.quennec.fr/gnulinux/utilisation/afficher-les-logs-en-couleur sur ccze sont valides. Cependant j’ai dû activer le mode ansi (avec -A ou --raw-ansi ou bien -m ansi ou encore --mode ansi) lors de mes tests, sinon il n’y avait aucune sortie dans le terminal.

Les journaux d’Apache, Exim, Postfix, syslog sont colorés par ccze. Pour la liste complète, man ccze.

Il est aussi possible d’ajouter de nouveaux type de journaux. Par contre, il faudra les écrire en C (cf. man ccze-plugin).

Fin : références, versions des logiciels

Les statistiques Debian concernant les langages sont issues de http://sources.debian.net/stats/. Pour en savoir plus, voir aussi http://sources.debian.net/doc/ (en particulier « Debsources: Live and Historical Views on Macro-Level »).

La page des lexers de pygmentize est /usr/share/doc/python-pygments-doc/html/docs/lexers.html sur Jessie (en supposant que python-pygments-doc est installé). L’emplacement était /usr/share/doc/python-pygments/lexers.html sur Wheezy (la version stable précédente) et était directement incluse dans le paquet python-pygments.

Les versions utilisées pour l’article :

stephane@foehn:~$ pygmentize -V
Pygments version 2.0.1, (c) 2006-2014 by Georg Brandl.
stephane@foehn:~$ highlight --version

 highlight version 3.18
 Copyright (C) 2002-2013 Andre Simon <andre.simon1 at gmx.de>

 Argparser class
 Copyright (C) 2006-2008 Antonio Diaz Diaz <ant_diaz at teleline.es>

 Artistic Style Classes (2.04)
 Copyright (C) 2006-2013 by Jim Pattee <jimp03 at email.com>
 Copyright (C) 1998-2002 by Tal Davidson

 Diluculum Lua wrapper (1.0)
 Copyright (C) 2005-2013 by Leandro Motta Barros

 xterm 256 color matching functions
 Copyright (C) 2006 Wolfgang Frisch <wf at frexx.de>

 This software is released under the terms of the GNU General Public License.
 For more information about these matters, see the file named COPYING.

stephane@foehn:~$ ccze --version
ccze 0.2.1

03 May, 2015 11:25AM by ascendances

April 15, 2015

Olivier Berger (pro)

Appel pour une “Linked Research” (recherche reliée), traduit en français

J’ai traduit en français les transparents de l’appel pour une “Linked Research” (que j’ai traduit par “recherche reliée”) de Sarven Capadisli originellement en anglais

L’objectif est d’inciter (entre autre actions) à la publication d’articles académiques sous une forme exploitable aussi bien par les humains que par les machines, et permettant ainsi d’embarquer dans le document des méta-données additionnelles.

Plus de détails dans les transparents ici : http://www-public.tem-tsp.eu/~berger_o/presentations-call-for-linked-research-fr/

15 April, 2015 11:51AM by Olivier Berger

Florent Gallaire

Neil McGovern élu DPL pour 2015

C’est Neil McGovern qui vient d’être élu Debian Project Leader (DPL) pour l’année 2015, succédant ainsi au double mandat de Lucas Nussbaum, contre qui il avait perdu en 2014.

Neil McGovern

Neil devance Mehdi Dogguy, qui recueille un nombre de voix très intéressant pour l’avenir, et Gergely Nagy (déjà candidat malheureux en 2004, 2012 et 2013). Voici une représentation du résultat du scrutin qui utilise la méthode Condorcet :

Vote DPL 2015

Bravo à toi Neil, et bonne chance dans la mise en œuvre de ton programme !

15 April, 2015 01:09AM by fgallaire

April 11, 2015

hackergotchi for Roland Mas

Roland Mas

Le marronnier du printemps

Eh ben eh ben eh ben. C'est bien calme ici, alors que j'aurais des tas de choses à dire… Je pourrais vous parler de Chacun sa part, qui continue de vivre sa vie et de croître doucement. Je pourrais vous parler de rock et de batterie. Je pourrais vous parler d'un truc rigolo que j'ai fait et qui mélange Gnucash, Boobank, Python, crm114 et Libre Office Calc. Ou de FusionForge. Ou de moto, de Montpellier, de soleil. Je pourrais vous parler de plein de choses, mais il se trouve que je passe mon temps à faire ces choses plutôt qu'à en parler sur mon blog, tout magnifique soit-il. Donc je me contenterai du marronnier habituel, qui porte cette année le numéro 38.

Et qui le porte bien, merci.

11 April, 2015 05:30PM

April 01, 2015

hackergotchi for Debian France

Debian France

Debian France a un nouveau Président

Suite à l'Assemblée Générale Ordinaire tenue le mois dernier, le Conseil d'Administration de Debian France a élu un nouveau Président: bienvenue à Nicolas Dandrimont (alias olasd) !

Le président précédent, Raphaël Hertzog, reste dans le Conseil d'Administration pour assurer la transition. Sylvestre Ledru reste trésorier et Julien Cristau est reconduit pour un nouveau mandat au Conseil d'Administration. Julien Danjou quitte l'équipe après plusieurs années de bons et loyaux services.

Un grand merci à tous les candidats au Conseil d'Administration, nous comptons sur eux pour aussi dynamiser l'association dans les années à venir: - François-Régis Vuillemin - Michel Barret - Sébatien Poher

01 April, 2015 04:14PM

January 23, 2015

Présentation du projet Debian aux Expériences Numériques

Expériences Numériques

Les EPN de la Maison pour Tous Salle des Rancy en collaboration avec l'Aadn, Aldil, Ubunteros de Lyon, Illyse organisent le 31 janvier 2015 : les Expériences Numeriques.

Ce rendez-vous est une journée de découverte, d’initiation et de rencontres autour des pratiques du numérique.

À cette occasion une conférence aura lieu à 16h pour présenter le projet Debian. Pendant cette journée une install party sera organisée où les personnes qui le désirent pourront installer notre distribution favorite.

Télécharger le programme.

Carte Openstreet Map. Voir aussi le plan d'accès officiel pour plus de détails.

logo Maison pour Tous Salle des Rancy

23 January, 2015 03:12PM

December 23, 2014

hackergotchi for Vincent Bernat

Vincent Bernat

Eudyptula Challenge : démarrage rapide d'un noyau Linux

Le challenge Eudyptula est une série d’exercices de programmation pour le noyau Linux. Il commence avec le très basique module « Hello world » puis progresse en complexité jusqu’à faire pousser des modifications dans l’arbre du noyau Linux.

Une des premières tâches de ce challenge est de compiler puis démarrer son propre noyau. eudyptula-boot est un script autonome permettant de démarrer une image noyau jusqu’à obtenir un shell. Il est livré avec les fonctionnalités suivantes :

  • Il permet de booter quasiment n’importe quel noyau Linux, du noyau fourni par votre distribution favorite jusqu’au noyau personnalisé1 pour travailler sur une fonctionnalité quelconque.

  • Il utilise le système de fichiers de l’hôte comme racine pour le système invité. Aucune image disque n’est donc nécessaire. Ces dernières prennent beaucoup de place, doivent être maintenues à jour, se retrouvent encombrées au fil du temps et les outils dont vous avez besoin ne sont jamais installés. Pour éviter toute modification accidentelle, le système de fichiers est par défaut monté en lecture seule. S’ils sont disponibles, OverlayFS ou aufs sont utilisés pour ajouter une couche accessible en écriture. Il est de plus possible d’utiliser n’importe quel répertoire comme racine.

  • Le répertoire utilisateur est également accessible. Il est ainsi simple de partager des scripts et des programmes avec le système hôte.

  • Il démarre un système minimal avec le strict nécessaire2 pour démarrer un shell dans de bonnes conditions. Le système est opérationnel en moins de cinq secondes.

Dans la vidéo ci-dessous, eudyptula-boot est utilisé pour démarrer le noyau de l’hôte et exécuter quelques commandes :

Dans la vidéo suivante, nous démarrons un noyau personnalisé contenant un appel système supplémentaire. Il s’agit de la tâche n°15 du challenge Eudyptula. Un programme de test permet de vérifier le bon fonctionnement de l’appel système. Vers la fin, la vidéo contient également une rapide démonstration de gdb.

Bien que ce hack permette également de lancer des conteneurs3 avec une isolation accrue, les performances de 9p sont malheureusement peu convaincantes pour un tel usage.

vido est un projet similaire.


  1. Il est toutefois nécessaire d’activer le support de 9p virtio. Il suffit pour cela d’utiliser make kvmconfig

  2. Seul udev est démarré. 

  3. Un point de départ pour une telle utilisation est de combiner les options --root, --force et --exec. Ajoutez également --readwrite pour conserver les modifications. 

23 December, 2014 12:46PM by Vincent Bernat

December 22, 2014

hackergotchi for Debian France

Debian France

Dons Debian France

Dons Debian France

En cette fin d'année, nous tenons à rappeler que l'association Debian France est reconnue d'intérêt général. Ainsi, les donations à destination de l'association peuvent être déduites des impôts.

Une fois la donation réalisée, pour obtenir un reçu, il suffit d'envoyer un mail au trésorier - <tresorier@france.debian.net> en indiquant votre adresse.

Formulaire de donation

22 December, 2014 04:47PM

December 10, 2014

Olivier Berger (perso)

Réparé les hauts-parleurs d'un portable HP dv6000 en échangeant deux nappes internes

Les hauts-parleurs internes du portable HP de mes parents, un dv6000, ne marchaient plus : plus de son sans devoir mettre des enceintes ou un casque :-(

En fait, il semble que ce soit un problème classique, qui semble causé par des nappes de connexion internes deffectueuses.

La réparation n'est pas trop compliquée, si on achète une nappe de remplacement, mais on peut aussi trouver un contournement.

J'ai réussi à échanger les deux nappes qui connectent la carte mère à la partie qui contient les boutons et les hauts-parleurs, au dessus du clavier, et même si maintenant, les boutons de cette rangée supérieure ne marchent plus, ce n'est pas trop grave, car le son est revenu.

Pour voir une vidéo (en anglais) qui explique comment faire, voir : Hp Pavilion Dv6000 power button and speaker fix!

Content d'avoir récupéré le son :-)

10 December, 2014 10:10PM by obergix

December 09, 2014

hackergotchi for Debian France

Debian France

Debian France au Capitole du Libre

Debian France au Capitole du Libre

Le samedi 15 novembre, l'association Debian France a tenu un stand au Capitole du Libre, l'événement du Libre à Toulouse. Ceci a permis de créer un certain nombre de contacts prometteurs, et de confirmer que Debian est une référence reconnue pour ses valeurs. Nous remercions l'association Toulibre pour son accueil et son très bel événement!

09 December, 2014 04:06PM

November 16, 2014

hackergotchi for Vincent Bernat

Vincent Bernat

Préparer des règles Netfilter dans un espace de nommage réseau

Souvent, les règles d’un pare-feu sont mises en place à l’aide d’un script faisant appel aux commandes iptables et ip6tables. Cela permet notamment d’utiliser des variables et des boucles. Il y a cependant trois inconvénients majeurs à cette méthode :

  1. Pendant toute la durée du script, le pare-feu est temporairement incomplet : les nouvelles connexions peuvent ne pas être autorisées à s’établir ou, inversement, le pare-feu peut autoriser des flux qui ne devraient pas l’être. Les règles de NAT nécessaires au bon fonctionnement du routeur peuvent également être absentes.

  2. Si une erreur survient, le pare-feu reste dans un état intermédiaire. Il est alors nécessaire de s’assurer que les règles autorisant l’accès à distance soient placées très tôt pour garder la main. Un système de retour automatique à la précédente version est également nécessaire pour corriger la situation rapidement.

  3. Construire de nombreuses règles peut être très lent. Chaque appel à ip{,6}tables va rapatrier l’ensemble des règles du noyau, ajouter la règle voulue et renvoyer le tout au noyau.

Avec iptables-restore§

Une façon classique de résoudre ces trois aspects et de construire un fichier de règles qui sera lu par iptables-restore et ip6tables-restore1. Ces outils envoient en une seule passe les règles au noyau qui les applique de manière atomique. Habituellement, un tel fichier est construit par ip{,6}tables-save mais un script peut également faire l’affaire.

MISE À JOUR : ferm, un outil pour maintenir un pare-feu, constitue une solution alternative à cette approche.

La syntaxe comprise par ip{,6}tables-restore est similaire à celle de ip{,6}tables. Cependant, chaque table dispose de son propre bloc et les chaînes doivent être déclarées différemment. Voyons un exemple :

$ iptables -P FORWARD DROP
$ iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -j MASQUERADE
$ iptables -N SSH
$ iptables -A SSH -p tcp --dport ssh -j ACCEPT
$ iptables -A INPUT -i lo -j ACCEPT
$ iptables -A OUTPUT -o lo -j ACCEPT
$ iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
$ iptables -A FORWARD -j SSH
$ iptables-save
*nat
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
-A POSTROUTING -s 192.168.0.0/24 -j MASQUERADE
COMMIT

*filter
:INPUT ACCEPT [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
:SSH - [0:0]
-A INPUT -i lo -j ACCEPT
-A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -j SSH
-A OUTPUT -o lo -j ACCEPT
-A SSH -p tcp -m tcp --dport 22 -j ACCEPT
COMMIT

La table nat et la table filter disposent chacune de leur bloc. La chaîne SSH est déclarée en haut du bloc de la table filter avec les autres chaînes par défaut.

Voici un script qui détourne les commandes ip{,6}tables afin de construire un tel fichier (en s’appuyant massivement sur Zsh2) :

#!/bin/zsh
set -e

work=$(mktemp -d)
trap "rm -rf $work" EXIT

# ➊ Redefine ip{,6}tables
iptables() {
    # Intercept -t
    local table="filter"
    [[ -n ${@[(r)-t]} ]] && {
        # Which table?
        local index=${(k)@[(r)-t]}
        table=${@[(( index + 1 ))]}
        argv=( $argv[1,(( $index - 1 ))] $argv[(( $index + 2 )),$#] )
    }
    [[ -n ${@[(r)-N]} ]] && {
        # New user chain
        local index=${(k)@[(r)-N]}
        local chain=${@[(( index + 1 ))]}
        print ":${chain} -" >> ${work}/${0}-${table}-userchains
        return
    }
    [[ -n ${@[(r)-P]} ]] && {
        # Policy for a builtin chain
        local index=${(k)@[(r)-P]}
        local chain=${@[(( index + 1 ))]}
        local policy=${@[(( index + 2 ))]}
        print ":${chain} ${policy}" >> ${work}/${0}-${table}-policy
        return
    }
    # iptables-restore only handle double quotes
    echo ${${(q-)@}//\'/\"} >> ${work}/${0}-${table}-rules #'
}
functions[ip6tables]=${functions[iptables]}

# ➋ Build the final ruleset that can be parsed by ip{,6}tables-restore
save() {
    for table (${work}/${1}-*-rules(:t:s/-rules//)) {
        print "*${${table}#${1}-}"
        [ ! -f ${work}/${table}-policy ] || cat ${work}/${table}-policy
        [ ! -f ${work}/${table}-userchains || cat ${work}/${table}-userchains
        cat ${work}/${table}-rules
        print "COMMIT"
    }
}

# ➌ Execute rule files
for rule in $(run-parts --list --regex '^[.a-zA-Z0-9_-]+$' ${0%/*}/rules); do
    . $rule
done

# ➍ Execute rule files
ret=0
save iptables  | iptables-restore  || ret=$?
save ip6tables | ip6tables-restore || ret=$?
exit $ret

En ➊, une nouvelle fonction iptables() est définie et masque la commande du même nom. Elle tente de localiser le paramètre -t pour savoir quelle table est concernée par la règle. Si le paramètre est présent, la table est mémorisée dans la variable $iptables et le paramètre est retiré de la liste des arguments. La défintion d’une nouvelle chaîne avec -N ou la mise en place d’une politique par défaut avec -P sont également gérés.

En ➋, la fonction save() va émettre les règles qui seront lues par ip{,6}tables-restore. En ➌, les règles de l’utilisateur sont exécutées. Chaque commande ip{,6}tables appelle en réalité la fonction précédemment définie. Si aucune erreur n’est survenue, en ➍, les commandes ip{,6}tables-restore sont invoquées.

Cette méthode est parfaitement fonctionnelle3. Toutefois, la méthode suivante est bien plus élégante.

Avec un espace de nommage§

Une approche hybride est de construire les règles avec ip{,6}tables dans un espace de nommage réseau (network namespace) puis de les sauver avec ip{,6}tables-save et enfin de les appliquer dans l’espace de nommage principal avec ip{,6}tables-restore.

#!/bin/zsh
set -e

alias main='/bin/true ||'
[ -n $iptables ] || {
    # ➊ Execute ourself in a dedicated network namespace
    iptables=1 unshare --net -- \
        $0 4> >(iptables-restore) 6> >(ip6tables-restore)
    # ➋ In main namespace, disable iptables/ip6tables commands
    alias iptables=/bin/true
    alias ip6tables=/bin/true
    alias main='/bin/false ||'
}

# ➌ In both namespaces, execute rule files
for rule in $(run-parts --list --regex '^[.a-zA-Z0-9_-]+$' ${0%/*}/rules); do
    . $rule
done

# ➍ In test namespace, save the rules
[ -z $iptables ] || {
    iptables-save >&4
    ip6tables-save >&6
}

En ➊, le script est réexécuté dans un nouvel espace de nommage réseau. Celui-ci dispose de ces propres règles de pare-feu qui peuvent être modifiées sans altérer celles de l’espace de nommage principal. La variable $ipatbles est utilisée pour déterminer quel est l’espace de nommage courant. Dans le nouvel espace de nommage, les fichiers de règles sont exécutés (➌). Ceux-ci contiennent l’appel aux commandes ip{,6}tables. Si une erreur survient, nous n’allons pas plus loin grâce à l’utilisation de set -e. Sinon, en ➍, les règles sont sauvegardées avec ip{,6}tables-save et envoyées dans l’espace de nommage principal en utilisant les descripteurs de fichier dédiés à cet effet.

L’exécution dans l’espace de nommage principal continue en ➊. Les résultats de ip{,6}tables-save sont envoyées à ip{,6}tables-restore. À ce point, le pare-feu est presque fonctionnel. Les fichiers de règles sont toutefois rejoués (➌) mais les commandes ip{,6}tables sont neutralisées (➋) de façon à ce que les éventuelles autres commandes, comme par exemple l’activation du routage IP, soient exécutées.

Le nouvel espace de nommage ne dispose pas du même environnement que l’espace de nommage principal. Notamment, il ne contient pas d’interfaces réseau. Il n’est donc pas possible de consulter ou de configurer des adresses IP. Lorsque des commandes ne peuvent être exécutées que dans l’espace de nommage principal, il est nécessaire de les préfixer par main :

main ip addr add 192.168.15.1/24 dev lan-guest

Jetez un coup d’œil à un exemple complet sur GitHub.


  1. iptables-apply est un autre outil pratique. Il applique un fichier de règles et revient automatiquement en arrière si l’utilisateur ne confirme pas le changement dans un laps de temps donné. 

  2. Zsh contient des primitives assez puissantes pour manipuler les tableaux. De plus, il ne nécessite pas d’utiliser les guillemets autour de chaque variable pour éviter leur découpage lorsqu’elles contiennent des espaces. Cela rend le script bien plus robuste. 

  3. S’il fallait pinailler, il y a trois petits problèmes. Primo, lorsqu’une erreur survient, il peut être difficile de savoir quelle partie du script l’a provoquée car on ne dispose que de la ligne dans le fichier de règles qui a été généré. Deuzio, une table peut être utilisée avant d’être définie ce qui peut faire passer inaperçu certaines erreurs dues à un copier/coller. Tertio, l’application de la partie IPv4 peut réussir alors que la partie IPv6 a échoué ou vice-versa. Ces problèmes n’existent pas avec la deuxième méthode. 

16 November, 2014 04:28PM by Vincent Bernat

September 24, 2014

hackergotchi for Debian France

Debian France

Debian France reconnu comme Debian Trusted Organization

Debian France reconnu comme Debian Trusted Organization

Grâce à la refonte des statuts de l'association, Debian France est maintenant reconnue officiellement comme étant une Trusted Organization. Ainsi, l'association Debian France est habilitée à recevoir des fonds au nom de Debian et procéder à des dépenses pour le projet.

L'annonce a été réalisée par Lucas Nussbaum, Debian Project Leader.

24 September, 2014 07:14AM

September 12, 2014

Stéphane Blondon

Key Signing Assistant (concept)

Dans les allées de la DebConf14, j’ai discuté avec Franklin de l’intérêt pour un développeur d’utiliser son téléphone portable lors d’une key signing party.

Les schémas sont un brouillon d’une utilisation possible du téléphone. L’objectif n’est pas de remplacer la rencontre réelle ou la validation mais juste d’aider à l’échange et validation des clefs.

Actuellement, ce n’est qu’un concept ; rien n’est implémenté.

Le principe général est d’utiliser le téléphone comme un terminal pour l’échange et la validation. Les données partent et reviennent sur la station de travail du développeur par l’intermédiaire d’un serveur web.

  • Le téléphone portable considéré doit être un smartphone ;
  • La seule autorisation à donner pour le téléphone est l’accès à internet ;
  • On considère que les échanges réseau sont fait en https. Je ne pense pas que ce soit indispensable mais il n’y a aucune raison de s’en priver.

Avant la key signing party

Le développeur dispose d’un téléphone sur lequel l’application est installée.
Le processus pour installer ses propres informations est le suivant :

Avant la key signing party

Pendant la key signing party

Le processus est à reproduire pour chaque participant.

Pendant la key signing party

Après la key signing party

Une fois rentré chez lui, le développeur récupère l’ensemble de ses validations sur sa machine de travail :

Après la key signing party

Qu’en pensez-vous ?

Source des schémas

Schémas réalisés avec Inkscape, à partir d’icônes Tango et Gnome-Tango.
Les fichiers svg et png sont disponibles dans le répertoire http://stephane.yaal.fr/ksa/.


12 September, 2014 07:18AM by ascendances

September 10, 2014

Olivier Berger (pro)

Le MOOC Bases de données relationnelles est lancé

Nous venons de lancer la première édition du MOOC sur les bases de données relationnelles de Télécom SudParis. Au programme, de la théorie (algèbre relationnelle), de la pratique (dans SQLite dans les navigateurs basés sur WebKit, et plus tard dans PostgreSQL dans une box Vagrant basée sur Debian (voir post précédent)), des contenus et logiciels libres (autant que possible) et pas mal de rush pour finaliser tout ça dans le Moodle.

On débute avec plus de 800 inscrits à la fin du premier jour (y compris les 180 étudiants ingénieurs de 2ème année de Télécom SudParis, qui suivront le cours présentiel en parallèle du MOOC, et collaboreront avec les apprenants externes pour les travaux personnels).

Il est toujours possible de s’inscrire : le gros du travail commence en semaine 2 (qui commence lundi 15/09 à 00h00 heure de Paris).

10 September, 2014 07:53PM by Olivier Berger

August 20, 2014

hackergotchi for Aurélien Jarno

Aurélien Jarno

MIPS Creator CI20

I have received two MIPS Creator CI20 boards, thanks to Imagination Technologies. It’s a small MIPS32 development board:

mips-ci20

As you can see it comes in a nice packaging with a world-compatible power adapter. It uses a Ingenic JZ4780 SoC with a dual core MIPS32 CPU running at 1.2GHz with a PowerVR SGX540 GPU. The board is fitted with 1GB of RAM, 8GB of NOR flash, HDMI output, USB 2.0 ports, Ethernet + Wi-Fi + BlueTooth, SD card slot, IR receiver, expansion headers and more. The schematics are available. The Linux kernel and the U-Boot bootloader sources are also available.

Powering this board with a USB keyboard, a USB mouse and a HDMI display, it boots off the internal flash on a Debian Wheezy up to the XFCE environment. Besides the kernel, the Wi-Fi + Bluetooth firmware, and very few configuration changes, it runs a vanilla Debian. Unfortunately I haven’t found time to play more with it yet, but it looks already quite promising.

The board has not been formally announced yet, so I do not know when it will become available, nor the price, but if you are interested I’ll bring it to DebConf14. Don’t hesitate to ask me if you want to look at it or play with it.

20 August, 2014 08:52PM by aurel32

Olivier Berger (pro)

Building a lab VM based on Debian for a MOOC, using Vagrant + VirtualBox

We’ve been busy setting up a Virtual Machine (VM) image to be used by participants of a MOOC that’s opening in early september on Relational Databases at Telecom SudParis.

We’ve chosen to use Vagrant and VirtualBox which are used to build, distribute and run the box, providing scriptability (reproducibility) and making it portable on most operating systems.

The VM itself contains a Debian (jessie) minimal system which runs (in the background) PostgreSQL, Apache + mod_php, phpPgAdmin, and a few applications of our own to play with example databases already populated in PostgreSQL.

As the MOOC’s language will be french, we expect the box to be used mostly on machines with azerty keyboards. This and other context elements led us to add some customizations (locale, APT mirror) in provisioning scripts run during the box creation.

At the moment, we generate 2 variants of the box, one for 32 bits kernel (i686) and one for 64 bits kernel (amd64) which (once compressed) represent betw. 300 and 350 Mb.

The resulting boxes are uploaded to a self-hosting site, and distributed through vagrantcloud. Once the VM are created in VirtualBox, the typical VMDK drives file is around 1.3Gb.

We use our own Debian base boxes containing a minimal Debian jessie/testing, instead of relying on someone else’s, and recreate them using (the development branch version of) bootsrap-vz. This ensure we can put more trust in the content as it’s a native Debian package installation without MITM intervention.

The VM are meant to be run headless for the moment, keeping their size to the minimum, even though we also provide a script to install and configure a desktop environment based on XFCE4.

The applications are either used through vagrant ssh, for instance for SQL command-line in psql, or in the Web browser, for our own Web based SQL exerciser, or phpPgAdmin (see a demo screencast (in french, w/ english subtitles)), which can then be used even off-line by the participants, which also means this requires no servers availability for our IT staff.

The MOOC includes a section on PHP + SQL programming, whose exercises can be performed using a shared sub-folder of /vagrant/ which allows editing on the host with the favourite native editor/IDE, while running PHP inside the VM’s Apache + mod_php.

The sources of our environment are available as free software, if you’re interested to replicate a similar environment for another project.

As we’re still polishing the environment before the MOOC opening (on september 10th), I’m not mentioning the box URLs but they shouldn’t be too hard to find if you’re investigating (refering to the fusionforge project’s web site).

We don’t know yet how suitable this environment will be for learning SQL and database design and programming, and if Vagrant will bring more difficulties than benefits. Still we hope that the participants will find this practical, allowing them to work on the lab / exercises whenever and wherever they chose, removing the pain of installing and configuring a RDBMS on their machines, or the need to be connected to a cloud or to our overloaded servers. Of course, one limitation will be the requirements on the host machines, that will need to be reasonably modern, in order to run a virtualized Linux system. Another is access to high bandwidth for downloading the boxes, but this is kind of a requirement already for downloading/watching the videos of the MOOC classes 😉

Big thanks go to our intern Stéphane Germain, who joined us this summer to work on this virtualized environment.

20 August, 2014 01:59PM by Olivier Berger

August 15, 2014

hackergotchi for Aurélien Jarno

Aurélien Jarno

Intel about to disable TSX instructions?

Last time I changed my desktop computer I bought a CPU from the Intel Haswell family, the one available on the market at that time. I carefully selected the CPU to make sure it supports as many instructions extensions as possible in this family (Intel likes segmentation, even high-end CPUs like the Core i7-4770k do not support all possible instructions). I ended-up choosing the Core i7-4771 as it supports the “Transactional Synchronization Extensions” (Intel TSX) instructions, which provide transactional memory support. Support for it has been recently added in the GNU libc, and has been activated in Debian. By choosing this CPU, I wanted to be sure that I can debug this support in case of bug report, like for example in bug#751147.

Recently some computing websites started to mention that the TSX instructions have bugs on Xeon E3 v3 family (and likely on Core i7-4771 as they share the same silicon and stepping), quoting this Intel document. Indeed one can read on page 49:

HSW136. Software Using Intel TSX May Result in Unpredictable System Behavior

Problem: Under a complex set of internal timing conditions and system events, software using the Intel TSX (Transactional Synchronization Extensions) instructions may result in unpredictable system behavior.
Implication: This erratum may result in unpredictable system behavior.
Workaround: It is possible for the BIOS to contain a workaround for this erratum.

And later on page 51:

Due to Erratum HSw136, TSX instructions are disabled and are only supported for software development. See your Intel representative for details.

The same websites tell that Intel is going to disable the TSX instructions via a microcode update. I hope it won’t be the case and that they are going to be able to find a microcode fix. Otherwise it would mean I will have to upgrade my desktop computer earlier than expected. It’s a bit expensive to upgrade it every year and that’s a the reason why I skipped the Ivy Bridge generation which didn’t bring a lot from the instructions point of view. Alternatively I can also skip microcode and BIOS updates, in the hope I won’t need another fix from them at some point.

15 August, 2014 04:02PM by aurel32

July 15, 2014

Stéphane Blondon

DebConf sur la planète

Cette année, la conférence Debian annuelle aura lieu à Portland, aux États-Unis. Comme l’année dernière, j’y participerai.:)

Participation à la conférence Debian

Cette conférence sera la quinzième du nom. Voici une carte des différentes DebConf (passées en rouge, la prochaine en blanc et celle de l’année prochaine en jaune).

debconf14_planet

Jusqu’ici les conférences ont eu lieu alternativement en Europe et en Amérique (du Nord, centrale ou du Sud). Ce sera aussi le cas en 2015 puisque la conférence aura lieu en Allemagne à Heidelberg.

Réalisation de la carte

La carte diffère légèrement de celle réalisée l’année dernière (pour DebConf13) grâce quelques changements de configuration d’xplanet.

Commande utilisée

xplanet -transpng debconf14_planet.png -geometry 1024x512 -projection peters -config debconf14_planet.conf -num_times 1

Deux paramètres ont été modifiés :

  • La carte utilise une projection de Peters plutôt qu’une projection de Mercator. Pour cela, il suffit de remplacer -projection mercator par -projection peters.
  • Avec cette projection, la taille de la Terre n’est pas la même et la zone vide est rempli par défaut par un ciel étoilé. Il est aussi possible de choisir une couleur unie ou sa propre image de fond. Remplacer le paramètre -output par -transpng pour définir le fichier de sortie permet d’avoir un fond transparent.

Fichier debconf14_planet.conf

[earth]
shade=100
marker_file=coords.txt
marker_fontsize=15
map=night.jpg

L’ajout de map permet de définir l’image à utiliser à la place de l’image par défaut. Ici, on obtient une image de la Terre de nuit (qui provient de /usr/share/xplanet/images/night.jpg).

Fichier coords.txt

+44.80 +0.58 "0&1" #Bordeaux, France
+43.65 -79.38 "2" #Toronto, Canada
+59.92 +10.75 "3" #Oslo, Norway
-29.99 -51.22 "4" #Porto Alegre, Brazil
+60.22 +24.66 "5" #Espoo, Finland
+18.91 -98.97 "6" #Oaxtepec, Mexico
+55.96 -3.19 "7" #Edinburgh, Scotland
-37.96 -57.59 "8" #Mar del Plata, Argentina
+39.60 -6.08 "9" #Extremadura, Spain
+40.74 -74.00 "10" #New York City, USA
+44.78 +17.21 "11" #Banja Luka, Republika Srpska, Bosnia and Herzegovina
+12.14 -86.25 "12" #Managua, Nicaragua
+46.87 +6.75 "13" #Le Camp, Vaumarcus, Switzerland
+45.53 -122.67 "14" color=white #Portland, Oregon, USA
+49.24 +8.42 "15" color=yellow #Heidelberg, Germany

Le fichier a simplement été mis à jour (ajout d’Heidelberg, décalage des couleurs).

À bientôt !


15 July, 2014 08:56PM by ascendances

June 18, 2014

hackergotchi for Aurélien Jarno

Aurélien Jarno

Debian is switching (back) to GLIBC

Five years ago Debian and most derivatives switched from the standard GNU C Library (GLIBC) to the Embedded GLIBC (EGLIBC). Debian is now about to take the reverse way switching back to GLIBC, as EGLIBC is now a dead project, the last release being the 2.19 one. At the time of writing the glibc package has been uploaded to experimental and sits in the NEW queue.

EGLIBC is dead for a good reason: the GLIBC development has changed a lot in the recent years, due to two major events: Ulrich Drepper leaving Red Hat and the GLIBC development, and the GLIBC steering committe self-dissolving. This has resulted in a much more friendly development based on team work with good cooperation. The development is now based on peer review, which results in less buggy code (humans do make mistakes). It has also resulted in things that were clearly impossible before, like using the same repository for all architectures, and even getting rid of the ports/ directory. Before we used to have two sets of architectures, the main ones in the glibc repository with architectures like x86, SuperH or SPARC, and the secondary ones in the glibc-ports repository with architectures like ARM or MIPS. As you can see the separation was quite arbitrary, and often leaded to missing changes on the secondary architectures. We also got real stable branches, with regular fixes.

The most important EGLIBC features have been merged to GLIBC, including for example the use of non-bash but POSIX shell, or the renaming of reserved keywords. The notable exception is the support for configurable components, which we originally planned to use for Debian-Installer, by building a smaller flavor using -Os and without NIS and RPC support. At the end we never worked on that, and it seems that the hardware targeted by Debian has grown faster than the GLIBC size, so that is not really a big loss. At the end, we ended up with only 5 missing patches from the EGLIBC tree:

The package names are unchanged (except the source package and the binary package containing the sources) so the transition is fully transparent for the users.

I would like to thank all the CodeSourcery employees who worked on EGLIBC, with a special thank to Joseph Myers who spent countless hours to merge the most important EGLIBC changes back to GLIBC, and sent regular emails about the merge status. I would also like to thanks all the people on the GLIBC side that made the change to happen, and all persons participating in the GLIBC development.

18 June, 2014 08:04PM by aurel32

April 11, 2014

hackergotchi for Roland Mas

Roland Mas

Une page de publicité

Allez, c'est vendredi, c'est permis, je vais m'autoriser deux petites annonces.

Premièrement : rappelez-vous Minami Taiko, ce groupe de tambours japonais du sud de la France. Bon, nous on est des amateurs, mais il se trouve qu'on fait venir, pour le festival Escale à Sète, un vrai groupe de taikos du Japon et tout. Ils s'appellent SEN, et ils vont faire quelques animations musicales dans Sète du 18 au 21 avril. Et avant de repartir dans leur lointain Cipango, ils feront un vrai concert à Montpellier, le mardi 22 avril au soir, sur le campus de l'INRA/Supagro. Et devinez qui fait la première partie ? Minami Taiko, voilà qui ! Donc si vous voulez découvrir le taiko ou voir quelques amateurs suivis d'un vrai groupe, faites donc un tour sur le site de Minami Taiko. À noter qu'il y a aussi un atelier d'initiation le même jour si ça vous intéresse.

Deuxièmement : je suis fier de vous présenter un petit site web que c'est moi qui l'ai fait avec mes petits doigts délicats. Ça s'appelle Chacun sa part, et ça sert à faire des comptes entre amis, genre quand on part en vacances ensemble, ou qu'on fait régulièrement des dépenses partagées dans un groupe de gens. Pour éviter des comptes d'apothicaire à chaque restau, chaque tournée au bar, chaque passage en caisse, on saisit la dépense sur le site, on dit qui a payé et qui a participé, et le site calcule automatiquement les soldes de chacun et propose des suggestions de remboursements pour rééquilibrer les comptes. Y'a un système d'invitations pour que chacun puisse consulter l'état du groupe et saisir des dépenses, des QR-codes pour faciliter la vie aux utilisateurs de smartphone, et même si ça n'a pas encore été testé à grande échelle ça a été validé par une poignée de testeurs dans différentes configurations. Allez-y, c'est cadeau. Chacun sa part. Point com.

11 April, 2014 08:06AM

37

C'est l'heure d'un marronnier de ce blog : la petite chronique numérologique du 11 avril. Celle-ci sera consacrée au nombre 37.

Nombre premier, premier irrégulier, premier cubain, cousin avec 41, hexagonal centré et étoilé, c'est aussi le numéro atomique du rubidium et ça nous fait une belle jambe.

Et c'est un nombre qui colle particulièrement bien à la journée d'aujourd'hui (qui, si jamais les générations futures s'y intéressent, s'annonce pour être belle et douce, avec peut-être un petit voile nuageux).

11 April, 2014 08:06AM

November 15, 2013

10 ans !

Eh ben dites-donc mes aïeux, le temps passe. Le 15 novembre 2003, j'émettais ma première facture en tant que consultant indépendant.

Eh ben dix ans plus tard, y'a eu des hauts et des bas, mais globalement tout va bien, et je continue à faire des factures de temps en temps, et ça me plaît toujours autant.

Touchons du bois pour que ça continue, et on en reparle dans dix ans !

15 November, 2013 02:45PM

October 10, 2013

Les rumeurs de la mort de ce blog…

…sont un peu exagérées. Mais c'est sûr, c'est calme, et apparemment une partie de mon lectorat s'en inquiète. Donc voici un lot de nouvelles pour ceux que ma vie passionne et qui n'ont plus accès au 3615 Roland.

Alors bon, suite à ce que je vous disais sur Eleven en mai, je me suis mis en quête d'un autre groupe de rock. J'avais cru en trouver un, mais j'ai l'impression que la motivation n'était pas universellement partagée, à tel point qu'on a dû faire moins d'une répétition par mois en moyenne. C'est pas des bonnes conditions, donc je suis de nouveau en recherche. Si vous cherchez un batteur pour jouer du rock aux environs de Montpellier, faites-moi signe.

Cela dit, je ne suis pas resté oisif pour autant : le taiko continue, l'association a été reprise en main, on répète, et hop hop hop on est même invités à jouer en public pas plus tard que ce week-end ! Ça va se passer au parc Borély à Marseille, à l'occasion du festival d'automne organisé par le consulat général du Japon. Plus de détails sur le site de Minami Taiko, vu que c'est comme ça qu'on s'appelle. Le site est neuf aussi, mais on y mettra des photos et peut-être des vidéos.

Sur les autres fronts : côté FusionForge c'est calme, mais la prochaine édition du Debian Administrator's Handbook / Cahier de l'Admin Debian avance petit à petit. On commence non pas à en voir le bout, mais à voir ce qu'il reste à faire avant d'en voir le bout. Mes autres récents petits bricolages de geek feront peut-être l'objet d'un billet dédié si je suis motivé.

Voilà voilà.

10 October, 2013 03:15PM

August 26, 2013

Olivier Berger (perso)

Synchroniser la musique entre ordinateur (Gnu/Linux) et NAS de la Freebox Revolution

J'utilise git-annex pour synchroniser le partage sur le NAS de la FreeBox Revolution, de mes fichiers de musique numérisée (MP3, Ogg), de façon à pouvoir gérer la musique sur mon ordinateur, tout en permettant de la jouer sur la télévision du salon, via l'interface de la freebox. La même procédure doit marcher pour d'autres NAS/set top boxes.

Données du problème :

  • mettre à jour les fichiers depuis le PC (ligne de commande, interfaces graphiques, numérisation de nouveaux CDs, etc.)
  • avoir un backup sur un disque de sauvegarde (sur une machine différente de cd PC, en cas de fausse manip, ou du NAS, au cas où la freebox plante).
  • avoir les fichiers en clair dans l'arborescence du NAS, sous son répertoire prédéfini par la freebox
  • automatiser la synchronisation et les backups, autant que faire se peut

La procédure est la suivante :

  1. monter sur mon ordi, via CIFS, le disque de la freebox, qu'elle exporte via samba : c'est donc un montage ne supportant pas les liens symboliques : git-annex supporte heuresement le mode "direct" pour les remotes. Ce n'est donc pas une remote réseau, mais une remote locale, dans un répertoire de l'ordi. Appelons-le /mnt/freebox-server dans ce qui suit.
  2. initialiser un dossier de bibliothèque musicale comme étant un repo git-annex :

$ cd ~/Musique
$ git init
$ git annex init "mon ordi"

# ajout des fichiers musicaux

$ git annex add . $ git commit -m "initial"

$ cd /mnt/freebox-server/Musiques # on clone dans un sous-répertoire pour permettre de gérer des fichiers en dehors ce schéma sur la freebox $ git clone ~/Musique all $ cd all $ git annex init "freebox server"

$ cd ~/Musique $ git remote add freebox-server /mnt/freebox-server/Musiques/all # copie des fichiers : long $ git annex copy --to freebox-server $ git annex sync
$ cd /mnt/freebox-server/Musiques/all #$ git remote add laptop $ git annex sync

Normalement, à l'issue de tout cela, le contenu sur la freebox est synchronisé.

Ensuite, il ne reste qu'à ajouter une remote spéciale rsync pour les backups vers une autre machine, mais ça je vous laisse jouer avec git-annex pour voir comment faire ;)

26 August, 2013 09:12AM by obergix

August 01, 2012

hackergotchi for Grégory Colpart

Grégory Colpart

Astuces pour gérer un répertoire ext3 bien rempli

Disclaimer : Valable pour de l’ext3 sous Linux (utilisable sur d’autres filesystems ou Unix à vos disques et péril)

Vous avez un répertoire rempli à rabord de nombreux fichiers, et il est impossible de connaître sa taille, le lister ou l’effacer sans impact sur la production ?

Voici quelques astuces :

– Avec un “ls -ld” sur le répertoire, vous pouvez estimer grossièrement le nombre de fichiers présents dans un répertoire. En effet, un répertoire vide fait 4 Ko (je simplifie). Et plus il contient de fichiers, plus sa taille va augmenter. Par exemple, un répertoire contenant 2 millions de fichiers pourra faire une taille de 100 Mo (je parle bien de la taille du répertoire et non pas de la taille du contenu). Attention, c’est variable selon la longueur des noms des fichiers. Et prendre garde aussi que ce n’est pas dynamique : si vous videz complètement un répertoire bien rempli, il gardera sa taille volumineuse (d’où l’intérêt de recréer un répertoire qui s’est rempli “par erreur”).

– Pour lister les fichiers du répertoire, utiliser la commande “ls” n’est pas une bonne idée car elle accède à toute la liste avant de l’afficher. Voici comment lister 10 fichiers sans attendre :

perl -le 'opendir DIR, "." or die; $i=0; while ($i<10) { my $f = readdir DIR; print $f; $i++; }; closedir DIR'

Grâce à leurs noms, vous pouvez désormais examiner (ouvrir, connaître sa taille) un échantillon de fichiers contenus dans votre fameux répertoire.

Pour lister l’ensemble des fichiers sans attendre comme “ls” :

perl -le 'opendir DIR, "." or die; print while $_ = readdir DIR; closedir DIR'

– Pour effacer le contenu du répertoire en limitant l’impact sur la production, oubliez “rm -rf” qui va saturer vos I/O disque mais préférez le faire par blocs de N fichiers avec des pauses de quelques secondes ! Voici une commande “conviviale” qui va faire cela par blocs de 300 fichiers avec des pauses de 5 secondes :

perl -le 'use POSIX qw/strftime/; opendir DIR, "." or die; $i=0; printf "DELETING IN PROGRESS...";
 while (my $f = readdir DIR) {unlink $f;  $i++;
 if ($i % 300 == 0) {printf "...$i files deleted\n".strftime("%Y-%m-%d %H:%M:%S",localtime)." : PAUSE...";
 $| = 1; sleep 5 ; printf "...DONE. "; printf "DELETING IN PROGRESS..."}}; printf "...DONE"; closedir DIR'

EDIT : en complément, on n’oubliera pas que l’on peut aussi gérer la priorité d’ordonnancement des I/O avec la commande ionice
(merci à Sylvain B. de l’avoir souligné)

01 August, 2012 02:24AM by Gregory Colpart

August 18, 2010

Mon compte-rendu de DebConf 10 à New York

DebConf est la conférence annuelle des développeurs du projet Debian. Cela permet aux développeurs et contributeurs de Debian d’assister à des présentations techniques, sociales et politiques, mais aussi de se rencontrer et travailler ensemble. Cette année, la 11e DebConf s’est tenue à New York du 1er au 7 août. Evolix a sponsorisé cette conférence et j’étais donc sur place, voici mon résumé de cette semaine.

Premiers pas plutôt festifs le vendredi soir avec le SysAdmin Day dans un bar à Manhattan puis direction Brooklyn pour une Debian Party organisée par NYC Resistor, un collectif local de hackers en électronique à l’origine de MakerBot, une imprimante 3D Open Source. Samedi c’est l’arrivée à Columbia University, l’université américaine qui accueille la DebConf 10. Une bonne partie des participants est hébergée sur le campus universitaire, dans des chambres avec accès haut-débit et une cafétéria à volonté.

C’est donc le dimanche 1er août que commence la DebConf avec des présentations orientées grand public pour cette première journée appelée le “Debian Day”. Un grand message de bienvenue pour un public plus large en ce premier jour, puis enchaînement des présentations. J’ai tout d’abord assisté à une présentation sur le sysadmin par François Marier qui a livré toutes ses astuces et une série de packages intéressants (unattended-upgrades, safe-rm, etckeeper, fcheck, fwknop, etc.). J’ai d’ailleurs pu échanger par la suite avec lui d’autres informations, sachant qu’il travaille dans une boîte similaire à Evolix : Catalyst située en Nouvelle-Zélande ! J’ai ensuite assisté à la présentation de Stefano Zacchiroli, l’actuel leader Debian, qui encourage fortement les développeurs à réaliser des NMU (Non Maintainer Upload), c’est-à-dire la publication d’un package par un autre développeur que celui responsable officiellement. J’ai ensuite poursuivi avec la présentation du Google Summer of Code 2010 de Debian : une présentation générale puis plusieurs “étudiants” expliquent leur projet en cours : Debian-Installer pour OpenMoko, GUI pour aptitude en QT, etc. D’autres présentations ont ensuite suivies, mais j’ai plutôt été découvrir le “hacklab” : une pièce pourvue de multiprises, switches et points d’accès afin de permettre à plusieurs dizaines de personnes de travailler/hacker. Le “Debian Day” a été un franc succès avec plusieurs centaines de participants. En soirée, c’est l’heure du coup d’envoi “officiel” de la DebConf par Gabriella Coleman, l’une des organisatrices de la DebConf 10, qui présente avec humour la semaine à venir, avec un petit retour en images sur les éditions précédentes.

Deuxième jour, on a le droit à un Bits from DPL en direct de la part de Stefano Zacchiroli (au lieu du traditionnel mail). Ensuite, il y a de nombreuses présentations. Durant DebConf, il y en aura plus de 100 au total, réparties dans 3 salles : Davis (avec vidéo), 414 Schapiro et Interschool (avec vidéo). Le choix est parfois difficile ! Pour ma part, j’ai assisté en fin de matinée à la présentation de la structure américaine à but non lucractif SPI : c’est elle qui gère les droits de la marque Debian, mais pas seulement : OpenOffice.org, Drupal, PostgreSQL, Alfresco, etc. de nombreux projets de logiciels libres utilisent cette structure légale ! Dans l’après-midi, c’est Mark Shuttleworth, fondateur d’Ubuntu et CEO de Canonical, qui nous présente le travail réalisé pour améliorer l’interface graphique des netbooks, notamment par l’intermédiaire du projet Ayatana. Puis, Jorge Castro, responsable chez Canonical des relations avec les développeurs extérieurs, parle de la collaboration entre Ubuntu et Debian. On notera que toute une équipe de Canonical est venue à DebConf et que les relations avec Debian semblent devenir plus sereines. Le soir venu, c’est l’heure de Wine&Cheese, un évènement devenu incontournable pour une DebConf : imaginez des centaines de fromages et alcools venus du monde entier (Italie, Allemagne, France, Mexique, Brésil, USA, Taïwan, Pologne, Kazhastan, Espagne, Nouvelle-Zélande, Corse, Vénézuela, Hollande, Marseille, Irlande, Angleterre, Japon, etc. etc.) et plus d’une centaine de développeurs Debian lâchés dessus pendant des heures… le résultat est… indescriptible ! Pour ma part, j’avais apporté un rosé Bandol, des bières La Cagole, du Banon et de la Tapenade… qui n’ont pas fait long feu.

Troisième jour et l’on débute par un talk d’Eben Moglen, avocat de la FSF, qui rappelle les dangers du Cloud Computing comme la gestion des données privées. Sa réponse : “Chacun devrait avoir un serveur chez soi” et il évoque la FreedomBox, une boi-boîte que tout le monde aurait chez soi pour faire office de petit serveur avec les fonctionnalités classiques (web, messagerie, VoIP). Cette idée rencontre un certain enthousiasme et plusieurs réfléchissent déjà à la réalisation de cette idée ! J’ai ensuite suivi une succession de présentations sur le thème de l’entreprise. On a parlé du déploiement de machines avec le logiciel Puppet, de l’installation automatisée de Debian avec FAI et Gosa, notamment présentée par Mickaël Bank, un développeur allemand très actif dans Debian. On a également des témoignages très intéressants : Russ Allbery, administrateur système et réseau à l’université de Standford en Californie, explique quels sont les arguments en faveur de Debian en entreprise et en profite pour présenter la gestion de Debian à Standford ; Faidon Liambotis, sysadmin chez GRNET (un opérateur public grec), présente leur utilisation de Debian mais aussi leurs choix en terme de déploiement (Puppet/FAI) ou de virtualisation (KVM/Ganeti). Pour terminer la journée, Guido Trotter de chez Google, nous parle des fonctionnalités réseau intéressantes sous Linux (VLAN, tunnels, routing, etc.). Une journée riche en idées et en informations ! En soirée, nous avons visualisé le film Open Source Sita Sings the Blues et Nina Paley nous a expliqué son choix d’une licence libre pour son film.

Le quatrième jour, c’est le Day Trip. Il s’agit classiquement d’une journée consacrée à des activités touristiques extérieures. Nous avons été visiter l’église Trinity Church à Manhattan où le drame du 11 septembre 2001 a mis un superbe orgue hors d’usage, remplacé temporairement par un orgue électronique “Powered by Linux”… qui a finalement été conservé en raison de sa qualité. Keith Packard, l’un des gourous de X.org employé chez Intel, a joué quelques minutes sur cet orgue. Ensuite, direction la plage de Coney Island. Puis un match de baseball où Stefano Zacchiroli lancera la première balle du match.

Cinquième jour, on reprend avec un BoF (un BoF=Birds of a Feather est une discussion informelle de groupe) sur la virtualisation où plusieurs personnes témoignent de leurs expériences et connaissances sur le sujet. Pas mal d’informations intéressantes, notamment sur le couple Ganeti/KVM pas mal mis en avant par Iustin Pop, l’un des développeurs de Ganeti employé chez Google. J’y apprends notamment que KVM gère une notion de mémoire partagée et ainsi démarrer une 2e machine virtuelle avec un même OS ne consommerait pas de mémoire supplémentaire sur le système hôte ! Suite des présentations, notamment une portant sur DebConf 12 qui pourrait peut-être se dérouler au Brésil. Et fin de la matinée avec François Marier qui présente le projet Libravatar permettant d’offrir une alternative à Gravatar, l’outil centralisé de gestion des avatars. Ses idées sont de se baser sur les DNS pour répartir les avatars pour chaque noms de domaine. Il a déjà commencé à développer une application en Django pour gérer cela. Suite de la journée avec un BoF sur Lintian (outil de vérification de la conformité des packages Debian) géré par Russ Allbery. Puis j’ai assisté à une présentation de Guido Günther qui a expliqué comment gérer son packaging avec Git et notamment git-buildpackage (très intéressant pour moi car je gère déjà mes packages Debian comme ça). Ensuite, petite pause sportive, car une dizaine de développeurs Debian a été participé à un cross de 5 kms dans le Bronx, avec des résultats honorables !

Sixième jour, on débute par Bits from Release Team qui déclare en direct que Squeeze, la prochaine version stable, est désormais freezée ! Un scoop à DebConf ! C’est ensuite Stefano Zacchiroli qui nous présente son travail en cours sur une amélioration de la gestion des dépendances, non seulement pour Debian mais aussi pour les autres distributions : plus de détails sur le site du projet Mancoosi. C’est ensuite la traditionnelle photo de groupe. En début d’après-midi, Margarita Manterola dresse un constat très lucide de l’état de Debian avec son talk Making Debian Rule, again. Puis en fin d’après-midi, c’est un BoF très apprécié mené par Joey Hess sur CUT (Constantly Usable Testing) qui explore les possibilités d’avoir une distribution Testing utilisable en permanence ! Le soir venu, c’est un BoF sur l’utilisation d’OpenPGP et la classique Keysigning Party qui a regroupé plusieurs dizaines de participants.

Septième et dernier jour, encore de nombreuses présentations. J’ai notamment assisté à celle de Philippe Kern, membre de la Release Team, qui a parlé du management de la version stable et de volatile. On notera par exemple qu’on peut désormais corriger des bugs en priorité “Important” dans les points de Release. La suite ce sont des fameux Lightnings Talks, une dizaine de présentations très courtes : une qui suggère d’arrêter complètement d’utiliser les mots de passe, une autre sur le logiciel runit, une autre sur les éclairs (lightnings !) ou encore l’historique en photos des Wine&Cheese Party ! Fun et instructif. Puis c’est l’heure de la conférence de clôture, où l’on remet des prix à ceux qui ont corrigé le plus de bugs mais surtout tous les volontaires sont vivement remerciés et j’en profite pour adresser une nouvelle fois mes remerciements à :
– L’équipe qui a organisé cette DebConf 10 : un travail impressionnant pour un résultat professionnel et communautaire à la fois : on frôle la perfection !
– L’équipe vidéo qui a fait un travail génial et vous pouvez ainsi retrouver l’ensemble des talks en vidéo,
– Les centaines de personnes sympas et passionnées qui contribuent à faire de Debian une distribution de grande qualité… et qui sait évoluer, la preuve avec les sujets abordés lors de cette DebConf !

Petite conclusion de cette semaine intensive, comme vous avez pu le lire : j’ai pu acquérir de nombreuses informations et faire le plein de nouvelles idées, mais aussi avoir des contacts réels avec d’autres développeurs et comprendre encore mieux le fonctionnement “social” de Debian. C’est donc très positif et cela va me permettre d’améliorer mon travail quotidien au sein d’Evolix, mais aussi réfléchir à d’autres projets et me motiver pour contribuer davantage à Debian. Debian rules !

18 August, 2010 11:52AM by Gregory Colpart