Fedora-Fr - Communauté francophone Fedora - Linux

Depuis un certain temps (mars 2009), je maintiens à titre totalement officieux un paquet RPM du serveur IIPImage dans mon dépôt personnel.

J'ai récemment décidé de l'intégrer dans les dépôts officiels, le but de mon dépôt n'étant pas de fournir des paquets sur le long terme, mais davantage de me servir d'incubateur en quelque sorte.... J'ai donc soumis une revue sur le Bugzilla.

Grâce aux conseils toujours très avisés de Remi sur cette revue, j'ai fait évoluer le paquet, apportant certaines modifications qui ne sont pas dénuées d'intérêt :

• le paquet ne dépend plus de apache HTTPD, ceux d'entre vous qui utilisent d'autres serveurs web peuvent donc installer le paquet sans dépendances disons... farfelues :)" class="smiley
• une unité Systemd qui permet d'exécuter le serveur seul, sur un port spécifié. Le service n'est disponible que sous Fedora 18 actuellement.

Les paquets nécessaires sont disponibles via mon dépôt pour les versions 17 et 18 de Fedora, ainsi pour les versions 5 et 6 de RedHat (et équivalents). Une fois la revue menée à bien, les paquets seront disponibles sur les dépôts officiels et seront supprimés de mon dépôt personnel.

Si vous souhaitez utiliser Apache HTTPD et mod_fcgid avec le serveur IIP, installez dans un premier temps les paquets adéquats :

$ su -lc 'yum --enablerepo=trashy install iipsrv-httpd-fcgi'

Vous trouverez dans le dossier /etc/httpd/conf.d un fichier nommé iipsrv.conf, dont vous pouvez vous inspirer pour votre configuration spécifique. C'est à peu près aussi simple que ça ; votre serveur IIP est désormais installé. Pour vérifier son fonctionnement de base, rendez vous à l'adresse http://localhost/iipsrv (ou celle que vous aurez configurée) ; vous devriez voir une simple page avec le nom du logiciel, sa version, un lien vers son site web et le nom de l'auteur.

Il semble qu'il ne soit actuellement pas possible de fournir de façon correcte des fichiers de configuration pour les autres serveurs, aussi, si vous souhaitez utiliser le serveur IIP avec un autre serveur web, ou directement en tant que service, installez uniquement le paquet iiprsv ;

$ su -lc 'yum --enablerepo=trashy install iipsrv'

Référez-vous ensuite à la documentation du serveur IIP ainsi qu'à celle de votre serveur web pour paramétrer tout ça correctement.

Si vous souhaitez utiliser le service, notez que l'adresse IP et le port sont configurables via un fichier actuellement disponible dans /etc/iipsrv/iipsrv.conf, dont le contenu est le suivant :

IP=127.0.0.1
PORT=9002

Une fois les valeur adaptées, lancez le serveur comme vous en avez l'habitude :

$ su -lc 'systemctl start iipsrv'

Votre serveur IIP est en route !

Vous pourrez tester ça avec Apache 2.4 et mod_proxy sous Fedora 18, par exemple. Ajoutez à votre configuration la ligne suivante (en adaptant l'hôte et le port si vous avez modifié la configuration par défaut) :

ProxyPass /iipsrv fcgi://127.0.0.1:9002/

Relancez Apache, et le tour est joué. L'adresse http://localhost/iipsrv devrait vous renvoyer la page par défaut.

Notez que par défaut, SELinux ne permettra pas à Apache de se connecter à un port qu'il ne connait pas. Pour y remédier, il vous suffira d'avoir recours aux bons et loyaux services de semanage :

$ su -lc 'semanage port -a -t http_port_t -p tcp 9002'

Notez enfin que ce paquet n'est peut-être pas actuellement dans sa version finale (tant que la revue n'est pas terminée), les modifications ultérieures ne devraient cependant pas avoir trop d'impacts (j'aimerai en être absolument certain, mais ma boule de cristal est malencontreusement tombée par terre récemment, et refuse catégoriquement de fonctionner :p).

