En ce mardi 17 septembre, les utilisateurs du Projet Fedora seront ravis d'apprendre la disponibilité de la version Beta Fedora 31.

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 31 et réduisant du même coup le risque de retard. Les versions en développement manquent de testeurs et de retours pour mener à bien leurs buts.

La version finale est pour le moment fixée pour le 22 ou 29 octobre. Voici les nouveautés annoncées pour cette version :

Expérience utilisateur

• Passage à GNOME 3.34.
• La roue tourne pour Xfce avec la version 4.14.
• Mise à jour de DeepinDE 15.11.
• Firefox utilise Wayland nativement par défaut, bien entendu si la session de bureau le permet.
• Les applications Qt utiliseront de manière analogue Wayland lors d'une session GNOME sous Wayland.
• Les paquets RPM utilisent le format de compression zstd au lieu de xz. Le temps de décompression est bien plus rapide d'un facteur trois ou quatre pour le paquet Firefox par exemple. Mais générer un paquet est légèrement plus long.

Gestion du matériel

• Le noyau Linux i686 n'est plus généré et les dépôts associés sont également supprimés. De fait il n'y aura plus d'images de Fedora pour cette architecture, ni mise à niveau possible depuis Fedora 30 pour ces utilisateurs. Des paquets i686 peuvent subsister dans les dépôts à destination des utilisateurs ayant l'architecture x86_64 uniquement.
• Le spin Xfce de Fedora dispose d'une image pour l'architecture AArch64.
• Sur les machines avec la fonctionnalité Secure Boot de l'UEFI activé, GRUB peut maintenant utiliser ses modules de sécurité nativement.

Internationalisation

• Les paquets langpacks sont subdivisés avec une partie langpacks-core qui ne propose que la police par défaut et la locale correspondante. L'utilisateur a donc plus de flexibilité à ce niveau.
• Mise à jour d'IBus 1.5.21.
• Les polices Google Noto Variables auront maintenant la priorité sur les polices non variables du même fournisseur.

Administration système

• Le binaire /usr/bin/python fait référence dorénavant à Python 3 et non Python 2. En effet, Python 2 ne sera plus supportée par le projet officiel en janvier 2020, le projet Fedora respecte donc la PEP 394 pour entamer la transition. En cas de problèmes vous pouvez créer le lien symbolique ~/.local/bin/python pour un utilisateur ou /usr/local/bin/python pour le système entier afin de restaurer le comportement habituel.
• De fait, il y a une suppression massive de paquets Python 2 pour ne garder essentiellement que les derniers projets non convertis à Python 3 aujourd'hui.
• La fonction des politiques de sécurité, introduite peu à peu dans Fedora ces dernières années, offre maintenant la possibilité aux administrateurs de personnaliser les règles comme le choix des protocoles de sécurité utilisables ou non sur le système.
• Le noyau propose les cgroups 2 au lieu de la version 1 utilisée jusqu'alors.
• OpenSSH refuse par défaut les identifications par mot de passe pour le compte super utilisateur.
• Tous les groupes utilisateurs ont la possibilité native de faire des ping sur le réseau sans binaire setuid. Cela est surtout à destination des environnements avec conteneur ou Fedora Silverblue.
• Le compteur RPM atteint la version 4.15.
• DNF émettra une erreur par défaut si un dépôt est non accessible au lieu d'émettre seulement un avertissement. Cela est surtout à destination des dépôts tiers qui n'activaient pas forcément cette option dans leur configuration.
• YUM 3 tire sa révérence, uniquement un lien symbolique vers DNF est maintenu. Son API n'est également plus accessible.
• Les paquets liés à 389-console sont retirés au profit d'une nouvelle interface web.

Développement

