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.

Petit bilan de Rawhide, 2 mois après

Charles-Antoine Couret

Comme vous le savez, il y a deux mois je suis passé à Rawhide. Pour la première fois je vais vivre entièrement le cycle de développement d'une version de Fedora. L'objectif étant bien entendu de découvrir des choses et d'aider à détecter des problèmes plus tôt. Afin que la Fedora 26 soit la plus stable possible.

Les problèmes rencontrés

Il n'y a pas à dire, à ce stade il y a du boulot ! J'ai rencontré en 2 mois quelques bogues plutôt importants. Je m'y attendais, et il y a eu de grands progrès par rapport à la situation d'il y a quelques années.

En premier lieu, un bogue de Firefox que j'avais peu avant la sortie de F25 qui continue à me poursuivre. Les vidéos sur les pages Web parfois tournent en boucle sur 1 seconde de buffer. Rendant illisible la lecture, obligeant de relancer Firefox.

Ensuite, un bogue qui continue toujours, GNOME Shell a une erreur obligeant à relancer la session, sans raison à son lancement. C'est plutôt aléatoire. Mais si la session se lance bien, ce problème ne surgit plus avant le prochain lancement.

Un bogue apparemment qui a concerné aussi F25 et F24, avec Firefox impossible d'aller sur des sites tels que Google ou Wikipédia. Un problème dû à HTTPS sur HTTP2 apparemment. Cela a été corrigé rapidement, mais pourrait revenir pour Thunderbird et SeaMonkey à l'avenir, à cause de la mise à jour de NSS (la bibliothèque de sécurité de Mozilla) et le manque de correctif pour ces programmes. C'est en discussion sur la manière d'aborder la chose.

Un nouveau bogue apparu hier, qui semble venir du logiciel lui même. Ouvrir des onglets dans Epiphany rend l'écran noir ou gèle le système. Plutôt ennuyeux, mais au moins Epiphany n'est pas mon navigateur principal donc cela ne me gêne pas trop.

Enfin, dernier bogue qui vient d'être résolu. GNOME Shell, GDM et d'autres programmes plantaient, à cause d'un écart de version entre la bibliothèque harfbuzz de Fedora et de FreeType dans RPMFusion. Le mainteneur dans RPMFUsion a rapidement corrigé le tir.

Bref, 5 bogues que je considère comme importants et que j'ai rencontré en 2 mois. Ce n'est pas beaucoup. Dont 2 qui ont touché aussi la version stable de Fedora par ailleurs. Cela demande quand même un peu de patience et de bidouilles pour corriger la situation mais rien d'insurmontable. :-)" class="smiley

Cependant, il y a eu discussion il y a quelques temps sur Rawhide. Un empaqueteur a jugé bon de pousser un paquets qui ne fonctionnait pas sur Rawhide dans les dépôts (car pas testé par ses soins avant). Selon lui Rawhide doit être un dépôt poubelle où la stabilité ne compte pas car cela pourrait ralentir ses développements. Je trouve que de manquer ici de respect aux testeurs est dommageable. Rawhide par définition doit être utilisable et un paquet doit être testé par son mainteneur avant. Cela paraît être le minimum à faire.

Heureusement que cette mentalité a fortement régressé. Il n'y a plus beaucoup d'empaqueteurs qui tiennent encore de tels propos.

Les changements

Forcément l'intérêt de passer à Rawhide ou à une version de tests, c'est aussi découvrir et profiter des changements en avance. Pour l'instant pas de grands bouleversements. GNOME Shell et LibreOffice sont en avance d'une version par rapport à Fedora 25 (mais sont toujours en développement). Comme souvent leurs améliorations sont par petite touche et l'ensemble est plus agréable.

Le plus grand changement visible vient de GNOME Builder je pense, dont une bonne partie de l'interface a été changée. C'est l'IDE que j'utilise depuis une année maintenant et il évolue vraiment dans le bon sens, c'est très appréciable.

Après nous ne sommes qu'au début du développement de ce que deviendra Fedora 26. Les fonctionnalités ne sont pas encore toutes définies, et encore moins mises en place. Et les logiciels upstream aussi ont beaucoup à faire, GNOME n'a pas encore fini de changer (sa sortie étant dans 2 mois) par exemple.

J'espère que ce genre de billets vous plairont, je compte en faire mensuellement. Quand j'aurais des changements plus visibles je ferais des captures d'écran associés. Si cela intéresse les gens d'aller à l'aventure de Rawhide, n'hésitez pas, il y a très peu de testeurs mais beaucoup de besoins ! Et c'est grâce à cette activité que la Fedora stable est stable.

PHP version 5.6.30, 7.0.15 et 7.1.1

Remi Collet

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

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

Les RPM de PHP version 5.6.30 sont disponibles dans le dépôt remi pour Fedora 22-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.3
  • la version EL6 est construite avec RHEL-6.8
  • 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)

É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 17 janvier à minuit 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é.

AMC version 1.3.0

Patrice Kadionik

Les RPM d'AMC (Auto Multiple Choice) version 1.3.0 sont disponibles dans le dépôt eddy33 pour Fedora ≥ 23, versions 32 et 64 bits.


Installation :

# dnf install http://kadionik.vvv.enseirb-matmeca.fr/fedora/repo-eddy33-1.0-1.fc25.noarch.rpm
# dnf install auto-multiple-choice

++

Persistence des données

Matthieu Saulnier

Salut lecteur,

Oui toi, pas la peine de regarder à gauche ou à droite, il y a absolument personne, je parle bien à toi cher lecteur. Tu as cru que je t'avais oublié, pas vrai ? Du tout, mais comme tu le sais, j'ai eu pas mal de distractions ces derniers temps, j'ai vraiment du mal à trouver du temps pour t'écrire.