N'hésitez pas à participer à la revue, ainsi qu'au projet IIPImage !

Les RPM de la nouvelle version du navigateur de la Mozilla Foundation sont disponibles dans le dépôt remi pour Fedora 15, 16 et Enterprise Linux 6 (RHEL, CentOS, ...).

A lire : Mozilla Firefox Release Notes (notes de version, en anglais) Installation : yum --enablerepo=remi update firefoxCe paquet utilise xulrunner-last, qui s'installe à côté de celui par défaut. Remarque : ce RPM est très proche de celui de Firefox 21 présent dans fedora 17/18/19. Attention : au premier lancement un dialogue en anglais... Lire Firefox 21

Bonjour cher lecteur,

Cette article concerne les packageurs, il a pour objectif d'introduire l' mise en place autour de ce thème.

Problématique

Ne trouvez vous pas que certaines étapes dans le processus de mises à jour des paquets pourrait être automatiser ? Il faut bien reconnaitre qu'il y a un certain nombre de tache commune et répétitives!

• récupération des sources si elles ne sont pas là
• récupérer la dernière révision lorsque l'on passe par un
• les mettres dans une archive .tar.xz
• faire un fedpkg switch-branch suivis d'un fedpkg pull afin d'etre à jour
• effectuer un bump de la release
• ajouter le changelog
• faire un build local
• si tout va bien ajouter les sources au repo fedora avec fedpkg new-sources
• puis faire une construction sur les serveurs fedora

Et enfin soumettre la mise à jour.

En plus certaines étapes sont à refaire pour chaque branche fedora ( f18, f19 … )

Refaites toutes ces étapes pour chaque paquets …

Afin de me faciliter la vie et passer moins de temps sur ce qui est automatisables j'ai conçu une API entièrement en bash pour cette problématique. L'API convient actuellement à mes paquets. J'estime qu'elle couvre par conséquent une bonne partie des paquets de chacun par rapport aux fonctionnalités déjà présente.

Utilisation

$ ./builder.sh -h
builder.sh [options]
    -h --help                                                 Display this message
    -v --verbose                                            Increase the verbosity
    -f --force                                                 Build rpm even package do not get an update
    -l --login                                                  Fas user name ( not used yet )
    -m --mail                                                 Mail to put into changelog
    -n --name                                               Real name to put into changelog
    -f --force <package name>                    Force to build the given package
    -b --branch <script name> <branch>    Specified for a script which branch to use (override branch list)
    --branchList <"branch1 branch2 …">     Global branch list to used

$ ./builder.sh -l bioinfornatics -m 'bioinfornatics at fedoraproject dot org' -n 'Jonathan MERCIER' --branchList 'f18 f19'

En une seule commande tous mes paquets ont récupérés la dernière version puis si besoin effectuer une construction locale. Si cette entière s'est terminé correctement une compilation sur les serveurs fedora est effectué.

Il est également possible de stocker certain nombre de paramètre dans un fichier de config afin de faciliter la réutilisation. Les chemins qui sont tenté dans l'ordre sont:

1. $HOME/.config/builder/config
2. /etc/builder/config

Les paramètres envoyé depuis la ligne de commande écraseront ceux définis dans le fichier de config

Exemple:

[GLOBAL]
name=<real name>
login=<login>
mail=<mail>
branchList=f18 f19
[BRANCH]
ldc=f19
derelict=f18

Principe

Le principe est simple « mettre dans un script bash toutes les commandes que vous réaliser habituellement »

Exemple simple pour le paquet earth-and-moon-backgrounds

#!/usr/bin/env bash
# earth-and-moon-backgrounds
. "$(dirname $0)"/common.sh
declare originalDir sourceFile
 
init 'earth-and-moon-backgrounds'
 
for sourceFile in "${sourcesFiles}"; do
    if [[ ! -f "${sourceFile}" ]] ; then
        curl -s -o "${sourceFile}" http://bioinfornatics.fedorapeople.org/$(basename "${sourceFile}")
    fi
done
 
localBuild
 
remoteBuild

