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.

PHPUnit 5.3

Remi Collet

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

Documentation : PHPUnit 5.3 manual et Release Announcement for PHPUnit 5.3.0 (english)

emblem-notice-24.pngCette nouvelle version nécessite PHP ≥ 5.6.

Installation, Fedora :

dnf --enablerepo=remi install phpunit

Installation, Enterprise Linux :

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

Remarque: cet outil est un epièce essentielle de la QA PHP dans Fedora.

PHP version 5.5.34, 5.6.20 et 7.0.5

Remi Collet

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

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

Les RPM de PHP version 5.5.34 sont disponibles dans le dépôt remi pour Fedora 20 et dans le dépôt remi-php55 pour Enterprise Linux.

emblem-important-2-24.pngPHP version 5.4 a atteint sa fin de vie et n'est plus maintenu par le projet. Compte tenu du nombre important de téléchargements par les utilisateurs de mon dépôt la version présente dans le dépôt remi pour Enterprise Linux (RHEL, CentOS...) a été conservée avec les correctifs de sécurité (de la version 5.5.34). La mise à jour vers une version maintenue est fortement conseillée.

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-important-2-24.png La version 5.5.27 était la dernière mise à jour corrigeant des bugs. La branche 5.5 est donc en maintenance de sécurité uniquement (jusqu'en Juillet 2016).

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

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

yum-config-manager --enable remi-php55
yum update

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

yum --enablerepo=remi install php55

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.7
  • beaucoup de nouvelles extensions sont aussi disponible, voir PECL extension RPM status page

emblem-notice-24.pngInformations, lire :

Paquets de base (php)

Software Collections (php55 / php56 / php70)

Refonte de script

Sylvain Réault

J'ai modifié le script qui génère le dépôt.
Désormais il sera automatiquement lancé, du coup je n'ai plus que le transfert des paquets à effectuer.
Je vais reprendre certains protocoles pour me rapprocher de ce qui ce fait actuellement. Surtout regardé du coté de KOJI qui devrait encore simplifier les prochaines versions.

Par contre la version ARM n'est toujours pas disponible et je m'en excuse. Je travail sur une machine virtuel (VM) pour pouvoir vous proposer des paquets correct.
Comme je n'y connais pas encore grand chose pour l'installation et l'exploitation d'une VM sous ARM (cela à l'air plus complexe qu'une simple image iso), cela risque de prendre un peu de temps.
Surtout que reprenant le chemin d'un emploi, je risque de ne plus en avoir souvent.

Enfin pour finir, la version pour Fedora 24 est disponible et n'a pas l'air de poser de problèmes. Je vais reprendre le .spec de cette version (qui est identique pour la RAWHIDE actuel, autrement dit Fedora 25), pour voir si je n'ai pas oublié quelques options.
Surtout celle concernant le pilote graphique virgl qui permet d'utiliser les performances et l'accélération graphique par le GPU (puce/processeur graphique) hôte dans une VM (sous KVM/QEMU).
Cela permet d'éviter de devoir dédié un matériel graphique ( autrement dit vgapassthrough) à cette tache.

Statistiques par version de PHP

Remi Collet

Voici quelques statistiques de téléchargement pour les différentes versions de PHP depuis le dépôt remi.

Calculées à partir des ~100k téléchargements en 1 mois.

Paquets de base (version unique)

  • 5.4.45: 32.6% (représentait 47% en octobre 2015)
  • 5.5.33: 18.9% (5.5.29 représentait 21%)
  • 5.6.19: 41.3% (5.6.13 représentait 31%)
  • 7.0.4: 7.2%

php-201603.png

Paquets SCL (installation en parallèle de plusieurs versions)

  • 5.4.45: 10.4%
  • 5.5.33: 16.6%
  • 5.6.19: 41.5%
  • 7.0.4: 31.5%

Les chiffres des SCL sont moins intéressants, car les elles sont utilisées pour avoir plusieurs versions, souvent sur une station de développement, ou pour tester une nouvelle version, ou pour conserver un ancienne version pour une ancienne application.

Conclusion: l'utilisation de 5.4 reste beaucoup trop élevé pour une version morte (non maintenue), même si l'intègre quelques correctifs de sécurité dans mes paquets (rétro-porté depuis 5.5), je recommande vivement de faire la mise à jour vers une version maintenue, 5.5 (fin de vie en juillet 2016) ou mieux 5.6 (fin de vie en Decembre 2018).

 

 

Fedora 24 Alpha est disponible !

Charles-Antoine Couret

En ce mardi 29 mars, les utilisateurs du Projet Fedora seront ravis d'apprendre la disponibilité de l'Alpha de la future Fedora 24.

Malgré les risques concernant la stabilité dune version Alpha, il est important de la tester ! En rapportant les bogues maintenant, vous découvrirez les nouveautés avant tout le monde, tout en améliorant la qualité de Fedora 24 et réduisez du même coup le risque de retard. Les versions en développements manquent de testeurs et de retours pour mener à bien leurs buts.

Notons que Wayland ne sera pas activé par défaut, mais Fedora 24 ambitionne dêtre complètement fonctionnelle avec celui-ci. Ce changement majeur viendra par défaut avec Fedora 25. Un effort immense a été fait pour gommer les différences fonctionnelles avec la session X.org, mais cela s'est avéré insuffisant. Cependant l'expérience utilisateur n'a jamais été aussi respectée qu'avec ces améliorations, si vous souhaitez donner un coup de main, n'hésitez pas à lancer Gnome avec Wayland ce qui est proposé en option dans votre gestionnaire de session (GDM pour Fedora Workstation).

Voici les nouveautés annoncées pour cette version :

Bureautique

  • Mise à jour de Gnome en version 3.20 : amélioration de la session Wayland, édition de cartes et affichage des itinéraires en lien avec OpenStreetMap via le programme Cartes, affichage graphique de l'ensemble des raccourcis claviers, nouvel agencement de la liste des impressions, éditions des images dans Photos, nouvelle interface de recherche dans Fichiers, intégration de LibreOffice dans Documents, refonte de l'utilitaire dconf, etc. ;
  • Fedora peut être mis à niveau entièrement via Gnome Logiciels ;
  • Mise en avant et refonte graphique de LiveUSBTools pour créer les images installables par clés USB de Fedora sur Windows, Linux et Mac OS X afin de simplifier l'installation de Fedora en utilisant un médium plus populaire que le CD ;
  • NetworkManager progresse à la version 1.2 : nouvelle API pour les VPN, gestion de plusieurs VPN, gestion des connexions des conteneurs Docker ou LXC, interface textuelle plus lisible avec plus de couleurs et utilisation d'une nouvelle bibliothèque graphique ;
  • L'environnement de bureau de l'ordinateur OLPC profite de la version 0.108 de Sugar ;
  • Mise en place de QGnomePlatform : un utilitaire pour intégrer visuellement le thème des applications écrites avec Qt dans l'environnement Gnome, et ce sans les modifier ;
  • Création d'un nouveau Spin de Fedora, dédié à l'astronomie, comprenant entre autre un environnement KDE avec KStar, Stellarium et Celestia ;
  • L'outil de manipulation de photos brutes Darktable évolue en version 2.0, qui s'intègre mieux dans Gnome via GTK+ 3, ajoute la gestion des écrans à très haute résolution, possède une meilleure gestion des couleurs et des impressions, prend en charge de nouveaux modèles d'appareils photos, et arrête la distribution de la version 32 bits.

Internationalisation

  • Ajout de méta paquets RPM et utilisation d'un nouveau champ du format RPM pour installer automatiquement les paquets de traduction des logiciels sur votre machine. Il doit remplacer à terme le greffon dnf-langpack qui effectuait cette tâche imparfaitement ;
  • Séparation des paquets de Glibc contenant les langues : un paquet par langue, pour un système plus léger (particulièrement utile pour les versions Server et Cloud);
  • Mise à jour du composant ibus-fbterm de la suite IBus à la version 1.5 afin de profiter d'IBus dans les environnements purement textuels ;

Administration système

  • Fusion des utilitaires ping et ping6 autour d'un même utilitaire (ping) gérant les deux types d'adresses IP ;
  • Séparation dans le paquet systemd, la gestion des conteneurs via systemd se faisant au travers de systems-containers, et la gestion du matériel via le paquet systemd-udev ;
  • systemd ne relance les services qu'une fois ou deux lors d'une transaction RPM complète sur l'ensemble des paquets concernés et non pour chaque paquet concerné en cours de traitement ;
  • Ajout dans anaconda d'une API DBus autour des volumes logiques LVM ;
  • livemedia-creator remplace livecd-creator qui sera plus générique (images pour périphériques ARM, LiveUSB, démarrage par PXE) et plus moderne avec une base en Python 3 au lieu de la version 2 ;
  • Kerberos prend en compte les règles génériques du système pour la conception des mots de passe ;
  • Pour le calcul des adresses IP, ipcalctool sera bientôt supprimé au profit d'ipcalc à cause de la redondance et du manque de support d'IPv6 ;
  • Distribution du logiciel sen, un utilitaire textuel pour gérer et surveiller les images Docker ;

Cloud

  • Ajout du très attendu OpenShift Origin dans Fedora pour le développement et le déploiement des services cloud ;
  • Ajout d'une entrée pour développeurs dans l'image de démarrage d'Atomic pour permettre de démarrer sans instancier un cloud ;
  • Les utilisateurs peuvent recevoir, pour plus de visibilité, la liste des mises à jour disponibles après leur connexion via les "messages du jour" ;
  • Refonte des paquets autour du langage Python, tout ce qui est requis du langage par les programmes system-* importants ont été mis dans des paquets system-python afin d'éviter d'utiliser le paquet python en entier ;
  • Les images Atomic peuvent bénéficier des espaces de stockages via glusterfs ou Ceph ;

Projet Fedora

  • Koji peut générer des dépôts avec des paquets RPM signés, permettant d'unifier nombre de procédures et d'outils en son sein ;
  • Mise à disposition d'images officielles de Fedora à base de couches d'images Docker : cela permettra à terme de faciliter le déploiement d'applications via un conteneur Docker par Fedora elle même ;
  • Réécriture de pungi, qui sert à réaliser les images de Fedora, avec une amélioration des performances permettant de réaliser des images plus souvent, avec les logs publics et de manière plus distribuée ;
  • Ajout du programme web Product Definition Center : remplace l'ensemble des scripts chaotiques (Python, Shell ou Perl) qui servaient à définir et générer les différentes images officielles du projet. La nouvelle architecture pour réaliser cela sera du type MVC, et ce programme correspond à la partie Model de la procédure ;

Développement

  • L'agrégat de compilateurs GCC passe à la version 6 ;
  • Le langage Python se mue à la version 3.5 ;
  • Remplacement du projet Subs, un client pour services web SOAP en Python, par le fork initié par Jurko Gospodnetić pour faute de maintenance et le non support de Python 3 ;
  • Le langage de Google, Go, évolue à la version 1.6 ;
  • Le langage Ruby quant à lui fonce en version 2.3 ;
  • Le langage Erlang bénéficie de sa dernière version 18 ;
  • Un coup de fouet a été donné pour la distribution LaTeX TeXLive vers la version 2015 ;
  • La célèbre bibliothèque C++ Boost, a été boostée vers la version 1.60 ;
  • La bibliothèque standard du langage C GLibc se contente de la version 2.23 ;
  • Suppression dans GLibc de librtkaio qui ajoutait l'API POSIX concernant le temps réel notamment pour les entrées/sorties asynchrones, qui était trop peu utilisée ;
  • Abandon de la dépendance des modules PHP PECL avec le paquet php-pear, projet qui devient obsolète ;
  • Les amateurs de la bibliothèque de Qt profiteront du remplacement de QtWebKit par QtWebEngine, qui est enfin disponible dans les dépôts ;
  • La plateforme de serveurs JavaScript, Node.js, découvre la véritable réponse 4.2 ;
  • Mise à jour de la plateforme de développement .NET Mono 4.2 ;
  • Ajout et activation du ramasse miette Shenandoah 1.0 à OpenJDK qui met en pause moins longtemps le programme pour nettoyer la mémoire de ce dernier ;
  • Fedora ajoute la prise en charge des environnements de développement pour le composant BBC Micro Bit, dédié à l'apprentissage de l'informatique au Royaume-Uni ;

Si l'aventure vous intéresse, les images sont disponibles par Torrent. En cas de bogue, n'oubliez pas de relire la documentation pour signaler les anomalies sur le BugZilla ou de contribuer à la traduction sur Zanata.

Bons tests à tous !

phpMyAdmin version 4.6

Remi Collet

Les RPM pour installer la nouvelle version majeure de phpMyAdmin sont disponibles dans le dépôt remi pour Fedora et remi-test pour Enterprise Linux (RHEL, CentOS...).

 

Site officiel : http://www.phpmyadmin.net/

Annonce de la version : phpMyAdmin 4.6.0 Release Notes

Je ne sais pas encore si cette nouvelle version majeure sera rapidement disponible dans les mises à jour officielles de Fedora (actuellement en 4.5.x), mais la version 4.0.x devrait rester dans EPEL-6 (pré-requis sur MySQL 5.5) et la version 4.4.x dans EPEL-7 (pré-requis sur PHP 5.4). Donc elle est déjà disponible pour fedora 20 à 24 dans le dépôt remi et pour enterprise linux 5 à 7 dans le dépôt remi-test.

Comme toujours, pour Fedora :

dnf --enablerepo=remi install phpMyAdmin

Ou pour Enterprise Linux

yum --enablerepo=remi-test,remi-php56 install phpMyAdmin

Je vous laisse découvrir cette nouvelle version qui intègre beaucoup de nouveautés, et remonter vos impressions.

emblem-important-4-24.png Attention, pour l'instant je laisse cette version dans remi-test car le dépôt remi contient uniquement PHP 5.4, mais comme il est désormais non maintenu, je pense rapidement mettre les nouvelles versions d'applications nécessitant PHP 5.5 (ou supérieur) dans le dépôt remi, notament pour encourager la migration vers PHP 5.5 ou 5.6.

100 000 000 de téléchargements

Remi Collet

Alors que le dépôt remi aura bientôt 11 ans, nous venons de dépasser la barre des 100 millions de RPM téléchargés :)

