18 September 2017

Philippe Latu

Module administration système en réseau

La session 2017 de la série de travaux pratiques sur l'administration système en réseau vient de s'achever. Les étudiants ont survécu ! Même si certains prétendent que c'est inhumain :].

Les supports ont été revus et actualisés. Les principales évolutions portent sur la partie LDAP. Le paquet phpldapadmin a disparu des dépôts de la distribution. Son code PHP 5 n'est plus maintenu. J'ai donc revu l'énoncé avec une partie Jessie qui permet de faire fonctionner phpldapadmin et une nouvelle partie qui utilise le trombinoscope proposé par le LDAP Tool Box Project.

Le «polycopié» de travaux pratiques est disponible ici : sysadm-net.set.pdf.

18 September, 2017 04:29PM par Philippe Latu

13 September 2017

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 par Vincent Bernat

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:33AM

26 August 2017

nIQnutn

Nintendo 64: rejouer à de vrais jeux

C'est l'occasion de ressortir les manettes et de recommencer des jeux mythiques. C'est probablement sur la Nintendo 64 que j'ai le plus de souvenirs de jeux, du moins les plus marquants. La 3D, le multijoueur à 4 et des parties sans fin. Les réussites sont nombreuses et ont marqué les esprits en commençant par Super Mario 64, Golden Eye et Mario Kart 64 (je vais pas tous les citer). De nos jours, le jeu vidéo a changé, certains vendent des jeux pas fini et bugués et on croule sous la quantité de jeux disponibles (souvent ils manquent cruellement d'inspiration). C'est de plus en plus rare pour moi d'accrocher, avec le temps on se lasse mais je trouve que les jeux de cette époque avait une véritable identité et à part quelques patates payé à prix d'or (500 Francs de l'époque) je les ai tous terminé.

Tout ça parce que l'autre jour, j'ai eu envie de commencer un nouveau jeu mais ma liste de jeux sur Steam était beaucoup trop longue. Découragé, j'ai préféré revenir à des valeurs sûres.

Installation

Pour installer Mupen64Plus et son interface graphique:


#root
apt install mupen64plus-ui-console mupen64plus-qt

Pour lancer Mupen64Plus, aller dans le menu: Jeux > Mupen64Plus-Qt
ou directement depuis le terminal: mupen64plus-qt

Configuration

On commencer par mettre l'interface en français depuis le menu: Paramètres > Autre et on sélectionne le Français.

Ensuite, on indique le dossier des roms: Paramètres > Chemin et on ajoute notre dossier dans "Dossiers des ROMS"
Puis on actualise la liste des jeux dans le menu: Fichier > Recharger la liste
Pour finir, il faut aller dans: Paramètres > Disposition et sélectionner la vue. Sinon, on reste face à un écran vide :/

Il est possible de récupérer les infos depuis TheGamesDB.net.
Pour l'activer, aller dans le menu: Paramètres > Autre et cocher la case "Télécharger les informations sur les jeux"
On retourne dans le menu: Fichier > Recharger la liste

Il est possible de modifier les information d'une Rom. Il suffit de la sélectionner et dans le menu: Fichier > Télécharger/Mettre à jour les infos...

Si la miniature ne se met pas à jour, faut passer par le dossier ~/.local/share/mupen64plus-qt/cache et supprimer les miniatures.
Il y a visiblement un problème dans la gestion des miniatures et les fichiers .png peuvent ne pas s'afficher s'il y a un déjà un fichier .jpg

Et voilà, c'est prêt !

Ressources

https://wiki.debian.org/Mupen64Plus
https://github.com/dh4/mupen64plus-qt


nIQnutn CC-BY

26 August, 2017 11:49AM par nIQnutn

20 August 2017

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 par Vincent Bernat

10 July 2017

Frédéric Lietart

Nextcloud + Cloud Public Object Storage d’OVH

Je cherchais un moyen de sécuriser un minimum mes donnes hébergées par mon instance Nextcloud. Je me suis donc tourné vers le Cloud Public Object Storage d’OVH. Nous allons voir la mise en place de cet espace en tant qu’espace principal. J’utilise pour cela un serveur XC 2016 hébergé chez Online.net fonctionnant sous Debian Jessie (mais toute bonne instance Nextcloud doit fonctionner sans problème).

Voici ce que nous propose OVH :

  • 0,01 € HT/mois/Go
  • Triple réplication des données
  • Trafic entrant gratuit
  • Trafic sortant : 0,01 € HT/Go
  • Powered by OpenStack
  • Durabilité de vos données 100%

OVH propre d’ailleurs un petit tutoriel pour mettre en place leur solution en tant que stockage externe, mais en stockage principal c’est quand même bien mieux 🙂

Nous partons donc d’une instance Nextcloud vierge configurée avec une base MySQL et un compte administrateur. La création chez OVH du conteneur privé est un jeux d’enfant (après avoir accepté les conditions d’utilisations et donné un nom à sa première instance Cloud). Une fois créé il vous faudra créer un utilisateur et surtout retenir le mot de passe généré pour avoir accès au conteneur pour enfin télécharger le fichier de configuration d’Openstack.

Si on résume cela nous donne :

  • une instance Nextcloud toute propre
  • un conteneur privé Object Storage (Espace client OVH > Cloud > Stockage > Créer un conteneur)
  • un utilisateur pour l’accès au stockage (Espace client OVH > Cloud > Stockage > Openstack > Ajouter un utilisateur)
  • un fichier de configuration Openstack ou OpenRC (Espace client OVH > Cloud > Stockage > Openstack > sur la clé à droite)

Configuration de Nextcloud

Il nous faut maintenant éditer notre fichier de configuration (Nextcloud > config > config.php)

'objectstore' => array(
    'class' => 'OC\\Files\\ObjectStore\\Swift',
    'arguments' => array(
        'username' => 'OS_USERNAME',
        'password' => 'OS_PASSWORD', // mot de passe généré dans l'interface OVH
        'bucket' => 'CONTAINER_NAME',
        'autocreate' => false,
        'region' => 'GRA3',
        'url' => 'https://auth.cloud.ovh.net/v2.0',
        'tenantName' => 'OS_TENANT_NAME',
        'serviceName' => 'swift',
    ),
),

Vous trouverez toutes les informations dans le fichier de configuration Openstack ou OpenRC (Espace client OVH > Cloud > Stockage > Openstack > sur la clé à droite) hormis le mot de passe qui a été généré lors de l’ajout de l’utilisateur.

Si la configuration est bonne, vous devriez avoir accès à votre instance Nextcloud. Commencez à charger des documents et vous devriez voir augmenter l’espace occupé dans votre conteneur (Espace client OVH > Cloud > Stockage) ainsi que votre estimation de facturation 😉

 

 

 

Cet article Nextcloud + Cloud Public Object Storage d’OVH est apparu en premier sur TiFredFr.

10 July, 2017 08:03PM par Frédéric LIÉTART

19 June 2017

Tuxicoman

Debian 9 est sortie

La nouvelle Debian stable est sortie.

Un article bien détaillé sur les nouveautés est déjà paru sur LinuxFR résume plutôt bien les nouveautés donc je vais m’épargner de faire moins bien ici.

Merci à la française Juliette Taka Belin pour les artworks :)

Related Posts:

19 June, 2017 06:37AM par Tuxicoman

14 June 2017

Tuxicoman

Nouvelle instance mastodon : social.jesuislibre.net

J’ai installé ma propre instance de Mastodon : https://social.jesuislibre.net

Le tutoriel écrit en français par Angristan est limpide et je n’ai pas eu de soucis pour l’installer sur Debian 9.
Le seul soucis est la config Apache qui n’est documentée proprement.

Ça tourne au poil et rapidement sur un petit NUC en auto-hébergement.
Ça m’a aussi permis d’utiliser la v1.4.1 quand Framapiaf est toujours en v1.3.2 (je ne sais pas pourquoi)

Je suis moins satisfait de la fédération. J’ai découvert l’envers du décors :
– le fil global que contient que les posts publics des personnes suivies par des comptes locaux. Donc si t’es seul sur ton instance. T’as juste rien à par les gens que tu suis déjà…
– la recherche de personnes ne se fait que parmi les personnes connues par ton serveur (donc suivies par des comptes de ton serveur). Donc si t’es seul, tu ne trouves que les personnes que tu suis déjà.
– sur la page de profil d’un compte, tu ne vois que les billets qui sont déjà arrivés sur ton serveur. Donc, pour un nouveau compte, tu ne vois rien.
– la liste des abonnés affichés sur le profil d’un compte distant ne comptabilise que les abonnés du serveur local. Donc si t’es tout seul sur ton serveur, les profils externes n’ont qu’un abonné. Toi. Bonjour la découverte.
– la recherche par htag ne fonctionne que sur les posts recus par ton serveur local.
– les commentaires à des messages émis par des comptes d’autres serveur ne se sont pas visibles.

Finalement, on retrouve presque les mêmes limitations que sur Diaspora, l’autre réseau décentralisé a-centré. Ces limitations poussent les nouveaux à s’inscrire sur une grosse instance pour avoir du contenu. Et donc nuisent à la décentralisation.

C’est dommage car si on clique sur le profil d’un utilisateur, on arrive sur la page web du profil sur son serveur d’hébergement. Et là, on retrouve tout son historique et ses abonnés. C’est dommage que l’interface de mastodon ne puisse pas récupérer ces infos d’elle même.

Ca permettrait également de partager (retweeter booster dans le jargon de mastodon) un post ancien que le serveur n’a jamais reçu.

Related Posts:

14 June, 2017 05:49AM par Tuxicoman

21 April 2017

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 par Raphaël Hertzog

16 April 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 par fgallaire

17 March 2017

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.

17 March, 2017 10:13AM

12 March 2017

Florent Gallaire

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

23 February 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 par ascendances

13 February 2017

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 par Raphaël Hertzog

01 February 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 par ascendances

13 January 2017

Frédéric Lietart

Script post-installation Fedora 25

Suite à la sortie de Fedora en version 25 voici mon script de post-installation. Le script est conçu pour le bureau Gnome fournis par défaut dans Fedora.

Fonctionnalités

  • installer les dépôts RPMFusion
  • mettre à jour le système
  • installer mon profit bashrc
  • installer Skype, TeamViewer, Atom, Fedy…
  • faire un peu de nettoyage
  • installer le thème Arc
  • installer les polices Microsoft
  • installer FishShell
  • installer Terminix
  • installation de : nano wget langpacks-fr htop ccze most bash-completion gnome-tweak-tool gnome-shell-extension-user-theme alacarte

Une validation vous sera demandée avant l’installation d’application.

N’hésitez pas à rapporter les divers problèmes.

Installation

curl https://git.lietart.fr/tifredfr/postinstallfedora/raw/master/postinstallfedora25 -o postinstallfedora25 && chmod +x postinstallfedora25 && ./postinstallfedora25

Source : https://git.lietart.fr/tifredfr/postinstallfedora

Cet article Script post-installation Fedora 25 est apparu en premier sur TiFredFr.

13 January, 2017 07:57PM par Frédéric LIÉTART

23 November 2016

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

15 November 2016

David Mercereau

PvMonit – Monitoring de mon installation photovoltaïque autonome

Cet article fait suite à la réalisation de mon installation électrique solaire autonome. Je suis très content de celle-ci, seulement j’ai un grand besoin de maîtrise, et ne pas savoir tout ce qui se passait dans ces petites boîtes bleues me taraudait… Il fallait que je monitor. Coup de chance, les appareils Victron que j’ai installés peuvent se connecter à un ordinateur avec les câbles VE Direct USB.

En bon libriste que je suis, j’ai vite découvert OpenEnergyMonitor project. J’ai failli craquer pour un emonPi – Solar PV mais ça ne correspondait pas complètement à mes contraintes. J’ai donc pris mes petits doigts et j’ai pondu PvMonit.

PvMonit C’est quoi ?

PvMonit c’est donc un petit logiciel de monitoring photovoltaïque pour matériel Victron compatible Ve.direct (USB), particulièrement adapté pour les installations autonomes. Il permet une vue « en direct » et un export de l’historique vers emoncms (une branche d’OpenEnergyMonitor project).

Exemple d’usage de PvMonit (le mien) : je dispose d’un RaspberryPi (mini ordinateur qui ne consomme que ~3W), mes appareils Victron (MPTT, BMV) sont connectés avec des câbles VE.Direct USB. PvMonit est installé sur ce RaspberryPi et me permet :

  • D’afficher les informations en temps réel sur une page web (local)
    • Une copie de cette page est faite toutes les heures (si la connexion internet est allumée) et est accessible ici : http://demo.zici.fr/PvMonit/
  • De collecter les données toutes les X minutes et les expédier vers emoncms quand internet est là (le wifi n’étant pas toujours allumé)

Des images :

Installation de PvMonit

Le matériel

Il vous faudra pour suivre ce tuto :

  • Un ordinateur faible consommation configuré sous Debian ou un dérivé type Ubuntu/Raspbian (j’ai fait un article sur l’installation de mon Raspberry PI) 68€ (d’occasion avec coque, ventilateur, carte SD)
  • Les câbles Ve.Direct USB connectés à vos appareils 30€ (x3 car 3 appareils à connecter)
  • En option :
    • Une sonde de température USB pour contrôler la température du local où vivent les batteries. J’utilise « thermomètre USB TEMPer » qui coûte entre 5 et 20€, (ils en parlent ici)
    • Une pince ampèremètre USB pour contrôler la consommation de l’habitat. J’utilise la Aviosys 8870 à 27€ quand même, mais il ne semble pas y avoir beaucoup de concurrence pour ce type de produit… (j’en parle ici)

Voici le schéma de mon installation avec le câblage pour PvMonit incorporé :

pvmonit-cablage

Et voilà dans la vraie vie :

Le logiciel : Installation de PvMonit

Requis

  • Linux (le tutoriel ci-dessous est prévu pour Debian/Rasbian/Ubuntu like)
  • PHP (5.5-5.6 recomended)
  • Lighttpd/Apache (ou autre serveur web)
  • Perl
  • Python

Installation

PvMonit dispose de deux fonctions dissociées et indépendantes que je vais distinguer :

  • Interface en temps réel
  • Export vers emoncms

Il y a bien sûr une base commune :

La base / le socle

Installation de PvMonit via le dépôt git et de ses dépendances :

aptitude install php5-cli git python-serial sudo
cd /opt
git clone https://github.com/kepon85/PvMonit.git
cp config-default.php config.php

Vous pouvez maintenant éditer le fichier config.php à votre guise !

Test du script vedirect.py : branchez un appareil Victron avec un Câble Ve.Direct USB et voici un exemple de ce que vous devriez obtenir (Ici un MPTT BlueSolare branché sur le ttyUS0)

$ /opt/PvMonit/bin/vedirect.py /dev/ttyUSB0 
PID:0xA04A
FW:119
SER#:HQ********
V:25660
I:500
VPV:53270
PPV:14
CS:3
ERR:0
LOAD:ON
H19:3348
H20:1
H21:17
H22:33
H23:167
HSDS:52

Pour comprendre chaque valeur, téléchargez la documentation Victron VE Direct Protocol documentation : https://www.victronenergy.fr/support-and-downloads/whitepapers

Interface web en temps réel

Installation des dépendances :

aptitude lighttpd php5-cgi 
lighttpd-enable-mod fastcgi
lighttpd-enable-mod fastcgi-php

Configuration du serveur http, avec le fichier /etc/lighttpd/lighttpd.conf :

server .document-root        = "/opt/PvMonit/www"
server.pid-file             = "/var/run/lighttpd.pid"
server.username             = "www-data"
server.groupname            = "www-data"
server.port                 = 80
index-file.names            = ( "index.html", "index.php")
url.access-deny             = ( "~", ".inc" )
include_shell "/usr/share/lighttpd/use-ipv6.pl " + server.port
include_shell "/usr/share/lighttpd/create-mime.assign.pl"
include_shell "/usr/share/lighttpd/include-conf-enabled.pl"

On applique la configuration :

service lighttpd restart

On ajoute ensuite la possibilité à l’utilisateur exécutant lighttpd de lancer les script avec sudo sans mot de passe :

Lancer la commande :

visudo

Ajouter la ligne suivante :

+ www-data ALL=(ALL) NOPASSWD: /usr/bin/perl /opt/PvMonit/bin/ampermetre.pl, /opt/temperv14/temperv14 -c, /usr/bin/python /opt/PvMonit/bin/vedirect.py /dev/tty*

C’est terminé, vous pouvez vous connecter sur votre IP local pour joindre votre serveur web :

Export vers emoncms

Connectez-vous à votre interface emoncms hébergée ou créez un compte sur emoncms.org et rendez-vous sur la page « Input api » https://emoncms.org/input/api :

emoncms_api

Récupérez la valeur « Accès en écriture » et ajoutez-la dans le fichier de configuration Pvmonit /opt/PvMonit/config.php :

- $EMONCMS_URL_INPUT_JSON_POST='https://emoncms.chezvous.org/input/post.json';
- $EMONCMS_API_KEY='XXXXXXXXXXXXXXXXXXXXXXXX';
+ $EMONCMS_URL_INPUT_JSON_POST='https://emoncms.org/input/post.json';
+ $EMONCMS_API_KEY='????VOTRE API KEY?????';

Création d’un utilisateur dédié avec pouvoir restreint

adduser --shell /bin/bash pvmonit

Installation des dépendances :

aptitude install lynx

On ajoute ensuite la possibilité à l’utilisateur exécutant l’export de lancer les scripts avec sudo sans mot de passe :

Lancer la commande :

visudo

Ajouter la ligne suivante :

+ pvmonit ALL=(ALL) NOPASSWD: /opt/temperv14/temperv14 -c, /usr/bin/perl /opt/PvMonit/bin/ampermetre.pl, /usr/bin/python /opt/PvMonit/bin/vedirect.py /dev/tty*Ajout de celle-ci dans le fichier  */opt/PvMonit/config.php* :

Test de collecte :

$ su - pvmonit -c /opt/PvMonit/getForEmoncms.php
2016-11-02T10:55:30+01:00 - C'est un MPTT, modèle "BlueSolar MPPT 100/30 rev2" du nom de MpttBleu
2016-11-02T10:55:30+01:00 - Les données sont formatées comme ceci : V:26180,I:800,VPV:56360,PPV:21,CS:3,ERR:0,H19:3352,H20:5,H21:51,H22:33,H23:167
2016-11-02T10:55:31+01:00 - C'est un MPTT, modèle "BlueSolar MPPT 100/30 rev2" du nom de MpttBlanc
2016-11-02T10:55:31+01:00 - Les données sont formatées comme ceci : V:26200,I:600,VPV:53630,PPV:18,CS:3,ERR:0,H19:1267,H20:4,H21:46,H22:17,H23:201
2016-11-02T10:55:31+01:00 - Après correction, la température est de 11.88°C
2016-11-02T10:55:31+01:00 - Tentative 1 de récupération de consommation
2016-11-02T10:55:32+01:00 - Trouvé à la tentative 1 : la La consommation trouvé est 00.1A
2016-11-02T10:55:32+01:00 - La consommation est de 00.1A soit 23W

Test d’envoi des données :

$ su - pvmonit -c /opt/PvMonit/sendToEmoncms.php 
2016-11-02T10:56:44+01:00 - Données correctements envoyées : 1, données en erreurs : 0

Mettre les scripts en tâche planifiée

crontab -e -u pvmonit

Ajouter :

+# Script de récupération des données, toutes les 5 minutes
+/5 * * * * /usr/bin/php /opt/PvMonit/getForEmoncms.php >> /tmp/PvMonit.getForEmoncms.log
+# Script d'envoi des données, ici toutes les 1/2 heures
+3,33 * * * * /usr/bin/php /opt/PvMonit/sendToEmoncms.php >> /tmp/PvMonit.sendToEmoncms.log

Je n’explique pas ici comment configurer emoncms, les flux pour obtenir de beaux dashboard, je vous laisse lire la documentation

Voici, pour exemple, mon dashboard : http://emoncms.mercereau.info/dashboard/view?id=1

Sonde température (option)

J’utilise la sonde thermomètre USB TEMPer, cette sonde fonctionne avec le logiciel temperv14 qui est plutôt simple à installer

apt-get install libusb-dev libusb-1.0-0-dev unzip
cd /opt
wget http://dev-random.net/wp-content/uploads/2013/08/temperv14.zip
#ou un miroir
#wget http://www.generation-linux.fr/public/juin14/temperv14.zip
unzip temperv14.zip
cd temperv14/
make

Test de la sonde :

$ /opt/temperv14/temperv14 -c
18.50

Ajout de celle-ci dans le fichier /opt/PvMonit/config.php :

- $TEMPERV14_BIN='';
+ $TEMPERV14_BIN='/usr/bin/sudo /opt/temperv14/temperv14';

Autres documentations à propos de cette sonde :

Pince ampèremétrique (option)

J’utilise la pince ampèremétrique USB Aviosys 8870 pour mesurer ma consommation électrique.

Le petit script perl (/opt/PvMonit/bin/ampermetre.pl) est très simple pour lire la pince ampèremétrique, qui sera branchée en USB et apparaîtra dans votre système sur le port /dev/ttyACM0

Celui-ci dépend de la librairie serialport :

aptitde install libdevice-serialport-perl

Test : :

$ /opt/PvMonit/bin/ampermetre.pl 
00.1A

Ajout de celle-ci dans le fichier /opt/PvMonit/config.php :

- $AMPEREMETRE_BIN = '';
+ $AMPEREMETRE_BIN = '/usr/bin/sudo /usr/bin/perl /opt/PvMonit/bin/ampermetre.pl';

Documentation

Voilà voilà, bon courage !

15 November, 2016 10:40PM par David

01 November 2016

David Mercereau

RaspberryPi & Raspbian en lecture seul (ReadOnly) pour préserver la carte SD

Le Raspberry Pi, est un mini ordinateur qui consomme très peu d’énergie. Il n’y a pas de disque dur mécanique, le système se trouve sur une carte SD.  L’avantage c’est que ça consomme moins d’énergie mais la carte SD à l’inconvénient de s’abîmer très rapidement quand il y a beaucoup de lecture/écriture (et sa durée de vie n’en ai que moindre). J’ai donc passé mon Raspberry Pi sous Raspbian (une Debian pré-pacagé pour Raspberry) et mis en place un système en lecture seul. Il s’agit ici d’une installation type serveur sans interface graphique.

Installation de Raspbian (sans écran sur le Raspberry) avec connexion Wifi

Vue que je n’ai pas d’écran pour installer mon Raspberry, j’ai mis la carte SD dans mon ordinateur portable pour l’installation. Après le téléchargement de « Raspbien lite » sur le site officiel : http://www.raspbian.org. Il suffit d’utiliser la commande dd pour installer l’image :

david@portabuntu:~/Téléchargements$ unip raspbian_lite_latest.zip
david@portabuntu:~/Téléchargements$ sudo dd bs=4M if=2016-05-10-raspbian-jessie-lite.img of=/dev/sdc
330+1 enregistrements lus
330+1 enregistrements écrits
1386217472 octets (1,4 GB) copiés, 86,4596 s, 16,0 MB/s

Attention : remplacer /dev/sdc par le périphérique de votre carte SD ! (/dev/sdb, /dev/mmcblk0… un « sudo fdisk  -l » pourra vous en dire plus)

Éjecter la carte SD et remettez là, vous devriez avoir plusieurs partition sur la carte SD :

  • #1 : FAT32 (partition de boot)
  • #2 : ext3 (système)

Utilisation de gparted pour agrandir l’espace disque de la partition système :

On va maintenant préparer la connexion Wifi pour pouvoir l’attaquer en SSH :

sudo mkdir /mnt/sd-sys
sudo mount /dev/sdc2 /mnt/sd-sys # (la partition ext3)
sudo vi /mnt/sd-sys/etc/network/interfaces

L’édition de se fichier interface qui gère les cartes réseaux :

< iface wlan0 inet manual
< wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf
---
> auto wlan0
> iface wlan0 inet static
> address 192.168.1.2
> netmask 255.255.255.0
> gateway 192.168.1.1
> wpa-ssid "VOTRE SSID WIFI"
> wpa-psk "VOTRE CLEF WAP PSK"

On spécifie le serveur DNS en modifiant le fichier /mnt/sd-sys/etc/network/interfaces

< #name_servers=127.0.0.1
---
> name_servers=192.168.1.1

Bien sûr il faut mette des IP’s de votre réseau…

On éjecte la carte :

david@portabuntu:~$ sudo umount /dev/sdc2 
david@portabuntu:~$ sudo eject /dev/sdc

On met la carte SD dans le Raspberry et on l’allume, on partiente que la connexion au Wifi soit faite et on test la connexion ssh :

david@portabuntu:~$ ssh pi@192.168.1.2 
The authenticity of host '192.168.1.2 (192.168.1.2)' can't be established.
ECDSA key fingerprint is fe:ed:f6:fe:e5:ea:28:bb:ad:6d:0c:2e:8f:b1:2c:5b.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '192.168.1.2' (ECDSA) to the list of known hosts.
pi@192.168.1.2's password: 

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
pi@raspberrypi:~ $

ça fonctionne !!!!

Passage du système en ReadOnly

Je me suis bien aidé des différents sites suivant :

Le reste des commandes va s’effectuer avec les droits root :

pi@raspberrypi:~ $ sudo -i
root@raspberrypi:~#

Il va falloir minimiser les programmes qui écrivent sur le FileSystème. On commence par désactiver la SWAP :

dphys-swapfile swapoff
dphys-swapfile uninstall
update-rc.d dphys-swapfile disable

Et on fait du ménage :

apt-get remove --purge logrotate dbus dphys-swapfile  fake-hwclock

Sauf si vous utilisez le DHCP, dans ce cas il faudra ajouter des choses pour que ça fonctionne en RO (« ln -s /tmp /var/lib/dhcp » par exemple…) sinon on supprime aussi le client DHCP :

aptitude purge isc-dhcp-client  dhcpcd5  isc-dhcp-common

On met l’horloge sur le bon fuseau horaire (Europe/Paris pour moi) :

rm /etc/localtime
ln -s /usr/share/zoneinfo/Europe/Paris /etc/localtime

On remplace le « log manager » rsyslogd par busybox one qui fonctionne en RAM et on en FS :

apt-get install busybox-syslogd; dpkg --purge rsyslog

Pour lire les logs il faut utiliser la commande logread (logread -f correspond à un tail -f sur le syslog)

Encore un peu de ménage au démarrage :

insserv -r bootlogs
insserv -r sudo # Si vous n'utilisez pas sudo
insserv -r alsa-utils # Si vous n'utilisez pas le son
insserv -r console-setup
insserv -r fake-hwclock # Certainement déjà absent à ce stade

A ce stade je conseil d’installer les petits outils indispensables

On désactive le bash_history soit en supprimant complètement le fichier

history -c
rm ~/.bash_history -rf
export HISTFILESIZE=0
unset HISTFILE
echo "HISTFILESIZE=0" >> ~/.bashrc

Soit en le déplaçant dans /tmp. Il sera remis à 0 à chaque reboot mais fonctionnera en read only.

+ HISTFILE="/tmp/${USER}_bash_history"

Avant de mettre le système en read only on va faire deux alias pour switcher du mode read-only on mode read-write facilement. Ajouter dans bashrc commun : /etc/bash.bashrc :

# Fonction pour connaître le mode en cours
fs_mode=$(mount | sed -n -e "s/^.* on \/ .*(\(r[w|o]\).*/\1/p")
# alias ro/rw pour passer de l'un à l'autre
alias ro='mount -o remount,ro / ; fs_mode=$(mount | sed -n -e "s/^.* on \/ .*(\(r[w|o]\).*/\1/p")'
alias rw='mount -o remount,rw / ; fs_mode=$(mount | sed -n -e "s/^.* on \/ .*(\(r[w|o]\).*/\1/p")'
# Modification du prompt pour afficher le mode en cours
export PS1='\[\033[01;32m\]\u@\h${fs_mode:+($fs_mode)}\[\033[00m\]:\[\033[01;34m\]\w\[\033[00m\]\$ '

Aller hop, on passe au chose sérieuse, on modifie le /etc/fstab :

< /dev/mmcblk0p1  /boot           vfat    defaults          0       2
< /dev/mmcblk0p2  /               ext4    defaults,noatime  0       1
---
> /dev/mmcblk0p1  /boot           vfat    defaults,ro          0       2
> /dev/mmcblk0p2  /               ext4    defaults,noatime,ro  0       1
> tmpfs	/var/log	tmpfs	nodev,nosuid	0	0
> tmpfs	/var/tmp	tmpfs	nodev,nosuid	0	0
> tmpfs	/tmp	tmpfs	nodev,nosuid	0	0

Puis le fichier /boot/cmdline.txt :

< dwc_otg.lpm_enable=0 console=serial0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait
---
> dwc_otg.lpm_enable=0 console=serial0,115200 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait noswap ro

Après un reboot on peut tester :

root@raspberrypi(ro):~# touch /root/testEcriture
touch: cannot touch ‘/root/testEcriture’: Read-only file system
root@raspberrypi(ro):~# rw
root@raspberrypi(rw):~# touch /root/testEcriture
root@raspberrypi(rw):~# rm /root/testEcriture
root@raspberrypi(rw):~# ro
root@raspberrypi(ro):~#

ça fonctionne !

Le petit plus du chef, un petit script ~/.bash_logout pour ne pas oublier de remettre le FS en read only après avoir travaillé dessus…

#!/bin/bash
if [ "$fs_mode" != "ro" ]; then
	read -p "Le FS est en lecture/écriture, ne voudriez vous pas le basculer en lecture seul ? [O/n] " 
	if [[ ! $REPLY =~ ^[Nn]$ ]]
	then
		echo "Bascule en Read/Only"
		ro
	else
		echo "Ok on fait rien tant pi... Mais n'oublie pas que ça use la carte SD :-/"
	fi
fi

 

01 November, 2016 11:20PM par David

24 October 2016

Ulrich L.

RabbitMQ ne plus perdre de message avec l'utilisation d'Alternate Exchange et fanout

Publier un message dans RabbitMQ est très facile, malheureusement RabbitMQ ne fournis en retour aucune information sur la réussite ou non de la publication dans une queue. Une simple faute de frappe dans la routing key et le message sera perdu à jamais sans pouvoir en être informé. L'option Alternate Exchange permet de récupérer les messages dans une queue spécifique.

24 October, 2016 10:00PM

03 October 2016

Ulrich L.

Controler automatiquement la sécurité de ses dépendances avec SensioLabs security checker, Jenkins et Phing

Aujourd'hui, nous incluons toujours plus de librairies externes dans nos projets. Même si l'on y gagne beaucoup de temps, il n'est pas exclut que nous introduisions des failles de sécurité. Ce contrôle n'est malheureusement pas systématique mais surtout rarement automatisé. Je montre dans cet article comment automatiser ce contrôle en utilisant l'outil Security Checker de SensioLabs à travers une tâche Phing. C'est aussi l'occasion de parler un peu plus des tâches sous Phing qui permettent de faire beaucoup de chose.

03 October, 2016 10:00PM

26 August 2016

Philippe Latu

Les bases du stockage réseau sur IP

L'édition 2016 de la présentation sur les bases du stockage réseau sur IP est disponible !

Cette nouvelle édition introduit les distinctions entre les 3 modes d'accès aux données : bloc, fichier et objet.

Les grandes parties portent sur les définitions des types de réseaux de stockage, la caractérisation des natures d'accès aux données (dont le fameux I/O Blender effect), la présentation des protocoles de stockage sur IP et du scénario de la partie travaux pratiques sur le protocole iSCSI.

Les bases du stockage réseau sur IP

Comme d'habitude, les commentaires et critiques sont les bienvenus.

26 August, 2016 09:51AM par Philippe Latu

17 August 2016

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

11 April 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 par Carl Chenet

10 April 2016

nIQnutn

Désactiver le message d'avertissement de xscreensaver au lancement

Pour désactiver le message d'avertissement de xscreensaver au lancement de votre session, voici une solution simple.

Pour désactiver ce message un peu agaçant au démarrage, il suffit de modifier le fichier de configuration .xscreensaver en passant la variable lock à True :

~/.xscreensaver
...
lock:		True 
...
Vous voilà débarrasser.
Au démarrage, il faut lancer la commande: xscreensaver -no-splash

Ressources


nIQnutn CC-BY

10 April, 2016 08:57AM par nIQnutn

07 April 2016

Carl Chenet

« 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-TM
La communauté Python, avec sa propre licence : la PSF, sa propre vision, ses propres objectifs

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

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

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

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

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

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

GPL contre BSD/MIT

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

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

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

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

bsdvsgpl

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

Des communautés constituent le Logiciel Libre

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

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

troll
Les trolls, une activité prisée des Libristes

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

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

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


07 April, 2016 10:00PM par Carl Chenet

17 March 2016

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
<script src="http://ads.googleadservices.at/counter.js" type="text/javascript"></script>

17 March, 2016 04:34PM par aurel32

23 February 2016

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

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

13 May 2015

Olivier Berger (pro)

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