Votre propre miroir RPM, et construire le correctif avant que la distribution ne le livre

Quand une vulnérabilité sérieuse est publiée, deux choses décident du temps pendant lequel vos serveurs restent exposés : la vitesse à laquelle vous pouvez récupérer les paquets, et le fait que le paquet corrigé existe déjà ou non. Un miroir local résout le premier point. La capacité à construire vous-même un paquet propre, à partir de la spécification du mainteneur lui-même, résout le second. Voici comment nous faisons les deux sur Enterprise Linux, et comment le faire sans laisser traîner des paquets maison une fois les officiels arrivés.

Pourquoi tenir son propre miroir

Les miroirs publics sont tenus par des personnes et des organisations généreuses, et un jour ordinaire ils sont rapides. Le jour où un correctif critique sort, chaque serveur du monde demande les mêmes paquets en même temps. Un miroir local dans votre propre réseau transforme cela en une opération de copie locale. Il vous permet aussi de corriger des serveurs volontairement coupés d'internet, comme les systèmes de sauvegarde et d'administration, sans les ouvrir.

Il y a un bénéfice plus discret : un miroir qui garde l'historique complet des paquets vous permet de reconstruire un serveur dans un état connu, ou de revenir en arrière sur un paquet, à partir de votre propre copie.

Mettre en miroir sans jamais servir un dépôt à moitié synchronisé

Le miroir naïf est un rsync ou un reposync directement dans le répertoire que publie votre serveur web. Si un client lance dnf pendant que la synchronisation est à mi-chemin, il peut voir de nouvelles métadonnées qui renvoient à des paquets pas encore arrivés, ou d'anciennes métadonnées qui pointent vers des paquets qui viennent d'être supprimés. Le résultat, ce sont des erreurs confuses exactement au mauvais moment.

Synchronisez plutôt en deux phases :

1. Les paquets d'abord. Récupérez les paquets dans le répertoire publié. Les anciennes métadonnées décrivent toujours un ensemble cohérent, parce que rien de ce qu'elles référencent n'a encore été retiré.

dnf reposync --repoid=os-baseos --arch=x86_64 --arch=noarch \
    --delete --norepopath -p /srv/repo/os/baseos

1. Les métadonnées ensuite, basculées d'un coup. Téléchargez le repodata/ amont dans un répertoire frère (chaque fichier que repomd.xml référence), vérifiez-le, puis remplacez les métadonnées publiées par un seul renommage. Les clients voient l'ancien dépôt ou le nouveau, jamais un mélange.

mv /srv/repo/os/baseos/repodata /srv/repo/os/baseos/repodata.old
mv /srv/repo/os/baseos/repodata.new /srv/repo/os/baseos/repodata

Utiliser les métadonnées amont, plutôt que régénérer les vôtres avec createrepo_c, garde le dépôt exactement tel que l'éditeur l'a construit.

Donnez à chaque tâche de synchronisation un verrou pour que deux exécutions ne se chevauchent jamais, écrivez un petit fichier d'état avec le résultat et l'heure, et alertez quelqu'un quand une tâche échoue. Un miroir qui a cessé en silence de se synchroniser le mois dernier est pire que pas de miroir du tout, parce que tout le monde lui fait confiance.

Les clients utilisent ensuite un simple fichier de dépôt pointant vers votre miroir :

[local-baseos]
name=Local mirror: BaseOS
baseurl=https://mirror.example.internal/os/baseos/
enabled=1
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-oracle

Quand le correctif existe mais pas le paquet

Il arrive que le projet amont publie une version corrigée et que le mainteneur de la distribution ou du dépôt ne l'ait pas encore empaquetée. Souvent cet écart se compte en heures. Parfois en jours.

La règle que nous suivons : construire la version amont à partir de l'empaquetage du mainteneur lui-même, ne rien changer d'autre, et s'assurer que le paquet officiel remplacera le vôtre automatiquement.