• Mise à jour de la bibliothèque C glibc vers la version 2.30.
• Gawk passe à la branche 5.0.
• Node.js en est à son 12e nœud.
• Le générateur de documentation Sphinx passe à la version 2 et abandonne la prise en charge de Python 2.
• Les tests Python passent du paquet python3-libs au paquet python3-test.
• Le langage Go fonce vers la version 1.13.
• Le langage Perl reluit à la version 5.30.
• Mise à jour du langage Erlang et OTP à la version 22.
• Alors que le compilateur Haskell GHC et Stackage LTS passent respectivement à la version 8.6 et 13.
• La pile .Net libre Mono bénéficie de la version 5.20.
• L'environnement et la chaine de compilation MinGW passent la 6e.
• Le projet Fedora propose une configuration alternative de l'éditeur de lien, pour passer aisément de celui du projet GNU LD à celui de LLVM LDD et vice versa sans changer l'environnement de développement.
• L'éditeur de lien GOLD de binutils, développé par Google mais maintenu par GNU maintenant a son propre paquet binutils-gold pour facilement s'en séparer si la maintenance s'arrête. Le projet n'étant plus développé activement.

Projet Fedora

• L'image Cloud de Fedora bénéficiera d'une nouvelle image chaque mois.
• Dans la continuité de rendre Rawhide plus stable et d'améliorer l'assurance qualité, Rawhide a maintenant Bodhi qui est activé. Cela signifie qu'un paquet doit suivre le même processus pour une mise à jour sur Rawhide que pour une version stable.
• Les sources RPM peuvent avoir des dépendances lors de la compilation générée dynamiquement. En effet de plus en plus de langages comme Rust ou Go gèrent eux mêmes les dépendances pour compiler un projet. Ainsi, l'empaqueteur n'a plus pour ces projets à recopier les dépendances que le projet a déjà lui même renseigné.
• De nouvelles règles d'empaquetage pour les projets utilisant Go ont été édictées.
• L'environnement de compilation de Fedora, le buildroot, utilise un gdb minimal pour gagner en efficience. Il ne dispose plus de la gestion du XML ou de Python.
• Les dépendances autour du langage R peuvent maintenant être résolues automatiquement.
• Le paquet glibc i686 nécessaire pour le buildroot de Fedora bénéficie d'une amélioration de sa compilation pour être plus maintenable et garantir le respect de la licence LGPL.

Tester

Durant le développement d'une nouvelle Fedora, comme cette version Beta, quasiment chaque semaine le projet propose des journées de tests. Le but est pendant une journée de tester une fonctionnalité précise comme le noyau, Fedora Silverblue, la mise à niveau, GNOME, l’internationalisation, etc. L'équipe de qualité élabore et propose une série de tests en général simples à exécuter. Suffit de les suivre et indiquer si le résultat est celui attendu. Dans le cas contraire, un bogue devra être ouvert pour permettre l'élaboration d'un correctif.

C'est très simple à suivre et requiert souvent peu de temps (15 minutes à une heure maximum) si vous avez une Beta exploitable sous la main.

Les tests à effectuer et les rapports sont à faire via la page suivante. J'annonce régulièrement ici quand une journée de tests est planifiée.

Si l'aventure vous intéresse, les images sont disponibles par Torrent ou via le site officiel.

Si vous avez déjà Fedora 30 ou 29 sur votre machine, vous pouvez faire une mise à niveau vers la Beta. Cela consiste en une grosse mise à jour, vos applications et données sont préservées.

Nous vous recommandons dans les deux cas de procéder à une sauvegarde de vos données au préalable.

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 !

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

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

Pour la 37ème semaine de l'année 2019, voici 15 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 !

