Après avoir monté votre premier serveur web, vous pouvez être amené à devoir le maintenir et à travailler un peu dessus pour l’améliorer, l’optimiser, le changer, le migrer, bref, faire des trucs assez sympathiques avec votre serveur. Etant en plein travail sur ce sujet, voici un petite liste des commandes indispensables (ou pas) pour bien débuter dans l’administration de votre serveur Debian.Lire la suite de

Il peut arriver certains cas où vous avez tout intérêt à définir des variables spécifiques à votre environnement de développement ou de production tout en gardant exactement le même code pour votre application (dans le cas de l’utilisation de git par exemple, ou simplement si vous travaillez en local avant la mise en production). Plus concrètement, vous pouvez vouloir changer les informations de connexion à votre base de donnée en fonction de votre environnement sans que ça impact votre code.

La solution la plus commune reste alors à déterminer dans votre code dans quel environnement vous vous trouvez :

if($_SERVER['HTTP_HOST'] == 'localhost') {
    // Environnement de développement
} else {
    // Environnement de production
}

Mais très honnêtement, cela peut apporter son lot de complications. A savoir, devoir modifier et redéployer son application à chaque changement pour le moindre environnement par exemple, ou ça devient vite ingérable si vous en utilisez plusieurs.

Une solution bien plus simple existe alors. Pour cela, il suffit de déclarer vos variables directement à l’intérieur même de votre environnement et simplement de les récupérer de manière transparente dans votre application. Pour cela, il suffit d’utiliser en PHP la fonction getenv($var) pour récupérer la variable $var que vous aurez déclaré dans votre votre vhost apache ou votre htaccess à l’aide de la commande SetEnv $var value

Exemple

Pour illustrer cette méthode, nous allons imaginer une application déployée sur 2 environnements différents. La première plateforme est celle de développement répondant à l’URL http://dev.application.com et devra se connecter sur le serveur de base de donnée de développement 123.456.789.0. La seconde plateforme est celle de production répondant à l’URL http://www.application.com et devra se connecter sur le serveur de base de donnée de production 123.456.789.1.

Vhost Apache :

# Développement
<VirtualHost *:80>
    ServerAdmin admin@application.com
    ServerName dev.application.com
    DocumentRoot /var/www/application/dev/

    SetEnv DBHOST 123.456.789.0
    SetEnv DBUSER application_dev
    SetEnv DBPASS application123
    SetEnv DBNAME application_dev

    <Directory /var/www/application/dev/>
        Options -Indexes FollowSymLinks MultiViews
        AllowOverride All
        Order allow,deny
        allow from all
     </Directory>
</VirtualHost>

# Production
<VirtualHost *:80>
    ServerAdmin admin@application.com
    ServerName www.application.com
    DocumentRoot /var/www/application/www/

    SetEnv DBHOST 123.456.789.1
    SetEnv DBUSER application_www
    SetEnv DBPASS application123
    SetEnv DBNAME application_www

    <Directory /var/www/application/www/>
        Options -Indexes FollowSymLinks MultiViews
        AllowOverride All
        Order allow,deny
        allow from all
     </Directory>
</VirtualHost>

Application PHP

$db = new PDO('mysql:host='. getenv('DBHOST').';dbname='.getenv('DBNAME'),
               getenv('DBUSER'),
               getenv('DBPASS'));

Et voila votre application communique maintenant avec votre environnement et est prête à être déployée où vous le voulez.

Lors de vos gros projets, il se peut que vous ayez à garantir la sécurité de votre site et donc avoir une copie exacte de tous vos fichiers et de vos données en permanence. Dans ce cas là, deux possibilités s’offrent à vous :

  • Le plan d’activité de reprise (PRA) : Vous utilisez un serveur maître qui gère le traffic des visiteurs et qui copie toutes ses données et tous ses fichiers sur un serveur esclave qui sera alors prêt à prendre la relève en cas de panne du serveur maître.
  • Le cluster : Vous utilisez deux ou plusieurs serveurs qui vont se répartir le traffic des visiteurs et s’assurer que toutes les données soient les mêmes partout.

Comment choisir votre architecture ? C’est plutôt simple. le PRA a l’avantage d’être peu coûteux par rapport au cluster qui nécessite un matériel spécifique (Load-Balancer, 70€/mois chez OVH contre 1€/mois pour l’IP Fail-over nécessaire au PRA) mais qui, lui, se révèle indispensable pour un projet à fort traffic (puisque les charges des serveurs sont répartis, vos visiteurs auront alors accès à un site plus fluide).

