Red Hat Enterprise Linux 5.4 : une rentrée pleine d'avant-premières technologiques

Posté par  (site web personnel, Mastodon) . Modéré par patrick_g.
Étiquettes :
30
3
sept.
2009
Red Hat
Red Hat a annoncé ce 2 septembre la version 5.4 de Red Hat Enterprise Linux (RHEL), distribution commerciale destinée aux professionnels et aux entreprises. Il s'agit d'une version mineure, qui permet d'améliorer l'existant sans casser la compatibilité avec les précédentes versions, particularité qui a été très soulignée dans l'annonce de Red Hat.

Quelques-unes des améliorations et correctifs apportés par cette nouvelle version sont détaillés dans la suite de la dépêche. Virtualisation
Comme à chaque mise à jour, Red Hat ajoute des fonctionnalités en virtualisation et RHEL 5.4 voit arriver un gros changement : l'apparition de l'hyperviseur KVM. Red Hat rappelle qu'il n'est possible d'utiliser qu'un seul hyperviseur à la fois, il faudra donc choisir, KVM ou Xen, mais Red Hat supporte les deux officiellement. Un bémol toutefois, l'« USB passthrough », possibilité d'allouer des ports USB à une machine virtuelle et donc d'utiliser des périphériques USB directement dans celle-ci, n'est présent qu'à titre d'avant-première technologique. Le paquet etherboot a été ajouté pour donner la possibilité de démarrer des machines virtuelles KVM en utilisant PXE. La fonctionnalité etherboot est limitée à cet usage uniquement.

Xen n'est pas en reste : la possibilité pour une machine virtuelle x86_32 para-virtualisée de fonctionner sur un hyperviseur x86_64 n'est plus une avant-première technologique, mais une fonctionnalité totalement supportée.

Il est dorénavant possible pour un hyperviseur de posséder 192 processeurs physiques (contre 126 en RHEL 5.3 et 64 en RHEL 5.2)

Prise en charge du matériel
Le pilote i2c a été mis à jour afin de prendre en charge la gamme AMD SB800, ainsi que la puce Broadcom HT1100. Notons aussi la mise à jour du pilote hpilo. À noter que Red Hat ne peut plus maintenir le pilote ipw3945 pour les cartes réseau sans fil car le constructeur des puces 3945 ne maintient plus ce pilote. Le pilote iwl3945 a donc été ajouté dans RHEL 5.3, et c'est donc celui-ci qui est mis à jour dans RHEL 5.4. Le pilote ipw3945 reste présent pour faciliter les migrations.

Cluster et stockage de données
Les outils de Cluster Suite ont été mis à jour pour détecter les hyperviseurs KVM, mais l'utilisation de Cluster Suite et de KVM conjointe n'est présente qu'à titre d'avant-première technologique (oui, encore...). D'autres ajouts concernent l'utilisation de Cluster Suite avec VMware ESX : des améliorations dans le « fencing », technique permettant de déconnecter un nœud du cluster en cas de problème, ce qui permet d'éviter la corruption de données sur les partages (GFS/GFS2 par exemple).

Côté stockage, c'est FUSE qui débarque dans RHEL, comprenant modules noyau et utilitaires. XFS et ext4 sont maintenant ajoutés dans le noyau officiel (mais encore en avant-première technologique). Notons dans les autres mises à jour Samba : Red Hat propose Samba 3.3 (oui, encore en avant-première technologique), qu'il convient d'installer plutôt que de l'utiliser en mise à jour de Samba 3.0.

Réseau
Le Generic Receive Offload (GRO) a été implémenté dans le noyau ainsi que dans l'outil ethtool. GRO permet de limiter l'utilisation du processeur en implémentant la même technique que le Large Receive Offload (LRO), mais appliqué à plus de couches de transport. GRO a aussi été ajouté dans plusieurs pilotes réseau, comme ceux des cartes Intel Gigabit 10 Gigabit. Netfilter s'est vu ajouter les valeurs Differentiated Services Code Point (DSCP). Côté DNS, bind est mis à jour pour mieux faire la différence entre les réponses autoritaires et non-autoritaires avec l'option allow-query-cache qui en contrôle l'accès.

