September 13, 2017

hackergotchi for Vincent Bernat

Vincent Bernat

VPN IPsec routé avec Linux et strongSwan

La façon la plus courante d’établir un tunnel IPsec sous Linux est d’utiliser un démon IKE, comme celui du projet strongSwan. Voici un exemple minimal de configuration1 :

conn V2-1
  left        = 2001:db8:1::1
  leftsubnet  = 2001:db8:a1::/64
  right       = 2001:db8:2::1
  rightsubnet = 2001:db8:a2::/64
  authby      = psk
  auto        = route

La même configuration peut être utilisée des deux côtés. Chacun sait déterminer s’il est « left » ou « right ». Les terminaisons du tunnel sont 2001:db8:­1::1 et 2001:db8:­2::1. Les réseaux protégés sont 2001:db8:­a1::/64 et 2001:db8:­a2::/64. En utilisant cette configuration, strongSwan met en place les politiques de sécurité suivantes dans le noyau :

$ ip xfrm policy
src 2001:db8:a1::/64 dst 2001:db8:a2::/64
        dir out priority 399999 ptype main
        tmpl src 2001:db8:1::1 dst 2001:db8:2::1
                proto esp reqid 4 mode tunnel
src 2001:db8:a2::/64 dst 2001:db8:a1::/64
        dir fwd priority 399999 ptype main
        tmpl src 2001:db8:2::1 dst 2001:db8:1::1
                proto esp reqid 4 mode tunnel
src 2001:db8:a2::/64 dst 2001:db8:a1::/64
        dir in priority 399999 ptype main
        tmpl src 2001:db8:2::1 dst 2001:db8:1::1
                proto esp reqid 4 mode tunnel
[…]

Ce type de tunnel IPsec se base exclusivement sur ces politiques de sécurité pour décider de l’encapsulation des paquets (policy-based VPN). Chaque politique de sécurité est constituée des éléments suivants :

  • une direction (out, in ou fwd2),
  • un sélecteur (un ensemble de critères tels que réseaux source et destination, ports, …),
  • un mode (transport ou tunnel),
  • un protocole d’encapsulation (esp ou ah),
  • les adresses source et destination du tunnel.

Quand une politique de sécurité s’applique, le noyau recherche l’association de sécurité correspondante (en utilisant reqid et les adresses du tunnel) :

$ ip xfrm state
src 2001:db8:1::1 dst 2001:db8:2::1
        proto esp spi 0xc1890b6e reqid 4 mode tunnel
        replay-window 0 flag af-unspec
        auth-trunc hmac(sha256) 0x5b68[…]8ba2904 128
        enc cbc(aes) 0x8e0e377ad8fd91e8553648340ff0fa06
        anti-replay context: seq 0x0, oseq 0x0, bitmap 0x00000000
[…]

Si aucune association de sécurité n’est trouvée, le paquet est mis de côté et le démon IKE est prévenu pour en négocier une. Lorsqu’un paquet encapsulé est reçu, l’entête contient le SPI qui permet d’identifier l’association de sécurité à utiliser. Deux associations de sécurité sont nécessaires pour un tunnel bi-directionnel :

$ tcpdump -pni eth0 -c2 -s0 esp
13:07:30.871150 IP6 2001:db8:1::1 > 2001:db8:2::1: ESP(spi=0xc1890b6e,seq=0x222)
13:07:30.872297 IP6 2001:db8:2::1 > 2001:db8:1::1: ESP(spi=0xcf2426b6,seq=0x204)

Toutes les implémentation d’IPsec permettent de travailler avec des politiques de sécurité. Toutefois, certaines configurations sont ardues à mettre en place de cette façon. Par exemple, considérons l’architecture suivante pour des VPN redondants reliant trois sites :

VPN redondants entre 3 sites

Une configuration possible pour le tunnel entre V1-1 et V2-1 serait :

conn V1-1-to-V2-1
  left        = 2001:db8:1::1
  leftsubnet  = 2001:db8:a1::/64,2001:db8:a6::cc:1/128,2001:db8:a6::cc:5/128
  right       = 2001:db8:2::1
  rightsubnet = 2001:db8:a2::/64,2001:db8:a6::/64,2001:db8:a8::/64
  authby      = psk
  keyexchange = ikev2
  auto        = route

À chaque fois qu’un réseau est ajouté ou retiré d’un site, les configurations de tous les sites doivent être mises à jour. De plus, le chevauchement de certains réseaux (2001:db8:­a6::/64 d’un côté et 2001:db8:­a6::cc:1/128 de l’autre) pose quelques problèmes supplémentaires.

L’alernative est d’utiliser des tunnels routés : tout paquet traversant une pseudo-interface sera encapsulé en utilisant une politique de sécurité associée à l’interface. Cela résout principalement deux problèmes :

  1. Des démons de routage peuvent être utilisés pour distribuer les routes à protéger sur chaque site. Cela réduit grandement la quantité de configuration à gérer quand de nombreux réseaux sont présents.
  2. L’encapsulation et la décapsulation peut s’exécuter dans une instance de routage ou espace de noms différent. Cela permet de cloisonner efficacement le routage privé (où les utilisateurs du VPN se trouvent) du routage public (où les terminaisons VPN se trouvent).

VPN routé avec Juniper

Regardons d’abord comment un tel concept est mis en place sur une plateforme JunOS (comme le Juniper vSRX). Les tunnels routés sont une fonctionnalité qui existe depuis longtemps sur celle-ci (héritage des Netscreen ISG avec ScreenOS).

Nous allons configurer le tunnel entre V3-2 et V1-1. Tout d’abord, nous mettons en place l’interface tunnel. Elle est associée à l’instance de routage private qui ne contiendra que les routes internes (avec IPv4, elle ne contiendrait que des routes de type RFC 1918) :

interfaces {
    st0 {
        unit 1 {
            family inet6 {
                address 2001:db8:ff::7/127;
            }
        }
    }
}
routing-instances {
    private {
        instance-type virtual-router;
        interface st0.1;
    }
}

La seconde étape consiste à configurer le VPN :

security {
    /* Configuration de la phase 1 */
    ike {
        proposal IKE-P1 {
            authentication-method pre-shared-keys;
            dh-group group20;
            encryption-algorithm aes-256-gcm;
        }
        policy IKE-V1-1 {
            mode main;
            proposals IKE-P1;
            pre-shared-key ascii-text "d8bdRxaY22oH1j89Z2nATeYyrXfP9ga6xC5mi0RG1uc";
        }
        gateway GW-V1-1 {
            ike-policy IKE-V1-1;
            address 2001:db8:1::1;
            external-interface lo0.1;
            general-ikeid;
            version v2-only;
        }
    }
    /* Configuration de la phase 2 */
    ipsec {
        proposal ESP-P2 {
            protocol esp;
            encryption-algorithm aes-256-gcm;
        }
        policy IPSEC-V1-1 {
            perfect-forward-secrecy keys group20;
            proposals ESP-P2;
        }
        vpn VPN-V1-1 {
            bind-interface st0.1;
            df-bit copy;
            ike {
                gateway GW-V1-1;
                ipsec-policy IPSEC-V1-1;
            }
            establish-tunnels on-traffic;
        }
    }
}

Il s’agit d’un VPN routé car l’interface st0.1 est associée au VPN VPN-V1-1. Une fois le tunnel fonctionnel, tout paquet entrant dans st0.1 sera encapsulé et envoyé vers la terminaison 2001:db8:­1::1.

La dernière étape est de configurer BGP dans l’instance private pour échanger les routes avec le site distant :

routing-instances {
    private {
        routing-options {
            router-id 1.0.3.2;
            maximum-paths 16;
        }
        protocols {
            bgp {
                preference 140;
                log-updown;
                group v4-VPN {
                    type external;
                    local-as 65003;
                    hold-time 6;
                    neighbor 2001:db8:ff::6 peer-as 65001;
                    multipath;
                    export [ NEXT-HOP-SELF OUR-ROUTES NOTHING ];
                }
            }
        }
    }
}

Le filtre d’export OUR-ROUTES doit sélectionner les routes à publier aux autres sites. Par exemple :

policy-options {
    policy-statement OUR-ROUTES {
        term 10 {
            from {
                protocol ospf3;
                route-type internal;
            }
            then {
                metric 0;
                accept;
            }
        }
    }
}

La configuration pour les autres terminaisons est similaire. La version complète est disponible sur GitHub. Une fois les sessions BGP opérationnelles, les routes des autres sites sont apprises localement. Par exemple, voici la route pour 2001:db8:­a1::/64:

> show route 2001:db8:a1::/64 protocol bgp table private.inet6.0 best-path

private.inet6.0: 15 destinations, 19 routes (15 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

2001:db8:a1::/64   *[BGP/140] 01:12:32, localpref 100, from 2001:db8:ff::6
                      AS path: 65001 I, validation-state: unverified
                      to 2001:db8:ff::6 via st0.1
                    > to 2001:db8:ff::14 via st0.2

Elle a été apprise de V1-1 (via st0.1) et V1-2 (via st0.2). Elle fait partie de l’instance de routage private mais les paquets encapsulés sont matérialisés dans l’instance de routage public. Il n’y a pas besoin d’échanger de routes entre ces deux instances pour que cela soit fonctionnel. L’étanchéité est donc assurée et le VPN ne peut pas servir de passerelle entre l’intérieur et l’extérieur. Il aurait été possible d’utiliser des règles de filtrage pour obtenir le même effet mais cette séparation simplifie le routage et évite qu’un problème de configuration se transforme en un désastre de sécurité.

VPN routé avec Linux

Depuis Linux 3.15, une configuration similaire est possible en utilisant les interfaces « VTI » (virtual tunnel interface)3. Tout d’abord, créons un espace de noms « privé » :

# ip netns add private
# ip netns exec private sysctl -qw net.ipv6.conf.all.forwarding=1

Les interfaces constituant le domaine « privé » doivent être déplacées dans ce nouvel espace de noms (aucune IP n’est configurée car nous utilisons les adresses locales au lien) :

# ip link set netns private dev eth1
# ip link set netns private dev eth2
# ip netns exec private ip link set up dev eth1
# ip netns exec private ip link set up dev eth2

Ensuite, nous créons l’interface tunnel vti6 (similaire à st0.1 dans l’exemple JunOS) :

# ip tunnel add vti6 \
   mode vti6 \
   local 2001:db8:1::1 \
   remote 2001:db8:3::2 \
   key 6
# ip link set netns private dev vti6
# ip netns exec private ip addr add 2001:db8:ff::6/127 dev vti6
# ip netns exec private sysctl -qw net.ipv4.conf.vti6.disable_policy=1
# ip netns exec private sysctl -qw net.ipv4.conf.vti6.disable_xfrm=1
# ip netns exec private ip link set vti6 mtu 1500
# ip netns exec private ip link set vti6 up

L’interface tunnel est créée dans l’espace de noms initial et déplacé dans celui « privé ». L’espace de noms d’origine est mémorisé par l’interface et sera utilisé pour recevoir et envoyer les paquets encapsulés. Tout paquet passant dans l’interface aura temporairement la marque 6 qui sera utilisée pour trouver la politique IPsec configurée par la suite4. Le noyau met en place un MTU assez faible pour tenir compte de toutes les protocoles et algorithmes possibles. Nous le rétablissons à 1500 et laissons le PMTUD jouer son rôle.

La configuration de strongSwan est la suivante5 :

conn V3-2
  left        = 2001:db8:1::1
  leftsubnet  = ::/0
  right       = 2001:db8:3::2
  rightsubnet = ::/0
  authby      = psk
  mark        = 6
  auto        = route
  keyexchange = ikev2
  keyingtries = %forever
  ike         = aes256gcm16-prfsha384-ecp384!
  esp         = aes256gcm16-prfsha384-ecp384!
  mobike      = no

Le démon IKE configure la politique de sécurité adéquate dans le noyau :

$ ip xfrm policy
src ::/0 dst ::/0
        dir out priority 399999 ptype main
        mark 0x6/0xffffffff
        tmpl src 2001:db8:1::1 dst 2001:db8:3::2
                proto esp reqid 1 mode tunnel
src ::/0 dst ::/0
        dir fwd priority 399999 ptype main
        mark 0x6/0xffffffff
        tmpl src 2001:db8:3::2 dst 2001:db8:1::1
                proto esp reqid 1 mode tunnel
src ::/0 dst ::/0
        dir in priority 399999 ptype main
        mark 0x6/0xffffffff
        tmpl src 2001:db8:3::2 dst 2001:db8:1::1
                proto esp reqid 1 mode tunnel
[…]

Cette politique s’applique quelle que soit la source et la destination tant que la marque de firewall est égale à 6, ce qui correspond à ce qui est configuré au niveau de l’interface tunnel.

La dernière étape est de configurer BGP pour l’échange des routes. Nous utilisons BIRD à cet effet :

router id 1.0.1.1;
protocol device {
   scan time 10;
}
protocol kernel {
   persist;
   learn;
   import all;
   export all;
   merge paths yes;
}
protocol bgp IBGP_V3_2 {
   local 2001:db8:ff::6 as 65001;
   neighbor 2001:db8:ff::7 as 65003;
   import all;
   export where ifname ~ "eth*";
   preference 160;
   hold time 6;
}

Une fois que BIRD a démarré dans l’espace de noms « privé », les routes distantes sont apprises :

$ ip netns exec private ip -6 route show 2001:db8:a3::/64
2001:db8:a3::/64 proto bird metric 1024
        nexthop via 2001:db8:ff::5  dev vti5 weight 1
        nexthop via 2001:db8:ff::7  dev vti6 weight 1

Cette route a été apprise depuis V3-1 (à travers vti5) et V3-2 (à travers vti6). Comme avec JunOS, nous n’avons copié aucune route entre les espaces de noms. Ceux-ci sont isolés. Ainsi, le VPN ne peut pas servir de passerelle entre les deux domaines. Cela nous assure qu’un problème de configuration (par exemple, démon IKE qui ne démarre pas) n’entraînera pas une fuite accidentelle des paquets internes.

En bonus, le trafic en clair est observable avec tcpdump sur l’interface tunnel :

$ ip netns exec private tcpdump -pni vti6 icmp6
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on vti6, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
20:51:15.258708 IP6 2001:db8:a1::1 > 2001:db8:a3::1: ICMP6, echo request, seq 69
20:51:15.260874 IP6 2001:db8:a3::1 > 2001:db8:a1::1: ICMP6, echo reply, seq 69

La configuration complète est disponible sur GitHub. La documentation de strongSwan contient aussi une page dédiée aux VPN routés.


  1. Libreswan est une alternative qui devrait fonctionner de manière identique pour les besoins de cet article. 

  2. fwd est utilisé pour les paquets arrivant pour une adresse non locale. Cela ne fait de sens qu’en mode transport et il s’agit d’un concept propre à Linux. 

  3. Les interfaces VTI ont été introduites dans Linux 3.6 (pour IPv4) et Linux 3.12 (pour IPv6). La possibilité de les changer d’espace de noms est disponible depuis Linux 3.15. 

  4. La marque est mise en place juste le temps de regarder la politique de sécurité à appliquer. Elle n’affecte donc pas les autres usages possibles (filtrage, routage). Netfilter peut également placer une marque et il convient donc de s’assurer qu’il n’y a pas de conflit possible. 

  5. Les algorithmes de chiffrement utilisés sont les plus robustes compatibles avec JunOS. La documentation de strongSwan contient une liste complète des algorithmes disponibles ainsi que des recommendations concernant la sécurité

13 September, 2017 08:20AM by Vincent Bernat

hackergotchi for Debian France

Debian France

Mini-debconf 2017 à Toulouse au Capitole du Libre

L'association Debian France [1] organise une mini-debconf à Toulouse. Cet évènement accueillera toutes les personnes intéressées par le projet Debian avec une série de conférences et d'ateliers autour de ce thème. Cette mini-debconf aura lieu en même temps et au même endroit que le Capitole du Libre [2] les 18 et 19 novembre 2017 à ENSEEIHT : 26 rue Pierre-Paul Riquet à Toulouse.

Nous aimerions avoir la moitié des conférences en anglais, les anglophones sont donc les bienvenus !

Les conférences et ateliers seront programmés sur la même grille que les conférences du Capitole du Libre. Il sera, ainsi, aisé de basculer de la mini-debconf au capitole du libre et inversement bien sur ;)

Les propositions de conférences sont ouvertes, vous pouvez vous inscrire par mail à minidebconf[at]france[dot]debian[dot]net et sur la page wiki [3]. Date limite pour soumettre une conférence : le 30 septembre 2017

13 September, 2017 07:29AM

September 10, 2017

hackergotchi for Charles Plessy

Charles Plessy

Résumé de la discussion sur les clés hors ligne.

Le mois dernier il y a eu une discussion intéressante au sujet des clés GnuPG hors ligne et de leurs supports de stockage, sur la liste debian-project@l.d.o. J'ai tenté de résumer la discussion dans le wiki Debian, un particulier en créant deux nouvelles pages.

10 September, 2017 12:06PM

August 20, 2017

hackergotchi for Vincent Bernat

Vincent Bernat

Fonctionnement de la table de routage IPv6 sous Linux

En bref: Linux stocke les tables de routage IPv6 à l’aide d’arbres radix. Les performances obtenues (450 ns pour une vue complète d’Internet — 40 000 routes) sont inférieures à IPv4 (50 ns pour une vue complète — 500 000 routes) mais l’utilisation mémoire reste honnête (20 Mio pour la vue complète).


Précédemment, nous avions regardé comment fonctionnait la table de routage IPv4 sous Linux. Qu’en est-il de l’implémentation pour IPv6 ?

Arbre de recherche

Chercher un préfixe dans une table de routage revient à trouver l’entrée la plus spécifique correspondant à la destination souhaitée. Une structure courante pour cette tâche est le trie, un arbre de recherche pour lequel chaque nœud est préfixé par son père.

Pour IPv4, Linux utilise un arbre doublement compressé (appelé LPC-trie), offrant de bonnes performances avec un usage mémoire faible. Pour IPv6, Linux emploie le plus classique arbre radix (encore appelé trie Patricia). Il y a trois raisons pour ne pas avoir recyclé la solution utilisée pour IPv4 :

  • L’implémentation IPv6 (introduite dans Linux 2.1.8, 1996) est antérieure à celle pour IPv4 qui date de Linux 2.6.13 (commit 19baf839ff4a).
  • Les fonctionnalités offertes sont différentes. Notamment, IPv6 intègre la possibilité d’un routage par l’adresse source1 (depuis Linux 2.1.120, 1998).
  • L’espace d’adressage IPv4 est beaucoup plus dense que celui d’IPv6, ce qui rend la compression par niveau du trie particulièrement efficace.

À titre d’exemple, l’illustration ci-dessous montre un arbre radix codant 6 préfixes :

Arbre radix

Pour des explications plus détaillées sur les différents codages possibles d’une table de routage et des éclaircissements sur les arbres radix, jetez un œil sur les explications pour IPv4.

La figure ci-dessous montre la représentation en mémoire de l’arbre radix précédent. Chaque nœud correspond à une structure fib6_node. Quand un nœud a le drapeau RTN_RTINFO, il contient un pointeur vers une structure rt6_info contenant des informations sur le prochain saut.

Représentation mémoire d'une table de routage

La fonction fib6_lookup_1() parcourt l’arbre radix en deux étapes :

  1. parcours descendant pour localiser un candidat potentiel,
  2. vérification de la validité du candidat et recherche en arrière si besoin.

Voici une version légèrement simplifiée (sans routage par la source) :

static struct fib6_node *fib6_lookup_1(struct fib6_node *root,
                                       struct in6_addr  *addr)
{
    struct fib6_node *fn;
    __be32 dir;

