12 October 2014

Raphaël Hertzog

Mes activités libres en septembre 2014

Voici le récapitulatif mensuel de toutes mes activités gravitant autour du logiciel libre. Si vous faites partie des personnes ayant fait un don pour soutenir mon travail (26,6 €, merci à tous !), c’est l’occasion de constater ce que je fais de votre argent. Sinon, c’est toujours quelques nouvelles intéressantes sur l’avancement de mes différents projets.

Django 1.7

Depuis que la version 1.7 de Django a été publiée début septembre dernier, j’ai mis à jour le paquet dans le dépôt experimental et continué de pousser pour son inclusion dans unstable. J’ai également envoyé quelques patchs supplémentaires concernant plusieurs dépendances inverses de compilation (python-django-bootstrap-form, horizon, lava-server), puis envoyé le paquet dans unstable. J’ai augmenté à ce moment la criticité de tous les rapports de bogue enregistrés pour des paquets qui ne compilaient alors plus avec Django 1.7.

Plus tard dans le mois, je me suis assuré de la migration du paquet vers testing, qui n’a requis qu’une suppression temporaire de mumble-django (cf. le rapport n°763087). Pas mal de paquets ont été mis à jour depuis (vous pourrez trouver les bogues restants par ici).

Support Debian à long terme

J’ai travaillé à garder Debian Squeeze sûre, cf. l’article qui y est dédié : Mon rapport Debian LTS pour septembre 2014.

Distro Tracker

Le rythme de développement de tracker.debian.org s’est ralenti légèrement ce mois-ci, avec seulement 30 nouveaux commits dans le dépôt, fermant 6 rapports de bogue. Certaines des modifications méritent néanmoins d’être citées : les nouvelles contiennent maintenant de vrais hyperliens vers les rapports de bogue, CVE et URL (en voici un exemple). J’ai également corrigé un problème important concernant la manière dont les utilisateurs étaient identifiés lorsqu’ils utilisaient leurs identifiants de compte Alioth pour s’authentifier via sso.debian.org.

Côté développement, nous sommes maintenant capables de calculer la couverture du code testé par la suite de tests, ce qui est plutôt utile pour identifier les pans de code manquant clairement de tests (cf. bin/gen-coverage.sh dans le dépôt).

Empaquetage divers

Publican. J’ai suivi l’empaquetage des nouvelles versions amont de Publican et, la période de gel approchant, j’ai décidé de m’en occuper. Ça n’a malheureusement pas été aussi simple qu’escompté, car j’ai découvert de nombreux problèmes que j’ai remontés à l’amont (identifiant public invalide, échec de la compilation PDF pour cause de fonction noNumberLines non-disponible, la compilation du manuel requiert une connexion réseau). La plupart de ces derniers ont été corrigés en amont dans l’intervalle, mais le dernier semble provenir de la manière dont nous gérons nos catalogues Docbook XML au sein de Debian. J’ai en conséquence créé le rapport de bogue n°763598 (docbook-xml: xmllint échoue à identifier une copie locale du fichier des entités Docbook), qui reste sans réponse de la part du mainteneur.

Parrainage de paquet. J’ai « sponsorisé » les nouveaux envois de dolibarr (correction d’un bug critique pour la publication), tcpdf (correction d’un bug critique pour la publication), tryton-server (mise à jour de sécurité) et django-ratelimit.

GNOME 3.14. Avec l’arrivée de GNOME 3.14 dans unstable, je me suis occupé de la mise à jour de gnome-shell-timer et j’ai également créé quelques tickets pour des extensions que j’utilise : https://github.com/projecthamster/shell-extension/issues/79 et https://github.com/olebowle/gnome-shell-timer/issues/25.

git-buildpackage. J’ai rapporté de nombreux bogues de git-buildpackage m’ayant affecté depuis que j’ai commencé à utiliser cet outil : n°761160 (gbp pq export/switch devrait être plus intelligent), n°761161 (gbp pq import/export devraient préserver les noms de fichier des patchs), n°761641 (gbp import-orig devrait être moins fragile et plus idempotent).

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 September 2014 contribuée par Weierstrass01.

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

12 October, 2014 08:47PM par Raphaël Hertzog

Mon rapport Debian LTS de septembre 2014

Grâce au soutien de nombreuses sociétés, j’ai été payé pour travailler (au moins) 11h sur Debian LTS ce mois-ci.

J’ai commencé par opérer un tri important dans le systèm de suivi des alertes sécurité (si vous souhaitez aider, les instructions se trouvent ici), car j’ai remarqué que la liste dla-needed.txt (qui contient la liste des paquets nécessitant une mise à jour de sécurité pour Debian Squeeze LTS) ne contenait pas un certain nombre de paquets qui pourtant avaient des vulnérabilités connues dans oldstable.

J’ai poussé in fine 23 commits dans le dépôt subversion de suivi des alertes sécurité. Je n’en présenterai pas le détail tout le temps mais, pour une fois, il est intéressant que vous puissiez vous faire une idée du travail que cela représente :

  • J’ai passé en revue les patchs des vulnérabilités CVE-2014-0231, CVE-2014-0226, CVE-2014-0118 et CVE-2013-5704, et j’ai confirmé que toutes affectaient la version d’apache2 présente dans Squeeze. J’ai ajouté par la suite apache2 au fichier dla-needed.txt.
  • J’ai passé en revue la vulnérabilité CVE-2014-6610 concernant asterisk et j’ai marqué la version présente dans Squeeze comme non affectée, dans la mesure où le fichier présentant la faille n’existe pas dans cette version (ce qui a nécessité d’inspecter d’autres fichiers à la recherche de cette fonctionnalité particulière, qui aurait pu y être déplacée à la faveur d’une réorganisation des fichiers ou de modifications internes similaires).
  • J’ai passé en revue la vulnérabilité CVE-2014-3596 (Apache Axis) et j’ai corrigé l’entrée mentionnant sa correction dans unstable. J’ai confirmé qu’elle affectait la version présente dans Squeeze, et l’ai ajouté au fichier dla-needed.txt.
  • Même chose pour la vulnérabilité CVE-2012-6153 affectant commons-httpclient.
  • J’ai passé en revue la vulnérabilité CVE-2012-5351 et ajouté un lien vers le ticket amont.
  • J’ai passé en revue les vulnérabilités CVE-2014-4946 et CVE-2014-4945 concernant php-horde-imp/horde3, ajouté des liens vers les patchs amont et marqué les versions présentes dans Squeeze comme non affectées, dans la mesure où ces failles proviennent de fichiers javascript absents de ces versions.
  • J’ai passé en revue la vulnérabilité CVE-2012-3155 affectant glassfish et fus vraiment ennuyé par le manque d’informations la concernant. J’ai donc commencé une discussion sur la liste debian-lts pour voir si ce paquet ne devait pas être marqué comme non supporté pour les mises à jour de sécurité. Il semble que nous n’allons marquer qu’un seul binaire comme non supporté… celui contenant le serveur d’applications touché par les vulnérabilités, le reste étant toujours requis pour compiler de nombreux paquets java.
  • J’ai passé en revue de nombreuses vulnérabilités CVE affectant dbus, drupal6, eglibc, kde4libs, libplack-perl, mysql-5.1, ppp, squid et fckeditor, et ajouté ces paquets au fichier dla-needed.txt.
  • J’ai passé en revue les vulnérabilités CVE-2011-5244 et CVE-2011-0433 affectant evince et suis parvenu à la conclusion que ces dernières avaient déjà été corrigées dans la version 2.30.3-2+squeeze1. Je les ai donc marquées comme corrigées.
  • J’ai supprimé graphicsmagick de la liste de dla-needed.txt car la seule vulnérabilité CVE l’affectant a été marquée comme no-dsa (ce qui signifie que nous estimons qu’une mise à jour de sécurité n’est pas requise, habituellement parce que le problème est mineur et/ou que sa correction aurait plus de chances d’introduire des régressions que d’aider).
  • J’ai créé quelques rapports de bogues lorsque ceux-ci étaient manquants : n°762789 concernant ppp, n°762444 concernant axis.
  • J’ai marqué un grand nombre de vulnérabilités CVE affectant qemu-kvm et xen comme « en fin de vie » dans Squeeze, puisque ces paquets ne sont actuellement plus supportés dans Debian LTS.
  • J’ai passé en revue la vulnérabilité CVE-2012-3541 et, dans la mesure où le rapport entier n’est pas très clair, j’ai envoyé un email à l’auteur amont. Cette discussion m’a conduit à marquer ce bogue comme no-dsa, car l’impact semble être limité à une divulgation d’informations uniquement. J’ai invité l’auteur amont à continuer cette discussion directement dans le ticket du bugzilla de RedHat.

