WebHostPro : l’hébergement web sur votre NAS QNAP

WebHostPro fait tourner des sites web sur un NAS QNAP : sites statiques, sites PHP avec leurs propres bases de données et proxys vers des applications du NAS, chacun sous son propre domaine avec un certificat, le tout depuis un seul panneau. Il est gratuit et s’installe depuis le dépôt App Center de ce site.

Fonctionne sur un NAS QNAP à processeur Intel ou AMD (x86_64), sous QTS 6.0 ou QuTS hero 6.0 ou version ultérieure.
S’installe depuis le dépôt QNAP Utilities de l’App Center sous le nom (example) WebHostPro.
Panneau : https://<NAS>:9541/ ; les sites répondent sur les ports 9542 et 9543 jusqu’à ce que vous les passiez sur 80 et 443.
Compilé depuis les sources avec l’App Builder de Bucket & Code Server IDE.

01Présentation

WebHostPro fait tourner des sites web sur un NAS QNAP. C’est une pile de serveurs web : nginx devant chaque site, Apache httpd derrière lui pour les sites qui l’utilisent, PHP 8.1 à 8.5, MariaDB, Percona Server, PostgreSQL, memcached et Valkey, avec un panneau en neuf langues qui ajoute, modifie et supprime les sites.

02Captures d’écran

WebHostPro: the overview of the sites and services

The list of sites with their PHP version and certificate

03Premier démarrage

Le bouton Ouvrir d’App Center mène au panneau, https://<NAS>:9541/ ; le port 9540, en HTTP simple, y redirige. Sur une nouvelle installation, le panneau affiche Première connexion : un mot de passe d’au moins 10 caractères, saisi deux fois. Le paquet ne définit aucun mot de passe et n’en génère aucun, et le panneau ne garde qu’une empreinte du mot de passe que vous définissez.

La page n’accepte le mot de passe que d’un ordinateur du réseau propre au NAS (adresse privée, de bouclage ou link-local) et pendant 60 minutes après le démarrage du panneau ; tant que personne ne l’a défini, c’est la première personne du réseau qui ouvre le panneau pendant cette heure qui le choisit. Redémarrez WebHostPro dans App Center pour la rouvrir. Une session dure 8 heures, et 10 connexions échouées depuis une adresse bloquent cette adresse pendant 15 minutes.

04Sites

Un site est un domaine avec ses alias, un type (fichiers statiques, PHP, ou un proxy vers un service du NAS ou du réseau local, conteneur compris, avec websockets), un serveur web (nginx ou Apache httpd) et, s’il en a besoin, une base de données. La cible d’un proxy est une adresse d’une plage privée, pas un nom d’hôte. Chaque site a un compte à lui, ws-<ID>, qui possède son dossier et exécute son PHP, si bien que le PHP d’un site ne peut pas lire les fichiers d’un autre. Le dossier se trouve dans un dossier partagé de QTS ou dans le dossier de données de WebHostPro, et son public/ est la racine des documents.

Un site PHP exécute son propre maître PHP-FPM, et son onglet PHP tient la version (8.1 à 8.5), le fuseau horaire, les limites, les erreurs, les sessions et la sécurité, OPcache et le JIT, APCu, les extensions, d’autres lignes php.ini et les workers PHP (le pool). Une ligne php.ini est vérifiée contre les directives que le PHP de cette version liste lui-même ; un nom qui charge du code, lance une commande, nomme un fichier ou contient un mot de passe est refusé. Le pool a le gestionnaire de processus (à la demande, dynamique ou statique), le nombre de processus (à la demande avec 5 par défaut), le délai d’inactivité, les requêtes par processus, une limite de temps par requête et un journal des requêtes lentes, que l’onglet Journaux montre. Un plantage ou un PHP surchargé sur un site laisse les autres tourner, et un changement des réglages PHP d’un site ne redémarre que son PHP. Un maître qui se termine est relancé et reste arrêté après cinq arrêts en une minute ; logs/php8.N-ID.log le dit.

Chaque site peut lancer des tâches planifiées sous son propre compte avec son propre PHP : un fichier PHP, une commande ou l’adresse du site, chaque minute ou selon n’importe quel calendrier cron. La page du site montre le résultat et la sortie de chaque exécution, et MailServerPro envoie un rapport quand une tâche commence à échouer.

