J'ai dernièrement profité de mes temps libres pour développer un module pour le client de messagerie Mozilla Thunderbird,  j'ai nommé celui-ci Scan'Mail. Il permet d'un simple clique droit sur une adresse email, un lien, une image ou une sélection de texte de générer un QR code que vous pourrez scanner à l'aide de votre smartphone (iPhone, Android ou autre) pour récupérer ses informations. C'est un moyen rapide et original de copier des données contenues dans vos emails sans risquer une erreur de retranscription.

J'ai pris beaucoup de plaisir à coder ce petit greffon même si j'ai trouvé la documentation en ligne peu conviviale et parfois incomplète. Je compte améliorer ce premier plugin en ajoutant, dans la prochaine version, le support du format vCard pour pouvoir transférer des contacts.

Je invite à télécharger Scan'Mail via son espace dédié sur le site de Thunderbird et à me laisser vos commentaires :

https://addons.mozilla.org/fr/thunderbird/addon/scanmail/

Me voilà donc de retour d'un voyage professionnel en Afrique du sud. Que dire de ce pays si ce n'est que je l'ai adoré. Temps radieux, paysages merveilleux, population accueillante... Tout ce qu'il faut pour passer un bon séjour, à noter toutefois, quelques problèmes d'insécurité.

Bref, ce retour annonce aussi la publication très rapidement de nouveaux billets.

Le PHP est un langage compilé à la volée, à chaque appel d'une page il y a compilation du code PHP en un code intermédiaire que l'on nomme opcode. Ce mécanisme de compilation systématique est lourd et rallonge sensiblement la durée de traitement des pages PHP.

APC (Alternative PHP Cache) est ce qu'on appèle  un cache d'OPCodes. Celui-ci permet donc de stocker en mémoire vive le code compilé des pages PHP et nous épargne ainsi la fastidieuse phase de compilation, les performances générales se retrouvent de ce fait nettement améliorées.

En plus d'être une solution fiable et robuste, APC est gratuit, opensource et relativement simple à installer et à utiliser. Alors pourquoi s'en priver ?

Tout d'abord commençons par préparer l'environnement :

# Installation des paquets nécessaires à la compilation d'APC
sudo apt-get install php5-dev php-pear apache2-prefork-dev
 
# Création d'un lien symbolique pour éviter un message d'erreur sur certains environnements
sudo ln -s /usr/bin/apxs2 /usr/bin/apxs

Maintenant que nous avons l'ensemble des paquets requis, procédons à l'installation d'APC :

sudo pecl install apc
# Répondez 'yes' à la question qui vous sera posée

Maintenant créons le fichier de configuration d'APC :

sudo nano /etc/php5/apache2/config.d/apc.ini

Et mettez y ceci :

[APC]
 
# Permet de charger le module APC
extension=apc.so
 
# Permet d'activer le module APC
apc.enabled=1 
 
# Taille de l'espace mémoire alloué à APC (en Mo)
apc.shm_size=30 
 
# Taille maximale des fichiers mis en cache
apc.max_file_size=1M 
 
# Vérification des modifications de fichiers
apc.stat=0

Il est important de s'attarder un peu sur l'option apc.stat. Si sa valeur est à 1, APC vérifiera à chaque appel d'une page si celle-ci a été modifiée depuis sa mise en cache, ces vérifications systématiques affaiblissent les performances. Sur un serveur de production sur lequel les fichiers sont modifiés rarement, il est préférable de désactiver cette option pour gagner en performances. Dès lors, si un fichier est modifié il faudra vider le cache pour que les modifications soient prises en compte.

Vous pouvez trouver la description complète des options disponibles sur cette page.

Il reste maintenant à redémarrer Apache pour achever l'installation d'APC.

sudo /etc/init.d/apache2 restart

Une fois APC installé, son cache se remplira au fur et à mesure des chargements des pages PHP améliorant ainsi progressivement les performances générales.

Il est possible d'obtenir des informations sur l'état de ce cache via une page web spéciale. Celle-ci n'est pas déployée par défaut sur votre serveur, pour se faire il suffit de la rendre accessible depuis le répertoire de votre serveur web :

# Le répertoire de destination peut différer selon la configuration de votre serveur web
sudo cp /usr/share/php/apc.php /var/www/apc.php

