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.

Xnee 3.18

Matthieu Saulnier

Rpm_logo.png

Nouvel épisode de la chronique d'empaqueteur pour le Projet Fedora. Au programme, grosse session packaging qui sera étalée dans plusieurs posts. On commence avec Xnee qui a un ticket bugzilla ouvert. Ce ticket a été ouvert automatiquement par le script de surveillance des nouvelles versions logiciel de Fedora, très pratique pour être instantanément averti de la sortie d'une nouvelle version de Xnee.

Synchronisation du dépôt local

Avec les paquets ayants une faible activité de développement, il arrive fréquemment que le dépôt local sur notre disque ne soit pas synchrone avec le dépôt en ligne. En effet, tous les 6 à 12 mois environ, tous les paquets de la distribution sont reconstruits au cours d'un « mass-rebuild ». Les mass-rebuild sont généralement lancés suite à l'évolution majeure du compilateur ou bien d'une bibliothèque utilisée par de nombreux paquets. Les changements engendrés sur mon paquet ne sont pas énorme, la release est incrémentée et une nouvelle entrée est ajoutée au Changelog dans la branche master (la branche utilisée par Rawhide). Il faut donc veiller avant de commencer à travailler que l'on possède bien la dernière version du dépôt de code source.

casper@blackbird:~/fedora-scm/Xnee$ fedpkg pull
Depuis ssh://pkgs.fedoraproject.org/Xnee
 * [nouvelle branche] f20        -> origin/f20
Already up-to-date.

Récupération du tarball

Commençons par récupérer le nouveau tarball en modifiant le fichier SPEC comme suit :

--- a/Xnee.spec
+++ b/Xnee.spec
@@ -1,8 +1,8 @@
 Summary:       X11 environment recorder
 Summary(fr):   Enregistreur de l'environnement X11
 Name:          Xnee
-Version:       3.16
-Release:       2%{?dist}
+Version:       3.18
+Release:       1%{?dist}
 
 License:       GPLv3+
 URL:           http://www.gnu.org/software/xnee/
@@ -139,6 +139,9 @@ make test
 
 
 %changelog
+* Mon Apr 28 2014 Matthieu Saulnier <fantom@xxxxxxxxxxxxxxxxxx> - 3.18-1
+- Update to 3.18
+
 * Sat Aug 03 2013 Fedora Release Engineering <rel-eng@xxxxxxxxxxxxxxxxxx> - 3.16-2
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass_Rebuild

 

Puis on peut télécharger les nouvelles sources avec la commande spectool :

casper@blackbird:~/fedora-scm/Xnee$ spectool -g -S Xnee.spec
Getting http://ftp.gnu.org/gnu/xnee/xnee-3.18.tar.gz to ./xnee-3.18.tar.gz
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 1817k  100 1817k    0     0   378k      0  0:00:04  0:00:04 --:--:--  378k

J'ai toujours l'habitude d'en avoir une copie dans ~/Téléchargements/ afin de pouvoir l'extraire et l'étudier plus en détail.

Étude de la nouvelle version

Souvenez-vous que le paquet passe directement de la version 3.16 à 3.18, on va sauter la 3.17. Du coup il va sûrement y avoir pas mal de changement au niveau du programme. Pour nous aider à nous y retrouver, le développeur renseigne le fichier texte nommé « NEWS », qui est également présent dans le RPM au passage.

Changes in version 3.18 ('Abbado')
==============================

  Removed incorrect comments.

Changes in version 3.17 ('Seeger')
==============================

  * New features:

  * Fixed bugs:

    Savannah:
    Mayhem:    #715746 "cnee crashes with exit status 139"
    Works with X.org 1.14.*


Changes in version 3.16
==============================

  * New features:

    Gnee can record XInput events

  * Fixed bugs:

    Savannah:

On voit ici qu'il s'agit de nouvelles compatibilités avec Xorg, de correction de bugs, et d'amélioration du code (les commentaires c'est important ^^).

Répercutions sur le SPEC

Concrètement, il y en a aucune. Cela ne dispense pas de faire une relecture complète du SPEC, et de remettre en cause tous les "quickfix". Ce serait pertinent de lancer un build hors SCM pour chaque élément à remettre en cause, puis de procéder à divers tests sur les RPMs obtenus et relire les logs de compilation. C'est d'ailleurs cette petite routine de contrôle qualité qui m'a indiqué ce qu'il y avait encore à améliorer, chaque détail compte.

Contrôle qualité

La mise à jour des paquets Fedora ne consiste pas à incrémenter des numéros de version puis lancer la construction, ça serait trop facile. D'autant plus que les vieux paquets comme celui de Xnee (mon premier paquet Fedora) ont la fâcheuse tendance de trainer une couche de résidus, léger certes, mais quand même. Rpmlint est un programme qui automatise un grand nombre de tests, il est très utilisé pendant la revue d'intégration d'un nouveau paquet dans le dépôt Fedora.

$ rpmlint Xnee*3.18* cnee*
Xnee-devel.x86_64: W: spelling-error Summary(fr) nécéssaires -> nécessaires
Xnee-devel.x86_64: W: spelling-error %description -l fr nécéssaires -> nécessaires
Xnee-devel.x86_64: W: spelling-error %description -l fr lib -> lob, lin, li
Xnee-devel.x86_64: W: no-documentation
5 packages and 0 specfiles checked; 0 errors, 4 warnings.

