Sélectionnez le type d'affichage

Linux (fr)

  • Microcontrôleur de DEL basé sur ESP8266 (Dépêches LinuxFR)

    ANAVI Light Controller est une nouvelle carte matérielle libre pour contrôler un ruban de DEL (LED strip RGB). Ce projet est libre et conçu avec KiCAD, et disponible à l’achat à partir de 25 € jusqu’au 27 juin 2018.
    plan du Anavi Light Controller sur KiCAD
    La carte peut être utilisée de façon autonome avec le logiciel embarqué de démo en se connectant sur une page Web (MQTT d’Eclipse Paho). Mais passer par Internet via un broker MQTT public n’est peut‐être pas idéal pour tous, donc une autre solution est tout aussi envisageable via une passerelle locale (et optionnellement accessible à distance).

    Naturellement, ce microcontrôleur (MCU) ESP8266 peut être aussi reprogrammé, c’est une alternative intéressante aux populaires Arduino car un bloc Wi‐Fi (pas libre ?) est intégré au MCU.

    Pour ma part, j’ai eu la chance de tester le produit, ça fait le job comme on dit ! Mais je vous invite à lire la revue en français sur le blog Framboise314.

    Pour utiliser une passerelle locale, il faut préalablement installer Mozilla IoT Gateway sur Raspberry Pi et reprogrammer le MCU avec mon implémentation de RGBLamp qui utilise l’API WebThings de Mozilla se connectant ensuite via mDNS, HTTP, REST (voir vidéo)…

    webthing-esp8266-webapp-20180602rzr

    Pour ceux qui ne veulent pas faire un pas hors de leur système d’exploitation préféré, considérez le précédent produit de Léon pour Raspberry Pi.

    Finalement, si vous utilisez Mozilla IoT, les retours sont bienvenus.

    Commentaires : voir le flux atom ouvrir dans le navigateur

  • Pâtes à l'huile d'olive ou au beurre ? (Journaux LinuxFR)

    En cette merveilleuse journée de mai, une question me traverse l'esprit. Est-ce que le lectorat de linuxfr préfère les pâtes à l'huile d'olive ou au beurre ?

    En effet, il semblerait que certaines personnes préfèrent les pâtes au beurre, ce qui est choquant, et j'aimerais savoir si ces personnes sont nombreuses.

    Évidemment, quand je parle d'huile d'olive, il s'agit de véritable huile d'olive, et pas quelque chose de coupé acheté en promotion dans une grande surface.

    Ce journal est à mettre en rapport avec le journal demandant si il fallait mettre de l'huile dans l'eau des pâtes. (La réponse est négative).

    Et pour finir, une nimage en rapport.

    Lire les commentaires

  • Falkon 3 le nouveau navigateur pour KDE (Dépêches LinuxFR)

    Vous souvenez‐vous de Qupzilla, petit projet commencé par le tout jeune David Rosca pour apprendre Qt, puis devenu un excellent navigateur WebKit ? En juillet 2017, pendant la réunion annuelle du projet KDE, l’Akademy, David Faure a proposé de remplacer Konqueror par Qupzilla.
    Après quelques mois d’incubation, le bébé sort des éprouvettes : Falkon 3.01 est disponible depuis le 8 mai 2018. C’est un navigateur moderne, dont les onglets tournent dans des processus séparés, en utilisant QtWebEngine, lui‐même basé sur Chromium pour le rendu.
    Logo du navigateur Falkon
    Il n’y a pas de grosses différences avec la dernière version de Qupzilla 2.2.6, c’est essentiellement une transposition vers le système de construction de KDE. Il faut bien commencer.

    Les utilisateurs de Konqueror seront en terrain familier pour la partie Web et le menu de configuration, en revanche la navigation de fichiers n’est pas encore intégrée. Il faut bien commencer (bis).

    Falkon protège bien votre vie privée (gestion des Cookies, de JavaScript, de HTML 5, Do Not Track), vous propose un greffon Flash (Pepper Flash), plusieurs moteurs de recherche (Duck Duck Go par défaut), un gestionnaire de sessions, des onglets avec indicateurs, un traducteur de pages Web, un validateur de code, des thèmes, une page « Speed Dial » facile à gérer, retrouve le contenu du formulaire quand on fait « précédent » — je reprends ma respiration, regardez les images :

    Les indicateurs (cliquables) sur les onglets :
    Onglets avec indicateurs
    Le (très pratique) gestionnaire de sessions :
    Gestionnaire de sessions dans Falkon
    Le (sympathique) menu déroulant « clic droit » :
    Le menu contextuel de Falkon

    Et comme il est jeune et crashe un peu, Falkon recharge automatiquement tous les onglets ouverts. À ce stade, vous le constatez sans doute, c’est dans l’esprit de KDE : un mélange de simplicité et de « super‐pouvoirs » à portée de configuration.

    Quelques extensions disponibles :

    • AdBlock, (San Ku Kaï c’est la bataille) contre les pubs ;
    • KWallet Passwords, un portefeuille pour les gérer tous ;
    • Vertical Tabs, les onglets bien dégagés sur les oreilles ;
    • AutoScroll, pour les claustros qui craignent les ascenseurs ;
    • Flash Cookie Manager, protège plus que plus la vie privée ;
    • GreaseMonkey, soyez le maîîîître du navigateur (scripts dispos sur http://openuserjs.org/) ;
    • ImageFinder, qui recherche par l’image, par l’image trouvera ;
    • Mouse Gesture, pour les souriceaux maniaques ;
    • PIM, pour jouer dans les formulaires ;
    • StatusBar Icons, oh que c’est zouli ces petites friandises là en bas !
    • Tab Manager, « Onglets ! Au rapport ! »

    Les WebExtensions qui sont déjà gérées par Chrome/Chromium, Firefox, Edge et Opera ont encore un long chemin à parcourir.

    L’extension ImageFinder en menu déroulant :
    Recherche par l’image sur Falkon
    L’extension Vertical Tabs en mode hiérarchique :
    Onglets verticaux dans Falkon

    D’ores et déjà, Falkon est un navigateur à mon goût : avec toutes les extensions, plusieurs onglets et trois fenêtres ouvertes, il tourne comme un charme sans charger le système ; je n’ai pas de problème sur les sites Web, ou alors tellement mineurs que je fais avec.

    Falkon est disponible pour GNU/Linux dans vos distributions et aussi en AppImage et Flatpak (via le dépôt KDE), sous Windows (à partir de Win 7) et macOS (à venir).

    Commentaires : voir le flux atom ouvrir dans le navigateur

  • Sortie de la version 7.4 de Bokeh (Dépêches LinuxFR)

    Bokeh

    Bokeh est un portail documentaire libre et communautaire sous licence AGPLv3.

    Il permet aux réseaux de médiathèques d'agréger leurs fonds physiques (livres, DVD, journaux…), numériques (fonds patrimonial numérisé, par exemple) ainsi que catalogues numériques externes (Arte VOD, Jamendo, Numerique Premium…).

    Le moteur d'indexation et de recherche intégré offre une interface unifiée aux utilisateurs pour qu'ils puissent consulter ce fonds, rechercher des documents précis ou bien élargir sur des ressources susceptibles de les intéresser.

    Les abonnés aux médiathèques peuvent réserver des documents ou gérer leurs prêts entre autres. CMS et gestion de lettres d'information permettent au médiathécaires de publier la programmation évènementielle du réseau, d'enrichir et mettre en avant leurs fonds.

    Cette version comporte de nombreuses évolutions du moteur de recherche :

    • ajout des suggestions qui permettent d'améliorer la pertinence des recherches ;
    • l'élargissement de la recherche à d'autres sites ;
    • la possibilité de restreindre la recherche à des domaines favoris ;
    • la personnalisation de l'impression du résultat de recherche ;
    • l'abonnement à une recherche via flux RSS ;
    • l'amélioration des performances du moteur (avec affichage des temps de recherche) et calculs des facettes en totalité.

    Suggestions de recherche

    Bokeh 7.4 offre aussi la possibilité de s'interfacer avec la plateforme de Prêt Numérique en Bibliothèque de Dilicom (qui n'offre malheureusement pour l'instant que des livres sous DRM Adobe).

    Vous pouvez consulter la liste complète des nouvelles fonctionnalités.

    Et l'avenir ?

    Actuellement Bokeh fournit un portail libre à plus de 200 réseaux de médiathèques.

    Nous aimerions élargir la communauté Bokeh :

    • intégration avec plus de SIGB: actuellement Bokeh peut communiquer via web services avec une douzaine de plateformes libres (Koha, Nanook) ou non (Aloes, Orphée…). Plus il y en a, mieux c'est ;
    • internationalisation : nous avons besoin d'aide pour la traduction, pour les courageux, nous avons ouvert un projet sur Transifex ;
    • plus de forks du code source, de merge requests, de hackfests et d'initiatives à l'instar du projet Waterbear;

    Lire les commentaires

  • 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

  • Choix ou obligation : quelle licence pour publier un projet ? (Laboratoire Linux SUPINFO)

    Selon la loi en vigueur en France, tout ce que vous créez vous attribue un droit moral perpétuel inaliénable et imprescriptible. Les droits d'utilisation, de modification ou de partage sont accordés indépendamment.

    Toute publication sans mention particulière relève ainsi uniquement du droit d'auteur (« Tous droits réservés »). Si vous pensiez permettre à d'autres étudiants de découvrir vos travaux (sources, tutos) et de pouvoir s'en servir simplement en les publiant, vous les exposez à des risques légaux en cas de réutilisation de leur part (lucrative ou non) sans votre consentement explicite.

    Car il faut également savoir que toute publication sur un élément de l'infrastructure mise en place par SUPINFO réserve à l'établissement les droits d'exploitation les plus étendus sur vos travaux (rubrique Propriété intellectuelle / droit d'auteur).

    En revanche, rien n'est prévu à destination des étudiants. Si vous souhaitez permettre la réutilisation de vos publications vous devez donc choisir une licence permissive et l'appliquer correctement.

    Vous pouvez visiter le comparatif mis en place par GitHub sur http://choosealicense.com/

  • RyDroid Web Proxy (1.0) : outil de capture de sessions Web (Dépêches LinuxFR)

    Pendant l’année scolaire 2016-2017, j’étais en dernière année d’école d’ingénieurs
    (l’ENSICAEN). J’ai donc fait un stage de fin d’études (à Orange, en France), avec le rapport qui va avec. J’ai fait un logiciel libre qui a été publié. En conséquence, il m’a paru logique de publier mon rapport, après avoir enlevé quelques parties (remerciements, présentation du collectif de production, conclusion personnelle, etc.) et fait de petites retouches pour qu’il soit cohérent avec ce nouveau format et la visibilité qui va avec. Cela permet de présenter plus largement ce que j’ai fait, tout en expliquant le pourquoi et comment, ce qui pourrait servir à d’autres personnes.

    Logo de CLIF Web Proxy (nom originel de RyDroid Web Proxy)

    Sommaire

    Le sujet

    Celui qui a été mon tuteur de stage participe activement au développement d'un outil de test de performance à travers le réseau, qui s'appelle CLIF et qui est présenté plus loin dans cet article. Le cas le plus courant est le test pour le web, avec le protocole HTTP et sa version chiffrée HTTPS. Pour faciliter l'usage pour ce cas commun, il faut que créer un scénario de test pour ce dernier soit aisé.

    Il existait déjà une solution : un proxy pouvait être configuré dans le navigateur web pour intercepter les flux réseaux et ainsi enregistrer les informations pertinentes dans le format adéquat (basé sur XML) pour rejouer une session web avec CLIF. Configurer un proxy dans un navigateur web peut être difficile pour certaines personnes ou perçu comme tel. De plus, le proxy ne gère pas le HTTPS (qui est de plus en plus courant), bien qu'il aurait été possible d'en ajouter la gestion, cela aurait nécessité d'ajouter un certificat dans le navigateur web. Mon tuteur voulait un outil plus simple à utiliser et qui gèrent le HTTPS, d'où ce stage.

    Comme CLIF, l'outil réalisé devait être du logiciel libre sous licence GNU LGPL en version 3.

    État de l’art

    Outils de test de charge

    La liste n'est pas exhaustive, mais il y a un article sur Wikipédia en anglais si on en désire une qui cherche à l'être. Cette partie a pour intérêt de présenter rapidement des outils cités plus loin dans l'article présent et de mettre en perspective le programme de mon tuteur de stage.

    Apache JMeter

    JMeter est un logiciel libre de la fondation Apache. Il est très populaire et packagé par au moins Debian et Trisquel GNU/Linux. Pour définir un test de charge, il faut lui soumettre un fichier XML. Il est extensible avec des modules complémentaires.

    Logo de Apache JMeter

    Gatling

    Gatling est un logiciel de test de charge, avec un focus sur les applications web. Il est sous licence Apache 2.0, donc libre. Il est écrit en Scala. Il est packagé par au moins Debian et Trisquel GNU/Linux.

    Selenium

    Selenium est un logiciel pour automatiser la navigation web à travers un navigateur web. Il peut donc servir à faire des tests, mais aussi automatiser des tâches administratives se faisant via le Web. Il est libre via la licence Apache 2.0.

    Tsung

    Tsung est un logiciel de test de charge distribué. Il gère différents protocoles (dont HTTP, XMPP, LDAP, et MQTT). Il est libre sous licence GNU GPL version 2.0. Le langage de programmation utilisé est Erlang. Il prend en entrée un fichier XML. Il est disponible sous forme de paquet dans au moins Trisquel GNU/Linux et Debian.

    Logo de Tsung

    Locust

    Locust a la particularité d'utiliser des scripts en Python pour définir le comportement des utilisateurs virtuels, alors que les autres outils utilisent généralement du XML et/ou une interface graphique. C'est un logiciel libre sous licence "MIT".

    Logo de Locust

    The Grinder

    The Grinder est un framework pour le test de charge. Il est adapté pour le test distribué sur plusieurs machines. Il est libre et écrit en langage Java.

    Taurus

    Taurus a pour but de cacher la complexité des tests fonctionnels et de performance. Il fait cela en étant une enveloppe pour JMeter, Gatling, Locust, Grinder, et Selenium WebDriver. Il prend en entrée un fichier au format YAML. C'est un logiciel libre sous licence Apache 2.0.

    Logo de Taurus

    CLIF

    CLIF est un logiciel libre initié, piloté, et maintenu par celui qui a été mon tuteur de stage (Bruno Dillenseger). C'est un acronyme récursif pour "CLIF is a Load Injection Framework". Ce projet est hébergé par le consortium OW2. Il est écrit dans le langage de programmation Java. Il a une interface en ligne de commande et une interface graphique sous forme de module complémentaire pour Eclipse. Il propose plusieurs manières de définir un test de charge, comme cela est expliqué dans une sous-sous-section (de cet article) partiellement dédiée. Il n'y a pas de paquet Debian, notamment à cause des nombreuses dépendances et d'au moins une dont les sources n'auraient pas été retrouvées.

    Logo de CLIF

    CLIF permet de déployer des injecteurs de requêtes répartis pour mesurer les temps de réponse. Il permet également de déployer des sondes afin de mesurer la consommation des ressources (processeur, réseau, mémoire, disque, etc.). Son environnement de scénario ISAC offre une façon formelle de définir les scénarios sous forme de comportements d'utilisateurs virtuels et d'une spécification du nombre d'utilisateurs virtuels actifs de chaque comportement au cours du temps. CLIF a été spécialement conçu pour être rapidement adaptable à toute sorte de cas de test (un assistant Eclipse permet de définir ses propres modules complémentaires pour intégrer de nouveaux protocoles ou de nouveaux jeux de données), y compris des hauts niveaux de charge (comme des centaines d'injecteurs et des millions d'utilisateurs virtuels). En pratique, CLIF est utilisé pour des tests de tenue en charge, mais également pour des tests fonctionnels, des tests en intégration continue et de la supervision de qualité d'expérience utilisateur, notamment via son module complémentaire pour Jenkins.

    Le code source est sur l'instance GitLab de OW2, à part le module complémentaire pour Jenkins qui est sur GitHub. CLIF est aussi disponible sur la forge historique de OW2 (qui propose des versions compilées).

    Loads et Molotov

    Loads et Molotov sont libres et écrits en langage Python. Ils permettent d'écrire des tests unitaires. Loads est développé et testé sur Python 2.6 et 2.7, tandis que Molotov nécessite Python 3.5 ou plus.

    Logo de Loads et Molotov par Juan Pablo Bravo

    HPE LoadRunner

    HPE LoadRunner est un logiciel privateur de test de charge, qui ne fonctionne complètement que sous Microsoft Windows. Il peut être étendu via des formats d'autres outils (comme JMeter) et des scripts dans différents langages (comme C et Java). Sa première version date de l'an 2000, il est depuis toujours amélioré, ce qu'il lui a permis d'acquérir une place importante dans le domaine du test de charge.

    megaLOAD

    megaLOAD est présenté comme étant une plateforme en ligne de test de charge qui serait facile à utiliser et capable de monter à l'échelle. Il aurait été spécialement créé pour tester les services de type back-end ayant vocation à être très robustes. Il est fait par Erlang Solutions. Il gère HTTP et serait suffisamment extensible pour gérer n'importe quel protocole. Il serait possible de l'utiliser via un navigateur web et/ou une interface de programmation RESTful. Il est disponible sur AWS (Amazon Web Services).

    Siege

    Siege est un outil libre pour tester la capacité de charge des implémentations des protocoles HTTP(S) (version 1.0 et 1.1) et FTP. Il est écrit en langage C et fonctionne sur divers systèmes d'exploitation POSIX (comme GNU/Linux et des BSD récents, mais pas Windows). Il est libre sous la licence GPL en version 3.0.

    Outils de capture d’utilisation Internet

    Différentes organisations proposent des services web pour l'injection de charge. Certaines d'entre elles proposent un outil pour facilement capturer une session d'usage du réseau, ce qui permet ensuite de la rejouer facilement.

    On pourrait naïvement penser que tcpdump, Wireshark, ou Scapy sont de bons candidats sans rien faire. Ce serait vrai si les communications passaient toutes, ou au moins une vaste majorité, en clair sur les réseaux et que cela n'était pas amené à changer. En effet, elles sont de plus en plus chiffrées (avec une accélération depuis 2013 suite aux révélations d'Edward Snowden), ce qui permet de "garantir" (par les mathématiques) la confidentialité de ce qui est chiffré (il y aura toujours un minimum de méta-données non chiffrées). Il faut donc trouver un moyen de contourner le chiffrement quand il y en a, ce que tcpdump, Wireshark, et Scapy ne font pas automatiquement. De plus, ces derniers montrent une quantité de détails techniques inutiles pour l'individu (dans notre contexte) et qui pourraient le perturber (par peur de l'inconnu et/ou difficulté à percevoir ce qui est pertinent).

    NeoLoad

    NeoLoad Recorder est une application qui enregistre un parcours utilisateur fait à travers un proxy. Pour cela, il crée un proxy sur la machine sur laquelle il est exécuté. Ensuite, il génère un certificat X.509 qui va servir à déchiffrer les échanges chiffrés via TLS. Puis, il démarre Firefox dans lequel il faut configurer le proxy et ajouter le certificat si on souhaite enregistrer les communications chiffrées via TLS. Après cela, il n'y a plus qu'à naviguer. Une fois que l'on veut arrêter, il faut penser à enlever le proxy (mais on s'en rendra vite compte si on oublie), et ne plus faire confiance au certificat (ce qui ne sera rappelé par aucune erreur).

    Cette solution technique est problématique si on doit passer par un proxy pour accéder à un réseau sur lequel le site web à tester est accessible. Techniquement, il est écrit en Java. Les données sont enregistrées dans un format inconnu et non trivial.

    Schéma du fonctionnement de NeoLoad Recorder

    HPE StormRunner Load

    HPE StormRunner Load est un service distant pour faire du test de charge et en analyser les résultats. Il est basé sur du logiciel privateur et se manipule via une interface web. Pour faciliter son usage, divers outils (non libres) sont mis à disposition.

    Pour rendre aisé la capture de la navigation web, il propose 2 outils : TruClient Lite et TruClient Standalone. Ils ont pour but de capturer (directement) ce qui se passe dans un navigateur web (donc sans proxy externe et sans certificat pour le HTTPS). TruClient Lite est un module complémentaire pour Chromium (et donc son principal dérivé Google Chrome), qui utilise les paramètres de proxy du navigateur web. TruClient Standalone est un logiciel (fonctionnant uniquement sur Windows) qui peut au choix se baser sur les moteurs de Firefox (Gecko), Chromium, ou Internet Explorer, mais également simuler un mobile ou une tablette (en configurant correctement la résolution du navigateur web et son agent utilisateur), il prend les contrôles sur le proxy du navigateur web. L'absence de contrôle sur le proxy est problématique si on doit passer par un proxy pour quitter un réseau interne, mais il est possible de lui indiquer un proxy après que le script soit généré. Ils enregistrent les clics sur les boutons avec leurs intitulés (même s'ils ne sont pas des liens), et se basent sur l'intitulé des boutons pour naviguer et pas sur les URLs, ce qui est pratique si les références des liens changent. Ils permettent également de rejouer (automatiquement) un script enregistré avec une visualisation graphique, cependant ils sont perdus s'ils essayent de rejouer mais que le texte du bouton n'est pas le même (par exemple à cause de la langue par défaut différente en fonction du navigateur web).

    Schéma du fonctionnement de HP TruClient

    BlazeMeter

    BlazeMeter est une plateforme SaaSS web. Il peut réaliser des tests de charge et montrer des statistiques (en temps réel) qui en résultent. Il propose une API web pour automatiser les tests, par exemple dans le cadre de l'intégration continue (via Jenkins ou un autre outil similaire). Il utilise divers logiciel libres (dont JMeter, Gatling, et Taurus) et gère donc leurs formats de données.

    Pour simplifier les tests web, un outil de capture de session web est proposé, BlazeMeter Proxy Recorder. C'est malheureusement du logiciel privateur. On peut le tester gratuitement pendant 1 mois. Pour l'utiliser, il faut s'inscrire et l'activer. Ensuite, il faut aller dans son interface, ce qui crée un proxy (sans intervention du testeur ou de la testeuse) et un certificat X.509 (souvent appelé d'une manière réductrice certificat TLS). Pour enregistrer ce que l'on fait via un client web, il faut activer le proxy (via un simple bouton) et configurer ce dernier dans notre client web. S'il l'on souhaite que les communications chiffrées soient enregistrées, il faut ajouter un certificat qui va permettre au proxy de déchiffrer avec une de ses clés privées (au lieu d'une clé privée du service web consulté). Au fur et à mesure de la navigation (via le proxy), l'interface graphique de BlazeMeter Recorder montre ce qu'il a capturé. Pour finaliser une session, il suffit de cliquer sur un bouton (de l'interface web). On peut ensuite avoir le résultat sous divers formes (URL pour BlazeMeter, fichier JMeter, fichier pour Selenium WebDriver, ou fichier pour Taurus).

    Schéma du fonctionnement de BlazeMeter Recorder

    SOASTA Cloud Test

    SOASTA Cloud Test est un SaaSS web pour le test de charge et l'analyse des données (en temps réel) qui en sont issues. Parmi les analyses qu'il propose, il a l'originalité de proposer une comparaison du temps de chargement et du revenu généré sur une période. Il permet de choisir où seront géographiquement les utilisateurs virtuels d'un test. Il propose une interface en 3 dimensions avec les flux réseaux qu'il génère sur une carte de la Terre, dont l'intérêt est probablement discutable, mais cela peut être pertinent pour se faire payer le service par un·e commercial·e. Il peut importer des fichiers JMeter.

    Contrairement à certains de ses concurrents, son outil de capture d'usage du réseau fonctionne sur plusieurs protocoles Internet (temps des connexions TCP, DNS, TLS, HTTP, etc.). C'est une machine virtuelle (sous CentOS) qui fonctionne avec VMware Player, ce qui est très lourd (en termes de puissance de calcul, de mémoire vive, et de place dans la mémoire persistante puisque le disque de la machine virtuelle fait 15Go). Ce choix technique le réserve à des informaticien·ne·s ayant du temps ou des personnes ne voulant pas se limiter au Web.

    La réalisation du projet

    Les outils utilisés

    Les outils pour le développement lui-même

    • Système d'exploitation : Debian GNU/Linux 9 "Stretch" (qui devenu stable pendant mon stage, inclut PHP 7, et est vastement utilisé)
    • Éditeur de code : GNU Emacs (parce qu'il ne nécessite pas de souris et qu'il est beaucoup plus léger qu'un environnement de développement intégré)
    • Langage de programmation : PHP 7 (qui a une librairie standard fourni pour le Web, permet la déclaration de type sur tous les types non objets, et a des avantages de facilité d'installation pour les applications se basant dessus comme cela est expliqué dans la partie qui est dédiée à ce sujet)

    Les outils pour gérer le développement

    • Gestionnaire de versions : git ("le gestionnaire de contenu stupide" (d’après son manuel) est un logiciel libre de gestion de versions décentralisé, libre, performant, et populaire)
    • Forges logicielles :
      • tuleap (une forge logicielle, comprenant des outils élaborés de gestion de projets et des possibilités de gestion fine des droits)
      • GitLab (de plus en plus utilisé, pensé avant tout pour les développeurs et développeuses, et je l'utilise pour des projets personnels)

    Les outils pour les tests

    Les outils « annexes »

    Le résultat

    Schéma du fonctionnement de mon proxy en PHP

    Comparaison avec un proxy classique

    Un proxy classique est légèrement plus dur à utiliser. En effet, il faut que l'utilisateur ou utilisatrice configure un proxy. De plus, pour les échanges chiffrés, il faut ajouter un certificat.

    Néanmoins, un proxy classique a un énorme avantage, il est techniquement plus simple, puisqu'il fait moins de choses, et est donc bien plus performant. En effet, le proxy que j'ai réalisé doit détecter puis analyser entre autres le HTML et le CSS, et enfin potentiellement les modifier, ce qui nécessite une puissance de calcul non négligeable si plusieurs agents l'utilisent en même temps.

    « Proxifier » une URL

    Mon proxy n'est pas un proxy "classique", il change les URLs pour qu'elles pointent toutes vers lui, c'est ce que l'on peut nommer la "proxification" d'URL. En simplifiant, cela revient à ajouter un préfixe à l'URL. Techniquement le préfixe est une référence du proxy (nom de domaine, adresse IP, ou nom purement symbolique comme localhost), puis la page qui "proxifie", et enfin le ou les différents paramètres GET à passer à la page.

    Il y a un paramètre obligatoire qui est l'URL de la page à "proxifier". Celui-ci peut contenir des caractères illégaux comme valeur de paramètre GET (comme un point d'interrogation "?" ou une esperluette "&"), il faut donc encoder ce paramètre au moment de la "proxification", et le décoder au moment de son usage. Cela est fait avec les fonctions PHP urlencode et urldecode (pour lesquels il existe des équivalents en JavaScript).

    Il y a aussi 2 paramètres GET facultatifs. Ils ont pour nom proxy-url et proxy-port et permettent d'indiquer à mon proxy d'utiliser un proxy classique (en spécifiant à minima une URL et potentiellement un numéro de port). Il y a d'autres moyens pour cela, mais ce moyen est prioritaire sur les autres. Si au moins un est indiqué, il faut le(s) propager à toutes les URLs à "proxifier".

    Récupérer une ressource Web

    Un proxy réseau sert d’intermédiaire pour récupérer une ressource. La problématique est banale, mais nécessite néanmoins un peu de temps pour être gérée correctement.

    La première approche que j'ai utilisée est d'utiliser la fonction file_get_contents. C'est une fonction de haut niveau qui prend en entrée obligatoire le chemin vers une ressource (du système de fichiers ou via le Web), et retourne le contenu si elle a réussi à l'obtenir. C'est très facile d'emploi, cependant elle a un gros manque : elle ne récupère pas les en-têtes HTTP, or elles peuvent être pertinentes pour rejouer une session web (ce qui pour rappel est la finalité indirecte de mon proxy). Il fallait donc proposer un autre moyen activé par défaut si disponible.

    Il y a une commande et une bibliothèque associée pour récupérer (entre autres) une ressource sur le Web qui est très connu et a de nombreuses options : il s'agit de curl. C'est libre et existe depuis longtemps (la première version date de 1997), ce qui explique au moins en partie qu'il y ait des fonctions pour utiliser curl dans la librairie standard de PHP. Dans les archives officielles de Debian, il est dans le paquet php-curl qui n'est pas une dépendance du paquet php, probablement pour mettre une installation minimaliste de PHP quand toute la librairie standard du langage n'est pas nécessaire.

    Une application web ne se sert pas nécessairement que de l'URL pour définir (et potentiellement générer) la ressource à envoyer. En effet, une ou des en-têtes HTTP de la requête peuvent être utilisées. Il a donc fallu faire suivre les en-têtes du client web envoyés au proxy au service web "proxifié". Cela a pu être fait avec les 2 méthodes de récupération de ressources.

    Certaines URLs commencent par //, ce qui indique qu'il faut deviner quel protocole utiliser. Le moyen employé pour gérer ce cas est de faire d'abord une requête en HTTPS (la version sécurisée de HTTP), puis renvoyer la réponse si elle est non nulle, sinon renvoyer la réponse de la requête en HTTP.

    Mon proxy peut nécessiter de passer par un proxy réseau non transparent pour accéder à Internet ou un autre réseau IP. C'est le cas dans un nombre non négligeables d'organisations, or certaines applications faites en interne peuvent n'être disponibles qu'en externe et le Web regorge d'exemples pour tester mon proxy. Il fallait donc que mon proxy puisse récupérer une ressource en passant par un proxy réseau non transparent. Cela a été implémenté avec les 2 méthodes de récupération de ressources et il y a plusieurs manières de configurer un proxy (paramètres HTTP GET, cookies, et fichiers INI).

    La gestion du HTML

    Il faut "proxifier" chaque URL d'un document HTML. Le HTML se manipule facilement via DOM et peut être parcouru avec XPath. Il parait donc assez simple de gérer le HTML. Ça l'est… dans la majorité des cas, mais quelques cas rares compliquent les choses.

    Dans les cas triviaux, on peut citer (avec l'expression XPath) : des liens avec a@href, des images avec img@src, les scripts avec script@src, les frames avec frame@src, des vidéos avec video@src, et d'autres. Mais comme nous allons le voir, le HTML est plus compliqué que cela.

    Démarrons avec un cas méconnu si on a appris le HTML récemment, car notoirement obsolète : l'attribut background. Il permet de définir un fond avec l'URL d'une image pour un élément HTML. Pour séparer la structure de la forme, il faudrait utiliser du CSS. Mais il reste de veilles pages web et des personnes n'ayant pas mis à jour leurs connaissances, il a donc fallu gérer ce cas. Cet attribut n'est valide que sur //html/body, mais en pratique certains sites web l'utilisent sur d'autres éléments (comme http://www.volonte-d.com/) et au moins Firefox prend en compte ce cas non standard, qu'il a fallu gérer.

    Poursuivons avec un cas inverse, que l'on ne connait bien que si on a des connaissances à jour : les images ! En effet, il y avait un temps où il y avait uniquement img@src. Cependant pour optimiser la bande passante et avoir une image matricielle d'une taille adaptée, il est maintenant possible de proposer plusieurs URLs pour différentes tailles et formats. La balise img peut maintenant avoir un attribut srcset, qui contient une ou plusieurs URLs séparées par des virgules et avec des indications de la qualité (par exemple <img srcset="img1.png 1x, img2.png 2x" />). Il y a également la balise picture qui peut contenir une ou plusieurs balises source qui peuvent avoir un attribut src ou srcset (//html/body/picture/source@srcset a la même syntaxe que //html/body/img@src).

    La naïveté peut laisser penser que les liens sont triviaux à gérer, c'est presque le cas. Les liens commençant par http:// et https:// sont les plus courants et il faut les "proxifier", mais il y a d'autres cas. Tout d'abord, il n'y a pas que HTTP et HTTPS, il y a d'autres protocoles dont il peut y avoir des références sur le Web et qui ne sont pas gérés par mon proxy, le plus courant étant probablement l'historique FTP (File Transfer Protocol). De plus, il y a des liens sans protocoles pour l'attribut href. En effet, il y a des liens d'actions (qui ne doivent pas être "proxifiés"), pour le courriel avec mailto:, pour le téléphone avec tel: (défini dans la RFC 3966), pour le JavaScript avec javascript: (malgré qu'il y ait l'attribut facultatif onclick et un événement associé en DOM 2), et pour une ressource d'un réseau pair-à-pair avec "magnet:". Il y a également des liens avec un protocole implicite ! Ils commencent par // et les clients web les remplacent par https:// ou http:// ou essayent l'un puis l'autre, il faut donc les "proxifier".

    Rediriger une page web peut se faire via HTTP, mais aussi en HTML. L'intérêt de la méthode en HTML est de pouvoir rediriger après un certain temps (en secondes) et potentiellement uniquement s'il n'y a pas de support JavaScript (en utilisant la balise noscript pour faire cette condition). Cela se fait avec une balise meta dans //html/head (et sans autre parent) en indiquant un temps et potentiellement une URL (par exemple <meta http-equiv="refresh" content="5" /> ou <meta http-equiv="refresh" content="0; url=https://example.net/" />). Il faut donc chercher ce genre de balise (par exemple avec /html/head/meta[lower-case(@http-equiv)='refresh' and contains(lower-case(@content), 'url=')] en XPath 2.0), puis extraire l'URL, ensuite la "proxifier", et enfin changer la valeur de l'attribut tout en conservant le temps.

    Pour utiliser du CSS dans du HTML, il y a plusieurs possibilités. La méthode la plus utilisée et recommandée est de faire référence à un ou plusieurs fichiers via une balise meta avec un attribut rel avec la valeur stylesheet en indiquant l'URL comme valeur de l'attribut href. On peut également vouloir inclure du CSS dans le HTML, ce qui est une mauvaise pratique, mais elle est toujours permise par les navigateurs web. Il y a 2 moyens pour cela : la balise style (/html//style[not(@type) or lower-case(@type)='text/css'] en XPath 2.0) et l'attribut style (/html/body[string(@style)] | /html/body//*[string(@style)]). Il faut donc récupérer le CSS puis le "proxifier" et ensuite mettre la version "proxifiée" dans la balise.

    La gestion du CSS

    Je n'y avais pas pensé au début, mais il peut y avoir des URLs dans du CSS. Elles peuvent par exemple servir pour définir un fond avec une image, inclure un autre fichier CSS, ou importer une police d'écriture
    (depuis CSS3 avec @font-face). Puisque le CSS sert pour la mise en page, il n'est pas négligeable, et a donc du être géré.

    J'ai identifié 2 situations où des URLs sont utilisées dans du CSS. La première et la plus courante est avec la "fonction" url en tant que valeur d'une propriété (par exemple background-image: url(image.png);) Le paramètre peut contenir des espaces avant et après. De plus, il peut être entouré d'un séparateur (soit un guillemet simple soit un double guillemet, heureusement que les formes valides en ASCII sont prises en compte). Le deuxième cas est avec l'instruction @import. Elle peut prendre directement une URL (avec les mêmes séparateurs que la "fonction" url) (par exemple @import "style.css";) ou via la "fonction" url (par exemple @import url(style1.css);).

    Même avec la version 7 de PHP (une version récente d'un langage de programmation orienté web), il n'y a pas de manipulateur lexical pour CSS dans la bibliothèque standard. Plutôt que d'ajouter une dépendance potentiellement non maintenue sur le long terme, j'ai écrit du code pour mon cas particulier. Cela a été motivé par le fait que CSS continue d'évoluer et qu'une avancée de ce dernier pourrait casser le fonctionnement d'un analyseur lexical. Néanmoins mon code souffre d'une limitation : il analyse le CSS ligne par ligne, or la valeur d'une propriété peut être définie sur plusieurs lignes (mais c'est peu courant notamment avec l'usage de programmes pour réduire la taille d'un fichier CSS comme clean-css et YUI Compressor). De plus, mon code ne "proxifie" pas toutes les URLs sur certaines lignes longues pour une raison inconnue. Un analyseur syntaxique de CSS pourrait être utilisé pour "proxifier" toutes les URLs (puisque mon code ne gère pas tous les cas), comme PHP-CSS-Parser de sabberworm, cssparser de Intekhab Rizvi, ou celui de Hord (pour lequel Debian a un paquet). Une option pourrait être ajoutée pour désactiver l'analyseur syntaxique au profit de mon code s'il venait à émettre une erreur fatale à cause d'un cas non géré (potentiellement nouveau) de CSS ou d'une approche moins laxiste que les navigateurs web (qui ont tendance à vouloir gérer à tout prix du code même non valide).

    La gestion du HTTP

    Hormis la ressource demandée par une requête HTTP, il peut y avoir au moins une URL pertinente à "proxifier" (mais cette fois à la réception d'une requête et pas en modifiant préalablement les éléments pouvant en engendrer). Un cas a été identifié : l'en-tête Location. Elle permet d'indiquer une nouvelle URL pour une ressource, expliqué autrement elle sert pour faire une redirection. C'est trivial à gérer si on a déjà le nécessaire pour "proxifier" une URL. En effet, chaque champ d'une requête a un intitulé et une valeur séparée par ":" et sur une seule ligne. C'est donc très simple à analyser et par extension de créer une structure de données pour le HTTP.

    La gestion du HTTP ne s'arrête néanmoins pas là. En effet, un serveur web répond à des requêtes HTTP, or le but de mon stage (et du projet qui en découle) est de rejouer une session web. Il faut donc à minima enregistrer les URLs demandées en extrayant chacune du paramètre GET correspondant. De plus, un serveur web ou une application peuvent répondre différemment en fonction des en-têtes HTTP (heureusement sinon aucun logiciel ne les utiliserait et elles seraient donc inutiles). Il y a donc un intérêt potentiel à les stocker (pour pouvoir reproduire exactement une session web) et en enlever certaines (que l'on peut juger superflues). Il a donc été fait en sorte de les enregistrer et des options ont été faites pour en enlever certaines.

    Gérer les formulaires Web

    Les formulaires web représentent un cas spécial. On pourrait naïvement penser que ce n'est qu'une question de HTML. Mais c'est légèrement plus compliqué que cela.

    Pour les formulaires qui utilisent (implicitement ou explicitement) la méthode HTTP GET (/html/body//form[not(@action) or (string(@action) and lower-case('@method')='get') or not(@method))] en XPath 2.0), il s'agit purement de HTML. Les paramètres GET potentiellement présents dans l'URL de l'attribut form@action (qui définit à quelle URL envoyer les données du formulaire) sont ignorés, en effet ce sont les champs du formulaire qui sont passés en paramètres GET. Il faut donc créer un champ dans le formulaire (avec la balise input) pour l'URL "proxifiée" et le cacher (ce qui se fait en créant un attribut type et lui attribuant la valeur hidden).

    Pour les formulaires utilisant la méthode HTTP POST (c'est l'unique autre possibilité), il faut "proxifier" l'URL de l'attribut action s'il y en a un. Une fois la requête POST reçu sur mon proxy, il faut détecter que c'est une méthode POST pour : la renvoyer en méthode POST au service "proxifié" (par défaut c'est la méthode GET qui est utilisée), ne pas essayer de "proxifier" le contenu, et ne pas renvoyer l'en-tête HTTP Content-Length (défini dans la section 14.13 de la RFC 2616) (ce qui peut faire échouer l'appel PHP à curl, probablement dans le cas où PHP ait encodé différemment le contenu et donc potentiellement changé la taille). Bien entendu, il faut aussi penser à enregistrer ces paramètres POST.

    La gestion du JavaScript

    Je n'y avais pas pensé au début (alors que c'est évident quand on fait du web en 2017), mais le JavaScript peut être source de requêtes web. Il faut "proxifier" les URLs de ces requêtes, bien entendu avant qu'elles n'aient lieu. La première idée qui pourrait venir à l'esprit serait d'utiliser un analyseur syntaxique de JavaScript, ce qui serait très lourd et il en existe à priori qu'en C et C++ (comme V8 de Google qui est libre) (mais il est possible d'appeler des binaires issus de ces langages avec PHP). Heureusement il n'y a pas de moyen de faire des requêtes avec le langage uniquement (c'est-à-dire avec des mots-clés de ce dernier), il faut en effet utiliser la bibliothèque standard du JavaScript. En JavaScript, une fonction peut être redéfinie sans erreur, y compris celles de la bibliothèque standard, c'est considéré comme dangereux (à juste titre) par certains, mais cela peut être fort utile dans de rares cas, comme celui présentement décrit.

    2 cas de fonctions à surcharger pour "proxifier" des URLs ont été identifiés et gérés. Dans chaque cas, il faut garder en mémoire la fonction actuelle (peut être qu'un autre script a déjà changé le comportement de base de la fonction), puis créer une nouvelle fonction qui "proxifie" le ou les arguments contenant potentiellement une ou plusieurs URLs, et enfin appeler la fonction à "proxifier" avec les arguments potentiellement modifiés, tout en retournant son résultat si elle en retourne un. Il ne reste ensuite plus qu'à surcharger, en donnant le même nom pour une fonction ou en modifiant le prototype de la classe pour une méthode d'instance (en effet le JavaScript a un système de classe par prototype qui diffère du modèle traditionnel présent par exemple en PHP et Java). Le terme "fonction" doit ici être compris comme une fonction en C ou en PHP, ce qui ne doit pas être confondu avec la notion de fonction en JavaScript, car celle-ci est bien plus large (les constructeurs et les méthodes sont aussi des fonctions et d'ailleurs défini avec le même mot-clé function).

    Le premier cas est facile à deviner, il s'agit de la fonction à laquelle on passe une URL pour une requête AJAX. C'est l'abréviation de "Asynchronous JavaScript and XML" et désigne un moyen de faire des requêtes synchrones ou asynchrones avec le langage JavaScript. Pour cela, il faut créer un objet de classe XMLHttpRequest (on passe ici sous silence partiel le cas de veilles versions d'Internet Explorer de Microsoft), ensuite définir un comportement (sous forme de fonction) pour le changement d'état (envoyé, reçu, etc.) puis utiliser sa méthode open, et enfin envoyer la requête avec la méthode send. Il suffit de "proxifier" le deuxième argument de la méthode open (le premier étant pour la méthode HTTP).

    Le second cas est moins commun et je ne soupçonnais pas son existence. Il s'agit de l'inclusion dynamique (en JavaScript) de balise script avec un attribut src existant et avec une valeur non nulle. Cela déclenche la récupération du script (grâce à son URL issue de l'attribut src), puis l'exécute (ce qui permet d'éviter la fonction eval). Un élément DOM a une méthode setAttribute, il faut donc la "proxifier" quand elle est appelée sur une balise script et ne "proxifier" le second argument (qui correspond à la valeur de l'attribut) que quand le premier argument vaut (en étant insensible à la casse) src (puisque cette balise peut avoir d'autres attributs comme type).

    La configuration

    Un certain nombre de choses est configurable. Il y a 4 catégories : le proxy pour faire des requêtes (une URL et un numéro de port), la capture de session (enregistrer ou pas, en-têtes HTTP à garder, etc.), le journal d'erreurs et d'avertissements (emplacement en tant que fichier, est-il publique ou non, etc.), et l'interface graphique (montrer des aides au débogage ou pas, afficher certains éléments facultatifs ou pas, etc.).

    La configuration se fait via plusieurs sources et sous forme de cascade. En effet, une source peut avoir une valeur indéfinie, mais une source de moindre priorité peut avoir une valeur définie. De plus, certaines sources ne doivent pas pouvoir définir des valeurs pour certaines propriétés. Par exemple, une source venant du client web ne doit pas être en mesure de définir le chemin d'enregistrement du fichier journal (puisqu'il pourrait s'en servir pour écrire un fichier utilisé par une autre application). Pour configurer au niveau du serveur, il faut utiliser un ou plusieurs fichiers INI.

    Les différentes sources de la plus prioritaire à celle qui l'est le moins est :

    • les paramètres GET dans l'URL
    • les cookies HTTP
    • la session PHP
    • un fichier INI spécifique à une catégorie dans le dossier de l'application
    • un fichier INI général pour toutes les catégories dans le dossier de l'application
    • un fichier INI général pour toutes les catégories dans un dossier système
    • les valeurs par défaut (qui sont codées en dur)
    Exemple de configuration (au format INI)
    # Une ligne commençant par un croisillon "#" est un commentaire.
# Le dièse "♯" ne marche pas.

# Une section aurait pu être utilisée.
proxy-url=https://proxy
proxy-port=80

[session-captured]
save-session=true
save-cookies=false

    Enregistrement des données

    À chaque fois qu'une ressource est récupérée par le proxy, celui-ci doit pouvoir enregistrer la demande. L'enregistrement se fait dans le format XML, pour sa manipulation aisée (notamment via DOM, XPath, et XSLT), les nombreuses bibliothèques le gérant, le fait qu'il soit standardisé, et qu'il ne demande pas un serveur de gestion de bases de données. Néanmoins, l'enregistrement en XML est "isolé", de sorte qu'il soit facile (en ajoutant le code nécessaire) d'enregistrer dans un autre format (comme le JSON) ou avec un système de base de données (qui ajouterait une dépendance et une lourdeur) et d'ajouter une option pour choisir le format.

    Un client web peut faire plusieurs requêtes simultanées (notamment pour réduire la latence avec HTTP 1). Or cela peut provoquer une écriture simultanée de nouveaux enregistrements, ce qui est presque certain de résulter en un fichier incorrect. Il a donc fallu mettre en place un verrou pour qu'un fichier d'enregistrement ne puisse être utilisé que pour un enregistrement à la fois. Cela a été fait avec la fonction flock (qui se base sur la fonction C du même nom). La mise en place et la gestion du verrou est dans une classe abstraite qui pourrait être réutilisée pour un autre format de fichier.

    Le proxy était à la base mono-utilisateur. En effet, toutes les données enregistrées étaient nécessairement dans un seul et même fichier. Pour que chaque utilisateur/utilisatrice n'ait pas à installer le proxy, il fallait qu'il soit mutualisable et donc capable de gérer plusieurs personnes. Plutôt qu'un processus de création d'un compte (qui aurait été lourd à utiliser et implémenter), un système d'identifiant de session a été mis en place. Concrètement une personne qui demande à créer une session d'enregistrement se voit retourner un identifiant textuel sous forme de cookie HTTP. Cet identifiant est un nombre pseudo-aléatoire (puisqu'il n'y a pas de réel aléatoire en informatique) obtenu avec une fonction réputée sûre pour la cryptographie (donc imprédictible) (dans mon cas la fonction random_bytes de PHP), ce qui permet de s'assurer que l'on ne puisse pas prédire l'identifiant des autres utilisateurs et utilisatrices. L'identifiant est utilisé comme une partie du nom de fichier, or le nom du fichier aurait été très grand avec la valeur en décimale et illisible avec la valeur en ASCII ou unicode, il est donc le résultat d'une fonction qui prend en entrée le nombre aléatoire et retourne une valeur en hexadécimale. La fonction de hashage SHA-512 a été utilisée, car elle a l'intérêt de créer très peu de collisions (2 valeurs d'entrée ayant la même valeur de sortie) et peut compliquer une attaque s'il venait à être découvert que la fonction n'est pas cryptographiquement sûr (puisqu'une fonction de hashage est censée ne pas avoir de fonction inverse).

    À tout cela, il manquait un élément clé. En effet, les données sont enregistrées pour rejouer un "session web", ce qui nécessite d'enregistrer des éléments techniques, mais également la temporalité de ceux-ci. Pour ce faire un timestamp POSIX (c'est-à-dire le nombre de secondes depuis le premier janvier 1970) est enregistré pour chaque requête. Ce format a l'avantage d'être simple et d'être très courant. Néanmoins la seconde (au format entier) n'est pas une unité très précise, puisqu'un client web sur un ordinateur moderne met moins d'une seconde pour demander différents éléments d'une page web, donc une fonction qui renvoie un timestamp avec les micro-secondes a été utilisée (il s'agit en l'occurrence de la fonction microtime).

    Conversion des données

    Les données sont enregistrées dans un format de données en XML. J'ai moi-même inventé ce format qui est simple et reflète la manière dont les données sont manipulées par le proxy. Cependant les données ne sont pas enregistrées pour un usage interne au proxy, mais pour être données en entrée d'un programme de test de performance. Puisque mon tuteur travaille sur CLIF, c'est pour cet outil qu'il était nécessaire (dans le cadre du stage) de proposer un moyen de faire une conversion. Cependant il n'y aurait aucun problème technique à convertir aussi pour d'autres outils similaires.

    CLIF peut jouer un scénario de test avec du code Java (un langage de programmation très répandu) ou avec des données en XML pour ISAC (qui est un jeu de mot recursif : ISAC is a Scenario Architecture for CLIF). Un moyen de convertir pour le format d'ISAC est de loin ce qui est le plus simple et ne pose aucun problème de limitation dans ce cas (il est possible de coder des comportements plus complexes en Java). C'est donc ce format qui a été choisi.

    Convertir un XML en un autre XML est une volonté courante. La structuration de ce format permet d'envisager facilement de répondre à cette volonté, et un langage est même dédié à cela : XSLT. La conversion est presque entièrement faite en XSLT (en moins de 300 lignes de codes), malgré des différences non négligeables (notamment la manière d'enregistrer les en-têtes HTTP). Cela a été fait en utilisant la version 1.0 du langage XSLT, car la version 2.0 apporte très peu et n'est à priori gérée que par 2 implémentations libres (Saxon-B XSLT et Saxon-HE XSLT).

    Le seul élément que je n'ai pas réussi à convertir avec XSLT est le temps. En effet, mon proxy enregistre le timestamp de chaque requête alors qu'ISAC a besoin du temps entre chaque requête. Il faut donc vérifier pour chaque requête qu'il y a en une suivante (ou précédente), puis faire la soustraction des timestamp, pour ensuite ajouter un élément entre les 2 indiquant le temps qui les sépare. Il a donc fallu faire un script, à appeler avant la conversion XSLT, pour ajouter cette pause.

    L'exécution du script et l'appel de la conversion XSLT sont faits en JavaScript sur le client web. L'opération est presque instantanée avec un ordinateur moderne, néanmoins c'est très dépendant de l'ampleur des données à convertir. L'avantage que ce soit le client web qui fasse l'opération est que le serveur ne nécessite pas les ressources pour cela.

    Exemple de données enregistrées par mon proxy
    <?xml version="1.0" encoding="UTF-8"?>
<session>
  <resource>
    <url value="https://www.w3.org/XML/" />
  </resource>

  <pause value="5003.14" unit="ms" />

  <resource>
    <url value="http://clif.ow2.org/" />
    <method value="GET" />
    <timeRequest  value="1497965627.5526"
                  unit="ms" type="unix-timestamp" />
    <timeResponse value="1497965627.6498"
                  unit="ms" type="unix-timestamp" />
    <headers from="client">
      <header key="User-Agent"
              value="Mozilla/5.0 (X11; i686) Firefox/45" />
      <header key="Accept-Language" value="en-us"/>
      <header key="Connection" value="keep-alive" />
      <header key="If-Modified-Since"
              value="Wed, 28 Oct 2015 15:47:33 GMT" />
      <header key="Cache-Control" value="max-age=0" />
    </headers>
    <proxy url="https://proxy" port="80" />
  </resource>
</session>
    Exemple de données converties pour ISAC de CLIF
    <?xml version="1.0" encoding="utf-8"?>
<scenario>
  <behaviors>
    <plugins>
      <use id="replayHttp" name="HttpInjector" />
      <use id="replayTimer" name="ConstantTimer" />
    </plugins>

    <behavior id="session">
      <sample use="replayHttp">
        <params>
          <param name="uri"
                 value="https://www.w3.org/XML/" />
        </params>
      </sample>

      <timer use="replayTimer" name="sleep">
        <params>
          <param name="duration_arg" value="5003" />
        </params>
      </timer>

      <sample use="replayHttp" name="get">
        <params>
          <param name="uri"
                 value="http://clif.ow2.org/" />
          <param name="headers" value="header=User-Agent|value=Mozilla/5.0 (X11\; i686) Firefox/45|;header=Accept-Language|value=en-us|;header=Connection|value=keep-alive|;header=If-Modified-Since|value=Wed, 28 Oct 2015 15:47:33 GMT|;header=Cache-Control|value=max-age=0|;" />
          <param name="proxyhost" value="https://proxy" />
          <param name="proxyport" value="80" />
        </params>
      </sample>
    </behavior>
  </behaviors>
</scenario>

    L’API Web

    Une API (Application Programming Interface) web basique a été faite. Elle ne s'appuie ni sur XML ni sur JSON (qui sont beaucoup utilisés pour faire une API web). En effet, elle utilise les paramètres GET (en entrée uniquement), les cookies HTTP (en entrée et en sortie), et le contenu HTTP (en sortie uniquement). Elle permet de "proxifier" une ressource, gérer une session (créer, détruire, et en recréer une qui écrase l'actuelle), obtenir les données de la session dans mon format, et d'obtenir la configuration au format HTML (il pourrait être utile de faire de même en JSON et/ou XML). Elle est utilisée par l'application, mais elle pourrait être utilisée par une application tierce. Elle est plus amplement documentée dans un fichier qui est converti en page web et accessible depuis le menu du proxy.

    L’interface graphique

    L'interface graphique est visuellement rudimentaire, mais elle est facile à utiliser et est adaptée à un écran de mobile. La page d'accueil permet de gérer une session (en utilisant l'API web qui peut rediriger vers la page précédente), d'être envoyé sur le formulaire pour "proxifier", de télécharger les données de la session (s'il y en a), et de gérer la configuration.

    Il est possible de télécharger les données de la session telles qu'elles sont enregistées par mon proxy. Il est également possible de télécharger les données converties. La conversion est pour l'instant possible uniquement pour CLIF, mais il serait facile d'ajouter le nécessaire dans l'interface graphique pour d'autres outils similaires. Pour récupérer les données converties, il y a un formulaire pré-rempli avec les données de mon proxy (récupérées via l'API grâce à une requête AJAX) qui fait la conversion dans le format sélectionné au moindre changement dans les données d'entrée dans le client web (pour éviter que le serveur ait à faire ce traitement) et en utilisant "uniquement" du JavaScript (mais le JavaScript peut utiliser du XSLT).

    La configuration se fait via des formulaires. Actuellement, ils sont gérés uniquement en JavaScript, mais il serait possible d'ajouter une gestion sans JavaScript. L'avantage de passer par JavaScript est de pouvoir afficher la nouvelle configuration effective sans recharger la page et sans soumettre le formulaire pour les cases à cocher (en positionnant des cookies dans ce langage et en utilisant des requêtes AJAX avec l'API web pour la configuration).

    L’installation facile

    Il n'y avait aucune certitude que quelqu'un continue régulièrement de développer l'outil, il fallait donc considérer par précaution qu'il n'y aurait que moi qui en aurait une bonne connaissance technique. Il faut donc que l'installation soit facile, même sans moi, pour éviter que ce que j'ai créé tombe dans l'oubli.

    La partie cliente nécessite un navigateur web avec JavaScript, comme Mozilla Firefox ou Chromium, ce qui est très simple à installer et très courant. La partie serveur est faite en PHP (dans sa version 7), qui est très courant pour faire un site web ou une application web. C'est un langage de script sans compilation, il suffit donc d'appeler un script PHP avec un interpréteur adéquat (ainsi que la bibliothèque standard) pour l'exécuter avec succès. Pour appeler automatiquement les scripts via le web, il faut un serveur web gérant CGI (Common Gateway Interface). Il y a pour cela Apache qui est libre (sous licence Apache 2.0), fonctionne sur les principaux systèmes utilisés pour faire serveur (GNU/Linux, les BSD, Microsoft Windows, et Apple macOS), packagé par les principales distributions GNU/Linux (notamment Debian, RHEL/CentOS, et Ubuntu) et est le logiciel faisant serveur web le plus utilisé au monde. Cela n'a pas été testé, mais il ne devrait pas y avoir de problème avec nginx qui est le principal concurrent libre. Les pré-requis pour l'installation et l'usage sont donc, aussi bien au niveau client que serveur, simples et courants, tout en ne nécessitant pas du logiciel privateur.

    Ce que j'ai créé ne s'appuie sur rien de spécifique à un système d'exploitation (y compris pour écrire de potentielles données de sessions et de potentiels journaux d'erreurs ou avertissements) et n'a besoin que de la bibliothèque standard de PHP, déposer le code source à un endroit où un serveur web va chercher des ressources et potentiellement exécuter du code PHP (en version 7) suffit pour installer et faire fonctionner la partie serveur. Cette méthode est simple et ne nécessite que d'avoir des droits d'écriture dans un dossier qu'un serveur web utilise.

    Le paquet Debian

    Il y a de fortes probabilités pour que mon outil soit utilisé sur un système Debian ou un dérivé (comme Ubuntu, Mint, et Trisquel GNU/Linux). La manière propre et usuelle pour installer un élément sur un de ces systèmes est de passer par un ou des paquets Debian (qui sont des archives organisées d'une certaine manière et ont usuellement deb comme extension). Un paquet Debian a des avantages (par rapport à une installation par copier/coller), tels que pouvoir être facilement mis à disposition via un dépôt de paquets, contenir des méta-données (comme la version, un journal des modifications synthétique, et la licence de chaque fichier du paquet source), permettre l'installation automatique des dépendances (avec APT ou un outillage similaire), et il peut être vérifié qu'il suit les bonnes pratiques. Il a donc été décidé de faire un paquet Debian, ou plutôt un moyen automatique et aisé d'en faire un.

    Le plus gros du travail est fait par dh_make, qui est un programme libre qui automatise de nombreuses parties de la construction d'un paquet Debian propre. Hormis le fichier control (qui contient une partie importante des méta-données) et le fichier copyright (qui indique des informations vis-à-vis des auteurs/autrices et des licences), il a essentiellement fallu faire une règle install et une autre uninstall dans le makefile (qui permettent respectivement, par logique élémentaire et convention, d'installer et de désinstaller un projet utilisable) (en utilisant le paramètre facultatif DESTDIR, qui permet par exemple de faire une installation à un emplacement où il n'y a pas besoin de privilèges d'écriture de SuperUser/root) que dh_make utilise automatiquement, comme la règle test (quand elle existe) qui lui permet de tester que les tests passent avant une potentielle construction du paquet.

    La construction est faite avec debuild qui appelle le programme Lintian. Celui-ci fait des tests sur les paquets et signale des erreurs pour les problèmes graves (qui ne sont pas tolérés pour un paquet dans l'archive Debian officiel) ainsi que des avertissements pour les problèmes non significatifs (mais dont l'évaluation pourrait changer à l'avenir) (comme des fichiers sans licence ou l'inclusion de jQuery alors que cette bibliothèque JavaScript est déjà packagée dans libjs-jquery et ne devrait pas être installée plusieurs fois). Toutes les erreurs et avertissements ont été corrigés, mais il y aurait probablement des petites choses à améliorer. La création automatique du paquet en génère donc un de qualité, bien qu'il ne soit pas parfait.

    Possibilités pour améliorer les performances

    • Réécrire le logiciel en langage Go : c'est un langage avec 2 implémentations libres (l'officielle et gccgo), qui peut se compiler en code natif (contrairement à PHP) et est adapté pour le Web (ce dont on peut se douter quand on connait son auteur, à savoir Google)
    • Réécrire les parties nécessitant une puissance de calcul non négligeable en C ou C++ et les appeler en PHP (le C peut aussi être appelé en Go)
    • Actuellement, il y a une classe par cas à gérer (lien, image, formulaire, script, etc.), ce qui permet de décomposer au maximum. Pour les documents HTML, chaque classe fait une requête XPath. Il serait possible d'en faire moins avec une classe qui aurait plus de responsabilités, au détriment de la qualité et maintenabilité du code source.
    • Manipuler le HTML en JavaScript sur le client : cela déchargerait notablement le serveur, mais cela nécessiterait la gestion du JavaScript sur le client et il faudrait arriver à faire les changements d'URL avant que le client web ne les utilise pour obtenir les ressources correspondantes.
    • Mon proxy récupère toutes les ressources demandées, mais il n'a aucun mécanisme de cache, ce qui peut le conduire à demander inutilement une même ressource plusieurs fois. Une solution serait d'implémenter un mécanisme de cache dans mon proxy, cela demanderait du temps mais aurait l'avantage que ce soit intégré et donc installé automatiquement. Une autre solution est de le faire utiliser un proxy web (comme Squid, Polipo, ou Varnish HTTP Cache), ce qui est facile et permet de ne pas recréer la roue, ainsi que d'être optimisé et déjà testé. Cette possibilité d'ajouter un cache n'a d'intérêt que s'il y a plusieurs utilisateurs/utilisatrices, si plusieurs clients web ne partageant pas un cache commun sont utilisés, ou si au moins un des clients web utilisés n'a pas de cache.

    Et après ?

    Il reste des cas non gérés ou mal gérés, comme la "proxification" des URLs dans le CSS, l'attribut pour l'intégrité en HTML, et un problème d'encodage sur de rares sites web. De plus, l'interface graphique est fonctionnelle et simple, mais a une apparence graphique très sobre, ce qui pourrait être changé par exemple avec un style CSS pré-existant comme KNACSS (qui est sous licence WTFPL), Milligram ou Twitter Bootstrap (qui sont sous la licence libre "MIT"). Il y a donc des choses à faire pour améliorer l'existant.

    On peut aussi vouloir aller au-delà. Il pourrait par exemple être intéressant de faire un moyen d'exporter les données pour Apache JMeter et Tsung, qui sont 2 outils libres qui peuvent prendre du XML en entrée et qui sont packagés par la majorité des distributions GNU/Linux. Les flux de syndication (au format Atom et RSS) ne sont pas gérés, or certains navigateurs web les gèrent. De plus, on pourrait imaginer une séparation de l'API web et de l'interface graphique en 2 services différents (mais dont l'un dépend de l'autre), ce qui faciliterait la contribution à une seule des 2 parties et simplifierait la maintenance de chacune.

    Il y a de nombreux tests unitaires, du moins pour PHP (qui représente la vaste majorité du code). Ainsi pour environ 15 000 lignes de codes PHP utilisés dans l'application, il y a environ 10 000 lignes de tests unitaires en PHP (chiffres obtenus respectivement avec wc -l src/include/php/class/* et wc -l tests/php/*, ce qui inclut les commentaires dont les en-têtes pour spécifier la licence de chaque fichier, les lignes vides, etc.). Il y a également d'autres tests automatiques et pas uniquement sur le code PHP. Il y a donc un filet de sécurité si l'on veut contribuer sans casser le fonctionnement et écrire le code en respectant certaines règles (pour qu'il garde une certaine homogénéité et soit donc plus facile à lire que s'il n'en avait pas). Puisque les 2 langages de programmation utilisés sont PHP et JavaScript (on fait ici exception du XSLT qui représente environ 300 lignes de code, ainsi que de HTML et CSS que tout développeur/développeuse web connait), il est facile de trouver une personne compétente pour modifier le code, car ce sont des langages courants et qui ne disparaitront pas avant de nombreuses années.

    Pourquoi ce nom ?

    Le nom originel est CLIF Web Proxy (d'où le logo qui n'a pas été modifié par la suite). C'était trivial et ça reflétait bien le projet, un proxy web pour le logiciel CLIF pour celles et ceux qui auraient directement sauté à cette partie (ou presque). Puisque le logiciel que j'ai produit peut être utilisé comme simple proxy web et qu'il pourrait servir pour d'autres logiciels de test de charge que CLIF, j'ai décidé de lui donner un nom plus général.

    Continuant dans mon imagination prodigieuse, je l'ai nommé RyDroid Web Proxy. Cela permet de rendre hommage au Créateur Suprême. En effet, RyDroid est un pseudonyme qu'il utilise couramment sur Internet. Certains racontent que c'est un mégalomane, tandis que d'autres prétendent qu'il avait bien peu d'imagination (au moins à ce moment là), je vous laisse vous faire votre avis. Après tant d'explications techniques, vous me ou lui (c'est qu'on se perd !) pardonnerez un moment de déconne et ça peut permettre de faire émerger un sourire avant la conclusion (quel sens de la transition !).

    Conclusion

    J'ai réalisé un proxy pour enregistrer une session web et la sauvegarder dans un format pour un outil de test de charge (en l'occurrence CLIF). Il est utilisable en l'état, mais il y a des manques qui peuvent être dérangeants dans certaines situations, et des fonctionnalités additionnelles qui pourraient être plaisantes. 2 moyens simples d'installation sont proposés, ce qui facilite l'utilisation de ma réalisation technique.

    Celle-ci a été publiée via Internet sous une licence libre, ce qui en fait un bien commun. De plus, il ne dépend que de technologies libres, ce qui permet d'avoir un contrôle total sur ce qu'il fait, mais aussi sur son évolution future, à laquelle un ou plusieurs autres contribueront potentiellement. Grâce au copyleft, les personnes distribuant des versions modifiées ont l'obligation légale de mettre leurs apports dans le pot commun, et ainsi créer un cercle vertueux qui ne soit pas basé sur l'exclusivité.

    Bonnes captures Web et vive le logiciel libre !

    Commentaires : voir le flux atom ouvrir dans le navigateur

  • Tutoriel : Comment utiliser la forge GitLab du labo pour gérer un projet ? (Laboratoire Linux SUPINFO)

    Initialiser un nouveau projet :

    1. Créer un compte sur la forge : http://code.labo-linux.org/users/sign_up
    2. Se connecter : http://code.labo-linux.org/users/sign_in
    3. Ajouter votre clé SSH : http://code.labo-linux.org/profile/keys
    4. Créer un nouveau projet : http://code.labo-linux.org/projects/new
    5. Suivre les instructions de lignes de commande GIT à exécuter pour initialiser le dépôt

    Le dossier ainsi créé va suivre les modification de tous vos fichiers. Vous devez maintenant apprendre à utiliser GIT en suivant dans l'ordre cette série de tutoriels : https://www.atlassian.com/fr/git/tutorial

    Si la ligne de commande vous rebute, il y a un client multiplateforme extrèmement complet : http://www.syntevo.com/smartgit/download (veillez à prendre la licence complète gratuite à usage non commercial).

    Pour que le versionnage soit utile, il faut Commit/Push à chaque fois que quelque chose est complété (comme un bug, une fonctionnalité, etc). Cela évite d'avoir des régressions et de pouvoir faire machine arrière le cas échéant.


    Découper son projet en toutes petites étapes :

    Cela permet d'y voir plus clair et de savoir par où commencer. Vous augmenterez votre motivation en évitant la paralysie de la feuille blanche.

    1. Se rendre sur l'interface Issues de votre projet (les liens sont à adapter) : http://code.labo-linux.org/root/demo/issues
    2. Cliquer sur New issue
    3. Décrire une tâche de l'ordre de « faire un hello world avec le framework X », « gérer le login/logout », « envoyer un email sur telle action », « créer une page de statistiques » ...
    4. Optionnellement, vous pouvez rattacher ces issues à des milestones (c'est un jalon, une version)


    Autres fonctionnalités utiles :

    1. Dans les champs texte, GitLab gère des symbols actifs comme le "@" (vous suggèrera les pseudos des membres) et le "#" (vous suggèrera vos issues).
    2. Préciser le numéro d'une issue dans un message de commit créé un référencement du commit dans l'issue. Exemple : le message de commit "Hello World #1" fera apparaitre un nouveau commentaire "mentionned in commit xxxxxx" dans l'issue n°1.
    3. Vous pouvez fermer automatiquement des issues dans vos messages de commit ! À découvrir en lisant ceci : https://about.gitlab.com/2013/09/22/gitlab-community-edition-6-dot-1-released/


    Git est un outil extrèmement puissant que vous découvrirez au fur et à mesure de vos besoins. Travailler en équipe requiers une réelle organisation en dehors de l'outil : répartition de tâches, tests préalables avant toute mise en commun pour limiter l'instabilité du logiciel, découpage en jalons, etc.

    Vous trouverez des réflexions sur les « workflows » (manière de s'organiser) sur cette page : https://www.atlassian.com/fr/git/workflows


    Gestion de projet plus globale

    La gestion d'issues proposée par GitLab ne peut pas se soustraire à une gestion d'équipe plus globale. Les Méthodes Agiles que vous découvrirez pendant votre cursus proposent de grands concepts qui évitent à de votre groupe de s'enrayer :

    1. Une réunion de départ qui dégage les jalons du projet, c'est à dire un premier découpage de ses grandes étapes qui n'entre pas dans le détail mais permet de fixer des échelles de temps
    2. Une revue hebdomadaire obligatoire, qui permet de définir à l'avance un objectif court terme pour l'équipe
    3. Un point journalier rapide, même s'il ne s'est rien passé, où chaque membre de l'équipe doit avouer ses difficultés et exprimer ce qui a été fait. Cela permet d'identifier au plus tôt qui a besoin d'aide.
    4. Une revue de projet (et une seule) toutes les deux semaines / un mois pour statuer sur l'avancée du jalon en cours ainsi que sur la prévision du prochain.

    Cette structuration de l'équipe par des cérémonies ponctuelles dans le temps neutralise l'effet « sous-marin » et permet à chaque membre de l'équipe de savoir où se situent les autres.

    L'objectif n°1 de ces méthodes est de faire passer le client et la qualité du logiciel avant toute chose. En itérant régulièrement, votre travail évoluera sur des bases saines car validerez au fur et à mesure qu'il correspond toujours aux attentes du client. La gestion des bugs devient ainsi prioritaire sur les fonctionnalités, si cela est pertinent. Ce fonctionnement est en totale opposition aux cahiers des charges dont le but est de figer un processus jusqu'à son aboutissement.

    Les Méthodes Agiles sont un genre de framework qui délimite bien d'autres routines d'équipe qui ne sont pas toujours adaptées à la situation : à vous de prendre ce qui vous plait ! C'est l'essence même de ces méthodes.

  • Agenda du Libre pour la semaine 26 de l'année 2018 (Dépêches LinuxFR)

    Calendrier web, regroupant des événements liés au Libre (logiciel, salon, atelier, install party, conférence), annoncés par leurs organisateurs. Voici un récapitulatif de la semaine à venir. Le détail de chacun de ces 30 événements (1 en Belgique, 29 en France, 0 au Luxembourg, 0 au Québec 0 en Suisse et 0 en Tunisie) est en seconde partie de dépêche.

    Sommaire

    [FR Nantes] Cycle café vie privée Protection de son trafic sur Internet (VPN) - Le lundi 25 juin 2018 de 18h00 à 21h00.

    Protection de son trafic sur Internet

    Pourquoi et comment chiffrer son trafic sur Internet avec un VPN (réseau privé virtuel) ?
    Présentation du fonctionnement d’un VPN, de son intérêt et de sa mise en place.

    Au bar associatif La Dérive https://lajavadesbonsenfantsblog.wordpress.com/

    [FR Grenoble] Contribuer à BANO, la base d’adresse nationale d’OSM - Le lundi 25 juin 2018 de 18h30 à 20h30.

    Le collectif OpenStreetMap Grenoble vous invite à son prochain atelier OSM, La Base Adresses Nationale Ouverte (BANO) est une initiative d’OpenStreetMap France.

    Elle a pour objet la constitution d’une base la plus complète possible de points d’adresse à l’échelle de la France.

    L’objectif est de proposer une couverture d’adresses la plus étendue possible et la plus homogène possible.

    Cela doit permettre de réaliser sur le plus largement possible des opérations de géocodage (Quelle position correspond à cette adresse) et de géocodage inversé (Quelle adresse correspond à cette position).

    Lors de ce mapathon, le collectif OpenStreetMap Grenoble vous propose d’apprendre à contribuer à la BANO.  

    À partir de 18h30 à La Coop-Infolab. 31 rue Gustave Eiffel – 38 000 Grenoble

    BANO ou BAN

    La BAN (Base Adresse Nationale) est la base de référence nationale issue d’une convention signée entre l’IGN, le Groupe La Poste, l’État et OpenStreetMap France.

    BANO est un projet initié par OpenStreetMap France début 2014 et n’a pas encore intégré de données issues de la BAN (chantier en cours). Le contenu de la BAN est plus complet (plus de 20 millions d’adresses) que BANO (15. 5M d’adresses), mais n’intègre(ra) pas de contributions faites sur OpenStreetMap et encore très peu de données opendata diffusées par certaines collectivités.

    C’est quoi OSM

    OpenStreetMap (OSM) est un projet international fondé en 2004 dans le but de créer une carte libre du monde.

    Nous collectons des données dans le monde entier sur les routes, voies ferrées, les rivières, les forêts, les bâtiments et bien plus encore

    Les données cartographiques collectées sont ré-utilisables sous licence libre ODbL (depuis le 12 septembre 2012). Pour plus d’information inscrivez-vous à la liste locale OSM de Grenoble

    [FR Gaillac] Atelier informatique libre - Le lundi 25 juin 2018 de 19h30 à 23h00.

    Un atelier d’informatique libre voit le jour au sein du chinabulle, pour créer un espace temps d’échange autour des solutions informatiques libres.

    [FR Marseille] PGDay France - Le mardi 26 juin 2018 de 08h30 à 17h30.

    Le PGDay France est un moment de rencontres et de conférences pour la communauté francophone de PostgreSQL.

    Les conférences s’adressent à tous les utilisateurs du logiciel étudiants, administrateurs systèmes, DBA, développeurs, chefs de Projets, décideurs.

    [FR Aiglun] Après-midi « Open data » et « Cartopartie » - Fête de l'été - Le mardi 26 juin 2018 de 15h00 à 19h00.

    Démarche participative et collaborative, il s’agit notamment de permettre aux associations, producteurs locaux, habitants et usagers de cartographier les services / activités qui constituent la richesse de notre territoire sur un outil libre (Openstreetmap).

    Les données publiques communales mises en ligne et la création d’un agenda partagé (à destination des associations) seront également valorisées.

    Les organisateurs du marché d’Aiglun proposeront de nombreuses animations à travers la fête l’été. Venez nombreux

    Tout l’après-midi marché bio et des producteurs locaux, animation musicale, balades avec les ânes, jeux, atelier de cartographie libre

    À 15 h, 16 h et 17 h visite du champ de lavande rendez-vous sur la place du marché

    À partir de 17 h dégustations des produits du marché préparés par le restaurant Le Pressoir Gourmand et grillades d’agneau

    À 18 h apéritif local offert par la mairie d’Aiglun, débat sur la cartographie et les données ouvertes

    [FR Quetigny] Découvrir, tester, installer Linux et d’autres logiciels libres - Le mardi 26 juin 2018 de 20h30 à 23h30.

    COAGUL est une association d’utilisateurs de logiciels libres et de GNU Linux en particulier.

    Nous utilisons toutes sortes de distributions GNU / Linux (Ubuntu, CentOs, Fedora, Debian, Arch…) et toutes sortes de logiciels pourvu qu’ils soient libres (VLC, LibreOffice, Firefox, Thunderbird, GPG, Tor, OpenNebula, LXC, Apache…).

    Nous partageons volontiers nos connaissances des logiciels libres et l’entraide est de mise dans nos réunions.

    Les permanences servent à se rencontrer et à partager nos expériences et notre savoir sur le logiciel libre.

    Vous souhaitez nous rencontrer nous vous accueillerons à notre permanence.

    On adore les gâteaux et les chocolats, vous pouvez donc en apporter-)

    [FR Le Mans] Permanence du mercredi après-midi - Le mercredi 27 juin 2018 de 12h00 à 17h00.

    Assistance technique et démonstration concernant les logiciels libres.

    [FR Rennes] Sécuriser son infrastructure - Le mercredi 27 juin 2018 de 18h30 à 21h00.

    La sécurité informatique ne repose pas que sur la qualité du code et le chiffrement (même s’ils sont essentiels), c’est aussi une question d’architecture.

    Vous (re)découvrirez quelques principes de sécurisation des infrastructures informatiques tels que la séparation des flux, la redondance et d’autres éléments pouvant améliorer la protection et la disponibilité des services.

    La conférence sera présentée par
      Thomas MICHEL
      Esprit Libre
      esprit-libre-conseil.com (link is external)

    mercredi 27 juin - 18h30

    FrenchTech Rennes - Saint-Malo
    2 rue de la Mabilais
    Rennes

    >>> S’inscrire

    [FR Montpellier] Rencontres des Groupes OpenStreetMap OSM - Le mercredi 27 juin 2018 de 19h00 à 22h00.

    Ces rencontres mensuelles se veulent être des instants conviviaux pour faire un compte-rendu des activités du mois précédent, mais aussi pour présenter les opérations et rendez-vous à venir que proposent les groupes HérOSM et le Collectif des Garrigues. Naturellement, elles sont également ouvertes à tout public.

    Si vous avez des propositions n’hésitez pas à compléter la page dédiée.

    Proposition de programme

    • En première partie de soirée, une initiation pour les débutants est prévue
    • Possibilité d’initiation à la contribution pour les débutants qui le désire
    • Préparation du dossier pour le budget de l’Opération Libre
    • Préparation de l’Opération Libre à Jacou
    • Travail sur les voies manquantes sur (enjeu évident de géocodage d’adresses, comme celles fournies par SIRENE ou FANTOIR par exemple
    • Petit topo sur la saisie des noms de rues à partir des données cadastre/fantoir par département

    • Propositions au sujet du calcul d’itinéraire multimodal (auto, vélo, piéton) dans les futures discussions

      • La pratique des cartoparties
      • Faut-il prioriser la cartographie de certains endroits (gares et arrêts de tram, par exemple) ?

    • Contributions libres

    Déroulement de la rencontre

    Nous vous présenterons les projets en cours, nous vous vous proposerons de contribuer, faire de la production de données, puis nous passerons à un instant convivial sur la terrasse.
    Comme d’habitude, chacun amène ce qu’il veut à manger et à boire pour un repas partagé.
    N’oubliez pas vos ordinateurs portables pour la séance de saisie

    Le dernier mercredi de chaque mois
    Mercredi 27 septembre 2017 de 19h00 à 22h00
    Mercredi 25 octobre 2017 de 19h00 à 22h00
    Mercredi 29 novembre 2017 de 19h00 à 22h00
    Mercredi 20 décembre 2017 de 19h00 à 22h00
    Mercredi 24 janvier 2018 de 19h00 à 22h00
    Mercredi 28 février 2018 de 19h00 à 22h00
    Mercredi 28 mars 2018 de 19h00 à 22h00
    Mercredi 25 avril 2018 de 19h00 à 22h00
    Mercredi 30 mai 2018 de 19h00 à 22h00
    Mercredi 27 juin 2018 de 19h00 à 22h00

    Mercredi 27 septembre 2017 de 19h00 à 22h00
    Le Faubourg - 15, rue du Faubourg de Nîmes, 34 000 Montpellier

    Tramway lignes 1, 2 et 4 arrêt Corum
    GPS Latitude 43.614186 | Longitude 3.881404
    Carte OpenStreetMap

    Le dernier mercredi de chaque mois.

    [FR Toulouse] Rencontres Tetalab - Le mercredi 27 juin 2018 de 20h30 à 23h30.

    Rencontre hebdomadaire des hackers et artistes libristes Toulousains.

    Ouvert au public tous les mercredi soir.

    Venez nombreux.

    [FR Choisy-le-Roi] Pas Sage en Seine - Du jeudi 28 juin 2018 à 10h00 au dimanche 1 juillet 2018 à 20h00.

    Le festival auto-organisé par vous et l’équipe de Pas Sage En Seine se tiendra du 28 juin au 1er juillet 2017 à Choisy-le-Roi dans et aux abords de la Médiathèque Louis Aragon.

    Nous vous invitons à participer à PSES2018 et venir participer à ses ateliers et conférences bien sûr, mais aussi installations, discussions et autres formes d’interventions.

    Des thèmes sont proposés, pas imposés, pour laisser place à la manifestation d’idées originales.

    Le Festival sera un moment convivial et festif pour décrire nos modes d’organisation, nos outils, nos perspectives, évoquer les usages d’autodéfense numériques faces aux perpétuelles manipulations sécuritaires.

    Le vendredi sera une journée spéciale consacrée au RGPD, et le samedi soir (lors de la micro-nocturne jusqu’à 21h30) vous pourrez assister à un concert de chiptune réalisé par le collectif Chip Bangers.

    L’Hacktiviste naît de cette prise de conscience intégrale. Il ouvre, détourne, invente tous les possibles, ou presque… Être et faire politiquement ensemble sera notre prochaine étape

    Le trajet depuis le centre de Paris prend une petite vingtaine de minutes uniquement (Gare du RER C Choisy-le-Roi).

    [FR Rennes] Conseil d’administration de Gulliver - Le jeudi 28 juin 2018 de 12h00 à 14h00.

    Gulliver tiendra son conseil d’administration à la Maison de la Consommation et de l’Environnement (MCE) le jeudi 28 juin 2018 à partir de 12 h. L’ordre du jour est donné dans le lien ci-dessous.

    Ce conseil d’administration est ouvert à tous. Toute personne, membre ou non membre de Gulliver, peut y assister (sauf CA exceptionnel signalé à l’avance), voir comment fonctionne notre association et y donner son avis.

    La MCE est située 42 bd Magenta à Rennes (plan d’accès). La salle réservée est celle de l’accueil.

    [FR Martigues] Permanence du jeudi de l'ULLM - Le jeudi 28 juin 2018 de 16h30 à 18h30.

    Comment utiliser et les Logiciels Libres.

    avec l’association des Utilisateurs de Logiciels Libres du Pays de Martégal (ULLM).

    28 2018 de 16h30 à 18h30 à la (quai des Anglais).

    Entrée Libre. Tout public.

    [FR Challans] Permanence Linux - Le jeudi 28 juin 2018 de 18h00 à 20h00.

    Chaque dernier jeudi du mois, Linux Challans vous donne rendez-vous à l’Albanera Café, 17 rue du Général Leclerc 85 300 Challans.

    Nous vous proposons lors de ces rendez-vous mensuels d’échanger autour du Libre, des conseils ou une assistance technique.

    Vous pouvez venir pour vous faire aider, ou aider, à installer et paramétrer une distribution GNU/Linux de votre choix ou des logiciels libres sur votre ordinateur.

    Recommandations

    • Sauvegardez vos données avant de venir.
    • Libérez de la place sur le disque dur (20 Go minimum) et défragmentez Windows si vous voulez le conserver.
    • Nous prévenir de votre passage via la messagerie.

    Vous pouvez aussi venir pour une première prise d’informations et de contacts.

    Nous vous attendons toujours plus nombreux

    [FR Bordeaux] Jeudi Giroll - Le jeudi 28 juin 2018 de 18h30 à 20h30.

    Les membres du collectif Giroll, GIROnde Logiciels Libres, se retrouvent une fois par semaine, pour partager leurs  savoir-faire et expériences autour des logiciels libres.

    Le collectif réalise aussi une webradio mensuelle, tous les second mardis du mois, à retrouver en direct sur le site de Giroll.

     Ses rencontres sont ouvertes à tous.

    [FR Peymeinade] Install-Party GNU/Linux - Le jeudi 28 juin 2018 de 19h00 à 21h00.

    Désormais tous les 4ᵉˢ mercredi du mois, Clic Ordi et Linux Azur vous proposent une install-party ouverte à tous et gratuite.

    • Découvrez un monde rempli de Papillons, licornes, mais surtout de manchots
    • Plus besoin de se soucier des virus et autres logiciels malveillants.
    • Le support de Windows Vista s’arrête dans un an, et les principaux logiciels ont déjà arrêté leurs mise à jour, réagissez
    • Ramenez vos ordinateurs obsolètes et donnez leur une seconde vie.

    Nous aimerions développer autour de Handy-Linux (et de sa future mouture avec Debian-Facile) afin de répondre à des besoins simples pour des personnes difficiles à former et pouvant se retrouver en fracture numérique).

    Nous sommes ouverts à tout, y compris à la bidouille sur l’atelier avec le fer à souder.

    Organisé conjointement par http://clic-ordi.com/fr et https://www.linux-azur.org

    [FR Vesseaux] Projection-débat du film « Nothing to hide » - Le jeudi 28 juin 2018 de 19h00 à 22h00.

    Ouverture des portes à 19h pour partager un moment de convivialité, discuter des choses et d’autres comme les logiciels libres, les données personnelles, la vie privée

    Il y a une buvette sur place, et vous pouvez également apporter un plat à partager ou biscuits apéro

    La projection du film documentaire Nothing to Hide aura lieu à 20h30, et sera suivie d’un débat pour répondre à vos questions

    « Dire que votre droit à la vie privée importe peu, car vous n’avez rien à cacher revient à dire que votre liberté d’expression importe peu, car vous n’avez rien à dire. Car même si vous n’utilisez pas vos droits aujourd’hui, d’autres en ont besoin. Cela revient à dire les autres ne m’intéressent pas », Edward Snowden

    Ce documentaire aborde le thème de la vie privée et des données personnelles.

    L’entrée est à prix libre (adhésion à l’association Vesseaux-Mère).

    [FR Paris] Soirée de Contribution au Libre - Le jeudi 28 juin 2018 de 19h30 à 22h30.

    Parinux propose aux utilisateurs de logiciels libres de se réunir régulièrement afin de contribuer à des projets libres. En effet, un logiciel libre est souvent porté par une communauté de bénévoles et dépend d’eux pour que le logiciel évolue.

    Nous nous réunissons donc tous les dans un environnement propice au travail (pas de facebook, pas de télé, pas de jeux vidéos, pas de zombies).

    Vous aurez très probablement besoin d’un ordinateur portable, mais électricité et réseau fournis.

    En cas de difficulté, vous pouvez joindre un des responsables de la soirée, Emmanuel Seyman (emmanuel (at) seyman.fr), Paul Marques Mota mota (at) parinux.org, ou Magali Garnero (Bookynette) tresorier (at) parinux.org.

    Pour obtenir le code d’entrée de la porte cochère, envoyez un mail au responsable.

    On peut amener de quoi se restaurer (Franprix, 8 rue du Chemin Vert, ferme à 22h)

    Regazouillez sur Twitter - Wiki des soirées

    Programme non exhaustif

    • Fedora (sa traduction)
    • Parinux, ses bugs et son infrastructure
    • April, … y a toujours quelque chose à faire
    • Open Food Facts/ Open Beauty Facts, sa base de données, ses contributeurs, sa roadmap
    • Schema racktables, son code
    • Agenda du Libre, mise à jour et amélioration du code
    • Ubuntu-Fr, son orga, ses événements
    • En vente libre, maintenance et commandes
    • Open street map, une fois par mois
    • Linux-Fr sait faire
    • en vente libre
    • …

    tout nouveau projet est le bienvenu.

    [FR Montpellier] Atelier du Libre Ubuntu et Logiciels Libres - Le vendredi 29 juin 2018 de 18h00 à 23h00.

    L’équipe de Montpel’libre vous propose une permanence Logiciels Libres, discussions libres et accompagnements techniques aux systèmes d’exploitation libres, pour vous aider à vous familiariser avec votre système GNU/Linux au quotidien.

    Le contenu de l’atelier s’adapte aux problèmes des personnes présentes et permet ainsi l’acquisition de nouvelles compétences au rythme de chacun.

    Vous pourrez y aborder plusieurs thèmes

    • Discussions conviviales entre utilisateurs autour de Linux en général
    • Préinscription aux prochains Cafés Numériques et Install-Party
    • Premières explorations du système
    • Installations et configurations complémentaires
    • Mise à jour et installation de nouveaux logiciels
    • Prise en main, découverte et approfondissement du système

    Les Ateliers du Libre ont lieu à la Mpt Melina Mercouri de Montpellier, tous les derniers vendredis de chaque mois de 18h00 à 20h00, sauf période de vacances.

    Entrée libre et gratuite sur inscription. Une simple adhésion à l’association est possible et auprès de la Mpt.

    Cet événement est proposé par le partenariat qui lie la Mpt Melina Mercouri de Montpellier et Montpel’libre.

    Toute une équipe de passionnés, vous propose l’animation de l’Atelier du Libre par les membres de Montpel’libre. Permanence Logiciels Libres, discussions libres et accompagnements des utilisateurs aux systèmes exploitation libres, Linux, sur le cyberespace de consultations libres.

    En fin de soirée, l’atelier fera progressivement place à un instant très convivial, les RDVL sont des rendez-vous mensuels de discussions sur le thème des logiciels libres, des arts libres, de l’open source et plus généralement de la culture du libre et du numérique.

    Cette soirée, très conviviale, se passe autour d’un repas partagé, chacun porte un plat, entrée, spécialité, dessert, boisson… Ordinateurs et réseaux disponibles.

    Notre équipe vous attend pour répondre à vos questions et satisfaire votre curiosité.

    Maison pour tous Mélina Mercouri 842, rue de la vieille poste, 34 000 Montpellier

    Bus ligne 9, La Ronde arrêt Pinville
    GPS Latitude 43.61354 Longitude 3.908768
    Carte OpenStreetMap

    Rendez-vous mensuel, tous les derniers vendredis, salle jamais le dimanche

    [FR Paris] Apéro April - Le vendredi 29 juin 2018 de 19h00 à 22h00.

    Un apéro April consiste à se réunir physiquement afin de se rencontrer, de faire plus ample connaissance, d’échanger, de partager un verre et manger mais aussi de discuter sur le logiciel libre, les libertés informatiques, fondamentales, l’actualité et les actions de l’April…

    Un apéro April est ouvert à toute personne qui souhaite venir, membre de l’April ou pas.

    N’hésitez pas à venir nous rencontrer.

    Où et quand cela se passe-t-il

    L’apéro parisien aura lieu vendredi 29 juin 2018 à partir de 19h00 dans les locaux de l’April.

    L’adresse
    April, 44/46 rue de l’Ouest, bâtiment 8, 75 014 Paris (entrée possible par la place de la Catalogne, à gauche de la Biocoop, au niveau des Autolib).
    Métros Gaîté, Pernety, Montparnasse. Sonner à « April » sur l’interphone.
    Le téléphone du local 01 78 76 92 80.

    L’Apéro a lieu à Paris notamment parce que le local s’y trouve ainsi que les permanents et de nombreux actifs. Pour les apéros dans les autres villes voir sur le pad plus bas.

    En ouverture de l’apéro nous ferons un court point sur les dossiers/actions en cours.

    Le glou et le miam

    Vous pouvez apporter de quoi boire et manger afin de reprendre des forces régulièrement. Nous prévoirons bien sûr un minimum vital.

    Vous pouvez vous inscrire sur le pad.

    [FR Dijon] Atelier de création numérique et électronique - Le vendredi 29 juin 2018 de 20h30 à 23h59.

    Le fablab et hackerspace l’abscisse vous propose comme tous les vendredis soir un atelier de création numérique et électronique.

    L’atelier est équipé de différents outils perceuse, CNC, Arduino, Raspberry Pi, ordinateurs, oscilloscope, multimètre.

    Une ressourcerie est à disposition, vous y trouverez des composants électroniques et des pièces détachées à prix libre.

    Vous pouvez venir découvrir l’atelier et les usagers du fablab à partir de 20h30.

    Vous pouvez aussi venir pour participer aux travaux numériques en cours, partager vos connaissances et vos savoir-faire.

    Tous nos travaux sont libres et documentés sous licence libre.

    [FR Saint-Jean-de-Védas] Repair Café - Le samedi 30 juin 2018 de 09h00 à 13h00.

    Nous vous proposons ce rendez-vous, où, bricoleurs, acteurs, bénévoles, associations, vous attendent pour vous aider à donner une deuxième vie à vos objets.

    Réparer ensemble, c’est l’idée des Repair Cafés dont l’entrée est ouverte à tous. Outils et matériel sont disponibles à l’endroit où est organisé le Repair Café, pour faire toutes les réparations possibles et imaginables. Vêtements, meubles, appareils électriques, bicyclettes, vaisselle, objets utiles, jouets, et autres. D’autre part sont présents dans le Repair Café des experts bénévoles, qui ont une connaissance et une compétence de la réparation dans toutes sortes de domaines.

    On y apporte des objets en mauvais état qu’on a chez soi. Et on se met à l’ouvrage avec les gens du métier. Il y a toujours quelque chose à apprendre au Repair Café. Ceux qui n’ont rien à réparer prennent un café ou un thé, ou aident à réparer un objet appartenant à un autre. On peut aussi toujours y trouver des idées à la table de lecture qui propose des ouvrages sur la réparation et le bricolage.

    Repair Café est un atelier consacré à la réparation d’objets et organisé à un niveau local, entre des personnes qui habitent ou fréquentent un même endroit, par exemple un quartier ou un village. Ces personnes se rencontrent périodiquement en un lieu déterminé, dans un café, une salle des fêtes ou un local associatif où des outils sont mis à leur disposition et où ils peuvent réparer un objet qu’ils ont apporté, aidés par des volontaires.

    Les objectifs de cette démarche alternative sont divers

    • réduire les déchets
    • préserver l’art de réparer des objets
    • renforcer la cohésion sociale entre les habitants des environs

    Seront présents

    • Autour.com : On se rend des services entre voisins, on partage des infos, on prête, on loue, on donne…
    • L’Accorderie : Est un système d’échange de services entre habitants d’un même quartier ou d’une même ville.
    • La Gerbe : Contribuer à la formation de citoyens éveillés, engagés et solidaires en offrant aux enfants et aux jeunes un espace privilégié d’expression et d’épanouissement Crèche, Centre de loisirs, Scoutisme, Ateliers, chacun peut y trouver un cadre pour son développement grâce au travail d’une équipe de professionnels et de bénévoles.
    • Les Compagnons Bâtisseurs : Prévoient d’amener des outils
    • Les Petits Débrouillards : est un réseau national de culture scientifique et technique, ils viendront avec pleins de conseils et une imprimante 3D.
    • Le Faubourg : Hébergera le Repear Café.
    • Montpel’libre : Sera là avec des pièces informatiques, pour essayer de reconditionner des ordinateurs, dépanner ceux qui ne fonctionnent plus, expliquer comment ça marche, faire comprendre le choix judicieux du logiciel libre, contourner l’obsolescence programmée grâce à GNU/Linux, comment réparer et entretenir son matériel soi-même, nous porterons un jerry.
    • TechLabLR : Accompagne les projets à composantes technologiques afin de les amener au pré-prototype, puis les guider vers les structures d’accompagnements.
    • Violons Dingues : Passionnés de la vie, des autres, de la culture, de l’art, du sport, de la mécanique, de la moto, de la photo, de la musique, des animaux, des insectes, des plantes, de l’environnement, enfin de tout ce qui circule (au propre comme au figuré) sur notre planète.

    • Zéro Waste Montpellier : La démarche « Zéro Waste » est une démarche positive pour aller vers une société zéro déchet et zéro gaspillage.

    • Maison des Associations, 18 bis rue Fon de l’Hospital, Saint-Jean-de-Védas, Occitanie, France

    • Adresse web http://montpel-libre.fr

    • Tags
      montpel-libre, repair-cafe, atelier

    [FR Casseneuil] Install Partie GNU/Linux - Le samedi 30 juin 2018 de 10h00 à 17h00.

    Le Samedi 30 Juin les bénévoles d’aGeNUx sont invités dans les locaux d’Avec 2L pour une Install-party.

    Venez découvrir et partager le monde du logiciel libre en toute sérénité.

    Animation Libre et non payante.

    Auberge Espagnole le midi.

    Avec 2L se situe derrière la poste de Casseneuil

    [FR Wintzenheim] Réunion du Club Linux - Le samedi 30 juin 2018 de 13h00 à 19h00.

    Comme tous les 3 samedis, le Club Linux de la MJC du Cheval Blanc se réunit et accueille toutes les personnes qui souhaitent découvrir ou approfondir Linux et les Logiciels Libres. Aucune compétence n’est demandée.  

    Pendant ces rencontres, informelles,

    • nous accueillons celles et ceux qui cherchent une réponse ou souhaitent découvrir Linux et les Logiciels Libres,
    • nous installons Linux sur des ordinateurs, la plupart des fois en « dual boot »(*), ce qui permet de conserver l’ancien système (par exemple Windows) et d’utiliser quand même, en choisissant au démarrage,
    • nous partageons nos recherches et nos découvertes, les nouveautés.

    Le Club Linux est également impliqué dans une démarche de libération des GAFAM (Google Apple Facebook Amazon Microsoft) et de promotion de solutions libres comme, entre autres, Wikipedia, Openstreetmap, les Framatrucs (*), les Chatons (*) et beaucoup d’autres.

    (*) : mais on vous expliquera

    [FR Villefranche-sur-Saône] Repaircafé - Le samedi 30 juin 2018 de 13h30 à 17h30.

    Dernier Repaircafé caladois mensuel de la saison avant les vacances.

    Avec la participation habituelle de la CAGULL.

    [FR Marseille] Install Party GNU/Linux - Le samedi 30 juin 2018 de 14h00 à 19h00.

    L’association (CercLL d’Entraide et Réseau Coopératif autour des Logiciels Libres) vous invite à une install party GNU/Linux, le, dans la salle du Foyer du Peuple 50 rue Brandis 13 005 Marseille.

    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, les mascottes de

    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 avec un ensemble de et pour une utilisation quotidienne.

    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.(L’adhésion n’est pas obligatoire).

    Plan d’accés

    [BE Liège] Linux Install Party - Le samedi 30 juin 2018 de 14h00 à 18h00.

    Une Linux Install Party a lieu tous les derniers samedis du mois de septembre à juin, dans les locaux du Cyber Seniors Énéo de Grivegnée, où je suis animateur.

    L’accès et la participation à l’Install Party est ouvert à tous et est gratuit.

    Vous venez avec votre ordinateur et on y installe le Linux que vous désirez.

    Les installations commencent à 14h et finissent à 18h.
    Prévoyez de venir avant 17h, parfois ça peut durer longtemps.

    [FR Ivry sur Seine] Cours de l’Ecole du Logiciel Libre - Le samedi 30 juin 2018 de 14h30 à 18h30.

    Présentation de l’E2L

    Quel est le rôle de l’école du logiciel libre

    Tout d’abord, ce n’est pas une école comme les autres. Elle n’a pas d’établissement fixe, pas de cours de récréation, pas de carte d’étudiant, ni de diplôme de fin d’année.

    Comme toutes les écoles, son rôle est d’apprendre à ses élèves les logiciels libres, c’est-à-dire

    • comment en trouver de bons parmi les nombreux sites qui en proposent,
    • comment en prendre possession en fonction des licences,
    • comment les installer en fonction de ses besoins,
    • comment les tester et les utiliser,
    • comment en comprendre le fonctionnement pour ensuite les modifier,
    • comment écrire ses propres logiciels libres.

    En fait, l’école du logiciel libre est une université populaire, comme celles qui ont vu le jour en France à partir du 19ᵉ siècle, et dont le but est de transmettre des connaissances théoriques ou pratiques à tous ceux qui le souhaitent. Et pour atteindre ce but, sa forme juridique est de type " association à but non lucratif ".

    Comment fonctionne l’école

    Cette école étant une association, elle possède, comme toutes les autres, un bureau, élu chaque année en assemblée générale, pour l’administrer. Mais elle a aussi des responsables pédagogiques dont le rôle est essentiel, car ce sont eux qui établissent les programmes des cours en fonction des souhaits des adhérents, valident les candidatures des enseignants et affectent les sessions.

    Les membres du bureau et les responsables pédagogiques forment « l’encadrement de l’école ». Tous les membres « encadrants » doivent être membres de l’association.

    Les locaux où se déroulent les cours seront ceux que l’on veut bien nous prêter une salle des fêtes, un théâtre, une salle de réunion publique, un amphi dans une école publique, ou autre.

    Les thèmes des cours sont définis par les adhérents en fonction de leurs envies, de leurs besoins. Les cours sont ensuite décidés par les responsables pédagogiques de l’école en fonction des enseignants disponibles.

    Afin de permettre au plus grand nombre de participer et d’assister aux cours, les sessions se tiennent essentiellement le samedi. Une première de 9h à 12h30, et une autre de 14h à 17h30.

    Programme détaillé sur le site http://e2li.org

    [FR Courbevoie] Assemblée Générale annuelle de l'association StarinuX - Le samedi 30 juin 2018 de 14h30 à 17h00.

    L'association GULL StarinuX vous invite à  son

    ASSEMBLÉE GÉNÉRALE annuelle

    le samedi 30 juin 2018 à 14h30,

    48 rue de Colombes 92 400 Courbevoie

    (SNCF Gare de Courbevoie,  Saint Lazare <=> La Défense).

    Seuls les adhérent(e)s peuvent voter, mais les discussions restent ouvertes à tous les présents.

    Un déjeuner facultatif aura lieu à 12h30.

    Au plaisir de nous rencontrer à l’AG 2018

    Le Bureau de StarinuX

    [FR Poucharramet] Festival AgitaTerre - Le dimanche 1 juillet 2018 de 09h30 à 23h00.

    L’association 3PA Formation vous invite à la cinquième édition du Festival AgitaTerre Nous vous donnons rendez-vous le dimanche 1er juillet au coeur du village de Poucharramet (31), entre la place des Marronniers et La Maison de la Terre

    Venez découvrir des alternatives durables, locales et citoyennes qui font vivre notre territoire. Cette année, le festival investit le thème des Communs venez en apprendre plus

    Un événement gratuit et tout public

    9h30-18h

    Marché de producteurs et artisans-créateurs locaux
    Forum associatif & Village des Communs

    Conférences
    Expositions « C’est quoi les Communs »
    Ateliers tous publics

    Expositions d’artistes sculpteurs sur bois
    Mur d’expression libre
    Vannerie géante collective

    Concerts
    Spectacles et animations

    Buvette & Restauration
    Espace enfants

    20h30 Grand concert en plein air avec notre partenaire La Maison de la Terre

    Programmation et exposants sur www.agitaterre.fr

    Infos agitaterre@3paformation.fr // 3PA 05.61.08.11.30

    Parking sur place
    Adapté aux personnes à mobilité réduite

    Commentaires : voir le flux atom ouvrir dans le navigateur

  • 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 là.

    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 ...]

    Où 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

     

  • Le WeTab maintenant à partir de 254€ (Linux Certif)

     Le WeTab, la tablette Linux basée sur Meego, est maintenant vendu à 253,99€ pour la version Wifi, et 333€ pour la version 3G.

    Pour rappel, le Wetab est une tablette sortie l'année passée et se voulait complètement à contre courant des autres tablettes.

    Quelques caractéristiques:

    • Linux complet avec X11 et gestionnaire de packet (plutôt qu'un Linux édulcoré pour téléphone)
    • MeeGo (plutôt que Android)
    • Processeur Intel Atom (plutôt que ARM)
    • Plutôt ouvert et avec une communautée
    Les raisons de la baisse de prix sont inconnues. Personellement, j'épère qu'un nouveau modèle va arriver. La possibilité que le projet est abandonné n'est pas a exclure.
  • Sortie de Sailfish OS 2.2.0 (Journaux LinuxFR)

    Bien que n'étant pas propriétaire d'un téléphone fonctionnant avec Sailfish OS, je regarde régulièrement les avancées de ce système alternatif à Android et iOS.

    Bonne nouvelle, j'ai découvert ce matin qu'une mise a jour a été publiée le 7 juin : la version 2.2.0

    Celle-ci supporte (enfin) la version double SIM du Sony Xperia X (F5122) en plus la version simple SIM (F5121) qui était un prérequis pour moi pour ne pas avoir deux téléphones dans la poche. Le communiqué met en avant d'autres fonctions qui sont maintenant apportées comme le déverrouillage par empreinte, un meilleur autofocus de l'appareil photo et une refonte de l'application de galerie.

    La note de publication détaille davantage les nouveautés et les anomalies identifiées, avec toujours quelques difficultés sur des équipements Bluetooth.

    Est-ce que des lecteurs ont un téléphone qui fonctionne avec Sailfish pour obtenir leur avis et retour d'expérience ? J'utilise le téléphone de façon très basique (téléphone, mail, internet et GPS) pour le travail et un usage perso. Le partage de connexion internet avec le PC est néanmoins indispensable ! Éventuellement quelques mini jeux pour passer le temps mais c'est assez exceptionnel.

    Merci

    Commentaires : voir le flux atom ouvrir dans le navigateur

  • 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

  • Cinelerra, openshot video et kdenlive, le duel (Journaux LinuxFR)

    'lut les gens,

    Moi les vacances de noël ça me déprime, tout cet étalage de bouffe, de guirlandes et de bons sentiments ce n'est décidément pas mon truc, du coup je me réfugie devant mon ordinateur, ça me vide la tête. Et quoi de mieux que de mettre en concurrence les dernières versions des logiciels libres de montage vidéo sous GNU/linux, à savoir kdenlive 17.12.0, openshot video 2.4.1 et cinelerra 7 qui viennent de sortir récemment.

    Commençons par kdenlive, à y regarder de plus près, pas de grosses évolutions, c'est essentiellement une version dite de maintenance avec le changelog qu'on peut découvrir par là https://kdenlive.org/2017/12/kdenlive-17-12-0-released. On nous promet par contre une version majeure 18.04 pour la nouvelle année avec une timeline retravaillée et des fonctionnalités nouvelles. Wait and see, mais j'espère toujours retrouver la fluidité de travail que j'avais quand kdenlive n'était pas encore passé à KF5. La force de kdenlive reste la richesse de ses fonctionnalités et de ses effets, on peut regretter que ce soit aussi mal documenté, il faut vraiment passer du temps pour tirer toute la quintessence du logiciel, fort heureusement on peut trouver pas mal de docs sur le net dès lors qu'on s'y donne la peine (et qu'on maîtrise un tant soit peu l'anglais !)
    Titre de l'image

    Passons à OpenShot Video Editor, bien qu'on soit passé d'une version majeure en passant de la 1.4 à la 2.4.1, l'évolution au niveau interface n'est pas très sensible, il faut reconnaitre toutefois que c'est maintenant bien plus stable et pleinement fonctionnel. Au niveau des fonctionnalités c'est quand même très en retrait par rapport à kdenlive, notamment au niveau des effets, des images clés et d'un tas d'autres fonctions (stabilisation des images, recadrage et autres zooms), mais c'est très largement suffisant pour un montage simple. La force d'Openshot c'est son interfaçage avec inkscape et blender pour les titres animés ainsi que ses transitions au point que je passe souvent d'openshot vers kdenlive pour certains bouts de séquences. Par ailleurs contrairement à kdenlive on arrive à monter et à jouer sur les effets en restant en HD, avec kdenlive je suis obligé de passer en clips intermédiaires en dégradant les rushs pour faire le montage, malgré mon i7 avec 16Go de RAM.
    Titre de l'image

    Terminons par cinelerra, la dernière version 7 apporte une meilleure prise en compte des vidéos de haute définition et du codec HEVC/x265, ainsi que la prise en compte des caméras sphériques, il y a une vidéo de démonstration par ici https://www.youtube.com/watch?v=zEQ4Cve3_-M . Bon à part ça, c'est toujours vraiment une galère pour le compiler. Une fois qu'on a passé cette difficile étape, à l'utilisation l'interface reste tout aussi brouillonne, vieillotte ça rappelle le X11/Motif dont beaucoup ici n'ont jamais entendu parlé, c'est un peu usine à gaz et ça ne donne vraiment, mais vraiment pas envie de s'y mettre d'autant que maintenant kdenlive l'a largement rattrapé en terme de fonctionnalités et de stabilité tout en offrant une interface bien plus conviviale.
    Titre de l'image

    J'ai quand même noté qu'il existait un fork d'une version Community Version par là https://cinelerra-cv.org/index.php je n'ai pas pris le temps de la tester. Je devrais, car l'interface semble plus sympathique et ça pourrait être un concurrent sérieux.

    Pour résumer, nous avons Openshot Video plutôt destiné aux débutants qui ont juste besoin de mettre quelques séquences bout à bout, kdenlive pour les plus expérimentés qui prennent le temps de monter et de faire des vidéos plus complexes et travaillées et cinelerra pour les masochistes :-). Bref un constat qui est loin d'être un scoop mais qui m'a permis un temps d'oublier la bûche, le sapin de noël et l'ambiance gnangnan qui va avec.

    Lire les commentaires

  • 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

  • Retour d'expérience d'une petite administration sous linux depuis 8 ans qui fait marche arrière (Journaux LinuxFR)

    Bonjour,

    Suite au journal Munich revient sur windows, j'avais envie de faire un retour sur notre triste expérience de 8 ans sous linux.

    Présentation

    Je suis développeur dans une université, j'ai jusqu'à récemment, responsable d'un tout petit service informatique pour un département (équipe de trois personnes en tout). Lors de mon arrivé en 2010, j'ai eu l'agréable surprise de voir que l'ensemble du parc informatique était sous client léger sous debian (parc étudiant + administratif), sous environ 100 de machines.

    Le déploiement n'avait pas été fait correctement, c'est à dire qu'il n'y avait pas eu information, ni formation auprès des usagers qui évidement ont un peu rallé après la perte de leur cher XP et de leur tour individuelle. Mais après un an, les usagers y étaient habitués.

    Habitués, mais à quoi ?

    A la panne. Le système ne fonctionnait pas. Le serveur d'impression tombait toujours en panne, le serveur PXE ne supportait pas la charge, et pour couronner le tout, il n'y avait pas d'admin système, l'installation avait été faite par un prestataire qui une fois le chèque encaissé se contentait de dire qu'il ne voyait pas d'ou ça pouvait venir. Une petite année plus tard, un collègue remis en état le système, sur des nouveaux serveurs et le tout commençait à tenir la route.

    La suite

    Malgré un système assez stable, on pouvait constater un agacement général du service vis à vis de l'informatique et des "clients légers sous linux". Au début j'avais cru que l'utilisateur était toujours attaché à ses anciennes habitudes de windows mais au bout de trois ans, il était temps de faire l'état des lieux des doléances.

    Années 2013-2014

    • Debian :

    Un des soucis rencontrés était les versions des programmes disponibles. Autant le système était assez stable, autant les logiciels de type Openoffice, Firefox etc n'étaient pas mis à jour (hormis les petits patchs habituels). Les logiciels courants devenaient de plus en plus anciens, et le seul moyen sans risquer de tout casser était de mettre à jour le système principal (avec le risque de tout casser).

    • Openoffice :

    Dans une administration, il y a un énorme usage des outils de bureautique, et notamment du publipostage. Comparaison du même publipostage entre word année 2013 (je ne sais plus la version) et Openoffice sur la même tour dell avec les mêmes données (mais pas les mêmes fichiers) : 20 min pour Word, 8 heures pour Openoffice.

    Niveau ergonomie, Word et Openoffice se ressemblaient énormément, je n'ai pas pas constaté de différences mesurables

    • Administration : Je reviendrais plus tard.

    2014-2016

    On a enfin un admin, il refait tout (entre temps je suis devenu le responsable de la fine équipe), il maitrise tout, on est sur du libreoffice, firefox à jours !!!.
    Et pourtant rien ne change. Toujours les problèmes d'impressions, toujours les problèmes de performance, les mêmes utilisateurs en train de raller, bref hormis le temps d'intervention, c'est toujours absolument un service mauvais qui est rendu à l'utilisateur.

    Pourtant l'équipe informatique et les usagers avaient eu le temps de bien s'y habituer. Pour moi tout venait des clients légers, du réseau etc. Le directeur voulait toujours qu'on reste sous linux avec ce système.

    2016

    La fac déploie les mêmes clients légers (même model) sous windows 7 dans le même étage mais avec des serveurs à plus de 100m (les notre à 25m) et ils fonctionnent nickel. Là c'est la claque. En plus l'admin qui s'occupait de ça n'était pas un admin windows.

    C'est une claque

    2017

    On migre sur des postes classiques Windows 7 avec AD et tout fonctionne nickel.

    Retour

    De mon point de vue voici ce qui manque pour que linux perce dans le desktop en entreprise :

    • Trop de manière de faire (contrairement à windows : un active directory et voilà)

    • Les logiciels évoluent sans tenir compte des besoins des utilisateurs lambda : Libreoffice sur mon mac (entre temps moi aussi j'ai craqué après 12 ans de fidélité) est d'une lenteur pour ouvrir un fichier excels de 125 lignes contenant beaucoups de texte (excel nickel), mais il peut théoriquement ouvrir des milliers de feuilles (qui le fait ?). L'ergonomie n'a pas beaucoup bougé, tandis que word complètement.

    On voit directement les secteurs qui sont soutenus par les entreprises. La totalité des serveurs sont sous linux et ça tourne nickel. Par contre combien de bureau et de distribution ? Combien d'énergie dépensée pour réinventer la roue alors qu'elle n'est même pas encore bien ronde.

    Désolé pour les fautes, je n'ai pas du tout l'habitude d'écrire hormis du code.

    Lire les commentaires

  • 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

    L'unité de calculs flottants, 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 switch), cet état est alors restauré pour retrouver un contexte correspondant au processus en cours.

    Ces opérations peuvent être coûteuses car les registres sont plus gros que ceux du CPU, c'est pourquoi les FPU fournissent une option pour désactiver toute opération flottante (CR0:TS) ; aussi, dès qu'un calcul flottant 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 restauration des registres, ou s'il s'agit d'un nouveau contexte, la sauvegarde puis 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/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 tache 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/restauration…
    … et ils peuvent contenir jusqu'à 2Kb 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 CPU 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 CPU 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 à produire. 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 CPU 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 sous les architectures récentes et surtout selon les usages actuels ; voire, le FPU étant 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/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 patch pour la Release 11.2. C'est un FreeBSD 11.1 qui a servi de cobaye ;

    • DragonFly BSD a poussé un patch dans la version 5.2.2 ;

    • Microsoft poussera un patch en juillet ;

    • OpenBSD a poussé un patch le 14 juin pour la version 6.3 ;

    • NetBSD a poussé un patch le 16 Juin sur MAIN .

    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 Core2 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 bugués comme jamais et nombre de ces bugs 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

  • AlterncCamp c'est dès jeudi 21 juin (Journaux LinuxFR)

    Salut

    Ayant déjà fait la dépéche et que le temps est passé, j'en profite pour rappeler que jeudi, vendredi et samedi il est possible d'aider à l'avancée du projet alternc

    Commentaires : voir le flux atom ouvrir dans le navigateur

  • 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

  • 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
            • Où 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\WindowsRE où C:\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

  • La monnaie libre pour une économie du Libre (Dépêches LinuxFR)

    Certains ici auront probablement déjà entendu parler du concept de monnaie libre et peut-être de sa première mise en pratique : la Ğ1 (généralement prononcée "june").
    J’ai pensé qu’une courte présentation sur ce site serait une bonne idée car nous sommes assez nombreux à penser que cette monnaie est parfaitement en adéquation avec la mise en place d'une économie dans l’esprit des logiciels libres : économie de la synergie, du partage spontané, du financement participatif et du don.
    Bonne lecture ! :)

    logo-G1

     Tite histoire

    L’idée de monnaie libre a germé dans l’esprit de Stéphane Laborde, mathématicien français ayant étudié les mécanismes monétaires afin d’en établir des relations mathématiques. Après recherches et rédactions, il produit ce qu’il appellera la Théorie relative de la monnaie, consultable ici dans sa version la plus récente :
    http://trm.creationmonetaire.info/TheorieRelativedelaMonnaie.pdf.
    Cette théorie propose une généralisation du principe de création monétaire et montre les asymétries propres aux systèmes monétaires actuellement en vigueur. Elle établit ainsi les fondements de ce que pourrait être une monnaie que l’auteur qualifiera de « libre » selon des critères qui ne sont pas sans rappeler les quatre libertés fondamentales du logiciel libre.
    Cette monnaie a pour base de création un dividende universel (petite portion de création monétaire créée par chaque individu à intervalles réguliers). Cela ressemble à un revenu universel à la différence que l’on ne reçoit pas ce dividende d’une autorité extérieure, il s’agit donc plutôt d’un « venu » !

    À partir de ce travail, des développeurs particulièrement motivés ont mis au point Duniter, un logiciel libre en pair à pair au fonctionnement similaire à celui développé pour le Bitcoin (chaîne de blocs, preuve de travail, etc.) mais destiné à assurer de la manière la plus sécurisée possible la création et le maintien d’une monnaie libre. Ce qui se produisit en mars 2017 avec le lancement de la Ğ1.

    logo-duniter

    Depuis, les communautés qui utilisent et promeuvent cette monnaie n’ont cessé de croître et de s’organiser, incarnant par là même une alternative crédible au modèle monétaire actuel, inégalitaire par essence.

    Précisons que la Ğ1 est pour le moment unique au monde, et que son principe rompt assez radicalement avec les monnaies habituelles. Ce n’est pas une énième cryptomonnaie obscure aux applications hyper‐spécialistes, c’est une alternative économique sérieuse et équitable qui passe actuellement l’épreuve du réel, de la pratique… et s’en sort pas trop mal !

    Afin de découvrir la monnaie libre et de mieux percevoir ses différences avec une « monnaie‐dette » (comme l’euro, par exemple), un jeu de société a été mis au point : Ğeconomicus. Les groupes locaux en organisent un peu partout en France, ne pas hésiter à se renseigner !

    Si le rapprochement avec le Bitcoin est valable quant à certaines technologies employées par le logiciel Duniter et qui font de la Ğ1 une cryptomonnaie, il devient en revanche erroné en ce qui concerne la monnaie en elle‐même, dont les caractéristiques en sont très éloignées.

    La communauté

    Nous sommes depuis peu plus de 1 000 à être déclarés comme membres de la toile de confiance (communauté de cooptation des cocréateurs de monnaie, avec adoption d’une licence, équivalente à une charte et donc à un engagement auprès de la communauté). Plusieurs personnes sont intégrées chaque jour à cette toile, et pas seulement en France !

    Quelques développeurs travaillent quotidiennement à l’amélioration du logiciel Duniter et de tous les développements liés de près ou de loin à la monnaie libre Ğ1 (gestionnaires de comptes, systèmes d’anonymisation, supervision, etc.).

    Cette équipe étant encore réduite, de nouveaux talents sont espérés, car ils permettraient de pérenniser cette monnaie, de l’enrichir de nouvelles fonctionnalités, d’en améliorer la sécurité logicielle et donc de lui conférer une fiabilité réelle et durable, propice à favoriser son adoption.

    Quoi qu’il en soit, cette monnaie est déjà utile au quotidien et permet d’acheter, de vendre : des légumes, des confitures, des boissons, des vêtements, des bijoux, des livres, des meubles des services et du matériel informatique, etc. En bref, tout ce que l’on veut. Des places de marchés Web existent également.

    À ce titre, des professionnels se sont lancés dans l’aventure, en ayant auparavant bien pris soin de le faire de manière raisonnée, cohérente.

    Les ressources présentes sur le Net répondent généralement à toutes les questions que l’on se pose légitimement sur la monnaie libre.

    Des liens pour les curieux

    Le sujet de la monnaie libre déclenche souvent des discussions animées, tantôt riches, tantôt interminables. Je vous invite à prendre le temps de vous renseigner sur ce dont il s’agit vraiment avant d’aller trop vite aux conclusions ! ;)

    À nouveau, une bonne lecture à tout le monde !

    Aubergine qui salue

    Commentaires : voir le flux atom ouvrir dans le navigateur

  • fdupes : un utilitaire pour gagner de la place sur son disque dur (Journaux LinuxFR)

    Un petit journal juste pour vous indiquer un petit utilitaire bien pratique nommé fdupes, qui permet de détecter les fichiers dupliqués sur votre machine.

    J'ai découvert ce soft dans le cadre du nettoyage de données que je suis en train de faire sur mes disques durs.

    En effet, il m'est souvent arrivé de copier des fichiers d'un répertoire à un autre pour réorganiser mes données sur mon (ou mes) disques, mais comme je n'aime pas jeter ni supprimer, j'ai accumulé certains fichiers en double ou en triple.

    fdupes permet de parcourir les répertoires qu'on lui passe en paramètre et de faire un rapport sur les fichiers en doublon que l'on peut y trouver.

    Pour identifier les doublons, fdupes effectue une comparaison de taille et de signature MD5 de chaque fichier, et ensuite une comparaison octet par octet est effectuée.

    Cet utilitaire m'a permis de gagner près d'une centaine de gigas en 30 mn. Ya encore d u potentiel de gain de place, mais je préfère ne pas me précipiter, pour ne pas perdre malencontreusement des données (les 100 Gb gagnés me permettront de remettre en marche le processus de sauvegarde de mon portable, en attendant de mettre en place une solution à base de nas).

    Note : pour supprimer mes fichiers dupliqués, je n'ai pas fait de rm sauvage: je les ai déplacés vers un dossier avant de les supprimer définitivement, pour éviter les grossières erreurs. Mon dernier rm -fr sur ~ m'a servi de leçon.

    Un lien vers le dépot github du projet et un autre vers quelques explications d'utilisation en français.

    Commentaires : voir le flux atom ouvrir dans le navigateur

  • fdupes : un utilitaire pour gagner de la place sur son disque dur (Journaux LinuxFR)

    Un petit journal juste pour vous indiquer un petit utilitaire bien pratique nommé fdupes, qui permet de détecter les fichiers dupliqués sur votre machine.

    J'ai découvert ce soft dans le cadre du nettoyage de données que je suis en train de faire sur mes disques durs.

    En effet, il m'est souvent arrivé de copier des fichiers d'un répertoire à un autre pour réorganiser mes données sur mon (ou mes) disques, mais comme je n'aime pas jeter ni supprimer, j'ai accumulé certains fichiers en double ou en triple.

    fdupes permet de parcourir les répertoires qu'on lui passe en paramètre et de faire un rapport sur les fichiers en doublon que l'on peut y trouver.

    Pour identifier les doublons, fdupes effectue une comparaison de taille et de signature MD5 de chaque fichier, et ensuite une comparaison octet par octet est effectuée.

    Cet utilitaire m'a permis de gagner près d'une centaine de gigas en 30 mn. Ya encore d u potentiel de gain de place, mais je préfère ne pas me précipiter, pour ne pas perdre malencontreusement des données (les 100 Gb gagnés me permettront de remettre en marche le processus de sauvegarde de mon portable, en attendant de mettre en place une solution à base de nas).

    Note : pour supprimer mes fichiers dupliqués, je n'ai pas fait de rm sauvage: je les ai déplacés vers un dossier avant de les supprimer définitivement, pour éviter les grossières erreurs. Mon dernier rm -fr sur ~ m'a servi de leçon.

    Un lien vers le dépot github du projet et un autre vers quelques explications d'utilisation en français.

    Commentaires : voir le flux atom ouvrir dans le navigateur

  • "Mr Robot" ou comment j'ai appris à aimer l'informatique (Journaux LinuxFR)

    Je viens de découvrir une série qui me transporte actuellement dans le monde informatique: Mr Robot.
    Le pitch, c'est l'histoire d'Eliott Alderson, brillant informaticien travaillant dans la cyber-sécurité et souffrant de paranoia et de dépression. Cyber-justicier, il fait la rencontre de Mr Robot, un mystérieux anarchiste, souhaitant le recruter dans un groupe de hackers. Leur objectif: rétablir l'équilibre de la société par la destruction des infrastructures des plus grosses banques et entreprises du monde.

    Cette série a des références qui me parlent tels que le film "Fight Club" de David Fincher avec le personnage de Tyler Durden, la musique des Dust Brothers, dans des situations anxiogènes, mais aussi le film "Las Vegas Parano" de Terry Gilliam. Par ailleurs, j'aime aussi la place qu'ont les femmes, dans cette série, en particulier Darlène ainsi qu'Angela (des caractères forts, qui en imposent et qui ne sont pas potiches).

    En m'immergeant dans cette série, je découvre un peu plus l'informatique, surtout le code et les langages. Il faut dire que je faisais souvent des pauses dans chaque épisodes lorsqu'on voyait un terminal et du code écrit. Je souhaitais apprendre à coder et être à l'aise comme les personnages. Vu que je suis une novice et que je n'y connais pas grand chose, j'ai reconnu quand même, un chat irc, l'utilisation de tor, le raspberry pi, un femtocell et kali linux. Tout ça, m'a donné envie de m'y mettre. Mon ami étant dans l'informatique m'a pas mal expliqué de choses et tout çà me fascine, mais je mesure le temps et les difficultés afin de comprendre comment tout cela marche.

    Pour commencer mon initiation, je suis sur le point de m'acheter un raspberry pi pour faire des choses simples. Aujourd'hui, j'ai appris ce qu'est une faille informatique. J'ai l'impression d'apprendre une langue étrangère. Il est clair que je vais me tromper, m'arracher les cheveux, m'impatienter… mais, je suis animée par la curiosité et le fait de m'amuser. Tout ça, évidemment à mon échelle. Je ne cherche pas à être une brillante informaticienne, comme Eliott Alderson. Au vue de mon âge, ça parait difficile, mais je veux pouvoir me débrouiller et avoir un socle de connaissances.

    Au-delà des aventures du personnage d'Eliott Alderson et des intrigues qui se dessinent autour de lui, je suis contente qu'une série comme celle-ci parle d'informatique (bien qu'il y en est d'autres, j'en suis sûre).

    Lire les commentaires

  • Les outils de l'IT pour un FabLab (Journaux LinuxFR)

    J'ai eu la chance de découvrir un FabLab à 10 min à pied de chez moi l'année dernière et depuis j'ai rejoint l'équipe IT :-) Notre sujet du moment est de migrer vers un nouveau serveur en Stretch et de rationaliser les outils utilisés.

    Pour la gestion des matériels informatiques, GLPI + FusionInventory remplissent leur office(*)

    Nous avions un dokuwiki (un peu cassé dernièrement) pour permettre aux membres de documenter leurs réalisations sous licence CC-by-SA ; nous nous orientons plutôt vers wikifab basé sur mediawiki et assez joli :

    • il simplifie l'interface pour les membres (pas de connaissance spécifique de mediawiki et guide pour remplir une page de documentation de son projet, taggué selon les technologies et rattaché à un groupe
    • capacité à l'instancier sur notre serveur, ce qui évite de transmettre l'intégralité de notre base d'adhérents à un service centralisé
    • il conserve les avantages de mediawiki et il y a des outils de migration de dokuwiki vers mediawiki
    • il n'y a pas de forum communautaire mais notre contact avec les développeurs à la Maker Faire de la Villette en Juin 2017 nous a encouragé à travailler avec eux

    Le site web principal a été migré sur le nouveau serveur, en conservant wordpress :

    • l'agenda par défaut est peu pratique pour les événements récurrents chaque semaine (il faut créer tous les événements plutôt que donner une période et un jour)
    • l'utilisation d'une carte openstreetmap reste à mettre en place (le greffon googlemaps a été utilisé par défaut o_O)
    • des greffons telegram ou plutôt mastodonte seraient nécessaires
    • les greffons facebook et twitter ne demandent qu'à être remplacés
    • un greffon meetup pourrait être utile (et une autre plateforme plus pratique)

    Notre migration de owncloud vers nextcloud a fonctionné :

    • tous les documents sont disponibles et la synchro est opérationnelle
    • nous regardons l'ajout de l'agenda au besoin, plutôt que dans wordpress
    • le greffon pour les photos nous évitera de remettre en place un piwigo (nous souhaitons à l'IT diminuer le nombre de logiciels utilisés si un existant fait le taf')

    (*) pour GLPI, ce sont de l'ordre de 60 portables / PC fixes sur 2 sites qui sont actuellement gérés :

    • déjà un recensement de l'existant, affecté à des groupes : ateliers, utilisation au FabLab, spécifique matériel (découpe laser, CNC, graveuse laser, ateliers scratch ou arduino) mais cela fonctionne pour les matériels complets ayant démarré et installés, moins bien pour le matos qui a des glitchs (manque disque dur, écran défaillant, mémoire défaillante) et qui devrait être rentré manuellement + mettre une action pour améliorer la situation
    • les fonctions de réservation de matériel pourraient être intéressantes :
      • recenser les matériels pouvant être réservés, déléguer la gestion des réservations (à tester), gérer les matériels non informatique pouvant être prêtés
      • inventaire manuel à tester
      • reste à tester l'interface avec de vrais utilisateurs (GLPI étant par nature très orienté IT…), surtout pour l'aspect réservation et complétude de ce qui est disponible par atelier (groupe ?)
    • nous souhaitons éviter FabManager côté IT :
      • intéressant fonctionnellement (réservation de ressource, gestion des membres, contacts entre membres),
      • mais c'est un docker (difficulté de mise à jour) et c'est la foire aux logiciels à gérer (aussi complexe qu'un mailman 3 que nous avons déjà)
    • GLPI à rendre plus joli : la migration en 9.2 va rénover le 0.84 de debian jessie déployé actuellement et utilisé uniquement par 2 personnes…
    • si vous avez un retour d'expérience ou des exemples utilisables par le commun des mortels, je suis preneur :D Sur stretch idéalement.

    Pour la gestion des membres :

    • grisbi côté comptabilité
    • fusiondirectory pour la gestion de l'authentification et des droits utilisateur
    • mailing-lists via mailman 3 (améliorable, pour traduction en français, gestion des spams, conso mémoire on a passé la VM à 4 Go de RAM pour s'éviter l'OOMK :D).

    Et vous, vous avez un FabLab près de chez vous ?

    Lire les commentaires

  • Sortie d’Ubuntu 16.04 LTS Xenial Xerus (Dépêches LinuxFR)

    Sortie le 21 avril 2016, Ubuntu 16.04 est la vingt-quatrième version d’Ubuntu. Il s’agit d’une version dite « LTS » (Long Term Support), qui sera maintenue pendant cinq ans. Son nom de code est Xenial Xerus, soit le « xerus hospitalier » en bon français.

    Un xerus

    Sommaire

    Distribution Ubuntu

    Logo Ubuntu

    Pour rappel, Ubuntu est une distribution GNU/Linux basée sur Debian. Elle a hérité de sa distribution mère l’objectif d’universalité : elle vise à être utile sur les ordinateurs de bureau, les ordinateurs portables, mais aussi les serveurs, le cloud, les téléphones, les tablettes et les objets connectés en général. Elle se veut simple d’accès pour les utilisateurs n’ayant pas de connaissances poussées en informatique, mais également attrayante pour les développeurs.

    En plus de la distribution mère, Ubuntu, il existe plusieurs variantes officielles, fournies avec des choix logiciels différents, afin de couvrir un besoin (Ubuntu Server, Ubuntu Studio…) ou de fournir un environnement de bureau particulier (Kubuntu, Xubuntu, Lubuntu…). Cette dépêche présente les principales nouveautés.

    Version LTS

    L’abréviation LTS signifie Long Term Support, ou support à long terme, c’est-à-dire que contrairement aux versions stables qui sortent tous les six mois et qui bénéficient des correctifs de sécurité neuf mois après la sortie de la publication stable, une version LTS sort tous les deux ans et est maintenue pendant 60 mois (cinq ans).

    Ce type de support étendu existe depuis les débuts d’Ubuntu (la première LTS était Ubuntu 6.06 « Dapper Drake », sortie il y a dix ans). Cependant, la généralisation du support de cinq ans à toutes les variantes (et pas seulement les serveurs) date d’Ubuntu 12.04 LTS « Precise Pangolin ».

    À noter cependant que certaines variantes, pour diverses raisons, peuvent décider de ne pas participer à la LTS ou de s’engager pour un temps plus restreint. La maintenance pendant 5 ans concerne Ubuntu Desktop, Ubuntu Server, Ubuntu Core et Ubuntu Kylin (adaptée aux utilisateurs chinois). Les autres variantes (Kubuntu, Lubuntu, Ubuntu GNOME, Ubuntu Mate, Ubuntu Studio, Xubuntu et Mythbuntu) ne seront maintenues « que » pendant trois ans.

    Il est possible de mettre à jour d’une version LTS à une autre. Si vous utilisez actuellement Ubuntu 14.04 LTS, notez que la mise à jour ne vous sera pas proposée avant fin juillet et la sortie de la première réédition « 16.04.1 » de cette nouvelle Ubuntu. En attendant, si vous souhaitez forcer le mouvement, vous pouvez simplement lancer la commande do-release-upgrade -d.

    Nouveautés générales

    • Noyau Linux 4.4 ;
    • prise en charge de ZFS disponible par défaut ;
    • Mesa 11.2 ;
    • systemd 229 ;
    • GCC 5.3 ;
    • Python 3.5 ;
    • PHP 7 ;
    • LXD 2.0 ;
    • la majeure partie des composants de GNOME passe en 3.18 ;
    • Qt 5.5.1 ;
    • LibreOffice 5.1 ;
    • prise en charge de la version 64 bits de la z/Architecture d’IBM (s390x).

    Le cas des cartes graphiques AMD/ATI

    AMD ne maintient pas son ancien pilote propriétaire sur Ubuntu 16.04, et celui-ci a été retiré des dépôts. Les utilisateurs mettant à jour depuis une version précédente d’Ubuntu seront automatiquement redirigés vers le pilote libre.

    Afin d’assurer une meilleure compatibilité et de meilleures performances, les composants du noyau correspondants ont été rétro-portés depuis la version 4.5 de Linux.
    À noter que le nouveau pilote propriétaire d’AMD, fonctionnant avec le module noyau libre « AMDGPU », devrait être ajouté aux dépôts officiels d’Ubuntu lorsque celui-ci sera disponible en version stable, courant 2016.

    Paquets snap

    La distribution adjoint au classique format de paquets deb, le format maison snap.

    Issus du retour d’expérience de l’Ubuntu phone et des plate-formes IoT (pour Internet of Things), les paquets Snap devraient fournir un environnement isolé pour exécuter des applications sans risquer de corrompre son système ou ses fichiers. Aussi, un paquet Snap peut contenir l’ensemble de ses dépendances binaires. Ceci devrait faciliter la mise à disposition des dernières applications alors que le système ne proposera plus des versions à jour des bibliothèques nécessaires. Et c’est particulièrement le cas pour une LTS en fin de vie.

    À noter cependant que le gain de sécurité des paquets Snap est quasi nul pour les applications graphiques dans un environnement X11. Cela est dû au protocole X en lui même, qui n’a pas été conçu pour isoler ses clients les uns des autres. Heureusement, la transition vers Mir et les divers compositeurs Wayland permettra de remédier à tout cela.

    L’outil Snapcraft a été mis à disposition. Il permet de créer et de publier des paquets Snap en quelques commandes.

    Nouveautés propres aux variantes

    Ubuntu

    La variante par défaut continue de se reposer sur la bonne vieille version 7 de Unity. Pour rappel, celle-ci est implémentée en tant que greffon dans Compiz.

    Unity 7 et Compiz continuent d’être maintenus et profitent encore de cette nouvelle version pour recevoir quelques retouches et autres optimisations.

    En vrac

    • Empathy (client de messagerie instantanée) ainsi que Brasero (graveur de disques) ne sont plus installés par défaut ;
    • l’application « Agenda » (gnome-calendar) est maintenant installée par défaut ;
    • le formatage est maintenant proposé dans le menu contextuel associé aux périphériques amovibles dans le dock de Unity ;
    • meilleure intégration des applications GTK utilisant une barre d’outils (headerbars) ;
    • l’exposé des applications peut maintenant se faire via la combinaison « Super+Ctrl+w » ;
    • une nouvelle option du centre de contrôle permet de toujours afficher le menu des applications ;
    • amélioration de l’accaparement du clavier de GNOME (key grabbing) ;
    • le nouveau design des barres de défilement (introduit dans Ubuntu 15.10) est maintenant également appliqué dans le dash ;
    • un meilleur support des thèmes a été implémenté dans le dash ;
    • support de la mise à l’échelle du curseur sur les écrans à très haute résolution (HiDPI) ;
    • grâce aux contributions de l’équipe d’Ubuntu Kylin, la barre de lancement peut être positionnée en bas. C’est d’ailleurs la configuration par défaut sur cette variante.

    Les recherches dans le dash se font maintenant hors ligne par défaut

    Il y a un peu moins de 4 ans, Ubuntu 12.10 créait la polémique en introduisant des résultats en provenance d’Amazon, d’Ebay ou encore de Wikipédia dans les recherches effectuées depuis le dash.

    L’intention était de faire du dash un moteur de recherche comme un autre, permettant aux utilisateurs de trouver tout et n’importe quoi, plutôt que de rester centré sur l’ordinateur en question. Cependant, de nombreuses personnes se sont scandalisées de cette fonctionnalité. Les résultats commerciaux étaient parfois assimilés à de la publicité. Certains, comme Richard Stallman, ont déclaré qu’il s’agissait purement et simplement d’un spyware (les recherches étant effectuées sur le net, tout ce qu’un utilisateur tape dans le dash est donc transmis à un serveur distant).

    Cette polémique est restée un argument parmi d’autres pour ne pas utiliser Ubuntu chez certains libristes intransigeants, et ce malgré la présence d’une option permettant de très facilement désactiver toute recherche en ligne.

    Ubuntu 16.04 met enfin un terme à tout ceci, puisque le dash ne cherche désormais plus rien en ligne par défaut.

    Canonical se serait donc réconcilié avec Saint IGNUcius ? Pas forcément, car la raison évoquée pour ce changement est bien plus pragmatique : Unity 7 étant amené à disparaître et Unity 8 utilisant un dash très différent, il n’y a pas de sens à continuer d’investir dans la montée en charge de l’infrastructure nécessaire côté serveur, et ce pendant les 5 ans du support de cette version LTS.

    Cependant, les nostalgiques seront ravis d’apprendre qu’ils pourront réactiver les recherches en ligne manuellement dans les paramètres système.

    Changement de logithèque

    La logithèque Ubuntu (Ubuntu Software Center) est retirée au profit de la logithèque de GNOME (GNOME Software).

    Proposée pour la première fois avec Ubuntu 9.10, la logithèque Ubuntu avait pour but d’uniformiser l’installation des applications dans Ubuntu. Pour Chris Hoffman de PCWorld.com le logiciel était à cette époque bon, mais a été laissé à l’abandon et est aujourd’hui plutôt lent. Il n’était plus dans la course et avait été retiré de Ubuntu MATE 15.10 pour cela. Controversée pour proposer des logiciels payants (le plus souvent propriétaires) au même titre que des logiciels libres, cette possibilité a été retirée sans prévenir les développeurs courant 2015, préparant l’abandon complet du logiciel.

    Pour les utilisateurs, ce changement, malgré des problèmes esthétiques, va permettre une expérience plus rapide, ainsi qu’une uniformisation avec Debian.

    Kubuntu

    Les principales nouveautés de cette variante utilisant KDE SC sont liées à l’intégration de la suite KDE Applications dans sa version 15.12 ainsi que d’une version corrigée et améliorée du gestionnaire de fenêtres Plasma 5 (version 5.5.4).

    De nombreux bugs ont été corrigés, l’application de capture d’écran « Spectacle » remplace l’ancien « KSnapshot », l’interface de l’éditeur vidéo « Kdenlive » a été améliorée, le gestionnaire d’archive « Ark » peut maintenant afficher les commentaires intégrés dans les fichiers ZIP et RAR…

    Cette variante sera maintenue pendant trois ans.

    Xubuntu

    Cette variante se voulant légère est basé sur Xfce.

    Le bureau Xfce n’ayant pas reçu de nouvelle version majeure depuis plus d’un an, il n’y a par conséquent que peu de vraies nouveautés à rapporter ici. En plus de la mise à jour de plusieurs applications, on pourra noter l’apparition d’un nouvel applet de gestion de l’énergie, d’une nouvelle sélection de fonds d’écran ainsi que l’amélioration de l’esthétique de l’écran de connexion.

    Cette variante sera maintenue pendant trois ans.

    Ubuntu GNOME

    Cette variante 100 % GNOME reprend une grande partie des nouveautés évoquées pour Ubuntu, mais en proposant GNOME Shell par défaut. Pour les nouveautés propres à GNOME 3.18, vous pouvez vous référer à la dépêche correspondante.

    Cette variante sera maintenue pendant trois ans.

    Ubuntu MATE

    Cette variante se voulant légère est basée sur le bureau MATE, qui est la continuité de GNOME 2.
    Il s’agit de la première version LTS d’Ubuntu MATE, et celle-ci sera maintenue pendant trois ans.

    Ces six derniers mois ont vu l’intégration de la suite MATE 1.12.1, l’ajout du lanceur d’application Synapse, l’amélioration de l’intégration avec Compiz et d’autres choses encore.

    Lubuntu

    Cette variante se voulant très légère est basée sur LXDE.

    Depuis plusieurs mois, le gestionnaire de bureau est en cours de réécriture pour passer de GTK à Qt (LXQt). Ce travail massif n’étant malheureusement pas terminé, il n’y a donc pas de vraie nouveauté spécifique sur Lubuntu 16.04, hormis des corrections de bugs et l’utilisation d’applications plus à jour.

    À noter que cette version de Lubuntu est également disponible officiellement pour l’architecture PowerPC (ce qui n’est pas le cas pour les versions non LTS).

    Cette variante sera maintenue pendant trois ans.

    Edubuntu

    Cette variante centrée sur l’éducation est malheureusement dormante, faute de main d’œuvre. Les anciens mainteneurs n’ont pas pu faire le travail nécessaire pour pouvoir sortir cette version 16.04. Ceux-ci préfèrent consacrer le peu de temps qu’ils ont sur le maintien de la dernière version d’Edubuntu en date : la 14.04.

    Un appel a été lancé pour trouver de nouveaux mainteneurs plus disponibles, faute de quoi Edubuntu finira par disparaître. Une lueur d’espoir cependant : au moins une personne s’est annoncée publiquement disponible pour reprendre les rênes de la distribution.

    Ubuntu Touch (téléphones, tablettes, mais pas que)

    Ubuntu Touch est une distribution dérivée à part entière. Il s’agit d’une quasi rolling-release dont chaque nouvelle version est déployée, en moyenne, toutes les six semaines. À terme, c’est cette version qui devrait prendre la place de l’Ubuntu officielle.

    Trois versions ont été déployées au cours des six derniers mois. On pourra noter les nouveautés suivantes :

    • De nouvelles applications sont installées par défaut :
      • un client mail (Dekko) ;
      • un calendrier/agenda ;
      • un navigateur GPS complet basé sur OpenStreetMap (uNav, développé par un membre de la communauté) ;
    • le tutoriel apparaissant au premier lancement a été entièrement refondu ;
    • toute la pile Bluetooth (jusqu’au noyau) a été mise à jour vers Bluez5 afin de permettre l’ajout de nouvelles fonctionnalités liées à ce protocole ;
    • support des sonneries/alarmes personnalisées ;
    • une notification sonore est maintenant jouée lorsque la batterie est faible ;
    • support d’OpenVPN (PPTP devrait suivre prochainement) ;
    • mise à jour de la palette de couleur : les applications peuvent maintenant choisir entre un thème clair et un thème sombre ;
    • support du clavier japonais ;
    • amélioration du support du Pinyin ;
    • ajout et optimisation de composants dans la palette des éléments d’interface utilisateur ;
    • la synchronisation des contacts se fait maintenant via Buteo, originellement développé par Jolla : celui-ci est modulaire et devrait permettre de rajouter de nouveaux protocoles relativement facilement, on pense à CardDAV par exemple ;
    • nouveau design pour l’application météo ;
    • l’actualisation du contenu des scopes se fait maintenant de façon bien plus fluide ;
    • un nouveau scope pour Twitter ainsi que pour la recherche de livres ;
    • diverses améliorations concernant le positionnement (GPS) ;
    • il est maintenant possible de lire des playlist en arrière plan ;
    • la lecture de média (pause, playlist…) peut être contrôlée depuis l’indicateur son ;
    • possibilité de jouer du son depuis un scope ;
    • le navigateur web a beaucoup évolué :
      • support de la caméra et du microphone : il ne manque apparemment qu’un peu d’interface (sélection de la caméra…) pour que les applications basées sur WebRTC soient entièrement fonctionnelles ;
      • ajout d’une vue globale des favoris ;
      • amélioration de la convergence (contrôle au clavier et à la souris…) ;
      • tous les types de fichiers peuvent maintenant être téléchargés ;
      • possibilité de sélectionner/copier/coller au sein des pages web ;
    • les applications peuvent maintenant directement proposer des achats (achats in-app) ;
    • de nombreux bugs ont également été corrigés.

    Un nouveau téléphone et une nouvelle tablette

    Au cours des six derniers mois, deux nouveaux appareils ont été dévoilés.

    Meizu PRO 5 Ubuntu Edition

    Le Meizu MX4 Ubuntu Edition ayant apparemment été victime de son succès (il n’est plus disponible à la vente), Meizu propose désormais en précommande son téléphone « PRO 5 Ubuntu Edition ». Il s’agit, ni plus ni moins, de l’Ubuntu Phone le plus puissant/haut de gamme à ce jour.
    Certains journalistes l’ayant eu en main regrettent cependant une fluidité qui ne serait pas à la hauteur des spécifications de la bête. C’est probablement pour cette raison que le téléphone n’est pas encore officiellement mis en vente, le temps que les ingénieurs de Canonical et de Meizu corrigent les problèmes en question.

    Ce téléphone pourra utiliser la technologie Miracast pour déporter son affichage sur d’autres écrans.

    BQ Aquaris M10 Ubuntu Edition

    Il s’agit non seulement de la première tablette utilisant Ubuntu, mais également du premier appareil proposant la fameuse convergence sur laquelle les développeurs d’Ubuntu travaillent d’arrache pied depuis de nombreux mois.

    Tablette BQ Aquaris M10 Ubuntu Edition

    En arrière plan vous pouvez voir le mode « tablette » classique, qui permet d’afficher deux applications simultanément : une que l’on peut placer sur le côté en la faisant glisser avec trois doigts et l’autre qui prend le reste de l’espace disponible.

    Certaines applications adaptent automatiquement leur ergonomie lorsqu’elles fonctionnent sur un grand écran comme celui d’une tablette. Par exemple, sur un téléphone, le client mail Dekko affiche la liste des emails et leur contenu dans des écrans dédiés. Sur un grand écran, Dekko affiche les deux côte à côte.

    Les choses deviennent cependant encore plus intéressantes lorsque l’on connecte un clavier et une souris à la tablette, que ce soit via Bluetooth ou via un câble adéquat. La tablette passe alors automatiquement en mode « bureau », ce qui transforme l’interface pour la faire ressembler au bureau Unity que nous connaissons tous, avec des fenêtres et les contrôles associés.

    Il est de plus possible de connecter la tablette à un écran externe, ce qui transforme ainsi l’ensemble en un véritable ordinateur de bureau.

    Pour couronner le tout, cette tablette vient préinstallée avec des logiciels usuels comme Firefox, LibreOffice et GIMP, qui sont disponibles en mode bureau. Ceux-ci tournent dans des conteneurs dédiés (Libertine) avec l’aide de Xmir.

    La tablette BQ Aquaris M10 Ubuntu Edition est d’ores et déjà disponible et existe en deux modèles différents. Compte tenu de la jeunesse des fonctionnalités mises en œuvre, il s’agit toujours d’un appareil non destiné au grand public (il n’est d’ailleurs vendu qu’en ligne). Cependant, de nombreuses améliorations et corrections de bugs sont attendus dans les prochaines semaines, au rythme des mises à jour OTA.

    Et la suite ?

    Ubuntu 16.10 aura pour nom de code « Yakkety Yak ». Rien d’officiel n’a été annoncé pour le moment, mais cette version (voire la suivante) devrait enfin voir l’arrivée de Unity 8/Mir par défaut. On notera que le pilote propriétaire Nvidia est depuis peu compatible avec Mir, ce qui signifie qu’un des derniers obstacles majeur avant le replacement de Unity 7/Xorg a été surmonté.

    Lire les commentaires

  • Un nouvel outil pour synchroniser Postgres et LDAP (Journaux LinuxFR)

    Salut les moules,

    Comme je sais qu'il y a quelques DBA parmi nous, je passe la nouvelle: j'ai travaillé depuis un mois sur un outils pour créer les rôles dans Postgres à partir d'un annuaire LDAP: ldap2pg.

    Pour la petite histoire, contrairement à PAM, PostgreSQL a besoin que les rôles soient créés dans l'instance avant de demander à LDAP d'authentifier l'utilisateur. Dis autrement, LDAP ne sert qu'à récupérer le mot de passe, c'est toujours PostgreSQL qui stocke les rôles, leurs options (SUPERUSER, LOGIN, etc.) et l'héritage de rôles entre eux.

    Il y a un projet pg-ldap-sync qui existait déjà. Pourquoi avoir réinventé la roue ? D'abord un soucis pratique: c'est en ruby, et on installe rarement ruby sur un serveur PostgreSQL ou alors c'est pas la bonne version, très peu de dépendances sont disponibles en paquets rpm/deb. Ensuite, pg-ldap-sync est assez simple: une recherche LDAP pour les utilisateurs et une pour les groupes. L'idée de définir ça dans un fichier YAML propre est très chouette.

    Tous les utilisateurs ont les mêmes options: pas moyen de créer des SUPERUSER sans que tout le monde le soit. Je voulais gérer dans un seul fichier YAML la définitions des rôles d'une instance. Sinon il faut faire des blacklists pour ne pas dropper ce qu'on crée par ailleurs.

    En outre, je voulais aussi accorder ou révoquer les ACLs des rôles. Là ça commence à être assez avancé: je veux gérer qui a les accès DDL ou pas, les accès DML ou pas. Et sans que l'outil écrive les requêtes à ma place.

    Au final, en un mois de dév je trouve ldap2pg assez complet et pas mal documenté! Et vous comment gérez-vous les rôles de vos instances PostgreSQL ?

    Lire les commentaires

  • Tutoriel 3D - 2D découpe au laser, le retour du tux (Journaux LinuxFR)

    Sommaire

    Tranche de pingouin

    Chose promise, cause perdue. Voici comment transformer un modèle 3D en tranches de bois pour découpe laser. Et en bonus, mon essai initial de découpe en création originale.

    Les outils que j’ai utilisé sont blender et inkscape, et ce juste parce que je les connaissais et donc plus facile pour expérimenter.

    Note aux amateurs de freecad, j’ai commencé à regarder comment ça marche, au cas où ce serait plus simple avec, si jamais je trouve une idée et le courage de refaire un tuto, ça me fera un zeugma.

    Au début était le cube

    Ouvrir un nouveau fichier dans blender et mettre la scène en métrique, car sinon les mesures ne sont pas fixées par taille réelle. Notez que à chaque étape du tuto on aura des soucis de conversion de dimensions, donc en fait… mais bon faut pas en profiter pour être négligent.

    où trouver le changement metrique

    Retirer le cube et ajouter le Tux à la scène. Vous pouvez le trouver ainsi que toutes les licences à Tuuuuuuux

    • Faire face au tux (1 au pavé num)
    • Mettre la vue iso (5 au pavé num)
    • sélectionner le tux
    • passer en editor mode (tab)
    • Sélectionner le dessous des pattes (B) qui est rond
    • Niveler (SZ0)
    • sélectionner les deux centres des pattes, (S) Snap cursor to selected
    • rebasculer en object mode (tab) , transform origine to 3d cursor (object/transform)

    Maintenant, le tux est calé pour avoir le plancher des pattes en comme origine, à la verticale du pseudo centre de gravité que nous venons de choisir.

    mettre la bête en Z 0.

    Il est gros vot manchot ?

    Il nous faut choisir une taille, suffisamment grosse pour que ce soit cool, et pas trop gros pour limiter le prix. Comme l’objet c’est aussi tester une bonne quantité d’épaisseurs pour voir comment ajuster la taille théorique d’une planche par rapport à sa taille réelle (il reste du vide, la colle ça épaissit, les planches sont pas forcément pile à la taille).

    Une planche 2mm chez sculpteo (chez qui je teste la découpe laser) fait 94cm*59cm, il faut aussi essayer de rester dans une seule planche avec tous les morceaux. Le tux est presque aussi large que haut, du coup on cherche une approximation de cube découpé en tranches et étalé fait la même surface en gardant un peu de marge. ça fait 55 tranches, donc une hauteur de 116.875mm

    Et si on l’écartelait ?

    Il nous faut séparer les pattes du corps du tux (ce sont des objets distincts dans le modèle de base en fait et elles s’interconnectent :

    Tux pattes interconnectées

    Il faut les réunir par booléen union au corps pour avoir un seul objet avec un intérieur/extérieur propre.

    tux vue pattes melees

    On peut maintenant appliquer une subdivision sur le tux CTRL+3, parce que le tux aime la douceur, et pas que celle angevine.
    c'est mieux avec les pattes creuses, c'est comme les heures à l'edf

    Lui sculpter des yeux plus sympa, parce que même si tout le monde ne veut pas l’avouer, pour avoir l’air cool faut quand même avoir un peu l’air con.

    tux sculptation des yeux (ou sculptage selon les régions)

    la même en couleur

    Mais quand est-ce qu’on coupe ?

    Patience, il faut regarder un peu avant de couper. Placer un plan plus grand que le tux au sol, genre 20cmx20cm et lui appliquer un booléen d’intersection avec le tux. Et regarder en bougeant le plan sur Z comment seront les tranches.

    On voit deux endroits à problème, les ailes et la queue qui auront des tranches avec plus que un morceau, ce qui est plus complexe à coller.

    par ex les ailes :

    ailes dissociées

    Ce sera lourd à coller ensuite, on peut mais pourquoi…

    autant relier les ailes au tronc le plus légèrement possible, avec un lien de 1mm de large.

    idem au niveau de la queue :

    queue perdue

    J’ajoute un bloc en union au niveau de la queue, le plus ajusté possible par un booléen union.

    jointure queue

    Cela vous permettra de facilement coller, il sera toujours possible de le limer après collage.

    Il faut bien nettoyer le résultat de l’union à l’intérieur du tux, ne pas laisser de cloisons internes, c’est à dire éviter d’avoir des plan à l’intérieur des plans :

    retirer les morceaux à l’intérieur des autres

    Finir de nettoyer en retirant les doublons de vertices, boucher les trous, assurer les normales pour que ce soit clair ce qui est à l’intérieur et à l’extérieur.

    Et si on l’empalait ?

    Pensons au support central qui va nous permettre de facilement positionner et coller les tranches de tux, il va être en trapèze et ressembler à ça au niveau d’une tranche :

    plan des tranches

    Le choix de la découpe sera donc toujours du côté le plus grand, en bas. Donc notre référence pour le positionnement des plans de découpe doit être la face basse de chaque tranche.

    Replaçons le plan à 0.01mm en Z (pour éviter le chevauchement parfait des surface avec les pattes Z=0), pensez à remettre tous les éléments avec scale=1 (Ctrl+A scale and rotation) pour la suite.

    Faire une array de 50 plans en Z espacés de 2.125mm, faire le booléen intersection avec le tux. Lors de la réalisation de mon bureau réel avec des tux, j’ai constaté que l’empilage de x tranches de 2mm n’a pas un résultat de x*2mm, mais avec l’air restant et la colle environ 2.125. Je vais affiner avec ce tux cette estimation mais déjà on part de 2.125mm par tranche.

    On voit les tranches et on voit des petits problèmes

    problème de tranche

    Une tranche qui manque en haut et le cul qui a une mini tranche en bas.

    Diminuer le overlap thresold du booléen pour que le problème du haut disparaisse :

    option thresold

    Remonter le point du bas du tux pour supprimer le second problème et non, ce n'est pas lui mettre un doigt dans le cul car ça ne doit pas rentrer :

    trou du cul de tux

    Nickel !

    bonnes tranches

    Simulons une épaisseur des tranches pour avoir un aperçu du résultat réel, ajoutons au plan un modifier solidify 2mm avec l’offfet à +1 (vers le haut) pour suivre le plan d’avoir la face basse comme référence :

    simul résultat final

    Le résultat est conforme, retirez le solidify, il ne doit pas interférer avec l’étape de création du lien central.

    On l’empale plus ?

    Mais si, mais si. En fait ce n’est pas obligatoire, mais ça facilite le positionnement des étages, et on peut aussi le garde sans le coller. Le lien central doit avoir une forme de trapèze et être parfaitement vertical, car pour l’instant sculpteo ne fait pas de découpe oblique.

    Il doit faire une épaisseur égale à celle du bois. Pour mon exemple je suis resté sur mon approximation (2.125mm) mais normalement il faut prendre 2mm et ajuster avec l’épaisseur du kerf qui est la taille du laser laissant un vide de découpe autour du trait de coupe. En pratique lors de mon premier essai j’ai eu des soucis d’épaisseur et j’ai du poncer mon trapèze. Du coup comme ce n’est pas nécessaire d’ajuster. Je surestime cette fois-ci la taille du trapèze.

    trapeze

    Il faut ajuster sa position pour qu’il traverse tout le tux, coup de chance c’est possible sur ce modèle en plaçant la traverse au centre de la dernière tranche du tux. Mais sinon on l’aurait simplement fait avec deux trapèzes sur deux hauteurs.

    Ajustez la taille en X et la hauteur de la partie haute pour faire joli, elle va dépasser un peu et même arrondir sa tête (note postérieure en pratique le trapèze sera toujours trop court, il faut juger les tranches encore un peu plus grand que 2.125mm).

    tete de tux

    En dessous ajuster aussi la taille en X pour donner un beau trapèze

    mise en trapeze

    On voit que c’est moche au niveau du pied

    tux chaplin

    On va donc remodeler un peu le trapèze pour qu’il soit plus joli à cet endroit.

    remodelage du pied

    aspect final

    Parlons peu, parlons kerf

    Le kerf c’est la partie du bois éliminée par le laser, en pratique la découpe est plus petite que le plan car le laser à une taille non ponctuelle. la découpe de la traverse dans les tranches sera donc un peu plus grande que prévu, et la traverse découpée plus court aussi que prévu.

    Dans ce modèle, on peut ignorer le kerf et accepter les différences, elles seront minimes et les pièces collées seront bien ajustées.

    appliquons donc le booléen différence entre le plan des tranches et la traverse

    Le résultat est difficile à voir mais en vue fil de fer c’est visible

    vue fil de fer du tux trapeziste

    C’est la lutte finale

    On peut passer à la phase finale, on réalise les “modifier” sur les planches, puis on aplati le trapèze en retirant les vertices d’un côté.

    En mode éditeur, on sépare toutes les tranches (P+loose parts en mode édition) et on les étale dans le bon ordre en vue du dessus. Attention, les numéros générés lors de la réalisation de l’array ne sont pas forcément dans l’ordre de Z…

    Pour ne pas me planter, je me met dans une vue adaptée et je bouge une par une les tranches avec des gx0.1 … Je vérifie bien que tout est dans l’ordre puis je met tout le monde à plat (sélectionner tout A puis SZ0)

    Nous allons avoir des soucis de conversion de taille entre blender puis Inkscape puis sculpteo… on commence par poser un étalon dans blender, un plan au sol de 1cm sur 90cm

    90cm etalon

    Le petit oiseau va sortir

    Enfin presque, il faut encore à faire la photo !

    Il existe une option de rendering qui génère du svg.

    Mettons la caméra au dessus en mode orthographique, d’abord une résolution 100% sur un ratio approximatif de mon rectangle incluant tout.

    100 pourcent

    puis placer la caméra assez bien au dessus de la scène et changez les paramètres :

    ortho

    L’échelle orthographique est ce qui correspond au zoom, ajustez la valeur pour que tout rentre au plus juste

    Tout doit rentrer dans la fenêtre de rendering :

    serrez les rangs

    Maintenant depuis les user pref, activez le svg freestyle exporter :

    options rendering

    Et activez les deux options freestyle et svg export depuis les options rendering

    option rendering activee

    Pressez F12, une image svg sera générée dans le répertoire indiqué dans output nommé 0001.svg,

    Ouvrez le dans Inkscape, dégroupez et sélectionnez l’étalon. mettez lui une épaisseur de contour à 0 pour ne pas fausser la taille et regardez sa taille. Dans mon cas je tombe sur 35.719cm.

    Je vais donc changer la résolution de l’image pour ajuster la taille d’un facteur de 90/35.719=2.52

    Je change dans blender le render pour :

    retailler

    Re F12 et vérification.

    Mon étalon fait maintenant 1cm sur 90.01cm.

    aller, on essaie avec un pixel de moins en Y :), on tombe sur 89.987. C’est moins bon, retour en arrière.

    Maintenant que l’on a les bonnes tailles dans Inkscape, il faut nettoyer. Parce que le freestyle a introduit des pixels de temps en temps.

    Je prends donc chaque découpe pour la repositionner au mieux et aussi supprimer les traces.

    points artefacts

    Pour m’aider et aussi servir d’étalon entre Inkscape et sculpteo je place un cadre dans une autre couleur qui délimite ma sélection, 53.5cm de large sur 75cm de haut.

    Et je fais tout rentrer dedans.

    Je vérifie chaque pièce pour assurer qu’il n’y a pas de défaut, et j’assure les contours à 1px et mon cadre avec une couleur différente

    C’est prêt.

    planche à découper

    Pour ceux qui sont plus observateurs que moi, vous verrez que j’ai oublié de grouper une fente dans une tranche. Moi je vais le voir au montage plus tard…

    TuxOlaser

    J’upload chez sculpteo.

    Deux couleurs sont détectées, l"une correspond au noir et l’autre au rouge du cadre. Les mesures n’ont pas été conservées, je ne sais pas pourquoi… mais mon cadre me permet de choisir un ajustement de taille à 26.5% qui me redonne les bonnes dimensions.

    Je peux alors désactiver le cadre rouge dans sculpteo (style 2 sur aucun et voila !

    prêt à couper.

    Livraison comprise il vous en coûtera 53.33€.

    Pour info, les tux du bureau ont coûté moins cher, ils étaient en une seule livraison et un peu plus petits, 72€ les 3.

    Déboitage du tux et montage

    Je hais les video de unboxing, et me voilà moi même à déboiter…

    Bon, puisqu’il faut :

    la boite est bien protégée

    boite

    et la planche dans la mousse

    planche entourée de mousse

    Les pièces sont tenues par du scotch, il faudra faire attention en retirant le scotch de ne pas casser les pièces fragiles.

    scotch sur les pieces

    Je numérote mes pièces avant de défaire, c’est moins cher que de faire des numéros au laser.

    sans scotch à numéroter

    Ensuite on empile jusqu’à la fameuse pièce 33 qu’il faudra redécouper.

    debut d'empilage

    piece 33

    redecoupe de la 33

    piece 33 empilee

    Tadaaaa

    Entrer une description pour l'image ici

    A propos de licences

    J’ai fouillé pour trouver les licences attachées au modèle de base, les voici :

    https://opengameart.org/content/tux

    https://opengameart.org/sites/default/files/license_images/gpl.png

    http://www.gnu.org/licenses/gpl-3.0.html

    https://opengameart.org/sites/default/files/license_images/cc-by.png

    http://creativecommons.org/licenses/by/3.0/

    Les fichiers

    Voila les fichiers sources blender et le inkscape (piece 33 corrigée)

    fichier blender

    fichier svg

    Commentaires : voir le flux atom ouvrir dans le navigateur

  • Le logiciel libre dont on ne peut utiliser les libertés (Journaux LinuxFR)

    Sommaire

    Dans mon entreprise, on utilise des logiciels libres. Il arrive qu'on aie besoin de modifier ces logiciels tiers, pour gérer un cas spécifique ou pour une meilleure intégration dans l'application.

    Et parfois, en se lançant dans ce genre de travaux, on tombe sur une surprise :

    Il existe des logiciels libres dont il est presque impossible d'utiliser les libertés sans une quantité déraisonnable de travail.

    Je ne parle pas d'openwashing ici, cette technique qui consiste à faire croire qu'un logiciel est libre mais ne l'est pas et dont on a récemment parlé ici. Non, je parle de programmes véritablement libres (sous licence Apache ou MIT généralement, notre code n'étant pas libre ça ne peut être des licences contaminantes comme la GPL) mais dont les subtilités font que… visiblement quelqu’un ne veut pas que les libertés soient trop utilisées. On notera déjà que c'est souvent des logiciels dont il existe une version avancée commerciale.

    Les libertés d'exécution et de redistribution sont généralement faciles à appliquer ; le problème survient souvent quand on veut étudier le programme et l'améliorer. Voici quelques exemples de techniques utilisées ; certaines peuvent être expliquées par un simple manque de volonté d'adhérer à l'esprit du logiciel libre ou par une mauvaise organisation interne ; d'autres s'approchent du sabotage. Dans tous les cas, la licence est respectée à la lettre.

    Toutes les techniques ci-dessous ont été croisées dans des cas réels (heureusement pas toutes sur le même projet) :

    Aucune documentation technique

    Il n'existe aucune documentation technique d'aucune sorte. Selon la taille du logiciel, ça peut être plus ou moins gênant (je vous laisse imaginer quand le workspace du projet fait plusieurs centaines de Mo).

    Parfois, rien qu'obtenir une version exécutable du logiciel à partir des sources est un calvaire.

    Une version avancée consiste à utiliser des frameworks, compilateurs ou réglages exotiques, sans que ce soit documenté publiquement.

    Les dépendances cachées

    Les dépendances du projet vont par défaut se télécharger depuis un serveur qui appartient à la même organisation que le projet, et pas depuis les dépôts standards. Et surprise, ce serveur ne contient (en public) que les dernières versions des dépendances.

    Au pire, ces dépendances sont elles-mêmes libres, on peut toujours aller les chercher et les compiler à la main, mais la quantité de travail pour obtenir une version fonctionnelle explose dès qu'on veut autre chose que la toute dernière version. Et je ne parle pas de la galère quand on veut mettre à jour un fork depuis l'origine.

    Le faux dépôt de sources

    Celle-ci est subtile : le dépôt des sources public n'est d'évidence pas un dépôt de travail, puisqu'il ne contient qu'un seul commit par version, sans le moindre commentaire. Ça n'est pas gênant tant qu'on essaie pas de maintenir un fork.

    La version avancée, qui consiste à ne fournir les sources que sous la forme d'un dossier compressé sans le moindre historique, semble avoir à peu près disparue, du moins dans mon domaine.

    Le tapis et le labyrinthe mouvant

    Deux variantes d'une même technique :

    1. Les sources peuvent être planquées à un endroit inaccessible, voire carrément absentes du site éditorial – rien, pas même un lien, pas même une mention claire de la licence : si tu ne sais pas déjà que le logiciel est libre… tu le découvres en lisant la licence après avoir donné toutes tes informations pour la fameuse « version de démonstration 30 jours ».
    2. Le site change tout le temps, et la manière d'accéder aux sources n'est jamais la même d'un mois sur l'autre.

    À noter que quelques entreprises ne fournissent les sources qu'aux clients de l'entreprise, ce qui est généralement autorisé.

    Une variante intéressante du point 2, c'est quand le logiciel change régulièrement de grands pans de son architecture.

    Le code qui fait des suppositions sur l'environnement de développement

    Généralement à base de chemins en dur dans le code ou de réglages spécifiques à un IDE. C'est rare, mais on en croise…

    La ressource libre-mais-déposée

    Ici ça s'applique plus aux ressources qu'au code, principalement aux logos : votre ressource est libre, mais est une marque déposée. Il y a plein de cas où on ne peut pas l'utiliser. Par exemple, le logo GNU n'illustre pas la version d'origine de cet article, parce que, je cite (le gras est d'origine) :

    Ce dessin est utilisable conformément à la GNU FDL v1.3, à la licence Art libre ou à la Creative Commons CC-BY-SA 2.0 (résumé en français ici). Toutefois, c'est aussi un logo déposé du projet GNU. Si vous voulez vous servir de cette tête de GNU pour mettre en lien un site web de la Free Software Foundation ou du projet GNU, n'hésitez pas ; de même, vous n'avez pas besoin de permission supplémentaire pour l'utiliser dans des contextes qui parlent de GNU de manière positive et exacte. Pour tout autre usage, veuillez au préalable demander la permission à licensing@fsf.org.
    Source: La page du logo GNU sur le site de la FSF

    Et donc ce logo est disponible sous 3 licences libres différentes, mais a des restrictions très fortes sur l'usage qui peut en être fait. C'est en fait valable avec à peu près tous les logos et toutes les marques – et les règles d'utilisations de logos et marques d'entreprises peuvent être bien plus restrictives.

    La conclusion de tout ceci ?

    Qu'un logiciel soit libre n'impose pas que son développeur doive vous faciliter l'application des libertés.

    C'est quelque chose qu'on croit trop souvent, de même qu'on mélange souvent « libre » et « gratuit ».

    Ce texte, placé sous licence CC BY 4.0, est une légère adaptation pour LinuxFR.org de l'original disponible sur Zeste de Savoir.

    Commentaires : voir le flux atom ouvrir dans le navigateur

  • L’heure du test — fork 1 — Void (Linux) (Dépêches LinuxFR)

    Voici un tour d’horizon d’une distribution peu connue mais néanmoins intéressante : Void (Linux) !


    Void est une distribution indépendante, créée de zéro (from scratch, pas une divergence de Debian ou autres). Elle est développée par une communauté de volontaires et vous pouvez facilement y contribuer via ses dépôts sur GitHub. C’est une distribution avec mise à jour en continu (rolling‐release), tournée vers les ordinateurs de bureau et qui se veut légère et performante.

    NdM. : Cette dépêche est inspirée par L’heure du test — épisode 1 — NixOS postée par gusterhack. Si vous aussi vous voulez parler de votre distribution ou logiciel libre préféré, n’hésitez pas.

    Sommaire

    La distribution Void

    L’aventure Void Linux a commencé en 2008 lorsque Juan Romero Pardines, un ancien mainteneur de NetBSD voulait tester son gestionnaire de paquets xbps. Depuis, elle a grandi pour avoir tout ce qu’il faut. Le système de base est totalement libre, dépourvu de blobs binaires venus des constructeurs. Les utilisateurs disposent cependant du dépôt non‐free pour installer des bouts de code propriétaires.

    D’un point de vue utilisateur

    Void est une distribution avec mise à jour en continu (rolling‐release), orientée bureau et qui se veut légère et performante. Elle se destine principalement à des utilisateurs de niveau intermédiaire ou avancé et peut être conseillée si vous voulez :

    • avoir des logiciels toujours à jour ;
    • ressusciter une vieille machine ;
    • développer en utilisant plein de bibliothèques récentes ;
    • utiliser une distribution avec une approche moderne (gestion des paquets, système d’initialisation…).

    En revanche, Void n’est pas à conseiller si vous cherchez :

    • une distribution ultra simple à installer et à configurer ;
    • une logithèque ultra fournie ;
    • une distribution ultra stable qui doit tourner sans redémarrage pendant dix ans.

    D’un point de vue technique

    Void est une distribution indépendante, créée « from scratch » (pas une divergence de Debian ou autres). Elle est développée par une communauté de volontaires et vous pouvez facilement y contribuer via ses dépôts sur GitHub.

    Void est disponible pour les architectures x86 et ARM, ainsi que compilé avec glibc (la bibliothèque C de GNU) ou avec musl-libc (une alternative plus légère à glibc).

    Void est une rolling‐release, c’est‐à‐dire que le système et les paquets sont mis à jour en continu ; il n’y a pas de « version » de la distribution. Void utilise son propre gestionnaire de paquets, xbps, qui est très similaire aux classiques apt, dnf, pacman et autres. Il y a un dépôt officiel ainsi qu’un dépôt « non‐free » et il est relativement facile de faire ses propres paquets.

    Enfin, Void utilise par défaut LibreSSL (l’alternative à OpenSSL développée suite à la faille de sécurité Heartbleed) ainsi que le système d’initialisation runit (alternative à systemd).

    Installation et configuration

    L’installation de Void est très classique et bien décrite dans la page Installation du Wiki :

    • on télécharge une image ;
    • on amorce le système sur l’image et l’on arrive sur un shell ;
    • on se connecte en root (mot de passe : « voidlinux ») ;
    • on peut passer le clavier en français avec loadkeys fr et voir la doc avec Alt + F8 ;
    • on lance l’installeur avec void-installer ;
    • on règle les classiques configurations et partitionnement, puis on lance l’installation ;
    • on redémarre sur le système installé et l’on termine la configuration comme décrit dans la page Post‐installation du Wiki.

    Le système d’initialisation runit

    Void utilise runit pour initialiser le système et gérer les services, ce qui en fait l’une des rares distributions actuelles à ne pas utiliser systemd (sans entrer dans le débat pro ou anti systemd). À l’usage basique de tous les jours, runit se révèle vraiment facile et rapide ; voir la doc runit dans le Wiki.

    Activer ou désactiver des services

    Les services disponibles sont dans /etc/sv/. Pour activer un service, il suffit d’ajouter un lien symbolique dans /var/service/. Par exemple, pour activer sshd :

    # ln -s /etc/sv/sshd /var/service/

    Pour désactiver un service, il suffit de supprimer le lien symbolique correspondant, dans /var/service/. Par exemple, pour désactiver sshd :

    # rm -r /var/service/sshd

    Gérer des services

    L’utilitaire sv permet de démarrer (start), d’arrêter (stop) ou d’interroger (status) un service. Par exemple, pour interroger sshd :

    # sv status sshd