Finissons ce billet avec un petit benchmark histoire d'avoir un aperçu du gain réel apporté par l'utilisation d'APC. Sur la même machine je vais tester, à l'aide de l'utilitaire ab fourni avec apache, les performances d'accès à la page d'accueil d'un site sous Joomla sans puis avec APC d'activé.

# Je simule dix utilisateurs qui effectuent dix requêtes chacun
ab -n 10 -c 10 http://127.0.0.1/joomla/

Le résultat obtenu avant l'activation d'APC :

Sans APC il est possible de traiter près de 14 requêtes par seconde.

Le résultat obtenu après l'activation d'APC et le chargement de la page dans le cache :

Avec APC activé (avec la page mise en cache ce qui implique une première visite de celle-ci), il devient possible de traiter près de 31 requêtes par seconde soit un gain de performance de facteur deux.

Vous l'aurez compris, APC apporte une véritable amélioration des performances tout en restant simple à déployer. De plus, il offre aussi une fonctionnalité de cache utilisateur que je n'ai pas traité dans ce billet.

Lorsqu'on est administrateur systèmes et réseaux spécialisé dans le logiciel libre, on bosse la majorité du temps sur des serveurs GNU/Linux ou BSD, ce qui implique une utilisation privilégiée de la console ainsi que du protocole SSH pour les accès distants.

L'un des risques que l'ont encoure est de perdre cet accès SSH suite à une fausse manipulation, plus particulièrement lors de l'ajout d'une règle de firewall.

Personnellement, je travaille essentiellement sur des serveurs localisés en Afrique du sud, une telle erreur serait donc dramatique car je perdrais mon unique voie d'accès. Pour éviter de me retrouver dans une telle situation, j'ai codé en Bash une petite commande pour adapter à iptables le mécanisme de confirmation qui existe sur Shorewall.

#!/bin/sh
 
# Safe-iptables
# Author  : Nassim Kacha
# License : GNU GPL2
# Date    : 30/08/2010
 
# Exit codes
#
# O Normal execution
# 1 Can't save previous firewalling rules
# 2 Bad arguments
# 3 Missing root privileges
# 4 Changements aborted by user
 
TIME=5 # Can be customized
 
if [ -z $TMPDIR]; then
     TMPDIR='/tmp'
fi
 
TMPFILE=`/usr/bin/mktemp --tmpdir=$TMPDIR iptables_XXXXX`
 
privilege_checking() {
	if [ $(id -u) -ne 0 ]; then
		echo "Sorry, you must run the command as root !"
		exit 3
	fi
}
 
main() {
	read -n 1 -t $TIME -p "Are you sure ? [y/N]" key
	case "$key" in
  		y|Y )
				/bin/rm -f $TMPFILE
				echo -e "n+ Rule applied"
				exit 0;;
 
		n|N|'' )
				/usr/sbin/iptables-restore > $TMPFILE
				/bin/rm -f $TMPFILE
				echo -e "n- Rule not applied"
			  	exit 4;;
 
		* ) 	echo ''
				main;;
	esac
}
 
### Main ###
privilege_checking
/usr/sbin/iptables-save > $TMPFILE
if [ $? -ne 0 ]; then
	echo "Error : not possible to save the previous firewall rules"
	exit 1
fi
/usr/sbin/iptables $*
if [ $? -eq 0 ]; then
	main
fi
exit 2

Cette commande fonctionne exactement de la même manière que la commande iptables à ceci près qu'elle vous demande une confirmation après avoir appliqué la nouvelle règle de pare-feu. Ainsi, si votre règle est mauvaise et qu'elle vous coupe votre liaison SSH, elle sera annulée après cinq seconde faute d'avoir pu confirmer la commande. Cela apporte donc une sécurité non négligeable lors de l'édition de vos règles de firewalling.

Je vous recommande d'enregistrer le code ci-dessus sous un fichier /usr/sbin/safe-iptables, de l'attribuer à l'utilisateur root et de lui donner les permissions 755. Il est aussi  judicieux d'insérer un alias dans votre fichier .bashrc qui remplacerait la commande iptables par safe-iptables.

Je compte packager ce script en DEB et en RPM dès que possible. Pour finir, je vous encourage à reprendre et à améliorer ce script si vous avez des idées supplémentaires.

EDIT 04/09/2010 : Modification du script suite aux excellentes remarques de TixxDZ.

