L'introduction reste générale, objective, et pose les contraintes, la première partie expose la solution choisie, et la deuxième partie aborde la mise en œuvre.

Comme tout ingénieur système sain d'esprit, j'aime bien les infrastructures qui ont de la gueule. Par là, j'entends une infra qui soit à l'épreuve de trois fléaux :

• Le temps : Les pannes étant choses fréquentes dans le métier, les différents éléments de l'infrastructure, tant matériels que stratégiques, doivent pouvoir être facilement et indépendamment ajoutés, remplacés ou améliorés.
• L'incompétence : Les opérateurs étant des êtres humains plus ou moins aguerris, le fonctionnement de l'infrastructure doit être le plus simple possible et sa maintenance doit réduire au maximum les risques d'erreurs de couche 8.
• L'utilisation : Personne ne doit être en mesure d'utiliser l'infrastructure d'une façon ou dans un objectif non désiré par ses concepteurs. C'est valable pour certains utilisateurs finaux qui tenteraient d'exploiter votre œuvre dans un but malveillant, aussi bien que d'éventuels changements d'équipe qui ne comprend rien à rien (cf. les dangers de l'incompétence).

Risques de Corona

J'aurais pu aussi préciser que votre infrastructure doit également être à l'épreuve du coronavirus, mais pas grand risque de ce côté là, quoiqu'il ne faille pas confondre avec la bière Corona, qui, si renversée négligemment sur un serveur, peux infliger des dégâts regrettables.

Concrètement, dans le cadre d'un cluster de virtualisation, ça se traduit par quelques maximes de bon sens :

• On fait en sorte qu'une VM puisse être exécutée sur n'importe quel hyperviseur.
• N'importe quel opérateur doit être en mesure d'effectuer des opérations de base (et de comprendre ce qu'il fait) sans corrompre le schmilblick, à toute heure du jour ou de la nuit, à n'importe quel niveau de sobriété, et s'il est dans l'incapacité physique, il doit pouvoir les expliquer à quelqu'un qui a un clavier et qui tient debout.
• La symphonie technologique (terme pompeux de mon cru pour désigner les différentes technos qui collaborent, s'imbriquent et virevoltent avec grâce au grand bal des services) doit s'articuler autour de technos et protocoles indépendants, remplaçables, robustes et s'appuyant les uns sur les autres.

Que de belles résolutions en ce début d'année, c'est touchant. Alors pour retomber sur terre, on va parler du problème épineux de l'unicité des instances de VM.

Et bien oui, le problème se pose, car dans un cluster, on partage un certain nombre de ressources, ça tombe sous le sens. Dans notre cas, il s'agit du système de stockage. Comme on l'a déjà évoqué, chaque nœud du cluster doit pouvoir exécuter n'importe quelle VM. Mais le danger est grand, car si on ne met pas en place un certain nombre de mécanismes de régulation, on risque d'exécuter une VM à plusieurs endroit à la fois, et c'est extrêmement fâcheux. On risque de corrompre d'une part les systèmes de fichiers de la VM concernée, ce qui est déjà pénible, mais en plus, si on effectue des modifications de la structure de stockage partagé à tort et à travers, on risque d'anéantir l’ensemble du stockage du cluster, ce qui impactera l'ensemble du service. C'est bien plus que pénible.

La solution de stockage

La virtualisation

L'outil de gestion de machines invitées que je préfère est libvirt, développé par les excellents ingénieurs de Redhat. À mon sens c'est le seul gestionnaire de virtualisation qui a su proposer des fonctionnalités très pratiques sans se mettre en travers de la volonté de l'utilisateur. Les commandes sont toujours implicites, on sait toujours ce qui est fait, la documentation est bien remplie, les développeurs sont ouverts, et surtout, libvirt est agnostique sur la gestion des ressources, c'est à dire qu'il manipule des concepts simples qui permettent à l'opérateur de le coupler à ses propres solutions avec une grande liberté.

Voici une liste d'autres solutions, qui ne me correspondent pas :

• Proxmox : Il s'agit d'une de ces solutions qui misent sur le tout-en-un, et donc contraire à l'approche KISS. Cela dit, son approche multi-utilisateurs est très intuitive surtout quand on a pas de compétences poussées en virtualisation, du fait de la présence d'une interface web intuitive. Il s'agit d'une solution satisfaisante lorsqu'on souhaite utiliser un unique nœud mais dès lors qu'on construit un cluster, Proxmox fait intervenir des élément très compliqués qui peuvent vite se retourner contre vous lors de fausses manipulations qui peuvent vous sembler bénignes. De ce fait, sa difficulté d'utilisation et de maintenance augmente de façon spectaculaire, et c'est ce contraste que je lui reproche.
• oVirt : Il s'agit d'une solution également développée par Redhat, avec interface web conne proxmox et beaucoup (peut-être trop) de fonctionnalités, et qui utilise libvirt pour faire ses opérations. Cependant, comme j'ai du mal à voir ce qui est fait sous le capot, j'ai décidé de ne pas l'utiliser.
• Virtualbox : Du fait de l'omniprésence et de la disponibilité des tutoriels sur Virtualbox, cela aurait semblé être une bonne solution. Mais il y a plusieurs problèmes : en premier lieu cette solution a été conçue principalement autour de son interface graphique, et son interface en ligne de commande est assez pauvre. Ensuite, par Virtualbox on parle d'une part de l'outil de gestion de VM, mais également du moteur d'exécution lui même. Ce moteur nécessite l'installation d'un module tiers dans le noyau du système, et je préfère éviter cette pratique.
• VMware : Non là je trolle. #Sapucépalibre

Sous linux, la solution la plus logique pour faire de la virtualisation est QEMU + KVM. Comme je l'ai évoqué, il existe aussi le moteur Virtualbox que j'ai exclu pour les raisons que vous connaissez. On aurait pu aussi s'éloigner de la virtualisation au sens propre et se tourner vers des solutions plus légères, par exemple la mise en conteneurs de type LXC ou Docker.

Les conteneurs sont de petits animaux très gentils avec un petit chapeau sur la tête pour pouvoir se dire bonjour. Et ils sont très, très intelligents.

Les conteneurs sont très utiles lorsqu'il s'agit de lancer des programmes rapidement et d'avoir des ressources élastiques en fonction de l'utilisation. L'avantage des conteneurs est qu'ils sont très réactifs en début et en fin de vie, pour la simple raison qu'ils ne possèdent pas de noyau à lancer et donc ses processus sont directement lancés par l'hôte. En revanche, je compte lancer des machines virtuelles complètes, dotées de fonctions propres, parfaitement isolées de l'hôte, et qui vont durer pendant de longues périodes. Pour des services qui doivent durer, les conteneurs n'apportent rien d'autre que des failles de sécurité. Mais bon, c'est à la mode, vous comprenez...

Bon c'est entendu, partons sur libvirt ne demande pas grand chose pour lier une machine virtuelle à son stockage, ce qui fait qu'il est compatible avec beaucoup de façons de faire. En particulier, si votre stockage se présente sous la forme d'un périphérique en mode block dans votre /dev, libvirt saura en faire bon usage.

Le partitionnement

Au plus haut niveau pour le stockage des VM, je me suis tourné naturellement vers LVM. C'est la solution par excellence quand on cherche à gérer beaucoup de volumes modulables et élastiques, avec de très bonnes performances. Besoin d'un nouveau volume ? Hop, c'est fait en une commande. Le volume est trop petit ? Pas de problème, LVM peut modifier la taille de ses partitions sans avoir à s'inquiéter de la présence d'autres partitions avant ou après, LVM se débrouille comme un chef.

LVM s'articule autour de trois notions :

• Les LV (logical volumes) : Les partitions haut niveau qui seront utilisées par les VM.
• Les VG (volumes groups) : un VG est une capacité de stockage sur laquelle on va créer des LV.
• Les PV (physical volumes) : Les volumes qui sont utilisés pour créer des VG. Un VG peut utiliser plusieurs PV, en addition ou en réplication, de façon similaire au RAID.

Par défaut, un VG est local, c'est à dire conçu pour n'être utilisé que sur une seule machine. Ce n'est pas ce qu'on souhaite. On souhaite un VG commun à tous les nœuds, sur lequel se trouvent des LV qui, on le rappelle, ne sont utilisés que par un seul nœud à la fois. LVM nous permet de créer un tel VG partagé, en ajoutant un système de gestion de verrous.

Là encore, il y a beaucoup de façons de faire. Moi, je cherchais un moyen qui ne m'impose pas de mettre en place des technos qui sont très mises en valeur dans la littérature mais sur lesquelles je me suis cassé les dents, à l'installation comme au dépannage. Typiquement, je refusais catégoriquement de donner dans du Corosync/Pacemaker. J'ai déjà joué, j'ai perdu, merci, au revoir. Un jour peut-être vous vanterai-je dans un article les bienfaits de Corosync lorsque j'aurai compris le sens de la vie et obtenu mon prix Nobel de la paix. Ou bien depuis l'au-delà lors du jugement dernier lorsque les bons admins monterons au ciel et les mauvais descendront dans des caves obscures pour faire du Powershell ou se faire dévorer par les singes mutants qui alimentent en entropie les algorithmes de Google. En attendant, j'y touche pas même avec un bâton.

Une technique qui m'a attiré par sa simplicité et son bon sens fait intervenir la notion de sanlock : plutôt que de mettre en place une énième liaison réseau entre les différents nœuds et de paniquer au moindre cahot, on part du principe que de toute façon, quelle que soit la techno de stockage partagé utilisé, les nœuds ont tous en commun de pouvoir lire et écrire au mème endroit. Donc on va demander à LVM de réserver une infime portion du média pour y écrire quelles ressources sont utilisées, et avec quelles restrictions. Ainsi, les nœuds ne se marchent pas sur les câbles. Moi ça m'allait bien.

Une photo de groupe de l'équipe admin de mon ancien travail. On venait de changer de locaux.

D'ailleurs, à ce niveau de l'histoire, je dois dire que je ne suis pas peu fier. En effet, pour mettre au point cette infrastructure, j'ai été inspiré en grande partie par l'infrastructure utilisée dans une de mes anciennes entreprises, dans laquelle j'avais la fonction de singe savant, et je ne comprenais pas (et ne cherchais pas à comprendre) le fonctionnement de mon outil de travail. Après mon départ, quand j'ai cherché à comprendre, j'ai entretenu une correspondance courriel avec un de mes anciens référents techniques, qui a conçu cette infra et pour qui j'ai toujours eu beaucoup de respect.

Je lui avais demandé des infos sur le sanlocking, ce à quoi il m'a répondu :

Quand j'ai testé le sanlocking ça avait fonctionné, mais je suis pas allé plus loin. Mais ici on gère vraiment le locking à la main.

En effet, les VG de stockages étaient de simples VG locaux. Les métadonnées étaient individuellement verrouillées localement sur chaque nœud, et dès lors qu'on voulait provisionner une nouvelle VM, on devait lancer un script qui déverouillait les métadonnées sur le nœud de travail. Du coup, rien n'empêchait un autre nœud de faire la même chose, au risque d'avoir des modifications concurrentes et la corruption de l'univers. Donc, on était obligé de hurler à la cantonade dans l'open space dès qu'on touchait à quoi que ce soit. Si on avait de l'esprit, on aurait pu parler de screamlock à défaut de sanlock. De la même façon, on risquait à tout moment de lancer des VM à deux endroits à la fois !

En fait on passe petit à petit sur oVirt pour gérer ce cas là. Aujourd'hui sur notre cluster KVM "maison", rien ne nous empêche de démarrer x fois la même machine sur plusieurs hôtes et de corrompre son système de fichiers 😕️ C'est une des raisons de la bascule progressive vers oVirt.

Donc je suis fier de ne pas avoir eu à passer à oVirt pour faire ça. Libvirt est suffisamment simple et ouvert pour nous laisser faire ce qu'on veut et c'est ce que j'aime.

Le partage

Quel PV doit-on choisir pour notre cluster ? Il nous faut un machin partagé, d'une manière ou d'une autre. J'ai envisagé au moins trois solutions :

• Un LUN iSCSI depuis un SAN (aka. la solution optimale) : Un SAN est un serveur de stockage mettant à disposition des volumes (appelés LUN). Le stockage est donc géré par des appareils dédiés, qui se fichent complètement de la façon dont on utilise ses volumes ni sur combien de nœuds. Le SAN ne sait pas si ses volumes contiennent des systèmes de fichiers, et il ne bronchera pas du tout si vous corrompez leur contenu parce que vous êtes pas fichu de vous organiser. Le soucis avec les SAN, c'est leur coût qui fait souvent dans les cinq chiffres...
• Une réplication DRBD multimaster (aka. la solution du pauvre) : Si vous êtes comme moi et que les brousoufs ne surpopulent pas votre compte en banque, vous pouvez vous limiter à utiliser le stockage local de vos nœuds, que vous mettez en réplication multimater DRBD. De cette façon, chaque modification du volume sera instantanément répercuté sur l'autre nœud. L'avantage de cette solution est que le stockage est local, donc pour les accès en lecture on ne génère pas de trafic réseau. D'autre part, on a de facto une réplication de l'ensemble des données en cas de panne d'un nœud. Le soucis avec DRBD, c'est qu'il ne supporte, pour l'instant, que deux nœuds. D'un autre côté, comme on est pauvre, on a difficilement plus de deux nœuds de toute façon, mais cela empêche une mise à l'échelle horizontale dans l'immédiat. On peut se consoler en planifiant qu'on pourra passer sans trop d'efforts à la solution SAN quand les finances seront propices.
• D'autres protocoles plus lourds comme Ceph qui vous promettent la lune et des super fonctions haut niveau (aka. la mauvaise solution) : Attention danger, on rentre dans l'effroyable empire des machines à gaz : on sait pas trop ce que ça fait, ça bouffe des ressources sans qu'on sache pourquoi, et quand ça foire, si on a pas passé sa vie à en bouffer, on peut rien faire. Déjà, Ceph est une solution mise en avant par Proxmox, donc il y a déjà matière à se méfier. En plus, les fameuses fonctions haut niveau, comme le partitionnement, le modèle qu'on a choisit nous pousse à le gérer avec autre chose, ici LVM. Donc merci, mais non merci.

Notez que peu importe la solution que vous choisirez, comme il s'agit de stockage en réseau, il est fortement recommandé d'établir un réseau dédié au stockage, de préférence en 10 Gbps. Et malheureusement, les cartes réseau et les switchs 10 Gbps, c'est pas encore donné.

Schéma récapitulatif

La mise en œuvre

Lors de la phase de conception, on est parti du besoin haut niveau pour descendre au contraintes matérielles. Pour la mise en œuvre, on va cheminer dans l'autre sens.

DRBD

Comme je vous l'ai avoué, d'un point de vue budget infrastructure, j'appartiens à la catégorie des pauvres. J'ai donc du me rabattre sur la solution DRBD.

Sur chacun de mes deux nœuds, je dispose de volumes de capacité identique, répondant au nom de /dev/sdb.

Après avoir installé DRBD, il faut créer sur chacun des nœuds la ressource associés à la réplication, qu'on va nommer r0.

# /etc/drbd.d/r0.res

resource r0 {
    meta-disk internal;
    device /dev/drbd0;
    disk /dev/sdb;

    syncer { rate 1000M; }
        net {
                allow-two-primaries;
                after-sb-0pri discard-zero-changes;
                after-sb-1pri discard-secondary;
                after-sb-2pri disconnect;
        }
    startup { become-primary-on both; }

    on node1.mondomaine.net { address 10.0.128.1:7789; }
    on node2.mondomaine.net { address 10.0.128.2:7789; }
}

Quelques explications :

• /dev/sdb est le périphérique de stockage qui va supporter DRBD.
• /dev/drbd0 sera le volume construit par DRBD
• Les noms des nœuds doivent correspondre au nom complet de l'hôte (défini dans /etc/hostname) et ne pointe pas obligatoirement vers l'adresse IP précisée, qui est souvent dans un réseau privé dédié au stockage.

Une fois que c'est fait, on peut passer à la création de la ressource sur les deux machines :

drbdadm create-md r0
systemctl enable --now drbd

DRBD va ensuite initier une synchronisation initiale qui va prendre pas mal de temps. L'avancement est consultable en affichant le fichier /proc/drbd. À l'issue de cette synchronisation, vous constaterez que l'un des nœuds est secondaires. On arrange ça par la commande drbdadm primary r0 sur les deux hôtes (normalement uniquement sur l'hôte secondaire mais ça mange pas de pain de le faire sur les deux).

LVM

On a besoin d'installer le paquet de base de LVM ainsi que les outils pour gérer les verrous.

apt install lvm2 lvm2-lockd sanlock

La page du manuel de lvmlockd est extrêmement bien ficelée mais je sens que je vais quand même devoir détailler sinon ce serait céder à la paresse. On va donc reprendre les étapes de la même façon que la documentation.

On prends conscience que c'est bien le type sanlock qu'on veut utiliser. L'autre (dlm) est presque aussi nocive que Corosync.

Dans le fichier /etc/lvm.conf on modifie :

use_lvmlockd = 1
locking_type = 1

Sur la version de LVM de la Debian actuelle (Buster), le paramètre locking_type est obsolète et n'a pas besoin d'être précisé.

Ne pas oublier de donner un numéro différent à chaque hôte dans le fichier /etc/lvm/lvmlocal.conf dans la rubrique local dans le paramètre host_id.

On active sur chaque hôte les services qui vont bien :

systemctl enable --now wdmd sanlock lvmlockd

On crée le VG partagé virtVG (sur un seul nœud) :

vgcreate --shared virtVG /dev/drbd0

Puis enfin on active le VG sur tous les hôtes :

vgchange --lock-start

Vous pouvez dès à présent créer des LV. Pour vérifier que votre VG est bien de type partagé, vous pouvez taper la commande vgs -o+locktype,lockargs. Normalement vous aurez un résultat de ce genre :

  VG     #PV #LV #SN Attr   VSize   VFree   LockType VLockArgs    
  virtVG   1   2   0 wz--ns 521,91g 505,66g sanlock  1.0.0:lvmlock

Dans la colonne Attr, le s final signifie shared, et vous pouvez voir dans la colonne LockType qu'il s'agit bien d'un sanlock.

Pour créer un LV de 8 Go qui s'appelle tintin :

node1:~# lvcreate -L 8g virtVG -n tintin
  Logical volume "tintin" created.
node1:~# lvs
  LV     VG     Attr       LSize Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
  prout  virtVG -wi------- 8,00g                                                    
  test   virtVG -wi------- 8,00g                                                    
  tintin virtVG -wi-a----- 8,00g

Le a de la commande Attr indique que le volume est activé. C'est sur cette notion d'activation qu'on va pouvoir exploiter le verrou. Pour en faire la démonstration, rendez-vous sur un autre hôte (on n'a qu'un seul autre hôte comme on est pauvre).

node2:~# lvs
  LV     VG     Attr       LSize Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
  prout  virtVG -wi------- 8,00g                                                    
  test   virtVG -wi------- 8,00g                                                    
  tintin virtVG -wi------- 8,00g

Notez que tintin n'est pas activé ici, et on a d'ailleurs tout fait pour que l'activation n'ait lieu que sur un seul nœud à la fois. Voyons ce qui se passe si on essaye de l'activer :

node2:~# lvchange -ay virtVG/tintin
  LV locked by other host: virtVG/tintin
  Failed to lock logical volume virtVG/tintin.

Cessez les applaudissements, ça m'embarrasse. Donc, pour l'utiliser sur le deuxième nœud il faut et il suffit de le désactiver sur le premier.

node1:~# lvchange -an virtVG/tintin
node1:~# lvs
  LV     VG     Attr       LSize Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
  prout  virtVG -wi------- 8,00g                                                    
  test   virtVG -wi------- 8,00g                                                    
  tintin virtVG -wi------- 8,00g

Et sur le deuxième on retente :

node2:~# lvchange -ay virtVG/tintin
node2:~# lvs
  LV     VG     Attr       LSize Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
  prout  virtVG -wi------- 8,00g                                                    
  test   virtVG -wi------- 8,00g                                                    
  tintin virtVG -wi-a----- 8,00g

Magie. Quand un volume est activé, libre à vous d'en faire un système de fichier, de le monter, de faire un dd dessus... Tous ce dont vous aurez besoin c'est du chemin du périphérique /dev/virtVG/tintin. Le plus probable dans le cadre de la virtualisation est qu'il va y être déployé une table de partition MBR ou GPT, auquel cas il faudra, si un jour vous souhaitez explorer ce LV autrement que depuis la VM, lire sa table de partition avec kpartx.

Virtualisation

On arrive presque à l'issue de la chaîne des technos. En fait, dès maintenant, libvirt est capable de créer des VM. Mais par contre, en l'état, vous devrez vous charger manuellement de l'activation des LV. C'est un peu fastidieux, surtout dans un milieu industriel.

D'un point de vue conceptuel, deux possibilités s'offrent à nous :

• On définit toutes les VM sur tous les hôtes (et bien sûr on ne démarre des VM que sur un seul hôte à la fois).
• On définit sur un hôte uniquement les VM que cet hôte a le droit d'exécuter pour l'instant

J'ai choisi la deuxième option pour des raisons de clarté, mais je n'exclue pas de passer à la première option dans le futur pour une raison ou une autre.

Il faut ensuite adopter une stratégie d'activation des LV. On peut en choisir entre ces deux là :

• Un hôte active les LV de toutes les VM qui sont définies sur lui.
• Un hôte active uniquement les LV des VM en cours d'exécution sur lui.

J'ai choisi la deuxième stratégie, car la première est incompatible avec l'option de définir toutes les VM sur tous les hôtes.

Selon cette deuxième stratégie, il y a trois opérations de base sur les VM qui nécessitent d'intervenir sur l'activation des LV :

• La mise en service
• L'arrêt
• La migration (le transfert d'une VM d'un hôte à un autre)

Pour la mise en service, il faut activer le volume (et donc poser un verrou) avant que la machine ait commencé à s'en servir. Pour l'arrêt, il faut désactiver le volume (et donc libérer le verrou) après que la machine ait fini de s'en servir. Pour la migration... c'est plus compliqué.

Pour la migration à froid, c'est à dire pendant que la machine est à l'arrêt, c'est facile : il faut activer le volume sur la machine cible avant la migration et le désactiver après. Pour la migration à chaud, c'est à dire pendant que la VM est en marche, je vous propose d'étudier la suite des états de la VM et du LV, avec en gras les événements et en italique les périodes :

1. Avant l'instruction de migration : la VM est en marche sur l'hôte source, donc le LV associé doit être activé sur l'hôte source.
2. Instruction de migration
3. Entre l'instruction de migration et la migration effective : la VM est en marche sur l'hôte source, donc le LV associé doit être activé sur l'hôte source ; l'hôte cible vérifie qu'il peut accéder au LV, donc le LV doit être activé sur l'hôte cible.
4. Migration effective
5. Après la migration effective : la VM est en marche sur l'hôte cible, donc le LV associé doit être activé sur l'hôte cible.

Vous le voyez bien : à l'étape 3, il est nécessaire que le LV de la VM soit activé à la fois sur la source et sur la cible. Et là, ce pour quoi on s'est battu depuis le début de cet article vole en éclat, et notre beau château de carte est désintégré par une bourrasque de vent.

Mais non, il reste de l'espoir, car je ne vous ai pas encore tout dit.

En fait, par défaut, les verrous des LV sont exclusifs, mais il est aussi possible de poser un verrou partagé :

lvchange -asy virtVG/tintin

Lorsqu'un LV est activé avec un verrou partagé, n'importe quel autre hôte a la possibilité d'activer le même LV avec un verrou partagé. Il faudra attendre que tous les hôtes aient désactivé le LV (et donc libéré leurs verrous partagés) pour que le LV puisse à nouveau être activé avec un verrou exclusif.

Bien entendu, si on laisse un verrou partagé sur plusieurs hôtes pendant une longue période, il est probable qu'un opérateur négligeant finisse par commettre l'irréparable en lançant la VM en question alors qu'elle est déjà en marche ailleurs...

C'est pourquoi il faut absolument que les périodes d'usage des verrous partagés soient réduites au nécessaire, c'est à dire pendant la migration.

Heureusement, libvirt vous donne la possibilité de mettre en place des crochets, c'est à dire des scripts qui vont être automatiquement appelés par libvirt au moment où il lance ces opérations. L'emplacement du crochet dont on a besoin est /etc/libvirt/hooks/qemu.

Nouveau problème : en l'état actuel, en ce qui concerne la migration, libvirt invoque le crochet uniquement sur l'hôte cible, et uniquement avant la migration effective. Nous avons besoin qu'il invoque le crochet à trois autres reprises :

• Avant la migration effective, sur l'hôte source, pour permettre de muter le verrou exclusif en verrou partagé
• Après la migration effective, sur l'hôte source et l'hôte, pour permettre de libérer les deux verroux partagés, dans le cas d'une migration à froid

Dans le cas d'une migration à chaud, libvirt notifie de toute façon, à la source, l'arrêt de la VM et donc la libération du verrou quel qu'il soit, et sur la cible, le démarrage de la VM et donc la pose d'un verrou exclusif qui écraserait un éventuel verrou partagé.

J'ai remonté le problème aux ingénieurs de Redhat en charge de libvirt, ils sont en train de développer la solution (suivez le fil sur la mailing list). Je publierai mon script dès que ce problème sera réglé.

À propos de la configuration de libvirt, j'ai un dernier conseil qui me vient à l'esprit. Il ne sert pas à grand chose de configurer le VG en temps que pool de volume, au sens de libvirt. En vérité, on peut très bien démarrer une VM même si son volume est en dehors de tout pool défini dans libvirt. En plus, si le pool est en démarrage automatique, libvirt va activer tous les LV quand il va démarrer, ce qui va provoquer une erreur dans le cas d'un redémarrage d'un hôte dans un cluster en service.

Le seul avantage de définir un pool auquel je peux penser est que libvirt peut créer des LV sans commande LVM auxiliaire au moment de la création d'une VM. La belle affaire. Personnellement je provisionne déjà mes VM avec un outil auxiliaire qui s'appelle virt-builder, faisant partie de la très utile suite utilitaire libguestfs. Je vous la recommande, elle fera peut être l'objet d'un futur article.

J'ai déjà beaucoup trop parlé et ça m'a saoulé, alors maintenant je vais la fermer et dormir un peu.

...

Nan j'déconne.

Enfin je vous conseille quand même de faire la mise à jour bien entendu, pour des raisons évidentes de sécurité, prévoyez de le faire au moins à long terme. Parce que bon, la oldstable est toujours supportée à travers des mises à jour de sécurité, mais après y a plus rien, et votre serveur est livré à lui même et aux attaquants qui sauront profiter de failles non corrigées.

Ce que je veux dire, c'est qu'en mettant à jour votre distribution, attendez-vous à des trucs qui vont péter sévère. Faites-ça quand vous n'avez rien d'autre à faire et quand un minimum de choses vitales sont attendues de votre serveur par vos utilisateurs. Va y avoir du vilain.

Donc oui j'aime Debian, mais Debian me gonfle parfois. Notamment ce comportement très fâcheux que je viens de découvrir aujourd'hui même concernant OpenVPN.

OpenVPN, j'en ai déjà parlé et je ne m'étendrai pas plus là dessus, est un outil permettant de construire des réseaux virtuels privés (VPN), utiles pour abstraire des réseaux entre des machines géographiquement distantes et/ou pour déporter son point de sortie pour "sembler" se connecter d'ailleurs. Il y a donc une machine qui crée le VPN, dite serveur ou tête de pont, et des machines qui s'y connectent à distance, dites clients.

J'ai donc une tête de pont que j'ai récemment mis à jour sur Stretch. Tout se passa bien entendu parfaitement en apparence, et tout le monde il était beau. Je me retrouvai avec une jolie Debian Stretch toute mignonne dont le cœur et l'âme n'aurait en aucun cas pu être mis en doute par quiconque. Sauf que sous ses jupons, elle avait dissimulé des trucs moins fun. Et en conséquence, quelques jours après, je me rendis compte que mes clients OpenVPN ne se voyaient plus. Je ne mis pas longtemps à soupçonner la belle Stretch d'avoir des aveux à me faire.

L'élément fautif : le service Systemd a changé bien en profondeur.  Sous Jessie, les fichiers nécessaires pour l'établissement du VPN (configurations, certificats, clefs...) se trouvaient alors modestement dans /etc/openvpn, et ne faisait pas la distinction entre configurations clients et configurations serveurs. Le service utilisé pour démarrer OpenVPN était nommé tout simplement openvpn.service, et son boulot était uniquement de lancer une instance d'OpenVPN par fichier de configuration (dont le nom se terminait par .conf) dans ce dossier. Pour lancer openvpn, il suffisait donc de la commande simple suivante :

systemctl start openvpn

Sous Stretch, tout a été changé. Premièrement, le service a changé de nom très salement. Par salement, je veux dire que l'ancien nom existe toujours, mais a été remplacé par un service qui ne fait absolument rien (il lance le programme /bin/true, programme dont l'utilité crève les yeux), ce qui fait que ce changement de service implique non seulement une rupture de ce service si aucune action n'est prise par la suite, mais également que c'est très difficile de s'en rendre compte, le service ancien openvpn.service étant diagnostiqué par le système comme actif et bien portant. Donc, la nouvelle forme de ce service est en fait un couple de service, [email protected] et [email protected], le premier se chargeant de lancer OpenVPN en temps que client, et le second en temps que serveur. Mais ce n'était pas fini : les configurations VPN devaient être déplacées aux nouveaux endroits adéquats, et la ségrégation entre clients et serveurs a été instaurée : désormais, les configurations clients doivent aller dans /etc/openvpn/client et les configurations serveurs dans /etc/openvpn/server. Mais ce n'est encore pas tout : ces nouveaux services ne s'invoquent plus de la même manière. On doit maintenant spécifier le nom de la configuration dans la commande qui démarre le service. Par exemple, pour une configuration serveur qui s'appelle hashtagueule.conf (dûment placée dans /etc/openvpn/server), la commande pour démarrer le service associé est donc :

systemctl start openvpn-server@hashtagueule

Pour couronner le tout, un bug de configuration, oui un bug, et non une modification de comportement, s'est glissée dans le fichier de service [email protected]. Ce fichier comporte la ligne suivante :

LimitNPROC=10

Cette directive est utile pour contrôler le nombre maximum de processus exécutés par un service, pour éviter dans certain cas l'explosion du load du serveur. Sauf qu'ici, cette valeur est beaucoup trop petite. On se retrouve alors avec l'erreur suivante consignée dans les logs :

openvpn_execve: unable to fork: Resource temporarily unavailable

Ce qui veut dire que le système refuse la création d'un nouveau processus pour ce service. Je me résolus donc à réparer salement et de manière non safisfaisante en changeant la valeur 10 par 100 (aucune idée si c'est carrément trop), et enfin, le service a accepté de fonctionner.

