Installation automatique

Un serveur prêt et sécurisé, en une commande.

L'installeur part d'un Debian 12 nu et livre un site en ligne : base de données, service applicatif, Nginx, certificat TLS, pare-feu, sauvegardes, surveillance. Il pose ses questions au début, puis enchaîne quinze étapes sans vous. Et il laisse derrière lui un serveur qui s'entretient seul.

Quinze étapes, toutes rejouables

Nom du site, domaine, compte d'administration, certificat, clé SSH : tout est demandé avant de commencer, puis résumé pour confirmation. Ensuite, plus rien à saisir. Chaque étape est idempotente — si l'une échoue, on corrige la cause et on relance la même commande, sans rien défaire.

[00] Pré-vol et vérifications
[01] Durcissement : pare-feu, SSH, fail2ban, sysctl, mises à jour auto
[02] Compte système, dossiers et permissions
[03] Dépendances système
[04] PostgreSQL — service et durcissement
[05] Base de données et rôle applicatif
[06] Memcached
[07] Environnement Python
[08] Paquet JEIKO et mécanisme de mise à jour
[09] Configuration Django (.env, settings, urls)
[10] Service Gunicorn
[11] Nginx
[12] Certificat Let's Encrypt et HTTPS
[13] Sauvegardes et surveillance
[14] Migrations, fichiers statiques, contrôle de santé

  1. Plusieurs sites par serveur. Chacun reçoit son compte Unix, sa base, son service et ses sauvegardes ; une faille dans l'un ne donne pas accès aux autres.
  2. Les secrets sont générés, pas choisis. La clé secrète de Django et, si vous laissez le champ vide, le mot de passe PostgreSQL (quarante caractères) sont tirés au hasard. Le mot de passe du compte d'administration sert une fois et n'est enregistré nulle part.
  3. Le compte d'administration peut se connecter tout de suite : son adresse est enregistrée comme vérifiée à la dernière étape.

La sécurité du serveur, posée d'office

Un serveur exposé sur Internet est sondé dans l'heure. L'installeur applique les protections qu'on oublie quand on configure à la main.

  1. Pare-feu. Tout est fermé en entrée, sauf SSH, HTTP et HTTPS (ports 22, 80 et 443).
  2. SSH. L'installeur propose de déposer votre clé publique, puis de couper la connexion par mot de passe — deux décisions séparées, pour ne jamais vous enfermer dehors. Le choix est mémorisé pour les sites suivants. Plus tard, une commande ajoute une clé et vérifie la configuration avant de l'appliquer.
  3. Fail2ban. Trois échecs de connexion SSH en dix minutes : l'adresse est bannie une heure. Une adresse qui dépasse vingt fois les limites de débit en cinq minutes est bannie deux heures.
  4. Limites de débit dans Nginx. Cinq tentatives de connexion par minute et par adresse, dix réservations ou écritures par minute, trente requêtes par seconde pour le reste. Un visiteur normal ne les atteint jamais.
  5. Un service enfermé. Le site tourne sous un compte sans shell ni dossier personnel, dans un service systemd qui ne voit ni /home ni le /tmp des autres, et ne peut pas réécrire le système.
  6. Des secrets à un seul endroit. Les identifiants du site vivent dans une fiche lisible par root seul ; le .env du site n'est lisible que par son propre compte.
  7. Les fichiers déposés ne s'exécutent jamais. Un .html, un .svg ou un .js envoyé par un formulaire est servi en téléchargement, dans un bac à sable — pas comme une page du site. Les .env, .sql, .bak et fichiers cachés sont refusés.
  8. HTTPS sérieux. TLS 1.2 et 1.3 uniquement, HSTS, en-têtes de sécurité (nosniff, cadre limité au site, politique de référent, permissions du navigateur restreintes).

Des mises à jour d'un clic, qui savent revenir en arrière

Depuis l'administration, « Mettre à jour JEIKO » affiche la version disponible, puis le journal en direct ; la page survit au redémarrage du site. Derrière ce bouton, l'application ne fait que déclencher : le script qui s'exécute appartient à root et vit hors du site, que le site ne peut pas modifier. Le compte du site n'a droit qu'à deux commandes, rien d'autre.

Le déroulé d'une mise à jour

1. lecture du manifeste de version
2. vérification de l'empreinte sha256 du paquet
3. sauvegarde de la base (pg_dump)
4. installation du paquet
5. réalignement de settings.py et urls.py
6. contrôle Django, migrations, fichiers statiques
7. permissions, redémarrage
8. contrôle de santé du site

→ une erreur après l'étape 4 : version précédente réinstallée,
gabarits restaurés, base restaurée si les migrations ont tourné.

  1. Un paquet dont l'empreinte ne correspond pas n'est pas installé. C'est le seul lien de confiance entre ce qui est publié et ce qui s'exécute chez vous.
  2. Deux mises à jour ne se chevauchent jamais : un verrou les sérialise.
  3. Vos réglages ne se perdent pas. settings.py est recopié à chaque version ; tout ce qui est propre au site — clés, domaine, messagerie, paiement — vient du .env, que la mise à jour ne touche pas.

Un serveur qui s'entretient seul

Les pannes d'un petit serveur ont rarement une cause exotique : un disque plein, un certificat expiré, une sauvegarde qui avait cessé de tourner. Rien de cela ne prévient. L'installeur pose donc la routine qu'on n'a jamais le temps de tenir.

  1. Correctifs de sécurité Debian, téléchargés et installés chaque jour. Après une mise à jour du noyau, la machine redémarre à 4 h 20 et le site revient seul.
  2. Sauvegarde quotidienne de la base, des médias et de la configuration, à une heure décalée par site. Chaque dump est vérifié ; une sauvegarde incomplète est effacée plutôt que de passer pour valide. Trente jours conservés, et une copie hors du serveur, chiffrée, si vous indiquez une destination.
  3. Contrôle de santé chaque matin à 7 h 30 : espace disque, mémoire, expiration des certificats, état des services, âge de la dernière sauvegarde.
  4. Renouvellement du certificat automatique, testé dès l'installation.

Les commandes, si vous voulez la main

sudo jeiko-backup monsite # sauvegarde à la demande
sudo jeiko-verifier # état de santé du serveur
sudo jeiko-client-update monsite --check
sudo jeiko-server-update monsite # réaligne la configuration serveur

La configuration serveur évolue aussi : une nouvelle version de l'installeur se rejoue sur un site existant, qui converge vers ce qu'une installation neuve produirait — sans toucher à la base ni aux données.

Installer un siteSécurité de l'application