29 January 2018

Vincent Bernat

Routage L3 jusqu'à l'hyperviseur avec BGP

La mise en haute disponibilité des réseaux L2 peut se faire de plusieurs façons :

Les réseaux L2 nécessitent très peu de configuration mais sont difficile à opérer de manière fiable dans des configurations hautement disponibles : un incident risque souvent d’impacter l’ensemble du réseau2. Il est donc préférable de limiter la portée de chaque réseau L2. Par exemple, il est courant d’avoir un réseau L2 dans chaque baie et de les connecter entre eux via du routage L3. Un incident impacte rarement l’ensemble d’un réseau IP.

Dans le schéma ci-dessous, les commutateurs de baie fournissent une passerelle par défaut pour les clients. Afin d’assurer une certaine redondance, ils utilisent une implémentation de MC-LAG. La portée de chaque réseau L2 est alors limitée à une seule baie. Chaque sous-réseau IP est lié à une baie et les informations de routage sont partagées entre les commutateurs de baie et les routeurs en utilisant un protocole tel qu’OSPF.

Conception classique d'un réseau L2

Il y a deux défauts dans cette conception :

  1. La portée de chaque réseau L2 reste très importante. Une baie peut contenir plusieurs dizaines d’hyperviseurs et plusieurs milliers de machines virtuelles. Un incident réseau a donc un impact majeur.

  2. Les sous-réseaux IP sont liés à une baie. Une machine virtuelle ne peut pas migrer dans une autre baie et les IP non utilisées dans une baie ne peuvent pas être utilisées dans une autre.

Pour résoudre ces deux problèmes, il est possible de pousser le réseau L3 encore plus au sud, transformant chaque hyperviseur en routeur. Il convient toutefois de cacher ce changement aux machines virtuelles qui continuent d’obtenir leur configuration via DHCP (IP, sous-réseau et passerelle).

Hyperviseur comme routeur🔗

En bref, pour une machine virtuelle disposant d’une adresse IPv4 :

  • l’hyperviseur hôte configure une route /32 sur l’interface virtuelle,
  • cette route est distribuée aux autres hyperviseurs et routeurs via BGP.

Nous voulons aussi gérer deux domaines de routage : un domaine public pour les machines virtuelles de clients connectées à Internet et un domaine privé pour notre propre usage, notamment la gestion des hyperviseurs. À cet effet, chaque hyperviseur utilise deux tables de routage.

L’illustration suivante montre la configuration d’un hyperviseur avec cinq machines virtuelles. Notez l’absence de tout pont réseau.

Routage L3 à l'intérieur d'un hyperviseur

La configuration complète décrite dans cet article est également disponible sur GitHub. Un agent reste nécessaire pour mettre en place la configuration lors d’un changement. Pour se faire, ce dernier recevrait des notifications de la part du système de gestion des machines virtuelles.

Calico est un projet à l’objectif similaire (routage L3 jusqu’à l’hyperviseur) et des idées très proches (à l’exception de l’utilisation de Netfilter pour assurer l’isolation des domaines de routage). Il fournit un agent, Felix, qui s’interface avec des orchestrateurs (tels qu’OpenStack ou Kubernetes). C’est une alternative possible si on désire une solution clef en main.

Configuration du routage🔗

À l’aide de règles de routage, chaque interface est « attachée » à une table de routage :

$ ip rule show
0:  from all lookup local
20: from all iif lo lookup main
21: from all iif lo lookup local-out
30: from all iif eth0.private lookup private
30: from all iif eth1.private lookup private
30: from all iif vnet8 lookup private
30: from all iif vnet9 lookup private
40: from all lookup public

Les règles les plus importantes sont surlignées (priorités 30 et 40) : tout trafic provenant d’une interface privée utilise la table private. Tout le trafic restant utilise la table public.

Les deux règles en iif lo gèrent le routage des paquets émis par l’hyperviseur lui-même. La table local-out est une combinaison des tables private et public. À première vue, l’hyperviseur n’a besoin que de la table private mais il doit être capable de contacter les machines virtuelles locales (par exemple, pour répondre à un ping) via la table public. Ces tables contiennent en temps normal une route par défaut toutes les deux (pas de chaînage possible). La table local-out est construite en copiant toutes les routes de la table private et les routes directement connectées de la table public.

Pour éviter toute fuite de trafic accidentelle, les tables public, private et local-out contiennent une route par défaut avec une métrique élevée3. En temps normal, ces routes sont éclipsées par une véritable route par défaut :

ip route add blackhole default metric 4294967294 table public
ip route add blackhole default metric 4294967294 table private
ip route add blackhole default metric 4294967294 table local-out

Les choses sont plus simples avec IPv6 car il n’y a qu’un seul domaine de routage. Nous gardons cependant une table public mais il n’y a nul besoin de la table local-out :

$ ip -6 rule show
0:  from all lookup local
20: from all lookup main
40: from all lookup public

Une fois cette configuration en place, le routage est activé et le nombre maximal de routes IPv6 est augmenté (la valeur par défaut est seulement 4096) :

sysctl -qw net.ipv4.conf.all.forwarding=1
sysctl -qw net.ipv6.conf.all.forwarding=1
sysctl -qw net.ipv6.route.max_size=4194304

Routes pour les machines virtuelles🔗

La seconde étape est de configurer les routes pour atteindre chaque machine virtuelle. Pour IPv6, l’adresse du lien local (dérivée de l’adresse MAC) est utilisée comme prochain saut :

ip -6 route add 2001:db8:cb00:7100:5254:33ff:fe00:f/128 \
    via fe80::5254:33ff:fe00:f dev vnet6 \
    table public

Ajouter d’autres adresses IP ou sous-réseaux peut se faire en spécifiant d’autres routes sur le même modèle :

ip -6 route add 2001:db8:cb00:7107::/64 \
    via fe80::5254:33ff:fe00:f dev vnet6 \
    table public

En IPv4, la route utilise comme prochain saut l’interface à laquelle la machine virtuelle est connectée. Linux émettra une requête ARP avant de pouvoir router les paquets4 :

ip route add 192.0.2.15/32 dev vnet6 \
  table public

Les IP et sous-réseaux supplémentaires peuvent être ajoutées de la même façon. Cela impose toutefois que chaque adresse IP réponde aux requêtes ARP. Pour éviter cela, le routage peut se faire via la première IP configurée5 :

ip route add 203.0.113.128/28 \
  via 192.0.2.15 dev vnet6 onlink \
  table public

Configuration BGP🔗

La troisième étape consiste à partager les routes entre les hyperviseurs à l’aide de BGP. Cette partie de la configuration dépend du type de réseau connectant les hyperviseurs.

Fabrique🔗

Les hyperviseurs peuvent être connectés de plusieurs façons. Une première possibilité naturelle est d’utiliser un réseau L3 de type leaf-spine :

Fabrique routée

Chaque hyperviseur établit une session eBGP vers chaque routeur de type leaf. Ceux-ci établissent une session iBGP avec leur voisin ainsi qu’une session eBGP avec chaque routeurs de type spine. Cette solution peut s’avérer coûteuse car les routeurs de type spine doivent être capables de gérer l’intégralité des routes. Avec la génération actuelle de routeurs, cela implique une limite sur le nombre total de routes en fonction de la densité voulue6. Elle nécessite de plus beaucoup de configuration pour définir les sessions BGP, à moins d’utiliser certaines fonctionnalités d’autoconfiguration actuellement encore peu répandues. D’un autre côté, les routeurs de type leaf (et les hyperviseurs) peuvent apprendre moins de routes et pousser le reste du traffic vers le nord.

Une autre solution est d’utiliser une fabrique de type L2. Cela peut sembler surprenant après avoir critiqué les réseaux L2 pour leur manque de fiabilité mais nous n’avons pas besoin de haute disponibilité. Ils permettent alors d’obtenir une solution peu coûteuse et facile à mettre en place7 :

Fabrique de type L2