    /* Step 1: locate potential candidate */
    fn = root;
    for (;;) {
        struct fib6_node *next;
        dir = addr_bit_set(addr, fn->fn_bit);
        next = dir ? fn->right : fn->left;
        if (next) {
            fn = next;
            continue;
        }
        break;
    }

    /* Step 2: check prefix and backtrack if needed */
    while (fn) {
        if (fn->fn_flags & RTN_RTINFO) {
            struct rt6key *key;
            key = fn->leaf->rt6i_dst;
            if (ipv6_prefix_equal(&key->addr, addr, key->plen)) {
                if (fn->fn_flags & RTN_RTINFO)
                    return fn;
            }
        }

        if (fn->fn_flags & RTN_ROOT)
            break;
        fn = fn->parent;
    }

    return NULL;
}

Mise en cache

Alors qu’IPv4 a perdu son cache dans Linux 3.6 (commit 5e9965c15ba8), IPv6 dispose toujours de ce mécanisme. Toutefois, les entrées sont placées directement dans l’arbre radix avec le drapeau RTF_CACHE et non dans une structure distincte.

Depuis Linux 2.1.30 (1997) et jusqu’à Linux 4.2 (commit 45e4fd26683c), quasiment toutes les recherches aboutissaient à la création d’une entrée dans le cache. Par exemple, un routeur voyant transiter un ping entre 2001:db8:1::1 et 2001:db8:3::1 en crée deux :

$ ip -6 route show cache
2001:db8:1::1 dev r2-r1  metric 0
    cache
2001:db8:3::1 via 2001:db8:2::2 dev r2-r3  metric 0
    cache

La fonction ip6_dst_gc() assure le nettoyage du cache avec les paramètres suivants :

$ sysctl -a | grep -F net.ipv6.route
net.ipv6.route.gc_elasticity = 9
net.ipv6.route.gc_interval = 30
net.ipv6.route.gc_min_interval = 0
net.ipv6.route.gc_min_interval_ms = 500
net.ipv6.route.gc_thresh = 1024
net.ipv6.route.gc_timeout = 60
net.ipv6.route.max_size = 4096
net.ipv6.route.mtu_expires = 600

Le ramasse-miette est activé au plus toutes les 500 ms lorsqu’il y a plus de 1024 entrées dans le cache ou au moins toutes les 30 secondes. Il ne tourne pas plus de 60 secondes, sauf s’il y a plus de 4096 entrées. Lorsqu’il tourne, il va d’abord effacer les entrées vieilles de plus de 30 secondes. Tant que le nombre d’entrées reste supérieur à 4096, il continue d’effacer les entrées de plus en plus récentes (mais pas plus récentes que 512 jiffies qui correspond à la valeur de gc_elasticity) avec une pause de 500 ms entre chaque passage.

Depuis Linux 4.2 (commit 45e4fd26683c), seules les exceptions PMTU provoquent la création d’une entrée dans le cache. Un routeur ne gèrant pas ces exceptions, seuls les hôtes auront (rarement) des entrées dans le cache. Martin KaFai Lau explique:

De toutes les routes IPv6 de type RTF_CACHE qui sont créées, le pourcentage qui a un MTU différent est très faible. Sur l’un de nos serveurs mandataires face à des utilisateurs finaux, seulement 1000 entrées sur 80 000 ont un MTU plus faible. En ce qui concerne le trafic dans notre DC, il n’y a pas d’exception MTU.

Voici à quoi ressemble une entrée dans le cache avec une exception PMTU :

$ ip -6 route show cache
2001:db8:1::50 via 2001:db8:1::13 dev out6  metric 0
    cache  expires 573sec mtu 1400 pref medium

Performance

Trois scénarios différents sont étudiés :

Extrait d’une vue complète d’Internet
Dans ce scénario, Linux se comporte comme un routeur connecté à plusieurs transitaires et disposant d’une vue « complète ». Actuellement, la taille d’une telle table de routage est légèrement supérieure à 40 000 routes.
Préfixes /48 saupoudrés linéairement avec différentes densités
Linux agit comme un routeur au cœur d’un datacentre. Chaque client ou baie obtient un ou plusieurs sous-réseau /48 qu’il convient d’aiguiller. Avec une densité de 1, les /48 sont contigus.
Préfixes /128 répartis aléatoirements dans un /108
Linux se comporte comme un routeur d’accès pour un réseau /64 dans lequel les hôtes obtiennent leur IP par auto-configuration. Si tous les hôtes partagent le même OUI, les 40 premiers bits sont fixes. Dans ce scénario, la table des voisins est convertie en routes par un processus externe et redistribué auprès des autres routeurs servant le même sous-réseau2.

Performance de la recherche

À l’aide d’un module noyau, il est possible de mesurer précisément le temps d’exécution3 de la fonction ip6_route_output_flags():

Profondeur maximale et temps de recherche

Obtenir des résultats satisfaisants s’avère complexe en raison de la taille de l’espace d’adressage. Aucun des scénarios ne dispose d’une route par défaut et les mesures ne sont conservées que lorsque la recherche aboutit à une solution4. Pour le scénario avec la vue complète, seules les adresses de 2400::/16 à 2a06::/16 sont utilisées (cela comprend plus de la moitié des routes). Pour le scénario avec les préfixes /128, l’intégralité du sous-réseau /108 est balayé. Pour le scénario avec les /48, le balayage est effectué depuis le premier /48 jusqu’au dernier. Pour chaque passage, 5000 adresses sont prises semi-aléatoirement. De nouveaux passages sont effectués jusqu’à atteindre 5000 recherches réussies ou 1 million de recherches au total.

La relation entre la profondeur maximale de l’arbre et le temps de recherche est partielle. Il m’est difficile d’expliquer la différence de performance entre les différentes densités du scénario en /48.

On peut toutefois observer deux points importants :

  • Avec une vue complète, le temps de recherche médian est de 450 ns. C’est environ 10 fois le budget pour expédier des paquets à 10 Gbps (environ 50 ns).
  • Avec une table de routage presque vide, le temps de recherche est de 150 ns. C’est encore au-dessus du budget pour une connexion à 10 Gbps.

Avec IPv4, le temps de recherche sur une table presque vide était d’environ 20 ns tandis qu’avec une vue complète (500 000 routes), il est d’environ 50 ns. Comment expliquer une telle différence ? Tout d’abord, la profondeur de l’arbre compressé en IPv4 est très faible (6 pour 500 000 routes) tandis que la profondeur de l’arbre radix avec 40 000 routes est d’environ 40.

Deuxièmement, bien que la fonction fib_lookup() pour IPv4 et la fonction ip6_route_output_flags() pour IPv6 ont des coûts fixes liés à l’évaluation des règles de routage, IPv4 dispose de plusieurs optimisations quand ces règles de routage n’ont pas été modifiées5. Ces optimisations sont retirées au premier changement. Dans ce cas, IPv4 est impacté de 30 ns. Cela laisse encore un désavantage de 100 ns pour IPv6.

Regardons où le temps CPU est dépensé pour chacune des deux fonctions. Voici un graphique de type flame graph pour la fonction IPv4 fib_lookup() :

Graphique flamegraph pour la recherche de routes en IPv4

Seulement la moitié du temps est dépensé dans le parcours d’arbre via la fonction fib_table_lookup(). Il convient de noter que cette fonction est en réalité exécutée deux fois : une fois pour la table local et une fois pour la table main. Le reste du temps consiste à évaluer les règles de routage (environ 30 ns). Le ratio est dépendant du nombre de routes insérées (1000 dans cet exemple).

Voici le graphique équivalent pour la fonction IPV6 ip6_route_output_flags() :

Graphique flamegraph pour la recherche de routes en IPv6

Grossièrement, la répartition du temps est la suivante :

  • 50% est dépensé dans le parcours de l’arbre pour la table main,
  • 15% est dépensé dans les verrous (IPv4 repose sur le mécanisme RCU, plus efficace),
  • 5% est dépensé dans le parcours de l’arbre pour la table local,
  • le reste du temps est dépensé dans l’évaluation des règles de routage (environ 100 ns)6.

Pourquoi l’évaluation des règles de routage est-elle notoirement plus lente en IPv6 ? Encore une fois, je n’ai pas de réponse franche sur ce point.

Historique

Le graphique suivant montre l’évolution des performances de Linux depuis le noyau 2.6.39 :

Progression des performances de recherche de routes pour IPv6

Tous les noyaux sont compilés avec GCC 4.9 (issu de Debian Jessie). Cette version est compatible avec des noyaux antiques ainsi qu’avec les noyaux les plus récents. La configuration du noyau est celle par défaut avec les options CONFIG_SMP, CONFIG_IPV6, CONFIG_IPV6_MULTIPLE_TABLES et CONFIG_IPV6_SUBTREES activées. D’autres options mineures sont activées pour permettre de prendre les mesures.

Il y a trois changements notables :

  • Avec Linux 3.1, Eric Dumazet retarde la copie des métriques pour corriger le partage involontaire entre toutes les entrées du cache (commit 21efcfa0ff27). Chaque route en cache dispose désormais de ces propres métriques, ce qui explique l’impact sur les performances pour les scénarios autres que celui en /128.
  • Avec Linux 3.9, Yoshifuji Hideaki retire l’enchevêtrement entre les entrées de routage et le sous-système des voisins (commit 887c95cc1da5). Cela aurait dû apporter un gain en performance.
  • Avec Linux 4.2, Martin KaFai Lau élimine la création des entrées dans le cache pour la plupart des routes à l’exception des routes dont le PMTU est différent du MTU de l’interface sous-jacente. Les gains proviennent essentiellement du commit 4b32b5ad31a6 et du commit 45e4fd26683c.

Performance des insertions

Une autre métrique intéressante est le temps d’insertion des routes. La mise en place de 40 000 routes se fait en moins de deux secondes. Pour certaines raisons, le temps d’insertion n’est plus linéaire au-delà et grimpe rapidement à 60 secondes pour un demi-million de routes.

Temps d'insertion

Malgré sa logique plus complexe pour insérer des routes, le sous-système IPv4 est capable d’insérer 2 millions de routes en moins de 10 secondes.

Utilisation mémoire

Les nœuds de l’arbre radix (struct fib6_node) et les informations de routage (struct rt6_info) sont allouées via l’allocateur slab7. Il est donc possible d’extraire du fichier /proc/slabinfo la quantité de mémoire utilisée à condition de démarrer le noyau avec l’option slab_nomerge :

# sed -ne 2p -e '/^ip6_dst/p' -e '/^fib6_nodes/p' /proc/slabinfo | cut -f1 -d:
♯  name            <active_objs> <num_objs> <objsize> <objperslab> <pagesperslab>
fib6_nodes         76101  76104     64   63    1
ip6_dst_cache      40090  40090    384   10    1

Dans l’exemple ci-dessus, la mémoire utilisée est de 76104×64+40090×384 octets (environ 20 Mio). Le nombre de struct rt6_info correspond au nombre de routes tandis que le nombre de nœuds est environ le double du nombre de routes :

Nœuds

La quantité de mémoire utilisée est donc simplement prévisible. Elle est également très raisonnable puisque quasiment n’importe quelle plateforme actuelle peut stocker plusieurs vues complètes (20 Mio chacune) :

Utilisation mémoire

L’arbre de recherche utilisé par IPv4 est plus efficace : alors qu’IPv6 nécessite 512 Mio pour un million de routes, IPv4 se contente de 128 Mio. Cela provient principalement de la différence de taille entre la structure rt6_info (336 bytes) pour IPv6 et la structure fib_alias (48 bytes) pour IPv4 qui stocke une bonne partie des informations sur le prochain saut dans des structures fib_info partagées entre les différentes entrées.

Conclusion

Les points à retenir sont :

  • un noyau 4.2 ou plus récent est nécessaire pour éviter la mise en cache excessive,
  • le temps de recherche d’une route est supérieur à IPv4 (d’un ordre de grandeur),
  • l’option CONFIG_IPV6_MULTIPLE_TABLES implique un coût fixe de 100 ns,
  • l’utilisation mémoire reste raisonnable (20 Mio pour 40 000 routes).

Comparé à IPv4, IPv6 dans Linux ne suscite pas le même intérêt, notamment en terme d’optimisations. Heureusement, les choses s’améliorent avec son adoption graduelle et son utilisation à l’échelle.


  1. Pour un préfixe destination, il est possible d’y attacher des préfixes sources :

    ip -6 route add 2001:db8:1::/64 \
      from 2001:db8:3::/64 \
      via fe80::1 \
      dev eth0
    

    La recherche se fait d’abord sur la destination puis sur la source. 

  2. Ce n’est pas le scénario classique où Linux agit comme une simple passerelle. Dans ce cas, la table de routage ne contiendrait que le préfixe /64 et la table des voisins contiendrait les informations sur chaque membre du réseau. 

  3. Les mesures sont faites dans une machine virtuelle disposant d’un seul vCPU. Le CPU hôte est un Intel Core i5-4670K tournant à une fréquence de 3,7 GHz pendant l’expérimentation (le gouverneur CPU est configuré en mode performance). Les mesures sont sérialisées. De nombreuses recherches sont effectuées et la valeur reportée est la médiane. Chaque recherche est chronométrée à l’aide du TSC

  4. Le destin de la plupart des paquets est d’atteindre une destination. Il semble donc plus représentatif de ne conserver que les recherches réussies. Toutefois, cela signifie que le code correspondant à la recherche en arrière n’est jamais exécuté dans les scénarios avec les /128 et /48. Ajouter une route par défaut donne des résultats très différents et rend difficile l’exploration de l’espace d’adressage. 

  5. Les mêmes optimisations seraient appliquables à IPv6 mais personne ne s’est encore penché dessus. 

  6. Retirer le support des règles de routage retire effectivement ces 100 ns. 

  7. Il y a aussi des pointeurs propres à chaque CPU alloués directement (4 octets par entrée et par CPU sur une architecture 64 bits). Nous ignorons ce détail. 

20 August, 2017 04:53PM by Vincent Bernat

July 03, 2017

Progression des performances de la table de routage IPv4 sous Linux

En bref : Linux 2.6.39, 3.6 et 4.0 apportent un progrès notable sur les performances de la table de routage IPv4.


Dans un précédent article, j’expliquais comment Linux stockait les routes dans un arbre compressé pour obtenir d’excellents résultats sur les temps de recherche. Le graphique suivant montre la progression des performances à travers les époques :

Performance de la table de routage IPv4

Deux scénarios sont testés :

  • 500 000 routes extraites d’un routeur Internet (la moitié étant des /24)
  • 500 000 routes /32 réparties consécutivement dans 4 sous-réseaux distincts

Tous les noyaux sont compilés avec GCC 4.9 (issu de Debian Jessie). Cette version est compatible avec des noyaux antiques1 ainsi qu’avec les noyaux les plus récents. La configuration du noyau utilisée est celle par défaut avec les options CONFIG_SMP et CONFIG_IP_MULTIPLE_TABLES activées (sans toutefois utiliser de règles de routage). D’autres options mineures sont activées pour permettre de prendre les mesures.

Le banc d’essai se déroule dans une machine virtuelle utilisant un seul vCPU2. Le CPU hôte est un Intel Core i5-4670K et le gouverneur CPU est configuré en mode « performance ». Les mesures sont faites par un module noyau appelant la fonction fib_lookup() en boucle en variant les destinations. Le chronométrage de chacune des 100 000 itérations est effectuée par la TSC et convertie en nanosecondes en se basant sur une fréquence d’horloge arbitraire. La valeur médiane est retenue.

Quelques noyaux apportent un progrès notable :

  • Avec Linux 2.6.39, commit 3630b7c050d9, David Miller retire l’implémentation basée sur des tables de hachage pour utiliser des arbres compressés (disponible sous forme d’option à la compilation depuis Linux 2.6.13). Cela provoque une légère régression dans le cas des routes en /32 mais améliore grandement les performances dans le cas général.

  • Avec Linux 3.0, commit 281dc5c5ec0f, l’amélioration n’est pas liée à un changement dans le sous-système réseau. Linus Torvalds a désactivé l’optimisation en taille qui était utilisée par défaut. Cette option devait permettre de rendre le cache des instructions plus efficace mais les compilateurs généraient cependant un code plus lent sur x86.

  • Avec Linux 3.6, commit f4530fa574df, David Miller ajoute une optimisation destinée à ne plus évaluer les règles de routage quand elles n’ont pas été modifiées. À partir de cette version, l’option CONFIG_IP_MULTIPLE_TABLES ne dégrade plus les performances à moins de configurer explicitement des règles de routage. Cette version retire également le cache des routes (commit 5e9965c15ba8). Toutefois, cela n’a pas d’effet sur les mesures car l’appel direct à fib_lookup() contourne ce cache.

  • Avec Linux 4.0, notamment le commit 9f9e636d4f89, Alexander Duyck réorganise l’algorithme de recherche des routes pour en augmenter les performances. Le résultat est probant !

  • Avec Linux 4.1, commit 0ddcf43d5d4a, Alexander Duyck fusionne les tables local et main quand aucune règle de routage n’est utilisée. Pour le trafic non local, ces deux tables étaient successivement consultées.


  1. Certains anciens noyaux ne compilent plus avec les outils actuels à moins d’appliquer de petits correctifs

  2. Les noyaux sont toutefois compilés avec l’option CONFIG_SMP pour activer le mécanisme RCU hiérarchique afin de suivre des chemins de code similaires aux routeurs multi-cœurs. Toutefois, tout progrès sur le parallélisme passe inaperçu. 

03 July, 2017 01:25PM by Vincent Bernat

June 21, 2017

Fonctionnement de la table de routage IPv4 sous Linux

En bref : Avec une implémentation des tables de routage IPv4 utilisant les tries « LPC », Linux offre de bonnes performances pour la recherche de routes (50 ns pour une vue complète d’Internet). L’utilisation mémoire est de plus très modérée (64 Mio de mémoire suffisent pour 500 000 routes).


Une étape importante du voyage d’un datagramme IPv4 à l’intérieur du noyau Linux est la recherche de la route à utiliser via la fonction fib_lookup(). À partir des informations essentielles concernant le datagramme (addresses IP source et destination, interfaces, …), cette fonction doit fournir rapidement une décision. Quelques unes des options possibles sont :

  • livraison locale (RTN_LOCAL),
  • routage via un intermédiaire fourni (RTN_UNICAST),
  • destruction sans notification (RTN_BLACKHOLE).

Depuis la version 2.6.39, Linux stocke les routes dans un arbre préfixe compressé (commit 3630b7c050d9). Auparavant, un cache des routes était maintenu mais celui-ci a été retiré1 de Linux 3.6.

Recherche d’une route dans un trie

Rechercher une route dans une table de routage revient à trouver le préfixe le plus spécifique correspondant à la destination. Considérons par exemple la table de routage suivante :

$ ip route show scope global table 100
default via 203.0.113.5 dev out2
192.0.2.0/25
        nexthop via 203.0.113.7  dev out3 weight 1
        nexthop via 203.0.113.9  dev out4 weight 1
192.0.2.47 via 203.0.113.3 dev out1
192.0.2.48 via 203.0.113.3 dev out1
192.0.2.49 via 203.0.113.3 dev out1
192.0.2.50 via 203.0.113.3 dev out1

Voici quelques exemples de recherches et les décisions associées :

IP destination Prochain saut
192.0.2.49 203.0.113.3 via out1
192.0.2.50 203.0.113.3 via out1
192.0.2.51 203.0.113.7 via out3 or 203.0.113.9 via out4 (ECMP)
192.0.2.200 203.0.113.5 via out2

Une structure très courante pour rechercher une route est le trie, une structure de recherche en arbre où chaque nœud a son père pour préfixe.

Recherche dans un trie simple

Le trie suivant encode la table de routage exposée ci-dessus :

Simple routing trie

À tout moment, la longueur du préfixe correspond à la profondeur actuelle et le préfixe lui-même correspond au chemin depuis la racine.