Évidement, ce chiffre n'est qu'un indicateur, il ne tient pas compte des premières années, des utilisateurs qui aspirent le dépôt complet ni des miroirs privés, mais il me permet tout de même d'observer le succès croissant de mon travail, ainsi que de mesurer la popularité des différents paquets disponibles.

Si les dons reçus me permettent de financer l'hébergement, ils sont surtout une preuve de l'utilité de mon travail et de la reconnaissance des utilisateurs. Lorsqu'ils cesseront, je saurais que je peu fermer le site.

D'autres dépôts tentent de suivre, récupérant mon travail ici ou dans fedora. Ils seront toujours derrière.

Un petit regret : PHP 5.4 représente encore 34% des téléchargements, c'est trop (PHP 5.5 20%, PHP 5.6 40% et PHP 7.0 7%) mais la tendance est bonne, juste un peu lente à mon goût.

Une satisfaction : les Software Collections représente environ 20% ce qui prouve que c'est un bon outil, répondant à un vrai besoin d'installation en parallèle.

PHP version 5.6.20RC1 et 7.0.5RC1

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.20RC1 en SCL sont disponibles dans le dépôt remi-test pour Fedora20 et Enterprise Linux6.

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

La branche PHP 5.5 étant en mode "maintenance de sécurité"; il n'y a plus de RC.

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

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