Pour ma part, pour le moment, je n’ai eu à m’occuper que de PRA, alors je voulais vous partager mon expérience. Nous avons déjà vu plusieurs étapes dans des tutoriaux précédents, je ne ferais donc que les citer.

Sommaires :

  • Etape 1 – Installation des serveurs web
  • Etape 2 – Configuration de l’IP Fail-Over
  • Etape 3 – Configuration du nom de domaine
  • Etape 4 – Réplication de la base de données
  • Etape 5 – Réplication des fichiers
Pour effectuer un PRA de base, nous aurons besoins :
  • Un nom de domaine avec ses accès DNS
  • Un IP Fail-Over (disponible chez OVH pour sa gamme de serveurs dédiés professionnels pour 1€HT/mois)
  • Deux serveurs web (pas forcément de la même capacité, il faut simplement qu’ils soient tous les deux accessibles par l’IP Fail-Over)
Pour l’installation d’un PRA, outre la propagation des DNS, comptez environs une heure de travail.

Etape 1 – Installation des serveurs web

Nous allons donc installer nos deux serveurs web, que nous appellerons S1 (pour le serveur maître) et S2 (pour le serveur esclave). Pour cela, pour vos deux serveurs, suivez ce tutoriel : [Tuto] Installer un serveur web sous Debian. Nous reviendrons sur les configurations d’apache plus tard. Pour ceux qui sont chez OVH, celui-ci vous permet de choisir un datacenter en particulier. Je vous conseille grandement de prendre vos deux serveurs dans des DC différents, histoire d’éviter que votre PRA soit mit à mal lors d’un incident physique sur le site.

Etape 2 – Configuration de l’IP Fail-Over

L’IP Fail-Over est un outil très pratique dans l’administration réseau. Celle-ci n’est en fait qu’une IP publique que vous pouvez faire rediriger votre l’IP privée de votre serveur (qui doit se trouver sur le même réseau). L’avantage, c’est qu’en un clic, et de manière presque instantanée, vous pouvez changer son IP de redirection. Fini donc les attentes longues des propagations DNS. Vous configurez votre nom de domaine pour que celui-ci pointe vers votre IP publique (ce qui peut prendre entre 30 minutes et 72 heures) une seule fois. A chaque changement de serveur, vous pourrez faire la modification d’IP rapidement, ce qui évite d’avoir des sites hors ligne de manière hasardeuse pendant quelques temps.

Commandez-donc votre IP fail-over que vous allez faire rediriger vers l’IP de votre serveur S1. Malheureusement, pour le moment, si vous tentez de vous connecter à cette IP, le serveur ne répondra pas. En effet, il va nous falloir configurer S1 et S2 pour accepter le traffic provenant de cette IP qui n’est pas la leur.

Pour cela, faites la manipulation suivante sur vos deux serveurs. Allez modifier le fichier « /etc/network/interfaces » et rajoutez les lignes suivantes à la fin du fichier :

post-up /sbin/ifconfig eth0:X 1.2.3.4 netmask 255.255.255.255 broadcast 1.2.3.4
post-down /sbin/ifconfig eth0:X down

Pensez à bien changer l’IP « 1.2.3.4 » (2 fois) par votre IP Fail-Over (IP publique). Puis lancez la commande :

/etc/init.d/network restart

Une fois que vous avez fait cette manipulation sur le S1, celui-ci devrait être accessible depuis son IP Publique. Mais n’oubliez pas de faire la même chose sur votre S2, sinon vous risquez d’avoir quelques soucis lors de votre premier basculement (et hop, un site hors ligne …).

Etape 3 – Configuration du nom de domaine

Cette étape là est relativement simple et à vrai dire, vous n’êtes pas forcément obligé de faire comme moi. Je vous conseille juste de prendre quelques précautions afin de pouvoir développer au mieux votre projet et de pouvoir cibler rapidement le moindre bug.

Nous allons donc configurer notre nom de domaine pour que celui-ci redirige vers l’IP publique de notre projet mais également des accès directs aux S1 et S2.

@ A [IP Publique]
www A [IP Publique]
s1 A [IP Privée S1]
s2 A [IP Privée S2]

Ainsi, quand vous venez de créer les redirections suivantes :

