10 May 2017

Tuxicoman

Debian 8.8

Mise à jour pour la version stable de Debian qui passe à la version 8.8

Vous trouverez ici la liste des changements en français. Comme d’habitude, principalement des corrections de bugs et de sécurité.

A noter la suppression du paquet Owncloud car il était obsolète. Il faut maintenant l’installer à la main (voir passer à Nextcloud)

N’oubliez pas que pour bénéficier de la mise à jour du noyau, il faut redémarrer la machine.

 

Related Posts:

10 May, 2017 06:51AM par Tuxicoman

07 May 2017

Tuxicoman

Raccourcis clavier Gnome Shell

Avez-vous jeté un oeil à la liste des raccourcis claviers pour le bureau Gnome?

J’y ai découvert des trucs bien sympas comme :

  • verrouiller sa session
  • basculer entre les fenêtres d’une même application
  • prendre une capture d’écran de l’application
  • enregistrer une vidéo de ce qui se passe à l’écran
  • bouger une fenêtre d’un écran à l’autre
  • se déplacer entre les bureau virtuels
  • ouvrir le panneau de notification
  • lancer une commande

 

Related Posts:

07 May, 2017 05:03AM par Tuxicoman

03 May 2017

Vincent Bernat

VXLAN: BGP EVPN avec Cumulus Quagga

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

Déploiement de VXLAN

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

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

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

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

Introduction à BGP EVPN

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

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

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

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

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

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

Déploiement VXLAN avec des réflecteurs de routes

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

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

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

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

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

Configuration des réflecteurs

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

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

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

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

Quagga

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

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

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

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

GoBGP

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

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

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

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

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

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

Juniper JunOS

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

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

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

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

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

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

Configuration des VTEP

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

Interface VXLAN et son pont

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

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

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

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

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

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

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

Vérifications

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

Récupération des informations sur les VXLAN

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

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

Les deux points importants sont :

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

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

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

Sessions BGP

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

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

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

La commande donne les informations suivantes :

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

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

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

Avec JunOS, voici la commande équivalente :

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

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

Routes envoyées

Depuis chaque VTEP, Quagga doit envoyer :

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

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

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

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

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

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

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

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

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

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

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

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

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

Avec GoBGP, il convient d’utiliser cette commande :

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

Routes reçues

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

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

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

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

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

Programmation de la FDB dans le noyau

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

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

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

Interopérabilité

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Et voici une route de type 2 :

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

03 May, 2017 09:56PM par Vincent Bernat

VXLAN & Linux

VXLAN est un protocole réseau permettant de transporter du trafic Ethernet au-dessus d’un réseau IP existant tout en supportant un nombre très elevé de locataires. Il est défini dans la RFC 7348.

Depuis Linux 3.12, l’implémentation de VXLAN est plutôt complète et supporte aussi bien le multicast que l’unicast, au-dessus d’IPv6 ou d’IPv4. Regardons les différentes façons de le mettre en œuvre.

VXLAN setup

Pour illustrer les exemples qui suivent, nous utilisons la configuration suivante :

  • un réseau IP existant (hautement disponible et évolutif, peut-être Internet),
  • trois ponts Linux servant de terminaison VXLAN (VXLAN tunnel endpoints ou VTEP),
  • quatre serveurs croyant partager un segment Ethernet commun.

Un tunnel VXLAN étend les segments Ethernet existants en un unique segment Ethernet (virtuel). Depuis n’importe quel hôte (par exemple H1), nous pouvons atteindre tous les autres hôtes partageant le segment virtuel:

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

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

Usage simple

Le déploiement de référence pour VXLAN est d’utiliser un groupe IP multicast pour joindre les autres VTEP:

# ip -6 link add vxlan100 type vxlan \
>   id 100 \
>   dstport 4789 \
>   local 2001:db8:1::1 \
>   group ff05::100 \
>   dev eth0 \
>   ttl 5
# brctl addbr br100
# brctl addif br100 vxlan100
# brctl addif br100 vnet22
# brctl addif br100 vnet25
# brctl stp br100 off
# ip link set up dev br100
# ip link set up dev vxlan100

Les commandes ci-dessus créent une interface de terminaison VXLAN appelée vxlan100 et la place dans un pont avec d’autres interfaces classiques1. Chaque segment VXLAN est associé à un identifant sur 24 bits, le VXLAN Network Identifier (VNI). Dans notre exemple, le VNI par défaut est configuré avec la directive id 100.

La première implémentation de VXLAN remonte à Linux 3.7 et le port UDP à utiliser n’était pas encore défini. Plusieurs constructeurs ont choisi 8472 et Linux a aussi opté pour cette valeur. Afin de ne pas casser les déploiements existants, c’est toujours la valeur par défaut. Pour utiliser le port assigné par l’IANA, il faut indiquer explictement la directive dstport 4789.

