Ist Arch Linux für Serverumgebungen geeignet?

Hältst du Arch Linux für eine Serverumgebung? Das fortlaufende Release-Modell und die Einfachheit scheinen eine gute Sache zu sein, denn sobald Sie es installiert haben, müssen Sie es nicht wie das Release-Modell aus anderen Distributionen neu installieren.

Aber das ständige Aufrüsten verursacht keine Stabilitätsprobleme? Obwohl es auf dem neuesten Stand ist, verwendet Arch Linux die neueste STABLE-Version der Software.

Das wahrscheinlich größte Problem bei Arch als Server-Betriebssystem ist, dass nicht klar ist, wo und wann Anwendungen nach einem Upgrade abstürzen können. In den meisten Fällen müssen Sie immer auf dem Laufenden sein, was im Wiki und in den Foren vor sich geht, bevor Sie ein Upgrade durchführen. Mit Debian und CentOS können Sie sicher sein, dass Upgrades keine Anwendungen beschädigen, da die in der STABLE-Verzweigung durchgeführten Upgrades häufig Sicherheits- / Fehlerbehebungen sind.

Obwohl ich Bogen liebe, würde ich es nicht für die Produktionsumgebung verwenden. Zunächst benötigen Sie in einer Produktionsumgebung etwas Stabiles und Getestetes. Darüber hinaus müssen Sie, da es ziemlich einfach ist, benutzerdefinierte Skripte erstellen oder Dinge manuell einrichten (manchmal ist es gut, weil Sie genau wissen, was auf Ihrem System läuft, aber sehr schlecht, weil es zu lange dauert, es zu konfigurieren). Außerdem, weil es in Produktionsumgebungen nicht weit verbreitet ist, werden Sie im Falle eines Problems nicht die Unterstützung finden, die Sie finden würden, wenn Sie Debian oder Fedora verwenden würden (Arch-Community ist großartig, aber um ehrlich zu sein, ist nicht so groß als Debians oder Fedoras)

Zusammenfassend finde ich, dass es sich hervorragend für den Desktop eignet, aber nicht für Produktionsumgebungen

Ja.

Vorteile:

• Sehr minimales System, das sofort einsatzbereit ist. Hervorragende Leistung, insbesondere auf Low-End-Maschinen / VPS. Keine unnötigen Dienste - im Vergleich zu CentOS 7, das mehrere VM-bezogene Dienste startete, die nicht einmal auf mich zutrafen, da ich auf Bare-Metal lief.

• aktuelle Software und große Repositories; Ich habe viel Zeit mit CentOS verloren, als etwas nicht in den Repos war und ich gezwungen war, es entweder aus dem Quellcode zu kompilieren oder RPMs / Repos von Drittanbietern zu installieren in Konflikt mit Upgrades von offiziellen Repos.

• systemd, obwohl andere Distributionen (sogar Ubuntu) dazu wechseln, ist es also weniger ein Profi, sondern etwas, das man von einer anständigen Distribution erwarten kann.

• Netzwerkkonfigurationstools, die Sinn machen. Kein Desktop-fähiger Networkmanager oder eine Firewall (siehe CentOS / RHEL).

• Paketmanager, der genau das tut, was er verspricht. Der Paketmanager wird nicht versuchen, Ihnen zu "helfen", indem er den gerade installierten Dienst automatisch konfiguriert oder startet (siehe Ubuntu / Debian). Es ist auch schnell, besser als yumund vielleicht ein bisschen schneller als apt-get.

• Installationsprozess, bei dem Sie keine Standardeinstellungen vornehmen müssen und der viel Platz für Anpassungen bietet - vergleichen Sie ihn mit CentOS / RHEL, bei dem Sie LVM und Swap verwenden müssen, was nicht immer erforderlich ist (in meinem Fall fast nie).

• /usr/bin/pythonist eigentlich das neueste Python 3, nicht das prähistorische Python 2.7. Das ist für mich bei den meisten anderen Distributionen immer ein Problem, und Sie können dies auch nicht leicht ändern (zumindest nicht systemweit), da dies viele Apps zum Erliegen bringt, die darauf angewiesen sind.