Et lorsque je dis « passé en revue », c’est un raccourci derrière lequel le processus suivant se cache :

  • Recherche d’une explication claire de la vulnérabilité, d’une liste des versions affectées, et des patchs pour les versions que nous avons dans Debian, aux endroits suivants:
    • La page Debian de suivi des vulnérabilités CVE.
    • L’entrée associée dans le système de suivi des bogues Debian (s’il y en a un).
    • La description de la vulnérabilité CVE sur cve.mitre.org, et les pages qui y sont référencées.
    • L’entrée du bugzilla de RedHat pour la vulnérabilité CVE (ce qui implique souvent le téléchargement du RPM source depuis CentOS, afin d’extraire le patch qu’ils ont utilisé).
    • Le dépôt git amont et parfois certaines pages dédiées à la sécurité sur le site web amont.
  • Lorsque cela n’a pas été suffisant pour les versions que nous avons dans Debian (et c’est malheureusement souvent le cas), cela passe par le téléchargement du paquet source Debian et la recherche dans les sources des anciennes versions du code problématique (en partant de l’hypothèse qu’on peut l’identifier depuis le patch dont on dispose pour les versions plus récentes).

Le tri des vulnérabilités CVE représente presque la moitié du processus en général : une fois que vous savez que vous êtes affectés et que vous disposez d’un patch, le chemin vers la publication d’une mise à jour est relativement simple (parfois cela requiert quand même un travail de rétroportage du patch).

Lorsque j’en ai eu fini avec la première passe de triage, j’avais déjà dépassé les 11 heures payées mais je me suis occupé de préparer la mise à jour de sécurité pour python-django. Thorsten Alteholz avait commencé le travail mais s’est retrouvé bloqué à l’étape du rétroportage des patchs. Comme je suis co-mainteneur du paquet, j’ai pris le relai et fini le travail, pour le publier sous la référence DLA-65-1.

Ceci est une traduction de mon article My Debian LTS report for September contribuée par Weierstrass01.

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

12 October, 2014 08:40PM par Raphaël Hertzog

24 September 2014

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

23 September 2014

Debian France

BSP (chasse aux bugs) à Paris

BSP à Paris

A la mi-novembre 2014, du 14 au 16, une Bug Squashing Party (BSP ou Hackathon) est organisée dans les locaux de Mozilla à Paris.

Le principe d'une BSP est de réunir des contributeurs Debian avec comme objectif de clôturer autant de bugs que possible dans Debian.

Cet évènement est aussi l'occasion pour des contributeurs potentiels d'échanger avec des Debian Developers ou Maintainers. En effet, de nombreux contributeurs réguliers seront présents et pourront guider les moins expérimentés pour corriger leurs premiers bugs.

Pour des questions d'organisation, une inscription sur le wiki Debian ou Meetup.com est nécessaire.

Inscriptions:

23 September, 2014 10:30AM

12 September 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 par ascendances

10 September 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 par Olivier Berger

20 August 2014

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 par 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.
<iframe allowfullscreen="allowfullscreen" frameborder="0" height="315" src="http://www.youtube.com/embed/sXZ3KGK5TCU?rel=0" width="420"></iframe>

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 par Olivier Berger

15 August 2014

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 par aurel32

15 July 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 par ascendances

05 May 2014

Vincent Bernat

Dashkiosk: gestion d'écrans pour tableaux de bord

Dashkiosk est une solution permettant de gérer de manière centralisée l’affichage de tableaux de bord sur plusieurs écrans. Il comprend quatre parties :

  1. Une partie serveur va piloter les écrans en leur envoyant les URL à afficher. Une interface web permet de configurer des groupes de tableaux de bord et de les associer à un ensemble d’écrans.

  2. Un récepteur tourne sur chaque écran dans un navigateur web. Au démarrage, il contacte le serveur et attend l’URL à afficher.

  3. Une application Android fournit un navigateur en plein écran pour faire tourner le récepteur.

  4. Une application Chromecast joue le même rôle mais pour les clefs Google Chromecast. Le serveur est capable de piloter ces dernières à l’aide de nodecastor, une réimplementation de l’API de pilotage.

La vidéo ci-dessous démontre les capacités de Dashkiosk en quelques minutes. Elle est aussi disponible au format Ogg Theora.

<iframe frameborder="0" height="270" src="http://www.dailymotion.com/embed/video/x1sy4x7" width="480"></iframe>

05 May, 2014 06:39PM par Vincent Bernat

27 April 2014

Vincent Bernat

Dépôts APT locaux en entreprise

Distribuer de manière efficace des logiciels sur l’ensemble d’une plateforme peut être ardu. Chaque distribution fournit un gestionnaire de paquets qui est généralement bien adapté à cette tâche. Dans le cas de Debian ou d’une distribution dérivée, il s’agit d’APT.

Certains logiciels ne sont pas présent dans les dépôts officiels ou peuvent être disponibles dans une version trop ancienne. La mise en place d’un dépôt local permet de contourner cet écueil.

Ce qui est présenté ici a été mis en place pour Dailymotion et a été fortement inspiré du travail de Raphaël Pinson chez Orange.

Configuration des dépôts locaux

Les dépôts à mettre en place peuvent se classer dans trois catégories :

  1. Les miroirs de distributions. Ils permettent d’économiser de la bande passante, d’obtenir un meilleur débit et un accès permanent même lorsque l’accès à Internet est perturbé.

  2. Les dépôts maisons pour vos propres paquets avec la possibilité de passer par une zone de test pour valider les paquets sur quelques machines avant de les pousser en production.

  3. Les miroirs pour les dépôts non officiels, tels que des PPA Ubuntu. Pour éviter tout changement inattendu, de tels dépôts sont aussi dôtés d’une zone de test et d’une zone de production.