Pour utiliser le transport multicast, nous devons en préciser le groupe (group ff05::100) ainsi que l’interface physique à laquelle s’associer (dev eth0). Le TTL par défaut est alors de 1. Si le réseau sous-jacent utilise du routage, il peut être nécessaire d’augmenter cette valeur, comme ici avec la directive ttl 5.

L’interface vxlan100 se comporte comme un pont et considère les VTEP distants comme des ports virtuels :

  • les trames dont la destination n’est pas connue et celles à large diffusion (broadcast, unknown unicast and multicast ou « BUM ») sont envoyées à tous les VTEP en utilisant le groupe multicast,
  • les associations entre les adresses MAC et les IP des VTEP sont découvertes via l’apprentissage des adresses source.

La figure suivante détaille la configuration mise en place:

Bridged VXLAN device

La table de correspondance MAC/VTEP (« Forwarding Database » ou FDB) de l’interface VXLAN peut être consultée avec la commande bridge. Lorsque l’adresse MAC destination est connue, la trame est envoyée au VTEP associé (unicast). L’adresse 00:00:00:00:00:00 n’est utilisée que lorsqu’une entrée plus spécifique n’existe pas.

# bridge fdb show dev vxlan100 | grep dst
00:00:00:00:00:00 dst ff05::100 via eth0 self permanent
50:54:33:00:00:0b dst 2001:db8:3::1 self
50:54:33:00:00:08 dst 2001:db8:1::1 self

Pour plus de détails sur la façon de configurer un réseau multicast et l’utiliser pour construire des segments VXLAN, jetez un œil à mon article « Réseaux virtuels avec VXLAN ».

Sans multicast

L’utilisation d’un réseau IP multicast comme transport pour VXLAN présente plusieurs avantages :

  • découverte automatique des autres VTEP,
  • bonne utilisation de la bande passante (les paquets sont dupliqués tardivement),
  • conception décentralisée et sans contrôleur2.

Toutefois, le multicast n’est pas disponible partout et sa mise en œuvre est parfois compliquée. Depuis Linux 3.8, les extensions DOVE ont été ajoutées et elles permettent notamment de supprimer cette dépendance sur le multicast.

Unicast avec déclaration statique des VTEP

Il est possible de remplacer le multicast par une réplication par l’émetteur de chaque trame de type « BUM » vers une liste de VTEP distants3 :

# ip -6 link add vxlan100 type vxlan \
>   id 100 \
>   dstport 4789 \
>   local 2001:db8:1::1
# bridge fdb append 00:00:00:00:00:00 dev vxlan100 dst 2001:db8:2::1
# bridge fdb append 00:00:00:00:00:00 dev vxlan100 dst 2001:db8:3::1

Le VXLAN est défini sans groupe multicast. À la place, les VTEP distants sont associés à l’adresse 00:00:00:00:00:00. Une trame de type « BUM » sera envoyée à chacune de ces destinations. L’interface VXLAN apprend également toujours les adresses MAC sources, limitant ainsi ce type d’envois.

Il s’agit d’une solution très simple. Avec un peu d’automatisation, il est possible de garder à jour la liste des VTEP. La duplication des trames à la source devient problématique quand il y a des centaines de VTEP.

Le démon vxfld de Cumulus est un exemple d’utilisation de cette stratégie dans l’un des deux modes de fonctionnement supportés.

Unicast avec déclaration statique des entrées L2

Quand l’association entre les adresses MAC et les VTEP est connue, il est possible de renseigner par avance la FDB et de désactiver l’apprentissage :

# ip -6 link add vxlan100 type vxlan \
>   id 100 \
>   dstport 4789 \
>   local 2001:db8:1::1 \
>   nolearning
# bridge fdb append 00:00:00:00:00:00 dev vxlan100 dst 2001:db8:2::1
# bridge fdb append 00:00:00:00:00:00 dev vxlan100 dst 2001:db8:3::1
# bridge fdb append 50:54:33:00:00:09 dev vxlan100 dst 2001:db8:2::1
# bridge fdb append 50:54:33:00:00:0a dev vxlan100 dst 2001:db8:2::1
# bridge fdb append 50:54:33:00:00:0b dev vxlan100 dst 2001:db8:3::1

Le drapeau nolearning désactive l’apprentissage des adresses sources. Si une adresse MAC est manquante, la trame sera toujours envoyée en utilisant les adresses pour l’entrée 00:00:00:00:00:00.

Cette dernière est toujours nécessaire pour le trafic à diffusion générale ou restreinte (ARP et la découverte des voisins en IPv6). Ce type de configuration fonctionne bien pour des machines virtuelles (les adresses MAC sont connues, mais pas les adresses IP). Un composant qui maintient à jour les entrées de la FDB est nécessaire.

BGP EVPN avec Cumulus Quagga est un exemple d’utilisation de cette stratégie (voir mon article « VXLAN: BGP EVPN avec Cumulus Quagga » pour plus d’informations).

Unicast avec déclaration statique des entrées L3

