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.

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)

Bonne anneé

Sylvain Réault

Et bien bonne année à toutes et à tous.

Une nouvelle version de Mesa est en route, elle devrait être disponible dans l'après midi.

Elle a prit du temps pour cause de problème d'empaquetage et surtout car j'ai pris quelques jours de vacances.

Je reprend le rythme d'un empaquetage par semaine, sauf si il y avait de gros changement.

Pour information! le site vas enfin connaitre de gros changement pour mieux correspondre aux attentes que j'ai. J'espère que cela vous plaira autant qu'à moi.

Chassons l'hiver pour l'AG

Fedora Paris

Comme vous le savez peut-être, l'assemblé générale de Borsalinux-Fr aura lieu samedi le 23 janvier à la FPH à 14h (en fait, on commence avec une assemblé générale extraordinaire). Certains d'entre nous arriveront vers midi et nous avons prévu de déjeuner au Cuba Compagnie Café (à deux minutes de la FPH à pied). On vous invite donc à nous y... Lire Chassons l'hiver pour l'AG

Assemblée Générale Extraordinaire et Ordinaire le 23 janvier à Paris

Association Borsalinux-Fr

L'Assemblée Générale Extraordinaire et Ordinaire de l'association a lieu à partir de 14h à la

Fondation du Progrès de l'Homme au 2e étage à l'adresse 38 Rue Saint-Sabin, 75011 Paris.

L'ordre du jour de l'AGE est le suivant :

1 - Vote des différentes propositions de modification de statuts, dont celle pour changement du siège social à Paris.

Puis elle sera suivie de l'AG avec l'ordre du jour est le suivant:

1- Présentation du le bilan moral de l'activité de l'association par le Conseil d'Administration;

2- Présentation du bilan financier de l'activité de l'Association par le Conseil d'Administration et du budget 2016.

3- Présentation des événements et des actions pour l'année 2016.

À qui envoyer sa procuration ?

Pour les procurations vous pouvez vous baser sur ce modèle. Vous pouvez transmettre vos procurations par courrier postale, ou par courrier électronique à condition que celui-ci soit signé.

Attention, un membre actif ne pourra détenir plus de deux procurations, conformément à notre règlement intérieur.

Ci-dessous est la liste des personnes qui ont confirmé leur venue à cette Assemblée Générale du 23 janvier 2016 et acceptant les procurations :

  • Charles-Antoine Couret (47 chemin de la Valbarelle à Saint-Marcel - Bâtiment les chênes, 13010 Marseille)
  • Emmanuel Seyman (133 rue de Silly, 92100 Boulogne-Billancourt)
  • Nicolas Chauvet

PHP version 5.5.31, 5.6.17 et 7.0.2

Remi Collet

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

Les RPM de PHP version 5.6.17 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.31 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 derniers correctifs de sécurité. 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)

Configuration d'une VM avec OpenVswitch sans VLAN

Edouard Bourguignon

Ce billet présente les premières étapes pour configurer une VM avec la libvirt et le support d'un switch virtuel OpenVswitch.

Dans un précédent billet nous avons vu comment configurer la partie OpenVswitch sur l'hyperviseur. Nous allons voir maintenant comment configurer les VM pour utiliser ce switch virtuel.

Normalement si tout c'est bien passé, sur l'hyperviseur le switch virtuel br0 est configuré:

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

Configuration simple sans VLAN

Le but maintenant est de faire en sorte d'ajouter automatiquement dans ce br0 les interfaces virtuelles de la VM dès son démarrage. Pour cela il faut faire comprendre à la libvirt qui gère notre VM que les interfaces réseaux de cette dernière sont à associer à notre "bridge" OpenVswitch nommé br0. La syntaxe XML pour cela est la suivante :
[...]
<source bridge='br0'/>
 <virtualport type='openvswitch'/>
[...]
Qu'il faudra ajouter dans le bloc des interfaces réseaux via la commande suivante :
virsh edit NOM_VM
Voici ce que donnerait un bloc interface complet :
[...]
<interface type='bridge'>
      <mac address='52:54:00:06:7e:aa'/>
      <source bridge='br0'/>
      <virtualport type='openvswitch'/>
      <model type='virtio'/>
</interface>
[...]
Aujourd'hui, passer par virt-manager ne permet pas de profiter de toutes les possibilités d'OpenVswitch. C'est pourtant prévu, mais en attendant, en fonction des versions de ce dernier, il ne connait même pas l'existence d'OpenVswitch. Du coup, pour faire le lien entre notre VM et notre br0 nous n'avons pas d'autre choix que d'éditer le fichier XML de configuration de la VM à la main. Cela repose sur l'utilisation de la libvirt bien sûr.
Ensuite pour démarrer la VM, il est possible de repasser par les outils habituels, soit virsh encore (virsh start NOM_VM), soit virt-manager par exemple. 
Il est ensuite possible de faire de même pour d'autres VMs, qui si elles ont la même configuration IP pourront communiquer. Bien sûr il ne faudra pas s'attendre à la main simplicité qu'avec un switch linux natif type bridge. Les VMs n'auront par exemple pas accès tel quel à votre réseau physique. Mais avec un prochain billet sur la configuration des VLANs et ce billet précédent sur la configuration basique d'OpenVswitch, tout devrait être possible.

Réunion de la communauté du libre

Fedora Paris

L'April et Parinux ayant décidé de faire un apéro commun le 15 janvier, Fedora Paris a décidé de se joindre à eux. Ce sera l'occasion de se souhaiter la bonne année et de discuter avec nos amis libristes pour voir si on ne peut pas faire quelque chose en commun pour promouvoir le Logiciel Libre en général et Fedora en particulier. Nous nous... Lire Réunion de la communauté du libre

PHP version 7.0.2RC1

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 7.0.2RC1 sont disponibles en SCL dans le dépôt remi-test pour Fedora20 et Enterprise Linux 6 et les paquets de base dans le dépôt remi-php70-test pour 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 7.0 :

yum --enablerepo=remi-test install php70

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

Paquets standards (php)

Bonnes fêtes de fin d'année et nouvelles...

Sylvain Réault

Et bien je vous souhaite de bonnes fêtes de fin d'année.

Il n'y aura pas de nouvelle version des paquets car il manque une mise à jour de la libdrm qui devrait être disponible rapidement je l'espère.

Du coup la nouvelle version sera disponible en début d'année si tout vas bien. N'étant pas fixé sur mon emploi du temps d'ici là, je ne peux pas non plus trop m'avancer.

Sur ceux @ l'année prochaine :).

Page générée le 02 mai 2016 à 15:36