Ces erreurs ont été introduites pendant la mise à jour du * Thu Aug 16 2012 d'après le ChangeLog. Nous allons donc les corriger.

Dernières modifications du SPEC

Dans le SPEC les erreurs sont situées au niveau du sous-paquet Xnee-devel :

diff --git a/Xnee.spec b/Xnee.spec
index 1c9dcb7..51992bb 100644
--- a/Xnee.spec
+++ b/Xnee.spec
@@ -1,8 +1,8 @@
 Summary:       X11 environment recorder
 Summary(fr):   Enregistreur de l'environnement X11
 Name:          Xnee
-Version:       3.16
-Release:       2%{?dist}
+Version:       3.18
+Release:       1%{?dist}
 
 License:       GPLv3+
 URL:           http://www.gnu.org/software/xnee/
@@ -41,7 +41,7 @@ quel client Xnee ou interface.
 
 %package devel
 Summary:       Files needed for building applications with libxnee
-Summary(fr):   Fichiers nécéssaires pour construire des applications avec libxnee
+Summary(fr):   Fichiers nécessaires pour construire des applications avec libxnee
 Requires:      Xnee-libs%{?_isa} = %{version}-%{release}
 
 %description devel
@@ -50,8 +50,8 @@ necessary for developing programs which use the xnee-lib library.
 
 %description devel -l fr
 Le paquet xnee-devel inclue les fichiers d'en-tête et bibliothèques
-nécéssaires au développement des programmes utilisant la bibliothèque
-xnee-lib.
+nécessaires au développement des programmes utilisant la bibliothèque
+libxnee.
 
 
 %package -n cnee
@@ -139,6 +139,10 @@ make test
 
 
 %changelog
+* Mon Apr 28 2014 Matthieu Saulnier <fantom@xxxxxxxxxxxxxxxxxxx> - 3.18-1
+- Update to 3.18
+- Fix spelling-error in summary and description
+
 * Sat Aug 03 2013 Fedora Release Engineering <rel-eng@xxxxxxxxxxxxxxxxxxx> - 3.16-2
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass_Rebuild

 

Enregistrement des modifications

Avant de commiter il faut d'abord uploader le nouveau tarball, sinon on devra faire un nouveau commit juste après l'upload :

casper@blackbird:~/fedora-scm/Xnee$ fedpkg new-sources xnee-3.18.tar.gz
Uploading: 2ffd7832026c871d0fb0f63e06c71519  xnee-3.18.tar.gz
######################################################################## 100,0%
Uploaded and added to .gitignore: xnee-3.18.tar.gz
Source upload succeeded. Don't forget to commit the sources file

C'est même indiqué par la commande « Don't forget to commit the sources file ».

casper@blackbird:~/fedora-scm/Xnee$ fedpkg commit -m "Update to 3.18" -p

C'est commité et pushé en une seule passe, on va donc passer au build.

Construction du paquet pour Rawhide

Comme toujours on travaille dans la branche master du dépôt Git, donc on impacte seulement Rawhide. C'est une sécurité, si jamais mon paquet devait introduire de l'instabilité dans la distribution, les versions stables de Fedora ne seront pas touchées. Bien sûr cela concerne les paquets principaux, mes petits paquets ne sont pas des dépendances d'autres paquets, et par conséquent s'ils ne sont pas stable ils ne menacent en rien la stabilité légendaire de Fedora. Mais ça permet toujours aux testeurs de vérifier et rapporter des bugs avant que le paquet n'arrive dans les branches stables.

casper@blackbird:~/fedora-scm/Xnee$ fedpkg build --nowait
Building Xnee-3.18-1.fc21 for rawhide
Created task: 6792610
Task info: http://koji.fedoraproject.org/koji/taskinfo?taskID=6792610

Il est possible que certains packageurs mettent à jour seulement Rawhide (la future F21) et pas les branches stables (F20, F19), ça m'est arrivé sur certain paquets. C'est autorisé par le réglement des Mises à jour de Fedora pour les updates n'apportant ni correctifs de bug ni correctifs de faille de sécurité. Les deux pratiques sont bonnes et ça dépend vraiment du bon vouloir du packageur en fait...

Mise à jour pour F20

On applique les changements de la branche master à la branche f20 du dépôt Git. Pour cela il faut d'abord changer de branche :

casper@blackbird:~/fedora-scm/Xnee$ fedpkg switch-branch f20
La branche f20 est paramétrée pour suivre la branche distante f20 depuis origin.

Puis on applique les modifications de la branche master :

casper@blackbird:~/fedora-scm/Xnee$ git merge master
Mise à jour 7fe7be6..81328d5
Fast-forward
 .gitignore |  1 +
 Xnee.spec  | 14 +++++++++-----
 sources    |  2 +-
 3 files changed, 11 insertions(+), 6 deletions(-)

Ensuite on synchronise le dépôt en ligne avec la commande :

casper@blackbird:~/fedora-scm/Xnee$ fedpkg push
Total 0 (delta 0), reused 0 (delta 0)
remote: Emitting a message to the fedmsg bus.
To ssh://fantom@pkgs.fedoraproject.org/Xnee
   7fe7be6..81328d5  f20 -> f20

Et enfin on peut demander la construction du paquet à partir du dépôt de code source en ligne :

casper@blackbird:~/fedora-scm/Xnee$ fedpkg build --nowait
Building Xnee-3.18-1.fc20 for f20-candidate
Created task: 6795576
Task info: http://koji.fedoraproject.org/koji/taskinfo?taskID=6795576

