Prérequis
Ce qu'une machine doit avoir avant de pouvoir faire tourner Chinaski : système d'exploitation, runtime du langage, base de données et dimensionnement. La version courte : une machine Debian/Ubuntu et Perl 5.26+.
Système d'exploitation
- Famille Debian/Ubuntu. Tout ce dont Chinaski a besoin, y compris chaque dépendance Perl, est disponible dans les paquets Debian stable, si bien qu'un serveur d'origine s'installe sans détour côté compilateur. L'installeur en une fois gère lui-même l'installation des paquets ; il n'y a rien à compiler à la main.
- Les cartes ARM (comme Raspberry Pi) fonctionnent, avec une réserve : les bibliothèques d'images listées ci-dessous doivent être installées explicitement, sinon le module de traitement d'images ne compilera pas.
Perl et prérequis au niveau du langage
- Perl 5.26 ou plus récent: les installeurs le vérifient explicitement et refusent avec un message d'erreur nommant la version trouvée s'il est plus ancien.
- L'ensemble de dépendances (toutes packagées Debian, avec les minimums exacts dans le cpanfile du projet) : Mojolicious, DBI + DBD::SQLite, Template (Template Toolkit), Crypt::Passphrase (+Bcrypt, +PBKDF2), CryptX, Imager, DateTime + DateTime::TimeZone, Archive::Tar, File::Copy::Recursive.
- Deux modules optionnels alimentent uniquement l'importeur Markdown (CommonMark, qui se lie à la bibliothèque système cmark, et YAML::PP). Sans eux le site démarre et tout le reste fonctionne ; seule cette unique route d'importeur affiche une erreur claire dans l'admin.
Paquets système (installations manuelles/hors ligne)
Si vous installez sur une machine hors ligne ou manuellement depuis les sources, ces paquets apt sont requis d'abord : perl, make, gcc, sqlite3, plus les bibliothèques de dev image (libjpeg, libpng, libgif), et pour l'installeur en ligne aussi openssl et cpanminus :
- make/gcc: utilisés uniquement pour compiler les modules XS (natifs) au moment de l'installation ; l'installeur officiel utilise des paquets Debian pré-compilés à la place, donc aucune compilation n'y est nécessaire.
- sqlite3: la CLI de la base de données, utilisée pour l'installation et la maintenance.
- Bibliothèques d'images: requises par la compilation native du module Imager.
La base de données
SQLite : embarquée, pas de processus serveur, pas d'identifiants à gérer. Tourne en mode WAL avec un cache de 64 MiB et un busy timeout de 5 secondes, dimensionné pour la charge attendue : une session admin active, des builds par lots périodiques. La sauvegarde est une copie de fichier.
Dimensionnement des ressources
Les unités systemd livrées documentent l'enveloppe prévue et plafonnent les processus emportés :
| Composant | Plafond mémoire | CPU |
|---|---|---|
| Instance du CMS | 1 GiB (avec limite souple de 768 MiB) | l'équivalent de 2 cœurs |
| Serveur MCP | 512 MiB (limite souple 384 MiB) | l'équivalent de 1 cœur |
- Workers : le daemon lance 2 workers par défaut, dimensionnés « sûr sur une machine de 1 Go ». Si plusieurs éditeurs seront connectés en même temps, la configuration accepte 4, confortable sur un hôte de 2+ Go.
- Les builds sont des processus séparés avec leur propre limite de temps mur (30 minutes dures) et un budget d'écriture par build ; un build emporté isolé ne peut donc pas affamer la machine indéfiniment.
- Disque : deux consommateurs pratiques dominent : la base SQLite (selon le poids de votre contenu) et l'arbre de sortie statique (mis en miroir à chaque rebuild). Les instantanés de sauvegarde ajoutent environ la taille compressée de la base par jour sous la rétention par défaut de 14 jours.
Ports et posture réseau
- Les daemons de backend se lient sur des ports hauts (série 3000 par numéro d'instance par défaut ; les installations rapides directes utilisent 8080) et le reverse proxy possède 80/443 : voyez la page de dépannage des ports pour les règles d'allocation exactes.
- Après l'installation, les appels sortants sont entièrement supprimés en mode air-gap ; la connectivité Internet n'est jamais requise pour que l'application fonctionne.
Voies d'installation
- Serveur Debian/Ubuntu : l'installeur en ligne d'une ligne (installe les paquets, crée l'utilisateur système, clone, initialise la base, écrit le fichier env, démarre systemd).
- Hors ligne : l'installation par bundle hors ligne documentée sur un lieu n'ayant pas besoin d'Internet, installation par miroir depuis des tarballs fournis avec un fichier de sommes SHA-256 pour vérifier l'intégrité.
- Exécution locale rapide : extraction du tar ;
install.sh --no-service; exécution via l'hypnotoad fourni sur le port 8080, pas de systemd, pas de reverse proxy, pas d'appel sortant nécessaire.