Quelle leçon tirer de cette aventure ? Premièrement, les mises à jour sont rarement simple, surtout dans le cas de Debian. Deuxièmement, même si le nouveau fonctionnement d'OpenVPN est désormais plus propre et correspond à l'usage conventionné sur les systèmes les plus récents, on peut déplorer la manière dont elle a été mise en place. Le bon usage aurait été d'instaurer une période de transition pendant laquelle les deux workflows auraient coexisté, plutôt que de casser brutalement une configuration existante et fonctionnelle. Et je ne parle même pas de la mauvaise limite du nombre de processus...

En espérant que cette histoire aura été utile à des gens, je vous souhaite une bonne mise à jour.

Ça va peut-être vous paraître bizarre, mais je pense qu'il est grand temps de reparler de chiffrement, un dada chez moi me direz-vous. En effet, ça fait depuis mi-novembre (à cause des attentats du 13, en fait) que les choses ont commencé à s'agiter,

Revenons sur l'actualité récente. Depuis dix jours, Apple s'est relancé dans la guerre pour le chiffrement, face au FBI et à la NSA. Suivit par le PDG de Whatsapp (et Mark Zucherberg) et celui de Google.

Si on s'arrête un moment, il est très curieux que ce soient des entreprises qui défendent des droits des utilisateurs — en l'occurrence celui d'avoir une vie privée — contre leur gouvernement. On s'attent plus typiquement au schéma inverse, mais là, non.