Lorsque le paquet sera effectivement construit, il sera taggué comme paquet de mise à jour potentielle pour le dépôt updates-testing. Il ne reste donc plus qu'à le tagguer en tant que mise à jour effective du paquet Xnee présent dans le dépôt Fedora, à l'aide du système de Mise à jour Fedora, Bodhi. Il ne faut pas oublier d'assigner le ticket de Bugzilla à l'update.

casper@blackbird:~/fedora-scm/Xnee$ bodhi -u fantom -n -b 1059676 -t enhancement -N "Update to 3.18" -R testing Xnee-3.18-1.fc20
Creating a new update for Xnee-3.18-1.fc20
Password for fantom:
Creating a new update for Xnee-3.18-1.fc20
Update successfully created
================================================================================
     Xnee-3.18-1.fc20
================================================================================
    Release: Fedora 20
     Status: pending
       Type: enhancement
      Karma: 0
    Request: testing
       Bugs: 1059676 - Xnee-3.18 is available
      Notes: Update to 3.18
  Submitter: fantom
  Submitted: 2014-04-29 17:19:16
   Comments: bodhi - 2014-04-29 17:19:31 (karma 0)
             This update has been submitted for testing by fantom.

  https://admin.fedoraproject.org/updates/Xnee-3.18-1.fc20


Dans 7 jours le paquet passera du dépôt updates-testing au dépôt updates, uniquement avec la commande que je dois lancer manuellement :

$ bodhi -u fantom -R stable Xnee-3.18-1.fc20

L'option -R signifiant "request" pour demander le passage en stable, et Xnee-3.18-1.fc20 indiquant le nom du paquet construit par Koji.

Présent à la table ronde "Evolution des meilleures pratiques du développement web" à Solutions Linux & Open Source 2014

Guillaume Kulakowski

Je serais présent au salon Solutions Linux & Open Source 2014 qui se déroulera les 20 et 21 mai au Cnit de Paris La Défense.

Cette années, en plus d'arpenter les allées de la partie pro ou du village gaulois, vous pourrez également me retrouver au track "Développement web : la nouvelle donne Open Source" :

Les technologies Web semblent évoluer sans cesse plus vite. Les performances et les capacités, des navigateurs ne cessent daugmenter. Tous les ans, un ou plusieurs nouveaux frameworks open source à la mode apparaissent. Dans ce contexte, comment tirer au mieux partie de ces innovations ? Quels outils et quels workflows pour les développeurs et pour les équipes ? Comment sorganiser pour rester au top ? Des experts techniques et des chefs de projets expérimentés débattront de ces sujets et répondront aux questions de lassistance.

Animateur : Stéphane VINCENT, Responsable des Offres et de l'Innovation, Alterway

Intervenants :

  • Gilles GUIRAND, CTO, Kaliop
  • Guillaume KULAKOWSKI, Expert technique en solutions Open-source, CGI
  • Jean-François LEPINE, Consultant technique, Alterway

Présent à la table ronde "Evolution des meilleures pratiques du développement web" à Solutions Linux & Open Source 2014

Guillaume Kulakowski

Je serais présent au salon Solutions Linux & Open Source 2014 qui se déroulera les 20 et 21 mai au Cnit de Paris La Défense.

Cette années, en plus d'arpenter les allées de la partie pro ou du village gaulois, vous pourrez également me retrouver au track "Développement web : la nouvelle donne Open Source" :

Les technologies Web semblent évoluer sans cesse plus vite. Les performances et les capacités, des navigateurs ne cessent daugmenter. Tous les ans, un ou plusieurs nouveaux frameworks open source à la mode apparaissent. Dans ce contexte, comment tirer au mieux partie de ces innovations ? Quels outils et quels workflows pour les développeurs et pour les équipes ? Comment sorganiser pour rester au top ? Des experts techniques et des chefs de projets expérimentés débattront de ces sujets et répondront aux questions de lassistance.

Animateur : Stéphane VINCENT, Responsable des Offres et de l'Innovation, Alterway

Intervenants :

  • Gilles GUIRAND, CTO, Kaliop
  • Guillaume KULAKOWSKI, Expert technique en solutions Open-source, CGI
  • Jean-François LEPINE, Consultant technique, Alterway

Présent à la table ronde "Evolution des meilleures pratiques du développement web" à Solutions Linux & Open Source 2014

Guillaume Kulakowski

Je serais présent au salon Solutions Linux & Open Source 2014 qui se déroulera les 20 et 21 mai au Cnit de Paris La Défense.

Cette années, en plus d'arpenter les allées de la partie pro ou du village gaulois, vous pourrez également me retrouver au track "Développement web : la nouvelle donne Open Source" :

Les technologies Web semblent évoluer sans cesse plus vite. Les performances et les capacités, des navigateurs ne cessent daugmenter. Tous les ans, un ou plusieurs nouveaux frameworks open source à la mode apparaissent. Dans ce contexte, comment tirer au mieux partie de ces innovations ? Quels outils et quels workflows pour les développeurs et pour les équipes ? Comment sorganiser pour rester au top ? Des experts techniques et des chefs de projets expérimentés débattront de ces sujets et répondront aux questions de lassistance.

Animateur : Stéphane VINCENT, Responsable des Offres et de l'Innovation, Alterway

Intervenants :

  • Gilles GUIRAND, CTO, Kaliop
  • Guillaume KULAKOWSKI, Expert technique en solutions Open-source, CGI
  • Jean-François LEPINE, Consultant technique, Alterway

