PROJET AUTOBLOG


Le blog de Seboss666

Site original : Le blog de Seboss666

⇐ retour index

Une bonne gestion des volumes NFS dans un cluster Docker Swarm

mardi 10 décembre 2019 à 18:30

Quand j’ai monté mon cluster chez moi sur le micro serveur, j’ai fait pas mal de boulettes, au final, l’une des seules qui mérite encore vraiment des claques c’est ma gestion des volumes persistants. J’ai donc pris le temps de chercher comment tout refaire, et de vous partager tout ça car c’est pas si trivial, et ça a pris du temps pour tout identifier.

Pas besoin de rappeler qu’il vous faut des volumes pour gérer les données persistantes de vos containers docker. L’outil dispose même d’une fonction native, avec une extensibilité certaine pour pouvoir gérer tous les types de stockage possibles.

Mais quand je découvre un truc j’ai toujours tendance à commencer par faire de la grosse merde, et en l’occurrence je ne me suis pas servi tout de suite de cette fonction. À la place, j’ai créé un « gros » partage global sur mon NAS, que j’ai monté ensuite dans un dossier sur chaque machine du cluster; chaque « volume » est un dossier dans ce partage, et j’ai indiqué dans la déclaration de la stack le chemin vers ce dossier. Ouais je suis comme ça, parfois.

Mais j’avais un gros problème avec ça : lors de micro-coupures de courant, le serveur redémarre en moins de 30 secondes, pareil pour les VMs du cluster qui du coup tentent de relancer tous les services. Sauf que le NAS met trois bonnes minutes à démarrer, ce qui fait que les VMs démarrent sans leurs volumes, et donc les containers n’ont pas leurs données. Au mieux, ça redémarre à blanc, au pire ça plante en boucle. Quand tout est revenu, il faut que je redémarre chaque VM pour rétablir le service (j’ai même fait un playbook ansible pour ça…)

Docker volume et NFS, foire à la saucisse

L’idée est donc de conserver ces partages, mais de les redéfinir en tant que volume Docker, on sépare ainsi la gestion des volumes de celles des stacks, c’est plus propre, ça réduit la dépendance à l’OS sous-jacent, enfin bref, vous avez compris à quel point c’est mieux.

Au début, vu le peu de documentation je pensais qu’il fallait un plugin pour gérer quelque chose d’aussi basique que le NFS, j’avais même commencé à écrire le brouillon de cet article en ce sens. Et en fait non c’est bien géré en natif, ça a juste une « forme » dégueulasse. Tellement dégueulasse que rien que pour la déclaration des volumes, ça m’a pris plusieurs essais, notamment parce que contrairement aux services, les volumes déclarés dans une stack ne sont pas supprimés avec elle. Et si vous tentez de redéfinir un volume existant, ben il n’en tient pas compte et garde la définition existante. Qui est probablement moisie. Il faut donc, entre chaque essai, supprimer les volumes fautifs sur tous les nœuds du cluster.

Pratique non ?

Passons à la pratique

Attention, pensez à bien tout sauvegarder avant, on est jamais a l’abri d’un effet de bord malencontreux lorsqu’on modifie un stockage avec donc des permissions particulières.

Commençons par détailler l’existant. Pour l’exemple je vais prendre les volumes de smokeping, c’est le moins critique de tous. Voici le partage sur le NAS :

Et sur chaque vm, j’ai un dossier monté via /etc/fstab :

ip_nas:/Docker /home/seboss666/docker nfs _netdev,nfsvers=3,defaults,user,exec 0 0

Aucun commentaire sur le chemin de destination s’il vous plaît 😀 Quant à la stack, les volumes sont déclarés et utilisés de la sorte :

version: "3"

networks:
  smokeping:
    driver: overlay

services:
  smokeping:
    image: linuxserver/smokeping:191068eb-ls64
    networks:
      - "smokeping"
    ports:
      - "20080:80"
    environment:
      - "PUID=1001"
      - "PGID=1001"
      - "TZ=Europe/Paris"
    volumes:
      - /home/seboss666/docker/smokeping/data:/data
      - /home/seboss666/docker/smokeping/config:/config
    deploy:
      replicas: 1
      restart_policy:
        condition: any

