November 17, 2019

hackergotchi for Debian France

Debian France

Paris Open Source Summit 2019

Debian France tiendra un stand à l'occasion du Paris Open Source Summit, les 10 et 11 Décembre 2019 aux Docks de Paris - 87 Avenue des Magasins Généraux, 93300 Aubervilliers.

Des développeurs Debian ainsi que des membres de l'association Debian France seront là pour répondre à vos questions. Des goodies Debian seront également disponibles !

Nous serons présents au village associatif, emplacement A32 parmi les nombreux autres stands.

17 November, 2019 10:09PM

September 16, 2019

Debian Buster Party à Lille - 2019

Lille - Fêtons l'arrivée de Debian Buster !

Une fête consacrée à Debian Buster et plus largement à Debian se déroulera à Lille, le samedi 5 octobre 2019 de 10h00 à 18h00.

Programme

  • 10h : début de l'atelier
  • 12h : auberge espagnole, options véganes
  • l'après-midi : la foire aux installations continue !
  • 16h : discussions au sujet de Debian et des logiciesl libres
  • 17h : goûter et gateaux pour fêter Buster !

Lieu

Liens

16 September, 2019 07:33PM

Capitole du libre 2019

Debian France tiendra un stand à l'occasion du Capitole du libre, les 16 et 17 novembre 2019 à l'INP-ENSEEIHT de Toulouse.

Des développeurs Debian ainsi que des membres de l'association Debian France seront là pour répondre à vos questions. Des goodies Debian seront également disponibles !

Nous serons présents au village associatif parmi les nombreux autres stands.

16 September, 2019 09:57AM

August 02, 2019

hackergotchi for Vincent Bernat

Vincent Bernat

Sécuriser BGP sur le serveur avec la validation de l'origine

Une conception moderne pour un réseau de datacentre est le BGP sur le serveur : chaque serveur embarque un démon BGP pour annoncer les IP qu’il gère et reçoit les routes pour contacter ses collègues. Comparé à une conception L2, il est très évolutif, résilient, multi-constructeur et sûr à utiliser1. Jetez un coup d’œil sur l’article « Routage L3 jusqu’à l’hyperviseur avec BGP » pour un exemple de mise en œuvre.

Réseau de type Clos avec deux routeurs de collecte, six routeurs de distribution et neuf serveurs physiques. Tous les liens ont une session BGP établie entre leurs extrémités. Certains serveurs ont une bulle indiquant le préfixe IP qu'ils désirent s'approprier.
BGP sur le serveur dans un réseau de type Clos. Une session BGP est établie sur chaque lien et chaque serveur annonce ses propres préfixes IP.

Bien que le routage sur le serveur élimine les problèmes de sécurité liés aux réseaux Ethernet, un hôte peut annoncer n’importe quel préfixe IP. Dans l’image ci-dessus, deux d’entre eux annoncent 2001:db8:cc::/64. Il peut s’agir d’une utilisation légitime (pour un service distribué) ou d’un détournement de préfixe. BGP propose plusieurs solutions pour améliorer cet aspect et l’une d’entre elles est d’exploiter les fonctionnalités autour de la RPKI.

Courte introduction à la RPKI

Sur Internet, BGP repose essentiellement sur la confiance. Cela contribue à divers incidents dus à des erreurs humaines, comme celui qui a affecté Cloudflare il y a quelques mois, ou à des attaques malveillantes, comme lors du détournement du DNS d’Amazon pour voler des portefeuilles de cryptomonnaies. La RFC 7454 explique les bonnes pratiques pour éviter de tels problèmes.

Les adresses IP sont attribuées par cinq registres régionaux (RIR). Chacun d’eux tient à jour une base de données des ressources Internet, notamment les adresses IP et les numéros d’AS associés. Ces bases de données ne sont pas totalement fiables, mais elles sont largement utilisées pour construire des listes de contrôle d’accès afin de vérifier les annonces d’un partenaire. Voici un exemple généré à l’aide de bgpq3 pour une liaison avec Apple2 :

$ bgpq3 -l v6-IMPORT-APPLE -6 -R 48 -m 48 -A -J -E AS-APPLE
policy-options {
 policy-statement v6-IMPORT-APPLE {
replace:
  from {
    route-filter 2403:300::/32 upto /48;
    route-filter 2620:0:1b00::/47 prefix-length-range /48-/48;
    route-filter 2620:0:1b02::/48 exact;
    route-filter 2620:0:1b04::/47 prefix-length-range /48-/48;
    route-filter 2620:149::/32 upto /48;
    route-filter 2a01:b740::/32 upto /48;
    route-filter 2a01:b747::/32 upto /48;
  }
 }
}

La RPKI (RFC 6480) ajoute une couche de cryptographie à clé publique pour signer l’autorisation d’un AS à annoncer un préfixe IP. Cet enregistrement est une « autorisation d’origine de route » (ROA). Vous pouvez parcourir les bases de données de ces « ROA » par l’intermédiaire de l’instance « RPKI Validator » du RIPE :

Capture d'écran d'une instance de RPKI Validator montrant la validité de 85.190.88.0/21 pour l'AS 64476
RPKI validator montre une « ROA » pour 85.190.88.0/21

Les démons BGP n’ont pas besoin de télécharger ces bases de données ou de vérifier les signatures pour valider des préfixes reçus: ils délèguent ces tâches à un validateur RPKI local implémentant le protocole « RPKI-to-Router Protocol » (RTR, RFC 6810).

Pour plus de détails sur la RPKI, jetez un œil sur l’article « RPKI and BGP: our path to securing Internet Routing » ou encore sur les articles de Stéphane Bortzmeyer sur les RFC 6480, 6481 et 6810.

Utiliser la validation de l’origine dans un réseau interne

Bien qu’il soit possible de configurer notre propre RPKI pour une utilisation en réseau interne, nous pouvons prendre un raccourci et utiliser un validateur, comme GoRTR, qui implémente RTR en acceptant une autre source de vérité. À titre d’exemple, utilisons la topologie suivante :

Réseau de type Clos avec deux routeurs de collecte, six routeurs de distribution et neuf serveurs physiques. Tous les liens ont une session BGP établie entre leurs extrémités. Trois des serveurs physiques sont en fait des validateurs et des sessions RTR sont établies entre ceux-ci les routeurs d'accès.
BGP sur le serveur avec validation des préfixes via RTR. Chaque serveur a son propre numéro d'AS. Les routeurs d'accès établissent des sessions RTR avec les validateurs.

Un applicatif maintient une correspondance entre les numéros d’AS privés et les préfixes autorisés3 :

Numéro d’AS Préfixes autorisés
AS 65005 2001:db8:aa::/64
AS 65006 2001:db8:bb::/64,
2001:db8:11::/64
AS 65007 2001:db8:cc::/64
AS 65008 2001:db8:dd::/64
AS 65009 2001:db8:ee::/64,
2001:db8:11::/64
AS 65010 2001:db8:ff::/64

A partir de cette table, nous construisons un fichier JSON pour GoRTR, en supposant que chaque serveur peut annoncer des préfixes plus longs (comme 2001:db8:aa::­42:d9ff:­fefc:287a/128 pour l’AS 65005) :

{
  "roas": [
    {
      "prefix": "2001:db8:aa::/64",
      "maxLength": 128,
      "asn": "AS65005"
    }, {
      "…": "…"
    }, {
      "prefix": "2001:db8:ff::/64",
      "maxLength": 128,
      "asn": "AS65010"
    }, {
      "prefix": "2001:db8:11::/64",
      "maxLength": 128,
      "asn": "AS65006"
    }, {
      "prefix": "2001:db8:11::/64",
      "maxLength": 128,
      "asn": "AS65009"
    }
  ]
}

Le fichier est déployé sur tous les validateurs et servi par un serveur web. GoRTR est configuré pour le récupérer et le mettre à jour toutes les 10 minutes :

$ gortr -refresh=600 \
        -verify=false -checktime=false \
        -cache=http://127.0.0.1/rpki.json
INFO[0000] New update (7 uniques, 8 total prefixes). 0 bytes. Updating sha256 hash  -> 68a1d3b52db8d654bd8263788319f08e3f5384ae54064a7034e9dbaee236ce96
INFO[0000] Updated added, new serial 1

L’intervalle entre deux mises à jour pourrait être réduit mais GoRTR peut aussi être notifié d’un changement en utilisant le signal SIGHUP. Les clients sont immédiatement avisés du changement.

L’étape suivante consiste à configurer les routeurs d’accès pour valider les préfixes reçus en utilisant les validateurs. La plupart des constructeurs sont compatibles avec RTR :

Platform Sur TCP? Sur SSH?
Juniper JunOS ✔️
Cisco IOS XR ✔️ ✔️
Cisco IOS XE ✔️
Cisco IOS ✔️
Arista EOS
BIRD ✔️ ✔️
FRR ✔️ ✔️
GoBGP ✔️

Configuration pour JunOS

JunOS n’est compatible qu’avec les connextions TCP en clair. La première étape consiste à configurer les serveurs de validation :

routing-options {
    validation {
        group RPKI {
            session validator1 {
                hold-time 60;         # la session est morte après 1 minute
                record-lifetime 3600; # le cache est gardé pendant 1 heure
                refresh-time 30;      # le cache est mis à jour toutes les 30 secondes
                port 8282;
            }
            session validator2 { /* OMITTED */ }
            session validator3 { /* OMITTED */ }
        }
    }
}

Par défaut, au maximum deux sessions sont établies au hasard en même temps. C’est un bon moyen de les équilibrer entre les validateurs tout en conservant une bonne disponibilité. La deuxième étape consiste à définir la politique de validation des routes :

policy-options {
    policy-statement ACCEPT-VALID {
        term valid {
            from {
                protocol bgp;
                validation-database valid;
            }
            then {
                validation-state valid;
                accept;
            }
        }
        term invalid {
            from {
                protocol bgp;
                validation-database invalid;
            }
            then {
                validation-state invalid;
                reject;
            }
        }
    }
    policy-statement REJECT-ALL {
        then reject;
    }
}

La politique ACCEPT-VALID transforme l’état de validation d’un préfixe de unknown à valid si la base de données ROA indique qu’il est valide. Il accepte également la route. Si le préfixe n’est pas valide, il est marqué comme tel et rejeté. Nous avons également préparé une politique REJECT-ALL pour refuser tout le reste, notamment les préfixes inconnus.

Un ROA ne certifie que l’origine d’un préfixe. Un acteur malveillant peut donc ajouter le numéro d’AS attendu en fin du chemin d’AS pour contourner la validation. Par exemple, l’AS 65007 pourrait annoncer 2001:db8:dd::/64, un préfixe attribué à l’AS 65006, en indiquant le chemin 65007 65006. Pour éviter cela, nous définissons une politique supplémentaire pour rejeter les chemins d’AS ayant plus d’un ASN4 :

policy-options {
    as-path EXACTLY-ONE-ASN "^.$";
    policy-statement ONLY-DIRECTLY-CONNECTED {
        term exactly-one-asn {
            from {
                protocol bgp;
                as-path EXACTLY-ONE-ASN;
            }
            then next policy;
        }
        then reject;
    }
}

La dernière étape est de configurer les sessions BGP :

protocols {
    bgp {
        group HOSTS {
            local-as 65100;
            type external;
            # export [ … ];
            import [ ONLY-DIRECTLY-CONNECTED ACCEPT-VALID REJECT-ALL ];
            enforce-first-as;
            neighbor 2001:db8:42::a10 {
                peer-as 65005;
            }
            neighbor 2001:db8:42::a12 {
                peer-as 65006;
            }
            neighbor 2001:db8:42::a14 {
                peer-as 65007;
            }
        }
    }
}

La politique pour l’import rejette tout chemin d’AS plus long qu’un AS, accepte les préfixes validés et rejette tout le reste. La directive enforce-first-as est très importante : elle garantit que le premier (et, ici, le seul) AS dans le chemin correspond à l’AS du serveur. Sans cela, un hôte malveillant pourrait injecter un préfixe en utilisant un AS différent du sien, ce qui irait à l’encontre de notre objectif5.

Vérifions l’état des sessions RTR et la base de données :

> show validation session
Session                                  State   Flaps     Uptime #IPv4/IPv6 records
2001:db8:4242::10                        Up          0   00:16:09 0/9
2001:db8:4242::11                        Up          0   00:16:07 0/9
2001:db8:4242::12                        Connect     0            0/0

> show validation database
RV database for instance master

Prefix                 Origin-AS Session                                 State   Mismatch
2001:db8:11::/64-128       65006 2001:db8:4242::10                       valid
2001:db8:11::/64-128       65006 2001:db8:4242::11                       valid
2001:db8:11::/64-128       65009 2001:db8:4242::10                       valid
2001:db8:11::/64-128       65009 2001:db8:4242::11                       valid
2001:db8:aa::/64-128       65005 2001:db8:4242::10                       valid
2001:db8:aa::/64-128       65005 2001:db8:4242::11                       valid
2001:db8:bb::/64-128       65006 2001:db8:4242::10                       valid
2001:db8:bb::/64-128       65006 2001:db8:4242::11                       valid
2001:db8:cc::/64-128       65007 2001:db8:4242::10                       valid
2001:db8:cc::/64-128       65007 2001:db8:4242::11                       valid
2001:db8:dd::/64-128       65008 2001:db8:4242::10                       valid
2001:db8:dd::/64-128       65008 2001:db8:4242::11                       valid
2001:db8:ee::/64-128       65009 2001:db8:4242::10                       valid
2001:db8:ee::/64-128       65009 2001:db8:4242::11                       valid
2001:db8:ff::/64-128       65010 2001:db8:4242::10                       valid
2001:db8:ff::/64-128       65010 2001:db8:4242::11                       valid

  IPv4 records: 0
  IPv6 records: 18

Voici un exemple de route acceptée :

> show route protocol bgp table inet6 extensive all
inet6.0: 11 destinations, 11 routes (8 active, 0 holddown, 3 hidden)
2001:db8:bb::42/128 (1 entry, 0 announced)
        *BGP    Preference: 170/-101
                Next hop type: Router, Next hop index: 0
                Address: 0xd050470
                Next-hop reference count: 4
                Source: 2001:db8:42::a12
                Next hop: 2001:db8:42::a12 via em1.0, selected
                Session Id: 0x0
                State: <Active NotInstall Ext>
                Local AS: 65006 Peer AS: 65000
                Age: 12:11
                Validation State: valid
                Task: BGP_65000.2001:db8:42::a12+179
                AS path: 65006 I
                Accepted
                Localpref: 100
                Router ID: 1.1.1.1

Une route refusée serait similaire avec comme état de validation invalid.

Configuration de BIRD

BIRD est compatible à la fois avec les connexions TCP en clair et SSH. Configurons le pour utiliser SSH. Nous devons générer des paires de clefs pour le routeur ainsi que pour les validateurs (ils peuvent se partager la même paire de clefs). Nous devons aussi créer un fichier known_hosts pour BIRD :