• Épurer un téléphone Android
• Gandi et Framasoft s’associent
• À la poursuite du minimalisme numérique
• Votre terminal n’est pas un terminal : Introduction aux flux
• Supprimer la publicité en ligne pour un numérique plus écologique ?
• L'avenir de Salto
• Deno : le nouveau NodeJS ?
• Ces SMS « invisibles » pourraient géolocaliser plus d’un milliard de mobiles
• Firefox chiffrera les requêtes de noms de domaine Web en activant le DNS-over-HTTPS à partir de fin septembre
• Ungleich : désactivez Firefox DNS-over-HTTPS (DoH), maintenant, car c'est très mauvais pour nous tous, à bien des égards
• Mozilla pense-t-il vraiment à notre vie privée comme priorité?
• Après Red Hat, Homebrew décide à son tour de supprimer MongoDB de ses formules de base suite à son passage en licence SSPL
• Huawei remplace Windows 10 par Linux sur ses PC portables
• HashiCorp Vault : le cookbook
• Utiliser k3d pour avoir un cluster k8s en local

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

• Le flux RSS du Journal du hacker
• Le compte Twitter du Journal du hacker
• Le compte Diaspora* du Journal du hacker
• Le compte Mastodon du Journal du hacker

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 :)

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

La littérature concernant systemctl est assez abondante en revanche pour systemctl --user on frôle le désert, un petit article ?

J’avais le désir de lancer mon émulateur de terminal Tilix au démarrage de ma session et qu’il se relance à chaque fois qu’il est fermé. Je commence à bien toucher les services systemd, systemctl mais là je me suis pris un four.

Le tiercé dans le bon ordre

Comme d’habitude ce n’est pas forcément compliqué, c’est juste qu’il faut le savoir. Pour mettre en place un service utilisateur systemd la difficulté ne se situe pas dans les lignes de commande mais davantage dans le bon ordre/enchaînement des commandes.

mkdir -p ~/.config/systemd/user
nano ~/.config/systemd/user/tilix.service
systemctl --user enable tilix.service # systemctl --user reenable tilix.service
systemctl --user start tilix.service # journalctl --user -u tilix -f

nano ~/.config/systemd/user/tilix.service
systemctl --user daemon-reload; systemctl --user restart tilix # systemctl --user --now enable tilix

Remarquez que nulle part il n’y a de sudo, vous n’avez besoin d’aucun droit root justement parce qu’on met en place un service utilisateur. Un service plus « classique » systemd comme on en met sur les serveurs par exemple aurait donné sudo systemctl enable joli.service.

On commence par créer le dossier qui va accueillir nos services utilisateur mkdir -p ~/.config/systemd/user. On crée/configure notre service nano ~/.config/systemd/user/tilix.service puis on l’active systemctl --user enable tilix.service donc à la prochaine ouverture de session de notre utilisateur, il sera lancé automatiquement. Maintenant on le démarre systemctl --user start tilix.service notamment pour voir si il fonctionne comme on le souhaite. En plus de ces commandes, il vous faudra utiliser journalctl --user -u tilix -f pour consulter les messages de votre service dans le journal et systemctl --user status tilix.service pour connaître l’état de votre service. À retenir aussi la commande systemctl --user reenable tilix.service qui va supprimer les symlinks créés par systemd pour démarrer le service et les recréer (This is a combination of disable and enable and is useful to reset the symlinks a unit file is enabled with to the defaults configured in its « [Install] » section), utile quand on se trompe dans la section [Install] (multi-user.target => default.target par exemple comme nous allons le voir après).

On part du principe que le service ne correspond pas exactement à ce que l’on souhaite (ça arrive souvent), on rentre donc dans une seconde phase, la modification du service et les commandes pour la prendre en compte. On modifie notre service car un truc nous convient pas nano ~/.config/systemd/user/tilix.service. On informe systemd que le service a été modifié et on redémarre le service systemctl --user daemon-reload; systemctl --user restart tilix. À connaître également on active le service à l’ouverture de la session et on le démarre systemctl --user --now enable tilix qui est l’équivalent de deux commandes --user enable et --user start.

tilix.service

La première version de mon service fut celle-ci, cat ~/.config/systemd/user/tilix.service.

[Unit]
Description=Tilix

[Service]
Type=simple
ExecStart=/usr/bin/tilix --minimize
Restart=always

