Una actualización de npm destroza varios sistemas Linux

El gestor de paquetes oficial para Node.js ha hecho de las suyas en las tierras de Tux. Una reciente actualización de npm (5.7.0) ha enredado con los permisos de archivos y directorios críticos, provocando en algunos casos la necesidad de reinstalar el sistema.

Múltiples usuarios en GitHub –varios de ellos ejecutando servidores linux– informan que después de utilizar “sudo npm”, binarios en el directorio /usr/bin dejaron de funcionar, así como otras carpetas y archivos presentes en la raíz del sistema, vieron transferida su propiedad a un usuario común (es decir al usuario actual en vez de a root).

No solo las distribuciones GNU/Linux fueron afectados, también sistemas como FreeBSD, viéndose obligados sus administradores a cambiar a mano y de forma recursiva los citados permisos.

La versión afectada es la 5.7.0 que en teoría es una versión previa, aunque la semántica de la misma y el anuncio del lanzamiento en el blog del proyecto, podría llevar a confusión. El fallo se corrigió unas horas después publicando npm 5.7.1.

This release reverts a patch that could cause some ownership changes on system files when running from some directories when also using `sudo`

Distros rolling releases como Arch Linux no llegaron a incluir npm 5.7.0, así que parece que en la mayoría de los casos, la nueva edición llego actualizando npm desde el propio gestor de paquetes (npm), mediante:

npm update -g

Un modo de actualización global, al que evidentemente le da igual, que sea una edición estable o en desarrollo, la que esté por llegar. El va a lo suyo. Llamadme loco, pero quizás esa conducta debería cambiarse.

Un tema complicado el de la gestión de paquetes en lenguajes de programación. Los pip, yarn, cargo, npm, rubygems… nos permiten acceder a paquetes no existentes en los repositorios oficiales o bien más actualizados, pero en mi experiencia lo ideal es optar por el gestor de paquetes de nuestra distro, en vez del específico de un lenguaje, siempre que ello sea posible.

La creación de entornos virtuales (como virtualenv en Python) para trabajar en modo local, también es una práctica recomendada, para evitarse conflictos. Aunque esto de npm es más grave de lo habitual, va más allá de una simple colisión de paquetes.

En cualquier caso, como pasa con la bebida, mejor no mezclar y siempre tenerle respeto al señor Sudo, sobre todo en sistemas en producción.

Y sobre todo si veis a npm 5.7.0, ¡corred por vuestra vida!.

6 thoughts on “Una actualización de npm destroza varios sistemas Linux”

  1. Diego says:

    A ver, estos gestores de dependencias son para desarrollo, cuando haces un programa o librería necesitas un montón de dependencias que están en este tipo de repositorios y nunca van a estar en los de tu distro. Cuando el programa está finalizado debería distribuirse e instalarse mediante el gestor de paquetes de la distro.
    La alternativa a npm es yarn (ambos gestores de dependencias de node), que los paquetes globales por defecto los instala en tu home y tú metes a mano la ruta al PATH si quieres. Si lo haces utilizando el fichero profile sólo afecta a tu usuario. De esta manera no necesitas sudo y es mucho más seguro para el resto del sistema.
    Para terminar hay muy pocos casos en los que veo necesario instalar paquetes globales. Lo normal es instalar paquetes por proyecto.

  2. aarroyoc says:

    Normalmente el comando “npm update -g” no actualiza a las versiones de prueba como tu bien has comentado que debería ser, el problema es que esa función se basa en versionado semántico, y en versionado semántico 5.7.0 sin nada más, es una versión estable más, así que la descargó sin problema.

  3. jncruces says:

    Ayer me salió la actualización y le dí a actualizar, acabo de revisar y resulta que se me olvidó ponerle el “-g” por lo que se instaló en mi cuenta de usuario sin efectos puesto que tiene preferencia la versión global.

    Me salvé por los pelos :D:D

    La versión 5.7.0 es una pre-versión, aún no es estable, lo raro es que sale la recomendación de instalarla pero hay que ejecutar el comando npm -i npm@ para que se instale

  4. Andrés says:

    Los nuevos gestores de paquetes… me quedo con los clásicos y su sistematización para evitar estas cosas.

  5. nadie says:

    Yo creo que la solución no es tanto optar por el sistema de paquetes del propio sistema operativo como evitar correr estas herramientas con permisos de administrador. Como alguien ya ha comentado por aquí, a veces es necesario utilizar estas herramientas para descargar paquetes, a nivel de usuario (no a nivel de administrador), por ejemplo para resolver las dependencias a la hora de compilar algún programa. Pero no veo por qué habría que ejecutarlas con permisos de administrador.

    Si hasta la instalación de paquetes flatpak se puede hacer como usuario normal.

  6. Tomás says:

    Estos nuevos sistemas de paquetería a lo Windows son un desastre.

Deja un comentario

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