^ Sommaire ^

3.b. MySQL (+MySQL tools) ‹

› 3.d. Subversion

Après les bases de données, le serveur web.

1. Installation

C'est bien entendu le couple Apache2 / PHP5 qui va être installé sur le serveur. On commence par apache2 avec ceci :

sudo apt-get install apache2 ssl-cert

puis ensuite

sudo apt-get install libapache2-mod-auth-mysql libapache2-mod-php5 php5 php5-common php5-curl php5-dev php5-gd php5-idn php-pear php5-imagick php5-imap php5-mcrypt php5-memcache php5-mhash php5-ming php5-mysql php5-sqlite php5-xmlrpc php5-xsl

Afin d'installer des extensions pour PHP5.

2. Configuration apache de base

Une fois l'installation terminée, je passe à la configuration.
Tout d'abord, changer l'emplacement du répertoire www pour qu'il soit sur une partition séparée, toujours la même : /mnt/dev.
Je crée donc le répertoire puis j'édite le fichier "default" pour faire refléter mes changements.

# création du nouveau répertoire et affectation des droits
sudo mkdir /mnt/dev/www
sudo chown www-data:www-data /etc/dev/www
 
# édition du fichier "default"
sudo gedit /etc/apache2/sites-available/default

Dans le fichier, je modifie la variable DocumentRoot et le Directory contenant le chemin de base pour y intégrer mon nouveau chemin /mnt/dev/www.

A partir de maintenant, je pourrais stocker mes fichiers dans /mnt/dev/www qui correspond à ma racine web. Je sauvegarde les modifications du fichier.

J'en profite pour modifier quelque peu l'ordre des extensions à afficher par défaut :

sudo gedit /etc/apache2/mods-available/dir.conf

DirectoryIndex index.html index.htm index.php index.xhtml

Je relance apache2

sudo /etc/init.d/apache2 restart

3. Tests php

Je peux maintenant créer un fichier php à la racine pour tester si l'installation a été faite correctement :

sudo gedit /mnt/dev/www/phpinfo.php

Dans lequel je vais simplement ajouter les lignes suivantes :

<?php
phpinfo();
?>

Je sauvegarde, et me rend à l'adresse http://192.168.1.20 pour voir que ça fonctionne correctement. Je tente à tout hasard de me rendre sur http://monServeur.dyndns.org pour voir si l'accès via la dyndns est fonctionnelle, mais ce n'est pas le cas, malheureusement. Il doit y avoir quelque chose à creuser du côté des virtualHost.

4. Sécurité apache2

Enfin, j'ai suivi le tutorial d'ubuntu-fr pour la sécurité d'apache2. J'ai par contre travaillé de manière un peu différente.
Plutôt que de placer ma configuration dans le fichier /etc/apache2/apache2.conf par défaut, j'ai créé un nouveau fichier /etc/apache2/conf.d/my-apache2.conf afin d'y mettre ma configuration personnalisée.
Apache2 s'occupe de charger tous les fichiers qui se trouvent dans le répertoire conf.d à la suite de la configuration par défaut (directive include).
Je peux donc totalement personnaliser ma configuration apache en passant par le répertoire conf.d. L'intérêt réside dans le fait que si je dois réinstaller apache sur le serveur, je n'aurai qu'à récupérer ma config personnalisée et la replacer dans la nouvelle installation.

J'ai tout d'abord mis en place un certificat SSL. Ce certificat est créé dans l'optique d'une configuration Subversion en SSL. Il sera donc nécessaire de faire pointer la bonne URL dans la partie "Common Name". Je génère le certificat en utilisant les commandes suivantes :

export RANDFILE=/dev/random
sudo mkdir /etc/apache2/ssl
sudo openssl req $@ -new -x509 -days 365 -nodes -out /etc/apache2/ssl/apache.pem -keyout /etc/apache2/ssl/apache.pem
 
sudo chmod 600 /etc/apache2/ssl/apache.pem