Chaque site PHP a son propre Valkey (il parle le protocole de Redis) et son propre memcached, chacun sur un socket dans un dossier que seul ce site peut ouvrir : aucun n’a besoin de mot de passe ni de port réseau, et l’onglet Cache du site montre les deux sockets. Chacun garde jusqu’à 64 Mo, et un redémarrage les vide tous les deux. Chaque version de PHP a imagick, avec ImageMagick qui lit et écrit JPEG, PNG, WebP, GIF et AVIF et lit HEIC. Sa politique refuse les formats qui lisent d’autres fichiers ou lancent des programmes, comme SVG et MSL.

Les fichiers .htaccess des sites Apache peuvent aussi utiliser l’authentification Digest, des groupes tirés d’un fichier de groupes, Substitute pour remplacer du texte dans une page et le filtre RATE_LIMIT pour limiter la vitesse d’un téléchargement.

Un site PHP peut aussi avoir ses propres extensions PECL : son onglet PHP les compile sous le propre compte du site, sans réseau, dans l’environnement de compilation de Bucket & Code Server IDE, et seul le PHP de ce site les charge.

WebHostPro peut devenir le serveur web du NAS en un clic, et une nouvelle installation le demande une fois : l’administration de QTS passe du port 443 au 44443 et le serveur web de QTS du 80 au 8880, chaque étape vérifiée avant la suivante, les sites de QTS passent derrière WebHostPro, et un clic sur la page Frontal et ports rend 80 et 443.

Une visite guidée mène des ports standard et de TurboDNS jusqu’à votre premier site, puis, après vérification de la configuration DNS, propose de diffuser l’adresse du serveur DNS par le DHCP du routeur.

Un site PHP ou statique servi par nginx a un onglet Cache. nginx compresse les réponses texte avec Brotli et zstd en plus de gzip. Un site PHP peut activer un cache de pages, désactivé par défaut : les visiteurs qui ont un cookie de connexion reçoivent toujours une page fraîche, l’en-tête X-Cache dit HIT, MISS, STALE, UPDATING ou BYPASS, et Vider le cache le vide. Les navigateurs peuvent garder les fichiers statiques 1, 7, 30 ou 365 jours. nginx accepte un corps de requête jusqu’à la plus grande requête du site (le post_max_size de l’onglet PHP) et répond 413 au-delà ; un site proxy n’a pas de limite de corps au frontal.

Ajouter un site est un assistant de domaine : Domaine, DNS, Bureau d’enregistrement, Site web, Base de données (pour un site PHP), Certificat et Récapitulatif. DNS demande qui répond pour la zone (TurboDNS sur ce NAS ; les serveurs du bureau d’enregistrement ou d’un fournisseur DNS ; ou Cloudflare ou OVHcloud, depuis la zone que TurboDNS garde sur ce NAS) et quelles adresses publiques ce NAS a. Bureau d’enregistrement liste ce qu’il faut saisir là où le domaine a été acheté, chaque valeur avec un bouton de copie, avec les redirections du routeur et l’état du frontal en dessous. L’essai à blanc du Récapitulatif montre le plan du site et celui de TurboDNS ensemble, et une seule application envoie les deux. Le certificat vient de Let’s Encrypt (HTTP-01, où le frontal sert le fichier sur le port 80, ou DNS-01 via TurboDNS ou Cloudflare ; WebHostPro le renouvelle quand il reste 30 jours ou moins), ou bien c’est un certificat envoyé, celui du NAS lui-même ou un certificat auto-signé.

Après l’application, la Vue d’ensemble du site a la carte Terminer la configuration de <nom> : Site appliqué, Enregistrements dans TurboDNS, Chez le bureau d’enregistrement, Vérification en direct, Certificat et Terminer. Vérifier maintenant lit les serveurs de noms de la zone parente, le TurboDNS de ce NAS, trois résolveurs publics et le frontal, et dit qu’il ne peut pas voir si les ports 53, 80 et 443 atteignent le NAS depuis Internet ; la ligne Certificat demande le certificat à Let’s Encrypt. La ligne Enregistrements dans TurboDNS est faite dès que le plan de TurboDNS pour le domaine ne trouve plus rien à changer, après l’essai à blanc de l’assistant, après Envoyer les enregistrements de la ligne ou après un nouvel envoi, et affiche alors Dans TurboDNS depuis le <date> ; un site dont les enregistrements sont déjà dans la zone l’obtient dès l’essai à blanc.