Comme je l’ai dit, basique mais ça fonctionne, mais c’est pas pour autant que je suis content de cette situation. Le mieux est quand même de pouvoir monter uniquement le dossier au lancement du service, sans impact pour la VM en dessous.

On va donc déclarer chaque volume dans les stacks avec les options de montage directement. Parmi les contraintes à relever :

Là où j’ai galéré, c’est pour ce connard de NAS. En effet, vous avez vu, je monte /Docker depuis ce NAS, mais pour une raison que j’ignore, /Docker/registry ne fonctionne pas, alors qu’il est bien présent. Et pourtant j’en fait des palanquées des montages NFS comme ça, à cibler un sous-dossier, sur plusieurs environnements, Debian, CentOS, mix des deux, même de l’EFS AWS, c’est dire. Et ça, que je teste en v3 ou v4.

Il aura fallu plusieurs essais ratés, des recherches frustrantes, une investigation en SSH directement sur le NAS, pour finir par demander un point de vue extérieur sur le forum NXI, pour avoir la solution, une solution qui me convient dans la mesure où elle fonctionne mais pas dans la logique qu’on doit appliquer. En effet, pour accéder aux sous-dossiers directement via NFS, c’est /volume1/Docker qui doit service de base, et pas /Docker. Me demandez pas pourquoi, oui c’est /volume1/Docker qui est déclaré dans le fichier /etc/exports sur le NAS, mais j’ai toujours pas compris pourquoi monter /Docker fonctionne quand même.

Enfin bon, voici donc la même stack, adaptée avec des volumes NFS bien déclarés :

version: "3.2"

volumes:
  smokedata:
    driver_opts:
      type: nfs
      o: "addr=192.168.1.200,rw,nfsvers=3,nolock,soft,exec"
      device: ":/volume1/Docker/smokeping/data"
  smokeconfig:
    driver_opts:
      type: nfs
      o: "addr=192.168.1.200,rw,nfsvers=3,nolock,soft,exec"
      device: ":/volume1/Docker/smokeping/config"

networks:
  smokeping:
    driver: overlay

services:
  smokeping:
    image: linuxserver/smokeping:191068eb-ls64
    networks:
      - "smokeping"
    ports:
      - "20080:80"
    environment:
      - "PUID=1001"
      - "GUID=1001"
      - "TZ=Europe/Paris"
    volumes:
      - type: volume
        source: smokedata
        target: /data
        volume:
          nocopy: true
      - type: volume
        source: smokeconfig
        target: /config
        volume:
          nocopy: true
    deploy:
      replicas: 1
      restart_policy:
        condition: any

Quand Swarm lance un déploiement, il va créer un volume local sur le nœud sélectionné, dont le détail aura cette forme (via docker inspect) :

[
    {
        "CreatedAt": "2019-12-08T19:48:43+01:00",
        "Driver": "local",
        "Labels": {
            "com.docker.stack.namespace": "smokeping"
        },
        "Mountpoint": "/var/lib/docker/volumes/smokeping_smokeconfig/_data",
        "Name": "smokeping_smokeconfig",
        "Options": {
            "device": ":/volume1/Docker/smokeping/config",
            "o": "addr=ip_nas,rw,nfsvers=3,nolock,soft,exec",
            "type": "nfs"
        },
        "Scope": "local"
    }
]

On retrouve bien nos éléments, et Docker gère le volume dans son arborescence comme un grand. On s’en occupe plus nous-même, c’est un peu mieux question erreurs possibles.

Road to Kubernetes

En soi, et depuis que j’ai l’onduleur, je n’ai plus de problèmes majeur avec le NFS, à part que sur un des nœuds, quand la VM redémarre, le montage NFS ne se fait pas (ses voisines avec strictement la même configuration n’ont pas ce problème). Du coup, il ne démarre dessus que les containers qui n’ont pas besoin de volume. Ça déséquilibre un peu la conso de RAM entre les VMs, mais c’est pas la mort.