A noter : la version 5.6.20RC1 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)

Paquets standards (php)

Ajout de la version Fedora 24 et ARM de mesa-git

Sylvain Réault

Les paquets pour la version Fedora 24, ainsi que les paquets pour l'architecture ARM est en route.
N'ayant pas d'appareil pour tester, je ne peux confirmer le fonctionnement sur cette architecture.

Une fois fait, je m'attaque au retour de la signature des paquets, ainsi que du dépôt.

Reprise des paquets pour Rawhide

Sylvain Réault

Suite à un souci avec les changements de la prochaine version de Fedora, il a fallut faire des modifications pour pouvoir empaqueter les paquets pour celle-ci.
Comme ces changements ne conviennent pas à la Fedora 23, j'ai modifié mon script et les spec, en deux version différentes, en générant deux paquets sources différent.

Une version intermédiaire apparaitra dans la journée le temps de tester si tout vas bien.

D'ici la fin de la semaine devrait apparaitre le dépôt propre à Fedora 24 (version Alpha si je ne me trompe pas) en plus de F23 et Rawhide.

En ce qui concerne le site, j'avance lentement étant occupé sur d'autres projets (3D, Travail, autres...), notamment le fond d'écran pour Fedora. Il devrait y avoir une mise à jour rapide pour corriger les bogues de celui ci.
Cela devrait être fait dans la semaine.