En plus, faut vraiment être motivé pour lire un article de plus sur Docker. Oui Docker, au travail j'ai carrément augmenté mon skill à ce sujet, et j'ai grave envie de t'en parler mon lecteur. D'ailleurs si t'as envie de connaitre mon opinion sur ce « truc », Aeris l'exprime parfaitement sur son blog, dans un article purement philosophique comme je les aime.

Au début je m'étais dit exactement comme tout le monde : AWESOME FAUT QUE JE DOCKERISE TOUS MES SERVEURS!!!! et puis je suis redescendu sur terre. Pour donner une proportion, j'en suis à 30% de mes services en container Docker, et ça n'augmentera plus. Pour illustrer pourquoi, je vais juste dire que mes serveurs imap et smtp utilisent les utilisateurs système de l'hôte, et ils doivent rester en correllation avec les utilisateurs SSH. C'est d'ailleurs la définition d'un « système », en fait. Pour le reste, soit.

Et puis vient la question de mettre quoi en container, de cloisonner quoi exactement. Dans un précédent article, je mettais tout en container, vraiment tout, et c'est vraiment pas pratique.

En fait, il m'a fallu un peu de temps avant de maitriser complètement la ligne de commande Docker, je parle de comprendre tous les concepts qu'elle induit, pour au final ne retenir qu'une seule philosophie. C'est le problème typique qu'on rencontre quand un système propose trop de possibilités. Avais-tu remarqué dans l'article précédent que je mettais les données statiques à disposition à travers un container statique ? Que se passerait-t-il si ce container disparaissait ?

Comme la plupart des gens qui font une utilisation intensive du service Docker, j'ai eu à un moment, tôt ou tard, besoin de supprimer /var/lib/docker pour résoudre un gros problème : Le service Docker ne démarrait plus. Inutile de te dire que le container disparait comme par magie, et que j'ai eu très peur pour mes données. Mais, je suis un hébergeur sérieux... j'ai des backups journaliers ^^

Cette mésaventure m'a poussé à repenser mes possiblités avec le service, cette fois-ci en considérant les containers comme non-définitifs. S'ils ne sont plus définitifs, alors ils ne doivent plus démarrer automatiquement au démarrage de l'hôte (virer l'option --restart always), et la "démonification" (option -d) doit être gérée par un gestionnaire de services, prenons Systemd.

Avec systemd, on pourra gérer à la fois le container, mais aussi les inputs passés au processus cloisonné.

L'avantage de passer par un orchestrateur de service est d'enlever au service Docker les rôles qui ne sont pas son point fort, comme le démarrage des containers dans un ordre précis, le redémarrage du container si le processus se termine en erreur (option --restart always), le status du processus cloisonné (le container est signalé comme "Up" alors qu'aucun processus n'est actif), et la gestion des logs du processus directement par Journald.

Pour récupérer la sortie standard et l'erreur, bref le log du processus, il faut que le container ne soit pas spawné avec l'option -d (détacher la tâche) pour ne pas qu'il parte en arrière-plan, c'est Systemd qui gère lui-même la partie « démon ». Du point de vue de Systemd, la commande ne forke pas, et toutes les sorties sont recueillies automatiquement par Journald.

Le second avantage est d'obtenir une meilleure intéraction avec le processus cloisonné. Tous les signaux comme SIGINT, SIGKILL et SIGHUP, envoyés par Systemd au container seront transférés par le service Docker directement au processus principal à l'intérieur du container. L'entrée standard reste ouverte si le container est attaché (à un tty ou à Systemd), mais on peut aussi demander de la laisser ouverte quand le container est détaché avec l'option -i.

Le service Docker ne sert plus d'intermédiaire comme un émulateur de VM qui doit relayer les signaux de fin de tâche à tous ses invités. Je serais tenté de croire qu'il y a un gain de temps non-négligeable dans le temps de réponse des processus, mais je n'ai pas fait de benchmark...

Et puis, les choses intéressantes commencent à arriver, on parle de container non-définitif, on parle de cloisonner seulement le processus, et surtout on parle de terminer le processus, tu as deviné la suite mon lecteur. =)

L'idée c'est de pouvoir perdre les containers, mais pas les données personnelles.

J'ai retourné toutes les pistes à fond, je suis même allé jusqu'au "container-boite-noire" (un trip vraiment obscure), mais aucune d'entre-elles ne répondait correctement à ma problèmatique. Si on perd les containers, il faut maitriser le moment de la perte (il ne faut pas que ce soit à un moment aléatoire). Pire encore, il faut recréer rapidement juste après les nouveaux containers qui doivent remplacer les anciens, et ils doivent être instantannément opérationnels sans avoir besoin de faire un quelconque setup manuel.

Il y a un événement que Systemd maitrise et qui pourrait servir de déclencheur à la destruction de l'ancien container. « Le processus se termine, alors je détruis le container. » Il y a une multitude de scénarios possibles, comme par exemple : « Au démarrage du nouveau processus, je détruis l'ancien container, puis je lance le nouveau » Tu remarqueras cher lecteur que lors du premier démarrage, il y aura des erreurs car aucun ancien container n'existe pas au préalable.

Heureusement, le service Docker gère bien ce point (ouf!), il suffit de passer dans la ligne de commande l'option --rm et lorsque le processus se terminera, son container sera détruit automatiquement. Systemd n'aura qu'à spawner les containers et tuer les processus à l'intérieur. C'est ce qu'on attend d'un gestionnaire de services, en fait.

Et donc, si l'on se dit que les données perso n'ont pas besoin d'être isolées, alors on peut les laisser dans un répertoire quelconque sur le disque dur (avec l'option -v).