run: sshd: (pid 775) 17011s

    Le gestionnaire de paquets xbps

    La gestion des paquets est expliquée en détails dans la page xbps du Wiki. À l’usage, xbps est vraiment rapide (en même temps, ça vaut mieux car le système est en rolling‐release et il y a des mises à jour tous les jours).

    Fonctionnalités de base

    Installer un paquet (par exemple le client IRC hexchat) :

    # xbps-install hexchat

    Chercher un paquet parmi les paquets disponibles dans les dépôts :

    $ xbps-query -Rs hexchat
[*] hexchat-2.12.4_2        A GTK+ based IRC client successor of Xchat
[-] hexchat-lua-2.12.4_2    A GTK+ based IRC client successor of Xchat - lua plugin
[-] hexchat-perl-2.12.4_2   A GTK+ based IRC client successor of Xchat - perl plugin
[-] hexchat-python-2.12.4_2 A GTK+ based IRC client successor of Xchat - python plugin

    Afficher les informations d’un paquet installé :

    $ xbps-query hexchat
architecture: x86_64
build-date: 2017-04-12 08:50 CEST
...
short_desc: A GTK+ based IRC client successor of Xchat
source-revisions: hexchat:66e4fa9536
state: installed

    Mettre à jour le système :

    # xbps-install -Su

    Supprimer un paquet :

    # xbps-remove hexchat

    Supprimer tous les paquets obsolètes :

    # xbps-remove -Oo

    Afficher les autres noyaux disponibles sur la machine :

    $ vkpurge list
