Red Hat Enterprise Linux 5.2

Posté par Nils Ratusznik (site web personnel, Mastodon) le 25 mai 2008 à 01:04. Modéré par rootix.

Étiquettes :

mai

2008

Red Hat a annoncé ce 21 mai la version 5.2 de Red Hat Enterprise Linux (RHEL), distribution commerciale destinée aux professionnels et aux entreprises.
Comme à chaque nouvelle version mineure, de nombreux correctifs de bugs ou de sécurité ont été intégrés (comme par exemple pour la faille vmsplice). Mais Red Hat a aussi intégré des améliorations dans les domaines suivants :

Virtualisation
Utilisation sur ordinateur de bureau et portable
Sécurité et chiffrement
Cluster et stockage de données
Réseau et IPv6
Diagnostic

Notons que RHEL 4 est toujours maintenue, et qu'une version 4.7 devrait sortir au mois de Juin. Virtualisation
Les améliorations portent sur le support des architectures NUMA, ainsi que sur le nombre de CPU physiques (64) sans oublier la mémoire vive (512 Go par système). Le nombre d'interfaces réseau sur les machines virtuelles n'est plus limitée à 3. Libvirt, la bibliothèque d'abstraction de virtualisation créée par Red Hat a elle aussi été améliorée.

Dans le noyau Linux, le support pour le CPU frequency scaling a été rétro-porté. Cela permet d'améliorer les performances, la stabilité tout en limitant la consommation électrique (qui fait partie des arguments mis en avant par les défenseurs de la virtualisation). Enfin, un pilote de para-virtualisation a été développé afin d'améliorer les performances des machines virtualisées en « full virtualization ». Ce pilote est disponible pour RHEL 3u9 (x86 et x86_64), RHEL 4.6, et 5.1 minimum.

Utilisation sur ordinateur de bureau et portable
De nouvelles versions de logiciels sont disponibles :

Evolution 2.12.3
Firefox 3
OpenOffice 2.3.0
Thunderbird 2.0

Du côté des ordinateurs portables, l'amélioration porte sur les fonctions d'hibernation (Suspend/Hibernate/Resume). Des pilotes graphiques ont été mis à jour, dont ceux d'Intel, qui ont été rétro-portés.

Sécurité et chiffrement
Des API de chiffrement matériel ont été rétro-portées du noyau Linux vers RHEL 5.2 Le chiffrement des mots de passe est dorénavant possible en utilisant SHA-256 et SHA-512. Un support des audits respectant la RFC 4303 a été ajouté. Rsyslog permet d'utiliser différent back-ends, et d'analyser en direct les logs.

Cluster et stockage de données
Red Hat Cluster Suite (disponible dans la gamme Advanced Platform) possède maintenant son langage de script, le Resource Event Scripting Language. Le multipath (accès à un média de stockage depuis plusieurs systèmes) a été amélioré, de même que l'iSCSI : il est possible à présent d'avoir sa partition système sur un serveur iSCSI.

Réseau et IPv6
RHEL 5.2 supporte SNMP, mais aussi OpenSwan et IKE 2 (pour le VPN) en IPv6. Le support IPv6 des clients et serveurs DHCP a aussi été amélioré. D'autres améliorations concernent NFS, Infiniband et RDMA.

Diagnostic
Le tracing noyau avec SystemTap est complètement supporté, et le tracing en espace utilisateur ajouté en « Technology Preview »

Aller plus loin

Red Hat (62 clics)
Release notes et documentation (13 clics)
NUMA (62 clics)
Libvirt (2 clics)
Multipath (2 clics)
Red Hat News : RHEL 5.2 (33 clics)

# Quelques détails, svp...

Posté par windu.2b le 25 mai 2008 à 01:14. Évalué à 2.

