Planet Libre

System Linux : Calculatrice graphique Open source et Française

calculette.jpg

Cocorico !

Allez on est pas à 80 balles prêt on fait l'effort ! :

https://www.numworks.com/fr/

Gravatar de System Linux
Original post of System Linux.Votez pour ce billet sur Planet Libre.

Articles similaires

Renault : [F28] Participez à la journée de test consacrée au noyau Linux 4.16

Aujourd'hui, ce vendredi 13 avril, est une journée dédiée à un test précis : sur le noyau Linux 4.16. En effet, durant le cycle de développement, l'équipe d'assurance qualité dédie quelques journées autours de certains composants ou nouveautés afin de remonter un maximum de problèmes sur le sujet.

Elle fournit en plus une liste de tests précis à effectuer. Il vous suffit de les suivre, comparer votre résultat au résultat attendu et le notifier.

En quoi consiste ce test ?

Le noyau Linux est le cœur du système Fedora (et des autres distributions GNU/Linux). C'est le composant qui fait le lien entre les logiciels et le matériel. C'est lui qui permet aux processus de travailler ensemble sur un même ordinateur et de pouvoir utiliser les périphériques (à travers des pilotes) disponibles sur chaque machine.

C'est donc un composant critique et il est nécessaire de s'assurer qu'il fonctionne.

Les tests du jour couvrent :

  • L'exécution des tests automatisés par défaut et ceux de performances ;
  • Vérifier que la machine démarre correctement ;
  • Vérifier que le matériel est bien exploité (affichage, claviers, souris, imprimantes, scanners, USB, carte graphique, carte son, webcam, réseau filaire et wifi, etc.)
Comment y participer ?

Vous pouvez vous rendre sur la page des tests pour lister les tests disponibles et rapporter vos résultats. La page wiki récapitule les modalités de la journée.

Si vous avez besoin d'aide lors du déroulement des tests, n'hésitez pas de faire un tour sur IRC pour recevoir un coup de main sur les canaux #fedora-test-day et #fedora-fr (respectivement en anglais et en français) sur le serveur Freenode.

En cas de bogue, il est nécessaire de le rapporter sur le BugZilla. Si vous ne savez pas faire, n'hésitez pas à consulter la documentation correspondante.

De plus, si une journée est dédiée à ces tests, il reste possible de les effectuer quelques jours plus tard sans problème ! Les résultats seront globalement d'actualité.

Gravatar de Renault
Original post of Renault.Votez pour ce billet sur Planet Libre.

Articles similaires

Renault : Du test de Fedora à une contribution pour Yocto / OpenEmbedded

Comme vous le savez certainement, je suis un amateur de Fedora depuis longtemps (merci papa), je prépare des dépêches de sortie depuis Fedora 9, et je teste les versions instables sur ma machine principale depuis Fedora 15. Cela est un moyen efficace de trouver des bogues pour les corriger avant la sortie finale (et ainsi améliorer la qualité pour tout le monde). La rédaction des dépêches permettant de voir l'ensemble des changements opérés à chaque fois en avance.

À l'occasion de la sortie de Fedora 28 Bêta, j'ai voulu préparer le terrain pour ma machine professionnelle pour m'assurer que mon travail serait possible dans cet environnement sans perdre de temps. Si globalement le système tourne bien, restait à s'assurer que mon travail compilerait toujours. Avec des changements de versions pour GLibc et GCC, rien n'est garanti.

Contexte

Pour le compte de mon employeur, le client actuel il y a deux Yocto utilisés (un par projet). L'un est un Yocto Pyro fourni par Toradex pour une plateforme iMX7D, l'autre un Yocto Rocko fourni par Variscite pour une plateforme iMX6. Comme ce sont des versions récentes, la probabilité que le comportement diverge est faible (et en réalité, ce sera le cas, seule un correctif supplémentaire sera nécessaire pour le Yocto Pyro).

Yocto est un système de génération de distribution. Grâce à un système de recettes et de couches, nous pouvons intégrer des logiciels provenant de différentes sources, les configurer et les assembler pour générer différentes images et des paquets. Pour cela, comme pour tout système similaire (comme buildroot), Yocto récupère les sources des compilateurs, des bibliothèques de base, etc. Il compile une chaîne de compilation croisée ce qui permet d'exécuter par exemple un compilateur comme GCC sur mon ordinateur de travail (d'architecture x86_64 Intel) mais dont le résultat sera exploitable sur la carte cible donc des processeurs ARM dans mon cas. Ensuite cette chaîne de compilation servira à générer l'ensemble des paquets et l'image finale pour la carte électronique du projet.

Pour la génération de la chaîne de compilation croisée, Yocto a besoin d'utiliser des outils déjà présents dans ma machine. Typiquement le compilateur GCC de mon architecture. C'est pour cette étape que changer de version de Fedora peut être risqué. Car si GCC change, le comportement pour générer la chaîne de compilation croisée aussi. Exemple : quand GCC active par défaut l'usage de CPP 14 certains programmes ne sont plus compilables en l'état car ils ne respectent pas cette nouvelle version du langage et il faut dans ce cas préciser à GCC de ne pas utiliser le comportement par défaut, ou rendre le programme compilé compatible CPP 14.

Et le soucis avec Fedora 28 ?

Pour minimiser les différences entre les distributions (Ubuntu, Fedora, Debian, etc.), Yocto a introduit par défaut un paquet yocto-uninative qui est un glibc-native précompilé pour la machine hôte (ici mon Fedora x86_64). Cela autorise par exemple à deux distributions de partager le cache de Yocto et que la compilation aboutisse malgré des glibc qui diffèrent. Cela n'est possible que parce que Glibc est globalement rétrocompatible dans les symboles.

Mais avec Fedora 28, le paquet yocto-uninative de Yocto ne fonctionne plus. Il faut compiler glibc-native à la main. Si cela ne constitue pas un frein pour travailler mais c'est une régression importante qu'il convient de corriger avant la sortie officielle de Fedora 28. D'autant que Yocto prépare la sortie de sa nouvelle version sumo et être compatible avec Fedora 28 est un gros plus.

Le problème survient lors de la compilation de bibliothèques Perl, qui se plaignent que le symbole XCRYPT_2.0 de la bibliothèque libcrypt n'existe pas. Et en effet, dans le glibc fournit par yocto-uninative, ce symbole n'existe pas alors qu'il existe dans la version de mon système. En somme, il y a une incompatibilité entre les deux en terme de symboles alors qu'il est nécessaire que cela corresponde pour continuer.

Je regarde dans les changements de Fedora 28 pour comprendre et je retombe sur cette page. Des développeurs de Fedora ont proposé de séparer glibc et libcrypt. Le but est de permettre de faire évoluer ce dernier plus facilement et rapidement. libcrypt serait fournie par le biais du programme libxcrypt. Mais l'équipe de glibc n'a pas encore intégré ce changement, Fedora est ainsi la seule distribution à avoir ce comportement par défaut.

Et c'est là d'où vienne les ennuis, si libxcrypt est rétro-compatible avec l'ancien libcrypt (il fournit les symboles que libcrypt fournissaient), l'inverse n'est pas vrai et on le voit par l'ajout du symbole XCRYPT_2.0.

Travail en amont

Pour corriger cela, il faut agir au niveau de Yocto. Je rejoins donc le canal IRC de #yocto sur Freenode pour expliquer le problème et qu'on élabore une marche à suivre. C'est ainsi que Joshua Watt de Garmin et Richard Purdie d'Intel, deux contributeurs de Yocto ont souhaité m'aider à résoudre ce problème.

Étape 1, générer un yocto-uninative depuis Fedora 28 et l'utiliser localement pour vérifier si cela résout mon soucis. Il faut donc créer la recette pour compiler libxcrypt, puis modifier celui de glibc pour ne pas compiler et de ne pas utiliser son libcrypt interne quand on souhaite générer un SDK. Je dois également corriger Perl (via un correctif déjà existant dans le paquet RPM de Fedora) pour utiliser libxcrypt convenablement avec.

Cela fonctionne bien. Du coup étape 2, j'envoie aux deux développeurs mon yocto-uninative pour qu'ils le testent de leur côté que la compatibilité est bonne sur Ubuntu ou Fedora 27. Cela fonctionne bien aussi.

Étape 3, nettoyer mon travail et l'envoyer en amont pour que tout le monde en bénéficie. Et les prochains yocto-uninative seront compatibles avec Fedora 28. Richard Purdie ira plus loin dans l'utilisation de libxcrypt en utilisant le concept de virtual/crypt. Sachant que ce travail devrait finir par disparaître quand Glibc officiel intégrera le changement de Fedora, normalement cette année.

Et quelques jours plus tard, le travail est publié ici et .

Conclusion

Tout d'abord que le Logiciel Libre est un travail d'équipe, vraiment. Grâce à Joshua et Richard j'ai gagné du temps en recherche d'info, de solution et dans la réalisation des tests. Leur aide a été précieuse. Et eux ont pu bénéficier un retour de Yocto sur Fedora 28 avant sa sortie, permettant de corriger des soucis avant qu'une horde d'utilisateurs ne viennent se plaindre que cela ne fonctionne pas. Et bien entendu les futurs utilisateurs de Fedora 28 et de Yocto pourront se contenter d'utiliser Yocto sans soucis et sans rien faire.

Ensuite, les tests c'est important. En testant les Fedora instables, on découvre des soucis et on peut les résoudre avant que l'utilisateur lambda ne s'en serve. Cela améliore grandement le confort d'utiliser la distribution. Et comme ce changement sera dans glibc officiel, cela permet de préparer le reste du Logiciel Libre à l'arrivée de ce genre de changements majeurs sous le capot.

Pour finir, tester Fedora et écrire les dépêches de sortie me permettent d'être à l'aise avec la distribution au fil du temps. J'ai pu identifier et corriger le soucis plus vite que si je ne maîtrisais pas mon système, car je sais où chercher l'information