www.votredomaine.com ==> IP Publique
votredomaine.com ==> IP Publique
s1.votredomaine.com ==> IP privée S1
s2.votredomaine.com ==> IP privée S2

Ce qui vous permettra de configurer votre IP publique mais aussi d’avoir un accès direct au serveur de votre choix (pour la gestion de la BDD par exemple).

Mais il faut maintenant configurer correctement apache de vos deux serveurs. Ainsi sur S1, modifier votre fichier vhost :

ServerName votredomaine.com
ServerAlias www.votredomaine.com s1.votredomaine.com

Et sur votre s2 :

ServerName votredomaine.com
ServerAlias www.votredomaine.com s2.votredomaine.com

Votre nom de domaine, une fois la propagation DNS effectuée, sera convenablement configuré pour votre PRA.

Etape 4 : Réplication de la base de données

Là, je vous invite simplement à relire l’article suivant : [Tuto] Réplication base de données avec PHPMyAdmin.

Etape 5 : Réplication des fichiers

« Et maintenant, le coeur de la maison, la cuisine » Ou du moins la plus importante, la réplication des fichiers de s1 vers s2. Pour cela, nous allons utiliser Unison, qui va assurer la synchronisation de deux répertoires toutes les X minutes à l’aide d’un cron.

La première des choses à faire est de créer un tunnel SSH entre S1 et S2 et encore une fois, je vous renvoi vers ce tutoriel : [Tuto] Créer un tunnel SSH entre deux serveurs Debian.

Nous allons ensuite installer unison sur les deux machines :

apt-get install unison

Unison s’occupe donc de synchroniser les deux répertoires. Il va aller vérifier que tous les fichiers sont présents et sont les mêmes. S’ils ont été modifiés, vous pouvez configurer Unison de deux manières différentes:

  • Newer : C’est le dernier fichier qui a été créé qui est considéré comme le bon fichier.
  • Force : Vous déterminez quel serveur est considéré comme référent.
Dans notre cas, nous allons toujours utiliser la méthode « Force » pour deux raisons :
  1. Nous ne ferons nos développements que sur S1 et nous laisserons le soins à Unison de mettre à jour S2. Ca évite toute erreur.
  2. Unison ne sait pas supprimer les fichiers en mode Newer. En effet, si vous supprimez le fichier sur s1, il va le remplacer par celui présent sur s2 en le considérant comme plus récent (ce qui est logique) ce qui va donc vous causer des soucis.
Le but est donc de forcer la mise à jour du répertoire /var/www de S1 sur S2 toutes les X minutes. Pour cela, nous allons créer le fichier de configuration sur S1 pour Unison : Créez le répertoire /root/.unison/ et le fichier /root/.unison/default.prf :

# On force les modifications en cas de conflit
auto=true
batch=true

# Si tout le répertoire sur s1 est vide, on empêche la mise à jour de s2 (question de sécurité)
confirmbigdeletes=true

# On accepte de se contenter de la vérification du nom du fichier et de sa taille pour la comparaison des fichiers au lieu d’aller vérifier tout son contenu (c’est nettement plus rapide).
fastcheck=true

# On garde le même propriétaire des fichiers
group=true
owner=true

# On force la mise à jour de S2 depuis S1 en cas de conflit entre deux fichiers
prefer = /var/www

# On demande à Unison de ne rien ressortir de ses actions (puisqu’on va l’effectuer avec un cron, c’est inutile)
silent=true

# On demande à ce que l’heure de modification des fichiers soit aussi synchronisée (pour avoir réellement les mêmes données sur les deux serveurs
times=true

Nous allons pouvoir tester notre configuration et voir si tout marche bien manuellement. Pour cela, créez un fichier vide sur S1 mais pas sur S2 dans votre répertoire /var/www/ puis testez la commande suivante

 root@s1:~# unison /var/www ssh://[IP Privée S2]//var/www

C’est la première fois que vous lancez unison donc il se peut qu’il soit un peu bavard mais cela n’a pas d’importance. Si vous allez sur S2, vous devriez voir apparaître votre fichier. Pour aller un peu plus loin dans les vérifications, modifier le contenu de votre fichier sur S1 et relancez la commande. Normalement, Unison ne dit plus rien et le contenu du fichier a bien été modifié sur S2. Refaite le test en modifiant le fichier sur S2, relancez la commande et vérifiez que le fichier sur S1 n’a pas été modifié et que celui sur S2 a bien été écrasé par celui du S1. Et enfin supprimez le fichier sur S1 puis relancez la commande pour vérifier qu’il disparaît bien sur S2.