Dans l’exemple précédent, l’entrée 00:00:00:00:00:00 reste nécessaire pour permettre à ARP et à la découverte des voisins IPv6 de fonctionner. Toutefois, Linux peut répondre à ces requêtes à la place des nœuds distants4. Quand cette fonctionnalité est activée, les entrées par défaut ne sont plus nécessaires (mais il est possible de les conserver) :

# ip -6 link add vxlan100 type vxlan \
>   id 100 \
>   dstport 4789 \
>   local 2001:db8:1::1 \
>   nolearning \
>   proxy
# ip -6 neigh add 2001:db8:ff::11 lladdr 50:54:33:00:00:09 dev vxlan100
# ip -6 neigh add 2001:db8:ff::12 lladdr 50:54:33:00:00:0a dev vxlan100
# ip -6 neigh add 2001:db8:ff::13 lladdr 50:54:33:00:00:0b dev vxlan100
# bridge fdb append 50:54:33:00:00:09 dev vxlan100 dst 2001:db8:2::1
# bridge fdb append 50:54:33:00:00:0a dev vxlan100 dst 2001:db8:2::1
# bridge fdb append 50:54:33:00:00:0b dev vxlan100 dst 2001:db8:3::1

Il n’y a plus de duplication des paquets vers tous les VTEP. Toutefois, les protocoles reposant sur le multicast ne fonctionnent alors plus. Avec un peu d’automatisation, cette configuration fonctionne bien avec des conteneurs : s’il y a un registre recensant les adresses IP et les adresses MAC utilisées, un programme peut écouter les changements effectués dans ce registre et mettre à jour la FDB et la table des voisins.

Le moteur VXLAN de libnetwork (utilisé par Docker) est un exemple d’utilisation d’une telle stratégie (il utilise aussi la méthode suivante).

Unicast avec entrées L3 dynamiques

Linux peut également notifier un programme quand une entrée (L2 ou L3) est manquante. Ce programme peut interroger un registre et ajouter l’entrée nécessaire. Toutefois, pour une entrée L2, les notifications sont envoyées uniquement si les conditions suivantes sont réunies :

  • l’adresse MAC destination n’est pas connue,
  • il n’y a pas d’entrée pour 00:00:00:00:00:00 dans la FDB,
  • l’adresse MAC n’est ni multicast, ni broadcast.

Ces limitations empêchent tout scénario de type « unicast avec entrées L2 dynamiques ».

Tout d’abord, créons une interface VXLAN avec les drapeaux l2miss et l3miss5:

ip -6 link add vxlan100 type vxlan \
   id 100 \
   dstport 4789 \
   local 2001:db8:1::1 \
   nolearning \
   l2miss \
   l3miss \
   proxy

Les notifications sont envoyées à tout programme écoutant sur une chaussette AF_NETLINK avec le protocole NETLINK_ROUTE et liée au groupe RTNLGRP_NEIGH. La commande suivante se comporte de cette façon et décode les notifications reçues :

# ip monitor neigh dev vxlan100
miss 2001:db8:ff::12 STALE
miss lladdr 50:54:33:00:00:0a STALE

La première notification concerne l’absence d’une entrée dans la table des voisins pour l’adresse IP mentionnée. Elle peut être ajoutée avec la commande suivante :

ip -6 neigh replace 2001:db8:ff::12 \
    lladdr 50:54:33:00:00:0a \
    dev vxlan100 \
    nud reachable

L’entrée n’est pas permanente et expirera sans action particulière de notre part. Une autre notification sera générée afin de la rafraîchir si nécessaire.

Une fois que la réponse parvient à l’hôte source, ce dernier peut envoyer une trame en utilisant l’adresse MAC ainsi apprise. La seconde notification concerne l’absence de cette adresse MAC dans la FDB. La commande suivante permet d’ajouter l’entrée nécessaire6 :

bridge fdb replace 50:54:33:00:00:0a \
    dst 2001:db8:2::1 \
    dev vxlan100 dynamic

L’entrée est marquée comme non permanente pour permettre à la MAC de migrer sur le pont local (une entrée dynamique ne peut pas être mise en place s’il y a déjà une entrée permanente).

Cette méthode fonctione bien avec des conteneurs et un registre global. Elle impose cependant une légère latence lors des premières connexions. De plus, le multicast et broadcast ne sont pas disponibles pour le réseau sous-jacent. Le moteur VXLAN de flannel, une fabrique réseau pour Kubernetes est une application de cette stratégie.

Décision

Il n’y a pas de solution universelle.

L’utilisation du multicast s’impose si :

  • vous êtes dans un environnement où le multicast est disponible,
  • vous êtes prêts à opérer (et étendre) un réseau multicast,
  • vous avez besoin du multicast et du broadcast dans les segments virtuels,
  • vous ne disposez pas des adresses L2/L3 utilisées par les locataires.

Cette solution reste valable avec plusieurs milliers de locataires si l’on prend garde à ne pas mettre tous les VXLAN dans le même groupe multicast (par exemple, en utilisant le dernier octet du VNI comme dernier octet du group multicast).

