Déployer Omeka S sur une VM Debian Linux

Introduction

Cet article documente l'installation d'Omeka S 4.2.0 sur une VM Debian 13 (Trixie) en architecture ARM64, avec Apache, PHP 8.4 et MariaDB. Toutes les commandes s'exécutent depuis une session SSH en tant que root.

Cette procédure est le pendant Debian des installations Alpine et macOS Tahoe. Les écarts notables par rapport à Alpine sont signalés au fil du texte : gestionnaire de paquets apt, extensions PHP fusionnées, utilisateur Apache www-data, services pilotés par systemd, et authentification unix_socket de MariaDB.

1. Reconnaissance et préparation du système

Avant tout, on identifie la version de Debian (elle détermine la version de PHP packagée, donc le nom des paquets), l'architecture, l'espace disque et la RAM.

cat /etc/os-release
uname -m
apt-cache policy php
df -h /
free -h

Sur la VM de référence : Debian 13.5 (Trixie), aarch64, PHP 8.4 comme version par défaut des dépôts. On met ensuite le système à jour.

apt update
apt -y full-upgrade

(Omeka S 4.2.0 supporte officiellement PHP 8.4 : aucun rétrogradage de version n'est nécessaire, on garde la même version d'Omeka que sur Alpine.)

2. Installation des paquets

Apache, PHP 8.4 avec les extensions requises par Omeka S, MariaDB et ImageMagick en une seule passe. La liste est nettement plus courte que sur Alpine : sur Debian, ctype, iconv, tokenizer, fileinfo, openssl, session et phar sont déjà dans le paquet php8.4, et dom, simplexml, xmlreader, xmlwriter sont tous regroupés dans php8.4-xml.

apt -y install \
 apache2 \
 php8.4 libapache2-mod-php8.4 \
 php8.4-mysql \
 php8.4-xml \
 php8.4-mbstring \
 php8.4-curl \
 php8.4-gd \
 php8.4-zip \
 php8.4-intl \
 php8.4-opcache \
 php8.4-imagick \
 mariadb-server mariadb-client \
 imagemagick \
 wget unzip

Relevage des limites PHP pour autoriser l'upload de fichiers volumineux. Attention : sur Debian le chemin de configuration est propre à chaque SAPI, ici celui d'Apache.

cat > /etc/php/8.4/apache2/conf.d/99-omeka.ini <<'EOF'
memory_limit = 256M
post_max_size = 128M
upload_max_filesize = 128M
max_execution_time = 300
EOF

Vérification que toutes les extensions requises sont chargées.

php -v
php -m | sort

(Apache bascule automatiquement de mpm_event vers mpm_prefork lors de l'installation de libapache2-mod-php : le module PHP n'est pas thread-safe. C'est normal et sans action requise.)

3. Configuration de MariaDB

Démarrage du service

Contrairement à Alpine, l'installeur Debian a déjà démarré et activé au boot les services mariadb et apache2 (via systemd). Il n'y a donc pas d'équivalent du rc-update add. On se contente de vérifier.

systemctl status mariadb --no-pager
mariadb --version

Sécurisation interactive

Sur Debian, le compte root de MariaDB utilise l'authentification unix_socket : c'est l'utilisateur système root qui est reconnu, sans mot de passe. La sécurisation supprime les comptes anonymes et la base test.

mariadb-secure-installation

Réponses aux invites, dans l'ordre :

Enter current password for root : laisser vide (Entrée) — l'auth socket fait foi
Switch to unix_socket authentication : n (déjà actif)
Change the root password : n (on conserve l'auth socket)
Remove anonymous users : Y
Disallow root login remotely : Y
Remove test database and access to it : Y
Reload privilege tables now : Y

(Debian affiche un avertissement « MariaDB is secure by default » : sans conséquence, le script effectue tout de même le nettoyage.)

Création de la base et de l'utilisateur dédié

Du fait de l'auth unix_socket, on se connecte avec un simple mariadb — sans -u root -p (c'est la différence majeure avec la commande équivalente sur Alpine).

mariadb <<'EOF'
CREATE DATABASE omeka_s CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
CREATE USER 'omeka'@'localhost' IDENTIFIED BY 'MotDePasseOmeka';
GRANT ALL PRIVILEGES ON omeka_s.* TO 'omeka'@'localhost';
FLUSH PRIVILEGES;
EOF

Test de bout en bout : l'utilisateur omeka doit pouvoir se connecter et voir sa base.

mariadb -u omeka -p'MotDePasseOmeka' -e "SHOW DATABASES; SELECT CURRENT_USER();"

(Remplacer MotDePasseOmeka par un mot de passe fort en production, et le réutiliser à l'identique dans database.ini à l'étape 5.)

4. Configuration d'Apache

Sur Debian on n'édite pas httpd.conf au sed comme sur Alpine : Apache y est modulaire via a2enmod / a2enconf. Trois actions : activer mod_rewrite (Omeka S s'appuie sur un .htaccess), déclarer le répertoire avec AllowOverride All, et fixer le ServerName.