OpenLayers : créer une couche à partir d'une feature

Thomas Bouffon

J'ai eu récemment à créer une carte qui affiche dynamiquement les résultats d'une recherche sur une carte. L'idée générale était d'avoir une liste de features, et d'afficher celles qui correspondaient à une recherche.

Ma première solution a été de créer la couche avec toutes les features à partir d'un fichier JSON ou KML, puis de masquer celles qui ne correspondent pas. Mais avec 1500 éléments, c'est très long sous IE.

Deuxième solution : supprimer l'attribut "source" de la couche (toujours de type kml ou json) à sa création, on arrive à créer une couche vide dans laquelle on peut rajouter des features.... Sauf si IE, encore une fois !

La solution qui fonctionne sous IE est de créer une couche de type vector, vide, puis d'y ajouter la feature :

var json;
$.getJSON( "fichier.json", function( data ) {
json=data;
}
);

feature=parser.parseFeature(json[0]);
feature.geometry=feature.geometry.transform("EPSG:4326",map.projection);
resultats=new OpenLayers.Layer.Vector("resultats",{
displayInLayerSwitcher:false, style:result_style
});
resultats.addFeatures([feature]);
map.addLayer(resultats);

Attention, il faut reprojeter la feature dans le système de coordonnées de la carte, qui OpenLayers.Layer.Vector ne supporte pas l'attribut projection !

Bug OpenSSL - CVE-2014-0160

Alexandre Frandemiche

Heartbleed Bug

Je pense que beaucoup d'entre vous ont vu passer l'info, je me contenterai donc de donner quelques liens permettant de sécuriser son routeur sous OpenWRT et son NAS ReadyNAS !

Bug OpenSSL en question : https://heartbleed.com/

Pour tester son site/url : http://filippo.io/Heartbleed/

Mise à Jour OpenWRT

Rendez-vous dans l'interface d'administration luci dans System -> Software et filtrer sur openssl, on constate la version incriminée, passer sur l'onglet "Available packages (openssl) et installer les 2 mises à jour de openssl-util et libopenssl et le tour est joué !

openwrt-opensslMise à Jour ReadyNAS OS 6

Le plus simple est de se rendre sur ce post et de suivre les instructions : http://www.readynas.com/forum/viewtopic.php?f=65&t=75947&start=15#p423049
En gros, cela revient à éxécuter en root les commandes suivantes : 

Pour vérifier la version actuelle :

dpkg -l | grep openssl

Mettre à jour openssl :
wget http://security.debian.org/debian-security/pool/updates/main/o/openssl/openssl_1.0.1e-2+deb7u5_amd64.deb
dpkg -i openssl_1.0.1e-2+deb7u5_amd64.deb
service apache2 restart
service ssh restart

Vérifier la version à nouveau :

dpkg -l | grep openssl

Ensuite, vous pouvez vous rendre sur l'interface d'administration de votre NAS, dans System -> Settings -> Services, cliquer sur HTTPS , changer le nom et regénérer le certificat !

Par la suite, vous pouvez aussi surpprimer vos clé SSH présent sur votre serveur :

rm /etc/ssh/ssh_host_*.pub
rm /etc/ssh/ssh_host_*
rm /root/.ssh/id_rsa.pub
rm /root/.ssh/id_rsa

Voilà ! Vous êtes tranquille ! ;)" class="smiley ... jusqu'à la prochaine faille :D!

mai 2014

Premier Samedi Date : samedi 3 mai 2014 Horaires : de 14h00 à 18h00 Lieu : Carrefour Numérique, Cité des Sciences et de lIndustrie, Paris Pour une nouvelle installation ou pour des ajustements de votre distribution GNU/Linux Fedora, Mageia ou Ubuntu, venez nous retrouver le samedi 3 mai 2014 au Carrefour Numérique de la Cité des Sciences […]

Et l'impensable arriva

Matthieu Saulnier

Grosse faille de sécurité découverte dans OpenSSL cette nuitheartbleed.png

Cette nuit le service de sécurité de Google a révélé l'existance d'une vulnérabilité au sein de la bibliothèque OpenSSL. L'exploitation de cette faille permet entre autre de récupérer la clé privée de chiffrement du serveur, ce qui a pour effet immédiat de compromettre toutes les communications en cours et futures entre les clients et le serveur. En clair les informations chiffrées circulant sur le réseau sont récupérables... en clair.

Plus d'infos sur la CVE-2014-0160 :

Upgradez votre paquet openssl, c'est urgent

Fedora 20 et 19 sont concernées par la faille car elles fournissent la version d'OpenSSL contenant la faille. Le mainteneur du paquet, Dennis Gilmore, a déjà reconstruit le paquet avec le correctif, et la communauté a déjà poussé le paquet dans le dépôt Updates Stable par le biais de fedora-easy-karma. Il se peut que le paquet ne soit pas présent sur votre miroir local, à l'heure où j'écris ces lignes il ne l'est pas. Il ne faut pas attendre qu'il le soit. Vous pouvez dès à présent installer le paquet directement depuis l'infrastructure de construction de fedora (Koji) avec ce qui suit :

yum install koji
koji download-build --key=246110c1 --arch=x86_64 openssl-1.0.1e-37.fc20.1
yum install openssl-1.0.1e-37.fc20.1.x86_64.rpm openssl-libs-1.0.1e-37.fc20.1.x86_64.rpm

Remplacez x86_64 par i686 ou armv7hl selon votre architecture.