• On charge la bibliothèque de fonction common.sh
• Déclaration des variables bash qui vont être utilisé ( c'est plus propres :-)" class="smiley )
• La fonction init va :
  • Récupérer le dépôt fedora du paquet earth-and-moon-backgrounds si besoin
  • Se mettre dans une branche (f18, f19 …)
  • Récupérer la dernière version de cette dernière
  • Enregistrer dans un tableau sourcesFiles les fichiers sources listé dans le fichier spec
• Pour chacune des sources. Téléchargement de ces dernières si elles sons pas présentes
• Construction du paquet sur la machine local via localBuild
• Si la construction locale du rpm est effectué avec sucés alors la fonction remoteBuild demandera une construction sur les serveurs de fedora

Exemple pour le paquet gtkd

#!/usr/bin/env bash
# gtkd
. "$(dirname $0)"/common.sh
 
declare gtkd_revision alphatag
 
init 'gtkd'
gitGetRepo 'git://github.com/gtkd-developers/GtkD.git'
gitExtractSnapDate
gitExtractRev
gtkd_revision="${revision}"
alphatag="${snapdate}"git"${gtkd_revision}"
 
gitArchive "${package_name}-${alphatag}" "${package_name}-${alphatag}" "${SOURCES}"
 
udpateSpec "Update to rev ${gtkd_revision}"    \
            '%global[[:blank:]]*snapdate[[:blank:]]*(.*)'       "${snapdate}"       \
            '%global[[:blank:]]*gtkd_revision[[:blank:]]*(.*)'  "${gtkd_revision}"
localBuild
 
remoteBuild "Updating to rev ${gtkd_revision}"

• On charge la bibliothèque de fonction common.sh
• Déclaration des variables bash qui vont être utilisé ( c'est plus propres :-)" class="smiley )
• La fonction init va :
  • Récupérer le dépot fedora du paquet gtkd si besoin
  • Se mettre dans une branche
  • Récupérer la dernière version
  • Enregistrer dans un tableau sourcesFileds les fichiers sources listé dans le fichier spec
• gitGetRepo va récupérer le dépôt gtkd s'il n'existe pas puis récupérer les dernières mise à jour
• gitExtractSnapDate récupère la date du dernier comit et la stock dans la variable snapdate
• gitGetRepo va récupérer le dépot gtkd s'il n'existe pas puis récupérer les dernières mise à jour
• gitExtractRevo va récupérer la révision du projet et stock dans la variable revision
• gitArchive créer une archive .tar.xz
  • paramètre n°1 correspond au chemin à partir duquel on archive ( afin de gérer les sous modules git )
  • paramètre n°2 correspond au nom de l'archive
• udpateSpec va bumper le spec avec le commentaire donné en premier argument si besoin
  • les autres paramètres sont des règles accompagné de la valeur de remplacement si la règle est vrai (Exemple: ' %global snapdate 20130510' -> ' %global snapdate 20130516' )
• Construction du paquet sur la machine local via localBuild si besoin
• Si la construction locale du rpm est effectué avec succès alors la fonction remoteBuild demandera une construction sur les serveurs de fedora si besoin

Les logs du workflow sont mis dans $HOME/rpmbuild/LOG/ afin de consulter le déroulement de ce dernier.

Les scripts quant a eux sont placé dans $HOME/rpmbuild/SCRIPT.

Les sources sont accessible ici: https://github.com/bioinfornatics/package_workfow

Il vous reste plus qu'a lancer un fedpkg update :-)" class="smiley

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

Lire l'annonce de version : PHP 5.4.15 and PHP 5.3.25 released! Utilisez YUM pour les installer : yum --enablerepo=remi update php-\* Cette version sera aussi prochainement dans les mises à jour officielles pour : Fedora 18 Fedora 17 Pour Fedora 19, ce sera PHP 5.5 Pour toute question ou demande d'aide, merci d'utiliser les Forums.... Lire php-5.4.15

Avec l'arrivée imminante de php 5.5, version qui verra disparaitre la librairie php-mysql, il est grand temps d'entamer une migration vers mysqlnd. Voici donc le mode opératoire pour effectuer ce changement en utilisant yum shell & le dépôt remi sur ma RHEL6.

Pourquoi yum shell ? Car il n'est pas possible de passer par un simple yum install :

root@kalach ~> yum install php-mysqlnd
Loaded plugins: changelog, downloadonly, presto, product-id, rhnplugin
This system is receiving updates from RHN Classic or RHN Satellite.
Setting up Install Process
Resolving Dependencies
--> Running transaction check
---> Package php-mysqlnd.x86_64 0:5.4.14-1.el6.remi will be installed
--> Processing Conflict: php-mysql-5.4.14-1.el6.remi.x86_64 conflicts php-mysqlnd
--> Finished Dependency Resolution
Error: php-mysql conflicts with php-mysqlnd-5.4.14-1.el6.remi.x86_64
 You could try using --skip-broken to work around the problem
 You could try running: rpm -Va --nofiles --nodigest

En effet php-mysqlnd et php-mysql rentrent en conflit...

Alors essayons de désinstaller php-mysql :

root@kalach ~> yum remove php-mysql
Loaded plugins: changelog, downloadonly, presto, product-id, rhnplugin
This system is receiving updates from RHN Classic or RHN Satellite.
Setting up Remove Process
Resolving Dependencies
--> Running transaction check
---> Package php-mysql.x86_64 0:5.4.14-1.el6.remi will be erased
--> Processing Dependency: php-mysql for package: php-pluf-1.0-3.gitb1fed2e.el6.remi.noarch
--> Processing Dependency: php-mysql for package: phpMyAdmin-3.5.8.1-1.el6.remi.noarch
--> Processing Dependency: php-mysql for package: cacti-0.8.8a-2.el6.noarch
--> Running transaction check
---> Package cacti.noarch 0:0.8.8a-2.el6 will be erased
---> Package php-pluf.noarch 0:1.0-3.gitb1fed2e.el6.remi will be erased
--> Processing Dependency: php-pluf >= 1.0-3 for package: indefero-1.3.3-1.el6.noarch
---> Package phpMyAdmin.noarch 0:3.5.8.1-1.el6.remi will be erased
--> Running transaction check
---> Package indefero.noarch 0:1.3.3-1.el6 will be erased
--> Finished Dependency Resolution
 
Dependencies Resolved
 
=======================================================================================================
 Package         Arch        Version                          Repository                          Size
=======================================================================================================
Removing:
 php-mysql       x86_64      5.4.14-1.el6.remi                @remi                              449 k
Removing for dependencies:
 cacti           noarch      0.8.8a-2.el6                     @epel                              5.4 M
 indefero        noarch      1.3.3-1.el6                      @/indefero-1.3.3-1.el6.noarch      3.4 M
 php-pluf        noarch      1.0-3.gitb1fed2e.el6.remi        @remi                              1.2 M
 phpMyAdmin      noarch      3.5.8.1-1.el6.remi               @remi                               22 M
 
Transaction Summary
=======================================================================================================
Remove        5 Package(s)
 
Installed size: 33 M
Is this ok [y/N]:

Trop de dépendances !

La solution : yum shell :

root@kalach ~> yum shell                                     13:37
Loaded plugins: changelog, downloadonly, presto, product-id, rhnplugin
This system is receiving updates from RHN Classic or RHN Satellite.
Setting up Yum Shell
> install php-mysqlnd
Setting up Install Process
> remove php-mysql
Setting up Remove Process
> run
--> Running transaction check
---> Package php-mysql.x86_64 0:5.4.14-1.el6.remi will be erased
---> Package php-mysqlnd.x86_64 0:5.4.14-1.el6.remi will be installed
--> Finished Dependency Resolution

================================================================================
 Package            Arch          Version                    Repository    Size
================================================================================
Installing:
 php-mysqlnd        x86_64        5.4.14-1.el6.remi          remi         260 k
Removing:
 php-mysql          x86_64        5.4.14-1.el6.remi          @remi        449 k

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

Total download size: 260 k
Is this ok [y/N]: y
Downloading Packages:
Setting up and reading Presto delta metadata
Processing delta metadata
Package(s) data still to download: 260 k
php-mysqlnd-5.4.14-1.el6.remi.x86_64.rpm                 | 260 kB     00:00     
Running rpm_check_debug
Running Transaction Test
Transaction Test Succeeded
Running Transaction
  Installing : php-mysqlnd-5.4.14-1.el6.remi.x86_64                         1/2 
  Erasing    : php-mysql-5.4.14-1.el6.remi.x86_64                           2/2 
  Verifying  : php-mysqlnd-5.4.14-1.el6.remi.x86_64                                                                                                                                                         1/2 
  Verifying  : php-mysql-5.4.14-1.el6.remi.x86_64                                                                                                                                                           2/2 

Removed:
  php-mysql.x86_64 0:5.4.14-1.el6.remi                                                                                                                                                                          

Installed:
  php-mysqlnd.x86_64 0:5.4.14-1.el6.remi                                                                                                                                                                        

Finished Transaction
> exit
Leaving Shell

Et voila, bien sûr on peut utiliser yum shell pour d'autres opérations.

Je viens de profiter des vacances pour mettre à jour mon portable sous Fedora 19, actuellement en version alpha. Jusqu'à présent, j'utilisais preupgrade, mais comme fedup deviendra bientôt la solution officielle, j'ai voulu tenter le coup.

preupgrade proposait une interface graphique qui permettait rapidement de passer à la version n+1. fedup, passe par un client en ligne de commande. Certes, c'est plus ardu mais ça permet de mettre à jour une Fedora sans interface graphique. Malheureusement, le passage par anaconda oblige toujours de devoir avoir un accès physique sur la bécane ou à minima un KVM Over IP.

Si vous aussi vous voulez tâter de l'alpha :

fedup-cli --disablerepo remi --disablerepo fedora-chromium-stable --disablerepo Dropbox --disablerepo google-musicmanager --disablerepo llaumgui --network 19 --debuglog fedupdebug.log --instrepo http://dl.fedoraproject.org/pub/fedora/linux/releases/test/19-Alpha/Fedora/x86_64/os/

Salut.

C'est encore avec beaucoup de retard, après une fin d'année 2012 très compliquée pour moi, que je vous livre ces dernières mesures...

Voici les résultats comparatifs de Fedora 18 vs Fedora 17.

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

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

Mon protocole de tests est le suivant :

• Installation de Fedora 18 version 32 bits avec le noyau Fedora 3.6.10-4.fc18.i686.PAE.
• La machine est placée en niveau 3 (init 3).
• 10 séries de tests avec UnixBench compilé sous Fedora 18 et exécuté sous Fedora 18 (noyau Fedora 3.6.10-4.fc18.i686.PAE).
• 10 séries de tests avec UnixBench compilé sous Fedora 17 et exécuté sous Fedora 17 (noyau Fedora 3.3.4-5.fc17.i686).

Voici les résultats obtenus :

Fedora 18 version 32 bits :

Série 1 : 755.2
Série 2 : 747.9
Série 3 : 757.8
Série 4 : 771.8
Série 5 : 764.7
Série 6 : 759.2
Série 7 : 764.8
Série 8 : 759.0
Série 9 : 766.7
Série 10 : 748.7

Moyenne : 759.6

Fedora 17 version 32 bits :

Voici pour rappel les résultats obtenus avec Fedora 17 :
Série 1 : 720.6
Série 2 : 720.1
Série 3 : 717.1
Série 4 : 728.1
Série 5 : 735.0
Série 6 : 736.3
Série 7 : 727.2
Série 8 : 719.6
Série 9 : 738.5
Série 10 : 719.7

Moyenne : 726.2

Résultats :

Pour Fedora 18, on obtient un indice moyen de 759.6 pour UnixBench.
Pour Fedora 17, j'avais obtenu un indice moyen de 726.2 pour UnixBench.


On a donc un gain moyen de près de 4.6 % de Fedora 18 32 bits par rapport à Fedora 17 32 bits...
On assiste encore une fois à une légère amélioration des performances avec cette nouvelle version de Fedora comme montré sur la figure suivante :

Conclusion :

Au moment de ces tests, le noyau Fedora 18 (basé sur le noyau vanilla 3.6.10) propose un gain de 4.6 % par rapport au noyau Fedora 17 (basé sur le noyau vanilla 3.3.4), ce qui le ramène au niveau de Fedora 7 (soit au début de mes tests !).


++

Les RPM pour installer la nouvelle version majeure de phpMyAdmin sont disponibles dans le dépôt remi pour fedora et enterprise linux (RHEL, CentOS, ...).

Site officiel : http://www.phpmyadmin.net/ Je ne sais pas encore si cette nouvelle version majeure sera aussi disponible dans les mises à jour officielles de fedora ou de EPEL-6. Donc il est disponible pour fedora 13 à 19 et enterprise linux 5 à 6 (à condition d'utiliser une version de php suffisante, aussi disponible dans le dépôt). Comme... Lire phpMyAdmin version 4.0

Date : samedi 4 mai 2013 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 4 mai 2013 au Carrefour Numérique de la Cité des Sciences [...]

Combien de fois vous a-t-on demandé ce que vous avez fait la semaine passée ??? Combien de fois la réponse a été : "Euh, et bien ... trou de mémoire ... :D" La solution peut se trouver grâce à Hamster, c'est une simple interface qui permet de suivre le temps passé sur des tâches. Simple rapide et efficace !

Au passage, il existe également une extension GNOME : https://extensions.gnome.org/extension/425/project-hamster-extension/

Bref l'essayer c'est l'adopter !

Installation en ligne de commande : yum install hamster

Installation avec l'interface graphique : Bureau GNOME > Time tracking applet

Localisation dans le menu : Accessoires

Lancement en ligne de commande : /usr/bin/hamster-time-tracker

Site web : http://projecthamster.wordpress.com/

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

Lire l'annonce de version : PHP 5.4.14 and PHP 5.3.24 released! Utilisez YUM pour les installer : yum --enablerepo=remi update php-\* Cette version sera aussi prochainement dans les mises à jour officielles pour : Fedora 18 Fedora 17 Pour Fedora 19, ce sera PHP 5.5 Pour toute question ou demande d'aide, merci d'utiliser les Forums.... Lire php-5.4.14

Les RPM de la nouvelle version du navigateur de la Mozilla Foundation sont disponibles dans le dépôt remi pour Fedora 15, 16 et Enterprise Linux 6 (RHEL, CentOS, ...).

A lire : Mozilla Firefox Release Notes (notes de version, en anglais) Installation : yum --enablerepo=remi update firefoxCe paquet utilise désormais xulrunner-last, qui s'installe à côté de celui par défaut. Remarque : ce RPM est très proche de celui de firefox 20 présent dans fedora 17/18/19. Les RPM sont disponibles pour Fedora 14 (x86_64),... Lire Firefox 20

APCu, la reprise du code d'APC, nettoyé du cache d'opcode, fournissant une API stable et connu pour le cache des données utilisateur est publiée en version 4.0.0. Les RPM sont disponibles dans le dépôt remi pour Fedora et Enterprise Linux.

Voir le billet : PHP : caches d'opcode et de données Donc je recommande à tous les utilisateurs d'APC de tester cette nouvelle extension qui doit la remplacer de manière transparent pour les applications. Pour les utilisateurs de PHP 5.4 yum remove php-pecl-apcyum --enablerepo=remi install php-pecl-zendopcache php-pecl-apcuPour les utilisateurs... Lire php-pecl-apcu-4.0.0

Ce logiciel est un équivalent à Rasterbator.

Si vous avez un mur à tapisser de posters, PosteRazor peut vous être utile. Ce logiciel vous permet de créer très facilement un poster à partir d'une photo, si possible de grande taille, dont vous n'aurez plus qu'à recoller les morceaux. Linterface de PosteRazor vous guide à travers plusieurs étapes, notamment pour vous aider à régler les marges ou la surface commune à deux parties du poster, ce qui vous permet d'obtenir une surface nécessaire au collage de deux parties.

La taille du poster peut être définie en centimètres, en pourcentage ou en nombre de pages et un aperçu en temps réel du résultat est disponible, les bandes rouges représentant les parties de chaque feuille qui se superposent. Une fois les réglages acceptés, le logiciel crée un fichier PDF contenant toutes les pages du poster que vous n'avez plus qu'à imprimer.

Installation en ligne de commande : yum install posterazor

Installation avec l'interface graphique : Autres > Make your own poster

Localisation dans le menu : Applications > Graphisme

Lancement en ligne de commande : /usr/bin/posterazor

Site web : http://posterazor.sourceforge.net/

La société Zend (The PHP Company) vient de libérer son cache d'opcode, Zend OPcache est donc dès maintenant disponible dans le dépôt remi pour Fedora et Enterprise Linux (RHEL, CentOS, ...)

On peut dire qu'il s'agit d'une excellente nouvelle. Ce cache est intégré dans PHP 5.5.0beta1. Pour l'installer yum remove php-pecl-apc php-xcache php-eacceleratoryum --enablerepo=remi install php-pecl-zendopcacheservice httpd restartPour les utilisateurs de PHP 5.5.0 (remi-test). yum install php-opcacheN'hésitez pas à le tester. Il manque un... Lire php-pecl-zendopcache-7.0.1

Une description des solutions existantes et de l'avenir des caches pour l'opcode des scripts PHP et pour les caches des données utilisateur.

1. Cache d'opcode. Il est particulièrement utile, voir indispensable, de disposer d'un cache d'opcode sur un site à fort trafic, ce mécanisme permet de gagner l'étape d'analyse du code lors du chargement d'un script en utilisant le résultat stocké en cache. On gagne généralement jusqu'à 80% du temps d'exécution. 1.1. eAccelerator Site :... Lire PHP : cache d'opcode et de données

La version 5.5.0beta1 étant publiée, je commence à travailler sur les RPM.

Actuellement les RPM sont disponible pour fedora ≥ 17 et Enterprise Linux ≥ 5 (RHEL, CentOS, ...), dans le dépot remi-test. Ce sera aussi une nouveauté de Fedora 19. Version actuelle : 201303201430 (beta1) Extensions disponibles (28) : php-magickwand-1.0.9 php-pecl-amqp-1.0.9 php-pecl-apc-3.1.15dev (uniquement pour le cache des données... Lire PHP 5.5.0 en préparation

SysBench est un outil de test modulaire, multi-plateforme et multi-threadé permettant d'évaluer les informations et paramètres lors d'une forte sollicitation d'une base de données.

L'idée de cet suite de tests de performances et d'avoir très rapidement un retour concernant l'état d'un système de base de données sans devoir configurer un ensemble de données ou de répertorier des requêtes multiples et complexes.
Voici les principales fonctionnalités permettant de remonter les informations suivantes :
* performance des E/S des fichiers
* performance de lordonnanceur
* allocation mémoire et vitesse de transfert
* performance POSIX threads
* performance de bases de données (OLTP benchmark)

Initialement écris pour MySQL, Sysbench a évolué afin de supporter de multiples moteurs de données.

Exemple de commande de préparation :
$ sysbench --test=oltp --db-driver=mysql --mysql-user=user --mysql-password=password --mysql-db=sysbench_table_for_test --mysql-host=host --mysql-table-engine=innodb prepare

Exemple de commande dexécution :
$ sysbench --test=oltp --db-driver=mysql --num-threads=1 --mysql-host=host --mysql-user=user --mysql-password=password --mysql-db=sysbench_table_for_test --max-time=60 --max-requests=0 --oltp-read-only=off run

Je vous laisse faire le tour de cet outil bien pratique et n'hésitez pas à en discuter dans les commentaires ;)" class="smiley !

Installation en ligne de commande : yum install sysbench

Installation avec l'interface graphique : Autres > System performance benchmark

Localisation dans le menu : Non présent

Lancement en ligne de commande : /usr/bin/sysbench

Site web : http://sysbench.sourceforge.net/