Gravatar de Renault
Original post of Renault.Votez pour ce billet sur Planet Libre.

Articles similaires

Thuban : Publication d'isotop 0.3

Qui dit nouvelle version d'OpenBSD dit nouvelle version d'isotop.
Pour les bavards du fond, isotop est une OpenBSD "simplifiée" qui permet d'avoir rapidement un environnement de travail sur un pc de bureau pour découvrir ce système. Autant que possible, les outils de base dans OpenBSD sont utilisés, et sont accompagnés par quelques scripts qui se veulent aussi légers que possible. Une série de programmes courants sont présents, comme par exemple la suite bureautique libreoffice ou encore le navigateur Firefox.
L'objectif d'isotop n'est pas d'être la plus rapide ni proposer les programmes les plus récents. Je souhaite faciliter l'accès à ce système réputé robuste et sûr, ce qui n'est pas une mince affaire de nos jours.

Pour récupérer la dernière version, vous pouvez lire la page de téléchargement ou bien la suite :

Cliquez sur un des magnets suivants :

Ou alors, les copains hébergent les isos sur leurs serveurs :

Outre les améliorations déjà présentes dans OpenBSD 6.3, on pourra entre autres noter les points suivants dans isotop :

  • Xenodm, le gestionnaire de connexion est plus joli.
  • Un outil pour configurer Xenodm est disponible. Il permet de changer le fond d'écran, en définir plusieurs aléatoirements ou bien configurer une connexion automatique pour un utilisateur (⚠️)
  • Une interface simple pour qu'un utilisateur puisse accéder à des privilèges root est intégrée. Ça évite de configurer doas pour chaque application nécessitant ces droits. On peut voir ça comme un "gksu" simplifié, qui ne retire rien à doas.
  • La possibilité de traduire l'interface est présente. Pour l'instant, c'est le français et l'anglais seulement, selon l'agencement du clavier définit à l'installation.
  • Les médias insérés sont automatiquement montés dans /vol. Un raccourci dans le dossier utilisateur est présent pour y faciliter l'accès.
  • Un peu moins de programmes sont présents par défaut, ça allège les images.
  • L'apparence est plus sobre, libre à chacun de personnaliser le thème à son goût.
  • Si un utilisateur décide d'envoyer aux développeurs d'OpenBSD son "dmesg" (ça aide à améliorer le support matériel), un message de confirmation lui est affiché.
  • Unbound est toujours présent pour se charger des résolutions DNS en local, le FAI n'a pas à savoir ces choses-là.
  • Ffom est intégré pour trouver un miroir rapide.
  • De nouveaux fonds d'écran (merci péhä!)

J'aurais souhaité proposer une installation automatisée. À vrai dire, ce n'est pas si compliqué à mettre en place. J'ai toutefois dû revoir ma copie, puisque cela imposait des choix par défaut à l'utilisateur qui peuvent s'avérer aussi perturbants voire plus que l'installateur normal. Normalement, tout le monde est capable de lire les quelques instructions pour l'installation, à savoir :

  • Laisser au moins de 4G pour les programmes installés avec isotop (je compte large) ;
  • Bien installer le set site63.tgz lors de l'installation.

Par ailleurs, c'est Firefox ESR 52 qui est installé par défaut, simplement pour assurer un support convenable dans le temps au cas où on installerait isotop dans 3 mois. Rien ne vous empêche d'installer la version 59 avec pkg_add.

Bref, j'espère que ça vous donnera envie de découvrir OpenBSD et que les petits ajouts vous feront plaisir :)

Gravatar de Thuban
Original post of Thuban.Votez pour ce billet sur Planet Libre.

Articles similaires

Renault : [F28] Participez à la journée de test consacrée à la version Atomic / Cloud

Aujourd'hui, ce mercredi 11 avril, est une journée dédiée à un test précis : sur l'image Atomic / Cloud de Fedora. En effet, durant le cycle de développement, l'équipe d'assurance qualité dédie quelques journées autours de certains composants ou nouveautés afin de remonter un maximum de problèmes sur le sujet.

Elle fournit en plus une liste de tests précis à effectuer. Il vous suffit de les suivre, comparer votre résultat au résultat attendu et le notifier.

En quoi consiste ce test ?

La version Cloud de Fedora est un des trois produits officiels du projet avec Workstation et Server. Son but est d'être une image très minimale pour être instanciée de nombreuses fois dans le cadre d'un infrastructure Cloud afin de remplir le rôle d'un service. Cependant, contrairement aux deux autres produits, la version Cloud est mise à jour très régulièrement (de nouvelles images sont disponibles toutes les quelques semaines seulement, contre 6-7 mois en moyenne pour les autres).

Une nouveauté qui commence à s'installer est la mise à disposition de Fedora Workstation Atomic. Jusque là, seule l'image Cloud bénéficiait de ce système. Ce travail provient du projet Atomic qui repose lui même sur rpm-ostree dont l'un des buts est de versionner le système pour améliorer la fiabilité du système en cas d'installation ou de mise à jour d'un programme en autorisant un retour en arrière très simplement et avec des opérations qui sont atomiques (d'où le nom). Il est également aisé de voir ce qui a changé dans le système, notamment si l'utilisateur a changé des fichiers de configuration importants et ce qu'il a appliqué. Le système est également plus orienté utilisation d'applications dans un conteneur (comme les Flatpak) et les répertoires systèmes sont mieux isolés, par exemple /usr est par défaut en lecture seule.

Les tests du jour couvrent :

  • Est-ce que l'image démarre correctement, permet de se connecter et si les services se base se lancent bien et que SELinux remplit son rôle ;
  • Vérifier si la gestion de Docker ou Atomic (installation, mise à jour, retour en arrière) fonctionne correctement ;
  • Lancement des applications ;
  • Vérifier la compatibilité avec le cloud Amazon et OpenStack ;
  • S'assurer que l'image Atomic Workstation fonctionne avec ses spécificités : installation du système, Flatpak et GNOME Logiciels pour les notifications et installer des programmes.

Si vous êtes intéressés par l'aspect Cloud de cette image ou par l'ajout d'Atomic dans Fedora Workstation, je vous invite à les tester, elles bénéficient en effet de relativement peu de retours pour le moment. La moindre aide est appréciée, merci.

Comment y participer ?

Vous pouvez vous rendre sur la page des tests pour lister les tests disponibles et rapporter vos résultats. La page wiki récapitule les modalités de la journée.

Si vous avez besoin d'aide lors du déroulement des tests, n'hésitez pas de faire un tour sur IRC pour recevoir un coup de main sur les canaux #fedora-test-days et #fedora-fr (respectivement en anglais et en français) sur le serveur Freenode.

En cas de bogue, il est nécessaire de le rapporter sur le BugZilla. Si vous ne savez pas faire, n'hésitez pas à consulter la documentation correspondante.

De plus, si une journée est dédiée à ces tests, il reste possible de les effectuer quelques jours plus tard sans problème ! Les résultats seront globalement d'actualité.

Gravatar de Renault
Original post of Renault.Votez pour ce billet sur Planet Libre.

Articles similaires

Littlewing : Intégration et médiation avec Apache Camel

Depuis quelques jours, je teste Apache Camel pour la mise en œuvre  de médiations.

Apache-camel-logo

Apache Camel est un framework assez ancien. Il est similaire à Spring Intégration et permet l’ implémentation de patterns d’intégration.

Les patterns d’intégration

Qu’est-ce qu’un pattern d’intégration allez-vous me dire ? C’est une solution d’architecture ou plus simplement une recette de cuisine permettant d’avoir une solution toute prête à une problématique d’intégration donnée. L’ensemble de ces patterns est décrit sur ce site ( ne vous attardez pas sur le look des années 90 … ).

Exemple :

PublishSubscribeSolution

 

Camel permet simplement de gérer l’intégration via un DSL.

Choix d’implémentations

On peut faire pas mal de choses avec ce FRAMEWORK et de plusieurs manières. J’ai fait les choix d’implémentation suivants :

  • Tout se fera avec SPRING … et pas en XML 🙂
  • Il faut que toutes les médiations soient testables
  • J’exécute le code dans un FATJAR ( pourquoi avec springboot )
Configuration de la route

Apache Camel définit les médiations dans des routes. Elles se définissent assez rapidement .

Les routes commencent par une instruction from et se terminent par une ou plusieurs instructions to.

Pour mon exemple, j’extrais les données d’une table et les stocke dans un fichier.

Tout se configure par des URLs. La première permet d’extraire les données via JPA/HIBERNATE. Une entité Address permet le requêtage. La seconde permet le stockage dans un fichier texte JSON.

Elles sont externalisées dans des fichiers de configuration pour faciliter les tests et accessibles via SPRING.

Lancement de la route

Le lancement de la route se fait dans une méthode main() :

Tests

Camel fournit une API de test assez bien fournie. Elle permet notamment de mocker des endpoints existants (ex. : le fichier de sortie de mon cas de test).

Dans mon cas, j’ai décidé de remplacer la base de données que j’interroge en input par une base HSQLDB chargée en mémoire. Le fichier de sortie est, lui, remplacé dynamiquement par un mock. Pour ce faire, j’ai utilisé les « adviceWith »

Pour aller plus loin

Il y a pas mal d’exemples sur le GITHUB de CAMEL. Vous pouvez également acheter le livre « Camel In Action ». Ca ne vaut pas Effective Java 🙂 , mais vu qu’il est écrit par le principal développeur, c’est une très bonne référence.

 

 

Gravatar de Littlewing
Original post of Littlewing.Votez pour ce billet sur Planet Libre.

Articles similaires

blog-libre : Comment suivre les mises à jour de vos logiciels libres

