Outils pour utilisateurs

Outils du site


serveur_lamp_opensuse

Serveur web Apache-PHP-MySQL avec sites "perso"

(Suse Linux 10.1, 10.2, 10.3, 10.3 x86_64 avec bureau KDE)

(modif 25/10/2007: post-installation de mysql sur la suse 10.3)

Objectif

Installer un serveur web “LAMP” (= “Linux-Apache-Mysql-PHP”) sur une machine SuSE Linux v10.1 ou 10.2 KDE, 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 n'utilise pratiquement pas la console!

Avertissements

On ne parle ici que d'un serveur web d'amateur sans enjeu financier, et ouvert sur internet seulement de façon occasionnelle!.

Il s'agit donc d'une machine linux “normale” avec graphique. C'est ce que je fais moi-même, et ça me permet non seulement de comprendre “comment ça marche”, mais aussi de mettre au point les sites que je transporte ensuite chez mon hébergeur professionnel (surtout quand il y a du PHP-MySQL). Cela me permet aussi, par exemple, de préparer les pages wiki, parce que j'ai installé “dokuwiki” (http://www.splitbrain.org/projects/dokuwiki). Cela me permet aussi d'avoir un serveur de musique et de radio web au sein de mon domicile, qui ne pourrait être public pour des raisons légales.

Si votre serveur devait être en ligne en permanence sur internet, il vaudrait mieux qu'il soit sur une machine dédiée (un pc de récupération par exemple), et sans graphique (pas de serveur X, donc pas de bureau graphique tel que KDE, 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 performance, de disponibilité (uptime) et sécurité deviennent critiques, et nécessitent de recourrir à des solutions professionnelles payantes, à la hauteur des risques commerciaux et financiers! Quel amateur pourrait se payer, par exemple, un certificat “verisign” à 1150 Euros HT par an?

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/ou de virus, page web qui imite un site bancaire pour voler des codes d'accès, vol d'informations de sites gouvernementaux ou commerciaux, attaques “DOS” d'autres sites, 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é!

Références documentaires

  • Manuel pour vsftp: voir les pages man de vsftpd et vsftpd.conf qui viennent avec le package vsftp

Configuration du réseau

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
  • derrière un routeur qui joue le rôle de passerelle internet,
  • avec un nom de machine interne (ici, “nesti.lan”)
  • et une adresse IP locale fixe (ici, “192.168.0.200”).
  • 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

Installation et configuration d'Apache2 et PHP5 avec yast

On lance yast → services réseau → serveur http

Une petite fenêtre propose d'installer apache2 et apache2-prefork –> on accepte –> l'installation se fait.

On accède à l'assistant serveur http page 1/5 (yast vous proposera votre adresse ip, et non la mienne!):

  • port 80 =Ok
  • écouter les interfaces 127.0.0.1 et 192.168.0.200 = Ok

Assistant page 2/5

  • Cochez au moins php5 puisque vous voulez PHP!

Assistant page 3/5

  • une liste de ligne de config: en général, c'est Ok, sauf l'adresse mail à mettre à jour (mettre la vôtre).

Assistant page 4/5

  • Hôtes virtuels à ajouter. Ne faites rien, vous pourrez les ajouter plus tard, quand le serveur marchera déjà.

Assistant page 5/5

  • Cochez pour démarrer apache à l'amorçage
  • Le reste est Ok
  • 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à.

Sortie de yast

Vérification: accéder à votre serveur par http://localhost ou par http://nesti.lan ou par http://192.168.0.200. Ça doit normalement donner une erreur “accès interdit”. Cela veut dire que votre serveur fonctionne, mais que vous n'avez aucune page d'index dans /srv/www/htdocs.

Avec konqueror en mode superutilisateur (=root) que vous trouvez ici: menu → système → gestion de fichier:

  • Accédez à /srv/www/htdocs. Clic droit → ajouter un nouveau .. fichier texte → que vous appelez “index.php”.
  • Clic droit sur le fichier index.php que vous venez de créer → ouvrir avec → utilitaires → éditeur → kate (ou kwrite)
  • Ajouter les lignes suivantes:
<?php
phpinfo();
?>  

NB: c'est ”<?php“ comme ici ou ”<?“: vous prenez ce qui fonctionne chez vous.

  • enregistrez et sortez de l'éditeur

Relancez maintenant votre navigateur, avec les adresses de votre machine: il doit afficher la configuration complète apache-PHP.

Mais si vous regardez bien, vous n'avez pas encore mysql: c'est l'objet du chapître suivant!

Installation et configuration de mysql5 par yast

Avec yast, ajoutez les rpm:

  • mysql
  • php5-mysql

Après l'installation, il faut activer mysql: prenez yast → système → éditeur de niveau d'exécution, trouvez la ligne “mysql” et demandez l'activation (le bouton en bas).

Pour la suite de la “post-installation”, il y a des changements, et je donne les 2 situations:

1er cas: méthode ancienne

Lors de la 1ère activation de mysql, il vient alors une petite fenêtre importante: elle donne des instructions de configuration de mysql. Prenez-en note. La chose la plus importante est celle-ci: il faudra après l'activation donner un mot de passe à root (ce root n'est pas le même que celui de linux: donnez un autre mot de passe!)! Une fois l'activation terminée, faites donc cette opération comme demandée:

# /usr/bin/mysqladmin -u root password donnezlemotdepasseroot
# /usr/bin/mysqladmin -u root -h nesti.lan password donnezlemotdepasseroot  

2ème cas: méthode récente

Dans ce cas, lors de la 1ère activation de mysql, il n'y a rien d'autre qu'un message de réussite du démarrage.

Dans une console sous root, il faut faire:

# mysql_secure_installation