Utilisation sur ordinateur de bureau et portable
ALSA a été mis à jour, pour mieux gérer High Definition Audio (HDA). Quelques pilotes graphiques ont aussi été revus : ati, i810 et intel, mga (pour les cartes Matrox) et nv (nVidia). Pour les ordinateurs portables, il est à présent possible d'utiliser un dock contenant un lecteur optique sans avoir à redémarrer, grâce à une mise à jour des pilotes ACPI pour le dock.

Diagnostic et outils système
SystemTap a été mis à jour pour être basée sur la dernière version officielle. GCC 4.4 est présent, devinez à quel titre ;)

Documentation
RHEL 5.4 a bénéficié d'un peu de ménage dans les documentations, les notes de versions (Release Notes) seront moins détaillées et les détails iront dans des notes techniques (Technical Notes). Le contenu technique de l'annonce est revu à la baisse et a bénéficié d'un gros paragraphe sur la compatibilité ascendante. Les lecteurs avides de nouveautés supplémentaires iront donc voir les notes techniques, qui contiennent encore plus d'informations que cet article.

Aller plus loin

  • # nostra

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

    /*mode nostradamus*/
    Deux éléments semblent se confirmer de plus en plus :

    1) la 5 va faire "court feu" : la Redhat 6 arrivera rapidement (plus rapidement que le calendrier 'officieux/clients' publié lors de l'update 6 de la rhel4). La 5 fait office d'avant première technologique et est fortement destinée aux laptops et stations de travail "ordinaires". D'où également l'arborescence particulière de 5 (Client, Workstation et VT, départageant de manière nouvelle les 'dépôts' présent sur les galettes), d'où aussi le calendrier (toujours 'officieux/clients" d'une sortie de la 6 pour le printemps 2010)

    2) Redhat a faim, très faim. Et souhaite à priori fortement étendre son activité bien sûr en continuant les serveurs et les stations de travail, mais aussi maintenant en s'occupant de postes plus ordinaires.

    Bref deux bonnes nouvelles :)
    Vont ils proposer une gamme 6 "Client" taillée genre "agence Elite" ? En plus, tout en continuant, la politique -de réussite' de la 4, appliquée à une autre 6 ?

    /*mode nostradamus*/

    (et merci pour la dépêche)
    • [^] # Re: nostra

      Posté par  . Évalué à 4.

      Nostradamus n'est pas en forme.

      1) la 5 va faire "court feu"

      Pas sûr du tout (et on dit "faire long feu").
      Il faut remarquer que la nouvelle stratégie de Red Hat pour la virtualisation (qui est une 'grosse affaire' sans vouloir rentrer dans les détails) est appliquée avec RHEL 5 et pas avec RHEL 6.
      Des évolutions majeurs et critiquent comme le passage à ext4 se trouvent aussi dans RHEL 5. KVM a été intégré à RHEL 5 et est la virtualisation par défaut.
      Donc il est bien probable que RHEL 6 va se fasse désirer.

      D'où également l'arborescence particulière de 5

      Ce n'est pas nouveau, c'est comme ça depuis la sortie de RHEL 5. En passant, ces deux branche sont à 99,999 % identiques et il n'y a que ce qui est lié à la sélection des paquets qui change.

      d'où aussi le calendrier (toujours 'officieux/clients" d'une sortie de la 6 pour le printemps 2010)

      Je pense que ça sera (encore) repoussé. RHEL 6 devait être basé sur F9, puis F10, puis F11, puis F12, je ne crois pas qu'elle sera basée sur F13 ni F14.
      Je voix bien Red Hat attendre la sortie de Gnome 3 (+ quelques mois).
      • [^] # Re: nostra

        Posté par  . Évalué à 10.

        Juste une réflexion / avis personnel relatif à Gnome 3:

        - Redhat s'en moque de Gnome, KDE, ou autre gestionnaire de fenêtre... là où RedHat gagne du fric, c'est sur les serveurs... et là -> on s'en fout du WM -> on l'installe même pas !!!
        • [^] # Re: nostra

          Posté par  . Évalué à 5.

          Par curiosité y'a les chiffres quelque part de l'utilisation serveur/poste de travail ?
        • [^] # Re: nostra

          Posté par  . Évalué à 2.

          Oui et non.
          Passer de Gnome 2 à Gnome 3 est un changement d'API et peut justifier une version majeur de RHEL.
          Par contre, passer de Xen à KVM ou ajouter ext4 à RHEL 5 ne change pas grand chose.
          N'oublions pas que Red Hat garantit la compatibilité source et BINAIRE pour toutes les RHEL 5.x, mais Red Hat ne le fait pas entre version majeur de RHEL.
        • [^] # Re: nostra

          Posté par  . Évalué à 2.

          J'oubliais un "détail", RHEL est beaucoup utilisé en station de travail.
      • [^] # Re: nostra

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

        Ah si Nostradamus est en forme !
        J'aime bien le jeu de mot: faire court feu.
        • [^] # Re: nostra

          Posté par  . Évalué à 1.

          Ce n'est pas un jeu de mot, c'est méconnaître sa langue natale ...
          Allez, je cite ...


          Ne pas faire long feu et Faire long feu

          Synonymes actuels: Rater son coup, ne pas s'attarder

          Plusieurs rumeurs planent au sujet de cette expression. La forme la plus couramment utilisée est en fait une déformation du sens véritable de celle-ci. Aujourd'hui, ne pas faire long feu, signifie rater son coup.

          - Fred est allé voir la belle jeune fille.... Elle lui a donné une de ces giffles!
          - Ouais! Faut dire qu'il n'a pas fait long feu...

          Cette utilisation de cette expression est une erreur puisque "n'a pas fait long feu" est utilisée dans le sens d'avoir raté son coup...Or c'est l'expression faire long feu qui veut exprimer le fait de rater quelque chose.

          Le Nouveau Petit Robert: "Faire long feu se dit d’une cartouche dont l’amorce brûle trop lentement, de sorte que le coup manque son but" et signifie au figuré "ne pas produire son effet, échouer"

          Là où on ne doit pas se tromper, c'est que l'expression ne pas faire long feu peut aussi être utilisée. Elle signifie "ne pas s’attarder" (faisant référence à la même amorce qui brûle trop lentement). Les expressions sont donc utilisées à tort même si elles ne sont pas des contraires directs. Celles-ci sont évidentes dans leurs contextes; l’une, plus ancienne, est surtout littéraire, l’autre, plus usuelle à l'oral. Le tout est de ne pas se tromper lorsqu'on les utilise!


          Par François Deslauriers, dimanche 6 mars 2005 à 01:32

          Ce n'est pas parce que les choses sont difficiles que nous n'osons pas. C'est parce que nous n'osons pas qu'elles sont difficiles. - Sénéque

          • [^] # Re: nostra

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

            Je crois que le mossieur voulait parler du jeu de mot "faire court feu" justement en rapport avec l'expression "fait long feu"...
            • [^] # Re: nostra

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

              Sauf que ça n'a pas de sens parce que « faire long feu » est ce qu'il fallait dire dans ce cas… s'il connaissait vraiment le sens de l'expression. C'est ce que le message d'au dessus essaye d'expliquer.
  • # rhel et ppc

    Posté par  . Évalué à 1.


    Côté stockage, c'est FUSE qui débarque dans RHEL, comprenant modules noyau et utilitaires. XFS et ext4 sont maintenant ajoutés dans le noyau officiel


    Est-ce vrai pour toutes les architectures ? Autant ext4 je le vois, autant XFS non.
    Je précise les rhel5 que j'ai son sous PPC.

    Côté gestionnaire de fenêtre, puisque quelqu'un en a parlé, sur les serveurs on s'en fiche. C'est vrai, néanmoins il me semble que redhat est beaucoup basé sur des interfaces graphiques.
    Lors du passage 5.3 à 5.4 yum m'a réinstallé kde ... (je ne sais même pas pourquoi ... Je ne me rappelle même pas l'avoir installé un jour)

    Je profite également, pour savoir si vous avez vous aussi des taux de téléchargements assez bas sur les serveurs ftp redhat pour les mises à jour ?
    J'atteins à peine les 300 ko/s ...
    • [^] # Re: rhel et ppc

      Posté par  . Évalué à 2.

      Côté gestionnaire de fenêtre, puisque quelqu'un en a parlé, sur les serveurs on s'en fiche.

      Sur les serveurs on s'en fout. Mais pour une entreprise qui vend pour les serveurs nettement moins. Par exemple, sur quoi est développement le "truc" JBoss qui tourne sur le serveur ? Que vont utiliser les admin ? Du Windows ?

      Autant ext4 je le vois, autant XFS non.

      Le support d'XFS est limité à certains fonctionnalités et est donné au cas par cas. Red Hat a n'a qu'un développeur XFS.

      Lors du passage 5.3 à 5.4 yum m'a réinstallé kde ...

      Réinstallé ou mise à jour ?

      Je ne me rappelle même pas l'avoir installé un jour

      Et tu es sûr qu'il t'a installé KDE ?
      Tu n'as peut-être que les librairies.
      C'est peut-être les dépendances qui ont ajouté Kdelibs, qt, etc.

      Je profite également, pour savoir si vous avez vous aussi des taux de téléchargements assez bas sur les serveurs ftp redhat pour les mises à jour ?

      Ça dépend. Red Hat a dit que la sortie d'une version, même mineur (5.4 ici), est une forte montée en charge de ses serveurs. N'oublions pas ceux qui downloadent les ISO.
      • [^] # Re: rhel et ppc

        Posté par  . Évalué à 1.

        Réinstallé, car je suis certain qu'il n'y était pas avant, il a installé kdebase, kdelibs, qt, etc.
        Je suis en effet convaincu que ce sont les dépendances qui ont ajouté cela.

        Pour le taux de téléchargement, tout simplement, je n'ai jamais dépassé les 300 ko lors de mise à jour avec yum.
        Après je ne suis absolument pas un expert avec les repos sous yum, il y a peut être des mirroirs que l'on peut sélectionner.
        • [^] # Re: rhel et ppc

          Posté par  . Évalué à 1.

          Après je ne suis absolument pas un expert avec les repos sous yum, il y a peut être des mirroirs que l'on peut sélectionner.

          Si on utilise RHEL, on utilise RHN pour les mises à jour, et il n'y a pas mirroirs.
          Je n'ai jamais fait attention au débit au RHN et 300 ko/s me semble correcte.
        • [^] # Re: rhel et ppc

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

          Depuis quelques mois, RHN utilise un CDN qui est censé faire que (presque tout) soit bien plus rapide qu'avant. Il y a eu quelques soucis avec RHN lors de la sortie de RHEL 5.4 / Satellite 5.3 mais pour autant que je sache, maintenant, c'est réglé. Il n'y a pas vraiment de moyen de choisir son mirroir manuellement. Si ta connexion permet de télécharger à plus de 300 ko/s, c'est censé suivre je pense.

          Si tu as encore des problème de vitesse de téléchargement reproducibles avec RHN, tu peux ouvrir un ticket avec le support et on peut essayer de voir. Faudrait l'IP depuis laquelle tu télécharges, le résultat de "wget -S" sur un lien RHN pour un gros fichier, genre l'ISO du DVD de 5.4 par exemple, un (bout de) tcpdump du download et un sosreport du système depuis lequel tu télécharges tant qu'on y est.

          pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

    • [^] # Re: rhel et ppc

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

      De ce que j'ai lu sur http://www.bofh-hunter.com/2009/09/04/rhel-5-4-and-xfs , RHEL 5.4 ne propose le module XFS que pour x86_64, et sans les xfsprogs. Anaconda ne reconnait même pas XFS, semble-t-il.

      Pour ceux que ça intéresse, le rapport de bug concernant cette situation est ici : https://bugzilla.redhat.com/show_bug.cgi?id=521173
      • [^] # Re: rhel et ppc

        Posté par  . Évalué à 1.

        Merci pour les conseils, je vais faire ça, car en effet la connexion du taff monte facile à 20 / 25 Mo /s sur certains ftp. Après je ne demande pas tant pour les mises à jour de redhat, mais 1 Mo /s ne serait pas du luxe :)
        Dommage pour XFS, il faudra faire sans visiblement.
  • # Red Hat Summit 2009

    Posté par  . Évalué à 1.

    Les vidéos du Red Hat Summit 2009 :
    http://www.redhat.com/promo/summit/2009/highlights/
    Je conseille vivement de les consulter.

    On y apprend que RHEL 6 est en début d'élaboration.

    En passant, RHEL 5.4 a le protocole Spice (tout est libre). Il n'est pas encore dans Fedora, mais j'ai hâte de l'y trouver.

Suivre le flux des commentaires

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