Bei meinem Ruf als Systemingenieur im Bereich Digital Design muss ich mich häufig mit anspruchsvollen Softwareprodukten und Architekturentwürfen auseinandersetzen. Dies führt dazu, dass ein Verlangen alles minimiert und vereinfacht, was zur Hand ist, und führt zur Freude an menschlichen Entscheidungen, die nur ihre Arbeit erledigen , ohne Registrierung und SMS .

Also habe ich mich mit Alpine Linux getroffen.

Diese Distribution könnte Ihnen aus folgenden Gründen gefallen:

• Wenn Sie Minimalismus und Werkzeuge mögen, die darauf ausgerichtet sind, die Aufgabe ohne unnötige Pfeifen und Dekorationen zu erfüllen;
• Wenn Sie feststellen, dass die vorhandenen "Mainstream" -Distributionen ein wenig (?) Aufgebläht und überflüssig sind;
• Wenn Sie ein bestehendes Problem auf einfache Weise lösen möchten.

Mit "Mainstream" meine ich das CentOS-Debian-Ubuntu-Trio (natürlich endet die Welt nicht dort), vergib mir all denen, die an diese wunderbaren Distributionen glauben. Wenn sie regelmäßig an der Grenze der Wahrnehmung verwendet werden, entsteht eine scharfe Idee: "Vielleicht kann es einfacher sein?".

Brauchen wir es wirklich

$ Holywar-Modus deaktivieren
Wirklich für die Lösung Ihrer kleinen Aufgabe ist all dies erforderlich:

• Wunderbares System. Ein Initialisierungssystem (überhaupt nicht ganz), das den Eindruck eines Shuttle-Steuerungssystems erwecken könnte?

  Nenen!

  Niemand sagt, dass Sie nicht verstehen können, wie man es verwaltet, aber sein zügelloses Wachstum kann erschrecken, und die Anzahl der Konzepte überschreitet deutlich den erforderlichen Mindestsatz. Ist dies alles wirklich notwendig für die Implementierung einer einfachen Aufgabe und einen sehr seltenen Neustart des Servers?
  
  

• Protokollierungs- / Überwachungssubsystem, das auf einem Bündel wie journald basiert -> rsyslogd + auditd?

  
  
  Das ist zweifellos großartig!

  Man kann sich vorstellen, warum dies so gemacht wird, aber ist eine solche Kette für meine einfache Aufgabe wirklich notwendig?

  
  

• Duplizierung der Funktionen zur regelmäßigen Ausführung von Aufgaben in systemd und crond?

  Oh dieser Cron!

  Vermisse ich wirklich seinen klassischen Mechanismus? Vielleicht ist seine Syntax nicht ganz offensichtlich, aber sind die Timer in SD so offensichtlich?
  
  

• Koexistenz mehrerer Netzwerkverwaltungssubsysteme in verschiedenen Kombinationen: klassisches Netzwerk / networkd / NetworkManager?

  Sie müssen das Netzwerk viel verwalten!

  Diese Kombination, ja, auf dem Serversystem und mit mehreren Verwaltungsschnittstellen für jeden Geschmack. Obwohl dies nicht der Fall ist, fügen wir hier auch netplan hinzu, das das Konfigurationsproblem für die aufgelisteten Subsysteme „löst“. Möchten Sie Ihren Dienst starten oder häufig die Umlaufbahn aufgrund einer Neukonfiguration der Netzwerkschnittstellen ändern?
  
  

• Dienste wie getunt und Firewall?

  Wie ohne sie?

  Werden sie für Ihre Aufgabe benötigt? Im Prinzip ist es schön, Firewalld als einen Versuch zu betrachten, der iptables-Syntax zu entkommen. Als Ergebnis werden Sie jedoch anstelle der einen Syntax die andere verstehen und von der Größe der Firewall-cmd-Befehle verwirrt sein. Und brauchen Sie wirklich einen Python-Interpreter und seine Prozesse im Basissystem? Nein, ich liebe Python, aber in diesem Fall nicht.
  
  

• Lokaler Postdienst. Sind Sie sicher, dass Sie es verwenden werden?

  
  

Da wir uns an den Minimalismus erinnerten, können wir unsere führenden Distributionen in ihrer minimalen Installation sehr grob vergleichen:

