Un système de pages perso avec URL lisibles via le mass virtual hosting Apache

lundi 3 juillet 2006
par  G a.k.a Gérard Milhaud
popularité : 44%

C’est sûr, le module userdir d’Apache est pratique et permet sans trop de conf. d’obtenir pour les pages perso les fameuses URL http://www.mon.domaine/˜login . Mais imaginons que les login, dans le cadre d’une centralisation du SI d’entreprise, deviennent, par exemple des codes à 7 chiffres de type "première lettre du nom+code d’entreprise à 6 chiffres", soit par exemple m567874... L’URL en ˜login n’est plus vraiment utilisable. L’objectif de ce mini howto est d’exposer une solution permettant de s’abstraire du login et de proposer des URL perso de type http://prenom.nom.perso.mon.domaine tout de même, vous me l’accorderez, bien plus sexy...

Mots clé

pages personnelles, Apache, Mass virtual hosting, mod_rewrite, wildcard DNS

Sources

- un mail d’Olivier Pagé (Olivier dot Page at egim-mrs.fr) de l’EGIM qui donnait quelques indications sur la mise en place une première version d’un tel système (le lien pour les abonnés à la liste sysadm)
- un page de la communauté Debian (Ahh Debian, que ferais-je sans toi ?..) : Wildcard hosting with Apache and Bind
- La doc. officielle Apache du mass vhosting
- La doc officielle Apache du mod_rewrite
- Toujours chez Apache, le guide de re-écriture des URL

La problèmatique

Vous êtes administrateur système et réseau et, pour une raison qui vous appartient, la forme classique des URL des pages personnelles de vos utilsateurs, de type

http://www.mon.domaine/˜login

ne vous convient pas ou plus. Les motivations pour changer de type d’URL sont muliples. On peut citer :

- lisibilité insuffisante des logins (par exemple logins numériques...)
- souhait d’un type d’URL plus clair
- ordre de la direction...

Nous allons détailler ici le moyen de passer d’URL du type

http://www.mon.domaine/˜login

à

http://prenom.nom.perso.mon.domaine

Notons qu’on intercale "perso" entre prenom.nom et mon.domaine. Pourquoi ? En fait, il n’y a ici aucune obligation technique, mais plutôt une décision politique. Il est peut-être plus pertinent de clairement séparer, dans la forme de l’URL, les pages perso. qui n’engagent que leurs auteurs (encore que...), des pages officielles de l’organisme. Le responsable communication de chez vous abondera très probablement dans ce sens...

La méthode exposée devrait permettre au lecteur toute la personnalisation souhaitée :
- remplacer perso par autre chose, voire par rien
- login (ou toute autre chose rattaché à l’utilisateur) à la place de prenom.nom
- etc.

Le DNS

Dans un premier temps, il faut indiquer à votre DNS que toutes les machines de type

xxxx.perso.mon.domaine

sont des hôtes valides chez vous. C’est très simple. Nous allons utiliser un enregistrement particulier qui pointera vers l’adresse IP de votre serveur web. À la toute fin de votre fichier de zone, ajouter

; Et quelques wildcards DNS pour le mass virtual hosting
*.perso         IN      A       A.B.C.D
*.myspace       IN      A       A.B.C.D

ou A.B.C.D est l’adresse IP de votre serveur web.

Notez qu’ici j’ai mis en place deux wildcards car je souhaite, vous l’aurez compris, que mes URL utilisateurs puissent s’écrire indifféremment

http://prenom.nom.perso.mon.domaine

ou

http://prenom.nom.myspace.mon.domaine

Relancez votre démon named et c’est terminé.

Apache

L’idée : on va définir un virtual host qui interceptera toutes les requêtes de type prenom.nom.perso.mon.domaine et qui les reécrira de façon à ce que la cible soit le répertoire reservé au pages web (traditionnellement public_html) du homedir de l’utilisateur concerné. Cette reécriture sera assurée par les directives du module Apache mod_rewrite et via une map qui permet de relier Prenom.Nom et homedir correspondant.

  • Définition du virtual host

Comme il y a du monde qui regarde, on va essayer de faire bien propre. Pour commencer on crée non pas un mais deux virtual host, car on aimerait bien que les pages soient accessibles en http (TCP 80) et https (TCP 443).

