Si administras servidores, sincronizas copias de seguridad o simplemente usas rsync a diario para mover archivos entre máquinas, hay una actualización que merece tu atención aunque el número de versión no lo parezca. Rsync 3.5.1 acaba de salir, y aunque a simple vista es solo un parche sobre la rama 3.5, toca varios puntos que llevaban tiempo dando problemas silenciosos: enlaces simbólicos que se comportaban de forma inesperada, descriptores de archivo que fallaban dentro de contenedores, y una opción de memoria que hacía justo lo contrario de lo que decía su documentación. Nada espectacular en el titular, pero sí en el detalle, que es donde rsync se juega su reputación desde hace treinta años.
Rutas, enlaces simbólicos y por qué esto importa más de lo que parece
Rsync tiene fama merecida de ser quisquilloso con las rutas, y no es capricho: de ahí depende que sincronices lo que crees que estás sincronizando y no otra cosa. En esta versión se corrige un caso concreto que podía dar más de un susto. Cuando una ruta de origen explícita atravesaba directorios padre que en realidad eran enlaces simbólicos, las protecciones de seguridad que rsync aplica durante los escaneos recursivos podían quedar debilitadas. Dicho de otro modo: el programa no siempre distinguía bien entre "esto es un directorio real" y "esto es un enlace que apunta a otro sitio", lo que en escenarios de backup automatizado puede traducirse en archivos que acaban donde no debían.
Se ha afinado también el comportamiento de la opción files-from, que se usa para pasarle a rsync una lista de archivos concretos en lugar de sincronizar un árbol entero. Antes, esas rutas podían interpretarse como si fueran subrutas dentro del directorio raíz de la transferencia, cuando en realidad el operador las había especificado de forma explícita. Si alguna vez has escrito un script que genera esa lista dinámicamente, sabrás que esta clase de ambigüedad es exactamente lo que puede romper una sincronización nocturna sin que nadie se entere hasta que faltan archivos.
Contenedores, espacios de nombres de usuario y la fontanería que nadie ve
Aquí es donde 3.5.1 corrige algo que probablemente ya te había mordido si trabajas con Docker, Podman o cualquier entorno con espacios de nombres de usuario. El acceso a los descriptores estándar, es decir /dev/stdin, /dev/stdout, /dev/stderr y las rutas /dev/fd/N, dejó de funcionar correctamente cuando esos descriptores apuntaban a pipes dentro de un espacio de nombres aislado. Eso afectaba a cosas muy concretas pero muy usadas: leer datos por lotes a través de un FIFO, o técnicas de sustitución de procesos en bash del tipo rsync algo <(comando). Eran regresiones introducidas en versiones anteriores, y si tu pipeline de automatización dejó de funcionar hace poco sin motivo aparente, esta podría ser la explicación que buscabas.
También hay mejoras de conectividad que apuntan en la misma dirección: hacer que rsync se comporte de forma predecible en entornos donde antes no lo hacía. Se ha mejorado la detección de conexiones inetd cuando el demonio recibe un socket local por la entrada estándar, y se ha añadido soporte para contimeout al conectar a un demonio rsync a través de rsh, sin que esto afecte a las transferencias normales por shell remoto. Para quien gestiona redes con latencia alta o conexiones poco fiables, tener control fino sobre los tiempos de espera no es un lujo, es lo que evita que un script se quede colgado media hora esperando algo que nunca va a responder.
Memoria, protocolo y un detalle que se agradece si compilas desde fuente
La opción max-alloc=0 tenía un bug curioso: en lugar de indicarle a rsync que usara el límite máximo de asignación del analizador, lo que hacía era desactivar el límite por completo. Puede sonar a matiz técnico menor, pero en transferencias de volúmenes grandes la diferencia entre "límite alto" y "sin límite" es la diferencia entre un proceso que falla de forma controlada y uno que puede comerse toda la memoria disponible de la máquina. Ya vuelve a comportarse como su nombre sugiere.
El número de protocolo sube a 33, lo que habilita una estadística nueva en la salida de --stats: cuántos bloques lógicos de 4 KiB distintos ha tocado el receptor durante la transferencia. Es un dato pensado para quien necesita entender de verdad qué está pasando bajo el capó cuando algo va más lento de lo esperado. Si compilas rsync con la biblioteca adecuada, esta versión también añade soporte para nombres de dominio internacionalizados, así que hosts con caracteres no ASCII en su nombre ya no necesitan trucos raros para funcionar.
El resto de correcciones son de las que rara vez se anuncian a bombo y platillo pero que uno agradece que existan: manejo corregido de rutas de raíz restringida en rrsync, validación más estricta del estado de directorio parcial, prevención de que un enlace simbólico en un destino alternativo se siga como si fuera el archivo base, arreglos de desplazamientos indefinidos en el código zlib incluido, y una corrección de compilación en FreeBSD amd64 relacionada con ensamblador y SIMD.
Lo que deja esta actualización, en el fondo, es un recordatorio de algo que se olvida fácil cuando una herramienta lleva tres décadas funcionando sin sobresaltos: la fiabilidad no es un estado que se alcanza una vez y ya, es un trabajo continuo de pulir casos límite que casi nadie va a notar hasta que le tocan a él. Rsync sigue ahí, silencioso, moviendo terabytes en scripts de cron de medio mundo, y esta versión es exactamente el tipo de mantenimiento invisible que hace que siga mereciendo esa confianza.
Fuente: NKsistemas
Añadir comentario
Comentarios