Red Hat lance RHEL 5

Posté par  (site web personnel, Mastodon) . Modéré par Nÿco.
Étiquettes :
0
14
mar.
2007
Red Hat
Red Hat lance ce 14 mars la nouvelle version de sa distribution commerciale destinée aux professionnels et aux entreprises : Red Hat Enterprise Linux 5. Cela aura pris plus de temps que prévu, mais c'est là, avec de nouveaux produits et services de la part de la célèbre marque au chapeau rouge.

Le retard de la RHEL 5 s'explique principalement à cause de l'intégration de Xen, ce qui a forcé Red Hat à repousser son calendrier de fin 2006 à fin février, puis mi-mars. Il aura fallu au total plus de deux ans de développement pour y arriver, passant entre autres du noyau 2.6.9 au 2.6.18.

Parmi les nouveautés de cette nouvelle mouture, on trouvera :
  • Intégration de Xen, la célèbre solution de virtualisation ;
  • Une version intégrée de Red Hat Cluster Suite, permettant de construire des clusters haute disponibilité (HA);
  • Support de l'iSCSI, un protocole permettant le transport de commandes SCSI sur un réseau TCP/IP ;
  • Support d'InfiniBand, un bus système à haut débit qu'on pourrait mettre en concurrence avec PCI-Express ;
  • SystemTap, un outil de diagnostic noyau ;
  • Support des processeurs 64 bits quadri-coeurs ;
  • Frysk, un outil pour monitorer et déboguer des applications
Red Hat a noué des partenariats avec IBM, Intel et Hitachi pour le développement.

