La experiencia de un usuario de BSD probando Alpine Linux

 (rubenerd.com)
1 puntos por GN⁺ 2024-04-28 | 1 comentarios | Compartir por WhatsApp
  • Un usuario que usa con frecuencia escritorios BSD y chroot, jail, prueba Alpine Linux y considera que su diseño centrado en seguridad, simplicidad y eficiencia de recursos resulta familiar para quienes vienen de BSD
  • Gracias a su tamaño pequeño y dependencias limitadas, Alpine se usa ampliamente no solo como imagen base para contenedores, sino también en sistemas embebidos, routers, dispositivos móviles, servidores y escritorios
  • La instalación se hace ejecutando setup-alpine en un entorno live para configurar en orden ajustes básicos como keymap, red, zona horaria, SSH y NTP
  • Después del primer arranque se hace evidente la combinación de OpenRC, musl y busybox, con elementos como /etc/rc.conf y crond(8) que conectan con la experiencia de rc al estilo BSD
  • Tras revisar la gestión de paquetes con apk, la configuración de repositorios e incluso la posibilidad de instalar ZFS, la impresión fue lo bastante buena como para considerarlo seriamente como candidato principal de distribución Linux para pruebas y servidores

El carácter de Alpine, familiar para usuarios de BSD

  • Alpine Linux es una distribución Linux independiente, no comercial y de propósito general para usuarios avanzados que priorizan seguridad, simplicidad y eficiencia de recursos
  • Los binarios del espacio de usuario están compilados con PIE (Position Independent Executables) y protección contra stack smashing, con el objetivo de reducir ciertos zero-days y la explotación de vulnerabilidades
  • Alpine es un proyecto más antiguo de lo que parece, al punto de que Natanael Copa ya hablaba de sus orígenes en 2005
  • Al igual que la familia BSD, se usa no solo en sistemas embebidos, routers y dispositivos móviles, sino también en servidores y escritorios generales
  • Por su tamaño pequeño y dependencias limitadas, se usa ampliamente como imagen base para contenedores Linux, y también existen herramientas como alpine-chroot-install para ejecutarlo fácilmente en chroot(8)
    • Esto resulta especialmente interesante para usuarios que usan mucho chroot(8) en NetBSD y jails de FreeBSD para pruebas y despliegues

Experiencia de instalación

  • Alpine ofrece varias compilaciones, incluyendo ARM, PPC64, x86 y x86_64
  • Se arrancó una imagen ISO de Xen en una VM, pero fue una elección basada en leer Dom0 como si fuera DomU
    • Dom0 se refiere al hipervisor Xen y no a un invitado
    • Aun así, el arranque y la instalación avanzaron como si fuera una ISO estándar
  • La instalación consiste en iniciar sesión como root con contraseña vacía en el entorno live y luego ejecutar setup-alpine
  • Durante la instalación se configuran en secuencia elementos básicos como keymap, red, zona horaria y autenticación de root
  • Desde el principio es posible inyectar claves SSH
    • Esto resulta útil después al desplegar grupos de VM o servidores con herramientas de orquestación
    • También ayuda en entornos de hosting que no ofrecen consola OOB
  • Se puede elegir el servidor SSH y el cliente NTP, con opciones como OpenSSH y openntpd
  • El proceso de instalación detectó correctamente que estaba corriendo sobre Xen
  • También es posible configurar LVM, pero en este caso se eligió la configuración estándar que Alpine llama partición sys
    • Esta configuración usa ext4

La configuración del sistema tras el primer arranque

  • Después del primer arranque, en dmesg(1) se puede confirmar que el sistema usa OpenRC
  • OpenRC es un sistema init con portabilidad, tamaño reducido, rapidez, eficiencia, transparencia y seguridad
  • Para quienes están acostumbrados a escribir scripts rc al estilo BSD, OpenRC se siente muy familiar
    • Elementos como /etc/rc.conf y crond(8) se conectan directamente con la experiencia de usuario BSD
  • Que existan distribuciones Linux como Devuan, Gentoo y Alpine usando OpenRC hace que Linux vuelva a sentirse divertido
  • Junto con OpenRC, Alpine incluye musl y usa busybox
    • musl y busybox son más limitados que GCC y GNU coreutils, pero contribuyen al tamaño pequeño del sistema base y a reducir la superficie de ataque
  • También se puede usar llvm
  • El MirBSD Korn shell también está disponible como paquete, y es uno de los shells interactivos preferidos del autor