(validatorX)$ ssh-keygen -qN "" -t rsa -f /etc/gortr/ssh_key
(validatorX)$ echo -n "validatorX:8283 " ; \
              cat /etc/bird/ssh_key_rtr.pub
validatorX:8283 ssh-rsa AAAAB3[…]Rk5TW0=
(leaf1)$ ssh-keygen -qN "" -t rsa -f /etc/bird/ssh_key
(leaf1)$ echo 'validator1:8283 ssh-rsa AAAAB3[…]Rk5TW0=' >> /etc/bird/known_hosts
(leaf1)$ echo 'validator2:8283 ssh-rsa AAAAB3[…]Rk5TW0=' >> /etc/bird/known_hosts
(leaf1)$ cat /etc/bird/ssh_key.pub
ssh-rsa AAAAB3[…]byQ7s=
(validatorX)$ echo 'ssh-rsa AAAAB3[…]byQ7s=' >> /etc/gortr/authorized_keys

GoRTR a besoin d’arguments supplémentaires pour autoriser les connexions via SSH :

$ gortr -refresh=600 -verify=false -checktime=false \
      -cache=http://127.0.0.1/rpki.json \
      -ssh.bind=:8283 \
      -ssh.key=/etc/gortr/ssh_key \
      -ssh.method.key=true \
      -ssh.auth.user=rpki \
      -ssh.auth.key.file=/etc/gortr/authorized_keys
INFO[0000] Enabling ssh with the following authentications: password=false, key=true
INFO[0000] New update (7 uniques, 8 total prefixes). 0 bytes. Updating sha256 hash  -> 68a1d3b52db8d654bd8263788319f08e3f5384ae54064a7034e9dbaee236ce96
INFO[0000] Updated added, new serial 1

Ensuite, configurons BIRD pour utiliser ces serveurs de validation :

roa6 table ROA6;
template rpki VALIDATOR {
   roa6 { table ROA6; };
   transport ssh {
     user "rpki";
     remote public key "/etc/bird/known_hosts";
     bird private key "/etc/bird/ssh_key";
   };
   refresh keep 30;
   retry keep 30;
   expire keep 3600;
}
protocol rpki VALIDATOR1 from VALIDATOR {
   remote validator1 port 8283;
}
protocol rpki VALIDATOR2 from VALIDATOR {
   remote validator2 port 8283;
}

Contrairement à JunOS, BIRD ne dispose pas d’une fonction permettant d’utiliser uniquement un sous-ensemble de validateurs. Par conséquent, nous ne configurons que deux validateurs. Par mesure de sécurité, en cas d’indisponibilité de la connexion, BIRD conservera les ROA pendant une heure.

Nous pouvons vérifier l’état des sessions RTR et le contenu de la base de données :

> show protocols all VALIDATOR1
Name       Proto      Table      State  Since         Info
VALIDATOR1 RPKI       ---        up     17:28:56.321  Established
  Cache server:     rpki@validator1:8283
  Status:           Established
  Transport:        SSHv2
  Protocol version: 1
  Session ID:       0
  Serial number:    1
  Last update:      before 25.212 s
  Refresh timer   : 4.787/30
  Retry timer     : ---
  Expire timer    : 3574.787/3600
  No roa4 channel
  Channel roa6
    State:          UP
    Table:          ROA6
    Preference:     100
    Input filter:   ACCEPT
    Output filter:  REJECT
    Routes:         9 imported, 0 exported, 9 preferred
    Route change stats:     received   rejected   filtered    ignored   accepted
      Import updates:              9          0          0          0          9
      Import withdraws:            0          0        ---          0          0
      Export updates:              0          0          0        ---          0
      Export withdraws:            0        ---        ---        ---          0

> show route table ROA6
Table ROA6:
    2001:db8:11::/64-128 AS65006  [VALIDATOR1 17:28:56.333] * (100)
                                  [VALIDATOR2 17:28:56.414] (100)
    2001:db8:11::/64-128 AS65009  [VALIDATOR1 17:28:56.333] * (100)
                                  [VALIDATOR2 17:28:56.414] (100)
    2001:db8:aa::/64-128 AS65005  [VALIDATOR1 17:28:56.333] * (100)
                                  [VALIDATOR2 17:28:56.414] (100)
    2001:db8:bb::/64-128 AS65006  [VALIDATOR1 17:28:56.333] * (100)
                                  [VALIDATOR2 17:28:56.414] (100)
    2001:db8:cc::/64-128 AS65007  [VALIDATOR1 17:28:56.333] * (100)
                                  [VALIDATOR2 17:28:56.414] (100)
    2001:db8:dd::/64-128 AS65008  [VALIDATOR1 17:28:56.333] * (100)
                                  [VALIDATOR2 17:28:56.414] (100)
    2001:db8:ee::/64-128 AS65009  [VALIDATOR1 17:28:56.333] * (100)
                                  [VALIDATOR2 17:28:56.414] (100)
    2001:db8:ff::/64-128 AS65010  [VALIDATOR1 17:28:56.333] * (100)
                                  [VALIDATOR2 17:28:56.414] (100)

Comme dans le cas de JunOS, un acteur malveillant pourrait essayer de contourner la validation en construisant un chemin où le dernier AS est l’AS légitime. BIRD est suffisamment flexible pour nous permettre d’utiliser n’importe quel AS pour vérifier le préfixe IP. Au lieu de vérifier l’AS d’origine, nous lui demandons de vérifier l’AS du serveur avec cette fonction, sans regarder le chemin :

function validated(int peeras) {
   if (roa_check(ROA6, net, peeras) != ROA_VALID) then {
      print "Ignore invalid ROA ", net, " for ASN ", peeras;
      reject;
   }
   accept;
}

L’instance BGP est alors configurée en utilisant cette fonction comme politique d’import :

protocol bgp PEER1 {
   local as 65100;
   neighbor 2001:db8:42::a10 as 65005;
   connect delay time 30;
   ipv6 {
      import keep filtered;
      import where validated(65005);
      # export …;
   };
}

Il est possible de voir les routes rejetées avec show route filtered. Toutefois BIRD ne stocke dans les routes aucune information à propos de la validation. Il est aussi possible de consulter les journaux :

2019-07-31 17:29:08.491 <INFO> Ignore invalid ROA 2001:db8:bb::40:/126 for ASN 65005

Actuellement, BIRD ne réévalue pas les préfixes lorsque les ROA sont mises à jour. Des travaux sont en cours pour y remédier. Si cette fonctionnalité est importante pour vous, jetez un œil sur FRR : il supporte également le protocole RTR et déclenche une reconfiguration des sessions BGP lorsque les ROA sont mis à jour.

Mise à jour (11.2019)

Cette limitation de BIRD a un autre inconvénient : si les ROA ne sont pas chargées lorsque la connexion BGP est établie, certaines routes seront rejetées car inconnues. C’est pour cette raison qu’une directive connect delay time est ajoutée à la configuration proposée.


  1. Notamment, le flux de données et le plan de contrôle sont séparés. Un nœud peut se retirer du réseau en avertissant ses pairs sans provoquer la perte d’un seul paquet. ↩︎

  2. Les gens utilisent souvent les ensembles d’AS, comme AS-APPLE dans cet exemple, car ils sont pratiques si vous avez plusieurs numéros d’AS ou des clients. Cependant, rien n’empêche actuellement un acteur malhonnête d’ajouter des numéros d’AS arbitraires à son ensemble d’AS↩︎

  3. Nous utilisons des numéros d’AS sur 16 bits pour la lisibilité. Comme nous avons besoin d’attribuer un numéro AS différent pour chaque serveur, dans un déploiement réel, nous utiliserions des numéros d’AS sur 32 bits. ↩︎

  4. Cette restriction empêche également d’ajouter son propre numéro d’ASN pour diminuer la priorité d’un chemin. Une alternative moderne est l’utilisation de la communauté d’arrêt planifiée, GRACEFUL_SHUTDOWN↩︎

  5. Les routeurs Cisco et FRR vérifient le premier AS par défaut. C’est une valeur paramétrable pour permettre l’utilisation de serveurs de routes : ils distribuent des préfixes pour le compte d’autres routeurs. ↩︎

02 August, 2019 09:16AM by Vincent Bernat

July 21, 2019

Makefile pour un projet Go (2019)

Très tôt, j’ai pris en grippe le principe du GOPATH mis en avant par Go : je ne veux en aucun cas mélanger mon propre code avec celui des dépendances. Je ne suis pas seul dans cette aversion et moults outils ou des Makefile ont été créés pour éviter d’organiser son code autour du GOPATH.

Heureusement, depuis Go 1.11, il est possible d’utiliser les modules pour gérer les dépendances sans obligation d’utiliser le GOPATH. Tout d’abord, votre projet doit être converti en un module1 :

$ go mod init hellogopher
go: creating new go.mod: module hellogopher
$ cat go.mod
module hellogopher

Ensuite, vous pouvez invoquer les commandes habituelles, telles que go build ou go test. La commande go va résoudre les imports en utilisant les versions spécifiées le fichier go.mod. Lorsqu’il rencontre un import pour un paquet non présent dans go.mod, il télécharge automatiquement la dernière version du module correspondant et l’ajoute dans le fichier.

$ go test ./...
go: finding github.com/spf13/cobra v0.0.5
go: downloading github.com/spf13/cobra v0.0.5
?       hellogopher     [no test files]
?       hellogopher/cmd [no test files]
ok      hellogopher/hello       0.001s
$ cat go.mod
module hellogopher

require github.com/spf13/cobra v0.0.5

Si vous voulez une version spécifique, vous pouvez soit éditer go.mod ou invoquer go get :

$ go get github.com/spf13/cobra@v0.0.4
go: finding github.com/spf13/cobra v0.0.4
go: downloading github.com/spf13/cobra v0.0.4
$ cat go.mod
module hellogopher

require github.com/spf13/cobra v0.0.4

Ajoutez go.mod à votre système de gestion des versions. Vous pouvez également ajouter go.sum, ce qui procure une sécurité contre une dépendance qui mute sa version. Si vous voulez inclure les dépendances (vendoring), vous pouvez lancer go mod vendor et ajouter le répertoire vendor/ à votre système de gestion des versions.

Grâce aux modules, je pense que la gestion des dépendances en Go est maintenant au niveau des autres langages, notamment Ruby. Bien qu’il soit possible d’effectuer la plupart des opérations (construction et tests) en utilisant uniquement la commande go, un Makefile est toujours utile pour organiser les tâches les plus courantes, un peu comme le setup.py de Python ou le Rakefile de Ruby. Je vais décrire le mien.

Utilisation d’outils tierces

La plupart des projets vont nécessiter quelques outils pour la construction ou les tests. Pour éviter à l’utilisateur d’avoir à les installer, je propose de les compiler à la volée. Par exemple, voici comment l’analyse statique du code est effectuée avec Golint :

BIN = $(CURDIR)/bin
$(BIN):
    @mkdir -p $@
$(BIN)/%: | $(BIN)
    @tmp=$$(mktemp -d); \
       env GO111MODULE=off GOPATH=$$tmp GOBIN=$(BIN) go get $(PACKAGE) \
        || ret=$$?; \
       rm -rf $$tmp ; exit $$ret

$(BIN)/golint: PACKAGE=golang.org/x/lint/golint

GOLINT = $(BIN)/golint
lint: | $(GOLINT)
    $(GOLINT) -set_exit_status ./...

Le premier bloc définit comment l’outil tiers est fabriqué : go get est invoqué avec le nom du paquet correspondant à l’outil à installer. Nous ne voulons pas polluer notre gestion de dépendances pour cet outil et nous travaillons donc dans un GOPATH vide. Les binaires générés sont placés dans bin/.

Le second bloc étend la règle générique définie dans le premier bloc en fournissant le nom du paquet pour golint. Pour ajouter un autre outil à compiler, une ligne similaire fait l’affaire.

Le dernier bloc définit la recette pour analyser le code. L’outil utilisé par défaut est golint tel que construit par le premier bloc. Mais il est possible d’outrepasser ceci avec make GOLINT=/usr/bin/golint.

Tests

Voici les règles permettant d’exécuter les tests :

TIMEOUT  = 20
PKGS     = $(or $(PKG),$(shell env GO111MODULE=on $(GO) list ./...))
TESTPKGS = $(shell env GO111MODULE=on $(GO) list -f \
            '{{ if or .TestGoFiles .XTestGoFiles }}{{ .ImportPath }}{{ end }}' \
            $(PKGS))

TEST_TARGETS := test-default test-bench test-short test-verbose test-race
test-bench:   ARGS=-run=__absolutelynothing__ -bench=.
test-short:   ARGS=-short
test-verbose: ARGS=-v
test-race:    ARGS=-race
$(TEST_TARGETS): test
check test tests: fmt lint
    go test -timeout $(TIMEOUT)s $(ARGS) $(TESTPKGS)

L’utilisateur peut invoquer les tests de différente façon :

  • make test lance tous les tests ;
  • make test TIMEOUT=10 implique une durée limite de 10 secondes par test ;
  • make test PKG=hellogopher/cmd exécute les tests pour le paquet cmd ;
  • make test ARGS="-v -short" utilise les arguments fournis ;
  • make test-race exécute les tests en activant la détection des problèmes d’accès concurrents.

go test permet également de déterminer la couverture des tests. Malheureusement, l’outil est très rudimentaire et ne permet de gérer qu’un seul paquet à la fois. Il faut également explicitement lister tous les paquets à instrumenter. Dans le cas contraire, seul le paquet testé l’est. De plus, les temps de compilation sont prohibitifs si trop de paquets le sont. Enfin, afin d’obtenir un rapport compatible avec Jenkins, quelques outils additionnels sont nécessaires.