a2enmod rewrite

cat > /etc/apache2/conf-available/omeka-s.conf <<'EOF'
<Directory "/var/www/html/omeka-s">
 Options Indexes FollowSymLinks
 AllowOverride All
 Require all granted
</Directory>
EOF
a2enconf omeka-s

echo "ServerName <IP-VM>" > /etc/apache2/conf-available/servername.conf
a2enconf servername

Différences avec Alpine : la racine web est /var/www/html (et non /var/www/localhost/htdocs) ; les fichiers de conf vont dans conf-available/ puis sont activés par a2enconf. Remplacer <IP-VM> par l'adresse IP — ou le nom DNS — de votre VM.

Contrôle de syntaxe (équivalent Debian du httpd -t d'Alpine), puis activation.

apache2ctl configtest
systemctl restart apache2
apache2ctl -M | grep rewrite

(Point critique : l'activation d'un nouveau module exige systemctl restart apache2, pas un simple reload. Sans mod_rewrite réellement chargé, le .htaccess d'Omeka renvoie des erreurs 500. La dernière commande doit afficher rewrite_module (shared).)

5. Téléchargement et déploiement d'Omeka S

Récupération de la version 4.2.0 depuis GitHub, déploiement dans /var/www/html, configuration de la connexion BDD.

cd /tmp
wget https://github.com/omeka/omeka-s/releases/download/v4.2.0/omeka-s-4.2.0.zip
unzip -q omeka-s-4.2.0.zip
mv omeka-s /var/www/html/omeka-s

cat > /var/www/html/omeka-s/config/database.ini <<'EOF'
user = "omeka"
password = "MotDePasseOmeka"
dbname = "omeka_s"
host = "localhost"
EOF

Application des permissions. Sur Debian, Apache tourne sous l'utilisateur www-data (et non apache comme sur Alpine) : la logique des droits est identique, seul le propriétaire change.

chown -R www-data:www-data /var/www/html/omeka-s
find /var/www/html/omeka-s -type d -exec chmod 755 {} \;
find /var/www/html/omeka-s -type f -exec chmod 644 {} \;
chmod -R 775 /var/www/html/omeka-s/files
chmod -R 775 /var/www/html/omeka-s/logs
chmod 600 /var/www/html/omeka-s/config/database.ini

Vérification de l'arborescence et des droits sensibles.

ls -la /var/www/html/omeka-s/
ls -ld /var/www/html/omeka-s/files /var/www/html/omeka-s/logs
ls -l /var/www/html/omeka-s/config/database.ini

(Attendu : tout appartient à www-data:www-data ; files/ et logs/ en drwxrwxr-x (775) pour qu'Apache puisse y écrire ; database.ini en -rw------- (600) pour protéger le mot de passe BDD.)

6. Finalisation via le navigateur

Avant d'ouvrir un navigateur, test depuis la VM pour confirmer qu'Apache sert Omeka, que PHP s'exécute et que le .htaccess/mod_rewrite fonctionne — on attend une redirection vers l'installeur, pas une erreur 500.

curl -sS -o /dev/null -w "Code: %{http_code} | Redirect: %{redirect_url}\n" \
 http://localhost/omeka-s/
curl -s -L http://localhost/omeka-s/ | grep -iE "<title>|install"

Code attendu : 302 redirigeant vers …/omeka-s/install. En cas de 500, diagnostiquer via /var/www/html/omeka-s/logs/application.log et /var/log/apache2/error.log.

L'installation se conclut via une interface web qui crée le super-utilisateur et initialise la base. À ouvrir depuis le poste client :

http://<IP-VM>/omeka-s/

(Omeka redirige automatiquement vers la page d'installation ; /omeka-s/admin aboutit au même formulaire au premier lancement. Le formulaire demande l'email/mot de passe de l'admin, le nom d'affichage, le titre de l'installation, le fuseau horaire et la langue.)

7. Configuration post-installation

Inspection préalable de la configuration

C'est l'étape la plus sensible. Plutôt que d'appliquer des sed « à l'aveugle », on inspecte d'abord le fichier et l'environnement, pour éviter tout remplacement silencieusement raté.

grep -nE "phpcli_path|imagemagick_dir|locale" \
 /var/www/html/omeka-s/config/local.config.php
which php && readlink -f /usr/bin/php
which convert magick
dpkg -l | grep -E "^ii +cron "
systemctl is-enabled cron

Constats sur la VM de référence : le binaire PHP CLI est /usr/bin/php (lien vers php8.4) — et non /usr/bin/php83 comme sur Alpine ; convert/magick sont dans /usr/bin ; et le paquet cron est déjà installé et activé.

Déclaration du chemin PHP CLI et d'ImageMagick

Ces réglages sont indispensables pour les tâches de fond et la génération de miniatures. Sauvegarde préalable, puis édition au plus juste (les motifs ont été confirmés par le grep ci-dessus).

cp /var/www/html/omeka-s/config/local.config.php \
 /var/www/html/omeka-s/config/local.config.php.bak

sed -i "s|'phpcli_path' => null,|'phpcli_path' => '/usr/bin/php',|" \
 /var/www/html/omeka-s/config/local.config.php

sed -i "s|'imagemagick_dir' => null,|'imagemagick_dir' => '/usr/bin',|" \
 /var/www/html/omeka-s/config/local.config.php

sed -i "s|'locale' => 'en_US',|'locale' => 'fr_FR',|" \
 /var/www/html/omeka-s/config/local.config.php

Contrôle de l'édition et validation syntaxique PHP du fichier (si un sed avait cassé le PHP, on le voit avant de recharger).

grep -nE "phpcli_path|imagemagick_dir|locale" \
 /var/www/html/omeka-s/config/local.config.php
php -l /var/www/html/omeka-s/config/local.config.php

Vidage du cache, remise des droits, rechargement Apache.

rm -rf /var/www/html/omeka-s/files/cache/*
chown -R www-data:www-data /var/www/html/omeka-s/files
systemctl reload apache2

Vérification du cron

Utile pour les tâches périodiques lancées par certains modules. Aucune installation nécessaire sur Debian : toute la section « dcron » de la procédure Alpine (apk add dcron + rc-service + rc-update) se réduit à une simple vérification.

systemctl is-active cron
systemctl status cron --no-pager | head -3

Emplacements clés

Les chemins à connaître pour la maintenance et le diagnostic (ils diffèrent d'Alpine — racine web /var/www/html au lieu de /var/www/localhost/htdocs) :

Racine de l'application :
/var/www/html/omeka-s
Configuration locale :
/var/www/html/omeka-s/config/local.config.php
Configuration BDD :
/var/www/html/omeka-s/config/database.ini
Logs applicatifs :
/var/www/html/omeka-s/logs/application.log
Logs Apache :
/var/log/apache2/error.log
Limites PHP (SAPI Apache) :
/etc/php/8.4/apache2/conf.d/99-omeka.ini
Confs Apache (Omeka, ServerName) :
/etc/apache2/conf-available/

Conclusion

Une installation propre tient en une trentaine de commandes. Par rapport à Alpine, Debian simplifie plusieurs points (extensions PHP fusionnées, services systemd auto-activés, cron déjà présent, MariaDB en unix_socket) mais déplace les chemins (/var/www/html, conf PHP par SAPI). Les étapes les plus sensibles restent les permissions sur files/ et logs/, le redémarrage d'Apache après activation de mod_rewrite, et la déclaration explicite du chemin PHP CLI (/usr/bin/php) — sans quoi les tâches de fond échouent silencieusement.

Les prochaines étapes naturelles : installer les modules essentiels (CSV Import, Common, Generic, Easy Admin), créer un premier site et concevoir un Resource Template adapté au corpus à publier.

↑ Haut de page