Quelle est l'issue de l'histoire ?

La faille est corrigée certes, GNU/Linux gagne toujours à la fin (en moins de 6 heures après divulgation tout de même). Mais depuis tout le temps qu'elle ne l'est pas qu'est-ce qui prouve que la clé privée de certificats, de casperlefantom.net pour ne citer que lui, n'a pas été compromise ? Rien. (Attention je parle uniquement du certificat servant à chiffrer la connexion, et non pas du CA qui n'est pas présent sur le serveur de toutes façons). Une solution pour les administrateurs de serveurs est donc de générer une nouvelle clé privée de certificats, reconstruire un CSR puis le refaire signer par son CA. Je pense que ça serait la moindre des choses par respect pour les visiteurs. Ce sera fait dans quelques heures pour ma part.

PHP 5.4.27 et 5.5.11

Remi Collet

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

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

Annonces des versions :

Installation de PHP 5.5

yum --enablerepo=remi-php55,remi update php\*

Installation de PHP 5.4

yum --enablerepo=remi update php\*

Et bientôt dans les mises à jour officielles:

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

  • la version EL6 est construite avec RHEL-6.5
  • pour php 5.5, l'extension Zip est désormais fournit dans le paquet php-pecl-zip.
  • beaucoup de nouvelles extensions sont aussi disponible, voir PECL extension RPM status page

emblem-notice-24.pngInformations, lire :

Mise en oeuvre de logstash

Edouard Bourguignon

Logstash est un excellent produit de tri, traitement et collecte des journaux (=>logs).

Présentation

Logstash est un moteur de découpage de logs. Il est déjà riche de nombreux plugins et expressions régulières pour comprendre une très large variété de logs (system, apache, postfix, etc). Il est de plus très souple pour configurer les règles et tries des logs qu'on lui envoit.

Le logiciel logstash possède de nombreux avantages, entres autres:

  • Il est compatible avec les protocoles courants comme syslog, idéal pour s'insérer dans des architectures existantes
  • il est extensible dans le sens où tout est configuré en utilisant des expressions régulières, dont beaucoup sont déjà fournies
  • il est très scalable car il repose sur une base de données elasticsearch (qui peut fonctionner en cluster), des services de "cache" (broker)

Le projet existe déjà depuis quelques années et possède une bonne communauté, avec de nombreux projets orbitant autour de cette solution.

Il supporte aussi très bien la mise à l'échelle, via des éventuelles clients pour pre-parser les logs, un gestionnaire de cache ou broker (par exemple redis), et une base de données modernes types noSQL (elasticsearch).

Mise en oeuvre

Pour la mise en oeuvre au sein d'une architecture simple, logstash se positionne sur un serveur central faisant office de collecteur de logs. Sur ce serveur logstash est configuré avec une entrée de type syslog sur le port 5544 (par ex).

Les clients envoyent leurs logs via rsyslog, exactement comme il le ferait vers un collecteur syslog classique.

Configuration des dépôts yum

Il y a un dépôt yum pour elasticsearch, et un pour logstash.

Fichier de configuration du dépôt pour elasticsearch dans /etc/yum.repos.d/elasticsearch.repo:

[elasticsearch-1.1]
name=Elasticsearch repository for 1.1.x packages
baseurl=http://packages.elasticsearch.org/elasticsearch/1.1/centos
gpgcheck=1
gpgkey=http://packages.elasticsearch.org/GPG-KEY-elasticsearch
enabled=1

Fichierde configuration du dépôtpour elasticsearch dans/etc/yum.repos.d/elasticsearch.repo:

[logstash-1.4]
name=logstash repository for 1.4.x packages
baseurl=http://packages.elasticsearch.org/logstash/1.4/centos
gpgcheck=1
gpgkey=http://packages.elasticsearch.org/GPG-KEY-elasticsearch
enabled=1

Installation des paquets

L'installation de la base de données se fait avec la commande suivante:

yum install elasticsearch

​L'installation de logstash se fait avec la commande suivante:

yum install logstash

Configuration

Voici un fichier de configuration d'exemple, avec des entrées de type syslog, un filtre pour comprendre les logs rsyslog, et un stockage en sortie dans elasticsearch.

# Ouverture en entrée d'un port d'écoute utilisant le protocol syslog
input {
  tcp {
    port => 5544 
    type => syslog 
  }
  udp {
    port => 5544 
    type => syslog 
  }
}

filter {
  # Traitement type syslog, le type étant marqué sur les données entrant par nos ports de type syslog
  if [type] == "syslog" {
    grok {
      # Si on ne veut pas garder le message non traité
      overwrite => "message"
      match => {
        # rsyslong envoi des messages de type : <Numero>Ligne Syslog avec le message
        "message" => "^(?:<%{NONNEGINT:syslog_pri}>)?%{SYSLOGBASE2} %{GREEDYDATA:message}" 
      }
      # on ajoute des tags perso, pratique pour filtrer dans l'interface kibana
      add_tag => [ "syslog", "grokked" ] 
    }
    # On ignore le champ syslog_pri
    syslog_pri { }

    # on crée une colonne hostip avec le contenu de la variable host
    mutate {
      add_field => [ "hostip", "%{host}" ] 
    }

    # on resoud l'ip présent dans la colonne host
    dns {
      reverse => [ "host" ] 
      action => "replace" 
    }
  }
}

# on stock dans elasticsearch
output {
  elasticsearch {
    host => "localhost" 
  }
}

Explication

La partie "input" est suffisament explicite. Le seul intérêt est qu'on marque ce qui entre par les ports indiqués comme étant de type "syslog". Cela permet de faire des traitements conditionnels plus loin si besoin en fonction du type de logs.

La partie "filter" est toujours la plus complexe. C'est dans cette partie que le traitement de la ligne de log reçue ce fait. Le plugin grok ici utilisé connait déjà beaucoup d'expressions régulières pour nous aider à découper nos lignes. C'est ce que fait en gros le paramètre "match" qui indique que le champ "message" (qui correspond à la ligne qu'on vient de recevoir), va être découpé selon l'expression suivante:

