on commence par la locale :
taper :

dpkg-reconfigure locales

choisir la bonne langue/locale et valider, comme ici :

faire de même à l'ecran suivant :

en suite on passe a l'heure, c'est très simple
on tape :

dpkg-reconfigure tzdata

et là on va avoir un écran où il faudra sélectionner "Europe" puis valider, en suite sélectionner "Paris" puis valider et c'est ok, l'heure est automatiquement régler avec le bon fuseau horaire, pas besoin de régler l'heure a la main puisque ntpdate s'occupe de la garder à jour.

N.B. Tous se fait sous root.

Aujourd'hui on va voir comment installer et configurer l'outil de monitoring munin

Un petit article aide mémoire comme beaucoup d'autres sur ce blog :)

pour commencer :

apt-get install munin munin-node

en suite il faut éditer le fichier de configuration : /etc/munin/munin.conf

changer juste la valeur de htmldir pour choisir un répertoire où les fichiers html des rapports seront déposés, pour moi c'est sous un vhosts de statistiques, exemple :

htmldir	/var/www/munin

vous pouvez aussi laisser la valeur par défaut.

un autre fichier de configuration pourrait vous intéresser, personnellement je n'ai pas eu a le toucher : /etc/munin/munin-node.conf

Important : Assurez vous que le répertoire "htmldir" choisi plus haut soit accessible en écriture a l'utilisateur munin (sinon le cron vous bombarde de mails pas cool), moi j'ai fait un :

chown -R munin:www-data MON/HTML/DIR/DE/MUNIN

maintenant on restart tout ça :

/etc/init.d/munin-node restart

quelques minutes après (le temps de générer quelques stats) on va a l'url correspondant au htmldir et on admire les garphs :)

d'après ce qu'on peut lire un peu partout sur le net, Lighttpd (lighty pour les intimes) est beaucoup plus performant quand il s'agit de servir des pages statiques, mais qu'en est-il vraiment ? et comment s'en sort-il avec le contenu dynamique ? (des sites statiques ça n'existe plus de nos jours ^^).

pour notre test, on va prendre un site très léger, basé sur Zend framework (donc loin d'être statique), contenant une page qui affiche 9 images au hasard a partir d'une tables mysql contenant environ 1000 enregistrements (seulement les emplacement des images sont stockés dans la base). Le serveur de test est un kimsufi L (petit processeur et 1Go de RAM).

versions utilisées :
Apache 2.2.9
Lighttpd 1.4.19
PHP 5.2.6

pour les tests on utilise siege, on lance donc un siege avec 100 concurrency sur 10 minutes, voici la commande :

siege -c100 -t10M URL_DU_SITE

on note également le Load average de la machine a la fin de l'opération.

1ère configuration : Lighttpd tout seul

voici le resultat :

Load average : 4.87
 
Lifting the server siege...      done.
Transactions:		       23859 hits
Availability:		      100.00 %
Elapsed time:		      600.37 secs
Data transferred:	       83.25 MB
Response time:		        2.02 secs
Transaction rate:	       39.74 trans/sec
Throughput:		        0.14 MB/sec
Concurrency:		       80.21
Successful transactions:       23859
Failed transactions:	           0
Longest transaction:	        5.20
Shortest transaction:	        0.10

2ème configuration : Apache2 tout seul

le résultat :

Load average : 77.51
 
Lifting the server siege...      done.
Transactions:		       23543 hits
Availability:		      100.00 %
Elapsed time:		      599.66 secs
Data transferred:	       82.16 MB
Response time:		        2.04 secs
Transaction rate:	       39.26 trans/sec
Throughput:		        0.14 MB/sec
Concurrency:		       80.22
Successful transactions:       23543
Failed transactions:	           0
Longest transaction:	       10.51
Shortest transaction:	        0.05

3ème configuration : Lighttpd + Apache

maintenant faisons le test en couplant les 2, dans cette configuration tout ce qui est statique (images, css, js, etc.) sera servi par lighty alors que les scripts php eux, seront traités par apache, pour cela on active le mod_proxy dans lighty, et on ajoute le code suivant dans le vhost de notre site :

 $HTTP["url"] !~ "\.(js|css|gif|jpg|png|ico|txt|swf|html|htm)$" {
               proxy.server  = ( "" => (
                               ( "host" => "127.0.0.1", "port" => 8080 )
                       )
               )
       }

vous l'aurez compris, Apache écoute sur le port 8080 (c'est fait en changeant le fichier /etc/apache2/ports.conf).

