Méthode automatique : un seul script depuis l'espace client prépare tout le serveur (pile web Apache + PHP, base de données, outils de sécurité, cron). Ensuite — déployez le tableau de bord, émettez le SSL et saisissez la licence. Fonctionne sous Ubuntu/Debian : sur un VPS neuf il configure tout de zéro, sur un serveur déjà configuré — de façon uniquement additive (profil « Serveur configuré », étape 01). Toutes les commandes ci-dessous sont dans l'ordre, il suffit de faire défiler du haut vers le bas. Sur un VPS neuf, chaque étape s'applique telle quelle ; si le serveur est déjà configuré ou s'il porte un panneau d'hébergement, le script vous laisse volontairement une partie du travail — il indique laquelle à la fin de son exécution (analyse de la sortie à l'étape 01).
monitor.example.com — votre domaine ; 203.0.113.10 — l'IP réelle du serveur ; /var/www/monitor — la racine du tableau de bord (où se trouvent public/, assets/, config.php) ; choisissez votre propre mot de passe BD.
jail.local), crontab root, règles UFW, configuration Apache. Si le serveur est déjà configuré (tableau de bord opérationnel, sites, messagerie, vos propres jails) — choisissez le profil « Serveur configuré » : il n'apporte que des modifications additives et ne touche ni à votre pare-feu, ni à Fail2ban, ni à la messagerie, ni au SSH, ni à sysctl. Si une panneau d'hébergement est détecté, le script bascule tout seul dans ce mode. Avant le premier lancement, vous pouvez activer le test à blanc (case à cocher dans l'espace client) — il montre ce qui sera fait, sans rien modifier. Sur un serveur en production, faites un instantané (snapshot) par précaution.
my.arciveo.com → rubrique « Configuration du serveur » (accessible après souscription à Arcivéo Security Monitor). Elle est liée à votre compte et contient un jeton personnel.
Le script prépare l'intégralité du serveur : pile web (Apache + PHP), base de données, outils SSL, jeu complet de moyens de protection et tâches cron (Lynis, SMART, debsums, Logwatch, rapport quotidien, mise à jour d'ipsum).
1) Choisissez le niveau de protection (dans l'espace client, avant de copier la commande) :
2) Exécutez sur le serveur en tant que root la commande de l'espace client — elle se présente ainsi :
3) Lisez la sortie affichée à la fin — elle indique ce qui reste à votre charge. Le script termine son exécution par un bloc de vérifications et la liste « Ensuite — installation du panneau ». Une partie des étapes, il ne les fait délibérément pas : lesquelles dépend du profil choisi et de ce qu'il a trouvé sur le serveur. Reportez-vous à la liste ci-dessous — vous ne devez exécuter que les points dont la ligne est apparue dans votre sortie.
Control panel detected (…) — le site se crée avec les moyens du panneau d'hébergement lui-même, le script ne crée pas de vhost. Étape 03, branche « Serveur avec panneau d'hébergement ».No vhost created (no domain given) — profil « Serveur configuré » sans domaine : un vhost sans nom deviendrait le site par défaut et intercepterait vos propres sites, il n'a donc pas été créé. Étape 03, branche « Créer le vhost manuellement ».sudo rules NOT written — le script n'a pas pu déterminer sous quel compte tourne le panneau. C'est une situation normale : les fichiers du panneau sont transférés après la configuration automatique, il n'y avait donc encore rien sur quoi se baser. Sans ces règles, les modules ne verront pas les données système. Étape 04, bloc « Le sudo pour le serveur web ».! Nginx does not read .htaccess — Nginx est placé devant Apache, et l'inscription de l'interdiction dans sa configuration n'a pas abouti automatiquement. Faites-le impérativement : sinon data/, keys/, database/ et config.php sont servis vers l'extérieur en contournant le .htaccess. Étape 03, bloc « Si Nginx est placé devant Apache ».UFW installed but inactive — le pare-feu est installé mais désactivé : sur un serveur déjà configuré, le script ne l'active pas de lui-même, afin de ne pas vous couper l'accès. Activez-le vous-même, en autorisant impérativement votre port SSH :
Fail2ban installed but not running — lancez-le : sudo systemctl enable --now fail2ban.Database server present … but not running — démarrez le SGBD avant l'étape 04 : sudo systemctl enable --now mariadb (ou mysql — selon ce qui est installé).Certbot skipped — issue SSL in … — le certificat s'émet avec l'interrupteur Let's Encrypt du panneau d'hébergement ; l'étape 06 ne vous concerne pas.All checks passed. Les points marqués d'un ! demandent votre attention ; les détails sont écrits dans le journal, dont le chemin est affiché tout à la fin (Log: …).
Pour ouvrir le tableau de bord à une adresse comme monitor.example.com et obtenir un SSL gratuit, le domaine doit pointer vers le serveur. Dans le panneau de gestion DNS (chez votre registraire ou hébergeur), créez un enregistrement A :
Au bout de quelques minutes (parfois jusqu'à une heure), vérifiez que le domaine pointe vers le serveur :
/var/www/monitor et configuré le site Apache (DocumentRoot vers la racine du panneau, PHP-FPM, AllowOverride pour .htaccess). Dans la sortie du script, c'est la ligne vhost … → DocumentRoot …. Pas besoin de créer séparément un répertoire ou un vhost — transférez simplement les fichiers et définissez les droits.
Branche « Serveur avec panneau d'hébergement » (dans la sortie : Control panel detected (…)). Sur un tel serveur, ce sont les moyens du panneau qui gèrent les sites, et le script ne crée délibérément pas son propre vhost — il serait écrasé dès la première reconstruction des configurations par le panneau. Procédez ainsi :
public_html de ce domaine : à côté d'index.php, api/, assets/ doivent également se trouver les dossiers de service config.php, includes/, data/, tmp/, logs/, keys/, cron/, database/. Rien n'est à sortir au-dessus de la racine web : les dossiers de service sont protégés par le fichier .htaccess de la distribution, et sous Nginx — par l'interdiction que le script a inscrite dans la configuration du domaine.config.php (étape 05). Dans les commandes, remplacez les chemins par /home/compte/web/domaine/public_html, et le propriétaire — par l'utilisateur de ce domaine au lieu de www-data.Branche « Créer le vhost manuellement » (dans la sortie : No vhost created (no domain given)). Cela n'arrive que sur le profil « Serveur configuré », lorsque le domaine n'a pas été transmis. Le plus simple est de relancer la commande de l'espace client en indiquant le domaine :
Une nouvelle exécution est sans risque : ce qui est déjà fait n'est pas dupliqué. Et si le vhost doit être créé à la main — voici la configuration même qu'écrit l'installateur :
ServerName est ici obligatoire. Un vhost sans nom devient le site Apache par défaut et se met à répondre pour les autres domaines du même serveur. Pour la même raison, ne désactivez pas 000-default.conf sur un serveur déjà configuré : ce site a pu être transformé en site de production pour quelqu'un — sur un VPS neuf, l'installateur le retire lui-même, ici ce n'est pas à faire.
! Nginx does not read .htaccess). Nginx sert les fichiers statiques directement depuis le disque et ne lit pas le .htaccess — les dossiers de service se retrouvent ouverts vers l'extérieur, alors même qu'Apache les protège correctement. Le script a préparé à l'avance un fichier d'interdictions ; il faut l'inclure dans le bloc server{} de votre site et recharger Nginx :
my.arciveo.com → « Téléchargements ». Décompressez l'archive avant de l'envoyer sur le serveur.
Transférez le contenu de la distribution dans /var/www/monitor (pour y retrouver public/, assets/, config.php, etc.) — par SFTP/SCP (FileZilla / WinSCP) ou avec la commande scp depuis votre ordinateur local :
ServerName), on le passe à la commande de configuration automatique dès l'étape 01 : … | sudo bash -s -- monitor.example.com (ou on indique le domaine dans le champ « Domaine du panneau » de l'espace client). Si le domaine n'a pas été fourni, le panneau répond à n'importe quel hôte et par IP, et ServerName sera inscrit par certbot lors de l'émission du SSL (étape 06) ; rien n'est à réinstaller.
root ou par SFTP, les fichiers appartiennent à root, et le serveur web (www-data) ne pourra pas les lire — le panneau s'ouvrira vide ou avec une erreur 403 (dans le journal : .htaccess unreadable / directory not executable). La commande ci-dessous corrige cela :
Ouvrez-vous l'accès au transfert par SFTP. Après la commande ci-dessus, tous les fichiers appartiennent à www-data, alors que FileZilla / WinSCP se connectent sous votre propre utilisateur — le transfert échouera alors avec SSH_FX_PERMISSION_DENIED (Permission denied). Choisissez l'une des deux variantes.
Variante A — une ACL pour votre utilisateur uniquement (recommandé). Vous seul obtenez le droit d'écriture ; le serveur web ne peut toujours pas réécrire le code du panneau :
Variante B — via le groupe www-data. Plus simple, mais le serveur web obtient lui aussi le droit d'écriture sur les fichiers du panneau : en cas de faille dans PHP, le code pourrait être remplacé. L'ordre des commandes compte — config.php et les dossiers de travail sont verrouillés en dernier :
id deploy — www-data doit apparaître dans la liste des groupes ; ls -ld /var/www/monitor — droits drwxrwsr-x, la lettre s à la place de x signifie que setgid est activé.
Créez la base et l'utilisateur, puis importez le schéma. Le bloc BDD se colle en entier dans le terminal (sudo mysql connecte root via socket unix — pas besoin du mot de passe root). monitor_db et monitor_user sont des noms d'exemple, vous pouvez choisir les vôtres ; retenez le nom de la base, l'utilisateur et le mot de passe — vous les saisirez dans config.php à l'étape suivante :
admin lors du premier accès dans le navigateur (depuis database/db.sql), si la base est vide.
Si les tables n'ont pas été créées (le tableau de bord affiche une erreur de connexion à la BD ou un écran vide au lieu du formulaire de connexion) — importez le schéma manuellement. La commande s'exécute à la racine du panneau, les valeurs sont reprises du bloc ci-dessus :
$DBNAME / $DBUSER / $DBPASS sont déjà « oubliées » (nouvelle session du terminal) — indiquez les valeurs à la main dans la commande ou redéfinissez-les avec les trois mêmes lignes du bloc ci-dessus.
sudo rules NOT written figurait dans la sortie du script — il n'y avait rien sur quoi se baser pour déterminer le compte du panneau (les fichiers n'étaient pas encore transférés), et les règles n'ont pas été créées. Sans elles, les sections comme le pare-feu, Fail2ban et CrowdSec resteront vides. Maintenant que les fichiers sont en place, relancez la commande de l'espace client en nommant le compte explicitement :
www-data par l'utilisateur sous lequel tourne le PHP de votre site (sur un panneau d'hébergement, c'est généralement le propriétaire du domaine). Vous pouvez le voir ainsi :
/etc/sudoers.d/monitor existe et contient des lignes avec votre utilisateur.
config.php à la racine du tableau de bord (/var/www/monitor/config.php) est le seul fichier à modifier manuellement. Tous les paramètres du tableau de bord y sont définis par des constantes define(). Ouvrez-le dans un éditeur :
Remplacez par vos valeurs aux endroits surlignés ; laissez le reste tel quel :
À modifier :
DB_NAME, DB_USER, DB_PASS — exactement les mêmes nom de base, utilisateur et mot de passe que ceux définis à la création de la BD à l'étape 04 (si vous avez gardé les exemples — monitor_db / monitor_user). Ne touchez pas à DB_HOST ni DB_CHARSET.APP_URL — adresse complète du tableau de bord avec https://, sans slash final ni www. Elle doit correspondre au domaine sur lequel vous activez la licence (étape 07), sinon la clé sera rejetée.TIMEZONE — votre fuseau horaire (liste : timedatectl list-timezones). N'affecte que l'affichage des dates par le tableau de bord ; n'affecte pas l'heure de lancement des tâches cron (c'est le fuseau du système qui s'applique).SESSION_LIFETIME — après combien de secondes d'inactivité le tableau de bord demande une reconnexion (8 heures par défaut). Par ex. 3600 = 1 heure, 86400 = un jour.display_errors, log_errors, error_log) — laissez-le par défaut.Enregistrez le fichier (Ctrl+O, Enter, puis Ctrl+X) et redémarrez PHP-FPM — sinon, à cause d'OPcache, les modifications ne s'appliqueront pas :
640 (définis à l'étape 03) et interdiction explicite dans le .htaccess racine. Ne le publiez pas sur des dépôts publics et ne le transmettez pas au support avec le vrai mot de passe.
http://, la connexion est impossible.
Certbot skipped — issue SSL in …). Le certificat s'émet avec l'interrupteur Let's Encrypt sur le domaine web du panneau lui-même — c'est donc aussi le panneau qui s'occupe de son renouvellement.
certbot et le plugin pour Apache sont déjà installés par la configuration automatique. Le DNS du domaine doit déjà pointer vers le serveur (étape 02). Émission en une seule commande :
Si le tableau de bord doit aussi s'ouvrir avec www. — énumérez les deux noms dans une seule commande, sinon le navigateur affichera un avertissement de certificat sur la seconde adresse :
Y.<VirtualHost *:443>, configurera la redirection http→https et le renouvellement automatique. À la fin — Successfully enabled HTTPS.
dig +short monitor.example.com renvoie l'IP du serveur et que les ports 80/443 sont ouverts (sudo ufw allow 80,443/tcp).
Après l'émission : https://monitor.example.com s'ouvre avec un cadenas, http:// redirige vers https://.
Ouvrez https://monitor.example.com, connectez-vous avec admin / useradmin et suivez la liste :
ARCIVEO-… depuis l'espace client sur votre domaine et collez la clé dans « Paramètres » → « Licence ». En savoir plus.public/start_db.php s'il subsiste : il permet de recréer la base sans authentification. Tant que le fichier reste à la racine du panneau ou dans public/, le panneau affiche un bandeau rouge d'avertissement.sudo /usr/local/bin/clamav-scan.sh) sollicite fortement le disque et le processeur et peut durer une heure ou davantage — sur un serveur en production, mieux vaut attendre le lancement nocturne de 01:30. Les sections « Disques (SMART) », « Performances » et « Mises à jour de sécurité » se remplissent d'elles-mêmes : toutes les 30 minutes, toutes les 5 minutes et une fois par heure respectivement.