L’objectif réel de tout ça est de pouvoir mettre à la retraite Docker Swarm pour jouer avec Kubernetes, via le projet K3S de Rancher qui est parfait pour les petites ressources de mon serveur (pour rappel on peu s’en servir sur un Raspberry Pi 3 ou 4). Je ne me voyais pas faire le sale à utiliser des volumes en host-path pour celui-ci, et pour exploiter déjà la solution NFS sur Azure parce que leurs outils de volumes sont à chier, ça marche très bien. En plus, avec cette syntaxe, je vais pouvoir tester d’utiliser Kompose pour faire le feignant et éviter d’écrire tous les manifestes à la main 🙂

Des alternatives au NFS ?

Si tant est que l’espace disque n’est pas une contrainte réelle sur les VMs (le SSD sous-jacent est pas non plus extensible à l’infini), il est possible d’utiliser d’autres solutions. Par exemple, l’homme qui a changé ma vie a publié un article sur Rook, qui se base sur une autre techno de stockage distribué, Ceph. Je suis tombé aussi sur Longhorn, un projet de stockage distribué au sein du cluster qui permet ensuite d’exporter sur un autre type de stockage. C’est encore un peu jeune, mais ça passera peut-être en test.

Une solution qu’a tenté aussi de me faire tester Nicolas Simond, c’est iSCSI. On sent le mec un peu trop habitué à VMWare 😀 Ceci dit, la techno est supportée sur Docker et Kubernetes donc vous pourriez éventuellement pouvoir l’exploiter en fonction de votre environnement. En parlant de VMware, j’ai vu un client nous demander si on pouvait supporter vSphere Storage for Docker, une extension pour gérer des volumes Docker sur les datastores VMware.

Tout ça pour dire que les options ne manquent pas pour vous adapter à votre environnement. Sur ce, j’ai mes autres stacks à refaire, je vous laisse 😉

Windows, WSL et Docker, mode d’emploi

lundi 25 novembre 2019 à 18:30

Soit Qwant n’est pas encore assez doué, soit je n’ai pas trouvé l’intégralité des infos que je cherchais sur ce sujet. Et après avoir vu la vidéo de Thomas, dans laquelle il manque un ou deux morceaux, comme je suis moi-même en train de tester Ubuntu via le Windows Subsystem for Linux, me suis dit qu’il fallait tester moi-même, et vous faire un retour. Et ça n’a pas été forcément tranquille.

Une solution qui a quelques prérequis pénibles

Docker for Windows a un fonctionnement tout de même bien différent de sous Linux. Sous ce dernier, il fait encore appel partiellement à LXC, qui permet de « conteneuriser » l’application à l’exécution. Sous Windows, choix a été fait de reposer sur Hyper-V, la couche de virtualisation de Windows. Hors, cette couche nécessite une version « Pro » au minimum de Windows, donc exit tous les Windows vendus avec les laptops grand public du marché. Pour ma part, j’utilise une version entreprise LTSC, vous savez pourquoi, donc c’est bon.

Le deuxième prérequis apparent est là encore une décision détestable : demander de créer/disposer d’un compte sur le Docker Hub pour pouvoir récupérer Docker Desktop for Windows. Alors même que la version Linux et Mac n’en demandent pas autant. Devoir filer une fois de plus des infos persos, à une boite américaine de surcroit, pour un truc opensource et gratuit, non merci. Fort heureusement, j’ai fini sur un article anglais par trouver le lien direct vers l’installeur, qui fonctionne parfaitement, comme quoi demander un compte alors qu’on verrouille pas le direct download est juste de la malhonnêteté. Ce qui est « drôle », c’est que l’article en question conseille tout de même la création du compte, arguant que ça permet le téléchargement d’images. Se peut-il que le rédacteur se soit planté en utilisant « download » plutôt que « upload », à savoir téléversement, c’est à dire déposer des images sur le Hub, qui là oui demande un compte ? Mais la plupart des images sont publiques sur le Hub, donc pas besoin de compte pour les télécharger.

Enfin bon, c’était entre autres le gros point qui manquait dans la vidéo de Thomas, le reste, ça ne va être grosso modo que de la transcription. J’ai le temps d’écrire, le téléchargement prend 1Go pratiquement…

Configuration de Docker for Windows