Si l'on se replonge dans l'actualité moins récente, ce n'est pas la première fois que ce débat prend une si grande importance dans les médias. Je pourrais citer des dizaines d'articles, mais ce qui me paraît essentiel, c'est de partir de la source, c'est-à-dire qu'il s'agit-là d'une demi-victoire pour Edward Snowden. En effet, cela fait trois ans (juin 2013, mais Edward Snowden était prêt depuis 6 mois, le temps que Glenn Greewald prenne en main Tails et des moyens pour communiquer avec du chiffrement fort, GPG, OTR et via Tor) que Snowden veut que nous ayons ce débat. Demi-victoire, puisque l'autre aspect important est le respect de la vie privée, pour lequel le chiffrement est nécessaire, mais pas suffisant, mais c'est un autre débat.

Du coup, cela fait depuis mi-novembre, comme je vous disais, que beaucoup d'articles prennent position en faveur ou contre le chiffrement. Au hasard celui-ci (et là) où le directeur de la NSA ment en affirmant que sans le chiffrement, les attentats de novembres auraient pu être évités (cf. ceci, téléphone non chiffré, communication via SMS), ou celui-là sur lequel je suis tombé récemment --- et dont on va reparler.

Ce qu'il y a de remarquable, c'est leur tonalité. Ils ne sont pas objectifs, puisqu'ils refusent d'aborder toutes les parties du débat. Du coup je vais me faire "avocat de la défense", vu qu'il y a déjà beaucoup de "procureurs" ayant fait des réquisitoires contre.