Volume de données quelconque, mais pas trop, quand même...

Le service Docker va gérer les modes et ownership des fichiers. Si le processus cloisonné les modifie, alors ils changeront sur le disque dur. Il est question seulement des fichiers à l'intérieur du volume exposé, il ne peut pas altérer les fichiers à l'extérieur. Tu remarqueras cher lecteur, que le processus peut changer lui-même les permissions du répertoire racine (le lien entre le volume sur disque et le volume dans le container). Si tu veux que les autres utilisateurs ne puissent pas regarder dedans, tu peux setter manuellement en root les bonnes permissions sur le répertoire parent.

Dans cet optique de permissions, il vaut mieux regrouper les volumes exposés du container dans un seul répertoire par container, pour pouvoir globalement interdire, ou pas, l'accès aux volumes du container aux utilisateurs système.

Okay on gère les droits linux de base, voyons si on peut pas augmenter le level.

SELinux propose une couche d'abstraction supplémentaire à la gestion des droits linux (jugée imparfaite par la NSA), directement au niveau du noyau Linux... mais je radotte, tu le sais déjà mon vieux lecteur. Le service Docker propose une option intéressante pour les systèmes possèdant SELinux. Oui, toute l'arborescence de répertoires exposée sur disque par le container sera cloisonnée par SELinux. Aucun processus, s'il n'a pas le droit de modifier les fichiers ayant le contexte 'svirt_sandbox_file_t', ne pourra JAMAIS altérer cette arborescence. Je sais pas pour toi, mais moi, perso, ça me fait kiffer. On pourrait aller beaucoup plus loin avec le mode Multi Level Security, malheureusement ce n'est pas le mode courant sur mon serveur.

En ligne de commande ça ressemble à ça :
-v /rep/sur/hote:/rep/dans/container:Z

Cette option exécute automatiquement un change context (commande 'chcon') sur les répertoires du disque. Attention pour que ce soit persistent après un restorecon il faut ajouter la règle avec semanage :
semanage fcontext -a -s system_u -t svirt_sandbox_file_t "/contener/mariadb-casper-im(/.*)?"
Dans tous les cas, il faut user et abuser de la commande restorecon pour bien vérifier ses règles, et je t'invite à lire cet article qui m'a sauvé la vie, d'ailleurs.

Pour terminer en beauté, le service Docker ne supprime pas les volumes exposés sur disque. Que ce soit dans le répertoire par défaut (/var/lib/docker/volumes) ou bien un répertoire assigné avec l'option -v, ce répertoire ne sera pas supprimé si le container est volontairement ou involontairement supprimé.

Voici une unité systemd pour le serveur de base de données de ma messagerie instantannée (Jabber) en guise d'exemple :

[Unit]
Description=Mariadb Server Casper IM
After=docker.service

[Service]
Restart=always
EnvironmentFile=/etc/%p.env
ExecStart=/usr/bin/docker run -i --rm --name %p -p 127.0.0.1:16000:3306 \
          -e MYSQL_USER \
          -e MYSQL_PASSWORD \
          -e MYSQL_DATABASE \
          -e MYSQL_ROOT_PASSWORD \
          -v /contener/%p/var/lib/mysql/data:/var/lib/mysql/data:Z \
          -v /contener/%p/etc/my.cnf.d:/etc/my.cnf.d:Z \
          -v /contener/%p/var/log/mariadb:/var/log/mariadb:Z \
          mariadb:10.1.20-8
ExecReload=/usr/bin/kill -HUP $MAINPID

[Install]
WantedBy=multi-user.target


Le fichier /etc/mariadb-casper-im.env contient les credentials du serveur Mariadb (user mysql, mot de passe, etc...) Il initialise les variables d'environnement MYSQL_USER, MYSQL_PASSWORD, etc... présentes dans l'unité systemd. Il a aussi le mode 400 car il contient des mots de passe. L'image docker est une image custom basée sur celle de Fedora Cloud (le dépôt Git.) Ma seule modification n'est pas vraiment une contribution, j'ai juste ajouté 2 volumes exposés.

VOLUME ["/var/lib/mysql/data", "/etc/my.cnf.d", "/var/log/mariadb"]

Voici quelques conseils de gestion de disque :
  1. Regrouper les volumes exposés dans un répertoire par container
  2. Regrouper les répertoires de container sur une partition montée
  3. Cette partition devrait être un volume LVM de type miroir
  4. Cette configuration ne dispense pas d'avoir des backups journalier (dump de base de données ou autre)
En parlant backup, n'hésitez pas à vous servir de 'docker exec' pour intéragir avec le programme cloisonné, par exemple :

docker exec -i mariadb-casper-blog  mysqldump --opt -u casperlefantom -p$MYSQL_USER_PASSWORD casperlefantom > db-casperlefantom-$(date +%Y%m%d).dump

Magie, le fichier "db-casperlefantom-20161220.dump" est généré à l'extérieur du container. J'ai volontairement utilisé des exemples avec Mariadb car c'est le programme qui m'a donné le plus de fil à retordre, les autres programmes comme apache pour servir des sites statiques étaient bien plus faciles, sans credentials, sans variables d'environnement, etc... Mais toujours avec backup ;)

[Unit]
Description=Apache HTTP Server Vhost onion1
After=docker.service

[Service]
Restart=always
ExecStart=/usr/bin/docker run -i --rm --name %p -p 127.0.0.1:8085:80 \
          -v /contener/%p/var/www/html:/var/www/html:Z \
          -v /contener/%p/etc/httpd/conf.d:/etc/httpd/conf.d:Z \
          -v /contener/%p/etc/pki/tls/private:/etc/pki/tls/private:Z \
          -v /contener/%p/etc/pki/tls/certs:/etc/pki/tls/certs:Z \
          -v /contener/%p/var/log/httpd:/var/log/httpd:Z \
          apache-single:2.4.23-2