• Der Marktführer bei Redundanz im Speicherplatz und in der Anzahl der Pakete ist Ubuntu 18.04 ( 2,8 GB Speicherplatz, 342 Pakete, 31 aktive Systemdienste, 15 Prozesse bei der Eingabe). Die systemd-Familie wird hier maximal dargestellt - systemd, networkd, timesyncd, aufgelöst, logind, es gibt dbus.
• CentOS 7.5.1804 verliert nach Festplatte und Anzahl der Pakete, ist jedoch führend bei wahrscheinlich redundanten Diensten (1,1 GB Festplattenspeicher, 299 Pakete, 34 aktive Systemdienste, 19 Prozesse bei der Eingabe, einschließlich NetworkManager, Firewalld, Tuned, Postfix, Polkitd, auditd, journald + rsyslogd, dbus).
• Debian 9.4.0 hat sich sehr bemüht, nicht aufzublasen: 940 MB, 334 Pakete, 25 aktive Systemdienste, 14 Prozesse beim Anmelden. Natürlich gibt es hier auch systemd (sowie journald, timesyncd und den dazugehörigen dbus), aber ohne viel Fanatismus in Bezug auf das Netzwerkmanagement.

Holywar: Modus kann nicht in "Deaktivieren" geändert werden: Berechtigung verweigert

Ich will ein seltsames

Sie können (versuchen), einen Teil des oben genannten manuell loszuwerden, aber plötzlich wurde bereits alles für uns erfunden? Idealerweise möchte ich anhand der Verteilung eines Allzweck-Server-Betriebssystems Folgendes sehen:

• Seltsamerweise der Bootloader, der uns zum Kernel erreichen wird;
• Der Betriebssystemkern selbst (in diesem Fall Linux);
• Das Initialisierungssystem, das der Kernel startet, wenn er bereit ist. Es ist der Einfachheit halber wünschenswert, nicht weit von der Axt entfernt zu sein;
• Die Mindestmenge an Prozessen, die das Initialisierungssystem startet. Nun, zum Beispiel:
  
  • Endgültige Geräteinitialisierung und Definition zusätzlicher Kernelparameter;
  • Bereitstellung von Journaling (ist dies mit Textmagazinen möglich? Nun, bitte);
  • Netzwerkkonfiguration (wäre schön, mit weniger Kontrollschichten);
  • Zeitsynchronisation (ntpd / chronyd);
  • Mehrere lokale Konsolen;
  • Optional - regelmäßige Ausführung von Aufgaben (crond);
  • Optional - Fernzugriff auf das System (sshd);
  • Es wäre schön, die Firewall-Konfiguration zu speichern und wiederherzustellen.

Und das war's auch schon, der Rest liegt beim Paketmanager. Weniger ausführbarer Code und weniger Konfiguration - weniger Fehler, weniger Fehler - weniger Fehler. Das System läuft und ist auch über das Netzwerk zugänglich. Die Idee sieht gut aus. Nun wollen wir sehen, wie nah die Alpine Linux-Distribution daran ist.

Über Alpine

Was kann Alpine besonders nach CentOS bezaubern? Verzweifelter Minimalismus!
Nun und natürlich die fehlende Notwendigkeit der Zertifizierung " Linux Systemd Certified Voldemort ".

Was die Autoren getan haben:

• Die Anzahl der verwendeten Basiskomponenten wurde reduziert.
• Wir haben kleinere und transparentere Module gewählt.
• Vereinfachung des Systemkonfigurationsprozesses.

Nämlich:

• Sehr präziser Installationsprozess mit dem Dienstprogramm setup-alpine console.
• Extlinux aus dem Syslinux-Projekt wurde als Loader verwendet.
• Ein kleines mkinitfs-Build-Tool zum Erstellen eines temporären Dateisystems, das beim Booten verwendet wird.
• OpenRc-Initialisierungssystem mit der Definition von Abhängigkeiten zwischen Diensten, Runlevels und einer Prise Scripting;
• Ersetzen der Standard-GNU-libc-Bibliothek durch eine leichtere musl-libc;
• Anstelle des GNU-Coreutils-Pakets sind die meisten Standard-Systemdienstprogramme in einer etwas verkürzten Version Teil des Busybox-Pakets, mit dem Sie möglicherweise in eingebetteten Lösungen vertraut sind.
• Standardmäßig wird die Ascheschale als Teil der Busybox verwendet. Natürlich stört es niemanden, wenn nötig zu schlagen gut und systemd ;;
• Native apk Paketmanager und proprietäre Paketverteilungsinfrastruktur.

