Instalar software en Linux no siempre depende del repositorio oficial de tu distribución. Cuando un paquete no aparece con dnf o apt, existen rutas alternativas para incorporarlo a tu servidor de forma controlada, y conocerlas es parte del trabajo diario de cualquier administrador de sistemas.
A continuación verás cinco caminos prácticos para instalar software en servidores Red Hat y Ubuntu, con sus riesgos, comandos y casos de uso reales extraídos de la clase.
¿Qué hago cuando un paquete no está en los repositorios oficiales?
Cuando intentas dnf install cowsay en Red Hat 8.6 y el sistema responde que no encuentra el paquete, no significa que el software sea inalcanzable. Significa que necesitas otra estrategia.
¿Qué es un archivo .rpm y un archivo .deb? Son los formatos de empaquetado de software en Linux. Los .rpm se usan en distribuciones basadas en Red Hat (Fedora, OpenSUSE, CentOS Stream) y los .deb en distribuciones basadas en Debian, como Ubuntu Server.
¿Cómo instalo un paquete .rpm descargado manualmente?
Una de las formas más directas es buscar el paquete en RPM Finder [02:30]. Ahí encuentras versiones de software empaquetadas para diferentes distribuciones y arquitecturas. Lo importante es elegir la versión correcta:
- Identifica tu distribución y versión, por ejemplo Red Hat 8.6.
- Busca paquetes EPEL (Extra Packages for Enterprise Linux), que son paquetes adicionales legítimos para entornos empresariales.
- Verifica la arquitectura:
x86_64 para servidores de 64 bits, aarch64 para ARM64.
En lugar de descargar el archivo en tu máquina local, copia el enlace y úsalo con curl directamente en el servidor [04:30]:
bash
curl <url-del-paquete> -o cowsay.rpm
sudo dnf install ./cowsay.rpm
El flag -o define el nombre del archivo de salida. Una vez descargado, dnf puede instalarlo apuntando al path local, resolviendo dependencias como si viniera del repositorio.
¿Es seguro instalar software con un script de shell?
La segunda forma es ejecutar scripts de shell descargados desde Internet. Es la vía típica de herramientas como Oh My Zsh, que requiere tener zsh previamente instalado [06:30].
El comando que ofrece su sitio oficial hace tres cosas en una sola línea: descarga el script con curl, lo pasa a sh y lo ejecuta. Es cómodo, pero implica confiar plenamente en la fuente.
¿Qué riesgo tiene ejecutar un script de Internet en mi servidor? El script corre con tus permisos y puede modificar archivos, instalar binarios o abrir puertos. Solo ejecuta scripts de proyectos con respaldo de comunidad y código auditable; nunca de tutoriales desconocidos.
La recomendación práctica: si dudas del origen, no lo instales. Esta regla aplica especialmente a shells, gestores y herramientas que piden permisos elevados.
¿Cómo instalo versiones más recientes con gestores de paquetes específicos?
Los repositorios oficiales suelen ir varias versiones atrás. Si instalas Node.js con dnf install nodejs y revisas con node -V, probablemente obtengas una versión vieja [09:00].
Para software vinculado a un runtime concreto, conviene usar gestores especializados:
- nvm y npm para Node.js, con gran respaldo de la comunidad JavaScript.
- Anaconda para Python, muy usado en data science y administración global de paquetes.
La instalación típica de nvm se hace con curl o wget. Tras la instalación, el script suele pedir que añadas líneas de configuración a tu archivo de shell:
.zshrc si usas Zsh..bashrc si usas Bash.
Una vez configurado, nvm install --lts te da la última versión con Long Time Support, que en la clase resultó ser Node.js 16.18.0 [11:30]. Verificas con node -V y listo.
¿Qué son Snapcraft y Flatpak?
Snapcraft y Flatpak son tiendas de paquetes universales para Linux [12:30]. Permiten instalar software actualizado y aislado, útil tanto para workstations como para herramientas de línea de comandos en servidores.
Ubuntu Server trae Snapcraft preinstalado. Para instalar NeoVim, por ejemplo, basta con verificar la versión y ejecutar el comando que la tienda indica:
bash
snap --version
sudo snap install nvim --classic
NeoVim es un editor en terminal derivado de Vim, ampliamente usado en desarrollo y DevOps por su soporte de plugins. Lo abres con nvim y sales con :q, igual que en Vim.
¿Qué hago si ninguna alternativa funciona en mi distribución?
La última ruta es descargar el binario compilado y colocarlo manualmente en el path del sistema. Es el caso de screenfetch en Red Hat [14:30], donde dnf no lo encuentra y tampoco está disponible en EPEL.
El flujo es el siguiente:
- Descargar el binario desde el repositorio oficial, por ejemplo el GitHub del proyecto.
- Darle permisos de ejecución con
chmod +x screenfetch-dev.
- Mover el binario a
/bin con privilegios de root para que esté disponible en el path.
bash
chmod +x screenfetch-dev
sudo mv screenfetch-dev /bin/screenfetch
screenfetch
Al quedar dentro de /bin, cualquier usuario del sistema puede ejecutarlo como un comando normal. screenfetch muestra un resumen visual del sistema: distribución, kernel, CPU, memoria y entorno de escritorio.
¿Por qué mover un binario a /bin lo convierte en comando? Porque /bin está incluido en la variable $PATH, que es la lista de directorios donde el sistema busca ejecutables cuando escribes su nombre en la terminal.
¿Cuál es el riesgo real de instalar software fuera de los repositorios?
Mientras un archivo sea ejecutable, puede entrar a tu sistema. Esa flexibilidad es la fortaleza de Linux y también su riesgo principal.
Instalar software desde fuentes no verificadas puede introducir:
- Software malicioso con acceso a datos o credenciales.
- Paquetes de baja calidad que rompen dependencias.
- Binarios que escalan privilegios sin control.
La regla práctica: descarga solo de proyectos con respaldo de comunidad, repositorios oficiales en GitHub o tiendas como Snapcraft y Flatpak. Antes de mover algo a /bin o ejecutar un script con sudo, pregúntate si confías en quien lo publicó.
¿Cuál de estas formas usas más en tus servidores y por qué? Cuéntalo en los comentarios.