ExecReload=/usr/bin/docker exec %p /usr/sbin/httpd -k graceful

[Install]
WantedBy=multi-user.target
Pour ajouter de l'orchestration entre les services, on peut jouer avec les options After et BindTo dans la partie [Service] des unités systemd. Indispensable lorsque l'on utilise du linkage entre 2 containers...

Création du dépôt Fedora eddy33

Patrice Kadionik

Salut.

Cela faisait pas mal de temps que je cherchais l'occasion de créer un dépôt Fedora... C'est fait !

J'utilise le logiciel libre AMC (Auto Multiple Choice) pour créer des QCM avec autocorrection après scan des copies afin d'évaluer certains de mes cours.

AMC est un logiciel plutôt génial pour cela : http://home.gna.org/auto-qcm/

Malheureusement, il n'est plus maintenu sous forme de paquetages RPM pour Fedora depuis la version 21. J'ai ainsi comblé ce vide avec la création du dépôt eddy33. Le dépôt eddy33 propose AMC pour Fedora 23 et supérieur en version 32 et 64 bits. Voici donc le premier paquetage que je maintiens. Il faut bien un début ;-)" class="smiley

L'accès au dépôt eddy33 se fait par la commande :
# dnf install http://kadionik.vvv.enseirb-matmeca.fr/fedora/repo-eddy33-1.0-1.fc25.noarch.rpm

Les paquetages disponibles sont signés.

++

