Projet Technique


Sommaire

Documentation développeur

Le process et les outils de développement

Marche à suivre pour le développement de la grenouille (serveur) :

Prérequis :

  1. Disposer d'un serveur apache + php + mysql ( plateformes LAMP ou WAMP classiques)
  2. Disposer d'un client git (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/magrenouille (non créé pour le moment).

Rajouter ou définir dans votre virtual host par défaut :

  DocumentRoot /home/toto/magrenouille

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 de l'interface web grenouille :

git clone git://git.grenouille.com/grenouilleweb.git magrenouille
git checkout v3

Récupérer les sources du kernel grenouille :

git clone git://git.grenouille.com/grenouillekernel.git monkernel
git checkout v3

Nota : Dans le cas de la grenouille en cours les sources sont gérés par le même serveur et on les récupère comme suit pour chaque composant :

Sources de l'interface web grenouille :

cd /path/to/magrenouille
git checkout master

Sources du kernel grenouille :

cd /path/to/monkernel
git checkout master

(à 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 dépôts git) :

git checkout -b vX master


Par la suite pour travailler sur la nouvelle branche il faudra refaire les deux opérations de checkout (co) dans chaque répertoire avec vX au lieu de v3.

Configuration du serveur grenouille

Aller dans /home/toto/magrenouille

cd magrenouille

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

(à détailler)

Création de la structure de la base et remplissage minimal

Commencer par faire un clone des sources du dépôt de grenouilleutils dans /home/toto

   git clone git://git.grenouille.com/grenouilleutils.git 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

git permet de synchroniser les travaux de plusieurs développeurs.

(On part du principe qu'on est toujours dans /home/toto/magrenouille)

Mise à jour du serveur à partir des modifs faites sur index.php :

git commit -a -s 

Ajout d'un fichier à la gestion locale pied.php :

git add pied.php

Mise à jour du serveur avec pied.php :

git commit -a -s

Récupération des modifs envoyées au serveur par les autres développeurs :

git pull

Vérification de l'état de synchronisation:

git status

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 répertoire qui va bien puis mettre à jour le code :

git pull 

ou

git fetch 

si vous ne voulez pas fusionner les changements dans le code avec les vôtres automatiquement.

suivi d'un

git checkout vX

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&param2=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 ait 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 renvoyez 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_string : une chaine de caractère permettant de définir la taille des paquets ICMP des tests.

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

mark : La qualité de la mesure, une valeur de 1 à 5 (à détailler)

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 faisant la différence entre sent et received).

total_time : cumul du nombre de millisecondes 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 contrôle 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

Coregrenouille

PyGrenouille

Camlgrenouille

vbGrenouille

La page de vbGrenouille est disponible ici : http://vbgrenouille.grenouille.com.

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

Le système de mesure grenouille

Grenouille

Administration des offres

Le principe est le suivant, pour les opérateurs non historiques, deux grands types d'accès : le non-dégroupé (IP/ADSL/ND) et le dégroupé pour les offres dite ADSL Max (celles qui posent le plus de problèmes pour leur calculer un mark qui tienne la route). Pour ces offres, on a choisi arbitrairement de mettre 1100 Ko/s comme vitesse de mesure descendante "bonne" (dl_good), tant qu'on aura pas refondu la base, on pourra pas faire mieux.

Pour les offres ADSL non Max, la règle pour choisir une bonne valeur d'une mesure est en général (vitesse_théorique_max) * 0.7

Les offres ADSL Max de l'opérateur historique n'ont donc qu'un seul cas.

Il est nécessaire d'éviter les configurations appliquées seulement à des utilisateurs ou ville sauf pour des débogages éventuels.

Pour les offres avec des autres types d'accès (câble, Fibre), même règle de calcul.

L'important, c'est que tous les mêmes types d'offre est le même dl_good sinon la pertinence des soleils, nuages, etc pour faire des comparaisons entre offres est mise à mal.

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

On 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
#
no_anon_password=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=ftp
#
# 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=105,gid=65534,mode=755 0 0

ou uid correspond à l'uid de l'utilisateur ftp et gid à celui du groupe de vsftpd.

Ceci permet d'éviter à la fois une usure prématuré du disque et le goulot d'étranglement que peuvent être les accès disques.

HOWTO : installation d'un serveur HTTP de test

TODO

Grenouille's server list and location

ns351.ovh.net aka oldpeople.grenouille.com

  • Functions : None currently. Scratch test box.
  • Location : Baie G24, Numéro 274

ns2023.ovh.net aka db2.grenouille.com

  • Function : slave MySQL, FTP
  • Location : Baie E02, Numéro 5385

ns2185.ovh.net aka devel.grenouille.com

  • Functions : LAMP, blog, TRAC, subversion, git, jabber, etc.
  • Location : Baie A22, Numéro 2017

ns2225.ovh.net aka grenouille.com

  • Functions : LAP
  • Location : Baie A29, Numéro 9170

ns2275.ovh.net aka db.grenouille.com

  • Functions : master MySQL
  • Location : Baie A25, Numéro 2286

ns2313.ovh.net aka forums.grenouille.com

  • Functions : LAMP
  • Location : Baie D02, Numéro 5931

ns37873.ovh.net aka laposte.grenouille.com

  • Functions : LAMP, SMTP, IMAPS, personal home page, personal git repositories
  • Location : Baie 03G06, Numéro 19196

ns37874.ovh.net aka wild.grenouille.com

  • Functions : FTP, slave MySQL
  • Location : Baie 03G06, Numéro 19197
De Wiki Grenouille.
Powered by MediaWiki
GNU Free Documentation License, sous les copyrights des membres de l