COVERAGE_MODE    = atomic
COVERAGE_PROFILE = $(COVERAGE_DIR)/profile.out
COVERAGE_XML     = $(COVERAGE_DIR)/coverage.xml
COVERAGE_HTML    = $(COVERAGE_DIR)/index.html
test-coverage-tools: | $(GOCOVMERGE) $(GOCOV) $(GOCOVXML) # ❶
test-coverage: COVERAGE_DIR := $(CURDIR)/test/coverage.$(shell date -u +"%Y-%m-%dT%H:%M:%SZ")
test-coverage: fmt lint test-coverage-tools
    @mkdir -p $(COVERAGE_DIR)/coverage
    @for pkg in $(TESTPKGS); do \ # ❷
        go test \
            -coverpkg=$$(go list -f '{{ join .Deps "\n" }}' $$pkg | \
                    grep '^$(MODULE)/' | \
                    tr '\n' ',')$$pkg \
            -covermode=$(COVERAGE_MODE) \
            -coverprofile="$(COVERAGE_DIR)/coverage/`echo $$pkg | tr "/" "-"`.cover" $$pkg ;\
     done
    @$(GOCOVMERGE) $(COVERAGE_DIR)/coverage/*.cover > $(COVERAGE_PROFILE)
    @go tool cover -html=$(COVERAGE_PROFILE) -o $(COVERAGE_HTML)
    @$(GOCOV) convert $(COVERAGE_PROFILE) | $(GOCOVXML) > $(COVERAGE_XML)

En ❶, un certain nombre d’outils sont requis, de la même façon que golint vu précédemment :

  • gocovmerge permet de combiner plusieurs profils en un seul,
  • gocov-xml convertit le rapport au format Cobertura pour Jenkins,
  • gocov convertit le rapport en un format utilisable par gocov-xml.

En ❷, pour chaque paquet à tester, nous exécutons go test avec l’argument -coverprofile. La liste des paquets à instrumenter est donnée à l’argument -coverpkg en utilisant go list pour extraire les dépendances du paquet en cours de test et en ne conservant que nos propres paquets.

Mise à jour (09.2019)

Comme mentionné dans un commentaire, depuis Go 1.10, il est possible de tester plusieurs paquets tout en collectant les informations de couverture. La recette test-coverage peut donc être simplifiée et gocovmerge n’est plus utile.

Construction

Bien que l’on puisse simplement utiliser go build pour obtenir notre programme, il est assez courant d’avoir à fournir quelques arguments supplémentaires ou de devoir exécuter des étapes additionnelles. Dans l’exemple suivant, la version est extraite de l’étiquette Git la plus proche ou d’un fichier .version à la racine du projet. Elle remplace la variable Version dans le paquet hellogopher/cmd.

VERSION ?= $(shell git describe --tags --always --dirty --match=v* 2> /dev/null || \
            cat $(CURDIR)/.version 2> /dev/null || echo v0)
all: fmt lint | $(BIN)
    go build \
        -tags release \
        -ldflags '-X hellogopher/cmd.Version=$(VERSION)' \
        -o $(BIN)/hellogopher main.go

On en profite également pour effectuer le formatage et l’analyse statique du code.


Les extraits fournis ci-dessus sont un brin simplifiés. Jetez un œil sur le résultat final pour plus de détails !

Mise à jour (09.2019)

Il y a un fil intéressant à propos de cet article sur Reddit. Il contient des indices pour bloquer la version des outils tierces. Plusieurs personnes ont également mis en avant Mage, un logiciel de construction utilisant Go. Il nécessite cependant une étape de construction non triviale.


  1. Pour une application qui n’est pas destinée à servir de dépendance, je préfère utiliser un nom court plutôt qu’un nom dérivé d’une URL, comme github.com/vincentbernat/hellogopher. Cela rend plus aisé à lire les blocs d’import :

    import (
            "fmt"
            "os"
    
            "hellogopher/cmd"
    
            "github.com/pkg/errors"
            "github.com/spf13/cobra"
    )
    

    ↩︎

21 July, 2019 07:20PM by Vincent Bernat

July 20, 2019

Écrire un script Python durable

Python est un excellent langage pour écrire rapidement un script entre une dizaine et quelques centaines de lignes de code. Une fois terminé, vous pouvez l’oublier et vous concentrer sur votre prochaine mission.

Six mois plus tard, un collègue vous demande pourquoi ce script échoue et vous n’en avez aucune idée : pas de documentation, paramètres codés en dur, aucune trace pendant l’exécution et aucuns tests pour vous éclairer.

Transformer un script Python « vite fait » en une version durable, facile à utiliser, à comprendre et à modifier par vos collègues et votre futur alter ego, ne demande qu’un effort modéré. À titre d’illustration, commençons par le script suivant pour résoudre le test classique « Fizz-Buzz » :

import sys
for n in range(int(sys.argv[1]), int(sys.argv[2])):
    if n % 3 == 0 and n % 5 == 0:
        print("fizzbuzz")
    elif n % 3 == 0:
        print("fizz")
    elif n % 5 == 0:
        print("buzz")
    else:
        print(n)

Documentation

Je trouve utile d’écrire de la documentation avant même d’écrire la première ligne de code : cela facilite la conception et m’assure de ne pas reporter cette tâche indéfiniment. La documentation peut être placée en haut du script1 :

#!/usr/bin/env python3

"""Simple fizzbuzz generator.

This script prints out a sequence of numbers from a provided range
with the following restrictions:

 - if the number is divisble by 3, then print out "fizz",
 - if the number is divisible by 5, then print out "buzz",
 - if the number is divisible by 3 and 5, then print out "fizzbuzz".
"""

La première ligne est un bref résumé du but du script. Les autres paragraphes contiennent des détails supplémentaires sur son action.

Arguments en ligne de commande

La deuxième étape consiste à transformer les paramètres codés en dur en valeurs documentées et configurables à l’aide d’arguments en ligne de commande, via le module argparse. Dans notre exemple, nous demandons à l’utilisateur de spécifier une plage et nous lui permettons de modifier les valeurs modulo pour « fizz » et « buzz ».

import argparse
import sys


class CustomFormatter(argparse.RawDescriptionHelpFormatter,
                      argparse.ArgumentDefaultsHelpFormatter):
    pass


def parse_args(args=sys.argv[1:]):
    """Parse arguments."""
    parser = argparse.ArgumentParser(
        description=sys.modules[__name__].__doc__,
        formatter_class=CustomFormatter)

    g = parser.add_argument_group("fizzbuzz settings")
    g.add_argument("--fizz", metavar="N",
                   default=3,
                   type=int,
                   help="Modulo value for fizz")
    g.add_argument("--buzz", metavar="N",
                   default=5,
                   type=int,
                   help="Modulo value for buzz")

    parser.add_argument("start", type=int, help="Start value")
    parser.add_argument("end", type=int, help="End value")

    return parser.parse_args(args)


options = parse_args()
for n in range(options.start, options.end + 1):
    # ...

La valeur ajoutée de cette modification est considérable : les paramètres sont maintenant correctement documentés et peuvent être découverts grâce à l’option --help. De plus, la documentation que nous avons écrite dans la section précédente est également affichée :

$ ./fizzbuzz.py --help
usage: fizzbuzz.py [-h] [--fizz N] [--buzz N] start end

Simple fizzbuzz generator.

This script prints out a sequence of numbers from a provided range
with the following restrictions:

 - if the number is divisble by 3, then print out "fizz",
 - if the number is divisible by 5, then print out "buzz",
 - if the number is divisible by 3 and 5, then print out "fizzbuzz".

positional arguments:
  start         Start value
  end           End value

optional arguments:
  -h, --help    show this help message and exit

fizzbuzz settings:
  --fizz N      Modulo value for fizz (default: 3)
  --buzz N      Modulo value for buzz (default: 5)

Le module argparse est assez puissant. S’il ne vous est pas familier, un survol de sa documentation est utile. J’aime particulièrement la possibilité de définir des sous-commandes et de grouper des options.

Traces

La troisième étape est d’afficher des informations durant l’exécution. Le module logging convient parfaitement à cet effet. Tout d’abord, nous définissons le « logger » :

import logging
import logging.handlers
import os
import sys

logger = logging.getLogger(os.path.splitext(os.path.basename(sys.argv[0]))[0])

Ensuite, nous rendons sa verbosité configurable : logger.debug() ne devrait afficher quelque chose que lorsqu’un utilisateur utilise le drapeau --debug. --silent devrait couper les traces sauf si une condition exceptionnelle se produit. Pour cela, nous ajoutons le code suivant dans parse_args() :

# In parse_args()
g = parser.add_mutually_exclusive_group()
g.add_argument("--debug", "-d", action="store_true",
               default=False,
               help="enable debugging")
g.add_argument("--silent", "-s", action="store_true",
               default=False,
               help="don't log to console")

Cette fonction permet alors de configurer les traces :

def setup_logging(options):
    """Configure logging."""
    root = logging.getLogger("")
    root.setLevel(logging.WARNING)
    logger.setLevel(options.debug and logging.DEBUG or logging.INFO)
    if not options.silent:
        ch = logging.StreamHandler()
        ch.setFormatter(logging.Formatter(
            "%(levelname)s[%(name)s] %(message)s"))
        root.addHandler(ch)

Le corps de notre script devient ceci :

if __name__ == "__main__":
    options = parse_args()
    setup_logging(options)

    try:
        logger.debug("compute fizzbuzz from {} to {}".format(options.start,
                                                             options.end))
        for n in range(options.start, options.end + 1):
            # ...
    except Exception as e:
        logger.exception("%s", e)
        sys.exit(1)
    sys.exit(0)

Si le script peut être exécuté non interactivement, par exemple depuis une crontab, il est possible d’envoyer les traces vers syslog :

def setup_logging(options):
    """Configure logging."""
    root = logging.getLogger("")
    root.setLevel(logging.WARNING)
    logger.setLevel(options.debug and logging.DEBUG or logging.INFO)
    if not options.silent:
        if not sys.stderr.isatty():
            facility = logging.handlers.SysLogHandler.LOG_DAEMON
            sh = logging.handlers.SysLogHandler(address='/dev/log',
                                                facility=facility)
            sh.setFormatter(logging.Formatter(
                "{0}[{1}]: %(message)s".format(
                    logger.name,
                    os.getpid())))
            root.addHandler(sh)
        else:
            ch = logging.StreamHandler()
            ch.setFormatter(logging.Formatter(
                "%(levelname)s[%(name)s] %(message)s"))
            root.addHandler(ch)

Pour cet exemple, cela représente beaucoup de code pour un seul appel à logger.debug(), mais en situation réelle, cela est très utile pour aider un utilisateur à comprendre le déroulement du script.

$ ./fizzbuzz.py --debug 1 3
DEBUG[fizzbuzz] compute fizzbuzz from 1 to 3
1
2
fizz

Tests

Les tests unitaires sont très utiles pour s’assurer qu’une application se comporte comme prévu. Il n’est pas courant de les utiliser dans des scripts, mais en écrire quelques-uns améliore grandement la qualité. Transformons le code contenu dans la boucle en une fonction avec quelques exemples interactifs d’utilisation dans sa documentation :

def fizzbuzz(n, fizz, buzz):
    """Compute fizzbuzz nth item given modulo values for fizz and buzz.

    >>> fizzbuzz(5, fizz=3, buzz=5)
    'buzz'
    >>> fizzbuzz(3, fizz=3, buzz=5)
    'fizz'
    >>> fizzbuzz(15, fizz=3, buzz=5)
    'fizzbuzz'
    >>> fizzbuzz(4, fizz=3, buzz=5)
    4
    >>> fizzbuzz(4, fizz=4, buzz=6)
    'fizz'

    """
    if n % fizz == 0 and n % buzz == 0:
        return "fizzbuzz"
    if n % fizz == 0:
        return "fizz"
    if n % buzz == 0:
        return "buzz"
    return n

pytest permet de s’assurer que les résultats sont corrects2 :

$ python3 -m pytest -v --doctest-modules ./fizzbuzz.py
============================ test session starts =============================
platform linux -- Python 3.7.4, pytest-3.10.1, py-1.8.0, pluggy-0.8.0 -- /usr/bin/python3
cachedir: .pytest_cache
rootdir: /home/bernat/code/perso/python-script, inifile:
plugins: xdist-1.26.1, timeout-1.3.3, forked-1.0.2, cov-2.6.0
collected 1 item

fizzbuzz.py::fizzbuzz.fizzbuzz PASSED                                  [100%]

========================== 1 passed in 0.05 seconds ==========================

En cas d’erreur, pytest affiche un message décrivant la localisation et la nature du problème :

$ python3 -m pytest -v --doctest-modules ./fizzbuzz.py -k fizzbuzz.fizzbuzz
============================ test session starts =============================
platform linux -- Python 3.7.4, pytest-3.10.1, py-1.8.0, pluggy-0.8.0 -- /usr/bin/python3
cachedir: .pytest_cache
rootdir: /home/bernat/code/perso/python-script, inifile:
plugins: xdist-1.26.1, timeout-1.3.3, forked-1.0.2, cov-2.6.0
collected 1 item

fizzbuzz.py::fizzbuzz.fizzbuzz FAILED                                  [100%]

================================== FAILURES ==================================
________________________ [doctest] fizzbuzz.fizzbuzz _________________________
100
101     >>> fizzbuzz(5, fizz=3, buzz=5)
102     'buzz'
103     >>> fizzbuzz(3, fizz=3, buzz=5)
104     'fizz'
105     >>> fizzbuzz(15, fizz=3, buzz=5)
106     'fizzbuzz'
107     >>> fizzbuzz(4, fizz=3, buzz=5)
108     4
109     >>> fizzbuzz(4, fizz=4, buzz=6)
Expected:
    fizz
Got:
    4

/home/bernat/code/perso/python-script/fizzbuzz.py:109: DocTestFailure
========================== 1 failed in 0.02 seconds ==========================

Nous pouvons également écrire des tests unitaires sous forme de code. Supposons que nous voulions tester la fonction suivante :

def main(options):
    """Compute a fizzbuzz set of strings and return them as an array."""
    logger.debug("compute fizzbuzz from {} to {}".format(options.start,
                                                         options.end))
    return [str(fizzbuzz(i, options.fizz, options.buzz))
            for i in range(options.start, options.end+1)]

À la fin du script3, nous ajoutons quelques tests unitaires utilisant les tests paramétrés de pytest :

# Unit tests
import pytest                   # noqa: E402
import shlex                    # noqa: E402


@pytest.mark.parametrize("args, expected", [
    ("0 0", ["fizzbuzz"]),
    ("3 5", ["fizz", "4", "buzz"]),
    ("9 12", ["fizz", "buzz", "11", "fizz"]),
    ("14 17", ["14", "fizzbuzz", "16", "17"]),
    ("14 17 --fizz=2", ["fizz", "buzz", "fizz", "17"]),
    ("17 20 --buzz=10", ["17", "fizz", "19", "buzz"]),
])
def test_main(args, expected):
    options = parse_args(shlex.split(args))
    options.debug = True
    options.silent = True
    setup_logging(options)
    assert main(options) == expected

La fonction de test s’exécute une fois pour chacun des paramètres fournis. La partie args est utilisée comme entrée pour la fonction parse_args() afin d’obtenir les options à passer à la fonction main(). La partie expected est comparée au résultat de la fonction main(). Quand tout fonctionne comme prévu, pytest affiche :

python3 -m pytest -v --doctest-modules ./fizzbuzz.py
============================ test session starts =============================
platform linux -- Python 3.7.4, pytest-3.10.1, py-1.8.0, pluggy-0.8.0 -- /usr/bin/python3
cachedir: .pytest_cache
rootdir: /home/bernat/code/perso/python-script, inifile:
plugins: xdist-1.26.1, timeout-1.3.3, forked-1.0.2, cov-2.6.0
collected 7 items

fizzbuzz.py::fizzbuzz.fizzbuzz PASSED                                  [ 14%]
fizzbuzz.py::test_main[0 0-expected0] PASSED                           [ 28%]
fizzbuzz.py::test_main[3 5-expected1] PASSED                           [ 42%]
fizzbuzz.py::test_main[9 12-expected2] PASSED                          [ 57%]
fizzbuzz.py::test_main[14 17-expected3] PASSED                         [ 71%]
fizzbuzz.py::test_main[14 17 --fizz=2-expected4] PASSED                [ 85%]
fizzbuzz.py::test_main[17 20 --buzz=10-expected5] PASSED               [100%]

========================== 7 passed in 0.03 seconds ==========================

Quand une erreur survient, pytest fournit une évaluation de la situation :

$ python3 -m pytest -v --doctest-modules ./fizzbuzz.py
[...]
================================== FAILURES ==================================
__________________________ test_main[0 0-expected0] __________________________

args = '0 0', expected = ['0']

    @pytest.mark.parametrize("args, expected", [
        ("0 0", ["0"]),
        ("3 5", ["fizz", "4", "buzz"]),
        ("9 12", ["fizz", "buzz", "11", "fizz"]),
        ("14 17", ["14", "fizzbuzz", "16", "17"]),
        ("14 17 --fizz=2", ["fizz", "buzz", "fizz", "17"]),
        ("17 20 --buzz=10", ["17", "fizz", "19", "buzz"]),
    ])
    def test_main(args, expected):
        options = parse_args(shlex.split(args))
        options.debug = True
        options.silent = True
        setup_logging(options)
>       assert main(options) == expected
E       AssertionError: assert ['fizzbuzz'] == ['0']
E         At index 0 diff: 'fizzbuzz' != '0'
E         Full diff:
E         - ['fizzbuzz']
E         + ['0']

fizzbuzz.py:160: AssertionError
----------------------------- Captured log call ------------------------------
fizzbuzz.py                125 DEBUG    compute fizzbuzz from 0 to 0
===================== 1 failed, 6 passed in 0.05 seconds =====================

L’appel à logger.debug() est inclus dans la sortie. C’est une autre bonne raison d’émettre des traces ! Si vous voulez en savoir plus sur les fonctionnalités de pytest, jetez un coup d’œil sur « Test d’un applicatif réseau avec pytest et les espaces de noms Linux ».


En résumé, les quatre modifications à apporter pour rendre un script Python plus durable sont :

  1. ajouter de la documentation en haut du script,
  2. utiliser le module argparse pour documenter les différents paramètres,
  3. utiliser le module logging pour enregistrer les détails sur l’exécution,
  4. ajouter quelques tests unitaires.

L’exemple complet est disponible sur GitHub et peut être utilisé comme modèle !


  1. La documentation est systématiquement en anglais. Dans notre domaine, il paraît difficile de faire l’impasse sur ce sujet. ↩︎

  2. Ceci nécessite que le nom du script se termine par .py. Je n’aime pas ajouter une extension à un nom de script : le langage est un détail technique qui ne doit pas être exposé à l’utilisateur. Cependant, il semble que ce soit le moyen le plus simple de permettre aux programmes tels que pytest de découvrir les tests à exécuter. ↩︎

  3. Du fait que le script se termine par un appel à sys.exit(), le code contenant les tests n’est pas exécuté en temps normal. Ainsi, pytest n’est pas nécessaire pour faire tourner le script. ↩︎

20 July, 2019 03:04PM by Vincent Bernat

July 13, 2019

hackergotchi for Debian France

Debian France

Nouvelles de l'association Debian France - Été 2019

Dernières nouvelles de l'association et des décisions du CA

 Informations du CA - Votes et résultats

  • Don goodies aux participants ou organisateurs d'évènements :

Faisant suite à un vote du CA, la somme de 40€ maximum par an peut être accordée sous forme de goodies à un organisateur ou participant d'évènement (pour une journée entière).

  • Délégation des pouvoirs du Bureau :

Faisant suite à un vote du CA, la liste des délégations du Bureau a été mise à jour et ajoutée sur le site de l'association dans la section L'équipe .
Nous avons maintenant un Vice-Trésorier et un Vice-Secrétaire.

 Évènements passés

  • Stand lors de PSES (Pas Sage En Seine) du 27 au 30 Juin. Merci à Jean-Philippe, Quentin et Alban.
  • Meetup à Bordeaux le 27 Juin. Merci à Pierre, Hervé et Lilian.

Évènements à venir

  • DebianDay - Anniversaire de Debian le 16 Août - Je vous invite à ajouter votre ville si vous voulez faire un évènement pour l’occasion !
  • Stand au Capitole du Libre en Novembre (date non confirmée)
  • Stand au Paris Open Source Summit (POSS) les 10 et 11 Décembre 2019
  • Meetup Bordeaux 2nd semestre 2019 ?
  • Meetup Paris 2nd semestre 2019 ?
  • Mini-DebConf 2020 à Bordeaux

 Autre

  • La page Présentations sur le Wiki Debian permet de regrouper les différentes présentations.
    Cette page n'est pas toute jeune et comportait plusieurs langues.
    Nous en avons donc profité pour faire une page dédiée aux présentations en Français . Si vous avez déjà des présentations, n'hésitez pas à les ajouter.

  • Après l'été, une réunion de l'association sera organisée sur IRC (OFTC canal #debian-france), vous êtes tous conviés à y participer.
    Aucune date n'est encore prévue.

  • Conformément à l'Article 7§c du Statuts de l'association en date du 18 Janvier 2014, un courriel d'appel de cotisation a été envoyé le 31 Mai 2019.
    Les secrétaires se sont lancés dans un nettoyage des comptes en les désactivant dans l'outil Galette ceux n'ayant pas donné de nouvelles depuis.

Nous vous souhaitons de bonnes vacances estivales (pour ceux qui ont la chance d'en avoir).

Alban et Quentin, Secrétaires Debian France

13 July, 2019 02:24PM

July 04, 2019

hackergotchi for Charles Plessy

Charles Plessy

Zéro inbox

J'ai effacé par accident toute la boîte de réception de mes courriels. C'est très facile avec mutt. J'ai quelque expérience dans la récupération de fichiers mais la dernière fois que je l'ai fait, ça ne m'a pas servi à grand chose au final. Alors envoyez-moi un rappel si vous attendez une réponse de ma part !

04 July, 2019 12:52PM

June 10, 2019

hackergotchi for Debian France

Debian France

Festival Pas Sage En Seine (PSES) 2019

L'association Debian France tiendra un stand à l'occasion du Festival Pas Sage En Seine 2019, du 27 au 30 Juin 2019 à la Médiathèque de Choisy-le-Roi (94600) à 5 min à pied de la Gare de RER « Choisy-le-Roi » sur la ligne C.

Venez nous rencontrer afin d'échanger au sujet de la distribution Debian et de l'association Debian France.

À très bientôt !

10 June, 2019 02:32PM

June 05, 2019

hackergotchi for Gr&#233;gory Colpart

Grégory Colpart

Mini-DebConf Marseille 2019 (fr)

L’idée d’organiser une mini-DebConf à Marseille est née à Toulouse en 2017 : après avoir participé avec plaisir à plusieurs (mini)DebConfs, se lancer dans l’organisation d’un tel évènement est une manière de rendre la pareille et de contribuer à Debian !

Fin 2018, après avoir réuni les personnes motivées, nous avons choisi la date du 25/26 mai 2019 et dimensionner l’évènement pour 50 à 70 personnes en sélectionnant un lieu approprié au centre-ville de Marseille. Je ne vais pas m’attarder ici sur détails de l’organisation (appel à conférences, enregistrement des participants, composition du programme etc.), car nous allons publier bientôt un « Howto Organizing a mini-DebConf » pour partager notre expérience.

Tout a commencé dès le mercredi 22 mai, où la formidable équipe vidéo DebConf s’est réunie pour un sprint de 3 jours pour préparer la couverture de l’événement avec le matériel déjà arrivé et former les membres qui gèreront le matériel pour la mini-DebConf Hambourg.

Vendredi 24 mai, l’équipe de traduction francophone de Debian est arrivée pour un sprint d’une journée. La plupart d’entre eux ne s’était jamais rencontré physiquement !

Une majeure partie des participants sont arrivés dans l’après-midi du vendredi 24 mai. Le bureau d’accueil (Front-Desk) était déjà prêt, et les arrivants ont pu récupérer leur badge et un T-shirt de l’événement. Pour des raisons écologiques, nous avions décidé de minimiser les goodies offerts au participants donc pas de sacs ou papiers superflus, mais un booklet distribué en amont. Si besoin, des goodies Debian (stickers, casquettes, polos, etc.) étaient aussi en vente au Front-Desk.

La soirée de vendredi a débuté avec un mini-CheeseWineBOF avec des denrées locales (fromages, vins, pastis, olives, fruits et légumes) et apportées par des participant(e)s : merci à Valhalla pour fromage italien, ainsi qu’à Urbec et Tzafrir !

La soirée de vendredi s’est poursuivie : pendant que l’équipe vidéo finalisait son installation dans la salle de conférence, les participants ont été invités à une réunion du Linux Users Group de Marseille : une présentation de Florence Devouard, pionnière de Wikipédia, qui est revenue l’historique de Wikipédia/Wikimédia avec de nombreuses anecdotes. La soirée s’est achevée avec une tradition locale : la dégustation de pizzas marseillaises. Le week-end n’est pas encore commencé, et déjà de bons moments sont partagés entre les participants !

Samedi matin, c’était le coup d’envoi officiel de la mini-DebConf ! Ouverture des portes à 8h30 pour le petit déjeuner : cookies fait-maison, café en grains, nous avons proposé durant tout le week-end de la cuisine locale, fait-main et végétarienne. Autre objectif : minimiser les déchets, et dans cette optique nous avons réfléchi à différents dispositifs : couverts en dur, tasses à étiqueter, Ecocups, etc.

75 participants s’étaient inscrits, ce qui correspondait au maximum de la capacité du lieu. Et 73 sont effectivement venus, ce qui est un bel exploit, notamment pour une conférence totalement gratuite. Si l’on compte quelques participants non-inscrits, nous avons été au total plus de 75 participants, soit au-delà de nos espérances !

À 9h45, c’est la conférence d’ouverture ! Jérémy déroule le programme du week-end, remercie les sponsors et rappelle le Code of Conduct, le système d’autorisations pour les photos, etc.

À 10h, c’est parti pour la première conférence ! Les choses sérieuses débutent : Cyril Brulebois – release manager du Debian Installer – détaille le fonctionnement de la migration d’un package vers Testing, et propose une solution pour visualiser les dépendances entre les packages et comprendre ainsi pourquoi un package peut être bloqué.

On enchaîne ensuite avec Peter Green – co-fondateur du projet Raspbian – qui présente l’outil autoforwardportergit qu’il utilise pour automatiser la création de packages Debian modifiés pour Raspbian.

Après une pause-café, c’est Raphaël Hertzog qui revient sur 5 ans du projet Debian LTS (Long Term Support). Il explique l’historique ainsi que le fonctionnement : la gestion des sponsors, le travail réparti entre plusieurs développeurs, l’offre extended LTS, l’infrastructure. Le sujet du financement des contributeurs provoquera plusieurs questions et suscitera un Lightning Talk sur le sujet dimanche matin.

Durant le midi, pendant que l’infatiguable équipe vidéo forme des débutants à ses outils, un déjeuner est servi sous forme de buffet végétalien ou végétarien. Nous sommes fiers d’avoir réussi à offrir une cuisine fait-maison avec des produits frais et locaux, et sans gâchis grâce à une bonne gestion des quantités.

Après le déjeuner, c’est l’heure de la KSP (Key Signing Party) organisée par Benoît. L’occasion pour chacun d’échanger des signatures de clés GPG et de renforcer le réseau de confiance.

Et l’on repart pour un cycle de conférences, avec Elena “of Valhalla” Grandi qui présente le protocole ActivityPub pour des réseaux sociaux fédérés comme Mastodon, Pixelfed, etc.

C’est au tour de Laura Arjona Reina venue de Madrid pour présenter la Welcome Team au sein de Debian qui œuvre pour accueillir les nouveaux arrivants.

Ensuite, Denis Briand – fraîchement élu président de Debian France – nous parle de l’association Debian France, de son but, de ses actions et de ses projets.

C’est au tour de Frédéric Lenquette d’aborder le sujet « Hardening and Secure Debian Buster » en explorant toutes les possibilités de sécurisation d’une Debian 10.

Enfin, dernière conférence de la journée de samedi : une partie de l’équipe de traduction francophone (Thomas Vincent, Jean-Philippe Mengual and Alban Vidal) présente son travail : comment fonctionne le travail en équipe, quelles tâches peuvent être faites par des débutants, etc.

Samedi soir, fin de la première journée : tous les participants sont invités à prolonger les échanges à la Cane Bière, un bar proche de la mini-DebConf.

Dimanche matin, on repart avec une présentation de l’équipe vidéo (représentée par Nicolas Dandrimont et Louis-Philippe Véronneau) qui révèle ses secrets pour assurer la couverture vidéo des (mini)DebConfs !

Puis on enchaîne avec une session de 6 Lightning Talks animés par Eda : « kt-update » (Jean-François Brucker), « the Debian Constitution » (Judit Foglszinger), « Elections, Democracy, European Union » (Thomas Koch), les méthodes de vote de Condorcet et du Jugement Majoritaire (Raphaël Hertzog), « encrypt the whole disk with LUKS2 » (Cyril Brulebois), « OMEMO – the big fish in the Debian bowl » (Martin) et « Paye ton Logiciel Libre » (Victor).

Après quelques mots pour clôturer les conférences, c’est déjà l’heure du rangement pour certains, tandis que d’autres en profitent pour faire un mini-DayTrip : descendre la Canebière à pied et embarquer au Vieux Port pour l’archipel du Frioul pour marcher et nager !

Nous remercions les 75 participant(e)s venus du monde entier (Canada, USA, Israël, Angleterre, Allemagne, Espagne, Suisse, Australie, Belgique etc.) ! Nous remercions également la fantastique équipe vidéo qui réalise un travail remarquable et impressionnant de qualité. Nous remercions Debian France qui a organisé l’événement, et les sponsors : Bearstech, Logilab et Evolix. Nous remercions la Maison du Chant de nous avoir mis à disposition les locaux. Nous remercions Valentine et Célia qui ont assuré tous les repas, il y a eu de nombreux compliments. Nous remercions Florence Devouard d’avoir assuré une belle présentation vendredi soir, ainsi que tous les orateurs(ices) de la mini-DebConf. Et je tiens à remercier tous les bénévoles qui ont assuré la préparation et le bon déroulement de l’événement : Tristan, Anaïs, Benoît, Juliette, Ludovic, Jessica, Éric, Quentin F. et Jérémy D. Mention spéciale à Eda, Moussa, Alban et Quentin L. pour leur implication et leur motivation, et à Sab et Jérémy qui se sont plongés avec moi dans cette folle aventure depuis plusieurs mois : you rock guys !

Twitter : https://twitter.com/MiniDebConf_MRS
Mastodon : https://mamot.fr/@minidebconf_mrs
Photos : https://minidebcloud.labs.evolix.org/apps/gallery/s/keMJaK5o3D384RA
Vidéos : https://ftp.acc.umu.se/pub/debian-meetings/2019/miniconf-marseille

05 June, 2019 01:57PM by Gregory Colpart

May 27, 2019

hackergotchi for Vincent Bernat

Vincent Bernat

Petit traité empirique de l'empaquetage Debian (2019)

Note

Ce guide est une mise à jour d’une version précédente. Si vous avez besoin de construire des paquets pour des distributions plus anciennes que Debian Stretch et Ubuntu Bionic, jetez un œil sur l’édition précédente.

Bien que la création de paquets Debian soit abondamment documentée, la plupart des tutoriaux ciblent les paquets respectueux de la charte Debian. De plus, leur création a longtemps eu la réputation d’être particulièrement difficile1 et beaucoup se sont tournés vers des outils moins contraignants2 tels que fpm ou CheckInstall.

Toutefois, la construction de paquets Debian en utilisant les outils officiels est plutôt simple en appliquant ces quelques concessions :

  1. Aucun paquet source ne sera généré. Les paquets seront construits directement depuis une copie propre issue du système de versions.

  2. Des dépendances supplémentaires peuvent être téléchargées pendant la construction. Empaqueter individuellement chaque dépendance est un travail ingrat, notamment avec certains environnements tels que Java, Javascript et Go.

  3. Les paquets produits peuvent combiner et inclure des dépendances tierces. Cela peut lever certaines objections liées à la sécurité et à la maintenance à long terme, mais c’est une concession courante dans certains écosystèmes tels que Java, Javascript et Go.

Ceinture blanche

Deux types de paquets coexistent dans l’archive Debian : les paquets sources et les paquets binaires. Un paquet source produit un ou plusieurs paquets binaires. Chaque paquet doit porter un nom.

Comme indiqué lors de l’introduction, aucun paquet source ne sera construit. Nous allons travailler directement sur sa représentation décompressée : une arborescence de fichiers incluant le répertoire debian/. Les exemples qui suivent utilisent une arborescence composée uniquement du répertoire debian/, mais ce dernier peut être inclus dans n’importe quel project existant.

Comme point de départ, nous allons empaqueter memcached, un cache mémoire distribué. Il nous faut créer quatre fichiers :

  • debian/compat,
  • debian/changelog,
  • debian/control et
  • debian/rules.

Le premier contient uniquement 113 :

echo 11 > debian/compat

Le second contient ceci :

memcached (0.0-0) UNRELEASED; urgency=medium

  * Fake entry

 -- Happy Packager <happy@example.com>  Tue, 19 Apr 2016 22:27:05 +0200

La seule information d’importance est le nom du paquet source, memcached, sur la première ligne. Toutes les autres informations sont sans influence sur les paquets créés.

Le fichier de contrôle

debian/control décrit les méta-données à propos du paquet source et des paquets binaires. Un bloc est dédié à chacun d’eux.

Source: memcached
Maintainer: Vincent Bernat <bernat@debian.org>

Package: memcached
Architecture: any
Description: high-performance memory object caching system

Le paquet source est memcached. Il faut utiliser le même nom que dans le fichier debian/changelog.

Un seul paquet binaire est créé : memcached. Par la suite, si vous voyez memcached, il s’agit du nom du paquet binaire. Le champ Architecture doit être soit any, soit all. Ce dernier est utilisé exclusivement si tous les fichiers sont indépendants de l’architecture matérielle. Dans le doute, il suffit de mettre any.

Le champ Description contient une courte description du paquet binaire.

La recette

Le dernier fichier à rédiger est debian/rules. Il s’agit de la recette du paquet. Nous avons besoin de télécharger memcached, le construire et installer son arborescence dans debian/memcached/ :

#!/usr/bin/make -f

DISTRIBUTION = $(shell sed -n "s/^VERSION_CODENAME=//p" /etc/os-release)
VERSION = 1.5.16
PACKAGEVERSION = $(VERSION)-0~$(DISTRIBUTION)0
TARBALL = memcached-$(VERSION).tar.gz
URL = http://www.memcached.org/files/$(TARBALL)

%:
    dh $@

override_dh_auto_clean:
override_dh_auto_test:
override_dh_auto_build:
override_dh_auto_install:
    wget -N --progress=dot:mega $(URL)
    tar --strip-components=1 -xf $(TARBALL)
    ./configure --prefix=/usr
    make
    make install DESTDIR=debian/memcached

override_dh_gencontrol:
    dh_gencontrol -- -v$(PACKAGEVERSION)

Les cibles vides override_dh_auto_clean, override_dh_auto_test et override_dh_auto_build permettent de s’assurer que debhelper ne fera rien de « magique ». La cible override_dh_gencontrol permet de spécifier la version4 sans avoir à tenir à jour debian/changelog. Cette recette est très similaire à ce qui aurait été écrit pour fpm :

DISTRIBUTION=$(sed -n "s/^VERSION_CODENAME=//p" /etc/os-release)
VERSION=1.5.16
PACKAGEVERSION=${VERSION}-0~${DISTRIBUTION}0
TARBALL=memcached-${VERSION}.tar.gz
URL=http://www.memcached.org/files/${TARBALL}

wget -N --progress=dot:mega ${URL}
tar --strip-components=1 -xf ${TARBALL}
./configure --prefix=/usr
make
make install DESTDIR=/tmp/installdir

# Build the final package
fpm -s dir -t deb \
    -n memcached \
    -v ${PACKAGEVERSION} \
    -C /tmp/installdir \
    --description "high-performance memory object caching system"

Vous pouvez lire le résultat final sur GitHub et le construire avec la commande dpkg-buildpackage -us -uc -b ou avec GIT_PBUILDER_OPTIONS=--use-network=yes DIST=bionic git-pbuilder -us -uc -b si vous avez déjà mis en place un outil tel que pbuilder.

Ceinture jaune

À partir de là, il est possible d’inclure quelques améliorations. Aucune n’est essentielle mais le gain est suffisamment intéressant pour justifier l’effort.

Les dépendances sources

Notre recette initiale ne fonctionne que si nous disposons déjà de wget et de libevent-dev. Ces paquets ne sont pas présents sur tous les systèmes. Il est assez aisé de spécifier ces dépendances en ajoutant un champ Build-Depends dans debian/control :

Source: memcached
Build-Depends: debhelper (>= 11),
               wget, ca-certificates,
               libevent-dev

Il faut toujours spécifier debhelper (>= 11) car son utilisation est centrale dans debian/rules. Il n’y a pas besoin de dépendre de make ou d’un compilateur C car le paquet build-essential est considéré comme toujours présent et il les fournit indirectement. dpkg-buildpackage se plaindra si une des dépendances est manquante. Pour installer sans peine ces paquets, par exemple depuis un environnement d’intégration continue, vous pouvez utiliser la commande suivante5 :

mk-build-deps \
    -t 'apt-get -o Debug::pkgProblemResolver=yes --no-install-recommends -qqy' \
    -i -r debian/control

Il est aussi intéressant de se pencher sur des outils tels que pbuilder, sbuild ou whalebuilder. Ils permettent de construire des paquets dans un environnement minimal et isolé.

Les dépendances binaires

Si le paquet ainsi construit est installé sur une machine vierge, memcached refusera de démarrer en raison de l’absence de libevent. Il est possible d’exprimer cette dépendance en ajoutant un champ Depends dans le fichier debian/control. De plus, dans le cas des bibliothèques dynamiques, ces dépendances peuvent être générées automatiquement en utilisant des variables de substitution :

Package: memcached
Depends: ${misc:Depends}, ${shlibs:Depends}

Le paquet construit contiendra les informations suivantes :

$ dpkg -I ../memcached_1.5.16-0\~buster0_amd64.deb | grep Depends
 Depends: libc6 (>= 2.17), libevent-2.1-6 (>= 2.1.8-stable)

Intégration avec un système de démarrage

La plupart des paquets fournissant un démon incluent une intégration avec le système de démarrage afin de démarrer le démon au boot ou de le redémarrer après une mise à jour. Bien que Debian assure la prise en charge de plusieurs systèmes de démarrage, je pense qu’il est préférable de se limiter à systemd.

Pour fournir un script pour systemd, il convient de placer son contenu dans debian/memcached.service. Par exemple :

[Unit]
Description=memcached daemon
After=network.target

[Service]
Type=forking
Environment=PORT=11211
Environment=MAXCONN=1024
Environment=CACHESIZE=64
Environment=OPTIONS=
ExecStart=/usr/bin/memcached -d -p $PORT -m $CACHESIZE -c $MAXCONN $OPTIONS
Restart=on-failure
User=_memcached
DynamicUser=yes

[Install]
WantedBy=multi-user.target

La directive Type est la plus importante. Nous avons utilisé forking car memcached est démarré à l’aide de l’option -d. Cela lui indique de se mettre en arrière-plan lorsqu’il est prêt à accepter des requêtes. Les autres possibilités sont notify pour un démon spécifiquement prévu pour fonctionner avec systemd ou simple pour un démon ne passant pas en arrière-plan.

Si un utilisateur veut personnaliser l’une des directives Environment, il peut utiliser systemctl edit memcached.service pour créer le fichier /etc/systemd/system/memcached.service.d/override.conf qui va surcharger les définitions du script fourni par le paquet. systemctl cat memcached.service permet d’obtenir la définition finale du service.

La directive DynamicUser est particulièrement intéressante. Elle indique à systemd de créer dynamiquement l’utilisateur _memcached6 qui sera utilisé pour faire tourner le démon. Cela nous libère de la gestion d’un utilisateur système !

Le résultat final est disponible sur GitHub et peut être testé avec la commande dpkg-buildpackage -us -uc -b.

Ceinture verte

Il est possible d’exploiter certaines capacités de debhelper pour réduire la taille du fichier debian/rules et pour le rendre plus déclaratif. Cette section est totalement optionnelle : vous pouvez la sauter si besoin.

Banalités

Il y a quatre étapes dans la construction d’un paquet Debian :

  1. debian/rules clean va nettoyer l’arborescence pour revenir dans son état initial.

  2. debian/rules build doit construire le logiciel. Pour quelque chose de basé sur autoconf, comme memcached, il s’agit essentiellement d’exécuter ./configure && make.

  3. debian/rules install doit installer l’arborescence de chaque paquet binaire dans le répertoire approprié. Pour des logiciels basés sur autoconf, il s’agit d’exécuter make install DESTDIR=debian/memcached.

  4. debian/rules binary doit empaqueter les différentes arborescences en paquets binaires.

Il ne faut pas écrire directement chacune de ces cibles. L’utilitaire dh, un composant de debhelper, va faire la majeure partie du boulot. Le fichier debian/rules minimaliste suivant suffit pour accomplir cette tâche pour de nombreux paquets sources :

#!/usr/bin/make -f
%:
    dh $@

Pour chacune des quatre cibles décrites ci-dessus, vous pouvez exécuter dh --no-act pour voir les utilitaires invoqués. Par exemple :

$ dh build --no-act
   dh_testdir
   dh_update_autotools_config
   dh_auto_configure
   dh_auto_build
   dh_auto_test

Chacun de ces utilitaires dispose d’une page de manuel. Ceux commençant par dh_auto sont un peu « magiques ». Par exemple, dh_auto_configure va tenter de configurer automatiquement le logiciel avant l’étape de construction. Selon les cas, il peut invoquer ./configure, cmake ou Makefile.PL.

Si un des utilitaires dh_ ne fait pas ce qu’il faut, il est possible de le remplacer en déclarant une cible nommée de manière adéquate :

override_dh_auto_configure:
    ./configure --with-some-grog

Chaque utilitaire est également configurable via des options. Ainsi, il est possible de modifier leurs comportements en définissant la cible correspondante et en invoquant l’utilitaire manuellement :

override_dh_auto_configure:
    dh_auto_configure -- --with-some-grog

Ainsi, ./configure sera appelé avec l’option --with-some-grog mais aussi avec des options par défaut telles que --prefix=/usr. Il y a une page de manuel pour chacun de ces outils.

Dans l’exemple initial de memcached, ces cibles « magiques » sont surchargées. dh_auto_clean, dh_auto_configure et dh_auto_build ont été neutralisées pour éviter tout comportement inattendu. dh_auto_install a été détournée pour exécuter l’intégralité de la construction de l’arborescence cible. De plus, le comportement de dh_gencontrol a été modifié en lui fournissant le numéro de version désiré plutôt que de le laisser regarder dans debian/changelog.

Construction automatique

memcached utilisant autoconf, dh sait comment le construire : ./configure && make && make install. Il est donc possible de laisser dh faire la majeure partie du boulot avec le fichier debian/rules suivant :

#!/usr/bin/make -f

DISTRIBUTION = $(shell sed -n "s/^VERSION_CODENAME=//p" /etc/os-release)
VERSION = 1.5.16
PACKAGEVERSION = $(VERSION)-0~$(DISTRIBUTION)0
TARBALL = memcached-$(VERSION).tar.gz
URL = http://www.memcached.org/files/$(TARBALL)

%:
    dh $@ --with systemd

override_dh_update_autotools_config:
    wget -N --progress=dot:mega $(URL)
    tar --strip-components=1 -xf $(TARBALL)

override_dh_auto_test:
    # Don't run the whitespace test
    rm t/whitespace.t
    dh_auto_test

override_dh_gencontrol:
    dh_gencontrol -- -v$(PACKAGEVERSION)

La cible dh_update_autotools_config est détournée pour effectuer le téléchargement et la mise en place de l’arborescence. Ni dh_auto_configure, ni dh_auto_build ne sont modifiés. dh appellera ./configure avec les options appropriées puis make. dh_auto_test doit exécuter la suite de tests de memcached. Toutefois, un des tests échoue en raison d’un fichier dans le répertoire debian/. Nous supprimons ce test récalcitrant et invoquons manuellement dh_auto_test. dh_auto_install n’est pas surchargé et dh exécutera alors une variante de make install.

Afin de mieux apprécier la différence, la voici sous forme de patch :

--- memcached-intermediate/debian/rules 2019-05-31 07:52:40.908868035 +0200
+++ memcached/debian/rules      2019-05-31 07:28:17.404380064 +0200
@@ -9,15 +9,14 @@
 %:
    dh $@

-override_dh_auto_clean:
-override_dh_auto_test:
-override_dh_auto_build:
-override_dh_auto_install:
+override_dh_update_autotools_config:
    wget -N --progress=dot:mega $(URL)
    tar --strip-components=1 -xf $(TARBALL)
-   ./configure --prefix=/usr
-   make
-   make install DESTDIR=debian/memcached
+
+override_dh_auto_test:
+   # Don't run the whitespace test
+   rm t/whitespace.t
+   dh_auto_test

 override_dh_gencontrol:
    dh_gencontrol -- -v$(PACKAGEVERSION)

Vous avez le choix de laisser dh faire une partie du travail ou non. Il est généralement possible de partir d’un debian/rules minimal et de surcharger uniquement quelques cibles.

Fichiers supplémentaires

Bien que make install a installé les fichiers essentiels pour memcached, il est parfois nécessaire de copier quelques fichiers supplémentaires dans le paquet binaire. Pour se faire, il est possible d’utiliser cp ou encore de déclarer les fichiers à copier :

  • les fichiers listés dans debian/memcached.docs seront copiés dans /usr/share/doc/memcached par dh_installdocs,
  • les fichiers listés dans debian/memcached.examples seront copiés dans /usr/share/doc/memcached/examples par dh_installexamples,
  • les fichiers listés dans debian/memcached.manpages seront copiés dans le sous-répertoire approprié de /usr/share/man par dh_installman,

Voici un exemple pour debian/memcached.docs :

doc/*.txt

Si vous avez besoin de copier des fichiers à un endroit arbitraire, il est possible de lister ceux-ci ainsi que leur répertoire cible dans le fichier debian/memcached.install. dh_install se chargera de la copie. Par exemple :

scripts/memcached-tool usr/bin

L’utilisation de ces fichiers permet une description plus déclarative de la recette. Il s’agit d’une histoire de goût et vous pouvez tout à fait utiliser cp à la place. Le résultat final est visible sur GitHub.

Autres exemples

Le dépôt Git comprend d’autres exemples. Ils suivent tous le même schéma et mettent en œuvre les techniques décrites dans les sections précédentes :

  • dh_update_autotools_config est surchargée pour télécharger et mettre en place les sources,
  • dh_gencontrol est modifiée pour fixer la version du paquet.

Il y a notamment des exemples de démons en Java, Go, Python et Node.js. Le but de ces exemples est de démontrer que l’utilisation des outils Debian est relativement simple. Mission accomplie ?

Mise à jour (05.2019)

Ce guide a été mis à jour pour utiliser override_dh_update_autotools_config pour télécharger des fichiers à la place de override_dh_auto_clean. Cela permet une intégration plus simple avec la plupart des outils de construction, tels que pbuilder et sbuild.


  1. La mémoire collective est toujours marquée par la glorieuse époque précédant l’introduction de debhelper 7.0.50 (circa 2009). La création du fichier debian/rules était alors particulièrement laborieuse. Toutefois, de nos jours, le squelette est devenu minimal. ↩︎

  2. La complexité n’est pas la seule raison de ce choix : les outils alternatifs proposent également la création de paquets RPM, ce que les outils Debian ne permettent pas. ↩︎

  3. Ce niveau de compatibilité est disponible à partir de Debian 9 et d’Ubuntu Bionic. Il couvre donc les distributions modernes. ↩︎

  4. Il y a différentes façons de numéroter les versions d’un paquet. La façon proposée ici n’est pas plus mauvaise qu’une autre pour Ubuntu. Pour Debian, elle ne couvre pas les mises à jour entre deux versions de la distribution. De nos jours, il est cependant plutôt courant de réinstaller un système plutôt que de le mettre à jour. ↩︎

  5. Les paquets devscripts et equivs sont alors nécessaires. ↩︎

  6. La charte Debian ne se prononce pas sur la convention à utiliser. Il est courant de préfixer le nom du démon avec un tiret bas (comme dans les BSD). Un autre usage courant est d’utiliser Debian- comme préfixe. Cette dernière méthode a l’inconvénient de produire un nom d’utilisateur trop long pour être visible dans les utilitaires comme top et ps.

    Si la directive User n’est pas précisée, systemd utilise simplement le nom du service comme nom d’utilisateur. Si cela vous convient, vous pouvez alors omettre cette directive. ↩︎

27 May, 2019 08:12PM by Vincent Bernat

May 22, 2019

hackergotchi for Charles Plessy

Charles Plessy

Enregistrez vos types media auprès de l'IANA !

En qualité de mainteneur du paquet mime-support dans Debian, je voudrais dire « kudos » à Petter Reinholdtsen, qui a ouvert un ticket à l'IANA pour créer le type media text/vnd.sosi. Que son example soit suivi !

22 May, 2019 10:19PM

April 21, 2019

Florent Gallaire

Sam Hartman élu DPL pour 2019

C’est Sam Hartman qui vient d’être élu Debian Project Leader (DPL) pour l’année 2019, succédant ainsi au second mandat de Chris Lamb qui avait été réélu sans opposition en 2018.

Dans une élection plus incertaine que les années précédentes, Sam l’emporte largement devant Martin Michlmayr, Joerg Jaspert et Jonathan Carter arrivés tous les trois quasiment à égalité – expression approximative concernant un scrutin qui utilise la méthode Condorcet, mais qui en reflète assez bien la réalité -.

Vote DPL 2019

Sam a commencé à s’investir dans le projet Debian en packageant Kerberos et d’autres logiciels de sécurité, et il participe aussi activement à l’amélioration de l’accessibilité puisqu’il présente la particularité d’être aveugle. Vous pourrez en apprendre plus sur Sam dans cette interview de lui faite par Raphaël Hertzog en 2011.

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

21 April, 2019 01:24AM by fgallaire

March 17, 2019

Quel DPL pour 2019 ?

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

Cependant, aucun candidat ne s’est déclaré pendant cette période. Après la question de la légitimité d’un scrutin avec un seul candidat, posée en 2016 par Paul Wise lorsque Mehdi Dogguy fut seul à se présenter, et déjà d’actualité en 2011 puis à nouveau d’actualité en 2018 quand Stefano Zacchiroli et Chris Lamb furent seuls à concourir à leur réélection, se posait la question de l’existence même d’un scrutin sans candidats

Heureusement la Constitution du projet Debian avait prévu ce cas de figure dans sa section 5.2. Nomination :

4. […] S’il n’y a pas de candidats à la fin de la période de désignation alors cette période est étendue d’une semaine supplémentaire, autant de fois que nécessaire.

La période de candidature fut donc prolongée d’une semaine, jusqu’au 16 mars, dans l’attente de candidats. Le fait que Lamby ait clairement explicité le fait qu’il n’avait pas l’intention de se représenter :

Whilst it would have been clear to any serious potential candidate already, for the sake of clarity I will not be looking to extend my term in this year’s DPL elections.

a semble-t-il réveillé les ambitions endormies et ce sont finalement pas moins de cinq candidats qui se présenteront cette année :

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

Mise à jour du 29 mars 2019 : Simon Richter s’est retiré de l’élection.

17 March, 2019 04:34AM by fgallaire

January 08, 2019

Stéphane Blondon

Processeur Intel -> Architecture AMD64 pour Debian

TL;DR

Nom courant Dénomination Debian Disponibilité
x86 i386 rarement en vente après 2010
x86_64 amd64 à moins d’acheter des ordinateurs spécifiques, il n’y a plus que ça pour le grand public

Si vous venez d’acheter un ordinateur, choisissez amd64.

L’histoire, avec un grand L

Intel avait conçu une architecture 8086, améliorée successivement jusqu’au 286 (un processeur 16 bits).
Au milieu des années 80, Intel améliore cette architecture qui devient 32 bits (avec les dénominations commerciales 386 puis 486, Pentium, Pentium II, etc.), nommée i386 par Debian, communément appelée x86. Cette architecture est aussi parfois nommée ia32 pour « Intel Architecture 32 bits ». D’autres constructeurs de processeurs comme AMD ou Cyrix concevaient des processeurs compatibles. C’est donc cette même architecture (i386) qui devait être utilisée pour ces processeurs.

Autocollant Intel Pentium 4 (32 bits) comme on en trouvait collé sur des ordinateurs portables au début des années 2000

Puis Intel décida de faire un nouveau processeur, 64 bits, incompatible avec les x86. Associé à HP, une nouvelle gamme de processeur, Itanium, voit le jour en 2001. La dénomination Debian est donc ia64 (« Intel Architecture 64 bits »). C’est un échec commercial, dû à des performances décevantes et l’absence de compatibilité ascendante. Cette gamme sera arrêtée dans l’indifférence générale en 2013.

Parallèlement à Intel, AMD décide d’étendre le processeur x86 pour qu’il fonctionne en 64 bits tout en ayant une compatibilité 32 bits. Cette architecture est souvent appelée x86_64, parfois x64. En 2003, AMD vend l’Athlon 64, premier processeur disponible au public de cette nouvelle architecture. Debian la désigne par le terme amd64. Des accords entre AMD et Intel permettant aussi à Intel de produire cette architecture, Intel a emboîté le pas à AMD et produit aussi des processeurs compatibles amd64. C’est pourquoi les processeurs modernes Intel nécessitent cette architecture lors de l’installation d’un système Debian.

Bien plus récent que le Pentium4, c’est un processeur 64 bits. Les autocollants, c’est bien joli mais pas très informatif.

D’autres architectures moins connues voire complètement oubliées existent

Debian est installable sur de nombreuses autres architectures, mais qui ne sont pas orientées grand public. La seule exception étant peut-être ARM avec les cartes RaspberryPi (cf. wiki).

Des exemples d’autres architectures et processeurs associés : https://lists.debian.org/debian-www/2017/10/msg00125.html (à la toute fin du message)

08 January, 2019 09:10PM by ascendances

December 22, 2018

hackergotchi for Charles Plessy

Charles Plessy

De l'utilité des paquets R dans Debian

Debian distribue le logiciel R pour faire des analyses statistiques, de la fouille de données, de la bioinformatique et d'autres tâches. Gravitant autour de R, existent des centaines de paquets de fonctions, principalement distribués par CRAN et Bioconductor, qui font toute la richesse de l'écosystème R. Debian redistribue certains de ces paquets au format Debian. Comme dans tous les cas similaires de « redistribution de distribution », il existe une tension entre les objectifs de Debian pour sa version stable et les attentes de nouveauté pour les utilisateurs (pour partie liés au cycle de développement de 6 mois de R), et l'on se demande parfois pourquoi utiliser les paquets Debian au lieu d'utiliser le directement le gestionnaire de paquet amont.

Aujourd'hui, après avoir installé un système minimal dans un conteneur « schroot », j'ai installé un paquet R et toutes ses dépendances nativement, c'est à dire en téléchargeant les sources via la ligne de commande de R, ce qui m'a fait poireauter 90 minutes le temps que tout compile, alors que les paquets R redistribués par Debian sont déjà pré-compilés. 90 minutes de compilation pour 10 minutes de travail; 90 minutes de compilation que j'aurais pu remplacer par quelques minutes avec quelques « apt install » bien placés. Merci à tout ceux qui maintiennent ces paquets R dans Debian !

22 December, 2018 12:02AM

October 27, 2018

hackergotchi for Vincent Bernat

Vincent Bernat

Haute densité (HiDPI) avec deux écrans 4K sous Linux

J’utilise un portable Lenovo Thinkpad X1 Carbon (210 PPP) depuis quatre ans ainsi qu’un téléphone Nokia 8 (550 PPP) depuis un an. J’apprécie la haute densité de leurs écrans respectifs : le rendu du texte est excellent. Pour obtenir des résultats similaires avec ma station de travail, j’ai acheté une paire d’écrans Dell P2415Q :

Deux Dell P2415Q
Configuration en écrans doubles avec deux moniteurs Dell P2415Q

Écrans

Le Dell P2415Q est un écran 24” doté d’un panneau IPS d’une résolution de 3840×2160 (185 PPP) et une couverture complète de l’espace de couleurs sRGB. Il est sorti en 2015 et son prix est désormais sous la barre des 400 €. Il a reçu des critiques positives.

L’une des unités est arrivé avec un pixel mort. Je pensais qu’il s’agissait d’un problème du passé, mais la politique de Dell concernant les pixels morts stipule :

Lors du processus de fabrication des écrans LCD, un ou plusieurs pixels se figent parfois dans un état immuable. Un écran comportant de 1 à 5 sous-pixels figés est considéré comme normal et conforme aux normes industrielles.

Mise à jour (12.2018)

Trois nouveaux pixels morts sont apparus. Aussi, je vous recommande d’éviter ces écrans.

Un deuxième problème est la présence de lignes grises horizontales (difficilement) visibles sur fond blanc. Le problème ne semble pas être rare, mais Dell est peu enthousiaste à ce sujet. Si je m’assois correctement, les lignes deviennent invisibles.

Je suis un peu déçu par ces aspects, mais je pense qu’ils restent supportables et que c’est l’occasion de corriger mon obsession pour ces détails.

Carte graphique

Pour piloter un écran 4K à 60 Hz, il faut au moins un connecteur HDMI 2.0 ou DisplayPort 1.2. Le Dell P2415Q a été mis à niveau vers HDMI 2.0 en 2016 et dispose également d’une entrée DP 1.2. Il y a un port pour chaîner un second écran, mais en l’absence de prise en charge de DP 1.3, le taux de rafraîchissement tomberait à 30 Hz.

Il n’y a actuellement aucune carte Radeon disponible autour de 100 € et capable de piloter deux écrans 4K. Côté Nvidia, la GeForce GT 1030 convient avec une consommation de 20 W pour la version DDR4. J’ai opté pour un modèle à refroidissement passif de MSI. Sous Linux, le résultat est assez décevant :

  • Le pilote nouveau n’a encore qu’une prise en charge rudimentaire pour cette génération de puces Nvidia. Le résultat est excessivement lent et le port HDMI 2.0 n’est pas géré correctement.

  • Le pilote propriétaire Nvidia présente d’importants problèmes de performance. Il est difficile de savoir si ceci est dû à la carte elle-même1 ou aux pilotes. J’ai testé les versions 390, 396, 410, 415 et 418 sans grand changements. De plus, la suspension en mémoire ne fonctionne pas.

Mise à jour (05.2019)

J’ai finalement opté pour une ASUS Phoenix Radeon RX 550. Avec une telle carte, tout tourne comme une horloge en utilisant le pilote libre amdgpu. La carte est équipée d’un ventilateur mais il est possible de contrôler sa vitesse. Le wiki de ArchLinux contient davantage de détails. En mode automatique, lorsque /sys/class/drm/card0/device/hwmon/hwmon1/pwm1_enable est placé à 2, il tourne à 1050 tours par minute :

$ sensors amdgpu-pci-0100
amdgpu-pci-0100
Adapter: PCI adapter
vddgfx:       +0.88 V
fan1:        1047 RPM
temp1:        +51.0°C  (crit = +94.0°C, hyst = -273.1°C)
power1:       17.20 W  (cap =  35.00 W)

Prise en charge de la haute densité avec X11

Gnome et KDE prennent désormais en charge les affichages à haute densité (HiDPI) sans configuration particulière sous X11. Pour les autres environnements, le paramétrage est assez simple, grâce à xsettingsd. Le code suivant doit être invoqué à partir de ~/.xsession ou lorsque la densité change :

# Densité cible
dpi=192

# Pour les applications supportant XSettings, `Xft/DPI' indique
# l'échelle pour les fontes (et parfois pour le reste de l'interface),
# `Gdk/WindowScalingFactor' indique l'échelle pour l'interface avec
# GTK 3 et `Gdk/UnscaledDPI' annule l'échelle choisie pour les fontes
# pour les applications GTK 3.
> ~/.xsettingsd cat <<EOF
Xft/DPI $(( $dpi*1024 ))
Gdk/WindowScalingFactor $(( $dpi/96 ))
Gdk/UnscaledDPI $(( $dpi*1024/($dpi/96) ))
EOF
pkill -HUP xsettingsd || xsettingsd &

# Pour les applications QT.
export QT_AUTO_SCREEN_SCALE_FACTOR=1

# Pour certaines autres applications.
echo Xft.dpi: $dpi | xrdb -merge

Ensuite, c’est à chaque application de savoir comment effectuer le rendu à la densité choisie. Le tableau ci-dessous donne un aperçu de la prise en charge pour certaines d’entre elles, en utilisant les paramètres ci-dessus. « Échelle du texte » indique si une application est capable d’adapter la taille du texte. C’est généralement la fonctionnalité la plus essentielle. « Échelle de l’interface » indique si elle est capable de mettre à l’échelle l’ensemble de l’interface, y compris les icônes. Idéalement, les applications devraient également être en mesure de changer dynamiquement leurs paramètres lorsqu’elles sont notifiées via XSettings, ce qui est utile lors du passage sur un écran externe.

Application Échelle du texte Échelle de l’interface Sans redémarrer ?
Applications QT 5 ✔️ ✔️ ✔️
Chromium2 ✔️ ✔️ ✔️
Applications Electron4 ✔️ ✔️ ✔️
Firefox3 (GTK 3) ✔️ ✔️ ✔️
Blender5 ✔️ ✔️
Emacs 26.1 (GTK 3) ✔️ 😐 ✔️
Terminaux VTE (GTK 3) ✔️ 😐 ✔️
Applications GTK 3 ✔️ 😐 ✔️
Gimp (GTK 2) ✔️ ✔️
Inkscape (GTK 2) ✔️ ✔️
Applications GTK 2 ✔️ ✔️
Applications Java6 🙄 🙄
xterm and rxvt (avec Xft) ✔️ n/a
Autres applications

Les applications QT 5 offrent une excellente prise en charge. Les applications GTK 3 ne peuvent utiliser qu’un coefficient multiplicateur entier pour mettre à l’échelle leurs interfaces, ce qui est ennuyeux quand on a besoin d’un facteur 1.5×. Les applications GTK 2 ne savent adapter que la taille du texte. Elles sont toujours assez nombreuses, avec notamment Gimp. Pour plus de détails, jetez un œil sur la page dédiée au sujet sur ArchWiki. Au-delà de X11, Wayland permet d’utiliser une densité différente pour chaque écran et de mettre à l’échelle les applications qui ne savent pas prendre en charge les densités élevées.

En conclusion, la situation actuelle dépend énormément des applications utilisées. Mes principales applications étant Firefox, Emacs et un terminal basé sur VTE, le résultat me satisfait.


  1. Par rapport à ma configuration précédente, le nombre de pixels est quadruplé. La carte utilise 4 voies sur PCI 3.0, ce qui correspond à une bande passante de 25 Gbits/s. Cela permet à peine le transfert de 7680×2160 pixels à 60 Hz en 24 bits. De plus, l’utilisation de mémoire DDR4 plutôt que GDDR5 est considéré comme une très mauvaise option↩︎

  2. Pour détecter les changements, Chromium surveille les évènements RandR. Ils peuvent être capturés avant d’avoir pu mettre à jour les variables XSettings↩︎

  3. Firefox surveille Gdk/WindowScalingFactor (qui est un entier), mais il sait adapter son interface à la valeur de Xft/DPI. Il a besoin d’un redémarrage pour prendre en compte le changement si la première valeur ne bouge pas. Voir le bug #1554850↩︎

  4. Si cela ne fonctionne pas, essayez avec le drapeau --force-device-scale-factor=2↩︎

  5. Blender se base sur la valeur de la ressource Xft.dpi↩︎

  6. Les applications Java doivent être invoquées avec la variable d’environnement GDK_SCALE=2, sans quoi, aucune mise à l’échelle n’est effectuée. ↩︎

27 October, 2018 09:34PM by Vincent Bernat

October 16, 2018

Didier Raboud

Raksha – Une idée

J’étais donc ce week-end en cours CG (responsables de groupes) pour l’ASVd à Froideville. Je tombe sur une conversation entre Chat et Pélican au sujet du lancement d’une commission IT au niveau cantonal pour fournir des services aux groupes du canton.

On continue la discussion, qui embraie rapidement sur un échange d’idées sur Framasoft, MiData (db.scout.ch) et les différentes initiatives pour fournir des services IT aux groupes scouts du canton.

Pour un petit historique, il y’a déjà eu plusieurs initiatives dans ce sens, mais actuellement, je n’ai pas connaissance d’équipes actives ou fonctionnelles pour ça:

  • Pour l’ASVd:
    • un bénévole s’occupe des services cloud (NextCloud), email, listes et site Internet (WordPress).
    • des groupes DropBox continuent d’exister.
  • Pour les groupes:
    • rien de centralisé, mais différentes initiatives isolées naîssent et meurent (Trello, Mattermost, etc)

Bref. La discussion a finalement tourné autour des idées suivantes:

  • Un service scout
  • S’inspirer de ce que fait Framasoft et les collectifs Chatons: décentraliser les services et reprendre le contrôle!
  • Commencer petit; proposer quelque chose de spécifique aux scouts suisses, voir même scouts vaudois pour commencer.
  • Tirer profit du bénévolat, mais couvrir tous les frais
  • Offrir des services « collectifs » (une instance cloud par canton) et « spécifiques » (une instance Mattermost par groupe)
  • Avoir des ambitions techniques élevées:
    • uniquement du logiciel libre
    • automatisation des processus
    • confiance dans les données (backup)
    • monitoring des services
    • intégrations qui font sens
    • authentification unifiée
    • reproductibilité du projet

Tout ça est évidemment à discuter, clarifier, raffiner, prioriser avec les premiers intéressés. Mais… Je cherchais un nom, en rapport autant avec le champ lexical des chats (Chatons) et du scoutisme. J’avais d’abord pensé à « gamelle », qui me plaisait bien, mais tous les `.ch` étaient pris. « Veillée », vraiment bien, et veillée.ch est libre; mais il y’aurait confusion avec le même nom sans accent. ☹

En feuilletant mon Livre de la Jungle de poche (non, non, en vrai: https://fr.wikipedia.org/wiki/Le_Livre_de_la_jungle#Les_animaux ), j’ai commencé à parcourir les différents animaux de l’histoire en testant leur disponibilité en .ch . Et c’est là que Mère Louve; Raksha, est apparue libre!

Raksha : la louve grise, également appelée Mère-Louve ou La démone, mère adoptive de Mowgli. Elle le défend lorsque Shere-Khan le réclame à l’entrée de sa tanière.

C’est plutôt un bon nom: les scouts avec une âme de louveteaux reconnaîtront le nom immédiatement, et c’est également un animal qui a des petits par portées, avec un aspect de défense des intérêts des scouts, et un aspect de collectif. Des chatons au louveteaux, on n’est pas très loin!

Bref. On doit se voir pour en discuter!

16 October, 2018 08:15AM by OdyX

September 27, 2018

Stéphane Blondon

Accéder à une console lorsque gdm plante

S’il est impossible d’avoir un terminal en appuyant simultanément sur ctrl+alt+F6 , il est possible de paramétrer Grub pour démarrer Linux avec un environnement multi-utilisateur mais sans interface graphique (runlevel 3) :

Lorsque le menu de Grub s’affiche, appuyer sur e pour modifier temporairement la configuration.
Puis ajouter 3 à la fin de la ligne :
linux /boot/vmlinuz-… root=UUID=12345678-… ro quiet 3
Puis appuyer sur la/les touches indiquées par Grub pour exécuter cette entrée.

J’ai trouvé plusieurs explications indiquant d’utiliser text à la place de 3 mais ça ne fonctionne pas avec la version avec laquelle j’ai subi ce problème (2.02+dfsg1-6).

La solution vient de https://superuser.com/a/974809, possibilité 5.

…Et Grub était innocent : c’était un problème de paquets mis-à-jour mais non configurés.

27 September, 2018 06:39AM by ascendances

September 23, 2018

hackergotchi for Charles Plessy

Charles Plessy

J'ai déménagé à Okinawa !

J'ai déménagé avec ma famille à Okinawa depuis août, dans le quartier d'Akano, ville d'Uruma. Nous sommes arrivés à temps pour vois plusieurs eisaa, des danses traditionnelles faisant usage d'un grand nombre de tambours, ayant souvent lieu vers la fin de mois d'août. Chaque quartier a sa propre troupe et nous espérons pouvoir nous y joindre pour l'année prochaine.

Nous habitons dans un immeuble avec une connexion en fibre optique partagée. Bon ping vers la métropole, mais le débit pour les gros téléchargements est catastrophique le soir quand toutes les familles sont connectées en même temps. Impossible de réussir un simple sbuild-update -dragu unstable, alors je n'ai malheureusement pas réussi à contribuer qui que ce soit à Debian. C'est frustrant mais il y a peut-être des solutions à chercher du côté de notre forge GitLab.

Côté travail, j'ai rejoint l'université Okinawa Institute of Science and Technology OIST. C'est un endroit formidable, ouvert au public même le week-end (notez les horaires du café). Si vous venez le visiter, faites-moi signe !

23 September, 2018 12:33PM

August 22, 2018

Imprimer avec Brother sur Debian

J'ai tourné en rond pendant plus d'une heure, avant de finir par comprendre qu'il faut aussi installer le paquet lib32stdc++6 quand on utilise les pilotes Brother (imprimante HL-L2365DW) sur un système amd64, puisqu'ils sont fournis sous la forme de paquets i386. Pourtant il y a plus d'une piste dans les instructions en ligne. Le plus difficile était que sans lib32stdc++6, tout semble se passer parfaitement sauf que rien ne sort de l'imprimante.

22 August, 2018 12:41PM

June 01, 2018

Stéphane Blondon

Installer Matomo sur Debian 9

Imaginons qu’Airgan, une plateforme communautaire payante de location et de réservation d’organes, veuille améliorer le suivi des visites sur son site web. Matomo est une réponse possible à ce besoin.

Matomo, anciennement Piwik, est un service web pour collecter des statistiques de visites. L’entreprise propose une version libre, auto-hébergeable et une version hébergée uniquement par Matomo qui inclut des fonctions non disponibles dans la version libre.

Matomo fournit un fichier .deb, permettant d’installer le service facilement sur une machine Debian. Cet article présente quelques éléments à prendre en compte.

Le changement de nom de Piwik à Matomo date de Janvier 2018. Tout n’a pas été transféré et la documentation ou les variables laissent parfois encore apparaître l’ancien nom.

Installation du paquet piwik

Le paquet n’est pas inclus dans la distribution mais est fourni dans un dépôt tiers géré par Matomo.
La documentation pour installer le paquet fourni par Matomo est disponible à http://debian.piwik.org/. Il suffit de la suivre.

Installation du paquet php-mbstring

Le fonctionnement du service nécessite que le paquet php-mbstring soit installé. Si ce n’est pas le cas, une erreur lors de la configuration de Matomo (dans quelques étapes, patientez !) sera affichée :

Capture d'écran de l'erreur

Une pull-request sur Github a été faite pour ajouter php-mbstring aux dépendances. Cette étape ne sera peut-être plus nécessaire dans la prochaine version ?

Configuration du service web

Le paquet ne dépend pas d’un serveur web en particulier. Le code d’example suivant suppose que c’est Apache2 qui est installé. N’importe quel autre serveur web fonctionnerait aussi.

<VirtualHost 19.84.19.84:80>
    ServerName matomo.airgan.tld

    # ce sera bien pratique quand on aura des problèmes
    ErrorLog /srv/airgan/logs/matomo-http-error.log
    CustomLog /srv/airgan/logs/matomo-http-access.log combined
    LogLevel info

    # les deux lignes importantes
    DocumentRoot /usr/share/piwik
    DirectoryIndex index.php
</VirtualHost>

Ensuite, il faut activer le virtualhost :
sudo a2ensite matomo.conf
sudo systemctl reload apache2

Ajouter un utilisateur pour la base de données

Un serveur de base de données MySQL ou MariaDB doit être installé. Ensuite, il faut se connecter sur ce serveur pour créer un utilisateur qui pourra créer la base de données et les tables nécessaires lors de la configuration de Matomo (c’est juste après cette étape, vous avez bien fait de patienter !).

#Créer un utilisateur nommé matomo :
CREATE USER matomo@'localhost';
SET PASSWORD FOR matomo@'localhost' = PASSWORD('secret');
#Lui donner les droits pour créer la base de données nécessaire au service :
GRANT CREATE, ALTER, SELECT, INSERT, UPDATE, DELETE, DROP, CREATE TEMPORARY TABLES on *.* to matomo@'localhost';

Configurer le service Matomo

Avec un navigateur web, allez sur le domaine paramétré dans la configuration du serveur web (matomo.airgan.tld dans notre exemple). Il suffit de suivre les étapes de l’interface pour finir l’installation. Elle correspond à l’étape « The 5-minute Matomo Installation » sur https://matomo.org/docs/installation/.

Une fois cette étape terminée, l’installtion est terminée et aller sur le domaine permet de voir l’interface de connexion pour accéder aux statistiques de visite.

Versions utilisées

L’installation ayant servie à écrire l’article a été faite sur
Debian GNU/Linux 9.3 (stretch) avec les versions suivantes des paquets :

apache2
2.4.25-3+deb9u4
mariadb-server
10.1.26-0+deb9u1
piwik
3.2.1-1

Dans le futur, il est possible que la livraison des organes se fasse à vélo. À étudier dans un prochain business plan.

01 June, 2018 03:51PM by ascendances

May 22, 2018

Olivier Berger (pro)

Recrutement ingénieur·e DevOps pour conteneurs de Travaux Pratiques en informatique/réseaux

MAJ : nous avons trouvé le candidat. Le poste n’est plus disponible.

Nous recrutons un·e ingénieur·e en informatique pour travailler à l’application des concepts et technologies DevOps (conteneurs Docker, Git, Linux, libre, …) pour la mise au point et l’hébergement de dispositifs de Travaux Pratiques virtualisés, qui seront utilisés pour des enseignements d’informatique et de réseaux, sur un CDD de 1 an, à Télécom SudParis, à Évry (91).

Pour en savoir plus, voir le descriptif du poste que j’ai mis en ligne.

22 May, 2018 07:25AM by Olivier Berger

May 18, 2018

Prochaine conférence MiNET sur les systèmes d’exploitation 24/05 Évry (France)

La prochaine conférence MiNET, le 24/05/2018 après-midi, promet d’être très intéressante sur le sujet des systèmes d’exploitation, avec 4 intervenants pointus :

  • Julia Lawall : “Introduction to Coccinelle and its usage in the Linux Kernel
  • Sebastien Valat : “Memory management and OS paging for high performance computing
  • Pierre Pronchery : “DeforaOS: Un voyage dans le développement de système d’exploitation
  • Cyril Brulebois : “Maintenir et développer la distribution Debian

Plus de détails sur https://conference.minet.net/#conf2018

N’hésitez pas à nous rejoindre à Évry pour participer à cette conférence, ou à suivre la retransmission sur la chaîne Youtube de MiNET.

 

 

18 May, 2018 08:06AM by Olivier Berger

April 17, 2018

Florent Gallaire

Lamby 2.0 : Chris Lamb réélu DPL pour 2018

Chris Lamb (Lamby) vient d’être réélu Debian Project Leader (DPL). Il va donc pouvoir continuer le travail commencé l’année dernière, et vous pouvez lire sa réaction sur son blog.

Ce n’est bien sûr pas une surprise puisque Chris était le seul candidat, et qu’il n’y avait aucune raison valable de lui préférer None Of The Above et ainsi de provoquer de nouvelles élections. Voici une représentation du résultat du scrutin qui utilise la méthode Condorcet :

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

17 April, 2018 08:51AM by fgallaire

March 15, 2018

Quel DPL pour 2018 ?

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

La question de la légitimité d’un scrutin avec un seul candidat, posée en 2016 par Paul Wise lorsque Mehdi Dogguy fut seul à se présenter, est malheureusement à nouveau d’actualité. En effet, seul le DPL sortant s’est porté candidat cette année :

Et force est de constater que les candidats ne se bousculent encore et toujours pas au portillon pour devenir DPL. Peu de développeurs semblent motivés par cette charge comme l’exprimait déjà Lars Wirzenius il y a deux ans :

After some serious thinking, I’ve decided not to nominate myself in the Debian project leader elections for 2016. […] Why not run? I don’t think I want to deal with the stress. I already have more than enough stress in my life, from work.

En plus de son rôle de développeur Debian et de DPL 2017, 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 1er au 14 avril lors d’un vote utilisant la méthode Condorcet car, même en l’absence d’autres candidats, Chris Lamb reste en concurrence avec le choix None Of The Above.

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

15 March, 2018 06:18PM by fgallaire

December 01, 2017

Olivier Berger (pro)

Conférence sur SoftwareHeritage par Roberto Di Cosmo

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

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

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

01 December, 2017 12:05PM by Olivier Berger

November 08, 2017

Stéphane Blondon

Ignorer des fichiers, de ack à ag

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

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

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

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

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

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

devient
$ cat .ignore
riri
fifi/
loulou

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

Testé avec les versions suivantes :

ack version 2.12 et 2.18
ag version 0.19.2 et 2.1.0

08 November, 2017 01:44PM by ascendances

April 21, 2017

hackergotchi for Rapha&#235;l Hertzog

Raphaël Hertzog

Le logiciel libre a t’il une couleur politique ?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

April 16, 2017

Florent Gallaire

Chris Lamb élu DPL pour 2017

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

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

Vote DPL 2017

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

16 April, 2017 12:39AM by fgallaire

February 23, 2017

Stéphane Blondon

Frise chronologique des distributions Debian

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

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

23 February, 2017 04:47PM by ascendances

February 13, 2017

hackergotchi for Rapha&#235;l Hertzog

Raphaël Hertzog

Mes activités libres en janvier 2017

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

Debian LTS

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

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

Empaquetage Debian

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

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

Travaux divers

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

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

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

Merci

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

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

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

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

February 02, 2017

Élections présidentielles, logiciel libre et Charlotte Marchandise

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

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

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

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

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

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

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

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

January 14, 2017

Mes activités libres en décembre 2016

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

Debian LTS

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

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

Empaquetages divers

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

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

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

Travaux Debian divers

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

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

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

Distro Tracker

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

Travaux divers

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

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

Merci

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

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

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

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

December 11, 2016

Mes activités libres en novembre 2016

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

Debian LTS

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

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

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

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

Travaux concernant pkg-security

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

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

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

Travaux Debian divers

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

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

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

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

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

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

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

Merci

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

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

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

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

November 23, 2016

hackergotchi for Tanguy Ortolo

Tanguy Ortolo

Interdit ou autorisé ?

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

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

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

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

23 November, 2016 04:56PM by Tanguy

November 19, 2016

hackergotchi for J. Fernando Lagrange

J. Fernando Lagrange

Debian Stretch et Dell Latitude E6520: installation

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

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

Ma démarche pour installer Stretch

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

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

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

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

En trois étapes:

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

« Options » choisies pendant l’installation

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

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

Changer les sources de paquets

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

# 

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

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

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

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

Mettre à jour vers Debian 9 Stretch testing

En trois étapes:

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

Note:

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

Et voilà !

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

19 November, 2016 11:44AM by Low Memory

October 29, 2016

Certificats Let’s Encrypt ! avec certbot

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

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

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

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

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

Préambule: installation

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

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

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

Puis lancé les commandes suivantes:

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

Créer de nouveaux certificats (pour nginx)

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

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

Créer le certificat

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

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

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

root@server ~# systemctl start nginx.service

Configuration de nginx

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

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

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

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

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

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

    ssl_prefer_server_ciphers on;

    ssl_dhparam /etc/nginx/dhparams.pem;

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

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


}

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

Mise à jour du certificat

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

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

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

Récapitulatifs

Mise en place du certificat pour nginx

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

Renouvellement du(des) certificat(s)

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

29 October, 2016 06:36PM by Low Memory

August 17, 2016

hackergotchi for Tanguy Ortolo

Tanguy Ortolo

Aux concepteurs de voies cyclables

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

Route avec une chicane à angle droit !

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

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

Piste cyclable avec une chicane à angle droit !

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

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

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

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

17 August, 2016 10:16AM by Tanguy

August 10, 2016

hackergotchi for J. Fernando Lagrange

J. Fernando Lagrange

Renouvellement de certificats LetsEncrypt avec systemd

Qu'est-ce que c'est donc ?

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

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

Comment on fait ?

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

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

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

1. Copier certbot sur le serveur

Je le copie dans le dossier /opt du serveur:

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

2. Créer le script pour utiliser certbot

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

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

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

3. Créer le service systemd

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

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

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

4. Créer la minuterie systemd

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

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

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

[Install]
WantedBy=timers.target
EOF

 

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

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

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

 

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

Documentation, ressources:

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

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

 

10 August, 2016 09:02PM by Low Memory

June 28, 2016

hackergotchi for Tanguy Ortolo

Tanguy Ortolo

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

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

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

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

Logo UltraViolet

Étape 1, Warner Bros

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

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

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

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

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

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

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

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

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

Étape 3, ripper son DVD

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

28 June, 2016 11:34AM by Tanguy

June 17, 2016

hackergotchi for J. Fernando Lagrange

J. Fernando Lagrange

La brique en voyage

La situation

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

Le problème

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

La solution

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

 

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

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

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

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

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

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

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

Deuxième problème

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

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

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

Deuxième solution

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

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

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

 

17 June, 2016 09:13AM by Low Memory

April 28, 2016

hackergotchi for Tanguy Ortolo

Tanguy Ortolo

Pour des cartes restaurant anonymes

Contexte

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

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

C'est possible

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

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

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

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

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

28 April, 2016 05:47PM by Tanguy

April 25, 2016

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

Parking Méditerranée

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

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

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

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

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

Théoriquement, un accès vélo

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

De surprise en surprise

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

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

Un parking hostile aux vélos

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

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

25 April, 2016 05:01PM by Tanguy

April 11, 2016

Carl Chenet

Richard Stallman ce samedi à Choisy-le-roi

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

saint-stallman

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

Peut-être à samedi donc 😉

11 April, 2016 06:53AM by Carl Chenet

April 07, 2016

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

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

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

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

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

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

Les communautés techniques

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

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

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

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

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

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

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

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

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

GPL contre BSD/MIT

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

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

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

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

bsdvsgpl

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

Des communautés constituent le Logiciel Libre

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

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

trollLes trolls, une activité prisée des Libristes

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

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

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

07 April, 2016 10:00PM by Carl Chenet

April 03, 2016

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

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

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

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

forum-small

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

banieres linux vert

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

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

Quelques liens pour finir :

03 April, 2016 10:00PM by Carl Chenet

March 31, 2016

Le danger Github (revu et augmenté)

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

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

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

codercatL’octocat, mascotte de Github

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

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

1. Points critiques

1.1 La centralisation

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

github-logo

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

1.2 Un logiciel privateur

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

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

1.3 L’uniformisation

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

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

2. Validité des points critiques

2.1 Les critiques de la centralisation

2.1.1 Taux de disponibilité du service

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

githubdown

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

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

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

2.2 Un peu de recul historique : SourceForge

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

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

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

 

2.3 Les critiques relatives à utiliser un logiciel privateur

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

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

 

bsdvsgpl

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

gplv3

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

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

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

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

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

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

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

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

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

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

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

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

 

2.4 L’uniformisation

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

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

git-logo

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

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

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

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

 

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

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

gitlabLogo de Gitlab, une alternative possible à Github

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

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

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

Texte sous licence Creative Commons CC BY-ND 3.0 FR

31 March, 2016 09:00PM by Carl Chenet

March 28, 2016

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

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

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

L’affaire npmgate

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

Npm-logo

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

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

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

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

sourceforge-logo

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

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

github-logo

Le danger de l’acteur non-communautaire

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

microsoft-free.png

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

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

28 March, 2016 09:00PM by Carl Chenet

March 17, 2016

hackergotchi for Aur&#233;lien Jarno

Aurélien Jarno

(Pseudo-)virtualizing Intel USB controllers

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

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

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

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

explain EHCI/OHCI/XHCI

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

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

add table

Add warning

17 March, 2016 04:34PM by aurel32

February 23, 2016

10 years ago…

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

Still it seems to me like yesterday.

23 February, 2016 09:43PM by aurel32

May 19, 2015

Olivier Berger (pro)

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

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

Les transparents de Nicolas sont disponibles sur son site.

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

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

Voici quelques photos :




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

19 May, 2015 02:52PM by Olivier Berger

May 13, 2015

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

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

On a pensé à vous, avec MiNET.

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

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

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

13 May, 2015 01:23PM by Olivier Berger

April 11, 2015

hackergotchi for Roland Mas

Roland Mas

Le marronnier du printemps

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

Et qui le porte bien, merci.

11 April, 2015 05:30PM

December 10, 2014

Olivier Berger (perso)

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

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

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

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

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

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

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

10 December, 2014 10:10PM by obergix

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

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

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

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

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

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

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

10 December, 2014 10:10PM by Olivier Berger

August 20, 2014

hackergotchi for Aur&#233;lien Jarno

Aurélien Jarno

MIPS Creator CI20

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

mips-ci20

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

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

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

20 August, 2014 08:52PM by aurel32

August 15, 2014

Intel about to disable TSX instructions?

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

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

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

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

And later on page 51:

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

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

15 August, 2014 04:02PM by aurel32

June 18, 2014

Debian is switching (back) to GLIBC

Five years ago Debian and most derivatives switched from the standard GNU C Library (GLIBC) to the Embedded GLIBC (EGLIBC). Debian is now about to take the reverse way switching back to GLIBC, as EGLIBC is now a dead project, the last release being the 2.19 one. At the time of writing the glibc package has been uploaded to experimental and sits in the NEW queue.

EGLIBC is dead for a good reason: the GLIBC development has changed a lot in the recent years, due to two major events: Ulrich Drepper leaving Red Hat and the GLIBC development, and the GLIBC steering committe self-dissolving. This has resulted in a much more friendly development based on team work with good cooperation. The development is now based on peer review, which results in less buggy code (humans do make mistakes). It has also resulted in things that were clearly impossible before, like using the same repository for all architectures, and even getting rid of the ports/ directory. Before we used to have two sets of architectures, the main ones in the glibc repository with architectures like x86, SuperH or SPARC, and the secondary ones in the glibc-ports repository with architectures like ARM or MIPS. As you can see the separation was quite arbitrary, and often leaded to missing changes on the secondary architectures. We also got real stable branches, with regular fixes.

The most important EGLIBC features have been merged to GLIBC, including for example the use of non-bash but POSIX shell, or the renaming of reserved keywords. The notable exception is the support for configurable components, which we originally planned to use for Debian-Installer, by building a smaller flavor using -Os and without NIS and RPC support. At the end we never worked on that, and it seems that the hardware targeted by Debian has grown faster than the GLIBC size, so that is not really a big loss. At the end, we ended up with only 5 missing patches from the EGLIBC tree:

The package names are unchanged (except the source package and the binary package containing the sources) so the transition is fully transparent for the users.

I would like to thank all the CodeSourcery employees who worked on EGLIBC, with a special thank to Joseph Myers who spent countless hours to merge the most important EGLIBC changes back to GLIBC, and sent regular emails about the merge status. I would also like to thanks all the people on the GLIBC side that made the change to happen, and all persons participating in the GLIBC development.

18 June, 2014 08:04PM by aurel32

April 11, 2014

hackergotchi for Roland Mas

Roland Mas

Une page de publicité

Allez, c'est vendredi, c'est permis, je vais m'autoriser deux petites annonces.

Premièrement : rappelez-vous Minami Taiko, ce groupe de tambours japonais du sud de la France. Bon, nous on est des amateurs, mais il se trouve qu'on fait venir, pour le festival Escale à Sète, un vrai groupe de taikos du Japon et tout. Ils s'appellent SEN, et ils vont faire quelques animations musicales dans Sète du 18 au 21 avril. Et avant de repartir dans leur lointain Cipango, ils feront un vrai concert à Montpellier, le mardi 22 avril au soir, sur le campus de l'INRA/Supagro. Et devinez qui fait la première partie ? Minami Taiko, voilà qui ! Donc si vous voulez découvrir le taiko ou voir quelques amateurs suivis d'un vrai groupe, faites donc un tour sur le site de Minami Taiko. À noter qu'il y a aussi un atelier d'initiation le même jour si ça vous intéresse.

Deuxièmement : je suis fier de vous présenter un petit site web que c'est moi qui l'ai fait avec mes petits doigts délicats. Ça s'appelle Chacun sa part, et ça sert à faire des comptes entre amis, genre quand on part en vacances ensemble, ou qu'on fait régulièrement des dépenses partagées dans un groupe de gens. Pour éviter des comptes d'apothicaire à chaque restau, chaque tournée au bar, chaque passage en caisse, on saisit la dépense sur le site, on dit qui a payé et qui a participé, et le site calcule automatiquement les soldes de chacun et propose des suggestions de remboursements pour rééquilibrer les comptes. Y'a un système d'invitations pour que chacun puisse consulter l'état du groupe et saisir des dépenses, des QR-codes pour faciliter la vie aux utilisateurs de smartphone, et même si ça n'a pas encore été testé à grande échelle ça a été validé par une poignée de testeurs dans différentes configurations. Allez-y, c'est cadeau. Chacun sa part. Point com.

11 April, 2014 08:06AM