PHP version 5.6.30RC1, 7.0.15RC1 et 7.1.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 5.6.30RC1 sont disponibles en SCL et en paquets de base dans le dépôt remi-test pour Fedora22 et Enterprise Linux5 (il s'agit de la dernière RC pour la branche 5.6 qui est désormais uniquement en support de sécurité).

Les RPM de PHP version 7.0.15RC1 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 22 et Enterprise Linux6.

Les RPM de PHP version 7.1.1RC1 sont disponibles en SCL dans le dépôt remi-test et les paquets de base dans le dépôt remi-php71-test pour Fedora 22 et Enterprise Linux6.

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

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

yum --enablerepo=remi-test install php56

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

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

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.1RC1 est aussi disponible dans Fedora rawhide.

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 (php56, php70, php71)

Paquets standards (php)

Fedora 25 vs Fedora 24 : comparaison des performances pour les versions 32 bits

Patrice Kadionik

Salut.

Voici les résultats comparatifs de Fedora 25 vs Fedora 24.

Pour rappel, ma machine est équipée d'un Quad Core Intel Q6600 à 2,4 GHz avec 4 Go de RAM.

Je me suis limité au benchmark UnixBench qui fournit un indice global, ce qui me simplifiera la comparaison. La version UnixBench utilisée est la version 4.1.0.

Mon protocole de tests est le suivant :
  • Installation de Fedora 25 version 32 bits avec le noyau Fedora 4.8.14-300.fc25.i686.
  • La machine est placée en niveau 3 (init 3).
  • 10 séries de tests avec UnixBench compilé sous Fedora 25 et exécuté sous Fedora 25 (4.8.14-300.fc25.i686).
  • 10 séries de tests avec UnixBench compilé sous Fedora 24 et exécuté sous Fedora 24 (4.8.14-200.fc24.i6866).
Voici les résultats obtenus :



Fedora 25 version 32 bits :

Série 1 : 778.2
Série 2 : 796.6
Série 3 : 636.6
Série 4 : 817.0
Série 5 : 837.5
Série 6 : 798.1
Série 7 : 814.8
Série 8 : 807.5
Série 9 : 806.6
Série 10 : 819.3

Moyenne : 791,2

Fedora 24 version 32 bits :

Voici pour rappel les résultats obtenus avec Fedora 24 :
Série 1 : 789.8
Série 2 : 793.5
Série 3 : 783.6
Série 4 : 794.6
Série 5 : 782.0
Série 6 : 788.2
Série 7 : 826.6
Série 8 : 819.1
Série 9 : 825.6
Série 10 : 821.4

Moyenne : 802,4

Résultats :

Pour Fedora 25, on obtient un indice moyen de 791,2 pour UnixBench.
Pour Fedora 24, j'avais obtenu un indice moyen de 802,4 pour UnixBench.


On a donc une baisse de 1,4 % de Fedora 25 32 bits par rapport à Fedora 24 32 bits :

perfs_fedora_F25.png

Conclusion :


Au moment de ces tests, le noyau Fedora 25 (basé sur le noyau vanilla 4.8.14 -300) est aussi performant que le noyau Fedora 24 (basé sur le noyau vanilla 4.8.14 -200). Le résultat est cohérent.


++

Fin de vie de Fedora 23

Charles-Antoine Couret

Depuis le 20 décembre 2016, Fedora 23 a été déclaré comme en fin de vie.

Qu'est-ce que c'est ?

Un mois après la sortie d'une Fedora version n, ici Fedora 25, la version n-2 (donc Fedora 23) 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 supportée 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 23 et antérieurs d'effectuer la mise à niveau vers Fedora 25 ou 24.

Que faire ?

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

Il est également possible de faire la mise à niveau sans réinstaller via DNF. Pour cela, taper les commandes suivantes en root dans votre terminal :

# dnf install dnf-plugin-system-upgrade
# dnf system-upgrade download --releasever=24
# dnf system-upgrade reboot

Notez que vous pouvez également passer directement à Fedora 25 par ce biais en changeant le numéro de version correspondante dans la ligne idoine. Cependant cette procédure est plus risquée car moins testée.

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

Fedora 24 vs Fedora 23 : comparaison des performances pour les versions 32 bits

Patrice Kadionik

Salut.

Voici les résultats comparatifs de Fedora 24 vs Fedora 23.

Pour rappel, ma machine est équipée d'un Quad Core Intel Q6600 à 2,4 GHz avec 4 Go de RAM.

Je me suis limité au benchmark UnixBench qui fournit un indice global, ce qui me simplifiera la comparaison. La version UnixBench utilisée est la version 4.1.0.

Mon protocole de tests est le suivant :
  • Installation de Fedora 24 version 32 bits avec le noyau Fedora 4.8.14-200.fc24.i686.
  • La machine est placée en niveau 3 (init 3).
  • 10 séries de tests avec UnixBench compilé sous Fedora 24 et exécuté sous Fedora 24 (4.8.14-200.fc24.i6866).
  • 10 séries de tests avec UnixBench compilé sous Fedora 23 et exécuté sous Fedora 23 (4.3.5-300.fc23.i686).
Voici les résultats obtenus :



Fedora 24 version 32 bits :

Série 1 : 789.8
Série 2 : 793.5
Série 3 : 783.6
Série 4 : 794.6
Série 5 : 782.0
Série 6 : 788.2
Série 7 : 826.6
Série 8 : 819.1
Série 9 : 825.6
Série 10 : 821.4

Moyenne : 802,4

Fedora 23 version 32 bits :

Voici pour rappel les résultats obtenus avec Fedora 23 :
Série 1 : 835.3
Série 2 : 851.1
Série 3 : 847.8
Série 4 : 860.2
Série 5 : 842.4
Série 6 : 835.0
Série 7 : 862.8
Série 8 : 831.9
Série 9 : 865.3
Série 10 : 852.4

Moyenne : 848,4

Résultats :

Pour Fedora 24, on obtient un indice moyen de 802,4 pour UnixBench.
Pour Fedora 23, j'avais obtenu un indice moyen de 848,4 pour UnixBench.


On a donc une baisse de 5,4 % de Fedora 23 32 bits par rapport à Fedora 23 32 bits :

perfs_fedora_F24.png

Conclusion :


Au moment de ces tests, le noyau Fedora 24 (basé sur le noyau vanilla 4.8.14) est moins performant de près de 6 % que le noyau Fedora 23 (basé sur le noyau vanilla 4.3.5).


++

ImageMagick6 et ImageMagick7

Remi Collet

Les RPM des dernières versions de la bibliothèque ImageMagick sont disponibles dans le dépôt remi pour Fedora et Enterprise Linux.

J'ai construit ces RPM afin de pouvoir bénéficier de l'ensemble des fonctions de l'extension imagick lors de l'installation du paquet php-pecl-imagick. Il remplace l'ancien ImageMagick-last (le nom étant ambigu).

Les paquets ImageMagick6-libs et ImageMagick7-libs sont conçus pour s'installer à côté de ImageMagick du dépôt officiel. Les applications utilisent la bonne version des bibliothèques fournies.

Sous Fedora, Il est possible de remplacer la version d'ImageMagick par ImageMagick6 ou ImageMagick7 afin de disposer de la dernière versions des commandes, puisque les bibliothèques sont fournies par ImageMagick-libs. Sous Enterprise Linux, ce n'est pas possible car ImageMagick fournit à la fois les commandes et les bibliothèques. Si vous n'avez pas du tout installé ImageMagick, et pas besoin de l'ancienne version des bibliothèques, sur votre machine, vous pouvez aussi installer ImageMagick7 pour bénéficier ainsi de la dernière version des commandes.

Pour l'extension PHP imagick, c'est encore la version 6 qui est utilisée. En effet plusieurs fonctions ont été supprimées de la version 7, ce qui entraine leur suppression de l'extension. Ces fonctions seront très prochainement dépréciées, et supprimées d'une prochaine version de l'extension (cf bug #162).

Les paquets sont disponibles pour toutes les versions de Fedora, RHEL et CentOS puisque les sonames (version des bibliothèques) sont différents.

Pour mémoire:

  • Fedora : ImageMagick 6.9.3, soname = 6.Q16.so.2
  • EL-7 : ImageMagick 6.7.8, soname = 6.Q16.so.1
  • EL-6 : ImageMagick 6.7.2, soname = 6.Q16.so.1
  • Version 6.9.6-8, soname = 6.Q16.so.3
  • Version 7.0.3.10, soname = 7.Q16HDRI.so.1

 

PHP version 5.6.29 et 7.0.14

Remi Collet

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

Les RPM de PHP version 5.6.29 sont disponibles dans le dépôt remi pour Fedora 22-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.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.2
  • la version EL6 est construite avec RHEL-6.8
  • 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)

Installer PHP 7.1 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.1.

 

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 25

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

Fedora 24

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

RHEL version 7.2 ou 7.3

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.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
rhn-channel --add --channel=rhel-$(uname -i)-server-optional-6

CentOS version 7.2 (ou 7.3)

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-php71

Les paquets sont dans les dépôts remi-safe (activé par défaut) et remi-php71 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-config-manager --enable remi-php71

Fedora