L'article titre "Un Terroriste est-il un client Apple comme les autres ?", à laquelle la réponse évidente semble être "non". Mais l'article aurait tout aussi bien pu titrer : "Faut-il forcer Apple à fournir une backdoor au gouvernement états-unien, au risque que la Chine en demande une, et s'en serve contre des dissidents de Hong-Kong ?", un titre un peu long, mais au moins aussi pertinent.

En effet, il y a deux côtés à cette histoire. Le fait qu'effectivement, le chiffrement permet de cacher de l'information. Et le fait qu'il est parfois nécessaire de cacher de l'information. Soit parce que c'est votre droit (comme par exemple celui de ne pas participer à sa propre incrimination) soit parce que votre pays a un régime fort au pouvoir. En effet, la notion de terroriste est très arbitraire. Il faut se rappeler que les résistants au régime de Vichy étaient appelés terroristes (aussi là).

Du coup pourquoi cette bataille a-t-elle lieu ? Deux arguments me font penser qu'il s'agit d'abord d'une bataille juridique, et d'une façon de faciliter le renseignement pour le FBI ensuite (& la NSA, mais elle a plus de moyens).

• Premièrement, les services de renseignement de la Grande-Bretagne (leur GCHQ), l'Allemagne, et les États-Unis (via le PATRIOT ACT) ont le droit de créer des malwares et autres chevaux de troie pour accéder aux ordinateurs de suspects de crimes graves (au moins terrorisme, peut-être pédophilie, mais je ne sais pas), la France en fabrique aussi, mais je ne sais pas si elle le fait déjà dans les affaires de terrorisme. Du coup, ces pays ont les moyens d'accéder a des iPhones, tant qu'ils ne s'y prennent pas mal.
• Deuxièmement, la NSA a été forcée de supprimer une base de données de conversations téléphoniques concernant des appels intra-États-Unis. D'où la nécessité pour eux d'obtenir un base de droit (jurisprudence ou autre) sur laquelle reposer.
• L'obtention d'une backdoor pour exploitation est donc importante, mais secondaire à mon avis.

