Le projet Debian distribue des paquets de logiciels via son archive, propagée à travers un réseau de miroirs. Cette archive est organisée en trois zones, main, qui contient le système Debian, et contrib et non-free qui contiennent des paquets accessoires qui ne sont pas libres. Les paquets dans non-free contiennent des fichiers dont la licence est privatrice. Les paquets source dans contrib ne contiennent que des fichiers libres, mais les paquets binaires produits sont soit inutilisables sans service extérieur, soit contiennent des fichiers non libres ou demandent l'installation de paquets non libres.

La zone contrib est l'objet de sempiternelles questions car il n'est pas toujours facile de tracer une ligne entre utilisable et inutilisable. Je me demande s'il ne vaudrait pas mieux remplacer la zone contrib par un nouveau niveau de priorité, « remote », plus bas qu'extra. Les paquets entièrement libres (source et binaire) et ne causant pas l'installation de logiciels privateurs y auraient leur place. Pour les paquets qui ne peuvent pas fonctionner sans code privateur, étant donné que l'effort sera le même pour les libérer que ce code privateur soit inclut dans le même paquet source (cas de non-free) ou non (cas de contrib), je pense qu'on devrait les placer dans non-free dans tous les cas : ils ne sont pas libres en pratique.

Cela permettrait de trancher avec un critère simple : la sélection d'un paquet binaire entraînera-t-elle l'installation de logiciels privateurs ? Si oui, le paquet et sa source appartiennent à non-free. Si non, ils appartiennent à main. Ensuite, s'ils demandent l'accès à un service extérieur impossible à mettre en place sur un réseau où seule Debian serait disponible, leur priorité sera remote.

Grâce au cadeau de Joey, umegaya est maintenant hébergé chez Branchable. Merci !

J'arrive enfin à créer une image machine de l'installeur Debian automatiquement, sans qu'aucune clé ou mot de passe ne transite par le réseau ni dans le Nuage, et sans utiliser les ec2-api-tools, qui ne sont pas libre. Merci à Eucalyptus pour avoir implémenté l'attribut InstanceInitiatedShutdownBehavior dans euca2ools 2.1.2.

En résumé, je démarre une micro-instance avec un volume supplémentaire, et je lui passe un script via cloud-init, qui va télécharger l'Installeur Debian sur ce volume et éteindre la micro instance. Ensuite, j'enregistre ce volume comme image machine.

Ces images machines de l'Installeur sont faites pour être pré-configurées via les métadonnées d'instance pour installer Debian sur un autre volume. Je bute encore sur cette pré-configuration. Plus de détails dans un prochain article. En attendant, voici les commandes que j'utilise.

Depuis l'ordinateur local, lancer une instance sur le Nuage. J'utilise une image Ubuntu en attendant que #696595 soit réglé et que cloud-init soit installé par défaut sur les images Debian.

HELPER_AMI=ami-7609bb77 # Ubuntu 12.04 LTS Precise amd64 EBS in (Asie Nord-Est)

On démarre l'instance avec un volume supplémentaire de 1 GiB qui persistera après l'extinction de l'instance (/dev/sdb=:1:false). On lui passe le script debigen-install-installer-cloud (voir plus bas).

HELPER_INSTANCE=$( euca-run-instances \
        --instance-initiated-shutdown-behavior terminate \
        --instance-type t1.micro \
        --block-device-mapping /dev/sdb=:1:false \
        --user-data-file debigen-install-installer-cloud \
        $HELPER_AMI |
        tee /dev/stderr | grep INSTANCE | awk '{print $2}')

On attend que le démarrage soit fini.

while [ ! $(euca-describe-instances $HELPER_INSTANCE | grep INSTANCE | cut -f 6 | tee /dev/stderr) = "running" ]
    do sleep 30
done

On récupère le numéro du volume persistant.

TARGET_VOLUME=$( euca-describe-volumes |
        grep $HELPER_INSTANCE | grep '/dev/sdb' |
        tee /dev/stderr | awk '{print $2}')

On attend que le script termine l'instance.

while [ ! $(euca-describe-instances $HELPER_INSTANCE | grep INSTANCE | cut -f 6 | tee /dev/stderr) = "terminated" ]
    do sleep 30
done

Et enfin, on enregistre une image à partir d'un instantané du volume.

PV_KERNEL=aki-44992845 # Démarre PV-Grub sur hd0 (Asie Nord-Est)

TARGET_SNAPSHOT=$( euca-create-snapshot $TARGET_VOLUME |
        tee /dev/stderr | awk '{print $2}')