Ce billet inaugure une toute nouvelle rubrique baptisée : Sysadmin's  friends (en français : les amis de l'admin sys). Non...non... mon intention n'est pas de vous présenter un pote à moi chaque semaine, il n'y aurait pas de quoi tenir un mois, nooooon je déconne !

Plus sérieusement, l'idée est donc de vous présenter régulièrement un petit outil qui apporte énormément au quotidien d'un administrateur système et réseau.

Pour cette première, j'ai choisi de vous présenter screen, un multiplexeur de terminaux en mode texte (réflexion personnelle :  voilà, j'ai largué la moitié de mon audiance rien qu'avec cette phrase).  Pour faire plus simple, screen permet  en quelque sorte d'avoir plusieurs terminaux dans une seule fenêtre.

Trêve de bavardages, passons aux choses pratiques :

# Installation de screen sous Debian/Ubuntu
aptitude install screen
 
# Installation de screen sous CentOS/Fedora/RHEL
yum install screen
 
# Installation de screen sous Archlinux
pacman -S screen

Lesson number one :

Pour lancer screen depuis votre terminal, il suffit de taper

screen

(ouahhh comment il est fort lui !).

Lesson number two :

Pour afficher le numéro de fenêtre (de terminal, de shell) sur lequel nous sommes, il suffit de presser CTRL+A puis W. Vous verrez normalement s'afficher dans le coin inférieur gauche de votre terminal la mention suivante : 0*$ bash. Le nombre zéro suivi d'une étoile signifie que nous sommes sur la première session (ou premier terminal).

Lesson number three :

Avant d'aller plus loin, lançons la commande top qui affiche des statistiques systèmes. Maintenant, faites CTRL+A puis C, vous devriez vous retrouvez à nouveau avec un terminal vide. Faites CTRL+A puis W, que remarquez vous ? Oui oui, c'est bien cela, vous êtes passés à une seconde session.

Lesson number four :

Maintenant je pense que vous aimeriez bien savoir comment retourner à votre session précédente non ? Et bien diverses possibilités s'offrent à vous.

CTRL+A puis P : Permet de passer à la session précédente.

CTRL+A puis N : Permet de passer à la session suivante.

CTRL+A puis n : n étant numéro de session que l'on désire atteindre.

Lesson number five :

Bon là, je vous vois dubitatif compte à l'intérêt de cette commande étant donné que les onglets existent déjà sur le shell de votre Gnome ou de votre KDE.

C'est là qu'intervient cette avant dernière leçon ! Quand vous utilisez le terminal de KDE ou de Gnome avec différents onglets, si vous fermez votre terminal et bien vous perdez logiquement l'ensemble de vos onglets... et inévitablement les commandes qui étaient lancées sont interrompues.

Et bien... petite démo !

Positionnez-vous sur la première session où la commande top a été lancée : CTRL+A puis 0 (c'est un zéro et non la lettre o de l'alphabet). Puis faites, CTRL+A puis D. Oupsss ! Tout a disparu ! C'est normal ne paniquez pas ! Maintenant, fermez complètement votre fenêtre de terminal (si vous êtes en environnement graphique bien entendu).

Re-ouvrez une fenêtre terminal et tapez : screen -r. Et là comme par miracle, vous vous retrouvez sur votre première session avec la commande top qui tourne toujours. Grâce à cette spécificité, vous pouvez utiliser screen lors d'une connexion SSH pour pouvoir lancer une commande sur une machine distante puis vous en déconnecter tout en laissant la commande continuer son exécution, il vous sera même possible de vous reconnecter par la suite en SSH et de reprendre votre session pour vérifier l'état d'exécution de la commande précédemment lancée.

Lesson number six :

Une dernière petite leçon en guise de "pompon sur la gâteau", en effet, je ne pouvais pas clore cet article sans parler du partage de session via SSH à l'aide de screen.

# Admettons que titi veut partager l'écran de sa machine avec toto qui possède un accès SSH sur celle-ci.
 
# Sur la machine de titi
screen -S nom_de_session
 
# Faites CTRL+A puis
:multiuser on
 
# Faites CTRL+A puis
:acladd toto
 
# Depuis la machine de toto :
ssh toto@ip_machine_titi
screen -x titi/nom_de_session

Voilà, maintenant vous savez comment partager vos sessions entre deux machines via SSH. A très bientôt les zouzous !