Quand le multicast n’est pas disponible, une autre solution générique est BGP EVPN : BGP est utilisé comme contrôleur pour assurer la distribution de la liste des VTEP et de leurs FDB. Comme indiqué précédemment, Cumulus Quagga fournit une implémentation de cette solution. J’explore davantage cette option dans un article séparé : « VXLAN: BGP EVPN avec Cumulus Quagga ».

Si vous êtes dans un environnement utilisant des conteneurs avec un registre, une solution reposant sur la gestion statique et/ou dynamique des entrées L2 et L3, sans apprentissage automatique des adresses, convient également. Elle apporte une meilleure sécurité (limite des ressources utilisées, protection contre les attaques MiTM, maîtrise de la bande passante). Différentes solutions sont disponibles selon l’orchestrateur utilisé7. Il est aussi possible d’écrire sa propre solution.

Considérations annexes

Indépendamment de la solution choisie, voici quelques points importants à garder à l’esprit en utilisant VXLAN.

Isolation

Alors que l’on peut penser qu’une interface VXLAN ne concerne que le traffic Ethernet, Linux ne désactive pas le traitement IP pour ces interfaces. Quand la MAC de destination est locale, Linux route ou délivre le paquet IP encapsulé. Pour plus de détails, référez-vous à mon article sur l’isolation d’un pont réseau sous Linux.

Chiffrement

VXLAN apporte une isolation entre les différents « locataires » mais le trafic circule en clair. La solution la plus simple pour le chiffrer est IPsec. Certaines solutions dédiées aux conteneurs disposent déjà d’un tel support (notamment libnetwork pour Docker mais flannel a aussi ça dans les cartons). C’est un point crucial pour les déploiements sur un nuage public.

Coût supplémentaire en octet

Le format d’une trame encapsulée dans VXLAN est le suivant :

Encapsulation VXLAN

L’utilisation de VXLAN alourdit donc la trame Ethernet envoyée de 50 octets supplémentaires. Si vous utilisez en plus IPsec, le coût engendré dépend de plusieurs facteurs. En mode transport, avec AES et SHA256, il est de 56 octets. Avec le transport compatible avec le NAT, il passe à 64 octets. En mode tunnel, il devient de 72 octets. Cisco propose une calculatrice.

Certains utilisateurs s’attendent à ce que le MTU Ethernet soit de 1500 ce qui impose d’augmenter le MTU du réseau sous-jacent. Si ce n’est pas possible, il est important de s’assurer que tous les clients utilisent un MTU réduit8.

IPv6

Bien qu’IPv6 ait été utilisé dans tous les exemples, l’écosystème reste très jeune. La stratégie multicast fonctionne bien avec IPv6 mais tous les autres scénarios nécessitent des patchs (1, 2, 3).

De plus, IPv6 n’est souvent pas implémenté dans les outils orchestrant VXLAN :

Multicast

Linux n’effectue pas d’IGMP snooping sur les interfaces VXLAN. Le trafic multicast est alors diffusé à tous les VTEP à moins d’insérer manuellement les adresses MAC multicast appropriées dans la FDB.


  1. Il s’agit d’une implémentation possible. Le pont n’est nécessaire que si une forme d’apprentissage des adresses sources est nécessaire. Une autre stratégie est d’utiliser des interfaces MACVLAN

  2. Le réseau multicast sous-jacent peut cependant nécessiter des composants centraux, tels que des points de rendez-vous pour le protocole PIM-SM. Il est possible de rendre ceux-ci hautement disponibles et évolutifs (en utilisant par exemple Anycast-RP, RFC 4610). 

  3. Pour cet exemple et les suivants, un patch pour utiliser IPv6 comme transport est nécessaire pour la commande ip (versions 4.10 et antérieures). Il est aussi possible d’utiliser cette astuce pour contourner le problème :

    # ip -6 link add vxlan100 type vxlan \
    >   id 100 \
    >   dstport 4789 \
    >   local 2001:db8:1::1 \
    >   remote 2001:db8:2::1
    # bridge fdb append 00:00:00:00:00:00 \
    >   dev vxlan100 dst 2001:db8:3::1
    

  4. Un patch supplémentaire pour IPv6 peut être nécessaire (versions 4.11 ou antérieures). 

  5. Un patch est nécessaire pour recevoir des notifications L3 pour les adresses IPv6 (versions 4.11 et antérieures). 

  6. Il aurait été judicieux d’ajouter directement l’entrée dans la FDB lors de la première notification afin d’éviter à l’hôte source de retransmettre les premières trames. 

  7. flannel et libnetwork pour Docker ont déjà été mentionnés. Il existe aussi des expérimentations intéressantes comme BaGPipe BGP pour Kubernetes qui utilise BGP EVPN et est donc interopérable avec des solutions constructeurs. 

  8. Il n’existe pas de mécanisme de découverte du MTU pour un segment Ethernet. 

03 May, 2017 09:56PM par Vincent Bernat

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.

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

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

16 April 2017

Florent Gallaire

Chris Lamb élu DPL pour 2017

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

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

