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
- Red Hat (92 clics)
- Notes de version et documentation (27 clics)
- Red Hat News sur RHEL 5.4 (52 clics)
- Dépêche précédente sur RHEL 5.3 (34 clics)
- etherboot (2 clics)
- PXE (14 clics)
# nostra
Posté par bubar🦥 (Mastodon) . Évalué à 5.
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 IsNotGood . Évalué à 4.
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 georgeswwbush . Évalué à 10.
- 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 Sphax . Évalué à 5.
[^] # Re: nostra
Posté par IsNotGood . Évalué à 2.
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 IsNotGood . Évalué à 2.
[^] # Re: nostra
Posté par bengo (site web personnel) . Évalué à 5.
J'aime bien le jeu de mot: faire court feu.
[^] # Re: nostra
Posté par Neije . Évalué à 1.
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 CrEv (site web personnel) . Évalué à 5.
[^] # Re: nostra
Posté par Dr BG . Évalué à 6.
[^] # Re: nostra
Posté par CrEv (site web personnel) . Évalué à 2.
# rhel et ppc
Posté par Benoît . É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 IsNotGood . Évalué à 2.
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 Benoît . Évalué à 1.
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 IsNotGood . Évalué à 1.
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 Krunch (site web personnel) . Évalué à 3.
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 Nils Ratusznik (site web personnel, Mastodon) . Évalué à 3.
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 Benoît . Évalué à 1.
Dommage pour XFS, il faudra faire sans visiblement.
# Red Hat Summit 2009
Posté par IsNotGood . Évalué à 1.
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.
[^] # Re: Red Hat Summit 2009
Posté par IsNotGood . Évalué à 1.
http://deltacloud.org/
"Many cloud, one API, no problem."
[^] # Re: Red Hat Summit 2009
Posté par bubar🦥 (Mastodon) . Évalué à 2.
ha ben zut alors, on m'aurais menti ?
:p
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.