[Install]
WantedBy=multi-user.target

Du très classique sur lequel je vais peu revenir, voir la documentation. Le Restart=always qui relance automatiquement Tilix dès qu’il est fermé, la commande à lancer ExecStart=/usr/bin/tilix --minimize. Dans mon cas je ne veux pas que Tilix ait le focus (soit au premier plan), je le veux minimisé.

La seconde version définitive.

[Unit]
Description=Tilix

[Service]
Type=simple
ExecStart=/usr/bin/tilix --minimize
KillMode=none
Restart=always

[Install]
WantedBy=default.target

J’ai remarqué rapidement que lorsque je fermais Tilix, toutes les applications que j’avais lancé via le terminal (par exemple Firefox ou TeamViewer) étaient fermées immédiatement. Voir KillMode. Autre subtilité/difficulté d’un service utilisateur, les targets ne sont pas les mêmes qu’un service systemd classique. Dans ce dernier vous verrez souvent WantedBy=multi-user.target alors que dans un service utilisateur, il n’y a pas multi-user.target notamment. Comparez systemctl list-units --type target et systemctl --user list-units --type target.

Euh… mais ça marche pas ?

Soudain le drame, Tilix n’est pas lancé à l’ouverture de la session après un redémarrage du pc. J’ai creusé, retourné, testé pensant que mon service Tilix n’était pas bon. L’un des côtés négatifs de mon syndrome de l’imposteur est que je vais passer X heures à chercher mon erreur sans envisager que ça ne vient pas de moi.

Après plusieurs heures de tests et de recherches vaines, j’allais raccrocher, la défaite était lourde. Je me suis souvenu qu’au boulot j’avais ramé deux heures sur un truc qui ne fonctionnait pas, c’était « juste » le script fourni qui était merdique. J’ai fait une recherche et en deux minutes j’ai trouvé le bug… Assez ironiquement il est reporté chez Red Hat depuis 15 jours, chez Ubuntu ça date. Il s’agit d’un bug lié à ECryptFS (partition /home chiffrée), j’ai testé la solution proposée avec /etc/pam.d/common-session mais ça ne fonctionne pas chez moi. J’ai confirmé le bug avec la session de Madame (partition /home non chiffrée), le service Tilix se lance bien à l’ouverture de session.

And voilà. Finalement j’ai ajouté dans l’utilitaire Session et démarrage de XFCE, Démarrage automatique d’application : systemctl --user --now enable tilix en attendant que le bug soit résolu.

Sources :
https://wiki.archlinux.fr/Systemd/utilisateur
https://vic.demuzere.be/articles/using-systemd-user-units/
https://unix.stackexchange.com/questions/385964/launching-chromium-on-startup-with-systemd

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

J’utilise TeamViewer pour dépanner et me connecter à un poste à distance. Son fonctionnement m’avait cependant dérangé et je m’étais noté de revenir dessus pour corriger ça.

La petite particularité et complexité de TeamViewer est qu’il nécessite le service teamviewerd (sudo systemctl status teamviewerd.service) ET le client graphique (TeamViewer).

ps aux | egrep '[t]eam'
root      6449  4.8  0.0 1473636 12424 ?       Sl   06:17   0:00 /opt/teamviewer/tv_bin/teamviewerd -d
moi      6466  7.1  0.7 2223904 116492 pts/1  Sl   06:17   0:00 /opt/teamviewer/tv_bin/TeamViewer

Si vous lancez le client sans que le service tourne, vous aurez le message : « Pas prêt. Veuillez vérifier votre connexion ». Au contraire si le service tourne alors tout sera bon : « Prêt à se connecter (connexion sécurisée) ».