Je fais de la veille depuis un moment mais je me suis fait la réflexion il y a seulement un mois que je devais suivre les mises à jour des logiciels/outils que j’utilise. Quelques raisons à cela :

  • Suivre l’actualité, surveiller le développement et les nouveautés des logiciels/outils qu’on utilise est sage et fort utile
  • Pour un sysadmin/architecte/dev, ça permet d’avoir une bonne visibilité des dernières solutions/features dans le domaine et de garder un œil sur les bugs résolus
  • Intéressant de voir ce « panaché » de différents projets, comment ils travaillent (cycle de dev, release notes, communication, outils utilisés…), comment ça évolue
  • Mieux comprendre mes outils, leur fonctionnement, leurs limites et bugs. J’aime beaucoup lire les news Coreutils notamment
  • Accessoirement ça peut aider à la prise de décision pour choisir un logiciel. En environnement professionnel un projet avec des commits fréquents, une communauté active peut faire la différence par exemple
RSS comme d’hab

J’ai voulu réutiliser l’outil principal me servant pour ma veille, le lecteur RSS. J’utilise FreshRSS (le meilleur !), il propose les avantages suivants :

  • Il permet de créer une catégorie où on rangera spécifiquement certains flux RSS, j’ai créé la catégorie Releases
  • Il permet lors de l’ajout du flux RSS de spécifier où envoyer le flux RSS (dans quelle catégorie), si on veut l’afficher dans le flux principal ou seulement dans une catégorie précise (Visibilité > Afficher dans sa catégorie) et de choisir la période de rafraîchissement (Ne pas automatiquement rafraîchir plus souvent que 12h pour ma part)
  • Lorsqu’on veut ajouter un flux RSS, il va chercher le flux sur le site. Et c’est très utile vu que la plupart des projets se foutent complètement d’indiquer l’adresse du flux RSS. Par exemple je lui donne https://secure.php.net/releases/, il me propose comme flux RSS https://secure.php.net/releases/feed.php
Bazar comme d’hab

J’ai commencé à lister tous les outils que je voulais suivre, ceux que j’utilise en tant qu’utilisateur (BorgBackup, Raspbian, Termux, Coreutils…), ceux sur lesquels je bosse (MariaDB, PHP, systemd, rsyslog…). Ensuite je me suis penché sur chaque projet, je m’attendais à quelque chose de plus carré et simple… c’est le bazar et pas du tout la cathédrale.

Voici ma liste par ordre alphabétique, je vais attendre un peu (work in progress) et j’en ferai un Mémo. Le premier lien concerne la page releases, le second lien le flux RSS, le troisième (quand il y a besoin) le changelog (news, release notes).

Ansible RSS Changelog
BorgBackup RSS Changelog
Chrony ML
Coreutils RSS
dnsdist RSS Changelog
Elixir RSS Changelog
Etcher RSS Changelog
FreshRSS RSS
Glances RSS
Guake RSS
HAProxy Changelog
MariaDB RSS Changelog
ncdu RSS
Nix RSS
Node.js RSS
peco RSS
PHP RSS
Python RSS
ranger RSS Changelog
Raspbian
rsyslog RSS Changelog
Ruby RSS
scrcpy RSS
Shaarli RSS Changelog
Signal RSS
Syncthing RSS
systemd RSS Changelog
Terminator RSS
Termux RSS
Tilix RSS

Ce que j’ai appris et compris

Le lecteur voit le résultat final qu’on lui présente élégamment dans un article, vous verrez difficilement certains points. Voici ce que j’ai appris et compris :

  • Il m’a fallu plus de 3h pour 30 projets entre lister mes outils, ah j’ai oublié celui-là, il est où le flux RSS, bordel le changelog !
  • Les 2/3 des projets sont sur GitHub… l’occasion de se remémorer l’article de Carl : Le danger GitHub
  • Pour ceux qui ne le savent pas, sur GitHub il suffit en général d’ajouter .atom à la fin de l’URL pour avoir le flux RSS. Ainsi https://github.com/peco/peco/releases devient https://github.com/peco/peco/releases.atom
  • Beaucoup de projets publient la release sur GitHub mais ne mettent aucune information. Par exemple rsyslog v8.34.0 (il faut cliquer pour comprendre) : v8.34.0. Dit autrement suivre certains flux RSS ne vous apportera aucune information sauf une date de sortie… il vous faudra systématiquement aller sur la page Changelog. C’est bien pour ça que je les ai donné
  • On pourrait croire que les projets plus importants sont mieux lotis ou plus carré, pas du tout ! Pour moi une référence c’est le changelog de Shaarli : 1/ Changelog versionné, nommé CHANGELOG.md bien voyant et à la racine du projet sur GitHub 2/ Une URL qui ne change pas ! https://github.com/shaarli/Shaarli/blob/master/CHANGELOG.md contrairement à https://github.com/borgbackup/borg/blob/1.1.5/docs/changes.rst#changelog avec le numéro de version dedans, ce qui veut dire que ça va changer 3/ Où on renseigne comment est pensé le changelog : The format is based on Keep a Changelog and this project adheres to Semantic Versioning
  • A comparer avec Raspbian par exemple, je n’ai pas trouvé de flux RSS… raspbian.org existe mais le changelog est chez raspberrypi.org…
  • Citons aussi dnsdist, un sous-projet de PowerDNS. Les releases de PowerDNS et dnsdist sont mises ensemble… donc mélangées : https://github.com/PowerDNS/pdns/releases
  • Parfois pas le choix, il faut passer par une mailing list : https://chrony.tuxfamily.org/lists.html https://www.mail-archive.com/haproxy@formilux.org/msg28004.html (on peut se brancher en RSS dessus mais il faudra filtrer sur ANNOUNCE)
  • Pour vous rendre compte de la difficulté et du bazar pour trouver les bonnes URL : http://feeds.feedburner.com/PythonInsider https://dev.yorhel.nl/ncdu/changes https://savannah.gnu.org/news/atom.php?group=coreutils https://github.com/systemd/systemd/blob/master/NEWS https://www.haproxy.org/download/1.8/src/CHANGELOG https://elixir-lang.org/blog/categories.html#Releases
Cheminement

Souvent les informations récoltées via flux RSS sont insuffisantes, il faut alors aller chercher le changelog qui peut être difficile à retrouver…

Pour ma part je garde un fichier nommé releases sous la main où j’ai répertorié les URL des projets. Concrètement le cheminement donne 1/ Je suis averti de la nouvelle version du logiciel par flux RSS 2/ Je consulte le changelog ou 3/ J’ouvre mon fichier releases, je clique sur le lien du changelog. C’est une solution peu satisfaisante et perfectible. Comment vous faites de votre côté ? Une meilleure solution ? Partagez !

En conclusion

Il reste encore beaucoup de chemin à parcourir aussi bien côté projets pour qu’ils informent correctement et de manière simple que côté utilisateurs cherchant « juste » à s’informer. Chaque projet gère sa barque comme il l’entend, il faut gérer les priorités et faire avec les moyens du bord mais communiquer, améliorer ou juste fournir un changelog et un flux RSS corrects ne devrait pas être négligé.

Les modèles du genre sont Python, MariaDB, Shaarli. Développeurs au boulot ;)

Gravatar de blog-libre
Original post of blog-libre.Votez pour ce billet sur Planet Libre.

Articles similaires

genma : Coffre-fort de mot de passe : état des lieux

Pour (re)définir ce que j'entends par Coffre-fort de mot de passe, je dirai ceci : "Dans le guide d'hygiène numérique, j'évoque le fait qu'il faut avoir un mot de passe différent généré aléatoirement par site, le tout stocké dans un logiciel dédié, un coffre-fort de mot de passe, qui s'ouvre avec une phrase de passe"

J'ai écrit différents articles de sensibilisation et de partage sur les mots de passe et les coffres-forts de mot de passe et je vous mets la série de lien ci-dessous :
-Les phrases de passe
-Changement de mot de passe et testament numérique
-Keepass au quotidien c'est possible
-A.I.2 - Porte blindée ou coffre-fort ?
Et d'une façon générale, Les billets tagués Keepass

Il existe des solutions de service en ligne qui ont l'avantage de proposer une synchronisation (via Internet) entre différents appareils (ordinateur, smartphone, tablette), mais dont le code source n'est pas accessible. Les experts en sécurité des podcasts que j'écoute (Le Comptoir Sécu pour ne pas le nommer) utilise et vante ce type de solution. Personnellement, adepte du logiciel libre, j'ai fait depuis un moment le choix de Keepass. Il faut un petit temps d'adaptation, car un gestionnaire de mot de passe (l'autre nom pour coffre-fort de mot de passe) demande un petit temps d'appropriation. Avec le temps, le réflexe est là : toute nouvelle inscription sur un site passe par la création d'une fiche dans Keepass, la création d'un mot de passe aléatoire utilisé uniquement pour le site en question.

Quelle solution pour une synchronisation ?

Différents billets de blogs et messages dans des forums proposent une même solution, à savoir :
- KeepassX (dans mon cas je suis passé à KeepassXC) ;
- Synchronisation du fichier de base de données via Nextcloud ;
- Application Keeweb intégrée à Nextcloud pour avoir un accès web ;
- Application Keepass2Android et synchronisation Webdav ou via l'application Nextcloud pour un usage mobile.

Quid des sauvegardes ?

Le fait d'avoir un coffre-fort de mot de passe synchronisé entre plusieurs appareils ne fait pas que l'on en a une sauvegarde. Car si on modifie / supprime un des mots de passe du coffre-fort, avec la synchronisation, la suppression est copié dans toutes les versions et on perd définitivement le mot de passe. Les recommandations liées aux sauvegardes s'applique donc là aussi : on copiera régulièrement le fichier du coffre-fort numérique sur un espace de confiance (par exemple un disque externe sur lequel on fait ses sauvegardes, disque que l'on conserve soigneusement).

Quid de la sécurité ?

La sécurité de Keepass tient essentiellement à la qualité et la complexité (la longueur) de la phrase de passe (il faut également penser à mettre à jour le logiciel).