Métrologie avec Carbon-Graphite - Partie 1 - Les concepts

Edouard Bourguignon

Présentation conceptuelle de la métrologie avec la pile "Carbon-Graphite".

Présentation

La métrologie est une des briques fondamentales de la supervision. Pour superviser au mieux, voir venir les problèmes, ou aider les diagnostics, il est toujours bon de s'appuyer sur un maximum de métriques. Les métriques étant juste des valeurs représentant l'état de santé d'un élément précis (CPU, disques, débits réseaux etc), archivées sur une durée plus ou moins longue.

Il y a les outils ancestraux comme MRTG, RRD qui s'occupent déjà très bien de cette partie, et répondent bien à la nécessité d'avoir le plus de surveillance possible. Mais ils manquent tous de souplesse.

La pile logiciel « carbon-graphite » en permettant le stockage d'un ensemble le plus exhaustif possible de métriques, répond elle aussi très bien à ce besoin. Cependant elle offre bien plus, en permettant aussi l'exploitation de toutes ces métriques, une facilité de mise en oeuvre, et une souplesse d'exploitation très intéressante, idéale pour les environnements assez mouvants comme la virtualisation (ou cloud pour les marketeux). Tout cela avec une approche très KISS que j'adore.

kiss.jpg

Afin de pouvoir répondre à ces exigences, il a fallu définir :

  • un protocole le plus simple et le plus leger possible
  • le même concept pour le stockage des métriques
  • un outil efficace de manipulation des données (graphes, fonctions mathématiques, etc)

C'est ce que tente d'apporter l'ensemble « carbon-graphite ».

Le protocole d'envoi des métriques (carbon)

Le démon carbon qui collecte les métriques écoute par défaut sur le port 2003, en UDP. Mais il est possible de passer par TCP si besoin. Mais ça, c'est pas très important.

Le plus important c'est que le protocole pour remonter les métriques à carbon est des plus simples (Yeah KISS !). Il s'agit d'un protocole ASCII PLAIN TEXT, et ça, ça change tout ! Il est donc facilement lisible et utilisable (via netcat par ex, curl ou autres). La "trame" doit juste suivre ce formalisme :

nom.de.votre.metrique valeur [date]

Exemple plus parlant (le CPU 0 de mon serveur 01 est idle à 99%):

serveur01.cpu.0.idle 99

La date si elle est omise sera celle de la réception de la métrique. Sinon il suffit de la préciser au format timestamp unix. Facile ?

Ainsi il est très envisageable de développer une sonde en 1 ligne de shell :

echo "serveur01.cpu.0.idle 99" | nc -u serveur-carbon 2003

C'est tout. Vous venez au passage de coder votre première sonde pour Carbon ! Est-il techniquement possible de faire plus simple ??

Le stockage des métriques (whisper)

Il faut ensuite pouvoir facilement stocker ces métriques (KISS once again !). Sans avoir non plus de configuration ou autres gestes à faire pour ajouter de nouvelles métriques. C'est là aussi toute la souplesse de cette solution. Il est possible d'y voir une sorte de "métrologie à la demande".

