les pré-requis :
- un serveur web Apache
- PHP5 avec l'extension APC
- jquery

dans ce tuto je pars du principe qu'Apache et PHP sont installés et fonctionnels, on va juste voir comment installer APC et activer le suivi de la progression d'upload :

apt-get install php-apc
vim /etc/php5/apache2/conf.d/apc.ini

ajouter à la fin du fichier :

apc.rfc1867 = on

cette ligne magique, activera la suivi de progression d'upload sur le serveur.

on reload apache :

/etc/init.d/apache2 reload

le coté système de la chose est maintenant terminé, passons à l'upload :

pour la petite histoire, voici ce que l'on va faire :
on va créer un formulaire, qui sera validé vers (target) une iframe invisible, le temps que l'upload se passe, on va contacter un petit script php en ajax (très souvent) qui va nous dire où en est l'upload, en nous retournant le pourcentage d'avancement (tout simplement), avec cette valeur, on va pouvoir mettre en place une barre de progression très facilement.

pour commencer, le formulaire :

<?php $unique_id = uniqid(); //id unique de notre formulaire ?>
 
<!-- iframe caché en javascript dans laquelle se fait l'upload, elle affichera le message de confirmation / ou erreur à la fin de l'upload -->
<iframe frameborder="0" border="0" id="upload_to" name="upload_to" style="width: 100%; border:none; border-color: #fff;" scrolling="no"></iframe>
 
<!-- le formulaire d'upload -->
<form id="upload_form" enctype="multipart/form-data" action="upload.php" method="post" target="upload_to">
<input type="hidden" name="APC_UPLOAD_PROGRESS" id="progress_key" value="<?php echo $unique_id?>"/>
<div id="progressouter">
	<div id="progressinner"><span id="progression_percent">0&nbsp;%</span></div>
</div>
<p><input id="file" type="file" name="file" size="30" /></p>
<p><input type="submit" value="valider" /></p>
</form>

le bout de php au début, permet de donner un id unique au formulaire
il est renseigné dans le champ "APC_UPLOAD_PROGRESS" ceci permet au système de donner un id à l'upload en cours, ce qui nous permettra de consulter la progression en le connaissant (l'id).

l'iframe n'a rien de spéciale, elle est caché en javascript (voir plus bas).

le formulaire contient l'HTML de la barre de progression (la div progressouter, on pourrait la mettre ailleurs, chacun fait ce qu'il veut. et le champ hidden APC_UPLOAD_PROGRESS comme dit plus haut, obligatoire pour le suivi de l'upload.

passons maintenant à notre script d'upload : upload.php
l'upload en lui même n'est pas vraiment notre sujet du jour, donc, je prends l'exemple d'upload le plus simple au monde (donné sur php.net)

$uploaddir = '/var/www/uploads/';
$uploadfile = $uploaddir . basename($_FILES['file']['name']);
 
if (move_uploaded_file($_FILES['file']['tmp_name'], $uploadfile)) {
    echo "File is valid, and was successfully uploaded.\n";
} else {
    echo "Possible file upload attack!\n";
}

on aura besoin du fameux script qui retourne le pourcentage d'avancement de l'upload : progress.php

header("Cache-Control: no-cache"); //utile pour IE (problème avec l'ajax)
//progression
if(isset($_GET['progress_key'])) {
    $upload = apc_fetch('upload_'.$_GET['progress_key']);
    $percent = 1000;
    if ($upload) {
        if ($upload['done'])
            $percent = 100;
        elseif ($upload['total'] == 0)
            $percent = 0;
        else
            $percent = $upload['current'] / $upload['total'] * 100;
    }
 
    echo number_format($percent, 2);
}

c'est presque fini, il ne reste plus que le javascript :

function getProgress(){
    var count = Math.random(); /// Math.random sélectionne un nombre entre 0 et 1 ( ex: 0.6489534931546957) pour IE aussi (même si le header no-cache devrait suffire)
    $.ajax({
        type: "GET",
        url: "/progress.php?progress_key=<?php echo($unique_id)?>&count="+count,
        success: function(percent) {
            if (percent <= 100){
                $("#progressinner").css("width", percent+"%");
                $("#progression_percent").text(percent+" %");
            }
            if (percent < 100){
                setTimeout("getProgress()", 100);
            }
            if (percent == 100){
                $("#upload_to").show("slow");
                $("#file").val('');
            }
        }
    });
}
 
function startProgress(){
    $("#progressouter, #progression_percent").show(200);
    setTimeout("getProgress()", 1000);
}
 
 
$(document).ready(function(){
    $("#upload_to").hide();
    $('#upload_form').submit(function () {
        startProgress();
    });
});

en gros (très gros même) ce js va cacher l'iframe au chargement de la page, et à la validation du formulaire, il va lancer la fonction startProgress(), qui elle, va afficher la barre de progression et lancer régulièrement getProgress, qui elle, fait un appel ajax à notre script progress.php et lui indiquant l'unique id généré tout au début de la page et en fonction du retour, elle va ajuster la largeur de la barre de progression.

