À l'appel de mon cœur et en tant qu'ingénieur système en conception numérique, je dois souvent faire face à des produits logiciels et à des conceptions architecturales sophistiqués. Cela provoque une envie de minimiser et de simplifier tout ce qui vient à portée de main, et conduit au plaisir des décisions humaines qui font juste leur travail , sans inscription et SMS .

J'ai donc rencontré Alpine Linux.

Vous pouvez aimer cette distribution pour les raisons suivantes:

• Si vous aimez le minimalisme et les outils orientés pour accomplir la tâche sans sifflets ni décorations inutiles;
• Si vous remarquez que les distributions «mainstream» existantes sont un peu (?) Gonflées et redondantes;
• Si vous souhaitez résoudre un problème existant de manière simple.

Par «grand public», je veux dire le trio CentOS-Debian-Ubuntu (bien sûr, le monde ne s'arrête pas là), pardonnez-moi tous ceux qui croient en ces merveilleuses distributions. Lorsqu'ils sont utilisés, périodiquement, à la frontière de la perception, une idée précise se pose - "peut-être que cela peut être plus facile?".

En avons-nous vraiment besoin?

$ mode saint-guerre désactivé
Vraiment pour la solution de votre petite tâche tout cela est nécessaire:

• Systemd merveilleux. Un système d'initialisation (pas tout à fait du tout) qui pourrait donner l'impression d'un système de contrôle de navette?

  Nenen!

  Personne ne dit que vous ne pouvez pas comprendre comment le gérer, mais sa croissance effrénée peut commencer à faire peur et le nombre de concepts dépasse clairement le minimum requis. Tout cela est-il vraiment nécessaire pour la mise en œuvre d'une tâche simple et d'un redémarrage très rare du serveur?
  
  

• Sous-système de journalisation / audit construit sur un groupe comme journald -> rsyslogd + auditd?

  
  
  C'est sans aucun doute génial!

  On peut deviner pourquoi cela se fait de cette manière, mais une telle chaîne est-elle vraiment nécessaire pour ma tâche simple?

  
  

• Duplication des fonctionnalités d'exécution de tâches périodiques dans systemd et crond?

  Oh ce Cron!

  Me manque-t-il vraiment son mécanisme classique? Peut-être que sa syntaxe n'est pas complètement évidente, mais les temporisateurs de sd sont-ils si évidents?
  
  

• Coexistence de plusieurs sous-systèmes de gestion de réseau dans différentes combinaisons: mise en réseau classique / networkd / NetworkManager?

  Vous devez beaucoup gérer le réseau!

  Cette combinaison, oui, sur le système serveur, et avec plusieurs interfaces de gestion pour tous les goûts. Bien que non, ajoutons ici également netplan, qui «résout» le problème de configuration des sous-systèmes répertoriés. Voulez-vous démarrer votre service ou changer souvent d'orbite en raison de la reconfiguration des interfaces réseau?
  
  

• Des services comme tuned et firewalld?

  Comment sans eux?

  Sont-ils nécessaires à votre tâche? En principe, il est agréable de considérer firewalld comme une tentative d'échapper à la syntaxe iptables, mais en conséquence, au lieu d'une syntaxe, vous comprendrez l'autre et serez perplexe devant la taille des commandes firewall-cmd. Et avez-vous vraiment besoin d'un interprète python et de ses processus dans le système de base? Non, j'aime le python, mais pas dans ce cas.
  
  

• Service de courrier local. Êtes-vous sûr de l’utiliser?

  
  

Puisque nous nous sommes souvenus du minimalisme, nous pouvons comparer très grossièrement nos principales distributions dans leur installation minimale :

• Ubuntu 18.04 est le leader de la redondance de l'espace disque et du nombre de packages ( 2,8 Go d' espace disque, 342 packages, 31 services systemd actifs, 15 processus à l'entrée). La famille systemd ici est représentée au maximum - systemd, networkd, timesyncd, resolu, logind, il y a dbus.
• CentOS 7.5.1804 perd par disque et nombre de paquets, mais le leader des services probablement redondants (1,1 Go d'espace disque, 299 paquets, 34 services systemd actifs, 19 processus à l'entrée, y compris NetworkManager, firewalld, tuned, postfix, polkitd, auditd, journald + rsyslogd, dbus).
• Debian 9.4.0 a fait de son mieux pour ne pas gonfler: 940 Mo, 334 paquets, 25 services systemd actifs, 14 processus à la connexion. Bien sûr, il y a aussi systemd ici (ainsi que journald, timesyncd et le dbus qui l'accompagne), mais sans beaucoup de fanatisme concernant la gestion du réseau.

Holywar: ne peut pas changer le mode pour «désactiver»: autorisation refusée

Je veux un étrange

Vous pouvez (essayer) de vous débarrasser d'une partie de ce qui précède manuellement, mais tout à coup, tout a déjà été inventé pour nous? Idéalement, je veux voir de la distribution d'un système d'exploitation de serveur à usage général:

• Curieusement, le chargeur de démarrage, qui nous atteindra jusqu'au noyau;
• Le noyau du système d'exploitation lui-même (linux dans ce cas);
• Le système d'initialisation que le noyau lancera lorsqu'il sera prêt. Il est souhaitable, en toute simplicité, non loin de la hache;
• Ensemble minimal de processus que le système d'initialisation va démarrer. Eh bien, par exemple:
  
  • Initialisation finale du périphérique et définition de paramètres de noyau supplémentaires;
  • Fournir des journaux (est-ce possible avec des magazines de texte? Eh bien, s'il vous plaît);
  • Configuration du réseau (ce serait bien, avec moins de couches de contrôle);
  • Synchronisation horaire (ntpd / chronyd);
  • Plusieurs consoles locales;
  • Facultatif - exécution périodique des tâches (crond);
  • Facultatif - accès à distance au système (sshd);
  • Ce serait bien d'enregistrer et de restaurer la configuration du pare-feu.

Et c'est à peu près tout, le reste appartient au gestionnaire de paquets. Moins de code exécutable et de configuration - moins de bogues, moins de bogues - moins de bogues. Et le système est également en cours d'exécution et accessible sur le réseau. L'idée semble bonne, voyons maintenant à quel point la distribution Alpine Linux est proche d'elle.

À propos d'Alpine

Qu'est-ce qui peut charmer Alpine, surtout après CentOS? Un minimalisme désespéré!
Eh bien et, bien sûr, l'absence de besoin de certification " Linux Systemd Certified Voldemort ".

Ce que les auteurs ont fait:

• Réduction du nombre de composants de base utilisés;
• Nous avons choisi des modules plus petits et plus transparents;
• Simplification du processus de configuration du système.

À savoir:

• Processus d'installation extrêmement concis utilisant l'utilitaire de configuration setup-alpine;
• Extlinux du projet syslinux a été utilisé comme chargeur;
• Un petit outil de construction mkinitfs pour créer un système de fichiers temporaire utilisé au démarrage;
• Système d'initialisation Openrc avec la définition des dépendances entre les services, les niveaux d'exécution et une pincée de script;
• Remplacement de la bibliothèque standard GNU libc par une bibliothèque musl plus légère;
• Au lieu du package GNU coreutils, la plupart des utilitaires système standard dans une version quelque peu tronquée font partie du package busybox, que vous connaissez peut-être dans les solutions intégrées;
• Par défaut, la coque en frêne est utilisée dans le cadre de busybox. Bien sûr, personne ne prend la peine de mettre bash si nécessaire , eh bien, et systemd ;
• Gestionnaire de packages apk natif et infrastructure de distribution de packages propriétaire.

En outre, les auteurs ont mis en œuvre un certain nombre de mesures visant à augmenter le niveau de sécurité du système de base:

• Nous avons appliqué les correctifs du noyau grsecurity / PaX (les opinions divergent quant à leur efficacité, mais quand même); Plus maintenant, merci au collègue des commentaires. Le 26 juin seulement, la version 3.8.0 est sortie .
• Les packages ont été collectés à l'aide de modes qui réduisent la probabilité d'exploiter un certain nombre de vulnérabilités possibles.

En conséquence, nous obtenons un système équipé d'un certain nombre de mécanismes de protection supplémentaires, ce qui nous permet de résoudre le problème existant et occupe environ 130 Mo. Sur le système en cours d'exécution, 41 packages sont installés et 13 processus utilisateur sont en cours d'exécution, vous pouvez frapper sur ssh.

Et rien de plus. Il reste à ajouter ce dont vous avez besoin (et à mettre iptables avec la possibilité de restaurer la configuration au démarrage).

Ouvrez légèrement le couvercle

Veuillez noter - Alpine peut être utile comme terrain d'entraînement pour se familiariser avec Linux! Il est subjectivement plus facile de voir la logique des composants que d'essayer de couvrir CentOS ou Ubuntu:

• Le bootloader de notre système installé est simple, sa configuration se décompose en 12 lignes:

• Oui, et dans / boot n'est pas trop de monde:

• Et voici le bootloader lancé sans fond d'écran fantaisie:

• Le noyau démarre, récupère initramfs, accomplit ses propres étapes d'initialisation et appelle la commande init (qui, en fait, est également fournie avec busybox). Init utilise le fichier / etc / inittab:

• Et ici, il est explicitement expliqué ce qui doit être lancé pour initialiser le système:
  
  • Exécutez 6 processus getty en attente sur 6 consoles virtuelles pour la connexion de l'utilisateur local.
  • Démarrez le système d'initialisation openrc pour atteindre alternativement les niveaux d'initialisation requis (openrc n'utilise pas les niveaux d'initialisation classiques 0-6, mais ses propres niveaux / groupes sysinit - boot - par défaut).

De plus, l'état du système dépend de la configuration de openrc, à savoir:

• Variables définies dans les fichiers du répertoire /etc/conf.d;
• Exécutez les scripts situés dans le répertoire /etc/init.d;
• Liaison des scripts de démarrage aux «groupes d'initialisation»:

Reste à lire les scripts de démarrage et à les traiter en tenant compte des niveaux de lancement et des dépendances.
En utilisant l'exemple syslog (/etc/init.d/syslog), nous pouvons voir à quoi ressemble le script de démarrage openrc.

Comme vous pouvez le voir, ce ne sont pas toujours ceux de vos sacs à pieds mal aimés:

Les variables utilisées lors de l'exécution du script sont définies dans le fichier correspondant /etc/conf.d/syslog. Dans notre cas, la variable SYSLOGD_OPTS = "- Z" est définie dans le fichier.
Veuillez noter que le script définit de manière déclarative les dépendances de ce service.

Openrc parcourt honnêtement les scripts de démarrage dans un ordre donné, atteint le niveau «par défaut» - et le voici, un système qui fonctionne!

Des démons sous le capot

Qu'est-ce qui est exactement caché sous les scripts de démarrage openrc? Curieusement - un ensemble de tâches et de démons énumérés ci-dessous.

• Tout d'abord, au niveau sysinit:

  
  
  • dmesg - définit le niveau de journalisation pour les messages du noyau;
  • devfs - monter et configurer / dev;
  • mdev - le gestionnaire de périphériques démarre;
  • hwdrivers - les modules de périphérique sont chargés en fonction des informations de / sys et / dev;
  
  

• Vient ensuite le niveau de démarrage:

  
  
  • modules - les modules du noyau sont chargés, dont la liste est définie dans / etc / modules;
  • hwclock - les horloges matérielles en temps réel sont configurées;
  • sysctl - définit les paramètres du noyau que nous avons définis dans /etc/sysctl.conf;
  • swap - la partition de swap est connectée;
  • bootmisc - les répertoires temporaires sont effacés;
  • urandom - un générateur de nombres aléatoires est configuré;
  • keymaps - la disposition du clavier est initialisée;
  • nom d'hôte - définit le nom de la machine, qui est défini dans / etc / hostname;
  • mise en réseau - recherche et initialisation des interfaces en utilisant les informations de / etc / network / interfaces;
  • syslog - démarre le démon de journalisation à partir de busybox;
  
  

• Et enfin, le niveau par défaut:

  
  
  • chrony - le service NTP démarre;
  • crond - le service d'exécution de tâche planifiée est lancé;
  • acpid - le service de suivi des événements d'alimentation démarre;
  • sshd - le service d'accès à distance démarre.
  
  

Hourra, après avoir terminé ces étapes, le système est prêt à fonctionner! N'oubliez pas les dépendances sur les services ci-dessus qui ont été spécifiées dans les fichiers init.d:

• sysfs - mount / sys;
• fsck - vérifier et réparer les systèmes de fichiers;
• root - monter le système racine pour écrire / lire;
• localmount - monte tous les systèmes de fichiers répertoriés dans / etc / fstab;
• klogd - journalisation des événements du noyau.

Nous ouvrons l'une des consoles locales où getty nous attend, saisissons la connexion, après quoi nous transmettons le mot de passe au processus de connexion et obtenons l'accès au shell ash en cours d'exécution (une fois lancé, le contenu des fichiers / etc / profile, /etc/profile.d/* et ~ /.profile pour préparer l'environnement utilisateur).

Hourra, aucune entité supplémentaire (sans doute utile dans certains cas, comme PAM) - et nous sommes dans le système!

Il reste à utiliser le gestionnaire de paquets apk et à rechercher les paquets dont nous avons besoin pour notre tâche. (Sont-ils là? Vous pouvez évaluer cela via le portail Web ).

Et aussi

• Les auteurs de la distribution ont créé leur propre module complémentaire iptables appelé «Alpine Wall». Et il ne se bloque pas constamment en tant que processus séparé dans le système;
• Pour ceux qui aiment gérer le serveur via l'interface Web, le package Alpine Configuration Framework a été préparé. Sans PHP ou Perl, mais avec Lua;
• Pour ceux qui veulent un bureau, il y a la possibilité d'installer un environnement graphique (bien que cela puisse s'avérer pénible au début);
• Pour les connaisseurs spéciaux il y a une "installation" d'Alpine en mémoire avec la configuration stockée sur un stockage externe (voir la description de l'outil lbu ).

Résumé

La distribution Alpine n'est pas parfaite, mais son laconicisme m'a vraiment impressionné, notamment dans le rôle de container (seulement 6 process - init, 4 * getty, syslogd). Pour moi, il devrait ressembler au système d'exploitation minimal du serveur (pardonnez-moi, CentOS!).

De plus, il convient tout à fait au rôle de plate-forme de formation, ce qui vous permet de voir en quoi consiste un kit de distribution moderne, sans plonger immédiatement dans l'abîme des services D et reproduire à plusieurs reprises des fonctionnalités dans des outils configurables à plusieurs niveaux pour toutes les occasions.