Attention, si vous trouvez que j'utilise trop souvent le mot métrique, c'est normal, je suis payé à chacune de ses occurrences... (ahah si seulement...)

La partie "backend" qui s'occupe de stocker les métriques sur disque s'appelle "whisper".

Pour se faire, la métrique est passée à whisper qui va la découper de manière hiérarchique. C'est plus simple que ça en a l'air, en gros il va remplacer les "." par des "/" et voilà! Ainsi nous retrouverons le nom de notre métrique dans larborescence des fichiers générés par whisper et qui stockent nos données.

Imaginons que le répertoire racine de notre base whisper soit /var/lib/carbon/whisper, notre métrique de notre exemple précédent sera stockée dans /var/lib/carbon/whisper/server01/cpu/0/idle.wsp. Pour l'exploitation vu que l'arborescence des fichiers représente la structure de nos données, c'est simple à manipuler.

Ensuite concrètement, dans ce fichier wsp, il s'agit d'une structure de type Round Robin. Pour des raisons de performance, la structure complète du fichier est crée à la première réception de la métrique. La taille est donc fixe. La structure est très rigide et imposée, pour des questions de performances. De toute façon, les données sont toujours du même type (un nom, une valeur, une date). Si vous avez un besoin particulier de stocker autres choses en plus (tags etc), il faudra se pencher sur InfluxDB (entres autres).

A fonction du nombre de métriques que vous recevrez à l'instant T, il faut que votre disque puisse encaisser (en débit et en IO/s). Sinon les métriques ne pouvant être écrites à temps seront stockées en cache par carbon, et au bout d'un moment ça finira par déborder. Et c'est pas jolie.

Chaque métrique, peut se voir associer une granularité et une rétention. Il faudra donc commencer par se poser la question "Qu'est-ce que je souhaite stocker?" mais surtout "avec quelle précision, et sur quelle durée". Ces questions permettront aussi d'estimer la volumétrie nécessaire. (et non 42 n'est pas une réponse)

Finesse des mesures et période de rétention

Toujours en suivant notre exemple, imaginons que nous souhaitons garder les métriques récentes de manière assez précise, puis plus on s'éloignera dans le temps, moins nous aurons besoin de cette finesse. En général c'est assez vrai, il est rare d'avoir à se pencher sur des métriques très précises 5 ans après un problème etc. Ceci dit, si c'est votre besoin, c'est tout aussi possible.

Cette partie dans le vocabulaire "carbon/graphite" s'appelle la gestion des schémas de stockage.

Pour notre exemple, disons donc, 1 métrique toutes les 10 secondes, sur 1 mois, puis nous passerons à 1 métrique toutes les minutes sur 3 mois, puis 1 métrique toute les 5 minutes sur 1 an (noté 10s:1m,60s:90d:5m:1y dans la configuration whisper). Il est possible de continuer longtemps comme ça. Ce mécanisme de rétention est configuré dans /etc/carbon/storage-schemas.conf. Baisser la granularité au fil de temps permet aussi de réduire la taille des bases en faisant des concessions sur la granularité. Ce qui nous amène à une nouvelle question, comment estimer la taille de nos métriques ?

Cette configuration très souple de la granularité s'applique sur des expressions régulières visant le nom de la métrique. Ceci permet de configurer simplement des rétentions et granularités différentes en fonction du nom de la métrique. Encore une fois, cette configuration se fait dans le fichier /etc/carbon/storage-schemas.conf, qui est vérifié toutes les 60 secondes par carbon. Attention l'ordre dans ce fichier est important, la première correspondance trouvée est appliquée.

A chaque changement de granularité, il y a une opération de consolidation (ou agrégation), configurable, que nous verrons plus bas.

Estimation de la taille des métriques

Il faut être honnête, nous nous sommes pas trop griller les neurones jusqu'à présent. J'ai donc voulu pimenter cet article avec un peu de mathématique. Si vous êtes allergique aux maths, l'approche empirique de tester le stockage de métrique pour une machine "témoin", et de multiplier ça par le nombre de machines en cible fonctionne très bien. Mais vous pouvez quand même faire semblant et lire l'explication suivante...

dog_computer.jpg

Pour estimer la volumétrie, il faut savoir qu'un point de métrique pèse 12 octets (c'est loin d'être lourd, pas très heavy metal mais KISS tout de même !). Reprenons notre exemple de rétention (10s:1m,60s:90d:5m:1y) :

  • Pour les métriques à 10s sur 30 jours :
    • Nombre de secondes dans 1 mois : 30 jours * 24 heures * 60 minutes * 60 secondes = 2592000
    • 1 seul métrique par tranche de 10 seconde : 2592000 / 10 = 259200 points
  • Pour les métriques à 60s sur 90 jours :
    • Nombre de minutes dans 90 jours : 90 jours * 24 heures * 60 minutes = 129600 points
  • Pour les métriques à 5 minutes sur 1 an :
    • Nombre de minutes sur 1 an : 365 jours * 24 heures * 60 minutes = 525600
    • 1 métrique par tranche de 5 minutes : 525600 / 5 = 105120 points