La synchronisation via Nextcloud pose le soucis de la sécurisation de Nexcloud en lui-même (il faut maintenir le serveur à jour et de façon sécurisé et de préférence déléguer cette partie à un administrateur système de confiance, comme au sein des CHATONS par exemple).

Dans le cas de la synchronisation par un client Nexcloud sur son téléphone, on a donc une copie de son coffre-fort numérique sur son téléphone. Tout comme avec son ordinateur (rappel les smartphones ne sont rien d'autres que des ordinateurs au format poche), il faut donc protéger son appareil avec un code, nécessaire au déverrouillage. Et activer le chiffrement du disque.

Autre solution (complémentaire) : avoir deux conteneurs Keepass. Un avec les mots de passe usuels que l'on peut utiliser sur un smartphone et un avec les mots de passe critique qu'on n'utilisera que sur des appareils de confiance, qui risquent peu (il y a toujours un risque, quelque soit l'appareil, mais il est plus facile de voler un smartphone - ou de le perdre) qu'un ordinateur de type tour qui ne bouge pas de son bureau.

Gravatar de genma
Original post of genma.Votez pour ce billet sur Planet Libre.

Renault : [F28] Participez à la journée de test consacrée à la modularité

Aujourd'hui, ce mardi 10 avril est une journée dédiée à un test précis : sur la modularité. En effet, durant le cycle de développement, l'équipe d'assurance qualité dédie quelques journées autours de certains composants ou nouveautés afin de remonter un maximum de problèmes sur le sujet.

Elle fournit en plus une liste de tests précis à effectuer. Il vous suffit de les suivre, comparer votre résultat au résultat attendu et le notifier.

En quoi consiste ce test ?

La modularité est le résultat de la réflexion de Fedora.next, amorcé en 2014. L'objectif est de découpler le cycle de vie des applications avec celui de Fedora afin qu'un utilisateur de Fedora bénéficie de plus de flexibilité. Il serait par exemple possible de choisir une version native de Python plus récente ou plus ancienne que celle disponible par défaut. Auparavant cela n'était possible qu'en choisissant une autre version de Fedora ce qui pouvait être contraignant.

Les modules se comportent comme des dépôts supplémentaires proposant un ensemble de paquets destinés à remplacer ceux des dépôts officiels. Mais bien entendu, tout cela est géré par le projet Fedora avec la même qualité et les mêmes mainteneurs.

Pour le moment Fedora propose quelques modules : Docker, Django, NodeJS et le langage Go.

Les tests du jour couvrent :

  • Lister les modules disponibles et installés ;
  • Installer un nouveau module ;
  • Activer un nouveau module.

Comme vous pouvez le constater, ces tests sont assez simples et ne devraient prendre que quelques minutes seulement.

Il vous faudra bien évidemment installer le dépôt modular avant (paquet fedora-repos-modular).

Comment y participer ?

Vous pouvez vous rendre sur la page des tests pour lister les tests disponibles et rapporter vos résultats. La page wiki récapitule les modalités de la journée.

Si vous avez besoin d'aide lors du déroulement des tests, n'hésitez pas de faire un tour sur IRC pour recevoir un coup de main sur les canaux #fedora-test-days et #fedora-fr (respectivement en anglais et en français) sur le serveur Freenode.

En cas de bogue, il est nécessaire de le rapporter sur le BugZilla. Si vous ne savez pas faire, n'hésitez pas à consulter la documentation correspondante.

De plus, si une journée est dédiée à ces tests, il reste possible de les effectuer quelques jours plus tard sans problème ! Les résultats seront globalement d'actualité.

Gravatar de Renault
Original post of Renault.Votez pour ce billet sur Planet Libre.

Articles similaires

alterlibriste : Et si Linux devenait une option comme une autre ?

Tous les ans, on nous fait le coup de l’année du desktop Linux, à tel point que cela en devient un running gag et que plus personne n’y croit, d’autant que la fin du support de XP et le passage forcé à Windows 10 n’ont pas changé grand-chose aux stats, et pourtant…

Ma fréquentation régulière du monde du podcast (dont pâtit quelque peu ce blog), qui n’est pas particulièrement libriste mais relativement versé dans la technologie et l’attiré pour la nouveauté me semble révéler un mouvement de fond : Linux devient une alternative crédible.

Certes, cela fait des années que nous répétons qu’il est désormais plus facile d’installer une distribution généraliste qu’un Windows, qu’il est révolu le temps de compiler ses drivers et qu’un Desktop bien peaufiné n’a rien à envier à iOS, mais comme nous crions entre nous, le temps de diffusion semble bien long.

Tous les gens qui touchent un peu à la technique, à la domotique, aux serveurs ou aiment bidouiller, ont désormais eu l’occasion de se frotter à une distribution et le Raspberry pi fait bien sûr parti de ce mouvement. Alors, les habitudes sont parfois un peu dures à changer et les lignes de commandes continuent à faire peur, mais une fois qu’on a goûté à un système qui marche et que l’on peut configurer comme on le souhaite, on apprécie et on le fait savoir.

Dans la cinquantaine de podcasts non libriste que j’écoute, je compte pas loin d’une dizaine de passages à Linux qui sont évoqués depuis un an. Et pas pour des raisons idéologiques. L’essai ne sera peut-être pas totalement concluant ou ne restera cantonné qu’à une vieille machine pour les enfants, mais peu importe, d’autres que les libristes en parlent comme d’une option aussi valable qu’un autre OS. Sans oublier le nombre croissant d’articles dans la presse informatique généraliste.

Parmi les arguments évoqués par les nouveaux convertis : le ras le bol des mises à jour inopinées, les bugs sur certains matériels, les régressions… et la joie de trouver un tout nouveau système totalement fonctionnel. Cette description en titille de plus en plus qui entrevoient alors la possibilité d’essayer.

Énième effet de mode ? Je ne me fais pas d’illusions, parmi ces essais, il y a une certaine proportion qui n’hésite pas à changer de système comme de chemise et repasseront sous OS propriétaire, car seul l’attrait de la nouveauté les y aura fait goûter. Néanmoins le système sort des fourrés dans une sphère plus grand public.
2018 ne sera probablement toujours pas l’année du desktop Linux, mais peut-être sera-t-elle celle où Linux devient une option non idéologique ?

Gravatar de alterlibriste
Original post of alterlibriste.Votez pour ce billet sur Planet Libre.

Journal du hacker : Liens intéressants Journal du hacker semaine #14

Pour la 14ème semaine de l'année 2018, voici 10 liens intéressants que vous avez peut-être ratés, relayés par le Journal du hacker, votre source d’informations pour le Logiciel Libre francophone !

Pour ne plus rater aucun article de la communauté francophone, voici :

De plus le site web du Journal du hacker est « adaptatif (responsive) ». N’hésitez pas à le consulter depuis votre smartphone ou votre tablette !

Le Journal du hacker fonctionne de manière collaborative, grâce à la participation de ses membres. Rejoignez-nous pour proposer vos contenus à partager avec la communauté du Logiciel Libre francophone et faire connaître vos projets !

Et vous ? Qu’avez-vous pensé de ces articles ? N’hésitez pas à réagir directement dans les commentaires de l’article sur le Journal du hacker ou bien dans les commentaires de ce billet :)

Gravatar de Journal du hacker
Original post of Journal du hacker.Votez pour ce billet sur Planet Libre.

Articles similaires

Marty : KooZic: sortie de la v0.8.0, dernière release...

... utilisant Python 2. Les derniers mois ont été assez calmes au niveau de KooZic, logiciel de streaming musical. Le développement ne s'est pas arrêté pour autant, que du contraire. Plusieurs fonctionnalités ont été développées. Entre autres, le support de la normalisation audio, du non-transcodage et d'un convertisseur.

Normalisation audio

Lorsqu'une liste de lecture est parcourue, il nous est tous arrivé au moins une fois de passer d'un titre à un autre et de percevoir une nette différence de volume. Ceci s'explique simplement par le fait que qu'un fichier audio possède un certain niveau de volume, qui peut être différent de l'un à l'autre. Évidemment, lors de l'écoute d'un album complet, ceci n'arrive pas, vu que le volume de l'album est cohérent d'un morceau à l'autre. Mais lorsque les titres proviennent d'origines différentes, le volume peut fortement varier.

De nombreux lecteurs audio permettent de normaliser le volume des titres grâce à la méthode ReplayGain. Plus récemment, l'industrie de diffusion a opté pour une nouvelle méthode de normalisation, la bien nommée EBU R128 (European Broadcasting Union Recommendation R128). Depuis la version 3.2.1, FFMpeg supporte nativement cette méthode de normalisation. Cool, hein ?

Avec la v0.8.0 de KooZic, il est donc à présent possible de paramétrer une liste de lecture pour que la normalisation sus-nommée soit appliquée à tous les titres. Pour que cela fonctionne, il sera évidemment nécessaire de disposer de FFMpeg >= 3.2.1. Notez qu'un binaire est maintenant distribué avec le package KooZic. Il suffit de le copier dans "/usr/local/bin", et le tour est joué.

Une information importante à avoir en tête : la normalisation est un processus gourmand en ressources et augmente de manière non négligeable la durée de conversion. À voir donc si votre serveur peut tenir cette charge supplémentaire.

Et si on ne convertissait plus du tout ?

L'option exactement opposée a été introduite dans cette nouvelle mouture. Et si on profitait des capacités de nos navigateurs modernes pour lire les fichiers audio sans aucun traitement ?

Il est possible de paramétrer une liste de lecture pour contourner complètement l'utilisation de FFMpeg, et simplement lire le fichier tel qu'on le possède. Cela permet de décharger fortement le serveur, au prix d'une augmentation du trafic réseau.

Il est à noter que les résultats diffèrent d'un navigateur à l'autre, selon le format. Selon votre configuration, cela peut s'avérer une option très utile.

Un outil de conversion, mais pour quoi faire ?