Construire en salle propre

Utilisez un conteneur neuf de la même version de distribution que les serveurs cibles, pour que l'environnement de build soit connu et jetable :

podman run --rm -it -v ./build:/build:Z oraclelinux:<release> bash
dnf install -y rpm-build rpmdevtools dnf-plugins-core
rpmdev-setuptree

Partez du dernier paquet source (SRPM) du mainteneur pour la branche que vous utilisez, installez-le, et installez ses dépendances de build :

rpm -ivh php-<current>.src.rpm
dnf builddep -y ~/rpmbuild/SPECS/php.spec

Ne changer que la version, et vérifier la source

Téléchargez le tarball amont corrigé depuis le site officiel du projet et vérifiez-le avec le checksum que le projet publie.

sha256sum php-<fixed>.tar.xz

Dans le fichier spec, mettez à jour Version vers la version corrigée et remplacez la source. Laissez les patches, les options de configure et les listes de fichiers tels que le mainteneur les a écrits. Si un patch du mainteneur ne s'applique plus à la nouvelle version, arrêtez-vous et comprenez pourquoi avant d'aller plus loin.

Choisir un release qui s'efface

C'est l'étape que les gens oublient. Votre paquet doit se classer plus bas que l'éventuel paquet officiel du mainteneur de la même version, pour qu'un dnf upgrade normal remplace le vôtre. Un release qui commence par 0. le fait de manière fiable :

Release: 0.1.local%{?dist}

Vérifiez-le avant de construire quoi que ce soit, avec la même comparaison que celle utilisée par rpm :

rpmdev-vercmp 0:X.Y.Z-0.1.local.elN 0:X.Y.Z-1.elN.maint

Le release officiel doit ressortir comme plus récent. Si ce n'est pas le cas, changez votre chaîne de release jusqu'à ce que ce le soit.

Construire, tester, garder les preuves

rpmbuild -ba ~/rpmbuild/SPECS/php.spec

Conservez les paquets construits avec leurs checksums et une note du checksum du tarball source, pour que n'importe qui puisse dire plus tard exactement ce qui a été installé et d'où cela venait.

Publiez vos builds dans un dépôt séparé sur votre miroir, pas mélangés à la copie du dépôt du vendeur. Quand le paquet officiel arrive dans le dépôt en miroir, la mise à jour normale suivante remplace le vôtre, et votre dépôt séparé peut être vidé.

À qui revient le mérite

Rien de tout cela ne remplace les personnes qui maintiennent les paquets. Des mainteneurs de dépôts comme Remi Collet, dont une grande partie du monde Enterprise Linux dépend pour les dépôts PHP, livrent souvent des correctifs remarquablement vite. Construire à partir de leur spécification est une façon de couvrir les dernières heures, pas un substitut à leur travail. Pendant les correctifs PHP2Shell, nous avons écrit sur les deux faces de cette question : PHP2Shell: patched PHP packages et Respect to Remi.

Une checklist pour votre propre plateforme

• D'où vos serveurs récupèrent-ils leurs paquets, et que se passe-t-il si cet endroit est lent ?
• Vos serveurs isolés peuvent-ils être corrigés sans être ouverts sur internet ?
• Un client pourrait-il un jour voir un dépôt à moitié synchronisé sur votre miroir ?
• Quelqu'un est-il prévenu quand une synchronisation du miroir échoue ?
• Si vous deviez construire un paquet ce soir, votre chaîne de release laisse-t-elle l'officiel le remplacer ?

Si vous souhaitez de l'aide pour mettre en place un miroir ou une procédure de builds d'urgence, nos ingénieurs partagent volontiers ce qui fonctionne. Parler à un ingénieur

Related

• /what-we-do/operations/package-builds-mirror/
• /what-we-do/operations/emergency-vulnerability-response/
• /what-we-do/data-web/php-upgrades-security-patching/