Fichier perso80

<VirtualHost 139.124.44.237:80>

Include /etc/apache2/sites-available/perso_common.conf
Include /etc/apache2/sites-available/gestion_erreurs_en_http.conf

</VirtualHost>

Fichier perso443

<VirtualHost 139.124.44.237:443>

Include /etc/apache2/sites-available/perso_common.conf
Include /etc/apache2/sites-available/enable_ssl.conf
Include /etc/apache2/sites-available/gestion_erreurs_en_https.conf

</VirtualHost>

Fichier enable_ssl.conf

# SSL STUFF
       SSLEngine on
       SSLCertificateFile /etc/apache2/ssl/mon_certif.pem
# END SSL STUFF

Fichier gestion_erreurs_en_http.conf

### ErrorDocument STUFF
       ErrorDocument 400 http://www.mon.domaine/erreur.php?code=400
       ErrorDocument 402 http://www.mon.domaine/erreur.php?code=402
       ErrorDocument 403 http://www.mon.domaine/erreur.php?code=403
       ErrorDocument 404 http://www.mon.domaine/erreur.php?code=404
       ErrorDocument 408 http://www.mon.domaine/erreur.php?code=408
       ErrorDocument 410 http://www.mon.domaine/erreur.php?code=410
       ErrorDocument 411 http://www.mon.domaine/erreur.php?code=411
       ErrorDocument 412 http://www.mon.domaine/erreur.php?code=412
       ErrorDocument 413 http://www.mon.domaine/erreur.php?code=413
       ErrorDocument 414 http://www.mon.domaine/erreur.php?code=414
       ErrorDocument 500 http://www.mon.domaine/erreur.php?code=500
       ErrorDocument 501 http://www.mon.domaine/erreur.php?code=501
### END OF ErrorDocument STUFF

Fichier gestion_erreurs_en_https.conf

Remplacer http par https dans gestion_erreurs_en_http.conf ...

  • La re-écriture : c’est là qu’il faut bien écouter...

Vous l’aurez compris, tout se passe dans le fichier perso_common.conf que nous allons décortiquer morceau par morceau.

- Pour commencer le nom, les alias et l’admin :

       ServerName perso.mon.domaine
       ServerAlias *.perso.mon.domaine
       ServerAlias *.perso
       ServerAlias *.myspace.mon.domaine
       ServerAlias *.myspace
       ServerAdmin sysadmin@mon.domaine

On renseigne la balise ServerName, même si ce nom précis "perso.mon.domaine" sans rien devant ne sera en principe jamais utilisé. Ça nous permet essentiellement de pouvoir définir les alias qui nous intéressent.

Le fait de définir des ServerAlias à la fois pour *.perso.mon.domaine et *.perso permet de s’éviter d’avoir à écrire .mon.domaine dans l’URL lorsque l’on utilise des pages depuis des machines (correctement configurées au niveau DNS) internes.

On donne pour finir l’adresse mail du responsable du virtual host (en général, c’est vous...)

- On passe au log

Notons un des problèmes de cette approche : on n’a pas un fichier de log par virtual host prenom.nom.perso.mon.domaine... mais un seul pour tous...

       ErrorLog /var/log/apache2/myspace_error.log
       LogLevel warn
       CustomLog /var/log/apache2/myspace_access.log

- Un peu de rigueur

On n’autorise aucune surcharge d’options dans les fichiers .htaccess.

<Directory />
AllowOverride None
</Directory>

On suppose que vous avez dans la conf. globale du serveur, ou mieux, dans celle du module userdir, quelque chose du style de ce qui suit, qu permet d’overrider à peu près tout ce qui est nécessaire dans les home directories...

Note Apache 2.0 et ultérieur : Notez que le .* dans la directive signifie "un nombre quelconque de répertoires imbriqués" et non pas un seul niveau.

       <Directory ~ "^/home/.*/public_html">
               AllowOverride FileInfo AuthConfig Limit Options Indexes
               Options MultiViews SymLinksIfOwnerMatch IncludesNoExec
       </Directory>

- Autoriser l’exécution des cgi là où il le faut