Parce que j'en avais besoin. Il existe une myriade d'outils pour convertir un fichier audio d'un format vers un autre. La plupart font ça très bien. Mais, à ma connaissance, aucun ne permet de facilement importer une liste de lecture et de la convertir, en respectant la hiérarchie des fichiers. KooZic est capable de le faire.

À l'image des listes de lecture, on peut facilement créer une liste de fichiers à convertir. Il est également possible d'importer une liste de lecture existante. On choisit le mode de conversion, la qualité, le répertoire de sortie (par défaut dans "/tmp/koozic/"), et on démarre. La conversion démarre de manière asynchrone après moins de 2 minutes. Rien de très sexy, il faut rafraîchir la page pour voir l'avancement. Mais ça fonctionne, et c'est efficace.

Autres Nouveautés

Dans les nouveautés perceptibles, on notera le pré-chargement de la piste suivante lors de la lecture. 30 secondes avant la fin d'une piste, KooZic va charger la piste suivante. Cela permet de diminuer de manière conséquente le gap entre 2 pistes, et se rapprocher d'une configuration "gapless".

Comme annoncé plus haut, cette version est la dernière version utilisant Python 2 (Odoo v10). La prochaine version utilisera Python 3 (Odoo v11).

Mise-à-jour d'une installation existante

La nouvelle version est disponible sur le site du projet. Pas de crainte à avoir, les sources précédentes peuvent être supprimées. On extrait la nouvelle version, et on lance la mise-à-jour à partir du répertoire:

./odoo-bin -u oomusic,oovideo -d koozic --stop-after-init

On peut relancer ensuite avec la commande habituelle.

Gravatar de Marty
Original post of Marty.Votez pour ce billet sur Planet Libre.

Marthym : Maven Release Plugin

Carrément, deux billets dans la même semaine, c’est rare. Bon rien de foufou, j’ai passé un peu de temps la semaine passé à automatiser le processus de release dans ma boite. J’avais déjà essayé d’utiliser le Maven Release Plugin mais j’ai jamais eu de succés.

Cette fois j’ai quand même été un peu plus loin alors j’écris trois mots sur le sujet, en français, si ça intéresse des gens.

Introduction

L’idée est de pouvoir versionner un composant sans autre intervention humaine que le choix des numéros de version (release et next snapshot).

Le POM.xml Configuration des plugin

Déjà la première chose est de configurer les différents plugins de release.

org.apache.maven.plugins maven-release-plugin 2.5.3 org.codehaus.mojo versions-maven-plugin 2.5 org.apache.maven.plugins maven-javadoc-plugin 3.0.0 true Maven Release Plugin

Le Maven Release Plugin est le plugin qui va faire le gros du travail, Mettre à jour le pom avec les bons numéros de version, faire les commit et poser les tags.

Versions Maven Plugin

Le Versions Maven Plugin va permettre de mettre à jour les dépendances SNAPSHOT avant la release.

Maven Javadoc Plugin

Le Maven Javadoc Plugin C’est le plugin chargé de générer la JavaDoc, il est utilisé par le Maven Release Plugin. Dans mon cas, la Javadoc est pas super valide. Pour éviter de faire planter la release, on désactive la JavaDoc.

Source Code Management

J’ai mis un peu de temps à trouver la configuration qui va bien pour que ça fonctionne.

scm:git:git://github.com/Marthym/hello-osgi-world.git scm:git:git@github.com:Marthym/hello-osgi-world.git https://github.com/Marthym/hello-osgi-world Fichier properties & choix des versions

Pour pouvoir fonctionner en mode silencieux, l’étape de préparation de la release a besoin d’un fichier de configuration, à placer à la racine du projet, contenant les numéros de versions des artefacts du projet, pour la release et pour la prochaine SNAPSHOT.

Le fichier a cette forme :

scm.tag=1.5.0 project.rel.fr.ght1pc9kc\\:hello-osgi-world=1.5.0 project.dev.fr.ght1pc9kc\\:hello-osgi-world=1.6.0-SNAPSHOT scm.commentPrefix=rel(main):

On peut aussi lui préciser le préfixe de commit, par défaut [maven-release-plugin], perso, j’aime bien l’AngularJS Commit Convention, rel(main):.

Les commandes Résolutions de dépendences SNAPSHOT mvn versions:use-releases -DprocessParent=true -DfailIfNotReplaced=true

Le principe du plugin consiste en la suppression des chaînes -SNAPSHOT dans le fichier mais le plugin vérifie quand même que la version existe bien et ait bien été releasé. Si ce n’est pas le cas, il plante.

Deux paramètres :

  • processParent: Précise qu’il faut traiter aussi le bloc parent
  • failIfNotReplaced: Demande au plugin de sortir en erreur si une version d’une dépendance n’existe pas
Release mvn release:prepare -DtagNameFormat="@{version}" release:perform

En fait le plugin agit en deux étapes qui peuvent être exécuté en une ligne.

  • prepare:
    • Rassemble les informations
    • Joue les test
    • Pose les tags
    • Modifie les poms avec les bonnes versions
  • perform:
    • Compile le code sous le tag
    • Pousse le jar sur le Nexus

Attention, il est nécessaire de push les modifs

git push && git push --tags

Maven Release Plugin écrit à l'origine par Marthym pour J’ai acheté un PC neuf cassé ... le April 06, 2018.

Gravatar de Marthym
Original post of Marthym.Votez pour ce billet sur Planet Libre.

genma : Chatonkademy - Billet N°0 - Présentation du projet

Dans le cadre du projet d'une école du numérique auquel je participe, l'OpenHackademy, nous (des membres d'une de mes équipes et moi-même) avons été amené à mettre en place l'infrastructure informatique qui sert aux apprenants dans le cadre de leur formation.

Au fur et à mesure, nous documentons tout ça en interne. Comme je me dis que l'expérience peut être utile à d'autres, je débute par le présent billet une une série de billets techniques relatant tout ce que nous avons pu apprendre dans la mise en place de cette infrastructure et son maintien au quotidien, son évolution...

Ce retour d'expérience se basera également sur l'expérience d'autres CHATONS avec lesquels j'ai pu échangé et discuté, venant ainsi compléter si besoin mes propos, proposer d'autres solutions logicielles que celle que j'ai pu mettre en place si il y a lieu, justifiant ainsi les choix techniques réalisés.

Présentation du projet

Pourquoi Chatonkademy ? Ce petit nom n'est autre que la contraction de CHATON et OpenHackademy. Pour l'OpenHackademy je vous renvoie vers >mon billet de blog dédié sur le sujet. Pour les CHATONS, le Collectif des Hébergeurs Alternatifs,Transparents, Ouverts, Neutres et Solidaires, vers le site du projet : https://chatons.org

En quelques mots, CHATONS ce sont les AMAP de l'informatique libre. Promouvant le projet au travers mon implication au sein de l'association Framasoft.

L'infrastructure

L'infrastructure repose sur un hyperviseur tournant sous Proxmox avec une IP fixe (en IPv4) et une IPv6, les différentes problématiques liées à l'usage d'une seule IP publique avec des ports particuliers (web, ssh etc.) seront abordés dans des billets dédiés.

Les machines virtuelles

Chaque étudiant a sa propre machine virtuelle pour son apprentissage. Les machines virtuelles sont gérées par les étudiants qui ont les droits administrateurs sur les machines (via un compte sudoers). Nous avons déployés ces machines sous Debian 9 et nous les avons "ansibelisées" : les playbooks etc. seront mis à disposition dans des billets dédiés. L'intervention sur plusieurs machines à distance en même temps (pour saisir la même commande), la gestion des logs centralisés pour ces différentes machines, leurs sauvegardes etc. Toutes ces problématiques donneront lieu, là encore, droit à des billets dédiés.

Yunohost

Ayant sensibilisé les apprenants au projets aux problématiques tel Le cloud, c'est l'ordinateur d'un autre et à celui de faire de la veille, (voir à ce sujet mon billet Le combo gagnant pour optimiser sa veille), j'ai mis en place une instance Yunohost multi-utilisateurs. Je suis administrateur de l'instance, chaque étudiant a son compte sur Yunohost et les applications que je lui mets à disposition.

Je ferai un ou plusieurs billets dédiés sur la gestion de Yunohost dans le cadre d'un certain nombre d'utilisateurs (40), le côté mono ou multi-utilisateur des applications (partagée publiquement ou non, cloisonnée pour chaque utilisateur ou non). Cette expérience sera également l'occasion de passer d'une instance Yunohost personnelle à une instance de plus grand niveau. Selon la sollicitation de l'instance, je serai amené à augmenter ou réduire sa capacité matérielle (ce qui se fait aisément vu qu'il s'agit d'une machine virtuelle), je ferai des retours d'expériences sur quelle type de machine pour combien d'utilisateur en même temps.

Conclusion