4.10.10_1
4.9.11_1

    Supprimer un noyau :

    # vkpurge rm 4.9.11_1

    La politique de paquets de Void

    Malgré quelques manques (notamment KDE 5), la logithèque de Void est assez fournie, au moins 8 000 paquets. Ce nombre peut paraître faible en comparaison des 43 000 paquets proposés par Debian, mais ce n’est pas tout à fait le cas, car Void réutilise les gestionnaires de paquets proposés par les différents langages et outils. Ainsi, là où Debian propose de nombreux paquets pour les bibliothèques Haskell, les packages LaTex et les greffons Vim, Void préfère généralement passer par les gestionnaires respectifs (cabal / stack, tlmgr, vundle), ce qui n’est pas comptabilisé dans les paquets de la distribution.

    Écrire et soumettre des paquets

    Void permet bien entendu de compiler et d’installer des logiciels « à la main ». Cependant, si vous voulez faire une installation propre, vous pouvez créer un paquet et l’installer via le gestionnaire xbps (voir la page xbps-src dans le Wiki). Et si votre paquet fonctionne bien, vous pourrez même facilement le proposer aux mainteneurs de Void pour qu’il soit intégré dans le dépôt officiel.

    Initialisation d’un dépôt de paquets

    Pour créer des paquets Void, le plus simple est de cloner le dépôt officiel de Void, puis d’en diverger en y créant ses paquets.

    Le dépôt de paquets contient un programme xbps-src pour compiler des paquets. Pour pouvoir l’utiliser, il faut d’abord initialiser un environnement de compilation :

    $ ./xbps-src binary-bootstrap

    Créer un paquet

    Imaginons, par exemple, que vous voulez empaqueter le programme GNU-hello. Commencez par créer une branche « hello » dans le dépôt de paquets :

    $ git checkout -b hello

    Initialisez un nouveau paquet hello :

    $ xnew hello

    Ceci crée un fichier srcpkgs/hello/template qui contiendra la description du paquet et les instructions de compilation. Éditez ce fichier pour votre paquet :

    # Template file for 'hello'