Nachteile:

• Einige Upgrades erfordern manuelle Eingriffe und können abbrechen. Ich empfehle, eine Replik Ihrer Produktionsumgebung in VMs zu haben und die Upgrades dort zu testen, bevor sie auf den realen Servern bereitgestellt werden.

• Keine Standardkonfigurationen. Schlecht für Leute, die nur apt-get ausführen und ihren unsicheren Standard-LAMP-Stack installieren möchten, um ihre beschissene verwundbare PHP-App bereitzustellen und das Internet zu verschmutzen. Das ist natürlich ein Vorteil für ernsthafte Leute, da Sie gezwungen sind, die Konfigurationsdateien zu überprüfen, bevor Sie den Dienst starten.

• keine SELinux-Unterstützung. Es gibt GRSecurity und seinen RBAC, aber Sie brauchen etwas Zeit, um sich daran zu gewöhnen und ihn zu optimieren.

Ich würde nicht zustimmen, dass Sie weniger Unterstützung bekommen. Klar, das stimmt. Ist das ein nachteil Nein, meiner Meinung nach. Es gibt sehr wenig in Arch, das kaputt gehen könnte und Unterstützung von jemandem benötigt, der mit Arch vertraut ist. Wenn Sie Support benötigen, benötigen Sie diesen normalerweise für eine bestimmte Software. In diesem Fall fragen Sie die Entwickler und die Tatsache, dass Sie Arch ausführen, spielt keine Rolle mehr.

Für mich ist die Verwendung von Arch viel einfacher und weniger zeitaufwendig als die Verwendung von CentOS und dessen Networkmanager, Firewall und anderen nicht benötigten Diensten (sie können deaktiviert werden, aber das ist bereits Zeitverschwendung). Außerdem kenne ich jeden einzelnen Dienst, der auf dem System ausgeführt wird, weil ich ihn installiert hätte, keine hinterhältige Software , die mich über einen Fehler beunruhigt und nach Hause telefonieren möchte, obwohl ich das System gerade installiert habe.

Ich würde immer eines vorschlagen:

• CentOS. Es ist ein kostenloser RHEL-Klon, was bedeutet, dass Sie einen sehr langen Support-Zyklus (7 Jahre) erhalten, in dem Sie nur Sicherheitskorrekturen und kleinere Verbesserungen vornehmen können, sodass das Aktualisieren des Systems sehr, sehr einfach ist. Viele "kommerzielle" Software zielen auf RHEL ab, sodass sie unter CentOS einfacher zu installieren sind. Nachteile: Ich bevorzuge apt / dpkg gegenüber yum / rpm, es ist nicht einfach, hochaktuelle Software darauf laufen zu lassen, etwas spartanische Softwareauswahl

• Ubuntu LTS. Eigentlich habe ich es noch nicht benutzt, aber es hat auch einen langen Support-Zyklus und es ist Debianish

• Debian-Tests. Debian ist meine Lieblingsdistribution, funktioniert sehr gut und hat eine unglaublich große Paketauswahl, die sehr gut zusammengestellt ist. Es ist etwas zeitaufwändiger, gepatcht zu bleiben, aber es ist einfacher, Software zu installieren (dh es gibt mehr Dinge, die einfach zu packen sind).

Ich würde vorschlagen, Profis zu überlegen, Arch Linux für einen dieser drei zu verwenden und zu prüfen, ob es sich lohnt.

Ich betreibe seit 2013 mehrere Archlinux Server in einer Produktionsumgebung und es funktioniert wie ein Zauber.

Stellen Sie sicher, dass die Updates ordnungsgemäß ausgeführt werden, indem Sie sie häufig ausführen, und überprüfen Sie vor dem Upgrade immer die Archlinux-Seite.

Aber das ist es, am Ende werden Sie viel mehr Probleme haben, RedHat / CentOS von 6 auf 7 (fast unmöglich) oder SLES / SLED von 11 auf 12 und so weiter zu aktualisieren.

