Erreur dépôt PHP Sury sur Debian 12 : la corriger

Pourquoi APT signale-t-il un fichier Release pas encore valide ?

Quand APT contacte un dépôt, il récupère des métadonnées qui décrivent les paquets disponibles. Le fichier InRelease contient notamment des informations de date et une signature. Avant d'utiliser le dépôt, APT vérifie ces éléments.

L'erreur typique ressemble à ceci :

E: Release file for https://packages.sury.org/php/dists/bookworm/InRelease
is not valid yet

Le message not valid yet veut dire que, d'après l'heure vue par votre machine, le dépôt n'a pas encore atteint sa fenêtre de validité. Si votre serveur a plusieurs minutes (ou heures, ou jours) de retard, la date « annoncée » par les métadonnées peut sembler être dans le futur.

L'erreur ne prouve pas que le dépôt est en panne

Il y a trois choses courantes derrière ces messages :

• L'horloge système : elle peut être fausse ou mal synchronisée.
• La configuration du dépôt : distribution, URL, clé de signature... tout ça peut être incorrect.
• Le chemin réseau : proxy ou cache qui renvoient des métadonnées plus anciennes que prévu.

Commencez par l'horloge : c'est rapide, et ça évite de multiplier les changements. Modifier ensuite une source APT ou remplacer une clé « au cas où » ajoute du bruit dans le diagnostic.

Et surtout : ne « contournez » pas le contrôle de signature pour que ça passe. Ça ne répare pas l'heure du serveur, et vous perdez une protection utile. Une horloge correcte sert aussi à d'autres tâches : TLS, lecture de journaux, planifications cron/systemd, etc.

Vérifier et synchroniser l'heure du serveur

D'abord, comparez l'heure locale et l'UTC, puis regardez l'état de synchronisation :

date
date -u
timedatectl status

Dans timedatectl status, cherchez notamment ce qui indique la synchronisation de l'horloge et l'état NTP. On s'attend souvent à un retour du style :

• System clock synchronized: yes
• NTP service: active

L'affichage exact dépend de la configuration et des services installés.

Une différence entre l'heure locale et l'UTC ne signifie pas automatiquement « problème » : c'est parfois juste le fuseau horaire (ex. heure de Paris). Pour lever l'ambiguïté, date -u est votre ami : l'UTC évite les confusions liées au fuseau.

Activer la synchronisation NTP avec systemd-timesyncd

Sur Debian 12, le client NTP peut être systemd-timesyncd. Vérifiez s'il est présent :

systemctl status systemd-timesyncd

S'il est là, activez la synchro :

sudo timedatectl set-ntp true

Puis contrôlez :

timedatectl status
timedatectl timesync-status

La synchronisation n'est pas toujours instantanée. Si l'écart est important, attendez quelques instants et recontrôlez l'heure avant de relancer APT.

Si vous n'utilisez pas systemd-timesyncd, regardez si un autre outil (souvent chrony) gère déjà l'horloge. Évitez d'en faire tourner deux en même temps : ils peuvent se marcher dessus.

Définir des serveurs NTP spécifiques

Si votre infra impose des sources de temps précises, configurez-les dans systemd-timesyncd :

sudo nano /etc/systemd/timesyncd.conf

Dans [Time], renseignez vos serveurs :

[Time]
NTP=0.my.pool.ntp.org 1.my.pool.ntp.org 2.my.pool.ntp.org
FallbackNTP=0.pool.ntp.org 1.pool.ntp.org

Enregistrez, puis redémarrez et réactivez :

sudo systemctl restart systemd-timesyncd
sudo timedatectl set-ntp true
timedatectl status
timedatectl timesync-status

Les valeurs ci-dessus sont des exemples. En entreprise ou en datacenter, prenez les sources prévues par l'admin réseau ou le fournisseur. Si, pour une raison quelconque, aucun service NTP n'est disponible et que les dépôts ne fonctionnent pas, corrigez d'abord l'heure via ce qui est déjà accessible dans votre environnement, puis installez les outils nécessaires une fois les dépôts joignables.