L'enjeu est de taille comme je l'ai souligné un peu rudement tout à l'heure en proposant un autre titre à l'article contre le chiffrement. Si le gouvernement états-unien obtient une backdoor dans l'iPhone, il y a tout d'abord un problème de sécurité, celui de la garder inexploitable pour quiconque, mais il est aussi clair que d'autres gouvernements vont faire pression pour obtenir des backdoors dans iOS. Clairement, je vois bien la France, la Chine, l'Iran, l'Allemagne en obtenir. Ça pose deux problèmes.

• Premièrement on peut imaginer que plusieurs gouvernements distincts aient accès au téléphones d'une seule personne. En ce qui me concerne, déjà que je n'ai pas très envie que le gouvernement français mette ses pattes dans mon smartphone, vous imaginez un gouvernement moins tolérant.
• Deuxièmement, il faut se mettre en tête que ce ne sera pas la faute d'Apple si un ressortissant de Hong Kong se fait dézinguer par le gouvernement chinois (au hasard) pour résistance. Parce qu'Apple aura fait son possible pour fournir du chiffrement.

Les autres aspects sont des questions de principe. Le vulgum pecus a-t-il le droit à du chiffrement de haute qualité ? C'est important parce que le chiffrement ne sert pas seulement à cacher des données, il comporte une partie authentification très importante. Par exemple votre navigateur reçoit des scripts JavaScript qu'il exécute. Il s'agit donc de code distant exécuté sur votre ordinateur. Il faut faire vraiment confiance à un tiers pour le laisser exécuter un programme dans votre ordinateur. Parce qu'il pourrait l'endommager, supprimer vos fichier, mettre un malware etc. Du coup le HTTPS des sites webs empêchent la modification d'une page web lors du trajet vers votre ordinateur, en authentifiant la page. Ainsi sans chiffrement fort, on se retrouve à poil.