Darüber hinaus haben die Autoren eine Reihe von Maßnahmen zur Erhöhung des Sicherheitsniveaus des Basissystems umgesetzt:

• Wir haben die grsecurity / PaX-Kernel-Patches angewendet (Meinungen über ihre Wirksamkeit sind unterschiedlich, aber immer noch). Nicht mehr, danke an den Kollegen aus den Kommentaren. Erst am 26. Juni wurde Version 3.8.0 veröffentlicht .
• Pakete wurden mithilfe von Modi gesammelt, die die Wahrscheinlichkeit verringern, eine Reihe möglicher Sicherheitslücken auszunutzen.

Als Ergebnis erhalten wir ein System, das mit einer Reihe zusätzlicher Schutzmechanismen ausgestattet ist, die es uns ermöglichen, das bestehende Problem zu lösen, und etwa 130 MB belegt . Auf dem laufenden System sind 41 Pakete installiert und 13 Benutzerprozesse laufen, Sie können auf ssh klopfen.

Und nichts mehr. Es bleibt noch hinzuzufügen, was Sie benötigen (und iptables mit der Möglichkeit zu setzen, die Konfiguration beim Start wiederherzustellen).

Öffnen Sie den Deckel leicht

Bitte beachten Sie - Alpine kann als Übungsgelände nützlich sein, wenn Sie sich mit Linux vertraut machen! Es ist subjektiv einfacher, die Logik der Komponenten zu erkennen, als zu versuchen, CentOS oder Ubuntu abzudecken:

• Der Bootloader unseres installierten Systems ist einfach, seine Konfiguration gliedert sich in 12 Zeilen:

• Ja, und in / boot ist nicht zu voll:

• Und hier ist der gestartete Bootloader ohne ausgefallenes Hintergrundbild:

• Der Kernel startet, nimmt initramfs auf, führt seine eigenen Initialisierungsschritte aus und ruft den Befehl init auf (der tatsächlich auch mit Busybox geliefert wird). Init verwendet die Datei / etc / inittab:

• Und hier wird explizit dargelegt, was zur Initialisierung des Systems gestartet werden muss:
  
  • Führen Sie 6 getty-Prozesse aus, die auf 6 virtuellen Konsolen auf die lokale Benutzeranmeldung warten.
  • Führen Sie das openrc-Initialisierungssystem aus, um abwechselnd die erforderlichen Initialisierungsstufen zu erreichen (openrc verwendet nicht die klassischen Initialisierungsstufen 0-6, sondern seine eigenen Sysinit-Stufen / Gruppen - Boot - Standard).

Ferner hängt der Zustand des Systems von der Konfiguration von openrc ab, nämlich:

• In den Verzeichnisdateien /etc/conf.d definierte Variablen;
• Führen Sie Skripte aus, die sich im Verzeichnis /etc/init.d befinden.
• Binden von Startskripten an "Initialisierungsgruppen":

Es bleibt, die Startskripte zu lesen und unter Berücksichtigung der Startstufen und Abhängigkeiten zu verarbeiten.
Anhand des Syslog-Beispiels (/etc/init.d/syslog) können wir sehen, wie das openrc-Startskript aussieht.

Wie Sie sehen können, sind dies nicht immer die Ihrer ungeliebten Fußtaschen:

Die beim Ausführen des Skripts verwendeten Variablen sind in der entsprechenden Datei /etc/conf.d/syslog definiert. In unserem Fall ist die Variable SYSLOGD_OPTS = "- Z" in der Datei definiert.
Bitte beachten Sie, dass das Skript die Abhängigkeiten dieses Dienstes deklarativ definiert.

Openrc iteriert ehrlich über Startskripte in einer bestimmten Reihenfolge, erreicht die Standardstufe - und hier ist es, ein funktionierendes System!

Dämonen unter der Haube

Was genau ist unter openrc-Startskripten verborgen? Seltsamerweise - eine Reihe von Aufgaben und Dämonen, die unten aufgeführt sind.

