A pedido de mi corazón y trabajando como ingeniero de sistemas en diseño digital, a menudo tengo que lidiar con sofisticados productos de software y diseños arquitectónicos. Esto provoca un ansia de minimizar y simplificar todo lo que viene a la mano, y conduce al deleite de las decisiones humanas que simplemente hacen su trabajo. , sin registro y SMS .

Entonces me reuní con Alpine Linux.

Puede que le guste esta distribución por los siguientes motivos:

• Si te gusta el minimalismo y las herramientas orientadas a realizar la tarea sin silbidos y decoraciones innecesarios;
• Si observa que las distribuciones "convencionales" existentes son un poco (?) Hinchadas y redundantes;
• Si desea resolver un problema existente de una manera simple.

Por "corriente principal", me refiero al trío CentOS-Debian-Ubuntu (por supuesto, el mundo no termina allí), perdóname a todos aquellos que creen en estas maravillosas distribuciones. Cuando se usan, periódicamente, en el límite de la percepción, surge una idea aguda: "¿tal vez puede ser más fácil?".

¿Realmente lo necesitamos?

$ desactiva el modo guerra santa
Realmente para la solución de su pequeña tarea se requiere todo esto:

• Maravilloso sistema. ¿Un sistema de inicialización (no del todo) que pueda dar la impresión de un sistema de control de lanzadera?

  Nenen!

  Nadie dice que no puede entender cómo administrarlo, pero su crecimiento desenfrenado puede comenzar a asustar, y la cantidad de conceptos claramente excede el conjunto mínimo requerido. ¿Es todo esto realmente necesario para la implementación de una tarea simple y un reinicio del servidor muy poco frecuente?
  
  

• Subsistema de registro / auditoría construido en un grupo como journald -> rsyslogd + auditd?

  
  
  ¡Esto es indudablemente genial!

  Uno puede adivinar por qué esto se hace de esa manera, pero ¿es realmente necesaria esta cadena para mi tarea simple?

  
  

• ¿Duplicación de la funcionalidad de ejecución de tareas periódicas en systemd y crond?

  ¡Oh, ese Cron!

  ¿Me estoy perdiendo realmente su mecanismo clásico? Quizás su sintaxis no sea completamente obvia, pero ¿son tan obvios los temporizadores en SD?
  
  

• Coexistencia de varios subsistemas de gestión de red en diferentes combinaciones: ¿redes clásicas / networkd / NetworkManager?

  ¡Necesita administrar mucho la red!

  Esta combinación, sí, en el sistema del servidor, y con varias interfaces de gestión para todos los gustos. Aunque no, agreguemos aquí también netplan, que "resuelve" el problema de configuración para los subsistemas enumerados. ¿Desea iniciar su servicio o, a menudo, cambiar la órbita debido a la reconfiguración de las interfaces de red?
  
  

• Servicios como tuned y firewalld?

  ¿Cómo sin ellos?

  ¿Son necesarios para su tarea? En principio, es bueno considerar firewalld como un intento de escapar de la sintaxis de iptables, pero como resultado, en lugar de una sintaxis, comprenderá otra y quedará perplejo por el tamaño de los comandos firewall-cmd. ¿Y realmente necesita un intérprete de Python y sus procesos en el sistema base? No, me encanta Python, pero no en este caso.
  
  

• Servicio de correo local. ¿Estás seguro de que lo usarás?

  
  

Como recordamos el minimalismo, podemos comparar nuestras distribuciones líderes en su instalación mínima :

• El líder en redundancia en espacio en disco y número de paquetes es Ubuntu 18.04 ( 2.8 GB de espacio en disco, 342 paquetes, 31 servicios activos de sistema, 15 procesos al ingresar). La familia systemd aquí está representada en la máxima medida: systemd, networkd, timesyncd, resuelto, logind, hay dbus.
• CentOS 7.5.1804 pierde por disco y número de paquetes, pero es el líder en servicios probablemente redundantes (1.1 GB de espacio en disco, 299 paquetes, 34 servicios activos del sistema, 19 procesos al ingresar, incluidos NetworkManager, firewalld, tuned, postfix, polkitd, auditado, journald + rsyslogd, dbus).
• Debian 9.4.0 hizo todo lo posible para no inflar: 940 MB, 334 paquetes, 25 servicios de systemd activos, 14 procesos al iniciar sesión. Por supuesto, también hay systemd aquí (así como journald, timesyncd y el dbus que lo acompaña), pero sin mucho fanatismo con respecto a la administración de la red.

Holywar: no se puede cambiar el modo a 'deshabilitar': permiso denegado

Quiero un extraño

Puede (intentar) deshacerse de una parte de lo anterior de forma manual, pero de repente todo ya ha sido inventado para nosotros. Idealmente, quiero ver desde la distribución de un sistema operativo de servidor de uso general:

• Curiosamente, el gestor de arranque, que nos llegará al núcleo;
• El núcleo del sistema operativo en sí (Linux en este caso);
• El sistema de inicialización que el núcleo lanzará cuando esté listo. Es deseable, en simplicidad, no lejos del hacha;
• El conjunto mínimo de procesos que iniciará el sistema de inicialización. Bueno, por ejemplo:
  
  • Inicialización final del dispositivo y definición de parámetros adicionales del kernel;
  • Proporcionar diario (¿es posible con revistas de texto? Bueno, por favor);
  • Configuración de red (sería bueno, con menos capas de control);
  • Sincronización horaria (ntpd / chronyd);
  • Varias consolas locales;
  • Opcional: ejecución periódica de tareas (crond);
  • Opcional: acceso remoto al sistema (sshd);
  • Sería bueno guardar y restaurar la configuración del firewall.

Y eso es todo, el resto depende del administrador de paquetes. Menos código ejecutable y configuración - menos errores, menos errores - menos errores. Y el sistema también se está ejecutando y accesible a través de la red. La idea se ve bien, ahora veamos qué tan cerca está la distribución de Alpine Linux .

Sobre Alpine

¿Qué puede encantar a Alpine, especialmente después de CentOS? ¡Minimalismo desesperado!
Bueno y, por supuesto, la falta de necesidad de certificación " Linux Systemd Certified Voldemort ".

Lo que hicieron los autores:

• Reducido el número de componentes base utilizados;
• Elegimos módulos más pequeños y más transparentes;
• Simplificó el proceso de configuración del sistema.

A saber:

• Proceso de instalación extremadamente conciso utilizando la utilidad de consola setup-alpine;
• Extlinux del proyecto syslinux fue tomado como el cargador;
• Una pequeña herramienta de compilación mkinitfs para crear un sistema de archivos temporal utilizado en el arranque;
• Sistema de inicialización Openrc con la definición de dependencias entre servicios, niveles de ejecución y una pizca de scripting;
• Reemplazar la biblioteca libc estándar de GNU con una libl musl más liviana;
• En lugar del paquete GNU coreutils, la mayoría de las utilidades del sistema estándar en una versión algo truncada son parte del paquete busybox, con el que puede estar familiarizado en las soluciones integradas;
• Por defecto, el shell de cenizas se usa como parte de busybox. Por supuesto, nadie se molesta en poner bash si es necesario , bueno, y systemd ;
• Administrador de paquetes apk nativo e infraestructura de distribución de paquetes patentada.

Además, los autores implementaron una serie de medidas destinadas a aumentar el nivel de seguridad del sistema base:

• Aplicamos los parches de kernel grsecurity / PaX (las opiniones difieren sobre su efectividad, pero aún así); Ya no, gracias al colega de los comentarios. Solo el 26 de junio, se lanzó la versión 3.8.0 .
• Los paquetes se recopilaron utilizando modos que reducen la probabilidad de explotar una serie de vulnerabilidades posibles.

Como resultado, obtenemos un sistema equipado con una serie de mecanismos de protección adicionales, lo que nos permite resolver el problema existente y ocupa unos 130 MB . En el sistema en ejecución, se instalan 41 paquetes y se ejecutan 13 procesos de usuario, puede activar ssh.

Y nada mas. Queda por agregar lo que necesita (y poner iptables con la capacidad de restaurar la configuración al inicio).

Abra ligeramente la tapa

Tenga en cuenta: ¡Alpine puede ser útil como campo de entrenamiento cuando se familiarice con Linux! Es subjetivamente más fácil ver la lógica de los componentes que tratar de cubrir CentOS o Ubuntu:

• El gestor de arranque de nuestro sistema instalado es simple, su configuración se divide en 12 líneas:

• Sí, y en / boot no está demasiado lleno:

• Y aquí está el gestor de arranque lanzado sin un fondo de pantalla elegante:

• El núcleo se inicia, recoge initramfs, cumple sus propios pasos de inicialización y llama al comando init (que, de hecho, también viene con busybox). Init usa el archivo / etc / inittab:

• Y aquí se explica explícitamente lo que se debe iniciar para inicializar el sistema:
  
  • Ejecute 6 procesos getty esperando en 6 consolas virtuales para el inicio de sesión del usuario local.
  • Ejecute el sistema de inicialización openrc para alcanzar alternativamente los niveles de inicialización requeridos (openrc no utiliza los niveles de inicialización clásicos 0-6, sino sus propios niveles / grupos sysinit - arranque - predeterminado).

Además, el estado del sistema depende de la configuración de openrc, a saber:

• Variables definidas en los archivos de directorio /etc/conf.d;
• Ejecute scripts ubicados en el directorio /etc/init.d;
• Vinculación de scripts de inicio a "grupos de inicialización":