On va donner ici la permission d’utiliser des CGI dans tous les répertoires de nom cgi-bin, situés immédiatement dans les répertoires public_html, situé n’importe où dans le répertoire /home du système de fichiers du serveur. Si vous avez des homedir dans d’autres partitions que /home il faudra faire autant de clauses Directory de ce type.

Libre à vous bien sûr de changer les noms "cgi-bin" et "public_html" en fonction de votre configuration personnelle.

       <Directory ~ "^/home/.*/public_html/cgi-bin">
           AllowOverride None
           Options ExecCGI
       
           Order allow,deny
           Allow from all
       </Directory>

- Le coeur du problème : la re-écriture

On commence par lancer le moteur de re-écriture

   RewriteEngine on

puis on se prépare un fichier de log pour la re-écriture. Au cas où tout ne se passe pas comme prévu, il suffira de décommenter et de reloader Apache. À noter : le fichier produit est remarquablement clair et lisible.

#    RewriteLog /var/log/apache2/myspace-rewrite.log
#    RewriteLogLevel 5

On définit les Rewrite Map (Doc Apache). Ce sont des fonctions de correspondance permettant de faire des substitutions dans des règles de re-écriture. Elles prennent en entrée une clé et renvoie le résultat de la fonction pour ladite clé.

La première s’appelle "lowercase" et correspond à une fonction interne ("int") d’Apache nommée "tolower" qui permet de passer en minuscules.

La deuxième est au coeur de notre propos. Elle est de type texte ("txt"), prend en argument un "prenom.nom" et renvoie le homedir correspondant. Plus concrètement, il s’agit d’un bête fichier où chaque ligne est de la forme :

gerard.milhaud /home/staff/g

Nous donnons plus loin deux petits programmes permettant de générer un tel fichier à partir d’une base NIS ou d’un annuaire LDAP.

Notons qu’il existe d’autres type de RewriteMap, en particulier le type programme externe ("prg"). Dans ce cas-là, on précise un programme écrit en langage quelconque capable de renvoyer le résultat voulu lorsqu’il est appelé avec une clé donnée. Ça semble séduisant mais si le serveur est utilisé intensivement, cela génèrera autant d’appels à ce programme, ce qui peut être dommageable en termes de performance...

Par contre les maps de type texte sont cachées une fois pour toutes dans la mémoire du serveur lors du premier appel : on voit le gain par rapport à la map de type programme en cas d’utilisation intensive, par exemple, au hasard, pour un système de home pages avec mass virtual hosting...

   RewriteMap lowercase int:tolower

   RewriteMap prenom.nom2homeDir txt:/etc/apache2/mass_vhosting/prenom.nom2homedir.txt