Donc au total, 1 métrique vu nos rétentions aura au maximum 259 200 + 129 600 + 105 120 = 493 920 points. La taille approximative du fichier wsp correspondant sera donc de 5 Mo (493 920 * 12 octets). Il faut prévoir une petite entête dans chaque fichier.

Si vous avez 20 serveurs, avec 100 métriques chaques, on arrive vite à de beaux volumes : 20 * 100 * 5 Mo = 10 Gio. En divisant par 2 nos prétentions sur les granularités (10s:1m,60s:90d:5m:1y => 20s:1m,120s:90d,10m:1y), ce qui n'est pas non plus dramatique, nous divisons par 2 la volumétrie nécessaire (donc 5Gio).

Voilà pour une idée sur comment estimer la volumétrie nécessaire. Et comme par défaut les fichiers whisper sont à taille fixe, tant que vous n'ajoutez pas de nouvelles métriques, l'espace utilisé n'évoluera pas.

Agrégation lors d'un changement de granularité

Que fait carbon quand il reçoit une métrique ? Il cherche déjà à savoir quelle granularité lui appliquer, grâce à la configuration faite dans /etc/carbon/storage-schemas.conf. La métrique passe dans la partie whisper pour être enregistrée sur disque, et les différentes finesses vont être calculées.

Quand une métrique bascule d'un niveau de granularité à un autre, il y a consolidation (ou agrégation, aggregation en anglais, je suis bilingue). C'est à dire qu'il faut appliquer une méthode pour changer la granularité. Par défaut, il s'agit de faire une moyenne pour lisser la perte de finesse. Mais ceci est configurable, cette fois dans /etc/carbon/storage-aggregation.conf. Il faut aussi disposer d'assez de valeurs dans la finesse précédente sur les périodes qui se chevauchent. Ceci est configurable via le paramètre xFilesFactor (par défaut à 0.5 ce qui signife qu'il faut 50% des points). 

Ne vous inquiétez pas, les valeurs par défaut couvrent 90% des usages. Ce qu'il faut retenir:

  • A chaque changement de rétention, carbon/whisper fait des calculs (=coût CPU)
  • Pour ces calculs il faut disposer d'assez de points (évitez donc d'avoir des plages de rétentions inutilisées)
  • Pour eviter de drôle de résultats, il vaut mieux que les périodes soit des multiples entre elles (passer d'une métrique toutes les 10s à 1 par minutes c'est ok car on consolide les 6 dernières métriques, mais ko si 1 par 10s puis 1 par 55s, car comment consolider 5,5 dernières métriques??)

La visualisation des données (graphite)

Sans parler de cette partie, nous avons déjà un outils plutôt puissant, et assez simple à mettre en oeuvre et à comprendre. J'ajouterais en plus que le code est en python, donc facile à lire, et très réduit. Mais la pile carbon-graphite ne serait pas complète sans la partie visualisation des données, la partie "graphite" (graphique quoi).

Ce qui est assez intéressant avec le moteur graphite, c'est qu'il fournit en fait un moteur, interrogeable en HTTP, qui peut restituer les données brutes dans plein de formats (json, csv, etc), mais aussi des graphiques (en SVG, JPG etc), tout en ayant une bibliothèque assez large de fonctions mathématiques pour manipuler les données. A noter qu'avant, avec les outils ancestraux, il fallait trop souvent penser dès le début s'il fallait stocker des résultats mathématiques (moyenne, min/max etc). Ici au final, nous avons les métriques brutes, il est du coup possible de les manipuler comme il nous plait après coup. Bien plus simple.