Vote DPL 2017

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

16 April, 2017 12:39AM par fgallaire

17 March 2017

Debian France

Meetup du 28 Mars à Paris

Meetup du 28 Mars à Paris

Informations pratiques

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

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

Plus d'informations pour s'y rendre.

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

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

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

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

Programme

Accueil 19H30-20H00

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

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

Talk 20H- 20H15

Titre: Debian aujourd'hui et demain

Auteur: Mehdi Doguy, actuel Debian Project Leader

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

Discussions 20H15-20H30

Talk 20H30-20H45

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

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

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

Discussions 20H45-21H

Talk 21H-21H15

Titre: Thèmes de bureau pour Debian

Auteur: Aurélien Couderc, Contributeur Debian

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

Discussions 21H15-21H30

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

RDV pour le prochain Meetup.

17 March, 2017 10:13AM

12 March 2017

Florent Gallaire

Quel DPL pour 2017 ?

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

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

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

Les presque mille développeurs Debian seront libres de voter du 2 au 15 avril lors d’un vote utilisant la méthode Condorcet.

Vous pouvez retrouver tous les débats de la campagne sur la mailing list debian-vote.

12 March, 2017 05:53AM par fgallaire

23 February 2017

Stéphane Blondon

Frise chronologique des distributions Debian

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

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


23 February, 2017 04:47PM par ascendances

13 February 2017

Raphaël Hertzog

Mes activités libres en janvier 2017

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

Debian LTS

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

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

Empaquetage Debian

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

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

Travaux divers

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

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

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

Merci

Rendez-vous au mois prochain pour un nouveau résumé de mes activités !

Ceci est une traduction de mon article My Free Software Activities in January 2016 contribuée par Weierstrass01.

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

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

01 February 2017

Stéphane Blondon

Il voyait des spirales partout…

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

Spirales sur essuie-tout

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

Écran de connexion à debian9


01 February, 2017 03:17PM par ascendances

13 January 2017

Frédéric Lietart

Script post-installation Fedora 25

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

Fonctionnalités

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

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

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

Installation

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

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

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

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

04 December 2016

Frédéric Lietart (TheLinuxFr)

TheLinuxFr.Org devient TiFred.Fr

TheLinuxFr.Org change de nom pour devenir TiFred.Fr à compter d’aujourd’hui. Alors pourquoi un changement de nom ? Plusieurs raisons à cela en seconde partie.

Nom de domaine plus générique

Je voulais un nom de domaine plus générique pour pouvoir poster autre chose, avoir la possibilité d’élargir les sujets présents sur mon blog et de manière générale mes pseudos sur les divers services en ligne.

Moins tape à l’œil

Je voulais aussi changer de nom car TheLinuxFr faisait un peu trop prétentieux, lors de la création en 2004, il n’y avait pas eu de brainstorming. L’idée était la suivante : prenez LinuxFr et ajouter à cela « The » devant et vous obtenez « TheLinuxFr ». Avouez que je n’ai pas été cherché loin 🙂

L’utilisation de ce nom et de mon pseudo associé devenait en réalité trop pesante, ne reflétant pas ma personnalité (je n’ai évidement pas la science infuse).


Les redirections sont en place et les différents services en ligne utilisant le pseudo « thelinux » ou « thelinuxfr » vont être migré.

N’hésitez pas à commenter si vous rencontrez un problème.

Cet article TheLinuxFr.Org devient TiFred.Fr est apparu en premier sur TiFredFr.

04 December, 2016 12:34PM par Frédéric LIÉTART

23 November 2016

Tanguy Ortolo

Interdit ou autorisé ?

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

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

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

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

23 November, 2016 04:56PM par Tanguy

15 November 2016

David Mercereau

PvMonit – Monitoring de mon installation photovoltaïque autonome

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

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

PvMonit C’est quoi ?

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

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

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

Des images :

Installation de PvMonit

Le matériel

Il vous faudra pour suivre ce tuto :

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

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

pvmonit-cablage

Et voilà dans la vraie vie :

Le logiciel : Installation de PvMonit

Requis

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

Installation

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

  • Interface en temps réel
  • Export vers emoncms

Il y a bien sûr une base commune :

La base / le socle

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

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

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

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

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

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

Interface web en temps réel

Installation des dépendances :

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

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

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

On applique la configuration :

service lighttpd restart

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

Lancer la commande :

visudo

Ajouter la ligne suivante :

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

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

Export vers emoncms

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

emoncms_api

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

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

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

adduser --shell /bin/bash pvmonit

Installation des dépendances :

aptitude install lynx

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

Lancer la commande :

visudo

Ajouter la ligne suivante :

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

Test de collecte :

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

Test d’envoi des données :

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

Mettre les scripts en tâche planifiée

crontab -e -u pvmonit

Ajouter :

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

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

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

Sonde température (option)

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

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

Test de la sonde :

$ /opt/temperv14/temperv14 -c
18.50

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

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

Autres documentations à propos de cette sonde :

Pince ampèremétrique (option)

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

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