Contrôler le dépôt Sury et actualiser les index APT

Quand l'heure est correcte et synchronisée, relancez les index APT :

sudo apt update

En théorie, l'erreur Release file ... is not valid yet disparaît.

Si elle persiste, évitez de modifier plein de choses en même temps. Remettez l'ordre de contrôle au clair : heure UTC, état NTP, accès réseau, puis vérifiez s'il existe un proxy/cache qui pourrait renvoyer des métadonnées périmées.

Si l'heure est bonne mais qu'APT échoue toujours, regardez aussi :

• la configuration de la source Sury
• la suite Debian ciblée
• la clé de signature

Sury est un dépôt tiers : il fournit des versions et des paquets PHP supplémentaires, mais ce n'est pas un dépôt « officiel Debian ». Il vaut mieux savoir pourquoi il est présent et quels composants de votre appli en dépendent.

Vérifier si Sury est déjà configuré

Avant d'ajouter une nouvelle source, cherchez s'il y en a déjà une :

grep -R "packages.sury.org/php" /etc/apt/sources.list /etc/apt/sources.list.d/ 2>/dev/null

Si vous avez déjà une entrée, n'en créez pas une deuxième : ça complique le diagnostic et peut donner des résultats inattendus.

Vérifiez aussi que la suite correspond bien à Debian 12, donc bookworm.

Installer Sury si nécessaire

Ne faites cette section que si Sury n'est pas déjà configuré et si vous avez besoin des paquets qu'il fournit. Une fois qu'APT fonctionne correctement, installez les outils :

sudo apt install -y ca-certificates curl lsb-release

Puis installez la clé fournie par Sury :

sudo curl -fsSL \
https://packages.sury.org/debsuryorg-archive-keyring.deb \
-o /tmp/debsuryorg-archive-keyring.deb
sudo apt install /tmp/debsuryorg-archive-keyring.deb

Ensuite, déclarez le dépôt dans un fichier deb822. La commande ci-dessous récupère le nom de code de la distribution :

sudo tee /etc/apt/sources.list.d/php.sources > /dev/null <<EOF
Types: deb
URIs: https://packages.sury.org/php/
Suites: $(. /etc/os-release && echo "$VERSION_CODENAME")
Components: main
Signed-By: /usr/share/keyrings/debsuryorg-archive-keyring.gpg
EOF

Sur Debian 12, Suites doit être bookworm. Si votre machine a été mise à niveau depuis une autre version ou si l'environnement est particulier, vérifiez ce fichier avant de continuer. Puis actualisez les index :

sudo apt update

Pour repérer ce que voit APT et les paquets PHP proposés à la mise à niveau :

apt-cache policy php
apt list --upgradable 2>/dev/null | grep -i php

Ces commandes indiquent ce qu'APT connaît. Elles ne garantissent pas, à elles seules, que chaque paquet PHP installé est effectivement « à jour ».

Mettre à jour les paquets PHP sans élargir le changement

Avant de lancer une mise à niveau, faites l'inventaire : quelles versions et quels paquets PHP sont réellement installés. Ça évite de confondre « mise à jour » et « changement d'architecture ».

dpkg-query -W \
-f='${binary:Package}\t${Version}\n' \
'php*' 2>/dev/null

Selon votre configuration, vous pouvez voir par exemple php8.2-cli, php8.2-common, php8.2-fpm, php8.2-mysql, php8.2-xml, php8.2-curl ou php8.2-mbstring. Votre liste peut aussi utiliser une autre version ou un autre ensemble d'extensions.

Vérifiez la version PHP en ligne de commande :

php -v

Attention : le php de la CLI n'est pas forcément celui utilisé par votre serveur web. Un site peut passer par PHP-FPM tandis que la commande php pointe vers une autre version installée.

Préparer la liste et simuler la mise à niveau