Une recherche dans un tel trie est simple. À chaque étape, récupérer le nème bit de l’adresse IPn est la profondeur actuelle dans le trie. Si celui-ci est 0, continuer avec le fils de gauche. Sinon, continuer avec celui de droite. Si un fils est manquant, remonter dans l’arbre jusqu’à trouver une entrée de routage. Par exemple, pour 192.0.2.50, le parcours de l’arbre se termine sur la feuille correspondante. Par contre, pour 192.0.2.50, lorsque le nœud 192.0.2.50/31 est atteint, il n’y a pas de fils à droite. On remonte donc l’arbre jusqu’à trouver l’entrée 192.0.2.0/25.

Ajouter ou retirer des routes est trivial. Du point de vue de la performance, la profondeur étant bornée par 32, la recherche se fait en temps constant par rapport au nombre de routes.

Quagga est un exemple de logiciel de routage utilisant toujours cette approche.

Recherche dans un trie compressé

Dans l’exemple précédent, la plupart des nœuds n’ont qu’un seul fils. Cela entraîne beaucoup de comparaisons bit à bit ainsi qu’un usage sous-optimal de la mémoire. Pour résoudre ce problème, il est possible de compresser les chemins : chaque nœud ayant un fils unique (et n’hébergeant par une entrée de routage) est supprimé. Les nœuds restants gagnent une propriété supplémentaire indiquant le nombre de bits en entrée qui doivent être ignorés. Un tel trie est aussi connu sous le nom d’arbre Patricia ou d’arbre radix. Voici la version avec des chemins compressés du trie précédent :

Arbre Patricia

Parce que certains bits ont été ignorés, une vérification finale est nécessaire pour s’assurer que l’entrée trouvée correspond à l’IP recherchée. Dans le cas contraire, on considère que l’entrée n’a pas été trouvée et on remonte l’arbre pour trouver une route adéquate. La figure ci-dessous montre deux adresses IP qui aboutissent à la même feuille :

Recherche dans un arbre Patricia

La réduction de la profondeur du trie compense la complexité supplémentaire résultant de la nécessité de gérer les faux positifs. L’insertion et la suppression de routes restent relativement aisées.

De nombreux systèmes de routage utilisent des arbres Patricia :

Recherche dans un trie doublement compressé

En plus de la compression le long des chemins, il est possible de compresser certains sous-arbres2. Cela consiste à détecter les sous-arbres densément peuplés et de les remplacer par un unique nœud contenant un vecteur de 2k fils. Ce nœud consomme donc k bits en entrée au lieu d’un seul. Par exemple, voici une version doublement compressée de notre trie précédent :

Trie doublement compressé

Un tel trie est appelé trie LC (level compressed trie) ou trie LPC (level and path compressed trie). Il offre des performances plus élevées par rapport à un arbre radix.

Une heuristique est utilisée pour décider combien de bits un nœud doit traiter. Linux considère que si le ratio du nombre de fils non vides sur le nombre total de fils est supérieur à 50% quand le nœud traite un bit supplémentaire, alors le bit en question est alloué au nœud. Par contre, si le ratio est actuellement inférieur à 25%, le nœud perd la responsabilité d’un bit. Ces valeurs ne sont pas configurables.

L’insertion et la suppression d’une route devient une tâche beaucoup plus complexe mais la temps de recherche est également sensiblement réduit.

Implémentation sous Linux

L’implémentation pour IPv4 existe depuis Linux 2.6.13 (commit 19baf839ff4a) et est utilisée par défaut depuis la version 2.6.39 (commit 3630b7c050d9).

Voici la représentation en mémoire de notre table de routage3 :

Représentation en mémoire d'un trie

Plusieurs structures sont utilisées :

  • struct fib_table représente une table de routage,
  • struct trie représente un trie,
  • struct key_vector représente un nœud interne (quand bits est différent de 0) ou une feuille,
  • struct fib_info contient des attributs partagés par plusieurs routes (comme l’adresse du prochain saut ou l’interface de sortie),
  • struct fib_alias assure le lien entre les feuilles et les structures fib_info.

Le trie peut etre visualisé à travers /proc/net/fib_trie:

$ cat /proc/net/fib_trie
Id 100:
  +-- 0.0.0.0/0 2 0 2
     |-- 0.0.0.0
        /0 universe UNICAST
     +-- 192.0.2.0/26 2 0 1
        |-- 192.0.2.0
           /25 universe UNICAST
        |-- 192.0.2.47
           /32 universe UNICAST
        +-- 192.0.2.48/30 2 0 1
           |-- 192.0.2.48
              /32 universe UNICAST
           |-- 192.0.2.49
              /32 universe UNICAST
           |-- 192.0.2.50
              /32 universe UNICAST
[...]

Pour les nœuds internes, les trois nombres suivant le préfixe sont :

  1. le nombre de bits consommés par ce nœud,
  2. le nombre de fils qui ne gèrent qu’un seul bit,
  3. le nombre de fils vides.

De plus, si le noyau a été configuré avec l’option CONFIG_IP_FIB_TRIE_STATS, des statistiques sur la structure sont disponibles dans /proc/net/fib_triestat4:

$ cat /proc/net/fib_triestat
Basic info: size of leaf: 48 bytes, size of tnode: 40 bytes.
Id 100:
        Aver depth:     2.33
        Max depth:      3
        Leaves:         6
        Prefixes:       6
        Internal nodes: 3
          2: 3
        Pointers: 12
Null ptrs: 4
Total size: 1  kB
[...]

Quand une table de routage est très dense, un nœud peut gérer de nombreux bits. Par exemple, si une table de routage contient un million d’entrées /32 placées dans un /12, un seul nœud interne peut gérer 20 bits. Dans ce cas, la recherche se réduit à récupérer l’élément adéquat dans un tableau.

Le graphique suivant montre le nombre de nœuds internes utilisés par rapport au nombre de routes insérées. Différents scénarios sont envisagés (routes provenant d’une vue complète d’Internet, routes /32 réparties sur 4 sous-réseaux différents avec des densités variées). Lorsque les routes sont denses, le nombre de nœuds internes est très réduit.

Nœuds internes et pointeurs nuls

Performance

À quel point la recherche d’une route est-elle performante ? La profondeur maximale du trie reste limité (environ 6 pour une vue complète d’Internet) ce qui rend la recherche particulièrement rapide. À l’aide d’un petit module noyau, il est possible de mesurer précisément5 le temps utilisé par la fonction fib_lookup() :

Profondeur maximale et temps de recherche

Le temps de recherche est empiriquement lié à la profondeur maximale. Quand la table de routage est densément peuplée, la profondeur maximale est limitée et les temps de recherche sont rapides.

Pour router à 10 Gbps, le budget pour le traitement d’un paquet est d’environ 50 ns. C’est aussi le temps nécessaire pour rechercher une route dans certains scénarios. Il n’est donc pas possible de router à pleine vitesse avec un seul cœur. Toutefois, les résultats restent très bons.

Les mesures sont faites avec un noyau Linux 4.11 empaqueté dans Debian unstable. Pour des chiffres concernant différentes versions du noyau, jetez un œil à l’article « Progression des performances de la table de routage IPv4 sous Linux ».

Un autre chiffre intéressant est le temps pour insérer un grand nombre de routes dans le noyau. Linux est également particulièrement efficace dans ce domaine puisque deux millions de routes sont insérées en moins de 10 secondes :

Temps d'insertion

Utilisation mémoire

La quantité de mémoire utilisée est indiquée directement dans le fichier /proc/net/fib_triestat. Cela ne prend pas en compte l’espace utilisé par les structures fib_info. Toutefois, celles-ci sont normalement peu nombreuses (une par saut possible). Comme on peut le voir sur le graphique ci-dessous, la quantité de mémoire utilisée est linéaire avec le nombre de routes insérées, quelle que soit la forme des routes.

Utilisation mémoire

Les résultats sont très bons : deux millions de routes tiennent dans 256 Mio !

Règles de routage

À moins d’être configuré sans l’option CONFIG_IP_MULTIPLE_TABLES, Linux gère plusieurs tables de routage et dispose d’un système de règles pour choisir la table à utiliser. Ces règles peuvent être configurées avec ip rule. Par défaut, il en existe trois :

$ ip rule show
0:      from all lookup local
32766:  from all lookup main
32767:  from all lookup default

Linux va d’abord utiliser la table local et en cas d’échec se rabattre sur main puis default.

Tables par défaut

La table local contient les routes pour la livraison locale :

$ ip route show table local
broadcast 127.0.0.0 dev lo proto kernel scope link src 127.0.0.1
local 127.0.0.0/8 dev lo proto kernel scope host src 127.0.0.1
local 127.0.0.1 dev lo proto kernel scope host src 127.0.0.1
broadcast 127.255.255.255 dev lo proto kernel scope link src 127.0.0.1
broadcast 192.168.117.0 dev eno1 proto kernel scope link src 192.168.117.55
local 192.168.117.55 dev eno1 proto kernel scope host src 192.168.117.55
broadcast 192.168.117.63 dev eno1 proto kernel scope link src 192.168.117.55

Cette table est gérée automatiquement par le noyau quand des adresses IP sont configurées. Regardons d’abord les trois dernières lignes. Quand l’adresse IP 192.168.117.55 a été configurée sur l’interface eno1, trois nouvelles routes ont été ajoutées automatiquement :

  • une route pour 192.168.117.55 pour la livraison locale en unicast,
  • une route pour 192.168.117.255 pour une livraison de type « broadcast »,
  • une route pour 192.168.117.0 pour une livraison de type « broadcast » vers l’adresse de réseau.

Quand 127.0.0.1 est configurée sur l’interface de loopback, des routes similaires sont ajoutées. Toutefois, une adresse de loopback reçoit un traitement spécial et le noyau ajoute également le sous-réseau entier à la table local. Cela permet d’utiliser n’importe quelle adresse dans 127.0.0.0/8 :

$ ping -c1 127.42.42.42
PING 127.42.42.42 (127.42.42.42) 56(84) bytes of data.
64 bytes from 127.42.42.42: icmp_seq=1 ttl=64 time=0.039 ms

--- 127.42.42.42 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.039/0.039/0.039/0.000 ms

La table main contient habituellement toutes les autres routes :

$ ip route show table main
default via 192.168.117.1 dev eno1 proto static metric 100
192.168.117.0/26 dev eno1 proto kernel scope link src 192.168.117.55 metric 100

La route default a été mise en place par un démon DHCP. La route connectée (scope link) a été ajoutée automatiquement par le noyau (proto kernel) lors de la configuration de l’adresse IP sur l’interface eno1.

La table default est vide et est rarement utilisée. Elle reste là depuis Linux 2.1.68 en hommage à la première tentative de routage avancé dans Linux 2.1.156.

Performance

Depuis Linux 4.1 (commit 0ddcf43d5d4a), quand les règles de routage ne sont pas modifiées, les tables main et local sont fusionnées en une seule table. De plus, depuis Linux 3.0 (commit f4530fa574df), sans règles spécifiques configurées, il n’y a pas d’impact sur les performances à utiliser un noyau supportant plusieurs tables de routage. Toutefois, dès qu’une nouvelle règle est ajoutée, quelques cycles CPU sont utilisés pour chaque datagramme à l’évaluation des règles. Voici une paire de graphiques démontrant l’impact des règles de routage sur les performances :

Impact des règles de routage sur les performances

La relation est linéaire quand le nombre de règles est entre 1 et 100 mais la pente augmente sensiblement au-delà. Le second graphique met en évidence l’impact négatif de la première règle de routage (environ 30 ns).

Une utilisation courante des règles de routage est la création de routeurs virtuels : les interfaces sont isolées en domaines et quand un datagramme entre par une interface du domaine A, la table de routage A est utilisée :

# ip rule add iif vlan457 table 10
# ip rule add iif vlan457 blackhole
# ip rule add iif vlan458 table 20
# ip rule add iif vlan458 blackhole

Les règles de type « blackhole » peuvent être supprimées si on s’assure qu’il y a toujours une règle par défaut dans chaque table de routage. Par exemple, on peut y ajouter une route par défaut qui rejette silencieusement tout datagramme. Une métrique importante est utilisée pour cohabiter avec une éventuelle route par défaut existante :

# ip route add blackhole default metric 9999 table 10
# ip route add blackhole default metric 9999 table 20
# ip rule add iif vlan457 table 10
# ip rule add iif vlan458 table 20

Pour réduire l’impact sur les performances quand de nombreuses règles de ce type sont utilisées, les interfaces peuvent être attachées à des instances VRF et une unique règle de routage permet de sélectionner la table de routage adéquate :

# ip link add vrf-A type vrf table 10
# ip link set dev vrf-A up
# ip link add vrf-B type vrf table 20
# ip link set dev vrf-B up
# ip link set dev vlan457 master vrf-A
# ip link set dev vlan458 master vrf-B
# ip rule show
0:      from all lookup local
1000:   from all lookup [l3mdev-table]
32766:  from all lookup main
32767:  from all lookup default

La règle spéciale l3mdev-table est ajoutée automatiquement lors de la définition de la première interface VRF. Cette règle sélectionne la table de routage associée à l’instance VRF à laquelle l’interface d’entrée (ou de sortie) a été attachée.

VRF a été introduit dans Linux 4.3 (commit 193125dbd8eb). Les performances ont été grandement améliorées dans Linux 4.8 (commit 7889681f4a6c). La règle de routage générique a également été introduite dans Linux 4.8 (commit 96c63fa7393d, commit 1aa6c4f6b8cd). La documentation du noyau contient des détails supplémentaires sur son utilisation.

Conclusion

Les points à retenir sont :

  • le temps de recherche d’une route augmente très peu avec le nombre de routes,
  • la recherche d’une route parmi des /32 densément distribuées est extrêmement rapide,
  • l’utilisation mémoire est très modérée (128 Mio par million de routes),
  • aucune optimisation n’est effectuée sur les règles de routage.

Pour IPv6, jetez un œil sur « Fonctionnement de la table de routage IPv6 sous Linux ».


  1. Le cache des routes était une cible facile pour des attaques par déni de service. Il était également supposément inefficace sur des sites importants bien que j’aie personnellement mesuré le contraire. 

  2. IP-address lookup using LC-tries”, IEEE Journal on Selected Areas in Communications, 17(6):1083-1092, Juin 1999. 

  3. Pour les nœuds internes, la structure key_vector est incluse dans une structure tnode. Cette dernière contient des informations jamais ou rarement utilisées pour une recherche, notamment la référence au père qui n’est généralement pas nécessaire pour remonter l’arbre car Linux mémorise le parent le plus proche dans une variable lors de la traversée initiale. 

  4. Une feuille peut contenir plusieurs préfixes (struct fib_alias est en réalité une liste). Le nombre de « préfixes » peut donc être supérieur au nombre de feuilles. Le système garde également quelques statistiques sur la répartition des nœuds selon le nombre de bits qu’ils consomment. Dans notre exemple, les trois nœuds internes utilisent tous 2 bits. 

  5. Les mesures sont faites dans une machine virtuelle équipée d’un seul CPU. Le CPU hôte est un Intel Core i5-4670K tournant à 3,7 GHz durant les mesures (le gouverneur CPU est configuré en mode performance). Une phase de chauffe est suivie par l’exécution chronométrée de 100 000 itérations. La TSC est utilisée pour mesurer le temps pris par chacune des itérations. Le résultat reporté sur le graphique est la médiane. 

  6. Histoire vraie : la documentation de cette première tentative est toujours présente dans les sources du noyau et explique l’utilisation de la classe de routage « default »

21 June, 2017 09:19AM by Vincent Bernat

May 03, 2017

VXLAN: BGP EVPN avec Cumulus Quagga

VXLAN est un protocole réseau permettant de transporter du trafic Ethernet au-dessus d’un réseau IP existant tout en supportant un nombre très elevé de locataires. Il est défini dans la RFC 7348. Pour une introduction dans le cadre de Linux, jetez un œil à mon article « VXLAN & Linux ».

Déploiement de VXLAN

Dans l’exemple de déploiement ci-dessus, des hyperviseurs hébergent des machines virtuelles appartenant à différents locataires. Chaque machine virtuelle a un accès un segment Ethernet virtuel propre à son locataire. Ces derniers s’attendent à obtenir un segment Ethernet classique : pas de restriction sur les adresses MAC1, un contrôle total sur l’adressage IP et la disponibilité du multicast.

Dans un déploiement à large échelle de VXLAN, il y a deux aspects cruciaux :

  1. la découverte des autres terminaisons (VTEP) partageant les mêmes segments VXLAN,
  2. la limitation des trames « BUM » (broadcast, unknown unicast and multicast) qui sont diffusées à l’ensemble des VTEP.

Une solution courante pour le premier point est d’utiliser le multicast. Le second point est généralement résolu par un apprentissage des adresses sources.

Introduction à BGP EVPN

BGP EVPN (RFC 7432 et draft-ietf-bess-evpn-overlay pour son application à VXLAN) est un protocole destiné à résoudre efficacement ces deux aspects sans reposer sur l’usage du multicast ni sur l’apprentissage des adresses sources.

BGP EVPN repose sur BGP (RFC 4271) et ses extensions MP-BGP (RFC 4760). BGP est le protocole de routage animant Internet. Via les extensions MP-BGP, il peut être utilisé pour transporter des informations d’accessibilité (NLRI) pour divers protocoles (IPv4, IPv6, L3 VPN et dans le cas qui nous intéresse, EVPN). EVPN est une famille spéciale permettant de publier des informations sur les adresses MAC et les équipements terminaux y donnant accès.

Il y a principalement deux types de routes qu’un VTEP peut publier à travers BGP EVPN :

  1. les VNI dont ils disposent localement (routes de type 3),
  2. les adresses MAC locales pour chacun des VNI (routes de type 2).

Le protocole couvre également d’autres aspects des segments Ethernet virtuels (informations concernant les voisins IP, mobilité des adresses MAC et attachement d’un segment Ethernet à plusieurs terminaisons2) que nous n’aborderons pas ici.

Usuellement, le déploiement de BGP EVPN utilise plusieurs réflecteurs de routes (à la fois pour la redondance et la montée en charge) comme illustré ci-dessous. Chaque VTEP ouvre une session BGP vers au moins deux réflecteurs, envoie les informations dont il dispose et réceptionne les informations disponibles. Cela permet de limiter le nombre de sessions BGP à configurer et maintenir.

Déploiement VXLAN avec des réflecteurs de routes

Par rapport aux autres solutions pour déployer VXLAN, BGP EVPN présente trois avantages :

  • interopérabilité avec les autres constructeurs (notamment Juniper et Cisco),
  • montée en charge éprouvée (un routeur BGP gère plusieurs millions de routes),
  • possibilité de mettre en place des politiques de distribution.

Sous Linux, Cumulus Quagga est une implémentation relativement complète de BGP EVPN (routes de type 3 pour la découverte de VTEP, routes de type 2 pour partager MAC et IP, mobilité des adresses MAC quand un hôte passe d’un VTEP à un autre) et ne nécessite que peu de configuration.

Il s’agit d’un dérivé de Quagga et est utilisé extensivement dans Cumulus Linux, une distribution réseau basée sur Debian et animant diverses marques de commutateurs. Dans le futur, l’implémentation de BGP EVPN sera reversé au projet FRR, un dérivé maintenu communautaire de Quagga3.

MISE À JOUR (08.2017) : Depuis la version 3.4.0, Cumulus est passé à FRR. La configuration présentée ici fonctionne également avec FRR 3.1 (actuellement non publié) en activant l’option de compilation --enable-cumulus.

Notons toutefois que cette implémentation de BGP EVPN ne prend actuellement en compte qu’IPv4.

Configuration des réflecteurs