si vous avez des questions, n'hésitez pas à les poser dans les commentaires.

bind-address           = 127.0.0.1

en ajoutant un # devant.

ça s'applique aussi quand on a un seul serveur mysql accessible par plusieurs serveurs web par exemple.

en faisant cela, on vient d'autoriser les connexions au serveur depuis... partout ! (alors que par défaut il ne les accepte que depuis localhost) ce qui va nous permettre d'avoir un phpmyadmin unique pour pleins de serveurs mysql.

le problème, c'est qu'en terme de sécurité, la règle est simple, "Je ferme tout, puis j'ouvre ce dont j'ai besoin"
ici le besoin est d'ouvrir l'accès à Mysql depuis le serveur qui héberge phpmyadmin, or, avec notre modification, on vient d'ouvrir l'accès à tout le monde (encore faut-il avoir des login/password valides pour se connecter, mais vaut mieux ne pas tenter le diable^^).

pour remédier au problème, on va avoir recours au firewall, sous debain (et linux en général) c'est iptables

on va explicitement permettre l'accès à notre mysql depuis le serveur hébergeant phpmyadmin, et... le refuser à tout le reste

iptables -A INPUT -p tcp -s IP_DU_SERVEUR_PHPMYADMIN --dport 3306 -j ACCEPT
iptables -A INPUT -p tcp --dport 3306 -j DROP

et voilà, en 2 lignes c'est fait.
la première autorise le serveur qui héberge phpmyadmin, la 2ème ferme tout.

il est à noter que ces règles seront perdues si le serveur redémarre, donc, si redémarrage, il faudra les retaper, ou sinon les mettre dans un script exécuté au démarrage, comment faire ? c'est le sujet d'un prochain post

Pour commencer installer memcached :

apt-get install memcached

ensuite, installer l'extension php

pecl install memcache

si l'installation échoue avec le message suivant :

