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.

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.

Publication de Fedora 27 !

Charles-Antoine Couret

En ce mardi 14 novembre 2017, le projet Fedora est fier dannoncer la sortie de la distribution GNU/Linux Fedora 27.

Cette version de Fedora s'est surtout concentrée sur trois axes : couche graphique, gestion du matériel et Fedora.next.

À noter que pour gagner du temps et des ressources, c'est la première version de Fedora n'ayant pas eu de version Alpha. Cela a été rendu possible grâce à l'amélioration des procédures de qualité pour les versions en développements.

GNOME-Bureau.png

Couche graphique

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 ;
  • Le logiciel de virtualisation Machines peut télécharger et lancer automatiquement une RHEL gratuite ;
  • Amélioration des performances pour quelques applications ou GNOME en général.

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.

dnfdragora.png

Gestion du matériel

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.

GNOME-Paametres.png

Fedora.next

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. À cause de ce changement important, l'édition Server sera disponible un mois après les autres éditions.

Et comme d'habitude, Fedora 27 réserve bien d'autres surprises à découvrir.

La communauté francophone

L'association

Logo.png

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 afin 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 à travers la France principalement.

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 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ées sur le sujet.

Le moindre que l'on puisse dire, c'est que le travail abattu est important : près d'une cinquantaine d'articles corrigés et remis au goût du jour. 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.

Liens

End of PHP 7.2 FTBFS marathon

Remi Collet

QA is a very important part of my daily work, and since PHP 7.2 is available in Fedora rawhide, we have to ensure everything works as expected with this new version.

 

As already explained, Koschei is our QA tool, used to monitor the full PHP stack, including ~60 extensions and ~500 libraries.

After the initial build of PHP 7.2.0RC3 in rawhide (September 29th) we have around one hundred FTBFS packages (Failed To Build From Sources).

Today everything is ok, all FTBFS have been fixed.

1. Extensions

Most PHP extensions are now compatible with PHP 7.2, excepted

  • XDebug, but version 2.6.0-dev works and a beta should be released soon
  • Timecop, this have been reported upstream, searching for a fix.

2. Mcrypt

Lot of packages were broken because they sadly still rely on the old deprecated mcrypt extension.

Despite I'm fighting for years to be able to remove it (see about libmcrypt and php-mcrypt), we still need it, so I have created the new php-pecl-mcrypt package from the PECL cemetery. This is obviously only a temporary solution, this extension is deprecated, un-maintained and should die.

3. Upstream patches

Most of PHP projects consider fix for new PHP version as standard bugfix, which means, could be done in a simple minor version, without requiring any major change.

So, some projects have already made the few minor changes needed, but have not yet released new version including theses changes. So the work was only about finding these fix, and applying them in the Fedora packages.

4. Pull Requests

Most projects are not yet monitoring PHP 7.2 (not enabled in travis) so were not really aware of needed changes.

So, of course, the first work was to report this failure upstream, and usually providing a possible fix (PR).

Some are already merged, some are still waiting for review.

5. Skip some

For a very few packages, as no real good fix exists for now, we have to temporarily skip some tests with 7.2. Most are about the session change, which breaks unit tests (session_start() failing)  without any real impact on the real usage.

6. Common error

The 2 more common errors, requiring a fix, are :

  • stricter prototype checking, fix for #73987, originally applied in 7.1.2RC1 then reverted as introduce a small BC break.
  • count on not countable
  • object is a reserved keywork

7. Conclusion

We are ready for PHP 7.2 in Fedora, and as usually, we done this the Fedora way: upstream first.

I also consider that having most extensions / libraries ready is a important criteria for the new version adoption by users.

PHP Forum 2017

Remi Collet

Cette année encore, j'ai eu le privilège de participer au PHP Forum à Paris, organisé par l'AFUP.

Comme à chaque fois, l'occasion de rencontrer de nombreux développeurs et utilisateurs de PHP, et d'avoir de grandes discussions. Comme d'habitude, l'organisation était parfaite. C'est vraiment l'événement francophone majeur autour de ce langage.

J'ai eu le plaisir de présenter, devant un amphi plein a craqué, la prochaine version PHP 7.2