A l’installation l’utilitaire propose de cocher une case « Use Windows containers instead of Linux containers », que j’ai laissé décoché évidemment. Il faudra se délogguer de votre session à la fin de l’installation, un peu comme sous Linux ou il faut relancer la session pour prendre en compte l’ajout de votre utilisateur au groupe docker pour que le démon accepte que vous l’utilisiez.

Le démarrage et le redémarrage du service Docker sont longs, très longs comparé à Linux, je soupçonne qu’en fait en dessous c’est une machine virtuelle Hyper-V qui est démarrée/redémarrée, et c’est pas rapide (ça expliquerait aussi la taille du téléchargement ceci dit). Je dis ça parce qu’une des premières choses à faire est d’aller dans les options de Docker (clic droit sur la baleine dans la barre des tâches, puis « Settings »), Pour décocher la télémétrie (Usage statistics, encore cette saloperie), et cocher « Expose daemon on tcp://… without TLS », c’est lui le plus important en fait.

Une fois validé, il vous demandera certainement de redémarrer, faites donc et patientez de longues secondes…

Configuration du client Docker dans WSL

L’installation du client docker (et uniquement lui) est gérable de manière tout à fait classique via la documentation officielle, à savoir ajout de la clé GPG, ajout du dépôt, et installation du client. Faut-il vraiment remettre les commandes ? Allez :

$ sudo apt install apt-transport-https ca-certificates gnupg-agent software-properties-common curl
$ curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -
$ sudo add-apt-repository \
   "deb [arch=amd64] https://download.docker.com/linux/ubuntu \
   $(lsb_release -cs) \
   stable"
$ sudo apt install docker-ce-cli

Il faut ensuite paramétrer l’environnement pour indiquer au client docker de taper sur le démon Windows qu’on a exposé un peu plus tôt. Pour ça, direction le fichier ~/.bashrc ( je préfère utiliser ~/.bash_aliases qui permet d’être plus indépendant de la distribution, et le bashrc d’Ubuntu est configuré pour charger celui-ci s’il existe), et ajouter une ligne dedans :

export DOCKER_HOST=tcp://localhost:2375

On le recharge ( source ~/.bashrc ) et roulez jeunesse. Un petit docker info devrait vous rassurer :

$ docker info
Client:
 Debug Mode: false

Server:
(...)
Kernel Version: 4.9.184-linuxkit
Operating System: Docker Desktop
(...)

Mes soupçons se confirment, c’est bien une machine virtuelle Linux qui est utilisée avec un noyal 4.9.x comme référence pour le démon Docker.

Reconfiguration WSL pour les volumes

Ah, oui, en l’état ça fonctionne, vous pouvez démarrer du container à foison, mais pour la gestion des volumes c’est pas encore tout à fait ça. En effet, par défaut sur WSL les volumes de Windows sont « montés » dans le dossier /mnt/c, /mnt/d, etc. Et ceux-ci ne sont pas utilisables avec Docker, on va voir pourquoi :/

Il faut pour ça commencer par reconfigurer WSL, via un fichier de configuration /etc/wsl.conf avec le contenu suivant :

[automount]
enabled = true

options = "metadata,umask=22,fmask=11"
mountFsTab = false
root = "/"

En fait, le « root », quand il n’est pas renseigné c’est /mnt. Vous commencez à voir où on va ?

Fermez la session, parce qu’il faut qu’on redémarre ensuite le service « LXSSManager », c’est le service système qui se charge de l’environnement WSL (oui, cherchez pas la logique du nom). Pour ça, j’ai une habitude fâcheuse mais très rapide depuis plusieurs années, c’est le raccourci clavier Win+R, services.msc :

Quand on relance, les volumes C:\, D:\ etc… ne sont plus montés dans /mnt/c/… mais directement dans /c/…, et ça tombe bien, puisque c’est le même point de montage dans la machine virtuelle de Docker Desktop. Il aura donc les bonnes informations pour aller créer/récupérer ses volumes. Attention, ça veut donc dire qu’il faut placer ses volumes persistants non pas dans la session WSL mais bien dans l’arborescence Windows. Avec toutes les limitations que posent le système de fichiers NTFS (sur la casse, les permissions…) 🙁

