Configurer la locale et l’heure – Debian -
Aujourd'hui on va voir comment configurer l'heure du système avec le bon fuseau horaire, ainsi que la locale pour, par exemple, passer une debian en Anglais en Français
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.
Installer et configurer Munin
... sur une debian.
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 :)
convertir un array en utf8
dans un précédent article nous avons vu comment convertir un texte en utf8.
aujourd'hui on va voir comment faire la même chose mais avec un tableau, sans passer par un foreach, ni aucune autre boucle.
pour cela nous allons utiliser une seule fonction qui convertira ce qu'on lui donne en entrée en utf8.
pour l'instant elle va savoir gérer, les chaînes de caractères et les tableaux.
function toUTF8($param) { if(is_array($param)) { array_walk_recursive($param, create_function('&$item, $index', '$item = toUTF8($item);')); return $param; } mb_detect_order('UTF-8, ISO-8859-15, ISO-8859-1, Windows-1252'); //parfois si le dernier caractère de la chaine est accentué, la conversion peut foirer, //donc on force avec un caractère qui ne l'est pas. //(astuce trouvée sur les commentaires de la doc sur php.net) $param .= '_'; $currentCharset = mb_detect_encoding($param); if ($currentCharset != 'UTF-8') { $param = mb_convert_encoding($param, 'UTF-8', $currentCharset); } return substr($param, 0, strlen($param)-1); } |
et voilà, cette fonction convertira array ou string en utf8 sans brancher...
en bonus voici une fonction somme que j'ai trouvé dans les commentaire de la doc sur php.net (une sorte de coup de coeur pour moi :-D)
function sum(){ $s=0; foreach(func_get_args() as $a) $s+= is_numeric($a)?$a:0; return $s; }; print sum(1,2,3,4,5,6); // will return 21 print sum(3,2,1); // will return 6 print sum(false,array(),5,5); // will return 10 |
trop fort non ?
protéger un ou plusieurs fichiers par htaccess
Nous avons vu dans précédent article comment protéger un répertoire avec htaccess, c'est l'utilisation la plus courante de cette technique, mais ici nous allons nous intéresser a comment faire la même chose mais pour protéger uniquement un ou quelques fichiers d'un répertoire, c'est à dire, dans le même répertoire, certains fichiers seront protégés mais pas d'autres.
pour protéger un seul fichier voici ce qu'il faut mettre dans le .htaccess :
<Files fichier.ext> require valid-user </Files> |
pour en protéger plusieurs :
<Files fichier1.ext fichier2.ext fichier3.ext> require valid-user </Files> |
cette syntaxe est a utiliser en complément de celle expliquée dans l'autre article bien sûr.
bonne protection de fichiers...
Lighttpd vs Apache vs Lighttpd + Apache
Il fut un temps où on ne se posait pas de question quant au serveur web, on prend Apache et on en parle plus, aujourd'hui les choses ont changé, Apache reste quand même le plus utilisé avec plus de 66% des parts de marché, suivi par IIS, puis tous les autres "petits" derrière, néanmoins en fonction des besoins, certains de ces petits peuvent s'avérer bien plus performants qu'Apache, aujourd'hui on va tester 3 configurations possibles avec Apache et Lighttpd.
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 :-)