Déployer Omeka S sur une VM Devuan GNU/Linux

Introduction

Cet article documente l'installation d'Omeka S 4.2.0 sur une VM Devuan 6 (Excalibur) 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 Devuan des installations Alpine, macOS Tahoe et Debian. Devuan étant un fork de Debian sans systemd, la base (paquets apt, racine web /var/www/html, utilisateur Apache www-data, authentification unix_socket de MariaDB) est identique à Debian 13 Trixie, dont Excalibur dérive. L'unique divergence structurelle est le gestionnaire de services : sur la VM de référence l'init est runit, et non systemd ni sysvinit. Ce point est traité en détail dans une section dédiée.

(Devuan permet de choisir l'init à l'installation : sysvinit, OpenRC, runit ou s6. La VM documentée ici tourne sous runit. Si votre VM utilise sysvinit, remplacez les commandes sv par service / update-rc.d ; voir la section « Gestion des services sous runit ».)

1. Reconnaissance et préparation du système

On identifie la version de Devuan (elle détermine la base Debian, donc la version de PHP packagée et le nom des paquets), l'architecture, l'init system (déterminant pour toute la gestion des services), les dépôts, l'espace disque et la RAM.

cat /etc/devuan_version
cat /etc/os-release
uname -m
cat /proc/1/comm
ls -l /sbin/init
command -v service update-rc.d invoke-rc.d rc-update sv
cat /etc/apt/sources.list
apt-cache search --names-only '^php[0-9.]+$'
df -h /
free -h

Sur la VM de référence : Devuan 6 « Excalibur » (base Debian 13 Trixie, noyau deb13), architecture aarch64, init = runit (/proc/1/comm renvoie runit, /sbin/init pointe vers runit-init), dépôt main uniquement, et php8.4 disponible.

Mise à jour du système :

apt update
apt -y upgrade

