Ajouter l’hôte www.enovatic.be

Quand plusieurs noms de domaine pointent vers le même serveur, Apache doit pouvoir distinguer le site demandé. Sans cette association, un nom peut afficher le contenu de l’autre hôte, ou tomber sur un site par défaut. Vous allez ajouter l’hôte secondaire du projet sans modifier le fichier global ni activer la configuration.

Un fichier dédié au second hôte

Le premier hôte, site.example.test, est déjà déclaré dans apache/site-http.conf et sert les fichiers de /var/www/application. Comme rappelé dans la leçon précédente, le nom demandé et la racine de documents sont deux informations distinctes. Vous allez maintenant déclarer api.example.test dans son propre fichier, en le reliant à /var/www/api.

La directive ServerAlias ajoute un autre nom à un hôte virtuel. Elle convient, par exemple, pour faire répondre l’hôte principal à la fois à site.example.test et à www.example.test. Dans ce projet, le second hôte est un site distinct : ne l’ajoutez donc pas comme alias du principal, car il doit servir sa propre racine.

Déclarer api.example.test

Créez apache/site-secondaire.conf dans l’arborescence du projet. Le bloc ci-dessous est complet pour cet hôte HTTP : il associe son nom à la racine secondaire, autorise Apache à lire ce répertoire et sépare ses journaux de ceux du site principal. Les noms de journaux sont propres à cet exemple ; adaptez leur répertoire si votre distribution utilise une organisation différente.

<VirtualHost *:80>
    ServerName api.example.test
    DocumentRoot /var/www/api

    <Directory /var/www/api>
        Require all granted
    </Directory>

    ErrorLog ${APACHE_LOG_DIR}/api-error.log
    CustomLog ${APACHE_LOG_DIR}/api-access.log combined
</VirtualHost>

Le port 80 correspond ici à l’état actuel du projet : la configuration HTTPS sera ajoutée dans une étape ultérieure. Le chemin ${APACHE_LOG_DIR} est une variable fournie par la configuration Apache de la distribution ; sur un système où elle n’est pas définie, remplacez-la par un chemin de journaux approprié. Ne créez pas de second bloc dans site-http.conf : un fichier par hôte rend l’association entre nom, racine et journaux plus facile à contrôler.

Vérifier les noms avant l’activation

Les noms en .test sont réservés aux essais et ne se résolvent pas par le DNS public. Pour un test depuis le serveur lui-même, vous pouvez les associer temporairement à l’adresse locale dans /etc/hosts. Cette association ne vaut que sur la machine où vous la configurez et ne remplace pas la configuration DNS nécessaire à un déploiement réel.

127.0.0.1 site.example.test api.example.test

Avant l’activation des fichiers, une résolution locale ne suffit pas à prouver qu’Apache distribuera les bons contenus : les deux hôtes ne sont pas encore configurés pour être pris en compte par le service. Vous pouvez toutefois vérifier que les noms se résolvent, puis examiner séparément les directives de chaque fichier. La validation de la configuration et l’activation des sites seront traitées dans la leçon suivante ; ne rechargez pas Apache à cette étape.

À retenir

• Conservez un fichier de configuration par hôte virtuel : le principal reste dans apache/site-http.conf et le secondaire est défini dans apache/site-secondaire.conf.
• Associez api.example.test à /var/www/api ; ne l’ajoutez pas comme alias du site principal.
• Utilisez ServerAlias uniquement pour un nom supplémentaire qui doit servir le même hôte et les mêmes fichiers.
• Une entrée temporaire dans /etc/hosts permet de résoudre les noms localement, mais ne rend pas les sites accessibles depuis Internet.
• À ce stade, les fichiers ne sont ni activés ni appliqués par un rechargement Apache.

Dans la prochaine leçon, vous testerez la configuration Apache, activerez les fichiers d’hôtes virtuels selon votre distribution, puis rechargerez le service seulement après validation.