[édition initiale Tyrtamos; modifié nov 2006; déc 2006]

Application sur openSuse 11 avec bureau KDE

On ne parle ici que d'un serveur web d'amateur sans enjeu financier, utilisé surtout sur le réseau local, et ouvert sur internet seulement de façon occasionnelle!

Si ce serveur devait être en ligne en permanence sur internet, il faudrait qu'il soit sur une machine dédiée, et sans graphique (pas de serveur X, ni KDE ni gnome,…), et vous ne pourriez pas appliquer ce tuto qui utilise à fond KDE pour installer le serveur. Et il faudrait dans ce cas travailler beaucoup plus la sécurité.

Pour un serveur professionnel de production, les préoccupations de sécurité deviennent critiques, et nécessitent de recourir à des solutions professionnelles!

Mais même pour un serveur web d'amateur, il faut avoir conscience qu'en cas de piratage, le risque principal pour vous n'est pas la destruction du serveur (conséquences = orgueil blessé + quelques heures de réinstallation), mais son utilisation comme relais pour des actions illégales: diffusion de spams et de virus, page web qui imite un site bancaire pour voler des codes d'accès, piratage de sites gouvernementaux ou commerciaux, diffusion d'images pédophiles, etc… Conséquences = actions en justice possibles, avec grosses amendes à 6 chiffres et prison à la clé! Il faut donc non seulement travailler la sécurité avec sérieux, mais aussi surveiller fréquemment votre site afin de réduire la durée d'activité du piratage s'il a eu lieu.

Attention: je ne suis pas un expert en sécurité des serveurs web (mais je me soigne…). Ce que vous ferez à partir de cette page sera sous votre entière responsabilité!

Installer un serveur web “LAMP” (= “Linux-Apache-Mysql-PHP”) sur une machine OpenSuSE v11 avec:

• un site principal, avec ou sans sous-domaine(s)

• des sites persos, avec ou sans sous-domaine(s), que les détenteurs de comptes linux peuvent gérer en tout autonomie

• mise à jour des différents sites à distance grâce à un serveur ftp “vsftp” sécurisé.

Pour tout cela, on arrive à ne pratiquement pas toucher à la console!!!

Manuel apache v2.0 (partiellement en français): http://httpd.apache.org/docs/2.0/

Manuel PHP v5.0 (en français): http://www.php.net/manual/fr/

Manuel MySQL v5.0 (en français): http://mysql.com/doc/refman/5.0/fr/index.html

On va supposer ici que votre réseau local est correctement configuré, et que vous êtes dans une configuration classique:

• une machine linux sur laquelle vous voulez créer le serveur web

• et une adresse IP locale fixe.

• derrière un routeur qui joue le rôle de passerelle internet,

• votre adresse IP internet peut être fixe, ou réaffectée à chaque nouvelle connexion avec votre FAI.

• vous pouvez avoir ou pas d'autres machines linux ou windows au sein de votre réseau local

• Yast >Installer et supprimer des logiciels
• Filtre > Schéma
• Sélectionner “Serveur Web et Lamp”

De cette manière sera installé automatiquement php5, mysql et apache.

Vous allez ajouter le package “phpmyadmin” qui va vous permettre de configurer vos bdd graphiquement.

Dans “yast”,

• services réseau,
• cliquer sur l'icône “serveur http”

Un assistant démarre.

Laisser la configuration par défaut ou l'adapter en connaissance de cause.

• port 80

• écouter les interfaces 127.0.0.1 et x.x.x.x

• ouvrir un port dans le pare-feu = oui s'il doit être accessible sur le web

• Cocher php5

• Adresse mail à modifier par la vôtre

• Ne rien changer

• Démarrer apache à l'amorçage (à cocher)

• cliquez sur “configuration du serveur http pour expert → onglet “modules du serveur” → ajoutez les modules que vous souhaitez. Je vous conseille de n'en rien faire maintenant: vous pourrez les ajouter après quand le serveur marchera déjà.

Cliquer sur “Terminer”

Une consultation régulière de vos logs vous permettra de mieux appréhender votre serveur (au niveau de la résolution des erreurs du serveur).

Les logs se trouvent :

/var/log/apache2

Note :