Nous pouvons maintenant automatiser cette commande à l’aide d’un cron. Pour cela, toujours sur S1, tapez la commande suivante pour ouvrir la console de gestion de vos tâches cron :

root@s1:~# crontab -e

Et ajoutez la ligne suivante :

*/1 * * * * unison /var/www ssh://[IP Privée S2]//var/www &> /dev/null

ici, la synchronisation s’exécute toutes les minutes (la ligne commence par */1). Une mise à jour aussi fréquente n’est pas nécessaire. Cela dépend totalement de votre type de projet. Si votre projet modifie des fichiers (en y stockant des données par exemple) alors oui, une synchronisation régulière est primordiale. Mais celle-ci étant lourde, si vos fichiers ne sont pas modifiés, n’hésitez pas à choisir des intervalle de synchronisation plus longs pour éviter de fatiguer votre serveur pour rien. Testez votre cron en modifiant un de vos fichiers sur S1 dans /var/www/ et vérifiez que celui-ci est répercuté sur S2 après l’intervalle de temps de votre cron.

Maintenant, si les tests sont concluants, alors bravo, vous venez de monter votre propre PRA.

Conclusion

Développez votre projet sur S1, toujours, ne touchez jamais à S2 sauf pour vérifier de temps en temps que tout fonctionne parfaitement (notamment du côté de la base de donnée). Dès que votre S1 a un problème et que vous êtes obligé de le mettre hors ligne, basculez votre IP Publique vers l’IP privée de votre S2 pour que celui-ci prenne la relève. Vous venez d’assurer à votre projet la sauvegarde intégrale de ses données en temps réelle et ça, ce n’est pas négligeable pour des sites importants.

Certaines de vos configurations réseaux vont impliquer la connexion d’un de vos serveurs en SSH à un autre de vos serveurs afin de pouvoir, par exemple, faire un sauvegarder ou encore synchroniser des fichiers ou des données. Afin d’automatiser cette connexion, nous pouvons apprendre à ces deux serveurs à se reconnaître entre eux et ainsi à ne pas demander de mot de passe ni de login. Nous allons pour cela, mettre en place un tunnel SSH à l’aide d’une paire de clef publique / clef privée sur chacun des serveurs.

Nous aurons besoins pour cela de deux serveurs linux tournant sous Debian 6.0. Nous appellerons le premier serveur S1 et le second S2.

Etape 1 : Création de la paire de clef publique / privée

La clef publique est une chaîne de caractère unique à chaque serveur. Cette clef est toujours associée à une clef privée qui permet au serveur de vérifier la validité de celle publique. Ainsi, si vous partagez la clef publique, le serveur pourra alors vérifier son authenticité et donc permettre la connexion sans mot de passe. Pour se faire, connectez vous sur votre serveur S1 et créez le couple de clefs :

$ root@server1:~# ssh-keygen -t dsa -b 1024

Votre console va vous demander où enregistrer la pair de clef et une « passphrase », laissez la vide et appuyer simplement sur entrer à chaque fois, jusqu’à ce que le « fingerprint » apparaisse. Vos fichiers « /root/.ssh/id_rsa » (clef privée) et « /root/.ssh/id_rsa.pub » (clef publique) ont été créées ! Réeffectuer la même opération sur votre S2.

Etape 2 : Transfert de la clef publique

Maintenant, nous allons partager notre clef publique et ainsi apprendre à notre serveur à accepter les connexions sans mot de passe de notre autre serveur. Pour cela, rien de plus simple, une petite ligne de commande :

$ root@server1:~# ssh-copy-id -i ~/.ssh/id_dsa.pub root@server2

Il vous demandera le mot de passe root de votre serveur 2 pour la dernière fois ! Faites de même dans le sens inverse pour accepter les connections de S2 sur S1.

Etape 3 : Tests

On va maintenant pourvoir tester. Connectez-vous en root sur S1 puis, depuis S1, connectez vous en root sur S2 :

$ root@server1:~# ssh root@server2

S’il ne vous demande pas de mot de passe, c’est que tout marche ! Effectuez le même test dans l’autre sens pour vérifier que la manipulation est bien symétrique. Vous venez de créer un tunnel SSH entre vos deux serveurs et ainsi de vous affranchir de vos mots de passes.

 