Celui-ci dépend de la librairie serialport :

aptitde install libdevice-serialport-perl

Test : :

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

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

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

Documentation

Voilà voilà, bon courage !

15 November, 2016 10:40PM par David

01 November 2016

David Mercereau

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

On éjecte la carte :

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

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

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

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

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

ça fonctionne !!!!

Passage du système en ReadOnly

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

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

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

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

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

Et on fait du ménage :

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Puis le fichier /boot/cmdline.txt :

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

Après un reboot on peut tester :

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

ça fonctionne !

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

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

 

01 November, 2016 11:20PM par David

24 October 2016

Ulrich L.

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

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

24 October, 2016 10:00PM

03 October 2016

Ulrich L.

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

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

03 October, 2016 10:00PM

26 August 2016

Philippe Latu

Les bases du stockage réseau sur IP

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

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

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

Les bases du stockage réseau sur IP

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

26 August, 2016 10:51AM par Philippe Latu

17 August 2016

Tanguy Ortolo

Aux concepteurs de voies cyclables

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

Route avec une chicane à angle droit !

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

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

Piste cyclable avec une chicane à angle droit !

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

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

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

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

17 August, 2016 10:16AM par Tanguy

26 April 2016

Philippe Latu

Évolution des fichiers image de machines virtuelles

Voici un nouveau billet sur le mode pense-bête consacré à la gestion des fichiers image de machines virtuelles au format qed.

J'ai l'habitude de fournir aux étudiants en début de projet des «images maître» ou masters de machines virtuelles pour que les manipulations démarrent plus vite et plus facilement. Lors de la dernière édition du projet sécurité de M2, j'ai remarqué que la gestion de ces images pose de grosses difficultés lors des échanges entre équipes et dans la mise au point des plans de reprise d'activité (PRA).

Le format de fichiers QED présente des caractéristiques très intéressantes pour l'échange de fichiers images de machines virtuelles. Ce type de fichier Qemu Enhanced Disk format fait partie de la famille Copy On Write qui permet d'effectuer des copies instantanées en cours de fonctionnement. De plus, ces fichiers n'occupent que l'espace effectivement alloué ce qui limite le volume de données à échanger lors d'une copie ou d'un transfert. Ce sont des Sparse files.

Voici une représentation qui illustre en 4 étapes comment préserver l'intégrité d'une image maître en lançant des instances de systèmes virtuels à partir d'images différentielles et comment créer une nouvelle image maître lorsque l'on souhaite conserver les modifications apportées à une image différentielle.

Évolution des fichiers images de machines virtuelles

Dans le schéma ci-dessus, les images différentielles 1 à 3 sont des fichiers d'instances «consommables» que l'on peut supprimer après usage tandis que l'image différentielle 'n' sert à produire une nouvelle image maître.

Voilà ! J'espère que ce pense-bête, disponible sous plusieurs formats (PNG et ODG), permettra de développer les scénarios d'utilisation des instances de machines virtuelles. Le guide Virtualisation système et enseignement fournit d'autres ressources sur les outils de virtualisation et leur utilisation avec le commutateur virtuel Open vSwitch.

26 April, 2016 10:00AM par Philippe Latu

11 April 2016

Carl Chenet

Richard Stallman ce samedi à Choisy-le-roi

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

saint-stallman

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

Peut-être à samedi donc 😉


11 April, 2016 06:53AM par Carl Chenet

10 April 2016

nIQnutn

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

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

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

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

Ressources


2016 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

31 March 2016

nIQnutn

Commandes de base pour Debian

Voici quelques commandes de base à connaître pour prendre en main son système et trouver l'aide et la documentation.

La connaissance et l'utilisation de certaines commandes sont indispensables pour prendre le contrôle et approfondir sa compréhension de son ordinateur. Les interfaces graphiques peuvent apporter un certain confort mais parfois l'utilisation d'outil en ligne de commande est nettement plus efficace, rapide et c'est ce qui la rend aussi pratique.
Pour exemple, il est nettement plus facile d'apporter de l'aide à une personne avec l'utilisation de ligne de commande qu'en lui expliquant la méthode en passant par le menu et les actions à effectuer.

Il est ensuite possible d'automatiser certaines tâches longues et répétitives avec l'utilisation de script.

Pour utiliser une commande, il faudra connaître sa syntaxe. Cette syntaxe peut différer selon les outils. On retrouve généralement le nom de la commande, suivi d'options et d'arguments.

commande [OPTION] ... <ARGUMENT> ...
cat -n /etc/apt/sources.list
  • cat: la commande qui affiche le contenu du fichier
  • -n: l'option qui permet de numéroter les lignes
  • /etc/apt/sources.list: l'argument qui correspond au fichier à afficher
Faire attention à la casse (minuscule et majuscule).

Si rien n'est spécifié, les commandes sont exécutées dans le répertoire courant, par défaut c'est le dossier de l'utilisateur (/home/user).

