Dois-je utiliser la version du package CentOS dans les référentiels (officiels) ou les dernières versions stables des packages?

9

Il s'agit d'une question ouverte, mais je souhaite avoir une discussion constructive et utile sur ce sujet.

Donc, pour clarifier la question: sur un serveur exécutant CentOS 7 (ou toute autre distribution / version Linux d'ailleurs) Est-il préférable de s'en tenir à la version du package dans le repo Base / EPEL ou est-il correct d'obtenir la dernière version stable former le site du package? Dans ce cas, je fais plus spécifiquement référence à des packages tels que nginx, MariaDB et PHP 7. Par exemple, quels seraient les avantages et les inconvénients de l'installation de nginx 1.8.0 par rapport à la version EPEL 1.6.3? Y a-t-il des différences de performances ou des risques de sécurité dans les deux cas?

Toutes les discussions et expériences sont les bienvenues, veuillez essayer de citer les ressources et les faits.

linux centos package-management GiggleSquid
la source
4
J'éviterais d'installer sur un package fourni par le système d'exploitation. Tout d'abord, vous ne savez pas vraiment si des personnalisations ont pu être apportées par le fournisseur de distribution - emplacement du fichier de configuration, etc. Par exemple, que se passe-t-il si vous installez nginx 1.8.0 sur le 1.6.3 fourni par la distribution, puis la distribution passe à 1.9.9? Qu'est-ce que cela va faire pour votre installation personnalisée? En général - ne vis pas avec fourni OS quoi que ce soit , sauf si vous voulez engager à maintenir votre système d' exploitation personnalisé installer pour la durée de vie du serveur . Pour une version ultérieure d'une application fournie par le système d'exploitation, installez-la dans /usr/localou similaire.
Andrew Henle
C'est un bon point, ma réplique à cela serait: encore une fois, par exemple, prenez nginx, la dernière stable étant 1.8.0 et la dernière version héritée étant 1.6.3, que se passe-t-il si un défaut de sécurité est découvert dans la version distro de 1.6.3 ?
GiggleSquid
5
Red Hat : Au fur et à mesure que des failles de sécurité sont découvertes, le logiciel affecté doit être mis à jour afin de limiter tout risque potentiel de sécurité. Si le logiciel fait partie d'un package au sein d'une distribution Red Hat Enterprise Linux actuellement prise en charge, Red Hat, Inc. s'engage à publier des packages mis à jour qui corrigent la vulnérabilité dès que possible. ... (suite)
Andrew Henle
5
Souvent, les annonces concernant un exploit de sécurité donné sont accompagnées d'un correctif (ou du code source qui résout le problème). Ce correctif est ensuite appliqué au package Red Hat Enterprise Linux, testé par l'équipe d'assurance qualité de Red Hat et publié sous la forme d'une mise à jour d'errata . ... Envisagez-vous de vous inscrire à tout ce que cela implique?
Andrew Henle

Réponses:

9

En général, j'essaie très fort d'utiliser les packages par défaut du système.

Cependant, ce n'est parfois pas possible. Pour faire un choix éclairé, vous avez dû répondre à ces questions:

  1. les packages de distribution fournissent-ils les fonctionnalités dont vous avez besoin? Si c'est le cas, vous n'avez même pas besoin de rechercher d'autres packages; utilisez simplement les packages fournis par les référentiels système.
  2. avez-vous besoin d'un soutien officiel et / ou avez-vous dû vous conformer à des politiques spécifiques? Si c'est le cas, vous ne pouvez pas utiliser un référentiel non officiel . Dans ce cas, vous utilisez probablement la mauvaise distribution pour votre projet logiciel.
  3. si la réponse aux questions précédentes était «non», vous deviez rechercher une version logicielle plus récente. Existe-t-il un référentiel bien reconnu avec le package requis? Si oui, utilisez-le.
  4. si aucun référentiel spécifique et fiable n'existe, vous devez utiliser le logiciel en amont. Dans ce cas, essayez très fort d'utiliser des logiciels packagés (par exemple: RPM, DEB, ecc) plutôt que tar.gz (ou autres).
shodanshok
la source
3
Une autre chose que vous pouvez ajouter: inconvénient. Votre employeur (le cas échéant) sait-il que vous faites cela avec les systèmes de l'entreprise, surtout s'il paie pour le support? Entre autres choses, il peut y avoir des raisons juridiques pour lesquelles une entreprise utilise une distribution prise en charge, et le déploiement de la vôtre peut très bien ouvrir l'entreprise à des problèmes de responsabilité, si, par exemple, les données des utilisateurs doivent être protégées. Si votre package installé à domicile non pris en charge fuit les données utilisateur parce que vous avez manqué un correctif de sécurité, vous ne pouvez plus pointer vers Red Hat et dire: «Nous exécutions leur système d'exploitation et nous les avons payés pour le maintenir à jour».
Andrew Henle
6

Les réponses de Matthew Ife et de shodanshok couvrent les problèmes en général, mais je veux répondre à votre préoccupation spécifique en mettant les problèmes en contexte, car c'est exactement ce genre de systèmes que je gère.

Ma version actuelle pour déployer des applications Web PHP / MySQL est la suivante:

Voyons d'abord pourquoi nous choisissons une distribution ou un ensemble de packages particulier. Soit nous privilégions la stabilité par rapport aux dernières fonctionnalités, soit nous privilégions les dernières fonctionnalités à la stabilité. Il n'est généralement pas possible d'avoir les deux dans la même distribution, car le logiciel de stabilisation nécessite du temps pour corriger les bogues, et l'ajout de nouvelles fonctionnalités introduit des bogues, donc de l'instabilité.

En règle générale, je veux que le système d'exploitation sur lequel l'application s'exécute soit aussi stable que possible, mais avec un ensemble de fonctionnalités raisonnablement moderne. Je vais donc choisir CentOS 7 plutôt que CentOS 6, ce qui est assez ancien à ce stade, et bien que cela fonctionne , il ne reste pas autant de temps dans son cycle de vie de support, donc je ne l'utiliserai pas pour un nouveau projet .

Cependant, j'ai ensuite rencontré le problème que la version de nginx incluse avec CentOS était trop ancienne et n'avait pas certaines fonctionnalités requises et corrections de bugs. Je suis donc allé à la recherche de packages alternatifs et j'ai découvert que nginx.org distribuait le leur. Je suis passé à eux presque immédiatement et les ai trouvés parfaitement stables sur le long terme.

Ensuite, il y a PHP. Je sais par histoire que la version de PHP livrée avec CentOS sera la seule version jamais obtenue, et ne recevra que des mises à jour de sécurité; aucune nouvelle fonctionnalité ni correction de bogue. Ainsi, une fois qu'il ne sera plus pris en charge en amont, je serai finalement incapable d'exécuter des applications Web PHP modernes si j'utilise ces packages. Il est donc nécessaire de les remplacer également.

De longue expérience, j'ai appris qu'il est préférable de suivre les versions de correctifs de bogues avec PHP, pas simplement de geler à un moment donné et de ne prendre que des correctifs de sécurité, car les applications Web que j'exécute seront également mises à jour et auront besoin de ces corrections de bogues. Donc, après avoir évalué de nombreux ensembles de packages PHP, je me suis installé sur les pacakges de remi. Remi se trouve être un employé de Red Hat et est également responsable des packages PHP dans RHEL / CentOS. Je sais donc que ses colis seront de haute qualité, et ils l'ont été. Ils remplacent directement les packages système et fonctionnent parfaitement.

Enfin, nous arrivons à MariaDB. Vous pouvez choisir de conserver les packages système ici et de ne subir aucun effet indésirable. J'ai choisi de passer aux packages 10.0 de MariaDB (et je passerai bientôt à 10.1) pour profiter de TokuDB et de certaines autres améliorations de performances non disponibles dans la version 5.5 livrée avec CentOS, et pour lesquelles il ne recevra jamais de mises à niveau majeures.

Dans l'ensemble, vous avez besoin de stabilité dans votre système de base, mais les applications Web changent beaucoup plus rapidement que, disons, les logiciels métier, et votre serveur devra suivre. J'ai donc choisi des points ciblés où la mise à niveau des packages gagnera clairement en avantages avec peu de frais administratifs supplémentaires (aka travail).

Michael Hampton
la source
5

La réponse courte est, utilisez toujours ce qui est fourni par les référentiels système. Faites très attention aux référentiels que vous installez également. Certains sont tout simplement mauvais.

Vous ne devriez pas écraser les packages systèmes avec des versions plus récentes, Redhat est conçu et orchestré très soigneusement et vous pourriez vous retrouver avec des bugs ou des problèmes étranges si vous le faites.

Certaines choses à considérer et à rechercher qui peuvent causer des problèmes comprennent.

  1. Certains référentiels sont tout simplement mal entretenus. Ils ne sont pas mis à jour avec des correctifs de sécurité pour les packages.
  2. Les gens ont tendance à écrire de mauvais RPM, ils ne marquent pas les fichiers de configuration comme des fichiers de configuration, ce qui écrase votre configuration à chaque mise à jour, ce qui pourrait provoquer des problèmes. J'ai déjà vu ce problème.
  3. Ils ne déclarent pas suffisamment leurs dépendances correctement. J'ai déjà vu cela aussi, où un phppaquet a été mis sur le système mais n'a pas mis à jour le pearpaquet qui a introduit des problèmes.
  4. L'installation de plusieurs référentiels offrant tous les mêmes noms de package peut entraîner des problèmes de dépendance imprévus sur votre système.
  5. Certains packages écrasent ou réécrivent les fichiers de configuration système dont d'autres packages dépendent ou s'attendent à exister. Cela entraîne des problèmes avec d'autres packages auxquels vous ne vous attendez pas.

Ne créez jamais de packages à partir des sources et ne les installez pas par-dessus les packages qui s'y trouvent. Cela rompt l'intégrité de votre package système, ce qui peut entraîner d'étranges problèmes ABI tels que la réception unresolved symbolou les undefined referencemessages. Il est assez critique que le système conserve un index fiable et précis sur les logiciels qui ont été déployés sur un système donné pour s'assurer que tout fonctionne correctement les uns avec les autres, c'est la raison pour laquelle nous utilisons les RPM en premier lieu.

La façon viable (et bénie par Redhat) de résoudre ce problème consiste à utiliser des collections de logiciels.

www.softwarecollections.org

Il installe son logiciel et ses «nouvelles» dépendances dans sa propre racine. Cela peut rendre légèrement plus difficile l'application du package dans votre environnement, mais protège votre système contre des erreurs ou des problèmes étranges. Il installe également les packages dans leur propre espace de noms, vous permettant d'installer plusieurs versions d'un package en parallèle.

Le site Web donne des instructions sur l'installation et l'activation de ces packages, il contient la plupart des éléments manquants sur les anciennes versions de CentOS et Redhat (EL6 en particulier). Certaines choses que j'ai utilisées avec succès sur ce site Web.

  • MySQL 5.6 et MySQL 5.7, MariaDB.
  • PHP 5.5 et PHP 5.6
  • Apache 2.4

Notez que votre position par défaut sur cette question ne devrait pas être de s'ajuster à ce que les référentiels Redhat poussent. Au lieu de cela, évaluez si vous avez vraiment besoin d'une version mise à jour d'un package, en particulier quelles sont vos exigences spécifiques, quels problèmes il est censé résoudre et quels risques il présente.

En règle générale, si vous avez constamment besoin d'un logiciel mis à jour et / ou si vous avez besoin de plusieurs versions parallèles des mêmes packages pour que les choses fonctionnent, c'est généralement un indicateur que vous faites quelque chose de mal.

Matthew Ife
la source
1
Certains packages système, tels que les applications utilisateur, peuvent être remplacés par des versions plus récentes en toute sécurité et sans effets néfastes, si le conditionneur sait ce qu'il fait . Mais il n'est pas sûr de mettre à niveau les bibliothèques de cette manière; c'est ce qui provoque les erreurs ABI que vous avez mentionnées. Malheureusement, la connaissance de ce qui peut être mis à niveau en toute sécurité et de la façon de le faire ne semble pas être courante chez les emballeurs. Même Red Hat s'est parfois trompé . OTOH, les collections de logiciels sont une douleur royale dans le cul à utiliser ...
Michael Hampton
1
nginxest l'un de ces packages «tout en un» comme ça. Mais, httpd(dépendances libapr) et mysql(dépendances libmysqlclient) en particulier ne le sont pas. De mauvaises mises à jour de ces deux packages ont causé des erreurs dans pythonet phppour moi dans le passé. Le problème ici n'est pas simple de savoir comment un paquet interagit avec un autre à moins que vous ne sachiez quoi chercher (traduction: il a déjà été gravé par lui).
Matthew Ife
2
Vous pouvez mettre à niveau quelque chose comme MariaDB sans problème réel, car il contient une bibliothèque de compatibilité pour permettre aux programmes liés à l'ancienne version du système de continuer à fonctionner. Vous devez juste vous rappeler d'installer le paquet (et yum devrait se plaindre si vous ne le faites pas). PHP est plus complexe, car il a beaucoup de dépendances qui doivent également être mises à jour avec lui, et si le packager ne le fait pas, les packages sont pires qu'inutiles. Heureusement, puisque remi est également le mainteneur PHP de RHEL, il sait ce que tout cela est, et ses packages ont été très bien.
Michael Hampton