Il vient alors des infos et des questions pour sécuriser votre mysql:

  • donner un mot de passe au root de mysql (ce root n'est pas le même que celui de linux: donnez un autre mot de passe!),
  • empêcher l'accès anonyme,
  • réserver l'accès root à localhost (donc d'empêcher l'accès root à partir d'une liaison distante),
  • supprimer la base de donnée “test”,
  • etc…

Cette méthode moderne est très bien: elle traite d'un seul coup la plupart des problèmes de sécurité de base. Elle est seulement très très mal documentée (je l'ai cherché un moment…).


Il faut ensuite relancer apache. Faites-le avec l'éditeur de niveau d'exécution, puisque vous l'avez sous la main: désactivez et réactivez la ligne “apache2”.

Vous auriez pu le faire aussi avec la console sous root, avec:

# rcapache2 restart  

Voilà, c'est fait: vous avez votre serveur web “LAMP”: Linux-Apache-Mysql-PHP.

Vérification: appelez de nouveau votre serveur avec ses adresses (voir plus haut). Votre page index.php doit vous donner la config complète de votre serveur web, y compris bien sûr l'apparition de la config de mysql que vous n'aviez pas avant.

Pour administrer mysql et les bases de données, je vous suggère d'installer mysql-administrator ou phpmyadmin. Il sont tous les 2 dans les packages de la suse.

Pour installer mysql-administrator avec la suse 10.2 et 10.3, il n'y a aucun problème, mais avec la suse 10.1, il manque un package en dépendance: mysql-gui-common-0.6.0-15.i586.rpm. Il faut aller le chercher ici: http://suse.mirrors.tds.net/pub/opensuse/distribution/SL-10.1/inst-source/suse/i586/mysql-gui-common-0.6.0-15.i586.rpm . Vous le placez quelque part. Moi, je le mets dans /ressources/progsup/mysql. Vous pouvez l'installer:

  • si vous avez une version ancienne de la suse 10.1, vous faites dans une console sous root et en vous plaçant dans le répertoire du rpm:
# rpm -ivh mysql-gui-common-0.6.0-15.i586.rpm  
  • si vous avez la dernière version de la suse 10.1 (et que vous utilisez toujours yast-zmd), prenez konqueror en mode root, sélectionnez le rpm, clic droit, ouvrir avec.. “installation de logiciels” et c'est zmd qui installera.

Vous pouvez ensuite installer mysql-administrator avec yast comme pour la suse 10.2 et 10.3.


Désormais, vous pouvez administrer mysql et vos bases de données avec menu → système → “MySQL administrator” (cherchez un peu: ça peut changer selon les versions).

Ajout de sous-domaines (hôtes virtuels)

Sous-domaine: qués acco ?

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.

Activation des hôtes virtuels par nom.

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

NameVirtualHost 192.168.0.200

Création des hôtes virtuels

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!):

Résolution de nom en local

Quand on a un réseau local, on aimerait bien pouvoir appeler le serveur web qu'on vient de créer (domaine et sous-domaines), avec leur 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  

A noter qu'on peut avoir plusieurs lignes pour la même machine:

192.168.0.200    nesti.lan

192.168.0.200    linux.nesti.lan  photos.nesti.lan  

Mais il faut faire cela sur TOUTES les machines (windows et linux) de votre réseau local si vous voulez que chacune de ces machines puisse appeler chacun des sites virtuels de votre serveur par son nom. Et chaque ajout d'un nouveau site virtuel sur votre serveur entrainera une mise à jour des fichiers hosts de tous les machines.

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).

Installation des sites "perso"

On veut ici pouvoir affecter une zône 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).

Faire reconnaître les comptes utilisateurs par apache

Plutot que de bricoler les fichiers de config, nous allons modifier sysconfig avec yast:

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

Sélectionnez 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électionnez la variable APACHE_MODULES et vérifiez qu'il y a bien “userdir” dans la liste des modules. Sinon, le rajouter.

Validez. 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 tout cela:

Mise en place des hôtes virtuels

Ici, on veut pouvoir appeler le site perso qu'on vient de créer 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.

Compléments pour faciliter l'administration des sites

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

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.

Installation et configuration du serveur ftp "vsftp"

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.

Installation de vsftp

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 et 10.2, 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).

Création de l'utilisateur système qui pourra accéder au site principal par ftp

Le serveur vsftp peut accepter 3 types de liaison ftp:

  • liaisons anonymes
  • liaison sécurisée (chroot, login, …) pour ceux qui ont déjà un compte sur la machine linux
  • liaison sécurisée pour d'autres personnes n'ayant pas de compte sur la machine linux (=utilisateurs virtuels)

Ici, nous ne 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).

Configuration de vsftp

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 (très) 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)

Droit d'accès des fichiers et des répertoires du site

Petit rappel des aspects étranges des droits d'accès

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).

Cas des fichiers du site téléchargés sur le serveur

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.

Cas des fichiers créés ou modifiés par PHP

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 (vous retirez les guillemets qui entourent chaque ligne):

<?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 du site, 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 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 être modifiés par des scripts php,
  • et d'élargir à chmod 777 les droits des répertoires dans lesquels des scripts php voudront créer, renommer ou effacer des fichiers ou des répertoires.

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!

Appel des sites web par internet

Ouverture du parefeu

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.

Adresse IP internet fixe

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…

Adresse IP internet variable

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 volontaires 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.

Conclusion

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 en permanence sur le web est attaqué en permanence: il doit donc être renforcé sur le plan sécurité et surveillé fréquemment!

Amusez-vous bien!

serveur_lamp_opensuse.txt · Dernière modification: 2008/01/22 19:35 par tyrtamos

Outils de la page