La présentation est en ligne : Paris-2017.pdf

Ainsi que la vidéo : PHP 7.2

Pour les rémois, j'ai aussi fait cette présentation, dans une version légèrement raccourcie, lors du Meetup de Novembre à Reims.

PHP version 7.0.26RC1 et 7.1.12RC1

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.12RC1 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.26RC1 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 est en mode développement, la version 7.2.0RC6 est aussi disponible.

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.12RC1 est aussi disponible dans Fedora 27 et la version 7.2.0RC6 dans Fedora rawhide pour la QA.

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)

Borsalinux-fr sera au Capitole du Libre 2017

Association Borsalinux-Fr

Comme chaque année, Borsalinux-fr assurera une permanence à l'évènement du libre « Capitole du Libre » qui se tiendra le samedi 18 et dimanche 19 novembre 2017 à lENSEEIHT dans la ville de Toulouse.

Vous pourrez rencontrer de notre communauté Emmanuel Seyman, Michael Scherer et Gaia (du forum). Ils tiendront le stand de l'association pour présenter Fedora, vous guideront en cas de difficultés, pourront recueillir vos dons éventuels, vous pourrez récupérer des images de la nouvelle Fedora 27 (qui sortira ce 14 novembre) et des goodies. C'est également un moment convivial pour se rencontrer.

Emmanuel Seyman fera une conférence pour présenter son projet Schema le dimanche 19 novembre à 14h00, salle A202.

Michael Scherer tiendra deux conférence, une sur la sécurité de l'espace de travail des contributeurs du libre le samedi 18 novembre à 15:00, salle A201. La deuxième portera sur l'importance d'avoir une infrastructure ouverte le samedi 18 novembre à 16h30, salle A002.

Si vous êtes intéressés d'y participer, ou de faire juste un coucou, vous trouverez plus d'informations sur le site web officiel de l'évènement.

Astuces de configuration de PHP

Remi Collet

Traduction de l'article PHP Configuration Tips.

Cet article regroupe les informations actualisées qui ont été publiées ici au cours des dernières années.

RHEL 7 fournit le serveur HTTP Apache  version 2.4 et PHP version 5.4.

Le configuration la plus commune pour Apache et PHP utilise mod_php, mais présente quelques limites et inconvénients :

  • une seule versions de mod_php peut être utilisée
  • mod_php tourne dans le processus httpd, sans isolation
  • mod_php n'est supporté que pour le MPM prefork

Cet article explique comment déléguer l'exécution des scripts PHP à un service d'arrière plan utilisant le protocole  FastCGI, comment utiliser une version récente de PHP, comment utiliser plusieurs versions de PHP, et comment améliorer les performances d'Apache..

Le paquet du serveur HTTP d'apache disponible dans RHEL fournit l'ensemble des fonctionnalités nécessaires pour une telle configuration.

1. Basculer vers php-fpm

1.1. Supprimer mod_php

Il est conseillé de supprimer ou de désactiver mod_php afin de réduire la consommation mémoire de chaque processus httpd.

Vous pouvez soit déinstaller le paquet php, qui ne contient que ce module

yum remove php

ou simplement le désactiver en commentant la directive LoadModule directive dans le fichier /etc/httpd/conf.modules.d/10-php.conf.

# disabled # LoadModule php5_module modules/libphp5.so

1.2. Installer php-fpm

Vous pouvez maintenant installer php-fpm et activer son service

yum install php-fpm
systemctl start php-fpm
systemctl enable php-fpm

Remarque: le paquet php-fpm est disponible dans le canal optional, qui doit être activé.

Pour configurer l'exécution des scripts PHP, modifiez ou créez le fichier de configuration /etc/httpd/conf.d/php.conf :

Les lignes suivantes interdise l'accès aux fichiers .user.ini depuis les clients Web!

  <Files ".user.ini">
    Require all denied
  </Files>

Activation de la gestion du Multiviews par php:

  AddType text/html .php

Ajouter index.php à la liste des fichiers utilisés pour fournir le contenu d'un dossier :

  DirectoryIndex index.php

La ligne suivante active les entêtes d'autorisation :

  SetEnvIfNoCase ^Authorization$ "(.+)" HTTP_AUTHORIZATION=

