Chaque site déclare son environnement d'exécution, et ne reçoit que ce dont il a besoin
L'environnement d'exécution d'un site est ce qui répond à une requête : des fichiers sur le disque, PHP, une application Node.js, un conteneur, ou un nom qui redirige ailleurs. Dashmox pose la question à la création du site, et ne lui donne que cela et rien de plus.
Les cinq
Ce qu'un site peut être.
Choisi à la création du site, et modifiable ensuite sans rien reconstruire.
Fichiers statiques
Le site sert ce que vous téléversez et rien ne s'exécute sur le serveur. Rien à maintenir en marche, rien à mettre à jour, rien à compromettre.
PHP
Le seul environnement d'exécution livré avec une base de données, le programme d'installation en un clic et un choix d'extensions. WordPress, Joomla, Laravel et tout le reste en PHP. Hébergement PHP
Une application Node.js
Votre propre programme, démarré, supervisé et redémarré par le serveur, avec votre certificat devant lui. Hébergement Node.js
Un conteneur
Une image approuvée par un administrateur, exécutée sans privilèges et avec un système de fichiers racine en lecture seule. Hébergement Docker
Rediriger ailleurs
Le nom répond ici et chaque requête est transmise à une adresse que vous indiquez. Réservé aux administrateurs. Mandataire inverse
Pourquoi poser la question
Parce qu'un serveur qui devine exécute plus de choses qu'il ne le doit.
L'agencement habituel veut que chaque site soit un site PHP, qu'il ait ou non jamais contenu une ligne de PHP.
C'est un comportement par défaut raisonnable et coûteux. Les processus PHP existent pour un site composé de trois cents fichiers HTML. L'interpréteur est joignable à tout chemin se terminant par .php, sur un site qui n'en possède aucun. Les pages de réglages proposent des versions et des extensions pour quelque chose qui ne s'exécute pas. Rien de tout cela ne fait de mal le jour de la configuration, et tout cela constitue une surface que personne ne surveille.
Déclarer ce qu'exécute un site renverse la situation. La question est posée une seule fois, dans le formulaire où vous nommez déjà le site, et tout ce qui suit découle de la réponse.
- Un site statique n'a aucun service PHP. Pas un service désactivé : il n'y a ni pool, ni socket, ni gestionnaire
.phpinscrit dans sa configuration. La seule ligne derrière lui esttry_files, qui sert un fichier ou répond 404. - Un site PHP obtient son propre pool, exécuté sous le compte Linux de ce site et accessible par son propre socket. Sa version et tout son
php.inilui appartiennent, et relever une limite pour une application exigeante ne la relève que pour cette application. - Un environnement d'exécution est supervisé, pas laissé au hasard. Une application Node.js ou un conteneur est démarré par le serveur, redémarré s'il s'arrête, et relancé après un redémarrage de la machine. Rien ne dépend d'un terminal que quelqu'un aurait laissé ouvert.
- Le panneau propose les bonnes pages et masque les mauvaises. Le programme d'installation et la page des extensions appartiennent aux sites PHP. Un site que l'on fait passer de PHP à autre chose perd ces deux pages et rien d'autre : il garde ses fichiers, ses domaines, son certificat, son courriel et ses sauvegardes.
- Les limites sont appliquées là où se trouve l'environnement d'exécution. Les limites de processeur, de mémoire et de processus s'appliquent à ce qui s'exécute réellement, si bien qu'un site très sollicité est borné plutôt que bruyant.
Il en résulte que la surface d'attaque d'un site est la surface de ce qu'il fait. Un site vitrine statique sur un serveur Dashmox est un répertoire et un serveur web, et la longue traîne des vulnérabilités de PHP n'est pas une chose qui peut lui arriver, car l'interpréteur n'a jamais été placé devant lui.
Changer d'avis
Un environnement d'exécution est un réglage, pas une reconstruction.
Ouvrez le site, choisissez un autre environnement d'exécution, appuyez sur Appliquer l'environnement. C'est le même site avec un autre moteur derrière lui : les domaines restent, le certificat reste, les fichiers restent où ils sont, les boîtes aux lettres sont intactes, les sauvegardes se restaurent toujours.
Cela compte plus qu'il n'y paraît, car l'autre solution est ce que les gens font réellement : créer un second site, tout y copier, déplacer le domaine, réémettre le certificat et espérer n'avoir pas oublié le DNS. Un réglage que vous pouvez changer est un réglage que vous changerez quand l'application changera. Un réglage que vous ne pouvez pas changer est une raison de laisser à jamais un site statique sous PHP.
Une seule règle : un site doit être achevé et en bonne santé avant que son environnement d'exécution ne change. Un site encore en cours de création, ou resté en erreur, doit d'abord se stabiliser, car changer ce qui tourne sous un site à moitié construit est la façon d'obtenir un site qui n'est ni l'un ni l'autre.
Ce qui reste pareil quel que soit votre choix
Les éléments placés devant votre application.
- Son propre compte Linux. Chaque site s'exécute sous un utilisateur qui lui est propre et ne peut pas lire les fichiers d'un autre site, quel que soit l'environnement d'exécution qu'il utilise.
- Ses domaines et un certificat gratuit. nginx détient les noms et le certificat Let's Encrypt, et le renouvelle. Votre application n'apprend jamais ce qu'est le TLS.
- Courriel, DNS, sauvegardes et tâches planifiées. Rien de tout cela ne se soucie de ce qu'exécute le site. Une application Node.js peut avoir des boîtes aux lettres sur son domaine et une sauvegarde nocturne, comme n'importe quel autre site.
- La même isolation. Les protections décrites sur la page sécurité s'appliquent à tous les environnements d'exécution, et celles propres à PHP, comme la désactivation des fonctions dont un interpréteur de commandes web a besoin, ne se posent simplement pas là où il n'y a pas de PHP.
Vos serveurs, sans que rien de ce qu'ils portent ne soit compté.
Le panneau entier est gratuit sur un serveur, sans limite de sites, de boîtes aux lettres, de zones DNS ou de comptes clients. Pro, jusqu'à cinq serveurs, n'est pas encore disponible.