Le dernier argument est celui de la prospective : le chiffrement fort sur un système GNU/Linux est plus facile que sous Android/iOS à mon avis (même si j'utilise APG, qu'il y a CyanogenMod, etc., mais ce n'est pas très répandu), du coup savoir si la majorité a droit au chiffrement sur mobile est une décision importante maintenant, mais sur le long terme, je doute que l'interdiction du chiffrement soit viable, tout simplement parce que beaucoup d'algorithmes de chiffrement sont librement disponibles et améliorable sur internet.

On vit dans un monde avec du chiffrement. Le refuser ne peut donc qu'être une solution temporaire, qui nuirait pas mal à l'utilisateur.

Sur ce, je vous laisse méditer, mettre des questions ou remarques en commentaire, et aller vous faire votre propre opinion sur ce débat. Il me paraît essentiel qu'on ait ce débat, et qu'on n'ait pas la naïveté de cette image :

parce que si on ne fait rien, une décision sera prise, sans nous.

Bonne journée !

Motius

PS : toute dernière remarque : Apple peut vouloir viser un marché aimant avoir de la vie privée, au contraire de ce que Microsoft fait actuellement...

PPS : merci à Nyx qui m'a fourni l'image de couverture !

Je parle bien sûr d'aujourd'hui 21 octobre 2015, jour qu'ont choisi Marty McFly et le Docteur Emmet Brown pour leur petite visite du futur dans le deuxième volume de la trilogie _Retour vers le Futur_.

Bon, le jour est déjà bien entamé, et pas d'apparition de Delorean volante aux infos, donc j'ai bien peur qu'un autre de nos fantasmes de gamin ne se soit évanoui. Enfin, grandissons un peu.

N'empêche que cette vision de l'année 2015 depuis l'année 1989 (26 ans, rendez vous compte !), même si manifestement différente de la réalité, reste pour le moins intéressante. Je ne vais pas vous faire l'affront de dresser une liste des différences, beaucoup de personnes plus talentueuses l'ont déjà fait.

D'aucuns vous diront que le futur imaginé en 1985 était beaucoup plus évolué que notre présent réel, d'autres affirmeront le contraire. Pour ma part, je pense que les deux évolutions se valent en norme, mais ont suivi des tangentes différentes. En effet, j'ai l'impression que le futur décrit dans le film poursuit la vision des années 80, avec un développement d'innovations hétéroclites, mais également réparties dans les différents domaines de la vie de tous les jours. On y met aussi l'accent sur les découvertes physiques, comme la lévitation, par exemple les voitures volantes ou le fameux overboard, qui a fait rêvé beaucoup de monde et qui a fait l'objet de plusieurs hoaxes.

Découvrez l'overboard dans la réalité par Gentside

Aujourd'hui, on se retrouve dans la réalité avec des innovations non moins négligeables, mais peut-êtres moins visibles et pas dans le même ordre.

Je rappelle que je ne fais que donner mon avis. Vous êtes libres de sortir dans la rue et d'observer la société par vous même, et de vous faire un avis en regardant le film.

Donc aujourd'hui, disais-je, mon impression est que le progrès a été nettement plus centralisé. On a focalisé nos efforts sur une technologie particulière (quoique vaste) qui est l'informatique et ses sous domaines, comme le big-data ou l'interface homme-machine, et on en a mis partout. Quand je dis partout, je veux dire partout. La liste des objets qui ne disposent pas d'un système d'exploitation standardisé se réduit à une peau de chagrin de nos jours, et c'est donc le règne de la micro et macro-informatique.

Ce qui découle aussi d'un phénomène plus global : au lieu d'inventer de nouvelles technologies, on a surtout perfectionné les technologies existantes : les voitures ne volent pas et roulent toujours au pétrole, mais elle sont plus sures et moins gourmandes (sauf exceptions).

Ce qui donne au final une image très différente de l'année 2015.

Mais bon, surtout, n'en voulons pas à Robert Zemeckis de s'être un peu trompé, franchement qui pourrait prévoir les évolutions de la société à presque 30 ans d'avance ? En tout cas, la science-fiction a entre autres pour rôle de stimuler l'imagination et de faire bouillir des neurones agités des scientifiques, ingénieurs, entrepreneurs, et finalement nous tous, car nous avons tous le pouvoir de faire changer la société, dans le bon ou le mauvais sens.

Aujourd'hui on va parler de SMSSecure et de TextSecure en tant que solutions de chifrement de textos. Avantages, inconvénients, architecture de chiffrement...

Comme d'habitude ans les échanges cryptographiques, on prendra Alice qui veut communiquer avec Bob, et Ève qui tente d'espionner (vous commencez à avoir l'habitude si vous lisez hashtagueule.fr régulièrement ;) ).

Fonctionnalités de base

Les deux application TextSecure et SMSSecure peuvent être utilisée par le grand public puisqu'elles fonctionnent même sans chiffrement. Elles servent alors de remplacement à l'application SMS/MMS par défaut de votre Android.

TextSecure et SMSSecure sont sous licence libre GPLv3 ! Vous pouvez vous en servir avec une grande confiance, et éventuellement donner aux développeurs de TextSecure et SMSSecure, si le cœur vous en dit.

Puisqu'elles sont sous licence libre, on peut plus facilement avoir confiance dans le chiffrement qu'elles proposent, ce que nous allons détailler ci-dessous.

Description du chiffrement

TextSecure est une solution de chiffrement développée par Open Whisper Systems, qui permettait le chiffrement de SMS et MMS sur mobile. Cette solution était d'assez bonne qualité, en voici les détails :

• chiffrement de bout en bout : Alice chiffre (automatiquement, c'est mieux pour le commun des mortels) le message sur son téléphone avec la clef de Bob. Ainsi le message n'est jamais sur le réseau de manière non-chiffrée ;

• pas de notion de session de chiffrement, à l'inverse de ce qui peut se faire avec XMPP + OTR : inconvénient : si Alice perd sa clef, tous les messages chiffrés par Bob peuvent être déchiffrés ;

• l'application utilise le "TOFU" : Trust on First Use : c'est-à-dire que lorsque Alice parle à Bob, elle va d'abord initier une session chiffrée, et quelqu'un (Bob a priori) va recevoir le message d'initialisation. Alice va donc recevoir une clef de chiffrment à utiliser. À partir de ce moment, la conversation est chiffrée, mais pas authentifiée, puisqu'Alice n'est pas certaine de savoir à qui appartient la clef de chiffrement reçue. Il faudra donc qu'Alice rencontre Bob, ou quelqu'un qui connait la clef de Bob (et en qui Alice a confiance) pour que la conversation soit authentifiée.

Depuis quelques mois, TextSecure a abandonné le chiffrement des SMS pour ne garder que celui des MMS, ce qui a mis en rogne certains utilisateurs, ce pourquoi SMSSecure est né, forké du code de TextSecure. SMSSecure a donc la même architecture de chiffrement que TextSecure, mais diffère sur quelques points.

Alors SMSSecure ou TextSecure ?

Avantages de SMSSecure :

• SMSSecure chiffre aussi les SMS.
• Les SMS chiffrés par SMSSecure ne passent pas par des serveurs de Google (contrairement aux messages chiffrés de TextSecure, ce qui fait que Google a les métadonnées, mais pas les données. On se rappelle Edward Snowden qui nous a dit que les métadonnées était aussi importantes que les données).
• SMSSecure demande moins de permissions que TextSecure. Là il faudrait voir s'il y a un loup, mais je préfère une application qui demande moins de permssions.

Avantage de TextSecure :

• TextSecure passe par la donnée, donc peut potentiellement être utilisé à l'étranger par des correspondants de différents pays. À l'instar des applcations Hangouts de Google et iMessage de Apple.
• TextSeure est compatible avec l'application iPhone "Signal".

Comment passer de l'une à l'autre ?

(Attention ni hashtagueule.fr ni l'auteur de cet article ne sont responsables d'éventuelles pertes de données. Je décris ces mécanismes parce que j'ai un peu bidouillé, et n'ai eu absolument aucun problème).

C'est assez facile, mais cela requiert que vos contacts fassent de même, ce qui peut être un frein... Le processus pour passer à SMSSecure est le suivant :

• on installe SMSSecure ;
• on définit SMSSecure comme application par défaut ;
• on importe les SMS (si vous utilisiez une autre application sans chiffrement, comme l'application par défaut)
• on exporte les données de TextSecure ;
• on importe la sauvegarde de TextSecure à l'aide de SMSSecure.

Voilà. C'est propre et assez rapide (les phases d'import et export sont les plus lentes, durant à peu près 5 min chacune, en fonction du nombre de SMS/MMS).

Important : ne pas supprimer d'application SMS ni de données tant que vous n'êtes pas arrivé au bon résultat que vous souhaitez.

Mais pas de panique, si vous importez en double des SMS/MMS sur SMSSecure, il vous suffit de tout supprimer de SMSSecure et de recommencer les deux procédures d'import.

Il ne vous reste qu'à indiquer cette procédure à tous vos amis, et les inciter à utiliser SMSSecure.

Bonne journée !

Motius

Ce post au titre ambitieux va traiter de quelques problèmes fréquents que vous avez pu rencontrer, et de leurs solutions par les gentils du net.

Les thèmes abordés seront le "logiciel libre" dans l'éducation, les "télécom" en tant qu'infrastructure, et "l'informatique" pour le commun des mortels (tout le monde sait qu'un pseudo UNIX est immortel ;) ).

Les idées de l'article sont indépendantes, puisqu'il s'agit-là d'une compilation de problèmes.

Le logiciel libre et l'éducation

Ce premier paragraphe vient faire écho à cet article (traduit) de Richard Stallman (rms). Dans la lignée du scandale Volkswagen qui invite à l'utilisation des logiciels libre, rms explique l'intérêt de la préférence du libre dans les écoles.

Je n'ai pas le niveau pour me comparer à rms (ni à l'excellent Eben Moglen), mais les idées développées par la fsf - quoique fondamentalement utiles pour le progrès du monde libre, et l'accessibilité de l'informatique à tous - sont généralement ou blanches ou noires.

Les deux différences entre "l'open-source" et "le libre", sont la philosophie qu'il y a derrière, et la licence.

• La philosophie du libre impose le partage. Si vous utilisez du logiciel libre que vous améliorez, il faut qu'il y ait des retours pour la communauté du libre. Le libre est un bien commun, en somme, une base sur laquelle on peut bâtir son petit bout de code.
• La licence -- la GPL par exemple -- qui va avec est donc différente d'une licence BSD. On peut fermer une branche de code sous BSD et s'approprier tout ce qu'on a construit dessus, la GPL dit qu non, et qu'il vaut mieux contribuer, puisqu'on a eu de l'intérêt pour du code ouvert que parce qu'il est de bonne qualité, à jour, compétitif industriellement parlant.

C'est pourquoi les licences ouvertes (libre ou open-source) sont a privilégier en termes d'éducation :

• l'ouverture incite à l'apprentissage et/ou la bidouille ;
• l'ouverture diminue les barrières à l'entrée ;
• les applications ouvertes sont l'exemple de ce qui se fait dans l'industrie (même Microsoft utilise Ubuntu !) ;
• l'école n'a pas à se soucier de licences ou droits d'auteurs qui :
  • coûtent des sous ;
  • posent des problèmes de compatibilité (pour C# disponible sur windows®), d'utilisation (pour les droits d'auteur), etc.

L'utilisation de solutions non-ouvertes posent plusieurs problèmes supplémentaires :

• dépendance des élèves à une plateforme ;
• dépendance des enseignants à un outil.
• risque de ne pas être assez général dans le domaine et ne parler que de l'outil propriétaire étudié (parler uniquement de Microsoft Access en cours de bases de données alors que MySQL de Oracle, et PostgreSQL ont une part de marché plus importante).

C'est pourquoi il devrait y avoir (sinon une exclusivité par trop utopique) une préférence marquée pour l'univers ouvert (libre ou open-source).

TL;DR : L'ouverture apportée par les logiciels libres (ou open-source) est bonne pour l'apprentissage, pour les élèves, pour les enseignants, pour donner une perspective et ne pas être enfermé dans un outils propriétaire, et partant, devrait être encouragée fortement.

Les réseaux : une infrastructure d'État

Vers la fin du XIXème siècle, la construction de l'infrastructure de réseau de chemin de fer a mobilisé jusqu'à 1/3 de l'épargne des français. Il s'est agit d'une entreprise complexe où cohabitèrent les directives de l'État, ses ingénieurs des Ponts-et-Chaussées, les entreprises privées -- chargées de la construction, du respect des normes et du tracé -- et enfin des capitaux actions des Français.

Le numérique est une révolution du même type, mais d'un ordre supérieur. Du même type, il s'agit entre autres d'une infrastructure réseau (fibre optique, réseau cuivre, antennes GPRS, EDGE, 2G, 3G, 4G, faisceaux hertziens...). D'un ordre supérieur, le numrique permet l'acheminement d'informations plus vite que la poste combinée au train et à l'avion. Mais le numérique n'est pas limité à l'infrastructure réseau, il implique aussi d'immenses espaces de stockages (bases de données, datacentres, fichiers de boîtes mails, etc.) et une intelligence au bout, l'ordinateur.

Le réseau de transport (ferré, routier, aérien...) n'a pas changé la nature de ce que l'on voulait changer : biens, personnes, objets à vendre ou vendus, etc. Le numérique si. Le numérique s'oppose à ce qui est analogique. Ce qui est numérique n'existe que sous forme de 0 et de 1. L'enjeu de la transformation entraîné par le numérique est donc beaucoup plus grand.

• Les gens font des albums photos, mais ils ne tiennent pas un serveur de photos en ligne avec une liste de permissions afin qu'untel puisse y accéder, mais qu'un autre se voie refuser cette possibilité. Ils utilisent facebook.
• Les films montrent la manière dont nos ancêtres (ça y est j'ai l'impression d'être vieux) géraient leur conversations épistolaires. Ils regroupaient les lettres par conversations et les rangeaient. Ça fait même l'objet de drames lorsqu'il y a du contenu compromettant dans l'une d'entre elles. Mais nous ne tenons pas de serveurs de mails. On utilise le webmail de son FAI, ou de Google, de Microsoft, de Yahoo...

Les exemples comme ceci sont légion. Mais le numérique a fait plus que cela. Avant le numérique, le coût d'une photo était bien plus grand. Une fois la photo prise avec son Kodak, il en restait une de moins sur la pellicule, que celle-ci fût réussie ou pas. On peut désormais les effacer. De plus les disques durs ont rendu le stockage bon marché.

Tout ça pour dire qu'il y a un changement de paradigme du fait du numérique, mais que certaines habitudes d'avant l'ère numérique n'ont pas subsisté. Parfois c'est une bonne chose, et parfois non. Et que d'autres habitudes on subsisté. Qui parfois sont utiles, parfois nuisibles dans ce "nouveau monde". (J'y reviendrais dans un prochain article, d'ailleurs).

Voyons où se situe le problème à l'aide de ces analogies (dont on a bien précisé qu'elles sont approximatives). Si la poste avait eu un service de bijoux concurrent de Baccarat, ou s'était associé à un concurrent de Baccarat, et qu'elle ralentissait de plusieurs mois l'acheminement des produits Baccarat, on trouverait cela intolérable, et cette pratique serait taxée de déloyale et non-concurrentielle. Sur un autre registre, si demain La Poste égare ou délaye l'envoi de tracts du PS, mais accélère celui du RPR (pardon de l'UMP) ce serait un scandale. L'existence même du CSA sert à garantir une forme d'équilibre du temps de parole à la TV des politiques, ce qui n'est rien d'autre qu'une égalité des chances de parler aux citoyens, étant donné que le nombre de chaînes hertziennes de TV est limité.

Eh bien dans le monde numérique -- notre monde, le nôtre à tous, sans peut-être que vous vous en soyez rendu compte -- La Poste, ce sont nos FAIs (Orange, Bouygues, SFR, Numéricâble, Free...), et le concurrent de Baccarat ce sont les grands hébergeurs du web. Google, Facebook, Microsoft, Apple, Twitter, Amazon. Le fait qu'un FAI privilégie le trafic vers un hébergeur plutôt qu'un autre pose le même problème qu'avant. Problèmes de censure, d'accès à l'information, de pratique déloyale et non-concurrentielle.

Empêcher cela porte un non : La neutralité du net. La neutralité du net préserve l'accès à l'information. Préserve la concurrence.

Vous pouvez souffler un peu, on a déjà fait un gros bout, mais la neutralité du net n'est même pas l'objet de cet article, même s'il est essentiel d'en comprendre les enjeux pour la suite.

J'en reviens au tout début de cette seconde partie : l'infrastructure qu'est un réseau de communication. Si ce sont des entreprises qui vendent du contenu qui créent les infrastructures qui délivrent le produit, ça pose problème. Imaginez que le premier marché de La Poste fût la vente de bijoux et non pas d'être un réseau de transport. Du jour ou La Poste devient un moyen de transport d'objet et est le seul moyen de véhiculer les objets, Baccarat a un problème. ce problème existe maintenant, il prend deux formes :

• l'association de certains opérateurs avec des boîtes pour leur garantir, moyennant finance, une priorité dans leur réseau ;
• le fait que des distributeurs de contenus se lancent dans le réseau informatique. Je pense bien évidemment à Google Fiber, pour l'occident, et aux drones de Facebook pour leur projet internet.org (qui vient d'être renommé), et aux ballons stratosphériques de Google. Ces deux derniers projets permettent à des pays en voie de développement d'accéder à l'internet, ce qui est une bonne chose, tant que l'on légifère dessus. Pour chaque pays.

Vous le voyez, le passsage au numérique est un sujet complexe, mais il existe des moyens pour s'en sortir bien. En ce qui concerne cette partie, les solutions (à choisir dans une gamme de solutions) ressemblent à pas mal de neutralité du net, plus une pincée de législation sur l'investissement pour les infrastructures réseau. Que Google et Facebook s'enrichissent en proposant un service d'hébergement et un service de FAI, pas de problème. Tant qu'il y a des garanties apportées. Elles sont synonymes d'une très grande transparence. À l'inverse, un État informé pourrait faire un choix plus souverainiste. Mon but étant toujours un choix informé.

TL;DR : Entre opérateurs réseaux et fournisseurs de contenu, il y a un grand enjeu pouvoir de distribution de l'information et de concurrence. L'un des aspects importants est la neutralité du net, l'autre la nécessité d'une loi par État régissant leurs rapports, et l'évolution de l'infrastructure.

La responsabilité sociale de l'univers informatique

Les gens ne gèrent plus leurs mails ? Très bien. C'est dommage, mais c'est ainsi. Les gens ne gèrent pas d'albums photo en ligne ? Très bien. C'est vraiment dommage, mais c'est ainsi.

De nombreux acteurs sont nés du numérique, et ce domaine s'est complexifié -- on a vu tout à l'heure que le numérique pris largement regroupe le réseau, le stockage, le logiciel, l'informatique... De cette complexité et cette richesse provient l'ignorance relative du vulgus pecum en matière de numérique. Plus qu'aucune autre discipline spécialisée, un contrat social est nécessaire entre les utilisateurs et "les adminsys" (plutôt les décideurs des grandes plateformes du web).

Les parallèles, c'est bien, ça fixe les idées. Allons-y.

Si je me fais arnaquer par mon banquier (ou si vous criez à la tautologie), la confiance que je vais accorder dans les métiers liés à la finance, etc. va baisser.

De même, si les personnes qualifiées (ou douées) dans des domaines IT sont les seules à pourvoir échapper à certains abus que l'on rencontre sur le web, la confiance générale diminuera.

On peut voir ceci de deux manières :

• soit sous forme d'un équilibre, les gens se font avoir, puis commencent à se méfier, et continuent à utiliser l'outil, mais moins. De même, les non-banquiers se font roulers, les agents immobiliers festoient comme des vautours sur les non-initiés, etc. et chaque profession pratique son propre corporatisme.
• Soit on essaie d'établir une sorte de renouveau de contrat social, où chacun se voit attribuer un traitement équivalent.

À mon avis, tout ceci tient toujours de l'équilibre. Mais on peut faire plus ou moins d'effort dans la transparence.

La raison pour laquelle ce contrat social est si important pour le domaine informatique est qu'il touche littéralement toutes les professions, en plus de tous les gens.

TL;DR : notion de responsabilité d'une profession envers les non-initiés, au moins a minima. afin de préserver un équilibre, un certain contrat social et éviter un corporatisme des professions.

Voilà, c'est tout pour aujourd'hui, long article qui m'a pris pas mal de temps. Des bouts de cette réflexion se retrouveront dans un prochain article, n'en doutez pas ;). N'hésitez pas à commenter l'article, les idées à rajouter des exemples qui vous paraîtraient pertinents. Bonne journée !

Motius

Rassurez-vous, vous pourrez bientôt contrôler toutes vos machines avec un seul couple clavier/souris. Souvenez-vous de l'adage : Think with portals.

Vous y arriverez grâce à Synergy. Il s'agit d'un logiciel multi-plateforme sous licence GPL même s'il vous suggère très lourdement de le payer. En tout cas, vous pouvez l'obtenir gratuitement sur les dépôts par défaut Debian/Ubuntu.

Il existe plusieurs manières d'utiliser Synergy sur Linux, dont une en lignes de commandes. Je vous conseille d'utiliser le paquet Quicksynergy également présent sur les dépôts Debian/Ubuntu.

Pour le configurer, rien de plus simple. Vous devez faire en sorte que vos machines soient accessibles l'une à l'autre (être sur le même réseau local est amplement suffisant) et connaître vos adresses IP ou vos noms d'hôtes.

L'idée est que vous allez configurer un serveur qui partagera son clavier et sa souris, sur lequel vont se connecter des clients. Dans le cas de ma configuration, mon serveur s'appelle fluttershy.local et j'ai un client qui s'appelle pearl.local.

Côté serveur, voilà ce que ça donne :

Cela signifie que l'écran de mon client se situera à droite de l'écran du serveur, c'est-à-dire que je devrai déplacer ma souris vers le bord droit de l'écran serveur pour aller sur le client et que le curseur y apparaîtra sur le bord de gauche. Enfin j'imagine que vous saisissez.

Remarquez que vous pouvez configurer jusque 4 clients qui peuvent être placer également à gauche, en haut et en bas. Il aurait été amusant de penser à une catégorie de machine entre le client et le serveur pour relayer l'autorité du serveur et pouvoir ainsi avoir jusque carrément un mur entier d'écrans, mais là je deviens un peu trop mégalo.

Du côté clients, voici la configuration :

Cliquez finalement sur "Execute" d'abord sur le serveur, puis sur les clients.

Et voilà, fini les brouettes de claviers et les câbles de souris qui s'emmêlent. Votre installation se comporte exactement comme une seule machine avec plusieurs écran, sauf que chaque machine dispose de ses applications propres !

Attention cependant, avec la version GPL de Synergy, il est impossible de sécuriser les liaisons directement depuis l'interface. Il est néanmoins possible de les sécuriser un peu en créant un tunnel SSH, référez-vous à ce tutoriel.

Vous avez aimé cet article ? N'hésitez pas à le partager à d'autres gentils du net et découvrez-en d'autres sur hashtagueule.fr.

une news très brève et à prendre avec des pincettes.  En effet, au cours de mes tribulations sur les zinternets, je suis tombé là-dessus : un article de Wikistrike (que je ne connaissais pas) datant d'août 2015 intitulé  1 million de signatures contre TAFTA à la poubelle. Je ne sais vraiment pas ce que ça vaut :

•  en termes de crédibilité, je ne connais pas le site ;
• de vérification des sources (c'est un sujet difficile, et les accord internationnaux sont secrets afin de laisser de la marge aux négociateurs, puis deviennent connus par les parlements (européen ici, mais ç'aurait pu être chacun des 27 parlements) et enfin publics).

La raison pour laquelle je vous en parle, c'est un paragraphe du texte (encore une fois à remettre en question, on n'est jamais trop prudent) situé vers la fin :

Parmi les grands dangers dénoncés par Stop TTIP, il y a cette mise en place de tribunaux d’arbitrages qui offriront la possibilité aux entreprises de contester des décisions gouvernementales. Toute décision collective qui entraverait le libre marché transatlantique serait susceptible d’être punie. Par exemple, si la France estime qu’il faut interdire un conservateur déterminé afin de protéger la population d’un risque sanitaire donné et que cette interdiction engendre une perte pour une multinationale, cette entreprise pourrait poursuivre l’état et exiger des dommages et intérêts.

Eh bien ça (que j'espère bien être faux) me paraît malsain.  On a toujours du mal a définir les limites de la liberté (où s'arrête ma liberté d'expression ? Je ne peux pas dire du mal d'autrui, ni dire du bien du IIIè Reich). De même je pense que la liberté d'entreprendre est une bonne chose, mais que toute entreprise n'est pas bonne et la liberté doit donc pouvoir être régulée par l'État. À partir d'ici il y a deux scénarios :

• soit on régule sur un critère objectif (pas de CFC, etc...) ;
• soit non (lui je l'aime pas, sa tête ne me revient pas).

Le second cas pose un problème de favoritisme ce pourquoi il est nécessaire de pouvoir contester les décisions de l'État.

Dans le cas d'un critère objectif, il existe deux sous-cas :

• soit le critère est jugé valide par des expert en la matière ;
• soit non.

Mais indifféremment des cas, on ne doit jamais pouvoir obtenir des dommages et intérêts de la part de l'État puisque l'État a rendu une décision (à tort ou à raison) et qu'il s'agit ainsi d'un choix de société.  Contester oui. Mais pas faire de calculs sur un éventuel manque à gagner.

Quoi qu'il en soit, j'espère qu'on ne verra rien de tel dans TTIP, et que sur ce point, wikistrike.com se trompait. Je sais, je fais naïf, là.

Bonne journée à vous !

Motius

PS : j'ai le point Godwin du jour !

PPS : oulà ! Plus long que je croyais cet article.