Y’a pas à dire, Linux c’est quand même mieux (ou le WSL 2 ?)

Ça a été long, chiant, mais ça fonctionne parfaitement. Malgré tout, c’est un sacré bidouillage, et une consommation de ressources sans commune mesure avec un démon Docker linux natif. C’est pas pour rien non plus que je me suis débarrassé de Windows au boulot, avec toutes les contraintes que ça m’a apporté derrière.

Microsoft l’a bien compris, et les améliorations tirées de ses enseignements sur Azure notamment l’ont poussé à travailler sur un WSL 2.0 qui embarquera un vrai noyau Linux pour pouvoir cette-fois-ci prendre en charge la version Linux de docker de manière native, donc beaucoup plus léger qu’un système à base de VM Hyper-V. Oui parce que j’ai pas évoqué l’impact sur les performances, mais disons simplement que c’est bien pour construire ses applis et tester leur stabilité, mais c’est pas l’environnement rêvé pour valider les performances…

WSL a d’autres limitations via certains programmes qu’on pourrait aborder dans d’autres articles. Déjà celle de Docker est contournée 🙂

Réduire la taille d’un disque virtuel au format VDI

dimanche 17 novembre 2019 à 10:30

Après mon changement d’OS sur le PC du boulot, j’avais notamment transféré la machine virtuelle Linux que j’utilisais pour récupérer notamment l’environnement SSH, Git, et Bash de manière générale. Et en regardant l’espace utilisé sur le système hôte, j’y ai vu un gros souci : la taille du disque virtuel. J’ai donc cherché à corriger ça.

L’image approchait les 40Go :

$ ll
total 75949920
drwxr-xr-x 4 seboss666 seboss666 4096 04.10.2019 09:25 ./
drwxr-xr-x 3 seboss666 seboss666 4096 04.10.2019 08:54 ../
drwxr-xr-x 2 seboss666 seboss666 4096 04.10.2019 08:54 Logs/
drwxr-xr-x 2 seboss666 seboss666 4096 05.06.2019 09:25 Snapshots/
-rw------- 1 seboss666 seboss666 8603 04.10.2019 09:25 SebLBNvm.vbox
-rw------- 1 seboss666 seboss666 8603 04.10.2019 09:06 SebLBNvm.vbox-prev
-rwxrwxrwx 1 seboss666 seboss666 40155217920 04.10.2019 09:06 SebLBNvm.vdi*

Pourtant, une fois dans la VM, la consommation n’est pas si importante :

$ df -h /
Sys. de fichiers Taille Utilisé Dispo Uti% Monté sur
/dev/mapper/lubuntu--vg-root 38G 7,3G 29G 21% /

L’explication est simple, le disque virtuel a beau être alloué de manière dynamique, par le passé j’ai pratiquement rempli cet espace, et le fichier ne se réduit pas de lui-même une fois le ménage effectué. C’est un fait bien connu des administrateurs de bases de données qui doivent exécuter des tâches de maintenance pour éviter que les tables explosent.

Pour réduire la taille, mes premières recherches m’ont conduit à une procédure qui demande de passer par deux étapes de conversion, VDI->VMDK, puis VMDK->VDI. On commence par faire la première passe, de VDI à VMDK. Alors avant de vous montrer la commande, il faut passer par une commande supplémentaire, zerofree, qui permet de réécrire des zéros sur l’espace libre, parce que sinon :

$ vboxmanage clonehd --format vmdk SebLBNvm.vdi SebLBNvm.vmdk
0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100%
Clone medium created in format 'vmdk'. UUID: 17f3ff3e-d23d-4091-a68d-00e9173de795

Voyons le résultat :

$ ll
total 75949920
drwxr-xr-x 4 seboss666 seboss666 4096 04.10.2019 09:25 ./
drwxr-xr-x 3 seboss666 seboss666 4096 04.10.2019 08:54 ../
drwxr-xr-x 2 seboss666 seboss666 4096 04.10.2019 08:54 Logs/
drwxr-xr-x 2 seboss666 seboss666 4096 05.06.2019 09:25 Snapshots/
-rw------- 1 seboss666 seboss666 8603 04.10.2019 09:25 SebLBNvm.vbox
-rw------- 1 seboss666 seboss666 8603 04.10.2019 09:06 SebLBNvm.vbox-prev
-rwxrwxrwx 1 seboss666 seboss666 40155217920 04.10.2019 09:06 SebLBNvm.vdi*
-rw------- 1 seboss666 seboss666 37617532928 04.10.2019 09:25 SebLBNvm.vmdk