Les tutoriels d’installation d’un serveur web pullulent sur le net. Mais Linux étant ce qu’il est, la plupart des packages (programme que vous installez sur votre serveur) sont rapidement obsolètes. Ainsi, dès que vous souhaitez suivre un tuto, vous tombez vite sur des erreurs ou carrément sur des configurations totalement différentes et donc inutilisables.

Je ne suis, pour ma part, absolument pas administrateur serveur/réseau. Ce n’est pas ma spécialité et je ne peux même pas dire que j’aime ça. Mais il n’empêche, qu’en quelques mois, j’ai dû installer plus d’une vingtaines de serveurs et donc c’est tout naturellement que je voulais vous partager ma méthode.

Ainsi, nous allons voir ensemble comment installer et configurer un serveur web sous Linux Debian assez basique mais amplement suffisant pour la création d’un site internet.

Sommaire :

  • Chapitre 1 : Les bases
  • Chapitre 2 : Apache
  • Chapitre 3 : PHP
  • Chapitre 4 : Base de donnée
  • Chapitre 5 : Serveur mail

Chapitre 1 : Les bases

Lorsque vous achetez (ou louez) un serveur web chez un hébergeur, celui-ci vous installe une distribution dessus. Par exemple chez Online, il vous laisse le choix entre plusieurs systèmes d’exploitation (si vous êtes en mode « serveur ») : Debian, Ubuntu, Centos, Windows, ESXI, Mageia, Proxmox et Fedora. Pour ce tutoriel, nous avons choisi le système d’exploitation Debian en version 64 bits.

Une fois votre serveur installé, il faut maintenant vous connecter dessus, nous allons utiliser pour ça, un protocole appelé SSH. C’est un protocole sécurisé qui permet de prendre le contrôle total de votre machine en ligne de commande. Sachez qu’il faut attendre entre 3 et 15 minutes après le premier allumage d’un serveur pour que le SSH fonctionne. Ainsi, si vous n’arrivez pas à vous connecter, retenter d’ici quelques minutes.

Pour se connecter en SSH sur votre serveur, vous avez plusieurs possibilités :

– Pour Windows : Installez Putty (http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html)

– Pour Mac : Utilisez directement votre terminal (/Applications/Utilitaires/Terminal)

– Pour Linux : Votre console fera amplement l’affaire …

Pour notre tutoriel, j’utilise le terminal de Mac OS X.  Son utilisation est exactement la même que la console de linux. Par contre, l’utilisation de putty est légèrement différente au niveau de la connexion au serveur. Celui-ci vous demande l’IP de votre serveur, le nom d’utilisateur et le mot de passe directement dans une fenêtre avant votre connexion et ce dernier vous connecte automatiquement au serveur. Ainsi, pour ceux qui utilisent putty, ne prenez pas en compte cette étape. Pour les autres, voici la ligne de commande a effectuer :

ssh  root@123.123.123.123

« root » est le super utilisateur par défaut de votre machine, celui-ci a les pleins pouvoir sur tous les fichier. Remplacez bien évidement 123.123.123.123 par l’IP de votre machine. La première fois que vous vous connecterez à votre serveur, votre ordinateur va vous demander si vous lui faites confiance. Ce choix vous appartiens entièrement, mais s’il est négatif, vous ne pourrez pas vous y connecter. C’est bête …

Ensuite, votre serveur vous demandera votre mot de passe. Attention ! Vous aurez beau le taper, celui-ci ne s’affichera pas, c’est tout à fait normal, simple question de sécurité. Valider simplement avec la touche « Entrer », vous êtes donc maintenant connecté à votre serveur.

Premier réflexe ! Mettre à jour votre machine. Commencez par rechercher des mises à jours :

apt-get update

Puis installez-les :

apt-get upgrade

Cette seconde opération est un peu plus longue (5 minutes chez moi) et peux vous poser quelques questions assez simples à répondre (il me demande par exemple le type de clavier que je veux utiliser, ce qui est totalement inutile, mais rien que pour me la péter, je sélectionne le MacBook Pro), si vous ne savez pas quoi répondre, la valeur par défaut est toujours idéale.

Votre serveur est à jour, nous sommes prêt à faire joujoux avec.

Chapitre 2 : Apache

Apache est le programme qui permettra à votre serveur d’interpréter vos fichiers et de les associer à une URL. Pour l’installer, exécutez la ligne de commande suivante :

apt-get install apache2