Avant de continuer, il est important de s’accorder sur la terminologie à employer. Examinons une ligne issue de mon /etc/apt/sources.list:

deb http://ftp.debian.org/debian/ unstable main contrib non-free

Dans cet exemple, http://ftp.debian.org/debian/ est un dépôt et unstable est une distribution. Une distribution est divisée en un certain nombre de composants. Nous en avons ici trois : main, contrib et non-free.

La mise en place des différents dépôts se fera avec le logiciel reprepro. Ce n’est pas la seule solution disponible mais il est à la fois plutôt versatile et simple à mettre en place. reprepro ne gère qu’un seul dépôt. Le premier choix à effectuer est donc de savoir comment répartir les paquets dans les dépôts, les distributions et les composants.

Voici quelques billes pour choisir :

  • Un dépôt ne peut pas contenir deux paquets identiques (même nom, même version, même architecture).
  • À l’intérieur d’un composant, il n’est possible d’avoir qu’une seule version d’un paquet.
  • Habituellement, une distribution est un sous-ensemble des versions tandis qu’un composant est un sous-ensemble des paquets. Par exemple, dans Debian, la distribution unstable permet d’obtenir des paquets dans des versions très récentes tandis que le composant main permet de se limiter aux paquets respectant la DFSG.

En partant sur plusieurs dépôts, il faudra gérer plusieurs instances de reprepro et la copie entre deux instances se fait manuellement. À Dailymotion, nous sommes partis sur un seul dépôt, mais il aurait été possible de partir sur trois dépôts :

  • un pour les miroirs de distributions,
  • un pour les paquets maisons,
  • un pour les miroirs de dépôts tiers.

Voici ce que nous allons mettre en place :

Local APT repository

Mise en place

La première étape est de créer un utilisateur pour travailler sur les dépôts :

$ adduser --system --disabled-password --disabled-login \
>         --home /srv/packages \
>         --group reprepro

Toutes les opérations qui suivent doivent utiliser exclusivement cet utilisateur. Chaque dépôt aura son propre répertoire dans lequel on trouvera les sous-répertoires suivants :

  • conf/ qui contient les fichiers de configuration,
  • gpg/ qui contient les fichiers permettant de signer et authentifier les dépôts avec GPG1,
  • logs/ qui contient les journaux,
  • www/ qui contient les fichiers du dépôt à rendre visible par un quelconque server web.

Voici le contenu de conf/options :

outdir +b/www
logdir +b/logs
gnupghome +b/gpg

Créons la clef GPG pour signer le dépôt :

$ GNUPGHOME=gpg gpg --gen-key
Please select what kind of key you want:
   (1) RSA and RSA (default)
   (2) DSA and Elgamal
   (3) DSA (sign only)
   (4) RSA (sign only)
Your selection? 1
RSA keys may be between 1024 and 4096 bits long.
What keysize do you want? (2048) 4096
Requested keysize is 4096 bits
Please specify how long the key should be valid.
         0 = key does not expire
      <n>  = key expires in n days
      <n>w = key expires in n weeks
      <n>m = key expires in n months
      <n>y = key expires in n years
Key is valid for? (0) 10y
Key expires at mer. 08 nov. 2023 22:30:58 CET
Is this correct? (y/N) y

Real name: Dailymotion Archive Automatic Signing Key
Email address: the-it-operations@dailymotion.com
Comment: 
[...]

Un mot de passe vide permet à reprepro de tourner sans intervention de l’utilisateur (notamment pour les mises à jour nocturnes). La clef publique devra être distribuée pour permettre à APT de vérifier les signatures de l’archive. Une façon commode de faire est de la placer dans un paquet.

Miroir local d’une distribution officielle

Commençons par mettre en place un miroir pour Ubuntu Precise. Nous avons besoin de faire deux choses :

  1. Configurer une nouvelle distribution dans le fichier conf/distributions.
  2. Configurer les sources dans le fichier conf/updates.

Ajoutons ce bloc dans conf/distributions:

# Ubuntu Precise
Origin: Ubuntu
Label: Ubuntu
Suite: precise
Version: 12.04
Codename: precise
Architectures: i386 amd64
Components: main restricted universe multiverse
UDebComponents: main restricted universe multiverse
Description: Ubuntu Precise 12.04 (with updates and security)
Contents: .gz .bz2
UDebIndices: Packages Release . .gz
Tracking: minimal
Update: - ubuntu-precise ubuntu-precise-updates ubuntu-precise-security
SignWith: yes

Il définit la distribution precise dans notre dépôt. Elle contient quatre composants : main, restricted, universe et multiverse (comme la distribution présente dans les dépôts officiels).

La ligne Update commence par un tiret. Cela signifie que reprepro va marquer tous les paquets comme à effacer avant d’appliquer les mises à jour indiquées. Les paquets supprimés de la distribution officielle ne seront donc pas conservés dans notre miroir. Dans conf/updates, nous définissons les sources :

# Ubuntu Precise
Name: ubuntu-precise
Method: http://fr.archive.ubuntu.com/ubuntu
Fallback: http://de.archive.ubuntu.com/ubuntu
Suite: precise
Components: main main multiverse restricted universe
UDebComponents: main restricted universe multiverse
Architectures: amd64 i386
VerifyRelease: 437D05B5
GetInRelease: no

# Ubuntu Precise Updates
Name: ubuntu-precise-updates
Method: http://fr.archive.ubuntu.com/ubuntu
Fallback: http://de.archive.ubuntu.com/ubuntu
Suite: precise-updates
Components: main restricted universe multiverse
UDebComponents: main restricted universe multiverse
Architectures: amd64 i386
VerifyRelease: 437D05B5
GetInRelease: no

# Ubuntu Precise Security
Name: ubuntu-precise-security
Method: http://fr.archive.ubuntu.com/ubuntu
Fallback: http://de.archive.ubuntu.com/ubuntu
Suite: precise-security
Components: main restricted universe multiverse
UDebComponents: main restricted universe multiverse
Architectures: amd64 i386
VerifyRelease: 437D05B5
GetInRelease: no

Les lignes VerifyRelease indiquent les empreintes des clefs GPG à utiliser pour vérifier la signature des dépôts distants. Il faut importer la clef en question dans l’anneau local :

$ gpg --keyring /usr/share/keyrings/ubuntu-archive-keyring.gpg \
>     --export 437D05B5 | GNUPGHOME=gpg gpg --import

Un autre point important est le fait que nous avons fusionné trois distributions (precise, precise-updates et precise-security) dans une seule distribution (precise) dans notre dépôt local. Cela peut provoquer des difficultés avec les outils, tels que le Debian Installer2, qui s’attendent à trouver les trois distributions classiques.

Il est ensuite possible de lancer reprepro pour mettre à jour le miroir :

$ reprepro update

Cela prend un certain temps la première fois. reprepro n’est pas la solution la plus efficace pour mettre en place un miroir, mais sa prise en main est simple et il est particulièrement fiable.

Dépôt maison