Chaque changement est d’abord un brouillon. L’essai à blanc écrit toute la couche web dans un dossier de travail, y exécute nginx -t, httpd -t et php-fpm -t et montre les fichiers ajoutés, modifiés et supprimés avec leurs différences. L’application exécute exactement ce plan, garde d’abord un instantané des fichiers en service, recharge en douceur et remet l’instantané en place si une étape échoue. Supprimer un site demande que son nom soit saisi ; son dossier et ses bases de données restent.

Pour un site proxy, Application sur ce NAS liste les applications installées pour lesquelles WebHostPro a un modèle : Rtorrent 16 et ses modules, Radarr, Sonarr, Prowlarr, Lidarr, Bazarr, Seerr, Tautulli, qBittorrent, Transmission, TunerHub, Weblate, Tolgee, Bucket & Code Server IDE, Plex Media Server et Jellyfin. Choisir une application remplit la cible avec le port qu’utilise son paquet et active les websockets si l’application en a besoin. Le frontal envoie alors à l’application X-Forwarded-Host et X-Real-IP, laisse jusqu’à une heure pour répondre à une application aux requêtes longues et diffuse sans mise en mémoire tampon les médias et les événements des applications qui en envoient. Un réglage que seule l’application peut changer, comme l’URL Base d’une application *arr, est indiqué en une ligne sous la liste.

05Site par défaut

Une requête pour un nom qu’aucun site ne porte, comme l’adresse ou le nom du NAS, aboutit au site par défaut : au dossier partagé Web de QTS quand le NAS en a un utilisable par WebHostPro, sinon à une page d’accueil dans le dossier de données de WebHostPro. Apache httpd le sert, donc les fichiers .htaccess du dossier fonctionnent, sauf les lignes Options, qui sont ignorées. Son PHP tourne sous un compte dédié. Après l’installation ou la mise à jour, il est activé en brouillon : le prochain essai à blanc et l’application des changements le mettent en ligne. Il répond sur les ports du frontal : sur 80 une fois le frontal déplacé sur ce port depuis la page Frontal et ports, sinon sur 9542. Tant que le serveur web de QTS occupe le port 80, sa page dans WebHostPro indique le réglage à désactiver dans QTS. Il ne sert jamais les dossiers des autres sites placés dans le dossier Web, les fichiers et dossiers dont le nom commence par un point (sauf .well-known), ni les dossiers de QTS qui commencent par @, et n’affiche aucune liste de dossier. WebHostPro ne modifie pas les autorisations du dossier. Les dossiers du dossier partagé Web qui sont des liens vers d’autres dossiers partagés ou volumes fonctionnent comme avec le serveur web de QTS, PHP compris.

En HTTPS, il répond avec le certificat propre du NAS, celui que QTS utilise pour ses propres pages ; tant que c’est le certificat auto-signé de QNAP, les navigateurs affichent un avertissement. Une requête TLS vers un site sans TLS est refusée.

WebHostPro fait lui-même la rotation de ses journaux : à 10 Mio ou après une semaine, il garde cinq copies compressées avec gzip, et nginx et httpd rouvrent leurs journaux sans perdre de requête.

06Bases de données

Un site reçoit une base de données et un utilisateur MariaDB, Percona Server ou PostgreSQL sur la page Bases de données ou dans son onglet Base de données. Percona Server 8.4 est mis en place quand la première base Percona est créée et écoute sur 127.0.0.1:9555 et sur un socket ; un NAS qui ne l’utilise jamais ne le démarre jamais. La page Bases de données a une carte pour MariaDB et une pour Percona Server, avec huit réglages (le buffer pool, les connexions, le plus grand paquet, le redo log, les tables temporaires, le cache de tables, le délai d’inactivité, le temps des requêtes lentes) et d’autres lignes my.cnf, vérifiées contre la liste d’options du serveur lui-même. Un changement est un brouillon ; l’application redémarre le serveur, si bien que ses bases de données ne répondent pas pendant quelques secondes.

07Avec les autres applis du NAS