Aller plus loin

  • # Re:

    Posté par  . Évalué à 8.

    > Red Hat a noué des partenariats avec IBM, Intel et Hitachi pour le développement.

    Et AMD.

    M'enfin, Red Hat a une tripotée de partenaires. Dont Oracle :-)
    Notons que le nombre d'applis pour Redhat qui sont certifiées "explose". On est maintenant à près de 3000.

    J'ai regardé le webcast de la sortie de RHEL 5. Il n'y a pas un mot sur le desktop !
    Je ne parle pas du desktop en entreprise qui est peu abordé.
    C'est serveur, virtualisation, serveur, virtualisation, serveur, développement, java, Jboss, Fedora, innovation, communauté du libre, Eclipse, virtualisation, déploiement, ouverture, souplesse, etc. Mais jamais desktop.

    Je pensais qu'il y aurait un petit frémissement d'intérêt de ce côté de la part de Red Hat, ben nada. C'est que dédié entreprise. Ce n'est pas un reproche, c'est un constat.

    > Le retard de la RHEL 5 s'explique principalement à cause de l'intégration de Xen

    Je crois qu'il n'y a pas que ça pour expliquer le retard.
    Red Hat a, semble-t-il au dernier moment, décidé d'ajouter la paravirtuaisation à RHEL 4 et que ce soit dispo à la sortie de RHEL 5 (NB : RHEL 4 est basé sur un 2.6.9 et doit resté compatible binaire et source). Enfin Red Hat a ajouté GFS pour RHEL 5 Advanced Plateforme. En général GFS sortait avec quelques semaines de retard. Il y a GFS 1 et GFS 2 (GFS 2 : considéré en preview au moment de la sortie de RHEL 5).

    • [^] # Re: Re:

      Posté par  . Évalué à 2.

      > J'ai regardé le webcast de la sortie de RHEL 5. Il n'y a pas un mot sur le desktop !

      Mais bonne nouvelle, on peut maintenant acheter du RHEL 5 desktop à l'unité (ce qui n'était pas le cas pour RHEL 4).
      http://www.europe.redhat.com/rhel/desktop/compare/
      Prix : de 80 $ à 219 $ par an (basic support).
      Intéressant.
      Pour 219 $ on a tout sauf quelques trucs pointus (cluster, gfs). Mais il y a les applis serveurs, virtualisation (nombre de guest illimité), développement, etc...
      C'est limité à deux socket/cpu. Limité le mot est un peu fort. C'est utilisable avec un bi-quadruple-coeur.

      Globalement les prix ont significativement baissé entre RHEL 4 et 5.

    • [^] # Re: Re:

      Posté par  (site web personnel) . Évalué à 2.

      J'ai regardé le webcast de la sortie de RHEL 5. Il n'y a pas un mot sur le desktop !
      Je ne parle pas du desktop en entreprise qui est peu abordé.
      C'est serveur, virtualisation, serveur, virtualisation, serveur, développement, java, Jboss, Fedora, innovation, communauté du libre, Eclipse, virtualisation, déploiement, ouverture, souplesse, etc. Mais jamais desktop.

      D'ailleurs dans RHN seules les 5 images ISO "Server" ont l'air d'être disponibles.

      • [^] # Re: Re:

        Posté par  . Évalué à 3.

        bizzare... moi j'ai les iso "desktop" disponibles dans rhn...

        Le nom du canal est "Red Hat Enterprise Linux Desktop (v. 5 for 32-bit x86)" (pour le version 32bit)

      • [^] # Re: Re:

        Posté par  . Évalué à 2.

        Si t'as un abonnement pour serveur, ça peut-être normal. Red Hat ne va pas te vendre la version desktop pour le prix de la version serveur.

        • [^] # Re: Re:

          Posté par  . Évalué à 1.

          C'est vrai. Ce n'est pas comme Microsoft, avec Windows NT.
          Ah non ! C'est différent, me dit-on. Microsoft, lui, vendait le même produit à des prix différents. Il suffisait juste de modifier des clés dans la base de registre pour transformer un "Windows NT Workstation" en "Windows NT Server".
          http://www.virus.ldh.org/num_01/pages/page27.html

  • # fin de libpthreads

    Posté par  . Évalué à 4.

    On pourra aussi noter la fin des anciennes libpthreads.

    Terminé les programmes développés par des fainéants qui comptaient sur des LD_ASSUME_KERNEL=2.4.18 à gogo et qui donnaient comme excuse quand on leur disait que c'était dépassé (même déconseillé) "Oui mais nous on se base sur la RedHat enterprise" quand on leur disait que leur merdasse refusait de marcher (pour Fedora depuis la FC5).

    Oui j'en ai quelques exemples bien énervants.

    • [^] # Re: fin de libpthreads

      Posté par  . Évalué à 2.

      > "Oui mais nous on se base sur la RedHat enterprise"

      Ben ils utilisent RHEL 4 pour encore 5 années. Autre choses, RHEL 5 offre de la virtualisation (et même de la paravirtualisation). Donc on peut faire tourner du RHEL 4 dans du RHEL 5 (sans compter la possibilité du chroot, ça marche pour linuxthread).

      Pour RHEL 4 c'était et c'est :
      - NPTL supporté
      - linuxthread supporté mais obsolete

      C'était annoncé à la sortie de RHEL 4 il y a plus de deux ans. On savait déjà qu'il n'y aurait pas linuxthread dans RHEL 5.

      • [^] # Re: fin de libpthreads

        Posté par  . Évalué à 2.

        Pour info, NPTL a été introduit dans RHEL 3. Donc il y a RHEL 3 et 4 qui supportent en parallèle NPTL et linuxthread.

        J'ai remis la main sur la release note de RHEL 4 :
        While support for LinuxThreads still exists for Red Hat Enterprise
        Linux 4, this statement serves as advance notice that Red Hat
        Enterprise Linux 5 will no longer include support for LinuxThreads.
        Therefore, applications that require LinuxThreads support must be
        updated before they will be able to work properly on a Red Hat
        Enterprise Linux 5 system.

        • [^] # Re: fin de libpthreads

          Posté par  (site web personnel) . Évalué à 4.

          Tant pis si je passe pour un idiot, mais on pourrait me donner un exemple de code linuxthreads et NTPL pour voir la différence ?
          (que je la comprenne par l'exemple)

          ps : je refuse pas une explication historique et de ce que c'est un peu plus complète (a part linuxthreads ça pue et consort svp)

          • [^] # Re: fin de libpthreads

            Posté par  . Évalué à 3.

            > Tant pis si je passe pour un idiot, mais on pourrait me donner un exemple de code linuxthreads et NTPL pour voir la différence ?

            Linuxthread et NPTL se veulent conforme Posix. Donc il n'y a pas de grosses différences. La grosse différence au niveau programmation est dans la gestion des signaux.

        • [^] # Re: fin de libpthreads

          Posté par  . Évalué à 2.

          Oui, c'est cela qui m'énerve d'autant plus , c'était largement annoncé et il a fallu que les éditeurs du soft en question se trouvent le nez dans le mur pour réagir.
          C'est moi qui leur ait appri il y quelque chose comme 2 mois quand nous avons passé certains postes en FC6 que cela faisait 2 ans que l'obsolescence était annoncée.

  • # Re:

    Posté par  . Évalué à 6.

    Un test en "avant première" et mini-interviews de développeur Red Hat/Fedora :
    http://www.linuxformat.co.uk/modules.php?op=modload&name(...)

    Fait sur un double quadruple coeur.
    Là n'est pas l'intérêt de l'article.
    You remember reading that Advanced Platform allows you unlimited Xen guests? Well, as part of your subscription to RHEL Advanced Platform you get access to unlimited Xen guest updates for RHEL. Go back and read that again,
    The second announcement is of the direct application of open source principles to Red Hat's business.
    Point important. C'est Havoc qui avait lancé cette idée. Il y a le logiciel libre, il devrait y avoir l'entreprise libre ou du moins ouverte/transparente.
    Specifically, the company intends to adopt the principles of transparency of open source software, the sharing of knowledge common to all, and the collaboration between community members.
    [...]
    RHEL 4 had a seven-page SLA, while Novell is rumoured to have a 36-page SLA in place. To cut through all the crap, Red Hat has produced a one-page SLA that clearly states what it does and doesn't support - in large letters to boot!

    L'accord MS/Novell :
    The fact that Microsoft and Novell have agreed to work together has changed nothing for us. In fact, Red Hat have hired the remaining members of the Samba from Novell.
    Marrant car dans le webcast RHEL5, Red Hat a deux ou trois fois indiqué qu'ils avaient beaucoup de développeurs Samba :-)

    • [^] # Re: Re:

      Posté par  . Évalué à 3.

      Point important. C'est Havoc qui avait lancé cette idée. Il y a le logiciel libre, il devrait y avoir l'entreprise libre ou du moins ouverte/transparente.

      Oui, disons plutôt « ouverte ». Parce que le logiciel, il est dit libre car il a été libéré des contraintes de la propriété intellectuelle [1], alors si on libère une entreprise des contraintes de la propriété tout court, on va encore se faire accuser de communisme, et j'avoue que là il y aura de quoi ;).




      [1] Je sais, l'auteur conserve toujours tous ses droits, mais la branche, l'instance ou la version (je ne sais pas trop comment l'appeler) du logiciel copylefté restera à jamais libre des monopoles de représentation et de reproduction.

  • # Infiniband

    Posté par  . Évalué à 6.

    Support d'InfiniBand, un bus système à haut débit qu'on pourrait mettre en concurrence avec PCI-Express ;


    Disons que lorsque Infiniband a été crée il était peut-être sensé être en concurence avec PCI-Express mais aujourd'hui Infiniband est un type de réseau (comme ethernet).

    Ce réseau a comme caractèristique d'avoir un haut débit (10Gb/s) et une très faible latence. Cela le rend très adapté comme réseau d'interconnect pour les clusters de calcul (des versions de MPI sachant l'utiliser existent).

    Si il faut vraiment le mettre en concurence avec quelque chose on peut citer Myrinet, Quadrics ou NUMALink.

    Et les cartes Infiniband sont en général des cartes PCI-Express.

    Je me rend compte que la confusion vient probablement de wikipedia:fr, faudrait vraiment changer cet article pour qu'il ressemble plus a la version en.

    • [^] # Commentaire supprimé

      Posté par  . Évalué à 2.

      Ce commentaire a été supprimé par l’équipe de modération.

      • [^] # Re: Infiniband

        Posté par  . Évalué à 2.

        Disons que c'est un axe de développement actuel d'Infiniband de faire passer du SCSI dessus, ce qui le pose en effet en concurrent du Fibre Channel.

        Mais j'ai l'impression que la techno a encore a faire ses preuves dans le domaine alors qu'en tant qu'interconnect pour le calcul elle est très reconnue.

    • [^] # Re: Infiniband

      Posté par  . Évalué à 3.

      en parlant d'infiniband, est-ce que les cartes infiniband ne sont disponibles qu'à travers un prestataire, ou existe-il des magasins où je pourrais personnellement en acheter ?

  • # Ca mere!

    Posté par  (site web personnel) . Évalué à 4.

    >Support de l'iSCSI, un protocole permettant le transport de commandes
    >SCSI sur un réseau TCP/IP ;

    Et alors la je demande à tous les redhateux du coin, ca utilise openiscisi?

    Parce que chez Hitachi, on a eu droit dernierement au beau discour: "oui, mais on connait que linux-iscsi (projet mort) et si debian n'utilise pas ca, on sera pas comment faire fonctionner notre matos"...

    Et comme la boite ne supporte que RedHat, le passage de redhat à openiscsi pourrait me donner de bon argument pour qu'ils trouvent comment faire fonctionner leur matos sous Debian....

    Voila, merci ;)

    • [^] # Re: Ca mere!

      Posté par  (site web personnel) . Évalué à 3.

      iSCSI, c'est le truc qui permet de rendre les SAN abordables, c'est ça ? Et ce truc ne marche pas aussi sur les autres distribs ?

      • [^] # Re: Ca mere!

        Posté par  (site web personnel) . Évalué à 3.

        Mais ca fonctionne sur toutes les distrib openiscsi...

        Sauf que la, avec une baie WMS100, impossible de lancer le "discover".

      • [^] # Re: Ca mere!

        Posté par  . Évalué à 5.

        iSCSI, c'est le truc qui permet de rendre les SAN abordables, c'est ça ?


        Oui, c'est un protocole transportant le scsi sur tcp/ip, donc contrairement à l'ATAOe, c'est implémentable avec une infrastructure réseau complexe.

        Et ce truc ne marche pas aussi sur les autres distribs ?


        Oui, mais ce n'est généralement pas intégré... il faut souvent recompiler...

        • [^] # Re: Ca mere!

          Posté par  . Évalué à 1.

          A ce sujet je dois choisir entre ISCSI ou AoE pour déporter l'unité de stockage des serveurs. Dans le cadre d'un réseau simple quelqu'un a une comparaison au sujet des 2 technos? Perfs toussa?

          • [^] # Re: Ca mere!

            Posté par  . Évalué à 4.

            En fait, AoE nécessite une connexion directe vu que ce sont des paquets ethernet non routables. Si tu as plusieurs vlans et que tu dois mettre un routeur entre ton serveur et ton san, AoE est hors de question.

            iScsi, de son côté, permet de mettre des routeurs entre le san et le client.

            En gros,

            AoE bouffe moins de cpu

            iSCSI est plus flexible

            ...

            Et avec du hardware san iSCSI, l'os dialogue directement avec de vrais disques qui reçoivent les commandes scsi sans transformations.

  • # Un peu de com/marketing

    Posté par  . Évalué à 4.

    Red Hat :
    http://www.redhat.com/videos/real_tech/
    Novell :
    http://www.novell.com/linux/demos/sles_main.swf

    La forme est très différente.

  • # Demo Xen

    Posté par  . Évalué à 3.

    En arrivant sur la page de démo :
    Please register to view this demo. After registration - the demo will display below

    putain l'angoisse !!

  • # La doc est en ligne

    Posté par  . Évalué à 2.

    http://www.redhat.com/docs/manuals/enterprise/
    On y trouve entre autres la note de mise à jour.
    C'est aussi une excellente source d'information pour les utilisateurs de GNU/Linux et plus spécifiquement de Fedora.
    Malheureusement la version française n'est pas en ligne et Red Hat semble être à la bourre (il n'y a pas de version pdf par exemple).

  • # CentOS est dispo aussi en beta

    Posté par  . Évalué à 5.

    Plus d'info ici : http://lists.centos.org/pipermail/centos-announce/2007-March(...) . Par contre, ils sont bien gentils Red Hat, mais je suis confronté à l'infâme bug expliqué sur leur propre doc ici : http://www.redhat.com/docs/manuals/enterprise/RHEL-5-manual/(...)
    Systems with SATA controllers may pause during the boot process, displaying the following error message: 
    ata2: port is slow to respond, please be patient
    Afterwards, the following error message appears: 
    ata2: reset failed, giving up
    Note that after the second error message, the system will continue the normal boot process. Other than the delay, there is no impact to the system; as long as the SATA drives are physically present they will still be detected properly.
    Loin d'être aussi bénin qu'il parait (juste une lenteur de 2 à 3 minutes), il ne me permet tout simplement pas d'installer la distribution car le lecteur CD n'est plus détecté. C'est quand même balot, non ? Bug qui existe sur Fedora Core 6 et donc Red Hat 5. Par contre, sur Slackware, Mandriva, Ubuntu, pas de problème particulier. D'après ce que j'ai lu, SUSE n'est pas non plus touchée. Quelqu'un aurait un indice pour que je puisse installer et booter sans perdre 3 minutes à chaque démarrage ?

    • [^] # Re: CentOS est dispo aussi en beta

      Posté par  . Évalué à 4.

      > Par contre, sur Slackware, Mandriva, Ubuntu, pas de problème particulier. D'après ce que j'ai lu, SUSE n'est pas non plus touchée

      Mandriva, Ubuntu 6.10 utilise un 2.6.17, Slackware un 2.4.x.

      Sinon Red Hat/Fedora utilise un nouvel ensemble (libata) pour ide/scsi. Développement de l'ensemble dirigé principalement par Alan Cox et maintenant en upstream (2.6.18?). A ma connaissance il n'y a que Red Hat et Fedora qui l'active par défaut. Les autres utilisent l'ancien système et attendent que Red Hat le débuggue et se fasse maudire par les utilisateurs avant qu'ils l'adoptent aussi...

      Il y a peut-être des bugs pour toi, mais ça doit débloquer d'autres personnes. Le passage à libata (et son développement) n'a pas été faire pour rien et doit avoir des bénéfices. On ne fait pas d'omelette sans casser des oeufs, malheureusement.

      > Quelqu'un aurait un indice pour que je puisse installer et booter sans perdre 3 minutes à chaque démarrage ?

      Pas moi. Demande à Centos de corriger le bug :-)
      https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=211211

  • # Mises à jour... Pire que Microsoft?

    Posté par  . Évalué à 1.

    ... très énervant, alors que sous rehat 4, il était encore possible de télécharger les mises à jour et packages sans les installer avec "up2date get", sous Redhat5, cette cochonnerie de yum est incapable de faire un --downloadonly (à moins que je n'ai raté une subtilité)

    Tout ça pour forcer la main des clients pour qu'ils achètent Rnh satellite...

    • [^] # Re: Mises à jour... Pire que Microsoft?

      Posté par  . Évalué à 3.

      Avec des titres comme ça, ça va aider le libre.

      > Tout ça pour forcer la main des clients pour qu'ils achètent Rnh satellite...

      Sans le moindre doute.

      Tu devrais en faire une news (oublie de dire que tu peux downloader les paquets directement depuis http://rhn.redhat.com/).

      > Pire que Microsoft?

      Au fait, comment tu fais pour downloader un paquet MS ? Je n'ai pas trouvé.

      > sous Redhat5, cette cochonnerie de yum est incapable de faire un --downloadonly

      Non, il n'y a pas. Mais tu peux porter yum-utils pour RHEL5. Il y aura bientôt un RHEL Extras.

      NB : Red Hat a changé sa politique de support. Avant Red Hat ne supportait pas tous les paquets fournis (il y avait quelques exceptions dont le populaire kernel-modules-unsupported). Maintenant tout est supporté (sauf ce qui est "technologie preview").

      Pourquoi tu veux les paquets binaires ? Pourquoi cette éxigence ? Si de temps à autre tu veux un paquet binaire, direction => http://rhn.redhat.com/ .

      Si tu les veux systématiquement, à part faire un truc qui n'est pas en accord avec le support de RedHat, je ne vois pas ce que tu veux faire.

      NB : je n'ai pas dit que c'était illégal car il est tout à fait légal de copier une RHEL (sauf que Red Hat peut alors refuser de donner du support).

      • [^] # Re: Mises à jour... Pire que Microsoft?

        Posté par  . Évalué à 3.

        Pourquoi tu veux les paquets binaires ? Pourquoi cette éxigence ?


        - Parceque RedHat Network n'est pas adapté aux besoins de l'entreprise pour laquelle je travaille, que pour certains éléments il est carrément contraire aux polices de sécurité, et qu'il faut tout de même une méthode de distribution des hotfixes convenable quand on a un grand parc de serveurs avec des environnements différents ainsi qu'une compartimentation réseau.

        - Parceque Rhel5 est une baisse de fonctionnalités à ce niveau par rapport à RedHat4.

        - Parceque le contrat de support entre redhat et la société pour laquelle je bosse est de plusieurs dizaines de millieurs d'euros, et vu le prix unitaire de la license, ce serait sympa de traiter les clients un peu mieux.

        Au fait, comment tu fais pour downloader un paquet MS ? Je n'ai pas trouvé.


        Paquet, non, hotfix oui... et c'est facilement automatisable (si on ne veut pas utiliser WSUS, WUS, ... )

        • [^] # Re: Mises à jour... Pire que Microsoft?

          Posté par  . Évalué à 1.

          > - Parceque RedHat Network n'est pas adapté aux besoins de l'entreprise pour laquelle je travaille, que pour certains éléments il est carrément contraire aux polices de sécurité, et qu'il faut tout de même une méthode de distribution des hotfixes convenable quand on a un grand parc de serveurs avec des environnements différents ainsi qu'une compartimentation réseau.

          Mouaif. Mouaif car tu fais quoi avec "yum --downloadonly" ?
          Tu utilises rhn, donc tu dépends de rhn. Tu peux tout autant aller sur http://rhn.redhat.com/ . Puis c'est pas sorcier de mettre en place un firewall qui ne laisse passer que le protocol rhn en sortant.
          Donc je ne vois pas bien le rapport avec ton propos.

          > - Parceque Rhel5 est une baisse de fonctionnalités à ce niveau par rapport à RedHat4.

          Oui. Essaie d'installer yum-utils.
          Le src.rpm de fc6 (doit probalement se "compiler" sans problème sur RHEL 5) :
          http://fr2.rpmfind.net/linux/fedora/extras/6/SRPMS/yum-utils(...)
          Tu trouveras sans difficulté la version "noarch.rpm" si tu ne veux pas compiler.

          Notes que RHEL passe de up2date (qui sous RHEL4 ne savait communiquer qu'avec rhn) à yum. Donc il n'y a pas qu'une perte de fonctionnalité dans le passage de up2date à yum. Il y a aussi un gain évident pour le client (pas évident pour Red Hat).

          > - Parceque le contrat de support entre redhat et la société pour laquelle je bosse est de plusieurs dizaines de millieurs d'euros, et vu le prix unitaire de la license, ce serait sympa de traiter les clients un peu mieux.

          Certes. Mais as-tu contacté Red Hat avant de venir "gueuler" ici ? Si tu payes "plusieurs dizaines de millieurs d'euros" tu devrais faire ça en premier. C'est évident, c'est ce que j'aurai fait en premier (après évidemment avoir vérifier que RHEL 5 ne fournit pas la fonctionnalité) !
          Je suis convaincu qu'il y aura yum-utils dans pas longtemps pour RHEL 5.
          http://fedoraproject.org/wiki/EPEL.

          Notes que c'est un projet sous le chapeau de Red Hat. Que ça fait partit de la "stratégie" RHEL. Si Red Hat voulais "embrigader" les utilisateurs de RHEL 5, il n'y aurait pas EPEL. Dis nous si Red Hat va interdire yum-utils dans EPEL.

          Donc ton "Tout ça pour forcer la main des clients pour qu'ils achètent Rnh satellite..." je le trouve assez méprisant et basé sur presque rien.

          • [^] # Re: Mises à jour... Pire que Microsoft?

            Posté par  . Évalué à 3.

            Mouaif. Mouaif car tu fais quoi avec "yum --downloadonly" ?


            Alimenter un workflow qui s'intègre dans les procédures de test et de validation pour alimenter une repository sur le lan.

            Tu peux tout autant aller sur http://rhn.redhat.com/


            opération manuelle, une opération automatisée est plus souhaitable pour notifier les paquets à faire valider et par qui, ainsi que de préparer les machines de test.

            Puis c'est pas sorcier de mettre en place un firewall qui ne laisse passer que le protocol rhn en sortant.


            Ce n'est pas une question de firewall, c'est le fait d'enregistrer des machines internes sur un site web à l'aide d'un client qui peut recevoir des ordres depuis ledit site web. Le firewall filtre les protocoles, pas les contenus ou la pertinence des informations retournées via un protocole licite. De plus, ça passe de toutes façons via un proxy, pas de connexions directes au web autorisées...

            Certes. Mais as-tu contacté Red Hat avant de venir "gueuler" ici ? Si tu payes "plusieurs dizaines de millieurs d'euros" tu devrais faire ça en premier.


            C'est en cours, mais je ne vais pas me priver de dire ce que je pense sur les forums pour autant...

            Maintenant, c'est vrai que quand on n'a pas des masses de serveurs et pas toute une série de contraintes administratives et sécuritaires, la disparition du "download only" ne doit pas être une grosse perte.

            En attendant, le plugin rhn pour yum est assez intéressant à lire et à modifier...

            • [^] # Re: Mises à jour... Pire que Microsoft?

              Posté par  . Évalué à 2.

              > C'est en cours, mais je ne vais pas me priver de dire ce que je pense sur les forums pour autant...

              OK, mais un peu de réflexion avant la parole ne fait pas de mal :-)

              > En attendant, le plugin rhn pour yum est assez intéressant à lire et à modifier...

              C'est aussi pour ça qu'il faut prendre du logiciel libre :-)

              Ce n'est pas facile à intégrer, mais si tu bosses souvent avec RHEL, je te conseille de t'abonner aux mailings beta (malheureusement la mailing beta de RHEL 5 n'a plus cours). Tu y seras en contact directement avec les développeurs de RHEL et ils sont assez réactifs à toute remarque d'un client. Non qu'ils répondent à tous les voeux, mais au moins tu sais de quoi il en retourne.

              • [^] # Re: Mises à jour... Pire que Microsoft?

                Posté par  . Évalué à 2.

                OK, mais un peu de réflexion avant la parole ne fait pas de mal :-)


                Oui, mais déjà une journée de perdue sur la validation de la plateforme à cause de ça... ça reste énervant... je trouve que mettre et up2date et yum dans rhes5 aurait été plus respectueux du client... Le client qui suit naïvement ce que RedHat offre et reprend est bon pour convertir tous ses scripts de déploiement.

                • [^] # Re: Mises à jour... Pire que Microsoft?

                  Posté par  . Évalué à 2.

                  > je trouve que mettre et up2date et yum dans rhes5 aurait été plus respectueux du client...

                  Argument "valide". La "mise à la poubelle" de up2date a été connue que depuis la beta1 de RHEL5.

              • [^] # Re: Mises à jour... Pire que Microsoft?

                Posté par  . Évalué à 2.

                C'est aussi pour ça qu'il faut prendre du logiciel libre :-)


                Pour info, j'ai terminé les grandes lignes de mon script de téléchargement, il permet de télécharger tous les canaux rhn auquel un serveur rh5 est abonné, séquentiellement, avec contrôle des checksums (je vais envisager la vérification gpg), et sans retélécharger les fichiers déjà présents dans le miroir. Le script utilise les librairies de rhn et de yam.

                Je vais en parler avec le tam de rh, et si ça ne pose pas problème, je le partagerai...

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.