Su propio mirror RPM, y construir la corrección antes de que la distribución la publique

Cuando se publica una vulnerabilidad grave, dos cosas deciden cuánto tiempo quedan expuestos sus servidores: a qué velocidad puede descargar paquetes, y si el paquete corregido existe ya. Un mirror local resuelve lo primero. La capacidad de construir usted mismo un paquete limpio, a partir de la propia especificación del mantenedor, resuelve lo segundo. Así hacemos nosotros ambas cosas en Enterprise Linux, y así se hace sin dejar paquetes caseros tirados después de que lleguen los oficiales.

Por qué operar su propio mirror

Los mirrors públicos los operan personas y organizaciones generosas, y un día normal son rápidos. El día en que aterriza una corrección crítica, todos los servidores del mundo piden los mismos paquetes a la vez. Un mirror local dentro de su propia red convierte eso en una operación de copia local. También le permite parchear servidores deliberadamente aislados de internet, como los sistemas de backup y de gestión, sin abrirlos.

Hay una ventaja más discreta: un mirror que conserva el historial completo de paquetes le permite reconstruir un servidor a un estado conocido, o revertir un paquete, desde su propia copia.

Haga mirror sin servir nunca un repositorio a medio sincronizar

El mirror ingenuo es un rsync o un reposync directo al directorio que publica su servidor web. Si un cliente ejecuta dnf cuando la sincronización va por la mitad, puede ver metadatos nuevos que se refieren a paquetes que aún no han llegado, o metadatos antiguos que apuntan a paquetes recién eliminados. El resultado son errores confusos justo en el peor momento.

Sincronice en dos fases en su lugar:

• Primero los paquetes. Descargue los paquetes en el directorio publicado. Los metadatos antiguos siguen describiendo un conjunto consistente, porque nada de lo que referencian se ha eliminado todavía.

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

• Después los metadatos, intercambiados de una vez. Descargue el repodata/ de upstream en un directorio hermano (cada fichero que referencia repomd.xml), verifíquelo, y después sustituya los metadatos publicados con un único rename. Los clientes ven el repositorio antiguo o el nuevo, nunca una mezcla.

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

Usar los metadatos de upstream, en lugar de regenerar los suyos con createrepo_c, mantiene el repositorio exactamente como lo construyó el editor.

Dé a cada tarea de sincronización un lock para que dos ejecuciones nunca se solapen, escriba un pequeño fichero de estado con el resultado y la hora, y avise a alguien cuando una tarea falle. Un mirror que dejó de sincronizar en silencio el mes pasado es peor que ningún mirror, porque todo el mundo confía en él.

Los clientes usan entonces un fichero de repositorio sencillo que apunta a su mirror:

[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

Cuando la corrección existe pero el paquete no

A veces el proyecto upstream publica una versión corregida y el mantenedor de la distribución o del repositorio aún no la ha empaquetado. Muchas veces ese hueco son horas; a veces son días.

La regla que seguimos: construya la versión upstream a partir del propio empaquetado del mantenedor, no cambie nada más, y asegúrese de que el paquete oficial sustituya al suyo automáticamente.

Construya en una sala limpia

Use un contenedor fresco de la misma versión de distribución que los servidores de destino, para que el entorno de construcción sea conocido y desechable:

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

Parta del último paquete fuente (SRPM) del mantenedor para la rama que usted ejecuta, instálelo, e instale sus dependencias de construcción:

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

Cambie solo la versión, y verifique la fuente

Descargue el tarball upstream corregido desde el sitio oficial del proyecto y verifíquelo contra la suma de comprobación que el proyecto publica.

sha256sum php-<fixed>.tar.xz

En el fichero spec, actualice Version a la versión corregida y sustituya la fuente. Deje los parches, las opciones de configure y las listas de ficheros tal como las escribió el mantenedor. Si un parche del mantenedor ya no aplica a la nueva versión, deténgase y entienda por qué antes de seguir.

Elija un release que se aparte

Este es el paso que la gente olvida. Su paquete debe ordenarse por debajo del eventual paquete oficial del mantenedor de la misma versión, de modo que un dnf upgrade normal sustituya al suyo. Un release que empiece por 0. lo consigue de forma fiable:

Release: 0.1.local%{?dist}

Compruébelo antes de construir nada, usando la misma comparación que usa rpm:

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

El release oficial debería salir como más nuevo. Si no lo hace, cambie su cadena de release hasta que lo haga.

Construya, pruebe, conserve la evidencia

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

Guarde los paquetes construidos con sus sumas de comprobación y una nota con la suma del tarball fuente, para que cualquiera pueda decir después exactamente qué se instaló y de dónde salió.

Publique sus builds en un repositorio separado en su mirror, no mezclados en la copia del repositorio del fabricante. Cuando el paquete oficial aterrice en el repositorio replicado, la siguiente actualización normal sustituirá al suyo, y su repositorio separado puede vaciarse.

El mérito a quien corresponde

Nada de esto sustituye a las personas que mantienen los paquetes. Mantenedores de repositorios como Remi Collet, de cuyos repositorios de PHP depende buena parte del mundo Enterprise Linux, publican correcciones con una rapidez notable muchas veces. Construir a partir de su especificación es una forma de cubrir las últimas horas, no un sustituto de su trabajo. Durante las correcciones de PHP2Shell escribimos sobre ambas caras de eso: PHP2Shell: patched PHP packages y Respect to Remi.

Una lista de comprobación para su propia plataforma

• ¿De dónde descargan paquetes sus servidores, y qué ocurre si ese sitio va lento?
• ¿Pueden parchearse sus servidores aislados sin abrirlos a internet?
• ¿Podría un cliente ver alguna vez un repositorio a medio sincronizar en su mirror?
• ¿Se avisa a alguien cuando falla la sincronización de un mirror?
• Si tuviera que construir un paquete esta noche, ¿permite su cadena de release que el oficial lo sustituya?

Si quiere ayuda para montar un mirror o un proceso de construcción de emergencia, nuestros ingenieros comparten con gusto lo que funciona.

cta: Hable con un ingeniero

Related

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