Comme on le voit, le résultat n’est pas très efficace. zerofree est un utilitaire qui s’exécute en mode rescue ou via un live cd/usb, et demande paradoxalement de remonter en read-only le volume concerné.

En cherchant un peu plus à propos de zerofree et des réductions d’image disque, je suis tombé sur le Saint Graal, spécifique au format VDI, la commande vboxmanage dispose d’une option « compact » qui fait exactement le boulot sans se taper la double conversion. Un gain de temps appréciable, et un résultat intéressant :

$ vboxmanage modifymedium disk "./SebLBNvm.vdi" --compact
0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100%
$ l
total 50365484
drwxr-xr-x 2 seboss666 seboss666 4096 04.10.2019 09:53 Logs/
drwxr-xr-x 2 seboss666 seboss666 4096 05.06.2019 09:25 Snapshots/
-rw------- 1 seboss666 seboss666 8603 04.10.2019 10:29 SebLBNvm.vbox
-rw------- 1 seboss666 seboss666 8603 04.10.2019 09:25 SebLBNvm.vbox-prev
-rwxrwxrwx 1 seboss666 seboss666 11418992640 04.10.2019 10:59 SebLBNvm.vdi*

Ah ben c’est mieux. Alors évidemment, pour m’assurer que c’est peinard j’ai fait un backup du fichier avant, et je ne peux que recommander de faire cette sauvegarde au préalable.

Les formats de disques virtuels, tout un monde

Je pourrais presque faire un article complet sur les principaux formats de disque virtuel, de leurs avantages et inconvénients, les implications sur la consommation, les performances, et l’aspect ouvert ou non des formats. Mais bon, déjà là vous avez une petite bidouille si vous êtes dans une chasse à l’espace disque et que vous travaillez avec des machines virtuelles. Ici, le format était celui de Virtualbox, et donc j’ai utilisé les outils fournis avec, mais vous pouvez sinon vous tourner vers l’utilitaire qemu-img que j’avais évoqué il y a cinq ans (déjà !).

Pourquoi l’utilisateur et le mot de passe sur deux pages différentes ?

mercredi 13 novembre 2019 à 18:30

Avec la multitude de services auxquels on doit se connecter en permanence, vous avez sûrement remarqué que certains sites proposent de saisir l’utilisateur (ou l’adresse e-mail) et le mot de passe sur deux pages différentes. C’est parfois fluide, parfois pénible, et je suis tombé sur un article en anglais qui met en lumière les réflexions derrière cette technique. Une traduction, ça faisait longtemps n’est-ce pas ?

L’article original a été posté sur le blog de Twilio, un service proposant des API pour construire des applications de communications (très très résumé).

La raison la plus courante pour demander l’utilisateur et le mot de passe sur deux pages différentes est de pouvoir supporter à la fois :

  1. Le Single-Sign On, aka SSO (par exemple, « se connecter avec Google », ou un autre service comme Okta)
  2. Le login classique utilisateur/mot de passe

Cependant, ce flux de login embrouille les gens ce qui est probablement la raison pour laquelle vous lisez ceci ! Les sites Web présentent habituellement les champs utilisateur et mot de passe sur la même vue pour l’authentification. Donc vous n’êtes pas seuls si vous vous êtes déjà demandé pourquoi le champ du mot de passe manque ou est sur une autre page.

Cet article jette un oeil à la sécurité associée à cette décision concernant cette conception et propose quelques options pour concevoir des formulaires de connexion qui supportent plusieurs méthodes d’authentification.

Est-ce que séparer les champs utilisateur et mot de passe sur deux pages différentes est plus sécurisé ?