pkgname="hello"
version="2.10"
revision=1
build_style=gnu-configure
distfiles="https://ftp.gnu.org/gnu/hello/${pkgname}-${version}.tar.gz"
checksum="31e066137a962676e89f69d1b65382de95a7ef7d914b8cb956f41ea72e0f516b"
short_desc="Produces a familiar, friendly greeting"
homepage="https://www.gnu.org/software/hello/"
license="GPL"

    Vous pouvez déterminer la somme de contrôle avec la commande :

    $ xgensum -f srcpkgs/hello/template

    Une fois le fichier de configuration écrit, lancez la compilation et la création du paquet :

    $ ./xbps-src pkg hello

    Si tout s’est bien passé, vous pouvez alors installer votre paquet sur votre machine :

    # xbps-install --repository=hostdir/binpkgs/hello/ hello

    Soumettre un paquet

    Si votre paquet fonctionne correctement, vous pouvez le proposer à la communauté pour qu’il soit intégré dans les paquets Void officiels. Tout d’abord, comme Void est disponible pour plusieurs architectures et libc, il faut commencer par tester si le paquet peut se compiler correctement sur d’autres architectures, par exemple pour ARM7, avec musl-libc :

    $ ./xbps-src -a armv7l-musl pkg hello

    Créez ensuite un commit décrivant votre contribution et envoyez‐le dans une branche spécifique sur le serveur :

    $ git add srcpkgs/hello/template
$ git commit -am "New package: hello-2.10"
$ git push -u origin hello

    Il ne vous reste plus qu’à vous connecter sur GitHub et à créer une demande d’intégration _— pull request — de votre commit dans le dépôt officiel. Si des modifications vous sont demandées, pensez à travailler toujours sur le même commit et la même branche distante :

    $ git commit -a --amend
$ git push -f

    Conclusion

    Void (Linux) est une distribution peu connue mais dont les choix techniques originaux sont plutôt appréciables à l’usage. Elle est légère, rapide, très à jour et facile à configurer « dans l’esprit UNIX ». En revanche, elle n’est pas destinée à des débutants et n’a pas la logithèque la plus complète qui soit.

    Personnellement, j’utilise Void tous les jours pour des usages classiques de bureautique, Web, multimédia, ainsi que pour développer en C++ et en Python avec toutes sortes de bibliothèques. En un an d’utilisation, je n’ai pas réussi à la casser ni à avoir de conflits majeurs. En deux occasions, la mise à jour du système ne fonctionnait pas, mais à chaque fois il a suffit d’attendre un jour ou deux pour que les mainteneurs corrigent le problème et que les mises à jour fonctionnent à nouveau.

    Lire les commentaires