voici le résultat :

Load average : 14.79
 
Lifting the server siege...      done.
Transactions:		       22684 hits
Availability:		      100.00 %
Elapsed time:		      600.25 secs
Data transferred:	       79.10 MB
Response time:		        2.13 secs
Transaction rate:	       37.79 trans/sec
Throughput:		        0.13 MB/sec
Concurrency:		       80.53
Successful transactions:       22684
Failed transactions:	           0
Longest transaction:	        8.61
Shortest transaction:	        0.07

plutôt surprenant !

Conclusion :

Lighty s'en sort très bien au vu des transactions/s (ou le nombre total de transactions traitées), contrairement a ce qu'on pouvait attendre, coupler les 2 nous fait perdre en performances (on enregistre quand même un load average nettement inférieur a la config d'apache tout seul).

personnellement ce que je retiens, c'est que lighty n'est pas si mauvais que ça pour le contenu dynamique, les performances restent quand très proches dans les 3 cas, donc autant utiliser la solution qui nous plait :-)

1. Le mode NAT
2. Adaptateur réseau hôte

Le mode NAT :

Avec ce type de configuration, la machine aura accès au net, mais sans plus, elle ne sera pas joignable, elle ne sera pas visible sur le réseau, c'est le plus simple, le plus rapide, mais pas le plus efficace, néanmoins, ça peut suffire dans la plupart des cas. D'ailleurs, c'est la configuration par défaut de VirtualBox, donc il n'y a rien à faire pour que ça fonctionne.

Adaptateur réseau du système hôte :

Cette configuration fait que, non seulement, la machine virtuelle aura accès au net, mais elle sera elle même joignable depuis le réseau, avec cette configuration, la machine virtuelle apparaitra sur le réseau comme une machine indépendante du système hôte, ce qui est plutôt appréciable pour certaines utilisations, indispensable pour d'autres.

Nous allons voir comment procéder à cette configuration dans le cadre d'un système hôte sous XP (ou Vista) et une machine virtuelle sous Linux (Debian Etch en l'occurrence).

Tout d'abord, aller dans les paramètres de la machine virtuelle (éteinte ;-) ) et modifier les options du réseau, dans la partie basse de la fenêtre ajouter une interface réseau (cliquez sur le "+" a droite de la fenêtre, cela créera une interface réseau supplémentaire qu'on utilisera plus tard (visible dans les connexions réseau).

dans "Attaché à :" sélectionnez "Adaptateur réseau hôte", puis validez.

aller dans les connexions réseau, sélectionnez votre connexion habituelle (en général elle s'appelle :"connexion au réseau local") et la connexion virtuelle créée précédemment, puis cliquez sur le bouton droit de la souris (il faut sélectionner les 2 en même temps), et dans le menu contextuel cliquez sur "connexion de ponts", ceci va créer un pont entre les 2 connexions réseau (en gros il va donner la connexion a l'interface virtuelle).

normalement si tout va bien votre machine virtuelle est ajouté au réseau (il faut l'allumer hein ;-) ), elle obtient directement son adresse IP (si vous avez un serveur DHCP sur le réseau bien sûr, sinon rester en NAT ou configurez une IP fixe).

En cas de problème n'hésitez pas à recommencer, parfois ça a du mal a fonctionner.

Quelques pistes en cas de problème :

parfois, si on a fait plusieurs tests, bidouillé un peu /etc/network/interfaces etc. l'interface coté linux peut changer de nom, en général c'est eth0 mais c'est pas toujours le cas, voici un moyen simple de savoir comment est appelée l'interface réseau :

cat /proc/net/dev

dans le résultat de cette commande on voit le nom de l'interface, pratique pour la configurer à la main (IP statique par exemple) en tout cas ça m'a bien servi pour voir que mon interface s'appelait eth4 ;-)

n'oublier pas une petit

/etc/init.d/networking restart

après chanque changement dans /etc/network/interfaces

Bonne chance, et bonne virtualisation :-)

Tout d'abord, précisions l'environnement :
Il s'agit d'un système Hôte sous Windows XP, nous installons dessus le logiciel VirtualBox, et dans ce dernier nous créons une machine virtuelle tournant sous Linux (Systême guest).

Pour commencer il faut installer les additions client pour notre VirtualBox, pour cela je vous renvoie à notre article : Additions client pour VirtualBox.

Une fois les additions client installées, procédons comme suit :