- On commence par traiter les requêtes de pages personnelles classiques, i.e. ne concernant pas les CGI. Les commentaires joints sont suffisants.

   ### REQUETES HORS CGI

   # On fait en sorte que les l'alias general "icons" défini
   # dans la conf. globale hors VirtualHost fonctionne. Pour ça
   # on précise qu'on ne doit pas re-écrire
   # si l'url est de type /icons/...
   RewriteCond %{REQUEST_URI} !^/icons/

   # On evite de re-écrire si la requête est de type /cgi-bin/
   # car on a un traitement particulier pour ce répertoire plus loin
   RewriteCond %{REQUEST_URI} !^/cgi-bin/

   # On s'assure que le serveur demande est bien de type
   # xxx.perso ou xxx.myspace
   # (La variable HTTP_HOST contient
   # la "base URL" de la requête i.e. entre le "://"
   # et le premier "/", c'est à dire le nom du serveur...
   # Le [NC] final permet de tester indépendamment de la casse
   RewriteCond   %{HTTP_HOST}                ^([a-z\-\.]+)\.(perso|myspace).*$ [NC]

   # Re-écrit la requête en la remplacant par le
   # homedir correspondant (résultat de la map pour %1 ; %1 étant
   # le premier motif parenthésé de la condition précédente,
   # i.e. le prenom.nom figurant en début de requête)
   # suivi du répertoire par défaut pour les pages web (public_html)
   # suivi du chemin demandé dans la requête
   # (premier motif parenthésé de la règle courante donc $1).
   # non_present est la "valeur par defaut" i.e. ce que retourne
   # la map si l'argument n'est pas présent dans la map (La
   # syntaxe Apache exige de la séparer de l'argument de la map
   # par un pipe (|)). Ici, ça correspond au cas                        
   # http://jean.dupont.mon.domaine avec
   # Jean Dupont non référencé dans les les utilisateurs et donc
   # non présent dans la map.
   # Notons l'utilisation du flag [E=variable:valeur] qui permet
   # de définir une variable d'environnement ici appelee
   # USERNAME à laquelle on attribue %1, c'est-à-dire le premier
   # motif parenthésé de la condition précédente, soit le
   # prenom.nom figurant en début de requête. On se servira
   # de cette variable dans la règle suivante...
   RewriteRule ^/(.*)$ ${prenom.nom2homedir:%1|/non_present}/public_html/$1 [E=USERNAME:%1]
   # Si l'utilisateur n'est pas présent dans la map, le motif,
   # reécrit par la règle précédente, commence par non_present.
   # Dans ce cas, on va rediriger vers une page spéciale qui
   # indiquera que l'utilisateur ne fait pas ou plus partie de
   # la structure et tout autres renseignements utiles
   # Notons le passage à ladite page spéciale du nom et prenom
   # de l'utilisateur non present via la variable d'environnement
   # définie dans la règle précédente. Ainsi le code php disposera
   # de cette information pour afficher un message plus précis.
   RewriteRule ^/non_present.*$ http://www.mon.domaine/page_explication.php?username=%{ENV:USERNAME}


   ### FIN REQUETES HORS CGI

À noter que la partie finale gérant le cas des utilisateurs non
présents est facultative, elle permet juste de mieux renseigner
l’internaute plutôt que de lui présenter une bête erreur 404...

  • Reste le cas des CGI

C’est le même principe que pour les requêtes non CGI si ce n’est qu’on force le type du fichier à "application/x-httpd-cgi" dans la dernière règle ([T=application/x-httpd-cgi])

   #################### CGI

   # On s'assure qu'on demande bien un répertoire cgi-bin
   RewriteCond %{REQUEST_URI} ^/cgi-bin/
   RewriteCond   %{HTTP_HOST}                ^([a-z\-\.]+)\.(perso|myspace).*$ [NC]
   RewriteRule ^/(.*)$ ${prenom.nom2homeDir:%1|/non_present}/public_html/$1 [T=application/x-httpd-cgi]
   RewriteRule ^/non_present.*$ http://page_explication.mon.domaine
   #################### FIN CGI

La génération des maps prenom.nom -> homedir

Je donne ici deux scripts permettant de générer la map texte "prenom.nom2homedir.txt" vue plus haut dans la conf.

  • NIS

On part des fichiers password et aliases, et la présupposition fondamentale est qu’il y a, dans le fichier aliases, pour tout login, une ligne du type :

prenom.nom : login

Dans le cas contraire, le script serait inopérant.

Ce script est à croner sur le serveur NIS et il faut, pour obtenir une exécution non interactive, copier la clé SSH du root sur le serveur NIS dans le .ssh/authorized_keys du root sur le serveur web.

#!/usr/bin/perl

my $passwd_file="/your/passwd/file";
my $aliases_file="/your/aliases/file";
my $prenomdotnom2homedir_file="/tmp/prenom.nom2homedir.txt";
my $webserver = "nom.du.webserver";
my $textmap_path_sur_webserver = "/etc/apache2/mass_vhosting/";


open(PASSWD,$passwd_file);

while (<PASSWD>)
{
       
# Pour FreeBSD
#($login,$crypt_pass,$uid,$gid,$rien,$zero1,$zero2,$gecos,$homedir,$shell)=split(/:/);
# Pour Linux
($login,$crypt_pass,$uid,$gid,$gecos,$homedir,$shell)=split(/:/);
       # On ne prend pas en compte les login qui contienne des
       # caracteres bizarres ("+", etc.)
       # car ce ne sont pas des comptes de personnes...
       if ($login =~ /^[a-zA-Z0-9]*$/)
       {
               $homedir{"$login"}=$homedir;
       }
}
close(PASSWD);

