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.

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 :

Un cadeau de Broadcom pour l'OpenSource

Edouard Bourguignon

Ce n'est pas la première fois, et ce ne sera surement pas la dernière! Broadcom vient d'annoncer la mise à disposition de la documentation complète sur ses puces graphiques VideoCore IV, ainsi que les sources complètes de la pile logiciel en rapport. Cela, peut être pour remercier le Raspberry Pi, qui fête sa 2e année, et son succès planétaire.

Encore aujourd'hui, de nombreux matériels utilisant un SoC ARM comprenant une puce graphique Broadcom VideoCore IV sont obligés de passer par un binaire fermé (blob). Ceci est aussi vrai pour la plus part des puces des concurrents, et pas forcément pour la partie graphique. Cela concerne l'ensemble des smartphones, mais aussi le Raspberry Pi.

Du coup, le pilote graphique sous Linux, qui peut être libre et OpenSource, ne fait que relayer les instructions à ce binaire fermé. Si des bugs se produisent, ou pour proposer la moindre amélioration, la communauté et les développeurs du noyau ne peuvent rien faire.

Peut être fort de son succès, que ce soit avec les smartphones sous Android ou avec un Raspberry Pi vendu à plus de 2.5 millions d'exemplaires, et une communauté autour de ce projet tout aussi importante, Broadcom vient d'ouvrir sa pile graphique autour de ses puces VideoCore IV BCM21553. Ce n'est pas exactement ce modèle qui est utilisé dans le Raspberry Pi mais une puce très similaire, une BCM2835, le portage ne devrait donc pas poser de soucis.