Prenez pour habitude d'avoir une fenêtre qui affiche vos logs dans un terminal. Faites un « tail -f /var/log/apache2/error_log » qui affichera les 10 dernières lignes de votre log en temps réel.

rcapache2 start

Vous pouvez maintenant accéder à votre serveur web par :

• http://localhost
• http://127.0.0.1.

Une page “It works” devrait apparaître.

La page “index.html” qui est affiché se trouve dans le répertoire “/srv/www/htdocs.”

Pour accéder à la configuration détaillé de votre serveur apache, nous allons créer un fichier phpinfo.

Dans “htdocs”,

vi phpinfo.php

<?php
phpinfo();
?>

Enregistrer.

Dans votre navigateur, entrer l'url “http://localhost/phpinfo.php”

Verifier que le service Sql est bien installé :

rcmysql status

Vous devriez voir apparaître en regard “unused”.

Pour démarrer le service :

rcmysql start

Par défaut, il n'y a “pas de mot de passe” “root” défini pour pouvoir accéder à la base de donnnée.

Définir un mot de passe “root” :

mysqladmin password "rootpassword"

Note : le mot de passe sera changé pour l'utiliateur qui éxecute la commande.

Pour vérifier que le nouveau mot de passe est bien effectif :

mysql -p

Note : Une fois le code saisi, vous devriez être connecté à la base de donnée.

Le package “phpmyadmin” va vous permettre de configurer la base de donnée plus facilement. (en interface graphique)

Dans “yast”,

• Installation de logiciels,
• Sélectionner “Phpmyadmin”

ou

 yast2 –install phpMyAdmin

Un répertoire “phpMyAdmin” vient de se crée dans “/srv/www/htdocs”

Pour configurer “phpMyAdmin”, il va falloir utiliser un fichier de configuration.

Dans le répertoire “phpMyAdmin”, faire :

cp config.sample.inc.php config.inc.php

vi config.inc.php

Dans le fichier de configuration, spécifier à la directive “$cfg['blowfish_secret']” un mot (peu importe).

• Redémarrer le serveur apache.

Pour démarrer “phpMyAdmin”, ouvrir un navigateur web et inscrire “http://localhost/phpMyAdmin”

Vous avez un site http://nesti.lan qui se trouve dans /srv/www/htdocs. Rien ne vous empêche de créer un autre site appelable, par exemple, par http://nesti.lan/toto et situé dans le répertoire /srv/www/htdocs/toto. Mais si vous voulez donner plus d'autonomie à ce site “toto”, vous allez créer, grâce aux hôtes virtuels, un sous-domaine que vous pourrez appeler http://toto.nesti.lan. Sur de nombreux points, ce site aura une existence autonome en tant que site, et pas seulement en tant que répertoire du site principal.