(Le dépôt main suffit : imagemagick et php-imagick y figurent. Aucun contrib/non-free à activer, contrairement au dépôt community d'Alpine.)

2. Installation des paquets

Apache, PHP 8.4 avec toutes les extensions requises par Omeka S, MariaDB et ImageMagick en une seule passe. Comme sur Debian, les extensions PHP sont des paquets fusionnés (php8.4-xml couvre dom/simplexml/xmlreader/xmlwriter, php8.4-mbstring couvre ctype/iconv/tokenizer, etc.).

apt -y install \
 apache2 \
 php8.4 libapache2-mod-php8.4 php8.4-cli \
 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

(À l'issue de l'installation, sous runit, Apache et MariaDB sont déjà démarrés et déjà supervisés — les paquets créent automatiquement les liens dans /etc/service/. Aucun start ni enable manuel n'est nécessaire.)

Relevage des limites PHP pour autoriser l'upload de fichiers volumineux, côté SAPI Apache et côté CLI (les tâches de fond passent par le binaire CLI) :

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

cp /etc/php/8.4/apache2/conf.d/99-omeka.ini \
 /etc/php/8.4/cli/conf.d/99-omeka.ini

Contrôle de la version PHP installée :

php -v
/usr/bin/php8.4 -v

3. Configuration de MariaDB

Vérification du service

Inutile de démarrer MariaDB : runit l'a lancé et le supervise dès l'installation. On vérifie simplement (la sortie au format run: mariadb: (pid …) est celle de runit) :

sv status mariadb

Sécurisation interactive

Définit un mot de passe root, supprime les comptes anonymes et la base test.

mariadb-secure-installation

Réponses recommandées : mot de passe root actuel → vide (auth unix_socket par défaut) ; Switch to unix_socket authentication → n ; Change the root password → Y (saisir un mot de passe solide) ; suppression des comptes anonymes, interdiction du root distant, suppression de la base test, rechargement des privilèges → Y partout.

(Sur Debian/Devuan, ce script affiche un avertissement indiquant que MariaDB est déjà sécurisé par défaut : c'est normal, on l'exécute tout de même pour fixer un mot de passe root explicite.)

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

L'utilisateur système root se connecte sans mot de passe via le plugin unix_socket ; nul besoin de -p.

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

Vérification que la base est visible et que les droits de l'utilisateur dédié sont effectifs :

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

(La sortie doit lister omeka_s et renvoyer omeka@localhost. Saisir au prompt exactement le mot de passe placé entre quotes dans le CREATE USER.)

4. Configuration d'Apache

Activation de mod_rewrite, déclaration d'un répertoire Omeka avec AllowOverride All, et fixation du ServerName. Comme sur Debian, on passe par a2enmod/a2enconf (Apache n'utilise pas un httpd.conf monolithique).

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

(Remplacer <IP-VM> par l'adresse IP — ou le nom DNS — réelle de votre VM avant d'exécuter le bloc. Cette valeur sera le ServerName d'Apache et celle saisie dans le navigateur à l'étape 6. La récupérer au besoin avec ip a sur l'interface concernée.)

Contrôle de syntaxe puis prise en compte. Différence Devuan/runit : pas de systemctl reload ; on recharge via sv (SIGHUP, rechargement graceful en place — le PID master ne change pas).

apache2ctl configtest
sv reload apache2
sv status apache2

(apache2ctl configtest doit afficher Syntax OK. L'avertissement sur le FQDN disparaît une fois le ServerName posé.)

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

Récupération de la version 4.2.0 depuis GitHub, déploiement dans la racine web Debian/Devuan (/var/www/html, et non /var/www/localhost/htdocs comme sur Alpine), 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 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 (Apache tourne sous l'utilisateur www-data sur Devuan comme sur Debian).

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

Contrôle de la syntaxe et des permissions (Apache tourne déjà sous runit, rien à démarrer) :

apache2ctl configtest
ls -ld /var/www/html/omeka-s \
 /var/www/html/omeka-s/files \
 /var/www/html/omeka-s/logs
ls -l /var/www/html/omeka-s/config/database.ini
sv status apache2

(Attendu : files/ et logs/ en 775 appartenant à www-data, database.ini en 600. Le mv échoue si /var/www/html/omeka-s existe déjà — purger d'abord le cas échéant.)

6. Finalisation via le navigateur

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/admin

(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

Déclaration du chemin PHP CLI et d'ImageMagick

Sur Devuan, le binaire PHP CLI s'appelle php8.4 et n'est pas détecté automatiquement par Omeka. Ces réglages sont indispensables pour les tâches de fond et la génération de miniatures.

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/php8.4',|" \
 /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

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

Vérification du cron

Différence notable avec Alpine : sur Devuan, cron est déjà installé et déjà supervisé par runit (lien dans /etc/service/). Rien à installer ni à activer, on vérifie seulement :

sv status cron

Vérification finale

Confirmation que les réglages ont bien été écrits, que les binaires répondent et que les trois services sont supervisés :

grep -E "phpcli_path|imagemagick_dir|'locale'" \
 /var/www/html/omeka-s/config/local.config.php
/usr/bin/php8.4 -v | head -1
which convert magick
sv status apache2 mariadb cron

(Attendu : phpcli_path => '/usr/bin/php8.4', imagemagick_dir => '/usr/bin', locale => 'fr_FR' ; /usr/bin/convert et /usr/bin/magick présents ; les trois services en run:.)

Gestion des services sous runit

C'est l'unique vrai point de divergence avec Debian. Devuan n'embarque pas systemd ; sur la VM de référence, l'init est runit. Les daemons packagés (apache2, mariadb, cron) sont supervisés via des liens dans /etc/service/ créés automatiquement à l'apt install. Conséquences :

Aucun « enable » à exécuter : un service présent dans /etc/service/ est de facto activé au démarrage et supervisé (relancé automatiquement s'il meurt). Il n'existe pas d'équivalent systemctl enable ou update-rc.d à lancer — la présence du lien suffit.
Aucun « start » manuel après installation : apt install a déjà lancé les services via runit.
Pilotage via sv : le plus explicite sous runit. La commande service … fonctionne aussi (Devuan la route vers sv) et renvoie le format runit run: <svc>: (pid …).
Désactiver un service : sv down <svc> puis suppression du lien dans /etc/service/ (non requis ici).

Table d'équivalence systemd → runit utilisée tout au long de cette procédure :

systemctl start/stop/restart X → sv start/stop/restart X
systemctl reload X → sv reload X (envoie SIGHUP)
systemctl status X → sv status X
systemctl enable X → rien (lien /etc/service/X déjà présent)
systemctl is-enabled X → ls -l /etc/service/X

(Si votre VM Devuan utilise sysvinit au lieu de runit : service X start|stop|restart|reload pour le pilotage, et update-rc.d X defaults / update-rc.d X enable pour l'activation au boot.)

Emplacements clés

Les chemins à connaître pour la maintenance et le diagnostic :

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
Limites PHP (Apache & CLI) :
/etc/php/8.4/apache2/conf.d/99-omeka.ini
/etc/php/8.4/cli/conf.d/99-omeka.ini
Logs Apache :
/var/log/apache2/error.log
Confs Apache Omeka :
/etc/apache2/conf-available/omeka-s.conf
/etc/apache2/conf-available/servername.conf
Services supervisés (runit) :
/etc/service/ (apache2, mariadb, cron)

Conclusion

Une installation propre tient en une trentaine de commandes. Devuan étant un Debian sans systemd, la quasi-totalité de la procédure Debian s'applique telle quelle ; le seul écart structurel concerne la gestion des services : sous runit, ni start ni enable manuels, le pilotage se fait via sv. Les étapes les plus sensibles restent les permissions sur files/ et logs/, ainsi que la déclaration explicite du chemin PHP CLI (/usr/bin/php8.4) — 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