Salut,
Je cherche à récupérer tous les patchs security d'une release redhat mais je sèche un peu sur la méthode à employer.
L'idée c'est de récupérer tous les patchs, par exemple d'une redhat 4 update 4, et ensuite de les appliquer sur un ensemble de machines à l'aide d'un serveur yam. Je maîtrise la partie serveur yam mais je ne vois pas trop comment downloader tous les patchs.
Le hic c'est qu'il n'y a pas de canal security comme il y a des canaux update ou extra. C'est en partie dû au fait que les patchs sont spécifiques à une sub-release ( 4 update 4 differents de 4 update 5 ).
Quelqu'un à une piste ?
Evidemment je cherche à tout récupérer en masse et pas aller sur le site de redhat pour prendre chaque patch.
Je sais aussi que ça doit être possible avec le produit payant de redhat Redhat Network Proxy mais j'aimerais éviter de payer encore d'autres licences.
Forum Linux.redhat Recuperer tous les updates security
8
nov.
2007
# Ah, toujours ces problèmes...
Posté par ragoutoutou . Évalué à 1.
Pour ma part, j'ai dû modifier lourdement le script de téléchargement du plugin rhn de yum (rhel5) afin d'avoir un script capable de chopper l'index complet des repositories de redhat, de comparer les checksums avec mes dépôts et de ne télécharger que les fichier non présents dans mes dépôts...
Pourquoi tant de chipotage alors qu'il suffirait d'acheter le proxy?
Parceque ça ne s'intègre tout simplement pas dans la politique de gestion des mises à jour et des releases dans l'entreprise où je travailles (secteur bancaire).
RedHat devrait vraiment faire quelque-chose à ce niveau, ce sont les produits qui doivent être adaptables aux besoins et non l'inverse. Quand on paye pour un RedHat, on devrait avoir tout de même au moins la flexibilité d'un CentOS ou d'un Fedora.
[^] # Sans parler de la debian
Posté par mururoa69 . Évalué à 0.
C'est rageant quand on connaît la facilité d'avoir un dépôt security avec une debian ...
[^] # Re: Sans parler de la debian
Posté par Raphaël SurcouF (site web personnel) . Évalué à 2.
[^] # Re: Sans parler de la debian
Posté par ragoutoutou . Évalué à 2.
[^] # Re: Sans parler de la debian
Posté par Raphaël SurcouF (site web personnel) . Évalué à 3.
Maintenant, faire un miroir Debian est aussi aisé que de disposer d'un serveur Satellite RHN. Je pense que ta contrainte est ailleurs (comme aucun accès direct à Internet ?).
[^] # Re: Sans parler de la debian
Posté par ragoutoutou . Évalué à 2.
Ben on peut sinon comparer à SuSE, qui offre tout de même une flexibilité proche des debian et autres pour la récupération des mises à jour pour se faire un dépôt sur le lan.
La contrainte est de pouvoir récupérer les fichiers simplement et de pouvoir les organiser comme on veut. Il est dommage que RedHat refuse cela à ses clients et essaye de leur fourguer un produit.
[^] # Re: Ah, toujours ces problèmes...
Posté par Raphaël SurcouF (site web personnel) . Évalué à 2.
Je ne pense pas cela dit que le problème vienne de RedHat car ces clients-là veulent surtout de RedHat un bon support matériel et se reposent entièrement sur le prestataire de services pour l'aspect logiciel. D'ailleurs, les applications installées ne sont pas toujours disponibles avec la distribution officielle de la RHEL installée...
Pourquoi ne pas acheter un proxy ? Comment ton entreprise s'y prend-t-elle pour les mises à jour de Windows ? Ou pour les mises à jour des autres systèmes (AIX, Solaris, etc.) ? En quoi consiste cette politique de gestion des mises à jour ?
[^] # Re: Ah, toujours ces problèmes...
Posté par ragoutoutou . Évalué à 3.
Enregistrer les machines sur RHN n'est pas forcément faisable avec les politiques de sécurité réseau en vigueur dans certaines entreprises ou certains vlans. De plus RHN est une plate-forme de gestion, et dans certaines entreprises on a pas forcément envie de voir des machines du lan interne communiquer avec un portail sur internet capable de donner des ordres.
Parceque ça n'a aucun intéret face aux besoins.
Quand il faut gérer des environnements différents avec des freeze des mises à jour et des mécanismes de workflow pour les validations et approbations, ainsi que des chaînes de prototypage qui réinstallent l'OS plusieurs fois far jour sur des machines de validation, ce proxy ne sert à rien, et l'interface rhn non-plus d'ailleurs.
Pourquoi RedHat ne fournit-il pas une possibilité d'aller chercher les mises à jour directement via rsync, ... (le tout authentifié par le userid et mot de passe et ne donnant accès qu'aux canaux pour lesquels on a une licence valide) ? C'est si difficile d'offrir la même flexibilité dans l'obtention des mise à jour que Fedora, Debian, voir même Microsoft?
[^] # Re: Ah, toujours ces problèmes...
Posté par Raphaël SurcouF (site web personnel) . Évalué à 2.
Et avec quoi gères-tu donc tout ça ?
Et as-tu étudié l'offre Satellite de RHN ? Cela permet d'avoir un RHN interne qui peut gérer ton parc comme le ferait le RHN de RedHat.
Si tu n'enregistres pas toutes tes machines, comment comptes-tu réaliser (si tu les réalises) les mises à jour ?
[^] # Re: Ah, toujours ces problèmes...
Posté par ragoutoutou . Évalué à 2.
Des scripts et une intégration aux outils standards de l'entreprise...
Oui, et dans l'ensemble, elle est sans intérêt par rapport à nos besoins, spécialement vu le prix.
Dépôts yum, jobs de mise à jour en dehors des heures de production, et promotion des packages dans les canaux en fonction des environnements... rien de bien compliqué. Le seul truc un peu compliqué est la récupération des paquets pour créer les dépôts, vu que RedHat complique les choses pour pousser à l'achat de son satellite.
[^] # Re: Ah, toujours ces problèmes...
Posté par mururoa69 . Évalué à 2.
Pour les Unix propriétaires on peut facilement récupérer les mises à jour et ces mises à jour se présentent sous la forme de "service pack" qui intègrent les mises à jour de sécurité. Par exemple sous Tru64 il y a des patchs kits et ensuite on peut lister toutes les mises à jour qui sont sorties après un patch kit, choisir celles qui nous intéressent et les télécharger puis les installer aussi facilement sur les machines que l'on veut patcher.
Pour debian encore plus facile, il suffit de faire en local une copie du dépôt debian-security.
On ne peut pas, pour des raisons x,y et z, essentiellement les mêmes que celles de ragoutoudou a exposées, enregistrer tous les serveurs ( 200+ ) sur rhn, ni permettre à redhat de voir ou d'agir sur nos serveurs ni se permettre d'appliquer des niveaux de patchs differents en fonction de la date de mise à jour, ni ...
Idem pour l'utilisation du satellite.
Il faut comprendre que redhat déconnecte volontairement les mises à jour et les patch de sécurité pour des raisons essentiellement commerciales.
[^] # Re: Ah, toujours ces problèmes...
Posté par Raphaël SurcouF (site web personnel) . Évalué à 2.
Je peux comprendre les réticences face à une offre commerciale mais si tu crois que les autres éditeurs ne font pas de même en ce qui concerne les mises à jour... Sous Solaris, si tu n'es pas à jour au niveau des patchs, tu ne peux pas avoir un bon support. Il faut donc appliquer au mieux les patchs recommandés pour être « prêt » en cas de besoin.
Si le serveur n'est pas directement connecté et que les mises à jour ne sont pas essentielles aux yeux de la hiérarchie, en général, on n'y touche même pas : la question des mises à jour ne se pose donc pas (notamment dans le secteur bancaire).
[^] # Re: Ah, toujours ces problèmes...
Posté par ragoutoutou . Évalué à 2.
Pour ma part, j'ai déjà utilisé RHN en long et en large, en passant par les fonctions d'installation, de gestion de config et tout et tout.
Si c'est avec RHN, c'est clairement un serveur sous le contrôle de redhat qui donne l'ordre, même si cet ordre est demandé par l'utilisateur. Le fait d'inféoder des machines d'un réseau d'entreprise à un serveur web sur internet est un risque de sécurité non négligeable: que se passerait-il par exemple si le serveur RHN se fait hacker et commence à envoyer des ordres malveillants?
Éventuellement, si la politique réseau le permet (p-ex, le serveur a accès à un proxy), on peut envisager de faire enregistrer les machines sur rhn au moment de l'installation et de couper le lien immédiatement après et à jamais, mais ça nécessite après d'aller gérer les licences à la main dans rhn, ce qui diminue le degré d'automatisation de la tâche).
Ensuite, ce lien entre les serveurs du lan et un serveur sur internet situé aux usa peut interdit dans certains pays comme par exemple le Luxembourg où les règles de confidentialité sont très strictes quand au risque d'avoir des données consultées depuis des personnes non autorisées, à fortiori depuis l'étranger.
Bon, maintenant, il y a le satellite qui adresse peut-être ce problème, mais quand on peut faire sans RHN, pourquoi payer le satellite, surtout que celui-ci rajoute une couche de complexité sans grande valeur ajoutée.
Ceci n'est pas un scoop, et c'est valable pour tous les OS, pas juste pour solaris.
Maintenant je vais peut-être t'apprendre quelque-chose, mais en général dans une grande entreprise, on ne peut pas appliquer les patches sans passer par un processus de validation avec une escalade d'environnement de test à environnement de production (et parfois de niombreux environnements de validation entre les deux) histoire de ne pas faire courir un risque idiot aux systèmes de production.
Quoiqu'il en soit, ce n'est pas à RedHat d'imposer les méthodes de gestion ou les outils: une entreprise n'est pas l'autre et un besoin n'est pas l'autre. Que des clients de RedHat achètent le proxy ou le satellite parcequ'ils voient une valeur ajoutée dans le produit, c'est normal.
Que des clients de RedHat doivent acheter le Satellite ou le proxy parceque RadHat l'impose en rendant presque impossible le téléchargement des mises à jour dans le but de faire un miroir sois-même, c'est anormal.
Même Microsoft laisse un libre accès à ses mises à jour sécurité (il suffit de quelques wget et grep pour tout récupérer).
[^] # Re: Ah, toujours ces problèmes...
Posté par Raphaël SurcouF (site web personnel) . Évalué à 2.
Tu ne m'apprends rien. Maintenant, j'ose bien espérer que tu ne comptais pas mettre directement à jour tes serveurs en production, même avec les mises à jour de sécurité glanées sur les sites de tes chers éditeurs. Je ne vois pas ce qu'un enregistrement au RHN change là-dessus. Si tu n'as pas un minimum de confiance en ton éditeur, c'est simple : écarte-le tout de suite de ta sélection. Est-ce que tu vérifies l'authenticité des mises à jour que tu télécharges ? Si non, que RHN se fasse compromettre par un attaquant ne change rien au fait que si cela arrive également pour un autre éditeur, tu téléchargerais ses mises à jour sans te poser plus de questions que cela.
Les offres de systèmes à base de Linux ne manquent pas. Si un client n'est pas d'accord avec la manière dont c'est géré, il peut également décider d'en changer. Ils ne sont pas non plus obligés de prendre RedHat.
Le jour où wget permettra de t'assurer de l'intégrité d'un fichier, tu m'appeles.
Ce n'est pas parce que tu as pu récupérer les mises à jour de sécurité avec « quelques wget » que cela signifie que Microsoft facilite davantage la disponibilité de ses mises à jour de sécurité, de manière à en faire un miroir parce que c'est faux. Tu pallies simplement au manque en question. Pourtant, il y a également une solution chez Microsoft, cela s'appelle SUS (Software Update Services). Je suppose que tu ne t'en sers pas non plus. Pas étonnant que Slammer ait fait autant de victimes. Un serveur relié directement ou indirectement à Internet reste exposé et doit être mis à jour le plus tôt possible et pas dans 6 mois. Si l'une de ses mises à jour vient à perturber la production, retournez-vous contre l'éditeur ou arrêtez donc de prendre de contrats de support si ça ne sert à rien.
Je continue de penser que tu as fait et continue de faire un blocage complet vis-à-vis de RHN pour de mauvaises raisons. Si tu es client RH, il suffirait de te connecter au RHN pour mettre en place tes « quelques wget » pour pallier au « problème » comme tu l'as fais pour Microsoft.
[^] # Re: Ah, toujours ces problèmes...
Posté par ragoutoutou . Évalué à 2.
Bien sûr que non... on dirait que tu n'as pas lu tout ce que j'ai mis avant.
Un attaquant ne pourrait sans-doutes pas compromettre les paquets des dépôts, gâce au mécanisme de contrôle de signature. Par contre il pourrait envoyer des ordres dans la limite des fonctionnalités du client rhn.
RedHat Enterprise Linux est en sois un excellent produit, à un détail près: une politique de gestion des patchs pas très respectueuse des besoins de ses clients.
En outre, RedHat bénéficie d'un quasi-monopole dans le cadre du support de nombreuses applications tierces, ce qui le rend très difficile à remplacer.
Il n'y a pas de distribution parfaite à l'heure actuelle, et changer de distribution, en admettant qu'il existe une distribution avec autant de certifications tierces, n'améliorerait pas forcément le tableau.
Donc je compte continuer à utiliser encore longtemps RHEL (car c'est un bon produit) ET critiquer la politique d'accès aux patchs (car c'est une mauvaise politique).
Et franchement, ton attitude de "tout ce qui n'est pas fait dans le cadre de RHN est mauvais, les gens sont idiots de vouloir s'en passer quelques soient les besoins" n'est absolument pas à ton honneur. Je ne sais pas si tu bosses pour redhat (ce qui expliquerait cette défense agressive de la valeur du proxy et du satellite), mais si c'est le cas, franchement vous gagneriez à écouter un peu plus vos clients et leurs besoins.
[^] # Re: Ah, toujours ces problèmes...
Posté par Raphaël SurcouF (site web personnel) . Évalué à 2.
Ce qui me dérange, c'est que tu es prêt à dénoncer la « mauvaise » politique de mise à jour de RedHat avec RHN là où tu encenserais presque celle de Microsoft sous prétexte qu'avec « quelques wget », tu parviennes à récupérer les patchs...
Microsoft propose pourtant un produit similaire à RHN, SUS et ne fournit rien pour un miroir très facilement. Et sa politique reste de passer par Windows Update, que ce soit via SUS ou non. Et là, curieusement, on ne t'entend pas. Deux même poids, deux mesures ?
[^] # Re: Ah, toujours ces problèmes...
Posté par ragoutoutou . Évalué à 2.
Bon, faut pas tout mélanger, je ne critique pas la politique de mise à jour de RedHat mais bel et bien sa politique commerciale.
Le fait est que chaque fournisseur peut avoir son outil de mise à jour, adapté ou non aux besoins. Je peux parfaitement comprendre qu'une entreprise n'est pas l'autre et qu'une seule taille ne peut aller à tout le monde. Maintenant ce que je reproches c'est cette attitude qui vise à pousser le client vers cet outil de mise à jour, adapté ou pas, bloquant les méthodes plus traditionnelles, pourtant plus simples à adapter aux besoins, apparemment dans le but de maximiser leurs ventes.
Si encore RedHat offrait gratuitement le satellite pour tout achat de 100 licences, je dirais pas, mais là, c'est juste du forçage de main.
La politique est certes de passer par windows update, mais elle aisément contournable si on lis la doc technet. Et les outils de patch management tels que SUS sont gratuits (si tu es en règle au niveau licence OS), contrairement au proxy et au satellite.
[^] # Et donc ?
Posté par mururoa69 . Évalué à 1.
A part le cas par cas ( fichier par fichier ), attendre la prochaine update qui integre aussi les patch de sécurité si je ne me plante pas et utiliser les outils de redhat il n'y a pas de solution ?
Et concernant CentOS, ils integrent les mises à jour de sécurité dans leurs updates standard ou pas ?
[^] # Re: Et donc ?
Posté par Nils Ratusznik (site web personnel, Mastodon) . Évalué à 1.
Sinon, pour récupérer les mises à jour RHEL, installer une machine récupérant toutes les mises à jour (quitte à installer trois fois trop de logiciels pour déclencher leur mise à jour) et ensuite créer des mirroirs yum en local me semble être une option viable. Je ne sais pas si up2date possède une option qui permet de ne faire que télécharger les mises à jour, ou de ne pas vider le cache de téléchargement, mais j'ose espérer que oui.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.