Passons au dépôt pour les paquets maisons. Pour chaque distribution officielle (telle que precise), nous mettons en place deux distributions :

  • precise-staging contient les paquets en cours de test.
  • precise-prod contient les paquets testés issus de precise-staging.

Dans cette organisation, les paquets sont introduits dans precise-staging où ils peuvent être testés sur quelques serveurs avant d’être copiés dans precise-prod pour être disponible sur l’ensemble de la plateforme. La déclaration dans conf/distributions se fait ainsi :

# Dailymotion Precise packages (staging)
Origin: Dailymotion # ➌
Label: dm-staging   # ➌
Suite: precise-staging
Codename: precise-staging
Architectures: i386 amd64 source
Components: main role/dns role/database role/web # ➊
Description: Dailymotion Precise staging repository
Contents: .gz .bz2
Tracking: keep
SignWith: yes
NotAutomatic: yes # ➋
Log: packages.dm-precise-staging.log
 --type=dsc email-changes

# Dailymotion Precise packages (prod)
Origin: Dailymotion # ➌
Label: dm-prod      # ➌
Suite: precise-prod
Codename: precise-prod
Architectures: i386 amd64 source
Components: main role/dns role/database role/web # ➊
Description: Dailymotion Precise prod repository
Contents: .gz .bz2
Tracking: keep
SignWith: yes
Log: packages.dm-precise-prod.log

Notez d’abord l’utilisation de plusieurs composants (en ➊) :

  • main contiendra les paquets génériques. Un paquet placé dans main doit pouvoir être utilisé sur n’importe quel serveur.
  • role/* sont des composants dédiés à un sous-ensemble de la plateforme. Par exemple, dans role/dns, on trouvera des versions modifiées de BIND.

La distribution de test utilise le drapeau NotAutomatic (en ➋) qui indique au gestionnaire de paquets de ne pas installer ces paquets à moins d’une requête expresse de l’utilisateur. Juste au-dessous, quand un nouveau fichier dsc est reçu, le script email-changes est exécuté. Il doit se trouver dans le répertoire conf/.

Les lignes Origin et Label (en ➌) sont particulièrement importants car elles seront utilisées pour déterminer la politique d’installation des paquets. Prenons ce fichier /etc/apt/sources.list :

# Ubuntu packages
deb http://packages.dm.gg/dailymotion precise main restricted universe multiverse

# Dailymotion packages
deb http://packages.dm.gg/dailymotion precise-prod    main role/dns
deb http://packages.dm.gg/dailymotion precise-staging main role/dns

Tous les serveurs peuvent utiliser la distribution precise-staging. Il est essentiel de ne pas installer par erreur des paquets de cette distribution. Le drapeau NotAutomatic est une première sécurité. Nous y ajoutons ce fichier /etc/apt/preferences :

Explanation: Dailymotion packages of a specific component should be more preferred
Package: *
Pin: release o=Dailymotion, l=dm-prod, c=role/*
Pin-Priority: 950

Explanation: Dailymotion packages should be preferred
Package: *
Pin: release o=Dailymotion, l=dm-prod
Pin-Priority: 900

Explanation: staging should never be preferred
Package: *
Pin: release o=Dailymotion, l=dm-staging
Pin-Priority: -100

Par défaut, les paquets ont une priorité de 500. En utilisant une priorité de -100 pour les paquets en provenance de la distribution de test, nous nous assurons qu’ils ne peuvent pas être installés du tout. C’est une contrainte plus forte que l’utilisation de NotAutomatic qui place la priorité à 1. Nous favorisons les paquets se trouvant dans le dépôt maison par rapport aux paquets officiels en leur affectant une priorité de 900 (voire 950 pour les paquets qui se trouvent dans un composant type rôle).

La section “How APT Interprets Priorities” de la page de manuel apt_preferences(5) donne plus de détails. Il faut garder en tête que les versions ne sont utilisées qu’à priorité égale. La commande apt-cache policy permet de vérifier que tout fonctionne comme attendu :

$ apt-cache policy php5-memcache
  Installed: 3.0.8-1~precise2~dm1
  Candidate: 3.0.8-1~precise2~dm1
  Version table:
 *** 3.0.8-1~precise2~dm1 0
        950 http://packages.dm.gg/dailymotion/ precise-prod/role/web amd64 Packages
        100 /var/lib/dpkg/status
     3.0.8-1~precise1~dm4 0
        900 http://packages.dm.gg/dailymotion/ precise-prod/main amd64 Packages
       -100 http://packages.dm.gg/dailymotion/ precise-staging/main amd64 Packages
     3.0.6-1 0
        500 http://packages.dm.gg/dailymotion/ precise/universe amd64 Packages

Pour installer un paquet en provenance de la distribution de test, il suffit d’invoquer apt-get avec l’option -t precise-staging qui augmente la priorité de cette distribution à 990.

Une fois le paquet testé sur quelques serveurs, il est possible de le copier vers la distribution de production :

$ reprepro -C main copysrc precise-prod precise-staging wackadoodle

Miroir local de dépôts tiers.

Parfois, plutôt que de reconstruire un paquet, il est préférable de le prendre directement sur un dépôt tiers. Un exemple courant est les dépôts mis en place par les constructeurs. Comme pour la mise en place d’un miroir d’une distribution officielle, il y a deux étapes : définition de la distribution et déclaration des sources.

Chaque miroir va se trouver dans les mêmes distributions que nos paquets maisons mais ils iront dans un composant dédié. Cela nous permet d’utiliser la même organisation que pour les paquets locaux : ils apparaîtront dans la distribution de test avant d’être manuellement copiés, après validation, dans la distribution de production.

La première étape consiste à àjouter le composant et la ligne Update appropriée dans le fichier conf/distributions :

Origin: Dailymotion
Label: dm-staging
Suite: precise-staging
Components: main role/dns role/database role/web vendor/hp
Update: hp
# [...]

Origin: Dailymotion
Label: dm-prod
Suite: precise-prod
Components: main role/dns role/database role/web vendor/hp
# [...]

Le composant vendor/hp a été ajouté aux deux distributions mais seule la distribution de test a une ligne Update. La distribution de production obtiendra les paquets par copie manuelle.

La source des paquets est déclarée dans le fichier conf/updates :

# HP repository
Name: hp
Method: http://downloads.linux.hp.com/SDR/downloads/ManagementComponentPack/
Suite: precise/current
Components: non-free>vendor/hp
Architectures: i386 amd64
VerifyRelease: 2689B887
GetInRelease: no

N’oubliez pas de rajouter la clef GPG correspondante dans l’anneau local. À noter une fonctionnalité particulièrement intéressante de reprepro qui permet de copier le composant non-free dans le composant vendor/hp.

Construction des paquets Debian

La configuration de reprepro est désormais terminée. Comment construire les paquets à placer dans la distribution de test ?

Selon le temps que vous souhaitez accorder à cette activité, il y a plusieurs possibilités :

  1. Construire un paquet source en ajoutant un répertoire debian/. C’est la façon classique. Il est possible de partir de zéro ou de prendre un paquet existant dans une distribution plus récente ou un rétroportage d’un dépôt non officiel.

  2. Utiliser un outil qui va créer un paquet binaire à partir d’un répertoire, tel que fpm. Un tel outil va minimiser le boulot à effectuer pour construire un paquet et peut même empaqueter automatiquement certains types de logiciels.

Il n’y a pas de solution universelle. La première approche est plus chronophage mais dispose des avantages suivants :

  • Les sources restent disponibles dans le dépôt. Si vous avez besoin de reconstruire un paquet en urgence pour corriger un problème, il n’est pas nécessaire de partir a la recherche des sources qui peuvent être temporairement indisponibles. Bien sûr, cela n’est valable que pour les paquets qui ne téléchargent pas les dépendances depuis Internet.

  • La recette de construction est conservée3 dans le dépôt. Si quelqu’un active telle option et reconstruit le paquet, cette option ne sera perdue lorsqu’un autre personne reconstruira le paquet. Ces changements sont documentés dans le fichier debian/changelog. De plus, un système de gestion des versions peut être utilisé pour garder une trace précise des changements liés à l’empaquetage.

  • Le paquet obtenu peut ensuite être proposé à l’inclusion dans Debian. Cela rendra service à de nombreuses autres personnes.

Compilation

pbuilder est utilisé pour la compilation automatique des paquets4. Sa mise en place est relativement simple. Voici le fichier pbuilderrc utilisé :

DISTRIBUTION=$DIST
NAME="$DIST-$ARCH"
MIRRORSITE=http://packages.dm.gg/dailymotion
COMPONENTS=("main" "restricted" "universe" "multiverse")
OTHERMIRROR="deb http://packages.dm.gg/dailymotion ${DIST}-staging main"
HOOKDIR=/etc/pbuilder/hooks.d
BASE=/var/cache/pbuilder/dailymotion
BASETGZ=$BASE/$NAME/base.tgz
BUILDRESULT=$BASE/$NAME/results/
APTCACHE=$BASE/$NAME/aptcache/
DEBBUILDOPTS="-sa"
KEYRING="/usr/share/keyrings/dailymotion-archive.keyring.gpg"
DEBOOTSTRAPOPTS=("--arch" "$ARCH" "--variant=buildd" "${DEBOOTSTRAPOPTS[@]}" "--keyring=$KEYRING")
APTKEYRINGS=("$KEYRING")
EXTRAPACKAGES=("dailymotion-archive-keyring")

pbuilder doit être invoqué avec les variables d’environnement DIST, ARCH et (optionnellement) ROLE. La mise en place de chaque environnement s’effectue ainsi :

for ARCH in i386 amd64; do
  for DIST in precise; do
    export ARCH
    export DIST
    pbuilder --create
  done
done

Concernant les rôles, un crochet de type D permet d’ajouter les sources appropriées avant la compilation :

#!/bin/bash
[ -z "$ROLE" ] || {
  cat >> /etc/apt/sources.list <<EOF
deb http://packages.dm.gg/dailymotion ${DIST}-staging role/${ROLE}
EOF
}

apt-get update

Un crochet de type E permet de s’assurer que les paquets de la distribution de test sont prioritairement utilisés pour la construction :

#!/bin/bash

cat > /etc/apt/preferences <<EOF
Explanation: Dailymotion packages are of higher priority
Package: *
Pin: release o=Dailymotion
Pin-Priority: 900
EOF

Enfin, un crochet de type C permet d’obtenir un shell en cas d’erreur, ce qui est pratique pour corriger un problème :

#!/bin/bash
apt-get install -y --force-yes vim less
cd /tmp/buildd/*/debian/..
/bin/bash < /dev/tty > /dev/tty 2> /dev/tty

