Pour RHN, j'ai l'impression que vous ne l'avez jamais utilisé tellement il y a une idée préconçue à ce sujet.
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.
Que ce soit la liaison avec RHN soit directe ou via un Satellite, ce n'est pas RedHat qui décide de manière unilatérale des mises à jour mais le client
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.
Sous Solaris, si tu n'es pas à jour au niveau des patchs, tu ne peux pas avoir un bon support.
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 ragoutoutou . En réponse au message Recuperer tous les updates security. É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).