Arch Linux est-il adapté à l'environnement de serveur?

Considérez-vous que Arch Linux convient à l'environnement de serveur? Son modèle de version évolutive et sa simplicité semblent être une bonne chose, car une fois que vous l'avez installé, vous n'avez pas besoin de réinstaller comme le modèle de version des autres distributions.

Mais cette mise à niveau constante ne pose pas de problèmes de stabilité? Bien qu'il soit à la pointe du progrès, Arch Linux utilise la version STABLE la plus récente du logiciel.

Le plus gros problème avec Arch en tant que système d'exploitation serveur est probablement qu'il n'est pas clair où et quand les applications peuvent se casser après une mise à niveau. Plus souvent qu'autrement, vous devez vous tenir au courant de ce qui se passe dans le wiki et sur les forums avant de faire toute sorte de mise à niveau; avec Debian et CentOS, vous pouvez être assuré qu'aucune mise à niveau ne cassera aucune application, car le plus souvent, les mises à niveau effectuées sur la branche STABLE seront des correctifs de sécurité / bogues.

Bien que j'aime arch, je ne l'utiliserais pas pour l'environnement de production. Tout d'abord, dans un environnement de production, vous avez besoin de quelque chose de stable et de bien testé. De plus, comme il est assez dépouillé, vous devez créer des scripts personnalisés ou configurer des choses manuellement (c'est parfois bien parce que vous savez exactement ce qui fonctionne sur votre système, mais très mauvais car cela prend trop de temps pour le configurer). En plus de cela, car il n'est pas largement utilisé dans les environnements de production, en cas de problème, vous ne trouverez pas le support que vous trouveriez si vous utilisiez Debian ou Fedora (la communauté Arch est géniale, mais pour être honnête, elle n'est pas aussi grande comme Debian ou Fedora)

Pour résumer, je pense que c'est génial pour une utilisation sur ordinateur, mais pas pour les environnements de production

Oui.

Avantages:

• système vraiment minimal hors de la boîte, idéal pour les performances en particulier sur les machines bas de gamme / VPS. Aucun service inutile - par rapport à CentOS 7 qui a démarré plusieurs services liés aux machines virtuelles qui ne m'étaient même pas applicables car je fonctionnais sur du bare-metal.

• logiciels à jour et grands référentiels; J'ai perdu pas mal de temps avec CentOS lorsque quelque chose n'était pas dans les dépôts et j'ai été obligé de le compiler à partir de la source ou d'installer des RPM / repos tiers, puis de me retrouver dans l'enfer des dépendances parce que ces RPM tiers étaient en conflit avec les mises à niveau des référentiels officiels.

• systemd, bien que d'autres distributions (même Ubuntu) y passent donc c'est moins un pro mais quelque chose à attendre de n'importe quelle distribution décente.

• des outils de configuration réseau qui ont du sens. Aucun Networkmanager de bureau ni pare-feu (en regardant CentOS / RHEL).

• gestionnaire de paquets qui fait exactement ce qu'il dit sur l'étain. Le gestionnaire de paquets n'essaiera pas de vous "aider" en configurant ou en démarrant automatiquement le service que vous venez d'installer (en regardant Ubuntu / Debian). C'est aussi rapide, meilleur que yum, et peut-être un tout petit peu plus rapide que apt-get.

• processus d'installation qui ne vous oblige pas à utiliser les valeurs par défaut et offre beaucoup de place pour la personnalisation - comparez cela à CentOS / RHEL qui vous oblige à utiliser LVM et à permuter, quelque chose qui n'est pas toujours nécessaire (presque jamais dans mon cas en fait)

• /usr/bin/pythonest en fait le dernier Python 3, pas le Python préhistorique 2.7. C'est toujours un problème pour moi avec la plupart des autres distributions, et vous ne pouvez pas facilement changer cela non plus (du moins pas à l'échelle du système) car cela cassera de nombreuses applications qui en dépendent.

Les inconvénients:

• certaines mises à niveau nécessitent une intervention manuelle et peuvent se briser. Je recommande d'avoir une réplique de votre environnement de production dans les machines virtuelles et d'y tester les mises à niveau avant de les déployer sur les vrais serveurs.

• aucune configuration de travail par défaut. Mauvais pour les personnes qui souhaitent simplement exécuter apt-get et installer leur pile LAMP non sécurisée par défaut pour déployer leur application PHP vulnérable et polluer Internet. Bien sûr, c'est en fait un avantage pour les personnes sérieuses car cela vous oblige à revoir les fichiers de configuration avant de démarrer le service.

• pas de support SELinux. Il y a GRSecurity et son RBAC, mais vous aurez besoin de temps pour vous y habituer et le peaufiner.

Je ne serais pas d'accord sur le fait que vous obtenez moins de soutien. Bien sûr, c'est vrai. Est-ce un inconvénient? Non à mon avis. Il y a très peu d'Arch qui pourrait se casser et nécessitera le soutien de quelqu'un qui connaît Arch. Habituellement, si vous avez besoin d'assistance, vous en aurez besoin pour un logiciel particulier, auquel cas vous demanderiez à ses développeurs et le fait que vous exécutiez Arch devient sans importance.

Pour moi, utiliser Arch est beaucoup plus facile et prend moins de temps que d'utiliser CentOS et son Networkmanager, firewalld et d'autres services inutiles (ils peuvent être désactivés, mais c'est déjà du temps perdu). De plus, je connais tous les services qui s'exécutent sur le système parce que je l'aurais installé, pas de logiciel sournois qui me harcèle sur un bug et veut téléphoner à la maison même si je viens d'installer le système.

Je suggérerais toujours l'un des:

• CentOS. Il s'agit d'un clone RHEL gratuit, ce qui signifie que vous bénéficiez d'un très long cycle de support (7 ans), au cours duquel vous pouvez obtenir uniquement des correctifs de sécurité et des améliorations mineures, donc garder le système patché est très, très facile. De plus, de nombreux logiciels "commerciaux" ciblent RHEL, ils sont donc plus faciles à installer sur CentOS. Inconvénients: je préfère apt / dpkg à yum / rpm, pas facile de faire fonctionner un logiciel de pointe, une sélection quelque peu spartiate

• Ubuntu LTS. En fait, je ne l'ai toujours pas utilisé, mais il a également un long cycle de support et c'est Debianish

• Test Debian. Debian, ma distribution préférée, fonctionne très bien et a une sélection de paquets stupidement énorme qui est très bien préparée. Il est un peu plus long de conserver les correctifs, mais il est plus facile d'installer des logiciels (c'est-à-dire qu'il y a plus de choses facilement emballées).

Je suggérerais de considérer les avantages de l'utilisation d'Arch Linux à l'un de ces trois et de voir si cela en vaut la peine.

J'exécute plusieurs serveurs Archlinux depuis 2013 dans un environnement de production et cela fonctionne comme un charme.

Bien sûr, vous devez vous assurer que les mises à jour se déroulent bien en les exécutant souvent et toujours vérifier la page archlinux avant de mettre à niveau.

Mais c'est tout, à la fin, vous aurez beaucoup plus de problèmes pour mettre à jour RedHat / CentOS de 6 à 7 (presque impossible) ou SLES / SLED de 11 à 12 et ainsi de suite.

Vous avez constamment de petites mises à jour qui, de temps en temps, provoquent des actions, mais je n'ai jamais eu quelque chose de gros au cours des 5 dernières années.

Et aussi, vous êtes toujours à jour, s'il y a une fuite de sécurité dans le noyau, dans openssl, dans le bash ou autre, vous avez les mises à jour en quelques heures plutôt qu'en jours ou mois.

Mon serveur par exemple est entièrement mis à niveau et protégé contre le spectre v1, le spectre v2 et l'effondrement, je suis à peu près sûr que seulement 1% des personnes qui publient ici ont des serveurs protégés contre les trois.

C'est rapide, sûr, stable (!) Et vous disposez d'un logiciel actuel qui vous soulage de nombreux problèmes.

Je peux fortement recommander d'utiliser Archlinux sur le serveur, le seul inconvénient est que vous devez savoir ce que vous faites. Vous devez avoir installé un système LFS au moins une fois afin de comprendre les bases de la construction et du fonctionnement d'une distribution Linux.

Le seul système de serveur que j'ai trouvé plus solide que Archlinux dans un environnement de serveur était Gentoo. Il y avait un système Gentoo sans mises à jour pendant 700 jours et 1 heure plus tard, ce système était à jour et fonctionnait avec le seul temps d'arrêt étant un redémarrage unique.

Mais d'autres systèmes comme Debian / Ubuntu, RedHat, SUSE vont juste vous bousiller complètement quand il y a une mise à niveau de la distribution. RedHat vous décourage même activement de faire une mise à niveau de la distribution et vous recommande de réinstaller (selon la documentation officielle).

Alors oui, RedHat est plus stable en termes de mise à niveau qu'Archlinux, mais uniquement parce que vous n'obtenez pas de grosses mises à niveau. Et quand vous les obtenez, vous êtes foutu.

Je dirais que oui, avec la mise en garde, vous ne devriez jamais simplement exécuter pacman -Syu sur un serveur de production et conserver des sauvegardes d'images diff du lecteur système qui peuvent être déplacées sur le système de fichiers en cas de rupture.

BEAUCOUP plus utilisable (beaucoup moins de sites de casse) que Debian testing / Sid. Si vous voulez des packages de pointe et une installation minimale, Arch est la meilleure distribution pour cela, mais nécessite beaucoup de confort avec une gestion manuelle.

La principale différence des distributions de serveur est que vous obtenez uniquement des mises à jour de sécurité, tandis que sur arch, vous obtenez également des révisions majeures des packages, ce qui peut casser des choses.

Si vous souhaitez rendre arch adapté aux serveurs, tout ce que vous avez à faire est de changer vos miroirs (l'endroit d'où vous obtenez les paquets). Par exemple:

• miroirs en arc: vous obtenez des mises à jour mineures / majeures des packages pendant la première semaine après leur sortie par leurs propriétaires.
• manjaro-unstable: Identique aux miroirs en arc, mais certains packages sont revérifiés . Certains bugs majeurs n'arriveront pas en production.
• manjaro-beta: Identique aux miroirs en arc, mais tous les packages sont vérifiés trois fois. La plupart des bugs majeurs n'arriveront pas en production.
• manjaro-stable: Identique aux miroirs en arc, mais les paquets sont vérifiés plusieurs fois pendant des mois. Très peu de bugs mineurs entrent en production.

De la même manière, si vous utilisez des miroirs spécialement conçus pour les serveurs, où vous n'obtenez que des révisions mineures, il serait alors sûr d'utiliser arch sur les serveurs.