"il est possible à présent d'avoir sa partition système sur un serveur iSCSI."
Cela signifie donc que la / peut être sur une partition distante ?
Mais je suppose que cela nécessite au moins d'avoir une /boot en local ? Ou bien Grub et/ou Lilo sont-ils capables de booter sur une parittion distante ?
Et qu'en est-il du débit ? Aller chercher les exécutables, bibliothèques et fichiers de configuration sur une partition distante ne ralentit-il pas trop le système ?
(ou bien j'ai rien compris ? Ce qui n'est pas totalement à exclure ^^ )
- [^] # Re: Quelques détails, svp...
  
  Posté par PLuG le 25 mai 2008 à 02:12. Évalué à 6.
  
  Quand on se lance sur du iSCSI c'est pour utiliser un SAN sans passer par la case couteuse FC (fiber channel, de la fibre optique et des switchs dédiés très chers). C'est donc en utilisant un réseau ethernet taillé pour le iSCSI avec au moins 1Gb/s de bande passante garantie (swicthée ou dédiée) par exemple. En général le SAN en face est *bien* plus rapide que les disques locaux.
  
  Mais tu as raison, il faut initialiser la machine avant qu'elle puisse rechercher un drive iSCSI sur le réseau. Soit le /boot est en local, soit la machine utilise un boot PXE sur le réseau pour télécharger un ramdisk suffisant.... je ne sais pas comment RedHat le fait mais y'a des solutions.
  - [^] # Re: Quelques détails, svp...
    
    Posté par ragoutoutou le 25 mai 2008 à 13:07. Évalué à 2.
    
    tu peux mettre le boot en local, sur une petite carte CF, par exemple... ou sur cd.
    
    Perso, sur les serveurs blades HP, j'utilise une image iso montée sur le lecteur cdrom virtuel de la carte ilo.
    - [^] # Re: Quelques détails, svp...
      
      Posté par bubar🦥 (Mastodon) le 26 mai 2008 à 11:03. Évalué à 3.
      
      Ou sur une clef usb (ou support de cartes sd ou puces) tu peux mettre un mbr + grub + etherboot (rom .zlilo par exemple). Cet ensemble permet que la machine puisse booter et descendre son nécessaire (noyau + ramdisk initial), avec la configuration du "partiionnement" adéquat ( / sur iscsi ou/et /home sur /nfs, etc etc). Sur ce même support de boot initial (clef, sd, puce) tu peux également mettre les clefs d' identification.
      
      Ainsi le personnel a tout sous la main, avec cette carte/sd/clef, pour pouvoir utiliser n' importe quel ordinateur, retrouver sa configuration, ses autorisations, et bien sûr son identification.
      
      Allez zou, mon laptop sous RedHat 5.2 ce soir ;)
    - [^] # Re: Quelques détails, svp...
      
      Posté par duf le 26 mai 2008 à 13:02. Évalué à 2.
      
      Est-ce que t'arrives à monter le lecteur cdrom virtuel depuis un poste distant par l'accès distant à ilo. Car en salles machines, directement sur la carte ilo ça fonctionne alors qu'avec un poste distant, l'iso montée n'est jamais vu par la lame du blade (ce sont des blades hp bl30 et bl35p) et c'est un peu chiant, car le site est un peu loin, donc pas pratique pour y aller....
      - [^] # Re: Quelques détails, svp...
        
        Posté par wismerhill le 26 mai 2008 à 21:08. Évalué à 3.
        
        J'ai déjà fait une installation distante (Même réseau du dournisseur d'accès, mais depuis nos bureaux à quelques dizaines de km du datacenter) avec un lecteur CD virtuel monté depuis ma machine via ilo, ce n'était qu'un CD net-boot debian, mais ça a pris une plombe pour en arriver au moment où il n'a plus besoin du CD, parce qu'il simule le périphérique en mode block et c'est contre-opmimal pour des accès réseau distant sur un réseau pas très rapide avec une latence relativement élevée.
        Et il est arrivé plusieurs fois que ça ne marche pas sans raison apparente avec une image ISO pourtant bonne.
        
        Donc c'est pratique pour ne pas devoir se déplacer, mais t'y gagne pas beaucoup de temps, juste du confort ;-)
      - [^] # Re: Quelques détails, svp...
        
        Posté par ragoutoutou le 01 juin 2008 à 17:20. Évalué à 2.
        
        Tu peux manipuler l'ilo via le langage RIBCL et monter une image cdrom en fournissant simplement une url vers l'image...
        
        c'est simple et ça marche très bien sur les bl20p, les bl4xxc, ...
  - [^] # Re: Quelques détails, svp...
    
    Posté par koopa le 26 mai 2008 à 11:03. Évalué à 3.
    
    Dans ma boite on a simplement équipé nos machines avec des cartes iSCSI de marque QLogic. C'est le BIOS de la carte qui s'occupe de l'intialisation.
    Linux croit avoir à faire à un controlleur SCSI classique et son disque dur SCSI local.
    Coté SAN, on a un simple Netapp FAS270.
# Support SNMP

Posté par Raphaël SurcouF (site web personnel) le 25 mai 2008 à 02:44. Évalué à 3.