Lors de l'appel à "sudo openssl ...", la génération du certificat va me poser plusieurs questions. J'y réponds avec mes informations standard. Le seul point sur lequel il faut être précis est

Common Name (eg, YOUR name) []:

Ici, il faudra rentrer l'url ou se trouvera subversion. J'ai choisi svn.titouille.ch, vous comprendrez pourquoi dans la section suivante.

J'ai ensuite rajouté mon fichier /etc/apache2/conf.d/my-apache2.conf toute la config supplémentaire glanée sur le net afin de sécuriser mon serveur, bien que je ne sois jamais sur que ça soit suffisant.

5. Configuration web

Le plus difficile semble fait, reste à comprendre comment fonctionne la notion de virtualHosts afin de pouvoir mettre en place quelques sites web.

Tout d'abord, un peu de réflexion. Sachant que j'ai une ip dynamique associée à une dyndns, j'aimerai pouvoir, dans l'idéal, monter mes sites et pouvoir y accéder de la même manière à partir de mon serveur, à partir d'un autre poste sur mon réseau local ou encore à partir d'un réseau externe.

J'avais pour habitude, lorsque je développe des sites, de le faire de la manière suivante :
admettons que je développe un site pour la société possédant le nom de domaine http://www.mytest.com. Je créais un virtualHost sur ma machine pour pointer sur http://www.mytest-prod.com.
En local sur mon propre poste, pas de souci, ça fonctionne sans problème. Même dans le cas d'un réseau local de machines, en modifiant un peu le fichier "hosts", ça pourrait encore fonctionner. Par contre en externe, il faudrai que je possède le nom de domaine http://www.mytest-prod.com pour pouvoir y accéder de la même manière. Après discussion avec David alias Pilgrim, un ami développeur, il me proposait de travailler avec un nom de domaine m'appartenant et de rediriger les requêtes vers mon propre serveur.

En gros, à la place d'utiliser www.mytest-prod.com, pourquoi ne pas utiliser mytest.titouille.ch. Je creusais un peu la méthode et demandais à François, mon admin serveur, si ce genre de processus était possible. Après quelques tests, il s'avère que oui. Il m'a fait une redirection de tous les sous-domaines titouille.ch qui ne sont pas explicitement déclaré sur le serveur qui héberge mes sites (ce blog et mon site vitrine) en direction de mon url dyndns.

De mon côté, il ne me restais plus qu'à créer les hôtes virtuels sur mon serveur perso pour que la redirection se fasse correctement.

Exemple :

Tout d'abord, éditer la configuration apache (mon fameux fichier my-apache2.conf situé dans /etc/apache2/conf.d/ pour y rajouter la ligne suivante :

NameVirtualHost 192.168.1.20:80

Une fois ceci fait, je vais pouvoir configurer mon nouveau virtualHost

# création du répertoire qui va contenir les fichier du site
sudo mkdir /mnt/dev/www/sites/mytest.titouille.ch
sudo chown -R www-data:www-data /mnt/dev/www/sites/mytest.titouille.ch
 
# création du fichier virtualHost
sudo gedit /etc/apache2/sites-available/mytest.titouille.ch

Le contenu du fichier virtualhost sera le suivant :

<VirtualHost 192.168.1.20:80>
DocumentRoot /mnt/dev/www/sites/mytest.titouille.ch
ServerName mytest.titouille.ch
</VirtualHost>

Il ne reste plus qu'à activer le site et relancer apache via les commandes ci-après :

cd /etc/apache2/sites-available/
sudo a2ensite mytest.titouille.ch
sudo /etc/init.d/apache2 restart

Une fois ceci fait, je vais encore modifier mon fichier "hosts" sur le serveur pour y ajouter une ligne permettant de rediriger en interne le sous-domaine :

sudo gedit /etc/hosts

et je vais y rajouter

192.168.1.20 mytest.titouille.ch

