Orbiter — Guide des fonctionnalités

Orbiter Shield — Protection des fichiers au niveau du noyau

Shield protège les fichiers du cœur du CMS, les plugins et les thèmes en montant le document root en lecture seule (:ro) au niveau de Docker/du noyau. Ce n'est pas un chmod — même root à l'intérieur du conteneur ne peut pas écrire dans les répertoires protégés.

Profils intégrés

Comment activer Shield

1. Ouvrez le panneau d'actions du domaine
2. Cliquez sur la section Shield
3. Sélectionnez un profil (détecté automatiquement selon le CMS)
4. Cliquez sur Activer — le conteneur est recréé avec les montages en lecture seule

Remarques importantes

• L'activation de Shield recrée le conteneur (brève coupure de quelques secondes)
• Si un plugin tente d'écrire dans un répertoire protégé, il obtiendra une erreur Permission Denied
• Pour WordPress : les plugins qui se mettent à jour automatiquement échoueront — utilisez plutôt le système de mise à jour de l'administration WordPress
• Pour Laravel : l'autodétection distingue la disposition de type Plesk (application à l'intérieur du docroot) de la disposition standard (application au parent de public/)
• Le blocage d'exécution nginx bloque en outre l'exécution des fichiers .php, .pl, .sh, .py dans les zones accessibles en écriture, en défense en profondeur

Désactiver Shield

Désactivez depuis la section Shield du panneau d'actions. Le conteneur est recréé en mode lecture-écriture.

Orbiter Fortress — Anti-exfiltration et WAF

Fortress est un profil de durcissement multicouche appliqué par domaine. Là où Shield protège le système de fichiers (montages en lecture seule), Fortress se concentre sur la protection à l'exécution : blocage des fonctions PHP dangereuses, restriction de la portée du système de fichiers, filtrage des requêtes HTTP malveillantes, limitation du trafic sortant et analyse des téléversements.

Les couches

• WAF (nginx) — filtrage des requêtes : motifs SQLi/LFI/XSS, mauvais user-agents, signatures de scanners, xmlrpc, accès aux fichiers .env/.git, bloqués. Renvoie un 403.
• Durcissement PHP — disable_functions (exec, eval, system, …) injecté dans le pool, plus le confinement open_basedir aux chemins du domaine.
• Contrôle de sortie — règles iptables limitant les connexions sortantes du conteneur (permissif / standard / strict).
• Scanner de téléversement — surveille les répertoires de téléversement accessibles en écriture, détecte les vrais types MIME, ré-encode les images, met en quarantaine les fichiers suspects.
• Nettoyage WP — supprime les mu-plugins Orbiter résiduels sur les sites précédemment protégés.

Comment activer Fortress

1. Ouvrez le panneau d'actions du domaine → Fortress
2. Choisissez un profil par cas d'usage (ou Avancé pour un contrôle total)
3. Enregistrez — les couches sont appliquées sans recréer le conteneur dans la plupart des cas

Avancé : listes et chemins manuels