open(ALIASES,$aliases_file);
open(PRENOMDOTNOM2HOMEDIR,">$prenomdotnom2homedir_file");

foreach $login (keys %homedir)
{
       open(ALIASES,$aliases_file);
       while (<ALIASES>)
       {
               # Si on tombe sur la ligne xxxxx : login, c'est banco
               # car le début de ligne avant le ":" est prenom.nom
               if (/^\s*([a-zA-Z\.]*)\s*:\s*$login\s*$/)
               {
                       $prenom_dot_nom = $1;
                       # On passe en minuscules
                       $prenom_dot_nom =~ tr/A-Z/a-z/;
                       print PRENOMDOTNOM2HOMEDIR $prenom_dot_nom."\t".$homedir{"$login"}."\n";
               }
       }
       close(ALIASES);
}


close(PRENOMDOTNOM2HOMEDIR);

# On copie où il faut sur le serveur web
system("scp $prenomdotnom2homedir_file root\@$webserver:$textmap_path_sur_webserver") and die("Impossible de scpiser $prenomdotnom2homedir_file vers $textmap_path_sur_webserver sur le compte root de $webserver");

# On detruit le fichier desormais inutile
unlink($prenomdotnom2homedir_file);
  • LDAP

C’est plus simple. On extrait les deux infos prenom.nom et homedir directement de l’annuaire LDAP et le script tourne directement sur le serveur web.
Ici on filtre avec l’attribut supannAffectation qui fait partie du schéma LDAP Supann et qui désigne l’UFR. Pour une structure moins universitaire, adaptez votre filtre.
Pour obtenir le prenom.nom, on coupe avant le @ la valeur de l’attribut MailLocalAddress [1]]. Il y a d’autres façons de faire, selon la politique du gestionnaire de l’annuaire (quels sont les attributs dont on est sûr i.e. nom modifiable par l’utilisateur, non multivalués, etc.)

#!/usr/bin/perl -w
 use strict;
 use Net::LDAP;

#### CONF
my $supannAffectation = "Mon UFR";
my $PrenomDotNom2HomedirFile = "/etc/apache2/mass_vhosting/prenom.nom2homedir.ldap.txt";

 my $mesg;

 my $ldap = Net::LDAP->new("mon_serveur_ldap", port => 389, version => 3)
    or die "erreur LDAP: Can't contact master ldap server ($@)";

 $mesg = $ldap->bind();
 $mesg->code && die $mesg->error;

 $mesg = $ldap->search(
   base   => 'dc=mon,dc=domaine',
   scope  => 'sub',
   filter => "(supannaffectation=$supannAffectation)"
 );
 $mesg->code && die $mesg->error;

 open(MAPFILE,">$PrenomDotNom2HomedirFile");
 foreach my $entry ($mesg->all_entries) {
    my $PrenomDotNom = $entry->get_value("maillocaladdress");
    # On coupe juste avant le @...
    $PrenomDotNom =~ s/([^@].*)@.*/$1/;
    # On enleve les eventuels .1 (ou 2,3,n) en fin d'adresse pour les doublons
    if ($PrenomDotNom =~ /[0-9]/)
    {
       $PrenomDotNom =~ s/(.*)\.[0-9]*/$1/;
    }
    print MAPFILE $PrenomDotNom."\t";
    print MAPFILE $entry->get_value("HomeDirectory")."\n";
 }

close(MAPFILE);

 $ldap->unbind();

[AJOUT DU 28/08/2007] Le problème épineux de la redirection

Ce problème m’est apparu 1 an après la mise en place. Imaginez qu’un utilisateur, disons Jean Valjean, vous demande de rediriger sa page http://jean.valjean.perso.mon.domaine/articles vers http://laboXX.autre.domaine/~jvaljean/recherche.

Pour un serveur classique, i.e. sans mass virtual hosting, ça serait très simple : insertion d’une directive Redirect dans le fichier de conf du VirtualHost.

Mais dans notre cas, c’est plus complexe : en effet les directives Redirect prennent en argument un URL PATH commençant par un /, donc la partie de l’URL qui est APRÈS http://nom.prenom.perso.mon.domaine . Dans le cas Jean Valjean ci-dessus, l’URL PATH serait /articles.