"^(?:<%{NONNEGINT:syslog_pri}>)?%{SYSLOGBASE2} %{GREEDYDATA:message}"

Une ligne type syslog ressemble à ça:

<Numero>Apr 5 09:36:33 syslog_facility.priorité client programme: message

Notre regexp précédente cherche bien un entier non negatif entre < >, qui sera stocké dans la colonne/variable syslog_pri.

La suite de notre regexp utilise des clefs proposées par grok, déjà écrites. Elles sont définies dans /opt/logstash/patterns. Par ex SYSLOGBASE2 correspond à:

(?:%{SYSLOGTIMESTAMP:timestamp}|%{TIMESTAMP_ISO8601:timestamp8601}) (?:%{SYSLOGFACILITY} )?%{SYSLOGHOST:logsource} %{SYSLOGPROG}:

SYSLOGTIMESTAMP et TIMESTAMP_ISO8601 sont aussi des clefs fournies par logstash et correspondent à des formats date type syslog. Exactement ce qui arrive après notre <Numero> dans notre ligne de log. La date ainsi trouvée sera stockée dans la variable timestamp pour une date au format classique, ou timestamp8601 si elle est au format iso8601.

Le reste de la ligne va récupérer le syslog_facility grâce au pattern SYSLOGFACILITY qui correspond à <%{NONNEGINT:facility}.%{NONNEGINT:priority}>. Ce qui va stocker la syslog_facility dans facility, et la priorité dans priority.

Le nom du client envoyant le log sera quand à lui stocké dans logsource.

Enfin le nom du programme est récupéré, suivi de : puis le message qui correspond au reste de la ligne (avec plein de caractères donc de type GREEDYDATA).

Voilà. Pour résumer notre ligne si elle correspond à l'expression que l'on cherche, est découpée et certaines parties (car tout n'est pas toujours à garder) sont ainsi stockées dans des variables. Comme au final nous stockons tout dans une base elasticsearch, qui est de type noSQL, nos variables seront en fait des colonnes dans la base. Et comme c'est du noSQL, chaque ligne de notre base peut avoir des colonnes différentes.

Ensuite dans notre filtre, nous avons préciser que nous voulions écraser la variable message, avec ce que nous découperons dans notre ligne. Car la ligne d'origine est déjà stockée dans la variable message. Si vous ne faites pas ça, la variable message que nous créons dans notre regexp sera ajoutée à la variable message déjà existante et qui deviendra du coup un tableau (message0 ligne d'origine, message1 notre variable traitée). C'est utilie éventuellement pour debuguer, mais au final c'est pas lisible, mieux vaut l'écraser.

Et enfin, notre plugin grok, après avoir trouvé nos variable, va ajouter des tags. C'est surtout utile pour retravailler certaines choses plus loin, ou tout simplemet pour filtrer les messages ensuite dans l'interface web. Ici nous ajoutons les tags syslog et grokked. Si le filtre echou (par ex la ligne ne ressemble pas au match indiqué), le tag _grokparsefailure est automatiquement ajouté.

Reste plus qu'à configurer l'interface web kibana pour apprécier tout ça.

Ghostscript : Réduire la taille d'un pdf

Thomas Bouffon

Certains pdf issus de scans sont très volumineux comparé au nombre de pages qu'ils contiennent : c'est dû à une résolution trop importante. Le paramètre PDFSETTINGS permet d'utiliser des préréglages en fonction de la destination vers laquelle il doit être affiché. Elle peut prendre les valeurs suivantes :

  • screen : 72dpi
  • ebook : 150dpi
  • printer : 300dpi
  • prepress : 300dpi

Le réglage ebook semble le meilleur compromis :

 gs -sDEVICE=pdfwrite -dCompatibilityLevel=1.4 -dPDFSETTINGS=/ebook -dNOPAUSE -dQUIET -dBATCH -sOutputFile=sortie.pdf entree.pdf

Bascule sous CentOS 6.5

Remi Collet

Jusqu'à présent mon serveur fonctionnait sous RHEL 6.5

# wget http://ftp-stud.fht-esslingen.de/pub/Mirrors/centos/6/os/x86_64/Packages/centos-release-6-5.el6.centos.11.1.x86_64.rpm
# yum shell
Setting up Yum Shell
> remove redhat-release
Setting up Remove Process
> install centos-release-6-5.el6.centos.11.1.x86_64.rpm
> run
===============================================================================================================================================================================
Package Arch Version Repository Size
===============================================================================================================================================================================
Installing:
centos-release x86_64 6-5.el6.centos.11.1 /centos-release-6-5.el6.centos.11.1.x86_64 32 k
Removing:
redhat-release-server x86_64 6Server-6.5.0.1.el6 @rhel-x86_64-server-6 119 k

Transaction Summary
===============================================================================================================================================================================
Install 1 Package(s)
Remove 1 Package(s)