Pour conclure ce premier billet numéroté 0, il y a déjà pas mal de choses à rédiger et mettre en forme, à anonymisée avant de mettre à disposition sous la forme de tutoriels et billets de blogs. Ce premier billet donne, je pense, une bonne idée des billets et projets à venir (tous les chantiers ne sont pas finis et pour beaucoup la peinture n'est pas encore sèche). A suivre donc :)

Gravatar de genma
Original post of genma.Votez pour ce billet sur Planet Libre.

Marty : KooZic : script d'installation automatique

DEB, RPM, PKG, Debian, Ubuntu, Fedora, CentOS, OpenSUSE, Archlinux, Gentoo... Autant de systèmes de paquets et de distributions qui font de GNU/Linux un écosystème riche et varié. Mais aussi un enfer à supporter. Le système de packaging change d'un système à l'autre, et les dépendances varient d'une version à l'autre. Essayez de générer un DEB d'une application un peu complexe compatible pour Ubuntu 14.04, 16.04 (bientôt 18.04), Debian 8 et 9, et vous allez vite comprendre la galère. J'ai essayé, j'en ai eu marre et j'ai laissé tombé. Mais je n'ai pas pour autant baissé les bras...

Un beau package bien emballé est la voie royale pour s'immiscer dans la logithèque de l'utilisateur moyen. Mais pour un projet mené avec une équipe limitée (moi), c'est beaucoup trop chronophage. Ayant définitivement abandonné l'idée de me lancer dans le packaging multi-plateforme du logiciel de streaming musical KooZic, j'ai opté pour quelque chose de plus simple : un script d'installation.

Utilisation

Les systèmes suivant sont supportés :

  • Ubuntu 16.04 (et dérivés, par exemple Linux Mint 18.x)
  • Debian 9
  • Debian 8
  • Fedora 27
  • CentOS 7.4

Si votre système est différent, tant pis, ça sert à rien de continuer à lire. Si il est dans la liste, l'installation tient en 3 commandes :

curl https://raw.githubusercontent.com/DocMarty84/koozic/10.0/extra/installer/koozic_install.py > k_install.py chmod +x k_install.py sudo ./k_install.py install

Y'a plus qu'à aller sur http://localhost:8069...

Au niveau des options, on a la possibilité de spécifier :

  • -u : l'utilisateur qui sera utilisé (par défaut : root)
  • -d : le répertoire d'installation (par défault : /opt)

Supprimer KooZic ?

sudo ./k_install.py uninstall

Voilà.

Mais ça fait quoi exactement ?

Lancer un script quelconque en root n'est franchement pas ce qu'il y a de plus sûr. Qui sait ce qui peut se cacher derrière ce qui est exécuté ? Celui qui prend la peine de lire le script, bien sûr. Pour ceux que ça ne motive pas plus que ça, il reste à me faire confiance.

Juré craché, le script va :

  1. installer les dépendances via le système de paquets
  2. installer les dépendances Python manquantes avec pip
  3. mettre en place un serveur PostgreSQL
  4. télécharger la dernière version
  5. installer FFMpeg dans /usr/local/bin
  6. initialiser KooZic
  7. installer et démarrer un script systemd qui permettra de lancer KooZic au démarrage du système

En cas de désinstallation, les étapes 1 à 3 ne seront pas annulées, pour éviter de casser quoi que ce soit. Le reste disparaîtra à tout jamais. Ou jusqu'à la prochaine installation.

Migration d'une installation existante

Si vous êtes de ceux qui utilisent KooZic, merci d'avoir passé le cap de l'installation manuelle ;-) Pour rendre votre installation compatible avec l'installation automatique, il faut stopper KooZic et désactiver le démon systemd si vous en avez créé un. Ensuite, rien de bien exceptionnel :

sudo ./k_install.py install -u USER

Remplacez USER par l'utilisateur qui était utilisé précédemment. Normalement, ça devrait fonctionner. Si pas... ben... Criez à l'aide.

Gravatar de Marty
Original post of Marty.Votez pour ce billet sur Planet Libre.

Articles similaires

Carl Chenet : De 0 à 860 abonnées en 30 numéros : la newsletter du Courrier du hacker

Ce vendredi sera publié le 30ème numéro du Courrier du hacker, la newsletter hebdomadaire résumant l’actualité francophone du Logiciel Libre et Open Source. Résumé d’une aventure commencée il y a 30 semaines 🙂

Pour rappel, le Courrier du hacker propose une sélection des meilleurs articles relayés dans la semaine par le Journal du hacker. Les meilleurs articles ont déjà été sélectionnés par la communauté du Journal du hacker et j’effectue également une sélection.

E-mail Submit

Origine du projet

J’ai été très influencé par l’excellent Hacker Newsletter, une newsletter très connue qui fait un résumé des meilleurs articles publiés sur Hacker News, l’agrégateur de liens communautaire. Le fait que ce type de newsletter n’existe pas en France m’a étonné. Et en tant que fondateur du Journal du hacker, le principal agrégateur communautaire de liens de la communauté du Logiciel Libre et Open Source francophone, il m’est rapidement apparu comme évident qu’il fallait que je le fasse moi-même.

Progression des abonnés

J’en ai déjà parlé dans un précédent article, le nombre d’abonnés a grimpé très rapidement les premières semaines. Après avoir atteint un plateau autour des 700 abonnés, la progression a fortement ralenti et a été plus erratique, dépendant principalement des communications publiques faites autour du projet.

À retenir : la communication autour de son projet reste indispensable. C’est un travail de fond en parallèle qui se fait dans la durée.

Travail constant

Il est difficile d’imaginer la régularité nécessaire à la publication d’une newsletter à date fixe, si vous etes comme moi tout le temps sur une dizaine de projets différents à la fois. Je n’ai publié la newsletter en retard que deux fois en 30 semaines, ce qui m’apparait comme un exploit personnel.

À retenir : les débuts sont faciles, le vrai challenge est de s’inscrire dans le temps et de durer. C’est à bien avoir à l’esprit quand on lance une newsletter.

Baisse du taux d’ouverture

Ayant un peu lu la documentation et les retours d’expérience des créateurs de newsletters, je savais que le taux d’ouverture de la newsletter décroissait de manière régulière avec l’augmentation du nombre d’abonnés. C’est bien sur une contrariété importante quand vous produisez du contenu de le voir ignoré par les abonnés. Mais il s’agit d’un processus normal reporté par tous les éditeurs de newsletters. Reste à voir jusqu’à combien cela descendra.

À retenir : j’étais prevenu et je pensais être au-dessus du lot. Raté. C’est une donnée à surveiller et à investiguer.

Interactions avec les abonnés et autour

Je publie régulièrement via les réseaux sociaux à propos des petites nouvelles autour du Courrier du hacker. Et c’est sympa d’apprendre que le Courrier du hacker génère du trafic pour les auteurs des articles 🙂

L’initiative que j’avais prises pour les 500 abonnés a également été apprécié. Et les remerciements font chaud au coeur !

À retenir : les créateurs de contenu apprécient (en général) être relayés et qu’on parle de leur travail (moi inclus). Donc un bon moyen de génerer de la visibilité, même si ça doit rester franc et sincère pour ne pas devenir lourd.

Le projet motive d’autres initiatives

Comme je l’avais déjà évoqué dans un précédent article, les newsletters n’ont pas un succès extraordinaire en France. Pourtant le Courrier du hacker semble motiver d’autres Libristes à s’intéresser aux newsletters, comme la Gazette de MicroLinux. Plus on est de fous et plus on rit !

Si vous connaissez d’autres newsletters francophones autour du Logiciel Libre, n’hésitez pas à laisser un commentaire.

Me suivre sur les réseaux sociaux

N’hésitez pas à me suivre directement sur les différents sociaux pour suivre au jour le jour mes différentes projets dans le Logiciel Libre :

Gravatar de Carl Chenet
Original post of Carl Chenet.Votez pour ce billet sur Planet Libre.

Articles similaires

Renault : Sortie de Fedora 28 beta

En ce mardi 3 avril, les utilisateurs du Projet Fedora seront ravis d'apprendre la disponibilité de la version Beta Fedora 28.

Malgré les risques concernant la stabilité d’une version Beta, il est important de la tester ! En rapportant les bogues maintenant, vous découvrirez les nouveautés avant tout le monde, tout en améliorant la qualité de Fedora 28 et réduisez du même coup le risque de retard. Les versions en développement manquent de testeurs et de retours pour mener à bien leurs buts.

Notons que Fedora 28, avec ses quelques 51 changements officiels validés, est sans conteste la version comportant le plus de changements de son histoire. La version finale est pour le moment fixée pour la première semaine de mai (sortie le 1er ou le 8 mai).

Voici les nouveautés annoncées pour cette version :

Bureautique
  • Passage à GNOME 3.28
  • L'environnement Sugar est disponible en version 112.
  • Mise à jour de Fontconfig à la version 2.13.
  • Réduction de la redondance entre Anaconda et gnome-initial-setup dans la configuration demandée à l'utilisateur crée lors de l'installation. Le clavier, la date, l'heure et la langue resteront configurés par Anaconda, par contre la configuration du nom d'hôte est supprimée tout comme la création du compte root pour reprendre la politique d'Ubuntu. La création du premier utilisateur revient à gnome-initial-setup.
  • Les modules invités de VirtualBox sont peu à peu intégrés dans le noyau officiel, Fedora propose ainsi dans ses dépôts officiels les paquets pour obtenir la résolution native ou le dossier partagé dans un système Fedora virtualisé dans Virtualbox.
Gestion du matériel
  • Meilleure gestion de l'autonomie des ordinateurs portables avec un processeur Intel. Cela passe par une meilleure gestion de l'énergie des ports SATA pour disques durs et SSD (gain de 1-1,5 W), Intel HDA codec pour le multimédia est mis en sommeil après une seconde d’inactivité (gain de 0,4 W) et activation de l'économie d'énergie pour les récepteurs Bluetooth en USB (gain de 0,4 W si tous les ports USB sont en repos). Sachant qu'un ordinateur portable récent non orienté puissance consomme moins de 10 W (7,5 W chez moi) en usage non intensif. Cela peut donner 20% d'autonomie supplémentaire.
  • Intégration de la norme Thunderbolt 3 (concurrent à l'USB sur de nombreux points). La politique de sécurité liée à cette norme (pour éviter qu'un nouveau périphérique accède sans autorisation à des informations confidentielles) est intégrée à Gnome Shell pour notifier les demandes à l'utilisateur.
  • Mise à jour de VA-API à la version 1.0.0, qui change l'API et l'ABI mais propose en contrepartie une meilleure exploitation de l’accélération matérielle du matériel récent.
  • Les appareils photo RealSens ont besoin de deux bibliothèques librealsense 1 et 2 pour exploiter l'entièreté de leur gamme historique. Le paquet librealsense réfèrera à la version 2 de la bibliothèque pour les versions modernes, un nouveau paquet librealsense1 sera nécessaire pour le matériel plus ancien.