Rediriger l'exécution des scripts PHP vers le service FPM

  <FilesMatch \.php$>
    SetHandler "proxy:fcgi://127.0.0.1:9000"
  </FilesMatch>

Si des directives php_value sont présentes dans ce fichier, vous devez les supprimer, elles ne concernent que mod_php.

Vous pouvez maintenant redémarrer le serveur web et, avec une simple page de test

<?php phpinfo();

vérifier qui PHP est désormais exécuté à par le service FastCGI:

  PHP Version 5.4.16
  Server API= FPM/FastCGI

1.3. Réglages de PHP

Le fichier de configuration principal est /etc/php-fpm.conf, qui contient beaucoup de commentaires expliquant chaque option.

FPM pour exécuter plusieurs services (pool), chacun exécutant les scripts PHP avec des options pouvant être différentes, le fichier de configuration du service par défaut (www) est /etc/php-fpm.d/www.conf, qui contient aussi de nombreux commentaires.

1.3.1. php_value, php-flag

Les options de PHP peuvent être configurées en utilisant les directives php_value, php_admin_value, php_flag et php_admin_flag :

  • avec mod_php,  dans les fichiers de configuration d'Apache
  • avec FPM, dans les fichiers de configuration de chaque service (pool)

1.3.2. .htaccess

Les options peuvent, en plus, être définies pour un dossier spécifique :

  • avec mod_php, en utilisant un fichier .htaccess
  • avec FPM, en utulisation un fichier .user.ini (les mot clés php_* ne sont pas nécessaires).

1.3.3. Réglages des processus

FPM fonctionne en service et lance plusieurs processus pour gérer les différentes requêtes en parallèle, il existe plusieurs modes :

  • pm = ondemand, un processus est lancé uniquement lors d'une nouvelle connexion, et arrêté lorsqu'il n'y a pas d'activité, ce mode est  adapté pour les environnements de développement
  • pm = dynamic, un groupe de processus est toujours en fonctionnement, plus de processus seront démarrés en cas de besoin, ce mode adapté à la production
  • pm = static, un nombre fixe de processus est toujours présent, ce mode est adapté à la production et peut améliorer les performances

1.4. Réglages du Serveur HTTP Apache

1.4.1. Mode threadé

Par défaut, le serveur HTTP apache utilise un ensemble de processus pour gérer les requêtes entrantes (MPM prefork).

Comme nous n'utilisons plus mod_php, nous pouvons basculer sur un MPM threadé (worker or event), et c'est un ensemble de threads qui gérera les requêtes, réduisant le nombre de processus, la consommation mémoire, et améliorant les performances, en particulier lorsqu'il s'agit de servir de nombreux fichiers statiques.

Changer leMPM utilisé dans le fichier de configuration /etc/httpd/conf.modules.d/00-mpm.conf :

  # disabled # LoadModule mpm_prefork_module modules/mod_mpm_prefork.so
  # disabled # LoadModule mpm_worker_module modules/mod_mpm_worker.so
  LoadModule mpm_event_module modules/mod_mpm_event.so

1.4.2. Unix Domain Socket

Par défaut, FPM écoute sur un socket réseau, mais il peut aussi utiliser un socket local (UDS), ce qui peut améliorer sensiblement les performances :

Dans la configuration du service (pool) FPM :

  listen = /run/php-fpm/www.sock
  listen.owner = apache
  listen.mode = 0660

Dans la configuration du serveur Apache :

  SetHandler "proxy:unix:/run/php-fpm/www.sock|fcgi://localhost"

1.4.2. Séparation du frontal et des serveurs applicatifs

Par défaut, FPM écoute les requêtes entrantes sur un socket réseau local, il est évidement possible d'utiliser un serveur séparé, une machine virtuelle ou un containeur (une instance docker)

Dans le configuration du service (pool) FPM :

  listen = 10.0.0.2:9000
  listen.allowed_clients = 10.0.0.1

Dans la configuration du serveur Apache :

  SetHandler "proxy:fcgi://10.0.0.2:9000"

1.4.3 Plusieurs serveurs applicatifs