1. Sélectionner la machine virtuelle est cliquez sur "Répertoires Partagés"
2. Cliquez sur le "+" (PLUS) a droite de la fenêtre qui s'ouvre et sélectionner un répertoire à partager, vous pouvez lui donner un nom
3. Valider et démarrez votre machine virtuelle

Maintenant, nous allons voir comment monter le partage du coté de notre système guest (Linux), pour cela, exécutez la commande suivante :

mount -t vboxsf NOM_PARTAGE POINT_MONTAGE

où :
NOM_PARTAGE est le nom que vous avez donné à votre répertoire partagé lors de sa sélection.
POINT_MONTAGE est le point (répertoire, ou encore emplacement) dans la machine virtuelle dans lequel vous voulez monter le répertoire.

voici un exemple avec un partage nommé Downloads :

mount -t vboxsf Downloads /mnt/downloads

ça parait simple, mais quand on a installé une Debian assez maigre (avec presque rien dessus) la tache ne se résume plus a un simple clic, voici donc ce qu'il faut faire :

la première étape est obligatoire pour nous éviter un message d'erreur du type :

"Please install the build and header files for your current Linux kernel.
The current kernel version is 2.6.17-5mdv
Please install the GNU compiler.
Problems were found which would prevent VirtualBox from installing.
Please correct these problems and try again."

debian-guest:~# apt-get install linux-headers-`uname -r` build-essential

après il faut aller dans : Périphériques >> Installer les additions client...

retourner dans Debian et faire :

debian-guest:~# cd /media/
debian-guest:~# mount cdrom0
debian-guest:~# cd cdrom
debian-guest:~# sh VBoxLinuxAddition-XXXX.run (le XXX c'est la version adm64 ou x86)

redémarrez les machine virtuelle est ca devrait être bon ;-)

il faut s'assurer que le paquet locale est deja installé (par défaut sur une etch il me semble) et faire un coup de :

dpkg-reconfigure locales

et là on sélectionne la locale voulue en la mettant par défaut, se déconnecter, se reconnecter et le tour est joué :)

C'est beau, rapide, léger, en gros c'est magnifique, mais c'est pas tout.

il faut noter tout de même quelques différences par rapport à Apache, Lighttpd ne comprend pas les .htaccess, ne gère pas les vhosts de la même façon qu'Apache etc.

Or, wordpress utilisse l'url rewriting pour nous donner de belles urls, voici donc le bout de code a ajouter dans le vhost de wordpress pour que ce dernier continue à servir de belles urls :

server.error-handler-404 = "/index.php?error=404"
 
url.rewrite = (
        "^/(wp-.+).*/?" => "$0",
        "^/(sitemap.xml)" => "$0",
        "^/(xmlrpc.php)" => "$0",
        "^/(.+)/?$" => "/index.php/$1"
)

On garde même la gestion de l'erreur 404 par wordpress ;)

avec ces quelques lignes, votre wordpress ne peut que mieux se porter dans son nouvel environnement Lighty :)

N.B. n'oublier pas d'activer le module rewrite dans lighttpd.conf pour qu'il sache ce qu'on lui demande quand même ;)
voici la ligne a décommenter (ou a ajouter) :

server.modules              = (
            ...
            "mod_rewrite",
            ...
)

n'oubliez pas un petit

 /etc/init.d/lighttpd restart

a la fin :)

Microsoft vient de signer avec Samba, et pour 10 000 € (paiement unique, pas de royalties ni autre), cette dernière a obtenu toute la documentation des protocoles utilisés par Windows.

Samba pour ceux qui ne connaissent pas, est un logiciel libre, en Open source, sous Linux qui permet de faire des partages réseaux entre ordinateurs Windows <--> Linux. Ce dernier avait un peu de mal à suivre toutes les évolutions de windows, et donc, ne pouvait pas vraiment être au top et présentait même des limites dans certaines situations, mais tout cela devrait changer maintenant que les développeurs possèdent la documentation des protocoles, et ainsi Samba n'aura plus d'excuses pour le mauvais fonctionnement dans certains cas bien précis.

Un choix étonnant de la part de la Bourse, qui a depuis toujours fonctionné sous Unix, mais les responsables disent ne pas vouloir être dépendant d'un Unix propriétaire, d'où le choix du libre. Sans oublier l'économie réalisée en faisant ce choix. étonnant également que la bourse n'ait pas retenu le Système d'exploitation d'HP avec tout ce matériel HP.