La séparation pourrait rendre les attaques « credential stuffing » (NdT : attaque voisine du brute-force, qui se concentre sur les dictionnaires d’identifiants fuités provenant d’attaques différentes) plus compliquées. Ça permet également à la plateforme de vérifier certaines conditions de sécurité. Par exemple, le site peut vérifier si le compte a activé l’authentification à deux facteurs, et sinon, demander de valider un CAPTCHA. La conception sur deux pages permet également de rendre plus difficile la création de sites de phishing avec des pages qui se ressemblent quand ça implique une redirection. Mais l’étape supplémentaire n’est probablement pas nécessaire à moins d’être dans un cas d’usage de SSO.

Il y a quelques discutions excellentes sur le sujet sur dev.to et Security Stack Exchange si vous voulez en savoir plus.

Options pour prendre en charge l’authentification à la fois SSO et utilisateur/mot de passe

1. Pages séparées pour les deux champs

Ce design fournit un chemin clair à suivre pour l’utilisateur dans les deux cas. L’étape de vérification de l’e-mail et l’action distincte (‘Next’) peut aussi simplifier le code de l’implémentation sous le capot. La séparation permet également les vérifications conditionnelles évoquées plus tôt.

Aujourd’hui, des sites comme Shopify, Yahoo, Google, Twilio font tous ça. Le bémol, c’est que les gens l’ont remarqué et se sont plaints. Également, ce flux n’est pas très pratique pour les gestionnaires de mots de passe et leur fonction d’auto-remplissage, mais les plus répandus (LastPass, 1Password) se sont adaptés.

2. Vérification sur une seule page

Des sites comme Dropbox et Segment proposent une belle interface pour ça. Un des ingénieurs de Segment m’a montré comment ça fonctionne. Si vous allez sur https://app.segment.com/ et entrez foobar@segment.com une option pour utiliser le SSO apparaîtra. Ca vérifiera le domaine de l’adresse e-mail et vérifier si l’organisation utilise le SSO avec Segment. C’est similaire à l’option 1 mais sans impliquer deux vues séparées. Cette option met d’abord l’accent sur l’authentification utilisateur/mot de passe, et peut fonctionner mieux avec les gestionnaires de mots de passe, mais ça demande une gestion via Javascript qui peut être capricieuse.

3. Champ de mot de passe optionnel

Une autre option est de rendre le champ du mot de passe optionnel. Hackerone, une plateforme de « bug bounty », procède ainsi sur son formulaire de login. Ca simplifie la page, ne nécessite pas la vérification du domaine, mais ça peut être malhabile/peu pratique pour les utilisateurs de SAML.

Montrer les deux champs sur une seule page permet aussi d’inclure d’autres méthodes d’authentification comme celles via les comptes de réseaux sociaux. Des sites comme Pinterest et Twitch proposent de telles options.

Comment concevoir le formulaire d’authentification parfait

Brad Frost a d’excellents conseils qui valent la peine d’être débattus dans son article « Ne soyez pas astucieux avec les formulaires de mots de passe« . Vous pouvez suivre la discussion sur Hacker News pour voir également d’autres idées. Évidemment les utilisateurs et mots de passe ne sont pas les seuls éléments à considérer sur un écran d’authentification. Vous pouvez renforcer la sécurité de votre flux avec l’authentification à deux facteurs de Twilio ou via la vérification du numéro de téléphone (NdT : ce que propose Twitter par exemple).

Est-ce que votre entreprise a résolu le problème d’une manière différente ? Où y a-t-il une autre raison pour séparer les pages utilisateur et mot de passe que je n’ai pas mentionné ? Dites le moi sur Twitter @kelleyrobinson ou allez voir la discussion sur cet article sur Hacker News.

Installer le WSL (et Ubuntu) sans Microsoft Store

dimanche 10 novembre 2019 à 18:30

Quand on a besoin d’un environnement Linux pour travailler mais que le poste de travail en question est un Windows, les solutions ne sont pas légions. Si j’avais opté pour une machine virtuelle auparavant, solution consommatrice de RAM, il existe désormais une option mature, bien qu’encore imparfaite, le Windows Subsystem for Linux. Comment s’en servir malgré ses imperfections ?

Présentation

