Linux (fr)

  • The MagPi n°7 et 8 distribués gratuitement sur les campus de Caen, Grenoble, Lyon, Troyes et Mâcon ! (Laboratoire Linux SUPINFO)

    En ce début d'année 2014, certain ont pu découvrir que le Père Noel était passé à SUPINFO, principalement à l'attention des laboratoires Linux, Robotique et SL3 mais aussi et surtout à tous les étudiants curieux d'électronique.

    The MagPi est un magazine communautaire anglophone qui a été traduit et édité sous licence Creative Commons BY-NC-SA, permettant ainsi à SUPINFO de l'imprimer et de le diffuser à titre gratuit, en sa qualité d'association loi 1901.

    Les magazines profitent de la même qualité d'impression que le Supinfo Inside, les étudiants des campus sélectionnés découvriront ainsi en version papier comment faire de la rétroingénierie classique, asservir une carte Arduino avec une carte Raspberry Pi (ainsi que les avantages que cela procure), de quoi stimuler leur imagination sur des projets robotiques ou domotiques. La sélection s'est basée sur la réalisation de projets publiés sur les sites des labos. Les magazines restent disponibles en PDF sur le site du MagPi.

    image

    Sophie, notre assistante de direction à Caen, semblait intriguée par le magazine !

    image

  • Rejoindre le labo, entrer en contact avec la communauté (Laboratoire Linux SUPINFO)

    Si vous êtes à Caen, Clermont Ferrand, Lyon, Paris ou Rennes, il existe déjà des étudiants qui travaillent en local que vous devriez contacter (cf. le guide des labo de l'an dernier pour retrouver les contacts). Vous devriez aller vous inscrire sur le site de votre campus que vous retrouverez dans cette liste.

    Si vous êtes le premier étudiant de ce labo sur votre campus, vous pouvez créer un compte ici même. Si de nombreux étudiants se joignent à vous, il vous sera possible de demander l'ouverture d'un site dédié.

    Pour communiquer, nous vous recommandons de rejoindre le réseau de messagerie instantannée décentralisé XMPP, qui repose sur une liste d'amis permanente. Le salon de discussion du labo est : labo-linux@conference.labo-linux.org

    Si vous n'avez pas de compte, vous avez la possibilité d'en créer un sur http://xmpp.labo-linux.org Ce client Web offre une interface Responsive pour téléphones ainsi qu'un réseau social. Il existe des clients lourds tels que Gajim, Pidgin ou Adium.

     

    image

  • Migrer Windows 10 d'un disque BIOS/MBR, vers un SSD en mode UEFI/GPT avec des logiciels libres (Journaux LinuxFR)

    Sommaire

    Introduction

    Ce tutoriel vous guide pas à pas pour migrer votre installation de
    Windows qui est actuellement sur un disque dur de votre PC vers un
    nouveau disque, en l'occurrence un SSD. A vrai dire, vous pouvez aussi
    bien migrer vers un autre HDD.

    La spécificité de ce tutoriel est qu'elle utilise les outils fournis par
    Microsoft avec Windows ainsi que des logiciels libres (Clonezilla
    principalement, mais si quelque chose devait mal tourner vous pouvez avoir
    besoin d'utiliser fdisk, gdisk ou testdisk pour ne citer qu'eux). Quand
    j'ai voulu faire cette migration je n'ai pas trouvé de tutoriel
    expliquant de bout en bout comment faire cette migration juste avec les
    outils de Microsoft et des logiciels libres.

    Typiquement, vous pouvez avoir envie/besoin de faire cela car vous avez
    acheté un nouveau disque pour remplacer l'ancien (par exemple car
    l'ancien montre des signes de faiblesse, ou vous voulez améliorer la
    réactivité de votre système).

    En plus de la migration du système d'exploitation, ce tutoriel vous
    explique comment passer d'un démarrage en mode BIOS/MBR à un démarrage
    en mode UEFI/GPT.

    Succinctement la démarche est la suivante, d'abord installer le nouveau
    disque dans le PC, et initialiser la table de partition selon les normes
    Microsoft. Puis cloner/dupliquer la partition contenant le système
    d'exploitation à l'aide de Clonezilla. Ensuite et avant de redémarrer
    dans le clone de Windows sur le SSD, faire quelques modifications dans
    le registre pour que la lettre de lecteur C: pointe vers la bonne
    partition et éventuellement modifier le mode SATA en AHCI si vous le
    modifiez aussi dans le UEFI/BIOS. Après cela, on va préparer la
    partition système EFI/ESP pour que le PC puisse démarrer dessus et qu'il
    démarre sur le Windows du SSD. Finalement, une fois dans le Windows du
    SSD, on va réactiver l'"environnement de récupération de Windows".

    Mise en garde : Faites une sauvegarde de vos données avant toute
    opération. Personne n'est à l'abri d'une mauvaise manipulation ou d'une
    erreur.

    Prérequis

    Compétences

    Niveau de difficulté : Difficile.

    Vous devez être à l'aise au niveau de l'utilisation de la ligne de
    commande dans Windows, mais aussi assez à l'aise pour gérer les
    partitions de votre disque. Savoir modifier le paramétrage de votre
    Firmware UEFI/BIOS et aussi nécessaire. Ce tutoriel guide pas à pas pour
    la majorité des opérations. Certaines n'ont pas été détaillées par souci
    de simplicité et d'efficacité.

    Matériel

    Le PC où vous voulez installer le SSD. Il faut qu'il soit en état de
    marche. De plus il doit avoir un firmware UEFI. S'il n'a que un BIOS
    standard, sans UEFI, ce tutoriel n'est pas adapté.

    Clé(s) USB ou plusieurs CD/DVD sur lequel vous aurez mis
    Clonezilla, System rescue
    CD
    et un environnement de démarrage
    Windows PE, ou Windows RE, ou le DVD/Disque d'installation de Windows.

    Le disque SSD (testé avec Samsung SSD 860 EVO 250GB). Il doit avoir une
    taille suffisante pour contenir votre partition de Windows. Dans tous
    les cas, la taille de la partition qui contiendra Windows sur le SSD
    doit être au moins égale à la taille de la partition Windows du HDD que
    vous voulez cloner. Au besoin, pour remplir ce critère, réduisez la
    taille de votre partition Windows avec le gestionnaire de disque de
    Windows par exemple (ou un autre outil de gestion de partition, comme
    gparted, sur le System Rescue CD). Cherchez sur internet si vous ne
    savez pas comment faire.

    Logiciel

    Windows 10 installé (en version 64 bits) (testé avec Win10 v1709)

    Windows 10 PE ou support d'installation de Windows 10 (clé USB ou DVD) -
    En Version 64 bits (testé avec un support d'installation de Win10 v1804)

    System rescue CD (version 5.2.2 par
    exemple)

    Clonezilla installé sur une clé ou un CD.
    Bien vérifier avant que votre système arrive à démarrer dessus. (Testé
    avec Clonezilla 2.5.5-38)

    Nomenclature

    SSD : désigne le nouveau SSD

    HDD : désigne votre disque actuel, sur lequel est installé Windows

    WinPE : un environnement de démarrage Windows PE, ou Windows RE, ou le
    DVD/Disque d'installation de Windows. Il doit être sur un support
    amovible (USB, CD ou DVD)

    S: La lettre de lecteur affectée à la partition Système EFI qui sera sur
    le nouveau SSD (parfois appelée ESP, EFI_System_Partition ou encore
    SYSTEM, ou EFI)

    N: Le clone de Windows, sur le SSD

    O: Le Windows cloné, sur le HDD

    C: La partition dans laquelle est installée Windows, lorsqu'on est dans
    Windows (que ce soit le windows cloné, ou le clone)

    Les commandes doivent être lancées en tant qu'administrateur.

    Procédure de base

    • Fixer et brancher le SSD dans l’ordinateur

    • Désactiver Windows FastStart (cf votre moteur de recherche préféré)

    • Initialiser et partitionner le disque à l'aide de Windows

      • Démarrer sur le Windows installé ou WinPE
      • Pour initialiser le disque, d'abord créer une table de partition, puis partitionner le disque. Pour ce faire :
        • Suivre les instructions de partitionnement UEFI/GPT selon Microsoft. Ci-dessous mon exemple, mais peut-être avez-vous besoin d'une partition "recovery" aussi, ou votre configuration nécessite quelques aménagements. Dans ce cas, voir les instructions de Microsoft et adapter pour vos besoins.
        • Par exemple: une partition EFI de 260Mo, une partition Microsoft Reserved (MSR) de 16Mo, une partition pour Windows (taille au moins égale à la taille de la partition de Windows à cloner). Pour informations, dans diskpart, les tailles que vous donnez en MB/Mo sont en réalité des MiB/Mio (220 = 10242 octets).
          • Ouvrir une invite de commande en mode administrateur et lancer diskpart . Et une fois dans diskpart :
            • list disk pour lister les disques et connaître le n° du SSD.
            • select disk # avec le numéro du SSD à la place de #
            • clean Supprime le contenu du disque / l'initialise
            • convert gpt Définit que le disque aura une table de partition GPT
            • create partition efi size=260 Crée une partition EFI de 260MiB
            • format quick fs=fat32 label="System" Formater la partition EFI au format FAT32
            • assign letter="S" Lui donner la lettre S
            • create partition msr size=16 Créer une partition Microsoft Reserved de 16MiB
            • create partition primary Créer la partition pour Windows (l'équivalent du C: )
            • format quick fs=ntfs label="Windows" Formater la partition pour Windows au format NTFS
            • assign letter="N" Lui donner la lettre N
            • list volume Liste les volumes. Permet de voir la table de partition.
            • exit Quitte diskpart
    • Cloner le Windows installé sur le HDD. Ceci sera fait à l'aide de
      Clonezilla

      • Redémarrer dans Clonezilla
      • Une fois dans clonezilla, et si vous êtes confortable avec les lignes de commande Linux, éventuellement supprimer de la partition Windows du HDD les fichiers pagefile.sys , hyberfil.sys (désactiver windows faststart avant), swapfile.sys .
      • Cloner la partition Windows du HDD vers le SSD (de préférence, partition de même taille, et de toutes façons, la partition de destination doit être plus grande que la source. Si ce n'est pas le cas, réduisez d'abord la taille de votre partition Windows depuis Windows). Dans clonezilla, utiliser le mode Partition vers Partition, et en mode Export. Utiliser les options -e1 auto (automatically adjust file system geometry for a ntfs boot partition if exists) -e2 (sfdisk uses CHS of hard drive from EDD (for non grub loader) -r (resize filesystem to fit partition size of target) -m (do NOT clone boot loader) -v (verbose)
      • Optionnellement cacher la partition contenant le windows source de la table de partition du disque source (si vous ne savez pas à quoi ça sert, passez votre chemin). Pour cela modifier le type de partition de la partition NTFS de windows (en principe, NTFS a un id de « 7 ». On peut utiliser id 17 pour la partition cachée : 17 correspond à « IFS Hidden »). Utiliser cfdisk ou fdisk pour faire ce changement (ce sont des programmes linux).
    • Dans le Firmware UEFI (ou BIOS-UEFI), on peut en profiter pour passer
      du mode SATA "IDE" vers "AHCI". Windows n'aime pas ce changement et
      il faut donc faire une opération dans le registre qui est
      détaillée ci-dessous. Tant que vous ne le faites pas, vous aurez un
      écran de plantage bleu de windows au démarrage (BSOD).

    • Si vous voulez être sûr de ne pas faire de bêtise dans le Windows que
      vous venez de cloner, je vous conseille d'éteindre l’ordinateur & de
      débrancher l’ancien disque. Ainsi vous ne risquez pas de modifier le
      mauvais fichier de registre (en l'occurrence celui de votre Windows
      sur le HDD)

    • Effectuer quelques opérations sur le Windows de destination (celui
      sur le SSD) avant qu'on ne démarre dessus. En particulier corriger le
      registre pour affecter la lettre de lecteur C: à la bonne partition,
      et si le paramétrage du Firmware UEFI (BIOS-UEFI) a été modifié pour
      passer de SATA Mode PCI vers AHCI, on va aussi faire ce changement
      pour que ca fonctionne.

      • Redémarrer dans WinPE (en Mode UEFI, pas MBR !)
        • Tout d'abord déterminer la lettre de lecteur affectée au clone de Windows, celui qui est sur le SSD. Ou, s'il n'y a pas de lettre affectée, lui en donner une, par exemple N: (lettre utilisée dans les exemples qui suivent)
          • Pour cela, lancer dans diskpart
            • list volume
              Ce qui retourne la liste des volumes avec la lettre de lecteur qui a été affectée à chacun.
          • Si aucune lettre de lecteur n'est affectée, il faut alors lui en affecter une. Pour cela, lancer dans diskpart
            • select volume # (avec # étant le numéro du volume qui contient le nouveau windows)
            • assign letter=N
              S'il n'est pas possible d'utiliser select volume alors faire comme ceci
            • list disk
            • select disk # (# étant le numéro affecté au SSD)
            • list partition
            • select partition # (# étant le numéro affecté à la partition de Windows sur le SSD, probablement 3)
            • assign letter=N
        • Faire un CHKDSK /F sur la lettre du nouveau Win
        • Pour que la partition C: utilisée par Windows soit celle du SSD et pas celle de l’ancien disque, modifier une clé de registre du nouveau Windows :
          • Lancer REGEDIT et dans le registre HKEY_LOCAL_MACHINE monter la ruche N:\Windows\System32\Config\SYSTEM . Lui donner le nom "NewWin" On s’intéresse à HKEY_LOCAL_MACHINE\NewWin\MountedDevices . Ce sont là les valeurs qui sont dans le registre " HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices " lorsqu'on est dans l'installation de Windows.
            • Dans HKEY_LOCAL_MACHINE\NewWin\MountedDevices modifier la lettre de lecteur C: en renommant \DosDevices\C: par \DosDevices\O: (car la valeur fait référence à la partition de l'ancien Windows sur le HDD et on ne veut pas, en démarrant, utiliser cette partition mais celle de son clone qui est sur le SSD). Ainsi, lorsqu'on démarrera dans le nouveau Windows, la partition contenant le Windows sur le HDD aura la lettre O:, et la partition contenant le Windows sur le SSD aura la lettre C:
            • Créer une nouvelle valeur binaire nommée \DosDevices\C: et lui donner comme contenu celui de \DosDevices\N: qui est renseignée dans le registre WinPE, c'est-à-dire là HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices ( C: étant la lettre qu'utilisait le Windows du HDD comme partition où il y a le dossier \Windows )
            • ATTENTION: Bien vérifier que la copie a fonctionné et qu'il y a les bonnes valeurs, car dans mes essais, j'ai du m'y reprendre à 2 fois car le 1er "coller" ne collait pas ce que je voulais.
            • En principe c'est tout. Mais d'après certaines sources, il y aurait une clé \\?\Volume{GUID} ayant le même contenu que le \DosDevices\O: qu’on vient de modifier. Chez moi ce n'était pas le cas. Si vous avez une telle valeur, alors il faut lui donner le contenu de \DosDevices\N: depuis le registre WinPE
        • Si en même temps que la migration on veut aussi passer du mode SATA IDE vers AHCI alors il faut encore faire ceci. Cela a été repris du site tomshardware.co.uk
          • Toujours dans REGEDIT avec la ruche montée en HKEY_LOCAL_MACHINE\NewWin
          • Aller à HKEY_LOCAL_MACHINE\NewWin\ControlSet000\Services\storahci\StartOverride
          • Changer la valeur DWORD de 3 à 0.
          • Au redémarrage, si ça n'a pas été fait, changer la paramétrage du contrôleur SATA de IDE à AHCI. Au redémarrage, Windows devrait directement démarrer correctement et sans plantage (BSOD).
        • Rendre le disque bootable en installant les outils EFI de microsoft et configurant le Magasin BCD (BCD Store)
          • D'abord assigner une lettre de lecteur à la partition ESP
            • MOUNTVOL S: /S
              Si ca n'a pas fonctionné, faire comme ceci dans diskpart
            • list disk
            • select disk # (# est le numero du SSD retourné par list disk)
            • list partition
            • select partition # (# est probablement 1)
            • assign letter=S
          • Puis lancer bcdboot N:\windows /l fr-fr /s S: /f UEFI
            • N:\Windows est le répertoire contenant le clone de Windows sur le SSD)
            • S: = partition EFI
    • Redémarrer, et avant le lancement de Windows vérifier votre UEFI
      (ou BIOS-UEFI). Il faut qu'il soit configuré pour démarrer par défaut
      en mode UEFI et pas en mode BIOS. Penser aussi à corriger le
      paramétrage SATA si cela a été modifié dans le registre de Windows.

      Le paramétrage du démarrage avec
      bcdboot N:\windows /l fr-fr /s S: /f UEFI a normalement créé le
      magasin BCD, mis tous les fichiers EFI sur la partition SYSTEME (ESP,
      partiton EFI, la 1ère du SSD) et dit au firmware UEFI qu'il doit
      automatiquement démarrer avec le gestionnaire de démarrage
      (boot manager) de Windows.

    • Une fois qu’on a réussi à démarrer dans la copie de Windows

      • Réactiver le "FastBoot"
      • Réactiver l'environnement de récupération de Windows en lançant, depuis une ligne de commande avec les droits administrateur, la commande reagentc.exe /enable . Vérifier avec reagentc.exe /info . Et s'il y a une erreur essayer avec reagentc.exe /enable /setreimage /path C:\Recovery\WindowsREC:\Recovery\WindowsRE est le dossier où se trouve le fichier Winre.wim
      • Vérifier que tout est en ordre. Eventuellement donner un nouveau nom à votre partition C: (pour la différencier de celle sur le HDD) en lançant: LABEL [drive:][label]
      • Redémarrer encore une fois en laissant le processus de démarrage se faire tout seul pour vérifier que tout est ok.
    • Réinsérer l'ancien disque dur.

    • Normalement, il devrait être possible de redémarrer dans l'ancien
      Windows, du moment que vous savez comment booter en MBR, et sous
      réserve de ne pas avoir modifié le mode SATA dans le UEFI/BIOS. SI
      c'est le cas, vous pouvez envisager de modifier le registre du
      Windows du HDD, ou de modifier le paramétrage du UEFI/BIOS.

      Si vous avez aussi Linux d'installé sur le HDD, il devrait toujours
      être possible de le démarrer en mode BIOS

    • On peut diminuer/augmenter la taille de la partition C: du SSD (Pour
      un SSD TLC ou VNAND, on peut par exemple laisser de l’espace libre à
      la fin ~10 % de la capacité du disque d'après le logiciel Samsung
      Magician, pour un SSD 860 EVO)

    • En principe, puisqu’on boot en EFI on peut enlever sur le clone
      Windows sur le SSD les fichiers \bootmgr et \Boot\BCD puisque ce
      sont ceux qui étaient utilisés pour un boot en mode BIOS/MBR et que
      désormais on est en EFI. Vous pouvez d'abord les renommer et vérifier
      que ca ne change rien au prochain boot, plutôt que de les supprimer
      tout de suite.

    Quelques pistes si ça ne fonctionne pas…

    • Faire un chkdsk sur la nouvelle partition
    • Recréer le bootsector du NTFS avec testdisk (dispo sur System Rescue CD, mais peut être aussi dans Clonezilla ? Je n'ai pas vérifié)
    • Vérifier le BCD:
    • Vérifier que la partition EFI est bien initialisée (présence des fichiers \EFI , \EFI\Boot\ , \EFI\Microsoft\ …) Si ce n'est pas le cas, il y a eu un problème avec bcdboot N:\windows /l fr-fr /s S: /f UEFI
    • Vérifier le boot manager du bios (démarrage en UEFI ou MBR ? Gestionnaire de démarrage par défaut ? Présence du gestionnaire de démarrage de Windows ?)
    • A priori, pas utile : Commandes à lancer dans WinPE
      • Pour recréer le boot sector de la partition systeme (EFI): bootrec /fixboot
      • Pour chercher les OS sur le disque et les mettre dans le bootloader bootrec /scanos
    • Quelques commandes de bcdedit pour modiser la valeur de certains éléments du magasin BCD. Inutile car le BCD Store qui est utilisé lorsqu'on démarre en mode EFI n'est pas le même que celui utilisé dans un démarrage en mode MBR. Donc, pas besoin de chercher à modifier le BCD. Je garde pour info : les lettres sont celles telles que définies dans le système où on est (WinPE par ex). Doc BCDEDIT
      • bcdedit /set {bootmgr} device \Device\HarddiskVolume1
      • bcdedit /set {default} device \Device\HarddiskVolume3
      • bcdedit /set {default} osdevice \Device\HarddiskVolume3
      • Ou à la place de \Device\HarddiskVolume1 mettre les lettres de lecteur :
      • bcdedit /set {bootmgr} device partition=S:
      • bcdedit /set {default} device partition=C:
      • bcdedit /set {default} osdevice partition=C:

    Documentation, pour aller plus loin…

    A propos du EFI/UEFI:

    A propos de l'entrée MountedDevices du registre:
    http://diddy.boot-land.net/firadisk/files/mounteddevices.htm

    Si on veut y accéder, par défaut les fichiers du BCD sont cachés. Pour
    les rendre visibles:

    • attrib bcd -s -h -r
    • mv bcd bcd.bak
    • bootrec /rebuildbcd

    Documentation bcdedit:

    MBR Partition ID

    A propos des disk ID (=Disk signatures):

    Si besoin de supprimer du registre les entrées de disques qui ne sont
    pas connectés ou sans lettre assignée lancer: mountvol /R. Ce
    programme permet aussi de lister les lettres de volumes avec leur GUID
    (GUID pour ce système uniquement, il n’est pas stocké dans la partition,
    ni ailleurs sur le disque, il est assigné par windows pour un couple
    (signature de disque/partition offset) dans une instance de windows
    alors que dans une autre instance de windows la même partition sur le
    même disque aura ce GUID différent)

    Changer le label du volume: commande LABEL [drive:][label]

    Historique de révisions

    • Vous trouverez la dernière version de ce tutoriel sur ma page perso
      de tutoriels informatique
      .
      Vous y trouverez aussi la version HTML, PDF et TXT.

    • 2018-06-17 : Ajout d'une note indiquant que ce tutoriel utilise des
      logiciels libres

    • 2018-06-11 : Correction de la forme et de fautes d'orthographe

    • 2018-05-28

    Commentaires : voir le flux atom ouvrir dans le navigateur

  • Adblock vous épargne désormais les alertes aux cookies ! (Journaux LinuxFR)

    C'est un journal bookmark de toute évidence. Je suis tombé sur cet article qui décrit la souffrance du monde entier sur les sites hébergés en Europe.

    Adblock propose sur cette page des listes additionnelles que vous pouvez suivre. Parmi elles, tout en bas, figure celle qui vous évitera les messages type "En surfant ici vous acceptez les cookies".

    Ces messages sont particulièrement agaçants, bien que dans une démarche de transparence, car tous les sites non visités vous avertissent d'une généralité du Web. Le problème, c'est que ces messages se basent sur l'usage… de cookies pour être cachés ! Une aberration qui conduit les utilisateurs de Firefox, ayant paramétré un reset complet des cookies à la fermeture du logiciel, à subir encore et encore ces messages indéfiniment.

    Résultat, Linkedin semble ne pas trop apprécier, pour le reste du Web c'est juste incroyable d'arriver sur un site sans se faire agresser !

    Je me rends soudain compte qu'Adblock n'est pas réductible à un simple bloqueur de pubs, et ce depuis ses débuts puisqu'il l'a toujours permis. D'autres filtres permettent de ne plus afficher les faux scans antivirus (bien utiles pour vos proches débutants) ou encore les messages de rébellions contre Adblock lui-même.

    Je suis toujours épaté du service que me rend ce script. Je ne sais pas pourquoi mais je sens que j'aurais dû attendre une demi heure avant de poster.

    Lire les commentaires

  • Faille Lazy FPU state restore (Dépêches LinuxFR)

    Intel est de nouveau confronté à la découverte d’une faille, le Lazy FPU State Restore flaw.
    Cette fois, seule la famille des Intel Core serait concernée.

    Sommaire

    Le FPU

    Le FPU, c’est le bordel, par Ingo Molnar

    L’unité de calcul en virgule flottante, le FPU, possède une série de registres qui lui permet de « définir » son état courant. Lors du basculement d’une tâche à une autre (context switching), cet état est alors restauré pour retrouver un contexte correspondant au processus en cours. Ces opérations peuvent être coûteuses car les registres du FPU sont plus gros que les autres, c’est pourquoi les FPU fournissent une option pour désactiver toute opération en virgule flottante (CR0:TS). Aussi, dès qu’un calcul en virgule flottante est appelé, une exception est lancée pour « réveiller » le FPU avant de lancer l’opération normalement.
    Lorsque cette exception (fpudna, FPU Device Not Available) se produit, un « gestionnaire de contexte FPU » vérifie quel processus a la main sur le FPU à ce moment‐là.
    S’il s’agit d’un autre processus, il procède à la sauvegarde puis la restauration des registres, ou s’il s’agit d’un nouveau contexte, la sauvegarde puis le nettoyage des registres ; sinon, il ne fait rien : c’est le mode « paresseux » (lazy). À la sortie du processus, il ne faut pas oublier de « nettoyer » ces tables et de (re)lever tous les drapeaux liés à cette exception.

    En mode eager (zélé, volontaire), la sauvegarde et restauration des registres associés au FPU est effectuée quoiqu’il advienne, au moment du changement de tâche et non durant l’exécution de la tâche qui vient de prendre la main.

    Le bâton

    Au fil des années, les processeurs ont multiplié les registres pour prendre en charge les instructions de type SIMD, soit une instruction capable de procéder au même calcul sur un ensemble de paires de données.

    Les registres SSE, AVX et MMX restent associés au FPU et seront donc intégrés au mécanisme de sauvegarde et restauration… et ils peuvent contenir jusqu’à 2 048 bits de données, rien que sur l’AVX.

    [    0.000000] Linux version 4.14.48-intel-pk-standard (oe-user@oe-host) (icc version 18.0.2 (gcc version 7.3.0 compatibility)) #2 SMP PREEMPT Wed Jun 20 13:21:48 UTC 2018                                                              
    [    0.000000] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers'                               
    [    0.000000] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'                                              
    [    0.000000] x86/fpu: Supporting XSAVE feature 0x008: 'MPX bounds registers'                                       
    [    0.000000] x86/fpu: Supporting XSAVE feature 0x010: 'MPX CSR'                                                    
    [    0.000000] x86/fpu: xstate_offset[3]:  576, xstate_sizes[3]:   64                                                
    [    0.000000] x86/fpu: xstate_offset[4]:  640, xstate_sizes[4]:   64                                                
    [    0.000000] x86/fpu: Enabled xstate features 0x1b, context size is 704 bytes, using 'compacted' format.
    

    Pour se faire battre

    Par le biais désormais connu de l’exécution spéculative puis de l’analyse de cache, un attaquant pourra lire ces registres depuis un autre processus, voire depuis une machine virtuelle. En effet, en mode lazy la sauvegarde des registres d’une tâche s’effectue au cours de l’exécution d’une autre tâche. La spéculation ignorant le drapeau CR0:TS, tout est alors possible.

    Ces registres peuvent contenir des informations sensibles comme des clefs de chiffrement (AES), par le biais des instructions d’accélération matérielle AES-NI.

    Delivers Fast, Affordable Data Protection and Security. AHeum.

    Colin Percival, ex‐membre de l’équipe sécurité de FreeBSD, a codé un exploit en quelques heures et note, dans un tweet :

    « You need to be able to execute code on the same CPU as the target process in order to steal cryptographic keys this way. You also need to perform a specific sequence of operations before the CPU pipeline completes, so there’s a narrow window for execution. »

    « Vous devez être en mesure d’exécuter le code de [l’exploit] sur le même processeur que celui de la cible pour voler les clefs de cette manière. Vous devrez en outre appliquer une suite précise d’opérations avant que la chaîne de traitement du processeur ne se termine ; de fait, la fenêtre de tir est très étroite. »

    Ce qui semble vouloir dire que, pour l’instant, coder le vol de données depuis un script venu du Web n’est pas simple à réaliser. Le temps nécessaire au vol des données des registres est la clef de l’attaque. Il faut le terminer avant que le séquenceur ne préempte la victime et que les valeurs des registres ne soient modifiées.

    Pour y arriver, les chercheurs ont utilisé plusieurs méthodes :

    Exception

    Il s’agit de coder la fuite de données à l’ombre d’une exception, sciemment provoquée, tel un page fault, par exemple. Mais il s’avère que cette solution est trop lente pour récupérer tout un jeu de registres.

    Intel TSX

    Cette mécanique n’est disponible que sur les architectures récentes (à partir de Haswell), ce qui limite l’angle d’attaque. Cette technologie comporte un jeu d’instructions appelé RTM (Restricted Transactional Memory) qui permet d’annuler un bloc d’exécution en cas d’interruption ; il suffit d’y encadrer le code malicieux, qui va innocemment faire appel au FPU, pour lever l’exception fpudna… Ce serait presque « étudié pour ».

    Retpoline

    Il s’agit au départ d’une contre‐mesure pour Spectre. Elle vise à fourvoyer sciemment le processeur sur l’adresse de retour d’un RET en plaçant une « fausse » boucle et donc le forcer à exécuter de manière spéculative un code innocent. Le code malicieux sera donc placé à cet endroit.

    Les correctifs

    Le mode lazy semble moins pertinent aujourd’hui. Les gains en performance sont faibles avec les architectures récentes et, surtout, selon les usages actuels. Le FPU étant même beaucoup plus utilisé dans nos logiciels, son usage serait contre‐productif.
    En effet, les compilateurs choisissent d’appeler les instructions SIMD (i.e. -sse) pour optimiser le code des logiciels. De fait, ceux‐ci auront de toute façon sauvegardé et restauré les registres du FPU à chaque changement de contexte. La gestion de l’exception sera inutile et va juste alourdir le processus. En outre, l’empreinte d’une sauvegarde et restauration serait moindre que celle de la gestion des drapeaux, des registres et de leurs états suite à l’interruption, le transfert de registres FPU en mémoire étant plus rapide car optimisé.

    Il est donc préconisé d’éviter le mode lazy au profit du mode eager.

    • Linux propose le mode eager plutôt que le mode lazy depuis la version 3.7 et l’active par défaut depuis la version 4.9 ;
    • ajoutez eagerfpu=on sur la ligne de démarrage pour les versions antérieures à la 4.9 ;
    • FreeBSD a poussé un correctif pour la Release 11.2 ; c’est un FreeBSD 11.1 qui a servi de cobaye ;
    • DragonFly BSD a poussé un correctif dans la version 5.2.2 ;
    • Microsoft poussera un correctif en juillet ;
    • OpenBSD a poussé un correctif le 14 juin pour la version 6.3 ;
    • NetBSD a poussé un correctif le 16 juin sur MAIN ;
    • Illumos a poussé un correctif le 19 juin.

    Conclusion

    Ils ne sont pas à la fête cette année, chez Intel. Le point positif est que la correction de cette faille devrait conduire à une amélioration des performances, voire de la consommation d’énergie.

    Theo de Raadt avait prévenu 11 ans auparavant que l’architecture Intel Core 2 promettait ce genre de faille :

    « These processors are buggy as hell, and some of these bugs don’t just cause development/debugging problems, but will ASSUREDLY be exploitable from userland code. »

    « Ces processeurs sont bogués comme jamais et nombre de ces bogues ne provoquent pas seulement des soucis de développement et d’analyse, mais ils vont assurément être exploitables depuis l’espace utilisateur. »

    Pour la petite histoire, l’embargo s’est terminé le 6 juin. Colin Percival, qui assistait à une conférence de Théo de Raadt lors de la BSDCan 2018, a codé un exploit dans la foulée, qu’il n’a pas encore rendu public. Mais il a convaincu Intel de lever l’embargo au plus vite.
    Il est notable qu’aucun des deux n’avait été mis dans la confidence ; OpenBSD signale même qu’ils en ont fait la demande (des rumeurs circulaient autour d’une énième version de Spectre), mais sans obtenir de réponse.

    Invitation to Embargo? No.
    We asked.
    No reply.

    Commentaires : voir le flux atom ouvrir dans le navigateur

  • Zet Uw Volgende Sigaret Into Your Last Met Deze Stoppen Met Roken Tips (Laboratoire Linux SUPINFO)

    e liquid ingredients. Als je een roker bent , is de kans groot dat u wilt stoppen en gewoon niet weten hoe dit te doen . Wees niet ontmoedigd , omdat de informatie en technieken die in dit artikel zijn bedoeld om mensen zoals jij te helpen . Gebruik de tips in dit artikel om u te helpen langs de weg om een ​​niet-roker

    does e liquid get you highOm uw kansen op succesvol stoppen met roken te stimuleren , denken zetten op papier alle potentiële voordelen en gevolgen van stoppen . Aanbrengen van de kwestie schriftelijk zal u helpen om het beter te kunnen zien . Dit kan u helpen gemotiveerd te blijven , en kunnen stoppen gemakkelijker te maken .

    Als u rookt als een manier om stress te beheersen , wil je andere stress saneringstechnieken klaar hebben wanneer je besluit om te stoppen . Blijf uit situaties die je kan stress voor de eerste paar weken nadat je hebt gestopt . U kunt ook uw stress te beheren door middel van yoga , meditatie of door het krijgen van een massage .

    Vergeet niet dat uw houding is alles. Wanneer u begint te voelen beneden , moet je proberen om jezelf er trots op dat je stoppen te maken. Roken is slecht voor je en elke keer dat je de drang om te roken te veroveren , moet je trots voelt als u het nemen van belangrijke stappen in de richting van een gezonder je .

    Maak een studie van wat triggers uw roken en zoek manieren om je triggers te vermijden. Bijvoorbeeld zaken als roken tijdens het rijden of het lezen , zodat je niet automatisch denken over je rookgedrag te veranderen . Je nodig hebt om een afleiding te vinden, om na te denken over iets anders.

  • Partager l'écran de son téléphone avec un PC (Journaux LinuxFR)

    Dans le cadre d'une présentation que je dois faire la semaine prochaine à l'occasion de la célébration des 20 ans de l'April à Brest, j'ai souhaité trouver un moyen de partager un téléphone android avec un PC, en m'imposant les contraintes suivantes :

    • cela doit fonctionner avec n'importe quel téléphone android (pas besoin d'être root ou d'avoir une application quelconque installée)
    • cela doit fonctionner avec un PC équipé de debian Gnu/Linux (parce que c'est ce qui équipe les ordinateurs cibles)
    • n'utiliser que des logiciels libres

    J'ai trouvé un paquet d'outils abandonnés ou ne respectant pas un des critères ci-dessus, finalement je m'en suis sorti avec AndroidScreencast, mais pas en suivant la documentation officielle qui ne m'a pas permis de faire fonctionner l'outil. Je fais donc un journal pour indiquer comment j'ai procédé, ça me permettra de le retrouver quand j'en aurai besoin la semaine prochaine, et ça peut servir à d'autres…

    Préparation du téléphone

    Il faut activer le debug USB sur le téléphone, pour cela :

    • aller dans les propriétés du téléphone
    • appuyer plusieurs fois sur « Numéro de version » ou « build number » jusqu'à que s'affiche un message indiquant que le mode développeur est activé
    • aller dans les options de développement (le menu a dû apparaître dans les propriétés)
    • cocher la case qui va bien

    Connexion du téléphone au PC

    Installer le SDK android :

    sudo apt-get install android-sdk maven git

    Brancher le téléphone au PC avec un câble laissant passer les données, et vérifier que le téléphone est bien vu avec la commande « adb devices » :

        $ adb devices
        List of devices attached
        9d5ac4af    device

    Générer AndroidScreencast

    Installer maven et git si besoin :

    sudo apt-get install android-sdk maven git

    Récupérer les sources de AndroidScreencast :

    git clone https://github.com/xSAVIKx/AndroidScreencast.git

    Générer les cibles :

    cd AndroidScreencast/
    mvn install

    Le répertoire taget/ contient maintenant un fichier androidscreencast--linux.tar.gz : c'est tout ce dont on a besoin

    voir le résultat

    Décompresser l'archive générée où on peut, puis lancer l'application :

    java -jar androidscreencast-0.0.8s-executable.jar

    Résultat du partage d'écran

    Et hop, mieux qu'un simple partage d'écran, on peut carrément contrôler le téléphone depuis son PC !

    Lire les commentaires

  • La gestion de l'authentification sous Linux avec PAM (Laboratoire Linux SUPINFO)

    La gestion de l'authentification sous Linux avec PAM

     

    Note: ce document est le second d'un cycle de trois articles sur l'authentification sur les systèmes Linux. Le premier se trouvant ici et le troisième .

    Il est possible de personnaliser finement tous les aspects de l'authentification des utilisateurs Linux et ce pour chaque application du système.

     

    Linux-PAM

    En effet, il a été choisi de centraliser le mécanisme d'authentification système sous Linux pour plusieurs raisons :

    • afin d'éviter de réimplémenter les mêmes schémas d'authentification dans tous les logiciels.
    • ne pas avoir à recompiler toutes les applications lors du changement des méthodes d'authentification.
    • permettre à l'administrateur de choisir quel mécanisme d'authentification chaque application utilise.

    Ces raisons ont conduit à la naissance de Linux-PAM (pour Pluggable Authentication Modules, soit en français Modules d'Authentification Enfichables).

    Avant PAM, pour pouvoir authentifier un utilisateur, une application faisait appel aux bibliothèques du système (via getpwnam() par exemple) qui la plupart du temps (à moins que NSS ne lui dise d'utiliser une autre source ailleurs) regardaient dans les fichiers /etc/passwd et /etc/shadow pour vérifier l'existence de l'utilisateur et la validité de son mot de passe. Cette technique fonctionnait mais n'était pas très souple pour les raisons évoquées précédemment.

    Dorénavant, une application compatible PAM délègue cette tâche à Linux-PAM (via un appel à la PAM-API), et celui-ci, suivant les directives inscrites dans ses fichiers de configuration, autorise ou non l'authentification.

    Mais PAM ne s'occupe pas seulement de la vérification du mot de passe. Il offre un total de six primitives d'authentification grâce à des modules fournissant certaines fonctions. Ces primitives sont regroupés dans les quatre catégories que voici :

    account
    • Gère la disponibilité du compte. Cette disponibilité regroupe l'accès au serveur sur lequel est stocké le compte, mais aussi si l'utilisateur est autorisé à utiliser ce compte à ce moment donné et par ce moyen. Par exemple on pourra spécifier qu'il n'est autorisé à se connecter qu'entre 8h30 et 17h00 et seulement en console.
    auth
    • Premièrement, c'est dans cette catégorie que l'on vérifie le moyen d'authentification (le mot de passe, le jeton, etc).
    • Ensuite c'est ici que l'on affecte les credentials de l'utilisateur, c'est à dire ses privilèges et les groupes auxquels il appartient.
    password
    • Les modules classés dans cette catégorie permettent simplement de mettre à jour le jeton d'authentification de l'utilisateur. Cela peut être parce que ce jeton à expiré, ou, si c'est un mot de passe, parce que l'utilisateur veut le modifier.
    session
    • Mise en place de la session
    • Fermeture de la session
    Pour ces deux aspects, cela prend en compte l'écriture dans les journaux système, l'affichage d'un message personnalisé, l'assignation des variables d'environnement, ou bien encore le montage/démontage de certains lecteurs.

     

    Les fichiers de configuration

    La configuration de PAM peut se faire de deux façon différentes. Soit dans un fichier unique nommé /etc/pam.conf ou soit dans une série de fichiers situés dans le répertoire /etc/pam.d. À noter que la présence de ce répertoire fait que PAM ignorera le fichier pam.conf.
    La façon la plus claire de faire et aussi la plus répandue est l'utilisation du dossier pam.d et c'est cette méthode que je vais détailler ici.

    Chaque fichier du répertoire pam.d gère la configuration du service homonyme. Par exemple le fichier /etc/pam.d/sudo configure l'authentification faite par l'intermédiaire de l'outil sudo.
    Il y a cependant une exception à cela. Le fichier /etc/pam.d/other contient la configuration pour les services n'ayant pas leur propre fichier.

    Ensuite, ces fichiers sont tous organisés suivant le même schéma. Ils sont composés d'une suite d'instructions qui constituent ce que l'on nomme une pile. Chaque instruction est inscrite sur une ligne et chaque ligne est organisée comme ci-dessous :

    catégorie contrôle chemin-du-module arguments-du-module

    Ces lignes sont donc empilées les unes au-dessus des autres pour combiner les actions des modules qui les composes. On pourra par exemple avoir une ligne ayant un module d'authentification vers un serveur LDAP, suivi d'une autre avec un module d'authentification vers un serveur Kerberos pour enchaîner ces deux méthodes.

    Dans l'instruction d'exemple ci-dessus, la catégorie est choisie parmi celles décrites dans la section précédente (account, auth, password ou session).

    Le contrôle est le comportement que la PAM-API doit adopter lorsque le module échoue à sa tâche. Il peut soit prendre la forme d'un simple mot clé, ou soit une forme plus compliquée composée d'une suite de valeur=action entourées de crochets.

    Voici les valeurs que peut prendre ce contrôle lorsque c'est un simple mot clé :

    required Si un module required échoue, un statut d'erreur sera retourné par la PAM-API, mais seulement après avoir exécuté les autres instructions du fichier ayant la même catégorie.
    requisite Comme pour required un statut d'erreur est retourné si un module requisite échoue, mais cependant la main est directement redonné à l'application appelante sans exécuter les modules suivants de la pile. Le statut d'erreur retourné est celui du premier module required ou requisite à échouer.
    sufficient Si aucun module précédent n'a échoué et l'exécution de ce module est un succès, les autres instructions de la pile ne sont pas exécutés et la main est redonnée à l'application en lui signalant la validation de l'authentification.
    Si le module échoue, son statut de retour est ignoré et le reste des instructions de la pile est exécuté.
    optionnal Le succès ou l'échec d'un tel module n'est important que s'il est le seul module de la pile de cette catégorie, sinon son statut de retour est ignoré.

     

    Quant à la syntaxe complexe du contrôle, elle a la forme suivante :

    [valeur1=action1 valeur2=action2 ...]

    valeurN correspond au code de retour de la fonction invoquée dans le module. Ce code de retour dépend des modules et est l'un des suivants (pour connaître ceux que peut renvoyer un module, se reporter à la page de manuel de celui-ci) :

    success Succès de l'établissement de la session.
    open_err Le module ne peut pas être ouvert (par exemple il peut ne pas être trouvé).
    symbol_err Un objet nécessaire au module (par exemple un fichier) est introuvable.
    service_err Une erreur interne au module est survenue.
    system_err Une erreur système est survenue (par exemple si l'appel à la PAM-API n'est pas formaté correctement).
    buf_err Une erreur mémoire est survenue.
    perm_denied Une permission d'accès à été refusée à l'utilisateur.
    auth_err L'authentification à échouée. Cette erreur arrive généralement car le jeton (ou mot de passe) est invalide.
    cred_insufficient Pour une raison quelconque l'application n'a pas les privilèges nécessaires pour authentifier l'utilisateur.
    authinfo_unavail Les informations d'authentification sont inaccessibles. Par exemple si ces informations sont sur un serveur LDAP et qu'il y a une coupure réseau, ce statut sera retourné.
    user_unknown L'utilisateur est inconnu.
    maxtries Le nombre maximal d'essais pour l'authentification à été atteint.
    new_authtok_reqd Le compte utilisateur est valide mais le jeton à expiré. L'action généralement faite par l'application suite à ce statut est de demander à l'utilisateur de changer son jeton.
    acct_expired Le compte utilisateur à expiré.
    session_err L'établissement de la session à échouée.
    cred_unavail Impossible de retrouver les credentials de l'utilisateur.
    Les « credentials » sont tout ce qui identifie de manière unique l'utilisateur, comme par exemple son numéro identifiant, les groupes auquel il appartient, etc.
    cred_expired Les credentials de l'utilisateur ont expirés.
    cred_err Impossible d'assigner ses credentials à l'utilisateur.
    no_module_data Des données spécifiques au module n'ont pas été trouvées.
    conv_err Erreur de conversation.
    authtok_err Le module n'a pas été capable d'obtenir un nouveau jeton d'authentification (par exemple lors du changement de celui-ci).
    authtok_recover_err Le module n'a pas été capable de retrouver l'ancien jeton.
    authtok_lock_busy Le module n'a pas été capable de changer le jeton d'authentification car celui-ci était verrouillé.
    authtok_disable_aging Le vieillissement du jeton (en vue de son expiration) à été désactivé.
    try_again Les tests préalables au changement du jeton d'authentification ont échoués, réessayer plus tard. Ces tests peuvent être par exemple le bon accès au serveur Kerberos si le jeton est un ticket Kerberos.
    ignore Ignorer le résultat de ce module. Il ne participera donc pas au code de retour de la pile de modules.
    abort Erreur critique, sortie du module immédiate.
    authtok_expired Le jeton d'authentification a expiré.
    module_unknown Le module est inconnu.
    bad_item L'application a essayée de définir ou d'accéder à un objet non disponible (un fichier par exemple).
    conv_again  
    incomplete  
    default Toute valeur précédemment listée non mentionnée explicitement.

     

    Quant à actionN il peut prendre une des formes suivantes :

    ignore Lorsqu'utilisé sur une pile de modules (donc que ce n'est pas le seul module de cette catégorie), le statut de retour de ce module ne participera pas au choix du code de retour envoyé à l'application.
    bad Cette action indique que le code de retour doit être considéré comme indicatif si le module échoue. Si ce module est le premier de la liste à échouer, sa valeur sera utilisée comme valeur de retour après l'exécution des autres instructions.
    die Équivalent à bad avec comme effet de quitter immédiatement la pile de modules (sans exécuter les modules suivants) et redonner la main à l'application.
    ok Cette action dit à PAM que le statut de retour de ce module doit contribuer directement au code de retour global renvoyé par la PAM-API après avoir lu la pile de modules. Autrement dit, si le statut renvoyé initialement devait être PAM_SUCCESS, le statut de retour du module remplacera cette valeur. À noter tout de même, si l'état initial de la pile était un code d'échec, cette valeur ne serait pas remplacée.
    done Équivalent à ok avec comme effet de quitter immédiatement la pile de modules (sans exécuter les modules suivants) et redonner la main à l'application.
    N (un entier non signé) Équivalent à ok avec comme effet de sauter les N modules suivants de la pile. Un N égal à 0 n'est pas permis (et serait égal à ok).
    reset Efface le statut de retour de la pile de modules et recommence avec le prochain module.

     

    En sachant cela, les quatre mots clés de la forme simple (required, requisite, sufficient et optionnal) peuvent se représenter de la façon suivante avec la syntaxe complexe :

    • required : [success=ok new_authtok_reqd=ok ignore=ignore default=bad]
    • requisite : [success=ok new_authtok_reqd=ok ignore=ignore default=die]
    • sufficient : [success=done new_authtok_reqd=done default=ignore]
    • optionnal : [success=ok new_authtok_reqd=ok default=ignore]

    L'élément suivant des instructions est le chemin-du-module qui peut être soit le chemin complet vers le module, ou soit le chemin relatif depuis le dossier par défaut des modules (cela peut être par exemple /lib/security, /lib64/security, /lib/x86_64-linux-gnu/security/, etc).

    Enfin, on termine les instructions par les argument-du-module. Pour les connaître, il faut consulter la page de manuel du module en question. Les arguments étant séparés par des espaces, afin de pouvoir placer un espace dans un argument, il faut entourer celui-ci de crochets.

     

    Les modules

    Les modules sont au cœur du système PAM. C'est grâce à eux que l'on peut définir le schéma d'authentification. Ils s'occupent chacun de la gestion d'un mécanisme d'authentification spécifique.
    Voici une liste des modules les plus communs :

    Nom Catégories compatibles Description courte
    pam_access.so Toutes Détermine l'endroit depuis lequel l'utilisateur à le droit de se connecter (en local, depuis telle adresse IP, etc...)
    pam_debug.so Toutes Aide à débugger le comportement de PAM en renvoyant le code de retour demandé par l'utilisateur.
    pam_deny.so Toutes Refuser l'accès de l'utilisateur. On invoque généralement ce module après avoir essayé les autres méthodes d'authentification.
    pam_echo.so Toutes Retourne un message texte personnalisé.
    pam_env.so Auth
    Session
    Permet de définir les variables et de supprimer les variables d'environnement de la session utilisateur.
    pam_exec.so Toutes Exécute une commande personnalisée.
    pam_faildelay.so Auth Change le délais d'attente avant de considérer l'authentification comme un échec pour une application.
    pam_filter.so Toutes Peut se placer pour filtrer les entrées/sorties entre l'utilisateur et l'application. Il peut par exemple forcer les minuscules surt tout ce que l'utilisateur écrira une fois loggé. Ne fonctionne cependant que pour les tty et les applications basées sur stdin/stdout.
    pam_ftp.so Auth Permet de se connecter à un serveur FTP.
    pam_getenv.so   Récupère les variables d'environnement depuis le fichier /etc/environment.
    pam_group.so Auth Assigne à l'utilisateur les groupes auquel il appartient.
    pam_issue.so Auth Affiche le contenu d'un fichier issue (par défaut /etc/issue) avant le prompt de l'utilisateur.
    pam_krb5.so Toutes Permet l'authentification via un serveur Kerberos.
    pam_lastlog.so Session Affiche une ligne d'information sur la dernière connexion de l'utilisateur.
    pam_ldapd.so Toutes Permet l'authentification via un serveur LDAP.
    pam_limits.so Session Permet de limiter l'usage des ressources système à l'utilisateur (charge CPU, nombre maximal de processus, etc).
    pam_listfile.so Toutes Accepte ou refuse l'authentification des utilisateurs en fonction du contenu d'un fichier.
    pam_localuser.so Toutes N'accepte que les utilisateurs listés dans le fichier /etc/passwd.
    pam_loginuid Session Applique l'UID de l'utilisateur au processus demandant l'authentification.
    pam_mail.so Auth
    Session
    Affiche un message si l'utilisateur a de nouveaux emails.
    pam_mkhomedir.so Session Créé le répertoire de l'utilisateur ci celui-ci n'existe pas.
    pam_motd.so Session Affiche le message du jour (par défaut le contenu du fichier /etc/motd).
    pam_mount.so Auth
    Session
    Donne la possibilité de monter un disque local ou distant à l'ouverture de la session utilisateur.
    pam_mysql.so ? Permet l'authentification via un serveur MySQL.
    pam_namespace.so Session Créé un espace de nommage pour la sessions (voir plus de détails dans la page de manuel du module).
    pam_nologin.so Account
    Auth
    Empêche les utilisateurs non-root de se connecter.
    pam_permit.so Toutes Module qui autorise tout le temps l'accès. À utiliser avec précaution pour des raisons de sécurité.
    pam_pwhistory.so Password Retient les anciens mots de passe des utilisateurs pour forcer à en avoir un différent lors du renouvellement de celui-ci.
    pam_rhosts.so Auth Permet l'authentification des utilisateurs sur la machine locale par SSH.
    pam_rootkok.so Auth Authentifie l'utilisateur sans avoir besoin de rentrer un mot de passe, du moment que son UID est 0 (l'UID de l'utilisateur Root).
    pam_securetty.so Auth Restreint la connexion de Root aux tty (terminaux) listés dans /etc/securetty.
    pam_selinux.so Session Met en place le contexte de sécurité pour la session qui s'ouvre.
    pam_sepermit.so Account
    Auth
    L'authentification est permise seulement si l'utilisateur possède une entrée dans fichier /etc/security/sepermit.conf.
    pam_shells.so Account
    Auth
    Autorise l'authentification seulement depuis les shells listés dans /etc/shells.
    pam_succeed_if.so Toutes Valide l'authentification suivant des tests faits sur les caractéristiques de l'utilisateur (nom, UID, GID, shell, home, etc).
    pam_tally2.so Account
    Auth
    Maintient un compteur du nombre d'essais d'authentifications. Ce compteur est réinitialisé lorsque l'authentification réussie. Utile pour bloquer un compte après un certain nombre de tentatives ratées.
    pam_time.so Account Permet de restreindre l'accès de l'utilisateur suivant l'heure de la journée, le jour de la semaine, le service sur lequel il se connecte et le terminal depuis lequel il se connecte.
    pam_timestamp.so Auth
    Session
    Permet de valider automatiquement l'authentification sans demander de mot de passe si la dernière authentification réussie est inférieur à une certaine date.
    pam_tty_audit.so Session Permet d'activer l'enregistrement de ce que l'utilisateur écrira dans un tty.
    pam_umask.so Session Définie l'umask sur la création des fichiers pour la session qui s'ouvre.
    pam_unix.so Toutes Authentification via les mécanismes standard, c'est à dire en faisant appel aux bibliothèques du système (ces dernières regardant par défaut dans les fichier /etc/passwd et /etc/shadow).
    pam_userdb Account
    Auth
    Authentification via une base de données Berkeley DB.
    pam_warn.so Toutes Module qui inscrit dans les logs l'authentification de l'utilisateur.
    pam_wheel.so Account
    Auth
    Autorise l'accès seulement aux utilisateurs du groupe wheel (ou du groupe au GID 0 si le groupe wheel n'existe pas).
    pam_winbind.so Toutes Permet l'authentification via un serveur Active Directory.
    pam_xauth.so Session Permet de conserver les clés xauth (cookies du serveur X) lors du changement de session.

     

    Il existe bien d'autres modules qui permettent d'utiliser tout types de serveurs pour l'authentification ou d'autres types de jetons (comme par exemple des cartes magnétiques). Mais vu qu'ils sont utilisés plus rarement, je vous laisse les découvrir par vous même.

     

    Conclusion

    PAM est un mécanisme très puissant pour la gestion de l'authentification sous Linux. Bien qu'assez complexe sur certains aspects, il permet à l'administrateur d'avoir un total contrôle de l'accès au système par les utilisateurs. C'est aussi un point clé lorsque l'on veut centraliser l'authentification des machines d'un réseau.

     

    Ressources supplémentaires

     

  • Faites tourner les PCB ! (Dépêches LinuxFR)

    Dans un circuit numérique, il y a toujours une dose d’analogique. Une carte toute faite comme une Arduino, ou une Raspberry Pi, ne suffit pas — ou alors, il faut gérer de la puissance — on doit donc créer une carte.

    Cette carte aura besoin de connecteurs, de composants, d’énergie et d’être réalisée.

    Sommaire

    Le schéma

    Il existe un grand nombre de logiciels pour faire des schémas et les traduire en layout ou pour le dessiner directement. Certains dessinent même directement sur le typon à la main. J’ai vu de magnifiques châssis de téléviseurs à tube haut de gamme, routé à la main, avec des tracés courbes pour limiter les interférences.

    Les logiciels sont parfois pénibles pour le choix des composants, ils demandent une référence précise, rarement présente dans la bibliothèque fournie, quand un composant « générique » suffirait. Le choix de l’empreinte du boîtier pourrait se faire plus tard, en fonction de ce que l’on a sous la main. Cela signifie le plus souvent qu’il faut créer un composant et dessiner ou choisir sa bonne empreinte.

    Parfois l’outil propose de faire des bibliothèques de schémas (par exemple, un IC avec ses capacités de découplage). Attention, si l’outil ne génère pas de schéma « à plat », il sera difficile de savoir à quoi correspond la résistance R25 de la carte.

    Circuit imprimé (PCB)

    Pour réaliser un circuit imprimé — Printed circuit board (PCB) —, il faut convertir le schéma électrique en un schéma d’implantation (layout) en respectant plusieurs contraintes : l’encombrement des composants, leur orientation, les dimensions des pistes, etc.

    Une carte classique est composée d’une feuille d’époxy de quelques millimètres d’épaisseur, ayant une ou deux couches de cuivre. C’est le fameux circuit imprimé ou PCB.
    PCB

    Il n’est pas toujours nécessaire de fabriquer ce genre de carte. Il existe des cartes à trous métallisés ayant des espacements standardisés (2,54 mm comme pour les composants DIP, 1,27 ou 1 mm pour les composants de montage en surface CMS). Les connexions se font avec des morceaux de fil. Si la carte est complexe, cela peut être long et fastidieux à souder, mais cela ne nécessite pas d’outillage particulier, en dehors d’un fer à souder et de l’huile de coude.

    Cela ressemble aux anciennes cartes « wrappées ». Les composants étaient mis sur des supports ayant des pattes longues. Des fils étaient enroulés autour de ces pattes pour les relier. On se retrouvait ainsi avec une grosse couche de fils sous la carte.
    wrap— Carte wrappée – Wikinaut - Wikipédia

    Ce genre de cartes peut poser un problème de fiabilité, à cause du nombre de soudures ou de contacts. Mais les fils sont plus courts que les lignes d’un circuit imprimé, de plus les traces sont parallèles alors que les fils s’entrecroisent de façon anarchique. Ainsi, comparés aux circuits imprimés, le bruit et les parasites sont inférieurs sur les cartes utilisant des fils. Les cartes de tests peuvent alors avoir de meilleurs performances analogiques.

    Le dessin du layout

    Pour faire ces cartes, qu’il s'agisse de cartes de test à souder, ou du routage d’un schéma sur Kicad, il s’agit de placer les composants en premier, en choisissant l’emplacement des connecteurs puis le reste. Il est souhaitable de disposer de façon systématique les composants pour éviter les erreurs de soudure (soudure tête bêche), on peut faire en sorte que les inscriptions des composants se lisent toutes dans le même sens, par exemple.

    Pour router les fils, on commence en général par le +, qui doit rester au centre de la carte, la masse est plutôt à l’extérieur, en étoile, sans boucle. Cela évite les catastrophes en cas de contact avec un châssis métallique, ou avec les vis de fixation au châssis. La piste + peut être faite un peu plus large que le reste, pour la remarquer plus facilement. Il faut une grosse intensité pour avoir besoin de pistes larges pour limiter les pertes ohmiques. Mais dans ce cas, la piste de la masse a aussi besoin d’être plus large (2,5 à 5 A par millimètre de large, pour du cuivre classique de 35 µm d’épaisseur).

    Les problèmes liés à la fréquence arrivent avec des signaux de 10 MHz et plus, pour des signaux numériques (1 MHz pour l’analogique, il ne faut pas oublier les harmoniques). Au‐delà de 10 MHz, il faut tenir compte de beaucoup de paramètres, comme les retours de masse, les capacités parasites entre pistes proches, les effets inductifs, le fait que le signal avance à un peu plus de 10 cm/ns. Donc, sur un signal d’une fréquence de 1 GHz, vous pouvez voir un « ventre » ou un « creux » sur une piste de 10 cm. Il s’agit presque de la vitesse de la lumière. C’est toujours surprenant de ne pas considérer cette vitesse comme infinie.

    Les signaux analogiques nécessitent un grand soin, selon la précision voulue : une variation de 1 mV étant significative (convertisseur analogique‐numérique à 12 bits pour des signaux de 3,3 V max), une interférence peut perturber les résultats de la mesure. L’audio, par exemple, manipule des µV.

    Il est intéressant de limiter la longueur des pistes et de limiter le nombre de trous. Cela augmente la fiabilité de la carte et diminue le nombre de trous à percer. Cette phase d’optimisation n’est pas à négliger, en cas de modification manuelle de la carte. On évite de se demander pourquoi une piste semble faire trois fois le tour.

    Il ne faut pas faire des pistes fines sans besoin. Les pistes épaisses tiennent mieux à l’époxy, s’il faut ressouder un composant ou faire un trou pour en ajouter un, ou pour ajouter un composant CMS entre deux pistes proches, pour rajouter un condensateur de découplage, par exemple. Il est plus fiable de réduire la largeur d’une piste pour passer entre deux pads, que d’avoir une piste fine en continu.

    Une petite LED, dans un coin, pour visualiser la présence de l’alimentation, évite de perdre du temps en débogage. Une autre peut servir dans une carte à microcontrôleur, quand rien ne semble marcher, pour la faire clignoter.

    Les connecteurs

    HE10— Connecteurs HE10 (pas de 2,54 mm) 20 broches, mâle pour PCB et femelle auto‐dénudant pour une nappe

    C’est souvent le composant négligé par le hobbyiste, car il est rapidement coûteux. On soude directement les câbles sur les cartes. Malheureusement, la soudure les raidit et ils finissent toujours par casser (non, pas toujours, juste quand il ne fallait pas ;-)). On peut solidifier la soudure avec un serre‐joint sur le fil, passant dans deux trous faits sur la carte, mais cela prend plus de place.

    On découvre ensuite que les connecteurs à vis sont tout de même bien pratiques. Ils sont peu coûteux et laissent passer beaucoup de courant. Et puis, un jour, malgré le signe + métallisé et les points de couleur noire et rouge, on branche la batterie à l’envers. La diode de protection conduit, mais le fusible ne fond pas assez vite et toute l’électronique de puissance y passe, ou explose littéralement (vécu, avec une série de 7805).

    Il faut donc, de préférence, des connecteurs avec détrompeur. Il faut aussi des câbles (avec les connecteurs) « standards » : cela évite les catastrophes quand on intervertit deux câbles ayant les mêmes connecteurs, mais avec le câblage croisé.

    Les connecteurs ont plusieurs caractéristiques : le nombre de points de connexion, l’intensité du courant maximal, la tension maximale, mais aussi la tenue mécanique de la connexion contre les vibrations, le nombre de connexions‐déconnexions prévues (certains connecteurs ne tiennent plus au‐delà d’un certain nombre assez faible).

    Je remarque trois besoins typiques pour les connecteurs : les nappes pour connecter les cartes numériques entre elles, les connexions pour l’alimentation et la puissance, et les connexions des capteurs et/ou effecteurs (contacteur, servomoteur peu puissant…).

    Il existe une infinité de connecteurs différents, à des prix très différents également. Pour la puissance (batterie ou moteur), j’aime bien les connecteurs type « molex » : ceux que l’on trouve dans les PC. Ils sont bon marché, tiennent mécaniquement, et laissent passer beaucoup de courant.

    Concernant les données, les connecteurs de type HE10, qui s’utilisent avec des nappes du genre de l’IDE 33 (oui, je suis vieux), sont assez pratiques. On trouve bien mieux en termes de densité, mais ceux‐ci sont plus faciles à souder. Il ne faut pas oublier qu’un fil de données ne supporte pas plus de 1 A, mais on peut toujours faire plusieurs lignes d’alimentation et de masse (attention, cela fonctionne toujours par paire, il ne faut pas oublier le retour du courant par la masse).

    Attention aux connecteurs RCA, les connecteurs ronds utilisés en audio, ils ne sont pas construits pour être défaits souvent, et finissent par ne plus tenir. De plus, n’étant pas conçus pour la puissance, il n’est pas souhaitable d’y faire passer plus de 1 A. Donc, c’est à oublier comme connecteur de batterie.

    Mais pourquoi utiliser des connecteurs ?

    Si vous le pouvez (une carte numérique, au lieu de deux) et si vous avez le choix, je vous conseille de tout mettre sur la même carte. Pas de connecteur est toujours plus fiable. De plus, cela simplifie le routage de la carte. On évite plein de fils qui se dirigent vers le même endroit : le connecteur de nappe.

    Méfiez‐vous de la fausse réutilisation, qui coûte cher en temps de travail, mais qui ne servira jamais, surtout si vous êtes contraint par l’espace, donc par la taille et la forme des cartes. La réutilisation de schéma permet de faire déjà beaucoup de choses.

    Pour les capteurs, il existe beaucoup de connecteurs linéaires au pas de 2,54 mm (le DIP standard), jusqu’à une dizaine de connexions à fils. Les contacteurs, comme les switches mécaniques, ont des plots à souder : il n’est donc pas possible d’utiliser une nappe classique.
    microswitch—Switch mécanique

    Je vous conseille les connecteurs qui disposent de systèmes auto‐dénudant. Les autres systèmes imposent de souder chaque fil, à un bout de métal minuscule, avant d’être introduits dans un support plastique. Cela peut représenter un gain de temps précieux et une plus grande fiabilité : on rentre tous les câbles, puis on clippe un support et c’est terminé.

    Évitez aussi d’avoir plusieurs types de connecteurs vaguement compatibles, vous n’aurez jamais les bons câbles sous la main, ou alors les connecteurs entrés en force pourraient abîmer les connecteurs mâles des PCB, voire les contacts seraient mauvais, ce qui introduit des pannes aléatoires. Vous ne voulez pas de pannes aléatoires.

    Il est aussi possible d’acheter un rouleau de petites nappes (avec chaque fil qui se sépare) et les connecteurs qui vont avec, pour être le plus « standardisé » possible.

    Du simple câble réseau doit pouvoir faire l’affaire. Il faut, en revanche, avoir l’outil pour sertir correctement les fils dans les connecteurs RJ45. Dans le cas d’usage d’un câble blindé, il faut respecter la règle de répartition en étoile, et ne surtout pas faire de boucle de masse (cela génère beaucoup de parasites, par induction) et donc ne connecter le blindage que d’un coté du câble. La dernière précaution est de ne pas mélanger les connections avec celles d’un réseau Ethernet, au risque de griller quelque chose.

    Support de circuit intégré (IC)

    Un support n’est pas toujours nécessaire pour les composants, même complexes, comme les circuits intégrés. On veut souvent facilement changer un composant grillé, mais un tel support peut être plus coûteux que le composant lui‐même. Il est souvent possible de dessouder deux ou trois fois un composant avant d’abîmer les pistes.

    Il est aujourd’hui facile de prévoir deux broches de programmation. Le temps où il fallait un programmateur d’EEPROM, produisant du 12 V pour les microcontrôleurs, est révolu.

    Les radiateurs

    Les radiateurs permettent d’évacuer la chaleur produite par un composant de puissance. Le but est d’éviter la destruction du composant par augmentation de la température, ou sa coupure par mise en sécurité.

    Pour des questions de solidité, il vaut mieux que celui‐ci soit vissé à la carte, au lieu de simplement tenir sur le composant. Ces radiateurs sont souvent en matériau conducteur, les bons conducteurs thermiques étant souvent de bons conducteurs électriques. Or, la plupart des éléments de puissance ont une de leurs pattes connectée à la partie métallique de leur boîtier.

    Attention à la proximité de plusieurs composants type TO-220, dont une partie du boîtier est métallique et conductrice. Attention aussi au contact avec un châssis, souvent relié à la masse.

    Il ne faut pas oublier non plus que du cuivre sur le PCB peut être utilisé dans une certaine mesure, comme dissipateur thermique.

    Un gros radiateur coûte cher. Un radiateur de processeur de PC est construit pour évacuer une centaine de watts de chaleur, cela peut être un très bon compromis efficacité/prix. Mais si vous avez besoin de dissiper autant de chaleur, il faudrait plutôt repenser la fonction.

    Les batteries

    Il existe plusieurs sortes de batteries. Les différences se situent sur le poids par rapport à l’énergie embarquée, mais aussi sur la quantité de courant maximum que l’on peut tirer et leurs fragilités.

    La batterie au plomb est la plus ancienne technologie. On en trouve de 6 ou 12 V avec des charges différentes. Cette charge s’exprime en Ah (Ampère fois des heures et non par heure). Une batterie 2 500 mAh, peut débiter 1 125 mA pendant 2 h ou 10 A pendant 15 minutes.

    Une batterie au plomb peut se charger avec une alimentation de labo, dont on utilise la limitation en courant. En général, on charge en 1 h ou plus pour ne pas user la batterie. Une batterie de 2 500 mAh, se charge donc avec un courant de 2,5 A pendant une heure ; voire, si on a le temps, avec un courant de 250 mA pendant 10 h (une nuit). Une charge lente évite la surchauffe, et la fait durer plus longtemps.

    Une batterie au plomb peut fournir 10 C sans problème. Cela veut dire qu’une batterie au plomb de C = 2 500 mA.h, peut fournir 25 A.

    Les piles rechargeables actuelles ont fait beaucoup de progrès pour supprimer l’effet mémoire. L’auto‐décharge a aussi baissé. Il y a quelques années une pile rechargeable pouvait se vider toute seule en six mois. Une pile rechargeable fournit 1,2 V (et non 1,5 V comme les piles alcalines), ce qui peut être pénalisant pour réaliser des tensions de 12 V (10 modules).

    Il n’est pas conseillé de faire débiter plus de 1 C à des batteries AA, sous peine de les user très vite, car elles chauffent. Attention aussi à la recharge, un accumulateur Ni‐Cd oublié sur une alimentation finit par dégager une fumée blanche irritante, très désagréable (vécu). Les piles rechargeables Ni‐Cd sont aujourd’hui difficilement trouvables (voire interdites en UE). Il vaut mieux utiliser un vrai chargeur dédié. Les piles rechargeables NiMH sont moins nocives.

    Il existe aussi des accumulateurs lithium‐ion, des modules de 3 V, que l’on trouve dans les batteries des ordinateurs portables. La densité d’énergie est encore plus élevée. On peut récupérer quelques modules fonctionnels, dans une batterie de portable « morte ».

    Il existe les batteries au lithium‐polymère, qui sont une version plate du modèle précédent. La batterie peut prendre toute sorte de formes. Sa densité énergétique est élevée. Ce genre de batterie est notamment utilisé en aéromodélisme. En revanche, une telle batterie peut s’enflammer en cas de gros choc. Vous pouvez trouver sur Internet des photos de sièges automobiles brûlés, après que des modélistes aient oublié leur batterie en train de charger, sur l’allume‐cigare.

    Si vous oubliez une batterie sur une alimentation de laboratoire et que vous dépasser son temps de charge, elle va chauffer d’autant plus que le courant est fort. La chaleur diminue la durée de vie de la batterie, voire celle‐ci peut s’enflammer.
    fusible— Des fusibles souvent utilisés pour protéger une carte

    Les circuits imprimés (PCB)

    Un circuit imprimé ou PCB est le support des composants. Il existe deux méthodes de fabrication, par fraiseuse ou par insoleuse. Par fraiseuse, l’outil retire mécaniquement le cuivre en dehors des pistes du circuit.

    Par insoleuse, une plaque d’époxy est couverte de cuivre et de résine photosensible. Un masque (typon) est posé dessus et le tout est mis dans une insoleuse. La résine soumise aux UV de l’insoleuse est ensuite retirée par un bain, seule reste la résine sous le masque, puis la plaque est plongée dans un acide. Le cuivre non protégé est dissous.

    Pour faire un double face, il faut utiliser une plaque ayant du cuivre des deux côtés. Pour plus de faces, les plaques sont collées entre elles. Il existe des PCB à plus de 12 couches (le maximum que j’ai vu est 24).

    Il existe une grande quantité d’information disponible sur Internet pour savoir comment réaliser cela en pratique. Une grande partie de la qualité du résultat dépend du masque, les résines étant très (très) précises.

    Le masque est souvent réalisé, avec une impression sur un transparent. Or, si l’on regarde un transparent à la loupe, on voit une série de fissures, dans les traits normalement opaques. On retrouve toutes ces micro‐fissures sur les pistes de cuivre. Si la piste est trop fine, cela peut introduire des coupures. Ces coupures peuvent être réduites en utilisant des pistes assez larges, ou bien en repassant un peu de soudure (c’est fastidieux).

    Le résultat peut être amélioré en opacifiant les zones noires du transparent avec un feutre. Il semblerait que les transparents faits avec une imprimante jet d’encre, soient plus efficaces qu’avec une imprimante laser. Certaines personnes ont déjà modifié une imprimante jet d’encre, pour remplacer les trois encres couleur par de l’encre noire, pour avoir un noir plus profond. Il est aussi possible d’utiliser 2 transparents superposés.

    On peut faire faire un circuit imprimé sur Internet pour moins de 100 €. Les tirages coûtent en fonction de la surface d’époxy, ou alors le prix est celui du grand panneau d’époxy utilisé à la base, qui peut permettre de faire un certain nombre de plaques à la fois. Les fabricants les moins chers limitent aussi le nombre de types différents de trous qui entraînent des changements d’outils. La finesse des pistes est aussi un paramètre à prendre en compte : est‐il possible de faire passer deux fils entre les deux pattes d’un composant DIP ou un seul ?

    Les composants traversants tel qu’on les connaît, ont tendance à être remplacé par les CMS. Il est très facile d’utiliser les composant 0805 et plus. Cela veut dire 0,8 mm × 0,5 mm. Il existe aussi des 1206. Le 0604 est, en revanche, plus difficile à souder. Les composants CMS évitent beaucoup de trous, c’est intéressant si l’on doit les faire soi‐même.

    En résumé, concevoir et souder un PCB CMS n’est pas si complexe, la production de la carte elle‐même peut l’être un peu plus.

    Vous pouvez reprendre une activité normale (comme regarder les réseaux sociaux).

    Merci à BAud, Yves Bourguignon, kantien, palm123, pulkomandy, gusterhack pour leur relecture.

    Lire les commentaires

  • Projet de tableau numérique interactif à base de Wiimote (Laboratoire Linux SUPINFO)

    Note: Cet article est le compte-rendu d'un projet personnel visant à créer un tableau numérique interactif avec une Wiimote comme composant principal. Vous pouvez télécharger le code source du logiciel ici (celui-ci se présente sous la forme d'un projet pour l'IDE Code-Blocks).

     

    1. L'idée du projet

    L'idée de ce projet m'est venue au cours d'une session sur le web. Je suis tombé sur un site qui vantait les mérites de ce qu'il appelait le TNWii ; c'est à dire un tableau numérique interactif basé sur les capacités des Wiimotes de la console de Nintendo.
    Le concept à été imaginé par Johnny Chung Lee, un chercheur sur les interactions homme-machine employé chez Microsoft. Il a pensé à réutiliser les caractéristiques de la manette de la console Wii et de la détourner afin d'en trouver d'autres utilisations.
    L'intérêt de cette manette est son capteur infrarouge. Il suffit de lui montrer une ou plusieurs source de lumière infrarouge et d'avoir le logiciel adéquat afin d'obtenir un outil de suivi de points basique. De plus, la Wiimote n'est pas filaire et utilise le protocole Bluetooth, ce qui permet donc de la relier facilement à un ordinateur.
    Johnny Chung Lee a abouti, entre autres choses, à la création d'un tableau numérique interactif. Son idée ayant fait des émules, différents logiciels ont été créés pour améliorer la chose, chacun fournissant plus ou moins de fonctions.
    Mais ces programmes sont en grande majorité écrits pour Windows, et n'ayant personnellement pas réussi à faire fonctionner les rares conçu pour les systèmes Linux, ainsi qu'étant curieux de connaître le fonctionnement d'un programme agissant avec un matériel de ce type, je me mis en tête de coder un logiciel basique pour Linux permettant de faire fonctionner la manette dans le cadre d'un tableau numérique.
    Bien qu'ayant un but fonctionnel, ce projet était principalement voué à m'apprendre des techniques avancées de programmation ainsi que le fonctionnement de petits matériels électronique.

     

    2. Description générale du tableau interactif et recherches préliminaires

    Le tableau interactif est constitué de quatre composants :

    • un projecteur qui affiche l'image de l'ordinateur contre un mur, un écran ou tout autre surface lisse.
    • un stylet infrarouge qui permet d'émettre un point de lumière sur la surface projetée afin d'indiquer un clic de souris.
    • une Wiimote qui récupère la position du point dans l'espace via sa caméra frontale et la transmet à l'ordinateur.
    • et enfin un ordinateur équipé d'un module Bluetooth (intégré ou sur un dongle USB) qui, grâce à un logiciel dédié, traite le signal reçu et effectue un clic de souris à l'emplacement du point infrarouge.

    Ceci donne donc juste la possibilité de faire un « clic gauche » de souris, mais certains logiciel plus évolués permettent d'effectuer des « clics droit » ainsi que d'autres actions.
    Possédant déjà une Wiimote ainsi qu'un ordinateur équipé d'une puce Bluetooth, il me restait donc à concevoir un stylet infrarouge ainsi qu'un programme dialoguant avec la Wiimote.

    Après quelques recherches plus poussées, je pus établir un plan des notions à assimiler et à mettre en pratique pour le développement du logiciel.
    La première chose à choisir était le langage de programmation à utiliser. J'avais tout d'abord opté pour le Python, dont l'interpréteur est très répandu sur les systèmes Linux et dont je possédait déjà des connaissances. Malheureusement, et bien que la bibliothèque de modules de Python soit très fournie, les rares modules conçus pour le support de Bluetooth sont trop anciens et obsolètes. Je me suis donc rabattu vers un autre langage de plus bas niveau : le C.
    Une interface graphique étant prévue pour mon logiciel, je choisis la bibliothèque graphique GTK+ car je l'avais déjà utilisé en Python.
    Ensuite il me fallait pouvoir communiquer avec la Wiimote. Or n'ayant aucune connaissance du protocole Bluetooth, j'allais devoir apprendre son fonctionnement.
    Une fois ceci fait, je devrai faire de même pour connaître la marche interne de la Wiimote ainsi que les commandes à lui envoyer pour lui faire effectuer les actions voulues.
    Il me resterai ensuite la création de l'algorithme de traitement des coordonnées des points infrarouges sur l'image projetée et leur interprétation pour les placer sur l'image réelle de l'écran d'ordinateur.
    Enfin, le tableau blanc interactif n'étant pas constitué de la seule Wiimote et d'un programme, il me fallait une source de lumière infrarouge qu'elle puisse capter. Cette source infrarouge serait incarnée ici sous la forme d'un stylet à construire moi-même.

    La liste des choses à faire ainsi que le choix des technologies faits j'allais pouvoir débuter la conception de mon TNWii.

     

    3. Construction de l'interface et prise en main du protocole Bluetooth

    J'ai donc commencé par faire un schéma afin de bien savoir visualiser ce qu'il y avait à construire au niveau de l'interface.

    Schéma d'interface du logiciel de tableau numérique à base de Wiimote.

    Cette interface est simple mais suffit à obtenir quelque chose de fonctionnel.

    La concrétisation de ce schéma ne m'a pas posé de vrai problème. Une fois que l'on a saisi le fonctionnement de la bibliothèque GTK+ la construction d'une interface n'est pas très compliquée.
    Voici par exemple ce que cela donne sur mon ordinateur :

    Interface du logiciel

    Là où les choses sont devenues plus difficiles, c'est lorsque j'ai dû utiliser le protocole Bluetooth. Celui-ci utilise les mêmes concepts de sockets que la programmation réseau classique, mais n'ayant pas non plus eu l'occasion de pratiquer cette dernière, j'ai dû tout apprendre de zéro. Cela m'a permis entre autre d'acquérir les notions de sockets, threads, mutex et endianess spécifiques à la programmation réseau.
    Mais au départ, j'ai quand même eu des problèmes pour trouver des ressources sur l'utilisation de la bibliothèque Bluez permettant l'accès à la pile Bluetooth sous Linux. Que ce soit en Français ou en Anglais, il y a très peu de documentation sur le sujet. C'est pourquoi, lorsque j'ai pu en trouver une de très bonne qualité, j'en ai effectué une traduction vers le Français car elle pourrait être très utile à tout développeur voulant utiliser le Bluetooth sous Linux.
    Ce document détaille l'utilisation des protocoles RFCOMM et L2CAP (équivalents de TCP et UDP) et donne des exemples d'implémentation. La version originale est disponible ici et ma traduction ici.

     

    4. Fonctionnement de la Wiimote

     

    4.1 Établissement de la connexion Bluetooth

    Le deuxième gros morceau de nouveauté à été la Wiimote. Connaître son fonctionnement n'est pas inné. Heureusement des hackers (au sens premier du terme, à savoir "bidouilleurs") ont effectué un gros travail de rétro-ingénierie, ce qui à aboutit à une documentation détaillant l'utilisation de chaque fonctionnalité pour les programmeurs et qui sera ma principale source de savoir.
    Je vais expliquer ici son fonctionnement en Français, car c'est l'un des buts de ce projet. Attention cependant, beaucoup de notions propres à Bluetooth sont utilisées donc il vaut mieux être à l'aise avec ce dernier.
    Pour établir la connexion avec la manette on utilise donc le protocole Bluetooth, mais il n'est pas nécessaire (bien que ce soit possible) d'effectuer un « pairing » avec celle-ci. Il suffit juste de la placer en mode découverte en appuyant sur le bouton « sync » (situé dans le compartiment des piles). Il est aussi possible, pour les Wiimote de première génération, d'appuyer sur les boutons 1 et 2 en même temps pour lancer le mode découverte.
    Le "nom convivial" (traduction de "friendly name") envoyé alors est RVL-CNT-01 pour les Wiimotes de première génération et RVL-CNT-01-TR pour celles de seconde génération.
    Une fois la découverte activée, deux PSM du protocole L2CAP sont prévus pour communiquer. Le PSM 0x11 est utilisé pour le flux de contrôle et le 0x13 pour le flux de données, bien que dans la réalité le 0x11 soit quasiment inutilisé.

    Note: Pour rappel, le protocole L2CAP est en quelque sorte un équivalent de UDP en Bluetooth et les PSM (pour « Protocoles Services Multiplexers ») sont les noms des ports de ce protocole. Ces numéros de PSM étant donnés en hexadécimal, nous avons ici donc en réalité les ports 17 et 19.

    Il suffit donc pour établir une connexion avec la manette, de la détecter, de récupérer son adresse MAC et d'y connecter un socket avec comme contexte d'adressage les informations données ci-dessus.

     

    4.2 Schéma général des communications

    Ensuite nous pouvons réellement dialoguer avec la Wiimote. Cela se fait par l'envoi de ce que l'on appel des rapports. Les rapports sont des messages constitués d'une suite d'octets dont la valeur est écrite en hexadécimal et qui suivent un format précis.
    Chaque type de rapport ne peut être envoyé que dans un sens. Un rapport entrant se fait dans le sens périphérique -> hôte et sera préfixé d'un octet contenant 0xa1 , alors qu'un rapport sortant se fait dans le sens hôte -> périphérique et débutera lui par un octet contenant 0xa2.

    Voici la liste des types de rapports disponibles pour communiquer avec la Wiimote :

    Sens ID Taille Fonction
    Sortant 0x10 1 Inconnue
    Sortant 0x11 1 Allumage des LEDs
    Sortant 0x12 2 Choix du mode de rapport pour les données envoyées par la Wiimote
    Sortant 0x13 1 Allumage de la caméra infrarouge (1ère partie)
    Sortant 0x14 1 Allumage du haut-parleur
    Sortant 0x15 1 Requête de demande de status
    Sortant 0x16 21 Écriture dans une mémoire ou un registre
    Sortant 0x17 6 Lecture d'une mémoire ou d'un registre
    Sortant 0x18 21 Envoie de données au haut-parleur
    Sortant 0x19 1 Passer le haut-parleur en muet
    Sortant 0xa 1 Allumage de la caméra infrarouge (2ème partie)
    Entrant 0x20 6 Informations de statut de la Wiimote
    Entrant 0x21 21 Données renvoyées lors de la lecture des mémoires et registre
    Entrant 0x22 4 Acquittement d'un rapport sortant (résultat du traitement du rapport ou code erreur)
    Entrant 0x30-0x3f 2-21 Données renvoyées par la Wiimote après le choix du mode de rapport de données.

    Les rapports envoyés ou reçus auront donc la forme suivante :

    Note: Dans la suite, pour les exemples de rapport comme celui ci-dessous, je n'inscrirai pas les 0x au début de chaque octet (bien qu'ils soient en notation héxadécimale) afin de rendre le contenu plus lisible.

    a1 30 00 00

    Ce rapport sera par exemple un rapport entrant (0xa1) contenant des données reçues de la Wiimote (0x30) et dont les deux derniers octets sont les données en question.

    Pour rappel, mon but est de localiser les points infrarouges vus par la Wiimote en récupérant leur coordonnées. Pour obtenir ces coordonnées il lui faut faire nous envoyer un rapport de données (les types 0x30 à 0x3f). Mais il existe plusieurs modes de rapports de données, chacun permettant de récupérer un contenu différent. Il faut donc sélectionner le mode de rapport que l'on veut obtenir. Cela se fait par l'envoi d'un rapport de type 0x12 dédié spécialement à ce choix.
    Le type de rapport 0x12 se présente ainsi :

    a2 12 TT MM

    Nous avons donc un premier octet pour le sens du rapport, un second pour le type, puis deux octets de contenu.
    Le premier octet de contenu, ici nommé TT, permet en activant son bit 2 (c'est à dire en mettant sa valeur à 0x04) de spécifier à la Wiimote que l'on veut qu'elle envoie des rapports de données en continu même si les valeurs sont restées inchangées. S'il est laissé à 0x00, ces rapports ne seront envoyés qu'à chaque changement de valeur.
    Le second, nommé MM, permet de choisir le mode de rapport proprement dit.
    Voici les différents modes disponibles :

    ID Contenu
    0x30
    a1 30 BB BB
    Ce mode retourne 2 octets ( BB ) contenants les valeurs des boutons appuyés de la Wiimote
    0x31
    a1 31 BB BB AA AA AA
    Ce mode retourne :
    • 2 octets ( BB ) contenants les valeurs des boutons appuyés
    • 3 octets ( AA ) contenants les données de l'accéléromètre
    0x32
    a1 32 BB BB EE EE EE EE EE EE EE EE
    Ce mode retourne :
    • 2 octets ( BB ) contenants les valeurs des boutons appuyés
    • 8 octets ( EE ) contenants les valeurs d'un périphérique d'extension que l'on peut brancher à la manette
    0x33
    a1 33 BB BB AA AA AA II II II II II II II II II II II II
    Ce mode retourne :
    • 2 octets ( BB ) contenants les valeurs des boutons appuyés
    • 3 octets ( AA ) contenants les données de l'accéléromètre
    • 12 octets ( II ) contenants les coordonnées des points détectés par la caméra infrarouge
    0x34
    a1 34 BB BB EE EE EE EE EE EE EE EE EE EE EE EE EE EE EE EE EE EE EE
    Ce mode retourne :
    • 2 octets ( BB ) contenants les valeurs des boutons appuyés
    • 19 octets ( EE ) contenants les valeurs d'un périphérique d'extension que l'on peut brancher à la manette
    0x35
    a1 35 BB BB AA AA AA EE EE EE EE EE EE EE EE EE EE EE EE EE EE EE EE
    Ce mode retourne :
    • 2 octets ( BB ) contenants les valeurs des boutons appuyés
    • 3 octets ( AA ) contenants les données de l'accéléromètre
    • 16 octets ( EE ) contenants les valeurs d'un périphérique d'extension que l'on peut brancher à la manette
    0x36
    a1 36 BB BB II II II II II II II II II II EE EE EE EE EE EE EE EE EE
    Ce mode retourne :
    • 2 octets ( BB ) contenants les valeurs des boutons appuyés
    • 10 octets ( II ) contenants les coordonnées des points détectés par la caméra infrarouge
    • 9 octets ( EE ) contenants les valeurs d'un périphérique d'extension que l'on peut brancher à la manette
    0x37
    a1 37 BB BB AA AA AA II II II II II II II II II II EE EE EE EE EE EE
    Ce mode retourne :
    • 2 octets ( BB ) contenants les valeurs des boutons appuyés
    • 3 octets ( AA ) contenants les données de l'accéléromètre
    • 10 octets ( II ) contenants les coordonnées des points détectés par la caméra infrarouge
    • 6 octets ( EE ) contenants les valeurs d'un périphérique d'extension que l'on peut brancher à la manette
    0x3d
    a1 3d EE EE EE EE EE EE EE EE EE EE EE EE EE EE EE EE EE EE EE EE EE
    Ce mode retourne :
    • 21 octets ( EE ) contenants les valeurs d'un périphérique d'extension que l'on peut brancher à la manette
    0x3e-f
    a1 3e BB BB AA II II II II II II II II II II II II II II II II II II
    a1 3f BB BB AA II II II II II II II II II II II II II II II II II II
    Les rapports 0x3e et 0x3f sont, lorsqu'ils sont choisit, envoyés alternativement par la manette et retournent :
    • 2 octets ( BB ) à chaque rapport contenants les valeurs des boutons appuyés
    • 2 octets ( AA ) sur deux rapports (donc à ré-assembler) contenants les données de l'accéléromètre
    • 36 octets ( II ) sur deux rapport (donc à ré-assembler) contenants les coordonnées des points détectés par la caméra infrarouge

    Note: Dans la suite, je ne détaillerai que les types de rapport dont je me suis servi. C'est à dire majoritairement ceux en lien avec la caméra infrarouge de la manette.

    Suivant les différents modes, on peut constater que le nombre d'octets renvoyés pour les données infrarouge varie. Pour savoir quelle en est la raison, il faut se pencher sur le format de ces données renvoyées.

    4.3 Allumage et configuration de la caméra infrarouge

    La caméra de la Wiimote a une résolution native de 128x96, qui est ensuite augmenté 8 fois par un processeur interne faisant une analyse sous-pixel, et qui permet d'atteindre une résolution de 1024x768. La manette est capable de renvoyer au total les coordonnées de 4 points infrarouges.

    L'allumage et l'initialisation de la caméra se fait par l'envoi d'une suite de commande précise :

    1. Il faut en premier lieu l'activer en lui envoyant un rapport 0x13 dont le bit 2 de l'octet de charge utile sera à 1. Cette octet de charge utile aura donc la valeur finale de 0x04. :
      a2 13 04
    2. Puis faire de même en lui envoyant un rapport 0x1a dont le bit 2 de l'octet de charge utile sera lui aussi à 1. Cette octet de charge utile aura donc la valeur finale de 0x04. :
      a2 1a 04
    3. La troisième action consiste à écrire 0x08 dans le registre 0xb00030.
      Les registres sont des zones mémoire et écrire dedans se fait par l'envoi d'un rapport 0x16 formaté comme ceci :
      a2 16 MM FF FF FF SS DD DD DD DD DD DD DD DD DD DD DD DD DD DD DD DD

      Avec :
      • MM pour sélectionner le type de mémoire sur laquelle on veut écrire. On peut le placer à 0x04 pour sélectionner les registres (zones de mémoire vive) ou le laisser à 0x00 pour utiliser la EEPROM (mémoire morte). Il faut bien faire attention à ne pas réécrire la EEPROM et bien placer cet octet à 0x04
      • FF les octets pour choisir le registre sur lequel écrire.
      • SS pour déclarer la quantité de données à écrire (en octets).
      • DD les données à écrire. Si les données ne prennent pas toute la place disponible (ce qui est notre cas), il suffit de remplir les octets restants avec la valeur hexadécimale ff.
      En remplaçant avec nos informations, nous obtenons le paquet ci-dessous :
      a2 16 04 b0 00 30 01 08 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
    4. En quatre, il nous faut choisir la sensibilité de la caméra. Cela se fait en écrivant deux blocs de 9 et 2 octets respectivement dans les registres 0xb00000 et 0xb0001a.
      Voici un tableau des différentes valeurs (retrouvées par rétro-ingénierie) pour les deux blocs de sensibilités :
      Bloc 1 Bloc 2 Notes
      00 00 00 00 00 00 90 00 C0 40 00  
      00 00 00 00 00 00 FF 00 0C 00 00 Sensibilité maximale
      00 00 00 00 00 00 90 00 41 40 00 Haute sensibilité
      02 00 00 71 01 00 64 00 fe fd 05 Wii niveau 1
      02 00 00 71 01 00 96 00 b4 b3 04 Wii niveau 2
      02 00 00 71 01 00 aa 00 64 63 03 Wii niveau 3
      02 00 00 71 01 00 c8 00 36 35 03 Wii niveau 4
      07 00 00 71 01 00 72 00 204 1f 03 Wii niveau 5
      C'est le dernier octet du bloc 1 qui détermine l'intensité de la sensibilité, et plus sa valeur est grande, moins la sensibilité est élevée. Il est recommandé de placer la sensibilité aussi haut que possible, en évitant la pollution lumineuse autre que le stylet, pour pouvoir bénéficier au maximum de l'analyse sous-pixel du processeur de la Wiimote. Plus la sensibilité est réduite, plus la résolution sous-pixel l'est aussi, et plus on se rapproche de la résolution native de la caméra (128x96).
      Nous envoyons donc les deux rapports afin d'écrire dans les registres la sensibilité choisie :
      // Rapport d'écriture du bloc 1
      a2 16 04 b0 00 00 09 00 00 00 00 00 00 ff 00 0c ff ff ff ff ff ff ff
      // Rapport d'écriture du bloc 2
      a2 16 04 b0 00 00 02 00 00 ff ff ff ff ff ff ff ff ff ff ff ff ff ff
    5. La cinquième étape consiste au choix du mode d'envois des données par la Wiimote. Il existe trois modes différents renvoyant chacun des données de tailles différentes. Ces tailles correspondants à celles des différents modes de rapports de données vus plus haut. Il faudra donc choisir le mode de rapport de la Wiimote suivant le mode de données choisit pour la caméra.
      Mais ce qu'il faut savoir tout d'abord, c'est la façon dont la manette gère les points qu'elle voit. Elle dispose de quatre slots et lorsqu'elle reconnaît un point lumineux, elle l'associe aux premier slot disponible. C'est à dire que si un objet sort de son champs de vision puis revient, il retrouvera le numéro de slot qu'il avait auparavant.
      Ci-dessous un petit tableau des modes disponibles :
      Mode
      Numéro du mode
      Basique
      1
      Étendu
      3
      Complet
      5
      Et voici un descriptif de chaque mode :
      • En mode basique, la caméra retourne 10 octets de données correspondants aux coordonnées X et Y de chaque point. Chaque coordonnées est codée sur 10 bits et s'étend de 0 à 1023 pour les X et de 0 à 767 pour les Y. Les données retournées sont divisées en deux paquets de 5 octets contenants chacun les coordonnées de 2 points.
        Voici un schéma pour comprendre comment sont répartis les bits de chaque point :
         
        Bit
        Octet
        7
        6
        5
        4
        3
        2
        1
        0
        0
        X1
        1
        Y1
        2
        Y1
        X1
        Y2
        X2
        3
        X2
        4
        Y2
      • Le mode étendu est quasiment similaire au mode basique, à part le fait qu'une information en plus est embarquée pour chaque point, à savoir sa taille. Cette taille est une valeur estimé et va de 0 à 15. L'ajout de cette valeur fait que chaque point est codé sur 3 octets entiers. Il faut donc au total 12 octets pour transporter les valeurs des 4 points.
        Ci-dessous un tableau détaillant la façon dont sont organisés les bits de chaque points :
         
        Bit
        Octet
        7
        6
        5
        4
        3
        2
        1
        0
        0
        X1
        1
        Y1
        2
        Y1
        X1
        S
      • Enfin, en mode complet, chaque point est codé sur 9 octets. Les trois premiers octets contiennent les même informations que le mode étendu, auquel on ajoute les coordonnées de la surface englobant chaque point ainsi qu'une valeur de l'intensité perçue du point. Il faut donc un total de 36 octets pour transporter toutes ces informations, ce que seul permettent les rapports 0x3e et 0x3f combinés.
        Voici le schéma correspondant à la façon dont sont organisés les bits de chaque point dans ce mode :
         
        Bit
        Octet
        7
        6
        5
        4
        3
        2
        1
        0
        0
        X1
        1
        Y1
        2
        Y1
        X1
        Y2
        X2
        3
        0
        X min
        4
        0
        Y min
        5
        0
        X max
        6
        0
        Y max
        7
        0
        8
        Intensité
    6. Enfin, pour valider tous nos choix, il faut répéter l'étape numéro 3 en envoyant la valeur 0x08 au registre 0xb0003.

    Une fois cette série d'étapes effectuée, la Wiimote devrait commencer à renvoyer les octets selon le mode de rapport de données et le mode de la caméra infrarouge que l'on a choisi.

     

    4.4 Extraction des coordonnées des points reçues

    Il ne suffit pas de faire une conversion des octets reçus au format hexadécimal vers la notation décimale pour obtenir les coordonnées des points.
    Comme on l'a vu dans les tableaux précédents, les coordonnées X et Y sont chaque fois codées sur 10 bits répartis sur 2 octets. Il faut donc convertir les valeurs hexadécimales au format binaire, isoler les bits intéressants, les associer avec leurs correspondants et reconvertir le tout en décimal.
    Ça c'est pour la description rapide, je vais détailler ci-dessous la démarche complète.

    Note: Je ne traiterai ici que de la conversion d'un seul point, vu que c'est ce que j'aurai concrètement dans le cadre de mon tableau numérique. Mais de toute façon, une fois que l'on a compris la procédure avec un point, le faire pour quatre n'est pas plus compliqué.

    Tout d'abord, il faut savoir que j'ai choisi le mode basique comme organisation des coordonnées renvoyées par la caméra infrarouge car je n'ai seulement besoin que de ces coordonnées sans informations supplémentaires. Ce mode de caméra renvoyant 10 octets, je n'ai le choix comme type de rapport de donnée qu'entre les rapports 0x36 et 0x37. J'ai personnellement opté pour le type 0x36.
    Pour rappel, les rapports que je vais recevoir de la Wiimote auront la forme suivante :

    a1 36 BB BB II II II II II II II II II II EE EE EE EE EE EE EE EE EE

    Donc, si on les numérote à partir de 0, les octets correspondants aux données infrarouges vont du numéro 4 au numéro 13. Dans ces 10 octets, les 5 premiers contiennent les coordonnées des 2 premiers points et les 5 suivants ceux des 2 derniers points. N'ayant qu'un point à convertir nous allons nous concentrer sur les données des 5 premiers octets.
    Imaginons que ceux-ci aient les valeurs suivantes :

    57 A4 30 00 00

    D'après le tableau de description du mode basique, nous pouvons savoir que :

    • le premier octet (0x57) contient les 8 bits de poids faible de la coordonnée X du premier point
    • le deuxième octet (0xA4) contient les 8 bits de poids faible de la coordonnée X du premier point
    • le troisième octet (0x30) contient les 2 bits de poids fort des coordonnées X et Y du premier et second points.

    Les autres octets contenant seulement les coordonnées du point 2, qui sont vides et ne nous intéressent pas, nous les laissons de côté.
    Nous allons maintenant convertir en binaire les valeurs de ces trois octets :

    Numéro de l'octet
    Valeur Hexadécimale
    Valeur binaire
    0
    0x57
    01010111
    1
    A4
    10100100
    2
    30
    00110000

    Grâce à ces valeurs binaire on peut recomposer les coordonnées complètes de 10 bits. Pour mieux les discerner, je les ait placées dans le tableau présentant l'organisation des bits du mode basique :

     
    Bit
    Octet
    7
    6
    5
    4
    3
    2
    1
    0
    0
    0
    1
    0
    1
    0
    1
    1
    1
    1
    1
    0
    1
    0
    0
    1
    0
    0
    2
    0
    0
    1
    1
    0
    0
    0
    0
    3
    0
    0
    0
    0
    0
    0
    0
    0
    4
    0
    0
    0
    0
    0
    0
    0
    0

    Sont coloriés en orange les bits de la coordonnée X et en bleu les bits de la coordonnée Y.
    Et maintenant en réorganisant les bits et en faisant la conversion en décimal, on obtient les coordonnées compréhensibles :

    Coordonnée
    Réorganisation en binaire
    Valeur convertie en décimal
    X
    1101010111
    855
    Y
    0010100100
    164

    La conversion est finie. Dans mon programme j'ai implémenté cette même démarche afin d'effectuer la conversion des coordonnées.

     

    5. Conversion des points vus par la Wiimote en points à inscrire sur l'écran

    Les coordonnées des points vus par la Wiimotes ne sont pas applicables directement pour l'affichage à l'écran. Ceci pour deux raisons :

    1. La caméra de la manette n'a pas forcément la même définition que l'écran sur lequel on va afficher.
    2. Les coordonnées récupérées sont définies dans le repère formé par la résolution de la caméra de la Wiimote et non par rapport à l'image projetée de l'écran qui nous intéresse.

    Pour ces deux raisons, il faut donc effectuer une conversion. Ce qui nous fait rentrer dans le domaine de la vision par ordinateur.

    Pour expliciter un peu mieux la chose rien ne vaut un schéma :

    Schéma montrant la différence de coordonnées d'un point entre ce que voit la Wiimote et sa position réelle sur la zone affichée.

    Sur ce schéma, est délimité en bleu la zone visible par la Wiimote. Celle-ci est rectangle et mesure 1024x768 pixel.
    Ensuite en vert, est symbolisé le périmètre de l'écran projeté et vu par la manette. Il n'est pas forcément aligné avec le cadre de la Wiimote suivant comment cette dernière est placée. Il n'est pas forcément rectangle pour les mêmes raisons.
    Enfin en rouge, le point infrarouge émit par le stylet.

    Il nous faut donc déduire, à partir des coordonnées du point [x, y] vues par la Wiimote, les coordonnées du point [x', y'] par rapport à l'écran projeté.
    Pour cela, il faut calculer la transformation entre les dimensions réelles de l'écran projeté (par exemple 1440x900) et celles vues par la Wiimote. Cela se fait par la résolution d'un système d'équations exprimé sous forme d'une matrice tel que décrit dans ce document.
    Des applications dans différents langages de ce document théorique sont disponibles sur cette page du forum developpez.net.
    La première application de l'utilisateur pseudocode en Java décrit la transformation inverse de celle que je doit mettre en œuvre. La seconde en C, de l'utilisateur luxigo donne la transformation dans les deux sens, mais est incomplète. Il a donc fallut que j'écrive à partir de ces exemples, la suite de calcul nécessaire à mes besoins.

    Malheureusement, n'ayant pas parfaitement compris l'algorithme en question, je me suis contenté de l'appliquer dans mon logiciel et je me garderai d'en fournir ici une explication potentiellement erronée. Je laisse cependant libre consultation de mon code si quelqu'un à besoin d'effectuer la même opération que moi à l'avenir.

     

    6. Déplacement du curseur aux coordonnées calculées

    Bien qu'amené à changer dans un futur plus ou moins proche avec l'arrivée de Wayland, les systèmes Linux utilisent actuellement le serveur d'affichage X.org. Afin de déplacer le curseur sur l'écran et de simuler des clics de souris, je me suis servis de la Xlib qui permet d'interagir avec ce serveur d'affichage.
    On peut trouver sur le Web des exemples de codes permettant de bouger le curseur assez facilement, mais pour effectuer des clics de souris cela devient très compliqué. Une façon plus méconnue d'effectuer cette action est d'utiliser une extension de la Xlib nommée XTest. Bien qu'étant une extension, elle est intégrée sur la grande majorité des distributions Linux.
    Grâce à celle-ci, les actions voulus peuvent être faites en appelant une simple fonction.
    Voici un exemple rapide :

    #include &ltX11/extensions/XTest.h&gt
    int X = 192;
    int Y = 42;
    // Création de la connexion au serveur X
    Display *d = XOpenDisplay(NULL);
    // Déplacement du curseur de la souris aux coordonnées X, Y
    XTestFakeMotionEvent(d, -1, X, Y, CurrentTime);
    // Clic de souris (bouton 1)
    XTestFakeButtonEvent(d, 1, True, CurrentTime);
    // Déclic de souris (bouton 1)
    XTestFakeButtonEvent(d, 1, False, CurrentTime);
    // Application des actions
    XSync(d, 0);

    De plus amples explications avec des liens vers d'autres exemples sont accessibles dans la bibliographie à la fin de ce document.

     

    7. Le stylet infrarouge

    Le stylet infrarouge est la seule partie matérielle de ce tableau numérique interactif à construire soit même.
    Le schéma électronique de ce stylet est des plus simple vu qu'il n'est constitué que d'une LED infrarouge, d'un interrupteur bouton-poussoir et d'une pile :

    Schéma électronique d'un stylet infra-rouge

    Seul le choix de la LED est déterminant pour le stylet. Pour ce composant, deux paramètres rentrent en compte :

    • Pour que la tâche de lumière qu'elle projette soit la plus resserrée possible, il faut choisir la LED avec un angle de demi-intensité (noté φ) le plus petit possible. Idéalement il faut qu'il soit au moins inférieur à 30°.
    • L'autre paramètre important est la longueur d'onde de la lumière émise par la LED. Il est préférable qu'elle soit comprise entre 800 et 1000nm.

    Cette LED n'étant pas un laser, il faudra tout de même la maintenir très près du support lors de l'utilisation du stylet pour que la Wiimote puisse voir la tâche de lumière qu'elle émet.

    Enfin, voici un exemple de mon stylet :

    Photo de mon stylet infrarouge

    On y retrouve tous les composant cités précédemment. En dehors du fil que je n'ai pas pu faire loger à l'intérieur, ce stylet est maniable et tiens bien en main.

     

    8. Informations sur le tableau numérique à base de Wiimote

    Voici quelques informations à savoir lorsque l'on veut mettre en place ce type de tableau interactif.
    Premièrement il possède des avantages, mais aussi des inconvénients.
    Avantages :

    • Il est très économique. En dehors du projecteur, il faut compter le prix de la Wiimote (une quarantaine d'euros), ceux des composants du stylet (j'en ai personnellement eu pour 1,75€ pour le bouton-poussoir et la LED infrarouge) et celui de l'adaptateur Bluetooth s'il n'est pas intégré à l'ordinateur que l'on souhaiter utiliser. Ceci est au final largement moins qu'un tableau interactif disponible sur le marché.
    • Installable rapidement

    Inconvénients :

    • Il faut éviter les sources infrarouges parasite. Le soleil par exemple en émet, et s'il est trop puissant, il vient diminuer le contraste entre le fond et le point infrarouge du stylet.
    • Il faut toujours veiller à ne pas se situer entre le point infrarouge et la Wiimote, ce qui oblige à tendre le bras.

    Une fois ces caractéristiques prises en compte, il y a quelques autres choses à savoir pour exploiter au mieux ce tableau interactif. Tout d'abord les angles de vision de la Wiimote sont de 33 degrés horizontalement et 23 degrés verticalement. Il faudra donc veiller à placer la manette à la bonne distance pour qu'elle puisse voir tout l'écran projeté. Pour rappel, il faudra aussi veiller à ne pas se placer entre la manette et l'écran.

     

    9. Résultat final

    Au final, j'ai réussi à concevoir le programme auquel je pensais pour qu'il soit fonctionnel. Le développement de ce logiciel m'aura permis d'apprendre de multiples notions avancées en C (sockets, endianess, threads, mutex, utilisations de bibliothèques diverses, etc). J'ai commenté le plus possible le code afin qu'une autre personne intéressée puisse le comprendre.

    De plus, j'encourage d'autres étudiants à implémenter le concept de tableau numérique pour l'utiliser en classe.

     


     

    Bibliographie

    Concept général :

    Documentations sur la programmation C nécessaires au développement du logiciels :

  • Dr. Geo 18.06 (Dépêches LinuxFR)

    GNU Dr. Geo est un logiciel de géométrie interactive euclidienne du plan, pour une utilisation à l'école secondaire et primaire. Il permet d'organiser des activités pédagogiques dans l'enseignement de la géométrie, voire d'autres domaines liés des mathématiques.
    Intégré à un environnement dynamique de programmation Smalltalk, il propose également une approche de la géométrie dynamique par la programmation, soit par l'utilisation de script(s) intégré(s) à une figure, soit par une description purement programmatique d'une construction géométrique. En outre, Dr. Geo est toujours modifiable depuis lui-même, fonctionnalité héritée de son environnement de développement.

    Dr. Geo 18.06

    La version 18.06 fait suite à la version 17.07 sortie en juillet 2017. Une grande partie de l'effort fut de porter le code de la version 3 à la version 7 de l'environnement Smalltalk Pharo avec lequel est développé Dr. Geo. Outre les corrections de bugs inhérentes à ce portage, quelques fonctionnalités nouvelles ont fait leur apparition.

    Nouvelles fonctionalités

    Dans Dr. Geo, un script est défini par une classe Pharo. L'utilisateur insère alors une instance du script dans la figure géométrique ; il lui associe si nécessaire d'autres objets géométriques de la figure en paramètres. Un script effectue un traitement ad-hoc, calculs ou modifications sur d'autres objets de la figure tels que programmés dans les méthodes du script. Une fois défini, le script est facile à utiliser.

    L'édition de script se fait maintenant à l'aide d'un outil d'édition de code dédié, et non plus par l'intermédiaire du navigateur de code de Pharo, qui est pour le moins impressionnant.

    À noter que l'ajout d'attribut au script nécessite toujours l'utilisation du navigateur de code de Pharo. Ce besoin est nécessaire uniquement lorsque le script a un état dont il doit se souvenir tout au long du cycle de vie de la figure.
    Editeur de script

    Le manuel utilisateur a une section dédiée au script.

    Inspecteur sur code de figures programmées

    Une figure programmée est l'autre forme d'utilisation de la programmation dans la géométrie dynamique. Dans cette approche la figure géométrique est entièrement définie par un code Smalltalk et l'utilisation de l'API dédiée.

    Il est dorénavant plus aisé de gérer ses fichiers de figures programmées. Le nouvel inspecteur de Pharo — outre l'inspection d'attributs d'instance de classe — propose aussi de voir, d'exécuter, d'éditer et de créer les scripts de figures programmées.
    Inspecteur sur scripts de figures programmées

    Zoom positionnel

    Pour zoomer dans une figure l'utilisateur dispose du widget de molette orange en haut à droite de chaque figure ou de la molette de la souris. Le zoom par la souris est maintenant positionnel, focalisé sur la position du curseur souris ; celui par le widget reste, lui, centré au milieu de la zone visible de la figure.

    Détection de polygone sans surface

    Lorsqu'un polygone est sans surface (vide), Dr. Geo ne détectera que ses lignes, et non plus sa surface intérieure puisqu'elle n'existe pas.
    Polygone sans/avec surface

    Tests unitaires basés sur figures programmées

    Le petit corpus de figures programmées distribué avec Dr. Geo est également utilisé pour définir une série supplémentaire de tests unitaires.

    Partage réseau

    Dans le cadre d'une activité pédagogique en salle informatique, distribuer aux élèves des fichiers de figures est pratique. Dr. Geo propose maintenant une fonctionnalité de partage en réseau local, indépendante des services du réseau local (NFS, Samba, Windows, etc.). La marche à suivre est la suivante :

    1. L'enseignant sauve les documents à partager dans son dossier DrGeo.app/MyShares : MyShares
    2. L'enseignant active le partage réseau local depuis le navigateur de préférences de DrGeo (menu Système, Préférences) : Activation du partage
    3. L'élève, depuis l'outil habituel d'ouverture de figures, parcourt les figures partagées (bouton 'Partage enseignant') : Parcourir les figures partagées

    Cette fonctionnalité peut s'utiliser de façon croisée avec Linux, Mac et Windows.

    Thèmes graphiques

    Le navigateur de préférences (menu Système, Préférences) donne accès à deux thèmes graphiques, hérités de Pharo :

    • Thème sombre, par défaut, à privilégier lorsque Dr. Geo est utilisé de façon autonome sur un seul poste.
      Thème sombre

    • Thème clair, à utiliser en vidéo projection, par exemple, car le thème sombre manque de contraste.
      Thème clair

    Option plein écran

    Depuis le menu système, l'utilisateur peut basculer en affichage plein écran ; le système hôte est alors complètement masqué. Pratique pour que les élèves se concentrent sur leur activité de géométrie dynamique.

    Les autres modifications de la version 18.06.

    Commentaires : voir le flux atom ouvrir dans le navigateur

  • Surface d'attaque des serveurs dans les nuages (cloud) (Journaux LinuxFR)

    Passionnant et très utile article sur le blog en anglais de James Bottomley (merci LWN.net pour le résumé) : il étudie la sécurité des solutions d'hébergement Cloud en se basant sur la solution retenue : serveurs dédiés, serveurs partagés, serveurs virtuels, conteneurs, et en comparant les profils d'attaques verticales et horizontales.

    Comme vous aimez les conclusions rapides, sachez déjà que la solution conteneurs l'emporte haut la main.

    Une attaque verticale c'est du code traversé : de la requête web à la base de donnée jusqu'à la réponse dans le navigateur ou l'application, et qui contient potentiellement des bugs, elle concerne uniquement votre hébergement :

    all code that is traversed to provide a service all the way from input web request to database update to output response potentially contains bugs; the bug density is variable for the different components but the more code you traverse the higher your chance of exposure to exploitable vulnerabilities. We’ll call this the Vertical Attack Profile (VAP) of the stack.

    Une attaque horizontale par contre peut se propager d'hébergement en hébergement :

    In an IaaS cloud, part of the vertical profile belongs to the tenant (The guest kernel, guest OS and application) and part (the hypervisor and host OS) belong to the CSP. However, the CSP vertical has the additional problem that any exploit in this piece of the stack can be used to jump into either the host itself or any of the other tenant virtual machines running on the host. We’ll call this exploit causing a failure of containment the Horizontal Attack Profile (HAP).

    La surveillance est répartie différemment selon l'hébergement, par exemble sur un serveur partagé l'hébergeur doit surveiller toute la pile : le matériel, le noyau, les librairies et le middleware, vous n'êtes responsable que de la couche applicative, tandis qu'avec un conteneur il surveille le matériel et le noyau hôte.

    Mais les attaques sont aussi réparties différemment. Dans un hébergement partagé, si vous attaquez le noyau vous pouvez compromettre tout le système, donc tous les hébergements tandis qu'il est plus difficile de sortir d'un conteneur.

    Compte tenu de quelques autres facteurs que je ne résume pas ici — veuillez lire cet article avant de commenter —, les équipes de sécurité de l'hébergeur bossent « mieux » avec des conteneurs, qui sont donc plus fiables, quoi qu'en dise votre contrat. Mais que ça ne vous dispense pas des opérations habituelles de base : backup, backup ET backup (sauvegarde, sauvegarde ET sauvegarde de leurs petits noms).

    Commentaires : voir le flux atom ouvrir dans le navigateur

  • Neatmail: un client mail minimaliste (Journaux LinuxFR)

    Sommaire

    J’utilise depuis quelque temps un tout petit client mail, qui ne fait vraiment que le minimum, mais a une interface si particulière, qu’il me semble intéressant de vous le présenter. Il s’agit de Neatmail écrit par Ali Gholami Rudi.

    Ali Gholami Rudi

    Je connais Ali Gholami Rudi pour une implémentation de Troff à la fois pertinente en termes de fonctionnalités et dont le code source est très propre. Il a aussi écrit un compilateur (neatcc), une libc (neatlibc), et une implémentation de vi. C’est un développeur qui, plutôt qu’une éthique, semble défendre une certaine esthétique du logiciel, que je qualifierai de minimaliste: code source compréhensible par une personne seule, logiciel qui fait peu de choses, mais le fait bien, etc.

    Neatmail le client mail qu'il s'est programmé, et celui‐ci met en scène toute l’esthétique de son auteur.

    Ce que Neatmail ne fait pas

    Neatmail ne fait que gérer un fichier mbox (une concaténation de mails). Ainsi, il ne sait ni rapatrier, ni envoyer les mails, il ne sait ni extraire, ni ajouter de pièce jointes, etc.

    Mais en vérité, il n’a pas besoin de faire tout cela, car d’autres logiciels le font. Ali Gholami Rudi propose ainsi un pop3 pour rapatrier les mails depuis un serveur pop3, et smtp pour envoyer ses mails à un serveur smtp. Et il existe dans certaines distributions un ripmime pour extraire les pièces jointes d’un fichier mime.

    Ce que Neatmail fait

    Neatmail se contente donc d’effectuer des actions sur un fichier mbox. Les actions de bases sont:

    mk Génère une liste des mails contenus dans la mbox.
    ns Génère une liste des nouveaux mails présents dans la mbox.
    pg Affiche un des mails contenu dans la mbox.

    On peut donc l’utiliser ainsi:

    # Obtient les mails
    pop3
    # liste les mails, triés par fil de discussion
    neatmail mk ‐r ‐st ‐0 18from:48~subject: mbox
    # affiche le 3e mail
    neatmail pg mbox 3
    # prépare une réponse
    neatmail pg ‐r mbox 3 > draft.eml
    vi draft.eml
    # envoie la réponse
    tail ‐n+2 draft.eml | smtp
    # garde une copie de la réponse
    cat draft.eml >> sent
    rm draft.eml

    Mais en outre, neatmail peut interpréter les commandes ex contenues dans la liste des mails. Autrement dit, l’utilisateur est invité à ajouter des commandes à cette liste de mails, et donner le tout à neatmail qui se chargera de l’exécution:

    neatmail mk ‐r ‐0 18from:48~subject > list.nm
    vi list.nm
    neatmail ex < list.nm

    Le commande ex de neatmail

    La commande ex de neatmail prend en entrée une liste de commandes, et les exécute sur un fichier mbox. Elle ignore toutes les lignes hormis celles commençant par deux points (commande ex) ou une lettre majuscule (un mail dans la liste). Les lignes commençant par une lettre majuscule de la forme "R100..", modifient le statut du message dont le nombre suit la lettre (ici, 100). Une telle ligne définit aussi le message actuel, celui sur lequel les commandes sont exécutées. Les commandes ex sont les suivantes:

    rm supprime le message courant.
    cp copie le message courant dans une mbox donnée.
    mv déplace le message courant dans une mbox donnée.
    hd modifie l’entête donnée du message courant.
    ft passe le message courant à une commande donnée.
    w écrit les modifications dans la mbox.
    tj joint les fils de discussion en modifiant l’entête "Reply‐To".
    ch coupe le message à l’offset indiqué.

    Par défaut, ces commandes agissent sur le message courant, mais il est aussi possible d’utiliser des adresses du type 2,5rm pour effacer les messages 2 à 5. Il est aussi possible d’utiliser des expressions régulières du type /regex/rm, où regex est recherché dans le sujet des messages. D’autres champs peuvent être spécifiés en utilisant l’expression ^field:value.

    Un script shell comme interface

    Vous allez certainement penser que l’interface est un peu rude… À vrai dire, Ali Gholami Rudi n’utilise pas neatmail directement: un script shell (m) lui sert d’interface. Et c’est là que le logiciel brille: pour peu que l’on ait un peu l’habitude du shell, on peut se créer une interface sur mesure. On peut par exemple imiter l’interface de mh (un autre client mail non interactif un peu oublié). On pourrait créer une interface interactive. Bref, on peut faire ce qu’on veut.

    J’utilise par exemple l’interface suivante:

    m box inbox # liste les messages contenus dans la mbox inbox.
    m vi 3 # affiche le message 3
    m next # affiche le message 4
    m repl # ouvre mon éditeur sur une réponse préformatée au message 4
    m add f.pdf # joint f.pdf à ma réponse
    m send # envoie ma réponse.
    m R # marque le message 4 comme lu.
    m com # enregistre les changements dans la mbox (ici, change l’entête du message 4)

    Conclusion

    Au jour le jour, je suis plutôt satisfait de l’ensemble. Le fait de travailler sur les mails en local est plutôt agréable: c’est fluide, offre une grande liberté d’organisation, s’associe bien à un système de sauvegarde ou de gestion de version, etc. Le fait que le client ne soit pas interactif apporte un certain confort d’usage: le shell est sous la main si besoin, je retrouve ma session de travail dans l’état où je l’ai laissée d’un jour à l’autre, il est facile d’implémenter des solutions pour revenir en arrière (cp…). Le fait de coupler le tout avec le shell offre une grande liberté dans la création de l’interface utilisateur.

    Commentaires : voir le flux atom ouvrir dans le navigateur

  • Les sources de données système sous Linux avec NSS (Laboratoire Linux SUPINFO)

    Les sources de données système sous Linux avec NSS

     

    Note: ce document est le premier d'un cycle de trois articles sur l'authentification sur les systèmes Linux. Les suivants se trouvant ici et .

    On utilise souvent la commande cat /etc/passwd pour connaitre la liste des utilisateurs d'un système Linux. Bien que le résultat renvoyé soit correct dans la grande majorité des cas, ce n'est pas la méthode que l'on devrait utiliser. En effet l'affichage du fichier /etc/passwd renvoie la liste des utilisateurs locaux uniquement. Mais si le système est relié à un serveur LDAP, les utilisateurs de ce serveur n’apparaîtront pas, bien qu'il soit possible de se connecter avec sur la machine.

     

    Name Service Switch

    La bonne méthode pour afficher la liste des utilisateurs est l'utilisation de la commande getent suivie du paramètre passwd. Celle-ci va interroger les différentes sources d'utilisateurs définies pour le système. Ces sources sont gérées par le mécanisme NSS (pour « Name Service Switch »). Et NSS ne s'occupe pas seulement des sources d'utilisateurs, mais aussi de leurs mots de passe, des groupes d'utilisateurs, des noms d'hôtes, des protocoles et services connus du système, etc.

    Cependant, bien que NSS permette de choisir les sources de données depuis lesquelles le système ira chercher les informations dont il a besoin, ce n'est pas lui qui défini les connexions vers ces sources de données.

    Voici la liste des bases de données (présentes habituellement sous la forme de fichiers plats) que l'on a l'habitude d'interroger en général et que NSS est capable de gérer :

    Bases de données Description Fichier correspondant
    aliases Alias des adresses e-mail /etc/aliases
    ethers Numéros Ethernet /etc/ethers
    group Groupes d'utilisateurs pour l'accès aux fichiers /etc/group
    hosts Correspondances entre les noms d'hôtes et les adresses IP /etc/hosts
    netgroup Groupes d'utilisateurs pour l'accès aux ressources réseau /etc/netgroup
    networks Noms et masques de réseau /etc/networks
    passwd Utilisateurs système /etc/passwd
    publickey Clés publiques utilisées par NFS et NIS+ /etc/publickey
    rpc Correspondances entre les noms et les numéros de RPC connus /etc/rpc
    services Correspondances entres les numéros de ports et les services réseau connus /etc/services
    shadow Mots de passes chiffrés des utilisateurs /etc/shadow

     

    Ces bases de données ne sont pas utilisées sur tous les systèmes, comme par exemple les aliases plutôt réservés aux serveurs mail, mais on retrouve les bases standard comme passwd, shadow ou group.

    Pour chacune de ces bases de données on va pouvoir demander à NSS d'interroger les fichiers plats locaux listés ci-dessus ainsi que diverses sources externes. Par exemple pour les noms d'hôtes, on va pouvoir configurer NSS pour interroger le fichier /etc/hosts puis les serveurs DNS.

     

    Le fichier nsswitch.conf

    La configuration de l'ordre d'interrogation des sources se fait très simplement à l'aide du fichier /etc/nsswitch.conf. Voici un fichier d'exemple issue d'un système Ubuntu :

    passwd:		compat 
    group:		compat 
    shadow:		compat 
    
    hosts:		files mdns4_minimal [NOTFOUND=return] dns mdns4 
    networks:	files 
    
    protocols:	db files 
    services: 	db files 
    ethers:		db files 
    rpc:		db files 
    
    netgroup:	nis
    

    Sur chaque ligne de celui-ci, est décrit une base de données et les sources depuis lesquelles on va chercher ces données. Chaque ligne aura donc cette forme :

    base_de_données:	source1 [STATUT=action] source2 source3

    NSS ira interroger chaque source une par une dans l'ordre dans lesquelles elles sont inscrites. Chaque interrogation d'une source renverra un statut parmi ceux listés ci-dessous et sera suivie par l'action par défaut :

    Statut Description Action par défaut
    success Succès de la récupération de la donnée recherchée. return
    notfound Accès au service de donnée réussi mais donnée non trouvée. continue
    unavail Le service est indisponible de manière permanente. Cela peut indiquer que le fichier nécessaire n'est pas lisible, ou, pour les services réseau, que le serveur n'est pas disponible ou n'accepte pas les requêtes. continue
    tryagain Le service est temporairement indisponible. Cela signifie qu'un fichier est verrouillé, et qu'un serveur ne peut pas actuellement accepter davantage de connexions. continue

     

    Il est possible de demander à arrêter ou continuer le processus entre deux sources suivant ce statut grâce à une mention du type [STATUT=action]. Cela permet d'exécuter l'action de son choix et non celle par défaut.

    L'action peut être l'une des deux suivantes :

    • return : s'arrêter ici et renvoyer les résultats trouvés
    • continue : interroger le service suivant

     

    Les sources de données disponibles

    Pour obtenir les données recherchées, on peut interroger différents services locaux ou distant comme par exemple les fichiers plats, un annuaire LDAP, une base de données SQL, etc. Par défaut les services disponibles sont files, db, nis et nisplus ainsi que compat pour les bases passwd, group et shadow. De plus, la base données hosts dispose de la source dns qui n'est utilisable que sur elle.

    Mais pour se connecter à des services plus évolués il faut disposer des bons modules. Ceux-ci se trouvent le plus souvent dans le répertoire /lib et ont un nom de la forme libnss_XXX.so.Y. Avec XXX pour le nom du service et Y le numéro de version de la glibc dans laquelle il s'intègre. Ces modules sont en grande partie installables depuis le gestionnaire de paquet de votre distribution.

    Et en voici une liste des plus courants :

    Nom du module Description
    files Utiliser les fichiers plats du système local.
    compat Similaire à files mais permet en plus d'utiliser un annuaire NIS inclus directement dans les fichiers passwd, groups et shadow et non dans le fichier nsswitch.conf. Pour plus d'informations, voir le lien correspondant à la fin de cet article.
    db Utiliser les fichiers au format Berkeley Database File.
    nis Connexion à un annuaire NIS (ancêtre de LDAP).
    nisplus Connexion à un annuaire NIS+ (version plus sécurisée de NIS).
    dns Connexion aux DNS. Utilisable seulement pour la base de données hosts.
    mdns Résolution en Multicast-DNS. Utilisable seulement pour la base de données hosts.
    ldap Connexion à un serveur LDAP
    winbind Connexion à un serveur Samba (ou Active Directory).
    cache Utilisation des fichiers de cache des noms de domaines de nscd (Name Service Cache Daemon).
    extrausers Utilisation des fichiers passwd, group et shadow situés dans le dossier /var/lib/extrausers. Ce dossier permet d'accueillir les fichiers précédemment cités venant d'autres systèmes sans copier leur contenu dans les fichiers locaux situés dans /etc.
    sshsock2 Connexion à un autre système via un socket ssh afin d'utiliser les utilisateurs de celui-ci. Valable seulement pour les bases de données passwd et group.
    lwres Lire le cache fournit par lwres (lightweight resolver). Utilisable seulement pour la base de donnnées hosts.
    mysql-bg Utilisation d'une base de données MySQL.
    pgsql2 Interrogation d'une base de données PostgreSQL.
    sss Interrogation d'un démon SSSd.

     

    La commande getent

    La commande getent citée au début de cet article permet quand à elle d'effectuer une requête pour une base de données sur les services inclus dans NSS.

    La commande est de la forme suivante :

    getent base_de_données [clé]

    La base_de_données est un nom parmi ceux listés dans le premier tableau de cet article. La clé n'est, elle, pas obligatoire. Si elle est présente, la commande n'affichera que la ligne concernant le nom recherché. Au contraire, si elle est absente, getent listera tous les éléments lorsque la base permet l'énumération.

    Par exemple, un annuaire LDAP permet l'énumération, et s'il est utilisé pour l'authentification sur votre système, vous pourrez lister tous les utilisateurs disponibles. À l'inverse, les services DNS ne permettent pas l'énumération (il est impossible de lister tous les noms de domaines existants) et vous serez obligés de fournir une clé (ici un nom de domaine) pour avoir son adresse IP correspondante.

     

    Conclusion

    On l'a vu au travers de cette article, NSS est un mécanisme qui nous permet de choisir les sources de données nécessaires au système. Il permet d'utiliser les fichiers locaux ou de déléguer la gestion de ces données à des services externes. Il est donc nécessaire lors de l'intégration d'une machine à un système centralisé.

     

    Ressources supplémentaires

     

  • Open Beauty Facts : que contiennent vraiment nos produits cosmétiques ? (Dépêches LinuxFR)

    Open Beauty Facts est un projet collaboratif en ligne dont le but est de constituer une base de données libre et ouverte sur les produits cosmétiques du monde entier.

    Après les aliments, Open Food Facts s’attelle donc à un nouveau chantier : les produits de beauté. Lancé en février 2016, Open Beauty Facts a pour but de réaliser pour les cosmétiques, dentifrices et autres shampooings ce que Open Food Facts a fait pour la nourriture.

    Logo Open Beauty Facts

    Les mêmes principes qu'Open Food Facts

    Comme pour le premier, Open Beauty Facts est un projet collaboratif, ouvert et à but non lucratif qui s’appuie sur des contributeurs qui - grâce au succès d'Open Food Facts - sont désormais aux quatre coins de la planète.

    Open Beauty Facts est donc une base ouverte de plus de 2 300 produits cosmétiques rajoutés grâce au site et à l’application.

    Open Beauty Facts (capture d'écran)

    Pourquoi ouvrir des cosmétiques ?

    Ouvrir des produits de beauté avant de les utiliser, c'est du bon sens ! Une fois la liste des ingrédients ouverte, il est possible de les déchiffrer/traduire pour savoir ce que l'on se met vraiment sur le corps. Que veulent dire tous ces « Numéros CI » et « methyl-» « hexyl » « polyol » ? Qui connaît les dizaines de milliers de codes et noms latins pour les ingrédients cosmétiques ?

    Pour les produits alimentaires auxquels Open Food Facts s'est attaqué, on comprend à peu près la liste des ingrédients, mais pour les cosmétiques il faut littéralement parler latin et être chimiste.

    Mettre la composition des cosmétiques dans une base de données ouverte permet également de comparer très facilement les produits entre eux. En quelques clics vous pouvez ainsi générer des comparatifs qui permettent d'éviter les ingrédients suspects.

    Comment ça marche ?

    Chaque produit est recensé par son code barre, et les informations relatives à ce produit sont renseignées par les contributeurs à partir des informations présentes sur l'emballage. On trouve par exemple les ingrédients, les allergènes, le lieu d'emballage et bien d'autres encore.

    Détecter les ingrédients indésirables

    Parabènes, libérateurs de formaldéhyde, substances parfumantes allergènes, silicones, phénoxyéthanol, triclosan, cetrimonium bromide, méthylisothiazolinone, sels d'aluminium.
    Quels que soit leur nom, l'abréviation ou la langue dans laquelle ils sont mentionnés, Open Beauty Facts est capable de détecter et déchiffrer les ingrédients suspects.

    Un produit sur Open Beauty Facts

    De plus, sur des produits comme les vernis à ongles, non seulement les ingrédients sont en anglais, latin et avec des abréviations, mais ils sont littéralement cachés sous l'étiquette.

    Des ingrédients cachés sous une petite étiquette à décoller - loupe requise

    Comment ajouter des produits ?

    Pour ajouter un produit à la base de données, le plus simple est d'installer l'application pour téléphones. Il en existe une pour Android et les versions IOS et Windows Phone arrivent. Il ne reste plus qu'à scanner le code barre du produit (cela vérifie qu'il n'est pas déjà dans la base), prendre quelques photos (le recto et les ingrédients). Ensuite, si vous le souhaitez, vous pouvez saisir les informations sur le produit avec la version web.
    Une fois fini, Open Beauty Facts effectue le déchiffrage de la liste d'ingrédients et rend le produit complètement « cliquable » pour tous les prochains scanners.

    Des listes d'ingrédients en anglais et en latin, pour petits chimistes

    Il est aussi possible de faire la même chose avec un appareil photo et un ordinateur.

    Des données ouvertes

    Les données sont disponibles sous licence ODbL 1.0 (comme pour OpenStreetMap). Cela permet de réutiliser les données le plus largement possible.
    Il existe également une API en lecture et écriture pour pouvoir utiliser ou contribuer des données.

    Vous nous rejoignez ?

    Open Food Facts et Open Beauty Facts ont besoin d'aide dans tous les domaines imaginables, que ce soit la traduction, le développement (Perl, HTML/CSS, Android, iOS…), la contribution via smartphone ou le web.

    Rejoignez-nous et mettez au défi vos amis d'ouvrir leur armoire de salle de bains !

    Lire les commentaires

  • Réseau domestique : mes choix (Journaux LinuxFR)

    Sommaire

    En lisant le journal de yekcim (avec son beau schéma de réseau domestique), je me suis dis que mon schéma de réseau n'avait pas été mis-à-jour depuis longtemps. Je l'ai donc re-dessiné et (fier comme un paon) j'ai décidé de le vous le montrer.

    C'est l'occasion de partager les solutions que j'ai choisi pour résoudre les problématiques d'un réseau domestique (ce qui est aussi le sujet du journal sus-cité). Je vous encourage aussi à faire de même. Il est toujours intéressant de confronter son opinion et ses choix avec ses pairs !

    Sans plus attendre, voici déjà mon bô dessin :

    LAN

    TL;DR

    La dessous, y'a un gros pavé. Si vous ne voulez pas tout lire, voici un résumé :

    • fonctions "techniques" regroupées et ondulées
    • données sur un NAS qui gère aussi le réseau
    • NFS pour l'accès aux données de partout
    • XBMC (xbox/raspbmc) et UPnPlay (android) pour les fonctions client media
    • Debian partout (ou presque)

    Background

    Puisque c'est mon journal et mon réseau, commençons sans hésiter par un 3615 MaVie.
    Quand j'ai rénové ma maison, j'ai fait mon électricité. Tant qu'a passer des fils, j'en ai profité pour câbler en basse tension (ie: câble Ethernet) toutes les pièces. je me retrouve donc avec 32 prises RJ45 toutes ramenées au tableau électrique (dans la GTL située au 1er étage) Il me suffit de les brasser vers le téléphone ou le switch (ou autre chose genre téléinfo) pour choisir leur utilisation.

    Sur le schéma on retrouve donc des lignes verticales représentant le réseau de chaque étage. Les taches colorées figurent les pièces. C'est une vue logique, pas physique. Je me doute bien que savoir que guiautec est relié à la prise murale E1CT05 elle même reliée à la prise A06 de la baie de brassage et au port ge3 du switch ne vous intéresse pas :)

    Le nommage des machines suit 2 règles : des noms d’îles de l'archipel des Glenan pour les généralistes et la fonction (ou la marque) pour les équipements spécialisés.
    Côté OS, c'est assez homogène avec du Debian (testing) partout :). On notera quand même un Windows 8 pour l'adolescente (uniquement pour Les Sims 4) et une machine virtuelle Windows 7 (non représentée) sur mon PC pour des outils de développement WIN only (du Python et gcc, franchement, ils auraient pu faire une version Linux !). Et bien sur, les équipements mobiles en Android.

    GTL : fonctions techniques

    Dans ce petit placard, sont regroupées toutes les fonctions "techniques".

    Le point névralgique de mon réseau (outre le switch) est le NAS qui assure toutes les fonctions de management du réseau. C'est un Synology DS213j. Il a remplacé un NAS homemade à base de mini-ITX via epia qui a rendu l’âme il y a quelques mois. Le basculement vers une appliance clef en main a été dicté par une volonté de simplifier l'administration. Je suis très content de ce choix ! J'ai très peu perdu en souplesse et fonctions, mais beaucoup gagné en simplicité de gestion.

    Il assure les fonctions réseau (DHCP, DNS, NTP …) car je fais moyennement confiance à la Livebox pour cela. De plus cela me donne beaucoup plus de maîtrise de ce qui se passe.
    Évidement, il me permet aussi d'héberger toutes mes données (musique, vidéos, photos et autres documents) et de les partager avec les autres machines du réseau.
    Il m'offre des fonctions annexes tel git ou un MariaDB accessibles de partout.
    Et enfin il gère toute la partie sauvegarde que nous verrons plus loin.

    Le switch est un Netgear GS724T gigabit. Il est administrable via une page web et offre une interface snmp. Au moment de l'achat c'était le gigabit (administrable) avec suffisamment de ports le moins cher. À noter (voir ci-dessous) qu'il permet aussi de gérer des VLANs.

    Côté domotique, je n'ai pas grand chose. Un RaspberryPi (sous Debian) gère cela :

    • La téléinfo EDF qui est stockée dans la BdD du NAS. Les graphiques sont accessibles via un serveur lighttpd hébergé directement sur le Pi.
    • Le Fil pilote (un seul radiateur pour le moment) est géré via une interface USB simple. Je ne l'utilise que pour allumer le sèche serviette de la salle de bain (parentale) pour les douches du matin. La aussi une interface web permet de le programmer.

    Enfin tout ce petit monde est branché (230V) sur un onduleur MGE Ellipse 1000. J'avais choisit MGE pour son soutien au libre (via NUT). Il est managé en USB par le NAS qui peut ainsi s'éteindre avant la coupure définitive. Le Pi accède aussi à ces informations via le réseau. C'est très appréciable car j'ai déjà cramé la carte SD d'un Pi à cause de micro coupures à répétition. Acheté en décembre 2006 j'ai du remplacer ses batteries le mois dernier (par contre il a coupé d'un coup sans prévenir :( ).

    1er étage : les machines de tout le monde

    Dans le "secrétariat" on trouve la machine en libre service (huic) qui sert pour les papiers et les comptes (et regarder des vidéos de minecraft sur youtube). C'est ma machine génération N-1.

    Pour imprimer et scanner j'ai choisit une imprimante réseau (Xerox phaser 6110MFP achetée en décembre 2008). La aussi l'administration s'en trouve simplifiée et tout le monde y a directement accès. Pour scanner, j’utilise le script perl de Jon Chambers démarré à la demande sur le NAS. Les documents sont alors accessibles en NFS.

    Dans mon bureau se trouve ma machine principale (guiautec) qui reste la plus puissante de la maison (elle date de cette année). Ma machine de génération N-2 (penfret) est sur mon établi électronique. Elle me sert principalement à afficher les schémas ou les datasheets quand je soude. Malheureusement sa carte GPIB ISA a cramé récemment et la machine elle-même donne de sérieux signes de fatigue. Je ne pense pas la remplacer, mon portable de récup fera bien l'affaire (sauf pour le GPIB :( )

    Pour les enfants, notre adolescente a (ENFIN! selon elle) son propre PC (bananec) et la petite utilise le PC en libre service. Je n'ai pas mis de proxy, de filtre parental ou autre. Nous croyons aux vertus de l'éducation (pour le moment …). De plus, elles connaissent les compétences de leur père ce qui sert d'arme de dissuasion ;)

    2ème : la musique

    Pour la musique, j'utilise une petite tablette chinoise à 2 balles (et écran résistif de merde) qui a le mérite de disposer d'un adaptateur Ethernet. Elle accède aux fichiers via le serveur DLNA du NAS et l'application UPnPlay. On est loin d'une installation de haute fidélité, mais au vu de mes oreilles moisies, c'est suffisant.

    C'est le seul équipement qui fait du DLNA. Ce protocole ne m'a jamais emballé, mais sur cet Android c'est le moyen le plus facile. Si la tablette était récente (et acceptée par Google) j'utiliserai sans doute les applications de Synology qui fonctionnent très bien sur mon téléphone.

    3ème : la vidéo

    Ici se trouve la TV et son boîtier Livebox associé. Soyons honnête il ne sert presque pas puisque nous consommons surtout des films.

    Depuis des années je suis un fervent utilisateur de XBMC, d'abord sur Xbox (sa principale utilisation depuis son achat d'occasion) puis sur RaspberryPi (raspbmc) suite à l’avènement des vidéos en HD.
    L'accès au NAS se faisait en Samba sur la xbox et en NFS sur le Pi.

    Le Pi est commandé via un clavier ou l'appli officielle sous Android. Je compte y ajouter une télécommande infrarouge quand j'aurais fini le projet associé RPiSU

    Sauvegarde

    J'essaye d'avoir une politique correcte de sauvegarde.

    • Chaque PC sauvegarde ses données (en gros /etc et /home) en Rsync (avec anacron et un petit script maison) dans un répertoire du NAS.
    • Le NAS est en RAID histoire de ne pas paumer ses données en cas de panne de disque (oui je sais ce n'est pas de la sauvegarde)
    • Toutes les nuits les données (importantes) du NAS et le répertoire de sauvegarde des PCs est copié (avec historique) sur un disque externe USB. Ce sont les outils de Synology qui permettent l'historique.

    Il me manque la sauvegarde off-site que je suis en train (depuis très longtemps …) d'étudier : cloud, synchro avec un NAS distant …

    VLAN : restreindre les enfants

    Une fonction que je n'ai plus d'implémentée dans le réseau actuel mais qui était en place quand les enfants étaient trop petits pour avoir leur propre accès Internet.

    Un WRT54G (sous OpenWRT) offrait un 2ème accès Wifi avec un vlan particulier. Certains ports du Switch étaient aussi dans ce vlan. Les enfants n'avaient accès qu'à ce Wifi ou ces ports particuliers. Ainsi ils pouvaient avoir accès aux données du NAS (films, photos, musique) mais n'avaient pas d'accès à internet (depuis leur chambre). Cela permet de les avoir en visu quand il y accèdent et de leur prodiguer les conseils et aide nécessaires.

    Évolutions éventuelles

    Le réseau domestique tel qu'il est actuellement nous convient et ne devrait pas beaucoup évoluer dans les temps à venir :

    • J'envisage de mettre en place une sauvegarde off-site.
    • J'ai aussi l'intention d'éteindre le Wifi de la Livebox (étage des chambres) pour installer mon WRT54G au 2ème étage (la ou les téléphones/tablettes) sont le plus utilisées.
    • je cherche aussi (doucement) un moyen de grapher toutes ces fonctions. Avant j’utilisais Munin mais sa lourdeur ne m'incite pas à la faire tourner sur mon NAS ou mon Pi

    Voila, bravo à ceux qui sont arrivés jusque la.
    Et maintenant c'est à votre tour, quels sont vos choix et solutions pour votre réseau domestique ?

    Lire les commentaires

  • Smash The Code, concours d'intelligence artificielle, démarre le 30 avril 2016 (Dépêches LinuxFR)

    Smash the Code sera le prochain concours de programmation d'intelligence artificielle organisé par CodinGame. L'événement se déroulera en ligne du samedi 30 avril 2016 à 18h (heure de Paris) au dimanche 8 mai 20h. La participation est gratuite et ouverte aux développeurs du monde entier.

    Smash the Code est un jeu de type multijoueurs où les participants devront développer un bot capable de vaincre ses adversaires de manière autonome. Pendant les 8 jours du concours, il sera possible de modifier son code autant que souhaité pour améliorer sa stratégie (pas de limitations, pas d'obligations). Pour rassurer ceux qui n'auraient pas beaucoup de temps à consacrer à leur programme, sachez qu'on peut démarrer et s'amuser avec une solution minimale qui peut être codée en quelques minutes seulement.

    Les participants pourront tenter de décrocher les lots offerts aux meilleurs du classement, et candidater pour des emplois ou des stages auprès des sociétés sponsors de l'évènement.

    Illustration

    La plate-forme

    La plate-forme CodinGame supporte 25 langages de programmation (C/C++, C#, Java, Javascript, PHP, Python, Python 3, Perl, Go, Dart, Scala, Haskell, Objective-C, Pascal, Ruby, Bash, Groovy, Clojure, VB.NET, Lua, OCaml, F#, Swift et Rust). Pour participer, vous avez la possibilité d'utiliser l'IDE en ligne proposé ou de coder directement depuis votre environnement habituel.

    Déroulement du concours

    Concrètement, vous devrez réaliser un programme qui lit sur l'entrée standard les données relatives au tour de jeu et vous devez écrire votre action sur la sortie standard. Pour tester votre programme, vous avez la possibilité de faire des matchs contre notre bot par défaut ou contre les adversaires de votre choix. Dès que votre programme est capable de faire quelque chose, même très basique, vous pouvez l'envoyer dans l’arène ce qui vous permettra de vous situer par rapport aux autres. Vous pouvez renvoyer une nouvelle version de votre bot à tout moment donc il ne faut pas hésiter. Le classement final sera celui de l’arène, "gelée" à la fin du jeu.

    Pour s'entraîner pour Smash The Code, nous vous conseillons d'essayer :

    Lire les commentaires

  • Install Party GNU/Linux le 29 août 2015 à Marseille (Dépêches LinuxFR)

    L’association CercLL (CercLL d’Entraide et Réseau Coopératif autour des Logiciels Libres) vous invite à une install-party GNU/Linux, le samedi 29 août 2015 de 14h30 à19h30, dans la salle de la Fabulerie au 4 rue de la Bibliothèque 13001 Marseille (près du Conservatoire).

    Logo de l'association CercLL

    Vous avez envie de découvrir un système d’exploitation libre, simple d’utilisation, stable, rapide et sécurisé. Une nouvelle façon d’utiliser votre ordinateur.

    Vous vous sentez une affection naissante pour le Gnou et le Manchot, les mascottes de GNU/ Linux.

    Au programme :

    • Découverte de l’univers des logiciels libres.

    • Installation d’un environnement GNU/ Linux, ainsi que le meilleur des logiciels libres.

    Venez avec votre ordinateur, nous installerons ensemble une distribution GNU/Linux avec un ensemble de logiciels libres et gratuits pour une utilisation quotidienne.

    Affiche

    Ouvert à tous – accessible aux débutant-e-s

    Une participation de 2 euros est demandée.

    L’adhésion à l’association est de 20 euros annuelle.

    Lire les commentaires

  • Olympe, hébergeur gratuit et sans publicités, mène une campagne de crowdfunding (Dépêches LinuxFR)

    Fondé en 2008, Olympe fournit un service d’hébergement gratuit et sans publicité. Pour survivre, l’association lance aujourd’hui une campagne de financement participatif sur Indiegogo.

    Olympe

    L’association Olympe a été fondée il y a huit ans afin de coordonner les efforts d’une équipe autour des enjeux de la fracture numérique et de la liberté d’expression. L’un des premiers objectifs était la mise en place d’un service d’hébergement gratuit ouvert à tous, permettant aujourd’hui à plus de 90 000 personnes et organisations de publier simplement et rapidement sites institutionnels, blogs, forums et applications métiers (en 5 langues).

    Auto-financée par ses partenaires et les membres de l’équipe, l’association se trouve dans une situation financière difficile depuis le rachat de son principal mécène par une société ne souhaitant plus contribuer au financement de ces services. Pour sortir de cette situation, le choix d'un financement participatif a été fait par l'équipe.

    L'objectif est clair : sauver Olympe en conservant un modèle de financement qui respecte nos valeurs et notre forme associative, et en conservant l’hébergement gratuit tel que nos utilisateurs le connaissent. Cette campagne va donc permettre à Olympe de poursuivre son activité le temps du déploiement de la nouvelle architecture et de la mise en place des nouveaux outils de gestion, puis de fournir suffisamment de trésorerie pour atteindre l’équilibre économique à trois ans.

    Nous souhaitons défendre notre modèle et prouver notre capacité à faire de l’hébergement, de l’opensource, de l'entraide « informatique » une véritable source de solidarité aussi bien locale que transnationale. Notre équipe a œuvré ces dernières années de toutes ses forces pour fournir un service et une assistance technique aussi réactifs et qualitatifs que possible.

    Nous voulons pouvoir continuer à le faire. Soit cette campagne aboutit, soit nous devrons fermer définitivement nos portes…

    Lire les commentaires

  • Tour d'horizon des éditeurs de texte pour le terminal (Journaux LinuxFR)

    Sommaire

    Le nombre d'éditeurs de texte disponible sur nos systèmes d'exploitation est très important, même en se limitant à ceux s'exécutant dans un terminal.

    La sélection suivante est donc forcement partielle. Dans la suite je parlerais des principaux éditeurs, de leurs clones, des anciens moins connu et enfin des plus récents.

    La famille vi

    La particularité de cette famille est d'être modale, les touches ont une action différente selon le mode dans lequel on est. De plus vi est dans la norme POSIX, donc tous les OS de type POSIX embarque un clone de vi.

    Voir l'histoire de vi : wikipedia - Vi History

    elvis

    Elvis est un des premiers clone de vi (avec Stevie)

    debian: tracker.debian.org/pkg/elvis

    nvi

    Nvi est une réécriture du vi des BSD 4.4 à partir du code d'Elvis.

    debian: tracker.debian.org/pkg/nvi

    vim

    Vim est certainement le clone de vi le plus utilisé aujourd'hui. Il est disponible sur de nombreuses plateformes et une vie entière ne suffit pas a faire le tour de ses fonctions.

    debian: tracker.debian.org/pkg/vim

    neovim

    Neovim est un fork de vim.

    Voir la dépêche sur le sujet, neovim une refonte de vim pour le 21e siecle

    debian:

    kakoune

    Éditeur qui s'inspire de vim mais a sa propre philosophie (voir le
    répertoire doc/)

    debian:

    La famille emacs

    M-x editeur

    wikipedia - Liste des implémentations d'Emacs

    emacs

    On ne le présente plus, le plus difficile étant de trouver quelque chose qu'on ne peut pas faire dans emacs.

    debian: tracker.debian.org/pkg/emacs24

    note: se lance en ligne de commande avec l'option -nw pour
    --no-window-system

    uemacs

    Version légère et portable d'emacs.

    Linus Torvalds maintient une ancienne version de uemacs et l'a fait
    depuis évoluer.

    mg

    Version très portable de uemacs nommé initialement Micro GNU/emacs.

    debian: tracker.debian.org/pkg/mg

    zile

    zile est une implémentation d'emacs plus limité et plus légère.

    debian: tracker.debian.org/pkg/zile

    La famille à menu

    Les éditeurs de cette famille ont comme point commun, d'être plus
    abordable pour le novice en fournissant un menu permettant l'auto-découverte.

    nano

    Nano est la version GNU de Pico (Pine Composer), l'éditeur de texte du client mail Pine.

    debian: tracker.debian.org/pkg/nano

    Note: Pico est aussi disponible dans Debian,
    packages.debian.org/jessie/alpine-pico

    Jed

    Jed associe les fonctionnalités d'un éditeur très extensible pour développeur à une interface facile basé sur un menu.

    • url: www.jedsoft.org/jed
    • filiation:
    • wikipedia: wikipedia - JED

    • code source: git://git.jedsoft.org/git/jed.git

    • début du développement: 2006 ?

    • langage : C + S-Lang

    • utf-8: ok

    debian: tracker.debian.org/pkg/jed

    ne

    ne, le nice editor semble être un bon compromis entre richesse des
    fonctions et simplicité. Cet éditeur possède un jeu de fonctions
    (commandes) qui peuvent être lié a une séquence de touche ou à une
    entrée de menu.

    debian: tracker.debian.org/pkg/ne

    mcedit

    mc (mindnight commander) propose un éditeur très complet, mcedit.

    debian: tracker.debian.org/pkg/mc

    kaa

    Encore un éditeur avec un menu, celui-ci extensible en Python.

    debian:

    Les autres

    Des éditeurs qui ne rentrent pas dans les précédentes catégories ou qui peuvent les imiter toutes.

    Joe

    Un des plus ancien challenger.

    debian: tracker.debian.org/pkg/joe

    Fork www.mirbsd.org/jupp.htm

    Diakonos

    L'objectif principal de Diakonos est de proposer un éditeur en console avec les raccourcis clavier classique d'une application graphique tel un navigateur ou un traitement de texte.

    debian: tracker.debian.org/pkg/diakonos

    Yi

    Yi est un éditeur de texte écrit et extensible en Haskell.

    debian: tracker.debian.org/pkg/yi

    Textadept

    Textadept est un éditeur graphique qui propose aussi une interface
    curse. Celui-ci est extensible en Lua. L'auteur utilisant le composant Scintilla pour la version graphique, celui-ci a développé une version pour curse scinterm

    Spacemacs

    Spacemacs n'est pas un éditeur, mais une (énorme) configuration pour
    emacs. Leur baseline "The best editor is neither Emacs nor Vim, it's
    Emacs and Vim!" et leur originalité un <leader> configuré sur espace qui ouvre un Menu permettant de découvrir les fonctions disponibles.

    Conclusion ?

    Pas de conclusion, si vous voulez en découvrir encore d'autre, voici deux listes :

    Mais attention de ne pas vous perdre par ici texteditors.org !

    Lire les commentaires

  • Et si on parlait de skateboard ? (Journaux LinuxFR)

    Bien le bonjour,

    Quel est le lien avec linux, vous me direz… Eh bien, il semble évident pour Rodney Mullen !

    J'écoutais un TED, empli d'une certaine nostalgie… Un TED mené par Rodney Mullen. Si le nom vous parle, vous avez probablement de près ou de loin touché une planche de skate, et sans doute, vous avez la même réaction en me lisant, que j'ai eu en découvrant cette vidéo : "Quoi ? Rodney Mullen a fait un TED ! Faut absolument que je voie ça." Alors, c'est là qu'on commence à regarder ses tricks (eh ouais… jargon franglais du milieu), qu'on découvre son enthousiasme un peu naïf mais communicatif… Et soudain… Bam… Ils nous montre une photo avec les bobines, notamment de Linus Torvalds et Richard Stallman (ça m'amuse ici de vous mettre les liens… A une époque, je connaissais mieux Mullen que Stallman…).
    Et voilà un rapprochement qui fait sens, auquel on ne s'attend pas venant d'un gars qui pratique le darkslide et le casper to casper.

    Si le skate ne vous intéresse pas, mais que vous êtes curieux de cette comparaison, je vous invite à ne regarder que la partie entre la 11'30'' et 13'40''.

    Et donc le lien !

    Bon kif !

    Lire les commentaires

  • CEGID racheté (Journaux LinuxFR)

    L'éditeur Lyonnais de logiciels de gestion CEGID vient d'être racheté par des fonds de pension américains : http://www.zdnet.fr/actualites/cegid-group-change-de-mains-39835732.htm
    CEGID n'est pas un vrai éditeur, il ne crée pas de logiciels mais se contente de racheter des logiciels de gestion existants (ERP, comptabilité, RH etc.) et de les commercialiser sous sa marque. Lorsqu'un de ses logiciels ne lui rapporte plus assez ou vient en concurrence avec un autre de ses produits, il n'hésite pas à arrêter sa commercialisation, forçant ses clients à racheter au prix fort une nouvelle solution. Par exemple, il a arrêté l'ERP Produflex, obligeant ses clients à se relancer dans une nouvelle intégration d'ERP coûteuse et pouvant être fatale à l'activité d'une PME.
    Les produits CEGID sont fortement intégrés avec les produits Microsoft, ils ne sont pas multi-plateforme.
    Les administrations françaises sont fortement équipées avec des produits CEGID, pour des raisons commerciales et sûrement aussi politiques. Le choix de tels outils est suicidaire à long terme, les clients n'ont aucune maîtrise de leur système d'information.

    Le rachat de CEGID par des fonds de pensions américains vont faire empirer les choses, ça me fait bien rigoler quand j'entends les discours sur la souveraineté des outils informatiques et tout le bla bla bla des politiques. Là, la souveraineté vient d'en prendre un sacré coup.

    Point de salut hors des logiciels libres.

    Lire les commentaires

  • Linux, c'est déjà demain - écran tactile (Journaux LinuxFR)

    Bonjour le monde,

    j'ai installé un linux récent sur un ordinateur portable récent (designed for windows 8), et je suis heureux de voir que tout marche bien.

    au bout de quelques jours, j'ai faille tomber à la renverse de ma chaise. Je me suis en effet rendu compte que l'écran du portable était tactile (un effet de bord win8?) mais surtout que le tactile fonctionnait (et sans rien configurer de ma part)! Donc je peux d'un doigt gracieux cliquer sur les boutons de mon window manager et les voir réagir harmonieusement. C'est bô. (sauf mon écran qu'est plein de tâche de gras, mais c'est un autre problème)

    C'est très beau, mais c'est complètement inutile. Il n'y a à peu près rien qui est pensé pour :-( J'utilise XFCE comme desktop manager et l'usage du tactile est limité:

    • seul le simple clic gauche marche (pas de double clic)
    • le clic gauche sur la barre de fenêtre ne donne pas le focus (?)
    • pas de clic droit
    • le glisser déposé ne fonctionne pas
    • sous firefox, pas moyen de surfer tactile. Un glissement de doigt ne fait que sélectionner une partie de la page. Par contre je peux cliquer sur les liens

    Vous connaissez des usages du tactile sous linux? Ca me sidère tellement que ça marche out-of-ze-box que j'ai envie de tester plein de trucs au doigt maintenant (non ce n'est pas sale).

    Donc un énorme BigUP aux dévs de linux/Xorg/(autre chose?) qui font que ça marche tout seul, et le prochain microsoftien primaire qui me dit que le matos récent est mal supporté sous linux, je lui rie au nez :-)

    Lire les commentaires

  • Sortie de Tryton 3.4 (Dépêches LinuxFR)

    Comme à l’accoutumée, le mois d’octobre voit la sortie d’une nouvelle version de Tryton, la plate‐forme de développement d’applications pour entreprise (progiciel de gestion intégré ou PGI mais aussi ERP).

    Tryton

    Sur cette version, un gros travail a porté sur la partie comptabilité, mais aussi sur une multitude de petites améliorations pour simplifier la vie des développeurs de modules.

    Et, bien évidemment, la migration depuis les précédentes versions est assurée.

    Vous pouvez venir découvrir toutes ces nouveautés à la conférence annuelle de la communauté, qui se déroule cette année à Leipzig.

    Détails des nouveautés

    Interface utilisateur

    Les widgets des champs relations ont été retravaillés pour tirer avantage de l’auto‐complétion en les simplifiant. Les boutons ont été remplacés par une icône dans le champ qui permet soit de rechercher, soit d’ouvrir le contenu.

    Une pré‐validation côté client a été ajoutée. Elle permet un meilleur retour à l’utilisateur par rapport à un message d’erreur. En effet, le client est capable de mettre en surbrillance les champs non valides.

    Un complètement automatique entre le code postal et la ville est disponible sur les adresses. Les données de GeoNames peuvent être chargées dans la base de données via un script.

    La fenêtre d’exportation d’enregistrement a été retravaillée afin de fournir une meilleure expérience à l’utilisateur. Elle s’ouvre avec les champs de la vue courante pré‐sélectionés. Il est possible de modifier et de sauvegarder directement une exportation prédéfinie. L’ordre des champs peut aussi être changé par glisser‐déposer.

    Outils pour développeur

    Le patron commun dans Tryton de recherche d’un enregistrement dans une liste suivant des critères sur des valeurs (de manière modulaire) a été généralisé dans un Mixin.

    Un autre Mixin a aussi été ajouté, permettant de définir un nouveau modèle (objet) comme étant l’UNION (l'opérateur SQL) de plusieurs modèles.

    Un descripteur a été ajouté aux champs de sélection, il permet d’accéder aux labels de ceux‐ci au lieu de leurs valeurs internes.

    Le fichier de configuration est maintenant extensible à volonté, et donc il peut être utilisé pour le paramétrage des modules. C’est déjà le cas du module ldap_authentication qui va y chercher les paramètres de configuration du serveur LDAP.

    Proteus (la bibliothèque pour accéder à Tryton comme le client) est maintenant capable d’exécuter les rapports. Et une méthode duplicate voit le jour qui imite la fonctionnalité de copie d’enregistrement du client.

    Sécurité

    Les droits d’accès ont été revus pour n’être appliqués que sur les appels RPC. Ceci simplifie grandement le développement, vu que les droits d’accès ne sont contrôlés qu’aux bordures du système, et donc le développeur n’a plus à devoir basculer en utilisateur root pour effectuer certaines opérations.

    Comptabilité

    Un nouvel assistant de lettrage comptable fait son entrée. Il passe en revue tous les comptes et tiers qui contiennent des lignes à lettrer et fait une proposition de combinaison. L’utilisateur peut l’accepter telle quelle ou bien la modifier, ainsi que passer une partie en pertes et profits. Ce mode de fonctionnement accélère grandement cette tâche comptable.

    Un autre assistant permet d’annuler rapidement une écriture comptable en passant l’écriture inverse. Une option permet de directement lettrer les entrées possibles.

    Afin de rendre plus homogène l’utilisation du champ tiers sur les écritures comptables, ce champ est rendu obligatoire ou interdit en fonction du paramétrage du compte sur lequel l’écriture est passée. Ceci permet de configurer le système pour soit fonctionner avec des comptes groupés pour les tiers, soit avec un compte par tiers. Tous les modules ont été vérifiés pour gérer correctement les deux cas de figures automatiquement.

    Il est maintenant possible de choisir entre un arrondi des taxes « par ligne » ou « par document ». La méthode par défaut reste « par document ».

    Les lignes des relevés comptables peuvent être ordonnées et numérotées afin de correspondre au mieux à la version papier. De nouvelles méthodes de validation des extraits sont disponibles : « balance », « montant » et « nombre de lignes ».

    Il est maintenant possible de changer par année fiscale la méthode de valorisation perpétuelle du stock (« continentale » ou « anglo‐saxonne »).

    Les paiements

    Les paiements à l’état « réussi » peuvent maintenant être changés en « échoué ». C’est moins contraignant en cas d’erreur d’encodage.

    La prise en charge du schéma « Business to Business » de la norme SEPA pour les prélèvements automatiques a été ajoutée. Les messages de notification de débit/crédit (CAMT.054) sont gérés. Le numéro d’identification et le formulaire de mandat sont configurés par défaut.

    Un nouveau module account_payment_clearing permet de générer automatiquement un mouvement pour le paiement dans un compte d’attente de la banque. Ce mouvement sera par la suite compensé, lors de l’encodage de l’extrait de compte.

    Lire les commentaires

  • SFR et la censure du Forum (Journaux LinuxFR)

    Haaaa qu'elle est belle la société qui gère ma connexion…

    OK, le prix est sympa, je dis pas… Si si, en offre 2 téléphones + box, je paye pas des masses. Mais quand vous connaissez un peu la technique, tout à coup vous voyez le visage des censeurs arriver en plongeant une ombre sur vos nuques. La toute puissance de la modération qui vient embraser vos ridicules vies de petits consommateurs Linuxien que vous êtes.

    Pour faire au plus simple: la box SFR permet de faire un partage de disque dur via Samba. La Box est sous un UNIX et, miracle, je suis sur Linux (un XBMC à droite, un PC à gauche).

    Espérant monter le disque via la vieille commande "mount -t cifs" je me dis "allez, un NAS pour pas cher". Que nenni mon ami, tu es dans l'erreur.

    Oui, on arrive à lire le disque. Mais une écriture = Permission Denied. Cherchez pas à me donner des tests de solution, le souci ne vient pas de la commande, mais bien du serveur Samba de la BOX.

    En branchant le disque sur le décodeur TV SFR, là pas de souci, hormis le petit souci (vous allez rire hein) que quand le décodeur se met en veille… hop, plus de partage. Mais bon, le serveur Samba du décodeur est OK.

    Un coup de "smbclient -L" et je vois la version du serveur, et au passage, l'OS de la box.

    Domain=[WORKGROUP] OS=[Unix] Server=[Samba 2.0.10-security-rollup]

    La version 2.x date de 2004… passons

    Le SAV (sur twitter) me dit d'appeler le service technique, qui lui me répond "samba n'est compatible qu'avec Windows". Ouiiiii bien sûr, et moi ma voiture ne marche qu'avec du foin.

    Je reviens vers le SAV qui me dit "postez sur le forum". Et c'est là que ça commence à être vraiment délirant.

    Premier post, je le fais avec des pointes d'humour, mais je me dis "allez c'est gentil". PIM! censure… Je relance le post en virant les blagues…. PIM! rebelote.

    J'en arrive à poster un message clairement "sans ton", le genre "poker face" de lady Gaga quoi… et pim ! censuré…

    Réponse du service de modération, accrochez vous à vos sièges:

    "Nous vous rappelons que la publication de messages incitant à des pratiques contraires à la législation n'est pas autorisée."

    J'ai vu passé un corbeau derrière ma tête…

    Et donc, depuis hier soir, je m'amuse à détecter la suppression du post pour le rebalancer sur le forum.

    Le message:
    http://forum.sfr.fr/t5/Aide-et-d%C3%A9pannage/Samba-CIFS-et-UNIX/m-p/1293225

    5 iéme message censuré, je le reposte en attendant que le service de modération m'explique quel partie du message est contraire à la legislation comme le stipule leur mail après suppression

    Box de SFR, type UNIX (c'est important)
    Mediacenter XBMC type UNIX (testé avec OpenElec et Raspbmc)
    Protocole de communication de partage de fichier Samba

    Création de point de montage:

    mount -t cifs //BOX/NAS /mnt/NAS -ouser=guest (testé avec plusieurs méthode d'authentification, options de mask etc…)

    Lecture OK
    Ecriture = "Permission Denied"

    Branchement du disque que le décodeur, même opération mais "Ecriture OK"

    Réponse du SFR (twitter SAV et Service Technique): ce n'est pas compatble avec UNIX et UNIX Like.

    J'insiste… Windows n'est pas un UNIX (ou Unix Like)… Windows est "compatible" avec le protocole Samba utilisé par la BOX.
    Donc, pour clarifier: Mac et Linux sont bien plus compatibles avec le service Samba de la BOX que Windows puisque nous utilisons le même logiciel pour le protocol de partage.

    Version utilisé par la BOX:
    Domain=[WORKGROUP] OS=[Unix] Server=[Samba 2.0.10-security-rollup]

    Version datant de 2004.

    Réponse du service technique: "nous n'avons pas prévu de mise à jour pour Samba d'ici les prochains mois"

    Le problème existe depuis le changement de protocol FTP vers Samba (2 ans si je ne me trompe pas).
    La version 2 de Samba contient énormément de bugs et de failles même en applicant les patches.

    Etant donné que le décodeur permet l'écriture, et pas la BOX, j'estime que la box a un Bug de configuration de service Samba.

    Je ne peux pas utiliser le décodeur comme NAS puisqu'il se met en veille régulièrement.

    Sur le forum SFR, des utilisateurs Mac se plaignent aussi de bugs du protocol, les utilisateurs XBMC (contenu dans énormément de media center) ne pourront pas écrire sur le disque, et tous les utilisateur Linux (y compris Android) ne peuvent créer de point de montage.

    Merci de nous expliquer pourquoi vous ne mettez pas à jour le service Samba pour qu'il soit compatible avec l'ensemble des clients réseaux.

    PS: je réitère, Windows n'est pas l'OS le plus compatible avec ce service, c'est l'inverse

    Résultat des courses, je pense que je vais aller voir ailleurs. Non pas parce que le bug persiste, non non, mais pour la manière dont SFR traite son client.

    Clairement, me dire que Samba n'est pas compatible avec Linux, c'est déjà fort, mais censurer un message parce que ça les gène de pas savoir répondre…

    Lire les commentaires

  • Sortie de poezio 0.9 (Dépêches LinuxFR)

    Poezio est un client de messagerie instantanée en console (licence zlib) pour le réseau XMPP (Jabber) (pour plus de détails, voir la série de très bons journaux rédigés par goffi qui vont en détail dans le protocole et ce qu’il permet d’accomplir).

    Poezio est conçu pour être rapide à utiliser au quotidien, avec une utilisation se rapprochant des clients IRC bien connus comme weechat et irssi. Dans cet esprit, il est avant tout conçu pour les salons de discussions (MUC) et ne gérait même pas la connexion à un compte (on peut maintenant en avoir un) dans les premières versions, dans l’idée d’avoir le même genre de client qui ne nécessite pas de configuration préalable.

    Poezio offre néanmoins un certain nombre de fonctionnalités avancées liées à XMPP, comme la correction de messages, les accusés de réception, les message carbons (duplication de messages vers tous les périphériques), le formatage xhtml-im, une interface de debug XML complète, et bien plus encore. Un certain nombre de compromis sont malheureusement réalisés du fait de l’interface en ncurses qui limite un peu les options niveau interface utilisateur.

    Du point de vue de la sécurité, poezio force le chiffrement avec le serveur en utilisant des ciphers corrects (l’utilisateur peut cependant désactiver le chiffrement ou réduire la qualité des ciphers), fait du cert pinning (via un hash du certificat à la première connexion, et un gros avertissement si ça change ensuite). Il intègre également un plugin GPG (que personne n’utilise) et OTR.

    Côté technologie, poezio dépend généralement de la dernière version de python en date à chaque nouvelle release, ce qui est rarement du goût de debian stable.

    Sommaire

    Nouveautés de poezio 0.9

    (NdM: l'auteur du journal mathieui est membre du projet et s'exprime à la première personne dans la suite.)

    Python 3.4 et slixmpp

    Une fois de plus, la version de python requise est incrémentée (pour 3.4).

    Cette fois c’est parce que nous avons changé de bibliothèque XMPP pour slixmpp, qui est notre fork de SleekXMPP (bibliothèque utilisée auparavant), en y substituant le multithreading événementiel par asyncio. Pour comprendre les raisons de ce fork, référez-vous à l’article de louiz’ donné en lien ci-dessus. (pour résumer : un code plus lisible, pas de race conditions, plus de facilité à raisonner sur le code)

    Cela ne veut pas dire pour autant qu’on se désolidarise complètement de SleekXMPP qui reste une excellente bibliothèque, puisque slixmpp partage toujours avec elle la majorité de son code sans modification. Nous pourrons donc appliquer des nouvelles fonctionnalités et corrections sans ou avec peu de modifications, et leur envoyer les nôtres en retour également.

    Greffon OTR amélioré

    Le greffon OTR qui avait été réécrit avec poezio 0.8 manquait encore des fonctionnalités communément attendues dans un greffon de chiffrement, c’est maintenant corrigé.

    La nouvelle fonctionnalité majeure est le Socialist Millionaire’s Protocol (SMP) qui permet à deux personnes de vérifier l’identité de leur correspondant respectif, à travers un secret partagé ou une question (auparavant il était possible de vérifier les identités, mais seulement en communiquant les empreintes de clefs sur un autre canal).

    D’autres améliorations sont présentes comme un peu de traitement de HTML pour améliorer l’expérience utilisateur, et d’autres options de sécurité pour forcer le chiffrement et la négociation de session.

    OTR

    Connexion avec des certificats clients

    Poezio permet désormais de se connecter sans mot de passe à son serveur en utilisant des certificats X.509 et un mécanisme décrit dans la XEP-0178, et également de gérer ces derniers à travers les fonctionnalités décrites dans la XEP-0257.
    Avec ces fonctionnalités vous pouvez, une fois connecté, ajouter, désactiver, lister ou supprimer ces certificats du serveur.
    Un bug dans le module prosody empêche malheureusement l’utilisation de la XEP-0257 pour l’ajout d’un certificat, mais on peut le patcher en attendant.

    Commandes ad-hoc

    Les commandes ad-hoc dans XMPP permettent à un humain d’interagir avec une entité sans qu’il existe de spécification précise quant à la nature de l’interaction (en dehors XEP-0050, justement). Par exemple, prosody permet avec le chargement du bon module de charger/décharger des modules, de déconnecter ou supprimer des utilisateurs, etc, juste avec des commandes ad-hoc.
    Dorénavant, poezio peut donc lister et exécuter ces commandes ad-hoc à travers une interface dédiée.

    Couleurs de pseudo

    Auparavant, les couleurs de pseudos étaient attribuées selon l’ordre d’entrée des participants dans le salon, ce qui était mémorisable en gardant poezio ouvert plusieurs mois, mais restait perturbant quand la même personne avait une couleur différente selon le salon dans laquelle elle était.
    À partir de maintenant, les pseudos seront hashés avant d’être projetés sur la liste des couleurs disponibles, ce qui permet d’obtenir une distribution relativement uniforme, aléatoire, et surtout fixe des couleurs. Les gens qui utilisent le même pseudo partout devraient donc toujours garder la même couleur.
    Si vous préfériez l’ancien comportement (pour des raisons étranges sûrement valides), il existe toujours et peut être réactivé en changeant une option.

    De plus, Perdu a ajouté une commande pour régler définitivement la couleur d’un pseudo, donc si vous trouvez qu’une couleur attribuée ne convient pas à quelqu’un, vous pouvez le modifier.

    Accusés de réception

    Les messages envoyés par poezio demandent maintenant des accusés de réception, si le correspondant les prend en charge. Évidemment, poezio répond également aux demandes d’accusés de réception, ce qui devrait permettre aux clients mobiles plus de fiabilité.
    Ce comportement peut être personnalisé, mais il est activé par défaut. Si un accusé de réception est reçu pour un message envoyé, un caractère de validation en vert s’affichera à côté du message.

    poezio receipts

    Gestion de marque-pages

    La commande /bookmarks permettait auparavant de lister tous les marque-pages connus, de façon un peu brute. Désormais cette commande ouvre un onglet vous permettant d’éditer les marque-pages, mots de passe, et de choisir l’emplacement de stockage ainsi que l’autojoin à l’ouverture du client.

    poezio bookmarks

    Performance

    Certains bouts de poezio étaient affreusement mal optimisés. Certains le sont certainement encore, mais quelques scénarios assez communs devraient être plus rapides de façon exponentielle (par exemple rejoindre un salon avec plusieurs milliers de participants). La lenteur est habituellement invisible dans les cas normaux (comme quelqu’un utilisant poezio sur un ordinateur construit après 2002 en ayant quelques tabs ouverts), mais ça devient plus problématique quand poezio tourne sur une carte ARMv7 à faible consommation avec plusieurs centaines de salons ouverts et un flux constant de nouveaux messages ou présences.

    Greffon IRC

    louiz’ a écrit entre temps un composant IRC appelé biboumi (qui est pour moi la meilleure passerelle IRC disponible). Malheureusement, mélanger des onglets IRC et des MUC normaux est un peu perturbant, j’ai donc écrit un greffon IRC simpliste qui, une fois configuré correctement, gère l’authentification avec nickserv et la connexion aux salons ensuite, ainsi que des commandes préfixées par irc_ pour plus de fluidité dans un fonctionnement normal. Le fonctionnement interne est un hack, mais ça reste bien plus agréable que de tout faire soi-même à chaque fois.

    Reconnexion aux salons

    Le problème quand une connexion timeout ou qu’un serveur redémarre est que vous pouvez ne jamais être prévenu que vous n’êtes en fait plus dans le salon avant que vous n’essayiez d’envoyer un message ou une présence et que ce dernier vous réponde par une erreur. Cette nouvelle version introduit un mécanisme appelé le self-ping qui, une fois activé (et éventuellement configuré plus finement), fera en sorte que poezio s’envoie un ping à travers chaque salon au bout d’un certain temps d’inactivité. Si le salon lui reçoit par une erreur, il va quitter le salon (afin d’être certain de ne plus y être) puis y revenir.
    Cela devrait permettre de ne plus découvrir le matin que l’on a été déconnecté de tous les salons juste après avoir été se coucher parce qu’un serveur a redémarré quelque part.

    Et bien plus encore

    Bien évidemment, il y a plus de commits que ça (plus de 500), que ce soit pour des nouvelles fonctionnalités ou des corrections de bugs. Par exemple, des améliorations de la commande /set, une refonte de l’onglet de debug XML, une commande de destruction de salon, le passage au SHA-2 pour la vérification du certificat, etc…
    Vous pouvez regarder le CHANGELOG ou l’historique git pour plus de nouveautés.

    Packaging

    Comme dit précédemment, poezio dépend maintenant de la bibliothèque slixmpp, cette dernière dépendant d’aiodns, ainsi qu’optionnellement de cython afin d’optimiser un module (et dans ce cas libidn sera requis également, ainsi que ses en-têtes pendant la compilation).

    Contributeurs

    En dehors de moi (mathieui), louiz’, et Link Mauve, je veux remercier les autres contributeurs Perdu, Ge0rG, eijebong, Florian Duraffour et Akim Sadaoui pour leur apport en fonctionnalités et corrections.

    Bugs

    Comme toujours, si vous essayez la version et que vous remarquez un bug également non corrigé dans la version git, merci de le rapporter.

    Lire les commentaires

  • Librem 13, l’espoir d’avoir un jour un ordinateur libre (Dépêches LinuxFR)

    Aujourd’hui, un nombre considérable d’ordinateurs sont conçus sans prendre en compte les libertés individuelles et enfreignent la vie privée de l’utilisateur. Depuis d'ingénieuses portes dérobées installées dans les micrologiciels embarqués dans les puces électroniques jusqu’aux modules propriétaires intégrés au noyau de nos systèmes d’exploitation, les menaces sont nombreuses. Les stratégies pour s’en prémunir étant devenues un sujet majeur au sein des communautés promouvant le logiciel libre, la question sur le matériel à choisir est plus que jamais d’actualité.

    C’est dans ce contexte qu’est né le projet Purism, ayant pour objectif de fournir des ordinateurs portables respectueux de la vie privée, de la liberté et de la sécurité des utilisateurs.

    Sommaire

    Historique

    Malgré l’existence d’une multitude de boîtiers totalement libres sur le marché, les solutions pour ordinateurs portables s’offrant à nous demeurent très limitées. Face à une concurrence tenace, maintenue par un cercle fermé de constructeurs non soucieux des libertés individuelles, et prisonniers de leurs accords financiers mutuels, la FSF (Free Software Foundation) peine à promouvoir le libre au-delà des limites des solutions logicielles. En conséquence, les compromis entre ergonomie, puissance et prix sont devenus coutumiers pour la plupart d’entre nous.

    Pour autant, des alternatives ont vu le jour. Le projet Gluglug du Minifree (Ministry of Freedom) propose ainsi, depuis le 29 janvier 2015, un nouvel ordinateur certifié RYF. Il s’agit du Libreboot x200, un Thinkpad x200 modifié de façon à échapper aux abus auxquels nous pourrions être confrontés avec d’autres produits informatiques. Le micrologiciel BIOS a été soigneusement remplacé par un logiciel libre, Coreboot, offrant l’assurance d’une protection dès la mise sous tension de l’ordinateur. Le système d’exploitation Trisquel GNU/Linux y est également installé par défaut. Il s’agit d’une distribution GNU/Linux constituée exclusivement de logiciels libres, et soutenue à ce titre par la FSF.

    Néanmoins, il ne s’agit que d’une solution basée sur du matériel vieillissant et ne bénéficiant pas des dernières avancées technologiques matérielles. C’est la raison pour laquelle le projet Purism fut lancé courant 2014. L’objectif de Purism serait de remplacer tous les bits propriétaires identifiables sur un ordinateur portable par des logiciels exclusivement libres. Il ne s’agirait pas ici de se contenter d’un système d'exploitation libre comme un certain nombre de fournisseurs, mais de choisir un matériel spécifique qui puisse fonctionner sur GNU/Linux avec des pilotes libres purs au point de remplacer les BIOS/UEFI fermés avec Coreboot. Ce combat permanent, soutenu vigoureusement par Richard Stallman, nous projette d’emblée dans un avenir meilleur, où les logiciels libres pourront remplacer l’intégralité des logiciels propriétaires.

    Caractéristiques matérielles

    Le Librem 13 est le premier ordinateur portable haut de gamme où l’utilisateur détient le contrôle et une complète visibilité sur son système. Bien que le bootloader, le noyau du système d’exploitation et toutes les applications logicielles soient des logiciels totalement libres et gratuit, le BIOS qui utilise les codes de Coreboot, dispose à l’heure actuelle, toujours d’un binaire développé par Intel, appelé FSP. Tandis que les efforts de l’équipe du projet se concentrent sur cette partie du BIOS non libre, le Librem sera le premier ordinateur portable jamais fabriqué avec un processeur Intel moderne exécutant du code non signé par le BIOS. L’équipe travaille également sur les micrologiciels embarqués dans les puces électroniques des contrôleurs des disques de stockage dur et flash. Les deux cartes réseaux, filaire et Wi-Fi, sont accompagnées également des pilotes logiciels libres et gratuits.

    L’entreprise Purism fabrique elle-même la carte mère, et la sérigraphie du clavier. De plus, il est également intéressant de noter qu’il s’agit d’un des seuls ultra-portables du marché proposant une configuration évolutive. Tous les composants sont facilement remplaçables après avoir dévissé l’arrière du boîtier. Et pour les plus paranoïaques d’entre nous, des commutateurs matériels sont proposés en option, afin de rendre indisponibles à la demande, le micro, la caméra ainsi que la carte réseau sans fil.

    • Écran : dalle IPS mate de 13.3” d’une résolution maximale de 1 920 × 1 080
    • Processeur : Intel i5 avec 2 cœurs (4 threads) cadencés à 2,2 GHz
    • Carte graphique : Intel HD Graphics 5500
    • Mémoire vive : 4 Go (jusqu’à 16 Go en option)
    • Stockage : 500 Go HD (jusqu’à 1 To HD ou 1 To SSD)
    • Carte réseau sans-fil (ath9k) : 802.11n Wi-Fi
    • Carte réseau filaire (r8169)
    • Caméra : 720p
    • Batterie : 48 Wh lithium-ion polymère, jusqu’à 8 h d’autonomie
    • Adaptateur secteur : 45 W disponible dans les versions US, EU et UK
    • Connectique :
      • 1 × port USB 3.0
      • 1 × port USB 2.0
      • 1 × port HDMI
      • 1 × port RJ45 de type Pop-Down
      • 1 × port jack
      • 1 × fente pour carte SDXC
    • Système d’exploitation : Purism PureOS 64-bit
    • Commutateurs matériels pour la carte réseau sans fil et la caméra (en option)
    • Clavier étendu dans une variété de langues, bépo.
    • Corps du boîtier en aluminium
    • Dimensions : 325 mm × 219 mm × 18 mm
    • Poids : 1,4 kg

    Caractéristiques logicielles

    Livré avec le système d’exploitation PureOS préinstallé, l’ordinateur portable embarque uniquement des logiciels choisis pour avoir la particularité de respecter les recommandations du logiciel libre. Les deux cartes réseaux, filaire et sans fil, sont donc accompagnées de pilotes logiciels totalement libre et gratuit. PureOS est un système d’exploitation basé sur la distribution Trisquel GNU/Linux soutenue par la FSF, dont le noyau est exempté de tout code binaire propriétaire, comme cela ne pourrait pas être le cas sur une distribution comme Debian. Il s’agit de mesures strictes visant à protéger l’utilisateur de tentatives de détournements que pourrait s’accorder certaines entreprises commerciales développant leurs propres pilotes matériels. Actuellement, seul le dossier /home est chiffré par défaut afin de simplifier, selon Purism, les démarches pour les utilisateurs, et éliminer ainsi les contraintes qui seraient liés au chiffrement global de l’ensemble de l’espace de stockage.

    Cette distribution embarque également des outils visant à protéger la vie privée des usagers, comme un navigateur web qui n’est autre qu’une version modifiée de Firefox incluant des modules comme Privacy Badger ou encore HTTPS-Everywhere. Des utilitaires basés sur le projet TOR sont également installés, auprès du reste des applications de bureautique, avec notamment des outils pour le dessin, le traitement de texte, les présentations, les activités multimédias, la gestion des mails… L’ensemble étant associé à l’environnement de bureau GNOME 3 de façon à rendre plus conviviale l’utilisation de l’ordinateur et faciliter ainsi la migration de certains utilisateurs.

    Critiques autour du projet

    Le projet n’attire pas que des louanges de la part de la communauté du libre. Un certain nombre de critiques sont apparues. Citons notamment :

    Aussi, il est important de garder à l’esprit que certaines personnes travaillant depuis un moment sur la réécriture des binaires bas niveau émettent eux-mêmes de gros doutes sur l’accomplissement de leurs travaux.

    Conclusion

    En définitive, le Librem 13 marierait le meilleur du logiciel libre avec les meilleurs composants matériels du marché, tout en proposant un design élégant et une qualité d’assemblage s’approchant de ce qui se fait de mieux. Le Librem 13 semble donc être l’un des seuls ordinateurs portables modernes qui nous propose l’assurance de défendre du mieux possible nos idéaux de confidentialité, de sécurité et d’ouverture.

    Cependant, il est important de garder à l’esprit que le projet n’en est qu’à ses débuts, et que le meilleur est à venir. Il va de soi qu’il est important que la communauté se mobilise, par un soutien financier depuis la plateforme de financement participatif CrowdSupply, assurément, mais également par une participation aux discussions et phases de développement de Coreboot.

    Lire les commentaires

  • Le film d’animation libre « ZeMarmot » : où en est‐on ? (Dépêches LinuxFR)

    ZeMarmot est un film d’animation en 2D entièrement réalisé avec des logiciels libres, partiellement financé participativement, et diffusé sous licences Creative Commons paternité — partage à l’identique et Art Libre.

    Nous en avions déjà parlé sur LinuxFr.org, mais rappelons les points principaux :
    Logiciellement, nous utilisons GIMP pour le dessin, Blender VSE pour l’édition vidéo et Ardour pour l’édition audio.

    Le cœur de l’équipe :

    • Aryeom, réalisatrice coréenne de film d’animation, est l’artiste principale du projet ;
    • moi‐même, Jehan, développeur GIMP, suis le scénariste ainsi que le responsable technique ;
    • enfin, nous travaillons avec l’AMMD, qui est en charge de la bande musicale du film.

    Nous approchons de la fin de la pré‐production. Il est donc temps pour une petite mise à jour : que s’est‐il passé depuis l’annonce du projet mi‐2015 ? Les détails, ainsi que de nouvelles opportunités de nous soutenir, sont dans la seconde partie de la dépêche.

    Sommaire

    ZeMarmot logo

    Passé

    Recherche

    Notre vidéo d’accroche (teaser) fut réalisée en environ un mois, dans une frénésie de création rapide, car nous voulions la sortir à temps pour Libre Graphics Meeting 2015. Notre financement participatif fut ainsi officiellement lancé le jour de la présentation du projet au monde, lors d’une conférence au Libre Graphics Meeting 2015 à Toronto.

    Cette vidéo bande annonce était surtout une démonstration technique de ce que nous savions faire, pour montrer qu’il est possible de créer un film d’animation 2D avec des logiciels libres. Le design du personnage principal — bien qu’ayant déjà connu plusieurs versions à l’époque — n’était pas final ; le scénario du film était encore à l’état de préversion et le script de la bande annonce était lui‐même très symbolique ; enfin, de manière générale, nous avions encore beaucoup de choix à effectuer.

    Pour le film véritable, nous avons pris notre temps, afin de créer une œuvre de qualité. Notre première action fut ainsi de partir en recherche d’informations sur le Net, mais aussi sur le terrain. Nous sommes donc allés dans les Alpes pour rencontrer des marmottes. Quelques jours à prendre des photos, filmer, observer les marmottes et enregistrer des sons, nous sommes revenus avec une centaine de gigaoctets de données multimédia. Bien entendu, ces données brutes (ainsi que toutes celles que nous ferons dans le cadre du projet) seront au final rendues disponibles sous les mêmes licences que le film.

    Baiser des marmottes

    Redesign

    Il s’en est suivi une phase de redesign du personnage principal, ainsi que des personnages secondaires. Ce redesign est passé par la confection de statuettes en argile pour avoir une vue 3D « réelle », pour l’étude de la perspective et pour une meilleure compréhension physique du personnage.
    Statuettes de ZeMarmot

    Le résultat de la recherche sur le terrain, sur Internet et en sculpture a donné ce nouveau design qui est probablement notre design final :
    Nouveau design

    Nous avons aussi terminé le design de plusieurs personnages secondaires.

    Script

    Nous avons décidé une découpe de notre scénario en plusieurs sous‐épisodes, qui donneront un long métrage complet. Le projet sera donc visionnable sous la forme d’épisodes à intervalles réguliers, puis sous celle d’un film unique à la fin.

    Notre première sortie sera donc un « pilote » de série en un sens, et nous avons pu finaliser le script parallèlement au redesign.

    Storyboard

    Aryeom a terminé le storyboard vers fin mars. Celui‐ci fut créé en partie sur papier, ainsi que directement sur GIMP.

    Storyboard sur papier

    Animatique

    Partie finale de la pré‐production, nous avons fini une première version de l’animatique. Celle‐ci n’est pas disponible publiquement à ce jour car elle divulgue l’intégralité du script du pilote. Nous utilisons l’animatique pour la mise en place du timing, avoir un aperçu visuel et animé de nos choix de scénario et de direction, ainsi que la collaboration avec les musiciens. Un article de blog est prévu bientôt sur le sujet mais n’est pas encore publié.

    Développement de GIMP

    Grâce à ZeMarmot, je suis un développeur de plus en plus actif sur GIMP, de nos jours le second plus gros développeur avec plus de 160 commits sur la dernière année (environ 11 % des commits de l’année), pour de nouvelles fonctionnalités, des corrections de bogues, des améliorations graphiques…
    N. D. M. : Jehan est également le principal rédacteur des excellentes dépêches sur GIMP dans LinuxFr.org.

    GIMP 2.10 s’annonce de plus en plus prometteur et une cuvée exceptionnelle, et je suis vraiment content d’en faire partie.

    Logiciels d’animation

    Je travaille sur un greffon pour l’animation sur GIMP, réunissant une partie pour le storyboarding et une fonction timeline classique.

    GIMP plugins for animation

    J’ai également commencé à travailler sur un logiciel maison pour l’organisation d’un projet d’animation, ainsi que sur une extension du format OpenRaster pour la prise en charge d’animations avancées.

    Futur

    Itérations storyboard/animatique

    Nous pouvons encore faire des modifications sur le storyboard et éditer de nouvelles animatiques. Une fois une animatique finale validée, ce sera la fin de la pré‐production, similaire à un gel de fonctionnalités pour du développement logiciel. Script, scènes et plans ne changeront plus jusqu’à la fin de la production.

    Musique

    Nous avons commencé à collaborer avec l’AMMD en leur envoyant une version commentée de l’animatique. À partir de là, la composition des musiques originales correspondant au projet peut commencer.

    Commentaire pour musiciens

    Développement

    Bien entendu, le développement logiciel va continuer de plus belle, que ce soit sur GIMP génériquement, mais aussi tous nos logiciels maison. J’ai aussi des plans pour Blender VSE, mais seul l’avenir nous dira si je pourrai travailler sur tous nos objectifs logiciels avec nos faibles moyens.

    Production

    La production peut donc bientôt commencer. Cela commencera par le layout, la peinture et l’animation des décors, l’animation des personnages…
    En fonction des scènes, nous devrons travailler en collaboration étroite avec les musiciens de l’AMMD.
    La production sera suivie (bien entendu) par de la post‐production, mais nous parlerons plus tard des détails de cette étape.

    Transfert de connaissance

    Nous sommes aussi très intéressés par la promotion des logiciels libres créatifs et surtout le transfert de connaissance. Nous aimerions ainsi pouvoir lancer une série d’ateliers entre les sorties d’épisodes, dans des lieux divers, que ce soit des universités (nous avons déjà un partenariat possible avec une université en région parisienne) ou des lieux plus grand public (comme probablement le Carrefour du Numérique² que beaucoup connaissent pour être hébergeur d’évènements libristes sur Paris). Idéalement nous aimerions aussi étendre notre portée hors de Paris, et pourquoi pas même de France.

    Présent

    Libre Graphics Meeting

    Nous sommes cette semaine à Londres, pour Libre Graphics Meeting 2016. Libre Graphics Meeting est une réunion annuelle à laquelle nous participons pour la quatrième fois, avec le sponsor du projet GIMP. Cette réunion nous permet de réunir régulièrement les développeurs de GIMP et ainsi discuter du développement et de l’orientation du logiciel.
    GIMP appartement à LGM

    Au passage, nous en profitons pour présenter une courte vidéo de présentation du projet ZeMarmot et de l’état de son développement lors de l’exposition Culture et Pratiques du Graphisme Libre à la Galerie London Gallery West de l’Université de Westminster, dont le vernissage se fera ce soir, à la fin de la première journée de conférences (l’exposition durera plus longtemps que les conférences, puisqu’elle s’étend jusqu’au 22 avril).
    Logo LGM 2016

    Si vous êtes sur Londres, n’hésitez pas à passer nous voir ! Les conférences, tout comme l’exposition, sont gratuites.

    GNOME.Asia

    GNOME soutient également ZeMarmot et nous a invité à présenter le projet lors du sommet GNOME.Asia 2016.
    GNOME Asia

    Nous serons donc à Delhi, en Inde, du 21 au 24 avril. Nous y présenterons deux conférences :

    • Travail en cours sur GIMP 2.10, le 22 avril ;
    • ZeMarmot, le 23 avril.

    Là encore, si des francophones sont à Delhi, n’hésitez pas à venir nous voir dans les bâtiments de l’Université internationale Manav Rachna !

    Second voyage de recherche

    L’an dernier, nous étions partis seuls dans les Alpes. Nous sommes récemment entrés en contact avec une équipe de recherche de l’Université Lyon 1. Nous les rejoignons pour trois jours sur leur site d’études. ZeMarmot n’est pas un « documentaire animé », mais nous sommes toujours friands d’en savoir un peu plus sur notre animal fétiche pour briser les règles de la nature avec encore plus de brio !

    Financement

    Notre projet, chapeauté par l’association loi 1901 LILA, ne sert à enrichir personne. Il n’y a pas d’actionnaires ou de patron. En revanche, nous aimerions à terme être capables de rémunérer toutes les personnes travaillant sur le projet au juste prix pour le travail accompli. Une reconnaissance du travail des artistes est pour nous un but important. Notre vision du travail d’artiste est qu’il faut rémunérer le travail, mais qu’une fois réalisée, l’œuvre est libre. Elle n’appartient plus à personne, ou plutôt à tout le monde ! Et ce fait est renforcé légalement par un choix de licence libre assurant le droit de diffusion, de remixage et de réutilisation de l’œuvre. Pour nous, puisque l’œuvre est destinée à appartenir au monde, il nous paraît raisonnable que le monde la finance.
    Nous rêvons ainsi du premier studio d’animation libre 2D, associatif tout en étant professionnel !

    Le logiciel libre et l’art libre sont ainsi des parties très importantes du projet. Pour la petite histoire, nous avons eu des contacts avec un producteur prêt à prendre en charge notre projet de film après notre premier financement participatif. Mais, puisque de notre côté il n’était pas question de revenir sur notre choix de licence libre pour la diffusion, les discussions n’ont pu aboutir.

    C’est pourquoi nous reposons énormément sur notre capacité à intégrer la communauté. Nous nous intéressons depuis peu aux financements participatifs de type « régulier » permettant de nous financer mensuellement via une somme que vous fixez, qui peut être juste 1 € comme 10 € ou — soyons fous — 100 € ou plus ! Vous pouvez aussi arrêter le financement quand vous le voulez.

    Nous avons donc ouvert une page sur Patreon, qui fonctionne en dollar des États‐Unis uniquement, mais nous avons aussi une page sur Tipeee, plate‐forme similaire, en euros.

    Si vous êtes intéressé et croyez en ce que nous faisons, j’espère que vous viendrez nous donner un coup de pouce sur l’une ou l’autre plate‐forme en fonction de votre monnaie ! LinuxFr.org est le premier endroit où nous parlons de cette page Tipeee toute neuve, ouverte aujourd’hui même, puisque nous venons à peine de découvrir l’existence de cette plate‐forme !

    Nous avons aussi commencé à rechercher activement des sponsors plus importants, que ce soit des entreprises, fondations, institutions ou autre. Si votre organisme ou entreprise est susceptible d’être intéressée par le mécénat du premier film libre 2D, alors nous serions vraiment très heureux si vous nous contactiez [page contact] ou jehan chez gimp point org). Le nom et le logo de l’entreprise auront bien entendu une belle place dans le générique, ainsi que sur le site Web ou nos divers communiqués et supports officiels.

    C’est tout pour aujourd’hui. Attendez‐vous à des nouvelles et encore beaucoup d’avancées sur l’état du projet dans quelques mois par notre petite équipe travaillant avec acharnement sur le projet !

    Lire les commentaires

  • Linux sur le bureau : combien de régressions ? (Journaux LinuxFR)

    Bonjour à toutes et à tous,

    Membre du collectif Samizdat, utilisateur exclusif de diverses distributions GNU/Linux sur mes PCs depuis 1999, j'ai écrit l'article suivant sur le nouveau site du Collectif pour essayer d'alimenter la discussion à-propos de notre système d'exploitation préféré sur les ordinateurs de bureau.

    En ce trolldi, merci d'avances pour vos remarques et commentaires…

    Denez

    Lien vers l'article : Linux sur le bureau

    Lire les commentaires

  • Algo de compression JPEG waifu2x (Journaux LinuxFR)

    Salut les moules qui font du graphisme ou qui aiment les Anime.

    Je suis tombé sur une info qui je l'espère pourra intéresser certains (d'où ce journal, parce que perso, je m'en bat le coquillart).

    Disclaimer: Je ne m'y connais pas du tout dans le domaine. Mon coquillart non plus.

    Il s'agit d'un algo pour compresser en JPEG, qui serait apparemment spécifiquement pensé pour mieux gérer les images issues du monde de l'Anime.

    Ci-dessous l'exemple donné sur le github du monsieur qui est a l'origine de l'algo et de son implémentation qui est en Lua sous licence MIT et propose de la ligne de commande ainsi qu'une interface Web mais a la mauvaise idée de dépendre spécifiquement d'un GPU Nvidia.

    L'algo utilise des réseaux de neurones à convolution. Il y a donc une phase "d'apprentissage" pots-installation (qui nécessite des nombreux exemples de qualitai)!

    Une interface web de démonstration est également disponible ici.

    2D character picture (HatsuneMiku) is licensed under CC BY-NC by piapro [piapro](http://piapro.net/en_for_creators.html)

    https://github.com/nagadomi/waifu2x
    http://waifu2x.udp.jp/

    Lire les commentaires