Dans /etc/apache2/listen.conf, ajouter à la fin la ligne (vous mettez l'adresse ip de votre machine!):

NameVirtualHost 192.168.0.200

On va créer, par exemple, les sous-domaines “linux” et “photos” sur le serveur web local http://nesti.lan, qu'on pourra donc appeler par http://linux.nesti.lan et par http://photos.nesti.lan

On crée les répertoires “linux” et “photos” dans /srv/www/htdocs.

On ajoute un nouveau fichier “meshotesvirtuels.conf” (éditeur de texte sous root) dans /etc/apache2/vhosts.d, et contenant:

# ---> Site principal

<VirtualHost 192.168.0.200>

ServerName nesti.lan

ServerAlias nesti.dyndns.org

DocumentRoot /srv/www/htdocs

</VirtualHost>

#

# ---> Site du sous-domaine "linux"

<VirtualHost 192.168.0.200>

ServerName linux.nesti.lan

ServerAlias linux.nesti.dyndns.org

DocumentRoot /srv/www/htdocs/linux

</VirtualHost>

#

# ---> Site du sous-domaine "photos"

<VirtualHost 192.168.0.200>

ServerName photos.nesti.lan

ServerAlias photos.nesti.dyndns.org

DocumentRoot /srv/www/htdocs/photos

</VirtualHost>

Pour éditer ce fichier sous root, restez sous KDE: prenez konqueror en superutilisateur (menu → système → gestion de fichiers), clic droit dans le répertoire /etc/apache2/vhosts.d, ajouter un nouveau fichier. Vous donnez son nom (meshotesvirtuels.conf). Ensuite, clic droit sur ce nom, ouvrir avec, utilitaires, éditeurs, kate ou kwrite. En ouvrant l'éditeur à partir de konqueror sous root, vous l'ouvrez sous root.

A noter que, dès qu'on met en action des hôtes virtuels, il faut redéfinir le site principal (celui de /srv/www/htdocs) en hôte virtuel, sinon, on ne l'a plus! Ça peut être voulu, mais pas forcément. Si on n'en a pas besoin pour mettre un site, on peut s'en servir au minimum pour mettre une page d'erreur afin de signaler une demande d'hôte virtuel inexistant (ex: http://hqfgufhfhd.nesti.lan). et ceci à condition que le serveur de nom utilisé permette les jokers (wildcard) et récupère donc les adresses du genre http://nimportequoi.nesti.lan Pour ma part, j'utilise le site principal pour présenter les différents sites hébergés (ex: http://www.jpvweb.com) et tous les vrais sites sont en sous-domaines (ex: http://linux.jpvweb.com).

Autre remarque, la ligne de la directive “ServerAlias” prépare l'appel du site (domaine ou sous-domaine) par l'extérieur. Comme mon adresse IP internet n'est pas fixe, j'utilise les services de dyndns.org. Si on a une ip fixe, on peut mettre ici comment on appelle le site à partir d'internet.

Relance du serveur apache avec l'éditeur de niveau d'exécution (désactivation/réactivation), ou en console sous root:

rcapache2 restart

Vérification (il doit y avoir un fichier index.html ou index.php dans chaque site pour que ça marche!):

• http://nesti.lan —> appelle le site principal situé dans /srv/www/htdocs

• http://linux.nesti.lan —> appelle le sous-domaine “linux” situé dans /srv/www/htdocs/linux

• http://photos.nesti.lan —> appelle le sous-domaine “photos” situé dans /srv/www/htdocs/photos

Quand on a un réseau local, on aimerait bien pouvoir appeler les sites du serveur web qu'on vient de créer (domaine et sous-domaines), avec leurs noms, et pas seulement avec l'adresse ip et les sous-répertoires. C'est quand même mieux d'appeler http://linux.nesti.lan que http://192.168.0.200/linux.

Contrairement à ce qu'on pense, il n'est pas nécessaire d'avoir un serveur dns local, sauf si on a un “gros” réseau local.

C'est simple: la correspondance entre d'un côté les noms de domaines et de sous-domaines, et de l'autre l'adresse IP locale du serveur, se trouve dans le fichier texte “hosts”:

• /etc/hosts pour linux

• c:\windows\system32\drivers\etc\hosts pour windows xp

Dans les 2 cas, on doit trouver une ligne comme (pour l'exemple ci-dessus):

192.168.0.200    nesti.lan  linux.nesti.lan  photos.nesti.lan

Mais il faut faire cela sur TOUTES les machines de votre réseau local!

Si vous aviez plusieurs machines dans votre réseau local, un serveur dns local pourrait vous épargner de mettre à jour tous les fichiers hosts à chaque fois que vous ajoutez 1 sous-domaine supplémentaire. Mais si vous n'avez que 2 ou 3 machines, ça ne vaut pas le coup.

Un vrai serveur dns local, comme bind9, par contre, serait plus rapide pour les échanges au sein de votre réseau local. A défaut, je vous suggère d'utiliser des adresses IP locales fixes pour gagner le temps de la résolution de nom.

Par ailleurs, si vous avez une adresse IP internet fixe, un vrai serveur dns local vous permettrait d'être appelé à partir d'internet par le nom de domaine que vous auriez acheté (voir plus bas pour des compléments).

On veut ici pouvoir affecter une zone personnelle, dans laquelle un utilisateur ayant un compte linux pourra installer son site web et le gérer de manière autonome, avec un nom spécifique de type sous-domaine (ex: http://tyrtamos.nesti.lan).

Plutôt que de bricoler les fichiers de configuration, il faut modifier sysconfig avec yast:

• yast → système → éditeur pour fichier sysconfig → network → www → apache2

Sélectionner la variable APACHE_CONF_INCLUDE_FILES et lui ajouter: “mod_userdir.conf”. Les modules sont séparés sur la ligne par des espaces.

Sélectionner la variable APACHE_MODULES et vérifier qu'il y a bien “userdir” dans la liste des modules. Sinon, le rajouter.

Valider. A la sortie, yast fait ce qu'il faut pour relancer la machine.

Modifiez ensuite le fichier de configuration /etc/apache2/mod_userdir.conf que vous venez d'ajouter avec yast (à éditer sous root). Décommentez la ligne:

UserDir public_html

N'essayez pas de modifier le nom du répertoire “public_html”: il est défini lors de la compilation d'apache.

Comme c'est indiqué dans ce même fichier, vous pouvez restreindre l'ouverture des comptes persos à certains utilisateurs seulement en faisant:

UserDir disabled

UserDir enabled user1 user2

Vous pouvez aussi ajuster, spécifiquement pour les sites persos, les directives “AllowOverride” (pour donner les possibilités des fichiers .htaccess) et “Options”.

Pour des raisons de sécurité, il est hautement déconseillé de permettre à root de faire son site perso! Aussi, laissez décommentée la ligne suivante:

UserDir disabled root

Et relancez apache avec l'éditeur de niveau d'exécution (désactivation/réactivation), ou en console sous root:

rcapache2 restart

Après ces modif:

• http://nesti.lan donne toujours le site situé dans: /srv/www/htdocs

• http://nesti.lan/~tyrtamos donne le site situé dans: /home/tyrtamos/public_html

Ici, on veut pouvoir appeler le site http://nesti.lan/~tyrtamos comme suit: http://tyrtamos.nesti.lan

On reprend le fichier des hôtes virtuels construit plus haut, et on ajoute les hôtes virtuels correspondant aux sites perso. Par exemple pour le site perso affecté à Tyrtamos:

<VirtualHost 192.168.0.200>

ServerName tyrtamos.nesti.lan

ServerAlias tyrtamos.nesti.dyndns.org

DocumentRoot /home/tyrtamos/public_html

</VirtualHost>

On peut aussi utiliser les sous-domaines à l'intérieur des sites perso. Par exemple, pour un site de sous-domaine “musiques” situé dans /home/tyrtamos/public_html/musiques, ajouter (après avoir créé le répertoire “musiques”):

<VirtualHost 192.168.0.200>

ServerName musiques.nesti.lan

ServerAlias musiques.nesti.dyndns.org

DocumentRoot /home/tyrtamos/public_html/musiques

</VirtualHost>

On aurait pu choisir “musiques.tyrtamos.nesti.lan”, à part que ça commence à être long comme adresse.

Par défaut, l'activité et les erreurs d'apache pour tous les sites sont enregistrées ici:

• /var/log/apache2/error_log

• /var/log/apache2/access_log

Si on veut suivre certains sites de manière particulière, ou si on veut qu'un utilisateur puisse suivre ses sites perso, on peut compléter les instructions précédentes dans les hôtes virtuels concernés par:

• l'adresse mail de l'administrateur du site. exemple:

    ServerAdmin tyrtamos@nomdedomaine.com

• et les adresses des fichiers log du site. Exemple (après avoir créé avant le répertoire “tyrtamos”):

    ErrorLog   /var/log/apache2/tyrtamos/error_log

    TransferLog    /var/log/apache2/tyrtamos/access_log

Relance du serveur apache avec l'éditeur de niveau d'exécution (yast), ou avec (dans une console sous root):

rcapache2 restart

A noter que si le serveur était un serveur de production en activité, on pourrait se contenter d'un:

rcapache2 reload

ce qui permettrait à apache de tenir compte des nouveaux fichiers de configuration sans arrêter son fonctionnement.

Le serveur “vsftp” est un bon serveur ftp sécurisé (“vs” de vsftp = “Very Secure”) qui fait partie des packages disponibles avec la Suse v 10.1.

S'il n'est pas déjà installé, faites son installation avec yast.

Il peut être lancé soit en “standalone” (tout seul) soit par “xinetd” (services réseaux), à vous de choisir.

Sur la suse 10.1, il est maintenant pré-configuré en standalone, grâce à la ligne “listen=YES” à la fin du fichier de configuration /etc/vsftpd.conf. Dans ce cas, il doit être démarré par l'éditeur de niveau d'exécution (yast → système).

Si vous préférez qu'il se lance par xinetd, changer la ligne par “listen=NO” dans le fichier de configuration, et activez vsftp par xinetd (yast → services réseau). Mais vérifiez avant qu'il n'est pas déjà en exécution en standalone (si oui, désactivez-le), et vérifiez aussi qu'il n'y a pas d'autres serveurs ftp en fonctionnement (il ne doit y en avoir qu'un).

Le serveur vsftp peut accepter 3 types de liaison ftp:

1. liaisons anonymes

2. liaison sécurisée (chroot, login, ...) pour ceux qui ont déjà un compte sur la machine linux

3. liaison sécurisée pour d'autres personnes n'ayant pas de compte sur la machine linux (=utilisateurs virtuels)

Ici, nous voulons une chose précise: que la liaison ftp puisse permettre la lecture et l'écriture du répertoire du site principal web, avec une liaison sécurisée afin de pouvoir gérer le site web à distance. C'est donc le cas 2 qui nous intéresse. Nous allons donc créer de toute pièce un utilisateur système (et un groupe) dont le répertoire personnel sera srv/www !!! Nous l'appellerons, par exemple, utilisateur=ftpweb, groupe=ftpweb. Ainsi, la liaison établie avec son login nous amènera chrooté dans le /srv/ww sans possibilité d'accès au reste du système.

Il existe déjà un utilisateur système qui s'appelle “ftp”, dont le répertoire personnel est ”/srv/ftp“: ne l'utilisez pas pour le site web, car ce nom est réservé à l'utilisation de liaison anonymes.

Pour créer l'utilisateur système ftpweb et le groupe ftpweb, faites le par yast → sécurité et utilisateurs → “modifier et créer des groupes” puis “modifier et créer des utilisateurs”. (on peut d'ailleurs passer de l'un à l'autre par une coche: c'est le même programme)

Pour la partie groupe comme pour la partie utilisateur, demandez le filtre “système” (bouton en bas à droite), et faites “ajouter”. Pour l'utilisateur, il faut que son uid soit inférieur à 500 pour être un utilisateur système (donnez un nombre non utilisé comme 150 s'il vous propose un uid >500). Donnez-lui un “répertoire personnel” (= ”/srv/www“), un groupe par défaut (=ftpweb), un mot de passe, et une durée de mot de passe (99999).

Nous allons donc configurer notre vsftp pour donner un accès sécurisé à tous les utilisateurs ayant un compte linux, chacun étant chrooté dans son répertoire personnel, et donc aussi à ftpweb pour le site principal.

Si vous voulez empêcher certains utilisateurs d'accéder à leur zône utilisateur par ftp, il y a un moyen simple: le fichier /etc/ftpusers donne la liste des utilisateurs à interdire pour le ftp: il suffit d'ajouter les noms des utilisateurs à interdire. En consultant /etc/ftpusers, vous noterez d'ailleurs que root est déjà interdit: il a trop de privilège pour une simple liaison ftp!

La configuration de vsftp sera faite ici par édition (sous root) du fichier /etc/vsftpd.conf. Elle peut aussi être faite par webmin, à condition d'ajouter le module vsftp qui ne s'y trouve pas par défaut (on le télécharge directement sous webmin).

Il faut permettre l'écriture pour l'upload des pages web: on modifie la zone appelée “General Setting”. On dé-commente la ligne:

write_enable=YES

Il faut ensuite permettre l'accès utilisateur, c'est à dire permettre l'accès aux personnes qui ont un compte linux. Il s'agit de modifier la zone appelée “Local FTP user Settings”:

local_enable=YES

local_umask=022

chroot_local_user=YES

Vous noterez d'ailleurs que sur le plan sécurité, vsftp délègue l'autorisation d'accès à PAM (voir fichier /etc/pam.d/vsftp)

Compte tenu de l'objectif qu'on s'est donné, il faut en plus empêcher les accès anonymes en intervenant dans la section appelée “Anonymus FTP user Settings”:

anonymous_enable=NO

anon_mkdir_write_enable=NO

anon_other_write_enable=NO

Et il est souhaitable d'avoir un enregistrement de l'activité de vsftp pendant les connexions dans un fichier log pour détecter d'éventuelles anomalies. Dans la section appelée “Log Settings”:

syslog_enable=NO            ---> pour avoir un fichier log spécifique

log_ftp_protocol=YES        ---> pour avoir les traces des demandes-réponses du protocole

xferlog_enable=YES          ---> pour avoir l'activité de téléchargement (dans les 2 sens)

vsftpd_log_file=/var/log/vsftpd.log    pour préciser le fichier log à utiliser

Si voulez utiliser dans votre site web des fichiers cachés de type .htaccess, .htusers, .htgroups, etc… sachez qu'apache comme vsftp interdit leur affichage ainsi que leur téléchargement, et c'est heureux pour la sécurité. Mais si vous voulez les voir quand même sous vsftp, vous ajoutez:

force_dot_files=YES

Il existe de nombreux autres paramètres pour configurer plus finement vsftp (faites “man vstpd.conf” pour voir!), mais avec ceux ci-dessus, on répond au problème posé.

Il faut relancer vsftp afin qu'il utilise les nouvelles données de config. On relance selon le mode d'exécution:

• en mode standalone, avec l'éditeur de niveau d'exécution (désactivation/réactivation)

• en mode xinetd, avec xinetd (désactivation/réactivation)

Rappelons un aspect dont on aura besoin ici:

• les droits d'examiner ou de modifier le contenu d'un fichier ne dépendent que des droits du fichier lui-même (propriétaire:groupe et rw-r–r– par exemple),

• par contre, le droit de créer, de renommer ou d'effacer un fichier ne dépend que des droits du répertoire et particulièrement de son droit d'écriture “w”.

Cela donne des conséquences quelquefois surprenantes:

• sous votre login, et dans un répertoire vous appartenant avec rwxr-xr-x, vous pouvez placer par recopie un fichier root:root avec rw——-, le renommer et même le supprimer! Mais bien sûr, vous ne pouvez ni examiner ni modifier son contenu.

• sous votre login mais dans un répertoire ne vous appartenant pas avec rwxr-xr-x, vous ne pouvez pas y placer un fichier à vous. S'il y est déjà, vous ne pouvez ni le renommer ni le supprimer! Mais vous pouvez consulter son contenu et même le modifier.

Autre aspect qu'il faut rappeler:

• sous votre login, si le fichier vous appartient, vous ne pouvez pas modifier son propriétaire (c'est à dire l'affecter à quelqu'un d'autre), mais vous pouvez modifier son groupe (parmi ceux dans lesquels vous êtes déjà), ainsi que ses droits de lecture-écriture.

• sous votre login, si le fichier ne vous appartient pas, et même si vous avez le droit d'écrire dedans (rw-rw-rw-), vous ne pouvez modifier ni son propriétaire, ni son groupe, ni ses droits de lecture-écriture (et c'est très bien ainsi).

Les fichiers du site qui sont téléchargés sur le serveur web par liaison ftp, auront comme propriétaire, le login utilisé pour la connexion ftp, et comme groupe, le groupe par défaut du propriétaire en question: rappelez-vous que dans notre cas, le login de connexion ftp correspond à un compte linux.

• pour le site principal et ses sous-domaines: ftpweb:ftpweb (dans l'exemple du tuto)

• pour les sites utilisateurs et leurs sous-domaines: tyrtamos:users (dans l'exemple du tuto)

Pour ce qui concerne les droits de lecture-écriture, c'est en fait le serveur ftp qui les affecte, en fonction de la valeur qu'on a donnée dans le fichier de configuration /etc/vsftpd.conf. Comme on a mis “local_umask=022”, cela donnera un droit rwxr-xr-x (755) pour les répertoires et rw-r–r– (644) pour les fichiers.

Cela veut dire que seul ftp pourra écrire, et c'est très bien ainsi! Il y a pas de raison qu'un autre service, même apache lui-même, vienne modifier les fichiers de votre site. En effet, la règle est toujours de donner le minimum de privilèges aux différents services impliqués.

Le répertoire /srv/www/htdocs appartiendra aussi au login de ftp, même si on ne l'a pas “uploadé”. En effet, on a défini que le compte linux correspondant au login de ftp avait un répertoire personnel dans /srv/www. De ce fait, tous les fichiers présents à la création du compte, dont htdocs, ont été convertis. Vous verrez que cela a des conséquences pour PHP!

Dernier point: si vous avez un accès direct (physique ou par accès à distance type VNC ou FreeNX) au linux qui porte le serveur, évitez d'aller trifouiller dans les répertoires et les fichiers du serveur. N'oubliez pas que les logiciels d'application (dont apache) ne peuvent pas outrepasser les droits linux. Par exemple si avec konqueror sous root vous créez un répertoire root:root avec des droits rwx——, personne d'autre que root ne pourra rentrer dedans: voilà une partie de votre site que personne ne verra… La manière normale et reproductible d'intervenir sur votre site, sauf cas particulier bien sûr, est de le faire uniquement avec ftp, comme si ce site était hébergé ailleurs.

Les fichiers .php étant téléchargés comme les autres sur le serveur par ftp, ils auront donc aussi le propriétaire:groupe et les droits de lecture-écriture donnés par la connexion ftp.

Mais qu'en sera-t-il des fichiers créés ou modifiés par PHP? Eh bien, PHP travaille sous le propriétaire et le groupe d'apache, c'est à dire wwwrun:www.

Prenons un cas concret: un compteur de visite (simpliste): Je crée un fichier appelé “compteur.php” contenant:

<?php

$file=@fopen("count.txt", "r+");

fscanf($file, "%d", $count);

$count++;

rewind($file);

fputs($file, $count);

fclose($file);

?>

<p> <?php echo "visites=".$count ?> </p>

ainsi que le compteur lui-même comme un fichier texte “count.txt” contenant au départ le chiffre 0, et qui sera incrémenté à chaque fois que quelqu'un appellera la page.

Je télécharge les 2 fichiers sur le site par ftp, et j'appelle la page compteur.php dans un navigateur et… ça ne marche pas. Pourquoi? parceque wwwrun n'a pas le droit d'écrire dans count.txt: seul ftp le peut (voir plus haut)! Et par ftp, je ne peux pas changer le propriétaire (=login de la connexion ftp), mais je peux changer les droits de lecture-écriture. je mets donc des droits rw-rw-rw- (666) sur le fichier count.txt pour que wwwrun puisse écrire: et le compteur marche. Ce n'est pas très satisfaisant, mais tous les compteurs de visite basés sur ce principe que j'ai pu voir fonctionnent comme cela.

Alors, je me dis que si je faisais créer le fichier “count.txt” par le programme php de “compteur.php”, il aurait tout de suite le bon propriétaire (wwwrun), et je n'aurais pas le problème. Je modifie donc le script PHP pour que “count.txt” soit créé la 1ère fois par PHP. Mais ça ne marche pas non plus, parce que la création d'un fichier dans un répertoire n'est possible que si les droits sur le répertoire le permettent. Or le répertoire htdocs appartient au login de la connexion ftp, avec des droits rwxr-xr-x (755). Pour que la création du fichier soit possible, il faudrait que je mette les droits 777 sur le répertoire htdocs: c'est encore pire pour la sécurité, parce qu'il serait ainsi facile à un pirate de créer d'autres fichiers dans htdocs, ou d'effacer ceux qui y sont déjà… Je préfère élargir les droits de count.txt.

Tout cela pour dire qu'il sera inévitable:

• d'élargir à chmod 666 les droits des fichiers uploadés par ftp et devant recevoir des écritures php,

• et d'élargir à chmod 777 les droits des répertoires dans lesquels PHP devra créer de nouveaux fichiers ou les supprimer.

Quand aux applications écrites en PHP (CMS, forum, wiki, etc…), il est important de bien suivre leurs instructions d'installation:

• quand il est demandé de supprimer le répertoire d'installation après l'installation, il faut le faire! sinon, c'est un trou de sécurité.

• quand il est demandé de passer certains fichiers en 666 ou certains répertoires en 777: il ne faut le faire que pour les fichiers et répertoires mentionnés! Surtout, ne passez pas tout en 777!

Pour atteindre votre serveur web à partir du web, il faut bien sûr ouvrir votre parefeu en entrée pour le port 80 (port par défaut pour le web). Si vous avez un routeur qui vous sert de passerelle pour internet, et qui porte votre parefeu, vous devez en plus indiquer vers quelle machine les requêtes vers le port 80 doivent être redirigée: c'est l'adresse IP locale de votre serveur web.

Si votre fournisseur d'accès vous a affecté une adresse internet fixe, pas de problème: on peut donc atteindre votre serveur avec cette adresse ip externe. Mais il faut s'en rappeler…

Si vous voulez qu'on puisse appeler votre site avec le nom de domaine que vous avez acheté chez un registrar, vous avez 2 solutions:

1er cas: vous enregistrez une redirection chez votre registrar. Auquel cas à chaque fois qu'un navigateur appellera votre nom de domaine, le serveur dns de votre registrar redirigera la demande vers votre adresse IP. Mais c'est votre adresse IP qui sera en haut du navigateur du demandeur, et c'est votre adresse IP qui sera dans ses bookmarks.

2ème cas: vous avez un vrai serveur dns (bind) sur votre serveur web, et vous faites enregistrer l'adresse IP de votre serveur dns dans le serveur dns de votre registrar. Et vous devrez ouvrir votre parefeu pour le port 53. Auquel cas, ce n'est plus une redirection: votre serveur dns étant lié aux serveurs dns mondiaux, le nom de domaine sera traduit directement par votre adresse IP. C'est votre nom de domaine qui sera en haut du navigateur du demandeur, et qui sera dans ses bookmarks. Mais il faut un serveur dns perso…

Comme il n'y a plus assez d'adresses IP internet pour tout le monde, les FAI les affectent à chaque connexion. Pour certains FAI, il y a même une coupure volontaire toutes les nuits pour que les adresses “dormantes” puissent de nouveau être mises en circulation. Mais si vous avez une adresse IP internet qui change à chaque connection, il faut utiliser un “serveur dns dynamique”. J'en connais 2: dyndns et no-ip. Je décris ici le service de dyndns (http://www.dyndns.com) puisque c'est celui que j'utilise. Un petit bémol pour ceux dont le fournisseur d'accès bloque le port 80 en entrée (en amérique du nord en particulier): il y a des solutions à trouver avec “no-ip”.

Le principe est simple: vous utilisez un nom de type http://nesti.dyndns.org (nesti est déjà pris par moi !!!) et votre routeur, ou un programme de votre machine, renseigne le serveur de dyndns.org à chaque fois que votre FAI vous affecte une autre adresse IP internet. Chez moi, c'est mon routeur netgear qui renseigne dyndns de l'adresse IP qui m'est affectée.

Il faut d'abord obtenir un nouveau nom de type http://xxxxx.dyndns.org en ouvrant un compte (gratuit) sur le site http://www.dyndns.com . Il y a d'ailleurs beaucoup d'autres noms “racine” que vous pouvez utiliser, tels que: http://xxxxx.is-a-chef.com !!!!

Une fois que c'est fait, et dans la mesure ou vous avez ouvert le port 80 de votre parefeu en entrée et en direction de votre machine serveur, et que vous avez un serveur apache en état de marche, un appel http://xxxxx.dyndns.org appelle directement votre serveur apache à partir du web.

Si vous avez configuré des hôtes virtuels que vous voulez appeler par (par exemple) http://tyrtamos.xxxxx.dyndns.org, il faut cocher la case “wildcard” sur votre compte dyndns. A partir de ce moment, toutes les requêtes du genre http://nimportequoi.xxxxx.dyndns.org viendront sur votre serveur, et c'est apache qui les acheminera vers le bon site grâce aux hôtes virtuels (et grâce à leurs directives “ServerAlias”). Et si aucun hôte virtuel ne correspond, c'est le site principal /srv/www/htdocs qui récupérera la requête.

Voilà, c'est fait! vous avez un bon serveur web de base qui vous permettra de porter des sites déjà assez sophistiqués grâce à PHP et à MySQL (blog, forum, wiki, streaming, etc…).

Sa puissance et ses fonctionnalités sont tout à fait comparables à ce que vous pouvez trouver chez des hébergeurs professionnels en tant qu'hébergement mutualisé, à part que:

• vous pourrez avoir 200Go de données sur votre site si vous voulez,

• mais vous aurez la limite de débit de l'upload de votre ligne ADSL.

Vous pouvez aussi héberger les sites de vos amis en leur donnant la possibilité de les administrer eux-mêmes à distance, tout en limitant les risques qu'ils vous abime le système.

Mais rappelez-vous: un serveur web mis en ligne sur internet est attaqué en permanence: il doit donc être renforcé sur le plan sécurité et surveillé fréquemment!

Amusez-vous bien!

Tyrtamos