Ist Arch Linux für Serverumgebungen geeignet?

Lösung 1:

Das wahrscheinlich größte Problem mit Arch als Serverbetriebssystem ist, dass nicht klar ist, wo und wann Anwendungen nach einem Upgrade kaputt gehen können. Meistens müssen Sie sich darüber informieren, was im Wiki und in den Foren vor sich geht, bevor Sie irgendeine Art von Upgrade durchführen; Mit Debian und CentOS können Sie sicher sein, dass Upgrades keine Anwendungen beschädigen, da die Upgrades, die im STABLE-Zweig durchgeführt werden, in den meisten Fällen Sicherheits-/Fehlerbehebungen sind.

Lösung 2:

Obwohl ich Arch liebe, würde ich es nicht für Produktionsumgebungen verwenden. Zunächst einmal benötigen Sie in einer Produktionsumgebung etwas Stabiles und gut getestetes. Da es ziemlich abgespeckt ist, müssen Sie außerdem benutzerdefinierte Skripte erstellen oder Dinge manuell einrichten (manchmal ist es gut, weil Sie genau wissen, was in Ihrem System läuft, aber sehr schlecht, weil es zu lange dauert, es zu konfigurieren). Da 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 (die Arch-Community ist großartig, aber um ehrlich zu sein, ist sie nicht so groß wie Debian oder Fedora)

Zusammenfassend finde ich es großartig für den Desktop-Einsatz, aber nicht für Produktionsumgebungen

Lösung 3:

Ja.

Vorteile:

• wirklich minimales System aus der Box, großartig für die Leistung, besonders auf Low-End-Rechnern/VPS. Keine unnötigen Dienste - im Vergleich zu CentOS 7, das mehrere VM-bezogene Dienste startete, die für mich nicht einmal anwendbar waren, da ich auf Bare-Metal lief.

• aktuelle Software und große Repositories; Ich habe ziemlich viel Zeit mit CentOS verloren, wenn etwas nicht in den Repos war und ich gezwungen war, es entweder aus dem Quellcode zu kompilieren oder RPMs/Repos von Drittanbietern zu installieren und dann in der Abhängigkeitshölle zu landen, weil diese RPMs von Drittanbietern waren Konflikt mit Upgrades aus offiziellen Repos.

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

• Netzwerkkonfigurationstools, die Sinn machen. Kein Desktop-Netzwerkmanager oder Firewalld (mit Blick auf 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 yum , und vielleicht etwas schneller als apt-get .

• Installationsprozess, der Sie nicht dazu zwingt, Standardeinstellungen zu verwenden, und viel Raum für Anpassungen bietet - vergleichen Sie das mit CentOS/RHEL, das Sie dazu zwingt, LVM und Swap zu verwenden, etwas, das nicht immer benötigt wird (in meinem Fall eigentlich fast nie)

• /usr/bin/python ist 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 das auch nicht einfach ändern (zumindest nicht systemweit), da es viele Apps, die darauf angewiesen sind, kaputt macht.

Nachteile:

• Einige Upgrades erfordern einen manuellen Eingriff und können brechen. Ich empfehle, eine Kopie Ihrer Produktionsumgebung in VMs zu haben und die Upgrades dort zu testen, bevor Sie sie auf den echten Servern ausrollen.

• keine standardmäßigen Arbeitskonfigurationen. Schlecht für Leute, die nur apt-get ausführen und ihren standardmäßigen unsicheren LAMP-Stack installieren wollen, um ihre beschissene anfällige PHP-App bereitzustellen und das Internet zu verschmutzen. Das ist natürlich ein Vorteil für ernsthafte Leute, da es Sie dazu zwingt, die Konfigurationsdateien zu überprüfen, bevor Sie den Dienst starten.

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

Ich würde der Tatsache widersprechen, dass Sie weniger Unterstützung erhalten. Sicher, 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 erfordert, der mit Arch vertraut ist. Wenn Sie Support benötigen, benötigen Sie ihn normalerweise für eine bestimmte Software. In diesem Fall fragen Sie die Entwickler und die Tatsache, dass Sie Arch ausführen, wird irrelevant.

Für mich ist die Verwendung von Arch viel einfacher und weniger zeitaufwändig als die Verwendung von CentOS und seinem Networkmanager, Firewalld und anderen unnötigen Diensten (sie können deaktiviert werden, aber das ist bereits Zeitverschwendung). Außerdem kenne ich jeden einzelnen Dienst, der auf dem System läuft, weil ich ihn installiert hätte, keine hinterhältige Software, die mich wegen eines Fehlers nervt und nach Hause telefonieren will, obwohl ich das System gerade installiert habe.

Lösung 4:

Ich würde immer eines der folgenden vorschlagen:

• CentOS. Es ist ein kostenloser RHEL-Klon, was bedeutet, dass Sie einen sehr langen Support-Zyklus (7 Jahre) erhalten, während dessen Sie nur erhalten können Sicherheitskorrekturen und kleinere Verbesserungen, sodass es sehr, sehr einfach ist, das System gepatcht zu halten. Außerdem zielen viele „kommerzielle“ Software auf RHEL ab, sodass sie unter CentOS einfacher zu installieren sind. Nachteile:Ich bevorzuge apt/dpkg gegenüber yum/rpm, es ist nicht einfach, hochmoderne Software darauf zum Laufen zu bringen, etwas spartanische Softwareauswahl

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

• Debian-Tests. Debian ist meine Lieblingsdistribution, funktioniert wirklich gut und hat eine unglaublich große Paketauswahl, die sehr gut zusammengestellt ist. Es ist etwas zeitaufwändiger, Patches zu halten, aber es ist einfacher, Software zu installieren (d. h. es gibt mehr Dinge, die sofort gepackt werden können).

Ich würde vorschlagen, Profis in Betracht zu ziehen, Arch Linux für eines dieser drei zu verwenden und zu sehen, ob es sich lohnt.

Lösung 5:

Ich betreibe seit 2013 mehrere Archlinux-Server in einer Produktionsumgebung und es funktioniert wie am Schnürchen.

Natürlich müssen Sie sicherstellen, dass die Updates gut laufen, indem Sie sie oft ausführen und immer die Archlinux-Seite überprüfen, bevor Sie ein Upgrade durchführen.

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 für etwas Action sorgen, aber ich hatte in den letzten 5 Jahren nie etwas Großes.

Und außerdem sind Sie 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 wenigen Stunden statt in Tagen bis Monaten.

Mein Server zum Beispiel ist vollständig aufgerüstet und gegen Spectre v1, Spectre 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 Server sehr empfehlen, der einzige 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 Serversystem, das ich in einer Serverumgebung felsenfester fand 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 einziger Neustart war.

Aber andere Systeme wie Debian/Ubuntu, RedHat, SUSE werden Sie einfach komplett vermasseln, wenn es ein Distributions-Upgrade gibt. RedHat rät Ihnen sogar ausdrücklich davon ab, ein Distributions-Upgrade durchzuführen, und empfiehlt eine Neuinstallation (laut offizieller Dokumentation).

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