Une compilation peut ensuite être lancée avec la commande :

$ ARCH=amd64 DIST=precise ROLE=web pbuilder \
>         --build somepackage.dsc

Numérotation des versions

Afin d’éviter des règles trop complexes pour les versions, tout paquet est traité comme étant un rétroportage. Le schéma utilisé est le suivant : X-Y~preciseZ+dmW.

  • X est la version amont5.

  • Y est la version Debian. S’il n’y a pas de version Debian, mettre 0.

  • Z est la version du backport dans Ubuntu. S’il n’existe pas, mettre 0.

  • W est notre version du paquet. Il est incrémenté à chaque changement dans le paquet. C’est le seul numéro que nous contrôlons. Tous les autres dépendent d’une entité en amont.

Supposons que l’on désire rétroporter le paquet wackadoodle. Il est disponible dans une Ubuntu plus récente en version 1.4-3. La première version du paquet aura pour version 1.4-3~precise0+dm1. Après un changement dans le fichier debian/rules, nous obtenons la version 1.4-3~precise0+dm2. En amont, une version 1.5 devient disponible. Elle n’est disponible ni dans Ubuntu, ni dans Debian. Le numéro de version du paquet sera alors 1.5-0~precise0+dm1.

Quelques semaines plus tard, le paquet arrive chez Ubuntu dans la version 1.5-3ubuntu1. Vous y appliquez des changements pour obtenir la version 1.5-3ubuntu1~precise0+dm1.

Une convention compatible avec les pratiques de Debian concernant les rétroportages est : X-Y~bpo70+Z~dm+W.

Envoi

Pour intégrer un paquet dans le dépôt, les étapes classiques sont les suivantes :

  1. Le paquet source est placé dans un répertoire incoming/.
  2. reprepro remarque le paquet source, vérifie sa validité (signature, distribution) et le place dans l’archive.
  3. Le système de compilation remarque un nouveau paquet source à construire et lance la compilation de celui-ci.
  4. Une fois les paquets binaires construits, ils sont également placés dans le répertoire incoming/.
  5. reprepro détecte les paquets binaires et les intègre dans l’archive.

Cette façon de faire a le désavantage d’être difficile à suivre pour l’utilisateur. Une alternative est de concevoir un script de construction exécutant chaque tâche de manière synchrone et permettant ainsi à l’utilisateur de suivre son terminal le bon déroulement des opérations. Ce script s’occupe également d’inclure les paquets finaux dans l’archive :

$ reprepro -C main include precise-staging \
>      wackadoodle_1.4-3~precise0+dm4_amd64.changes

Voilà !


  1. Le répertoire gpg/ peut être partagé par plusieurs dépôts. 

  2. Il est possible d’apprendre à l’installeur Debian de travailler avec un tel dépôt en utilisant un fichier de configuration approprié

  3. fpm-cookery est un outil particulièrement pratique pour fpm, dans la même veine que Homebrew ou que l’arbre de ports des BSD. Il peut être utilisé dans une optique similaire. 

  4. sbuild est une alternative qui est aussi l’outil utilisé officiellement par Ubuntu et Debian. Historiquement, pbuilder était plus orienté vers les besoins des développeurs. 

  5. Pour un extrait de dépôt Git, le numéro de version amont utilisé ressemble à 1.4-git20130905+1-ae42dc1 ce qui correspond à un extrait situé après la version 1.4 (utiliser 0.0 s’il n’y a jamais eu de publication) à la date donnée. Le chiffre qui suit la date peut être incrémenté si plusieurs extraits sont utilisés dans la même journée. Enfin, le condensat à la fin permet de récupérer l’extrait exact. 

27 April, 2014 01:43PM par Vincent Bernat

16 April 2014

Tanguy Ortolo

Signing party au salon Solutions Linux le 20 mai 2014