Pour traiter plus de requêtes simultanément, vous pouvez désirer répartir la charger entre plusieurs serveurs PHP, ce qui est très facile.

Exemple de configuration du serveur Apache avec 3 serveurs applicatifs :

  # Création du répartiteur de charge
  <Proxy balancer://phpfpmlb>
    BalancerMember fcgi://10.0.0.2:9000
    BalancerMember fcgi://10.0.0.3:9000
    BalancerMember fcgi://10.0.0.4:9000
  </Proxy>
  # Redirection de l'exécution des scripts PHP
  <FilesMatch \.php$>
    SetHandler "proxy:balancer://phpfpmlb"
 </FilesMatch>

2. Utilisation d'une version récente de PHP

RHEL fournit PHP version 5.4, qui était la version courante lors de la publication de RHEL-7, mais qui peut être trop ancienne pour des projets récents.

PHP version 5.6, 7.0 et 7.1 sont maintenant supportés sur RHEL, fournit dans le produit Red Hat Software Collections (RHSCL).

Dans l'example ci-dessous, nous utiliserons la version 7.0, mais s'applique à l'identique pour les autres versions.

2.1. Installation

Installation de la  Software Collection, après avoir activé le canal RHSCL:

  yum install rh-php70

Installation du service FPM service pour cette version:

  yum install rh-php70-php-fpm

Installation des extensions supplémentaires nécessaires :

  yum install rh-php70-php-mbstring rh-php70-php-pgsql rh-php70-php-opcache

Astuce : comparer la liste des extensions disponibles, pour s'assurer que tout ce qui est nécessaire est présent.

  php --modules | tee /tmp/54
  scl enable rh-php70 'php --modules' | tee /tmp/70
  diff /tmp/54 /tmp/70

Astuce : ne jamais se fier au nom des paquets, mais préférer le nom des extensions (e.g. php-mysqli ou rh-php70-php-simplexml), en effet la découpage des paquets peut changer entre les versions.

2.2. Utiliser une nouvelle version de PHP

Lorsqu'on utilise FPM, c'est aussi simple que darrêter l'ancien service et de démarrer le nouveau:

  systemctl stop  php-fpm
  systemctl start rh-php70-php-fpm

2.3. Paquet additionnels

Les Software Collections fournissent les même extensions que les paquets standard de RHEL.

Les utilisateurs sont habitués à trouver des extensions supplémentaires dans le dépôt EPEL, de la même manière, des extensions sont disponibles dans le dépôt communautaire centos-sclo-sclo, pour plus d'information, cherchez sclo-php sur le site https://www.softwarecollections.org/.

3. Utiliser plusieurs versions de PHP

Puisque l'exécution de PHP est redirigée version le service FastCGI service par la directive SetHandler, elle peut être définie pour chaque hôte virtuel, chaque projet ou chaque dossier.

Dans l'exemple ci-dessous, nous utiliserons PHP version 5.4 du système de base (pour des applications anciennes, qui a été configuré précédement)  et PHP version 7.1 simultanément.

3.1. Installation

Installation de la Software Collection, après avoir activé le canal RHSCL:

  yum install rh-php71 rh-php71-php-fpm rh-php71-php-mbstring rh-php71-php-opcache ...

Configuration de FPM pour écouter sur un port différent de celui utilisé par le service php-fpm service par défaut, dans le fichier /etc/opt/rh/rh-php71/php-fpm.d/www.conf.

  listen = 127.0.0.1:9071

Configurer SELinux pour ne pas bloquer ce port :

  semanage port -a -t http_port_t -p tcp 9071

Démarrer le service :

  systemctl start rh-php71-php-fpm

Il est désormais possible de choisir la version de PHP utilisée pour chaque dossier dans le fichier de configuration du serveur Apache :

Exemple:

  # Utiliser PHP 7.1 par défaut
  <FilesMatch \.php$>
    SetHandler "proxy:fcgi://127.0.0.1:9071"
  </FilesMatch>
  # Utiliser PHP 5.4 pour une ancienne application
  <Directory /var/www/html/old>
    <FilesMatch \.php$>
      SetHandler "proxy:fcgi://127.0.0.1:9000"
    </FilesMatch>
  </Directory>