Avant de configurer les VTEP, nous devons configurer les réflecteurs. Plusieurs solutions sont possibles, dont :

  • Cumulus Quagga,
  • GoBGP, une implémentation de BGP en Go,
  • Juniper JunOS.

Pour des raisons de fiabilité, il peut être intéressant de panacher les implémentations utilisées, celles-ci étant entièrement interopérables sans difficultés dans ce rôle.

Les configurations proposées sont très minimales. Il est possible de centraliser les politiques de distributions sur les réflecteurs (par exemple, les routes présentant telle communauté ne doivent être redistribuées que sur un certain type de VTEP).

Quagga

La configuration est simple. Le réflecteur utilise l’adresse 203.0.113.254.

router bgp 65000
  bgp router-id 203.0.113.254
  bgp cluster-id 203.0.113.254
  bgp log-neighbor-changes
  no bgp default ipv4-unicast
  neighbor fabric peer-group
  neighbor fabric remote-as 65000
  neighbor fabric capability extended-nexthop
  neighbor fabric update-source 203.0.113.254
  bgp listen range 203.0.113.0/24 peer-group fabric
  !
  ! Avec FRR, utiliser : address-family l2vpn evpn
  address-family evpn
   neighbor fabric activate
   neighbor fabric route-reflector-client
  exit-address-family
  !
  exit
!

Un groupe fabric est défini et nous utilisons une fonctionnalité intéressante de Cumulus Quagga permettant d’accepter des voisins sans avoir à les déclarer individuellement. Cela réduit la configuration nécessaire : tout client issu du réseau 203.0.113.0/24 et s’identifiant comme faisant partie de l’AS 65000 peut se connecter. Toutes les routes EVPN envoyées sont acceptées et réfléchies vers les autres clients.

Il n’est pas nécessaire de faire tourner Zebra, la partie de Quagga qui dialogue avec le noyau. Pour éviter que bgpd ne se plaigne de son absence, il convient de le démarrer avec le drapeau --no_kernel.

GoBGP

GoBGP est une implémentation de BGP en Go4. Il fournit une API de type RPC pour la configuration mais accepte également des fichiers de configuration classiques et est livré avec un client en ligne de commande.

Il est nécessaire de définir tous les voisins via l’API, le client en ligne de commande ou fichier de configuration construit à partir d’un gabarit (l’implémentation des voisins dynamiques est en cours)5. Voici une configuration pour un seul voisin :

global:
  config:
    as: 65000
    router-id: 203.0.113.254
    local-address-list:
      - 203.0.113.254
neighbors:
  - config:
      neighbor-address: 203.0.113.1
      peer-as: 65000
    afi-safis:
      - config:
          afi-safi-name: l2vpn-evpn
    route-reflector:
      config:
        route-reflector-client: true
        route-reflector-cluster-id: 203.0.113.254

Il est possible d’ajouter des voisins depuis la ligne de commande :

$ gobgp neighbor add 203.0.113.2 as 65000 \
>         route-reflector-client 203.0.113.254 \
>         --address-family evpn

Par défaut, GoBGP ne tente aucune interaction avec le noyau, ce qui nous convient parfaitement dans ce rôle.

Juniper JunOS

De nombreux produits Juniper peuvent jouer le rôle de réflecteur, notamment :

Le principal facteur est le CPU (type x86) et la mémoire. Le QFX5100 ne dispose pas de beaucoup de mémoire et ne pourra donc pas supporter de très gros déploiements sans utiliser une politique de distribution plus agressive.

Voici une configuration comparable à celle proposée pour Quagga :

interfaces {
    lo0 {
        unit 0 {
            family inet {
                address 203.0.113.254/32;
            }
        }
    }
}

protocols {
    bgp {
        group fabric {
            family evpn {
                signaling {
                    /* Do not try to install EVPN routes */
                    no-install;
                }
            }
            type internal;
            cluster 203.0.113.254;
            local-address 203.0.113.254;
            allow 203.0.113.0/24;
        }
    }
}

routing-options {
    router-id 203.0.113.254;
    autonomous-system 65000;
}

Configuration des VTEP

La seconde étape est de configurer les VTEP/hyperviseurs. Chaque VXLAN est assorti à un pont pour y placer les interfaces locales, comme illustré ci-dessous. Le pont gère les adresses MAC locales (notamment leur apprentissage par la source) tandis que l’interface VXLAN s’occupe des adresses MAC distantes (reçues via BGP EVPN).

Interface VXLAN et son pont

Les interfaces VXLAN sont créées avec le script suivant. L’apprentissage des adresses source est désactivé car superflu : BGP EVPN permet de synchroniser les FDB entre les hyperviseurs.

for vni in 100 200; do
    # Création de l'interface VXLAN
    ip link add vxlan${vni} type vxlan
        id ${vni} \
        dstport 4789 \
        local 203.0.113.2 \
        nolearning
    # Création du pont associé
    brctl addbr br${vni}
    brctl addif br${vni} vxlan${vni}
    brctl stp br${vni} off
    ip link set up dev br${vni}
    ip link set up dev vxlan${vni}
done
# Attacher les VM locales sur les segments appropriés
brctl addif br100 vnet10
brctl addif br100 vnet11
brctl addif br200 vnet12

La configuration de Cumulus Quagga est similaire à celle d’un réflecteur mais la directive advertise-all-vni indique à Quagga de publier l’ensemble des VNI présents localement :

router bgp 65000
  bgp router-id 203.0.113.2
  no bgp default ipv4-unicast
  neighbor fabric peer-group
  neighbor fabric remote-as 65000
  neighbor fabric capability extended-nexthop
  neighbor fabric update-source dummy0
  ! BGP sessions with route reflectors
  neighbor 203.0.113.253 peer-group fabric
  neighbor 203.0.113.254 peer-group fabric
  !
  ! Avec FRR, utiliser : address-family l2vpn evpn
  address-family evpn
   neighbor fabric activate
   advertise-all-vni
  exit-address-family
  !
  exit
!

Une fois la configuration mise en place, les instances partageant un même VNI doivent pouvoir communiquer entre elles. Si IPv6 est activé sur toutes les machines virtuelles, la commande ping permet de vérifier le bon fonctionnement de l’ensemble :

$ ping -c10 -w1 -t1 ff02::1%eth0
PING ff02::1%eth0(ff02::1%eth0) 56 data bytes
64 bytes from fe80::5254:33ff:fe00:8%eth0: icmp_seq=1 ttl=64 time=0.016 ms
64 bytes from fe80::5254:33ff:fe00:b%eth0: icmp_seq=1 ttl=64 time=4.98 ms (DUP!)
64 bytes from fe80::5254:33ff:fe00:9%eth0: icmp_seq=1 ttl=64 time=4.99 ms (DUP!)
64 bytes from fe80::5254:33ff:fe00:a%eth0: icmp_seq=1 ttl=64 time=4.99 ms (DUP!)

--- ff02::1%eth0 ping statistics ---
1 packets transmitted, 1 received, +3 duplicates, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.016/3.745/4.991/2.152 ms

Vérifications

Regardons point par point comment tous les éléments se sont combinés pour en arriver à ce résultat stupéfiant.

Récupération des informations sur les VXLAN

Sur chaque VTEP, Quagga doit obtenir la liste des interfaces VXLAN. La commande vtysh permet de vérifier ce point:

# show interface vxlan100
Interface vxlan100 is up, line protocol is up
  Link ups:       1    last: 2017/04/29 20:01:33.43
  Link downs:     0    last: (never)
  PTM status: disabled
  vrf: Default-IP-Routing-Table
  index 11 metric 0 mtu 1500
  flags: <UP,BROADCAST,RUNNING,MULTICAST>
  Type: Ethernet
  HWaddr: 62:42:7a:86:44:01
  inet6 fe80::6042:7aff:fe86:4401/64
  Interface Type Vxlan
  VxLAN Id 100
  Access VLAN Id 1
  Master (bridge) ifindex 9 ifp 0x56536e3f3470

Les deux points importants sont :

  • le VNI est 100,
  • le pont associé à l’interface est correctement détecté.

Quagga doit également récupérer pour chaque VXLAN les adresses MAC locales qui y sont attachées :

# show evpn mac vni 100
Number of MACs (local and remote) known for this VNI: 2
MAC               Type   Intf/Remote VTEP      VLAN
50:54:33:00:00:0a local  eth1.100
50:54:33:00:00:0b local  eth2.100

Sessions BGP

Chaque VTEP doit établir une session BGP vers les réflecteurs. Sur un VTEP, cela peut être vérifié avec vtysh :

# show bgp neighbors 203.0.113.254
BGP neighbor is 203.0.113.254, remote AS 65000, local AS 65000, internal link
 Member of peer-group fabric for session parameters
  BGP version 4, remote router ID 203.0.113.254
  BGP state = Established, up for 00:00:45
  Neighbor capabilities:
    4 Byte AS: advertised and received
    AddPath:
      L2VPN EVPN: RX advertised L2VPN EVPN
    Route refresh: advertised and received(new)
    Address family L2VPN EVPN: advertised and received
    Hostname Capability: advertised
    Graceful Restart Capabilty: advertised
[...]
 For address family: L2VPN EVPN
  fabric peer-group member
  Update group 1, subgroup 1
  Packet Queue length 0
  Community attribute sent to this neighbor(both)
  8 accepted prefixes

  Connections established 1; dropped 0
  Last reset never
Local host: 203.0.113.2, Local port: 37603
Foreign host: 203.0.113.254, Foreign port: 179

La commande donne les informations suivantes :

  • l’état de la session BGP est établie (Established),
  • la famille L2VPN EVPN est correctement publiée,
  • 8 routes sont reçues du réflecteur.

L’état des sessions BGP peut également être vérifié depuis les réflecteurs. Avec GoBGP, utilisez la commande suivante :

# gobgp neighbor 203.0.113.2
BGP neighbor is 203.0.113.2, remote AS 65000, route-reflector-client
  BGP version 4, remote router ID 203.0.113.2
  BGP state = established, up for 00:04:30
  BGP OutQ = 0, Flops = 0
  Hold time is 9, keepalive interval is 3 seconds
  Configured hold time is 90, keepalive interval is 30 seconds
  Neighbor capabilities:
    multiprotocol:
        l2vpn-evpn:     advertised and received
    route-refresh:      advertised and received
    graceful-restart:   received
    4-octet-as: advertised and received
    add-path:   received
    UnknownCapability(73):      received
    cisco-route-refresh:        received
[...]
  Route statistics:
    Advertised:             8
    Received:               5
    Accepted:               5

Avec JunOS, voici la commande équivalente :

> show bgp neighbor 203.0.113.2
Peer: 203.0.113.2+38089 AS 65000 Local: 203.0.113.254+179 AS 65000
  Group: fabric                Routing-Instance: master
  Forwarding routing-instance: master
  Type: Internal    State: Established
  Last State: OpenConfirm   Last Event: RecvKeepAlive
  Last Error: None
  Options: <Preference LocalAddress Cluster AddressFamily Rib-group Refresh>
  Address families configured: evpn
  Local Address: 203.0.113.254 Holdtime: 90 Preference: 170
  NLRI evpn: NoInstallForwarding
  Number of flaps: 0
  Peer ID: 203.0.113.2     Local ID: 203.0.113.254     Active Holdtime: 9
  Keepalive Interval: 3          Group index: 0    Peer index: 2
  I/O Session Thread: bgpio-0 State: Enabled
  BFD: disabled, down
  NLRI for restart configured on peer: evpn
  NLRI advertised by peer: evpn
  NLRI for this session: evpn
  Peer supports Refresh capability (2)
  Stale routes from peer are kept for: 300
  Peer does not support Restarter functionality
  NLRI that restart is negotiated for: evpn
  NLRI of received end-of-rib markers: evpn
  NLRI of all end-of-rib markers sent: evpn
  Peer does not support LLGR Restarter or Receiver functionality
  Peer supports 4 byte AS extension (peer-as 65000)
  NLRI's for which peer can receive multiple paths: evpn
  Table bgp.evpn.0 Bit: 20000
    RIB State: BGP restart is complete
    RIB State: VPN restart is complete
    Send state: in sync
    Active prefixes:              5
    Received prefixes:            5
    Accepted prefixes:            5
    Suppressed due to damping:    0
    Advertised prefixes:          8
  Last traffic (seconds): Received 276  Sent 170  Checked 276
  Input messages:  Total 61     Updates 3       Refreshes 0     Octets 1470
  Output messages: Total 62     Updates 4       Refreshes 0     Octets 1775
  Output Queue[1]: 0            (bgp.evpn.0, evpn)

Dans le cas où une session BGP ne s’établit pas, les journaux des différents démons BGP doivent en indiquer la cause.

Routes envoyées

Depuis chaque VTEP, Quagga doit envoyer :

  • une route de type 3 pour chaque VNI local,
  • une route de type 2 pour chaque adresse MAC locale.

Le meilleur endroit pour vérifier les routes envoyées est l’un des réflecteurs. Avec JunOS, la commande suivante affiche les routes reçues du VTEP dont l’IP est fournie :

> show route table bgp.evpn.0 receive-protocol bgp 203.0.113.2

bgp.evpn.0: 10 destinations, 10 routes (10 active, 0 holddown, 0 hidden)
  Prefix                  Nexthop              MED     Lclpref    AS path
  2:203.0.113.2:100::0::50:54:33:00:00:0a/304 MAC/IP
*                         203.0.113.2                  100        I
  2:203.0.113.2:100::0::50:54:33:00:00:0b/304 MAC/IP
*                         203.0.113.2                  100        I
  3:203.0.113.2:100::0::203.0.113.2/304 IM
*                         203.0.113.2                  100        I
  3:203.0.113.2:200::0::203.0.113.2/304 IM
*                         203.0.113.2                  100        I

Il y a une route de type 3 pour le VNI 100 et une autre pour le VNI 200. Il y a également deux routes de type 2 concernant deux adresses MAC associées au VNI 100. Le mot clef extensive permet obtenir davantage d’informations. Par exemple, voici une route de type 3 indiquant que 203.0.113.2 est un VTEP pour le VNI 1009 :

> show route table bgp.evpn.0 receive-protocol bgp 203.0.113.2 extensive

bgp.evpn.0: 11 destinations, 11 routes (11 active, 0 holddown, 0 hidden)
* 3:203.0.113.2:100::0::203.0.113.2/304 IM (1 entry, 1 announced)
     Accepted
     Route Distinguisher: 203.0.113.2:100
     Nexthop: 203.0.113.2
     Localpref: 100
     AS path: I
     Communities: target:65000:268435556 encapsulation:vxlan(0x8)
[...]

Et voici une route de type 2 indiquant la localisation de l’adresse MAC 50:54:33:00:00:0a pour le VNI 100:

> show route table bgp.evpn.0 receive-protocol bgp 203.0.113.2 extensive

bgp.evpn.0: 11 destinations, 11 routes (11 active, 0 holddown, 0 hidden)
* 2:203.0.113.2:100::0::50:54:33:00:00:0a/304 MAC/IP (1 entry, 1 announced)
     Accepted
     Route Distinguisher: 203.0.113.2:100
     Route Label: 100
     ESI: 00:00:00:00:00:00:00:00:00:00
     Nexthop: 203.0.113.2
     Localpref: 100
     AS path: I
     Communities: target:65000:268435556 encapsulation:vxlan(0x8)
[...]

Avec Quagga, la commande suivante permet d’obtenir des informations similaires :

# show bgp evpn route
BGP table version is 0, local router ID is 203.0.113.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal
Origin codes: i - IGP, e - EGP, ? - incomplete
EVPN type-2 prefix: [2]:[ESI]:[EthTag]:[MAClen]:[MAC]
EVPN type-3 prefix: [3]:[EthTag]:[IPlen]:[OrigIP]

   Network          Next Hop            Metric LocPrf Weight Path
Route Distinguisher: 203.0.113.2:100
*>i[2]:[0]:[0]:[48]:[50:54:33:00:00:0a]
                    203.0.113.2                   100      0 i
*>i[2]:[0]:[0]:[48]:[50:54:33:00:00:0b]
                    203.0.113.2                   100      0 i
*>i[3]:[0]:[32]:[203.0.113.2]
                    203.0.113.2                   100      0 i
Route Distinguisher: 203.0.113.2:200
*>i[3]:[0]:[32]:[203.0.113.2]
                    203.0.113.2                   100      0 i
[...]

Avec GoBGP, il convient d’utiliser cette commande :

# gobgp global rib -a evpn | grep rd:203.0.113.2:200
    Network  Next Hop             AS_PATH              Age        Attrs
*>  [type:macadv][rd:203.0.113.2:100][esi:single-homed][etag:0][mac:50:54:33:00:00:0a][ip:<nil>][labels:[100]]203.0.113.2                               00:00:17   [{Origin: i} {LocalPref: 100} {Extcomms: [VXLAN], [65000:268435556]}]
*>  [type:macadv][rd:203.0.113.2:100][esi:single-homed][etag:0][mac:50:54:33:00:00:0b][ip:<nil>][labels:[100]]203.0.113.2                               00:00:17   [{Origin: i} {LocalPref: 100} {Extcomms: [VXLAN], [65000:268435556]}]
*>  [type:macadv][rd:203.0.113.2:200][esi:single-homed][etag:0][mac:50:54:33:00:00:0a][ip:<nil>][labels:[200]]203.0.113.2                               00:00:17   [{Origin: i} {LocalPref: 100} {Extcomms: [VXLAN], [65000:268435656]}]
*>  [type:multicast][rd:203.0.113.2:100][etag:0][ip:203.0.113.2]203.0.113.2                               00:00:17   [{Origin: i} {LocalPref: 100} {Extcomms: [VXLAN], [65000:268435556]}]
*>  [type:multicast][rd:203.0.113.2:200][etag:0][ip:203.0.113.2]203.0.113.2                               00:00:17   [{Origin: i} {LocalPref: 100} {Extcomms: [VXLAN], [65000:268435656]}]

Routes reçues

Chaque VTEP doit recevoir de la part des réflecteurs les routes de type 2 et 3 concernant ses collègues. Cela peut être vérifié avec vtysh et la commande show bgp evpn route.

Quagga comprend-il correctement les routes reçues ? Pour vérifier la bonne interprétation des routes de type 3, nous utilisons la commande suivante pour voir l’association entre les VNI et les VTEP distants :

# show evpn vni
Number of VNIs: 2
VNI        VxLAN IF              VTEP IP         # MACs   # ARPs   Remote VTEPs
100        vxlan100              203.0.113.2     4        0        203.0.113.3
                                                                   203.0.113.1
200        vxlan200              203.0.113.2     3        0        203.0.113.3
                                                                   203.0.113.1

Pour les routes de type 2, l’association entre les MAC distantes et les VTEP peut être visualisée avec la commande suivante :

# show evpn mac vni 100
Number of MACs (local and remote) known for this VNI: 4
MAC               Type   Intf/Remote VTEP      VLAN
50:54:33:00:00:09 remote 203.0.113.1
50:54:33:00:00:0a local  eth1.100
50:54:33:00:00:0b local  eth2.100
50:54:33:00:00:0c remote 203.0.113.3

Programmation de la FDB dans le noyau

La dernière étape est de s’assurer que Quagga programme correctement les informations reçues dans le noyau. Cela peut se faire avec la commande bridge :

# bridge fdb show dev vxlan100 | grep dst
00:00:00:00:00:00 dst 203.0.113.1 self permanent
00:00:00:00:00:00 dst 203.0.113.3 self permanent
50:54:33:00:00:0c dst 203.0.113.3 self
50:54:33:00:00:09 dst 203.0.113.1 self

Parfait ! Les deux premières lignes correspondent aux routes de type 3 (les trames de type « BUM » seront envoyées à la fois à 203.0.113.1 et à 203.0.113.3). Les deux dernières lignes correspondent aux routes de type 2.