La section Avancé (intitulée « Avancé — listes et chemins manuels » dans l'interface) vous donne un contrôle direct et fin sur deux éléments que les profils gèrent autrement pour vous :

1. Fonctions PHP bloquées (disable_functions)

Une grille de cases à cocher listant chaque fonction PHP que Fortress peut désactiver pour ce domaine (exec, shell_exec, system, passthru, eval, proc_open, popen, parse_str, …).

• Une fonction cochée est bloquée — PHP déclenchera une erreur fatale si l'application tente de l'appeler.
• Décochez une fonction pour l'autoriser à nouveau — faites-le lorsqu'un plugin ou un framework légitime en a besoin (par ex. un plugin de sauvegarde qui exécute des commandes shell, ou une bibliothèque d'images utilisant proc_open).
• Utilisez le champ texte pour ajouter une fonction personnalisée absente de la liste par défaut (séparées par des virgules). Cela vient s'ajouter à la directive disable_functions du domaine.

⚠️ Bloquer exec/system/proc_open est la mesure d'atténuation la plus efficace contre les web-shells PHP — gardez-les bloquées sauf si une fonctionnalité précise cesse de fonctionner. Lorsque quelque chose casse avec une erreur « call to undefined/disabled function », c'est ici qu'il faut regarder en premier.

2. Chemins supplémentaires pour open_basedir

Par défaut, Fortress confine l'accès aux fichiers PHP au document root du domaine et à ses sous-chemins standard. Si votre application a légitimement besoin de lire ou d'écrire en dehors de cette arborescence (un répertoire de bibliothèque partagé, un montage NFS, un projet voisin), ajoutez ici le chemin absolu — un par ligne.

• Chaque chemin doit rester sous /var/www/vhosts/ (les chemins en dehors de cette arborescence sont rejetés par sécurité).
• Ajouter un chemin élargit le bac à sable — n'ajoutez que ce qui est strictement nécessaire. Chaque chemin supplémentaire est une route d'exfiltration potentielle si le site est compromis.
• Laissez vide pour conserver le confinement strict par défaut.

Quand utiliser Avancé plutôt qu'un profil

• Utilisez un profil si votre stack correspond à l'un des cas d'usage — il est sélectionné et maintenu pour vous.
• Utilisez Avancé lorsqu'aucun profil ne convient, lorsqu'un profil est trop strict pour un plugin spécifique, ou lorsque vous devez élargir open_basedir pour une disposition non standard. Les modifications sont par domaine et persistent à travers les recréations de conteneur.

Désactiver Fortress

Désactivez depuis la section Fortress du panneau d'actions — toutes les couches (WAF, durcissement PHP, sortie, scanner de téléversement) sont retirées et la configuration nginx/PHP d'origine est restaurée.

Scanner de téléversement — Surveillance en temps réel

Le scanner de téléversement est la couche Fortress qui inspecte le contenu des fichiers au moment où ils arrivent sur le disque. Là où le WAF bloque les requêtes malveillantes et où Shield verrouille le système de fichiers en lecture seule, le scanner de téléversement surveille les répertoires de téléversement accessibles en écriture (qui, par définition, ne peuvent pas être en lecture seule) et intercepte les logiciels malveillants qui se faufilent en se faisant passer pour une « image » ou un « document ».

Fonctionnement

Un watcher Python léger s'exécute comme service systemd, un par domaine. Il utilise inotify pour réagir en temps réel : chaque fichier écrit ou déplacé dans un répertoire surveillé est analysé en quelques millisecondes — pas de cron, pas de polling, pas de délai. Les fichiers suspects sont déplacés vers un dossier de quarantaine et passés en chmod 0400 (lecture seule, propriétaire uniquement), afin qu'ils ne puissent jamais être servis ni exécutés.

Ce qui est surveillé

Le scanner cible automatiquement les chemins de téléversement accessibles en écriture du CMS détecté :

Vous pouvez ajouter des répertoires supplémentaires à surveiller depuis le panneau Fortress → Scanner de téléversement (chacun doit rester sous /var/www/vhosts/).

Les 7 contrôles

Chaque contrôle peut être activé ou désactivé individuellement par domaine sans arrêter l'ensemble du watcher :

1. Type MIME (scan_mime) — lit le type réel via libmagic (et non l'extension du nom de fichier). Rejette tout ce qui sort de la liste autorisée (images, PDF, documents courants).
2. Charge utile PHP (scan_php) — analyse par regex sur octets bruts à la recherche de code PHP / d'appels de fonctions dangereuses n'importe où dans le premier 1 Mo. Repère les web-shells <?php déguisés en .jpg.
3. Inspection ZIP (scan_zip) — inspecte les entrées d'archive, se prémunit contre le ZipSlip (traversée de chemin) et les bombes zip.
4. Assainissement SVG (scan_svg) — analyse le XML et refuse <script>, les URL javascript: et les gestionnaires d'événements on* (le SVG est un vecteur classique de XSS stocké).
5. Inspection PDF (scan_pdf) — signale les actions /JavaScript, /Launch et /EmbeddedFile.
6. Contrôle d'entropie (scan_entropy) — entropie de Shannon > 7.5 sur les fichiers text/plain / application/json (détecte les charges utiles compactées/chiffrées dissimulées dans du « texte »).
7. Régénération d'image (scan_regen) — ré-encode les JPEG/PNG/GIF/WebP à partir des seules données de pixels via Pillow. Cela supprime tous les blocs de métadonnées — EXIF, IPTC, XMP, ICC, commentaires — de sorte que tout ce qui est intégré dans les métadonnées (une astuce courante d'exfiltration/de charge utile) est détruit. L'image semble identique ; les octets cachés ont disparu.

Quarantaine

Les fichiers suspects sont déplacés vers quarantine/<file>.<timestamp>.<reason> et passés en lecture seule. Depuis le visualiseur de quarantaine (panneau Fortress), vous pouvez examiner les fichiers signalés, voir pourquoi chacun a été intercepté, restaurer un faux positif, ou vider la quarantaine en masse.

Un TTL configurable (7 / 14 / 30 / 60 / 90 jours, ou jamais) purge automatiquement les anciens fichiers en quarantaine via un cron quotidien, de sorte que le dossier ne grossit jamais sans limite.

Activation et configuration

1. Activez Fortress (le scanner est l'une de ses couches — activé par défaut).
2. Ouvrez Fortress → Scanner de téléversement pour :
   • activer/désactiver le watcher,
   • ajouter des répertoires surveillés supplémentaires,
   • activer/désactiver individuellement chacun des 7 contrôles,
   • définir le TTL de la quarantaine,
   • lancer un test d'injection (dépose une charge utile de test bénigne pour confirmer que le watcher l'intercepte).

Remarques

• Le watcher nécessite python3-magic (libmagic) et python3-pil (Pillow) sur l'hôte — installés automatiquement par Orbiter.
• Recréer ou migrer un domaine réécrit simplement la carte des répertoires du watcher et redémarre le service — aucune reconfiguration nécessaire.
• Les fichiers sains, non-images, sont laissés intacts ; seuls les fichiers signalés sont mis en quarantaine.

Pare-feu applicatif web (WAF)

Le WAF est la couche Fortress qui filtre les requêtes HTTP entrantes au niveau de nginx — avant qu'elles n'atteignent PHP. Chaque règle inspecte l'URL, la chaîne de requête ou les en-têtes et renvoie un 403 Forbidden en cas de correspondance. C'est la première ligne de défense contre les attaques automatisées les plus courantes.

Ce que fait chaque règle

Conséquences à garder à l'esprit

• Il peut bloquer du trafic légitime. Chaque règle est un compromis entre sécurité et compatibilité. Si une fonctionnalité de votre site cesse de fonctionner après l'activation de Fortress (un formulaire renvoie un 403, une intégration échoue), le WAF est le premier endroit où regarder — ouvrez l'onglet WAF et décochez la règle fautive.
• xmlrpc est la règle la plus fréquemment désactivée sur les sites WordPress qui utilisent l'application mobile ou Jetpack.
• Le WAF ne voit que ce qui passe par nginx. Les requêtes servies depuis le cache ou traitées par un CDN devant le serveur ne sont pas inspectées par lui.

En-têtes de sécurité

Lorsque le WAF est actif, Fortress ajoute également des en-têtes de réponse de sécurité modernes : X-Content-Type-Options: nosniff, X-Frame-Options: SAMEORIGIN, Referrer-Policy, Permissions-Policy, et une Content-Security-Policy qui restreint les domaines externes autorisés à charger des scripts/styles/polices. Voyez la section Avancé — listes et chemins manuels si vous devez autoriser un CDN externe.

Réglage fin

Toutes les règles s'activent par domaine dans Fortress → WAF, ou sont guidées par l'assistant de configuration lors de la première activation de Fortress. Les modifications s'appliquent immédiatement (rechargement de nginx), avec un rollback automatique si la configuration générée échoue au nginx -t.

Durcissement PHP — Standard vs Strict

Le durcissement PHP injecte une directive disable_functions dans le pool PHP-FPM du domaine, neutralisant les fonctions les plus exploitées par les web-shells et les scripts d'exfiltration. Il confine également l'accès aux fichiers avec open_basedir. Orbiter propose deux niveaux.

Standard (recommandé)

Bloque les fonctions d'exécution système et de bas niveau — celles dont un web-shell PHP a besoin pour causer de réels dégâts :

exec, system, passthru, shell_exec, popen, proc_open, pcntl_exec, pcntl_fork, proc_*, fsockopen, pfsockopen, socket_* / stream_socket_* bruts, assert, dl, phpinfo, link, symlink, putenv.

C'est compatible avec la grande majorité des CMS et plugins, car les applications PHP normales n'exécutent pas de commandes système. C'est la mesure anti-RCE la plus efficace à elle seule.

Strict

Tout ce qui est dans Standard plus les fonctions réseau et de messagerie :

file_get_contents, fopen, curl_init, curl_exec, curl_multi_*, dns_get_record, gethostbyname, gethostbyaddr, getmxrr, checkdnsrr, mail.

Cela empêche un site compromis de « téléphoner à la maison » (exfiltrer des données ou récupérer une charge utile de deuxième étage) — mais c'est intrusif.

⚠️ Strict casse beaucoup de choses. Tout plugin qui appelle une API externe, récupère une URL distante, envoie un e-mail via le mail() de PHP, ou résout du DNS cessera de fonctionner. Réservez Strict aux sites isolés (API internes, sites statiques/vitrines sans besoin sortant). Pour un site WordPress/WooCommerce normal, utilisez Standard.

Conséquences et comment récupérer

Si une fonctionnalité casse après l'activation du durcissement, vous verrez généralement une erreur « Call to undefined function » ou « … has been disabled for security reasons » dans le journal PHP. Pour la corriger :

1. Ouvrez Fortress → PHP → Avancé — listes et chemins manuels.
2. Décochez la fonction précise dont le plugin a besoin (par ex. ré-autoriser curl_exec pour une passerelle de paiement).
3. Enregistrez — la modification est par domaine et persiste à travers les recréations de conteneur.

Vous pouvez aussi ajouter des fonctions personnalisées à bloquer, ou élargir open_basedir pour des dispositions non standard. Voyez Avancé — listes et chemins manuels.

Note sur la sortie réseau (egress)

Le blocage des fonctions réseau de Strict est un contrôle au niveau de PHP. Pour une restriction sortante au niveau du noyau (indépendante de PHP), utilisez plutôt la couche Egress (règles iptables permissif / standard / strict) — elle ne peut pas être contournée par une fonction PHP alternative.

Contrôle de sortie (Egress) — Réseau sortant

Le contrôle de sortie restreint ce à quoi le conteneur peut se connecter en sortie, à l'aide de règles iptables au niveau du noyau sur l'IP du conteneur. Contrairement aux disable_functions de PHP (qu'une charge utile habile pourrait contourner), les règles de sortie s'appliquent à tous les processus du conteneur — PHP, un shell, un binaire compilé — de sorte qu'un site compromis ne peut pas « téléphoner à la maison » ni pivoter vers votre réseau interne.

Les trois modes

En mode Strict, vous fournissez une liste d'autorisation d'adresses IPv4 (ou de plages CIDR) dans le panneau Fortress ; toute autre destination est rejetée.

Conséquences à garder à l'esprit

• Strict cassera tout ce que vous oubliez d'autoriser — serveurs de mise à jour de plugins, relais SMTP, API tierces, vérifications de licence. Commencez par Standard et ne passez à Strict qu'une fois que vous connaissez chaque point de terminaison contacté par votre site.
• La sortie (egress) est au niveau du noyau et plus robuste que le blocage réseau de PHP Strict, mais les deux sont complémentaires : le durcissement PHP empêche la fonction d'exister, la sortie arrête le paquet quelle que soit la façon dont il est envoyé.
• Les connexions bloquées sont rejetées (et non silencieusement abandonnées), de sorte que PHP obtient une erreur claire « connection refused » que vous pouvez tracer.

Scanner de téléversement

La même étape de l'assistant active/désactive le scanner de téléversement — le watcher en temps réel qui inspecte le contenu des fichiers téléversés. Il est détaillé dans sa propre section : Scanner de téléversement — Surveillance en temps réel.

Réglage fin

Définissez le mode de sortie (et la liste d'autorisation Strict) dans Fortress → Egress, ou via l'assistant de configuration. Les règles sont appliquées immédiatement et retirées proprement lorsque Fortress est désactivé.

Cache Nginx

Orbiter inclut un cache Nginx FastCGI/proxy intégré qui peut accélérer les pages jusqu'à 10× pour les visiteurs.

Activer le cache

Rendez-vous dans la section Cache du domaine, dans le panneau d'actions, et cliquez sur « Activer le cache ». Choisissez un profil CMS pour des exclusions automatiques (zones d'administration, panier, paiement, etc.).

Options de TTL du cache

1 minute (debug), 5 minutes, 15 minutes, 30 minutes, 1 heure, 6 heures, 24 heures.

Options avancées

• Contournement sur les chaînes de requête — Exclure du cache les URL avec ?parameter
• URL personnalisées à exclure — Une URL par ligne, regex Nginx prise en charge
• Cookies personnalisés à contourner — Si un cookie précis est présent, ignorer le cache
• Ignorer Cache-Control — Mettre en cache même si PHP envoie Cache-Control: no-cache
• Ignorer Set-Cookie — Mettre en cache même si PHP envoie un cookie de session
• Cache mobile séparé — Servir un contenu mis en cache différent aux appareils mobiles
• Jeton de purge — Jeton permettant de purger le cache depuis un script externe (par ex. après un déploiement)

Purge du cache

Utilisez le bouton « Purger le cache » dans le panneau Cache, ou appelez le point de terminaison de purge du cache avec le jeton configuré.

Limites de ressources

Chaque conteneur prend en charge des limites de ressources indépendantes, définies via l'icône des curseurs sur la ligne du domaine.

Limites PHP-FPM (distinctes des limites du conteneur) :

• pm.max_children — Nombre maximal de workers PHP concurrents
• request_terminate_timeout — Délai avant qu'un script PHP ne soit tué
• ProxyTimeout (mode Apache uniquement) — Délai avant qu'Apache ne renvoie un 504 au client

Limites Plesk natives — Protéger Orbiter des sites non conteneurisés

Accessibles via Sites → Limites Plesk natives. Ces plafonds protègent l'hôte des sites qui tournent encore nativement sous Plesk (pas encore conteneurisés). Un site Plesk natif qui s'emballe — plugin WordPress bogué, cron en boucle, attaque — peut saturer le CPU/la RAM du serveur et perturber Orbiter ainsi que tous les sites conteneurisés à ses côtés. Les trois niveaux ci-dessous sont un filet de sécurité pour ce cas.

Les sites à l'intérieur d'un conteneur Orbiter ne sont pas affectés. Ils sont déjà isolés avec leurs propres limites Docker (configurées par conteneur via l'icône des curseurs — voir Limites de ressources ci-dessus).

Les trois niveaux (cgroup v2 de systemd)

Orbiter écrit un fichier drop-in pour chaque niveau. Le noyau impose le plafond ; les processus sont bridés dès qu'ils le dépassent.

Chaque niveau dispose de sa propre rangée de préréglages — Conservateur, Standard, Généreux, Illimité — plus des champs CPU / RAM / Tâches modifiables. Le bouton Configuration guidée en haut vous accompagne à travers les trois niveaux dans un seul assistant, avec des scénarios concrets.

Important : la granularité est au niveau du service, pas par site

Le cgroup systemd affecte les processus par le lanceur, et non par l'UID Unix sous lequel ils s'exécutent. Cela a deux conséquences pour PHP-FPM :

• Le plafond PHP-FPM est bien imposé — mais c'est un plafond unique partagé par tous les sites servis par cette version de PHP. Vous ne pouvez pas fixer 100 % de CPU sur siteA.com et 200 % sur siteB.com via systemd. Les deux partagent le même cgroup plesk-php84-fpm.service.
• Pour un réglage PHP-FPM par site, utilisez les contrôles natifs de Plesk : Domaines → site → Réglages PHP — pm.max_children, pm.max_requests, request_terminate_timeout, php_admin_value[memory_limit]. Ceux-ci ne brident pas le CPU au niveau du noyau, mais plafonnent la concurrence et la RAM par worker.
• Si vous avez besoin de véritables plafonds CPU/RAM par site avec un bridage au niveau du noyau, conteneurisez le site. Chaque conteneur Orbiter est son propre cgroup avec ses propres limites.

Surcharges CLI par utilisateur

L'onglet CLI utilisateur possède un sous-onglet Surcharges par utilisateur — un tableau de chaque utilisateur système Plesk (un par domaine principal) avec recherche, puces de filtre (Tous / Avec surcharge / Hérite du global) et pagination. Le bouton Configurer sur une ligne ouvre une mini-fenêtre avec les mêmes préréglages pour définir un plafond spécifique à l'utilisateur qui prend le pas sur la valeur par défaut globale. Utile lorsqu'un client a légitimement besoin de lancer des tâches WP-CLI lourdes (par ex. wp media regenerate sur 50 000 images).

La surcharge est écrite dans /etc/systemd/system/user-<UID>.slice.d/orbiter-override.conf. La supprimer (bouton Retirer la surcharge) efface le drop-in et l'utilisateur revient au plafond global, appliqué en direct.

À quoi ressemble une configuration typique

Le préréglage Standard de l'assistant sur un serveur équilibré donne :

Un plugin bogué provoquant une boucle incontrôlée est alors plafonné à 2 cœurs et 4 Go de RAM, quel que soit le site natif sur lequel il tourne — le serveur reste réactif pour tout le reste, y compris les sites conteneurisés.

Ce qui n'est pas couvert

Ces plafonds protègent Orbiter et les autres sites des sites Plesk natifs qui se comportent mal. Ils ne protègent pas un site natif de lui-même — un site exécutant une requête SQL de 60 secondes ne verra cette requête interrompue que si le request_terminate_timeout de son propre pool intervient. Pour une isolation complète (CPU/RAM/IOPS strictement imposés par site, plus l'isolation du système de fichiers, plus sa propre MariaDB si nécessaire), conteneurisez le site via Conteneuriser sur sa ligne.

Capacité du serveur — Conteneurs encore créables

L'onglet Capacité du tableau de bord estime combien de conteneurs supplémentaires votre serveur peut encore héberger avant de manquer de ressources. C'est une aide à la planification, pas une limite stricte — Orbiter ne bloque jamais la création sur la base de ce nombre.

Comment l'estimation fonctionne. Orbiter examine les ressources libres du serveur (RAM, CPU, disque et limites du noyau telles que les PID/le nombre de processus) et les divise par l'empreinte typique d'un conteneur. Le résultat correspond à la dimension la plus contrainte — c'est-à-dire que la ressource qui s'épuise en premier fixe le plafond.

Pourquoi le nombre change. L'estimation est dynamique : démarrer un conteneur de base de données, augmenter les limites de ressources d'un conteneur, ou d'autres sites devenant plus actifs, la feront baisser. Elle se rafraîchit automatiquement et peut être rafraîchie manuellement depuis l'onglet.

Les conteneurs avec une MariaDB intégrée pèsent plus lourd que les conteneurs sans base de données, car chaque MariaDB embarqué réserve de la mémoire et des processus. Si la capacité est plus basse que prévu, les conteneurs avec MariaDB activé en sont généralement la raison.

Bonne pratique. Traitez ce chiffre comme une marge de sécurité. Laissez de la réserve plutôt que de provisionner jusqu'à l'estimation, afin que les sites existants conservent suffisamment de ressources sous charge.

Déploiement Git

Configurez le déploiement automatique depuis un dépôt Git.

Mise en place

1. Ouvrez le panneau d'actions du domaine → section Déploiement Git
2. Saisissez l'URL du dépôt, la branche et le secret de déploiement
3. Ajoutez éventuellement un hook post-déploiement (commande shell exécutée après chaque déploiement)
4. Utilisez le bouton « Déployer maintenant » pour un déploiement manuel, ou l'URL du webhook pour les déclencheurs de push CI/CD

Note de sécurité

La route git-set est restreinte aux seuls administrateurs. Les utilisateurs de domaine ne peuvent pas configurer le déploiement git.

Surveillance de disponibilité

Orbiter surveille chaque domaine avec des sondes HTTP toutes les minutes.

Mise en place

Activez la surveillance de disponibilité depuis le panneau d'actions du domaine. Configurez :

• Le chemin à sonder (par défaut : /)
• L'e-mail d'alerte pour les notifications d'indisponibilité

Historique

La vue d'historique de disponibilité affiche les fenêtres d'indisponibilité avec horodatage. Le cron de surveillance s'exécute toutes les minutes.

Alertes par e-mail

Configurez des alertes par e-mail par domaine pour les événements de conteneur.

Types d'alertes

Anti-spam

Le même type d'alerte n'est pas renvoyé dans un délai de 60 minutes (temps de pause configurable).

Mode maintenance

Placez un domaine en mode maintenance avec un message 503 personnalisé.

Fonctionnalités

• Message de maintenance personnalisé affiché aux visiteurs
• Contournement par IP admin — votre IP peut toujours accéder au site normalement
• Activation/désactivation en un clic depuis le panneau d'actions du domaine
• Remplace la page de maintenance par défaut de Plesk

Quotas par domaine

Les administrateurs peuvent définir des quotas de ressources par client Plesk :

• Nombre maximal de conteneurs
• RAM totale maximale sur l'ensemble des conteneurs
• Nombre maximal de bases de données

Les quotas sont appliqués à la création du conteneur. Si un quota est dépassé, la création est bloquée avec une erreur « Quota exceeded ».

Synchronisation de sauvegarde externe

Les sauvegardes peuvent être automatiquement synchronisées vers des destinations externes après chaque sauvegarde planifiée.

Destinations prises en charge

• Amazon S3 (et stockages compatibles S3)
• SFTP
• FTPS

Mise en place

Allez dans Réglages → Sauvegardes → Destinations de sauvegarde. Ajoutez une destination, configurez les identifiants et utilisez « Tester la connexion » pour vérifier. Activez « Synchroniser automatiquement vers toutes les destinations externes » pour synchroniser après chaque sauvegarde automatique.

Tableau de bord OPcache

Consultez les statistiques OPcache par conteneur : taux de hits, mémoire utilisée, scripts en cache. Réinitialisation en un clic depuis le panneau PHP.

Test de vitesse de page

Lancez un test de TTFB (Time To First Byte) avec décomposition par phase via curl, directement depuis l'interface Orbiter. Une sonde externe optionnelle via SSH fournit des mesures de latence réseau réalistes.

Console web

Accès terminal complet à l'intérieur de chaque conteneur depuis le navigateur.

• S'exécute sous l'utilisateur propriétaire du domaine (permissions de fichiers correctes)
• Prend en charge les commandes bash standard : ls, cd, cat, grep, etc.
• Outils PHP disponibles : composer, artisan, wp-cli
• Accès direct à MariaDB via le client mysql
• L'accès à la console peut être désactivé par les administrateurs, conteneur par conteneur

Journal des actions

Chaque domaine conserve une piste d'audit indiquant qui a fait quoi et quand :

• Création, suppression, recréation de conteneur
• Activation/désactivation de Shield
• Changements de version de PHP
• Notes ajoutées

Consultez le journal des actions depuis le panneau d'actions du domaine → section Notes.

Commandes CLI

Orbiter expose plus de 148 commandes CLI via plesk ext orbiter --<command>.

Commandes courantes

# Container management
plesk ext orbiter --create-container <domain>
plesk ext orbiter --delete-container <domain>
plesk ext orbiter --recreate-container <domain>
plesk ext orbiter --start-container <domain>
plesk ext orbiter --stop-container <domain>
plesk ext orbiter --restart-container <domain>

# PHP
plesk ext orbiter --set-php-version <domain> --php-version 8.2
plesk ext orbiter --get-php-config <domain>
plesk ext orbiter --set-php-config <domain> --key memory_limit --value 512M

# Database
plesk ext orbiter --db-export <domain> --db-name mydb > dump.sql
plesk ext orbiter --db-import <domain> --db-name mydb --file dump.sql

# Shield
plesk ext orbiter --shield-enable <domain> --profile wordpress
plesk ext orbiter --shield-disable <domain>
plesk ext orbiter --shield-status <domain>

# Monitoring
plesk ext orbiter --system-health
plesk ext orbiter --version
plesk ext orbiter --os-info

Note sur db-export

Le dump SQL est envoyé sur stdout. Redirigez-le vers un fichier :

plesk ext orbiter --db-export <domain> --db-name mydb > dump.sql 2>/dev/null

Les messages de statut vont sur stderr et ne contamineront pas le fichier de dump.