Nous avons donc rien de particulier à faire si nous voulons avoir une moyenne, glissante ou pas, une valeur de percentile, un top 10, des déviants, et même des prédictions de tendance. Facilement utilisable via l'interface web proposée, ou en développant soi-même quelques petits scripts en javascripts (vu que ça cause JSON).
L'interface web proposée est pas si mal, avec peu être un look un peu old-school. Mais elle met facilement à disposition toutes les fonctions possibles et la navigation dans l'ensemble des métriques est simple. Il est même possible de définir des dashboards etc. Mais pour ce type d'usage plus évolué, nous verrons plutôt l'outil Grafana (qui était d'ailleurs à la base que du javascript devant le moteur graphite).

Conclusion

Au final cette solution de métrologie est très satisfaisante, facile à mettre en oeuvre (je ferais sûrement des billets la dessus), et tient la charge à condition d'avoir bien penser son architecture et surtout ses capacités de stockage.
A completer avec une centralisation des logs ELK (que j'ai déjà abordé ici mais c'est vieux) et c'est tout bon.

Dotclear 2.9

Remi Collet

Ça y est ! La dernière version de Dotclear est installée.

Migration en douceur, aucun problème. Comme d'habitude, j'ai simplement appliqué le patch. Non, je n'utilise pas la fonction intégrée de MAJ qui nécessite des réglages à l'encontre des règles de sécurité.

Mon thème fonctionne parfaitement.

P.S. comme pour chaque version majeure, j'ai aussi pris soin de copier toutes les images depuis l'archive officielle.

Mémento :

$ tar czf save/blog-20160305.tgz blog
$ mysqldump -uroot -pxxx blog | gzip >save/remi-20160305.sql.gz
$ cd download
$ wget http://download.dotclear.org/patches/2.8.2-2.9.diff.gz
$ wget http://download.dotclear.org/latest/dotclear-2.9.tar.gz
$ cd ../blog
$ gzip -dc ../download/2.8.2-2.9.diff.gz | patch -p1
$ cd ..
$ tar xf download/dotclear-2.9.tar.gz
$ for i in $(find dotclear/ -name \*png); do cp $i ${i/dotclear/blog}; done

PHP version 5.5.33, 5.6.19 et 7.0.4

Remi Collet

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

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

Les RPM de PHP version 5.5.33 sont disponibles dans le dépôt remi pour Fedora 20 et dans le dépôt remi-php55 pour Enterprise Linux.

emblem-important-2-24.pngPHP version 5.4 a atteint sa fin de vie et n'est plus maintenu par le projet. Compte tenu du nombre important de téléchargements par les utilisateurs de mon dépôt la version présente dans le dépôt remi pour Enterprise Linux (RHEL, CentOS...) a été conservée avec les correctifs de sécurité (de la version 5.5.33). La mise à jour vers une version maintenue est fortement conseillée.

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-important-2-24.png La version 5.5.27 était la dernière mise à jour corrigeant des bugs. La branche 5.5 est donc en maintenance de sécurité uniquement (jusqu'en Juillet 2016).

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

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

yum-config-manager --enable remi-php55
yum update

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

yum --enablerepo=remi install php55

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.7
  • beaucoup de nouvelles extensions sont aussi disponible, voir PECL extension RPM status page

emblem-notice-24.pngInformations, lire :

Paquets de base (php)

Software Collections (php55 / php56 / php70)

PHP version 5.6.19RC1 et 7.0.4RC1

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.19RC1 en SCL sont disponibles dans le dépôt remi-test pour Fedora20 et Enterprise Linux6.

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

La branche PHP 5.5 étant en mode "maintenance de sécurité"; il n'y a plus de RC.

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

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

A noter : la version 5.6.19RC1 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)

Paquets standards (php)

Reprise des créations graphique

Sylvain Réault

Et bien je me remet sur mes créations graphique.

Pour commencer voici la version 2016 de la F1 pour Fedora.

J'espère qu'elle vous plaira, elle évoluera rapidement, car elle stagne depuis bien trop longtemps.

Installer PHP 7 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.0.

 

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 23

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

RHEL version 7.2

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

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

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

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

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

Fedora

dnf config-manager --enable remi-php70

 

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.0.3 (cli) (built: Feb  3 2016 10:09:48) ( NTS )
Copyright (c) 1997-2016 The PHP Group
Zend Engine v3.0.0, Copyright (c) 1998-2016 Zend Technologies
    with Xdebug v2.4.0RC4, Copyright (c) 2002-2016, by Derick Rethans

 

Problèmes connus

La mise à jour peut échouer 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 php70. Voir le billet PHP 7.0 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 25 (la proposition de changement n'a pas encore était enregistrée).

En fournissant une pile complète, environ 150 extensions disponibles, 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...).

PHPUnit 5.2

Remi Collet

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

Documentation : PHPUnit 5.2 manual et Release Announcement for PHPUnit 5.2.0 (english)

emblem-notice-24.pngCette nouvelle version nécessite PHP ≥ 5.6.

Installation, Fedora :

dnf --enablerepo=remi install phpunit

Installation, Enterprise Linux :

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

Remarque: cet outil est un epièce essentielle de la QA PHP dans Fedora.

PHP version 5.5.32, 5.6.18 et 7.0.3

Remi Collet

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

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

Les RPM de PHP version 5.5.32 sont disponibles dans le dépôt remi pour Fedora 20 et dans le dépôt remi-php55 pour Enterprise Linux.

emblem-important-2-24.pngPHP version 5.4 a atteint sa fin de vie et n'est plus maintenu par le projet. Compte tenu du nombre important de téléchargements par les utilisateurs de mon dépôt la version présente dans le dépôt remi pour Enterprise Linux (RHEL, CentOS...) a été conservée avec les correctifs de sécurité (de la version 5.5.31). La mise à jour vers une version maintenue est fortement conseillée (Une version intégrant les correctifs de la version 5.5.32 devrait bientôt être disponible)

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-important-2-24.png La version 5.5.27 était la dernière mise à jour corrigeant des bugs. La branche 5.5 est donc en maintenance de sécurité uniquement (jusqu'en Juillet 2016).

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

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

yum-config-manager --enable remi-php55
yum update

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

yum --enablerepo=remi install php55

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.7
  • beaucoup de nouvelles extensions sont aussi disponible, voir PECL extension RPM status page

emblem-notice-24.pngInformations, lire :

Paquets de base (php)

Software Collections (php55 / php56 / php70)

Configuration d'une VM avec OpenVswitch avec VLAN

Edouard Bourguignon

Ce billet aborde la configuration des VLANs pour une VM reliée à un OpenVswitch.

Configuration avec VLAN

Quand plusieurs projets se retrouvent virtualisés sur le même hyperviseur, pour ajouter plus de sécurité en isolant les réseaux, bref faire comme c'est fait en "physique" habituellement, il faut passer par des VLAN. Cela permet de découper un switch en plusieurs réseaux isolés, pour ceux qui ne connaîtraient pas cette norme. Donc en gros avec les VLAN, il est possible de faire des réseaux virtuels sur notre switch virtuel br0. Chacun de ces réseaux dits virtuels aura un identifiant (de 1 à 4095). C'est ce numéro qui est souvent appelé VLAN par abus de langage. Du moment que 2 interfaces réseaux se trouvent sur le même VLAN elles pourront communiquer. Simple non?

Configuration manuelle

La première possibilité qui vient à l'esprit est d'ajouter manuellement le VLAN après que la VM soit lancée. Avec l'exemple de configuration cité plus haut, la carte réseau de la VM sera automatiquement branchée sur notre br0 OpenVswitch. La partie visible sur l'hyperviseur de cette carte réseau "virtuelle" est un périphérique de type tap. Le nom de ce tap est configurable dans la libvirt ainsi que dans le fichier XML de la VM. Par défaut il sera préfixé vnet et suffixé par un identifiant numérique. Admettons que notre VM soit la seule de l'hyperviseur, logiquement il y aura donc un tap "vnet0" (vu comme port et interface) dans notre br0. Voyons voir:

[root@hyperviseur01 ~]# ovs-vsctl show
c5f92e84-adaa-4b87-beac-c7f6c8129a7c
    Bridge "br0"
        Port "vnet0"
            Interface "vnet0"
        Port "br0"
            Interface "br0"
                type: internal
    ovs_version: "2.4.0"
Il y est donc maintenant possible d'associer un numéro de VLAN à ce port "vnet0", par ex le VLAN 99:
[root@hyperviseur01 ~]# ovs-vsctl set port vnet0 tag=99
[root@hyperviseur01 ~]# ovs-vsctl show
c5f92e84-adaa-4b87-beac-c7f6c8129a7c
    Bridge "br0"
        Port "vnet0"
            tag: 99
            Interface "vnet0"
        Port "br0"
            Interface "br0"
                type: internal
    ovs_version: "2.4.0"
Ensuite si nous démarrons une 2e VM, et qu'on associe son vnet1 au VLAN 99 par la même méthode, si la configuration IP dans ces VMs est correcte (même réseau IP), elles pourrons communiquer !

Configuration via la libvirt

La méthode manuelle fonctionne mais il y a encore mieux, en indiquant la configuration VLAN dans le fichier XML de la VM. Pour cela il suffit d'ajouter le bloc suivant dans le bloc de notre interface réseau virtuelle:
<vlan>
<tag id='99'/>
</vlan>

Il est aussi possible de définir plusieurs VLAN en utilisant la balise trunk et non tag. Mais il faudra du coup "tagguer" vos interfaces dans l'OS de la VM. Classique quand il faut utiliser plusieurs VLAN. Mais quand un seul VLAN est utilisé, un seul tag, il s'agit d'un "access port", et il n'y a rien à faire de particuler dans l'OS de la VM.

Je décrirais peut être plus tard dans un autre billet une méthode plus répandue mais que je trouve plus contraignante qui passe toujours par la libvirt mais via la configuration d'un réseau/switch virtuel (notre br0) dans lequel il est possible de définir des portgroups. C'est au niveau des portgroups du switch qu'il faut définir les VLANs. Ensuite dans la configuration de la VM il faut la relier à ces portgroups. C'est moins direct vu qu'il faut modifier deux fichiers de configuration, mais ça rajoute une couche d'abstraction qui dans certains cas peut être utile.

En attendant, voici le bloc complet de configuration de l'interface réseau de ma VM:

<interface type='bridge'>
<mac address='52:54:00:06:7e:aa'/>
<source bridge='br0'/>
<vlan>
<tag id='99'/>
</vlan>
<virtualport type='openvswitch'/>
<model type='virtio'/>
</interface>

Et voici l 'état de mon br0 après avoir démarrer 2 VMs:

[root@hyperviseur01 ~]# ovs-vsctl show
c5f92e84-adaa-4b87-beac-c7f6c8129a7c
Bridge "br0"
Port "vnet0"
tag: 99
Interface "vnet0"
Port "br0"
Interface "br0"
type: internal
Port "vnet1"
tag: 99
Interface "vnet1"
ovs_version: "2.4.0"

Voilà, les 2 VMs étant sur le VLAN 99 elles communiquent bien ensemble.

PHP version 5.6.18RC1 et 7.0.3RC1

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.18RC1 en SCL sont disponibles dans le dépôt remi-test pour Fedora20 et Enterprise Linux6.

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

La branche PHP 5.5 étant en mode "maintenance de sécurité"; il n'y a plus de RC.

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

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

A noter : la version 5.6.18RC1 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)

Paquets standards (php)

Page générée le 05 déc 2016 à 19:40