Fedora-Fr - Communauté francophone Fedora - Linux

Planet de Fedora-Fr : la communauté francophone autour de la distribution Linux Fedora

A propos

Cette page est actualisée toutes les heures.

Cette page est une sélection de blogs autour de Fedora. Fedora-Fr.org décline toute responsabilité au sujet des propos tenus par les auteurs des blogs de ce planet. Leurs propos sont leur entière responsabilité.

Le contenu de ce planet appartient à leurs auteurs respectifs. Merci de consulter leur blogs pour obtenir les licences respectives.

AMC version 1.3.0 Fedora 27

Patrice Kadionik

Les RPM d'AMC (Auto Multiple Choice) version 1.3.0 pour Fedora 27 sont disponibles dans le dépôt eddy33.


Installation :

# dnf install http://kadionik.vvv.enseirb-matmeca.fr/fedora/eddy33-release-27.rpm
# dnf install auto-multiple-choice

++

PHP version 7.2.1RC1

Remi Collet

Les versions Release Candidate sont disponibles dans le dépôt remi-test pour Fedora et Enterprise Linux (RHEL / CentOS) afin de permettre au plus grand nombre de les tester. Elles sont  fournit en Software Collections, pour une installation en parallèle, solution idéale pour ce type de tests. (uniquement pour x86_64) et également en paquets de base.

Les RPM de PHP version 7.2.1RC1 sont disponibles en SCL dans le dépôt remi-test et les paquets de base dans le dépôt remi-php72-test pour Fedora 25-27 et Enterprise Linux.

PHP Version 7.2.1 est planifiée pour  le 4 janvier.

emblem-notice-24.pngInstallation : voir la Configuration du dépôt et choisir la version.

Installation en parallèle, en Software Collections de PHP 7.2 :

yum --enablerepo=remi-test install php72

Mise à jour, de PHP 7.2:

yum --enablerepo=remi-php72,remi-php71-test update php\*

A noter : la version 7.2.1RC1 est aussi disponible dans Fedora rawhide.

emblem-notice-24.pngLes paquets pour EL-7 on été construit à partir de RHEL-7.4.