Donc, rediriger avec un Redirect /articles le redirigerait pour Jean Valjean MAIS AUSSI pour tous les autres utilisateurs qui ont un répertoire articles à la racine de leur espace web... Ennuyeux.

Donc, on va rediriger avec mod_rewrite, et c’est finalement assez simple.

À la suite des dernières règles de reécriture, c’est-à-dire

RewriteRule ^/(.*)$ ${prenom.nom2homedir:%1|/non_present}/public_html/$1
RewriteRule ^/non_present.*$ http://page_explication.mon.domaine

on va ajouter les redirections sous forme de RewriteRule. Notons que le motif sur lequel on va agir n’est plus un URL PATH, mais puisque la règle précédente a opéré la transformation via la RewriteMap, le chemin absolu, au sens système de fichiers Unix, vers le fichier ou répertoire demandé (on suppose qu’on est dans le cas d’un utilisateur légitime, et pas dans le cas "non_present").

Donc si on sait que le répertoire personnel de Jean Valjean est, par exemple, /home/miserables/jvaljean, la règle de reécriture qui va assurer la redirection voulue est la suivante :

RewriteRule ^/home/miserables/jvaljean/public_html/articles.* http://laboXX.autre.domaine/~jvaljean/recherche [R=permanent,L]

Le flag R indique qu’il s’agit là d’une redirection externe, que le modificateur permanent rend permanente : on obtient ainsi le même effet que la clause Apache <BIG>RedirectPermanent</BIG>.

Le flag L indique qu’il s’agit de la dernière règle de reécriture executée (permet de ne pas faire agir les règles suivantes sur le nouveau motif ; parfois TRÈS utile pour éviter les boucles...). Dans notre cas, puisqu’il s’agit d’une redirection externe sur une url déterminée, il est évidemment inutile de passer sur les règles suivantes.

Plus d’infos sur les flags de RewriteRule.

Et voilà... Facile non ? On peut même le voir tout de suite en vraie grandeur par exemple ici : http://gerard.milhaud.myspace.esil....