Il reste cependant beaucoup de travail pour avoir une pile 100% libre et OpenSource autour de ses puces, mais la fondation Raspberry Pi souhaitant toujours proposer le matériel le plus ouvert possible, tente daccélérer les choses en proposant une prime de 10 000$ à celui qui codera des drivers full OpenSource permettant de jouer à Quake III sur notre bon vieux Raspberry Pi à 30$. La fondation sponsorise déjà de nombreux projets libres, dont pourrait tirer profit le Raspberry Pi, comme XBMC, ou encore Wayland/Weston (cherchez sur Youtube Wayland sur Raspberry Pi pour comprendre l'intérêt face à Xorg).

Donc merci Broadcom, et bon anniversaire au Raspberry Pi.

mesa 10.2 from git for Fedora 20

Nicolas Chauvet

This has started as a attempt to test the improvements of the freedreno ARM driver, so I've made an updated mesa package (and newer libdrm) specially for testing.

You can grab it installing the kwizart-release repository and

yum update --enablerepo=kwizart-testing libdrm\* mesa\*

The updated mesa 10.2 package from git20140209 is available for i686 x86_64 and armv7hl. The final version is scheduled in 3 months from now (so it could be in Fedora 21 by default). This is a different branch from the 10.1 branch to be release soon.

I'm not interested in xorg-x11-drv-vmware in this case, and there is an ABI break behind, so

yum remove xorg-x11-drv-vmware

Also an interesting feature of the mesa 10.2 branch is the OpenMAX IL feature on AMD devices. I try to maintain libomxil-bellagio within fedora, so I'm interested in feedbacks on this topic. The AMD GPU I can test on doesn't seem to be compatible with the feature. But there are also probably few issues with libomxil-bellagio given the lack of upstream activity.

VLC from RPM Fusion should be compatible with OpenMAX IL, and gstreamer has a plugin that should enter into Fedora at some point (currently in review).

Also the packaging git work is currently ahead of the fedora rawhide spec, so there are probably few patches that can be used in the next fedora package.

Nouveau dépôt : remi-php56

Remi Collet

Les RPM pour Fedora ≥ 19 et  Enterprise Linux (RHEL, CentOS...) de PHP 5.6 et de ses extensions sont désormais disponibles dans le nouveau dépôt expérimental dédié : remi-php56.

Sur le modèle du dépôt remi-php55, je viens d'ouvrir un nouveau dépôt pour PHP 5.6.

Attention Attention ; il s'agit actuellement d'une version 5.6.0-dev, donc pour test, à ne pas utiliser en production. Les extensions pecl ne sont pas toutes encore disponibles.

Pour Enterprise Linux vous disposez désormais de 4 dépôts :

  • remi qui contient les paquets communs, PHP 5.4 et les extensions PHP qui ne dépendent pas de la version utilisée.
  • remi-php55 qui contient les paquets PHP 5.5 et les extensions
  • remi-php56 qui contient les paquets PHP 5.6 et les extensions
  • remi-test qui contient "vraiment" les paquets à tester.

Pour Fedora il s'agit d'un dépôt temporaire, lorsque le version 5.6 sera stable, ils rejoindront le dépôt remi.

Remarques :

  • Si vous activez remi-php56 vous devez aussi activer remi.
  • Les RPM des extensions C ont désormais un suffixe .remi.5.4 ou .remi.5.5 ou .remi.5.6.
  • Ce nouveau dépôt est défini dans la nouvelle version du paquet remi-release (version 5.10-1, 6.5-1, 19-2 ou 20-2).

J'espère ne rien avoir oublié, n'hésitez pas à me signaler le moindre problème sur le forum.

avril 2014

Premier Samedi Date : samedi 5 avril 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 5 avril 2014 au Carrefour Numérique de la Cité des Sciences […]

GLPI version 0.84.5

Remi Collet

GLPI (Gestionnaire Libre de Parc Informatique) version 0.84.5 est publiée. Les RPM sont disponibles dans le dépôt remi pour Fedora ≥ 15 et EL ≥ 5.

Le dépôt remi-test est donc nettoyé, et pourra être utilisé pour la prochaine 0.85 (les beta-tests viennent de commencer).

Annonces des versions :

La documentation est disponible en PDF : glpidoc-0.84.3-fr.pdf

Cette version est aussi disponible dans les dépôts officiels de Fedora 20 (sans extension).

Actuellement dans le dépôt :

  • glpi-0.84.5-1
  • glpi-appliances-1.9.0-1
  • glpi-data-injection-2.3.0-1
  • glpi-behaviors-0.84.1-1
  • glpi-fusioninventory-0.84.0.2.0-1
  • glpi-ocsinventoryng-1.0.2-1
  • glpi-pdf-0.84-1
  • glpi-reports-1.7.2-1
  • glpi-webservices-1.4.1-1

Attention Attention: l'assistant d'installation est pour des raisons de sécurité uniquement accessible depuis le serveur sur lequel GLPI est installé. Voir le fichier de configuration (/etc/httpd/conf.d/glpi.conf) pour élargir temporairement cette autorisation si besoin.

Vous êtes invités à tester ces versions sur un environnement spécifique et à remonter vos questions, commentaires ou problèmes sur

Les RPM de GLPI et de quelques extensions ainsi cette page seront régulièrement mis à jour.

Advanced Intrusion Detection Environment (AIDE)

Matthieu Saulnier

Système de sécurité HIDS

AIDE est un système de détection de l'intègrité de l'hôte (HIDS: Host Integrity Detection System). La machine hôte contient un système de fichier qui permet de faire fonctionner le système d'exploitation. Les fichiers vitaux du système d'exploitation sont principalement la cible des attaques informatiques. L'intègrité d'une machine hôte est compromise si ses fichiers parvenaient à être modifiés par un moyen quelconque utilisé par un attaquant. AIDE est un logiciel qui permet de détecter si une intrusion a eu lieu, mais ne sert pas à empècher une intrusion. C'est un détecteur et non un système de réponse adaptée à une situation précise (logiciel de contre-mesure). Il permet donc d'avoir un rapport exhaustif sur l'intègrité du système d'exploitation. En fait ce logiciel indique juste quels fichiers ont été modifiés, créés, supprimés, en comparant ceux actuellement présent sur le système d'exploitation avec ceux d'une base de données initialisée par l'administrateur de la machine. Il est d'usage de créer cette base de données avant de raccorder la machine au réseau la rendant sujette au risque de compromission. Personnellement avant d'avoir découvert AIDE dans ce très bon guide, j'avais installé sur mon serveur un autre HIDS : Tripwire. Maintenant Tripwire et AIDE cohabitent sur la même machine, les HIDS ne font jamais de conflits entre-eux.

Installation sur Fedora 20

L'installation et la mise en route sont encore plus simple que pour Tripwire :

# yum install aide

Puis créer la base de données initiale contenant la liste des fichiers du système d'exploitation ainsi que leurs sommes de contrôle :

# aide --init

Cette commande prend du temps, prévoir un café pendant que ça tourne. Lorsque la commande aura rendu le prompt, la base de données écrite par AIDE sera toujours dans le fichier /var/lib/aide/aide.db.new.gz. La base de données utilisée pour effectuer le test d'intègrité sera toujours dans le fichier /var/lib/aide/aide.db.gz. Aussi avant de lancer les tests il convient de copier la base de données nouvellement créée au bon emplacement :

# scp /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz

AIDE et SELinux

Les deux fichiers qui viennent d'être créés n'ont pas les bons contextes SELinux.

# ll -Z /var/lib/aide/
-rw-------. root root unconfined_u:object_r:var_lib_t:s0 aide.db.gz
-rw-------. root root unconfined_u:object_r:var_lib_t:s0 aide.db.new.gz

Du coup si on lance les tests avec l'utilisateur root qui possède le contexte :

# id -Z
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

Le processus ne sera pas cloisonné et donc ça marchera. Par contre, si on lance AIDE dans un Cron, alors le processus sera cloisonné et SELinux nous fera un joli refus d'accès AVC. Heureusement il y a un contexte prévus par défaut dans le module de règles targeted, au lieu d'appliquer de nouveaux contextes l'opération ressemble plutôt à une restauration des contextes initialement prévus par le module de règles :

# restorecon -vR /var/lib/aide/
restorecon reset /var/lib/aide/aide.db.gz context unconfined_u:object_r:var_lib_t:s0->unconfined_u:object_r:aide_db_t:s0
restorecon reset /var/lib/aide/aide.db.new.gz context unconfined_u:object_r:var_lib_t:s0->unconfined_u:object_r:aide_db_t:s0

La target prévue était aide_db_t, j'ignore encore pourquoi ce contexte n'a pas été appliqué dès la création des fichiers malgrès que le service restorecond soit actif. (Service systemd livré avec le paquet policycoreutils-restorecond qui n'est pas toujours installé par défaut).

Rapport journalier

On peut automatiser le contrôle d'intègrité dans un Cron affin de suivre l'évolution du système d'exploitation au jour le jour. Le rapport est vraiment bien détaillé et permet de voir l'impact d'une mise à jour ainsi que les développements de l'admin, très utile pour la recherche d'une avarie. Le script Cron est tout simple, mais il n'est pas livré avec le paquet, il faut donc l'ajouter à la main :

# cat /etc/cron.daily/z-aidereport.sh
#!/usr/bin/bash

aide --update --verbose=20
cp -f /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz && echo "Updated database file: aide.db.gz"

Avec les bonnes permissions (chmod +x). Le nom du script est important, ici je le fais commencer par la lettre Z car les scripts du répertoire /etc/cron.daily/ sont exécutés dans l'ordre alphabétique, il sera donc lancé après tous les autres. Le rapport sera alors envoyé par email à l'utilisateur root de la machine. Prelink étant retiré définitivement de Fedora à partir de la version 20, pas besoin de le désactiver pour éviter les faux positifs dans le rapport des HIDS.

Checkdns 0.5-15

Matthieu Saulnier

Introduction

La chronique continue, avec cette fois-ci la mise à jour d'un paquet que je viens de récupérer du dépôt. Son propriètaire précédent ne montrant plus signe de vie, ses paquets sont devenus "orphelins" et sont automatiquement retirés du dépôt s'ils ne trouvent pas un nouveau propriètaire. Ces événements sont annoncés sur la liste de diffusion de développement du Projet Fedora. Récupérer un ancien paquet n'est pas une opération anodine, car même si le paquet est déjà fait, il est resté un certain temps sans aucune maintenance et donc n'a pas suivi les dernières évolutions d'empaquetage de la distribution. Les tickets du bugzilla s'empilent sur son dos tandis que la dernière activité des développeurs du logiciel remonte à 2005 (dans le jargon on dit que « Upstream est mort »). Avant de se porter acquéreur d'un paquet nouvellement orpheliné, il convient de vérifier que les tickets de bugzilla ouverts contre ce paquet puissent être fermés, soit par une mise à jour produite par les développeurs du logiciel (appelés Upstream pour les intîmes), soit par une mise à jour du paquet produite par le packageur. Le seul ticket ouvert concerne une évolution d'empaquetage, que je vais donc devoir résoudre avec cette mise à jour.

Prérequis

Toujours avoir le groupe de paquets Empaqueteur Fedora installé sur votre machine.

# yum install @rpm-development-tools

Récupération des sources du paquet

Même si le paquet est marqué comme "orphelin" et qu'il est donc retiré du dépôt, son code source restera toujours accessible. Ainsi les sources de n'importe quel paquet qui a été présent au moins une fois dans le dépôt fedora par le passé peuvent être récupérées. Dans le cas présent vu que je suis son nouveau propriètaire le cas ne se pose pas mais je tenais à le signaler. Comme d'habitude, on clône le dépôt à code source de checkdns sur le disque dur :

casper@blackbird:~/fedora-scm$ fedpkg clone -a checkdns

Si vous ne possédez pas votre propre compte FAS, l'option -a de la commande est obligatoire (-a pour "anonyme", sans spécifier de compte FAS). Aussitôt on vérifie que la version du logiciel empaquetée est bien la dernière version du logiciel parue :

casper@blackbird:~/fedora-scm/checkdns$ egrep 'URL|Version|Source0' checkdns.spec
Version:        0.5
URL:            http://www.enderunix.org/checkdns/
Source0:        http://www.enderunix.org/checkdns/%{name}-%{version}.tar.gz

Si j'ai également fait apparaitre l'url du tarball, c'est parce que le site en PHP a un comportement un peu étrange, du coup je voulais vérifier la présence du fichier et d'un éventuel nouveau tarball. Il s'avère que tout est en ordre, le paquet contient bien la dernière version du logiciel.

Les modifications du RPM

Certes, cette mise à jour n'implique pas beaucoup le logiciel empaqueté, mais l'opération de taille consiste à faire le ravalement de façade du paquet, en résolvant en premier le ticket du bugzilla.

Fixer le bug

Le rapporteur du bug nous informe d'un changement approuvé par le Comité d'Empaqueteur Fedora concernant les paquets fournissants des tâches Cron. Ces paquets doivent désormais avoir une dépendance sur le paquet "crontabs" lorsqu'ils ajoutent une tâche dans le répertoire /etc/cron.d/, et les fichiers de tâche doivent avoir les permissions en 0640. Le rapporteur donne même un exemple sur le paquet Cacti en pièce jointe du ticket. Du coup, on incrémente le tag Release du paquet, et on applique les changements imposés par la nouvelle Guideline d'empaquetage des fichiers de tâche Cron. En l'occurence on ajoute une dépendance sur le paquet crontabs qui possède le répertoire %{_sysconfdir}/cron.d/, et on ajuste les permissions du fichier de tâche Cron en 640 conformément à la guideline.

--- checkdns.spec.orig  2014-02-25 01:58:14.926521141 +0100
+++ checkdns.spec       2014-02-25 01:58:55.330904343 +0100
@@ -1,6 +1,6 @@
 Name:          checkdns
 Version:       0.5
-Release:       14%{?dist}
+Release:       15%{?dist}
 Summary:       A Domain Name Server analysis and reporting tool
 
 Group:         Applications/Internet
@@ -11,7 +11,7 @@ Source1:      checkdns.cron
 Patch0:                checkdns-0.5.config_location.patch
 BuildRoot:     %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
 
-Requires:      httpd, bind
+Requires:      httpd, bind, crontabs
 Requires(pre): shadow-utils
 
 %description
@@ -45,7 +45,7 @@ install -p checkdns $RPM_BUILD_ROOT/%{_s
 install -d $RPM_BUILD_ROOT/%{_sysconfdir}
 sed -e '/html_output_dir/s@usr/local/apache/htdocs@var/www/html@' -e '/lang_file/s@local/@@' checkdns.conf-dist > $RPM_BUILD_ROOT/%{_sysconfdir}/checkdns.conf
 install -d $RPM_BUILD_ROOT/%{_sysconfdir}/cron.d
-install -p -m 0644 %{SOURCE1} $RPM_BUILD_ROOT/%{_sysconfdir}/cron.d/%{name}
+install -p -m 0640 %{SOURCE1} $RPM_BUILD_ROOT/%{_sysconfdir}/cron.d/%{name}
 install -d $RPM_BUILD_ROOT/%{_localstatedir}/www/html/%{name}
 install -p -m 0644 checkdns.css $RPM_BUILD_ROOT/%{_localstatedir}/www/html/%{name}
 install -d $RPM_BUILD_ROOT/%{_datadir}/%{name}
@@ -70,6 +70,10 @@ getent passwd checkdns >/dev/null || use
 %config(noreplace) %{_localstatedir}/www/html/%{name}/checkdns.css
 
 %changelog
+* Tue Feb 25 2014 Matthieu Saulnier <fantom@xxxxxxxxxxxxxxxxx> - 0.5-15
+- Add requirement on crontabs (Fix RHBZ #947058)
+- Fix modes of cron job file in %%install section
+
 * Sat Aug 03 2013 Fedora Release Engineering <rel-eng@
xxxxxxxxxxxxxxxxx> - 0.5-14
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass_Rebuild

Supprimer les tags obsolètes

Ce paquet est resté très longtemps sans maintenance, il contient pas mal de tags qui ont été rendu obsolètes par l'évolution de l'empaquetage Fedora. Le plus flagrant étant le tag BuildRoot qui n'est plus nécessaire depuis Fedora 10. Petite visite historique du paquet et nettoyage de fond en comble sont au programme.

  • Le tag Group était obligatoire, maintenant il ne l'est plus.
  • La racine de construction (BuildRoot) n'a plus besoin d'être nettoyée au début de la section %install.
  • La ligne %defattr indique les propriètaire et groupe par défaut (root:root), elle n'est donc plus nécéssaire depuis que ce standard est inclus automatiquement dans la partie %files.

Mais le ravallement de façade n'est pas tout à fait terminé...

--- checkdns.spec.orig  2014-02-25 02:02:19.251839258 +0100
+++ checkdns.spec       2014-02-25 02:07:40.471855789 +0100
@@ -3,13 +3,11 @@ Version:      0.5
 Release:       15%{?dist}
 Summary:       A Domain Name Server analysis and reporting tool
 
-Group:         Applications/Internet
 License:       GPLv2+
 URL:           http://www.enderunix.org/checkdns/
 Source0:       http://www.enderunix.org/checkdns/%{name}-%{version}.tar.gz
 Source1:       checkdns.cron
 Patch0:                checkdns-0.5.config_location.patch
-BuildRoot:     %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
 
 Requires:      httpd, bind, crontabs
 Requires(pre): shadow-utils
@@ -39,7 +37,6 @@ export CFLAGS
 make %{?_smp_mflags}
 
 %install
-rm -rf $RPM_BUILD_ROOT
 install -d $RPM_BUILD_ROOT/%{_sbindir}
 install -p checkdns $RPM_BUILD_ROOT/%{_sbindir}
 install -d $RPM_BUILD_ROOT/%{_sysconfdir}
@@ -51,8 +48,6 @@ install -p -m 0644 checkdns.css $RPM_BUI
 install -d $RPM_BUILD_ROOT/%{_datadir}/%{name}
 cp -rp lang $RPM_BUILD_ROOT/%{_datadir}/%{name}
 
-%clean
-rm -rf $RPM_BUILD_ROOT
 
 %pre
 getent passwd checkdns >/dev/null || useradd -d \
@@ -60,7 +55,6 @@ getent passwd checkdns >/dev/null || use
 :
 
 %files
-%defattr(-,root,root,-)
 %doc AUTHORS ChangeLog COPYING INSTALL LICENSE README THANKS TODO
 %config(noreplace) %{_sysconfdir}/checkdns.conf
 %config(noreplace) %{_sysconfdir}/cron.d/%{name}
@@ -73,6 +67,8 @@ getent passwd checkdns >/dev/null || use
 * Tue Feb 25 2014 Matthieu Saulnier <fantom@xxxxxxxxxxxxxxxxx> - 0.5-15
 - Add requirement on crontabs (Fix RHBZ #947058)
 - Fix modes of cron job file in %%install section
+- Remove obsoletes tags in spec file
+- Remove %%clean section in spec file

 * Sat Aug 03 2013 Fedora Release Engineering <rel-eng@
xxxxxxxxxxxxxxxxx> - 0.5-14
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass_Rebuild

Cleanup de la section %install

Pourquoi faire en deux commandes l'équivalent d'une seule commande ? La commande `install` permet de créer le répertoire parent et d'y placer un fichier en une seule passe, très utile lorsque le fichier doit être renommé. Par contre les répertoires sont ignorés, la commande `cp` devra être utilisée à la place.

--- checkdns.spec.orig  2014-02-25 02:37:57.972868958 +0100
+++ checkdns.spec       2014-02-25 03:27:48.157016352 +0100
@@ -37,14 +37,11 @@ export CFLAGS
 make %{?_smp_mflags}
 
 %install
-install -d $RPM_BUILD_ROOT/%{_sbindir}
-install -p checkdns $RPM_BUILD_ROOT/%{_sbindir}
+install -D -p %{name} $RPM_BUILD_ROOT/%{_sbindir}/%{name}
 install -d $RPM_BUILD_ROOT/%{_sysconfdir}
 sed -e '/html_output_dir/s@usr/local/apache/htdocs@var/www/html@' -e '/lang_file/s@local/@@' checkdns.conf-dist > $RPM_BUILD_ROOT/%{_sysconfdir}/checkdns.conf
-install -d $RPM_BUILD_ROOT/%{_sysconfdir}/cron.d
-install -p -m 0640 %{SOURCE1} $RPM_BUILD_ROOT/%{_sysconfdir}/cron.d/%{name}
-install -d $RPM_BUILD_ROOT/%{_localstatedir}/www/html/%{name}
-install -p -m 0644 checkdns.css $RPM_BUILD_ROOT/%{_localstatedir}/www/html/%{name}
+install -D -p -m 0640 %{SOURCE1} $RPM_BUILD_ROOT/%{_sysconfdir}/cron.d/%{name}
+install -D -p -m 0644 %{name}.css $RPM_BUILD_ROOT/%{_localstatedir}/www/html/%{name}/%{name}.css
 install -d $RPM_BUILD_ROOT/%{_datadir}/%{name}
 cp -rp lang $RPM_BUILD_ROOT/%{_datadir}/%{name}
 
@@ -69,6 +66,7 @@ getent passwd checkdns >/dev/null || use
 - Fix modes of cron job file in %%install section
 - Remove obsoletes tags in spec file
 - Remove %%clean section in spec file
+- Cleanup %%install section in spec file
 
 * Sat Aug 03 2013 Fedora Release Engineering <rel-eng@xxxxxxxxxxxxxxxx> - 0.5-14
 - Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass_Rebuild

Ajout de la Description en français

J'ai pour habitude de traduire la description de mes paquet en français, mais ça fera l'objet de la prochaine mise à jour.

Essais de construction

Avant de mettre en ligne les changements (commit + push), on peut toujours tester si le paquet se construit correctement. Certains packageurs utilisent Mock, personnellement mon mock est hors-service depuis un moment, du coup j'utilise Koji en remplacement. Pour celà il faut créer un SRPM depuis le contenu du dépôt Git, tout simplement avec la commande :

casper@blackbird:~/fedora-scm/checkdns$ fedpkg srpm

Puis lancer le build du SRPM sur l'infrastructure de construction de Fedora :

casper@blackbird:~/fedora-scm/checkdns$ koji --user=fantom build --scratch --nowait f21 /home/casper/fedora-scm/checkdns/checkdns-0.5-15.fc21.src.rpm

Si tous les tests passent, alors on peut commiter et pusher les changements, et bien sûr on construit le paquet pour les différentes branches de Fedora depuis le Git en ligne. Vu que les changements sont mineurs on va les appliquer jusqu'à la branche f19 (en partant de Rawhide). Pour commiter et pusher en une seule commande, il faut ajouter l'option -p :

casper@blackbird:~/fedora-scm/checkdns$ fedpkg commit -m "Fix RHBZ #947058" -p

Et enfin on builde pour la branche Rawhide.

Construction pour f20 et f19

Les modifications que nous venons de valider avec la construction du paquet Rawhide peuvent être appliquées aux autres branches sans risque. Dans notre dépôt local on change de branche :

$ fedpkg switch-branch f20

Puis on applique les changements automatiquement réalisés dans la branche master (la branche en perpétuel développement, assimilée à Rawhide) :

$ git merge master

Les changements sont appliqués seulement dans notre dépôt local, il convient de les pousser en ligne avant de pouvoir demander la construction du paquet à partir du dépôt Git :

$ fedpkg push

On peut désormais construire le paquet pour f20 :

$ fedpkg build --nowait

L'option --nowait est utile lorsqu'on travaille à la chaîne, en effet sans cette option la commande ne rend le prompt du terminal seulement à la fin de la construction du paquet. Du coup le terminal est monopolisé pour 5 à 10', mais avec cette option dès que la tâche est lancée sur Koji la commande rend automatiquement le prompt en 10". Lorsqu'il y a plusieurs branches à mettre à jour c'est une option qui permet vraiment de gagner du temps.

Création de l'update Bodhi

Dans le précédent billet nous avons utilisé la commande `fedpkg update` qui lance un editeur en mode console. Éditeur au choix défini par la variable d'environnement $EDITOR :

$ echo $EDITOR
emacs -nw

L'inconvénient de cette méthode est qu'il faut remplir à la main le petit formulaire, certes il n'y a que 2 ligne à compléter, mais bon... Pour changer nous allons le faire en une commande par branche (f20 et f19), ce qui est beaucoup plus rapide. Concrètement, avec la commande il faut marquer le paquet construit comme étant paquet de mise à jour pour le dépôt, cette commande peut être lancée n'importe où, pas besoin d'être dans le dépôt Git pour la lancer (à l'inverse de `fedpkg update`). En revanche, le fait de ne pas avoir le petit formulaire interractif nous oblige à fournir toutes les informations nécessaire du premier coup. Dans le cas de checkdns il faut spécifier le numéro du bug fixé par l'update (#947058), le type d'update (avancement, sécurité, bugfix), le commentaire décrivant l'update pour les testeurs, et bien sûr où le paquet doit aller avec cette marque (dépôt updates-testing).

casper@blackbird:~$ bodhi -u fantom -n -b 947058 -t bugfix -N "Fix RHBZ #947058" -R testing checkdns-0.5-15.fc20
Creating a new update for checkdns-0.5-15.fc20
Update successfully created
================================================================================
     checkdns-0.5-15.fc20
================================================================================
    Release: Fedora 20
     Status: pending
       Type: bugfix
      Karma: 0
    Request: testing
       Bugs: 947058 - Add a missing requirement on crontabs for the cron job to
           : the spec file
      Notes: Fix RHBZ #947058
  Submitter: fantom
  Submitted: 2014-02-25 03:20:43
   Comments: bodhi - 2014-02-25 03:21:00 (karma 0)
             This update has been submitted for testing by fantom.

  https://admin.fedoraproject.org/updates/checkdns-0.5-15.fc20


Pour f19 il suffit de remplacer fc20 par fc19, et le paquet correspondant sera aussi marqué. Attention, je tiens à rappeler que seuls les paquets construits depuis leurs dépôts à code source Git (donc avec la commande `fedpkg build` uniquement) peuvent être marqués en tant que mise à jour potentielle par Bodhi.

Page générée le 21 oct 2014 à 16:08