Interopérabilité

Un des avantages de BGP EVPN est son interopérabilité avec les implémentations d’autres constructeurs. Pour montrer qu’il s’agit d’une réalité, nous allons configurer un Juniper vMX pour agir en tant que VTEP.

Tout d’abord, nous devons le configurer en tant que pont. La configuration ci-dessous est équivalente à l’utilisation de ip link et brctl avec Linux. Nous ne configurons qu’une seule interface physique avec deux VLAN classiques que l’on associe aux VXLAN de façon à ce que les identifiants correspondent.

interfaces {
    ge-0/0/1 {
        unit 0 {
            family bridge {
                interface-mode trunk;
                vlan-id-list [ 100 200 ];
            }
        }
    }
}
routing-instances {
    switch {
        instance-type virtual-switch;
        interface ge-0/0/1.0;
        bridge-domains {
            vlan100 {
                domain-type bridge;
                vlan-id 100;
                vxlan {
                    vni 100;
                    ingress-node-replication;
                }
            }
            vlan200 {
                domain-type bridge;
                vlan-id 200;
                vxlan {
                    vni 200;
                    ingress-node-replication;
                }
            }
        }
    }
}

Nous devons ensuite configurer BGP EVPN pour publier l’ensemble des VNI locaux. La configuration est similaire à celle de Quagga :

protocols {
    bgp {
        group fabric {
            type internal;
            multihop;
            family evpn signaling;
            local-address 203.0.113.3;
            neighbor 203.0.113.253;
            neighbor 203.0.113.254;
        }
    }
}

routing-instances {
    switch {
        vtep-source-interface lo0.0;
        route-distinguisher 203.0.113.3:1; # ❶
        vrf-import EVPN-VRF-VXLAN;
        vrf-target {
            target:65000:1;
            auto;
        }
        protocols {
            evpn {
                encapsulation vxlan;
                extended-vni-list all;
                multicast-mode ingress-replication;
            }
        }
    }
}

routing-options {
    router-id 203.0.113.3;
    autonomous-system 65000;
}

policy-options {
    policy-statement EVPN-VRF-VXLAN {
        then accept;
    }
}

Un petit patch de compatibilité est de plus nécessaire10 pour Cumulus Quagga.

Les routes générées sont très similaires à celles de Quagga. Il y a toutefois ces deux différences :

  • sur JunOS, le route distinguisher est configuré statiquement en ❶,
  • sur JunOS, le VNI est également encodé en tant que Ethernet tag ID.

Voici une route de type 3 envoyée par JunOS :

> show route table bgp.evpn.0 receive-protocol bgp 203.0.113.3 extensive

bgp.evpn.0: 13 destinations, 13 routes (13 active, 0 holddown, 0 hidden)
* 3:203.0.113.3:1::100::203.0.113.3/304 IM (1 entry, 1 announced)
     Accepted
     Route Distinguisher: 203.0.113.3:1
     Nexthop: 203.0.113.3
     Localpref: 100
     AS path: I
     Communities: target:65000:268435556 encapsulation:vxlan(0x8)
     PMSI: Flags 0x0: Label 6: Type INGRESS-REPLICATION 203.0.113.3
[...]

Et voici une route de type 2 :

> show route table bgp.evpn.0 receive-protocol bgp 203.0.113.3 extensive

bgp.evpn.0: 13 destinations, 13 routes (13 active, 0 holddown, 0 hidden)
* 2:203.0.113.3:1::200::50:54:33:00:00:0f/304 MAC/IP (1 entry, 1 announced)
     Accepted
     Route Distinguisher: 203.0.113.3:1
     Route Label: 200
     ESI: 00:00:00:00:00:00:00:00:00:00
     Nexthop: 203.0.113.3
     Localpref: 100
     AS path: I
     Communities: target:65000:268435656 encapsulation:vxlan(0x8)
[...]

Nous pouvons vérifier que le vMX comprend correctement les informations reçues de ses collègues qui font tourner Quagga :

> show evpn database l2-domain-id 100
Instance: switch
VLAN  DomainId  MAC address        Active source                  Timestamp        IP address
     100        50:54:33:00:00:0c  203.0.113.1                    Apr 30 12:46:20
     100        50:54:33:00:00:0d  203.0.113.2                    Apr 30 12:32:42
     100        50:54:33:00:00:0e  203.0.113.2                    Apr 30 12:46:20
     100        50:54:33:00:00:0f  ge-0/0/1.0                     Apr 30 12:45:55

Inversement, ces derniers comprennent correctement les routes construites par JunOS :

# show evpn vni 100
VNI: 100
 VxLAN interface: vxlan100 ifIndex: 9 VTEP IP: 203.0.113.1
 Remote VTEPs for this VNI:
  203.0.113.3
  203.0.113.2
 Number of MACs (local and remote) known for this VNI: 4
 Number of ARPs (IPv4 and IPv6, local and remote) known for this VNI: 0
# show evpn mac vni 100
Number of MACs (local and remote) known for this VNI: 4
MAC               Type   Intf/Remote VTEP      VLAN
50:54:33:00:00:0c local  eth1.100
50:54:33:00:00:0d remote 203.0.113.2
50:54:33:00:00:0e remote 203.0.113.2
50:54:33:00:00:0f remote 203.0.113.3

Je suis intéressé par tout retour sur l’interopérabilité avec d’autres constructeurs !


  1. Par exemple, ils peuvent configurer des ponts pour interconnecter des conteneurs. 

  2. Une telle fonctionnalité permet de remplacer les implémentations propriétaires de type MC-LAG, permettant à plusieurs VTEP de terminer un aggrégat. Ce n’est pas utile dans notre cas où les hyperviseurs agissent en tant que VTEP

  3. Le développement de Quagga est lent et opaque. Les nouvelles fonctionnalités sont souvent bloquées. FRR est placé sous le patronage de la Linux Foundation. Il a opté pour un développement basé sur GitHub et une gouvernance démocratique. Plusieurs fonctionnalités intéressantes ont déjà été contribuées (notamment, add-path pour BGP, support des interfaces sans IP, MPLS et LDP). 

  4. Je suis souvent circonspect envers les projets se contentant de réécrire un service existant en Go. Toutefois, bien que plutôt jeune, GoBGP a des mérites propres (bonne architecture, bonnes performances). 

  5. Le support des voisins dynamiques a été intégré dans GoBGP 1.21. Jetez un œil à cet exemple de configuration

  6. La version 48 ports coûte autour de 10 000 $ avec la licence BGP

  7. Un chassis vide avec deux cartes de routage (RE-S-1800X4-16G) coûte autour de 30 000 $. 

  8. Je ne connais pas son prix mais il est disponible gratuitement à des fins d’évaluation pour les clients existants. 

  9. La valeur de 100 utilisée en route distinguisher (203.0.113.2:100) n’est pas utilisée pour encoder le VNI. Ce dernier est encodé dans le route target (65000:268435556), dans les 24 derniers bits (268435556 & 0xffffff égale 100). Tant que les VNI sont uniques, ces détails ne sont pas très importants. 

  10. L’encodage du VNI dans le route target est en cours de standardisation dans draft-ietf-bess-evpn-overlay. Juniper implémente déjà les premières versions de ce document. 

03 May, 2017 09:56PM by Vincent Bernat

April 21, 2017

hackergotchi for Raphaël Hertzog

Raphaël Hertzog

Le logiciel libre a t’il une couleur politique ?

En pleine campagne présidentielle, après avoir échoué à obtenir les parrainages pour Charlotte Marchandise, j’ai décidé de soutenir Jean-Luc Mélenchon.

Il se trouve que le volet numérique du programme de la France Insoumise est très bien ficelé et fait la part belle aux logiciels libres.

Mais face aux enjeux, ce n’est évidemment pas mon seul critère de choix. L’élément décisif pour ma part est la mise en place d’une assemblée constituante avec des citoyens tirés au sort pour changer nos institutions et notre système électoral à bout de souffle. Il nous faut le jugement majoritaire (cliquez le lien pour tester la méthode sur cette élection présidentielle) pour en finir avec le vote utile. Il faut dépasser la monarchie présidentielle et apprendre à travailler ensemble pour le bien de tous.

Mais même en allant au delà de ces deux aspects, je me retrouve en accord avec le programme de la France Insoumise sur la quasi totalité des thématiques sauf l’Europe et sur le revenu universel (qui est absent!).

Pour autant, je n’aime pas le personnage de Jean-Luc Mélenchon (ce n’est pas pour rien que je soutenais Charlotte Marchandise) et son historique politique (cumul dans le temps…) n’est pas en phase avec mes convictions, mais il n’y a pas de candidat parfait et il a promis de démissionner une fois la nouvelle constitution en place alors je m’en accommode.

Bref, pour en revenir avec le sujet de mon article, très peu de candidats[1] à la présidence ont pris des positions aussi claires en faveur des logiciels libres alors je m’interroge. Est-ce un hasard que le seul projet qui défend le logiciel libre soit aussi celui qui me correspond le mieux par ailleurs ? Ou bien est-ce que le fait que je fasse partie de la communauté du logiciel libre peut avoir une relation avec le côté humaniste/progressiste/écologiste qui m’attire en politique ?

J’ai l’habitude de présenter le logiciel libre comme apolitique, car les gens de gauche y voient un modèle de coopération et de partage des communs, et les gens de droite y voient la liberté totale et un marché ouvert avec une concurrence parfaite. Et parfois j’ai l’impression que cette distinction se retrouve aussi dans la différence de terminologie « logiciel libre » vs « open-source »…

L’existence même de ces deux tendances discréditerait alors la corrélation que je semble observer. Mais tout de même, lorsqu’on parle de « communauté du logiciel libre » j’ai remarqué que ceux qui se reconnaissent derrière ce label sont plutôt des contributeurs qui sont portés par des motivations (au moins partiellement) altruistes et lorsque je discute avec d’autres contributeurs bénévoles aussi impliqués que moi, il est assez rare que je tombe sur des personnes avec des valeurs en forte opposition aux miennes.

Ceux pour qui le logiciel libre se résume à l’open-source ne semblent pas s’identifier à la notion de communauté du logiciel libre et sont moins impliqués/présents/visibles dans les événements qui fédèrent les communautés (conférences, sprints, etc.).

Qu’en dites-vous ? Faites-vous le même constat que moi ? Ou bien avez-vous une expérience diamétralement opposée à la mienne ?

Il est possible (voire probable) que la communauté Debian (dont je fais partie) ne soit pas forcément représentative de l’ensemble de la communauté du libre. L’existence même du contrat social comme texte fondateur explique peut-être un biais vers le côté humaniste/progressiste.

En tout cas, avec le nombre de chercheurs qui ont déjà étudié les développeurs de logiciels libres, je m’étonne que cette problématique n’ait pas encore été étudiée. Si vous connaissez une étude à ce sujet, partagez la dans les commentaires, cela m’intéresse et je rajouterai volontiers un lien dans l’article.

[1] François Asselineau soutient aussi le logiciel libre. Mais j’ai l’impression que c’est plus par anti-impérialisme américain — car les logiciels propriétaires dominants viennent de là — que par conviction.

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

21 April, 2017 12:36PM by Raphaël Hertzog

April 16, 2017

Florent Gallaire

Chris Lamb élu DPL pour 2017

C’est Chris Lamb qui vient d’être élu Debian Project Leader (DPL) pour l’année 2017, succédant ainsi au mandat de Mehdi Dogguy qui avait été élu sans opposition en 2016.

Si le mandat de Mehdi s’est bien déroulé, il donnait peut-être trop l’impression d’un Zack 4.0, et il semblerait donc que Chris puisse apporter une nouvelle dynamique au projet Debian. Voici une représentation du résultat du scrutin qui utilise la méthode Condorcet.

Vote DPL 2017

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

16 April, 2017 12:39AM by fgallaire

March 12, 2017

Quel DPL pour 2017 ?

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

La question de la légitimité d’un scrutin avec un seul candidat, posée l’année dernière par Paul Wise, n’est heureusement plus d’actualité, mais force est de constater que les candidats ne se bousculent toujours pas au portillon pour devenir DPL. Il y en aura donc deux cette année :

En plus de son rôle de développeur Debian, Chris Lamb est un important contributeur du projet Reproducible builds ainsi que du framework web Python Django et de son écosystème.

Les presque mille développeurs Debian seront libres de voter du 2 au 15 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.

12 March, 2017 05:53AM by fgallaire

February 23, 2017

Stéphane Blondon

Frise chronologique des distributions Debian

De manière assez inattendue, on m’a suggéré de mettre à jour la frise chronologique montrant des différentes distributions de Debian au fil du temps. L’image de l’article précédent s’arrêtait à la sortie future de Wheezy. Cette fois-ci, elle va jusqu’à la future sortie de Stretch :
Frise chronologique Debian 1993-2016

Il s’agit simplement d’une version modifiée du fichier Gimp précédent. Le nouveau fichier .xcf est téléchargeable à http://stephane.yaal.fr/frise-chronologique/frisechrono_debian_1993_2016.xcf.


23 February, 2017 04:47PM by ascendances

February 13, 2017

hackergotchi for Raphaël Hertzog

Raphaël Hertzog

Mes activités libres en janvier 2017

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

Debian LTS

Ce mois-ci ce sont 10 heures de travail sur les mises à jour de sécurité pour Debian 7 Wheezy qui ont été subventionnées. Elles ont été consacrées aux tâches suivantes :

  • J’ai passé en revue de multiples CVE affectant ntp, et décidé de les marquer comme « no-dsa » (de manière identique à ce qui a été réalisé pour Jessie);
  • J’ai relancé les auteurs amont de jbig2dec (ici) et XML::Twig (par message privé) concernant les rapports de bogue n’ayant pas encore eu de retour de leur part;
  • J’ai demandé plus de détails sur la liste oss-security au sujet de la CVE-2016-9584, car le fait qu’elle ait déjà été remontée à l’amont n’était pas évident. Il s’est avéré que c’était bien le cas, j’ai donc mis à jour le suiveur de sécurité en conséquence;
  • Après avoir obtenu une réponse sur jbig2dec, j’ai commencé à rétroporter le patch désigné par l’amont, ce qui ne fut pas chose facile. Lorsque cela a été fait, j’ai également reçu le fichier permettant de reproduire le problème qui est à l’origine du rapport… et qui ne provoquait malheureusement plus le même problème avec la vieille version de jbig2dec présente dans Wheezy. Cela étant, Valgrind a tout de même identifié des lectures en-dehors de l’espace mémoire alloué. C’est à partir de cet instant que j’ai examiné avec plus d’attention l’historique Git, et découvert que les trois dernières années n’avaient vu principalement que des correctifs de sécurité pour des cas similaires n’ayant jamais été remontés en tant que CVE. En conséquence, j’ai ouvert une discussion sur comment régler cette situation;
  • Matthias Geerdsen a remonté dans le n°852610 une régression concernant libtiff4. J’ai confirmé le problème et passé de nombreuses heures à élaborer un correctif. Le patch ayant entraîné la régression était spécifique à Debian, car l’amont n’avait pas encore corrigé le problème. J’ai publié un paquet mis à jour dans la DLA-610-2.

Empaquetage Debian

La période de gel « fort » approchant, j’ai procédé à quelques mises à jour de dernière minute :

  • schroot 1.6.10-3 : correction de quelques problèmes anciens avec la manière dont les montages bind sont partagés, et autres corrections importantes;
  • live-boot 1:20170112 : correction d’un échec au démarrage sur système de fichier FAT, et autres corrections mineures;
  • live-config 5.20170112 : regroupement de plusieurs patchs utiles en provenance du BTS;
  • J’ai fini la mise à jour de hashcat 3.30 avec sa nouvelle bibliothèque privée, et corrigé en même temps le bogue critique pour la publication n°851497. Le travail avait été initié par des collègues de l’équipe pkg-security team.

Travaux divers

Parrainages J’ai parrainé un nouvel envoi de asciidoc abaissant une dépendance en recommandation (cf. le n°850301). J’ai parrainé une nouvelle version amont de dolibarr.

Discussions J’ai appuyé plusieurs modifications préparées par Russ Allbery sur debian-policy. J’ai aidé Scott Kitterman au sujet d’une incompréhension sur la manière dont les fichiers de service Postfix sont supposés fonctionner, en lien avec le rapport n°849584. J’ai discuté dans le rapport n°849913 d’une régression dans la compilation des compilateurs croisés, et fourni un patch afin d’éviter le problème. Guillem est finalement parvenu à une meilleure solution.

Bogues J’ai analysé le n°850236 concernant l’échec d’un test Django durant la première semaine suivant chaque année bisextile. J’ai créé le n°853224 afin de remonter plusieurs petits problèmes en lien avec les scripts mainteneur de desktop-base.

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 January 2016 contribuée par Weierstrass01.

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

13 February, 2017 10:37AM by Raphaël Hertzog

February 09, 2017

hackergotchi for Charles Plessy

Charles Plessy

[résolu] Attention à libinput 1.6.0-1

Depuis que j'ai mis à jour ce soir, je ne peux quasiment plus cliquer en tapotant mon pavé tactile. Heureusement, une correction est en route.

m-à-j : Réinstaller les paquets version 1.5.5-4 résout le problème en attendant.

m-à-j : Les paquets version 1.6.2-1, encore dans Sid pour le moment, fonctionnent parfaitement. Merci !

09 February, 2017 01:22PM

February 07, 2017

hackergotchi for Debian France

Debian France

Meetup du 28 Mars à Paris

Meetup du 28 Mars à Paris

Informations pratiques

Un meetup Debian France aura lieu à Paris le mardi 28 mars 2017 à partir de 19h30.

Le meetup est accueilli par l'Institut des Systèmes Complexes de Paris Île de France (CNRS) , 113 rue Nationale, Paris 13ème (métro Nationale, Place d'Italie ou Olympiades).

Plus d'informations pour s'y rendre.

Les codes à l'entrée seront indiqués 24H avant le meetup (ou par mail pour ceux qui seront inscrits):

  • code de la porte d'entrée : XXXX
  • code de la seconde porte : XXXX
  • Salle de conférence 1.1 au premier étage (escalier ou ascenseur).

Merci de s'inscrire pour que nous puissions prévoir votre accueil dans les meilleures conditions.

Pour toute question concernant l'organisation, vous pouvez contacter Alexandre Delanoë (anoe AT debian DOT org).

Programme

Accueil 19H30-20H00

  • Accueil et présentation des objectifs des meetups (Alexandre Delanoë, secrétaire Debian France, 5mn)
  • Présentation de Debian France par son Président (Nicolas Dandrimont, Développeur Debian, 5mn)

Présentation (rapide) de soi, si la salle n'est pas trop pleine

Talk 20H- 20H15

Titre: Debian aujourd'hui et demain

Auteur: Mehdi Doguy, actuel Debian Project Leader

Résumé: L'actuel Leader du projet Debian présentera les moments forts durant l'année écoulée. Il nous parlera du futur de Debian, la tendance actuelle qui se dessine et ses projets pour l'année à venir.

Discussions 20H15-20H30

Talk 20H30-20H45

Titre: Debian, forces et limites pour l'accessibilité du logiciel libre

Auteur: Alexandre Arnaud, chef de projet à Hypra.fr

Résumé: Comment utiliser un ordinateur lorsque l'on est mal-voyant? Quel système prévoir ? Alexandre Arnaud, chef de projet à Hypra.fr montrera comment il travaille et présentera l'équipe Debian accessibilité, son cycle de développement favorable aux tests et sa politique de mises à jour. Cependant, les logiciels d'aide technique ne sont pas forcément à jour et certaines évolutions obligent Hypra à maintenir ses propres dépôts logiciels (notamment pour certains paquets de Mate ou Orca) afin de concilier cette stabilité avec le progrès nécessaire et rapide dans l'accessibilité du libre.

Discussions 20H45-21H