RHEL 5.2 supporte SNMP
Est-ce à dire qu'auparavant, les RHEL ne supportaient pas le protocole SNMP ? Je ne puis y croire.
Qu'est-ce que la version 5.2 apporte de plus que les versions précédentes sur le protocole SNMP ?
- [^] # Re: Support SNMP
  
  Posté par Nils Ratusznik (site web personnel, Mastodon) le 25 mai 2008 à 02:56. Évalué à 4.
  
  C'est le SNMP en IPv6 qui a été amélioré.
  - [^] # Re: Support SNMP
    
    Posté par Raphaël SurcouF (site web personnel) le 25 mai 2008 à 03:24. Évalué à 2.
    
    Après re-lecture, c'est effectivement IPv6 qui semble être le principal sujet d'amélioration.
    En quoi le support IPv6 du protocole SNMP a-t-il été amélioré ? Est-ce les nombreux patches à ce sujet durant l'année 2007 ?
    - [^] # Re: Support SNMP
      
      Posté par Vincent Knecht le 25 mai 2008 à 14:50. Évalué à 1.
      
      Je ne pense pas qu'il s'agisse d'amélioration du protocole SNMP en lui-même,
      plutot des corrections de bugs concernant le support SNMP sur des machines où IPv6 a été désactivé, comme https://bugzilla.redhat.com/show_bug.cgi?id=444236
# ah tiens, comme Ubuntu...

Posté par Gniarf le 25 mai 2008 à 10:43. Évalué à 10.

ils t'y collent un Firefox 3 qui n'existe toujours pas \o/
- [^] # Re: ah tiens, comme Ubuntu...
  
  Posté par Paddy le 25 mai 2008 à 14:28. Évalué à 3.
  
  Comme Fedora aussi ...
  - [^] # Re: ah tiens, comme Ubuntu...
    
    Posté par Frederic Bezies le 25 mai 2008 à 16:19. Évalué à -2.
    
    Elle n'existe pas la version Release Candidate 1 de Firefox 3 ? Merdre, alors ;)
    - [^] # Re: ah tiens, comme Ubuntu...
      
      Posté par briaeros007 le 25 mai 2008 à 18:53. Évalué à 2.
      
      une rc1 c'est avant la release, comme son nom l'indique.
      - [^] # Re: ah tiens, comme Ubuntu...
        
        Posté par Frederic Bezies le 25 mai 2008 à 19:18. Évalué à -2.
        
        Mais c'est pourtant une version qui existe et qui est utilisable. Dire que Firefox 3 n'existe pas est donc un mensonge.