Gestión de paquetes y repositorios

  • El gestor de paquetes predeterminado de Alpine es apk
  • Como suele pasar en Linux, apk actualiza juntos el sistema base y los paquetes, sin separarlos
  • Aún no se ha comprobado si puede ejecutarse como una copia sin privilegios, como ocurre en BSD
  • También se puede usar pkgsrc, así que queda una alternativa disponible
  • La configuración de repositorios está en /etc/apk/repositories
    • Si se descomenta la segunda URL que ofrece el instalador, se puede activar el repositorio community
    • Alpine también tiene un repositorio testing, y se pueden agregar repositorios propios
  • Su uso es simple, aunque por costumbre a veces se escribe por error apt install en lugar de apk add
  • La interfaz web oficial de paquetes está en pkgs.alpinelinux.org
  • Los repositorios de Alpine también pueden consultarse en pkgs.org

ZFS y su evaluación como candidato para servidores

  • Tras instalar algunos paquetes, fue posible dejarlo con una configuración de “herramientas imprescindibles” similar a la de una laptop solo de consola
  • Uno de los paquetes más sorprendentes fue ZFS
    • La instalación y la carga del módulo del kernel pudieron hacerse con dos comandos
# apk add zfs zfs-lts


# modprobe zfs
  • Configurar el sistema de archivos root sobre ZFS podría ser más complejo
  • Aún no se ha verificado cómo funcionaría una configuración con ZFS después de una actualización
  • Incluso con la experiencia actual, la impresión ha sido lo bastante buena como para considerar seriamente cambiarse a Alpine como distribución Linux principal para pruebas y servidores
  • Entre sus ventajas se mencionan ver solo unos pocos procesos reconocibles en htop(1) y lsof(1), el uso de OpenRC, una gestión de paquetes que parece simple y una configuración sencilla
  • Si existiera un “Occam’s Linux” moderno y funcional, Alpine sería algo muy cercano a eso
  • Si se necesita más funcionalidad que la de busybox, podría probarse uutils, aunque en servidores no parece muy necesario

Lecturas relacionadas

