From Fedora Project Wiki
No edit summary
m (Corrections)
Line 30: Line 30:
L'offre des cartes prises en charge s'étoffera dans le temps, de même que la mise à disposition des versions personnalisées de Fedora.
L'offre des cartes prises en charge s'étoffera dans le temps, de même que la mise à disposition des versions personnalisées de Fedora.


Toujours à propos du matériel, Fedora a travaillé pour avoir une meilleure gestion des SoC Intel Bay Trail et Cherry Trail (essentiellement des puces Pentium, Celeron et Atom sur portables et tablettes). Le travail a consisté en l'amélioration de la surveillance de la batterie (consommation actuelle, temps restant sur batterie, en charge ou non) et de la gestion de l'audio. Les écrans tactiles et les accéléromètres seront également mieux détectés et donc exploitables par le système et les applications.
Toujours à propos du matériel, Fedora a travaillé pour avoir une meilleure gestion des SoC Intel Bay Trail et Cherry Trail (essentiellement des puces Pentium, Celeron et Atom sur portables et tablettes). Le travail a consisté en l'amélioration de la surveillance de la batterie (consommation actuelle, temps restant sur batterie, savoir si la machine est en charge ou non) et de la gestion de l'audio. Les écrans tactiles et les accéléromètres seront également mieux détectés et donc exploitables par le système et les applications.