- [^] # Re: ah tiens, comme Ubuntu...
  
  Posté par Raphaël SurcouF (site web personnel) le 25 mai 2008 à 17:42. Évalué à 4.
  
  Et là, on n'entend pas IsNotGood sur le sujet...
  - [^] # Re: ah tiens, comme Ubuntu...
    
    Posté par Anonyme le 25 mai 2008 à 18:50. Évalué à 9.
    
    Il est surement en train de se renseigner sur la justification officielle de RedHat avant de venir la donner ici. Par ce qu'il ne faudrait pas donner une explication qui ne correspond pas exactement à celle de RedHat, ca pourrait donner la fausse impression qu'il a son propre avis.
    - [^] # Re: ah tiens, comme Ubuntu...
      
      Posté par Frederic Bezies le 25 mai 2008 à 19:20. Évalué à -2.
      
      Avec toujours autant de mauvaise foi, euh de justification capillotracté ?
      
      Je sens que je vais arriver à -15 avec ce commentaire ;)
      - [^] # Re: ah tiens, comme Ubuntu...
        
        Posté par FreeB5D le 28 mai 2008 à 22:20. Évalué à -1.
        
        Non, -43 pour que ceux à -42 ne le voient pas .
    - [^] # Re: ah tiens, comme Ubuntu...
      
      Posté par IsNotGood le 25 mai 2008 à 22:42. Évalué à 3.
      
      > Il est surement en train de se renseigner sur la justification officielle de RedHat avant de venir la donner ici.
      
      Admettons. L'important est de savoir si Red Hat dit des conneries ou non.
      La montée de version n'a rien de surprenant (c'est aussi fait pour OOo et Thunderbird) et ça a été annoncé.
      
      Comme tu refuses de lire tout communiqué de Red Hat, il n'y a que moi et quelques autres qui te donne des infos. C'est bien regrettable.
  - [^] # Re: ah tiens, comme Ubuntu...
    
    Posté par IsNotGood le 25 mai 2008 à 22:40. Évalué à -1.
    
    L'explication est simple, ça fait depuis longtemps que Red Hat ne se prend pas pour Debian.
    Pour des paquets complexes mais non critiques pour le business ne Red Hat et ses clients (comme les applis desktop), Red Hat pour RHEL s'appuit sur l'upstream. Firefox passe à Firefox 3, RHEL aussi. Ce n'est pas plus compliqué que ça.
    Si j'ai bonne mémoire, c'est un passage de Firefox 1.5 à Firefox 3.
    C'est fait pour Firefox, Thunderbird et OOo. Pour ces projets Red Hat n'a pas l'expertise de backporter les patchs de sécurité. Puis ce n'est pas critique. Rare sont les clients qui vont gueuler car l'API de Firefox a changé.
    Cette politique n'est pas récente. Elle a été annoncée pour RHEL 4.
    - [^] # Re: ah tiens, comme Ubuntu...
      
      Posté par ohnoes le 26 mai 2008 à 02:58. Évalué à 3.
      
      Ahlala, le discours du Parti sait s'adapter. Un coup on prétexte qu'on veut pas casser les API quand les utilisateurs réclamaient Firefox 2 (qui était en version finale) pour Fedora Core 6 (qui est censée être une distribution bleeding edge), un coup on a carrément les couilles de foutre une préversion de Firefox 3 dans leur distribution entreprise, RHEL.
      
      https://bugzilla.redhat.com/show_bug.cgi?id=213177
      
      Sachant qu'ils ont dû plier aux exigeances et passer à Fx2 pour Fedora 7 bien qu'ils souhaitaient attendre Fx3.
    - [^] # Re: ah tiens, comme Ubuntu...
      
      Posté par Gniarf le 26 mai 2008 à 05:14. Évalué à 5.
      
      mais Firefox 3 n'est toujours pas sorti. la MoFo n'est pas passée à Firefox 3. http://www.mozilla.com/ reste scotché à Firefox 2.0.0.14 . c'est pour bientot mais elle n'est pas encore là.
      
      et en plus la version de Firefox inclue dans cette RHEL 5.2 est une version beta. pas une RC (release candidate), hein, une version beta :
      
      firefox-1.5.0.12-3.el5 => firefox-3.0-0.beta5.6.el5
      
      et c'est le seul paquet qui soit d'un soft en version beta. le seul. il y a des paquets de softs en version 0.qq chose mais ce n'est pas le même style de version beta.
      
      ( Updated Packages de http://www.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5.(...)
      
      et tu dis que ce n'est pas critique de livrer des versions beta. soit. et que Firefox n'est pas un paquet critique pour les clients de Red Hat. soit. je ricane tout de même.
      
      je pense que d'ici 7 ans on sera à Firefox 5 ou 6 ou 7. alors l'expertise nécessitée pour backporter les patchs de sécurité de Firefox 3 sera la même que pour ceux de Firefox 2 : la MoFo aura enterré ces versions depuis longtemps. une 3.1 est déjà évoquée pour la fin de l'année.
      
      pour finir je vais juste mentionner que la numérotation des versions de Firefox suit entre autres des critères marketing et parait donc des fois un peu farfelue, comme cette 1.5 ... entre la 1 et la 2. youpi \o/ . mais bon. on va pas s'acharner sur des numéros finalement sans queue ni tête.
      
      car là finalement, c'est surtout la politique de backport de (mes) applications critiques qui va m'intéresser.
      - [^] # Re: ah tiens, comme Ubuntu...
        
        Posté par rewind (Mastodon) le 26 mai 2008 à 11:50. Évalué à 4.
        
        On peut aussi noter que dans la numérotation de version Firefox, le troisième élément ne sert à rien puisqu'il est toujours à 0. Exemple, 1.5.0.X où X augmente, 2.0.0.X où X augmente. Donc on n'aura jamais de 2.0.1 ou même de 2.1.0. Je retourne sur Wormux 0.8 et mon KDE 3.5.9.
      - [^] # Re: ah tiens, comme Ubuntu...
        
        Posté par reno le 26 mai 2008 à 12:24. Évalué à 2.
        
        [[et tu dis que ce n'est pas critique de livrer des versions beta. soit. et que Firefox n'est pas un paquet critique pour les clients de Red Hat. soit. je ricane tout de même.]]
        
        Pareil.. Je suis très surpris, il y a quand même eu pas mal de grincements de dents sur la stabilité de FF3 lors des sorties d'Ubuntu et de Fedora, donc le retrouver dans RHE, c'est curieux.
        
        Je ne m'y attendais pas, maintenant il faut dire que FF2 est loin d'être un modele de fiabilité, c'est peut-être la raison.
# et le LTS ?

Posté par duf le 26 mai 2008 à 01:20. Évalué à 1.

Une petite question car en gros fainéant je ne suis pas allé voir sur le site de RH. Il est de combien le LTS avec Red Hat, car à mon taf c'est en train de prendre une grosse importance.
- [^] # Re: et le LTS ?
  
  Posté par aae le 26 mai 2008 à 03:07. Évalué à 3.
  
  Je cite cette page : http://www.guideinformatique.com/fiche-opensource_maturite_d(...)
  
  support : chaque version dispose d'un engagement de durée de vie et de support/maintenance de 7 ans minimum après leur sortieLe cycle de vie de Red Hat Enterprise Linux est de sept années pour chaque version. De nouvelles versions sont présentées selon un cycle prévisible de 18 mois.
  Suse : 18 mois (!)
  
  Doit pas y avoir mieux que redhat sur ce point.
- [^] # Re: et le LTS ?
  
  Posté par olosta le 26 mai 2008 à 10:48. Évalué à 6.
  
  Le support se découpe en 3 phase :
  - 3 ans de sorties de versions mise à jour (securité, bug fix, drivers et améliorations qui ne cassent pas la compatibilité matérielle). Sortie des updates (versions mineures comme la 5 Update 2 qui est le sujet de la dépéche).
  - 6 mois de support au déploiement (sécurité et bug fix)
  - 3 ans et demi d'update de sécu
  
  https://www.redhat.com/security/updates/errata/
  
  Comme tu dit LTS, tu doit penser à Ubuntu. Je t'encourage à lire une bonne analyse de Dag Wieers (un des membres actif de la communauté CentOS) à propos d'Ubuntu versus RHEL et de la proposition de Mark Shuttleworth de synchroniser les releases :
  
  http://dag.wieers.com/blog/ubuntus-need-to-catch-a-wave
  - [^] # Re: et le LTS ?
    
    Posté par duf le 26 mai 2008 à 12:59. Évalué à 3.
    
    Non non je ne pensais pas du tout à Ubuntu car bon en entreprise, Ubuntu à part mettre sur du desktop pour faire joli, je ne vois pas comment on pourrait le justifier auprès du service achat.
    
    Là je pensais réellement LTS au sens "noble" du terme (pas tapé, un petit troll le lundi matin ne fait pas de mal :-) ) c'est à dire, comment en entreprise, quand on va payer des dizaines de milliers d'euros voir plus, qu'on aura un support à long terme.
    
    Perso j'ai bien suse, mais c'est sur ma station de travail et seulement sur quelques frontaux webs apache (qui ne font pas grand chose à part de la redirection d'instance avec gestion sso), mais en ce moment avec la virtualisation, un support de 7 ans ça commence à plaire aux achats (même si perso moi je suis un peu trop loin pour discuter de tout ça). En tout cas clairement face à de l'aix, sun ou hp, ça se positionne plutot pas mal.
# coquille or not coquille ?

Posté par rsystem le 26 mai 2008 à 10:52. Évalué à 1.

dites voir, je viens de lire la news, un truc me chiffonne :

Enfin, un pilote de para-virtualisation a été développé afin d'améliorer les performances des machines virtualisées en « full virtualization »

para-virtualisation et full virtualisation (aussi appelé HVM) sont 2 techniques de virtualisation différentes si ma mémoire est bonne, donc quid du driver en question ?
- [^] # Re: coquille or not coquille ?
  
  Posté par Skanx (site web personnel) le 27 mai 2008 à 15:15. Évalué à 1.
  
  not coquille: ces pilotes disques et réseau spécifiques améliorent les performances des machines virtualisées en full-virtualization, en diminuant la surcharge due à la virtualisation.
  
  Plus d'infos ici (en anglais) :
  http://www.press.redhat.com/2008/05/20/%EF%BB%BFred-hat-rele(...)
# definition du multipath

Posté par Prosper le 26 mai 2008 à 20:08. Évalué à 2.

Le multipath (accès à un média de stockage depuis plusieurs systèmes)

Si tu entends "systèmes" par serveur/os , ce n est pas du tout à ça que sert le multipath , en terme SAN , ça permet entre autre d'améliorer la disponibilité ( mais aussi les performances ) de ton lien serveur<->SAN , pour _le même serveur_ , par exemple en mettant plusieurs cartes Fiber ou initiateurs iSCSI vers le même SAN.

Suivre le flux des commentaires

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