1 comentarios

 
GN⁺ 2024-04-28
Opiniones de Hacker News

  • Desde el punto de vista de la seguridad, hoy en día la mayoría de los binarios de Linux se compilan como PIE
    Si ejecutas checksec sobre un binario cualquiera de Ubuntu, verás esa propiedad, y puedes instalar checksec con pip install pwntools
    Por otro lado, hasta donde sé, GLIBC tiene la implementación de heap más endurecida, con más mitigaciones contra double free y otros ataques al heap
    Así que, en ese aspecto, podría decirse que Alpine es menos seguro por usar musl, pero el hecho de ser un sistema pequeño y fácil de entender es una ventaja real en seguridad

    • No termino de entender por qué “un sistema pequeño y fácil de entender” sería un argumento a favor de glibc. ¿No sería más bien lo contrario?
    • En los nodos Alpine siempre ejecuto checksec sobre todo, y todos los procesos salen de esta forma. Omito la salida completa porque es larga, pero nunca he visto que falten estas flags en algo compilado por Alpine
      COMMAND PID RELRO STACK CANARY NX/PaX PIE
      init 1 Full RELRO Canary found NX enabled PIE enabled
      [snip...]
      crond 422838 Full RELRO Canary found NX enabled PIE enabled
    • También vale la pena revisar OpenBSD libc
    • Desde la perspectiva de seguridad en Linux, si alguien puede ejecutar aunque sea un poco de código en el sistema, ya está todo perdido. Linux está lleno de agujeros, y la razón por la que no está tan lleno de malware como Windows es que poca gente usa Linux en el escritorio, así que los creadores de malware no lo tienen tan en la mira
      Francamente, creo que tanto Windows moderno como macOS tienen una arquitectura de seguridad mejor

  • Yo también soy del mundo BSD y, casualmente, esta semana probé Alpine por primera vez en una VM sobre bhyve
    La clave es BusyBox. Si las utilidades de /bin y /sbin no necesitan ser binarios independientes cada una, el espacio de usuario queda muy pequeño y el arranque también es rápido. Con instalar Tmux y zsh, me alcanzó para la mayoría de usos Unix
    Para llegar al entorno final terminé instalando bastantes cosas con apk, pero en general fue la mejor experiencia con Linux que he tenido en mucho tiempo. Me gustaría que ZFS viniera incluido por defecto y que la conexión virtio adaptada a una ejecución basada en ZFS sobre bhyve fuera más explícita

    • Llevo más de 20 años usando y desplegando FreeBSD, y honestamente me da rechazo entrar a una máquina GNU/Linux. Hay tantas variantes e inconsistencias que el sistema se siente como un desastre. Incluso conectarme a un servidor Windows me parece más “coherente”
      Aun así, me alegra saber que quizá exista una distribución Linux sensata, y si alguna vez necesito una máquina Linux, la probaré. Aunque eso pasa bastante rara vez
    • Me da curiosidad qué tanto esperas que ZFS venga “incluido por defecto”. Alpine es una de las pocas distribuciones que ofrecen módulos de kernel ZFS binarios, así que con un solo comando apk queda prácticamente instalado
      La wiki de Alpine también tiene documentación bastante buena para instalar el sistema de archivos raíz sobre ZFS: https://wiki.alpinelinux.org/wiki/Root_on_ZFS_with_native_en...
    • ZFS funciona muy bien en Alpine. Alpine + ZFS es mi configuración de servidor predeterminada desde hace varios años

  • Si eres usuario de BSD, Void Linux también podría gustarte. Es una distribución creada por xtraeme, desarrollador de NetBSD; tiene versiones con glibc y musl, y usa runit como sistema de init
    También puedes compilar paquetes desde el código fuente con xbps-src
    https://voidlinux.org/

    • Venía usando Arch y, tras buscar una alternativa sin SystemD que se sintiera parecida a Arch, terminé quedándome con Void. La razón por la que elegí Void en vez de Alpine fue el soporte de glibc, que me permite usar los drivers de NVidia. Claro, conozco el “abucheo a NVidia”
    • Me gusta mucho Void. Mi sistema principal es Arch por la gran selección de paquetes y la comodidad de systemd, pero instalé Void en tres equipos, entre los de un familiar y los míos, y funcionó excelente
      Eso sí, hay que tener en cuenta que solo he usado una instalación de xfce con cambios mínimos. Las configuraciones multiusuario complejas pueden ser un poco más engorrosas porque runit trae menos funciones integradas que systemd
    • Hace unos años había problemas al usar Rust en voidlinux+musl. Por suerte, Void se puede reinstalar fácilmente con glibc
    • Chimera también podría estar bien. La mayoría del espacio de usuario de sus herramientas principales proviene de FreeBSD, así que debería resultar bastante familiar para usuarios de BSD
    • También está CRUX. Es una distribución que viene a ser como la precursora de Archlinux

  • Pensé que alguien mencionaría que las páginas man de las que presumen los BSD no vienen incluidas por defecto en Alpine. Esa fue una de las razones por las que no usé Alpine en mi laptop de viaje, y ahora uso OpenBSD
    ¿Me habré perdido alguna opción de configuración para que la documentación se instale siempre al recibir paquetes en Alpine? ¿O no queda otra que instalar manualmente los paquetes -doc cada vez?

    • Si siempre quieres documentación, instala el metapaquete docs. A partir de ahí, arrastrará los paquetes *-doc correspondientes a lo que instales después
    • ¿Qué tal es el soporte de hardware usando OpenBSD en una laptop?

  • Sinceramente, no entiendo en absoluto por qué a la gente le parecen atractivas cosas como OpenRC. Creo que cualquier enfoque basado en supervisión es mejor que soltar PIDs, guardarlos en un archivo PID y esperar que, tres semanas después, ese valor siga apuntando al daemon que ejecutaste
    Además, en algunos casos hacen pgrep de un nombre de proceso específico para encargarse de tareas de administración de servicios. Estoy de acuerdo hasta cierto punto con la idea de que no todo debería reiniciarse automáticamente por defecto, pero esa es prácticamente la única ventaja que puede reivindicar esta clase de herramientas
    Y, al final, estas cosas dependen mucho de syslog, que es tecnología de los 80 tal cual. Herramientas como multilog o svlogd podrían mejorarse para ofrecer más fácilmente una vista centralizada que permita ver de un vistazo el orden de los eventos de varias herramientas, pero se siente raro agrupar logs en categorías ambiguas y permitir que cualquiera registre cualquier cosa, con cualquier nombre, en cualquier lugar

    • Como referencia, Alpine lleva años intentando reemplazar OpenRC, pero no ha encontrado una alternativa adecuada. También hay intentos de convertirse en una distribución independiente del sistema de init
      https://mastodon.social/@ariadne@treehouse.systems/112044942...
      https://mastodon.social/@ariadne@treehouse.systems/112214386...
    • Dicho eso, la principal alternativa es systemd, pero está diseñado de una forma que no es segura y deja espacio para que sigan apareciendo CVE nuevos e interesantes
      Hay demasiadas cosas dentro de PID1, y está escrito en un lenguaje que no es seguro en memoria. No veo ninguna razón técnica por la que no pueda dividirse en un PID1 mínimo y algunos programas setuid
      Lo único que se me ocurre es que eso permitiría ejecutar systemd dentro de contenedores Docker, pero Red Hat/IBM probablemente prefiera que se usen sus propias herramientas de contenerización, como systemd-nspawn, así que no creo que lo quieran con muchas ganas. Con la estructura actual, desde el punto de vista de seguridad, me parece imposible que llegue a ser justificable

  • Alpine tiene una ventaja divertida. Cuando los usuarios de Nix presumen de gestión declarativa de paquetes, puedes editar directamente /etc/apk/world y ejecutar apk fix para mostrar cómo hacerlo sin Nix

    • Por lo general, el enfoque de Gentoo es mejor. Los paquetes instalados manualmente pueden ir en /var/lib/portage/world, los conjuntos elegidos en /var/lib/portage/world_sets y las definiciones de conjuntos en /etc/portage/sets/
      Así puedes dividir los paquetes por categoría, instalar solo algunos en los sistemas que los necesiten y agregar comentarios en los archivos como quieras. El equivalente de apk fix es emerge -uDU @world && emerge -c, aunque es un poco más aparatoso
      Alpine también permite crear algo parecido a conjuntos con apk add -t setname pkg1 pkg2 pkg3, lo que crea un paquete ficticio que depende de los paquetes seleccionados. Yo normalmente hago scripts de shell en /etc/apk/sets/ para imitar el estilo de Gentoo, pero no siempre es igual
    • En el tiempo que Nix tarda en evaluar el flake de mi sistema, puedo reinstalar Alpine desde cero
    • Está genial, pero Nix/OS hace mucho más que instalación declarativa de paquetes

  • Recuerdo que antes, al correr Alpine en Docker, había artículos sobre rendimiento que recomendaban usar Debian/Ubuntu
    Artículos sobre Alpine lento:
    https://pythonspeed.com/articles/alpine-docker-python/
    https://superuser.com/questions/1219609/why-is-the-alpine-do...
    Artículo favorable a Alpine:
    https://nickjanetakis.com/blog/benchmarking-debian-vs-alpine...
    Me pregunto si esto sigue siendo válido hoy

    • Muchas de las quejas concretas ya se resolvieron, al menos. Como reconoce el primer enlace al final, ahora existen wheels de Python compatibles con Alpine, y el problema de DNS se corrigió hace bastante
      Aun así, sería interesante correr benchmarks y ver números reales en términos de rendimiento

  • ¿musl todavía no soporta pthread_attr_setaffinity_np, cierto? Entonces cierto software no puede ejecutarse, y el ejemplo más grande es PyTorch

    • Si una carga de trabajo sensible al rendimiento depende de glibc justamente por ese rendimiento, creo que esa aplicación se puede correr “simplemente” en un contenedor
      En muchas situaciones, la simplicidad o la seguridad son preocupaciones más importantes que el rendimiento

  • El punto medio razonable que encontré entre BSD y Linux es Slackware. Es orgullosamente unixero y no es complicado, y también tiene un árbol de ports propio abundante mediante Slackbuilds

    • Slackware intentó competir con las distribuciones de escritorio, pero perdió el rumbo al no comprometerse de verdad
      Antes me gustaba porque era una distribución mínima que no estorbaba, y la veía orientada a gente un poco más técnica
      Pero cuando investigabas un problema, la comunidad solía ponerse hostil si no habías hecho una instalación completa. La instalación completa era la forma recomendada, y si no la hacías surgían problemas de dependencias tontos, como que mplayer no funcionara por no tener samba
      Creo que Alpine es una mejora frente a Slackware en todos los aspectos
    • Respeto a quienes usan Slackware, pero la falta de gestión de dependencias parece engorrosa

  • Entonces Alpine Linux en realidad no era GNU/Linux. No lo sabía
    ¿Entonces es BusyBox/Linux?

    • Basta con llamarlo Alpine Linux. Que yo sepa, BusyBox no tiene nada que ver con las actitudes ocasionales de autopromoción que se le escapan a RMS, así que está bien