Talk 21H-21H15

Titre: Thèmes de bureau pour Debian

Auteur: Aurélien Couderc, Contributeur Debian

Résumé: Organisation du concours de thèmes, sélection du thème par défaut et mise en ¿uvre. Challenges et travail à réaliser à chaque version de Debian. Avec une mise en perspective sur les nouveautés pour la prochaine version de Debian : Stretch.

Discussions 21H15-21H30

Échanges et signatures de clefs GPG 21H30-22H

RDV pour le prochain Meetup.

07 February, 2017 02:41PM

February 02, 2017

hackergotchi for Raphaël Hertzog

Raphaël Hertzog

Élections présidentielles, logiciel libre et Charlotte Marchandise

L’élection présidentielle approche et commence à prendre une grande place médiatique. À cette occasion, les associations comme l’April essaient d’interpeller les candidats pour les sensibiliser sur le sujet…

En temps qu’association, il faut garder ses distances et ne pas prendre position. Mais en tant qu’individu, je peux aller plus loin et soutenir explicitement un candidat qui partage les valeurs du logiciel libre.

Charlotte MarchandiseC’est ce que je veux faire aujourd’hui. Je vous invite à découvrir Charlotte Marchandise. C’est la gagnante des primaires citoyennes organisées par laprimaire.org et son programme politique est en parfaite adéquation avec mes valeurs (revenu de base inconditionnel, 6ème république, transition écologique, etc.) y compris sur le logiciel libre (voir ici l’article dédié de son programme).

C’est une candidature citoyenne non-partisane qui ne peut donc s’appuyer sur aucun financement pré-existant. Elle a donc besoin de nos dons. J’ai déjà fait un don conséquent et je vous invite à en faire de même. Cliquez ici pour accéder au formulaire permettant de soutenir la campagne de Charlotte Marchandise.

Si vous ne pouvez pas donner, je vous invite simplement à parler de Charlotte et de son programme dans votre entourage et à partager cet article. Si vous avez un peu de temps à investir, vous pouvez participer à la recherche de parrainages.

Je fais partie de ceux qui ne veulent plus de la classe politique en place et qui souhaite une réforme des institutions et du système électoral en premier lieu. Avec cette candidature citoyenne, « hackons le système » !

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

02 February, 2017 01:57PM by Raphaël Hertzog

February 01, 2017

Stéphane Blondon

Il voyait des spirales partout…

♪ …et pour lui ça voulait dire des trucs : ♫ ♪

Spirales sur essuie-tout

Je suis tombé sur cet essuie-tout par hasard et ça m’a rappelé de suite un logo, voire un thème. 🙂

Écran de connexion à debian9


01 February, 2017 03:17PM by ascendances

January 14, 2017

hackergotchi for Raphaël Hertzog

Raphaël Hertzog

Mes activités libres en décembre 2016

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

Debian LTS

Ce mois-ci ce sont 10 heures de travail sur les mises à jour de sécurité pour Debian 7 Wheezy qui ont été subventionnées. Elles ont été consacrées aux tâches suivantes :

  • J’ai publié la DLA-741-1 concernant unzip. Ce fut une mise à jour facile;
  • J’ai passé en revue le patch de Roberto Sanchez pour la CVE-2014-9911 concernant ICU;
  • J’ai publié la DLA-759-1 concernant nss, en collaboration avec Antoine Beaupré. J’ai fusionné et mis à jour le travail de Guido pour activer la suite de tests au cours de la compilation, et pour ajouter les tests DEP-8;
  • J’ai créé le dépôt Git qui sera utilisé pour la maintenance de php5 dans Debian LTS, et j’ai commencé à travailler sur une mise à jour. J’ai ajouté les patchs pour 2 CVE (CVE-2016-3141 et CVE-2016-2554), ainsi que quelques fichiers binaires requis par certains tests (qui échouent, à l’heure actuelle).

Empaquetages divers

Avec l’approche du gel définitif de Stretch, certains clients m’ont demandé de pousser des paquets dans Debian et/ou de corriger des paquets sur le point d’être retirés de cette distribution.

Alors que j’essayais de ramener uwsgi dans testing, j’ai créé les rapport de bogue n°847095 (libmongoclient-dev: Ne devrait pas rentrer en conflit avec le paquet de transition mongodb-dev) et n°847207 (uwsgi: FTBFS sur de multiples architectures avec des références indéfinies à des symboles uwsgi_*), de même que j’ai travaillé sur quelques-uns des bogues critiques pour la publication qui maintenaient le paquet hors de testing.

J’ai également travaillé sur quelques nouveaux paquets (lua-trink-cjson, lua-inotify, lua-sandbox-extensions) qui améliorent le paquet « hindsight » dans certains cas d’usage, et j’ai parrainé une mise à jour de rozofs dans experimental, afin de corriger un conflit de fichiers avec inn2 (cf. le n°846571).

Travaux Debian divers

Debian Live J’ai publié deux mises à jour de live-build. Avec la seconde ont été ajoutées plusieurs options de personnalisation de la configuration GRUB (que nous utilisons dans Kali pour surcharger le thème, et ajouter de nouvelles entrées au menu), à la fois pour le boot EFI et pour le boot normal.

Rapports de bogue divers Rapport de bogue n°846569 concernant libsnmp-dev, afin de tenir compte de la transition libssl (j’avais remarqué que le paquet n’était pas maintenu, j’ai en conséquence fait appel aux nouveaux mainteneurs potentiels sur la liste debian-devel). Le n°847168 sur devscripts pour debuild qui a commencé à échouer lorsque lintian échouait (régression inattendue). Le n°847318 concernant lintian, afin d’éviter les faux-positifs sur les paquets Kali (ce qui était ennuyeux du fait de la régression debuild précédemment mentionnée). Le n°847436 concernant un problème de mise à jour avec tryton-server. Le n°847223 concernant firefoxdriver, dans la mesure où il dépendait toujours d’iceweasel au lieu de firefox.

Parrainage J’ai parrainé une nouvelle version d’asciidoc (rapport de bogue n°831965), ainsi que de ssldump (version 0.9b3-6), pour la transition libssl. J’ai également poussé une nouvelle version de mutter, afin de corriger le n°846898 (elle était déjà prête dans SVN).

Distro Tracker

Pas grand chose de nouveau, j’ai corrigé le n°814315 en basculant quelques URLs restantes vers https. J’ai fusionné les patchs d’efkin pour corriger la suite de tests fonctionnels (cf. le n°814315), ce qui constitue une contribution vraiment très utile ! Ce même contributeur s’est attaqué à un autre ticket (le n°824912) concernant l’ajout d’une API pour récupérer les objets d’action. Cela représente une tâche plus importante et demande quelques réflexions. Je dois encore lui faire mes retours sur ses derniers patchs (après déjà deux itérations).

Travaux divers

J’ai mis à jour la formule salt letsencrypt-sh pour la version 0.3.0, et ajouté la possibilité de personnaliser le script hook pour recharger le serveur Web.

Le compte Twitter @planetdebian n’est plus actif depuis que twitterfeed.com a fermé ses portes, et que son remplaçant (dlvr.it) n’apprécie pas le fil RSS de planet.debian.org. J’ai créé le n°848123 concernant planet-venus, ce dernier ne préservant pas l’attribut isPermalink dans le tag guid.

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 December 2016 contribuée par Weierstrass01.

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

14 January, 2017 01:55PM by Raphaël Hertzog

December 24, 2016

Florent Gallaire

Les fonctions anonymes lambda en Python : print, expressions conditionnelles et récursivité

Si Python n’est pas un langage de programmation fonctionnelle, il possède cependant des fonctions anonymes lambda qui sont typiques de cette famille de langages. Ces fonctions sont réputées peu puissantes en Python car elle ont été volontairement limitées syntaxiquement à une expression, sans possibilité d’utiliser des instructions. Pourtant, nous allons voir qu’elles ont dans ce langage quelques particularités intéressantes.

Print

L’instruction print est devenue une fonction print() – et donc une expression – dans Python 3 suite à la PEP 3105. Ainsi, si vous utilisez print dans une fonction lambda, Python 2 lèvera une exception SyntaxError: invalid syntax alors que Python 3 l’acceptera :

>>> pr = lambda x : print(x)
>>> pr('OK en Python 3')
OK en Python 3

Expressions conditionnelles

Introduites (tardivement) dans Python 2.5 suite à la PEP 308, les expressions conditionnelles sont une manière simplifiée de réaliser grâce à l’opérateur ternaire true_value if condition else false_value la suite d’instructions suivante :

if condition:
    x = true_value
else:
    x = false_value

Comme leur nom l’indique, les expressions conditionnelles sont bien des expressions et elles permettent donc de mettre de la logique dans les fonctions lambda. Cela était déjà possible précédemment, en abusant un peu les opérateurs logiques classiques avec condition and true_value or false_value, mais c’est une méthode que je déconseille car elle n’est pas totalement fiable pour certaines valeurs de condition.

Dans l’exemple suivant, j’utilise une expression conditionnelle avec la fonction print() et donc Python 3, ce dernier me permettant d’utiliser un nom de variable avec le caractère non-ASCII é (PEP 3131) :

>>> majorité = lambda x : print("mineur") if x < 18 else print("majeur")
>>> majorité(15)
mineur
>>> majorité(25)
majeur

Récursivité

Le principe des fonctions anonymes étant de ne pas être nommées, il est donc logiquement difficile de les appeler. Ainsi, les fonctions anonymes de certains langages fonctionnels ne peuvent pas s’appeler, et donc ne peuvent pas être récursives. En Python, les lambda sont un sucre syntaxique limité des fonctions normales mais elles leur sont sémantiquement équivalentes, et elles peuvent donc parfaitement s’appeler récursivement.

En utilisant une expression conditionnelle et la récursivité on peut ainsi facilement implémenter l’algorithme récursif naïf de la très classique suite de Fibonacci :

>>> fib = lambda x : x if x < 2 else fib(x - 1) + fib(x - 2)
>>> fib(1)
1
>>> fib(10)
55
>>> fib(25)
75025

N’essayez pas d’aller beaucoup plus haut pour tester cet algorithme de complexité exponentielle, mais il démontre bien la puissance quelque peu surprenante des fonctions lambda en Python.

Compréhension de liste

On peut enfin ajouter que l’usage de compréhension de liste permet aisément de faire une boucle dans une fonction lambda :

>>> incr = lambda liste : [i + 1 for i in liste]
>>> incr([1, 45, 340])
[2, 46, 341]

24 December, 2016 07:56AM by fgallaire

December 11, 2016

hackergotchi for Raphaël Hertzog

Raphaël Hertzog

Mes activités libres en novembre 2016

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

Debian LTS

Dans les 11 heures de travail (rémunérées) qui m’incombaient, je suis parvenu à publier la DLA-716-1, aussi connue sous le nom de tiff 4.0.2-6+deb7u8, corrigeant les CVE-2016-9273, CVE-2016-9297 et CVE-2016-9532. On dirait bien que ce paquet est concerné par de nouvelles CVE tous les mois.

J’ai ensuite consacré pas mal de temps à passer en revue toutes les entrées dans dla-needed.txt. Je souhaitais me débarrasser des commentaires erronés ou qui ne sont plus pertinents, et en même temps aider Olaf, qui s’occupait du « frontdesk LTS » pour la première fois. Cela a abouti au marquage de pas mal d’entrées comme « no-dsa » (c’est à dire que rien ne sera fait pour elles, leur gravité ne le justifiant pas), telles que celles affectant dwarfutils, dokuwiki, irssi. J’ai supprimé libass, car la CVE ouverte était sujette à débat et marquée comme « pas importante ». Tandis que je faisais cela, j’ai corrigé un bogue dans le script bin/review-update-needed que nous utilisons pour identifier les entrées n’ayant fait aucun progrès dernièrement.

Je me suis ensuite attaqué à libgc, et publié la DLA-721-1, ou libgc 1:7.1-9.1+deb7u1. Elle corrige la CVE-2016-9427. Le patch était important et a du être rétroporté manuellement, car il ne s’appliquait pas correctement.

Enfin, la dernière tâche réalisée fut le test d’une nouvelle version d’imagemagick et la revue d’une mise à jour préparée par Roberto.

Travaux concernant pkg-security

L’équipe pkg-security continue sur sa bonne lancée : j’ai parrainé le travail de patator concernant le nettoyage d’une dépendance inutile de pycryptopp, qui allait être retiré de Testing du fait du ticket n°841581. Après m’être penché sur ce bogue, il s’est avéré que celui-ci était résolu dans libcrypto++ 5.6.4-3. Je l’ai donc clôturé.

J’ai parrainé plusieurs envois : polenum, acccheck, sucrack (mises à jour mineures), bbqsql (nouveau paquet importé de Kali). Quelques temps plus tard, j’ai corrigé quelques soucis dans le paquet bbsql, qui avait été rejeté de NEW.

Je me suis également occupé de quelques bogues critiques pour la publication, et liés à la transition vers openssl 1.1 : j’ai adopté dans l’équipe sslsniff et corrigé le n°828557, par une compilation dépendante de libssl1.0-dev. Ceci après avoir ouvert le ticket amont correspondant. J’ai fait la même chose pour ncrack et le n°844303 (le ticket amont est ici). Quelqu’un d’autre s’est occupé de samdump2, mais j’ai tout de même adopté le paquet dans l’équipe pkg-security, dans la mesure où il s’agit d’un paquet concernant le thème de la sécurité. J’ai aussi effectué un envoi en tant que non-mainteneur d’axel et du n°829452 (cela ne concerne pas pkg-security, mais nous l’utilisons dans Kali).

Travaux Debian divers

Django J’ai participé à la discussion débattant de l’opportunité de laisser Django compter le nombre de développeurs qui l’utilisent. L’impact quant à la diffusion de données personnelles que ce changement entraînerait a suscité l’intérêt des listes de diffusion Debian, et jusqu’à celui de LWN.

Sur un plan plus technique, j’ai poussé la version 1.8.16-1~bpo8+1 vers jessie-backports, et corrigé le bogue critique pour la publication n°844139. Pour se faire, j’ai rétroporté deux commits amont, ce qui a mené à l’envoi 1.10.3-2. Je me suis ensuite assuré que cela était également corrigé dans la branche amont 1.10.x.

dpkg et /usr fusionné. En parcourant debian-devel, j’ai découvert que le bogue n°843073 menaçait la fonctionnalité d’un /usr fusionné. Dans la mesure où le bogue était présent dans du code que j’avais écrit il y a plusieurs années, et du fait que Guillem n’était pas intéressé par sa correction, j’ai passé une heure à mettre au point un patch relativement propre que ce dernier pourrait appliquer. Guillem n’a malheureusement pas encore réussi à sortir une nouvelle version de dpkg embarquant ces patchs. Espérons que cela ne tardera plus trop.

Debian Live J’ai fermé le n°844332 , qui demandait le retrait de live-build de Debian. Étant marqué comme orphelin, j’avais toujours gardé un œil sur ce paquet, et avait poussé quelques petites corrections vers Git. J’ai décidé cette fois d’adopter officiellement le paquet au sein de l’équipe debian-live, et de travailler un peu plus dessus. J’ai passé en revue tous les patchs en attente dans le suiveur de bogues, et poussé de nombreuses modifications vers Git. Quelques changements restent à faire pour finaliser un meilleur rendu du menu GRUB, et j’ai prévu de pousser une nouvelle version très prochainement.

Diverses créations de tickets J’ai créé deux tickets amont concernant uwsgi, afin d’aider à la correction de bogues ouverts et critiques pour la publication affectant ce paquet. J’ai créé le n°844583 concernant sbuild, afin de supporter les suffixes arbitraires de version pour les recompilations binaires (binNMU). Et j’ai créé le n°845741 concernant xserver-xorg-video-qxl, afin qu’il soit corrigé pour la transition vers xorg 1.19.

Zim. Alors que j’essayais de corriger le n°834405 et de mettre à jour les dépendances requises, j’ai découvert que je devais mettre à jour pygtkspellcheck en premier lieu. Le mainteneur de ce paquet étant malheureusement aux abonnés absents (MIA – missing in action), je l’ai adopté en tant que membre de l’équipe python-modules.

Distro Tracker. J’ai corrigé un petit bogue, qui entraînait l’affichage d’une affreuse trace à l’occasion de requêtes avec un HTTP_REFERER non-ASCII.

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 November 2016 contribuée par Weierstrass01.

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

11 December, 2016 07:37PM by Raphaël Hertzog

hackergotchi for Charles Plessy

Charles Plessy

apt purge ifupdown

...owow, ça marche encore... Je n'avais jamais réalisé que network-manager n'avait pas besoin d'ifupdown.

11 December, 2016 07:30AM

December 08, 2016

Florent Gallaire

Base LEGI et système de fichiers : ext4 vs XFS

Comme je l’indiquais dans mon article sur la base LEGI, cette dernière est assez volumineuse et structurée d’une manière très complexe. Ainsi, la dernière version de la base est composée de 1 624 783 fichiers XML, répartis dans une arborescence absconse de 1 537 949 sous-répertoires pour une taille d’une dizaine de Go.

Cette structure est suffisamment extrême pour nous amener à nous interroger sur le choix et sur les performance de notre système de fichiers, alors que la plupart des gens utilisent un système de fichiers sans même en avoir vraiment conscience et a fortiori sans le choisir.

Le première chose si vous souhaitez travailler sur la base LEGI, qui est composée d’un très grand nombre de petits fichiers, c’est de privilégier l’utilisation d’un SSD à celle d’un disque dur classique. En effet, les performances seront 10 à 20 fois meilleures avec un SSD.

Les systèmes de fichiers sont un sujet très technique et de très bas niveau, sur lequel peu de personnes sont compétentes et où les convictions affichées relèvent parfois plus de la croyance que de l’analyse scientifique. Voici donc trois éléments de comparaison objectifs et compréhensibles des systèmes de fichiers ext4 – le choix par défaut sous Linux – et XFS.

1) Taille de la base LEGI

Dans mon article je mentionnais que la base LEGI pouvait varier de taille selon le système de fichier, sans citer explicitement ext4 et XFS.

ext4 : 15 Go
XFS : 9 Go

Pourquoi une telle différence ? C’est Jean-Baptiste Denis qui m’a aidé à percer ce mystère. En fait XFS possède des Shortform Directories qui permettent de stocker les petits répertoires directement dans leur inode. Les 6 Go supplémentaires correspondent donc aux 1 537 949 blocs de 4 Ko créés par ext4 pour chacun des sous-répertoires.

Vainqueur : XFS

2) Nombre d’inodes

Un inode est utilisé par fichier et par répertoire lors de la décompression de la base LEGI. Il faut donc que la partition dans laquelle est stockée la base possède au minimum 1 624 783 + 1 537 949 = 3 162 732 inodes. Or le nombre d’inodes varie selon les systèmes de fichiers et les options de formatage. Pour visualiser le nombre d’inodes de vos partitions il suffit d’utiliser la commande df -ih.

ext4 : 65 000 inodes/Go
XFS : 1 000 000 inodes/Go

Ceci n’est pas du tout anecdotique, car beaucoup d’hébergeurs ne permettent pas de choisir votre système de fichier : ce sera ext4 avec ses options de formatage par défaut et rien d’autre. Avec seulement 65 000 inodes par Go, il faudra une partition d’une taille minimale de 50 Go pour pouvoir stocker la base entière. Cela implique que certaines offres de VPS peu chères, avec une capacité de stockage SSD de petite taille, ne vous permettront pas d’exploiter la base LEGI.

Vainqueur : XFS

3) Performances

J’ai évalué les performances des deux systèmes de fichiers avec plusieurs commandes parcourant la base LEGI sur un serveur Xeon 8 cœurs 3,7 GHz doté de 16 Go de RAM et d’un SSD. Les résultats permettent de comparer Ext4 et XFS, mais les performances sur votre ordinateur risquent d’être nettement inférieures.