while euca-describe-snapshots $TARGET_SNAPSHOT | grep -q pending ; do sleep 30 ; done

euca-register \
    --name test_di \
    --description test_of_debian_installer \
    --snapshot $TARGET_SNAPSHOT \
    --kernel $PV_KERNEL \
    --architecture x86_64

Voici le script appelé debigen-install-installer-cloud, lancé plus haut.

#!/bin/sh -ex

mke2fs -L debian-installer /dev/xvdb -F
mount LABEL=debian-installer /mnt/

cd /mnt

ARCH=amd64
DIST=squeeze
DI_VERSION=20110106+squeeze4+b2
MIRROR=jp
BASEURL=http://ftp.$MIRROR.debian.org/debian/dists/$DIST/main/installer-$ARCH/$DI_VERSION/images/netboot/xen

wget $BASEURL/initrd.gz $BASEURL/vmlinuz

mkdir -p boot/grub

cat > boot/grub/menu.lst <<__END__
default 0
timeout 3

title  Debian Installer ($DI_VERSION $ARCH)
root   (hd0)
kernel /vmlinuz root=LABEL=debian-installer ro console=hvc0 auto=true priority=critical url=http://169.254.169.254/latest/user-data DEBIAN_FRONTEND=text
initrd /initrd.gz
__END__

sleep 30

halt

Un paquet Debian contient quelques méta-informations sur le programme emballé. Par exemple, l'adresse de sa page d'accueil est enregistrée dans le ficher de contrôle du paquet source (debian/control) et propagée par le ficher de contrôle source Debian (.dsc). Le problème avec cette approche, c'est qu'il faut mettre à jour le paquet source pour mettre à jour les méta-données.

À ce jour, plusieurs milliers de paquets source Debian sont développés dans un système de gestion de version, le plus souvent Subversion ou Git. L'adresse du dépôt est aussi propagée via les fichiers de contrôle montrés plus haut. Il est donc possible de surveiller la branche principale pour détecter et propager des mises à jour sans qu'il ne soit nécessaire d'envoyer un nouveau paquet dans l'archive Debian.

En 2009, j'ai proposé de centraliser les méta données concernant le projet amont dans un fichier au format YAML, debian/upstream. Nous l'utilisons maintenant dans le projet Debian Med pour véhiculer la référence bibliographique des articles scientifiques décrivant le fonctionnement des programmes empaquetés. On peut les voir sur les sentinelles correspondant à nos méta-paquets. Les données transitent via la base de données Ultime de Debian (UDD).

Imaginons que le concept s'étende et que des milliers de paquets fournissent un fichier debian/upstream. Comment faire pour maintenir la base de données à jour sans générer des milliers de requêtes quotidiennes sur notre forge Alioth ?

Je développe un système, que j'ai appelé Umegaya, pour Umegaya is a MEtadata GAtherer using YAml. Umegaya fournit une interface web avec une structure simple, que l'on peut utiliser pour consulter des données. Par exemple, http://upstream-metadata.debian.net/emboss/reference-year renvoie 2000, l'année où le premier article sur EMBOSS a été publié. Si au moment de la consultation, la dernière mise à jour date d'il y a plus d'une heure le système va relire le fichier debian/upstream du paquet. C'est donc en consultant les données que l'on les met à jour. Réciproquement, il suffit de consulter les données après avoir changé debian/upstream pour synchroniser la base.

Umegaya est encore une ébauche, et beaucoup de choses pourraient changer. Mais le service tourne depuis plus d'un an à l'adresse upstream-metadata.debian.net. Il sert entre autres à remplir le dépôt Subversion appelé packages-metadata, rassemblant les fichiers debian/upstream, debian/control et debian/copyright des paquets envoyés dans l'archive Debian (depuis quelques mois). On y voir par exemple que parmi les 3 646 fichiers copyright, 1 218 déclarent se conformer au format 1.0.

Comme j'aime beaucoup le principe emballe ce que tu utilises, utilise ce que tu emballes, umegaya est entré dans l'archive Debian il y a quelques jours.

Il est rare que je me serve de réseaux sociaux, mais généralement je ne refuse pas les invitations à se connecter quand elles viennent de gens que je connais. Ceci dit, j'ai un doute à accepter les yeux fermés les demandes provenant d'autres développeurs Debian, que pour la plupart je n'ai jamais rencontré de face : l'identité du demandeur est-elle certaine ? Heureusement, nous avons un outil pour résoudre ce problème, notre réseau de clés GPG. J'ai donc décidé de signer les URLs qui correspondent à mes pages sur des réseaux sociaux, et dorénavant je n'accepterai que des demandes certifiées de cette manière ou d'une autre, lorsqu'elles viennent de personnes ayant une clé.