Fedora 27 peut enfin tourner sur les ordinateurs ayant un UEFI 32 bits mais un CPU 64 bits. Cela consiste en l'installation d'un GRUB 32 bits (chargé par l'UEFI lui même) qui lui même charge un noyau et l'espace utilisateur en 64 bits. Cette configuration, assez atypique, a nécessité un travail sur GRUB, Anaconda et les utilitaires EFI pour les prendre en charge. Fedora sera ainsi installable sur ces configurations comme l'Asus Transformer T100TA, le HP Stream 7, le Dell Venue 8 Pro 5830 et les premiers Macintosh Intel d'Apple.
Fedora 27 peut enfin tourner sur les ordinateurs ayant un UEFI 32 bits tout en ayant un CPU 64 bits. Cela consiste en l'installation d'un GRUB 32 bits (chargé par l'UEFI lui même) qui lui même charge un noyau et l'espace utilisateur en 64 bits. Cette configuration, assez atypique, a nécessité un travail sur GRUB, Anaconda et les utilitaires EFI pour les prendre en charge. Fedora sera ainsi installable sur ces configurations comme l'Asus Transformer T100TA, le HP Stream 7, le Dell Venue 8 Pro 5830 et les premiers Macintosh Intel d'Apple.


Mise à jour de libpinyin vers la version 2.1 pour les entrées de saisi en chinois. Cette version consiste essentielle dans la fusion avec la bibliothèque libzhuyin qu'il remplace. Cela apporte la prise en charge du chinois Zhuyin pour la saisie rapide dans cette langue.
Mise à jour de libpinyin vers la version 2.1 pour les entrées de saisi en chinois. Cette version consiste essentielle dans la fusion avec la bibliothèque libzhuyin qu'il remplace. Cela apporte la prise en charge du chinois Zhuyin pour la saisie rapide dans cette langue.


La mise à disposition de polices de caractères Serif pour le chinois par défaut. Jusqu'ici Fedora fournissait surtout des polices Sans pour le chinois. Mais depuis la libération de certaines polices de la part d'Adobe et de Google, il est dorénavant possible de fournir des polices de caractères Serif convenables pour ces utilisateurs nativement.
La mise à disposition des polices de caractères Serif pour le chinois par défaut. Jusqu'ici Fedora fournissait surtout des polices Sans pour le chinois. Mais depuis la libération de certaines polices de la part d'Adobe et de Google, il est dorénavant possible de fournir des polices de caractères Serif convenables pour ces utilisateurs nativement.


== Administration système ==
== Administration système ==


Suppression du script ''256term.sh'' (''/etc/profile.d/256term.sh'' et ''/etc/profile.d/256term.csh'') qui changeait la valeur de la variable ''$TERM'' pour activer les couleurs dans les terminaux selon le terminal employé. Maintenant ce sont les émulateurs de terminal qui s'en chargent directement, ce qui rend la procédure plus reproductible, plus simple et plus rapide car le script n'est plus exécuté à chaque nouveau shell lancé.
Suppression du script ''256term.sh'' (''/etc/profile.d/256term.sh'' et ''/etc/profile.d/256term.csh'') qui changeait la valeur de la variable ''$TERM'' pour activer les couleurs dans les terminaux selon le terminal employé. Maintenant ce sont les émulateurs de terminal qui s'en chargent directement, ce qui rend la procédure plus reproductible, plus simple et plus rapide car le script n'est plus exécuté pour chaque nouveau shell.


Activation de l'option TRIM pour les nouvelles partitions chiffrées avec LUKS1. L'option TRIM permet aux SSD de connaître les cellules mémoires utilisées par le système de fichier afin de pouvoir contrôler l'usure des cellules au mieux sans impacter les performances et de conserver les performances en écriture dans le temps. Les SSD étant de plus en plus populaires, il a été décidé de rendre cela par défaut pour les partitions chiffrés, ce qui aurait un impact négligeable pour ceux utilisant un disque dur. Cela consiste à l'ajout natif de l'option ''discard'' dans ''/etc/crypttab''. Le manque de place dans les métadonnées de LUKS1 explique pourquoi cela ne concerne que les nouvelles partitions.
Activation de l'option TRIM pour les nouvelles partitions chiffrées avec LUKS1. L'option TRIM permet aux SSD de connaître les cellules mémoires utilisées par le système de fichier afin de pouvoir contrôler l'usure des cellules au mieux en conservant les performances en écriture dans le temps. Les SSD étant de plus en plus populaires, il a été décidé de rendre cela par défaut pour les partitions chiffrés, ce qui aurait un impact négligeable pour ceux qui utilisent un disque dur. Cela consiste à l'ajout natif de l'option ''discard'' dans ''/etc/crypttab''. Le manque de place dans les métadonnées de LUKS1 explique pourquoi cela ne concerne que les nouvelles partitions.


Nouveau système de cache par défaut pour les identifiants Kerberos nommé KCM. C'est le 4e système de cache à ce sujet, le premier était basé sur les fichiers, le second sur les répertoires et le 3e sur le porte-clé du noyau. Mais :
Nouveau système de cache par défaut pour les identifiants Kerberos nommé KCM. C'est le 4e système de cache à ce sujet, le premier était basé sur les fichiers, le second sur les répertoires et le 3e sur le porte-clé du noyau. Mais :


* Celui basé sur les fichiers est certes largement géré, mais il ne peut gérer plusieurs caches pour une même collection ;
* Celui basé sur les fichiers est certes largement pris en charge, mais il ne peut gérer plusieurs caches pour une même collection ;
* Celui basé sur les répertoires corrige ce problème, mais cela nécessite son propre contrôle d'accès pour la gestion des répertoires ce qui est délicat ;
* Celui basé sur les répertoires corrige ce problème, mais cela nécessite son propre contrôle d'accès pour la gestion des répertoires ce qui est délicat ;
* Le dernier utilisant le noyau, n'est pas adapté pour les environnements isolés (qui partagent le même noyau), ne bénéficiant pas des espaces de noms de l'utilisateur.
* Le dernier utilisant le noyau, n'est pas adapté pour les environnements isolés (qui partagent le même noyau), ne bénéficiant pas des espaces de noms de l'utilisateur.


L'architecture ici change énormément. Cela va reposer sur un principe client serveur où l'application qui utilise Kerberos comme ''kinit'' va communiquer avec un serveur KCM comme ''sssd''. Pour le moment seul Heimdal Kerberos implémentaient un serveur KCM. Heimdal et MIT ont implémenté un client KCM dans ''libkrb5''. Fedora a proposé d'inclure un serveur KCM dans SSSD, plutôt qu'un démon isolé, pour bénéficier de l'API D-Bus qu'emploie SSSD afin que par exemple une application graphique puisse recevoir les notifications associées, la possibilité de sauvegarder des données secrètes facilement pour exploiter à nouveau le cache en cas de redémarrage et un accès facile à l'authentification de SSSD côté utilisateur, qui est également bien testé.
L'architecture ici change énormément. Cela va reposer sur un principe client serveur où l'application qui utilise Kerberos comme ''kinit'' va communiquer avec un serveur KCM comme ''sssd''. Jusqu'alors seul Heimdal Kerberos implémentait un serveur KCM. Heimdal et MIT ont implémenté un client KCM dans ''libkrb5''. Fedora a proposé d'inclure un serveur KCM dans SSSD, plutôt qu'un démon isolé, pour bénéficier de l'API D-Bus qu'emploie SSSD afin que par exemple une application graphique puisse recevoir les notifications associées, la possibilité de sauvegarder des données secrètes facilement pour exploiter à nouveau le cache en cas de redémarrage et un accès facile à l'authentification de SSSD côté utilisateur, qui est également bien testé.


libcurl réutilise OpenSSL pour la cryptographie et le protocole TLS au lieu de NSS. En effet, il y a 10 ans, c'était dans la décision inverse que le projet Fedora avait acté. L'objectif de ce revirement est de permettre la conception d'images de base de Fedora plus légères (dans le cadre des conteneurs entre autre). Cela facilite la possibilité d'enlever NSS dans ce genre de contexte nativement. Par contre l'inconvénient est que libcurl ne peut plus exploiter nativement les bases de données de certificats de NSS, dont ceux fournis avec Firefox. Un export est nécessaire pour cela.
libcurl réutilise OpenSSL pour la cryptographie et le protocole TLS au lieu de NSS. En effet, il y a 10 ans, c'était la décision inverse que le projet Fedora avait acté. L'objectif de ce revirement est de permettre la conception d'images de base de Fedora plus légères (dans le cadre des conteneurs entre autre). Cela facilite la possibilité d'enlever NSS dans ce genre de contexte nativement. Par contre l'inconvénient est que libcurl ne peut plus exploiter nativement les bases de données de certificats de NSS, dont ceux fournis avec Firefox. Un export est nécessaire pour cela.


Le serveur OpenVPN utilise un nouvel algorithme de chiffrement par défaut qui est AES-256-GCM au lieu de BF-128-CBC améliorant la sécurité des connexions. En effet, il y a un an avec l'attaque [https://sweet32.info/ SWEET32], il a été révélé que les blocs chiffrés d'une taille de 128 bits et inférieurs sont vulnérables. La nouvelle politique passant par défaut à 256 bits, cela évite le problème. Le changement consiste dans la liste d'options par défaut du service openvpn qui était :
Le serveur OpenVPN utilise un nouvel algorithme de chiffrement par défaut qui est AES-256-GCM au lieu de BF-128-CBC améliorant la sécurité des connexions. En effet, il y a un an avec l'attaque [https://sweet32.info/ SWEET32], il a été révélé que les blocs chiffrés d'une taille de 128 bits et inférieur sont vulnérables. La nouvelle politique passant par défaut à 256 bits, cela évite le problème. Le changement consiste dans la liste d'options par défaut du service openvpn qui était :
     ExecStart=/usr/sbin/openvpn --status %t/openvpn-server/status-%i.log --status-version 2 --suppress-timestamps --config %i.conf
     ExecStart=/usr/sbin/openvpn --status %t/openvpn-server/status-%i.log --status-version 2 --suppress-timestamps --config %i.conf
devenant
devenant
     ExecStart=/usr/sbin/openvpn --status %t/openvpn-server/status-%i.log --status-version 2 --suppress-timestamps --cipher AES-256-GCM --ncp-ciphers  AES-256-GCM:AES-256-CBC:AES-128-GCM:AES-128-CBC:BF-CBC --config %i.conf
     ExecStart=/usr/sbin/openvpn --status %t/openvpn-server/status-%i.log --status-version 2 --suppress-timestamps --cipher AES-256-GCM --ncp-ciphers  AES-256-GCM:AES-256-CBC:AES-128-GCM:AES-128-CBC:BF-CBC --config %i.conf


Comme vous le voyez, dans la nouvelle version, AES-256-GCM est employé par défaut mais en cas de clients non compatibles (version 2.3 et inférieurs), il reste possible d'employer BF-128-CBC ou un autre algorithme compatible par une classique négociation au début de la connexion. Ainsi la compatibilité reste préservée au maximum, tout en améliorant la sécurité par défaut des clients le pouvant.
Comme vous le voyez, dans la nouvelle version, AES-256-GCM est employé par défaut mais en cas de clients non compatibles (version 2.3 et inférieur), il reste possible d'employer BF-128-CBC ou un autre algorithme compatible par une classique négociation au début de la connexion. Ainsi la compatibilité reste préservée au maximum, tout en améliorant la sécurité par défaut des clients le pouvant.


Le serveur OpenSSH rejoint la politique centralisée des mots de passe, comme le client OpenSSH, GnuTLS, NSS, OpenSSL et OpenJDK avant lui. En effet, depuis quelques versions de Fedora, les utilitaires pouvant avoir une politique de mots de passe, par exemple de huit caractères avec au moins un chiffre et deux majuscules, bénéficient peu à peu de l’unification de cette politique. En définissant la politique une fois via l’utilitaire update-crypto-policies, elle sera disponible pour l’ensemble des applications compatibles.
Le serveur OpenSSH rejoint la politique centralisée des mots de passe, comme le client OpenSSH, GnuTLS, NSS, OpenSSL et OpenJDK avant lui. En effet, depuis quelques versions de Fedora, les utilitaires pouvant avoir une politique de mots de passe, par exemple de huit caractères avec au moins un chiffre et deux majuscules, bénéficient peu à peu de l’unification de cette politique. En définissant la politique une fois via l’utilitaire update-crypto-policies, elle sera disponible pour l’ensemble des applications compatibles.
Line 67: Line 67:
Installer le paquet ''perl'' installera l'ensemble des modules ''core'' du projet officiel. Ce comportement est plus conforme vis à vis des autres distributions et de ce qui est attendu par les développeurs de Perl. Pour les utilisateurs qui souhaitent un environnement Perl plus léger, comme proposé avant par Fedora, vous pouvez vous rabattre sur le paquet ''perl-interpreter'' qui nécessite moins de modules par défaut.
Installer le paquet ''perl'' installera l'ensemble des modules ''core'' du projet officiel. Ce comportement est plus conforme vis à vis des autres distributions et de ce qui est attendu par les développeurs de Perl. Pour les utilisateurs qui souhaitent un environnement Perl plus léger, comme proposé avant par Fedora, vous pouvez vous rabattre sur le paquet ''perl-interpreter'' qui nécessite moins de modules par défaut.


Les paquets officiels ayant besoin de Java n'utiliseront plus la variable ''$PATH'' pour retrouver la JVM à employer mais directement la JVM fournie par défaut par Fedora (OpenJDK). La méthode employée naviment pour exécuter les applications Java jusqu'à Fedora 26 consistait en :
Les paquets officiels ayant besoin de Java n'utiliseront plus la variable ''$PATH'' pour retrouver la JVM à employer mais directement la JVM fournie par défaut par Fedora (OpenJDK). La méthode employée nativement pour exécuter les applications Java jusqu'à Fedora 26 consistait en :


* Lire le fichier ''/etc/java/java.conf'' ;
* Lire le fichier ''/etc/java/java.conf'' ;
Line 75: Line 75:
* En dernier recours, utiliser directement la variable ''$PATH''.
* En dernier recours, utiliser directement la variable ''$PATH''.


Cette méthode est plutôt complexe et risquée. Un utilisateur pour installer durablement une version alternative de la JVM devait être superutilisateur (pour agir sur l'avant dernière étape) ou pouvait modifier deux variables d'environnements qui pouvaient charger la JVM d'exécution de référence pour les applications fournies par Fedora. Applicatons qui ne sont peut être pas compatibles avec la JVM réclamée par les applications de l'utilisateur.
Cette méthode est plutôt complexe et risquée. Un utilisateur pour installer durablement une version alternative de la JVM devait être superutilisateur (pour agir sur l'avant dernière étape) ou pouvait modifier deux variables d'environnements qui changeaient la JVM d'exécution de référence pour les applications fournies par Fedora. Applications qui ne sont peut être pas compatibles avec la JVM réclamée par les applications de l'utilisateur.


La méthode actuelle consiste en supprimer la dernière étape (pour les applications systèmes). L'utilisateur pourra jouer sur la variable ''$PATH'' pour spécifier la JVM de référence pour ses applications. L'administrateur système pourra toujours changer la JVM pour les applications systèmes via la variable ''$JAVA_HOME'' ou le fichier de configuration mentionné plus haut.
La méthode actuelle consiste en supprimer la dernière étape (pour les applications systèmes). L'utilisateur pourra jouer sur la variable ''$PATH'' pour spécifier la JVM de référence pour ses applications. L'administrateur système pourra toujours changer la JVM pour les applications systèmes via la variable ''$JAVA_HOME'' ou le fichier de configuration mentionné plus haut.
Line 83: Line 83:
Remplacement de l'interface graphique de gestion de paquets Yumex par dnfdragora qui propose une interface Qt, GTK+ et ncurses. Le développement de Yumex s'est arrêté il y a un an, qui met fin à une application ayant accompli dix ans de bons et loyaux services et a même su migrer de ''yum'' vers ''dnf''. dnfdragora présente la particularité de reposer sur rpmdragora, qui vient de Mageia.  
Remplacement de l'interface graphique de gestion de paquets Yumex par dnfdragora qui propose une interface Qt, GTK+ et ncurses. Le développement de Yumex s'est arrêté il y a un an, qui met fin à une application ayant accompli dix ans de bons et loyaux services et a même su migrer de ''yum'' vers ''dnf''. dnfdragora présente la particularité de reposer sur rpmdragora, qui vient de Mageia.  


Ajout de Samba AD pour la gestion des Active Directory. Si FreeIPA et Samba traditionnel sont déjà employés pour déployer les contrôleurs de domaine, ils n'étaient pas capables de gérer les enregistrements et la gestion des des clients Windows 8 et supérieurs. Et jusqu'ici, il était impossible de compiler Samba AD avec MIT Kerberos (employé par Fedora, Debian et Ubuntu exploitant Heimdal Kerberos).
Ajout de Samba AD pour la gestion des Active Directory. Si FreeIPA et Samba traditionnel sont déjà employés pour déployer les contrôleurs de domaine, ils n'étaient pas capables de gérer les enregistrements et la gestion des clients Windows 8 et supérieur. Et jusqu'ici, il était impossible de compiler Samba AD avec MIT Kerberos (employé par Fedora, Debian et Ubuntu exploitant Heimdal Kerberos).


Samba AD est une bonne alternative à l'implémentation de référence de Microsoft. Il serait capable de gérer des déploiements de centaines de milliers d'utilisateurs par groupe sur plusieurs sites. Et ce, avec un matériel considéré comme peu cher ce qui le rend intéressant pour les petites et moyennes structures. L'intéropérabilité avec FreeIPA a été également améliorée ce qui permet aujourd'hui d'employer des environnements entièrement sous Fedora dans ce cadre.
Samba AD est une bonne alternative à l'implémentation de référence de Microsoft. Il serait capable de gérer des déploiements de centaines de milliers d'utilisateurs par groupe sur plusieurs sites. Et ce, avec un matériel considéré comme peu cher ce qui le rend intéressant pour les petites et moyennes structures. L’interopérabilité avec FreeIPA a été également améliorée ce qui permet aujourd'hui d'employer des environnements entièrement sous Fedora dans ce cadre.


Mise à jour de RPM à la version 4.14. Au menu de ce composant central, des erreurs plus lisibles et pertinents, une meilleur fiabilité en désactivant les signaux durant une opération d'écriture, ou avec une fonction de rappel plus sûre si la base de données principale est ouverte. La compatibilité avec les compilations reproductibles est améliorée. Il peut également utiliser OpenSSL pour les opérations cryptographiques. Et l'écart entre le RPM officiel et celui de Fedora s'est également réduit.
Mise à jour de RPM à la version 4.14. Au menu de ce composant central, des erreurs plus lisibles et pertinentes, une meilleur fiabilité en désactivant les signaux durant une opération d'écriture, ou avec une fonction de rappel plus sûre si la base de données principale est ouverte. La compatibilité avec les compilations reproductibles est améliorée. Il peut également utiliser OpenSSL pour les opérations cryptographiques. Et l'écart entre le RPM officiel et celui de Fedora s'est également réduit.


== Développement ==
== Développement ==
Line 93: Line 93:
La bibliothèque standard Glibc progresse à la version 2.26. Cette version ajoute un cache par fil d'exécution pour ''malloc'' ce qui améliore significativement les performances des allocations et suppressions de petites zones de la mémoire. Comme souvent, elle bénéficie de la dernière norme UNICODE 10.0. Les architectures ia64, powerpc64le, x86-32, et x86-64 peuvent gérer des nombres flottants 128 bits via le type ''_Float128''. Et enfin, le résolveur DNS détecte les changements du fichier ''/etc/resolv.conf'' automatiquement pour le recharger à la volée.
La bibliothèque standard Glibc progresse à la version 2.26. Cette version ajoute un cache par fil d'exécution pour ''malloc'' ce qui améliore significativement les performances des allocations et suppressions de petites zones de la mémoire. Comme souvent, elle bénéficie de la dernière norme UNICODE 10.0. Les architectures ia64, powerpc64le, x86-32, et x86-64 peuvent gérer des nombres flottants 128 bits via le type ''_Float128''. Et enfin, le résolveur DNS détecte les changements du fichier ''/etc/resolv.conf'' automatiquement pour le recharger à la volée.


La bibliothèque majeure du C++ Boost donne un coup de boost à la version 1.64. Elle ajoute une nouvelle bibliothèque ''process'' qui permet la créations de processus enfants, de configurer leur flux d'entrées-sorties, de communiquer avec eux de manière synchrone et asynchrone et bien entendu d'attendre et de tuer ces processus. Un changement de l'API de la partie ''Context''. Puis bien entendu de nombreuses corrections de bogues dans l'ensemble de la bibliothèque.
La bibliothèque majeure du C++ Boost donne un coup de boost à la version 1.64. Elle ajoute une nouvelle bibliothèque ''process'' qui permet la création de processus enfants, de configurer leur flux d'entrées-sorties, de communiquer avec eux de manière synchrone et asynchrone et bien entendu d'attendre et de tuer ces processus. Un changement de l'API de la partie ''Context'' est à noter. Puis comme d'habitude de nombreuses corrections de bogues dans l'ensemble de la bibliothèque.


Le serveur de rendu de JavaScript Node.js s'exécute à la version 8.6 LTS (au lieu de la branche 6.x). Cette onuvelle version majeure fourni ''async_hooks'' dans le module ''core''. Elle ajoute expérimentalement une Node API pour garantir la compatibilité ascendante de l'ABI des modules natifs afin d'éviteur leur recompilation à chaque changement de node.js. Le module interne expérimental pour gérer le protocole HTTP 2 a été ajouté. Le moteur JavaScript V8 a été mise à jour à la version 6.0, plus proche donc de la version disponible dans Google Chrome avec une amélioration des performances.
Le serveur de rendu de JavaScript Node.js s'exécute à la version 8.6 LTS (au lieu de la branche 6.x). Cette nouvelle version majeure fournie ''async_hooks'' dans le module ''core''. Elle ajoute expérimentalement une Node API pour garantir la compatibilité ascendante de l'ABI des modules natifs afin d’éviter leur recompilation à chaque changement de node.js. Le module interne expérimental pour gérer le protocole HTTP 2 a été ajouté. Le moteur JavaScript V8 a été mise à jour à la version 6.0, plus proche donc de la version disponible dans Google Chrome avec une amélioration des performances.


La boîte à outils Web Ruby on Rails 5.1 est sur les rails. Parmi les changements annoncés, nous pouvons noter la possibilité d'utiliser ''NPM'' via Yarn pour résoudre les dépendances de JavaScript ce qui simplifie l'usage de bibliothèques telles que React ou VueJS. Il devient possible d'utiliser Webpack via le gem ''Webpacker'' afin d'assembler les différents éléments de votre applications dans un seul fichier JavaScript automatiquement. La bibliothèque jQuery n'est plus une dépendance obligatoire. Il devient possible de facilement insérer des données secrètes dans un fichier chiffré prévu à cet effet, mécanisme inspiré du gem ''sekrets''. Et bien d'autres changements.
La boîte à outils Web Ruby on Rails 5.1 est sur les rails. Parmi les changements annoncés, nous pouvons noter la possibilité d'utiliser ''NPM'' via Yarn pour résoudre les dépendances de JavaScript ce qui simplifie l'usage de bibliothèques telles que React ou VueJS. Il devient possible d'utiliser Webpack via le gem ''Webpacker'' afin d'assembler les différents éléments de votre applications dans un seul fichier JavaScript automatiquement. La bibliothèque jQuery n'est plus une dépendance obligatoire. Il devient possible de facilement insérer des données secrètes dans un fichier chiffré prévu à cet effet, mécanisme inspiré du gem ''sekrets''. Et bien d'autres changements.


Le langage Go fonce à la version 1.9. Il devient possible de spécifier que deux types pointent vers le même type via l'instruction ''type T1 = T2'', où T1 et T2 sont deux alias d'un même type. L'instruction suivie d'une addition, qui est souvent optimisé par les processeurs modernes, supprime la nécessité de l'arrondi intermédiaire lors du calcul. Pour la réactiver, vous pouvez faire ''float64(x*y) + z'' ce qui dégrade bien sûr les performances. La compilation des différents paquets se fait maintenant en parallèle. Le code généré est également plus rapide maintenant, le ramasse miette est également plus performant. Le paquet ''time'' prend en charge nativement le temps monotonique pour éviter les problèmes de saut du temps (à cause d'une synchronisation NTP par exemple). Enfin, ajout d'un nouveau paquet ''math/bits'' pour la manipulation des bits. Et d'autres corrections encore.
Le langage Go fonce à la version 1.9. Il devient possible de spécifier que deux types pointent vers le même type via l'instruction ''type T1 = T2'', où T1 et T2 sont deux alias d'un même type. L'instruction multiplication suivie d'une addition, qui est souvent optimisée par les processeurs modernes, supprime la nécessité de l'arrondi intermédiaire lors du calcul. Pour la réactiver, vous pouvez faire ''float64(x*y) + z'' ce qui dégrade bien sûr les performances. La compilation des différents paquets se fait maintenant en parallèle. Le code généré est également plus rapide maintenant, le ramasse miette est également plus performant. Le paquet ''time'' prend en charge nativement le temps monotonique pour éviter les problèmes de saut du temps (à cause d'une synchronisation NTP par exemple). Enfin, ajout d'un nouveau paquet ''math/bits'' pour la manipulation des bits. Et d'autres corrections encore.


Le langage Perl a été poli à la version 5.26. Pour des raisons de sécurité, le répertoire courant ''.'' est supprimé de la recherche des chemins ''@INC'' pour éviter de charger des modules provenant d'un répertoire non sûr. Perl gère maintenant l'UNICODE 9.0. Les sous-routines lexicaux ne sont plus expérimentaux. Et d'autres changements plus mineurs ou de problèmes résolus.
Le langage Perl a été poli à la version 5.26. Pour des raisons de sécurité, le répertoire courant ''.'' est supprimé de la recherche des chemins ''@INC'' pour éviter de charger des modules provenant d'un répertoire non sûr. Perl gère maintenant l'UNICODE 9.0. Les sous-routines lexicaux ne sont plus expérimentaux. Et d'autres changements plus mineurs ou de problèmes résolus.
Line 105: Line 105:
La nouvelle version de la machine virtuelle OpenJDK danse la Java pour une 9e fois. Bien entendu après quelques années, Java se met à niveau avec l'inclusion d'UNICODE 8.0, le port vers l'architecture AARCH64, l'utilisation de GTK+3 pour les interfaces graphiques sous Linux et l'ajout d'un client HTTP2. Côté sécurité, Java supporte le protocole applicatif de négociation de TLS, et remplace la fonction de hashage SHA-1 par SHA-3. OpenJDK devient plus modulaire, les modules standards sont placés derrière le préfixe ''java.'', les autres derrière ''jdk.''. Et bien entendu tous les changements apportés par le langage Java 9 lui même.
La nouvelle version de la machine virtuelle OpenJDK danse la Java pour une 9e fois. Bien entendu après quelques années, Java se met à niveau avec l'inclusion d'UNICODE 8.0, le port vers l'architecture AARCH64, l'utilisation de GTK+3 pour les interfaces graphiques sous Linux et l'ajout d'un client HTTP2. Côté sécurité, Java supporte le protocole applicatif de négociation de TLS, et remplace la fonction de hashage SHA-1 par SHA-3. OpenJDK devient plus modulaire, les modules standards sont placés derrière le préfixe ''java.'', les autres derrière ''jdk.''. Et bien entendu tous les changements apportés par le langage Java 9 lui même.


''Make sudo pip safe again!'' qui propose enfin un meilleur nettoyage lors de la désinstallation d'un module installé via pip et une meilleure séparation entre les modules de Fedora et ceux des utilisateurs. En effet, jusqu'ici, les modules installés via ''sudo pip install'' allaient s'installer au même endroit que les modules installés via dnf ce qui induisait un conflit entre les deux mécanismes. Pour régler ce problème, les modules installés sans dnf sont installés dans le dossier ''/usr/local/lib/pythonX.Y/'' ce qui est en plus conforme aux standard '' Filesystem Hierarchy Standard''.
''Make sudo pip safe again!'' qui propose enfin un meilleur nettoyage lors de la désinstallation d'un module installé via pip et une meilleure séparation entre les modules de Fedora et ceux des utilisateurs. En effet, jusqu'ici, les modules installés via ''sudo pip install'' allaient s'installer au même endroit que les modules installés via dnf ce qui induisait un conflit entre les deux mécanismes. Pour régler ce problème, les modules installés sans dnf sont installés dans le dossier ''/usr/local/lib/pythonX.Y/'' ce qui est en plus conforme au standard ''Filesystem Hierarchy Standard''.


Il est possible d'installer les paquets de débogue (les debuginfo) 32 et 64 bits pour une même application en même temps. Car typiquement, sous Fedora x86_64, il est possible d'installer des paquets en 32 ou 64 bits car il y a compatibilité ascendante de l'architecture. Dans certaines situations où les deux sont installées en parallèle, cas de nombreuses bibliothèques, il est possible de faire de même pour les informations de débogues. Cela simplifiera la tâche des développeurs et des testeurs pour identifier les problèmes des applications multi-architectures.
Il est possible d'installer les paquets de débogue (les debuginfo) 32 et 64 bits pour une même application en même temps. Typiquement, sous Fedora x86_64, il est possible d'installer des paquets en 32 ou 64 bits car il y a compatibilité ascendante de l'architecture. Dans certaines situations où les deux sont installés en parallèle, cas de nombreuses bibliothèques, il est possible de faire de même pour leurs informations de débogue. Cela simplifiera la tâche des développeurs et des testeurs pour identifier les problèmes des applications multi-architectures.


Les paquets ''debuginfos'' sont scindés en ''debuginfos'' et ''debugsources''. Le premier contient les binaires et autres bibliothèques avec les symboles de débogage tandis que les seconds contiennent uniquement le code source du paquet. Cela permet non seulement de ne télécharger et installer que le strict nécessaire au débogue (les sources ne sont pas toujours requis) et va dans le sens d'harmoniser les pratiques autours du format RPM avec d'autres distributions.
Les paquets ''debuginfos'' sont scindés en ''debuginfos'' et ''debugsources''. Le premier contient les binaires et autres bibliothèques avec les symboles de débogage tandis que les seconds contiennent uniquement le code source du paquet. Cela permet non seulement de ne télécharger et installer que le strict nécessaire au débogue (les sources ne sont pas toujours requis) et va dans le sens d'harmoniser les pratiques autours du format RPM avec d'autres distributions.
Line 115: Line 115:
Création et mise à jour des outils dans le cadre de la Factory 2.0 pour permettre le découplage entre la version d'un paquet, la version de rattachement dans Fedora et sa fin de vie. Le principal concerné est l'outil ''pkgdb'', la pièce maîtresse de Fedora qui contient la liste des paquets, permet d'en créer un nouveau, d'en faire une revue, de lire leurs métadonnées, le lien avec les versions de Fedora et bien entendu les développeurs / empaqueteurs responsables de leur maintenance. Jusqu'ici, cet outil associait à chaque paquet une branche nommée par exemple ''f26'' pour signifier qu'il est disponible dans Fedora 26 et dont la fin de vie de cette branche est la même que Fedora 26.
Création et mise à jour des outils dans le cadre de la Factory 2.0 pour permettre le découplage entre la version d'un paquet, la version de rattachement dans Fedora et sa fin de vie. Le principal concerné est l'outil ''pkgdb'', la pièce maîtresse de Fedora qui contient la liste des paquets, permet d'en créer un nouveau, d'en faire une revue, de lire leurs métadonnées, le lien avec les versions de Fedora et bien entendu les développeurs / empaqueteurs responsables de leur maintenance. Jusqu'ici, cet outil associait à chaque paquet une branche nommée par exemple ''f26'' pour signifier qu'il est disponible dans Fedora 26 et dont la fin de vie de cette branche est la même que Fedora 26.


Mais dans le cadre de la modularité, il est possible que plusieurs branches d'un paquet soient disponibles pour une même version de Fedora grâce aux différents modules. Donc l’outil a été profondément remaniè pour permettre à un module de spécifier n'importe quelle branche d'un paquet et de définir sa propre date de fin de vie plutôt que celle d'une version de la distribution.
Mais dans le cadre de la modularité, il est possible que plusieurs branches d'un paquet soient disponibles pour une même version de Fedora grâce aux différents modules. Donc l’outil a été profondément remanié pour permettre à un module de spécifier n'importe quelle branche d'un paquet et de définir sa propre date de fin de vie plutôt que celle d'une version de la distribution.


Séparation du ''Base Runtime'' en ''Plateforme'' et ''Hôte'', le premier prenant en charge l'espace utilisateur et la base du système quand le second s'occupe uniquement de la gestion du matériel. En somme, la seconde partie contient le noyau, le chargeur de démarrage, les firmwares et quelques pilotes. Dans le cadre de la modularité, le but de ce changement est de découpler la gestion du matériel du reste du système pour proposer des cycles de vie différents et autonomes. L'utilisateur pourra ainsi bénéficier de plus de souplesse, comme avoir la dernière version du support du matériel avec le reste de Fedora un peu plus ancien ou inversement. À terme, on pourrait avoir une sorte de gestion de matériel fournie par Fedora 27 avec un espace utilisateur fourni par Fedora 28. Ou inversement selon le cas d'usage.
Séparation du ''Base Runtime'' en ''Plateforme'' et ''Hôte'', le premier prenant en charge l'espace utilisateur et la base du système quand le second s'occupe uniquement de la gestion du matériel. En somme, la seconde partie contient le noyau, le chargeur de démarrage, les firmwares et quelques pilotes. Dans le cadre de la modularité, le but de ce changement est de découpler la gestion du matériel du reste du système pour proposer des cycles de vie différents et autonomes. L'utilisateur pourra ainsi bénéficier de plus de souplesse, comme avoir la dernière version du support du matériel avec le reste de Fedora un peu plus ancien et inversement. À terme, on pourrait avoir une sorte de gestion de matériel fournie par Fedora 27 avec un espace utilisateur fourni par Fedora 28. Ou inversement selon le cas d'usage.


L'édition Fedora Server reçoit les premiers travaux officiels pour gérer la modularité, alors qu'elle a été testée par l'édition spéciale Boltron lors de Fedora 26. L'objectif est de mettre en place la modularité dans une image officielle de Fedora et non annexe comme l'a été Boltron. Cela permettra aux administrateurs systèmes de prendre en main le projet de manière plus large pour bénéficier d'un maximum de retours. Il sera également possible de voire le comportement de la modularité durant le cycle de vie complet de Fedora 27.
L'édition Fedora Server reçoit les premiers travaux officiels pour gérer la modularité, alors qu'elle a été testée par l'édition spéciale Boltron lors de Fedora 26. L'objectif est de mettre en place la modularité dans une image officielle de Fedora et non annexe comme l'a été Boltron. Cela permettra aux administrateurs systèmes de prendre en main le projet de manière plus large pour bénéficier d'un maximum de retours. Il sera également possible de voir le comportement de la modularité durant le cycle de vie complet de Fedora 27.


Comme pour Fedora 26, je vous invite à consulter la [https://docs.pagure.org/modularity/ documentation de la modularité] et leur [https://www.youtube.com/channel/UC4O8G9SZwqtkIAuKcT8-JpQ chaine Youtube] pour en apprendre plus à ce sujet. Il est d'ailleurs très probable à cause de ce changement que l'image Fedora Server soit proposée quelques jours après la sortie officielle.
Comme pour Fedora 26, je vous invite à consulter la [https://docs.pagure.org/modularity/ documentation de la modularité] et leur [https://www.youtube.com/channel/UC4O8G9SZwqtkIAuKcT8-JpQ chaine Youtube] pour en apprendre plus à ce sujet. Il est d'ailleurs très probable à cause de ce changement que l'image Fedora Server soit proposée quelques jours après la sortie officielle.
Line 137: Line 137:
[https://www.borsalinux-fr.org/ Borsalinux-fr] est l'association qui gère la promotion de Fedora dans l'espace francophone. Nous constatons depuis quelques années une baisse progressive des membres à jour de cotisation et de volontaires pour prendre en main les activités dévolues à l'association.
[https://www.borsalinux-fr.org/ Borsalinux-fr] est l'association qui gère la promotion de Fedora dans l'espace francophone. Nous constatons depuis quelques années une baisse progressive des membres à jour de cotisation et de volontaires pour prendre en main les activités dévolues à l'association.


Nous lançons donc un appel à nous rejoindre, à nous aider.
Nous lançons donc un appel à nous rejoindre et de nous aider.


L'association est en effet propriétaire du [https://www.fedora-fr.org/ site officiel de la communauté francophone de Fedora], organise des évènements promotionnels comme les Rencontres Fedora régulièrement et participe à l'ensemble des évènements majeurs concernant le libre.
L'association est en effet propriétaire du [https://www.fedora-fr.org/ site officiel de la communauté francophone de Fedora], organise des évènements promotionnels comme les Rencontres Fedora régulièrement et participe à l'ensemble des évènements majeurs concernant le libre.
Line 143: Line 143:
Si vous aimez Fedora, et que vous souhaitez que notre action perdure, vous pouvez :
Si vous aimez Fedora, et que vous souhaitez que notre action perdure, vous pouvez :


* [https://www.borsalinux-fr.org/pages/Adh%C3%A9rer Adhérer à l'association] : les cotisations nous aidant à produire des goodies, à nous déplacer pour les évènements, à payer le matériel ;
* [https://www.borsalinux-fr.org/pages/Adh%C3%A9rer Adhérer à l'association] : les cotisations nous aident à produire des goodies, à nous déplacer pour les évènements, à payer le matériel ;
* Participer sur le forum, les listes de diffusion, à la réfection de la documentation, représenter l'association sur différents évènements ;
* Participer sur le forum, les listes de diffusion, à la réfection de la documentation, représenter l'association sur différents évènements francophones ;
* Concevoir des goodies ;
* Concevoir des goodies ;
* Organiser des évènements type Rencontres Fedora dans votre ville.
* Organiser des évènements type Rencontres Fedora dans votre ville.
Line 150: Line 150:
Nous serions ravis de vous accueillir et de vous aider dans vos démarches. Toute contribution même minime est appréciée.
Nous serions ravis de vous accueillir et de vous aider dans vos démarches. Toute contribution même minime est appréciée.


Si vous souhaitez avoir un aperçu de notre activité, vous pouvez participer à nos réunions hebdomadaires le lundi soir à 20h30 (heure de Paris) sur IRC (canal #fedora-meeting-1 sur Freenode).
Si vous souhaitez avoir un aperçu de notre activité, vous pouvez participer à nos réunions hebdomadaires chaque lundi soir à 20h30 (heure de Paris) sur IRC (canal #fedora-meeting-1 sur Freenode).


=== La traduction ===
=== La traduction ===
Line 167: Line 167:
== Fedora 28 ==
== Fedora 28 ==


Fedora 28 doit sortir courant du mois de mai 2018.
Fedora 28 doit sortir durant du mois de mai 2018.


Parmi les nouveautés prévues à ce stade :
Parmi les nouveautés prévues à ce stade :

Revision as of 11:19, 16 October 2017

Dépêche sous licence CC BY-SA

En ce mardi 7 novembre 2017, le projet Fedora est fier d’annoncer la sortie de la distribution GNU/Linux Fedora 27.

Fedora est une distribution communautaire développée par le projet Fedora et sponsorisée par Red Hat, qui lui fournit des développeurs ainsi que des moyens financiers et logistiques. Fedora peut se voir comme une sorte de vitrine technologique pour le monde du logiciel libre, c’est pourquoi elle est prompte à inclure des nouveautés.

Fedora garde un rôle central dans le développement de ces nouveautés via le développement en amont. En effet, les développeurs de la distribution contribuent également directement au code d’un certain nombre de logiciels libres contenus dans la distribution, dont le noyau Linux, GNOME, NetworkManager, PackageKit, PulseAudio, X.Org, systemd, la célèbre suite de compilateurs GCC, etc. Cliquez ici pour voir l’ensemble des contributions de Red Hat.

Par ailleurs, les distributions telles que RHEL, Scientific Linux ou CentOS (plus indirectement), avec un cycle de sortie plus espacé permettant un support à plus long terme, sont développées à partir d’une version de Fedora et mises à jour environ tous les trois à cinq ans. Notons que CentOS est un clone gratuit de RHEL, cette dernière étant certes libre, mais payante, offrant ainsi un support technique, des certifications et une garantie.

Environnement bureautique

GNOME est toujours à l'honneur avec sa version 3.26. C'est une version essentiellement de polissage et de stabilité avec :

  • La barre principale qui devient transparente, si aucune fenêtre n'est maximisée ;
  • De nouvelles animations, plus fluides, en cas de redimensionnement ou de mouvement des fenêtres ;
  • La recherche globale fonctionne sur des actions du système (comme Éteindre) et affiche plus de résultats à la fois ;
  • Les paramètres du système bénéficient d'une refonte complète de l'interface ;
  • Le logiciel Disques peut enfin redimensionner les partitions, Agenda prenant en charge les évènements récurrents et Web acceptant la synchronisation depuis Firefox Sync ;
  • Amélioration des performances pour quelques applications ou GNOME en général.

Fedora propose une image unique pour l'architecture AARCH64 (ARM 64 bits) ce qui rejoint la solution proposée pour les cartes disposant d'un ARMv7. Pour l'instant cette image prendra en charge les cartes suivantes :

  • Pine64 (et ses variantes)
  • Raspberry Pi 3 (64 bit mode)
  • 96boards HiKey
  • 96boards Dragonboard 410c
  • ARM Juno

L'offre des cartes prises en charge s'étoffera dans le temps, de même que la mise à disposition des versions personnalisées de Fedora.

Toujours à propos du matériel, Fedora a travaillé pour avoir une meilleure gestion des SoC Intel Bay Trail et Cherry Trail (essentiellement des puces Pentium, Celeron et Atom sur portables et tablettes). Le travail a consisté en l'amélioration de la surveillance de la batterie (consommation actuelle, temps restant sur batterie, savoir si la machine est en charge ou non) et de la gestion de l'audio. Les écrans tactiles et les accéléromètres seront également mieux détectés et donc exploitables par le système et les applications.

Fedora 27 peut enfin tourner sur les ordinateurs ayant un UEFI 32 bits tout en ayant un CPU 64 bits. Cela consiste en l'installation d'un GRUB 32 bits (chargé par l'UEFI lui même) qui lui même charge un noyau et l'espace utilisateur en 64 bits. Cette configuration, assez atypique, a nécessité un travail sur GRUB, Anaconda et les utilitaires EFI pour les prendre en charge. Fedora sera ainsi installable sur ces configurations comme l'Asus Transformer T100TA, le HP Stream 7, le Dell Venue 8 Pro 5830 et les premiers Macintosh Intel d'Apple.

Mise à jour de libpinyin vers la version 2.1 pour les entrées de saisi en chinois. Cette version consiste essentielle dans la fusion avec la bibliothèque libzhuyin qu'il remplace. Cela apporte la prise en charge du chinois Zhuyin pour la saisie rapide dans cette langue.

La mise à disposition des polices de caractères Serif pour le chinois par défaut. Jusqu'ici Fedora fournissait surtout des polices Sans pour le chinois. Mais depuis la libération de certaines polices de la part d'Adobe et de Google, il est dorénavant possible de fournir des polices de caractères Serif convenables pour ces utilisateurs nativement.

Administration système

Suppression du script 256term.sh (/etc/profile.d/256term.sh et /etc/profile.d/256term.csh) qui changeait la valeur de la variable $TERM pour activer les couleurs dans les terminaux selon le terminal employé. Maintenant ce sont les émulateurs de terminal qui s'en chargent directement, ce qui rend la procédure plus reproductible, plus simple et plus rapide car le script n'est plus exécuté pour chaque nouveau shell.

Activation de l'option TRIM pour les nouvelles partitions chiffrées avec LUKS1. L'option TRIM permet aux SSD de connaître les cellules mémoires utilisées par le système de fichier afin de pouvoir contrôler l'usure des cellules au mieux en conservant les performances en écriture dans le temps. Les SSD étant de plus en plus populaires, il a été décidé de rendre cela par défaut pour les partitions chiffrés, ce qui aurait un impact négligeable pour ceux qui utilisent un disque dur. Cela consiste à l'ajout natif de l'option discard dans /etc/crypttab. Le manque de place dans les métadonnées de LUKS1 explique pourquoi cela ne concerne que les nouvelles partitions.

Nouveau système de cache par défaut pour les identifiants Kerberos nommé KCM. C'est le 4e système de cache à ce sujet, le premier était basé sur les fichiers, le second sur les répertoires et le 3e sur le porte-clé du noyau. Mais :

  • Celui basé sur les fichiers est certes largement pris en charge, mais il ne peut gérer plusieurs caches pour une même collection ;
  • Celui basé sur les répertoires corrige ce problème, mais cela nécessite son propre contrôle d'accès pour la gestion des répertoires ce qui est délicat ;
  • Le dernier utilisant le noyau, n'est pas adapté pour les environnements isolés (qui partagent le même noyau), ne bénéficiant pas des espaces de noms de l'utilisateur.

L'architecture ici change énormément. Cela va reposer sur un principe client serveur où l'application qui utilise Kerberos comme kinit va communiquer avec un serveur KCM comme sssd. Jusqu'alors seul Heimdal Kerberos implémentait un serveur KCM. Heimdal et MIT ont implémenté un client KCM dans libkrb5. Fedora a proposé d'inclure un serveur KCM dans SSSD, plutôt qu'un démon isolé, pour bénéficier de l'API D-Bus qu'emploie SSSD afin que par exemple une application graphique puisse recevoir les notifications associées, la possibilité de sauvegarder des données secrètes facilement pour exploiter à nouveau le cache en cas de redémarrage et un accès facile à l'authentification de SSSD côté utilisateur, qui est également bien testé.

libcurl réutilise OpenSSL pour la cryptographie et le protocole TLS au lieu de NSS. En effet, il y a 10 ans, c'était la décision inverse que le projet Fedora avait acté. L'objectif de ce revirement est de permettre la conception d'images de base de Fedora plus légères (dans le cadre des conteneurs entre autre). Cela facilite la possibilité d'enlever NSS dans ce genre de contexte nativement. Par contre l'inconvénient est que libcurl ne peut plus exploiter nativement les bases de données de certificats de NSS, dont ceux fournis avec Firefox. Un export est nécessaire pour cela.

Le serveur OpenVPN utilise un nouvel algorithme de chiffrement par défaut qui est AES-256-GCM au lieu de BF-128-CBC améliorant la sécurité des connexions. En effet, il y a un an avec l'attaque SWEET32, il a été révélé que les blocs chiffrés d'une taille de 128 bits et inférieur sont vulnérables. La nouvelle politique passant par défaut à 256 bits, cela évite le problème. Le changement consiste dans la liste d'options par défaut du service openvpn qui était :

   ExecStart=/usr/sbin/openvpn --status %t/openvpn-server/status-%i.log --status-version 2 --suppress-timestamps --config %i.conf

devenant

   ExecStart=/usr/sbin/openvpn --status %t/openvpn-server/status-%i.log --status-version 2 --suppress-timestamps --cipher AES-256-GCM --ncp-ciphers  AES-256-GCM:AES-256-CBC:AES-128-GCM:AES-128-CBC:BF-CBC --config %i.conf

Comme vous le voyez, dans la nouvelle version, AES-256-GCM est employé par défaut mais en cas de clients non compatibles (version 2.3 et inférieur), il reste possible d'employer BF-128-CBC ou un autre algorithme compatible par une classique négociation au début de la connexion. Ainsi la compatibilité reste préservée au maximum, tout en améliorant la sécurité par défaut des clients le pouvant.

Le serveur OpenSSH rejoint la politique centralisée des mots de passe, comme le client OpenSSH, GnuTLS, NSS, OpenSSL et OpenJDK avant lui. En effet, depuis quelques versions de Fedora, les utilitaires pouvant avoir une politique de mots de passe, par exemple de huit caractères avec au moins un chiffre et deux majuscules, bénéficient peu à peu de l’unification de cette politique. En définissant la politique une fois via l’utilitaire update-crypto-policies, elle sera disponible pour l’ensemble des applications compatibles.

Suppression du protocole SSH-1 dans les clients OpenSSH. Ce protocole, de 20 ans d'âge, n'était plus sécurisé. Par ailleurs le projet OpenSSH va supprimer prochainement l'ensemble du code le concernant. Fedora ne le compilait plus dans le binaire standard depuis deux ans, mais le protocole subsistait dans le paquets de compatibilité openssh-clients-ssh1 qui sera supprimé. Cela améliorera la sécurité globale du système en réduisant la surface d'attaque disponible.

Installer le paquet perl installera l'ensemble des modules core du projet officiel. Ce comportement est plus conforme vis à vis des autres distributions et de ce qui est attendu par les développeurs de Perl. Pour les utilisateurs qui souhaitent un environnement Perl plus léger, comme proposé avant par Fedora, vous pouvez vous rabattre sur le paquet perl-interpreter qui nécessite moins de modules par défaut.

Les paquets officiels ayant besoin de Java n'utiliseront plus la variable $PATH pour retrouver la JVM à employer mais directement la JVM fournie par défaut par Fedora (OpenJDK). La méthode employée nativement pour exécuter les applications Java jusqu'à Fedora 26 consistait en :

  • Lire le fichier /etc/java/java.conf ;
  • Si la variable d'environnement $JAVA_HOME existait, charger la JVM qu'elle pointait ;
  • Si cette même variable était définie dans le fichier de configuration, faire de même ;
  • Tenter de trouver via la variable $JVM_ROOT qui valait par défaut /usr/lib/jvm ;
  • En dernier recours, utiliser directement la variable $PATH.

Cette méthode est plutôt complexe et risquée. Un utilisateur pour installer durablement une version alternative de la JVM devait être superutilisateur (pour agir sur l'avant dernière étape) ou pouvait modifier deux variables d'environnements qui changeaient la JVM d'exécution de référence pour les applications fournies par Fedora. Applications qui ne sont peut être pas compatibles avec la JVM réclamée par les applications de l'utilisateur.

La méthode actuelle consiste en supprimer la dernière étape (pour les applications systèmes). L'utilisateur pourra jouer sur la variable $PATH pour spécifier la JVM de référence pour ses applications. L'administrateur système pourra toujours changer la JVM pour les applications systèmes via la variable $JAVA_HOME ou le fichier de configuration mentionné plus haut.

Suppression des paquets krb5-appl-clients et krb5-appl-servers qui ne seront bientôt plus officiellement maintenus et ne sont plus assez sécurisés aujourd'hui. Pour la petite histoire, ces paquets n'ont plus été touchés depuis 2013 par le projet Fedora. Et ces paquets n'ont rien reçu de nouveau depuis 2010 par le projet d'origine.

Remplacement de l'interface graphique de gestion de paquets Yumex par dnfdragora qui propose une interface Qt, GTK+ et ncurses. Le développement de Yumex s'est arrêté il y a un an, qui met fin à une application ayant accompli dix ans de bons et loyaux services et a même su migrer de yum vers dnf. dnfdragora présente la particularité de reposer sur rpmdragora, qui vient de Mageia.

Ajout de Samba AD pour la gestion des Active Directory. Si FreeIPA et Samba traditionnel sont déjà employés pour déployer les contrôleurs de domaine, ils n'étaient pas capables de gérer les enregistrements et la gestion des clients Windows 8 et supérieur. Et jusqu'ici, il était impossible de compiler Samba AD avec MIT Kerberos (employé par Fedora, Debian et Ubuntu exploitant Heimdal Kerberos).

Samba AD est une bonne alternative à l'implémentation de référence de Microsoft. Il serait capable de gérer des déploiements de centaines de milliers d'utilisateurs par groupe sur plusieurs sites. Et ce, avec un matériel considéré comme peu cher ce qui le rend intéressant pour les petites et moyennes structures. L’interopérabilité avec FreeIPA a été également améliorée ce qui permet aujourd'hui d'employer des environnements entièrement sous Fedora dans ce cadre.

Mise à jour de RPM à la version 4.14. Au menu de ce composant central, des erreurs plus lisibles et pertinentes, une meilleur fiabilité en désactivant les signaux durant une opération d'écriture, ou avec une fonction de rappel plus sûre si la base de données principale est ouverte. La compatibilité avec les compilations reproductibles est améliorée. Il peut également utiliser OpenSSL pour les opérations cryptographiques. Et l'écart entre le RPM officiel et celui de Fedora s'est également réduit.

Développement

La bibliothèque standard Glibc progresse à la version 2.26. Cette version ajoute un cache par fil d'exécution pour malloc ce qui améliore significativement les performances des allocations et suppressions de petites zones de la mémoire. Comme souvent, elle bénéficie de la dernière norme UNICODE 10.0. Les architectures ia64, powerpc64le, x86-32, et x86-64 peuvent gérer des nombres flottants 128 bits via le type _Float128. Et enfin, le résolveur DNS détecte les changements du fichier /etc/resolv.conf automatiquement pour le recharger à la volée.

La bibliothèque majeure du C++ Boost donne un coup de boost à la version 1.64. Elle ajoute une nouvelle bibliothèque process qui permet la création de processus enfants, de configurer leur flux d'entrées-sorties, de communiquer avec eux de manière synchrone et asynchrone et bien entendu d'attendre et de tuer ces processus. Un changement de l'API de la partie Context est à noter. Puis comme d'habitude de nombreuses corrections de bogues dans l'ensemble de la bibliothèque.

Le serveur de rendu de JavaScript Node.js s'exécute à la version 8.6 LTS (au lieu de la branche 6.x). Cette nouvelle version majeure fournie async_hooks dans le module core. Elle ajoute expérimentalement une Node API pour garantir la compatibilité ascendante de l'ABI des modules natifs afin d’éviter leur recompilation à chaque changement de node.js. Le module interne expérimental pour gérer le protocole HTTP 2 a été ajouté. Le moteur JavaScript V8 a été mise à jour à la version 6.0, plus proche donc de la version disponible dans Google Chrome avec une amélioration des performances.

La boîte à outils Web Ruby on Rails 5.1 est sur les rails. Parmi les changements annoncés, nous pouvons noter la possibilité d'utiliser NPM via Yarn pour résoudre les dépendances de JavaScript ce qui simplifie l'usage de bibliothèques telles que React ou VueJS. Il devient possible d'utiliser Webpack via le gem Webpacker afin d'assembler les différents éléments de votre applications dans un seul fichier JavaScript automatiquement. La bibliothèque jQuery n'est plus une dépendance obligatoire. Il devient possible de facilement insérer des données secrètes dans un fichier chiffré prévu à cet effet, mécanisme inspiré du gem sekrets. Et bien d'autres changements.

Le langage Go fonce à la version 1.9. Il devient possible de spécifier que deux types pointent vers le même type via l'instruction type T1 = T2, où T1 et T2 sont deux alias d'un même type. L'instruction multiplication suivie d'une addition, qui est souvent optimisée par les processeurs modernes, supprime la nécessité de l'arrondi intermédiaire lors du calcul. Pour la réactiver, vous pouvez faire float64(x*y) + z ce qui dégrade bien sûr les performances. La compilation des différents paquets se fait maintenant en parallèle. Le code généré est également plus rapide maintenant, le ramasse miette est également plus performant. Le paquet time prend en charge nativement le temps monotonique pour éviter les problèmes de saut du temps (à cause d'une synchronisation NTP par exemple). Enfin, ajout d'un nouveau paquet math/bits pour la manipulation des bits. Et d'autres corrections encore.

Le langage Perl a été poli à la version 5.26. Pour des raisons de sécurité, le répertoire courant . est supprimé de la recherche des chemins @INC pour éviter de charger des modules provenant d'un répertoire non sûr. Perl gère maintenant l'UNICODE 9.0. Les sous-routines lexicaux ne sont plus expérimentaux. Et d'autres changements plus mineurs ou de problèmes résolus.

La nouvelle version de la machine virtuelle OpenJDK danse la Java pour une 9e fois. Bien entendu après quelques années, Java se met à niveau avec l'inclusion d'UNICODE 8.0, le port vers l'architecture AARCH64, l'utilisation de GTK+3 pour les interfaces graphiques sous Linux et l'ajout d'un client HTTP2. Côté sécurité, Java supporte le protocole applicatif de négociation de TLS, et remplace la fonction de hashage SHA-1 par SHA-3. OpenJDK devient plus modulaire, les modules standards sont placés derrière le préfixe java., les autres derrière jdk.. Et bien entendu tous les changements apportés par le langage Java 9 lui même.

Make sudo pip safe again! qui propose enfin un meilleur nettoyage lors de la désinstallation d'un module installé via pip et une meilleure séparation entre les modules de Fedora et ceux des utilisateurs. En effet, jusqu'ici, les modules installés via sudo pip install allaient s'installer au même endroit que les modules installés via dnf ce qui induisait un conflit entre les deux mécanismes. Pour régler ce problème, les modules installés sans dnf sont installés dans le dossier /usr/local/lib/pythonX.Y/ ce qui est en plus conforme au standard Filesystem Hierarchy Standard.

Il est possible d'installer les paquets de débogue (les debuginfo) 32 et 64 bits pour une même application en même temps. Typiquement, sous Fedora x86_64, il est possible d'installer des paquets en 32 ou 64 bits car il y a compatibilité ascendante de l'architecture. Dans certaines situations où les deux sont installés en parallèle, cas de nombreuses bibliothèques, il est possible de faire de même pour leurs informations de débogue. Cela simplifiera la tâche des développeurs et des testeurs pour identifier les problèmes des applications multi-architectures.

Les paquets debuginfos sont scindés en debuginfos et debugsources. Le premier contient les binaires et autres bibliothèques avec les symboles de débogage tandis que les seconds contiennent uniquement le code source du paquet. Cela permet non seulement de ne télécharger et installer que le strict nécessaire au débogue (les sources ne sont pas toujours requis) et va dans le sens d'harmoniser les pratiques autours du format RPM avec d'autres distributions.

La modularité

Création et mise à jour des outils dans le cadre de la Factory 2.0 pour permettre le découplage entre la version d'un paquet, la version de rattachement dans Fedora et sa fin de vie. Le principal concerné est l'outil pkgdb, la pièce maîtresse de Fedora qui contient la liste des paquets, permet d'en créer un nouveau, d'en faire une revue, de lire leurs métadonnées, le lien avec les versions de Fedora et bien entendu les développeurs / empaqueteurs responsables de leur maintenance. Jusqu'ici, cet outil associait à chaque paquet une branche nommée par exemple f26 pour signifier qu'il est disponible dans Fedora 26 et dont la fin de vie de cette branche est la même que Fedora 26.

Mais dans le cadre de la modularité, il est possible que plusieurs branches d'un paquet soient disponibles pour une même version de Fedora grâce aux différents modules. Donc l’outil a été profondément remanié pour permettre à un module de spécifier n'importe quelle branche d'un paquet et de définir sa propre date de fin de vie plutôt que celle d'une version de la distribution.

Séparation du Base Runtime en Plateforme et Hôte, le premier prenant en charge l'espace utilisateur et la base du système quand le second s'occupe uniquement de la gestion du matériel. En somme, la seconde partie contient le noyau, le chargeur de démarrage, les firmwares et quelques pilotes. Dans le cadre de la modularité, le but de ce changement est de découpler la gestion du matériel du reste du système pour proposer des cycles de vie différents et autonomes. L'utilisateur pourra ainsi bénéficier de plus de souplesse, comme avoir la dernière version du support du matériel avec le reste de Fedora un peu plus ancien et inversement. À terme, on pourrait avoir une sorte de gestion de matériel fournie par Fedora 27 avec un espace utilisateur fourni par Fedora 28. Ou inversement selon le cas d'usage.

L'édition Fedora Server reçoit les premiers travaux officiels pour gérer la modularité, alors qu'elle a été testée par l'édition spéciale Boltron lors de Fedora 26. L'objectif est de mettre en place la modularité dans une image officielle de Fedora et non annexe comme l'a été Boltron. Cela permettra aux administrateurs systèmes de prendre en main le projet de manière plus large pour bénéficier d'un maximum de retours. Il sera également possible de voir le comportement de la modularité durant le cycle de vie complet de Fedora 27.

Comme pour Fedora 26, je vous invite à consulter la documentation de la modularité et leur chaine Youtube pour en apprendre plus à ce sujet. Il est d'ailleurs très probable à cause de ce changement que l'image Fedora Server soit proposée quelques jours après la sortie officielle.

Le concept du Python Système est revisité et devient la Plateforme Python. L'objectif est de fournir un Python pour les applications systèmes de base comme dnf et rpm (dont le binaire devient /usr/libexec/platform-python) qui puisse différer de celui des autres applications (dont le binaire reste /usr/bin/python). En effet, dans le cadre de la modularité, l'objectif est de séparer la base du système avec le reste des applications afin d'autoriser une certaine souplesse à l'usage. Auparavant, toutes les applications devaient utiliser Python 3.6 par exemple et il était assez compliqué de faire autrement pour l'utilisateur. Avec cette séparation, les outils systèmes pourront rester à Python 3.6 quand les applications pourront bénéficier en simultanée de Python 3.7 ou 3.8 quand ils seront disponibles. Cela autorise également Fedora à embarquer qu'un sous-ensemble de Python pour ses propres applications afin d'alléger le système minimal pour les images destinées aux environnements Cloud.

Autour de Fedora

Comme annoncé, Fedora 27 n'a pas bénéficié et le projet Fedora n'utilisera plus de version Alpha durant son développement grâce à l'amélioration des outils et des procédures de qualité. L'objectif est d'améliorer la qualité de la branche de développement Rawhide de sorte à atteindre la qualité d'une Alpha en permanence. En procédant ainsi, le projet Fedora gagne du temps durant le processus et peut libérer les ressources mobilisées pour produire une Alpha à d'autres tâches. En effet, la sortie d'une version Alpha nécessite des ressources pour gérer le processus, geler le développement, identifier et corriger les bogues bloquants, communiquer autour de sa sortie, mettre à jour les sites web, construire des images spécifiques, les tester…

L'utilitaire Bodhi, qui sert notamment au déploiement et aux retours des mises à jours RPM et des ISO de Fedora, peut prendre en charge les applications Flatpak, OStrees, les images Docker, etc. Cela va dans le sens d'améliorer la qualité des produits de Fedora. Il devient ainsi possible de noter la mise à jour de ces fichiers suivant si elle est bonne ou non (ce que l'on appelle le karma), de facilement remonter les problèmes vers le Bugzilla du projet, d'exécuter les tests automatisés ou encore d'envoyer des courriels aux listes de diffusion concernées.

La communauté francophone

L'association

Borsalinux-fr est l'association qui gère la promotion de Fedora dans l'espace francophone. Nous constatons depuis quelques années une baisse progressive des membres à jour de cotisation et de volontaires pour prendre en main les activités dévolues à l'association.

Nous lançons donc un appel à nous rejoindre et de nous aider.

L'association est en effet propriétaire du site officiel de la communauté francophone de Fedora, organise des évènements promotionnels comme les Rencontres Fedora régulièrement et participe à l'ensemble des évènements majeurs concernant le libre.

Si vous aimez Fedora, et que vous souhaitez que notre action perdure, vous pouvez :

  • Adhérer à l'association : les cotisations nous aident à produire des goodies, à nous déplacer pour les évènements, à payer le matériel ;
  • Participer sur le forum, les listes de diffusion, à la réfection de la documentation, représenter l'association sur différents évènements francophones ;
  • Concevoir des goodies ;
  • Organiser des évènements type Rencontres Fedora dans votre ville.

Nous serions ravis de vous accueillir et de vous aider dans vos démarches. Toute contribution même minime est appréciée.

Si vous souhaitez avoir un aperçu de notre activité, vous pouvez participer à nos réunions hebdomadaires chaque lundi soir à 20h30 (heure de Paris) sur IRC (canal #fedora-meeting-1 sur Freenode).

La traduction

La documentation

Depuis juin 2017, un grand travail de nettoyage a été entrepris sur la documentation francophone de Fedora, pour rattraper les 5 années de retard accumulés sur le sujet.

Le moindre que l'on puisse dire, c'est que le travail abattu est important : près de XX articles corrigés et remis au goût du jour depuis. Un grand merci à Charles-Antoine Couret, Nicolas Berrehouc, Édouard Duliège et les autres contributeurs et relecteurs pour leurs contributions.

L'équipe se réunit tous les lundis soir après 21h (heure de Paris) sur IRC (canal #fedora-doc-fr sur Freenode) pour faire progresser la documentation par un travail collaboratif. Le reste de la semaine cela se passe sur les listes de diffusion.

Si vous avez des idées d'articles ou de corrections à effectuer, que vous avez une compétence technique à retransmettre, n'hésitez pas à participer.

Fedora 28

Fedora 28 doit sortir durant du mois de mai 2018.

Parmi les nouveautés prévues à ce stade :

  • Suppression de l'outil tcp_wrappers ;

Liens