J’ai utilisé la commande echo 3 | sudo tee /proc/sys/vm/drop_caches pour vider les caches avant chaque essai (merci Jean-Baptiste bis).

Commandeext4XFSext4/XFS
du -hsc legi3'08"0'53"3,5
find legi -type d | wc -l3'06"0'56"3,3
find . -name "*.xml" | wc -l2'54"0'51"3,4
tar xzf Freemium_legi_global.tar.gz2'26"1'18"1,9

On peut ici conclure que XFS se révèle globalement 3 fois plus rapide qu’ext4.

Vainqueur : XFS

XFS sort donc grand vainqueur de cette comparaison avec ext4, et je ne peux que vous encourager à l’utiliser si vous voulez exploiter la base LEGI. À titre personnel, j’ai décidé de ne plus utiliser que XFS.

08 December, 2016 01:34PM by fgallaire

December 05, 2016

Ruby est mourant (Python, Node.js, Go et Elixir l’ont tué)

En août 2015 GitHub publiait le classement des langage de programmation les plus populaires depuis son lancement en 2008. L’article mettait l’accent sur la progression de Java, lié à l’adoption des services de GitHub par les entreprises friandes de ce langage, mais c’est bien l’évolution de la popularité de Ruby qui m’avait le plus interpellé.

Leader aux premiers jours de 2008, avec en particulier la présence immédiate de Ruby on Rails sur GitHub (GitHub est une application Ruby en Rails), Ruby est passé 2ème en 2013, puis 3ème en 2014 et enfin 4ème en 2016.

github

Suivant de près la popularité des langages sur GitHub, j’ai eu la chance de capturer hier l’improbable moment où PHP – le grand-père du web en net regain de forme depuis la sortie de PHP 7 – a dépassé l’enfant prodige pour le reléguer à la 5ème place !

classment2

Mais si Ruby est mourant, quels sont donc ses meurtriers ?

Python pour la diversité d’utilisation

Python est un peu le concurrent historique de Ruby, tant ces deux langages semblaient occuper la même « niche » de langage de programmation moderne, dynamique et orienté objet. Ce que l’on peut faire avec Python on peut le faire avec Ruby, et réciproquement, le choix entre les deux est plus une question de feeling sur la syntaxe du langage ou l’ambiance de la communauté.

Oui mais justement, que fait-on avec ces langages ? En première page du site web du langage Python on peut trouver une section « Use Python for… » qui donne une réponse à cette question dans le but de conforter les débutants dans leur choix de Python : ils ne vont pas seulement apprendre un langage de programmation puissant et facile d’utilisation, mais aussi un outil pour faire plein de choses utiles et très diverses.

python

Car si Python est bien sûr utilisé pour la programmation web et qu’il a son alter ego de Rails avec Django, il est aussi énormément utilisé dans bien d’autres domaines. Python est installé par défaut sur toutes les distributions GNU/Linux et sur macOS, il est largement utilisé en administration système, s’est imposé pour des utilisations scientifiques et pédagogiques et représente le choix le plus simple et efficace pour développer des interface graphiques, avec de nombreux bindings vraiment fonctionnels et maintenus.

Ruby et sa communauté sont en comparaison par trop web-centric. Rails, Sinatra et Jekyll sont formidables, et ils étaient même très innovants, mais de nombreux projets s’en sont inspiré, des équivalents ont été développés dans d’autres langages et ils ne peuvent plus à eux seuls justifier d’apprendre le Ruby. Ruby a percé grâce à Rails et au web, mais il n’a jamais su s’en émanciper et c’est ce qui est en train de causer sa perte.

Node.js pour le buzz

D’une manière qui a parfois pu irriter les pythonistes, Ruby a longtemps eu l’image d’un langage cool, et tout ce qui s’y rapportait de près ou de loin faisait facilement le buzz. Oui mais voilà, Node.js est passé par là, amenant au JavaScript l’ubiquité, cette exceptionnelle singularité d’être le seul langage de programmation présent à la fois côté serveur et côté client.

trend

Node.js a bénéficié d’une large et dynamique communauté préexistante de développeurs JavaScript, ce qui a permis son adoption à une vitesse incomparable à celle d’un « nouvel entrant ». Node.js a donc attaqué frontalement Ruby sur sa niche web tenue par Ruby on Rails et l’a en quelque sorte dépossédé de son buzz.

Go et Elixir pour les performances

Deux langages de programmation récents ont aussi causé beaucoup de tort à Ruby en l’attaquant sur le terrain des performances, son point faible historique. On peut ainsi développer rapidement de beaux et fonctionnels sites web avec Ruby on Rails, mais quand le succès arrive, il est alors très difficile de scaler. Le remplacement de Ruby on Rails par du Java par Twitter en 2011 en est bien sûr l’exemple le plus cinglant.

Go est un langage de programmation compilé créé par Google en 2007 et rendu disponible en 2009. Alors que l’on pensait que ce langage allait attirer les développeurs C et C++ à la recherche de plus de confort, il a en fait attiré beaucoup de développeurs de langages dynamiques à la recherche de plus de performances. Ainsi de nombreuses personnes réécrivent leur application Rails en Go et constatent des gains de performances leur permettant par exemple de passer de 30 à 2 serveurs pour l’hébergement, ce qui implique des économies de travail, de temps et d’argent colossales.

Elixir est un langage de programmation fonctionnel datant de 2012 qui utilise BEAM, la formidable machine virtuelle massivement concurrente développée pour Erlang. La particularité d’Elixir est de reprendre la sémantique d’Erlang et de la proposer aux développeurs sous la forme d’une nouvelle syntaxe… inspirée du Ruby ! Cela n’est pas très surprenant quand on sait qu’Elixir a été créé par José Valim, un des principaux développeurs de Ruby on Rails. Et ce sont bien sûr les problèmes de performance de Ruby qui ont motivé sa démarche. Elixir se positionne donc clairement comme un nouveau Ruby, mais qui scale.

Il est très probable que Go et Elixir vont continuer à devenir de plus en plus populaires dans les années qui viennent, et que Ruby va avoir beaucoup de difficultés à s’en relever. Un dernier petit exemple en passant, sur les cinq logiciels libres dont je parlais dans mon article sur la base LEGI, deux sont en Python, un en PHP, un en Go, un en Julia… et aucun en Ruby.

05 December, 2016 06:18AM by fgallaire

November 23, 2016

hackergotchi for Tanguy Ortolo

Tanguy Ortolo

Interdit ou autorisé ?

Vu près de l'entrée d'un jardin public, celui de Brimborion, de mémoire :

Panneau rond avec une large bordure verte et un vélo noir au milieu

Alors, dans ce parc, le vélo est-il autorisé, interdit, recommandé, obligatoire ? (Rayez les mentions inutiles.)

C'est interdit, évidemment, mais modifier ainsi la couleur d'un panneau standard est une très mauvaise idée. Et la raison pour laquelle cette erreur a été commise, à savoir mieux s'assortir avec la couleur de l'environnement, est parfaitement stupide. Service des parcs de Sèvres, changez-moi ça tout de suite !

23 November, 2016 04:56PM by Tanguy

November 19, 2016

hackergotchi for J. Fernando Lagrange

J. Fernando Lagrange

Debian Stretch et Dell Latitude E6520: installation

J’ai un nouveau travail, pour lequel on m’a fourni un Dell Latitude E6520. Voici comment j’ai installé Debian 9 Stretch testing dessus.

Debian testing est la version actuellement en développement de la prochaine version stable de Debian. Elle est aussi disponible sous le nom de la future version, c’est-à-dire Stretch (depuis le 25 avril 2015).
(Extrait du wiki officiel)

Ma démarche pour installer Stretch

Pour installer la future Debian stable, j’ai suivi les étapes suivantes (indiquées comme la manière la plus fiable dans le wiki officiel (il est aussi possible d’utiliser l’installateur encore en version alpha pour Stretch):

  1. Installer Debian 8 Jessie stable à partir d’une clé USB
  2. Changer les sources de paquets
  3. Mettre à jour vers Debian 9 Stretch testing

Installer Debian 8 Jessie stable à partir d’une clé USB

Préparation de et démarrage sur la clé USB

En trois étapes:

  1. Télécharger la dernière version stable (la 8.6.0 en cemoment)
    À partir du lien en haut à droite de la page d’accueil du projet Debian
  2. Copier le contenu de ce téléchargement sur une clé USB
    Avec la commande # cp /chemin/dossier/téléchargement/debian-8.6.0-amd64-i386-netinst.iso /dev/sd<ma_cle_usb>
  3. Démarrer l’ordinateur sur la clé USB
    Pour cela, sur ce Dell (Latitude E6520), appuyer sur F12 pendant le démarrage de l’ordinateur et sélectionner la clé USB

« Options » choisies pendant l’installation

Mes « options » préférées pendant une installation de poste de travail:

  • Ne pas mettre de mot de passe au compte de l’administrateur (root): cela installe sudo et ajoute l’utilisateur créé pendant l’installation dans le groupe sudo
  • Utiliser le disque en entier avec LVM et une partition chiffrée, qui contient tous les dossiers
  • Choisir l’environnement de bureau XFCE

Changer les sources de paquets

Dans /etc/apt/sources.list, changer jessie par stretch, le fichier final que j’ai utilisé est le suivant:

# 

deb http://httpredir.debian.org/debian/ stretch main
deb-src http://httpredir.debian.org/debian/ stretch main

deb http://security.debian.org/ stretch/updates main
deb-src http://security.debian.org/ stretch/updates main

deb http://httpredir.debian.org/debian/ stretch-updates main
deb-src http://httpredir.debian.org/debian/ stretch-updates main

Puis mettre à jour la liste des paquets disponibles: # apt update

Mettre à jour vers Debian 9 Stretch testing

En trois étapes:

  1. Mettre à jour l’outil de gestion des paquets:
    # apt install apt
  2. Mettre à jour les paquets installés:
    # apt upgrade
  3. Redémarrer (je ne sais pas si c’est nécessaire, mais cela permet d’utiliser le noyau qui vient d’être installé):
    # reboot
  4. Finir la mise à jour:
    # apt full-upgrade

Note:

  • Pendant la mise à jour, j’ai rencontré un problème, temporaire et dont la cause première a déjà été corrigée), en indiquant que le paquet rdnssd est en conflit avec network-manager. Comme j’utilise network-manager, j’ai résolu ce problème en supprimant le paquet rdnssd, qui ne me semble pas nécessaire dans mon cas.

Et voilà !

Comme ce modèle n’était pas dans la partie « Installing Debian On » du wiki, je l’ai ajouté ! 🙂

19 November, 2016 11:44AM by Low Memory

October 29, 2016

Certificats Let’s Encrypt ! avec certbot

Qu’est-ce que c’est donc ? (bis)

Le mois dernier, j’avais partagé comment je faisais pour renouveler des certificats Let’s Encrypt ! Je me suis alors rendu compte qu’il y a des outils dédiés dans le projet Debian, et qu’ils ont étés rétroportés pour Jessie: le paquet Debian certbot. Voici comment j’utilise ce paquet.

Pour rappel:
« Let’s Encrypt (abrégé LE) est une autorité de certification lancée le 3 décembre 2015 (Bêta Version Publique). Cette autorité fournit des certificats gratuits X.509 pour le protocole cryptographique TLS au moyen d’un processus automatisé destiné à se passer du processus complexe actuel impliquant la création manuelle, la validation, la signature, l’installation et le renouvellement des certificats pour la sécurisation des sites internet. »
Contenu soumis à la licence CC-BY-SA 3.0. Source : Article Let’s Encrypt de Wikipédia en français (auteurs ).

Voici donc comment j’utilise ce paquet Debian certbot pour:

  • Créer de nouveaux certificats (pour nginx)
  • Mettre à jour ces certificats

Préambule: installation

Pour installer le paquet certbot, il faut d’abord ajouter la source des paquets rétroportés. C’est indiqué dans les instructions (en anglais) et sur la page wiki (en français). Personnellement, voici comment j’ai fait:

J’ai créé un fichier /etc/apt/sources.list.d/backports.list contenant la ligne suivante:

deb http://ftp.debian.org/debian jessie-backports main

Puis lancé les commandes suivantes:

root@server ~# apt update
[…]
root@server ~# apt install certbot
[…]

Créer de nouveaux certificats (pour nginx)

J’utilise nginx comme serveur web. J’ai mis en place le certificat Let’s Encrypt ! en 3 étapes:

  1. Créer le certificat
  2. Configurer nginx pour utiliser le nouveau certificat
  3. Relancer nginx

Créer le certificat

Voici comment j’ai créé les certificats pour le site web www.fosforito.fr:

root@server ~# systemctl stop nginx.service
root@server ~# certbot certonly -d www.fosforito.fr
[…]

Puis, j’ai suivi les instructions (en anglais) pour utiliser l’authentification avec un serveur web autonome (standalone). Cela autorise certbot à lancer son propre serveur web, le temps de créer le certificat. nginx ne doit donc pas fonctionner le temps de créer le certificat (quelques secondes dans mon cas), c’est le but de la première commande. Pour le relancer, j’ai utilisé la commande suivante:

root@server ~# systemctl start nginx.service

Configuration de nginx

Pour utiliser la configuration ci-dessous, j’ai d’abord créé une clé Diffie-Hellman comme indiqué par SSL Labs:

root@server ~# openssl dhparam -out /etc/nginx/dhparams.pem 2048
[…]

Voici le fichier /etc/nginx/sites-available/www.fosforito.fr.conf que j’utilise avec la commande root@server ~# ln -s /etc/nginx/sites-available/www.fosforito.fr.conf /etc/nginx/sites-enabled/www.fosforito.fr.conf:

server {
    listen 443;
    server_name www.fosforito.fr;

    ssl on;
    ssl_certificate /etc/letsencrypt/live/www.fosforito.fr/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/www.fosforito.fr/privkey.pem;

    ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA';

    ssl_prefer_server_ciphers on;

    ssl_dhparam /etc/nginx/dhparams.pem;

    root /srv/www.fosforito.fr/;
    index index.html;

    access_log      /var/log/nginx/www.ssl.access.log;
    error_log       /var/log/nginx/www.ssl.error.log;


}

Une fois tout cela mis en place, je teste avec SSL Labs et je vois que ce site obtient un A, ce qui me va bien. 🙂

Mise à jour du certificat

Le paquet certbot met en place une tâche planifiée pour mettre à jour automatiquement le(s) certificat(s) Let’s Encrypt ! présent(s) sur le serveur. Malheureusement, pour l’instant, cela ne fonctionne que pour le serveur web apache (paquet apache2 dans Debian).
Pour nginx, j’ai simplement modifié la tâche planifiée, dans le fichier /etc/cron.d/certbot, pour arrêter le serveur web avant le renouvellement de certificat et le relancer après. Voici le fichier au complet (notez les options pre-hook et post-hook):

# /etc/cron.d/certbot: crontab entries for the certbot package
#
# Upstream recommends attempting renewal twice a day
#
# Eventually, this will be an opportunity to validate certificates
# haven't been revoked, etc.  Renewal will only occur if expiration
# is within 30 days.
SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

0 */12 * * * root test -x /usr/bin/certbot && perl -e 'sleep int(rand(3600))' && certbot -q renew --pre-hook "service nginx stop" --post-hook "service ngnix start"

Récapitulatifs

Mise en place du certificat pour nginx

  1. Arrêter nginx
  2. Créer le certificat Let’s Encrypt !
  3. Créer le groupe Diffie-Hellman
  4. Mettre en place la configuration du site web
  5. Relancer nginx

Renouvellement du(des) certificat(s)

Ajouter les options pre-hook et post-hook à la tâche plannifiée.

29 October, 2016 06:36PM by Low Memory

October 08, 2016

hackergotchi for Charles Plessy

Charles Plessy

Je viens de finir de lire la trilogie des chroniques du Radch.

J'ai beaucoup aimé. Il y a déjà de nombreux commentaires sur Internet (merci à Russ pour m'avoir fait découvrir ces romans), donc je ne m'attarderai pas dans les détails. Et il est difficile de résumer sans dévoiler l'intrigue... En bref :

Le premier tome, La justice de l'ancillaire nous fait visiter plusieurs mondes et cultures et nous donne un aperçu de ce que ça fait d'être un demi-dieu. La culture dominante ne fait aucune différence entre les deux sexes, et la grammaire de son langage n'a pas de genre. Ça donne une touche particulière à l'histoire, car par exemple quand il parle une langue étrangère, le héros a des difficultés pour s'adresser correctement à ses interlocuteurs sans les froisser. Malheureusement, la langue anglaise elle-même utilise peu les genres, donc l'effet littéraire s'en trouve un peu amoindri. Peut-être que sur ce point la traduction française, que je n'ai pas lue, pourrait être plus intéressante ?

le deuxième tome L'épée de l'ancillaire nous raconte comment on peut se dire des choses dans une société de surveillance sans intimité, en variant subtilement la manière de servir le thé. On en boit des litres dans ce tome, dont le principal intérêt est le jeu des relations entre les personnages, et leurs dialogues.

Le troisième tome La miséricorde de l'ancillaire pose la question de ce qui nous rend humains. Parmi les personnages les plus intéressants, il y a un ambassadeur extra-terrestre, qui est une sorte d'humain de synthèse. Au premier abords, il semble complètement étranger, mais à bien y réfléchir, il n'est pas très différent d'un nouveau-né qui comme par miracle saurait parler: au début, le monde n'a aucun sens, et petit à petit, par l'expérience, il déduit son fonctionnement. C'est comme ça que ce personnage finit par comprendre que ce que l'on appelle « la guerre », c'est un phénomène compliqué dont l'une des conséquences est une pénurie de sauce au poisson.

J'étais un peu surpris qu'aucun des livres ne nous emmène au coeur de l'empire du Radch, mais je vois à l'instant sur Wikipédia qu'un autre roman est en préparation... On pourrait spéculer que le Radch central ressemble à un Occident futur dystopique, dans lequel tout le monde est suivi en totalité et en permanence mais se croit heureux, et dont la paix intérieure est garantie par des opérations armées à l'extérieur, exécutées principalement par des robots-tueurs pilotés par des intelligences artificielles. Un futur peut-être pas si lointain ?

Il va sans dire que dans l'empire du Radch, il ne semble pas avoir le moindre logiciel libre. Ça me rappelle que je n'ai pas trop contribué à Debian pendant que je lisais...

08 October, 2016 03:29PM

August 17, 2016

hackergotchi for Tanguy Ortolo

Tanguy Ortolo

Aux concepteurs de voies cyclables

À voir le tracé de certaines voies cyclables, ceux qui les conçoivent ne sont pas toujours conscients qu'un cycliste se déplace avec une vitesse de l'ordre de 20 km/h. Ce genre d'aménagement, qui serait impensable pour une route normale :

Route avec une chicane à angle droit !

Au top, braquez et serrez le frein à main. Attention… TOP ! ;-)

… ce genre d'aménagement donc, est tout aussi invraisemblable pour une voie cyclable :

Piste cyclable avec une chicane à angle droit !

Au top, tournez votre guidon à 90°. Attention… TOP ! ;-)

Un cycliste ne peut pas tourner sur place à angle droit. Au mieux, on peut essayer de s'en approcher, mais ces virages à rayon de courbure nul sont pénibles et toujours dangereux, parce que cela implique :

  • de freiner brutalement — et paf, le cycliste qui arrive derrière et qui n'a pas remarqué cette anomalie du tracé ;
  • de tourner avec un angle déraisonnable — et zip, le cycliste sur route mouillée ou jonchée de gravier ou de feuilles mortes.