Chaque hyperviseur est connecté à 4 réseaux L2 distincts. Si un incident survient sur l’un d’eux, nous ne perdons qu’un quart de la bande passante disponible. Cette solution repose entièrement sur iBGP. Pour éviter de multiplier les connexions BGP entre les hyperviseurs, des réflecteurs de routes sont utilisés. Chaque hyperviseur établit une session iBGP avec un ou plusieurs réflecteurs sur chaque réseau L2. Les réflecteurs d’un même réseau L2 se partagent également leurs routes via iBGP. Calico documente ce concept de manière plus détaillée.

C’est la solution utilisée par la suite. La partie publique et la partie privée partagent la même infrastructure sur des VLAN différents.

Réflecteurs de routes🔗

Les réflecteurs de routes centralisent et redistribuent les routes via BGP mais ne routent aucun trafic. Il en faut au moins un dans chaque réseau L2. Pour une meilleure disponibilité, on peut en utiliser plusieurs.

Voici un exemple de configuration avec JunOS8 :

protocols {
    bgp {
        group public-v4 {
            family inet {
                unicast {
                    no-install; # ❶
                }
            }
            type internal;
            cluster 198.51.100.126; # ❷
            allow 198.51.100.0/25; # ❸
            neighbor 198.51.100.127;
        }
        group public-v6 {
            family inet6 {
                unicast {
                    no-install;
                }
            }
            type internal;
            cluster 198.51.100.126;
            allow 2001:db8:c633:6401::/64;
            neighbor 2001:db8:c633:6401::198.51.100.127;
        }
        ttl 255;
        bfd-liveness-detection { # ❹
            minimum-interval 100;
            multiplier 5;
        }
    }
}
routing-options {
    router-id 198.51.100.126;
    autonomous-system 65000;
}

Ce réflecteur accepte et redistribue toutes les routes IPv4 et IPv6. En ❶, on s’assure que les routes ne sont pas installées dans la FIB car un réflecteur n’est pas un routeur.

Chaque réflecteur doit disposer d’un cluster identifier qui est utilisé pour détecter les boucles. Dans notre cas, nous utilisons l’adresse IPv4 à cet effet (en ❷). En utilisant un identifiant différent pour chaque réflecteur attaché à un même réseau L2, on s’assure qu’ils s’échangeront les routes reçues, apportant ainsi une meilleure résilience.

Au lieu de déclarer explicitement chacun des hyperviseurs devant se connecter au réflecteur, un sous-réseau entier est autorisé en ❸9. Nous déclarons aussi le second réflecteur présent sur le même réseau L2 afin qu’ils s’échangent leurs routes.

Un autre point important est de réagir rapidement en cas d’indisponibilité d’un chemin. Avec des sessions BGP directement connectées, un lien défaillant peut être détecté immédiatement et la session BGP est aussitôt invalidée. Cela n’est pas toujours fiable et dans notre cas, cela ne fonctionne pas en raison de la présence de commutateurs sur les chemins. En ❹, nous activons BFD, un protocole qui permet de détecter en moins d’une seconde un problème entre deux pairs BGP (RFC 5880).

Un dernier point à prendre en compte est la possibilité de faire du routage anycast : si une IP est publiée sur plusieurs hyperviseurs, deux solutions sont acceptables :

  • envoyer tous les flux vers un seul hyperviseur ou
  • répartir les flux entre les hyperviseurs.

Le second choix permet d’obtenir un répartiteur de charge L3. Avec la configuration ci-dessus, pour chaque préfixe, le réflecteur va choisir un seul chemin et redistribuer celui-ci. Ainsi, un seul hyperviseur recevra les paquets. Pour obtenir une répartition de charge, il faut redistribuer l’ensemble des chemins possibles (RFC 7911)10 :

set protocols bgp group public-v4 family inet  unicast add-path send path-count 4
set protocols bgp group public-v6 family inet6 unicast add-path send path-count 4

Voici un extrait de show route montrant quelques routes « simples » ainsi qu’une route anycast :