Queda por leer los scripts de inicio y procesarlos teniendo en cuenta los niveles de lanzamiento y las dependencias.
Usando el ejemplo de syslog (/etc/init.d/syslog), podemos ver cómo se ve el script de inicio de openrc.

Como puede ver, estos no siempre son estos de sus zapatos no amados:

Las variables utilizadas al ejecutar el script se definen en el archivo correspondiente /etc/conf.d/syslog. En nuestro caso, la variable SYSLOGD_OPTS = "- Z" se define en el archivo.
Tenga en cuenta que el script define declarativamente las dependencias de este servicio.

Openrc honestamente itera sobre los scripts de inicio en un orden determinado, alcanza el nivel "predeterminado" - y aquí está, ¡un sistema que funciona!

Demonios bajo el capó

¿Qué se esconde exactamente debajo de los scripts de inicio de openrc? Curiosamente, un conjunto de tareas y demonios se enumeran a continuación.

• Primero, a nivel sysinit:

  
  
  • dmesg: establece el nivel de registro para los mensajes del núcleo;
  • devfs - montar y configurar / dev;
  • mdev: se inicia el administrador de dispositivos;
  • hwdrivers: los módulos de dispositivo se cargan según la información de / sys y / dev;
  
  

• El siguiente es el nivel de arranque:

  
  
  • módulos: se cargan los módulos del núcleo, cuya lista se define en / etc / modules;
  • hwclock: se configuran relojes de hardware en tiempo real;
  • sysctl: establece los parámetros del núcleo que definimos en /etc/sysctl.conf;
  • swap: la partición de intercambio está conectada;
  • bootmisc: los directorios temporales se borran;
  • urandom: se configura un generador de números aleatorios;
  • mapas de teclado: la distribución del teclado se inicializa;
  • hostname: establece el nombre de la máquina, que se define en / etc / hostname;
  • redes: búsqueda e inicialización de interfaces utilizando información de / etc / network / interfaces;
  • syslog: inicia el daemon de registro desde busybox;
  
  

• Y finalmente, el nivel predeterminado:

  
  
  • chrony: se inicia el servicio NTP;
  • crond: se inicia el servicio de ejecución de tareas programadas;
  • acpid: comienza el servicio de seguimiento de eventos de energía;
  • sshd: se inicia el servicio de acceso remoto.
  
  

¡Hurra, después de completar estos pasos, el sistema está listo para funcionar! No olvide las dependencias de los servicios anteriores que se especificaron en los archivos init.d:

• sysfs: montaje / sys;
• fsck: comprueba y repara los sistemas de archivos;
• root: monta el sistema raíz para escribir / leer;
• localmount: monta todos los sistemas de archivos listados en / etc / fstab;
• klogd: registro de eventos del kernel.

Abrimos una de las consolas locales donde getty nos está esperando, ingresamos el inicio de sesión, luego de lo cual pasamos la contraseña al proceso de inicio de sesión y obtenemos acceso al shell de ash en ejecución (cuando se inicia, el contenido de los archivos / etc / profile, /etc/profile.d/* y ~ /.perfil para preparar el entorno del usuario).

¡Hurra, no hay entidades adicionales (indudablemente útiles en algunos casos, como PAM) - y estamos en el sistema!

Queda por usar el administrador de paquetes apk y buscar los paquetes que necesitamos para nuestra tarea. (¿Están allí? Puede evaluar esto a través del portal web ).

Y tambien

• Los autores de la distribución hicieron su propio complemento de iptables llamado "Alpine Wall". Y no se cuelga constantemente como un proceso separado en el sistema;
• Para aquellos a quienes les gusta administrar el servidor a través de la interfaz web, se ha preparado el paquete Alpine Configuration Framework. Sin PHP o Perl, pero con Lua;
• Para aquellos que desean un escritorio, existe la posibilidad de instalar un entorno gráfico (aunque esto puede resultar doloroso al principio);
• Para los conocedores especiales hay una "instalación" de Alpine en la memoria con la configuración almacenada en el almacenamiento externo (consulte la descripción de la herramienta lbu ).

Resumen

La distribución alpina no es perfecta, pero su laconicismo realmente me impresionó, especialmente en el papel de un contenedor (solo 6 procesos: init, 4 * getty, syslogd). Para mí, parece que debería ser el sistema operativo mínimo del servidor (¡perdóname, CentOS!).

Además, es bastante adecuado para el papel de una plataforma de capacitación, lo que le permite ver en qué consiste un kit de distribución moderno, sin sumergirse de inmediato en el abismo de lo que sea-servicios y duplicar repetidamente la funcionalidad en herramientas magníficamente configurables de múltiples niveles para todas las ocasiones.