Ainsi, je surdéfini en local l'adresse mytest.titouille.ch, et lorsque je tappe l'url http://mytest.titouille.ch dans mon navigateur, je suis redirigé sur le serveur, dans le bon dossier (/mnt/dev/www/sites/mytest.titouille.ch) tout en gardant l'url correcte.

De la même manière, je vais modifier le fichier /etc/hosts de mon macbook pro pour rediriger de la même manière un appel à mytest.titouille.ch.

Ici, je ne sais pas encore quel sera le résultat en externe. J'imagine que je devrai modifier à nouveau le fichier hosts de mon portable lorsque je suis à l'extérieur, pour le faire pointer sur la dyndns plutôt que l'adresse locale 192.168.1.20. A tester.

Voilà en ce qui concerne la configuration d'apache. Pour chaque nouveau site que je voudrai mettre en ligne, j'utiliserai le même mode de fonctionnement :

1. création d'un répertoire dans la racine www/sites/
2. création d'un fichier pour le virtualhost dans /etc/apache2/sites-available
3. configuration du fichier virtualhost
4. ajout du site dans les sites activés via la commande a2ensite [fichier de config]
5. redémarrage d'apache2
6. edition du fichier /etc/hosts pour y rajouter le nouveau sous-domaine

RAJOUT :

Dernièrement, je bossais avec Eclipse et le plugin Remote System Explorer pour me connecter à un serveur distant via SFTP. Et là je me dis tiens, pourquoi je n'essayerai pas de faire la même chose pour me connecter sur mon petit serveur de salon, afin de ne plus avoir à faire des éditions de fichier via "sudo nano monFichier".

Je mets donc en place une nouvelle connexion sur le plugin, via SFTP. Après quelques essais, j'arrive enfin à me connecter correctement. Par contre, je n'ai accès à rien, je ne peux pas faire d'édition... Pourquoi donc ? en fait les fichiers n'appartiennent pas à l'utilisateur qui se connecte, mais à apache...
J'ai fait différentes manipulation pour reconfigurer le tout correctement :

Tout d'abord, dans le fichier /etc/apache2/envars je rajoute umask 002.
La commande umask permet de faire en sorte que lorsque apache va créer de nouveaux fichiers / dossiers, il va appliquer les droits 666 (pour les fichiers) ou 777 (pour les dossiers) - {valeur umask} : en l'occurence, 666 - 002 = 664. 777 - 002 = 775.
Ce qui permet de faire en sorte que le propriétaire (premier chiffre) et le groupe (second chiffre) possède les droits d'accès les plus élevés.

J'ai ensuite balancé une commande du type :

sudo find . type -d -exec chmod 775 {} \;
sudo find . type -f -exec chmod 664 {} \;

à partir de la racine www de mon serveur. Ainsi tous les répertoires (type -d) sont à 775, et tous les fichiers (type -f) sont à 664

à l'aide d'un

usermod -a -G {group} {user}

(remplacez {group} par le groupe dans lequel vous voulez ajouter l'utilisateur {user})
J'ai rajouté l'utilisateur qui se connecte via SFTP (voir le début du paragraphe) dans le groupe d'apache.
Ainsi l'utilisateur par défaut fait partie du groupe apache, et peut donc avoir accès aux fichiers et dossiers.

Après ça, le plugin Eclipse me permettait d'éditer les fichiers, mais me balançait toujours une erreur me disant un truc du genre "permission d'accès refusée" lors de l'enregistrement, mais l'enregistrement était pourtant bien pris en compte.

J'ai fini par balancer un

sudo chown -R {user}:{group} .

Après une petite discussion sur le forum ubuntu.fr, j'en ai appris un peu plus sur la gestion des droits utilisateurs avec apache, et comment mettre en place la sécurité des droits d'accès aux fichiers / dossiers d'un serveur proprement, merci à snapshot et yohann

Jusqu'ici tout va bien, un serveur web tout neuf et plus ou moins configuré.

^ Sommaire ^

3.b. MySQL (+MySQL tools) ‹

› 3.d. Subversion