emblem-notice-24.pngLa version RC est généralement identique à la version finale (aucun changement accepté, à l'exception de correctifs de sécurité).

Software Collections (php72)

Paquets standards (php)

Fin de vie de Fedora 25

Charles-Antoine Couret

C'est en ce mardi 12 décembre 2017 que Fedora 25 a été déclaré comme en fin de vie.

Qu'est-ce que c'est ?

Un mois après la sortie d'une version de Fedora n, ici Fedora 27, la version n-2 (donc Fedora 25) est déclarée comme en fin de vie. Ce mois sert à donner du temps aux utilisateurs pour faire la mise à niveau. Ce qui fait qu'en moyenne une version est officiellement maintenue pendant 13 mois.

En effet, la fin de vie d'une version signifie qu'elle n'aura plus de mises à jour et plus aucun bogue ne sera corrigé. Pour des questions de sécurité, avec des failles non corrigées, il est vivement conseillé aux utilisateurs de Fedora 25 et antérieurs d'effectuer la mise à niveau vers Fedora 27 ou 26.

Que faire ?

Si vous êtes concernés, il est nécessaire de faire la mise à niveau de vos systèmes. Vous pouvez télécharger des images CD ou USB plus récentes.

Il est également possible de faire la mise à niveau sans réinstaller via DNF ou GNOME Logiciels.

GNOME Logiciels a également dû vous prévenir par une pop-up de la disponibilité de Fedora 26 ou 27. N'hésitez pas à lancer la mise à niveau par ce biais.

Compte rendu des JM2L 2017

Charles-Antoine Couret

Le samedi 25 novembre dernier, j'ai représenté avec Nicolas Chauvet l'association Borsalinux-fr dans le cadre de la Journée Méditerranéenne du Logiciel Libre.

JM2L-Stand.jpg

Bien qu'il y avait moins de visiteurs que lors de la précédente édition en 2015, nous avons pu discuter ou aider avec une quinzaine de personnes à propos de Fedora. Que ce soit des utilisateurs de longue date, ou de simples curieux.

Le matin nous avons été interrogé par France 3 Côte d'Azur (dont la diffusion a été le dimanche 26 au soir au JT local) à propos des Logiciels Libres en général. Je précise que contrairement à ce qui est indiqué sur l'image, je ne suis pas un employé de Red Hat. C'est une erreur de la journaliste en question. De même, l'équipe de Nice-Matin a couvert l'évènement avec une belle photo de groupe des participants.

L'après-midi nous avons continué le stand et j'ai présenté ma conférence à 15h sur Les apports de Fedora Workstation à l'écosystème du Logiciel Libre. Elle a été suivie par une quinzaine de personnes. L'ensemble du contenu sera disponible bientôt sur quelques sites web francophones dont mon blog.

C'était une chouette journée, bravo aux organisateurs et à dans deux ans pour une prochaine édition !

Les élections au sein du projet Fedora en cours sont retardées

Charles-Antoine Couret

J'avais annoncé cette semaine l'ouverture des votes pour différents organes du projet Fedora : le conseil, FESCo et FAmSCo..

Tout d'abord j'ai oublié en effet qu'il a été décidé de remplacer le FAmSCo par Mindshare, qui n'est pas un simple changement de nom car cette organe a des représentants de plus d'équipes sociales du projet que seulement les ambassadeurs. Mais cela n'est pas l'objet de ce billet.

Le scrutin mentionné plus haut a été reporté depuis le 8 décembre à une date ultérieure, apparemment début janvier 2018. L'objet de ce report vient en fait de la décision de réformer un peu l'organisation des élections afin notamment de publier des entretiens de chaque candidat à la date d'ouverture des élections. Seulement, certains candidats n'ont pas pu poster à temps leur réponse pour des raisons de temps ou des difficultés techniques côté infrastructure de Fedora.

Par soucis d'équité et de cohérence, tous les scrutins ont été décalés par décision du conseil de Fedora.

Bon courage aux candidats et aux organisateurs, en espérant que la prochaine élection se déroule sans accroc !

PHP version 7.0.27RC1 et 7.1.13RC1

Remi Collet

Les versions Release Candidate sont disponibles dans le dépôt remi-test pour Fedora et Enterprise Linux (RHEL / CentOS) afin de permettre au plus grand nombre de les tester. Elles sont  fournit en Software Collections, pour une installation en parallèle, solution idéale pour ce type de tests. (uniquement pour x86_64) et également en paquets de base.

Les RPM de PHP version 7.1.13RC1 sont disponibles en SCL dans le dépôt remi-test et les paquets de base dans le dépôt remi-test pour Fedora 26-27 ou  remi-php71-test pour Fedora 24-25 et Enterprise Linux.

Les RPM de PHP version 7.0.27RC1 sont disponibles en SCL dans le dépôt remi-test et les paquets de base dans le dépôt remi-test pour Fedora 25 ou remi-php70-test pour Fedora 24 et Enterprise Linux.

PHP Version 5.6 est désormais en mode maintenance de sécurité, il n'y aura donc plus de Release Candidate.

PHP Version 7.2.1RC1 est planifiée pour la semaine prochaine. Les versions stables sont planifiées pour le 4 janvier.

emblem-notice-24.pngInstallation : voir la Configuration du dépôt et choisir la version.

Installation en parallèle, en Software Collections de PHP 7.0 :

yum --enablerepo=remi-test install php70

Installation en parallèle, en Software Collections de PHP 7.1 :

yum --enablerepo=remi-test install php71

Mise à jour, de PHP 7.0 :

yum --enablerepo=remi-php70,remi-php70-test update php\*

Mise à jour, de PHP 7.1:

yum --enablerepo=remi-php71,remi-php71-test update php\*

A noter : la version 7.1.13RC1 est aussi disponible dans Fedora 27 et la version 7.2.0 dans Fedora rawhide.

emblem-notice-24.pngLes paquets pour EL-7 on été construit à partir de RHEL-7.4.

emblem-notice-24.pngLa version RC est généralement identique à la version finale (aucun changement accepté, à l'exception de correctifs de sécurité).

Software Collections (php70, php71)

Paquets standards (php)

Élections pour le Conseil, FESCo et FAmSCo cette semaine

Charles-Antoine Couret

Comme le projet Fedora est communautaire, une partie du collège des organisations suivantes doit être renouvelée : Council, FESCo et FAmSCo. Et ce sont les contributeurs qui décident. Chaque candidat a bien sûr un programme et un passif qu'ils souhaitent mettre en avant durant leur mandat pour orienter le projet Fedora dans certaines directions. Je vous invite à étudier les propositions des différents candidats pour cela.

J'ai voté

Pour voter, il est nécessaire d'avoir un compte FAS actif et de faire son choix sur le site du scrutin. Vous avez jusqu'au mardi 13 décembre à 1h heure française pour le faire. Donc n'attendez pas trop.

Je vais profiter de l'occasion pour résumer le rôle de chacun de ces comités afin de clarifier l'aspect décisionnel du projet Fedora mais aussi visualiser le caractère communautaire de celui-ci.

Council

Le Council est ce qu'on pourrait qualifier le grand conseil du projet. C'est donc l'organe décisionnaire le plus élevé de Fedora. Le conseil définit les objectifs à long terme du projet Fedora et participe à l'organisation de celui-ci pour y parvenir. Cela se fait notamment par le biais de discussions ouvertes et transparentes vis à vis de la communauté.

Mais il gère également l'aspect financier. Cela concerne notamment les budgets alloués pour organiser les évènements, produire les goodies, ou des initiatives permettant de remplir les dits objectifs. Ils ont enfin la charge de régler les conflits personnels importants au sein du projet, tout comme les aspects légaux liés à la marque Fedora.

Les rôles au sein du conseil sont complexes.

Ceux avec droit de vote complet

Tout d'abord il y a le FPL (Fedora Project Leader) qui est le dirigeant du conseil et de facto le représentant du projet. Son rôle est lié à la tenue de l'agenda et des discussions du conseil, mais aussi de représenter le projet Fedora dans son ensemble. Il doit également servir à dégager un consensus au cours des débats. Ce rôle est tenu par un employé de Red Hat et est choisi avec le consentement du conseil en question.

Il y a aussi le FCAIC (Fedora Community Action and Impact Coordinator) qui fait le lien entre la communauté et l'entreprise Red Hat pour faciliter et encourager la coopération. Comme pour le FPL, c'est un employé de Red Hat qui occupe cette position avec l'approbation du conseil.

Il y a deux places destinées à la représentation technique et à la représentation plus marketing / ambassadrice du projet. Ces deux places découlent d'une nomination décidée au sein des organes dédiées à ces activités : le FESCo et le FAmSCo. Ces places sont communautaires mais ce sont uniquement ces comités qui décident des attributions.

Il reste deux places communautaires totalement ouvertes et dont tout le monde peut soumettre sa candidature ou voter. Cela permet de représenter les autres secteurs d'activité comme la traduction ou la documentation mais aussi la voix communautaire au sens la plus large possible. C'est pour l'une de ces places que le vote est ouvert cette semaine !

Ceux avec le droit de vote partiel

Un conseiller en diversité est nommé par le FPL avec le soutien du conseil pour favoriser l'intégration au sein du projet des populations le plus souvent discriminées. Son objectif est donc de déterminer les programmes pour régler cette problématique et résoudre les conflits associés qui peuvent se présenter.

Un gestionnaire du programme Fedora qui s'occupe du planning des différentes versions de Fedora. Il s'assure du bon respect des délais, du suivi des fonctionnalités et des cycles de tests. Il fait également office de secrétaire du conseil. C'est un employé de Red Hat qui occupe ce rôle toujours avec l'approbation du conseil.

FESCo

Le FESCo (Fedora Engineering Steering Committee) est un conseil entièrement composé de membres élus et totalement dévoués à l'aspect technique du projet Fedora.

Ils vont donc traiter en particulier les points suivants :

  • Les nouvelles fonctionnalités de la distribution ;
  • Les sponsors pour le rôle d'empaqueteur (ceux qui pourront donc superviser un débutant) ;
  • La création et la gestion des SIGs (Special Interest Group) pour organiser des équipes autour de certaines thématiques ;
  • La procédure d'empaquetage des paquets.

Le responsable de ce groupe est tournant. Les 9 membres sont élus pour un an, sachant que chaque élection renouvelle la moitié du collège.

FAmSCo

Le FAmSCo (Fedora Ambassadors Steering Committee) est l'équivalent du FESCo sur l'aspect plus humain du projet. Pendant que le FESCo se préoccupera beaucoup plus des empaqueteurs, la préoccupation de ce conseil est plutôt l'ambassadeur.

Voici un exemple des thèmes dont il a compétence :

  • Gérer l'accroissement des ambassadeurs à travers le mentoring ;
  • Pousser à la création et au développement des communautés plus locales comme la communauté française par exemple ;
  • Réaliser le suivi des évènements auxquels participent les ambassadeurs ;
  • Accorder les ressources aux différentes communautés ou activités, en fonction des besoin et de l'intérêt ;
  • S'occuper des conflits entre ambassadeurs.

Les 7 membres de cette équipe sont également entièrement élus avec une durée de mandat d'un an. Chaque élection renouvelle le collège par moitié.

Installer PHP 7.2 sur CentOS, RHEL ou Fedora

Remi Collet

Voici un guide rapide pour mettre à jour le PHP fournit par Fedora, RHEL ou CentOS par la dernière version 7.2.

 

Configuration des dépôts:

Sur Fedora, les dépôts standards sont suffisant, sur Enterprise Linux (RHEL, CentOS) il est aussi nécessaire de configurer le dépôt Extra Packages for Enterprise Linux (EPEL), et sur RHEL d'activer le canal optional.

Fedora 27

wget http://rpms.remirepo.net/fedora/remi-release-27.rpm
dnf install remi-release-27.rpm

Fedora 26

wget http://rpms.remirepo.net/fedora/remi-release-26.rpm
dnf install remi-release-26.rpm

RHEL version 7.4

wget https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm
wget http://rpms.remirepo.net/enterprise/remi-release-7.rpm
rpm -Uvh remi-release-7.rpm epel-release-latest-7.noarch.rpm
subscription-manager repos --enable=rhel-7-server-optional-rpms

RHEL version 6.9

wget https://dl.fedoraproject.org/pub/epel/epel-release-latest-6.noarch.rpm
wget http://rpms.remirepo.net/enterprise/remi-release-6.rpm
rpm -Uvh remi-release-6.rpm epel-release-latest-6.noarch.rpm
rhn-channel --add --channel=rhel-$(uname -i)-server-optional-6

CentOS version 7.4

wget https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm
wget http://rpms.remirepo.net/enterprise/remi-release-7.rpm
rpm -Uvh remi-release-7.rpm epel-release-latest-7.noarch.rpm

CentOS version 6.8

wget https://dl.fedoraproject.org/pub/epel/epel-release-latest-6.noarch.rpm
wget http://rpms.remirepo.net/enterprise/remi-release-6.rpm
rpm -Uvh remi-release-6.rpm epel-release-latest-6.noarch.rpm

 

Activation du dépôt remi-php72

Les paquets sont dans les dépôts remi-safe (activé par défaut) et remi-php72 qui n'est pas activé par défaut (choix de l'administrateur en fonction de la version de PHP souhaitée).

RHEL et CentOS

yum install yum-utils
yum-config-manager --enable remi-php72

Fedora

dnf install dnf-plugins-core
dnf config-manager --set-enabled remi-php72

 

Mise à jour de PHP

Par choix, les paquets ont le même nom que les paquets fournit par défaut avec le système, une simple mise à jour est donc suffisante :

yum update

Et c'est tout :)

$ php -v
PHP 7.2.0 (cli) (built: Nov 28 2017 10:27:47) ( NTS )
Copyright (c) 1997-2017 The PHP Group
Zend Engine v3.2.0, Copyright (c) 1998-2017 Zend Technologies
    with Zend OPcache v7.2.0, Copyright (c) 1999-2017, by Zend Technologies
    with Xdebug v2.6.0alpha1, Copyright (c) 2002-2017, by Derick Rethans

 

Problèmes connus

La mise à jour peut échouer (c'est voulu) lorsque certaines extensions présentes ne sont pas encore compatibles avec PHP 7.

Voir la liste des compatibilité : PECL extensions RPM status

Si elles ne sont pas indispensables, vous pouvez les désinstaller avant la mise à  jour, sinon, il faudra patienter.

Attention : quelques extensions sont encore en phase de développement (xdebug...), mais il m'a semblait utile de les fournir afin de permettre la mise à jour au plus grand nombre, et aussi permettre leur test et des retours vers les auteurs.

 

Plus d'informations

Si vous souhaitez une installation en parallèle de la version par défaut de PHP, cela est possible en utilisant les paquets préfixés php72 Voir le billet PHP 7.2 en Software Collection.

Vous pouvez aussi utiliser le nouvel assistant de configuration.

Les paquets présents dans le dépôt seront utilisés comme source pour Fedora 28 (la proposition de changement, reportée pour F27, a déjà été acceptée).

En fournissant une pile complète, environ 150 extensions disponibles, 4 versions de PHP, paquets de base et SCL, pour Fedora et Enterprise Linux, et avec 200 000 téléchargements par jour, le dépôt remi est devenu en 12 ans une référence pour les utilisateurs de PHP sur les distributions RPM, maintenu par un contributeur actif aux différents projets (Fedora, PHP, PECL...).

Et aussi :

On Air

Matthieu Saulnier

Je voulais vous parler d'une émission de radio plutôt cool qui passe en ce moment dans les câbles : Sang libre

Malheureusement je ne suis pas un bon critique d'émission radiophonique et je ne saurais vous décrire comme il se doit cette émission, si ce n'est qu'elle me plait beaucoup, et que je vous encourage à l'écouter avec une bonne paire d'enceintes...

Vous pouvez télécharger et diffuser, c'est permis !

On Air

Matthieu Saulnier

Je voulais vous parler d'une émission de radio plutôt cool qui passe en ce moment dans les câbles : Sang libre

Malheureusement je ne suis pas un bon critique d'émission radiophonique et je ne saurais vous décrire comme il se doit cette émission, si ce n'est qu'elle me plait beaucoup, et que je vous encourage à l'écouter avec une bonne paire d'enceintes...

Vous pouvez télécharger et diffuser, c'est permis !

PHPUnit 6.5

Remi Collet

Les RPM de PHPUnit version 6.5 sont disponibles dans le dépôt remi pour Fedora ≥ 24 et pour Enterprise Linux (CentOS, RHEL...)

Documentation : PHPUnit 6.5 manual et Release Announcement for PHPUnit 6.5.0 (en anglais)

emblem-notice-24.pngCette nouvelle version nécessite PHP ≥ 7.0 et n'est pas rétro-compatible avec les versions précédentes, donc s'installe en parallèle de la version 5.

Installation, Fedora :

dnf --enablerepo=remi install phpunit6 

Installation, Enterprise Linux :

yum --enablerepo=remi install phpunit6 php-phpunit-dbunit3

Remarque: cet outil est une pièce essentielle de la QA PHP dans Fedora. Je prévois rapidement, une mise à jour dans Fedora 27, dès que la revue #1519719 sera approuvée.

PHP version 7.2.0 est publiée !

Remi Collet

La RC6 était bien GOLD, donc la version 7.2.0 GA vient juste d'être publiée, à la date prévue.

Un grand merci à tous les développeurs qui ont contribué à cette nouvelle version majeure de PHP, et à tous les testeurs des versions RC qui ont permit de livrer une version de qualité.

Cette version est particulièrement importante pour moi, car j'ai la chance d'avoir été choisi comme Release Manager avec Sara Golemon.

Les RPM sont disponibles dans le dépôt remi-php71 pour Fedora 25 et et Enterprise Linux 6 (RHEL, CentOS) ainsi qu'en Software Collection dans le dépôt remi-safe.

Lire l'annonce de version PHP 7.2.0 Release Announcement (en anglais).

emblem-notice-24.pngInstallation : voir la Configuration du dépôt et choisir le mode d'installation, ou utiliser l'assistant de configuration.

Remplacement du PHP par défaut du système par la version 7.2 (le plus simple) :

yum-config-manager --enable remi-php72
yum update php\*

Installation en parallèle, en Software Collection de PHP 7.2 (x86_64 uniquement, recommandée pour les tests) :

yum install php72

emblem-important-2-24.pngÀ noter :

  • la version EL7 est construite avec RHEL-7.4
  • la version EL6 est construite avec RHEL-6.9
  • cette version sera la version par défaut de Fedora 28, voir PHP 7.2
  • l'ensemble des extensions est déjà disponibles, voir la page PECL extension RPM status..

emblem-notice-24.pngInformations, lire :

Paquets de base (php)

Software Collections (php72)

Participez à la journée de test consacrée au noyau Linux 4.14

Charles-Antoine Couret

Aujourd'hui, ce jeudi 30 novembre, est une journée dédiée à un test précis : sur le noyau Linux 4.14. 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é.

Revue de presse de Fedora 27

Charles-Antoine Couret

Cela fait depuis Fedora 19 que je publie sur la liste de diffusion de Fedora-fr une revue de presse de chaque sortie d'une nouvelle version. Récapituler quels sites en parle et comment. Je le fais toujours deux semaines après la publication (pour que tout le monde ait le temps d'en parler). Maintenant, place à Fedora 27 !

Bien entendu je passe sous silence mon blog et le forum de fedora-fr.

Sites web d'actualité

Soit 7 sites sur les 25 contactés.

Blogs, sites persos ou sites non contactés

Soit 4 sites.

Bilan

Le nombre de sites parlant de Fedora 27 est stable depuis Fedora 19. Beaucoup d'articles se fondent sur ce que j'ai moi même rédigé (que ce soit la version courte ou longue). La semaine de sa sortie, nous avons eu entre 300 et 400 visiteurs uniques en plus sur le site fedora-fr.org ce qui représente un pic de 30%. Augmentation similaire que pour l'annonce de Fedora 26 (mais comme c'était l'été, Fedora 26 a attiré moins de personnes sur notre site).

Si vous avez connaissance d'un autre lien, n'hésitez pas à partager ! Rendez-vous pour Fedora 28.

Compte rendu mensuel de la documentation francophone, numéro 3

Charles-Antoine Couret

Pour rappel, vous pouvez consulter l'état du travail en cours sur la documentation.

Les sujets traités ont changé quelque peu depuis la dernière fois. C'est plus centré autours des thématiques :

  • Le noyau et composantes basses ;
  • La sécurité et autres utilitaires ;
  • L'usage serveur de courrier.

Personnellement je me suis occupé plutôt des deux premiers thèmes. En effet même si le noyau Linux ne change pas fondamentalement, ses correctifs majeurs et sa procédure de compilation ont un peu changé. Ils ont nécessité un petit rafraîchissement. De plus, avec Fedora 25 qui a inauguré avec Wayland par défaut, il a fallu lui dédier un nouvel article pour familiariser les utilisateurs avec cette technologie.

Concernant le deuxième point, il était nécessaire de revoir la liste des logiciels pour chaque usage sur notre système préféré. Si les éditeurs d'images ou suites bureautique n'ont pas beaucoup changé en 5 ans, on ne peut pas en dire autant des clients de messagerie ou des navigateurs Web. Ces secteurs ont été très dynamiques avec beaucoup de projets obsolètes et de nouveaux venus. Pour la sécurité, deux outils majeurs que sont gnupg et ssh ont évolué. Surtout le premier avec sa version 2. Maintenant c'est corrigé. Nicolas a amélioré la sécurité des connexions VNC à travers SSH.

Enfin, la FAQ a été modernisée un petit peu les effets 3D de bureau sont passés de mode et systemd a remplacé le concept des niveaux dexécution.

Le dernier point a été particulièrement étudié par Nicolas comme d'habitude, car Fedora a bien entendu un usage serveur important dont le paysage a changé. Cela commence par bien sûr parler de sendmail ou d'effectuer les redirections des courriels.

Mais son apport le plus important a bien sûr été la refonte de l'énorme article sur les serveurs de messagerie. Un article tout en un très complet qui a bénéficié d'un grand ravalement de façade. Bravo !

Je remercie également les autres contributeurs, relecteurs ou toute autres personnes qui se sont impliquées dans ce processus comme Édouard et d'autres.

Aujourd'hui donc, nous sommes à 55 articles traités, contre 42 au précédent bilan. Je suis satisfait des progrès réalisés sur la documentation. Il y a beaucoup de travail à mener encore, mais il semble possible que la documentation soit dans un état très acceptable bientôt. Ensuite il faudra veiller à maintenir la documentation à jour continuellement et ajouter des articles suivant les besoins du moment.

Je vous invite en tout cas à nous donner un coup de main, pour cela je vous conseille de suivre la procédure pour contribuer à la documentation et si possible de participer à nos ateliers hebdomadaires tous les lundi soir à partir de 21h (heure de Paris) sur le canal IRC #fedora-doc-fr du serveur Freenode. Rien ne vous empêche de contribuer en dehors du cadre des ateliers, toute l'aide est la bienvenue. Alors, n'hésitez pas !

PHP version 7.0.26 et 7.1.12

Remi Collet

Les RPM de PHP version 7.1.12 sont disponibles dans le dépôt remi pour Fedora 26 et dans le dépôt remi-php71 pour Fedora 24-25 et Enterprise Linux (RHEL, CentOS).

Les RPM de PHP version 7.0.26 sont disponibles dans le dépôt remi pour Fedora 25 et dans le dépôt  remi-php70 pour Fedora 24 et Enterprise Linux.

emblem-notice-24.pngPas de correctifs de sécurité ce mois ci, donc pas de mise à jour de la 5.6.32.

emblem-important-2-24.pngPHP version 5.5 a atteint sa fin de vie et n'est plus maintenu par le projet.

Ces versions sont aussi disponibles en Software Collections.

Annonces des versions :

emblem-notice-24.pngInstallation : voir l'assistant de configuration et choisir la version et le mode d'installation.

Remplacement du PHP par défaut du système par la version 7.1 (le plus simple) :

yum-config-manager --enable remi-php71
yum update

Installation en parallèle, en Software Collections de PHP 7.1 (x86_64 uniquement) :

yum install php71

Remplacement du PHP par défaut du système par la version 7.0 (le plus simple) :

yum-config-manager --enable remi-php70
yum update

Installation en parallèle, en Software Collections de PHP 7.0 (x86_64 uniquement) :

yum install php70

Et bientôt dans les mises à jour officielles:

emblem-important-2-24.pngÀ noter :

  • la version EL7 est construite avec RHEL-7.4
  • la version EL6 est construite avec RHEL-6.9
  • beaucoup de nouvelles extensions sont aussi disponible, voir PECL extension RPM status page

emblem-notice-24.pngInformations, lire :

Paquets de base (php)

Software Collections (php56 / php70 / php71)

Appel à tests de l'autonomie des ordinateurs portables

Charles-Antoine Couret

Le développeur de Red Hat, Hans de Goede, travaille pour Fedora 28 afin d'améliorer l'autonomie des ordinateurs portables avec notre système préféré.

L'un des travaux pour parvenir à cet objectif est d'activer SATA Link Power Management. Ce dispositif existait depuis longtemps, mais certains modèles de disques durs et de SSD subissaient des craches et même des pertes de données. Matthew Garret a travaillé sur le sujet par le passé, ce que Hans a complété en se basant sur les travaux d'Intel et de son implémentation dans Windows.

Donc il propose au noyau Linux un nouveau mode LPM nommé med_power_with_dipm qui est proche en résultats de min_power setting proposé par Matthew. Il espère que de s'inspirer de Windows puisse résoudre les difficultés rencontrées à l'époque.

Si vous souhaitez donner un coup de main, ce serait apprécié. Il faut bien entendu d'un ordinateur portable disposant d'un disque dur ou d'un SSD accessible par SATA (donc pas de NVME). Il est également indispensable de sauvegarder vos données avant la manipulation.

Procédure de tests

Le test est plutôt simple. À partir d'une Fedora la plus fraîche possible (désactivez toutes les optimisations que vous avez fait avec powertop éventuellement). Lancez powertop pendant 5 minutes, sans aucun autre logiciel de lancé, uniquement powertop dans le terminal.

Récupérez la valeur de consommation durant cette période, qui doit être entre 5-10W environ.

Ensuite, répétez la procédure en installant et bootant sur le noyau disponible à cette adresse qui contient le correctif en question. Téléchargez également le fichier rc.local dans le dossier /etc/rc.d/rc.local en le rendant exécutable bien évidemment.

Au redémarrage, vérifiez que tout est OK ainsi :

cat /sys/class/scsi_host/host0/link_power_management_policy"

Vous devez avoir la valeur med_power_with_dipm s'afficher, sinon quelque chose a raté.

Ensuite refaites la procédure avec powertop à l'identique. Et testez ce noyau pendant 2 semaines idéalement.

À la fin du test, vous pouvez contacter hdegoede@redhat.com directement en précisant :

  • Si cela a été un succès, sinon quels problèmes il y a eu ;
  • La différence de consommation entre avant et après le correctif ;
  • La marque et modèle de votre ordinateur ;
  • La sortie des commandes
cat /proc/cpuinfo | grep "model name"
cat /sys/class/scsi_device/*/device/model

Cette nouveauté est actuellement en cours de discussion pour Fedora 28. N'hésitez pas à donner un coup de main pour que cela soit possible d'en bénéficier en mai 2018. :-)" class="smiley

La sécurité, l'obsolescence et la maintenance des systèmes embarqués

Charles-Antoine Couret

Il est assez banal de dire que de plus en plus d'équipements modernes sont connectés au réseau. Cela apporte de nouvelles fonctionnalités, la possibilité d'améliorer le produit même une fois vendu par des mises à jour mais aussi des problèmes de confidentialité et de sécurité.

Les systèmes embarqués sont particulièrement concernés par ces problématiques, que les industriels traitent parfois mal et dont les consommateurs sont rarement dans le vrai également.

C'est de cette problématique dont on va parler.

Obsolescence programmée ?

Ce terme revient souvent dans ce genre de discussions. Que l'abandon du support d'un produit, comme par exemple l'absence d'une mise à jour Android, ou que justement la mise à jour de trop rend le système trop lent (cas de certains iPhone) serait une pratique digne de l'obsolescence programmée.

Globalement c'est faux. L'obsolescence programmée est une pratique supposée où un constructeur fragilise **volontairement** son produit afin de nécessiter un remplacement régulier pour augmenter ses ventes.

Le mot clé est donc l'aspect volontaire. Qui est difficile en réalité à constater. Et certains oublient aussi l'aspect de l'équilibre entre le prix et la qualité. Un produit bas de gamme va minimiser la qualité des matériaux par exemple pour que cela coûte moins cher au client. Il est donc normal que le produit dure moins longtemps. Cette question du compromis dans la réalisation du produit est l'essence même du travail d'un ingénieur et de la création de différentes gammes de produits, on ne peut assimiler cela à de l'obsolescence programmée qui consiste en un sabotage.

Je ne vais pas m'étendre beaucoup sur le sujet, il y a trois articles de blog (ici, et là-bas) qui traitent bien de la question de l'obsolescence programmée qui reste une pratique à priori confidentielle. Mais le célèbre reportage d'Arte sur le sujet a mis en lumière cette pratique avec de mauvais exemples et certains le voient du coup... partout.

En tout cas on ne m'a jamais demandé de saboter mon propre produit, et aucun de mes collègues ou connaissances non plus. ;-)" class="smiley Par contre il arrive que certains bogues ne soient jamais corrigés, faute de temps ou de ressources financières pour les traiter.

De la question du progrès logiciel

Certains produits, comme nos ordinateurs ou téléphones portables, peuvent vivre des années sans problèmes. Et ces outils à usage assez génériques peuvent exécuter du logiciel conçu bien après la réalisation du produit.

Mon ordinateur portable personnel actuel date de 2011, il est passé de Fedora 16 à 27, de Windows 7 à 10, de Firefox 7 à Firefox 56, de GNOME 3.0 à GNOME 3.26, de Linux 3.1 à Linux 4.14, etc.

Ce sont des millions de lignes de code ajoutées depuis, le Web a beaucoup grossi entre temps avec du JavaScript devenu omniprésent et des sites devenant de plus en plus des applications complètes. Le contenu multimédia salourdit, passant du 720p à 4K pour les vidéos ou les photos. Le chiffrement s'est généralisé également dans les communications ou le stockage.

J'ai constaté peu à peu un ralentissement de ma machine, la consommation de la mémoire a monté (j'ai du rajouter 4 Gio récemment) alors que mon usage, fondamentalement n'a pas changé.

Ce phénomène n'a rien de nouveau, cela suit la loi de Wirth.

C'est un phénomène naturel. Les logiciels évoluent pour ajouter des fonctionnalités (pour répondre à des besoins des utilisateurs). Il est impossible de proposer du logiciel plus moderne tout en espérant une consommation en ressource identique indéfiniment. Soit il faut utiliser un produit qui n'évoluera plus fonctionnellement (cas de beaucoup d'outils simples et légers), ou alors il faudrait beaucoup de ressources financières et humaines pour maintenir plusieurs déclinaisons du logiciel dans le temps. Ce que l'on abordera plus tard.

Ce que la loi de Wirth n'explique pas ou mal, c'est que l'évolution du matériel se produit de manière globale, mais localement un produit a un matériel plutôt figé. Si le matériel évolue mais que les logiciels n'exploitent pas cette puissance supplémentaire, ce serait du gâchis. Donc la consommation des programmes évoluent pour bénéficier de ces ressources disponibles. Et forcément cela se fait au détriment des machines qui accusent d'un certain âge. Cela est encore plus visible sur les téléphones qui ont fait un saut de performances spectaculaire en très peu d'années.

Certains veulent exploiter la machine le plus longtemps possible (donc disons 10-15 ans) tout en bénéficiant de ces évolutions. Ce n'est pas possible sans concession. Il faut faire des choix, en payant cher des produits pour les maintenir longtemps, en renonçant partiellement à ce progrès, en changeant de machine ou renoncer à des usages. Typiquement, aller sur le Web avec une machine de 2002 doit être possible, mais cela ne doit pas être une expérience très agréable en dehors de quelques sites très légers.

Et pour un téléphone bas de gamme, conçu pour être tout juste capable de lancer les applications populaires de l'époque, ne peut pas soutenir la charge d'une mise à jour des dites applications sur le long terme.

Et après toute cette explication, comment associer cela à de l'obsolescence programmée alors que cette lourdeur progressive provient de logiciels extérieurs à la conception du matériel ? Ce n'est pas Intel qui a rendu Firefox plus lourd avec le temps. :-)" class="smiley

La sécurité

La sécurité est devenue depuis quelques années un sujet de premier plan pour tout un nouveau panel de produits. Avec une connexion accessible depuis Internet, il devient possible d'essayer d'infiltrer ces produits qui peuvent être accessibles non stop pendant des années et sans maintenance active (il n'y a pas un administrateur système pour surveiller le réseau domestique d'un particulier).

Du coup, pour combler les failles, il devient nécessaire de mettre à jour le produit. Parfois changer l'outil interne, ou le protocole employé (le MD5 n'est plus un moyen fiable pour vérifier l'intégrité d'un fichier ou d'un certificat).

Du coup pour améliorer la sécurité, on doit les faire évoluer. Ce qui peut nous faire revenir sur le point précédent où le logiciel devient trop lourd pour le matériel considéré ce qui rend compliqué la conciliation des deux.

L'autre problème est... le coût. Quand on achète un produit type téléphone, un réfrigérateur connecté, un modem ou autre, nous achetons le produit à un prix fixe, parfois très dérisoire car très bas de gamme. Sauf que d'assurer une maintenance sur 10-15 ans, cela coûte très cher. Car il devient nécessaire de maintenir plusieurs versions du logiciel (suivant l'âge du matériel et de ses successeurs à maintenir), de tester chaque mise à jour sur chaque produit, tester son déploiement, corriger les éventuels ratés auprès des clients, communiquer auprès d'eux (manuels explicatifs, mise à jour d'un site Web possiblement en plusieurs langues, courriers / courriels envoyés en nombre).

Admettons que pour maintenir un modèle d'un téléphone portable pendant 15 ans il faut une équipe de 10 personnes à temps plein (ce qui n'est pas irréaliste car cela demande beaucoup de travail pour corriger la moindre faille ou les bogues découverts, sachant que le logiciel dépend également du lieu vendu pour des raisons de contraintes légales). En admettant qu'ils ne sont pas mal payés (et qu'il leur faut du matériel adéquat), cela peut revenir par employé à un coût annuel pour l'employeur d'environ 100 000€. Donc 1 million d'euros par an. Sachant qu'un modèle lambda d'un téléphone peut être vendu auprès du million d'unités au total, cela reviendrait a un coût de 10-15 millions d'euros rien que pour la maintenance une fois le produit vendu. Pour des téléphones à 100€, cela représente 10% du budget global du produit ! Ce n'est clairement pas négligeable. Et je ne parle pas des cas de produits moins vendus qui méritent pourtant la même maintenance.

Le Libre comme solution ?

Certains pensent qu'un produit embarqué, s'il est fait avec du logiciel libre, il est aisé de le maintenir pour proposer des mises à jour du produit pendant des années après l'abandon par son constructeur. La réalité est plus complexe.

Pour les projets assez puissants pour accueillir un système d'exploitation Linux (cas des téléphones par exemple), le système est rarement compilé de zéro à la main. Pour gagner du temps, il existe des solutions comme Yocto ou buildroot (et ses déclinaisons OpenWRT ou ptxdist) pour compiler l'ensemble des logiciels (dont le noyau) pour notre système afin d'obtenir une image qu'on pourra installer sur la cible. Je les présenterais dans un autre article.

Seulement, chaque processeur ou plateforme a ses spécificités. C'est pourquoi, les concepteurs des puces (Qualcomm, Texas Instrument, Broadcom, Freescale / NXP et autres) fournissent les solutions citées plus haut avec les changements nécessaires pour exploiter la plateforme. Très souvent le noyau Linux et le chargeur de démarrage U-Boot accueillent une grande liste de correctifs maison (plusieurs centaines).

Cela est bien, car nous n'avons pas à développer nous même les pilotes pour exploiter les fonctions du processeur (notamment pour la couche graphique) et dans l'essentiel cela reste du code libre. Cependant ces correctifs sont gros et souvent… mal réalisés. Faute de temps et de ressources, les constructeurs ne cherchent pas à concevoir des correctifs qui finiront dans le projet officiel. Leur but est que cela fonctionne avec le noyau fourni aux développeurs / intégrateurs. Du coup nous nous retrouvons avec un noyau et un chargeur de démarrage figé, car Linux évolue très vite et il est très difficile de porter ces correctifs pour une autre version. Et comme cela est trop souvent trop mal fait (utilisation d'une pile logicielle différente que celle du noyau pour une fonction donnée, comme le SPI ou le réseau par exemple, code spaghetti avec lien fort entre le tronc commun et leur pilote, etc.) il est difficilement imaginable de porter cela sur le noyau officiel directement.

Pas mal de personnes essayent pourtant de porter le nécessaire sur le noyau officiel. Mais cela demande beaucoup de temps (aujourd'hui le support du téléphone N900 est quasiment complet, mais il aura fallu 8 ans après sa sortie !) et c'est souvent au prix de fonctionnalités partielles (performances graphiques ou réseaux plus faibles, gestion de l'énergie douteuse). Sans collaboration du fondeur, c'est une tâche globalement vouée à l'échec étant donné le rythme de sortie des composants. Puis le fabricant de la puce bosse déjà sur la plateforme suivante. Ils n'ont pas le temps, ni l'envie, de s'attarder sur un produit qui n'a plus d'avenir.

Et même dans le cas où ce serait possible, il y a des sacs de nœuds dans l'architecture du système. Si vous souhaitez profiter par exemple des dernières tablettes Wacom sur votre machine, il faudra un noyau récent. En admettant que vous avez un noyau LTS un peu ancien comme la 3.4, il faudra rétro-porter cette fonctionnalité. Cela signifie récupérer le pilote mais souvent d'autres commits sur le sous-systèmes des périphériques entrées. Mais le noyau ne fait pas tout, il faut également que l'interface graphique propose de quoi configurer et exploiter le matériel. Donc par exemple en récupérant du travail effectué sur les versions récentes de GTK+ et de GNOME. Cela peut donc représenter beaucoup de travail, sur beaucoup de composants, et il faudra tester bien sûr du bon fonctionnement, de la sécurité et de la maintenance de tout ceci.

Bref, l'aspect libre peut aider bien sûr à maintenir un produit plus longtemps. D'ailleurs les initiatives du genre OpenWRT, CyanogenMod / LineageOS permettent de maintenir à jour certains produits embarqués plus longtemps que le support officiel du constructeur. Mais cela se fait souvent au détriment de certaines fonctionnalités matérielles.

Solutions ?

Je pense que la solution ne peut se passer de l'aide des industriels, qui eux-mêmes ne peuvent pas se permettre à un coût fixe d'une maintenance complexe sur une très longue durée. Imposer légalement une durée minimale de support conduirait à une hausse de prix d'achat inévitable de tous ces biens.

Une autre solution serait d'évoluer vers une tarification en tant que service. À savoir payer pour une durée de maintenance souhaitée. Si l'utilisateur souhaite 10 ans de maintenance, il le pourra, au prix d'un abonnement ajusté en conséquence. Je pense que c'est la seule solution, notamment pour les produits vendus à un volume moyen ou faible, d'avoir une maintenance dans le temps à la hauteur, sans rendre le produits inutilisable ou trop cher à l'achat.

La solution libre et gratuite me semble difficilement possible. Il suffit de voir qu'aucune distribution purement communautaire gratuite pour x86 n'arrive à gérer une maintenance de plus de 5 ans. Pourtant la plateforme est plus simple et plus standard. Donc aller au delà me paraît difficile. Car ce n'est pas une tâche aisée, ni très passionnante. Il faut en effet du savoir faire du matériel et beaucoup de temps.

Après bien entendu, les constructeurs ont leur part à jouer, en s'impliquant d'avantage dans le noyau officiel (qui pourrait lui également avoir une politique plus adaptée à ces besoins, en ayant une API interne plus stable). Il faut également réduire la surface d'attaque au maximum, n'offrir l'accès au réseau que lorsque la plus valu est réelle. Ce genre de décisions aideraient à avoir une meilleure sécurité dans le temps de ces plateformes.

Rencontrez Borsalinux-fr lors des Journées Méditerranéennes du Logiciel Libre (JM2L)

Association Borsalinux-Fr

Les JM2L sont un évènement bi-annuel concernant le Logiciel Libre qui se déroulent dans les locaux de Polytech'Nice, à Sophia-Antipolis, près de Nice. Sa dixième édition aura lieu le samedi 25 novembre 2017 et Borsalinux-fr sera sur place !

Ce sera l'occasion pour Charles-Antoine Couret et Nicolas Chauvet de tenir le stand de l'association pour présenter Fedora, l'association Borsalinux-fr, les nouveautés de la Fedora 27 (qui est sortie le 14 novembre), etc. C'est également l'occasion de se rencontrer et de discuter d'autres sujets si vous le souhaitez.

Charles-Antoine Couret tiendra une conférence sur les apports de Fedora à l'écosystème du Logiciel Libre. Elle aura lieu à 15h dans la salle Flavientris.

Si vous êtes intéressés de nous rencontrer, ou de simplement participer à l'évènement, vous trouverez les informations nécessaires sur le site officiel.

Fedora 27: Changements dans httpd et php

Remi Collet

La configuration du serveur HTTP Apache et de PHP a été modifiée dans Fedora 27, voici quelques explications.

1. Bascule du serveur HTTP en mode event

Depuis l'origine de la distribution, le serveur utilise le MPM prefork.

Pour des raisons évidentes de performance, il a été décidé de suivre les recommandations du projet et d'utiliser event par défaut. Ce changement est aussi nécessaire pour bénéficier du support complet du protocole HTTP/2 via mod_http2.

2. Le problème de mod_php

Le module mod_php est uniquement supporté quand le MPM prefork est utilisé.

Dans la documentation PHP on peut lire :

Avertissement : Nous ne recommandons pas l'utilisation de PHP dans un environnement threadé MPM, avec Apache 2.

Et effectivement, quelques rapports de bugs signalent des plantages dans cette configuration.

Il n'était donc pas raisonnable de conservé mod_php par défaut.

De plus ce module a d'autres limitations ennuyeuses :

  • intégré au serveur web, il partage son espace mémoire, pouvant entrainer des problèmes de sécurité
  • une seule version peut être chargée

3. Utilisation de FastCGI

Depuis plusieurs années nous avons travaillé à rendre l'exécution de PHP aussi flexible que possible, dans différentes configurations, fonctionnant sans changement de configuration :

  • httpd + mod_php
  • httpd + php-fpm (lorsque mod_php est désactivé ou absent et que le serveur php-fpm fonctionne)
  • nginx + php-fpm

L'utilisation de FPM est devenu la configuration par défaut recommandée pour une exécution propre de PHP :

  • support de multiples serveurs web (apache httpd, nginx, lighttpd)
  • isolation du frontal pour la sécurité
  • dorsaux multiples
  • architecture micro-services
  • fonctionnement en container (docker)
  • multiples versions de PHP

4. FPM par défaut

Depuis Fedora 27, mod_php ZTS (multi-thread) est toujours fournit, mais n'est plus activé, c'est donc FastCGI qui sera utilisé par défaut.

Pour ne pas casser les configurations existantes lors de la mise à jour, ou obtenir un serveur opérationnel dès l'installation, nous avons choisi de mettre en place quelques solutions, probablement de manière temporaire

  • Le paquet php a une dépendance optionnelle sur php-fpm qui permet son installation par défaut
  • le service httpd a une dépendance sur le service php-fpm qui permet son démarrage automatique

5. Problèmes connus

5.1. Modification de la configuration

Lors d'une modification de la configuration, ou de l'installation d'une nouvelle extension il est désormais nécessaire de redémarrer le service php-fpm.

5.2. Fichiers de configuration

Avec mod_php, il est habituel d'utiliser les directives php_value ou php_flag dans la configuration du serveur Apache ou dans un fichier .htaccess.

Il est désormais nécessaire soit d'utiliser les directives php_value ou php_flag dans la configuration de du pool FPM, soit d'utiliser un fichier .user.ini dans le dossier de l'application.

6. Revenir sur mod_php

Si vraiment vous souhaitez rester (temporairement) sur mod_php, cela reste possible :

  • Revenir en MPM prefork dans le fichier /etc/httpd/conf.modules.d/00-mpm.conf.
 LoadModule mpm_prefork_module modules/mod_mpm_prefork.so
 #LoadModule mpm_worker_module modules/mod_mpm_worker.so
 #LoadModule mpm_event_module modules/mod_mpm_event.so
  • Activer le chargement du module dans le fichier /etc/httpd/conf.modules.d/15-php.conf. Attention, cette configuration ne sera pas supportée.
 # ZTS module is not supported, so FPM is preferred
 LoadModule php7_module modules/libphp7-zts.so

Dans ce cas, le paquet php-fpm pourra être désinstallé.

7. Conclusion

Fedora 27 utilise désormais une configuration moderne et conforme aux recommandations des projets. La sécurité et les performances sont améliorées.

Tout changement provoque inévitablement quelques petits problèmes et quelques grincement de dents, mais nous essaierons de prendre en compte les difficultés et d'améliorer ce qui doit l'être dans les prochaines mises à jour et dans les prochaines versions de Fedora.

Je prévois de mettre à jour ce billet en fonction des retours.

Page générée le 22 fév 2018 à 09:22