4. Conclusion

J'espère que ce petit article a illustré les nombreux bénéfices de basculer sur FPM pour vos applications PHP:

  • isolation des processus entre le frontal web (httpd) et les serveurs applicatifs (fpm)
  • amélioration des performances
  • utilisation des versions modernes de PHP
  • utilisation de plusieurs versions de PHP

PHP version 5.6.32, 7.0.25 et 7.1.11

Remi Collet

Les RPM de PHP version 7.1.11 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.25 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.

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

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.

security-medium-2-24.pngCes versions corrigent quelques failles de sécurité, la mise à jour est donc vivement recommandée.

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

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

yum-config-manager --enable remi-php56
yum update

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

yum install php56

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)

Changement de pâte thermique sur mon ordinateur portable

Charles-Antoine Couret

Il y a parfois des tâches d'entretien d'un ordinateur qu'on oublie de faire et qui pourtant sont essentielles.

Le changement de pâte thermique en fait parti. La pâte thermique est ce qui permet d'améliorer la conductivité thermique entre le processeur (ou le GPU) et le radiateur dédié à évacuer cette chaleur. Il permet de gommer les aspérités des deux surfaces pour augmenter la surface de contact et éviter la présence d'air qui est un bon isolant.

Mais la pâte thermique n'est efficace que quelques années, ensuite il commence à se fissurer, à se décoller et donc à ne plus remplir correctement sa fonction. Il est nécessaire de le remplacer.

Mon ordinateur est un HP Elitebook 8560w qui vient de fêter ses 6 ans d'utilisation. Depuis quelques semaines / mois, la température était constamment entre 80 et 100°C, même si je ne faisais rien de particulier. C'est bien trop chaud. Du coup le processeur se mettait en économie d'énergie pour éviter la surchauffe ce qui dégradait les performances.

Je me suis décidé à régler le problème, ne prévoyant pas de changer de machine avant quelques mois.

Matériel

Coût total, moins de 30€.

En effet, ma machine possède beaucoup de vis Torx, puis pour éviter d'abimer la machine j'ai préféré avoir un outil très fin pour séparer les éléments et avoir de quoi gratter la pâte thermique. D'où l'achat des deux sets qui permettent globalement de démonter pas mal de machines en théorie.

Une petite pince est assez appréciable pour manipuler les petits connecteurs.

Opérations

Avant de commencer, pour éviter de faire des erreurs, j'ai préféré consulter une vidéo du démontage avant.

Comme beaucoup d'ordinateurs portables, accéder à la carte graphique et au processeur n'est pas évident. Il faut pratiquement tout retirer de la partie basse de la machine : clavier, touchpad, disque dur, lecteur CD... En fait il ne reste qu'une partie du châssis et la carte mère.

On retire donc l'ensemble du module de refroidissement qui est commun pour le processeur et la carte graphique. En effet, chacun a son radiateur qui communique la chaleur à un ventilateur et à un radiateur externe commun. Cela rend l'opération un peu plus pénible.

Vous pouvez voir le module démonté :

IMG-20171020-WA0001.jpg

Et la carte mère, avec le CPU sur la gauche, la carte graphique sur la droite :

IMG-20171020-WA0000.jpg

Bien entendu il faut ensuite tout remonter, sans se planter sur les vis. Essayer de bien réintégrer les éléments (ce dont j'ai échoué la première fois, notamment le connecteur pour les touches de la souris qui n'a pas été bien enfiché). Allumer la bête et tester que tout va bien. Et ouf tout fonctionne.

Résultats

Maintenant mon ordinateur au repos fonctionne entre 60 et 80°C. Les 100°C ne sont atteints que lors d'une activité intensive. C'est quand même bien plus sympa, à l'usage j'ai moins de ralentissements, l'utiliser sur les genoux est possible sans se brûler.

Pour un peu moins de 30€ et près de 3h à s'en occuper le résultat est très appréciable. N'hésitez pas à le faire si votre machine chauffe trop (et si bricoller un peu ne vous fait pas peur). ;-)" class="smiley

Page générée le 18 mai 2018 à 06:34