Mesdames, Messieurs les responsables des aménagements de voirie, pour éviter ce genre d'erreur de conception, ce n'est pas compliqué : lorsque vous tracez une voie cyclable, essayez d'imaginer qu'il s'agit d'une route normale, en plus petit. Vous n'iriez tout de même pas mettre une chicane à angle droit sur une route normale ? Eh bien, sur une piste cyclable, c'est pareil, si vous devez mettre une chicane, prévoyez un rayon de courbure raisonnable. Sans cela, dans le meilleur cas, les cyclistes ne respecteront pas votre aménagement inapproprié, et dans le pire des cas vous ramasserez des cyclistes et des piétons accidentés, direction l'hôpital le plus proche.

17 August, 2016 10:16AM by Tanguy

hackergotchi for Charles Plessy

Charles Plessy

Qui a fini DEP 5 ?

Beaucoup de monde a travaillé à finir DEP 5. Je trouve que le blog de Lars ne montre pas assez l'aspect collectif du processus.

Si l'on regarde dans le texte de la spécification, on y trouve:

The following alphabetical list is incomplete; please suggest missing people:
Russ Allbery, Ben Finney, Sam Hocevar, Steve Langasek, Charles Plessy, Noah
Slater, Jonas Smedegaard, Lars Wirzenius.

Le journal des changements de la charte Debian mentionne:

  * Include the new (optional) copyright format that was drafted as DEP-5.
    This is not yet a final version; that's expected to come in the
    3.9.3.0 release.  Thanks to all the DEP-5 contributors and to Lars
    Wirzenius and Charles Plessy for the integration into the Policy
    package.  (Closes: #609160)

 -- Russ Allbery <rra@debian.org>  Wed, 06 Apr 2011 22:48:55 -0700

et

debian-policy (3.9.3.0) unstable; urgency=low

  [ Russ Allbery ]
  * Update the copyright format document to the version of DEP-5 from the
    DEP web site and apply additional changes from subsequent discussion
    in debian-devel and debian-project.  Revise for clarity, to add more
    examples, and to update the GFDL license versions.  Thanks, Steve
    Langasek, Charles Plessy, Justin B Rye, and Jonathan Nieder.
    (Closes: #658209, #648387)

Pour ma part, je suis très reconnaissant à Bill Alombert d'avoir enregistré le document dans le dépôt Git, ce qui a mis fin aux débats.

17 August, 2016 04:08AM

August 10, 2016

hackergotchi for J. Fernando Lagrange

J. Fernando Lagrange

Renouvellement de certificats LetsEncrypt avec systemd

Qu’est-ce que c’est donc ?

« Let’s Encrypt (abrégé LE) est une autorité de certification lancée le 3 décembre 2015 (Bêta Version Publique). Cette autorité fournit des certificats gratuits X.509 pour le protocole cryptographique TLS au moyen d’un processus automatisé destiné à se passer du processus complexe actuel impliquant la création manuelle, la validation, la signature, l’installation et le renouvellement des certificats pour la sécurisation des sites internet1. » (Contenu soumis à la licence CC-BY-SA 3.0. Source : Article Let’s Encrypt de Wikipédia en français (auteurs) )

Bref, c’est bien pratique pour faire du HTTPS (entre autres) et on peut automatiser le renouvellement des certificats. Il y a plusieurs années, j’aurais fait un cron, mais comme j’ai appris que systemd pouvait gérer des tâches répétitives, je me suis dit que c’était l’occasion de m’y mettre ! 😉

Comment on fait ?

Voici les étapes suivies, détaillées ci-dessous puis quelques documents qui m’ont permis de le faire, sans compter le conseil d’un ami: « T’as qu’à faire un timer ! » :

  • Copier certbot sur le serveur, logiciel (libre, non-copyleft) de gestion des certificats de Let’s Encrypt
  • Créer un script pour renouveler les certificats avec certbot
  • Créer un service systemd pour lancer le script
  • Créer une minuterie (timer) systemd pour lancer le service à intervalles réguliers

Enfin, activer et lancer la minuterie puis vérifier que ça fonctionne.

1. Copier certbot sur le serveur

Je le copie dans le dossier /opt du serveur:

root@serveur:~# cd /opt/ && git clone https://github.com/certbot/certbot
[…]

2. Créer le script pour utiliser certbot

Le script se nomme certbot-renew, il est créé dans /opt/certbot/, au même endroit que certbot. Créez aussi le dossier pour les journaux avec la commande mkdir /var/log/letsencrypt/.

Si vous utilisez le serveur web apache, changez le service que systemd doit arrêter et redémarrer, en gras dans le code ci-dessous:

root@serveur:~# cat > /opt/certbot/certbot-renew << EOF
#!/bin/sh
# Inspired by <https://letsencrypt.org/getting-started/>
systemctl stop nginx.service
/opt/certbot/certbot-auto renew -nvv --standalone > /var/log/letsencrypt/renew.log 2>&1
LE_STATUS=$?
systemctl start nginx.service
if [ "$LE_STATUS" != 0 ]; then
echo Automated renewal failed:
tail -n 200 /var/log/letsencrypt/renew.log
exit 1
fi
EOF

3. Créer le service systemd

C’est ce service qui va lancer le script /opt/certbot/certbot-renew créé à l’étape précédente:

root@serveur:~# cat > /etc/systemd/system/certbot-renew.service << EOF
# Voir <https://mjanja.ch/2015/06/replacing-cron-jobs-with-systemd-timers/>
[Unit]
Description=Renouvellement des certificats letsencrypt

[Service]
Type=simple
nice=19
IOSchedulingClass=2
IOSchedulingPriority=7
ExecStart=/opt/certbot/certbot-renew
EOF

4. Créer la minuterie systemd

C’est cette minuterie qui va lancer le service créé à l’étape précédente. Notez que la valeur daily pour OnCalendar lance le service à minuit. Comme le serveur était programmé pour faire d’autres choses à minuit, j’ai utilisé un autre moment. ^^

root@serveur:~# cat > /etc/systemd/system/certbot-renew.timer << EOF
# Voir <https://mjanja.ch/2015/06/replacing-cron-jobs-with-systemd-timers/>
[Unit]
Description=Renouvellement des certificats letsencrypt

[Timer]
#OnCalendar=daily
OnCalendar=*-*-* 04:20:42

[Install]
WantedBy=timers.target
EOF

 

Il ne reste plus qu’à activer cette minuterie pour qu’elle soit lancée à chaque démarrage du serveur:  systemctl enable certbot-renew.timer

Pour éviter un redémarrage, la minuterie peut être lancée manuellement: systemctl start certbot-renew.timer

Pour vérifier que tout fonctionne bien le service peut aussi être lancé manuellement: systemctl start certbot-renew.service. Vérifiez alors les journaux pour voir si tout s’est bien déroulé.

 

Voici donc comment j’ai procédé, il doit exister bien d’autres façons de faire, n’hésitez-pas à m’en faire part et/ou à améliorer ce que je présente ici.

Documentation, ressources:

Manuels de systemd: systemd.exec, systemd.service et systemd.timer.
Manuel de ioprio_set.
Remplacer les cron jobs par des minuteries systemd (en anglais).
Pour débuter avec Let’s Encrypt (en anglais).

Un brin de persévérance, un tonneau de tests et quelques couplets de corrections. 😉

 

10 August, 2016 09:02PM by Low Memory

June 28, 2016

hackergotchi for Tanguy Ortolo

Tanguy Ortolo

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

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

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

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

Logo UltraViolet

Étape 1, Warner Bros

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

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

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

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

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

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

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

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

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

Étape 3, ripper son DVD

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

28 June, 2016 11:34AM by Tanguy

June 17, 2016

hackergotchi for J. Fernando Lagrange

J. Fernando Lagrange

La brique en voyage

La situation

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

Le problème

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

La solution

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

 

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

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

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

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

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

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

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

Deuxième problème

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

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

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

Deuxième solution

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

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

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

 

17 June, 2016 09:13AM by Low Memory

April 28, 2016

hackergotchi for Tanguy Ortolo

Tanguy Ortolo

Pour des cartes restaurant anonymes

Contexte

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

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

C'est possible

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

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

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

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

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

28 April, 2016 05:47PM by Tanguy

April 25, 2016

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

Parking Méditerranée

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

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

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

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

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

Théoriquement, un accès vélo

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

De surprise en surprise

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

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

Un parking hostile aux vélos

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

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

25 April, 2016 05:01PM by Tanguy

April 11, 2016

Carl Chenet

Richard Stallman ce samedi à Choisy-le-roi

Pour information j’ai découvert ce week-end que Richard Stallman sera présent à la médiathèque de Choisy-le-roi ce samedi 16 avril 2016 à 17h. Pour information des Parisiens indécrottables, c’est en très proche banlieue parisienne :p Comptez par exemple entre 20 et 30 mn depuis le centre de Paris en passant par le RER C pour y arriver.

saint-stallman

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

Peut-être à samedi donc 😉


11 April, 2016 06:53AM by Carl Chenet

April 07, 2016

« La » communauté du Logiciel Libre, ça n’existe pas

Suivez-moi aussi sur Diaspora*diaspora-banner ou Twitter 

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

« La » communauté du Logiciel Libre, ça n’existe pas

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

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

Les communautés techniques

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

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

python-logo-master-v3-TMLa communauté Python, avec sa propre licence : la PSF, sa propre vision, ses propres objectifs

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

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

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

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

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

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

GPL contre BSD/MIT

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

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

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

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

bsdvsgpl

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

Des communautés constituent le Logiciel Libre

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

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

trollLes trolls, une activité prisée des Libristes

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

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

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


07 April, 2016 10:00PM by Carl Chenet

April 03, 2016

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

Suivez-moi aussi sur Diaspora*diaspora-banner ou Twitter 

Un rapide message pour annoncer le lancement d’un forum dédié à l’emploi dans la communauté du Logiciel Libre et opensource :

Le forum de LinuxJobs.fr : https://forum.linuxjobs.fr

forum-small

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

banieres linux vert

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

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

Quelques liens pour finir :


03 April, 2016 10:00PM by Carl Chenet

March 31, 2016

Le danger Github (revu et augmenté)

Suivez-moi aussi sur Diaspora*diaspora-banner ou Twitter 

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

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

codercatL’octocat, mascotte de Github

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

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

1. Points critiques

1.1 La centralisation

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

github-logo

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

1.2 Un logiciel privateur

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

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

1.3 L’uniformisation

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

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

2. Validité des points critiques

2.1 Les critiques de la centralisation

2.1.1 Taux de disponibilité du service

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

githubdown

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

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

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

2.2 Un peu de recul historique : SourceForge

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

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

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

 

2.3 Les critiques relatives à utiliser un logiciel privateur

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

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

 

bsdvsgpl

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

gplv3

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

FreeBSD, principal projet des BSD sous licence MITFreeBSD, principal projet des BSD sous licence BSD

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

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

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

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

mastering-issuesIssues, le suivi de bug propriétaire de Github

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

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

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

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

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

 

2.4 L’uniformisation

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

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

git-logo

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

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

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

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

 

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

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

gitlabLogo de Gitlab, une alternative possible à Github

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

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

cat-sleeping-fireplaceLe « lion » devant la cheminée

Texte sous licence Creative Commons CC BY-ND 3.0 FR


31 March, 2016 09:00PM by Carl Chenet

March 28, 2016

Du danger d’un acteur non-communautaire dans votre chaîne de production du Logiciel Libre

Suivez-moi aussi sur Diaspora*diaspora-banner ou Twitter 

La récente affaire désormais connue sous le nom de npmgate (voir plus bas si cet événement ne vous dit rien) est encore une illustration à mon sens du danger intrinsèque d’utiliser le produit possédé et/ou contrôlé par un acteur non-communautaire dans sa chaîne de production du Logiciel Libre. J’ai déjà tenté à plusieurs reprises d’avertir mes consœurs et confrères du Logiciel Libre sur ce danger, en particulier au sujet de Github dans mon billet de blog Le danger Github.

L’affaire npmgate

Pour rappel sur cette affaire précise du npmgate, l’entreprise américaine Kik.com a demandé à l’entreprise npm Inc., également société américaine, qui gère le site npmjs.com et l’infrastructure derrière l’installeur automatisé de modules Node.js npm, de renommer un module nommé kik écrit par Azer Koçulu, auteur prolifique de cette communauté. Il se trouve qu’il est également l’auteur d’une fonction left-pad de 11 lignes massivement utilisée comme dépendance dans de très très nombreux logiciels enNode.js. Ce monsieur avait exprimé un refus à la demande de kik.com.

Npm-logo

Cette entreprise, qui pour des raisons obscures de droits d’auteur semblait prête à tout pour faire respecter sa stupide demande (elle utilise d’ailleurs elle-même du Logiciel Libre, à savoir au moins jquery, Python, Packer et Jenkins d’après leur blog et en profite au passage pour montrer ainsi sa profonde gratitude à l’égarde de la communauté), s’est donc adressé à npm, inc, qui, effrayée par une éventuelle violation du droit d’auteur, a obtempéré, sûrement pour éviter tout conflit juridique.

Azer Koçulu, profondément énervé d’avoir vu son propre droit d’auteur et sa volonté bafoués, a alors décidé de retirer de la publication sur npmjs.com l’ensemble de ses modules, dont le très utilisé left-pad. Bien que npmjs.com ait apparemment tenté de publier un module avec le même nom, le jeu des dépendances et des différentes versions a provoqué une réaction en chaîne provoquant l’échec de la construction de très nombreux projets.

Sourceforge, Github, npmjs.com et … bientôt ?

Sourceforge, devant un besoin accru de rentabilité et face à la desaffection de ses utilisateurs au profit, on l’imagine, de Github, a commencé à ne plus respecter les prérequis essentiels d’une forge logicielle respectueuse de ses utilisateurs.

sourceforge-logo

J’ai présenté assez exhaustivement les dangers liés à l’utilisation de Github dans une chaîne de production du Logiciel dans mon article de blog le danger Github, à savoir en résumé la centralisation, qui avec de nombreux installeurs automatisés qui vont maintenant directement chercher les différents composants sur Github, si Github vient à retirer une dépendance, il se produira une réaction en chaîne équivalente au npmgate. Et cela n’est qu’une question de temps avant que cela n’arrive.

Autres risques, l’emploi de logiciel propriétaire comme l’outil de suit de bugs de Github issues, la fermeture et la portabilité limitées des données hébergées par eux et l’effet plus insidieux mais de plus en plus réel d’une sorte de fainéantise communautaire, inédite dans  notre communauté dans la recherche de solutions libres à des produits propriétaires existants et hégémoniques, sentiment également ressenti par d’autres.

github-logo

Le danger de l’acteur non-communautaire

Devant la massification des interdépendances entre les différents projets et le développement important du Logiciel Libre, aujourd’hui rejoint par les principaux acteurs hier du logiciel privateur comme Microsoft ou Apple qui aujourd’hui adoptent et tentent de récupérer à leur profit nos usages, il est plus que jamais dangereux de se reposer sur un acteur non-communautaires, à savoir en général une entreprise, dans la chaîne de création de nos logiciels.

microsoft-free.png

C’est un modèle séduisant à bien des égards. Facile, séduisant, en général peu participatif (on cherche à ce que vous soyez un utilisateur content), souvent avec un niveau de service élevé par rapport à ce que peut fournir un projet communautaire naissant, une entreprise investissant dans un nouveau projet, souvent à grand renfort de communication, va tout d’abord apparaître comme une bonne solution.

Il en va malheureusement bien différemment sur le moyen ou long terme comme nous le prouve les exemples suscités. Investir dans la communauté du Logiciel Libre en tant qu’utilisateur et créateur de code assure une solution satisfaisant tous les acteurs et surtout pérenne sur le long terme. Ce que chacun de nous recherche car bien malin qui peut prévoir le succès et la durée de vie qu’aura un nouveau projet logiciel.


28 March, 2016 09:00PM by Carl Chenet

March 17, 2016

hackergotchi for Aurélien Jarno

Aurélien Jarno

(Pseudo-)virtualizing Intel USB controllers

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

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

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

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

explain EHCI/OHCI/XHCI

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

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

add table

Add warning

17 March, 2016 04:34PM by aurel32

February 25, 2016

Stéphane Blondon

Des graphiques à la Xkcd

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

graphique à la xkcd

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

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

Installation

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

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

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

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

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


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

Et là, ça marche ! 🙂

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

Versions des logiciels utilisés, code source

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

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

from matplotlib import pyplot as plt
import numpy as np

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

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

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

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

25 February, 2016 10:26PM by ascendances

February 23, 2016

hackergotchi for Aurélien Jarno

Aurélien Jarno

10 years ago…

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

Still it seems to me like yesterday.

23 February, 2016 09:43PM by aurel32

August 15, 2015

Stéphane Blondon

DebConf15 à Heidelberg

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

club_mate

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

Le logo compatible Club-Mate :
Dc15going1


15 August, 2015 05:30PM by ascendances

May 19, 2015

Olivier Berger (pro)

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

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

Les transparents de Nicolas sont disponibles sur son site.

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

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

Voici quelques photos :




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

19 May, 2015 02:52PM by Olivier Berger

May 13, 2015

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

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

On a pensé à vous, avec MiNET.

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

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

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

13 May, 2015 01:23PM by Olivier Berger

May 03, 2015

Stéphane Blondon

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

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

Affichage de la sortie de cat, highlight et pygmentize

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

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

highlight et pygmentize

De nombreux langages disponibles

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

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

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

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

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

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

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

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

hightlight colore COBOL ou graphviz, pas pygmentize.

Facile à utiliser

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

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

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

Colorer de nouveaux langages

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

Autres usages

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

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

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

Que choisir ?

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

ccze

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

Affichage de la sortie de cat et ccze

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

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

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

Fin : références, versions des logiciels

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

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

Les versions utilisées pour l’article :

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

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

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

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

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

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

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

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

03 May, 2015 11:25AM by ascendances

April 15, 2015

Olivier Berger (pro)

April 11, 2015

hackergotchi for Roland Mas

Roland Mas

Le marronnier du printemps

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

Et qui le porte bien, merci.

11 April, 2015 05:30PM

April 01, 2015

hackergotchi for Debian France

Debian France

Debian France a un nouveau Président

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

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

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

01 April, 2015 04:14PM

January 23, 2015

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

Expériences Numériques

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

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

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

Télécharger le programme.

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

logo Maison pour Tous Salle des Rancy

23 January, 2015 03:12PM

December 22, 2014

Dons Debian France

Dons Debian France

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

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

Formulaire de donation

22 December, 2014 04:47PM

December 10, 2014

Olivier Berger (perso)

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

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

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

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

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

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

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

10 December, 2014 10:10PM by obergix

September 10, 2014

Olivier Berger (pro)

Le MOOC Bases de données relationnelles est lancé

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

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

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

10 September, 2014 07:53PM by Olivier Berger

August 20, 2014

hackergotchi for Aurélien Jarno

Aurélien Jarno

MIPS Creator CI20

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

mips-ci20

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

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

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

20 August, 2014 08:52PM by aurel32

Olivier Berger (pro)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

20 August, 2014 01:59PM by Olivier Berger

August 15, 2014

hackergotchi for Aurélien Jarno

Aurélien Jarno

Intel about to disable TSX instructions?

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

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

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

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

And later on page 51:

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

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

15 August, 2014 04:02PM by aurel32

June 18, 2014

Debian is switching (back) to GLIBC

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

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

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

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

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

18 June, 2014 08:04PM by aurel32

April 11, 2014

hackergotchi for Roland Mas

Roland Mas

Une page de publicité

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

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

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

11 April, 2014 08:06AM

37

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

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

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

11 April, 2014 08:06AM

November 15, 2013

10 ans !

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

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

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

15 November, 2013 02:45PM

October 10, 2013

Les rumeurs de la mort de ce blog…

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

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

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

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

Voilà voilà.

10 October, 2013 03:15PM