dnf config-manager --set-enabled remi-php71

 

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.1.0 (cli) (built: Dec  1 2016 06:23:20) ( NTS )
Copyright (c) 1997-2016 The PHP Group
Zend Engine v3.1.0-dev, Copyright (c) 1998-2016 Zend Technologies
    with Zend OPcache v7.1.0, Copyright (c) 1999-2016, by Zend Technologies
    with Xdebug v2.5.0, Copyright (c) 2002-2016, 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 (memcache, redis...), 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 PHP 5, cela est possible en utilisant les paquets préfixés php71 Voir le billet PHP 7.1 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 26 (la proposition de changement 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 100 000 téléchargements par jour, le dépôt remi est devenu en 10 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 :

PHPUnit 5.7

Remi Collet

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

Documentation : PHPUnit 5.7 manual et Release Announcement for PHPUnit 5.7.0 (english)

emblem-notice-24.pngCette nouvelle version nécessite PHP ≥ 5.6 (PHPUnit est disponible dans le dépôt remi, car PHP 5.4 et 5.5 ont atteint leur fin de vie).

Installation, Fedora :

dnf --enablerepo=remi install phpunit

Installation, Enterprise Linux :

yum --enablerepo=remi,remi-php56 install phpunit

Remarque: cet outil est une pièce essentielle de la QA PHP dans Fedora. Cette version est aussi disponible dans les dépôts officiels de Fedora rawhide (donc utilisée par Koschei). Je prévois une mise à jour dans Fedora 24 et 25 prochainement.

PHP version 7.1.0 est sorti !

Remi Collet

La RC6 était bien GOLD, donc la version 7.1.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 un version de qualité.

Les RPM sont disponibles dans le dépôt remi-php71 pour Fedora 23 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.1.0 Release Announcement (en anglais).

La tribu sagrandit:

Tribe.jpg

Lire aussi :

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.1 (le plus simple) :

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

emblem-important-2-24.pngIl est possible que la mise à jour échoue si des extensions installées ne sont pas encore disponibles pour PHP 7, cela évite de casser une installation sans avertissement, grâce à la protection de la compatibilité de l'ABI (php(zend-abi)). Après vérification, il peut donc être nécessaire de désinstaller certaines extensions avant la mise à jour. Normalement, l'ensemble des extensions compatibles PHP 7 sont aussi disponibles pour PHP 7.1 (sauf phalcon).

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

yum install php71

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

  • la version EL7 est construite avec RHEL-7.2
  • la version EL6 est construite avec RHEL-6.8
  • cette version sera la version par défaut de Fedora 26, voir PHP 7.1
  • les extensions commencent à être disponibles, voir la page PECL extension RPM status..

emblem-notice-24.pngInformations, lire :

Paquets de base (php)

Software Collections (php70)

Paris Open Source Summit 2017 (compte-rendu)

Emmanuel Seyman

Il y a deux semaines avait lieu le Paris Open Source Summit, 2ième édition et Borsalinux-Fr y ténait un stand (pour la première fois, personne n'ayant pu se libérer l'année passée).

Je suis arrivé avec le matériel de l'association et j'ai rapidement retrouvé Jean-Baptiste. Le temps de déplier le totem, de coller quelques affiches puis de répartir sur la table les différents goodies et bonbons que nous avions apportés et nous étions fin prêt à recevoir le public. Le mercredi matin a connu une affluence relativement importante et nous avons pu distribuer des DVDs Fedora 24 (tout en expliquant que Fedora 25 sortait dans très peu de temps). Nous avons parlé des différences de Fedora par rapport aux autres distributions, du travail de traduction que nous faisons pour le projet et répondu à tout un tas de questions. L'après-midi, J.-B. a cédé la place à misc qui était venu nous prêter main-fort (j'avais prévu de passer la première journée sur le stand des Mongueurs de Perl).

Le jeudi a été un peu plus calme mais J.-B. et moi avons continué à répondre aux questions et distribuer des goodies. En début d'après-midi, Deb Bryant du pôle Open Source & Standards de Red Hat est passée nous voir pour nous remercier de tout le travail que faisons pour faire vivre la distribution. À intervalles réguliers, j'ai profité de creux dans les visites pour aller discuter avec nos amis des stands voisins (Ubuntu-Fr, Framasoft, Ada-France, Joomla-Fr, ...).

La journée terminée, nous avons nos affaires de stand et sommes rentrés bien fatigués.

Passage à Fedora Rawhide

Charles-Antoine Couret

Alors que le 22 novembre a donné lieu à la sortie de Fedora 25 en version stable après 6 mois de gestation, j'en ai profité dès le soir même pour passer à Fedora Rawhide (la future F26). Cela fait depuis Fedora 15 que j'installe des versions instables, en général pour la Beta ou Alpha. Depuis Fedora 22 j'essaye de passer à Rawhide avant la Alpha de la version à venir. Reculant de plus en plus, j'atteins enfin le stade où ma machine personnelle n'exploite plus une Fedora stable durant tout un cycle de développement.