Total size: 32 k
Is this ok [y/N]: y
Downloading Packages:
Running rpm_check_debug
Running Transaction Test
Transaction Test Succeeded
Running Transaction
Installing : centos-release-6-5.el6.centos.11.1.x86_64 1/2
Erasing : redhat-release-server-6Server-6.5.0.1.el6.x86_64 2/2
Verifying : centos-release-6-5.el6.centos.11.1.x86_64 1/2
Verifying : redhat-release-server-6Server-6.5.0.1.el6.x86_64 2/2

Removed:
redhat-release-server.x86_64 0:6Server-6.5.0.1.el6

Installed:
centos-release.x86_64 0:6-5.el6.centos.11.1

Finished Transaction
> Leaving Shell

# cat /etc/redhat-release
CentOS release 6.5 (Final)

# yum remove rhn\*
...
# yum update

Bascule sous CentOS 6.5

Remi Collet

Jusqu'à hier mon serveur fonctionnait sous RHEL 6.5

# wget http://ftp-stud.fht-esslingen.de/pub/Mirrors/centos/6/os/x86_64/Packages/centos-release-6-5.el6.centos.11.1.x86_64.rpm
# yum shell
Setting up Yum Shell
> remove redhat-release
Setting up Remove Process
> install centos-release-6-5.el6.centos.11.1.x86_64.rpm
> run
===============================================================================================================================================================================
Package Arch Version Repository Size
===============================================================================================================================================================================
Installing:
centos-release x86_64 6-5.el6.centos.11.1 /centos-release-6-5.el6.centos.11.1.x86_64 32 k
Removing:
redhat-release-server x86_64 6Server-6.5.0.1.el6 @rhel-x86_64-server-6 119 k

Transaction Summary
===============================================================================================================================================================================
Install 1 Package(s)
Remove 1 Package(s)

Total size: 32 k
Is this ok [y/N]: y
Downloading Packages:
Running rpm_check_debug
Running Transaction Test
Transaction Test Succeeded
Running Transaction
Installing : centos-release-6-5.el6.centos.11.1.x86_64 1/2
Erasing : redhat-release-server-6Server-6.5.0.1.el6.x86_64 2/2
Verifying : centos-release-6-5.el6.centos.11.1.x86_64 1/2
Verifying : redhat-release-server-6Server-6.5.0.1.el6.x86_64 2/2

Removed:
redhat-release-server.x86_64 0:6Server-6.5.0.1.el6

Installed:
centos-release.x86_64 0:6-5.el6.centos.11.1

Finished Transaction
> Leaving Shell

# cat /etc/redhat-release
CentOS release 6.5 (Final)

# yum remove rhn\*
...

# yum update
...

Amélioration de PHP-FPM et HTTPD 2.4

Remi Collet

Suite du billet PHP-FPM et HTTPD 2.4

Jusqu'à présent, on devait passer par la directive ProxyPassMatch, pas très souple, voici comment faire plus simple.

La version Apache HTTP Server 2.4.9 récemment publiée sera bientôt disponible dans les mises à jour de Fedora 20.

Cette version intègre un correctif (pas encore dans la version officielle) qui permet de rediriger les requêtes vers un mandataire FastCGI à l'aide de la directive SetHandler.

La directive ProxyPassMatch étant évaluée au tout début d'une requête

  • les directives AddType (pour le MultiView) ou DirectoryIndex ne sont pas utilisables
  • la gestion des droits par dossier n'est pas prise en compte
  • chaque Alias doit être complété d'une règle de proxy

La directive SetHandler qui est évaluée à la fin est donc beaucoup plus pratique, elle est d'ailleurs utilisée pour mod_php

<FilesMatch \.phps$>
SetHandler application/x-httpd-php-source
</FilesMatch>

Grâce à cette évolution on va pouvoir utiliser php-fpm aussi simplement que mod_php.

Pour rediriger les scripts PHP vers le serveur FPM:

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

Attention, si vous déinstallez ou désactivez mod_php vous devez aussi supprimer toutes les directives php_value et php-flag, par exemple en les rendant conditionnelles :

<IfModule  mod_php5.c>
php_value session.save_handler "files"
php_value session.save_path "/var/lib/php/session"
php_value soap.wsdl_cache_dir "/var/lib/php/wsdlcache"
</IfModule>

Au passage, on peut en profiter pour abandonner le MPM prefork au profit d'un mode utilisant les threads :

#LoadModule mpm_prefork_module modules/mod_mpm_prefork.so
LoadModule mpm_event_module modules/mod_mpm_event.so

Ensuite, les applications web en PHP fonctionnent normalement (sauf celle utilisant l'authentification http, qui n'est pas encore supportée par FPM).

A suivre : l'utilisation des Sockets du domaine Unix, annoncé pour la 2.4.9 mais ne fonctionne que partiellement (les correctifs sont en cours de revue).

OpenLayers, couches wmts et niveaux de zoom

Thomas Bouffon

Dans Openlayers, le niveau de zoom min ou max ne dépend pas de la carte, mais de chaque couche : ainsi, si on ne veut fournir que certaines résolutions pour une couche wmts, il faut utiliser les paramètres resolutions et serverResolutions à la création des couches, sans modifier les paramètres de la carte :

resolutions:[5000,2500,1500,1000,750],
serverResolutions: [null,null ,null, null, null, null, 2445.9849047851562, 1222.9924523925781, 611.4962261962891, 305.74811309814453, 152.87405654907226, 76.43702827453613, 38.218514137268066, 19.109257068634033, 9.554628534317017, 4.777314267158508],