Félicitation, votre serveur est maintenant officiellement un serveur « web ». Tapez l’IP de votre machine dans votre navigateur, et vous verrez un beau « It works ! » apparaître. Ce fichier se trouve dans le répertoire « /var/www/ » par défaut. Cependant, certains d’entre vous n’ont pas forcément envie que leur site soit accessible directement depuis son IP. Apache nous permet donc de filtrer les entrées en fonction du nom de domaine appelé et de les rediriger vers des répertoires différents grâce aux fichier vhost. Nous allons donc maintenant configurer votre premier site (à tout hasard test.com).

Nous allons commencer par créer le répertoire qui accueillera le site en question. Allez dans le répertoire d’apache par défaut :

 cd /var/www/

Puis créez votre répertoire au nom de votre site :

mkdir test.com

Le répertoire /var/www/test.com/ est maintenant créé et va pouvoir accueillir votre site internet. Créons donc sa première page index.html qui va nous permettre de tester si apache est bien configuré :

nano /var/www/test.com/index.html

Remplissez le avec un code HTML, juste de quoi attester de la présence du fichier :

<center><b>Vous êtes maintenant sur le site test.com</b></center>

Pour enregistrer les fichier, appuyez sur CTRL + X puis validez. Nous allons maintenant créer le vhost qui correspondra au nom de domaine test.com

cd /etc/apache2/sites-available
nano test.conf

Et voici votre premier vhost :

<VirtualHost *:80>
        ServerAdmin contact@test.com
        ServerName test.com
        ServerAlias www.test.com
        DocumentRoot /var/www/test.com
        <Directory /var/www/test.com>
                Options -Indexes FollowSymLinks
                AllowOverride All
                Order allow,deny
                allow from all
        </Directory>
</VirtualHost>

Je m’explique :

ServerAdmin : L’adresse e-mail à renvoyer à vos utilisateur si une erreur survient

ServerName : Le nom de domaine sur lequel doit répondre le serveur

ServerAlias : Les alias du nom de domaine, comme le www ou d’autres sous-domaines

DocumentRoot : La racine de votre répertoire pointant vers le site

Toute la partie Directory représente les droits des fichiers du serveur (je ne développerais pas plus ici, sachez juste que les valeurs de notre vhost sont optimales pour un site web).

Enregistrez le fichier. Il faut maintenant l’activer, et pour ça, rien de plus simple :

a2ensite test

Maintenant, apprenez par coeur la ligne de commande suivante, elle vous permettra de prendre en compte les modifications effectuées à Apache et de redémarrer ce dernier :

service apache2 restart

Votre serveur est maintenant configuré pour recevoir le trafic venant du domaine test.com et redirigé vers le dossier /var/www/test.com/.

Par contre, vous l’aurez remarqué, le vrai domaine test.com ne pointe pas forcément sur votre serveur (si c’est le cas, vous avez énormément de chance !), nous allons, pour tester notre configuration, obliger votre ordinateur à rediriger test.com vers votre serveur.

Sur mac, ouvrez Finder, dans le menu, choisissez « Aller » puis « Allez au dossier » et tapez le répertoire suivant :

/private/etc/

Trouvez le fichier « host » (sans extension). Clic droit, « lire les informations ». Dans la partie « Partage et permissions » sélectionnez votre utilisateur et définissez lui le droit « Lecture et écriture » puis ouvrez le fichier avec votre éditeur de texte. Pour les autres systèmes d’exploitation, la manipulation est très similaire. Une petite recherche Google vous permettra d’arriver à vos fins. Une fois sur le fichier, rajouter à la fin de celui ci la ligne suivante :

123.123.123.123 test.com www.test.com

Notez que nous n’utilisons pas d’espace mais des tabulations ! Enregistrez. Vous venez d’apprendre à votre ordinateur à rediriger test.com et www.test.com vers l’IP 123.123.123.123 (modifiez cet IP par celui de votre serveur). Vous pouvez maintenant vous rendre à l’adresse http://www.test.com et vous allez voir votre fichier index.html.

Vous avez la possibilité, pour des questions de sécurité, de supprimer la redirection par défaut sur le répertoire /var/www en désactivant le vhost default :

a2dissite default

N’oubliez pas de redémarrer apache :

service apache2 restart

Si vous avez l’intention d’utiliser de l’URL rewriting, n’oubliez pas d’activer le mode, pour cela, rien de plus simple :

a2enmod rewrite