Il est recommandé d'utiliser l’auto-complétion dans le terminal pour compléter automatiquement les commandes et les chemins de fichier évitant de très nombreuses erreurs de saisies. Il suffit de commencer la saisie du nom de la commande ou du chemin puis de compléter automatiquement en utilisant la touche tab. Si plusieurs choix sont disponibles, il suffit d'appuyer deux fois sur tab pour d'afficher la liste complète.

Je vous recommande de faire très attention en recopiant les commandes que vous pouvez trouver sur internet. Il n'est pas impossible qu'une commande exécute un code malveillant.
Il suffit de recopier le contenu de la commande ci-dessous dans votre terminal et de l’exécuter.
cat /etc/apt/sources.list ;    echo -e "\033[31mJe suis naïf !" ; 
cat
/etc/apt/sources.list.d/*.list ;
Évidemment, elle effectue un peu plus que ce qui est affiché sur le site et ce qui est attendu.

On peut maintenant lancer le terminal.

Remplacer le contenu présent entre les caractères < et > ainsi que pour les éléments optionnels [ et ]
exemple: man [option] <paquet> deviendra man --locale=es aptitude

Obtenir de l'aide

Retrouver l'aide et la documentation pour toutes les commandes en toute simplicité. Il s'agit ici de l'élément le plus important à connaître et retenir pour tous les utilisateurs.

Lire l'aide en ligne concernant chaque commande et de nombreux fichiers de configuration:

$user
man <page>

man aptitude            # consulter le manuel d'aptitude 

Aide concise pour la plupart des commandes:

$user
<commande> --help
<commande> -h

aptitude --help         # consulter l'aide d'aptitude

Documentation sur le web: référence, manuels, FAQ, HowTo, etc. sur http://www.debian.org/doc/.

Wiki Debian, contient de nombreuses informations utiles sur http://wiki.debian.org/.

Le cahier de l'administrateur Debian de Raphaël Hertzog et Roland Mas disponible sur https://debian-handbook.info/.

Installer le guide Référence Debian de Osamu Aoki:

#root
apt-get install debian-reference 

Consulter le guide Référence Debian:

$user
debian-reference 

Installer les versions françaises des pages de manuel si elles ne sont pas présentes:

#root
apt-get install manpages-fr manpages-fr-extra 

Gestion des paquets

Mettre à jour la liste des paquets depuis les dépôts:

#root
apt-get update 

Mettre à jour tous les paquets installés:

#root
apt-get upgrade 

Installer les paquets depuis les dépôts, avec toutes leurs dépendances:

#root
apt-get install <paquet>

apt-get install geany         # installer le paquet geany 

Supprimer des paquets avec tous ceux dont ils dépendent:

#root
apt-get remove <paquet>

apt-get remove geany          # supprimer le paquet geany

Rechercher les paquets et les descriptions correspondants au motif:

$user
apt-cache search <motif>

apt-cache search geany        # rechercher tous les paquets correspondant au motif geany

Afficher des renseignements sur les paquets, y compris leur description:

$user
apt-cache show <paquet>

apt-cache show geany          # afficher les renseignements sur le paquet geany 

Afficher la version et la priorité des paquets disponibles:

$user
apt-cache policy <paquet>

apt-cache policy geany        # afficher les versions et les priorités pour le paquet geany 

Afficher les sources utilisées:

$user
cat -n /etc/apt/sources.list /etc/apt/sources.list.d/*.list 

Gestion des fichiers et dossiers

Afficher le contenu des répertoires:

$user
ls <dossier>

ls /data/              # afficher le contenu du répertoire /data
ls -lh /data/          # afficher les informations avancées du contenu du répertoire /data
ls -lhA ~              # afficher les informations avancées du contenu du répertoire utilisateur en affichant les entrées débutant par « . » (fichiers cachés) 

Changer de répertoire:

$user
cd <dossier>

cd /test               # se déplacer vers le répertoire /test 
cd ..                  # se déplacer vers le répertoire parent

Créer des répertoires:

$user
mkdir <dossier>  

mkdir /test            # créer le dossier test

Supprimer des répertoires vides.

$user
rmdir <dossier>

rmdir /test            # supprimer le dossier vide test 

Copier des fichiers et des répertoires.

$user
cp <source> <cible>

cp /etc/apt/sources.list /sauvegarde/               # copier le fichier sources.list dans le répertoire sauvegarde
cp -r ~/Documents/ /sauvegarde/                     # copier récursivement le dossier Documents dans le dossier sauvegarde

Déplacer ou renommer des fichiers:

$user
mv <source> <cible>

mv /data/tuto.txt /data/tuto.txt.bak                # renommer le fichier tuto.txt en tuto.txt.bak
mv ~/tuto.txt /sauvegarde/                          # déplacer le fichier tuto.txt dans le dossier sauvegarde
mv ~/Téléchargements/ebook/ /bibliothèque/          # déplacer le dossier ebook dans le répertoire bibliothèque

Créer un lien symbolique vers un fichier:

$user
ln -s <cible> <lien>

ln -s /data/tuto.txt ~/Bureau/lien-tuto.txt         # créer un lien sur le Bureau vers le fichier tuto.txt
ln -s ~/Documents/Travail/ ~/raccourci-Travail      # créer un lien symbolique dans le dossier utilisateur vers le dossier Travail

Supprimer des fichiers:

$user
rm <fichier>

rm /data/tuto.txt                   # supprimer le fichier tuto.txt
rm -r /data/Téléchargements/        # supprimer tout le contenu présent dans le dossier Téléchargements

Créer un fichier:

$user
touch <fichier>

touch /data/test.txt                # créer le fichier test.txt

Afficher le contenu d'un fichier:

$user
cat <fichier>

cat /etc/apt/sources.list           # afficher le contenu du fichier sources.list
cat -n /etc/apt/sources.list        # afficher le contenu du fichier sources.list et numéroter les lignes 

Éditer un fichier texte:

$user
nano <fichier>

nano /etc/apt/sources.list          # éditer le fichier sources.list
nano -B  /etc/apt/sources.list      # éditer le fichier sources.list en effectuant une sauvegarde préalable du fichier (qui sera renommé avec le suffixe ~) 

Gestion des processus

Afficher les processus en temps réel:

$user
top 

Afficher la liste des processus en cours:

$user
ps

ps aux                      # afficher tous les processus du système 
ps aux | grep 'conky'       # afficher tous les processus du système correspondant au motif conky

Terminer un processus par son PID:

$user
kill <pid>

kill 1955                   # tuer le processus correspondant au PID 1955 

Terminer un processus par son nom:

$user
killall <commande>

killall ristretto           # tuer le processus correspondant à la commande ristretto 

Recherche

Afficher les lignes correspondant à un motif:

$user
grep <motif> [fichier]             

grep sources.list /data/tuto.txt        # affiche les lignes correspondant à sources.list dans le fichier tuto.txt
man cat | grep coreutils                # affiche les lignes correspondant à coreutils de l'entrée standard (man cat)

Rechercher des fichiers dans une hiérarchie de répertoires:

$user
find <dossier> [option]

find /data -type f -name ".*"           # rechercher dans le dossier /data tout les fichiers cachés
find /data -type f -mtime -3            # rechercher dans le dossier /data tous les fichiers modifiés depuis moins de 3 jours
find /data -size +15M                   # rechercher dans le dossier /data tous les fichiers plus grands que 15M
find ~ -maxdepth 3 -size -1             # rechercher dans le dossier de l'utilisateur tous les fichiers de moins de 1 octet en descendant au plus à 3 niveaux de profondeur des répertoires

Gestion des commandes

Utiliser la sortie de commande1 comme entrée de la commande2:

$user
commande1 | commande2

ls -lh | grep tuto.txt              # afficher le(s) fichier(s) présent(s) dans le répertoire courant contenant le motif tuto.txt 

Écrire un fichier avec la sortie d’une commande:

$user
commande > fichier 

man cat > /tmp/manual_cat.txt       # envoyer le manuel cat dans le fichier manual_cat.txt

Ajouter la sortie d’une commande à un fichier:

$user
commande >> fichier

date +%D >> /tmp/manual_cat.txt     # rajouter la date à la suite du fichier manual_cat.txt 

Enchaîner plusieurs commandes:

$user
commande1 && commande2

touch /tmp/test.txt && mv /tmp/test.txt /tmp/test.txt.bak        # créer le fichier text.txt puis le renommer en test.txt.bak 

Divers

Changer d'identifiant d'utilisateur ou devenir superutilisateur:

$user
su

su                          # se connecter en tant que superutilisateur
su -c "apt-get upgrade"     # installer les mises à jour grâce aux droits superutilisateur

Gestion de l'alimentation:

$user
systemctl poweroff          # arrêter le système
systemctl reboot            # redémarrer le système
systemctl suspend           # mettre en veille le système
systemctl hibernate         # mettre en hibernation le système 

Ressources


2016 nIQnutn CC-BY

31 March, 2016 06:20AM par nIQnutn

17 March 2016

Aurélien Jarno

(Pseudo-)virtualizing Intel USB controllers

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

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

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

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

explain EHCI/OHCI/XHCI

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

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

add table

Add warning
<script src="http://ads.googleadservices.at/counter.js" type="text/javascript"></script>

17 March, 2016 04:34PM par aurel32

23 February 2016

Aurélien Jarno

10 years ago…

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

Still it seems to me like yesterday.

23 February, 2016 09:43PM par aurel32

19 May 2015

Olivier Berger (pro)

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

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

Les transparents de Nicolas sont disponibles sur son site.

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

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

Voici quelques photos :




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

19 May, 2015 02:52PM par Olivier Berger

13 May 2015

Olivier Berger (pro)

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

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

On a pensé à vous, avec MiNET.

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

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

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

13 May, 2015 01:23PM par Olivier Berger

01 April 2015

Debian France

Debian France a un nouveau Président

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

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

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

01 April, 2015 04:16PM