Internationalisation
  • Ibus Typing utilise maintenant la boîte de dialogue pour les emoji afin de proposer des symboles UNICODE en tapant leur description. Ainsi copyright sign propose le symbole ©.
  • La bibliothèque libidn passe à la version 2.0.0 forçant le passage de la norme IDNA2003 à IDNA2008 qui ne sont pas compatibles et pouvaient être source d'attaque par redirection. Cette norme sert à transcrire un nom de domaine Internet UNICODE en une chaîne latine unique comme faß.de qui devient fass.de ou xn--fa-hia.de respectivement.
  • Les données concernant l’internationalisation de GLibc sont mises à jour à partir des fichiers ISO et CLDR de 2015 (Unicode 9.0) en remplacement de iso14651_t1_common qui avait 15 ans. Cela permettra de corriger pas mal d'erreurs, dont des tris alphabétiques dans des langages moins courants en Occident. Ou les symbole infini et ensemble vide qui étaient considérés comme identiques.
  • Les langues asiatiques chinoises, coréennes et japonaises utiliseront par défaut les polices de Google Noto.
Administration système
  • Anaconda, le programme d'installation, devient modulaire. La communication se fait via une API plus stable en DBus, permettant d'améliorer les tests, d'être utilisable sans les droits super utilisateur et d'être étendu par l'utilisateur.
  • authselect remplace authconfig et devient l'outil de configuration par défaut pour le PAM et le fichier nsswitch.conf.
  • Le paquet tcp_wrappers est supprimé. Son utilisation doit être remplacée par iptables, ou mieux par firewalld.
  • libnsl et nss_nis sont proposés hors de GLibc comme recommandé par le projet officiel. libnsl passe à la version 2 au passage autorisant la compatibilité de NIS avec la norme IPv6.
  • De même pour Sun RPC dont la gestion dans GLibc est supprimée pour libtirpc qui permet entre autre la gestion de l'IPv6 nativement.
  • Le stockage par défaut des clés et autres certificats de sécurité par la bibliothèque NSS est le format de SQLite au lieu de DBM. Cela permet l'accès parallèle et diminue le risque de corruption de la base de données.
  • OpenLDAP utilise OpenSSL au lieu de NSS, comme recommandée par le projet officiel.
  • Les bibliothèques de OpenLDAP non compatibles multithread redirigent vers leur version compatibles multithread comme libldap qui pointe vers libldap_r.
  • OpenLDAP abandonne la gestion de TCP Wrappers également.
  • L'utilisateur et groupe nobody:nobody passent de UID et GUID 99:99 à 65534:65534, nfsnobody est supprimé, et nobody n'est plus utilisé de manière systématiquement par défaut pour certains services. Des utilisateurs dédiés seront crées.
  • Nouvelle version de la politique de sécurité par défaut. Les clés RSA doivent être de minimum 2048 bits et DSA est désactivé par défaut. Le passage à TLS 1.2 minimum est repoussé pour le moment.
  • Les paquets de gestion de Kerberos dans Python sont grandement remaniés. python-krbV, pykerberos et python-requests-kerberos sont remplacés par python-gssapi. Le premier n'est pas compatible Python 3, le second n'a pas de documentation et est trop minimaliste quant au dernier il n'est plus maintenu.
  • libcurl utilisera libssh au lieu de libssh2 pour les protocoles SCP et SFTP ce qui permet l'utilisation de l'authentification GSS-API et l'usage d'algorithmes plus sécurisés par défaut.
  • L'outil time passe à la version 1.8, qui change de licence vers GPLv3 et GFDL, qui a de nouveaux codes d'erreur et une nouvelle sortie par défaut. L'affichage conforme POSIX reste possible via l'option -p.
  • Mise à disposition de l'application Stratis Storage qui est une application Python communiquant à travers DBus pour gérer l'espace de stockage du système. Reposant sur le système de fichier XFS pour le moment, son but est de proposer des fonctionnalités populaires chez Btrfs, ZFS ou LVM mais en plus simple pour l'utilisateur comme les clichés, l'intégrité des données ou mettre en place un système de cache.
  • Facter passe de la version 2.4.3 à 3.9.2.
Développement
  • Binutils passe à la version 2.29.1.
  • GLibc 2.27 est utilisée par défaut.
  • La partie cryptographique libcrypt de GLibc est remplacée par libcrypt.
  • GCC 8 devient le compilateur de référence.
  • Le framework Web de Python DJango dégaine à la version 2.0.
  • Coup de Boost à la version 1.66.
  • Ruby est polis à la version 2.5.
  • Le compilateur Haskell GHC évolue à la version 8.2.
  • De même pour le couple Erlang/OTP pour la version 20.
  • Le langage Go court vers la version 1.10.
  • L'éléphant PHP avance prudemment à la version 7.2.
  • Mise à jour de giflib vers la version 5.1.4. Un paquet compat-giflib est proposé pour faciliter la transition aux utilisateurs.
  • Les symboles de débogue PE pour les applications compilées avec MinGW (à destination de Windows donc) seront conservés pour simplifier le débogue natif. Les autres symboles seront bien conservés dans le dossier .debug à part. Cela a un sourcoût d'environ 17% d'espace disque pour une application compilée par ce biais.
Modularité
  • Ajout des dépôts modular, modular-updates et modular-updates-testing pour proposer des composants dans des versions différentes que dans les dépôts natifs de Fedora. Ainsi l'utilisateur peut choisir d'utiliser une version plus récente (ou ancienne) de Python que celle proposée nativement. Mais seulement des composants toujours maintenus par le projet officiel sont proposés.
Projet Fedora
  • L'architecture Aarch64 (ARM 64 bits) devient une architecture primaire pour Fedora Server, donnant lieu à une meilleure promotion et à une meilleure qualité des images officielles.
  • L'architecture s390x est proposée aux images Cloud, Docker et Atomic.
  • Les binaires empaquetés par Fedora et compilés avec GCC sont maintenant annotés pour permettre de plus facilement retrouver les options de compilations l'ayant généré ou les propriétés de son ABI.
  • Renforcement des options de compilation par défaut pour une meilleure sécurité. Ajout de -fstack-clash-protection, D_GLIBCXX_ASSERTIONS, -fcf-protection=full -mcet, .got.plt et --enable-default-pie.
  • Définition et empaquetage des applications écrites en Rust comme exa, ripgrep ou tokei.
  • Activation de Python Generators pour permettre aux empaqueteurs de choisir d'utiliser ou non le générateur automatique de dépendance envers un module Python au lancement.
  • Les scriptlets ldconfig sont supprimés, du moins pour les paquets installant les bibliothèques partagées dans des endroits standards. Cela simplifiera la maintenance des specs RPM et l'installation des paquets sera également plus rapide.

Si l'aventure vous intéresse, les images sont disponibles par Torrent ou via le site officiel. En cas de bogue, n'oubliez pas de relire la documentation pour signaler les anomalies sur le BugZilla ou de contribuer à la traduction sur Zanata.

Bons tests à tous !

Gravatar de Renault
Original post of Renault.Votez pour ce billet sur Planet Libre.

Articles similaires

Framablog : Framaclic, un nouveau service qui compte

Vous avez besoin de compter les visites sur vos sites sans fliquer vos visiteureuses ? On a un framachin pour vous !

Prenons un exemple rapide. Fred aime bien pondre des textes et il les sème un peu partout sur le vaste Ouèbe.

Cela lui pose deux problèmes.

Ses textes sont sur des sites différents avec parfois des adresses web (ou « URL ») longues comme un jour sans pain. Mais pour ça il a trouvé la parade, c’est frama.link, le raccourcisseur d’URL de Framasoft. Il a créé une adresse courte pour chacun de ses textes, et quand on lui demande où on peut lire sa prose, il donne cette URL plutôt qu’une adresse de 256 caractères biscornus. Pour avoir des adresses web encore plus courtes, il pourrait utiliser https://huit.re/.

L’autre souci de Fred, c’est qu’il est affreusement cabotin. Il écrit pour le plaisir, il publie sous licence libre, il a compris qu’il ne bouclerait pas ses fins de mois grâce à sa plume, mais il ne peut pas s’empêcher de se demander si quelqu’un⋅e lit réellement ce qu’il commet.

Fred est donc tout content quand Framasoft sort Framaclic (bon, il ne fait pas des triples saltos, mais il a un moment de jubilation).

C’est quoi ?

Zag, l’adorable mascotte de Dolomon

Framaclic est un raccourcisseur d’URL qui compte les clics. Voilà. Dit comme ça, on dirait que c’est drôlement simple, non ?

Eh bien, bonne nouvelle : c’est simple !

Bon, soyons justes, Frama.link avait déjà un compteur, rudimentaire. Il reconnaît l’auteur de l’URL courte via un petit cookie et est capable de lui fournir un comptage des clics. Seulement, ça ne marche que depuis l’ordinateur et le navigateur sur lesquels l’adresse courte a été créée (à cause du cookie).

« Framaclic est un frama.link dopé aux stéroïdes », nous dit Luc, l’auteur de l’application (qui développe aussi parfois des petites applis complètement inutiles donc parfaitement indispensables).

Comment ça marche ?

Framaclic est basé sur Dolomon, comme DOwnLOad MONitor. Pas besoin d’avoir fait anglais première langue pour piger ça.

Fred se rend sur framaclic.org. Il crée un compte avec un mot de passe, histoire d’être seul à pouvoir accéder à ses statistiques (des fois qu’elles soient mauvaises).

Il fait une liste des adresses de toutes les ressources vers lesquelles il veut créer un lien : ses textes, son blog, son CV, ses galeries de photos, une BD de Simon qu’il adore partager avec ses collègues… Si la liste n’est pas exhaustive, ce n’est pas grave, il pourra en ajouter par la suite.