downloading memcache-2.2.6.tgz ...
Starting to download memcache-2.2.6.tgz (35,957 bytes)
..........done: 35,957 bytes
11 source files, building
running: phpize
sh: phpize: command not found
ERROR: `phpize' failed

Allez faire un tour ici : Installation de fileinfo on a déjà rencontré ce problème

Pour rappel, il faut faire un simple :

apt-get install php5-dev
et retenter le :
pecl install memcache

il va surement vous poser une question, appuyez sur « entrée »

maintenant que memcache est correctement installer il faut l'activer en créant un fichier memcached.ini dans le dossier conf.d utilisé par le serveur (dans mon cas pour apache c'est : /etc/php5/apache2/conf.d) pour lighttpd par exemple c'est /etc/php5/cgi/conf.d) (cela évite de modifier les php.ini)
memcached.ini doit contenir :

extension=memcache.so

pour s'assurer que l'extension est bien installée, créer un fichier php contenant :

phpinfo()

et aller voir dedans, normalement vous devriez voir l'extension activée.

pour l'utilisation, rien de bien méchant, la doc php (http://php.net/manual/fr/book.memcache.php) est très bien faite

petit bonus :
pour vérifier que le service est bien lancé, faite :

netstat -latupen |grep memcached
résultat :
tcp        0      0 127.0.0.1:11211         0.0.0.0:*               LISTEN      0          157533      5952/memcached

pour commencer il faut trouver une autre porte d'entrée au serveur (une autre adresse IP)

en suite le but est de supprimer la règle concernant votre IP sans devoir toucher aux autres règles voici comment faire :

iptables -L --line-numbers

ce qui donne (entre autre) :

Chain fail2ban-ssh (1 references)
num  target     prot opt source               destination
1    DROP       all  --  kol-static-36-240-16-61.direct.net.in  anywhere
2    DROP       all  --  unknown-host.yaltanet.com.ua  anywhere
3    RETURN     all  --  anywhere             anywhere

là on vois qu'il y a 2 ip bannies, il faut repérer le numéro de ligne de cette qu'on veut supprimer (ce qui revient à autoriser l'ip a se connecter au serveur)

iptables -D fail2ban-ssh X

fail2ban-ssh : le nom de la chain créée par fail2ban pour le ssh
X : le #numéro de ligne qui nous intéresse

étant utilisateur occasionnel de tortoiseSVN à jour, impossible pour moi d'utiliser svn en ligne de commande (beaucoup plus rapide que tortoise) sur ma debian, d'où l'idée de d'installer svn 1.6 qui n'est pas disponible dans les paquets debian.

la procédure consiste a utiliser les backports, elle est très simple, encore faut-il la connaitre (ou la trouver facilement)

pour commencer il faut savoir que svn 1.5 doit être déjà installé sur la machine, si ce n'est pas le cas, faire :

apt-get install subversion subversion-tools apache2 libapache2-svn

1. configuration du sources.list
il faut ajouter cette ligne à la fin du fichier /etc/apt/sources.list

deb http://www.backports.org/debian lenny-backports main contrib non-free

2. mettre à jour la base de paquets :

apt-get update

3. on instalel svn en spécifiant la source (backports) :

apt-get -t lenny-backports install subversion subversion-tools libapache2-svn

et maintenant on peut utiliser svn en ligne de commande avec des référentiels "commités" avec des version récentes de subversion (comme tortoise)

Source du tuto : http://swherdman.com/2009/05/subversion-16-on-debian-lenny/

aujourd'hui nous allons voir comment, facilement, exploiter une fonctionnalité offerte par Gandi (ou bien comprise dans le prix de nom de domaine, ça dépend comment on voit les choses).

beaucoup d'entre nous n'ont pas le temps (et souvent pas l'envie de non plus) de se prendre la tête avec un vrai MTA genre postfix ou exim et le configurer en s'assurant de bien renseigner les enregistrement MX chez le registrar, d'installer les bons outils pour le POP (ou IMAP) etc. etc.

il faut savoir qu'avec un nom de domaine de chez Gandi, on a droit a quelques comptes emails (5 par domaine de mémoire) et une infinité d'alias sur ces comptes.

ce qu'on va voir ici, c'est comment configurer une machine (serveur dédié) pour assurer le minimum syndical en s'appuyant sur le service proposé par gandi.

dans notre exemple il s'agira d'un Exim4 (c'est le seul avec lequel j'ai testé pour l'instant, et ça marche tellement bien que je n'ai pas envie de changer )

on va supposer un compte admin@mon-domaine.com

tout d'abord il faut éditer le fichier : /etc/exim4/passwd.client en ajoutant tout à la fin :

*:admin@mon-domaine.com:MOT-DE-PASSE-DU-COMPTE

en suite, on va éditer le fichier /etc/exim4/update-exim4.conf.conf pour avoir quelque chose comme :

dc_eximconfig_configtype='satellite'
dc_other_hostnames=''
dc_local_interfaces='127.0.0.1'
dc_readhost='mon-domaine.com'
dc_relay_domains=''
dc_minimaldns='false'
dc_relay_nets=''
dc_smarthost='mail.gandi.net:587'
CFILEMODE='644'
dc_use_split_config='false'
dc_hide_mailname='true'
dc_mailname_in_oh='true'
dc_localdelivery='mail_spool'

un petit

/etc/init.d/exim4 reload

et le tour est joué

votre serveur envoie maintenant ces mails en utilisant le compte gandi, plus de soucis de conf complexe, maj à risque etc a se faire...

pour tester :

test-machine:/etc/exim4# mail user@omain.tld
Subject: test
ceci est un message de test !
.
Cc:

PS. procédure trouvé il y a un moment sur les forums gandi, mais je n'arrive jamais a la retrouver je la mets ici, au cas où.
PS2. comme d'habitude, notre distribution ici est 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

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

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

Pour l'installation, ce n'est pas très compliqué, il suffit de suivre ces quelques étapes à la lettre et tout ira très bien

tout d'abord il faut s'assurer d'avoir les bons paquets d'installés, en voici une liste :

• php5-dev
• openssl
• libssl-dev
• gcc
• make
• etc. je suppose que si vous installez cette extension, c'est que vous avez déjà php, apache etc.

Toute la suite s'effectue en root

mais avant toute chose, n'oublions pas de faire un petit :

apt-get update
apt-get upgrade

en suite il faut créer un répertoire de travail :

cd ~
mkdir libssh2
cd libssh2

ensuite télécharger libssh2 :

wget http://ovh.dl.sourceforge.net/sourceforge/libssh2/libssh2-0.14.tar.gz

puis l'extraire :

tar -xzvf libssh2-0.14.tar.gz

aller dans le répertoire créé et installer libssh2 :

cd libssh2-0.14
./configure && make all install

maintenant que libssh2 est installée, passons a ssh2 :

on sort du repertoire de libssh2 et on télécharge ssh2 :

cd ..
wget http://pecl.php.net/get/ssh2-0.10.tgz

extraire l'archive téléchargée :

tar -xzvf ssh2-0.10.tgz

aller dans le répertoire créé et installer ssh2 :

cd ssh2-0.10
phpize && ./configure --with-ssh2 && make

maintenant que l'installation est terminée, on active l'extension, ici on va copier le fichier ssh2.so dans le répertoire des extension de php5 (il peut être différent du mien selon la distrib et l'installation) :

cp modules/ssh2.so /usr/lib/php5/20060613+lfs

puis on ajoute l'extension en créant un fichier ssh2.ini dans le répertoire conf.d (comme pour toutes les autres extensions de php) on n'oublie pas de le faire pour apache mais aussi pour le mode CLI.

echo "extension=ssh2.so" > /etc/php5/cli/conf.d/ssh2.ini
echo "extension=ssh2.so" > /etc/php5/apache2/conf.d/ssh2.ini
/etc/init.d/apache2 restart

Et voilà, notre extension est installée, a vous ssh2 et sftp avec php