Qui est derrière le référentiel Webtatic et lui faites-vous confiance

12

Le référentiel Webtatic contient de nombreux packages utiles pour CentOS et RedHat. Cependant, le référentiel est très opaque et j'ai du mal à trouver des informations sur qui est derrière, à part "Andrew Thompson", connu sous le nom d'Andy ici.

Il semble faire un excellent travail en fournissant tous ces packages utiles. J'ai besoin d'utiliser le référentiel sur des serveurs d'entreprise en direct et l'utilisation de référentiels non officiels déclenche immédiatement une alarme en moi.

  • S'agit-il d'un référentiel individuel?
  • Est-il soutenu par une entreprise?
  • Il semble exister depuis quelques années maintenant, mais qu'en est-il de demain? (à part l'astéroïde géant qui peut tous nous essuyer)
  • Est-il sécurisé? Je ne veux pas ensuite yum updatetélécharger un cheval de Troie.
  • À quelle vitesse les correctifs de sécurité sont-ils déployés des packages fournis? ....

Les commentaires des administrateurs CentOS / RedHat réels seront grandement appréciés.

Merci d'avance

Niki
la source
1
Je voudrais noter qu'il existe au moins deux niveaux de confiance très différents: en tant que développeur, je me soucie principalement si les packages sont propres (non modifiés de manière malveillante) et raisonnablement à jour. C'est en tant qu'administrateur système que je me soucie énormément du soutien à long terme et de la longévité des responsables.
jhominal
Correct. Ici, je demande en tant qu'administrateur système, changer le système d'exploitation du serveur / enseigner uniquement tous les 5 ans ou plus
Niki
En tant qu'administrateur système et développeur, il est important d'utiliser des sources décentes de builds. Sinon, vous risquez d'avoir des problèmes tels que de mauvaises versions provoquant des bogues ou des limitations dans les ensembles de fonctionnalités, etc. Une mauvaise source peut distribuer des packages sans des choses comme -O2 et vous ne serez absolument pas au courant.
jgmjgm

Réponses:

5

À mes débuts en tant qu'administrateur Linux il y a 8 ans, j'utilisais un référentiel tiers populaire pour mettre à niveau ma pile LAMP. Il était dirigé par une seule personne. L'une des principales raisons était que les développeurs me faisaient pression pour une version de PHP plus récente que celle fournie avec RHEL 5. Cela a fini par me mordre.

La personne a abandonné les référentiels, donc je n'obtenais plus de mises à jour de sécurité, mais je ne pouvais pas non plus supprimer tous les nouveaux packages et revenir aux packages RHEL en raison de la version RHEL de PHP provenant d'une branche trop ancienne. Le passage à la pile LAMP de ce référentiel a touché au moins une demi-douzaine de packages ou plus. Donc, maintenir ces packages et les recompiler tous à la main de temps en temps serait un PITA majeur.

Vous perdez également la possibilité d'utiliser les avis de sécurité du fournisseur du système d'exploitation concernant les vulnérabilités CVE pour déterminer si votre système est ou non vulnérable à un certain exploit pour ces packages. Cela s'est avéré être un problème majeur pour moi des années plus tard, même si je ne l'avais jamais prévu à l'époque.

Donc, en plus d'avoir confiance dans l'intégrité et les compétences techniques des responsables, vous devez vous demander si vous leur faites confiance pour ne pas passer à un nouvel emploi qui ne leur permettra pas de maintenir le référentiel, ou de se marier et d'avoir des enfants et non plus avoir le temps, etc ....

Depuis lors, je suis très nerveux à l'idée d'utiliser des référentiels tiers, en particulier ceux qui ne sont gérés que par une seule personne.

addictions numériques
la source
Merci! Ce sont toutes les questions que je me pose déjà, mais votre expérience est en partie une réponse à ma question principale. Maintenant, j'espère juste pouvoir obtenir des commentaires plus spécifiques sur le repo Webtatic en particulier, sinon je pense que je suivrai votre conseil, qui est aussi mon instinct et ce que j'ai toujours fait jusqu'à présent. (Comme vous, sa version PHP ...)
Niki
4

La question n'est pas si nous faisons confiance à Andy, c'est si vous faites confiance à Andy.

Je ne connais pas le référentiel mais le bouton don suggère un effort personnel. N'hésitez pas à contribuer si cela a de la valeur pour vous.