Si je le fais, c'est déjà grâce au grand travail opéré depuis pour stabiliser ces branches. À l'époque de Fedora 15, s'aventurer sur Rawhide était très complexe, nécessitant souvent de prévoir des logiciels alternatifs opérationnels au cas où qu'une mise à jour rende un logiciel inopérant tels que GNOME, Firefox ou LibreOffice. Il était préférable aussi d'être à l'aise avec les environnements restreints et certains outils comme YUM (à l'époque) pour se sortir de mauvaises passes. Les progrès sont visibles, les versions instables d'aujourd'hui sont bien plus fiables que les versions stables du passé selon moi. Même si cela reste perfectible bien entendu. Mais je n'ai plus de bogues rendant ma machine inutilisable, ne serait-ce le temps d'une mise à jour pour corriger le problème.

Ensuite, après tout ce temps à utiliser des versions instables, je constate le déficit important de testeurs et c'est pourquoi je souhaite grossir constamment les rangs. Beaucoup trop de problèmes sont découverts à la sortie de la version stable car peu de personnes ont jugé utile de sauter le pas plus tôt. Et même parmi ceux qui testent en avance de phase, trop de gens encore prennent ces versions pour un jouet, pour découvrir les changements en général. Mais oubliant de signaler les bogues quand ils en trouvent. C'est pourtant l'essence même de ces versions, traquer les bogues pour les corriger avant la mise à disposition en version finale.

Enfin, j'adore tester des programmes, essayer de les faire planter, découvrir les changements et voir les choses s'améliorer. Je dois dire que les versions stables de Fedora sont aujourd'hui trop fades de ce point de vue. Ce qui est une bonne chose bien sûr, c'est ce qu'on recherche au sein du projet Fedora.

Comme depuis Fedora 20, j'utilise la mise à niveau pour changer de version, comme suit :

# dnf install dnf-plugin-system-upgrade
# dnf system-upgrade download --releasever=rawhide
# dnf system-upgrade reboot

Tout s'est bien passé. J'ai dû uniquement virer supertuxkart pour des raisons de dépendance pour que cela fonctionne. Je ne note pas de régressions particulières, GNOME avec Wayland tourne toujours aussi bien. Les applications également. J'ai toujours cependant un bogue gênant depuis la mise à jour de Firefox 50 sur Fedora 25 (que j'ai rapporté), si je charge plusieurs vidéos au cours d'une sessions de Firefox (que ce soit Youtube, Dailymotion ou une autre plateforme), il se peut que les vidéos bouclent sur des buffers d'une seconde environ. Le fichier continuant à se lire, le son étant quant à lui totalement normal et linéaire. Ce bogue n'est donc pas corrigé par ce changement.

Après il est vrai que les programmes de Rawhide ne sont pas radicalement différents que sous F25 encore. GNOME n'est qu'au début du développement de sa future version et le passé nous a montré que cela pouvait être parfois plus chaotique un peu plus tard...

Je vous encourage bien sûr à sauter le pas aussi, si l'aventure ne vous rebute pas trop. Dans ce cas, n'hésitez pas à rapporter un bogue, effectuer les tests de non régression du noyau, à noter les mises à jour du système et enfin à participer aux journées de tests.

J'essayerais durant tout le cycle de vous tenir au courant des évolutions de Rawhide, de vous décrire comment y participer activement (bien que les quatre liens cités plus haut soient les principales activités à réaliser), et peut être de vous présenter les changements notables que j'aurais noté. :-)" class="smiley

PHP version 5.6.29RC1 et 7.0.14RC1

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.

Les RPM de PHP version 5.6.29RC1 sont disponibles en SCL et en paquets de base dans le dépôt remi-test pour Fedora22 et Enterprise Linux6.

Les RPM de PHP version 7.0.14C1 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 22 et Enterprise Linux6.

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

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

yum --enablerepo=remi-test install php56

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

yum --enablerepo=remi-test install php70

Mise à jour, de PHP 5.6 :

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

Mise à jour, de PHP 7.0 :

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

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 (php56, php70)

Paquets standards (php)

Fedora 25 est de sortie, Wayland enfin par défaut !

Charles-Antoine Couret

En ce mardi 22 novembre 2016, le projet Fedora est fier dannoncer la sortie de la distribution GNU/Linux Fedora 25.

Comme à son habitude, le projet Fedora propose le dernier cru des environnements GNOME, GNOME 3.22.

Cette version de Fedora s'est surtout concentrée sur deux axes : couche graphique et simplicité.

Couche graphique

La nouveauté la plus importante est sans conteste la mise à disposition par défaut de Wayland pour l'environnement bureautique GNOME. Fedora devient ainsi la première distribution majeure à faire ce choix, pour promouvoir ce projet novateur annoncé il y a huit ans maintenant. Wayland consiste en une remise à plat du serveur graphique historique X11 (qui a plus de 30 ans) en tenant compte de l'évolution des usages et de l'architecture de nos machines aujourd'hui. Wayland vise à améliorer la sécurité du système, en évitant qu'une application quelconque puisse dessiner sur d'autres applications par exemple. Il pourrait à terme améliorer les performances, en exploitant pleinement l'accélération matérielle par les cartes graphiques. Puis il devrait améliorer la fiabilité du système, en améliorant l'architecture du programme et en facilitant sa maintenance.

Cependant, si Wayland commence à devenir mûr, de nombreuses fonctionnalités restent à proposer par rapport à l'expérience proposée par X11. C'est pourquoi, à l'ouverture de la session GNOME, il reste possible de choisir X11. Pour ceux qui n'ont pas besoin de ces fonctions, l'usage de Wayland devrait être totalement transparent.

La distribution propose de mieux exploiter les machines avec deux cartes graphiques, une intégrée au processeur et une autre externe. Cette configuration, très populaire sur les ordinateurs portables récents, permet en temps normal d'avoir une carte graphique minimale suffisante pour la bureautique qui consomme peu d'énergie et d'utiliser la carte externe pour les applications gourmandes. Jusquici, votre environnement fonctionnait avec une carte graphique seulement et sans possibilité de changer celle en fonction. Aujourd'hui, celle intégrée au processeur est utilisée par défaut. Puis, en cas de besoin, vous pouvez lancer un logiciel sur l'autre carte graphique. Cela nécessite de lancer le programme avec la variable d'environnement DRI_PRIME=1 ou via un clic droit pour lancer l'application dans l'interface GNOME Shell.

Simplicité

L'assistant à la saisie IBus a bénéficié de deux améliorations importantes. Tout d'abord, son aide à la saisie rapide peut proposer les emoji. Plutôt que d'insérer manuellement les caractères UNICODE correspondants, ici ils seront donc suggérés. Ce même assistant, qui suggère des mots durant la frappe peut gérer plusieurs langues à la fois. Ainsi il est possible d'autocompléter le terme en cours en anglais alors que la phrase est en français et inversement.