Paradoxalement, bien que les réseaux sociaux pour la plupart ne redistribuent pas le code source de leurs systèmes, la seule fois où l'un d'entre eux m'a vraiment servi, c'était pour le Libre, en contactant un ancien développeur dont l'adresse courriel n'était plus disponible, afin de clarifier la licence d'un bout de code qu'il avait écrit il y a longtemps, ce qui m'a permis d'éviter à un paquet dont je m'occupe d'être relégué dans notre zone non-libre.

Avec László Böszörményi nous avons adopté mime-support, qui était maintenu depuis septembre 1996 par Brian White. C'est le premier paquet de priorité standard dont je m'occupe. Ça fait un peu le même effet que quand on a enlevé les roulettes sur mon vélo, il y a très longtemps...

Nous avons transféré le paquet source sur Alioth, et fait une première mise à jour permettant d'extraire les informations pour le fichier mailcap directement depuis les fichiers Desktop. Je pense que les deux prochaines actions seront de résoudre le bug sur la gestion des fichiers PHP, et de mettre à jour la base mime.types, si possible en synergie avec Fedora ou d'autres distributions.

Chaque instance (machine virtuelle) démarrée partir de la même image est configurée de manière identique. Le même compte et le même moyen seront utilisés pour s'y connecter. Si l'image machine est publique et l'instance ouverte sur l'extérieur, comme souvent lorsqu'on passe par un prestataire comme Amazon, une personne mal intentionnée pourrait essayer de se connecter au hasard à des adresses IP du nuage, en espérant finir par accéder à une instance avant son locataire et en prendre le contrôle.

Pour personnaliser la connexion à chaque instance, on peut passer des informations au démarrage, que l'on appelle des des métadonnées d'instance, et qui seront accessible à une adresse HTTP fixe visible seulement depuis l'instance en question. Si le locataire de l'instance fournit une clé publique SSH, seul le détenteur de la clé privée pourra se connecter.

Après la prochaine mise à jour de network-console, ce type de connexion sera possible pour les images de l'installeur Debian. De même pour les images de systèmes Debian produites à partir de ces installeurs, via le programme cloud-init, que j'ai empaqueté dans la section expérimentale de notre archive. Ce paquet cloud-init est loin d'être abouti. Il lui manque les scripts de démarrage, il n'est pas traduit, et pour être honnête, il n'est pas testé. Mais l'avoir dans Debian me permet de bénéficier des systèmes de suivi des paquets et de leurs bugs. N'hésitez pas à en rajouter, et plus encore, à participer à l'entretien du paquet.

Cloud-init fait beaucoup d'autres choses intéressantes. Merci à Scott Moser, le développeur amont et responsable du paquet chez Ubuntu, pour sa coopération lors de la création du paquet Debian, car j'ai fait de grosses modifications, en particulier j'ai enlevé la partie concernant la gestion du fichier menu.lst pour pv-grub, qui aura son propre paquet ou sera transférée ailleurs.

Debian Med prépare un méta-paquet pour des images machines polyvalentes rassemblant tous les outils distribués par Debian pour la bio-informatique et utilisés en ligne de commande ou via des scripts, qui ne dépendent pas de systèmes graphiques trop lourds.

Je voudrais préparer une telle image pour le nuage Amazon, de la manière la plus sûre possible, et le plus simple est de la construire automatiquement de manière à ne rien avoir à nettoyer à la fin de l'opération. J'ai essayé pendant plusieurs mois de passer par l'installeur Debian, et me suis tapé longuement la tête contre les murs, car il était impossible de re-partitionner le disque depuis lequel l'installeur était démarré. Cela n'était finalement pas nécessaire.

Par exemple, on peut démarrer une image contenant l'installeur sur une micro-instance (-t t1.micro) avec un disque supplémentaire de un gibibyte (-b /dev/sdb=:1:false) pour y installer Debian, et pré-configurer l'installeur via les métadonnées passées à l'instance (-f preseed.txt) avec un fichier préparé à l'avance. À la fin de l'installation, l'instance se termine au lieu de s'arrêter (--instance-initiated-shutdown-behavior terminate) et ses volumes disparaissent, sauf celui où l'on a installé Debian (/dev/sdb=:1:false).