[1[Spécifique Université de la Méditerranée : on enlève aussi les .1 ou .2, .3, etc. qui peuvent se trouver en fin de prenom.nom au cas où prenom.nom est non unique dans l’annuaire...


Commentaires  (fermé)

Logo de DECLERCQ
mardi 24 octobre 2006 à 20h43 - par  DECLERCQ

Bonsoir ;

Ne vous inquiétez pas, je ne suis pas vexé.

J’aurais juste une petite suggestion concernant cette ligne :

RewriteCond %HTTP_HOST ^([a-z\-\.]+)\.(perso|myspace).*$ [NC]

Ne serait-il pas plus judicieux d’écrire ceci :

RewriteCond %HTTP_HOST ^([a-z\0-9\-\.]+)\.(perso|myspace).*$ [NC]

En effet, la ligne que vous donnez ne permet pas l’utilisation des chiffres dans le noms des comptes utilisateur. Je pense que cela pourrait poser problème pour certains.

Dans mon cas, cela m’a posé problème puisque que le sous-domaine php5info.france-hosting.fr ne pouvait pas être résolu.

Sinon, vous aviez effectivement raison, il m’a suffit de votre exemple de modification et un peut de lecture pour me rendre compte que ce n’est pas si compliqué.

Merci encore.

Bien cordialement ;

Monsieur Laurent DECLERCQ

Site web : nuxwin.com
Logo de G a.k.a Gérard Milhaud
mardi 24 octobre 2006 à 12h42 - par  G a.k.a Gérard Milhaud

Très franchement, je suis désolé d’avoir osé poser une question qui semble vous avoir fait perdre votre temps ! ! !

Encore une fois, je suis vraiement désolé d’avoir oser vous demander assistance.

Houla ! Ne vous vexez pas. Je reconnais avoir été un peu surpris de votre requête dans la mesure où la réponse est si proche de ce qui est écrit dans l’article que j’ai vraiment eu l’impression que vous n’aviez pas pris la peine de le lire sérieusement.

Il me semble avoir fait mon boulot d’internaute citoyen en essayant de publier un article aussi précis que je le pouvais sur la manip., pour essayer de faciliter la mise en oeuvre pour d’autres.

Je consacre très volontiers du temps à répondre à toute personne qui a un problème en tentant de mettre en oeuvre la solution décrite, mais moins à celle qui me demande carrément de lui faire le travail pour lui éviter, à elle, de consacrer du temps à lire un tout petit peu la doc...

Si votre demande n’est pas dans ce dernier cadre, alors c’est que je l’ai mal comprise et j’en suis désolé. J’espère dans tous les cas que ma réponse vous aura permis d’avancer dans la mise en place de votre solution.

Cordialement,

Gérard Milhaud.

Logo de DECLERCQ
mardi 24 octobre 2006 à 01h56 - par  DECLERCQ

Bonsoir ;

Très franchement, je suis désolé d’avoir osé poser une question qui semble vous avoir fait perdre votre temps ! ! !

Usuellement, c’est moi qui aide les utilisateurs pour qu’ils puissent disposer d’une plateforme LAMP fonctionnelle sur leur machine.

Ce faisant dans le cas présent, j’étais confronté à un problème qui réside dans le fait que je ne connais absolument pas la syntaxe employée par le module rewrite d’Apache bien que celle ci me fait penser à la celle employer par php pour ce qui concerne les expressions rationnelles.

Tout de même, je vous remercie de m’avoir répondu même si j’entrevois un certain manque de motivation de votre part.

En ce qui concerne la documentation Apache concernant le module rewrite, je la trouve pour ma part innaccessible à celui qui n’a jamais utiliser ce genre de syntaxe.

Encore une fois, je suis vraiement désolé d’avoir oser vous demander assistance.

Bien cordialement ;
Monsieur Laurent DECLERCQ.

Site web : Merci quand même
Logo de G a.k.a Gérard Milhaud
lundi 23 octobre 2006 à 09h15 - par  G a.k.a Gérard Milhaud

Ce que je décris ici est totalement indépendant du module userdir, je précise d’ailleurs dès le début que le but est de ne plus utiliser ledit module...

Votre problème est vraiment très proche de ce qui est décrit dans cet article... Vous n’avez pas dû avoir trop envie de réfléchir tout seul :)

Il vous suffit de générer la map texte pseudo2homedir du type

pseudo /var/www/virtual/pseudo/htdocs

à partir de votre BD MySQL, puis de changer (à peine...) les lignes de conf Apache fournies.

Bien que je vous le conseille, je pense que vous pouvez même éviter de lire la documentation associé au module rewrite qui vous inquiète...

Les deux règles de reécriture principales dans votre cas seront du style :


RewriteCond %{HTTP_HOST} ^([a-z\-\.]+)\.france-hosting.fr [NC]

RewriteRule ^/(.*)$ ${pseudo2homedir :%1}/$1

Attention, ici on agit sur TOUTES les requêtes en xxx.france-hosting.fr, puisque vous ne voulez pas ajouter un signe distinctif (type perso) dans l’URL pour discriminer...

Je ne détaille pas plus, le reste étant trivial entre les explications de l’article et les infos ci-dessus.

Bonne chance.

Logo de DECLERCQ
samedi 21 octobre 2006 à 01h01 - par  DECLERCQ

Bonjour ;

Je suis vraiment intérresssé par cette méthode mais pas vraiment pour les mêmes raisons.

Vous, vous utilisez cette méthode pour les comptes utilisateur unix. avec le module userdir d’apache.

En ce qui me concerne, je voudrais faire exactement la même chose pour la configuration suivante :

Pas d’utilisation du module userdir.

pseudo.france-hosting et non nom.prenom.perso.france-hosting.fr pour l’accès au répertoire de chaque espace d’hébergement.

les répertoires des utilisateurs se trouvent :

exemple pour l’utilisateur moi :

/var/www/virtual/moi/htdocs

ici, le public_html est remplacé par htdocs.

La liste des utilisateurs et homedir seraient récupéré dans une base mysql.

En s’appuyant sur votre méthode, je suis pratiquement certain que c’est facile de faire cela. Cependant, je ne connais pas assez le module rewrite d’apache.

Pourriez vous m’éclairer.

Merci.