En ces temps troublés, il est important de sécuriser nos échanges d'information — en chiffrant — ainsi que la distribution de logiciels — en signant les publications.

À cette fin, le salon Solutions Linux, Libres et Open Source sera l'occasion d'une signing party PGP, le 20 mai 2014 à 18h près du stand Debian France. Cette signing party est ouverte à tous les visiteurs et exposants du salon.

Pour faciliter les échanges d'empreintes de clefs en cas d'affluence, il est possible que nous utilisions une liste officielle de participants selon le protocole de Zimmermann-Sassaman. Pour préparer cela, il est demandé aux participants de me contacter en m'envoyant leur clef publique. Selon la méthode de signing party retenue, je publierai ultérieurement des instructions plus précises.

16 April, 2014 06:45PM par Tanguy

15 April 2014

Florent Gallaire

Lucas 2.0

Lucas Nussbaum vient d’être réélu Debian Project Leader.

Comme on peut le constater sur ce graphe, il a obtenu 47 voix de plus que Neil McGovern :

Une analyse plus précise des votes permet d’en calculer une représentation plus “classique” du point de vue des habitudes électorales, et donc plus compréhensible pour la majorité des gens :

Lucas Nussbaum : 56,5%
Neil McGovern : 43,5%

C’est bien une large victoire de Lucas, mais aussi une défaite très honorable pour Neil, qui se positionne donc comme un prétendant sérieux à la victoire l’année prochaine.

flattr this!

15 April, 2014 04:36PM par fgallaire

11 April 2014

Roland Mas

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

04 April 2014

Florent Gallaire

Quel DPL pour 2014 ?

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

Dès le 13 février, anticipant quelque peu sur le calendrier, Lucas avait exprimé le souhait de se représenter :

As it has been done by other DPLs in the past, I think that it makes sense for the DPL to announce his/her plans way before the next DPL election.

So, let’s do that now: I will run for reelection.

Après ses précédentes tentatives infructueuses de 2004, 2012 et 2013, Gergely Nagy s’était représenté, mais il a finalement dû se résoudre à retirer sa candidature :

Due to unexpected events, my plans and life got turned upside down (for the better) in the past few days, and because of that, I have to scale down a number of things. Unfortunately, running for DPL is one such thing.[...] Therefore, after a lot of thought, I’m withdrawing from the Debian Project Leader elections of 2014.

Le seul concurrent de Lucas est donc finalement Neil McGovern. Le plus important est bien sûr de lire les programmes de chacun des candidats :

Les presque mille développeurs Debian sont libres de faire leur choix depuis le 31 mars et jusqu’au 13 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.

flattr this!

04 April, 2014 12:21AM par fgallaire

28 March 2014

Tanguy Ortolo

Payez en liquide (et autres mesures de protection de la vie privée)

TL;DR¹ : les banques cherchent à exploiter les données de paiement par carte bancaire, il est donc temps de revenir au bon vieux liquide, intraçable et anonyme.

Développement d'une possibilité de surveillance généralisée

Notre vie privée s'érode petit à petit, tandis que s'instaure une possibilité de surveillance généralisée. C'est particulièrement visible avec le développement des systèmes de traitement automatique ces dernières décennies, mais ce mouvement est en réalité plus ancien :

Développement d'une possibilité de surveillance généralisée

Notre vie privée s'érode petit à petit, tandis que s'instaure une possibilité de surveillance généralisée. C'est particulièrement visible avec le développement des systèmes de traitement automatique ces dernières décennies, mais ce mouvement est en réalité plus ancien :

  • Dans l'Antiquité, puis au Moyen-Âge, l'État ne connaissait pas d'une façon générale l'identité de ses ressortissants ni de ses habitants, à moins d'effectuer de coûteux recensements.
  • Puis, je ne sais quand, un premier fichage systématique a eu lieu, de sorte que nous sommes connus par l'État dès notre naissance.
  • Un jour, il est devenu indispensable en pratique d'utiliser les services de banques, qui connaissent et disposent des pleins pouvoirs sur l'essentiel de notre patrimoine financier.
  • Depuis l'introduction de la carte bancaire, les banquiers savent pour la plupart de leurs clients où ils se déplacent et où et quand ils effectuent leurs achats.
  • Depuis l'introduction de la vente à distance, notamment par Internet, ces fournisseurs savent exactement ce que chacun de leurs clients leur achètent. Il en est de même pour le commerce local avec les cartes de fidélités, qui ont été créées pour cela.
  • Avec les téléphones portables, les opérateurs connaissent, à la cellule GSM près, les déplacements de tous leurs clients.
  • Avec l'introduction des titres de transport nominatifs tels que les cartes Navigo ou Vélib' à Paris, les régies de transport en commun connaissent avec une précision de l'ordre de la centaine de mètres tous les déplacements d'une grande partie des habitants de ces villes.

En quelques siècles, nous sommes donc passés d'une situation où, sorti du cercle des voisins, des amis et de la famille, chacun était inconnu et ses actions anonymes, à une situation où nous sommes connus et fichés dès notre naissance, et où des entreprises privées connaissent très précisément nos déplacements et nos achats, sans parler de nos communications. Chose plus inquiétante, on s'habitue peu à peu à ce qui paraissait scandaleux il y a quelques dizaines d'années et qui l'est pourtant toujours autant.

Dernières nouvelles : l'exploitation des données d'utilisation des cartes bancaires

Cartes de crédit

Il est souvent objecté que ces entreprises n'exploitent pas ces données. C'est parfois vrai, mais l'expérience montre que lorsqu'il y a une possibilité qu'un abus soit commis, cela arrive tôt ou tard². Face au risque d'exploitation des données d'utilisation des cartes bancaires, on suppose ainsi que ces données n'intéressent pas les banquiers. Sauf que : en fait si.

Limiter l'exploitation de nos données personnelles

Au niveau personnel, il est possible de limiter l'exploitation de données nous concernant, simplement en évitant de les fournir au départ. Comme souvent, il s'agit d'un compromis entre la vie privée parfaite et la fonctionnalité complète. Ainsi, voici une liste de propositions qui permettent de limiter la casse en restant à un niveau de contrainte raisonnable :

  • Payer en liquide : cela implique d'effectuer des retraits de montants plus élevés au distributeur le plus proche de chez soi, d'avoir sur soi un peu plus de liquide et d'en stocker une petite réserve de liquide chez soi. À la rigueur, payer par chèque, les banques enregistrant bien moins d'informations qu'avec les cartes bancaires.
  • Préférer les magasins locaux à la vente à distance. En plus ça coûte moins cher en transport, et par conséquent ça pollue moins.
  • Se déplacer de façon anonyme : si on doit utiliser une carte de transport, prendre la version anonyme, qui existe grâce à la contrainte de la CNIL sur les régies de transport.
  • Éteindre son téléphone mobile pendant les déplacements : il n'est certainement pas pratique de l'éteindre tout le temps, mais puisqu'il est de toute façon interdit de téléphoner en voiture ou à vélo, et que c'est très peu pratique en bus ou en métro, autant ne pas révéler notre position pendant les transports. Même chose pendant les promenades, randonnées ou sorties en général : si on ne s'attend pas à être appelé ou à devoir appeler quelqu'un, autant éteindre le téléphone, en plus ça économise de l'énergie.