Le sous-système Windows pour Linux est un des moyens inventés par Microsoft et livré en 2017 pour tenter de garder dans sa prison aspiratrice à données personnelles les développeurs partis soit sous Linux soit sous Mac, en leur proposant un moyen efficace de faire tourner un environnement de type shell, provenant d’une distribution linux « classique ». La principale différence, l’absence de noyau puisque le concept est de « traduire » à la volée les appels système des applications pour que ce soit le noyau de Windows qui fasse le boulot en dessous.

Quand je disais qu’il était imparfait, c’est notamment par son mode d’installation. En fait, vous activez d’abord la fonctionnalité WSL,  et il faut ensuite installer une distribution, qui s’affiche dans votre menu démarrer comme une application classique. Déjà, l’activation demande de redémarrer l’ordinateur, ce que je trouve toujours pénible. Mais surtout, les distributions sont à récupérer… par le Microsoft Store, ce qui nécessite un compte en ligne Microsoft. Mais c’est niet chez moi, Microsoft n’espionnera que le strict nécessaire (sous couvert de la fameuse télémétrie). En plus, j’en avais parlé dans le passé, je n’ai pas d’application du store ni le store lui-même sur l’installation personnalisée que j’ai faite.

Installation sans le store, c’est possible (sans la carte Kiwi)

Alors comme souvent, la ligne de commande est plus rapide que le clicodrome, on commencer par activer WSL, via Powershell en mode administrateur :

Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux

Ensuite il faut redémarrer (j’ai déjà dit que c’était con ?). À partir de là, il faut trouver le moyen de récupérer les packages d’installation. Grâce à Internet et la magie des moteurs de recherche (Qwant en l’occurrence), et Stackoverflow, j’ai pu obtenir une liste d’images officielles à installer :

Ensuite, créez un dossier C:\Users\<votre_utilisateur>\<votre_distrib>. Avec 7-Zip (et uniquement celui-ci apparemment), décompressez le fichier téléchargé dans le dossier fraîchement créé. Lancez l’exécutable (par exemple, Debian.exe si vous avez choisi Debian), patientez que le système de base soit installé, et c’est terminé. Optionnel mais recommandé : créez un raccourci vers l’exécutable dans le menu Démarrer pour faciliter les lancements futurs.

L’imperfection va devenir moins imparfaite

La première version du WSL, comme je l’ai dit, avait un gros manque pour les adorateurs de Linux : l’absence d’un vrai noyau, et donc de la possibilité d’utiliser Docker (un Docker pour Linux s’entend). Ce manque est sur le point d’être « corrigé » par Microsoft avec la future version 2. Ceux qui sont contraints de garder un Windows tout en devant bosser sur des environnements Windows (comme moi), ça devient une solution très intéressante. Le problème reste Windows lui-même, sans parler de l’inévitable antivirus qu’on doit se paver.

En effet, jusque là, c’était la machine virtuelle qui constituait la solution à privilégier. Sauf que pour l’avoir vécu, c’est pas toujours ultra stable, très consommateur de mémoire, même en prenant une distribution ultra-légère, et basculer de l’un à l’autre n’est pas aussi naturel et fluide. Et pour avoir pété la VM de mon PC de jeu peu de temps avant d’en changer, je me suis dit que ça serait intéressant de se pencher sur la techno. Pour ma part, j’ai fait le choix d’Ubuntu, Canonical étant un partenaire de plus en plus courant de Microsoft sur pas mal de sujets, dont Azure.

Quelques bonus

Installer Terminator : Là, je vais faire le gros flemmard, et vous diriger vers le site Pofilo qui a écrit un très bon tuto. Un collègue de boulot ingénieur avait déjà tenté le coup à l’époque de la sortie du premier WSL, c’était encore un peu frais, mais ça semblait faire le taf.

Installer CentOS : Il n’y a pas de package officiel pour la distribution chapeautée désormais par Red Hat, mais vous pensez bien que certains ont cherché à corriger ce point. Je n’ia pas du tout essayé, mais si ça vous tente, vous pouvez tenter l’expérience.

Plus de détails sur WSL 2 : Comme souvent je vous recommande la lecture de NextINpact pour les détails à la fois sur WSL 2 (version du noyau, support Docker et FUSE) et sur le futur Windows Terminal qui doit là aussi séduire les exilés.