Ainsi, on indique que :

  • Quand la couche avec laquelle on a défini ces paramètres est la couche de base, alors les niveaux de zoom disponibles pour la carte correspondent au tableau resolutions de la couche : zoom 0 -> résolution 5000, zoom 4 -> résolution 750.
  • Le serveur wmts fournit les résolutions 2445 à 4.77. Ainsi, en fonction de la résolution demandée pour la carte (dans le tableau resolutions), OpenLayers demandera la couche dont la résolution est la plus proche de la résolution carte. Par exemple, pour la résolution carte 5000, on va requêter la résolution 2455. Les éléments null viennent du fait que serverResolutions est utilisé pour faire la correspondande tilematrix/résolution : si je veux la résolution 1222, je vais requêter la TM 7. Or pour cette couche du WMTS, les tilematrixes 1 à 5 ne sont pas disponibles.

Mutt et les signatures PGP d'Enigmail

Matthieu Saulnier

mutt.png

Une petite remarque sur la configuration par défaut de Mutt. Je ne sais pas si vous recevez beaucoup de mails en provenance de Thunderbird, mais lorsque le mail est signé par PGP, dans Mutt il n'est pas considéré comme un email signé. Du coup Mutt n'invoque pas automatiquement la commande de vérification de signature PGP, et le mail est affiché comme n'importe quel mail en texte brut.

Voici un exemple :

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

[...texte de l'email...]

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlMshhsACgkQrlYvE4MpobOIsQCghsLBWa3m8QxihXmjXsmm8UcE
708AmgOi7Hp1e1FRGMyuohfqonoS4fQQ
=PP3O
-----END PGP SIGNATURE-----

Heureusement il existe une option pour forcer la vérification au moment de la lecture de l'email. Ou plutôt pour détecter dans le contenu de l'email du texte correspondant à la sortie de GPG, puis auquel cas invoquer automatiquement la commande de vérification de signature. Dans la liste du contenu de la boite aux lettres l'email ne sera taggé comme signé qu'après lecture de celui-ci, si on utilise le format de boite aux lettres Maildir/.

set pgp_auto_decode = yes

Étrangement ce paramètre est très peu répandu dans les .muttrc prêts à l'emploi qu'on récolte un peu partout sur le web...

Fedora Paris au Bon Pêcheur

Fedora Paris

Fedora Paris se réunit à nouveau ! Haïkel (number80 pour les intimes) a décidé de descendre sur Paris. Et du coup, pour fêter l'un de nos lyonnais préférés, nous avons décidé de nous réunir pour diner. Nous vous donnons donc rendez-vous le 1er avril à 19h30 (et non, c'est pas une blague). Pour fêter malgré tout les poissons, nous allons diner au... Lire Fedora Paris au Bon Pêcheur

Red Hat va fournir PHP 5.5 pour RHEL-6

Remi Collet

Annonce : Red Hat Software Collections 1.1 now available

Que les accrocs de la stabilité se rassurent, PHP 5.3.3 reste la version standard fournit avec RHEL-6.

Que les utilisateurs de RHSCL 1.0 se rassurent, la collection php54 est toujours là. Elle s'enrichit même de l'extension Zend OPcache (php-pecl-zendopcache).

Nous disposerons donc bientôt d'un moyen officiel et supporté d'installer PHP version 5.4 ou 5.5, en parallèle  de la version système, sans affecter les composants standards. L'annonce prévoit un cycle de vie de 3 ans.

emblem-important-2-24.png Il s'agit pour l'instant uniquement d'une version Beta destinée à l'évaluation.

Pour plus d'informations sur l'installation et l'utilisation des SCL, vous pouvez consulter les autres billets déjà publiés à ce sujet :

emblem-notice-24.pngPour les utilisateurs des clones de RHEL (CentOS, Oracle, Scientific Linux, ...) vous pouvez utiliser les dépôts Copr de test :

emblem-notice-24.pngPour ceux qui souhaitent plus d'extensions, en attendant la possibilité de les inclure dans EPEL, j'ai ouvert 2 dépôts Copr avec toutes celles qui sont déjà prêtes (d'autres devraient suivre).

En dehors de PHP, RHSCL 1.1 senrichit de plusieurs morceaux de choix, je retiendrais Apache 2.4 et MongoDB (d'ailleurs, l'extension pecl/mongo est disponible dans la collection php55).

Il me semble que c'est une excellent nouvelle qui devrait aider à l'adoption des versions récentes de PHP dans le monde de l'entreprise.

emblem-question-24.pngSi vous avez des questions, j'ai même ouvert un nouveau Forum : About PHP SCL.

Adhésion à l'April

PHP 5.4.26 et 5.5.10

Remi Collet

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

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

security-medium-2-24.png Ces versions corrigeant plusieurs failles de sécurité, la mise à jour est recommandée.

Annonces des versions :

Installation de PHP 5.5

yum --enablerepo=remi-php55,remi update php\*

Installation de PHP 5.4

yum --enablerepo=remi update php\*

Et bientôt dans les mises à jour officielles:

À noter :

  • la version EL6 est construite avec RHEL-6.5
  • pour php 5.5, l'extension Zip est désormais fournit dans le paquet php-pecl-zip.
  • beaucoup de nouvelles extensions sont aussi disponible, voir PECL extension RPM status page

Informations, lire :

Page générée le 01 sept 2014 à 16:54