Notes

  1. Too long; didn't read, soit trop long, pas lu. C'est un résumé pour décideurs pressés.
  2. Voyez par exemple le cas des verrous numériques sur les livres, qui permettent aux vendeurs de désactiver à distance la lecture d'un livre acheté par un lecteur. Bah, de toute façon ils ne le feront jamais, tu t'inquiètes pour rien. Ah, ben en fait si, Amazon l'a fait. 743.

28 March, 2014 01:36PM par Tanguy

01 February 2014

Charles Plessy

Consultation européenne sur les copyrights.

Ça y est, j'ai répondu à la Consultation publique sur la révision des règles de l’Union européenne en matière de droit d’auteur. Coïncidence, la radio diffusait European Super State de Killing Joke.

On peut voir en filigrane dans la consultation un Internet taillé sur mesure pour contrôler la diffusion et la copie des œuvres non-Libres, et surveiller les possibles infractions. Il est donc important de répondre pour rappeler la primauté de la présomption d'innocence et l'importance du respect de la vie privée.

J'ai néanmoins recommandé la minimisation des exceptions au copyright, car donner un accès gratuit temporaire aux documents non-libres, c'est aussi décourager la création d'alternatives que l'on peut copier, modifier et redistribuer librement.

01 February, 2014 01:41PM

25 December 2013

Carl Chenet

Cadeau de Noël : Publication de Brebis 0.9, le vérificateur automatisé de sauvegarde

Suivez-moi aussi sur Identi.ca ou sur Twitter 

Peu de temps avant ce Noël, l’équipe du projet Brebis a publié la version « Bouddhinette » 0.9 du vérificateur automatisé de sauvegardes. Pour rappel, Brebis est un programme en ligne de commande codé en Python permettant le contrôle automatisé de l’intégrité d’archives (tar, gz, bzip2, lzma, zip) et de la cohérence des fichiers à l’intérieur des archives. Au menu de cette version :

  • Support des archives apk
  • Nouvelles options de la ligne de commandes pour écrire le fichier de configuration (-C), la liste des fichiers dans l’archive (-L) ou les deux (-O) dans un répertoire défini par l’utilisateur (où précédemment ces fichiers étaient écrits par défaut dans le même répertoire que l’archive elle-même).
brebis-brown-big-logo

Anisette, la fière nouvelle mascotte et nouveau logo du projet Brebis généreusement contribué par Antoine Millet

Comme annoncé aux JM2L, Brebis continue d’intégrer des nouveaux types d’archives , mais aussi rend sa manipulation plus flexible afin d’être intégré plus simplement pour répondre aux besoins de ses utilisateurs en s’adaptant plus simplement aux différentes situations existantes..

Feedback sur Brebis

Et vous ? Que pensez-vous de Brebis ? N’hésitez pas à vous abonner à la liste de diffusion de Brebis,  à laisser un commentaire ici ou  un message sur le forum ou à me contacter directement, tous les retours seront appréciés.


25 December, 2013 10:01PM par Carl Chenet

14 December 2013

Charles Plessy

Fatigué

En voulant préparer la mise à jour d'un paquet, j'ai vu une image au format PNG, et avant même de l'ouvrir je me suis senti vieux, usé, abattu, et incapable de faire face. Après inspection, c'est évident image n'a pas été faite à la main, il manque le ficher source. Une autre image dans le même répertoire a le même style et a une source au format SVG, c'est la preuve. Il manque quand même les instructions pour convertir le SVG en PNG. De plus en plus dans ces situations-là, je baisse les bras et je laisse tomber le paquet. J'ai perdu le temps et l'énergie pour exiger des auteurs des changements pour lesquels je n'ai personnellement aucun intérêt concret. Le SVG en plus du PNG, c'est mieux, mais le PNG sans SVG, pour la documentation d'un programme, c'est suffisamment libre à mon goût. Mais les points de vue exprimés sur debian-devel me donnent l'impression que ce n'est pas assez bon pour Debian, alors je laisse tomber…

14 December, 2013 02:19AM

08 December 2013

Carl Chenet

Retour sur Brebis, le vérificateur automatisé de sauvegarde, aux JM2L

Suivez-moi aussi sur Identi.ca ou sur Twitter 

Comme chaque année avait lieu à Sophia Antipolis les Journées Méditerrannéennes du Logiciel Libre, organisées par l’association Linux Azur. J’avais proposé pour cette année une présentation du projet  Brebis, le vérificateur automatisé de sauvegarde. C’était pour moi l’occasion de réaliser quelques slides parlant du projet (désormais disponible en ligne – CC by SA) et de recueillir les réactions du public.

jm2l

L’accueil est chaleureux, comma d’habitude et le public est présent. On m’avait accordé un créneau d’une bonne heure. j’ai donc essayé de captiver mon public pendant 50 minutes avant la séance de questions. La présentation se découpe en deux phases, une introduction au domaine de la sauvegarde et à la nécessité de vérifier les sauvegardes régulièrement, puis une seconde partie plus technique sur les fonctionnalités du logiciel Brebis lui-même.

brebis-brown-big-logo

Anisette, la fière nouvelle mascotte et nouveau logo du projet Brebis généreusement contribué par Antoine Millet

La conférence a été filmée, je pourrai donc vérifier ce qu’il en est une fois que les vidéos seront en ligne.

Niveau stand, les exposants sont accueillants et disponibles et je suis content de voir cet événement du Logiciel Libre toujours aussi fréquenté. Trois fois que je fais le déplacement et je repasse sans faute l’année prochaine !

Étiez-vous aux JM2L aussi ? Qu’en avez-vous pensé ? N’hésitez pas à réagir dans les commentaires de ce billet.


08 December, 2013 09:54AM par Carl Chenet

15 November 2013

Roland Mas

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

26 August 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 par obergix

01 August 2012

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 par Gregory Colpart

05 October 2010

Vincent Carmona

Adapter une bibliothèque C pour ruby (4)

Ce quatrième billet présente comment obtenir une documentation grâce à rdoc : il suffit de commenter les fichiers sources.

Documentation

Commenter

Pour documenter les méthodes de la classe TagLib::File, il suffit de commenter les différentes fonctions les implémentant.

La méthode title permet d'obtenir le titre d'une piste. On l'indique en commentaire juste avant la fonction file_get_title.
 
/*Get track title*/ 
VALUE 
file_get_title(VALUE self) 

Par défaut, les paramètres d'une méthode sont nommés p1, p2, .... Pour la méthode title=, on utilise l'instruction call-seq: pour afficher le texte title=title (au lieu de title=(p1)).
 
/* 
call-seq: title=title 
 
Set track title to title 
 
title: a string 
*/ 
VALUE 
file_set_title(VALUE self, VALUE title) 

La méthode initialize ne devrait jamais être appelée directement depuis un code ruby. On utilise l'instruction :nodoc: pour indiquer que la méthode ne doit pas apparaitre dans la documentation.
 
/*:nodoc:*/ 
VALUE 
file_init(VALUE self, VALUE path) 