Les packages semblent être signés GnuPG, il est donc possible de vérifier avec une certaine certitude que les packages sont authentiques. Vous pouvez également vérifier s'il est sur la toile de confiance.

En ce qui concerne la qualité ou la sécurité, il vaut mieux que quelqu'un d'autre regarde comment fonctionne le référentiel. Ça pourrait être toi. Abonnez-vous aux avis de sécurité en amont et vérifiez s'ils sont affectés. Évaluez les packages comme le ferait un critique pour Fedora.

Si la continuité de ces packages est importante pour vous, acquérez des compétences similaires. Apprenez l'emballage ou embauchez quelqu'un qui le peut.

John Mahowald
la source
1

Remi est la norme pour les dernières versions de PHP pour RHEL. Il est une source établie depuis longtemps et fiable pour les packages RPM qui est activement maintenue et comprend autant de packages pertinents que possible.

La source webtatique est inconnue et non fiable. Il ne devrait pas du tout être utilisé.

Je l'ai trouvé fonctionnant sur un système hérité. Il y avait une grave fuite de mémoire. Je l'ai remplacé par Remi, exactement la même version PHP et tout à coup tout se passe bien. Je ne pense pas que ce soit même une compilation stable.

jgmjgm
la source
0

En général, à moins que vous ne sachiez qu'il existe une fonctionnalité dont vous avez réellement besoin et dont vous ne pouvez pas vous passer (comme beaucoup de gens penseront qu'ils ne peuvent pas ... jusqu'à ce que ce soit un choix entre `` ancien '' ou rien), alors restez avec les packages du fournisseur.

Apprenez à vos webdevs pourquoi une branche n'est pas un instantané stagnant, et montrez-leur - PHP en est un excellent exemple - comment le rebasage en amont apporte beaucoup plus de bugs; et comment, dans de nombreux cas, le temps de réponse pour un backport autour d'un problème de sécurité est en fait plus rapide et plus fiable fourni par une distribution dans leur branche maintenue (car c'est la priorité et le travail de quelqu'un) que dans la version OEM en amont.

Vous êtes peut-être celui qui réussit réellement, et vous devez à nous tous d'essayer ;-)

user2066657
la source
PHP est un assez mauvais exemple: nous avons presque toujours besoin de versions ponctuelles pour les corrections de bugs, mais les distributions ne les fournissent pas. Ils ont bien sûr raison. Mais avoir les dépôts disponibles où nous pouvons obtenir des corrections de bogues dans les versions ponctuelles est extrêmement utile.
Michael Hampton
Nous utilisons différentes distributions, je suppose. Je n'ai pas vu un manque de correction de bogues et de mises à jour de sécurité en PHP, même si la distribution s'est branchée sur une certaine version en amont et que la version semble verrouillée pour le profane. rpm -q php --changelog affiche des mises à jour hebdomadaires avec des corrections de bugs et des mises à jour de sécurité en abondance. Je suis désolé si vous n'obtenez pas le même kilométrage :-(
user2066657
Des distributions définitivement différentes. Je ne vois pas cela en PHP sur RHEL 7.5 ou CentOS 7.5. Fedora a cependant mis à jour les packages PHP et n'a généralement pas ce problème. Heureusement, Remi Collet, l'employé de Red Hat qui construit les packages PHP de RHEL, gère également les référentiels avec les versions de points PHP. Ce qui fait partie de la raison pour laquelle Red Hat l'a embauché.
Michael Hampton
Hmm. Je regardais ceux RH / Centos. Je ne peux pas expliquer pourquoi vous ne voyez pas le même - la liste des modifications que je suis, et je suis désolé de le voir. Je souhaite que Remi mette à jour SCL un peu plus. J'y vois des ralentissements (7.1.8 et même pas une version de package à mettre à jour). J'étais en fait surtout convaincu qu'il était parti ce matin. Si seulement Fedora n'était pas une éphémère.
user2066657
Vraiment? Je ne sais pas quels paquets vous regardez mais je ne vois aucune mise à jour depuis php-5.4.16-45.el7. Peut-être que vous regardez quelque chose d'une collection de logiciels? En parlant de cela, les SCL sont un peu plus lents. Si vous voulez réellement des versions de PHP au fur et à mesure, rendez-
Michael Hampton