Comme il aime bien que les choses soient correctement rangées (rappel : cet exemple est une fiction), il crée des catégories et des étiquettes pour s’y retrouver. Surtout qu’il se dit que ce truc-là va drôlement lui rendre service et qu’il va finir par y mettre beaucoup d’adresses.

Ensuite, pour chaque adresse longue il en génère une courte (un « dolo »). Pas besoin de la conserver, Framaclic s’en charge.

 


Les dolos sont créés au fur et à mesure.

Pour suivre les visites sur une page précise, Fred peut créer un dolo pointant sur une petite image transparente (Dolomon vous en propose une) et insérer l’URL générée, comme on insère une image, dans sa page.

Fred aime surtout créer des dolos qui pointent sur un document, au lieu de la page web. Par exemple, un dolo pour le pdf de son roman (http://framabook.org/docs/vieuxflic/FredUrbain_VFVV_cczero20151108.pdf au lieu de la page générique https://framabook.org/vieux-flic-et-vieux-voyou/), un autre pour la version e-pub, et encore un pour le code source en Latex. De cette façon, Fred saura quelle version est la plus téléchargée.

Mais il ne saura rien de plus : Framaclic n’enregistre que des statistiques anonymes, pas les adresses IP des visiteureuses.

Par contre, cela fait de beaux graphiques :

Et comme vos données vous appartiennent, vous pouvez les télécharger dans un fichier CSV, ce qui vous permettra de les manipuler à votre guise, de faire des camemberts colorés…

Ah, un dernier truc cool à savoir : Luc a fait un plugin Dolomon pour WordPress. Si vous avez un blog, vous pourrez créer vos dolos directement depuis votre article.

Contribuez

Comme tout logiciel qui n’a pas encore subi l’épreuve du feu (enfin, l’épreuve de l’utilisation massive), Dolomon comporte certainement quelques bugs ou nécessite un petit coup de polish pour en améliorer l’ergonomie : n’hésitez pas à contribuer en ouvrant des tickets !

Nous tenons au passage à lever notre chapeau à Luc, alias Framasky notre infatigable admin-sys, qui a codé Dolomon pour nos besoins internes, et l’a amélioré afin que l’on puisse l’ouvrir au public ;).

Pour aller plus loin

Gravatar de Framablog
Original post of Framablog.Votez pour ce billet sur Planet Libre.

Articles similaires

Marthym : Spring et connexion sécurisé via proxy

Dans le cadre d’un projet, j’ai une configuration Spring Secure tel que :

... http.requiresChannel() .antMatchers("/client/").requiresSecure() .antMatchers("/fr/client/").requiresSecure() .antMatchers("/es/client/").requiresSecure() .antMatchers("/en/client/").requiresSecure() ...

Ce qui provoque un redirect vers https si l’on tente d’accéder à l’une de ces URL en http.

Le problème est lorsque que je mets un reverse proxy NginX devant, c’est lui qui s’occupe du https, il redirige vers mes routes Spring en http. Spring ne permet de configurer qu’un seul port de serveur qui peut faire http/https. Mais tous mes certif ne sont pas configurés et j’ai pas forcément envie de faire du https entre NginX et Spring.

Du coup, pour que Spring détecte la connexion comme sécurisé et ne fasse pas une redirection infinie entre lui et le reverse proxy, il faut que la configuration NginX ressemble à ça :

server { listen 443 ssl; server_name monsite.fr ssl on; ssl_certificate /etc/ssl/monsite.fr.crt; ssl_certificate_key /etc/ssl/monsite.fr.key; ssl_protocols TLSv1 TLSv1.1 TLSv1.2; ssl_ciphers HIGH:!aNULL:!MD5; location / { proxy_set_header Host $host; proxy_set_header X-Is-Secure true; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-Host $host; proxy_set_header X-Forwarded-Port 443; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto https; proxy_pass http://localhost:9003/; } error_page 500 502 503 504 /50x.html; location = /50x.html { root /usr/share/nginx/html; } }

L’important étant les headers X-Forwarded.

Spring et connexion sécurisé via proxy écrit à l'origine par Marthym pour J'ai acheté un PC neuf cassé ... le April 03, 2018.

Gravatar de Marthym
Original post of Marthym.Votez pour ce billet sur Planet Libre.

Thuban : Guide de Migration OpenBSD 6.2 => 6.3

OpenBSD 6.3 est disponible depuis aujourd'hui. Joie !

Voyons maintenant comment migrer d'OpenBSD 6.2 vers 6.3 ?!

Avant la mise-à-niveau

Comme d'habitude, une des premières actions est de supprimer les manpages obsolètes :

# rm -rf /usr/share/man

Pour une fois, l'action suivante est de supprimer le répertoire de reliaison des bibliothèques, du fait d'un changement à ce niveau :

# rm -r /usr/share/compile Changement de configuration

Pour info, il y a des changements de configuration :

  • gestion logicielle des pavés tactiles : maintenant, gérés par le pilote ''ws''... - normalement, transparent pour l'utilisateur... sauf à vouloir utiliser le pilote synaptics, ce qui nécessite de se créer un fichier ''xorg.conf'' personnalisé.
  • au niveau IPv6 : en rapport avec la gestion slaac, pour se mettre en conformité avec la RFC 7217 - normalement, c'est transparent pour l'utilisateur...
  • ifconfig : l'option ''deletetunnel'' est remplacée par ''-tunnel'' - ajustez votre configuration et autres scripts, si besoin...
  • iked et isakmpd : afin de se mettre en conformité avec la RFC 5903, du fait d'un changement dans le calcul du secret partage de DH, cela rend incompatible les groupes ECP. Veillez à mettre à jour tous vos pairs, en même temps, si vous êtes concernés !
  • vmd : gros changement : vmd ne crée plus automatiquement l'interface de pont, nécessaire. C'est à l'utilisateur de le faire, par exemple, dans le fichier ''/etc/hostname.bridge0'', puis d'ajouter dans le fichier de configuration de ''vm.conf'' la définition de celui-ci, tel que : switch "uplink" { interface bridge0 }
Changements spécifiques

Certains binaires changent dans leur fonctionnement, en étant mis-à-jour.
C'est principalement le cas de ''Buildbot'', ''memcached'', ''neomutt'', ''newsbueter'' et ''PostgrSQL''.

Pour en savoir plus sur les autres changements induits par ces mises-à-niveau, veuillez lire le Guide de Migration...

Conseils pratiques

Avant de faire la mise-à-niveau, si vous utilisez Gnome3, pensez à désactiver gdm : # rcctl disable gdm
Lors du redémarrage, vous vous retrouverez en terminal texte, mais cela permettra de ne pas avoir de soucis avec l'interface graphique.

Vous pouvez faire de même pour xenodm...

Idem, pour les services serveurs, il est recommandé de les désactiver !

Téléchargement

Maintenant que les précautions d'usage ont été exécutées - n'est-ce pas ?! - occupons-nous de télécharger le nécessaire !

Pour cela, positionnons-nous à la racine du système et téléchargeons le binaire ''bsd.rd'', puis les fichiers de sommes de contrôle, et de signature, pour les vérifier :

$ cd /
# for file in bsd.rd SHA256.sig; do [ -f $file ] && rm -fP $file; ftp -n -m -C "https://fastly.cdn.openbsd.org/pub/OpenBSD/6.3/$(arch -s)/$file"; done
$ sha256 -c SHA256.sig 2>&1 | awk '/bsd.rd/ {print $3}'
OK
$ signify -Cp /etc/signify/openbsd-63-base.pub -x SHA256.sig bsd.rd
Signature Verified
bsd.rd: OK

Installations

(Re)démarrons la machine informatique, et lors de l'invite 'boot>', tapez : boot bsd.rd

Laissez faire, jusqu'à ce que le processus vous demande le choix d'(I)nstaller, d'(U)pgrader, etc … choisissez : ''U''

Puis, tapez ''http'' si vous voulez la faire en étant connecté à Internet...
ou si vous avez le CD ou une clé USB, tapez ''cd'' !

Ensuite, répondez aux questions, tout comme lors de votre première installation… pour finir par redémarrer, si tout s'est bien passé : reboot

Normalement, OpenBSD met-à-jour automatiquement les firmwares, et essaye de fusionner correctement les nouveaux fichiers de configuration avec ceux que vous auriez pu modifier...

au cas où, utilisez ''sysmerge'', puis ''fw_update''.

Puis terminez par la mise-à-niveau des packages !

# pkg_add -iuv

Laissez faire - cette étape peut être très longue, selon le nombre de paquets que vous aviez précédemment installés pour votre usage.
Parfois, il peut être nécessaire de répèter cette commande... plusieurs fois ; s'il vous est demandé de réparer, faites-le en spécifiant 'y'.

et une fois effectuée, exécutez :

# pkg_check

Et si vous l'avez installé, exécutez :

# sysclean

Sinon, si ''sysclean'' n'est pas installé, une fois n'est pas coutume, il sera nécessaire d'exécuter ceci :

# cd /usr/X11R6/lib
# rm libpthread-stubs.a \\
     libpthread-stubs.so.2.0 \\
     pkgconfig/pthread-stubs.pc

En effet, ceci est nécessaire du fait d'un changement dans la gestion de la bibliothèque ''libpthread-stubs'' qui n'est plus nécessaire - pour plus d'informations, je vous renvoie au Guide de Migration...

Ceci étant dit, étant fait, pensez à réactiver les services que vous auriez désactivé, lors de la phase de préparation de la mise-à-niveau, puis une fois fait, redémarrez votre machine...

Une fois que vous êtes dans votre session, pensez à lire les fichiers pkg-readmes préparés dans ''/usr/local/share/doc/pkg-readmes/''.

Documentation

La traduction anglais->français (in)officielle du Guide de migration OpenBSD 6.3 est prête !

N'hésitez pas à venir en discuter sur notre forum ;)

 

Gravatar de Thuban
Original post of Thuban.Votez pour ce billet sur Planet Libre.

Articles similaires

Pages