Release Tech Tecnología

El efecto 2020 en Perl y sus consecuencias en Pandora FMS

enero 3, 2020

El efecto 2020 en Perl y sus consecuencias en Pandora FMS

This post is also available in : Inglés

Perl 2020: un fallo y una actualización necesaria de Pandora FMS

Cuando creíamos que nos habíamos librado del efecto 2000, nos hemos topado de bruces con un efecto inesperado. El efecto 2020. Enterrado en lo más profundo del sistema, una librería básica de Perl ha hecho que a partir del 1 de enero de 2020, cualquier operación de comparación de fechas con el año 1970 se convierta en 2070. Puede parecer algo sin importancia, excepto que para muchos sistemas, el “comienzo” del calendario Unix empieza precisamente en 1970, es decir, una fecha de referencia base, utilizada en mucho código, precisamente, desde el origen de los tiempos de Unix, 1970.

Este bug lo detectaron al menos cuatro personas distintas a lo largo de 2018 (desconocemos si alguna de ellas lo hizo en sus propias comunidades después de analizar el trabajo de otra persona):

Según informa el hilo de CPAN, el problema se arregló en la versión 1.27 (Perl 5.27.1), pero dicha actualización no se reflejó en las diferentes distribuciones de Linux. Hemos probado OpenSUSE 15, Debian 10.2 y Debian Testing (Dic 2019), Ubuntu19 y CentOS8 y son todas vulnerables a este problema.

El caso es que este problema afecta a Linux como sistema operativo base, ya que la librería Time-Local es parte del núcleo básico de Perl, y Perl es una parte esencial de las distribuciones de Linux.

Este problema afecta a Pandora FMS, haciendo que no pueda crear módulos nuevos. Afortunadamente, en un sistema en producción no tiene mayor efecto que ese, pero seguramente unas decenas de usuarios que han desplegado monitorización nueva o instalado algún entorno desde cero han experimentado una gran frustración al intentar desplegar su monitorización.

El equipo de Pandora FMS se dio cuenta del fallo el mismo día 2 de enero a primera hora de la mañana, el día 3 ya estábamos desplegando hotfixes a nuestros clientes para solventar el fallo. En vez de recomendar parchear una librería base del sistema, tarea compleja teniendo en cuenta la inmensa variedad de versiones de sistemas Linux que existen, hemos decidido cambiar la función que se utiliza en Pandora FMS para comparar fechas, de manera que en vez de usar la función de Perl timelocal() utilizaremos srtftime() que no tiene este problema. Para ello, hemos generado una serie de paquetes binarios para nuestros clientes con soporte; ya estamos trabajando con ellos para que solucionen y conozcan el problema antes incluso de que lo adviertan por ellos mismos.

Es tan sencillo como reemplazar el servidor y reiniciarlo. Como una actualización más de Pandora FMS, pero fuera de fecha. Digamos que esta vez, los Reyes Magos nos han traído una actualización no deseada.

Descarga los paquetes aquí.

¡Feliz año 2020!


One comment
  1. Joaquín Ferrero

    Una aclaración sobre la distribución de Time::Local. La versión 1.27 de este módulo apareció en metacpan el 2018/06/09, el mismo día que se publicó el parche en RT.Como se trata de un módulo integrado en la distribución estándar, apareció en Perl v5.29.1 (versión de desarrollo) el 2018/07/20, actualizado a la versión 1.28, y en Perl v5.30 (versión estable) el 2019/05/22.El problema está en las distribuciones Linux, que tardan mucho en actualizar la versión de Perl. Por ejemplo: · Debian 10 (buster) tiene la v5.28.1-6. Perl v5.30 aún está en la rama inestable (bullseye). · Ubuntu 19.10 tiene la misma versión que Debian. · CentOS 8 sigue en Perl v5.26.3. · openSUSE Leap 15.1, Perl v5.26.1En cambio otras ya lo han hecho: · Fedora 31 tiene Perl v5.30.1 · NetBSD 8.1, Perl v5.30.0 · Arch Linux, Perl v5.30.1La recomendación básica es: no hay que confiar en la versión Perl del sistema en donde estemos. Ese Perl está preparado y probado para funcionar con ese sistema operativo, pero no hay garantías de que esté optimizado para nuestras necesidades o en la versión que requerimos para nuestra aplicación. O, como es este caso, suficientemente actualizado.Es por ello que se recomienda instalar un Perl local para nuestra aplicación, algo que es muy cómodo de hacer hoy en día con herramientas como perlbrew (App::perlbrew) o plenv. Con herramientas como local::lib y cpanminus se puede además mantener un sitio local para otras bibliotecas no incluidas en la distribución principal, con lo que tendremos un ecosistema completamente aislado del Perl del sistema.https://blog.geekuni.com/2015/05/how-to-install-different-versions-of-perl.html http://perlenespanol.com/foro/post29004.html http://perlenespanol.com/foro/actualizar-perl-t7725.html https://stackoverflow.com/questions/4764025/how-to-specify-which-version-of-perl-to-use-on-centosEsto es una solución común en otros lenguajes, como Java, donde muchas aplicaciones se distribuyen con su propio JRE.

Leave a comment

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.