Nous en avions parlé pour Fedora 24, l'utilitaire LiveUSB Tools est la méthode de téléchargement de Fedora par défaut. L'objectif est en effet que l'utilitaire télécharge et installe très simplement une version spécifiée de Fedora, qui peut être un Spin par exemple. Cela évite notamment de devoir graver l'image disque à la main sur clé USB ou CD, étape compliquée pour trop d'utilisateurs potentiels. Cette fois, l'utilitaire est disponible pour Windows et macOS également, d'où la mise en avant pour cette version.

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

Liens

Redis depuis PHP

Remi Collet

Voici un petit récapitulatif des différents moyens d'utiliser une base de données Redis depuis PHP sous Linux

L'ensemble des tests ont été réalisés sous Fedora 25 mais devrait fonctionner avec RHEL, CentOS ou une autre distribution.

Solution testées:

 

Pour chaque solution, j'ai utilisé 3 jeux d'essai (lancé une dizaine de fois pour avoir une valeur moyenne)

  • connexion et incrément d'une valeur, uniquement pour mesurer le coût de la connexion
  • connexion et set / get de 10000 valeurs numériques
  • connexion et set / strlen de ~2700 valeurs importantes (l'ensemble des pages de man 1)

1. Extension redis

Composants nécessaires :

  • Extension redis
  • Paquets RPM: php-pecl-redis

Exemple de code :

<?php
$time = microtime(true);
$redis = new Redis();
$redis->connect('127.0.0.1', 6379);
printf("Value = %d\n", $redis->incr("foo"));
$time = microtime(true)-$time;
printf("Done in %.6f\n", $time);

Résultats :

  • Connexion : 0.000299
  • Set / get : 0.277000
  • Set / strlen : 0.110900

C'est la solution la plus connue est la plus utilisée, j'ai malheureusement de gros doute sur la qualité du code actuel de l'extension.

2. Bibliothèque Predis

Composants nécessaires:

  • Bibliothèque Predis
  • Paquets RPM: php-nrk-Predis

Exemple de code :

<?php
require 'Predis/Autoloader.php';
Predis\Autoloader::register();
$time = microtime(true);
$redis = new Predis\Client(['host' => '127.0.0.1', 'port' => 6379]);
printf("Value = %d\n", $redis->incr("foo"));
$time = microtime(true)-$time;
printf("Done in %.6f\n", $time);

Résultats :

  • Connexion : 0.001890
  • Set / get : 0.375500
  • Set / strlen : 11.445000

Rien d'étonnant à ce qu'une implémentation pure PHP soit nettement plus lente. C'est évidement le chargement de la bibliothèque qui pénalise la connexion, ensuite l'exécution de requêtes simples (get/set) reste très acceptable.

3. Extension phpiredis

Composants nécessaires:

  • Extension phpiredis
  • Paquets RPM: php-phpiredis, hiredis

Exemple de code :

<?php
$time = microtime(true);
$redis = phpiredis_connect('127.0.0.1', 6379);
printf("Value = %d\n", phpiredis_command($redis, "INCR foo"));
$time = microtime(true)-$time;
printf("Done in %.6f\n", $time);

Résultats :

  • Connexion : 0.000241
  • Set / get : 0.288100
  • Set / strlen : 0.105000

Les résultats sont comparables à ceux de l'extension redis.

Il est dommage que cette extension, pourtant ancienne, soit toujours en phase de développement (beta). Le code très simple (~1000 lignes contre ~20000 pour redis), et utiliser la bibliothèque hiredis me semble beaucoup plus sain et maintenable à long terme.

4. Bibliothèque Predis avec l'extension phpiredis

Composants nécessaires:

  • Bibliothèque Predis
  • Extension phpiredis
  • Paquets RPM: php-nrk-Predis, php-phpiredis, hiredis

Exemple de code :

<?php
require 'Predis/Autoloader.php';
Predis\Autoloader::register();
$time = microtime(true);
$redis = new Predis\Client(['host' => '127.0.0.1', 'port' => 6379], ['connections' => ['tcp' => 'Predis\\Connection\\PhpiredisSocketConnection']]);
printf("Value = %d\n", $redis->incr("foo"));
$time = microtime(true)-$time;
printf("Done in %.6f\n", $time);

Résultats :

  • Connexion : 0.001795
  • Set / get : 0.378900
  • Set / strlen : 0.145300

Comme indiqué dans la documentation, la bibliothèque Predis est largement optimisée en utilisant l'extension phpiredis pour les données importantes. Les résultats des tests sont donc très acceptables.

5. Conclusion

À vous de faire votre choix à la lecture des résultats.

J'aurais tendance à privilégier l'extension phpiredis lorsque la vitesse est une priorité absolue, et la bibliothèque Predis pour la beauté du code. Ce couple suivant une rationalisation aussi suivi par d'autres projets (e.g. mongo => mongodb) ou l'extension est réduite au minimum en utilisant une bibliothèque dédiée (ici hiredis) et se charge uniquement de la partie bas niveau, là où les perfornances sont nécessaires, la bibliothèque fournissant la partie haut niveau au développeur.

Je prévois d'aider l'auteur de l'extension phpiredis pour qu'une version soit publié, et si possible sur la forge PECL afin de lui donner la visiblité qu'elle me semble mériter. Alors je soumettrais probablement une revue pour les dépôts officiels de Fedora/EPEL.

 

P.S. le code complet utilisé pour les tests : redis.txt, predis.txt, phpiredis.txt

Page générée le 21 jan 2017 à 18:02