Paul Jusot

Création d'un hôte virtuel

Créer des copies des fichiers /etc/apache2/sites-available/000-default.conf et default-ssl.conf dans le même dossier et les renommer.
Le fichier default-ssl.conf contient la config par défaut d'un hôte écoutant sur le port 443, l'autre est pour le port 80 et contiendra une redirection vers https://mon-site. Chaque site se retrouve donc avec deux fichiers .conf.

Dans le fichier contenant la configuration de l'hôte écoutant le port 443, on doit indiquer le nom d'hôte attendu (ex: sous-domaine.domaine) et le chemin du dossier du site (normalement /var/www/nom-du-site).

La sécurité du site sera grandement améliorée du moment que sa "racine" est située dans un sous-dossier (appelé "public"), on ajoutera alors /public au chemin dans la configuration d'Apache.

├── config
│   └── config.ini
├── public
│   ├── assets
│   ├── css
│   ├── downloads
│   ├── erreur404.html
│   ├── index.php
│   └── js
├── src
│   ├── controller
│   ├── model
│   └── view

Cela fait:

• Il devient alors impossible aux visiteurs de parcourir tous les dossiers du site.
• Seuls les fichiers susceptibles d'être demandés par le client sont visibles.
• Le fichier config.ini qui contient les codes de la BDD, n'est accessible n'est accessible que par PHP (l'utilisateur www-data de Debian).
• l'application n'a plus qu'une seule entrée, le fichier index.php qui est le routeur de l'application, le reste se trouve dans /src.

Pour finir, activer les sites avec la commande "a2ensite" (Debian uniquement) puis recharger la configuration du serveur avec un: systemctl reload apache2

HTTPS et certificat Let's encrypt

Installer et exécuter "certbot".

Certbot est conçu pour fonctionner avec Apache et permet d'installer facilement et gratuitement un certificat SSL. Touts les hôtes virtuels sont détectés et les fichiers .conf sont modifiés. Les hôtes écoutant sur le ports 443 sont configurés pour utilisé le certificat placé dans /etc/letsencrypt/live/mon-domaine/, les hôtes écoutant sur le port 80 quand à eux redirigeront automatiquement les visiteurs vers le bon hôte.

Etape 1: Créer un dossier

Un moyen simple d'éviter tout problème de droit est de donner le dossier à l'utilisateur Apache:
chown -R www-data:www-data dossier-du-site

Toutes les commandes suivantes devront être précédées de sudo -u www-data.

Etape 2: Installation avec git clone au lieu de FTP

Filezilla c'est bien, git c'est mieux. Un simple "git clone" permet de télécharger tout le code et de le mettre à jour avec "git pull".
L'utilisation de cette méthode me simplifie vraiment la vie, toute modification, amélioration ou correction de bug apportée au code et "push" sur le dépôt peut ensuite être appliquée au site en production en quelques secondes.

Etape 2.1: Il manque le fichier config.ini qui est absent du dépôt git

Filezilla reste utile... pour ça.

Etape 3: Installation des bibliothèques avec Composer

Le code est accompagné d'un fichier composer.json qui permet d'installer de la même manière les bibliothèques dans la version souhaitée avec la commande "composer install" (ou "php composer.phar install").

Il est également possible d'installer des dépendances pour le côté client avec NPM, mais NodeJS doit être disponible, ce qui n'est pas toujours le cas en fonction de l'hébergeur. Un moyen de contourner ce problème est d'installer les mêmes dépendances avec Composer lorsque c'est possible (TinyMCE est disponible avec Composer).

Etape 3.1: Autoloader de Composer

La commande est "composer dump-autoload -o", elle est à refaire à chaque création d'un nouvelle classe (ce qui n'est pas le cas avec la configuration utilisant des namespaces).

Le composer.json doit contenir la configuration appropriée:
    "autoload": {
        "classmap": ["src/"]
     }

Cette configuration me dispense d'aller chercher mes classes dans le code et de manipuler des namespaces.
Les bibliothèques sérieuses comme Doctrine utilisent toutes des namespaces. Je suis donc certain que mon code n'entrera pas en conflit avec elles.

Etape 4: Base de données

La bibliothèque Doctrine génère elle-même les tables dans une nouvelle base de données vide. Pour créer les tables:
php bin/doctrine orm:schema-tool:create

En cas de migration, on demandera à Phpmyadmin de créer un dump ne contenant que les données.

Pas de SSH: Solutions de contournement

Ce qui précède est facile et suffisant, sauf lorsque l'hébergeur bloque SSH (mais autorise SFTP) ce qui est le cas avec la formule d'hébergement d'OVH choisie par les nageurs bigoudens. parce qu'elle suffit chez OVH pour installer wordpress depuis l'espace client.

J'ai dû trouver des moyens de contourner cette petite difficulté.