J'indique que je ne désire pas commenter le module TagLib en plaçant un commentaire vide afin d'éviter que rdoc utilise un commentaire non-désiré.
 
/* */ 
  mTagLib=rb_define_module("TagLib"); 

Dans le fichier lib/raglib2.rb, j'ajoute la directive :main: afin que la page initiale de la documentation pointe sur la classe TagLib::File.
 
#:main: TagLib::File 
module TagLib 

Bizarrement, cette directive ne semble pas fonctionner si elle est placée dans le fichier taglib2.c.

Produire la documentation

 
rdoc --exclude extconf.rb 

Le fichier doc/index.html est créé.
aperçu de la documentation

Conclusion

Rendez-vous pour le dernier billet où j'introduirai quelques concepts que je n'ai pas utilisé dans le module TagLib.

Billet original publié sur les blogs de developpez.com...

05 October, 2010 10:43PM par vinc-mai

04 October 2010

Vincent Carmona

Adapter une bibliothèque C pour ruby (3)

Cet article fait suite au premier et deuxième billets dans lesquels nous avons vu comment créer un objet de la classe TagLib::File. Cet objet utilise les fonctions de la bibliothèque taglib, écrite en C, afin d'accéder aux tags de fichiers audio. Dans ce billet, nous verrons comment obtenir les valeurs des tags et comment modifier un tag.

» Lire la suite!

Billet original publié sur les blogs de developpez.com...

04 October, 2010 02:47PM par vinc-mai

18 August 2010

Grégory Colpart

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 par Gregory Colpart

18 May 2008

Olivier Berger (perso)

Déclaration d'impôts sous Debian testing : difficultés mais contournement trouvé

J'ai essayé de télédéclarer mes impôts sur le revenu depuis ma Debian (testing) avec iceweazel (plugin Java Sun du paquet sun-java5-plugin).

Tou allait bien jusqu'à la phase finale de signature, où j'obtenais des erreurs de ce genre (dans la console Java) :

java.lang.UnsatisfiedLinkError: Expecting an absolute path of the library: local/.TaoUSign/libjsec.so
        at java.lang.Runtime.load0(Runtime.java:767)
        at java.lang.System.load(System.java:1005)
        at com.dictao.plfm.a.b(Unknown Source)
        at signview.b(Unknown Source)
        at signview.start(Unknown Source)
        at sun.applet.AppletPanel.run(AppletPanel.java:465)
        at java.lang.Thread.run(Thread.java:619)

Le problème apparemment, c'est que :

$ ldd ~/local/.TaoUSign/libjsec.so 
	linux-gate.so.1 =>  (0xffffe000)
	libnspr4.so => /usr/lib/libnspr4.so (0xb7f14000)
	libpthread.so.0 => /lib/i686/cmov/libpthread.so.0 (0xb7efc000)
	libnss3.so => not found
	libdl.so.2 => /lib/i686/cmov/libdl.so.2 (0xb7ef7000)
	libm.so.6 => /lib/i686/cmov/libm.so.6 (0xb7ed2000)
	libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb7d84000)
	/lib/ld-linux.so.2 (0x80000000)

Mais j'ai trouvé le contournement suivant pour que ça passe (après avoir complètement quitté iceweasel) : lancer iceweasel depuis le répertoire contenant libnss3.so, avec LD_LIBRARY_PATH positionnée à "." :

$ cd /usr/lib/iceweasel/
$ LD_LIBRARY_PATH=. iceweasel

Et voilà, ça marche mieux.

18 May, 2008 07:55PM par olberger

19 April 2006

Pierre Machard

Et si les écologistes s’étaient trompés au sujet du nucléaire?

Hier en lisant slashdot je suis tombé sur un billet qui mentionnait que Patrick Moore (un des fondateurs de Greenpeace), dans un éditorial du Washington Post, expliquait que l’énergie nucléaire était la seule source d’énergie qui pouvait couvrir nos besoins.

« Thirty years on, my views have changed, and the rest of the environmental movement needs to update its views, too, because nuclear energy may just be the energy source that can save our planet from another possible disaster: catastrophic climate change. »

Ce qui dans la langue de Molière pourrait donner quelque chose comme :
« En 30 ans, mes idées ont évolué, et le mouvement écologiste doit également évoluer dans ses considérations, car l’énergie nucléraire est peut être la source d’énergie qui peut préserver notre planète d’un autre risque probable : un boulversement climatique. »

La catastrophe de Tchernobyl a eu lieue il y a 20 ans, néanmoins, il convient de réfléchir sur nos besoins en énergie, développer les énergies non-fossiles, mais aussi de se rendre compte que nous n’avons pas d’alternative au nucléaire, sans quoi nous serions obligé d’éteindre tous nos ordinateurs.

19 April, 2006 09:01AM par migus

15 March 2006

Pierre Machard

Une belle explication des DRM

Hier soir dans l’hémicycle de l’Assemblée Nationale j’ai eu la chance d’entendre une magnifique définition de ce qu’est un DRM. M. Suguenot (UMP) a très didcatiquement détaillé comment fonctionne un DRM. Je vous copie/colle ici le verbatim du propos de M. Suguenot. La seule erreur à noter est l’utilisation du verbe crypter là où nous aurions dû trouver chiffrer :

« Lorsque vous achetez de la musique sur internet, les DRM sont déjà systématiquement utilisés. Dans le système de Microsoft adopté par la Fnac et Virgin, le serveur de votre fournisseur crypte le morceau de musique à l’aide d’une clef secrète, que vous ne recevrez naturellement pas. Vous devez alors utiliser un lecteur compatible, Windows Media Player par exemple. Ce lecteur, détectant que le fichier est crypté, protégé par un DRM, prend contact avec le serveur pour lui demander la clé secrète nécessaire à la lecture. Avant de la lui envoyer, le serveur lui demande le numéro de série de votre ordinateur puis met à jour votre fiche client en y inscrivant le numéro de série du morceau concerné suivi de celui de l’ordinateur sur lequel vous désirez l’écouter, avant de fabriquer un fichier qu’on appelle licence. Cette licence contient la clé secrète de décryptage, mais aussi une liste de règles précisant ce que vous êtes autorisé à faire avec le morceau en question. Le serveur envoie cette licence à votre lecteur qui la « cache » sur votre disque dur. Disposant alors du morceau de musique et de sa licence, il vérifie dans celle-ci que vous avez bien le droit de lire celui-là. Si tout est en règle, vous pouvez, enfin, écouter votre musique !

Comprenant mieux le fonctionnement des DRM, on imagine les règles qu’ils permettent d’imposer. Si vous transférez le morceau sur une autre machine, le lecteur, ne trouvant plus de licence, va à nouveau contacter le serveur pour en obtenir une. Votre fiche client sera mise à jour et le serveur « saura » que vous avez installé ce morceau une deuxième fois. Si vous dépassez le nombre maximal d’ordinateurs autorisés, cinq avec iTunes par exemple, le serveur refusera de vous accorder une nouvelle licence, vous devrez lui demander d’en retirer une à un ordinateur pour la transférer à un autre. La licence peut également imposer une limitation dans le temps de l’utilisation d’un fichier, un délai au-delà duquel le lecteur le détruira.  »

15 March, 2006 10:36AM par migus