Documentation développeur
Le process et les outils de développement
Marche à suivre pour le développement de la grenouille (serveur) :
Prérequis :
- Disposer d'un serveur apache + php + mysql ( plateformes LAMP ou WAMP classiques)
- Disposer d'un client subversion (ici ça sera le client en ligne de commande... c'est rustique mais ça permet de bien comprendre)
Choix de configuration
Pour la suite on décidera arbitrairement de paramétrer le serveur apache pour que http://localhost pointe sur le répertoire "racine" /home/toto/magrenouillev3 (non créé pour le moment).
Rajouter ou définir dans votre virtual host par défaut :
DocumentRoot /home/toto/magrenouillev3
et redémarrer votre serveur apache.
Récupération des sources grenouille
Aller dans le répertoire /home/toto
cd /home/toto
Récupérer les sources grenouilleweb :
svn co https://subversion.grenouille.com/svn/grenouilleweb/branches/v3 magrenouillev3
Récupérer les sources du kernel grenouille :
svn co https://subversion.grenouille.com/svn/grenouillekernel/branches/v3 monkernelv3
Nota : Dans le cas de le grenouille en cours de dev les sources sont gérés par le même serveur et on les récupère comme suit :
svn co https://subversion.grenouille.com/svn/grenouilleweb/trunk magrenouilledev
Sources du kernel grenouille :
svn co https://subversion.grenouille.com/svn/grenouillekernel/trunk monkerneldev
(à noter qu'il faudrait adapter aussi la configuration du serveur http... et mettre en place une base de données ad hoc)
Lorsque cette grenouille entrera en phase de stabilisation on en fera une nouvelle branche avec les commandes suivantes ( en principe réservé au gestionnaire des repositories subversion ) :
svn copy https://subversion.grenouille.com/svn/grenouilleweb/trunk \ https://subversion.grenouille.com/svn/grenouilleweb/branches/vX \ -m "stabilisation de la vX"
svn copy https://subversion.grenouille.com/svn/grenouillekernel/trunk \ https://subversion.grenouille.com/svn/grenouillekernel/branches/vX \ -m "stabilisation de la vX"
Par la suite pour travailler sur la nouvelle branche il faudra refaire les deux opérations de checkout (co) dans un nouveau répertoire avec vX au lieu de v3.
Configuration du serveur grenouille
Aller dans /home/toto/magrenouillev3
cd magrenouillev3
Copier le fichier de modèle de configuration grenouille_config.inc.tpl en grenouille_config.inc.php
cp grenouille_config.inc.tpl grenouille_config.inc.php
Modifier le fichier en fonction de la configuration
(a détailler)
Création de la structure de la base et remplissage minimal
Commencer par faire un checkout des sources du trunk de grenouilleutils dans /home/toto
svn co https://subversion.grenouille.com/svn/grenouilleutils/trunk grenouilleutils
Ensuite passer sous root :
su
Et enfin exécuter le script install_grenouille.sh dans un terminal afin de créer une la base grenouille et un jeu minimal de configuration.
Développement et gestion de configuration
Subversion permet de synchroniser les travaux de plusieurs développeurs.
(je pars du principe qu'on est toujours dans /home/toto/magrenouillev3)
Mise à jour du serveur à partir des modifs faites sur index.php :
svn commit index.php -m "description de la petite modification pour l'historique"
Ajout d'un fichier à la gestion locale pied.php :
svn add pied.php
Mise à jour du serveur avec pied.php :
svn commit pied.php -m "Ajout du fichier pied.php"
Récupération des modifs envoyées au serveur par les autres développeurs :
svn update
Vérification de l'état de synchronisation:
svn status
A = Ajouté en local
M = Modifié par rapport au serveur
U = En retard par rapport au serveur (nécessite un update)
G ou C = conflit (a détailler plus tard)
Mise à jour du serveur
A partir du moment où le code est dans un état "apte à passer en production" on peut mettre à jour le serveur (action bien entendu réservée aux seuls administrateurs... qui seront pendus si la mise à jour se passe mal huhuhu) :
Se connecter sur le serveur avec le compte qui va bien... se placer dans le repertoire qui va bien puis mettre à jour le code :
svn update
Voilà c'est tout :o)
Documentation technique
Le protocole d'échanges de données client/serveur
Auteurs initiaux : ManuelVila AlanSchimtt JulienCatalano
Toute la communication entre le client et le serveur s'appuie sur le protocole HTTP et se fait en envoyant un GET Ã une URL unique :http://www.grenouille.com/interface.php.
Pour que l'interface sache ce qu'on veut d'elle, il faut bien sûr lui communiquer des paramètres. Le passage de paramètres avec un GET est très simple, il suffit de faire préceder l'URL d'un "?" suivi des différents paramètres "param=valeur" séparés par des "&". Exemple :
http://domain.com/page.html?param1=valeur1¶m2=valeur2
Attention, le jeu de caractères utilisé dans les URLs est très limité : pas d'accents, pas d'espaces, etc. Pour passer n'importe quel caractère il faut utiliser un "%" suivi de la représentation hexadécimale du code ASCII de l'ISO-8859-1. Mais pas de panique, j'ai fait en sorte qu'on est pas à envoyer de caractères spéciaux. Par exemple, le nom de l'utilisateur ne pourra pas contenir d'espaces et autres gremlins... ;-)
Le premier paramètre dont l'interface à besoin s'intitule "command", c'est grâce à lui que l'on indique ce que l'on veut faire. En plus du paramètre "command", l'interface à besoin de paramètres supplémentaires dépendant de chaque commande. Pour le moment l'interface reconnait 6 commandes : hello, post_dl, post_ul, post_ping et post_breakdown.
Les commandes peuvent retourner des résultats représentés ainsi :
resultat1=valeur1 resultat2=valeur2 resultat3=valeur3
Les lignes sont terminées par un retour chariot Unix (code ASCII 10).
Toutes les commandes retournent au minimum un résultat :
- result=OK pour signifier que tout c'est bien passé et qu'aucune erreur n'est survenue.
- error=Message d'erreur
Attention, pour s'assurer qu'une commande a bien été traitée il vaut mieux tester la présence de "result=OK" plutôt que rechercher "error=quelquechose" car il peut arriver qu'une commande n'aboutisse pas et ne renvoie aucun résultat, lors d'une coupure de câble par exemple... En d'autre terme :
Si result=OK -> Yeah, tout c'est bien passé.
Si error=quelquechose -> Une erreur "quelquechose" est survenue.
Si ni l'un ni l'autre -> Une erreur indéterminée est survenue.
Commande hello
Cette commande doit être envoyée une seule fois au lancement du client. Cela permet de vérifier que l'utilisateur est bien enregistré sur grenouille.com et de déterminer quel client il utilise (nécessaire pour garantir une compatibilité ascendante).
Paramètres
username : le nom de l'utilisateur.
password : le mot de passe crypté (voir annexes).
client : le nom du logiciel client (exemple : ma_grenouille).
version : la version du logiciel client sous la forme d'un numérique (en guise de virgule "." et "," sont autorisés). La version 2.3.1 donnera par exemple "2.31" ou "2,31".
system : le système d'exploitation sur lequel le client tourne (on pourrait normaliser ainsi : linux, windows ou mac_os) .
beta : si le client est en version béta, indiquer le numéro de béta ici (exemple beta2). Si le client est en version finale, indiquer beta255. Si ce paramètre n'est pas spécifié, le client sera considéré comme une version finale.
build : numéro de build (à la Windows) pouvant aller de 0 à 65535
Résultats
id : c'est l'identifiant unique de l'utilisateur qui devra être utilisé ensuite dans toutes les autres commandes. Ainsi, plus besoin d'envoyer utilisateur et mot de passe par la suite (jusqu'au prochain lancement du logiciel), l'id sert à identifier l'utilisateur. Cet id est crypté mais vous n'avez pas à vous en soucier, vous le renvoyer tel quel.
result ou error : comme pour toutes les commandes, permet de savoir si tout est OK. Voir explications plus haut.
Exemple hello
La commande
wget http://www.grenouille.com/interface.php?command=hello&username=manu02&password=hjglke&client=ma_grenouille&version=2.01&system=mac_os
retourne :
id=Ei54oy5kY7 result=OK
Commande getlastversion
Retourne la dernière version du client disponible sur grenouille.com.
Paramètres
id : l'identifiant de l'utilisateur retourné par la commande hello.
Résultats
client : nom du client
version : version du client
beta : numéro de béta ou 255 s'il s'agit d'une version finale
build : numéro de build
system : windows, mac_os, linux,...
Commande get_config
Renvoie la configuration propre à l'utilisateur, la ville ou le provider permettant d'effectuer les mesures.
Paramètres
id : l'identifiant de l'utilisateur retourné par la commande hello.
Résultats
dl_host : l'ip ou le nom de domaine du serveur FTP servant à faire les mesures du download.
dl_path : le chemin d'accès au fichier qui sera downloadé.
dl_file : le nom du fichier.
dl_frequency : la fréquence de la mesure du download exprimée en nombre de secondes. Contrairement au client actuel où la fréquence des mesures est hardcodée, on a maintenant la possibilité de fixer cette fréquence "à distance". Je crois que ce sera intéressant pour se livrer à des expériences et s'adapter plus facilement au contexte de chaque provider. Pour la mesure de l'UL par exemple, on peut avoir une fréquence soutenue pour l'ADSL et une plus relaxe pour les Cybercâblés... ;-)
dl_max : le débit maximum de la voie descendante de l'utilisateur en Kbps. Ca peut servir à Mwarf qui a besoin de cette information pour déssiner ses zoulis graphiques... ;-)
ul_host : le FTP servant à la mesure de l'upload.
ul_path : chemin où on va uploader.
ul_file : nom du fichier qui devra être créé sur le FTP. Ce nom est en fait constitué de l'id de l'utilisateur suivi de ".bin".
ul_size : nombre d'octets à uploader. On pourrait générer un fichier avec un contenu aléatoire (pour contourner les éventuelles compressions liées à la connexion).
ul_frequency : la fréquence de la mesure de l'upload en seconde.
ul_max : le débit maximum de la voie montante de l'utilisateur en Kbps.
ping_host : l'host qu'on va pinguer.
ping_quantity : le nombre de pings à effectuer lors de chaque mesure.
ping_frequency : la fréquence de la mesure du ping en secondes.
ping_min : sert au serveur pour évaluer la qualité du ping (permet de déterminer l'icone des 'tites nuages) mais ne devrait pas être utile pour le client dans un premier temps.
ping_max : même remarque que pour pingmin.
breakdown_host : le ou les hosts servant à déterminer les pannes. Chaque host sont séparés par une virgule (exemple : "ns.oleane.com, www.wanadoo.fr, ftp.symantec.com").
breakdown_frequency : la fréquence du contrôle des pannes en secondes.
dl_ratiomaxdl : ratio d'invalidation fonction du trafic entrant sur la carte réseau pendant une mesure du download
dl_ratiomaxul : ratio d'invalidation fonction du trafic sortant sur la carte réseau pendant une mesure du download
ul_ratiomaxdl : ratio d'invalidation fonction du trafic entrant sur la carte réseau pendant une mesure de l'upload
ul_ratiomaxul : ratio d'invalidation fonction du trafic sortant sur la carte réseau pendant une mesure de l'upload
web_host : URL racine où est présentée les graphiques des mesures effectuées
Mécanisme d'invalidation
Pour la mesure du download :
Soient :
- down le nombre d'octets entrant sur la carte réseau
- up le nombre d'octets sortant sur la carte réseau
- ftp la taille du fichier downloadé
ratioDL = (down / ftp - 1) * 100 Si ratioDL > dl_ratiomaxdl Alors la mesure doit être invalidée
ratioUL = up / ftp * 100 Si ratioUL > dl_ratiomaxul Alors la mesure doit être invalidée
Pour la mesure de l'upload (la même chose mais on inverse up et down) :
Soient
- down le nombre d'octets entrant sur la carte réseau
- up le nombre d'octets sortant sur la carte réseau
- ftp la taille du fichier uploadé
ratioDL = down / ftp * 100 Si ratioDL > ul_ratiomaxdl Alors la mesure doit être invalidée
ratioUL = (up / ftp - 1) * 100 Si ratioUL > ul_ratiomaxul Alors la mesure doit être invalidée
Important
Si pour une raison quelconque le client était incapable de déterminer le trafic sur la carte réseau, la mesure doit être invalidée. Un moyen simple de s'en assurer : pour la mesure du download, ratioDL ne doit pas être inférieur à zéro, idem pour ratioUL dans le cas de la mesure de l'upload.
Exemple get_config
http://www.grenouille.com/interface.php?command=get_config&id=Ei54oy5k
pourrait retourner :
dl_host=ftp.oleane.com dl_path=/pub/doc/rfc/ dl_file=rfc1131.ps dl_frequency=1800 dl_max=64 . . . result=OK
Commande getlastnews
Retourne la dernières news postée sur grenouille.com
Paramètres
id : l'identifiant de l'utilisateur retourné par la commande hello.
Résultats
date : date de la news au format mm/aa
subject : sujet de la news au format HTML
body : le texte de la news au format HTML
Commande post_dl
renommée en post_dl_ftp L'interface, cependant maintient la compatibilité ascendante.
Commande post_dl_ftp
Envoie du résultat de la mesure du download ftp.
Paramètres
id : l'identifiant de l'utilisateur retourné par la commande hello.
bandwidth : débit mesuré en Ko/sec ("," et "." accépté en guise de séparateur décimal).
elapsed_seconds : nombre de secondes écoulées entre la mesure et l'envoie du résultat. Cela permet au serveur de savoir précisément quand la mesure à eu lieu, tout est calé sur sa propre horloge.
Résultats
Aucun résultat spécifique n'est retourné, il n'y a donc que le controle d'erreur habituel "result=OK" ou "error=quelquechose".
Exemple post_dl_ftp
http://www.grenouille.com/interface.php?command=post_dl_ftp&id=Ei54oy5k&bandwidth=47.12&elapsed_seconds=0
pourrait retourner :
result=OK
Commande post_ul
renommée en post_ul_ftp L'interface, cependant maintient la compatibilité ascendante.
Commande post_ul_ftp
Envoi du résultat de la mesure de l'upload ftp.
Paramètres et résultats similaires à la commande post_dl_ftp.
Commande post_dl_http
Envoi du résultat de la mesure de download http.
Paramètres et résultats similaires à la commande post_dl_ftp.
Commande post_ul_http
Envoi du résultat de la mesure de l'upload http.
Paramètres et résultats similaires à la commande post_dl_ftp.
Commande post_ping
Envoi du résultat du la mesure du ping.
Paramètres
id : l'identifiant de l'utilisateur retourné par la commande hello.
sent : nombre de pings envoyés pour réaliser la mesure.
received : nombre de pings reçus (le serveur peut donc déterminer le nombre de pings perdus en faisaint la différence entre sent et received).
total_time : cumul du nombre de milisecondes des pings reçus (le serveur déterminera la moyenne en divisant total_time par received).
elapsed_seconds : nombre de secondes écoulées entre la mesure et l'envoie du résultat.
Résultats
Aucun résultat spécifique n'est retourné, il n'y a donc que le controle d'erreur habituel "result=OK" ou "error=quelquechose".
Exemple post_ping
http://www.grenouille.com/interface.php?command=post_ping&id=Ei54oy5k&sent=10&received=9&total_time=538&elapsed_seconds=0
pourrait retourner :
result=OK
Commande post_breakdown
Permet de reporter les pannes.
Paramètres
id : l'identifiant de l'utilisateur...
elapsed_seconds : ici, ce paramètre prend toute sa dimension... ;-)
Résultats
Aucun résultat spécifique n'est retourné, il n'y a donc que le controle d'erreur habituel "result=OK" ou "error=quelquechose".
Exemple post_breakdown
http://www.grenouille.com/interface.php?command=post_breakdown&id=Ei54oy5k&elapsed_seconds=2720
pourrait retourner :
result=OK
Ouf, terminus pour les commandes, c'est simple à comprendre mais long à décrire... ;-)
ANNEXES
Comment faire un GET sur un serveur HTTP ?
C'est simplissime, trois lignes de codes suffisent ! ;-)
1) Se connecter au serveur sur le port 80
2) Envoyer :
GET /interface.php?command=... HTTP/1.0<CRLF> User-Agent: ma''grenouille''mac_os<CRLF> Host: www.grenouille.com<CRLF> <CRLF>
Les lignes sont séparées par des retours chariots <CRLF> type Dos (code ASCII 13 + code ASCII 10). Le serveur HTTP considère que la requète est terminée quand il reçoie deux <CRLF> consécutif.
3) Recevoir :
Faire une boucle qui va attendre les résultats du serveur HTTP. Comment déterminer quand est-ce que tout est arrivé ? Fruste mais efficace : la connexion est terminée par le serveur...
Algorithme de cryptage du mot de passe
Je vous livre le source en Basic brut de pomme, j'espère que c'est suffisement simple pour que vous puissiez le porter dans votre environnement de développement sans autre explication de ma part. ;-)
Function CrypterPassword(password as String) as String
Dim clef as String
Dim crypt as String
Dim i as Integer
Dim asciiPass as Integer
Dim asciiClef as Integer
clef = "pasfaciledetrouverlaclefpourouvrirlaporte"
crypt = ""
For i = 1 to Len(password)
asciiPass = Asc(Mid(Lowercase(password), i, 1))
asciiClef = Asc(Mid(clef, i, 1))
If asciiPass >= Asc("a") And asciiPass <= Asc("z") Then
crypt = Chr((asciiPass + asciiClef) Mod 26 + Asc("a")) + crypt
ElseIf asciiPass >= Asc("0") And asciiPass <= Asc("9") Then
crypt = Chr((asciiPass + asciiClef) Mod 10 + Asc("0")) + crypt
Else
crypt = "_" + crypt
End If
Next
Return(crypt)
End Function
Les mesures
La mesure du temps de réponse
Le but est de connaitre le temps de réponse de certains services couramment utilisés par les internautes et dont le délai trop long peut perturber l'utilisation quotidienne d'internet.
Protocole ICMP
Une définition pointue se trouve à cette adresse pour ceux dont le détail est important ;) .
En se qui nous concerne, nous allons effectuer une requête de Ping ICMP pour interroger un hôte cible pour savoir, d'une part, s'il est présent sur le réseau, et d'autre part, en combien de temps une réponse peut revenir de cet hôte cible.
Tout les "ping_icmp_frequency" secondes, nous effectuons la mesure de Ping ICMP.
Dans nos mesures, nous allons interroger l'hôte cible "ping_icmp_host" un nombre "ping_icmp_quantity" de fois.
Nous mesurons le temps entre notre demande et la réponse obtenue.
Nous enregistrons si la réponse ne vient pas.
Enfin, la durée totale et le nombre de Ping envoyés et reçus sont transmis à Grenouille via une commande de "post_ping_icmp".
Protocole HTTP
Le principe du Ping HTTP diffère quelque peu du Ping ICMP car ça n'est pas proprement dit un Ping, mais l'application que nous en avons semble s'y rapprocher d'assez prêt.
En effet, pour mesurer le Ping HTTP, nous interrogeons un serveur HTTP, comme le ferait n'importe quel navigateur web, et nous mesurons le temps de réponse.
Donc, toutes les "ping_http_frequency" secondes, nous effectuons la mesure de Ping HTTP.
Dans la mesure, nous allons interroger l'hôte cible "ping_http_host" un nombre "ping_http_quantity" de fois.
Nous mesurons le temps entre notre demande et la réponse obtenue.
Nous enregistrons si la réponse ne vient pas (ou si la réponse vient trop tardivement).
Enfin, la durée totale et le nombre de Ping envoyés et reçus sont transmis à Grenouille via une commande de "post_ping_http".
La mesure du débit descendant
Le débit descendant est le débit qui vient d'internet pour arriver à l'internaute. Ce débit est aussi appelé Download.
Protocole FTP
Protocole HTTP
La mesure du débit montant
Le débit montant est le débit qui va de l'internaute vers l'internet. Ce débit est aussi appelé Upload.
Protocole FTP
Protocole HTTP
La mesure des pannes
Principe :
Connaitre le moment ou un internaute subit une panne de service de son fournisseur d’accès à Internet.
Mise en Å“uvre :
Le client Grenouille émet quelques requêtes vers les serveurs indiqués dans la variable « breakdown_hosts » retournée par l’interface lors d’un « get_config ».
Lorsque tous les serveurs ne répondent plus, cela indique que c’est plutôt la connexion de l’internaute qui ne fonctionne plus.
En effet, il est plus qu’improbable que tous les serveurs cible ne répondent plus au même moment.
Le client Grenouille inscrit donc le moment ou tous les serveurs cible ne répondent plus, et ce, à toutes les périodes du contenu de la variable « frequency » retournée par l’interface lors d’un « get_config ».
Lors du test suivant, si au moins un serveur cible répond aux requêtes, cela indique que le service a repris et qu’il faut en informer Grenouille.
Le client envoie alors, par la commande « post_breakdown », dans la variable « elapsed_time » le délai entre la constatation de la panne et le moment de l’envoi du rapport.
Pour info : Selon le délai de la panne subie par l’internaute, il se peut que plusieurs périodes se passent dans que le service soit rétabli. Cela implique que le client Grenouille devra envoyer autant de rapport que de période de test concluant à une panne.
Les clients grenouille
Pygrenouille
Camlgrenouille
vbGrenouille
Développé en VB.NET 2005 (Microsoft Framework 2), vbGrenouille est le premier client qui prend en charge les nouvelles mesures de Grenouille.
Le client se compose de deux parties distinctes.
La première partie est un "service" qui communique avec les serveurs Grenouille et qui se charge d'effectuer les mesures habituelles de la connexion Internet. Les avantages sérieux de cette partie du client est de démarrer en même temps que Windows (qu'un utilisateur soit identifié sur la station ou non) et surtout d'être un processus autonome.
La seconde partie (qui peut être développée dans tout autre langage de programmation) est une interface graphique qui communique avec le "service" via un port réseau afin d'y puiser les informations nécessaires à présenter à l'utilisateur et peut demander au "service" d'effectuer une mesure à la demande.
Il est prévu que ce client soit porté vers Linux, Sun Solaris et Apple Mac OSX grâce à l'excellent travail du Projet Mono sponsorisé par la société Novell.
Chef de projet de développement vbGrenouille : Gil DERENNE
Documentation Fournisseur d'accès
Afin de permettre aux abonnées de réaliser leurs mesures de bande passante au mieux il est nécessaire de mettre en place un serveur FTP et HTTP dédié.
HOWTO : installation et paramétrage d'un serveur FTP de test
Le choix du serveur FTP est aisé : vsftpd ou rien :
- c'est le plus performant et de loin
- il est facile à configurer
- c'est le plus sécurisé
- il est disponible sur tous les *nix libres
Je présuppose pour la suite que vsftpd à été installé avec le gestionnaire de paquets de votre *nix.
Voici le vsftpd.conf :
# Example config file /etc/vsftpd.conf # # The default compiled in settings are fairly paranoid. This sample file # loosens things up a bit, to make the ftp daemon more usable. # Please see vsftpd.conf.5 for all compiled in defaults. # # READ THIS: This example file is NOT an exhaustive list of vsftpd options. # Please read the vsftpd.conf.5 manual page to get a full idea of vsftpd's # capabilities. # # # Run standalone? vsftpd can run either from an inetd or as a standalone # daemon started from an initscript. listen=YES # # Run standalone with IPv6? # Like the listen parameter, except vsftpd will listen on an IPv6 socket # instead of an IPv4 one. This parameter and the listen parameter are mutually # exclusive. #listen_ipv6=YES # # Allow anonymous FTP? (Beware - allowed by default if you comment this out). anonymous_enable=YES # # Uncomment this to allow local users to log in. #local_enable=YES # # Uncomment this to enable any form of FTP write command. write_enable=YES # # Default umask for local users is 077. You may wish to change this to 022, # if your users expect that (022 is used by most other ftpd's) #local_umask=022 # # Secure uploaded file to not be retrived anon_umask=0007 # # Uncomment this to allow the anonymous FTP user to upload files. This only # has an effect if the above global write enable is activated. Also, you will # obviously need to create a directory writable by the FTP user. anon_upload_enable=YES # # Uncomment this if you want the anonymous FTP user to be able to create # new directories. #anon_mkdir_write_enable=YES # # Activate directory messages - messages given to remote users when they # go into a certain directory. dirmessage_enable=YES # # Activate logging of uploads/downloads. xferlog_enable=YES # # Make sure PORT transfer connections originate from port 20 (ftp-data). connect_from_port_20=YES # # If you want, you can arrange for uploaded anonymous files to be owned by # a different user. Note! Using "root" for uploaded files is not # recommended! #chown_uploads=YES #chown_username=whoever # # You may override where the log file goes if you like. The default is shown # below. #xferlog_file=/var/log/vsftpd.log # # If you want, you can have your log file in standard ftpd xferlog format #xferlog_std_format=YES # # You may change the default value for timing out an idle session. #idle_session_timeout=600 # # You may change the default value for timing out a data connection. #data_connection_timeout=120 # # It is recommended that you define on your system a unique user which the # ftp server can use as a totally isolated and unprivileged user. #nopriv_user=ftpsecure # # Enable this and the server will recognise asynchronous ABOR requests. Not # recommended for security (the code is non-trivial). Not enabling it, # however, may confuse older FTP clients. #async_abor_enable=YES # # By default the server will pretend to allow ASCII mode but in fact ignore # the request. Turn on the below options to have the server actually do ASCII # mangling on files when in ASCII mode. # Beware that on some FTP servers, ASCII support allows a denial of service # attack (DoS) via the command "SIZE /big/file" in ASCII mode. vsftpd # predicted this attack and has always been safe, reporting the size of the # raw file. # ASCII mangling is a horrible feature of the protocol. #ascii_upload_enable=YES #ascii_download_enable=YES # # You may fully customise the login banner string: #ftpd_banner=Welcome to blah FTP service. # # You may specify a file of disallowed anonymous e-mail addresses. Apparently # useful for combatting certain DoS attacks. #deny_email_enable=YES # (default follows) #banned_email_file=/etc/vsftpd.banned_emails # # You may restrict local users to their home directories. See the FAQ for # the possible risks in this before using chroot_local_user or # chroot_list_enable below. #chroot_local_user=YES # # You may specify an explicit list of local users to chroot() to their home # directory. If chroot_local_user is YES, then this list becomes a list of # users to NOT chroot(). #chroot_list_enable=YES # (default follows) #chroot_list_file=/etc/vsftpd.chroot_list # # You may activate the "-R" option to the builtin ls. This is disabled by # default to avoid remote users being able to cause excessive I/O on large # sites. However, some broken FTP clients such as "ncftp" and "mirror" assume # the presence of the "-R" option, so there is a strong case for enabling it. #ls_recurse_enable=YES
Il faut ensuite monter en RAM le répertoire utilisateur sous lequel tourne vsftpd en mettant dans votre fstab sous Linux :
# mount anonymous ftp in RAM none /home/ftp tmpfs nodev,noexec,noatime,uid=108,gid=65534,mode=755 0 0
ou uid correspond à l'uid sous lequel tourne vsftpd et gid à celui du groupe.
Ceci permet d'éviter à la fois une usure prématuré du disque et un goulot d'étranglement que peuvent être les accès disques.
HOWTO : installation d'un serveur HTTP de test
TODO