• Erstens auf der Sysinit-Ebene:

  
  
  • dmesg - legt die Protokollierungsstufe für Nachrichten vom Kernel fest;
  • devfs - mount und configure / dev;
  • mdev - der Geräte-Manager startet;
  • hwdrivers - Gerätemodule werden basierend auf Informationen von / sys und / dev geladen.
  
  

• Als nächstes kommt die Boot-Ebene:

  
  
  • Module - Kernelmodule werden geladen, deren Liste in / etc / modules definiert ist.
  • hwclock - Echtzeit-Hardware-Uhren sind konfiguriert;
  • sysctl - legt die Kernelparameter fest, die wir in /etc/sysctl.conf definiert haben;
  • Swap - Swap-Partition ist verbunden;
  • bootmisc - temporäre Verzeichnisse werden gelöscht;
  • urandom - ein Zufallszahlengenerator ist konfiguriert;
  • Keymaps - Das Tastaturlayout wird initialisiert.
  • Hostname - Legt den Namen des Computers fest, der in / etc / hostname definiert ist.
  • Vernetzung - Suche und Initialisierung von Schnittstellen unter Verwendung von Informationen aus / etc / network / interfaces;
  • syslog - Startet den Protokollierungsdämon von der Busybox.
  
  

• Und schließlich die Standardstufe:

  
  
  • chrony - der NTP-Dienst wird gestartet;
  • crond - Der geplante Taskausführungsdienst wird gestartet.
  • acpid - Der Dienst zur Verfolgung von Stromereignissen wird gestartet.
  • sshd - Der Fernzugriffsdienst wird gestartet.
  
  

Hurra, nach Abschluss dieser Schritte ist das System betriebsbereit! Vergessen Sie nicht die Abhängigkeiten von den oben genannten Diensten, die in den init.d-Dateien angegeben wurden:

• sysfs - mount / sys;
• fsck - Dateisysteme prüfen und reparieren;
• root - Mounten Sie das Root-System zum Schreiben / Lesen.
• localmount - Mounten Sie alle in / etc / fstab aufgelisteten Dateisysteme.
• klogd - Protokollierung von Kernelereignissen.

Wir öffnen eine der lokalen Konsolen, auf denen getty auf uns wartet, geben den Login ein, geben dann das Passwort an den Login-Prozess weiter und erhalten Zugriff auf die laufende Ascheschale (beim Start den Inhalt der Dateien / etc / profile, /etc/profile.d/* und ~ /.profile zur Vorbereitung der Benutzerumgebung).

Hurra, keine zusätzlichen Entitäten (zweifellos nützlich in einigen Fällen, wie PAM) - und wir sind im System!

Es bleibt, den apk-Paketmanager zu verwenden und nach den Paketen zu suchen, die wir für unsere Aufgabe benötigen. (Sind sie da? Sie können dies über das Webportal bewerten).

Und auch

• Die Autoren der Distribution haben ihr eigenes Iptables-Add-On namens "Alpine Wall" erstellt. Und es hängt nicht ständig als separater Prozess im System;
• Für diejenigen, die den Server über die Weboberfläche verwalten möchten, wurde das Alpine Configuration Framework-Paket vorbereitet. Ohne PHP oder Perl, aber mit Lua;
• Für diejenigen, die einen Desktop wünschen, besteht die Möglichkeit, eine grafische Umgebung zu installieren (obwohl sich dies am Anfang als schmerzhaft herausstellen kann).
• Für besondere Kenner gibt es eine „Installation“ von Alpine im Speicher, deren Konfiguration im externen Speicher gespeichert ist (siehe Beschreibung des lbu- Tools).

Zusammenfassung

Die alpine Verteilung ist nicht perfekt, aber ihr Lakonismus hat mich wirklich beeindruckt, besonders in der Rolle eines Containers (nur 6 Prozesse - init, 4 * getty, syslogd). Für mich sieht es so aus, als ob das minimale Server-Betriebssystem aussehen sollte (verzeihen Sie mir, CentOS!).

Darüber hinaus eignet es sich gut für die Rolle einer Schulungsplattform, mit der Sie sehen können, woraus ein modernes Distributionskit besteht, ohne sofort in den Abgrund von was auch immer-Diensten zu stürzen und Funktionen in hervorragend mehrstufig konfigurierbaren Tools für alle Gelegenheiten wiederholt zu duplizieren.