L'installeur de Debian Stable n'est pas souvent mis à jour, et sa taille est très réduite. On peut donc envisager de distribuer à peu de frais une image machine par zone et par architecture. Je viens de le faire pour Tôkyô (ap-northeast-1) sur amd64. Elle contient le noyau, son initrd, et un menu GRUB 1 pour pvgrub qui lui passe les options console=hvc0 auto=true priority=critical url=http://169.254.169.254/latest/user-data DEBIAN_FRONTEND=text.

Il manque au système ainsi produit deux éléments importants. Il faut que lors de l'installation du noyau et de ses mises à jours, le fichier de configuration GRUB 1 pour pvgrub soit rafraîchi. Ensuite, il faut que le système soit capable de télécharger une clé SSH publique via les métadonnées d'instance, afin que l'on s'y connecte sans mot de passe défini à l'avance. Ces deux fonctions sont disponibles dans le paquet cloud-init, disponible chez Ubuntu et Fedora. Je cherche des volontaires pour maintenir ou co-maintenir cloud-init dans Debian.

Cela fait deux jours que tous mes courriels, @debian.org y compris, sont coincés entre leur envoyeur et mon MX, car mon serveur a cassé à un moment où je n'avais pas une seconde à moi (date butoir pour une de financement). C'est un OpenRD Ultimate avec un disque solide d'occasion. J'étais bien content d'avoir un système ARM sous la main, pour tester quelques paquets comme T-COFFEE, mais il semble que je vais devoir le remplacer.

On dirait que la machine redémarre en permanence. Aucune tentative d'accéder au port série USB n'a été fructueuse; il ne se passe pas 10 secondes sans que le port USB ne soit déconnecté / reconnecté. Les loupiotes des deux ports ethernet clignotent ensemble de manière synchrone avec les déconnections. Retirer le disque solide n'a rien changé.

Le disque lui-même se porte bien, et je n'ai rien trouvé dans les logs qui suggère un problème logiciel. Coïncidence étrange, le dernier fichier de log modifié est daemon.log, qui indique la visite de notre réseau sans fil, non protégé mais à ma connaissance jamais visité, d'un(e) certain(e) megumi-PC. Après, plus rien.

Ce samedi a bien commencé avec la lecture sur Planet Debian de deux articles stimulants, l'un à propos de GitTogether2011, et l'autre à propos de l'utilisation de Git dans la société Baserock.

J'aime beaucoup l'idée d'utiliser Git au-delà de la gestion du code source de programmes. D'ailleurs cet article est lui-même diffusé via un réseau de référentiels Git. Pour les paquets Debian dont je m'occupe et qui sont gérés avec Git, je stocke depuis quelques temps les journaux de construction dans une branche appelée meta. Depuis que sbuild filtre certaines parties variables de ses journaux, la commande git diff --word-diff=color permet de surveiller efficacement la différence entre les constructions de deux versions d'un paquet. Par exemple, pour la mise à jour de bedtools que j'ai faite ce matin, pas grand chose à signaler si ce n'est que -D_FORTIFY_SOURCE=2 n'est plus passé et que par conséquent les alertes -Wunused-result ont disparu.

Un des autres avantages de stocker les journaux de construction est simplement de rendre disponible une information qui ne l'était pas auparavant : buildd.debian.org contient les journaux pour toutes les plates-formes sauf celle utilisée par le responsable du paquet, souvent l'une des plus utilisées, car ses téléchargements combinent paquets source et binaires. Ce problème sera réglé lorsque notre archive reconstruira automatiquement les paquet binaires téléchargé avec les paquets source, mais pas complètement car il est toujours possible de télécharger un paquet binaire isolément.

Dans la branche meta de mes dépôts Git, les journaux sont gardés côte-à-côte pour toutes les plates-formes. Je ne suis pas sûr que que ça soit la disposition idéale, mais pour le moment je suis réticent à l'idée d'avoir une multitude de branches parallèles. Je commence à automatiser la gestion des journaux, par exemple avec le petit script suivant pour les récupérer depuis buildd.debian.org.

#!/bin/bash

BASEURL=buildd.debian.org:/srv/buildd.debian.org/db
PACKAGE=$1
shift

for version in "$*"

do
  scp $BASEURL/${PACKAGE:0:1}/$PACKAGE/${version}/* .
  for arch in $(ls *bz2 | sed 's/_.*//g')
    do bzcat ${arch}*bz2 > ${arch}.log
    rm ${arch}_*_log.bz2;
  done
done

exit