paquete

  • El día de ayer me enteré, gracias a la lista de correo de seguridad de Arch Linux, de una vulnerabilidad severa en Grafana para las versiones previas a 5.3.2. Por ende procedí a actualizar mi instalación de Grafana.

    Este artículo podría haberse titulado "Cómo actualizar Grafana en Debian".

  • En este artículo voy a explicar cómo actualizar Slackware, la más antigua (no confundir con vieja) distribución GNU/Linux con vida, utilizando como ejemplo la versión 13.1

    En Slackware existe la herramienta automatizada slackpkg para manejar los paquetes. Slackpkg es una herramienta para instalar o actualizar paquetes de forma sencilla a través de Internet. Es posible tener una instalación mínima de Slackware e instalar/actualizar los paquetes necesarios.

  • En este artículo voy a explicar cómo buscar paquetes, y obtener información de los mismos, desde el gestor de paquetes APT en Debian y derivados (Ubuntu, Mint, Elementary, etc.).

  • Estos días estuve ocupado instalando el SDK (Software Development Kit) de Informix en un servidor Debian. Y junto con eso tuve que instalar el GSKit (IBM Global Security Kit), el cual viene disponible sólo como paquete para Red Hat (.rpm).

    En este artículo voy a explicar cómo convertir un paquete de Red Hat (RPM) en un paquete de Debian (.deb).

  • Este artículo explica cómo administrar/manejar/gestionar paquetes en [inserte nombre de distribución GNU/Linux aquí]. Navegando por DistroWatch me encontré con este excelente material, el cual me tomé el trabajo de traducir al español. Se trata de un cheatsheet o tarjeta de referencia de manejo de paquetes en distribuciones GNU/Linux. Algo que todo distro-hopper debe tener. Si se preguntan qué es un distro-hopper, se trata de una persona que tiene a DistroWatch como página de inicio en su navegador. Recomiendo una leída a los artículos de Enrique Bravo, un célebre distro-hopper y gran bloguero.

    El manejo, administración o gestión de paquetes es probablemente una de las características más distintivas de toda distribución GNU/Linux. Mientras que la tendencia es ofrecer una herramienta gráfica donde los usuarios puedan administrar sus paquetes con el click del mouse, estos programas son front-ends a las utilidades de bajo nivel que manejan las tareas asociadas a la instalación de paquetes en cualquier sistema Linux. A pesar de que a muchos usuarios GNU/Linux les puedan resultar atractivas las herramientas gráficas de alto nivel, no se pueden negar las características que ofrecen las herramientas de línea de comandos: poder, flexibilidad y velocidad. Por otro lado, en un servidor sin interfaz gráfica (¿existen servidores GNU/Linux con interfaz gráfica?) la única alternativa es utilizar las herramientas de línea de comandos.

  • Este artículo explica cómo instalar un paquete no provisto por los repositorios configurados en un servidor CentOS. Cabe recordar que yum, como la mayoría de los gestores de paquetes, permite descargar e instalar software desde diferentes fuentes, llamados repositorios.

    Básicamente, veamos cómo instalar un paquete provisto por el repositorio EPEL, sin agregar el repositorio EPEL a la configuración de yum.

  • Tuve la necesidad de determinar en qué ubicación un cierto paquete estaba instalando uno de sus archivos. En sistemas basados en Debian es posible hacer uso de la herramienta dpkg para tal fin.

  • Para listar todos los paquetes instalados en sistemas Debian/Ubuntu y derivados se debe utilizar la herramienta dpkg.

  • Por razones de compatibilidad, sobretodo cuando instalamos paquetes por fuera del manejador yum (por ejemplo al compilar e instalar un paquete que no está en los repositorios a partir del código fuente), necesitamos que alguna librería o paquete requerido no sea actualizado a una versión más actual.

  • Esto es una funcionalidad genial que acabo de descubrir en Debian. Es posible determinar de forma precisa cual es el paquete que provee a un determinado archivo.

    Un problema que tuve recientemente en una instalación de Debian, fue la ausencia de un determinado archivo. Es decir, conocía exactamente qué archivo me estaba faltando, pero no sabía qué paquete debía instalar para obtenerlo. En estas situaciones es cuando los gestores de paquetes son realmente útiles.

  • En artículos anteriores expliqué cuales son las secciones de cada repositorio y cómo saber desde qué repositorio proviene un paquete en los sistemas basados en Debian. Este artículo pretende explicar cuál es el propósito de los principales repositorios de Debian, y qué tipo de paquetes y actualizaciones provee cada uno.

  • Todavía hay muchas cuestiones en Debian que están pobremente documentadas, o directamente no documentadas. Un caso típico es conocer con exactitud desde qué repositorio proviene un paquete específico. Una pregunta muy lógica, especialmente cuando el sistema operativo en cuestión cuenta con paquetes provenientes de múltiples repositorios. Cierto paquete está causando problemas y quisiéramos saber desde qué repositorio provino.

  • El manejo, administración o gestión de paquetes es probablemente una de las características más distintivas de toda distribución GNU/Linux. Mientras que la tendencia es ofrecer una herramienta gráfica donde los usuarios puedan administrar sus paquetes con el click del mouse, estos programas son front-ends a las utilidades de bajo nivel que manejan las tareas asociadas a la instalación de paquetes en cualquier sistema Linux. A pesar de que a muchos usuarios GNU/Linux les puedan resultar atractivas las herramientas gráficas de alto nivel, no se pueden negar las características que ofrecen las herramientas de línea de comandos: poder, flexibilidad y velocidad. Por otro lado, en un servidor sin interfaz gráfica (¿existen servidores GNU/Linux con interfaz gráfica?) la única alternativa es utilizar las herramientas de línea de comandos.

  • Hoy tuve la necesidad de listar paquetes por repositorio en un servidor Debian 6. Determinar qué paquetes fueron instalados desde un repositorio en particular. Descubrí que no es una tarea sencilla en absoluto. Por ello decidí escribir este breve artículo, para tener a mano el comando en caso de necesitar utilizarlo en el futuro.

  • Si recuerdan, hace un tiempo expliqué cómo utilizar los backports en Debian. Más adelante demostré cómo dar prioridad a los backports, y en dicho artículo decía textualmente:

    "...los backports son paquetes provenientes de testing compilados en un entorno estable... Esto significa que no son paquetes estables."

    "Habiendo aclarado nuevamente la naturaleza de los backports, la conclusión es que esta configuración no es 100% recomendable para servidores..."

    Bueno, este es el caso típico de "haz lo que yo digo, mas no lo que yo hago". Por dar prioridad a los backports y blacklistear "systemd*", terminé con un buen problema de dependencias y el sistema imposible de actualizar. Crónica de una muerte anunciada...

    En este artículo voy a demostrar cómo diagnosticar y resolver problemas de dependencias cuando se utilizan repositorios inestables de Debian y derivados.

  • En una actualización de kernel en Debian, durante la etapa de generación de la imagen del sistema de archivos inicial en memoria RAM (update-initramfs), surgió una advertencia (W: warning) debido a la posible falta de firmare para un determinado módulo.

  • En una instalación mínima de CentOS 6, al tratar de compilar un paquete me encontré con el error possibly undefined macro: AC_PROG_LIBTOOL.