Sie haben ständig kleine Updates, die von Zeit zu Zeit etwas bewirken, aber in den letzten 5 Jahren hatte ich nie etwas Großes.

Und Sie sind immer auf dem neuesten Stand, wenn es ein Sicherheitsleck im Kernel, in OpenSSL, in der Bash oder was auch immer gibt, haben Sie die Updates in ein paar Stunden anstatt Tagen bis Monaten.

Mein Server ist zum Beispiel vollständig aufgerüstet und gegen Specter v1, Specter v2 und Meltdown geschützt. Ich bin mir ziemlich sicher, dass nur 1% der Leute, die hier posten, Server haben, die gegen alle drei geschützt sind.

Es ist schnell, sicher, stabil (!) Und Sie haben aktuelle Software, die Sie von vielen Problemen befreit.

Ich kann die Verwendung von Archlinux auf dem Server nur empfehlen, der Nachteil ist, dass Sie wissen müssen, was Sie tun. Sie sollten mindestens einmal ein LFS-System installiert haben, damit Sie die Grundlagen verstehen, wie eine Linux-Distribution aufgebaut ist und funktioniert.

Das einzige Server-System, das ich in einer Server-Umgebung als stabiler empfand als Archlinux, war Gentoo. Es gab ein Gentoo-System ohne Updates für 700 Tage und 1 Stunde später war dieses System auf dem neuesten Stand und lief mit der einzigen Ausfallzeit, die ein einzelner Neustart war.

Aber andere Systeme wie Debian / Ubuntu, RedHat, SUSE werden Sie nur völlig durcheinander bringen, wenn es ein Distributions-Upgrade gibt. RedHat rät Sie sogar aktiv von einem Distributions-Upgrade ab und empfiehlt eine Neuinstallation (gemäß der offiziellen Dokumentation).

Also ja, RedHat ist stabiler als Archlinux, aber nur, weil Sie keine großen Upgrades erhalten. Und wenn du sie bekommst, bist du beschissen.

Ich würde ja sagen, mit dem Vorbehalt sollten Sie pacman -Syu niemals einfach auf einem Produktionsserver ausführen und Backups mit unterschiedlichen Images des Systemlaufwerks aufbewahren, die bei einem Defekt über das Dateisystem gerollt werden können.

VIEL benutzerfreundlicher (weit weniger Brüche) als Debian-Tests / sid. Wenn Sie modernste Pakete und eine minimale Installation wünschen, ist Arch die beste Distribution dafür, erfordert aber viel Komfort bei der manuellen Verwaltung.

Der Hauptunterschied von Serververteilungen besteht darin, dass Sie nur Sicherheitsupdates erhalten, während Sie auf arch auch größere Revisionen der Pakete erhalten, die möglicherweise zu Problemen führen.

Wenn Sie möchten, dass Arch für Server geeignet ist, müssen Sie nur Ihre Spiegel (den Ort, an dem Sie Pakete erhalten) ändern. Beispielsweise:

• Arch Mirrors: Sie erhalten kleinere / größere Paket-Updates in der ersten Woche, nachdem sie von ihren Besitzern veröffentlicht wurden.
• manjaro-unstable: Wie Arch Mirrors, jedoch werden einige Pakete doppelt geprüft. Einige große Bugs schaffen es nicht in die Produktion.
• manjaro-beta: Wie Arch Mirrors, aber alle Pakete sind dreifach geprüft. Die meisten großen Bugs schaffen es nicht in die Produktion.
• manjaro-Stall: Wie Bogenspiegel, jedoch werden Pakete monatelang mehrmals überprüft. Sehr kleine kleine Fehler schaffen es in die Produktion.

Auf die gleiche Weise ist es sicher, arch auf Servern zu verwenden, wenn Sie Mirrors verwenden, die speziell für Server entwickelt wurden und bei denen Sie nur geringfügige Überarbeitungen erhalten.