Quand TurboDNS tourne sur le NAS, l’étape DNS de l’assistant lui propose la zone, et l’application envoie les enregistrements. Sans MailServerPro, ils ne portent aucun enregistrement de courrier : une nouvelle zone reçoit les serveurs de noms ns et ns1, tous deux ce NAS sauf si vous nommez un second serveur de noms, et les enregistrements A et AAAA des noms du site, de ns et de ns1 ; une zone que TurboDNS sert déjà garde ses propres serveurs de noms. Avec MailServerPro installé, la zone reçoit le modèle d’hébergement de TurboDNS avec les adresses publiques du NAS que vous confirmez, les enregistrements A et AAAA des noms propres du site (le modèle couvre le domaine, www, ns, ns1 et les noms du courrier, si bien qu’un second site tel que shop.example.com reçoit les siens) et les enregistrements DKIM, MTA-STS, TLS-RPT et TLSA de MailServerPro. Rien n’est écrit dans TurboDNS avant l’application, et le Récapitulatif montre d’abord chaque enregistrement.

La troisième réponse de l’étape DNS, Cloudflare ou OVHcloud, depuis la zone que TurboDNS garde sur ce NAS, envoie à TurboDNS les mêmes enregistrements que la première réponse, et un fournisseur DNS répond pour le domaine. TurboDNS envoie la zone par l’API du fournisseur, et seulement quand vous le lui demandez : ouvrez la zone dans TurboDNS, son onglet Cloudflare et OVH, Examiner les changements, puis Envoyer changement(s). L’étape Bureau d’enregistrement ne liste alors ni serveurs de noms, ni enregistrements glue, ni port 53 : le bureau d’enregistrement garde les serveurs de noms du fournisseur, et la zone n’a pas besoin de redirection du port 53 sur le routeur. La vérification en direct passe alors sur les résolveurs publics et le frontal, les lignes Serveurs de noms chez le bureau d’enregistrement et Enregistrements glue étant ignorées.

Avec Bucket & Code Server IDE installé, l’onglet Fichiers d’un site ouvre son dossier dans l’éditeur.

08Sans adresse publique

Un NAS derrière un CGNAT, ou derrière un routeur qui ne redirige aucun port, peut publier des sites choisis sur Internet par un Cloudflare Tunnel. La carte Rendre les sites accessibles depuis Internet via Cloudflare de la page Frontal et ports prend un jeton d’API de votre compte Cloudflare et une zone dont les serveurs de noms sont ceux de Cloudflare. WebHostPro crée alors son propre tunnel et lance cloudflared, qui se connecte lui-même à Cloudflare. Chaque site déjà appliqué reçoit un interrupteur qui donne à ses noms dans la zone un enregistrement CNAME proxifié vers le tunnel ; WebHostPro refuse un nom qui a déjà un enregistrement A, AAAA ou CNAME qu’il n’a pas créé. Désactiver le tunnel supprime les enregistrements créés par WebHostPro et le tunnel. Cloudflare termine le TLS et voit le trafic, et avec l’offre gratuite une requête peut envoyer au plus 100 MB.

09Installation

Recommandé : depuis App Center. Ajoutez une fois le dépôt de ce site ; ensuite, le paquet s’installe et se met à jour depuis App Center comme n’importe quelle autre appli.

App Center → ⚙ Paramètres → Dépôt d’applications → Ajouter.
Nommez-le QNAP Utilities, collez https://www.qnaputilities.com/repo.xml, Ajouter.
Ouvrez QNAP Utilities dans la colonne de gauche et installez (example) WebHostPro.

Le panneau du dépôt : tous les paquets du flux →

10Ce qu’il faut

Un NAS QNAP à processeur x86_64 (Intel ou AMD) sous QTS 6.0 ou QuTS hero 6.0 ou plus récent.

Le panneau est sur le port 9541 (HTTPS ; 9540 y redirige), le frontal (nginx) sur 9542 (HTTP) et 9543 (HTTPS, et UDP pour HTTP/3 quand nginx l’a), et httpd sur 127.0.0.1:9544 derrière lui. Les bases de données, les caches et les services facultatifs n’écoutent que sur 127.0.0.1. Le frontal ne passe sur les ports 80 et 443 que lorsque vous cliquez sur la page Frontal et ports, qui liste les étapes dans QTS qui libèrent ces ports et ce que chacune casse ; WebHostPro ne change jamais lui-même les réglages de QTS.

Sur QuTS hero, un dossier partagé avec les autorisations avancées de dossier ne peut pas contenir de sites : l’application s’arrête, nomme le dossier et redemande. WebHostPro 0.14.4 a été essayé sur QTS 6.1.0 et sur QuTS hero 6.1.0.