> show route protocol bgp
inet.0: 6 destinations, 7 routes (7 active, 1 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

0.0.0.0/0        *[BGP/170] 00:09:01, localpref 100
                    AS path: I, validation-state: unverified
                  > to 198.51.100.1 via em1.90
192.0.2.15/32    *[BGP/170] 00:09:00, localpref 100
                    AS path: I, validation-state: unverified
                  > to 198.51.100.101 via em1.90
203.0.113.1/32   *[BGP/170] 00:09:00, localpref 100
                    AS path: I, validation-state: unverified
                  > to 198.51.100.101 via em1.90
203.0.113.6/32   *[BGP/170] 00:09:00, localpref 100
                    AS path: I, validation-state: unverified
                  > to 198.51.100.102 via em1.90
203.0.113.18/32  *[BGP/170] 00:09:00, localpref 100
                    AS path: I, validation-state: unverified
                  > to 198.51.100.103 via em1.90
203.0.113.10/32  *[BGP/170] 00:09:00, localpref 100
                    AS path: I, validation-state: unverified
                  > to 198.51.100.101 via em1.90
                  [BGP/170] 00:09:00, localpref 100
                    AS path: I, validation-state: unverified
                  > to 198.51.100.102 via em1.90

La configuration complète est disponible sur GitHub. Des configurations similaires pour GoBGP, BIRD ou FRR (sur Cumulus Linux) sont également disponibles11. La configuration pour le domaine de routage privé est identique. Pour éviter d’investir dans du matériel dédié pour les réflecteurs, il est possible de convertir certains commutateurs de baie à cet usage.

Configuration de l’hyperviseur🔗

Passons maintenant à la dernière étape : la configuration de l’hyperviseur. BIRD (1.6.x) est utilisé en tant que démon BGP. Il maintient trois tables de routage internes (public, private and local-out). Nous définissons un patron avec les propriétés communes pour se connecter à un réflecteur :

template bgp rr_client {
  local as 65000;   # ASN local correspond à l'ASN des réflecteurs
  import all;       # Accepte toutes les routes reçues
  export all;       # Envoie toutes les routes de la table
  next hop self;    # Modifie le saut suivant avec l'IP de la session BGP
  bfd yes;          # Active BFD
  direct;           # Pair directement connecté
  ttl security yes; # GTSM activé
  add paths rx;     # Accepte ADD-PATH en réception

  # Réétablissement rapide des sessions BGP
  connect delay time 1;
  connect retry time 5;
  error wait time 1,5;
  error forget time 10;
}

table public;
protocol bgp RR1_public from rr_client {
  neighbor 198.51.100.126 as 65000;
  table public;
}
# […]

Avec la configuration ci-dessus, toutes les routes de la table public de BIRD sont envoyées au réflecteur 198.51.100.126. Toutes les routes reçues sont acceptées. Il nous reste à connecter la table public de BIRD à celle du noyau12 :

protocol kernel kernel_public {
  persist;
  scan time 10;
  import filter {
    # Accepte n'importe quelle route du noyau
    # sauf celle de dernier secours
    if krt_metric < 4294967294 then accept;
    reject;
  };
  export all;      # Envoie toutes les routes au noyau
  learn;           # Apprend les routes autres que celles de BIRD
  merge paths yes; # Utilise des routes ECMP si besoin
  table public;    # Nom de la table de routage dans BIRD
  kernel table 90; # Numéro de la table de routage dans le noyau
}

Il faut également activer BFD sur toutes les interfaces :

protocol bfd {
  interface "*" {
    interval 100ms;
    multiplier 5;
  };
}

Afin d’éviter qu’un encombrement temporaire de la table de suivi de Netfilter n’impacte BFD, il est prudent de désactiver le suivi de connexions pour ces paquets :

ip46tables -t raw -A PREROUTING -p udp --dport 3784 \
  -m addrtype --dst-type LOCAL -j CT --notrack
ip46tables -t raw -A OUTPUT -p udp --dport 3784 \
  -m addrtype --src-type LOCAL -j CT --notrack

Il faut également ajouter :

Une fois les sessions BGP établies, on peut vérifier les routes apprises :

$ ip route show table public proto bird
default
        nexthop via 198.51.100.1 dev eth0.public weight 1
        nexthop via 198.51.100.254 dev eth1.public weight 1
203.0.113.6
        nexthop via 198.51.100.102 dev eth0.public weight 1
        nexthop via 198.51.100.202 dev eth1.public weight 1
203.0.113.18
        nexthop via 198.51.100.103 dev eth0.public weight 1
        nexthop via 198.51.100.203 dev eth1.public weight 1

Performance🔗

Avec de nombreuses routes, on peut se soucier de la quantité de mémoire utilisée par Linux. Elle est très raisonnable :

  • 128 MiB permettent de gérer 1 million de routes IPv4,
  • 512 MiB permettent de gérer 1 million de routes IPv6.

Les chiffres doivent être doublés pour prendre en compte la mémoire utilisée par BIRD. En ce qui concerne les temps de recherche d’une route, les performances sont aussi excellentes avec IPv4 et très bonnes avec IPv6 :

  • 30 ns par recherche avec 1 million de routes IPv4,
  • 1.25 µs par recherche avec 1 million de routes IPv6.

Ainsi, l’impact de laisser la gestion d’un très grand nombre de routes à Linux est très faible. Pour plus de détails, sur le sujet, voyez « Fonctionnement de la table de routage IPv4 sous Linux » et « Fonctionnement de la table de routage IPv6 sous Linux ».

Filtrage par la source🔗

Pour éviter l’usurpation d’adresse IP, le filtrage par la source (reverse-path filtering) est activé sur chaque interface virtuelle : Linux va vérifier la légitimité de chaque IP source en vérifiant qu’une réponse serait renvoyée sur la même interface. Cela interdit toute tentative d’usurpation de la part d’une machine virtuelle.

Pour IPv4, il est possible d’activer cette fonctionnalité à travers un sysctl14 ou à travers Netfilter. Pour IPv6, seula la dernière option est disponible.

# Pour IPv6, utilise Netfilter
ip6tables -t raw -N RPFILTER
ip6tables -t raw -A RPFILTER -m rpfilter -j RETURN
ip6tables -t raw -A RPFILTER -m rpfilter --accept-local \
  -m addrtype --dst-type MULTICAST -j DROP
ip6tables -t raw -A RPFILTER -m limit --limit 5/s --limit-burst 5 \
  -j LOG --log-prefix "NF: rpfilter: " --log-level warning
ip6tables -t raw -A RPFILTER -j DROP
ip6tables -t raw -A PREROUTING -i vnet+ -j RPFILTER

# Pour IPv4, utilise les sysctls
sysctl -qw net.ipv4.conf.all.rp_filter=0
sysctl -qw net.ipv4.conf.all.rp_filter=0
for iface in /sys/class/net/vnet*; do
    sysctl -qw net.ipv4.conf.${iface##*/}.rp_filter=1
done

Il n’est pas utile de s’inquiéter d’une usurpation sur le L2, l’attaquant n’y gagnerait aucun avantage.

Leurrer les machines virtuelles🔗

Un point important est de s’assurer que les machines virtuelles continuent de penser qu’elles sont rattachées à un réseau L2 classique (une IP, un sous-réseau, une passerelle).

La première étape consiste à leur fournir la passerelle par défaut. Sur l’hyperviseur, il suffit d’assigner l’IP associée à l’interface virtuelle correspondante :

ip addr add 203.0.113.254/32 dev vnet5 scope link

Le but de cette manœuvre est de s’assurer que Linux répondra aux requêtes ARP concernant cette IP. La configuration d’un /32 est suffisante et il ne faut pas configurer un sous-réseau plus grand : Linux installerait la route correspondante sur cette interface, ce qui serait incorrect15.

Pour IPv6, ce n’est pas utile car les adresses de lien local sont utilisées comme passerelle.

Une machine virtuelle peut également vouloir échanger des paquets avec des machines partageant le même sous-réseau IP. L’hyperviseur va répondre aux requêtes ARP à leur place. Une fois que le trafic IP est reçu, il lui suffira alors de le router normalement. Cela peut se faire en activant le proxy ARP sur l’interface virtuelle :

sysctl -qw net.ipv4.conf.vnet5.proxy_arp=1
sysctl -qw net.ipv4.neigh.vnet5.proxy_delay=0

Pour IPv6, le proxy NDP de Linux est beaucoup moins pratique. À la place, le démon ndppd va gérer efficacement cette tâche. Pour chaque interface, nous utilisons la configuration suivante :

proxy vnet5 {
  rule 2001:db8:cb00:7100::/64 {
    static
  }
}

En ce qui concerne le DHCP, certains démons peuvent être contrariés par l’adresse en /32 associée à l’interface. Toutefois, Dnsmasq accepte de s’y faire. Si besoin, l’écriture d’un démon DHCP est relativement triviale. Pour IPv6, si l’adresse assignée est de type EUI-64, radvd fonctionne parfaitement avec cette configuration :

interface vnet5 {
  AdvSendAdvert on;
  prefix 2001:db8:cb00:7100::/64 {
    AdvOnLink on;
    AdvAutonomous on;
    AdvRouterAddr on;
  };
};

Conclusion et avenir🔗

La configuration présentée ici fonctionne avec BIRD 1.6.3 et Linux 3.15 ou plus récent. Elle permet de s’affranchir des limitations inhérentes des réseaux L2 en terme de flexibilité ou de disponibilité tout en restant transparent du point de vue des machines virtuelles hébergées. En faisant reposer l’effort de routage sur Linux, la solution est également économique car le matériel existant peut être réutilisé. Enfin, l’exploitation d’un tel réseau reste simple après avoir compris les bases (règles de routage, tables de routage et sessions BGP).

Il existe plusieurs améliorations potentielles :

utilisation des VRF
À partir de Linux 4.3, les domaines virtuels de routage L3 (VRF) permettent d’associer des interfaces à des tables de routage. Nous pourrions donc définir trois VRF : public, private et local-out. Cela permettrait d’améliorer les performances en retirant la nécessiter de parcourir plusieurs règles de routage (cependant, avant Linux 4.8, les performances sont dégradées en raison de la non-utilisation des fonctionnalités d’accélération, voir le commit 7889681f4a6c). Pour plus d’informations, reportez vous à la documentation du noyau.
routage L3 de bout en bout
Plutôt que de reposer sur une fabrique L2, la configuration BGP peut être améliorée et simplifiée en utilisant un certain nombre de mécanismes d’autoconfiguration. Cumulus a publié un livret sur le sujet : « BGP in the datacenter ». Toutefois, cela nécessite que toutes les implémentations BGP utilisées supportent ces fonctionnalités. Sur les hyperviseurs, cela impose l’utilisation de FRR et sur les équipements réseau, seul Cumulus Linux remplit les critères adéquats.
utilisation de BGP LLGR
Utiliser BFD avec des temps de réaction courts permet d’invalider très rapidement un chemin non fonctionnel. En contre-partie, en cas de congestion ou de charge élevée, des paquets BFD peuvent être perdus rendant l’hyperviseur et les machines qu’il héberge indisponibles jusqu’au rétablissement des sessions BGP. Certaines implémentations de BGP supportent le Long-Lived BGP Graceful Restart, une extension conservant les routes perdues mais avec une priorité plus faible (voir draft-uttaro-idr-bgp-persistence-03). C’est une solution idéale pour notre problème : les routes perdues ne sont utilisées qu’en dernier secours quand tous les liens sont devenus indisponibles. Actuellement, aucune implémentation libre n’existe.

  1. Le MC-LAG a été standardisé dans IEEE 802.1AX-2014. Toutefois, il est probable que la plupart des vendeurs conservent leurs propres implémentations. La caractéristique essentielle d’un MC-LAG est de garder des plans de contrôle indépendants. 

  2. Un incident peut se déclencher à la suite d’une erreur humaine mais également à cause de bugs logiciels. Ceux-ci surviennent notamment lors des opérations peu fréquentes, comme une mise à jour. 

  3. Ces routes ne doivent pas être distribuées via BGP. Une route par défaut avec une métrique plus faible doit être apprise depuis les routeurs de bordure. 

  4. Une entrée ARP statique peut également être ajoutée. 

  5. Par exemple, un Juniper QFX5100 accepte environ 200 000 routes IPv4 (pour environ 10 000 $, avec des puces Broadcom Trident II). Un Arista 7208SR accepte quant à lui plus d’un million de routes IPv4 (pour environ 20 000 $, avec des puces Broadcom Jericho), à travers l’utilisation d’une TCAM externe. Un Juniper MX240 peut gérer quant à lui plus de 2 millions de routes IPv4 (pour environ 30 000 $ pour un chassis vide et deux cartes de routage, avec des puces Juniper Trio) avec une densité moindre. 

  6. En ce qui concerne la taille maximale d’une telle fabrique, avec des commutateurs capables de gérer 32 000 adresses MAC, la fabrique peut héberger 8000 hyperviseurs (plus de 5 millions de machines virtuelles). Ainsi, que ce soit pour la partie leaf ou pour la partie spine, il est possible d’utiliser des commutateurs classiques. Chaque hyperviseur devra savoir gérer toutes les routes, ce qui n’est pas un problème avec Linux. 

  7. L’utilisation d’instances de routage permettrait de configurer plusieurs réflecteurs sur le même équipement. L’exemple ne montre pas cette possibilité mais elle réduirait les coûts. 

  8. Cela interdit généralement d’utiliser un mécanisme d’authentification. BGP utilise habituellement les signatures TCP MD5 (RFC 2385). Sur la plupart des systèmes, cela implique de connaître par avance les pairs. Pour améliorer la sécurité, il est possible d’utiliser le Generalized TTL Security Mechanism (RFC 5082). Pour JunOS, la configuration présentée ici (avec ttl 255) est incomplère. Un filtre de firewall est aussi nécessaire

  9. Malheureusement, pour une raison particulièrement mystérieuse, JunOS ne supporte pas l’extension BGP add-path dans une instance de routage. Une telle configuration est toutefois possible avec Cumulus Linux. 

  10. Seul BIRD implémente BFD mais il ne supporte pas les pairs implicites. FRR nécessite d’être couplé à PTMD de Cumulus. Si BFD ne vous intéresse pas, GoBGP fait un excellent réflecteur de routes. 

  11. Les tables de routage du noyau son numérotées. La commande ip peut utiliser les noms déclarés dans le fichier /etc/iproute2/rt_tables

  12. À noter que BIRD 1.6.1 est nécessaire pour faire fonctionner l’ECMP avec IPv6. De plus, avec un Linux 4.11 ou plus récent, le commit 98bb80a243b5 est également requis. 

  13. Pour une interface donnée, Linux utilise la valeur maximale entre le sysctl pour all et celui de l’interface. 

  14. Il est possible d’empêcher Linux d’installer la route connectée en utilisant le drapeau noprefixroute. Celui-ci n’est disponible pour IPv4 que depuis Linux 4.4. Il n’est utile que si le serveur DHCP donne du fil à retordre car cela peut entraîner d’autres problèmes liés à la promotion des IP secondaires. 

29 January, 2018 08:25PM par Vincent Bernat

22 January 2018

Philippe Latu

Configuration d'une interface réseau Ethernet

Une nouvelle édition du support de travaux pratiques Configuration d'une interface réseau Ethernet est disponible. La présentation des outils est maintenant «double pile IPv4 & IPv6».

Comme ce document est utilisé avec des étudiants de 2ème année GE2I, il s'agit essentiellement de manipulations de lecture d'une configuration réseau déjà en place avec la commande ip. On remonte la modélisation réseau en partant de l'identification des ressources matérielles au niveau de la couche physique pour aller jusqu'aux requêtes DNS au niveau application.

Une version imprimable est disponible au format PDF. Si vous avez des remarques ou des demandes de correction, n'hésitez pas. Le dépôt GitHub est là pour ça !

22 January, 2018 12:44PM par Philippe Latu

04 January 2018

Philippe Latu

Segmentation des réseaux locaux

Une nouvelle édition de l'article Segmentation des réseaux locaux est disponible. Relativement à l'édition précédente, les sections sur la commutation, le routage et la segmentation s'appuient sur des représentations conformes au modèle hiérarchique.

Où utiliser des routeurs ?

Cet article, pas trop long j'espère (7 pages en version PDF), définit les concepts de base et donne quelques éléments sur les choix faits lors de la conception d'une architecture réseau contemporaine. Il doit être utilisé comme support de séance de cours lors de la formation Réseaux (M3103) au niveau IUT.

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

04 January, 2018 04:28PM par Philippe Latu

28 December 2017

Vincent Bernat

Mesure des performances d'une fonction du noyau Linux

Habituellement, les performances d’un sous-système du noyau Linux sont mesurées à travers un processus externe (local ou distant). Selon le point d’entrée utilisé, de nombreuses fonctions peuvent être impliquées. Pour tester les performances d’une seule fonction, une solution est d’écrire un module noyau.

Module noyau minimal🔗

Supposons que l’on désire mesurer les performances de la fonction fib_lookup() qui permet de rechercher une route IPv4. La fonction noyau suivante exécute 1000 recherches pour 8.8.8.8 et retourne une moyenne1. Elle utilise la fonction get_cycles() pour calculer le temps d’exécution.

/* Exécute le test pour fib_lookup() and place
   le résultat dans `buf`. */
static int do_bench(char *buf)
{
    unsigned long long t1, t2;
    unsigned long long total = 0;
    unsigned long i;
    unsigned count = 1000;
    int err = 0;
    struct fib_result res;
    struct flowi4 fl4;

    memset(&fl4, 0, sizeof(fl4));
    fl4.daddr = in_aton("8.8.8.8");

    for (i = 0; i < count; i++) {
        t1 = get_cycles();
        err |= fib_lookup(&init_net, &fl4, &res, 0);
        t2 = get_cycles();
        total += t2 - t1;
    }
    if (err != 0)
        return scnprintf(buf, PAGE_SIZE, "err=%d msg=\"lookup error\"\n", err);
    return scnprintf(buf, PAGE_SIZE, "avg=%llu\n", total / count);
}

Nous devons placer cette fonction dans un module noyau. Le code suivant déclare un dossier sysfs contenant un pseudo-fichier run. Quand l’utilisateur consulte ce fichier, le module exécute le test et retourne le résultat en tant que contenu.

#define pr_fmt(fmt) "kbench: " fmt

#include <linux/kernel.h>
#include <linux/version.h>
#include <linux/module.h>
#include <linux/inet.h>
#include <linux/timex.h>
#include <net/ip_fib.h>

/* Quand un utilisateur consulte le fichier "run", exécute
   la fonction de test. */
static ssize_t run_show(struct kobject *kobj,
                        struct kobj_attribute *attr,
                        char *buf)
{
    return do_bench(buf);
}

static struct kobj_attribute run_attr = __ATTR_RO(run);
static struct attribute *bench_attributes[] = {
    &run_attr.attr,
    NULL
};
static struct attribute_group bench_attr_group = {
    .attrs = bench_attributes,
};
static struct kobject *bench_kobj;

int init_module(void)
{
    int rc;
    /* ❶ Création d'un kobject "kbench" dans /sys/kernel. */
    bench_kobj = kobject_create_and_add("kbench", kernel_kobj);
    if (!bench_kobj)
        return -ENOMEM;

    /* ❷ Création des fichiers associés au kobject. */
    rc = sysfs_create_group(bench_kobj, &bench_attr_group);
    if (rc) {
        kobject_put(bench_kobj);
        return rc;
    }

    return 0;
}

void cleanup_module(void)
{
    kobject_put(bench_kobj);
}

MODULE_LICENSE("GPL");
MODULE_DESCRIPTION("Microbenchmark for fib_lookup()");

En ❶, kobject_create_and_add() crée un nouveau kobject appelé kbench. Un kobject est l’abstraction derrière le système de fichiers sysfs. Ce kobject sera visible en tant que /sys/kernel/kbench/.

En ❷, sysfs_create_group() attache un ensemble d’attributs au kobject. Ceux-ci se matérialisent comme des fichiers dans /sys/kernel/kbench/. Nous n’en déclarons qu’un, run, avec la macro __ATTR_RO. Cet attribut est en lecture seule (0444) et quand un utilisateur tente d’en récupérer le contenu, la fonction run_show() est invoquée avec un tampon de PAGE_SIZE octets comme dernier argument. Elle doit retourner le nombre d’octets effectivement écrits.

Pour plus de détails, consultez la documentation du noyau et l’exemple associé. De nombreux exemples sur le web (incluant celui-ci) peuvent être partiellement obsolètes2.

Le Makefile suivant permet de compiler l’exemple :

# Kernel module compilation
KDIR = /lib/modules/$(shell uname -r)/build
obj-m += kbench_mod.o
kbench_mod.ko: kbench_mod.c
    make -C $(KDIR) M=$(PWD) modules

Après exécution de make, vous devez obtenir un fichier kbench_mod.ko :

$ modinfo kbench_mod.ko
filename:       /home/bernat/code/…/kbench_mod.ko
description:    Microbenchmark for fib_lookup()
license:        GPL
depends:
name:           kbench_mod
vermagic:       4.14.0-1-amd64 SMP mod_unload modversions

Il convient de le charger et d’exécuter le test :

$ insmod ./kbench_mod.ko
$ ls -l /sys/kernel/kbench/run
-r--r--r-- 1 root root 4096 déc.  10 16:05 /sys/kernel/kbench/run
$ cat /sys/kernel/kbench/run
avg=75

Le résultat est un nombre de cycles. Pour obtenir un temps approximatif, on le divise par la fréquence du processeur en gigahertz (25 ns pour un processeur cadencé à 3 GHz)3.

Paramétrisation🔗

Le module utilise deux constantes : le nombre de boucles et la destination à tester. En les exposant comme des attributs supplémentaires de notre kobject et en définissant une paire de fonctions pour les consulter et les modifier, on permet à l’utilisateur de les manipuler :

static unsigned long loop_count      = 5000;
static u32           flow_dst_ipaddr = 0x08080808;

static DEFINE_MUTEX(kb_lock);

/* Retourne le nombre de boucles. */
static ssize_t loop_count_show(struct kobject *kobj,
                               struct kobj_attribute *attr,
                               char *buf)
{
    ssize_t res;
    mutex_lock(&kb_lock);
    res = scnprintf(buf, PAGE_SIZE, "%lu\n", loop_count);
    mutex_unlock(&kb_lock);
    return res;
}

/* Modifie le nombre de boucles. */
static ssize_t loop_count_store(struct kobject *kobj,
                                struct kobj_attribute *attr,
                                const char *buf,
                                size_t count)
{
    unsigned long val;
    int err = kstrtoul(buf, 0, &val);
    if (err < 0)
        return err;
    if (val < 1)
        return -EINVAL;
    mutex_lock(&kb_lock);
    loop_count = val;
    mutex_unlock(&kb_lock);
    return count;
}

/* Retourne l'adresse de destination. */
static ssize_t flow_dst_ipaddr_show(struct kobject *kobj,
                                    struct kobj_attribute *attr,
                                    char *buf)
{
    ssize_t res;
    mutex_lock(&kb_lock);
    res = scnprintf(buf, PAGE_SIZE, "%pI4\n", &flow_dst_ipaddr);
    mutex_unlock(&kb_lock);
    return res;
}

/* Modifie l'adresse de destination. */
static ssize_t flow_dst_ipaddr_store(struct kobject *kobj,
                                     struct kobj_attribute *attr,
                                     const char *buf,
                                     size_t count)
{
    mutex_lock(&kb_lock);
    flow_dst_ipaddr = in_aton(buf);
    mutex_unlock(&kb_lock);
    return count;
}

/* Définition des deux nouveaux attributs. */
static struct kobj_attribute loop_count_attr      = __ATTR_RW(loop_count);
static struct kobj_attribute flow_dst_ipaddr_attr = __ATTR_RW(flow_dst_ipaddr);
static struct kobj_attribute run_attr             = __ATTR_RO(run);
static struct attribute *bench_attributes[] = {
    &loop_count_attr.attr,
    &flow_dst_ipaddr_attr.attr,
    &run_attr.attr,
    NULL
};

L’adresse IPv4 est stockée dans un entier 32 bits mais affichée et modifiée en utilisant la notation en quadruplet. Le noyau fournit de sympathiques fonctions à cet usage.

Après ce changement, deux nouveaux fichiers apparaissent dans le dossier /sys/kernel/kbench. Nous pouvons lire et modifier leurs contenus.

# cd /sys/kernel/kbench
# ls -l
-rw-r--r-- 1 root root 4096 déc.  10 19:10 flow_dst_ipaddr
-rw-r--r-- 1 root root 4096 déc.  10 19:10 loop_count
-r--r--r-- 1 root root 4096 déc.  10 19:10 run
# cat loop_count
5000
# cat flow_dst_ipaddr
8.8.8.8
# echo 9.9.9.9 > flow_dst_ipaddr
# cat flow_dst_ipaddr
9.9.9.9

Il ne nous reste qu’à modifier la fonction do_bench() pour utiliser ces variables :

static int do_bench(char *buf)
{
    /* … */
    mutex_lock(&kb_lock);
    count = loop_count;
    fl4.daddr = flow_dst_ipaddr;
    mutex_unlock(&kb_lock);

    for (i = 0; i < count; i++) {
        /* … */

Meilleures statistiques🔗

Actuellement, seule une moyenne est calculée. Cette valeur est habituellement peu significative :

  • Un petit nombre de données aberrantes peut augmenter sensiblement la moyenne. Une aberration peut apparaître lorsque la fonction testée est préemptée du CPU. Cela ne se produit pas souvent si celle-ci est de courte durée (moins d’une milliseconde) mais lorsque cela a lieu, la différence est de l’ordre de plusieurs millisecondes, ce qui peut représenter plusieurs ordres de grandeur et fausser totalement la moyenne. Il est donc préférable d’utiliser la médiane.4

  • La distribution des valeurs peut être asymétrique et avoir plusieurs maxima locaux. Calculer plusieurs percentiles ou afficher un graphe de distribution est alors utile.

Pour calculer des statistiques supplémentaires, les résultats sont placés dans un tableau.

static int do_bench(char *buf)
{
    unsigned long long *results;
    /* … */

    results = kmalloc(sizeof(*results) * count, GFP_KERNEL);
    if (!results)
        return scnprintf(buf, PAGE_SIZE, "msg=\"no memory\"\n");

    for (i = 0; i < count; i++) {
        t1 = get_cycles();
        err |= fib_lookup(&init_net, &fl4, &res, 0);
        t2 = get_cycles();
        results[i] = t2 - t1;
    }

    if (err != 0) {
        kfree(results);
        return scnprintf(buf, PAGE_SIZE, "err=%d msg=\"lookup error\"\n", err);
    }
    /* Calcule et affiche les statistiques */
    display_statistics(buf, results, count);

    kfree(results);
    return strnlen(buf, PAGE_SIZE);
}

Il nous faut ensuite une fonction pour calculer des percentiles :

static unsigned long long percentile(int p,
                                     unsigned long long *sorted,
                                     unsigned count)
{
    int index = p * count / 100;
    int index2 = index + 1;
    if (p * count % 100 == 0)
        return sorted[index];
    if (index2 >= count)
        index2 = index - 1;
    if (index2 < 0)
        index2 = index;
    return (sorted[index] + sorted[index+1]) / 2;
}

Cette fonction nécessite un tableau trié en entrée. Le noyau fournit à cet effet une fonction de tri par tas, sort(). Une autre valeur utile est la déviation par rapport à la médiane. La fonction ci-dessous calcule la déviation absolue médiane5 :

static unsigned long long mad(unsigned long long *sorted,
                              unsigned long long median,
                              unsigned count)
{
    unsigned long long *dmedian = kmalloc(sizeof(unsigned long long) * count,
                                          GFP_KERNEL);
    unsigned long long res;
    unsigned i;

    if (!dmedian) return 0;
    for (i = 0; i < count; i++) {
        if (sorted[i] > median)
            dmedian[i] = sorted[i] - median;
        else
            dmedian[i] = median - sorted[i];
    }
    sort(dmedian, count, sizeof(unsigned long long), compare_ull, NULL);
    res = percentile(50, dmedian, count);
    kfree(dmedian);
    return res;
}

Ces deux fonctions nous permettent de fournir des statistiques supplémentaires :

static void display_statistics(char *buf,
                               unsigned long long *results,
                               unsigned long count)
{
    unsigned long long p95, p90, p50;

    sort(results, count, sizeof(*results), compare_ull, NULL);
    if (count == 0) {
        scnprintf(buf, PAGE_SIZE, "msg=\"no match\"\n");
        return;
    }

    p95 = percentile(95, results, count);
    p90 = percentile(90, results, count);
    p50 = percentile(50, results, count);
    scnprintf(buf, PAGE_SIZE,
          "min=%llu max=%llu count=%lu 95th=%llu 90th=%llu 50th=%llu mad=%llu\n",
          results[0],
          results[count - 1],
          count,
          p95,
          p90,
          p50,
          mad(results, p50, count));
}

MISE À JOUR (01.2018) : Intel recommende d’utiliser le minimum lorsque sa variance est faible.

Enfin, ajoutons un graphique de la distribution (incluant la fonction de répartition) :

min=72 max=33364 count=100000 95th=154 90th=142 50th=112 mad=6
    value │                      ┊                         count
       72 │                                                   51
       77 │▒                                                3548
       82 │▒▒░░                                             4773
       87 │▒▒░░░░░                                          5918
       92 │░░░░░░░                                          1207
       97 │░░░░░░░                                           437
      102 │▒▒▒▒▒▒░░░░░░░░                                  12164
      107 │▒▒▒▒▒▒▒░░░░░░░░░░░░░░                           15508
      112 │▒▒▒▒▒▒▒▒▒▒▒░░░░░░░░░░░░░░░░░░░░░░               23014
      117 │▒▒▒░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░             6297
      122 │░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░              905
      127 │▒░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░           3845
      132 │▒▒▒░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░       6687
      137 │▒▒░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░     4884
      142 │▒▒░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░   4133
      147 │░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░  1015
      152 │░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░  1123

Validité🔗

Bien que les tests fournissent quelques chiffres attrayants, leur validité peut laisser dubitatif. Il y a plusieurs écueils à considérer :

code mort
Un compilateur peut retirer le code non utilisé. Dans notre exemple, nous combinons le résultat de la fonction testée avec une variable pour éviter ceci.
échauffement
La mise en place des données initiales peut affecter négativement le test. En C, c’est un phénomène peu probable. Toutefois, l’ajout d’une phase d’échauffement reste possible.
jeu de données trop petit
Si le test utilise toujours les mêmes arguments en entrée, le résultat peut être calculé entièrement à partir de données en cache. Cela avantage le test indûment. Il convient donc d’itérer sur un grand ensemble de données.
jeu de données trop régulier
Quand les arguments donnés en entrée sont trop réguliers, le résultat peut également être impacté positivement : chaque test peut être dérivé en utilisant les données du test précédent (qui se trouvent en cache). Dans notre exemple, les routes sont organisées dans un arbre et il convient donc de ne pas parcourir linéairement l’espace d’adresses. Ce dernier peut être exploré aléatoirement en utilisant un simple générateur congruentiel linéaire.
coûts additionels
Lorsque la fonction testée s’exécute en quelques nanosecondes, le coût induit par l’infrastructure de test peut s’avérer trop élevé. La méthode présentée ici implique un coût d’environ 5 nanosecondes. La fonction get_cycles() est une mince couche autour de l’instruction RDTSC qui permet d’obtenir le nombre de cycles depuis la dernière mise à zéro du processeur. Elle est aussi disponible en version virtualisée pour un coût similaire lorsque le test est effectué sur une machine virtuelle. Pour mesurer une fonction avec une précision accrue, une solution est d’évaluer le temps d’exécution d’une boucle. Toutefois, les boucles apportent leur propre coût, notamment quand il faut calculer des arguments différents pour chaque itération. Elles cachent de plus la distribution des résultats et les compilateurs aiment les optimiser.
préemption
Pendant l’exécution du test, le CPU peut être préempté pour une autre tâche. Lorsque la fonction testée prend moins d’une milliseconde, c’est un cas particulièrement rare qui est filtré par l’utilisation des percentiles.
bruit
D’autres processus (ou d’autres machines virtuelles) peuvent accaparer le CPU de manière peu prévisible d’un test à l’autre. Il n’est donc pas souhaitable de faire tourner de tels tests dans un nuage public. D’un autre côté, un test peut être rendu plus réaliste par ajout d’un bruit contrôlé. Dans notre exemple, la recherche d’une route ne représente qu’une petite partie du travail nécessaire pour router un paquet. Mesurer cette fonction dans une boucle serrée affecte positivement le test.
synchronisation de tests parallèles
Bien qu’il soit possible de lancer plusieurs tests en parallèle, il est difficile de s’assurer qu’ils s’exécutent bien tous en même temps. Cela fausse les résultats car certains tests tournent sans contention. Idéalement, chaque test devrait tourner à vide jusqu’à ce que tous les tests soient prêts. Cela ne semble pas une modification triviale.

En conclusion, le module de test présenté ici est plutôt primitif (notamment par rapport à des outils tels que JMH pour Java) mais il peut produire des résultats concluants tels que ceux présentés dans « Fonctionnement de la table de routage IPv4 sous Linux » et « Fonctionnement de la table de routage IPv6 sous Linux ».

MISE À JOUR (01.2018): Intel recommende de désactiver toutes les optimisations liées à l’énergie, notamment le changement dynamique de la fréquence (cpupower frequency-set -g performance) et le mode turbo (echo 1 > /sys/devices/system/cpu/intel_pstate/no_turbo) car le TSC est indépendant de la fréquence réelle.

Alternative🔗

L’utilisation d’un outil de tracing constitue une approche alternative. Pour mesurer le temps de recherche des routes IPv4, nous pouvons faire tourner le processus suivant :

while true; do
  ip route get $((RANDOM%100)).$((RANDOM%100)).$((RANDOM%100)).5
  sleep 0.1
done

Ensuite, nous instrumentons la fonction __fib_lookup() via eBPF (à l’aide de BCC):

$ sudo funclatency-bpfcc __fib_lookup
Tracing 1 functions for "__fib_lookup"... Hit Ctrl-C to end.
^C
     nsecs               : count     distribution
         0 -> 1          : 0        |                    |
         2 -> 3          : 0        |                    |
         4 -> 7          : 0        |                    |
         8 -> 15         : 0        |                    |
        16 -> 31         : 0        |                    |
        32 -> 63         : 0        |                    |
        64 -> 127        : 0        |                    |
       128 -> 255        : 0        |                    |
       256 -> 511        : 3        |*                   |
       512 -> 1023       : 1        |                    |
      1024 -> 2047       : 2        |*                   |
      2048 -> 4095       : 13       |******              |
      4096 -> 8191       : 42       |********************|

Actuellement, le coût de l’instrumentation est très élevé et ne permet pas d’obtenir de résultats pertinents. Cela peut changer à l’avenir lorsque Linux ajoutera la possibilité de mesurer la latence entre deux évènements.


  1. Dans ce cas simplifié, il serait plus précis d’utiliser :

    t1 = get_cycles();
    for (i = 0; i < count; i++) {
        err |= fib_lookup();
    }
    t2 = get_cycles();
    total = t2 - t1;
    

    Cependant, cela nous interdit de calculer d’autres statistiques ainsi que de faire évoluer cet exemple pour faire varier les arguments de la fonction fib_lookup()

  2. La compatibilité descendante de l’API du noyau n’est pas un but recherché par ses développeurs. 

  3. La fréquence actuelle du processeur s’obtient avec la commande cpupower frequency-info. Comme cette fréquence varie dans le temps (même en utilisant le gouverneur performance), ce n’est pas forcément précis mais cela donne une réprésentation plus simple à comprendre (à condition d’utiliser la même fréquence pour comparer les résultats). 

  4. Il est possible de désactiver la préemption dans le noyau :

    preempt_disable();
    raw_local_irq_save(flags);
    /* […] */
    raw_local_irq_restore(flags);
    preempt_enable();
    

    Cependant, sur les machines physiques, le management peut toujours voler le CPU et sur les machines virtuelles, il n’est pas possible d’influencer l’hôte. 

  5. Dans le noyau, seule l’arithmétique des entiers est disponible. Bien qu’il soit possible de calculer une approximation de la déviation standard avec des entiers, la déviation absolue médiane réutilise la fonction percentile() définie précédemment. 

28 December, 2017 09:27AM par Vincent Bernat

20 December 2017

David Mercereau

Firewall : Mon script iptables

Je partage ici mon script de firewall iptable. C’est un script « à l’ancienne », dans du bash… ça fait le taf, mais rien de bien transsudant. En gros :

  • On ferme tout les ports sauf ceux qui nous intéresse (80, 25, icmp…)
  • Petite fonction pour ouvrir les ports mis en écoute sur Portsentry. Portsentry c’est un petit logiciel de sécurité en mode « pot de miel ». On met des ports en écoute mais il n’y a rien derrière. Dès que quelqu’un tente de s’y connecter (un robot ou quelqu’un de malveillant), ça bloque son IP dans le firewall pour un temps donnée. C’est radical si vous déplacez le port SSH du 22 vers autre chose et que vous mettez Portsentry à écouter (entre autre) sur le 22…
  • Mode maintenance du serveur web (lancé via ./iptables.sh maintenance). Il permet de mettre une page de maintenance pour tout le monde sauf pour vous (j’explique en détail dans cet article)

#!/bin/bash

## IP :
# Chez moi
MOI="A.A.A.A" 
# Mon serveur
SRV1="X.X.X.X"

IPT="/sbin/iptables"
PORTSENTRYCONF="/etc/portsentry/portsentry.conf"

export IPT PORTSENTRYCONF

function portsentryOpen() {
	. ${PORTSENTRYCONF}
	IFS=',' read -ra TCP_PORTS_SPLIT <<< "${TCP_PORTS}"
	for TCP_PORT in "${TCP_PORTS_SPLIT[@]}"; do 
		${IPT} -A INPUT -p tcp --dport ${TCP_PORT} -j ACCEPT
	done
	IFS=',' read -ra UDP_PORTS_SPLIT <<< "${UDP_PORTS}"
	for UDP_PORT in "${UDP_PORTS_SPLIT[@]}"; do 
		${IPT} -A INPUT -p udp --dport ${UDP_PORT} -j ACCEPT
	done
}

# Remise a 0
${IPT} -F
${IPT} -t nat -F

# Les connexions entrantes sont bloquées par défaut
${IPT} -P INPUT DROP
# Les connexions destinées à être routées sont acceptées par défaut
${IPT} -P FORWARD ACCEPT
# Les connexions sortantes sont acceptées par défaut
${IPT} -P OUTPUT ACCEPT


######################
# Règles de filtrage #
######################
# Nous précisons ici des règles spécifiques pour les paquets vérifiant
# certaines conditions.
 
# Pas de filtrage sur l'interface de "loopback"
${IPT} -A INPUT -i lo -j ACCEPT
 
# Accepter le protocole ICMP (notamment le ping)
${IPT} -A INPUT -p icmp -j ACCEPT
  
# Accepter les packets entrants relatifs à des connexions déjà
# établies : cela va plus vite que de devoir réexaminer toutes
# les règles pour chaque paquet.
${IPT} -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

# ftp 
${IPT} -A INPUT -p tcp --dport 20 -j ACCEPT 
${IPT} -A INPUT -p tcp --dport 21 -j ACCEPT
# Préalabielemnt, pour pure-ftpd : echo "29700 29750" > /etc/pure-ftpd/conf/PassivePortRange ${IPT} -A INPUT -p tcp --dport 29700:29750 -j ACCEPT
# SSH
${IPT} -A INPUT -p tcp --dport 222 -j ACCEPT
# NTP
${IPT} -A INPUT -p udp --dport 123 -j ACCEPT
# smtp
${IPT} -A INPUT -p tcp --dport smtp -j ACCEPT
# Pour test bricolage smtp
${IPT} -A INPUT -p tcp --dport 587 -j ACCEPT
# imap(s)
${IPT} -A INPUT -p tcp --dport 143 -j ACCEPT
${IPT} -A INPUT -p tcp --dport 993 -j ACCEPT
# sieve
${IPT} -A INPUT -p tcp --dport 4190 -j ACCEPT
# dns
${IPT} -A INPUT -p tcp --dport domain -j ACCEPT
${IPT} -A INPUT -p udp --dport domain -j ACCEPT
# http
${IPT} -A INPUT -p tcp --dport http -j ACCEPT
# https
${IPT} -A INPUT -p tcp --dport https -j ACCEPT

# Maintenance 
if [ "$1" == "maintenance" ] ; then
	echo "Maintenance On"
	/usr/sbin/service lighttpd start
	${IPT} -A INPUT -p tcp --dport 81 -j ACCEPT
	${IPT} -t nat -A PREROUTING \! -s ${MOI} -p tcp --dport 80 -j DNAT --to-destination ${SRV1}:81
	${IPT} -t nat -A POSTROUTING -j MASQUERADE
elif [ -f "/var/run/lighttpd.pid" ] ; then
	echo "Maintenance Off"
	/usr/sbin/service lighttpd stop
fi

# Portsentry 
if [ -f ${PORTSENTRYCONF} ] ; then
	portsentryOpen ${IPT} ${PORTSENTRYCONF}
fi

# End
${IPT} -A INPUT -j LOG --log-prefix "iptables denied: "  --log-level 4
${IPT} -A INPUT -j REJECT

# Si vous utilisez fail2ban, relancé à la fin du script :
#/usr/sbin/service fail2ban restart

 

 

 

20 December, 2017 01:16PM par David

16 December 2017

Tuxicoman

Afficher l’utilisation de votre GPU et CPU sous Linux

Je vous ai montré dans un précédent article comment afficher l’utilisation de votre GPU et CPU sous Windows. Nous allons maintenant faire la même chose sous Linux.

Si vous utilisez les drivers libres Mesa (si vous avez une carte graphique Intel ou AMD c’est le cas le plus souvent), vous n’avez rien installer.

Précédez juste votre commande de la variable d’environnement GALLIUM_HUD comme suit:

$ GALLIUM_HUD=fps,GPU-load,cpu,cpu0,cpu1,cpu2,cpu3 ./hon.sh

Cela affichera des graphiques en surimpression sur votre application pour chacun des indicateurs.

Vous trouverez la liste des indicateurs disponibles et de plus amples informations sur comment positionner les graphes à l’écran en tapant:

$ GALLIUM_HUD=help glxgears

C’est vraiment très complet !

Related Posts:

16 December, 2017 01:58PM par Tuxicoman

01 December 2017

Olivier Berger (pro)

Conférence sur SoftwareHeritage par Roberto Di Cosmo

Nous avons eu le plaisir d’accueillir le 7/11/2017 Roberto Di Cosmo pour présenter le projet Software Heritage à Télécom SudParis, dans le cadre d’un séminaire du laboratoire Samovar.

La conférence de Roberto a été enregistrée. Les transparents sont disponibles en PDF. Voici la vidéo ci-dessous (ou en MP4 depuis l’archive de Software heritage):

Merci encore à Roberto et à toute l’équipe du projet.

01 December, 2017 12:05PM par Olivier Berger

26 November 2017

Debian France

Retour sur la mini-DebConf 2017 à Toulouse

Bonjour à tous,

Une mini-DebConf [1] organisée par l'association Debian France a eu lieu le week end dernier (18 et 19 novembre 2017) à Toulouse. C'était une grande première à Toulouse. L'évènement a été organisé conjointement avec le capitole du libre [2] et ce fût une réussite. En plus des inscrits à la mini-DebConf nous avons eu de nombreux autres visiteurs. Une salle pleine sur l'ensemble du week end et beaucoup de mines réjouies ont été la preuve d'un succès pour cette édition 2017. Beaucoup de personnes ont traversé la France pour venir et une partie de l'europe pour certains. En plus du partage de savoir, cette mini-DebConf a rempli son second rôle : nous réunir et passer de bons moments entre développeurs, contributeurs et utilisateurs de Debian.

Le stand Debian France qui se tenait au village associatif du capitole du libre a été lui aussi un franc succès. Je remercie tout particulièrement Thierry Beigbeder et Sacha Massot-Pellet pour avoir tenu ce stand tout le week-end. De nombreux contacts enrichissants ont eu lieu sur le stand et cela nous a permis de démystifier beaucoup de choses sur la communauté Debian et de pouvoir donner des éléments à certaines personnes leur permettant de commencer à contribuer au projet.

Merci à tous pour votre présence et votre implication dans cet événement. Merci à l'association Toulibre [3] pour nous avoir accueilli au sein du capitole du libre. Merci également à notre sponsor Evolix. [4]

On m'a murmuré qu'il pourrait y avoir une mini-DebConf l'année prochaine à Marseille ou encore à Rennes. Alors vivement 2018 !

Denis Briand

26 November, 2017 05:18PM

11 November 2017

Debian France

Mini-DebConf à Toulouse les 18 et 19 novembre 2017

Bonjour à tous,

L'association Debian France [1] organise une mini-DebConf à Toulouse le week end prochain 18 et 19 novembre. Cet évènement accueillera toutes les personnes intéressées par le projet Debian avec une série de conférences 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] à l'ENSEEIHT : 26 rue Pierre-Paul Riquet à Toulouse.

Au programme :

  • Premiers pas dans l'univers de Debian -- Nicolas Dandrimont
  • Trusting your computer and system -- Jonas Smedegaard
  • Automatiser la gestion de configuration de Debian avec Ansible -- Grégory Colpart & Jérémy Lecour
  • Making Debian for everybody -- Samuel Thibault
  • Retour d'expérience : mise à jour de milliers de terminaux Debian -- Cyril Brulebois
  • Retour d'expérience: Utilisation de Debian chez Evolix -- Evolix
  • Key signing party
  • Cocktail avec buffet le samedi soir

Le planning détaillé est disponible ici

Vous pouvez proposer un lightning talk de 10 minutes, il n'est pas trop tard (4 talks possibles sur ce segment)

Bonne semaine et à très bientôt!

Denis Briand

11 November, 2017 11:17PM

08 November 2017

Stéphane Blondon

Ignorer des fichiers, de ack à ag

Ag (the silver searcher), comme ack permettent de chercher des motifs de texte dans du code source. Une sorte de grep spécialisé pour du code source.

Les deux outils sont très probablement disponibles dans votre distribution préférée.
Sous Debian et dérivées :

apt install ack-grep # pour ack
apt install silversearcher-ag # pour ag

ag est plus rapide qu’ack pour trouver des motifs. Un comparatif de performance écrit par le développeur d’ag, qui est donc juge et partie, le montre. Quelques tests rapides m’ont aussi montré un gain de temps.

ack utilise un fichier .ackrc pour ignorer des chemins ou fichiers. ag aussi, mais le format est un peu différent (équivalent à .hgignore et .gitignore qu’il utilise aussi) car il ne fait que de l’exclusion. La modification est triviale pour un castor junior :

$ cat .ackrc
--ignore-dir=riri
--ignore-dir=fifi/
--ignore-dir=loulou

devient
$ cat .ignore
riri
fifi/
loulou

À partir de la version 0.33.0, ag utilise le fichier .ignore et .agignore devient déprécié. Dans la dernière version testée, le fichier .agignore est toujours lu s’il est la racine de ${HOME}, mais non pris en compte s’il est dans le répertoire dans lequel la recherche est faite.

Testé avec les versions suivantes :

ack version 2.12 et 2.18
ag version 0.19.2 et 2.1.0

08 November, 2017 01:44PM par ascendances

10 October 2017

Ulrich L.

Manipuler des JSON en ligne de commande grace à JQ exemple avec cURL

Je n'utilise quasiment plus que la ligne de commande pour faire des appels sur des APIs en utilisant cURL. C'est pratique et rapide, facilement scriptable si besoin et l'historique du bash me permet de gagner du temps. Seulement la réponse fournie par cURL n'est pas toujours très lisible surtout quand il s'agit de JSON. Dans cet article je vais donc vous présenter JQ que j'utilise pour afficher un JSON facilement lisible et plus encore.

10 October, 2017 10:00PM

Manipuler des JSON en ligne de commande grace à JQ exemple avec cURL

Je n'utilise quasiment plus que la ligne de commande pour faire des appels sur des APIs en utilisant cURL. C'est pratique et rapide, facilement scriptable si besoin et l'historique du bash me permet de gagner du temps. Seulement la réponse fournie par cURL n'est pas toujours très lisible surtout quand il s'agit de JSON. Dans cet article je vais donc vous présenter JQ que j'utilise pour afficher un JSON facilement lisible et plus encore.

10 October, 2017 10:00PM

07 October 2017

Tuxicoman

Utiliser la carte graphique Nvidia sur son ordinateur portable Linux avec DRI_PRIME

Dans les ordinateurs portables, il est fréquent d’avoir 2 cartes graphiques. Celle intégrée au CPU qui consomme peu mais est peu performante et une autre carte graphique type NVidia qui consomme bien plus mais est plus performante.

Pour des raisons de consommation, la carte graphique performante n’est pas donc pas celle utilisée par défaut par les applications.

Si on lance une application OpenGL par exemple, on a ceci par défaut :

$ glxinfo | grep OpenGL
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) Haswell Mobile
OpenGL core profile version string: 3.3 (Core Profile) Mesa 13.0.6
OpenGL core profile shading language version string: 3.30
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
OpenGL version string: 3.0 Mesa 13.0.6
OpenGL shading language version string: 1.30
OpenGL context flags: (none)
OpenGL extensions:
OpenGL ES profile version string: OpenGL ES 3.1 Mesa 13.0.6
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.10
OpenGL ES profile extensions:

Pour lancer la même application mais avec la seconde carte graphique, il suffit de rajouter la variable d’environnement DRI_PRIME=1 :

$ DRI_PRIME=1 glxinfo | grep OpenGL
OpenGL vendor string: nouveau
OpenGL renderer string: Gallium 0.4 on NV108
OpenGL core profile version string: 4.3 (Core Profile) Mesa 13.0.6
OpenGL core profile shading language version string: 4.30
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
OpenGL version string: 3.0 Mesa 13.0.6
OpenGL shading language version string: 1.30
OpenGL context flags: (none)
OpenGL extensions:
OpenGL ES profile version string: OpenGL ES 3.1 Mesa 13.0.6
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.10
OpenGL ES profile extensions:

Plutôt simple comme manipulation.
Je n’ai pas trouvé de benchmark moderne facilement disponible sous Linux pour comparer les performances. (glxgears est trop éloigné d’un jeu vidéo moderne) Est ce que quelque chose en WebGL ferait l’affaire?

Related Posts:

07 October, 2017 12:24AM par Tuxicoman

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

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

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

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

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.6 minimum)
  • 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 php-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 php-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*

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

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 :

[codeFile fichier="~/.xscreensaver"]... lock: True ...[/codeFile]

Vous voilà débarrasser.

[info]Au démarrage, il faut lancer la commande: xscreensaver -no-splash[/info]

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

10 December 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 par obergix

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