Une cible large comme php* peut inclure des paquets qui ne sont pas installés. Si votre objectif est juste de mettre à jour ce qui existe déjà, commencez par construire la liste des paquets PHP réellement installés :

mapfile -t PHP_PACKAGES < <(
dpkg-query -W -f='${binary:Package}\n' 'php*' 2>/dev/null |
grep -E '^php([0-9.]|[-:])'
)
printf '%s\n' "${PHP_PACKAGES[@]}"

Relisez la liste. Si elle est vide, stoppez et vérifiez les noms des paquets installés ou la manière dont PHP est déployé. Ne lancez pas une mise à niveau avec une liste vide ou mal interprétée.

Ensuite, simulez :

sudo apt-get -s install --only-upgrade "${PHP_PACKAGES[@]}"

Cette simulation sert à vérifier ce que APT proposerait de changer : suppressions inattendues, ajout d'une autre version de PHP, divergences par rapport à votre but. En production, cette étape vaut presque toujours mieux qu'une commande « en aveugle ».

Si tout est cohérent, appliquez la mise à niveau uniquement sur les paquets déjà installés :

sudo apt-get install --only-upgrade "${PHP_PACKAGES[@]}"

L'option --only-upgrade limite l'action aux paquets existants, au lieu d'installer des paquets absents de la liste. C'est une façon simple de réduire le périmètre (et donc le risque), sans remplacer une sauvegarde ni un plan de rollback.

Vérifier le résultat et le service utilisé

Après la mise à niveau, contrôlez la version CLI et la config :

php -v
php --ini
apt list --upgradable 2>/dev/null | grep -i php

Si la dernière commande ne renvoie rien, c'est souvent que rien n'est « upgradeable » côté APT pour la liste que vous avez filtrée. Pour un contrôle plus fin, utilisez aussi apt-cache policy sur les paquets concernés.

Si vous utilisez PHP-FPM, repérez les services :

systemctl list-units \
--type=service \
--all \
'php*-fpm.service'

Puis regardez le service correspondant à votre installation (par exemple) :

systemctl status php8.2-fpm

Adaptez php8.2-fpm au nom réel présent sur le serveur. Vérifiez aussi que Nginx ou Apache pointe bien vers le bon socket/module, et que l'application répond. Pour une appli Laravel, pensez à vérifier les extensions requises, les tâches planifiées, les files de traitement et le bon ensemble PHP-FPM.

Vérifier les correctifs de sécurité

Mettre à jour ne garantit pas que chaque vulnérabilité pertinente est couverte « comme vous l'espériez ». Regardez les versions installées et candidates :

apt-cache policy php8.2-cli
apt-cache policy php8.2-fpm

Adaptez les noms selon votre installation, puis consultez les avis de sécurité et les changelogs des paquets. Le numéro de version Debian peut intégrer des correctifs sans reprendre exactement la numérotation d'une version « amont » de PHP. Comparer uniquement le numéro affiché sur le site officiel peut mener à une fausse conclusion.

Enfin, en production, prévoyez une fenêtre de maintenance proportionnée au risque, et testez les parcours essentiels de l'application. Une mise à jour système, c'est une chose ; valider le comportement applicatif après coup, c'est une autre.

Conclusion

L'erreur de validité sur le dépôt PHP Sury ne veut pas forcément dire que le dépôt est cassé. Sur Debian 12, une horloge désynchronisée suffit souvent à faire considérer des métadonnées pourtant valides comme « datées du futur ».

Le bon ordre de dépannage est simple : vérifiez l'heure, rétablissez la synchronisation NTP, relancez apt update, puis contrôlez la source et les paquets PHP. Terminez par une simulation, puis vérifiez le service réellement utilisé par votre application.

La prochaine fois que vous planifiez une maintenance, gardez le contrôle d'horloge comme étape de routine. Ça évite des diagnostics inutiles et aide à préserver les vérifications de sécurité d'APT. Pour aller plus loin, consultez la documentation Debian sur la gestion des paquets, la documentation de timedatectl, et les informations du dépôt PHP Sury.