Je me sers de TeamViewer peut-être 20 mn par mois et un jour je me rends compte qu’un $%*?#+ de service tourne : teamviewerd.service. Déjà j’ai horreur que le service d’un outil de contrôle à distance tourne sur mon poste mais surtout je veux juste pas d’un service qui tourne pour rien. J’ai ouvert le client graphique, je suis allé dans Suppléments, Options puis dans Général, j’ai décoché « Start TeamViewer with system »… pour me rendre compte quelques jours après qu’en fait le service tournait toujours.

Maintenant faisons les choses proprement comme si on l’installait pour la première fois.

wget https://download.teamviewer.com/download/linux/teamviewer_amd64.deb # Téléchargement de la dernière version
sudo gdebi teamviewer_amd64.deb; rm teamviewer_amd64.deb # Installation de TeamViewer et ses dépendances avec gdebi puis suppression du paquet deb
sudo systemctl disable --now teamviewerd.service # Désactivation du service teamviewerd au démarrage et arrêt du service

L’option --now (When used with disable or mask, the units will also be stopped) permet d’économiser une ligne : systemctl stop teamviewerd.service.

Le service ne tourne plus et ne sera pas lancer au prochain démarrage du pc, maintenant comment lancer TeamViewer ?

sudo systemctl start teamviewerd.service && (teamviewer >/dev/null 2>&1 && sudo systemctl stop teamviewerd.service &)

sudo systemctl start teamviewerd.service # On démarre le service
teamviewer >/dev/null 2>&1 # On lance le client graphique en redirigant toutes les sorties vers /dev/null (>/dev/null 2>&1)
&& sudo systemctl stop teamviewerd.service # Une fois que le client graphique est quitté, on stoppe le service
Concernant la grammaire (&&, & et ( )), je vous invite à man bash puis /Liste.

Évidemment je ne tape pas cette commande à chaque fois, j’ai un alias dans ~/.bashrc.

alias team='sudo systemctl start teamviewerd.service && (teamviewer >/dev/null 2>&1 && sudo systemctl stop teamviewerd.service &)'

Je suppose que cela doit paraître bien lourd et compliqué à certains, perso ce que je trouve lourd c’est un service qui tourne pour rien ha ha.

Bonus : Confiance ou méfiance

Lecteur tu es arrivé jusque là, tu as le droit à un bonus de lecture !

TeamViewer est un logiciel propriétaire et payant, mon dieu ! Depuis 1 an, on commence à entendre du bien de DWService, un article chez Microlinux et Sebsauvage cette semaine. Le client est publié sur GitHub depuis quelques mois, le service est gratuit et non limité (contrairement à TeamViewer pour la version gratuite).

Je m’étais penché dessus, j’en avais conclu que je n’installerai certainement pas ce logiciel. La page Sécurité ne me rassure pas du tout, aucune précision sur les technos utilisées. Le fait que ça fonctionne est la condition 0, on n’en parlerait même pas si ça ne fonctionnait pas. Pour un outil de prise de contrôle à distance, la condition N°1 pour moi est la sécurité et n’est pas remplie.

À titre personnel ce logiciel aurait été un lecteur vidéo, une calculette, etc. la condition N°1 n’aurait pas été la sécurité mais il s’agit d’un outil de prise de contrôle à distance dont on installe le serveur sur le poste qu’on souhaite piloter puis client/serveur se connecte à une node. Les sources de la node et du serveur ne sont pas fournies, on ne sait rien de comment ça fonctionne et ce que ça fait. Je précise que je trouve très bien que DWService propose le code source de son client, je ne sais pas si node et serveur sont des outils de qualité et sécurisés mais je ne peux qu’encourager et souhaiter bonne chance à l’équipe derrière. Il n’est pas question pour moi de dire que c’est mauvais mais juste de s’interroger sur la confiance qu’on peut placer dans cet outil.

Alors lecteur tu privilégies un outil proprio faisant plus de 20 millions de sessions d’assistance par jour avec 360000 abonnés payants développé par une entreprise allemande de 900 personnes et récemment introduite en bourse (source) ou un logiciel libre (pour certaines parties) dont on ne sait pas grand-chose ?

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