Votre apache est maintenant configuré correctement. Vous êtes presque prêt à installer votre site internet. Il manque encore un petit détail : votre serveur ne sait que lire vos fichiers, pas les interpréter. Nous devons donc installer PHP.

Chapitre 3 : PHP

Cette installation est très rapide et ne demande aucune configuration !

apt-get install php5

On peut également rajouter tout de suite quelques librairies bien utiles

apt-get install php-pear php5-gd php5-curl

On va maintenant vérifier que PHP fonctionne bien, pour cela, il suffit d’installer un fichier à la racine de votre site test.com avec à l’intérieur un phpinfo() :

nano /var/www/test.com/phpinfo.php

Et entrez le code suivant dans votre page :

<?php
phpinfo();
?>

Enregistrez et rendez-vous sur l’url de la page : http://www.test.com/phpinfo.php. Voici un récapitulatif de toutes les informations PHP de votre serveur. PHP est donc bien installé.

Chapitre 4 : Base de donnée

J’ai fait depuis longtemps le choix d’une base de donnée décentralisée, histoire de gagner du temps. Mais si vous souhaitez installer une base de donnée sur votre serveur, alors il vous faut installer MySQL, apprendre à votre serveur à faire communiquer votre base de donnée et PHP et enfin, vous donner la possibilité d’administrer cette base de donnée.

Pour commencer, il faut installer mysql :

apt-get install mysql-server

On va vous demander le mot de passe administrateur de votre base de donnée, notez le bien. Ensuite, apprenons à PHP à communiquer avec la base de donnée :

apt-get install php5-mysql

Et enfin, installons PHPMyAdmin qui nous permettra d’administrer cette base de donnée.

apt-get install phpmyadmin

Il va d’abords vous demander de faire un choix entre lighthttpd et apache2. Choisissez apache2 (attention, le fait qu’il soit surligné par défaut ne le sélectionne pas pour autant. Il vous faut appuyer sur la barre d’espace pour voir une étoile apparaître devant « apache2 »). Ensuite, il va vous demander l’autorisation de modifier votre base de donnée, répondez oui puis donnez lui le mot de passe de celle-ci. Il vous demandera ensuite de choisir un mot de passe pour vous connecter à PHPMyAdmin. Voila, PHPMyAdmin est installé avec succès. Vous devriez pouvoir vous connectez depuis l’URL http://www.test.com/phpmyadmin/. Si ce n’est pas le cas il faut déterminer par quel moyen y accéder. La solution la plus courante reste à paramétrer votre vhost pour que celui-ci fasse pointer le répertoire /phpmyadmin/ de votre site vers phpmyadmin :

nano /etc/apache2/sites-available/test

Et rajoutez juste après </Directory> les lignes suivantes :

Alias /phpmyadmin "/usr/share/phpmyadmin/"
<Directory /usr/share/phpmyadmin/>
        Options Indexes FollowSymLinks
        AllowOverride All
        Order allow,deny
        allow from all
</Directory>

Puis redémarrez votre serveur apache :

service apache2 restart

Concrètement, je vous conseille de ne pas utiliser cette URL qui est utilisée par défaut. En effet, des milliers de robots scrutes tous les serveurs afins de déterminer qui a installé phpmyadmin et d’y exploiter d’éventuelles failles. Donc choisissez votre propre URI discrète.

Chapitre 5 : Serveur mail

Vous avez sûrement envie de pouvoir envoyer des mails depuis votre site internet. Pour cela, il faut apprendre à votre serveur à le faire en installant postfix :

apt-get install postfix

Il va vous demander comment le configurer, choisissez la configuration « Site Internet » puis un domaine depuis lequel envoyer vos mails. Dans l’idéal, renseignez un domaine existant, pointant réellement sur votre machine, mais pour ces tests, nous nous contenterons d’utiliser test.com. La seule répercussion (à ce que je sache) est que tout mail envoyé depuis test.com aura de grande chance de se trouver dans les SPAM.

Voila, la fonction mail() de PHP fonctionnera maintenant à merveille.

 

Voila votre serveur web prêt à être en production ! Dès que j’aurais le temps, je vous ferais sécuriser un peu tout ça.

 

UPDATE 06/10/2015 : Suite à la remarque de d’Alexis, ce tutoriel a été mit à jour pour la version 8 de Debian ! Quelques modifications sont importantes : vous devez impérativement renommer vos VHOST pour y ajouter l’extension « .conf ».