Red Hat Enterprise Linux 7.2

Posté par (page perso) . Édité par BAud, Benoît Sibaud, Jean-Max Reymond, palm123, ZeroHeure, Misc et Lucas. Modéré par patrick_g. Licence CC by-sa
34
11
jan.
2016
Red Hat

Red Hat a annoncé, ce 19 novembre 2015, la version 7.2 de Red Hat Enterprise Linux (RHEL), distribution commerciale destinée aux professionnels et aux entreprises.

Pour rappel, RHEL 7 est disponible depuis juin 2014 et apporte de nombreuses nouveautés, comme Docker, systemd et l'utilisation par défaut du système de fichiers XFS. RHEL 6 et 5 sont, malgré tout, encore maintenues par l'éditeur.

Il convient, bien entendu, de ne pas confondre RHEL 7.2 avec Red Hat Linux 7.2 sortie en octobre 2001 ;).

RHEL 7

Vous trouverez en deuxième partie de cet article une sélection des changements apportés.

Sommaire

Prise en charge du matériel

Une bien maigre mise à jour côté matériel pour démarrer cette version 7.2, puisque Red Hat n'a daigné signaler dans ses notes de version que la prise en charge officielle des cartes OSA-Express5s par l'outil qethqoat, présent dans le paquet s390utils. Pourquoi officielle ? Parce que cela était déjà présent en avant-première technologique dans RHEL 7.1.

En attendant, on peut noter que RHEL 7.2 est maintenant capable de gérer 12 To de mémoire vive sur un système x86_64. La précédente limite était de 6 To.

Installation et démarrage

Anaconda s'améliore en RHEL 7.2, à commencer par la résolution d'un problème réseau dans le cas d'une installation via Kickstart, dans le cas où celui-ci redéfinit la configuration réseau. Maintenant celle-ci est faite très tôt au niveau de l'installation, pour éviter de se retrouver dans le mode « urgence ».

Encore côté Anaconda, celui-ci est maintenant capable de créer des volumes LVM « en cache » et d'installer RHEL dessus, mais uniquement dans des installation via Kickstart.

Jamais deux sans trois, une autre amélioration concerne les actions sur les disques pendant l'installation. Auparavant, Anaconda et Blivet ne revenaient pas correctement sur les actions programmées sur les disques lorsque la sélection changeait, provoquant quelques problèmes. Avec cette mise à jour, Anaconda a été corrigé pour créer un instantané de la configuration de stockage d'origine et y revenir lorsque la sélection de disque change.

On continue sur Anaconda, qui voit arriver l'ajout d'⁠OpenSCAP. Il est donc maintenant possible (et optionnel) de créer une politique de sécurité, sans avoir recours à divers scripts pour la mettre en place. Concrètement, cela veut dire qu'une nouvelle section fait son apparition dans Kickstart ("%addon org_fedora_oscap"), ainsi qu'un nouvel écran dans l'installeur graphique. Le guide d'installation est mis à jour en conséquence. En plus de l'application d'une politique de sécurité, via sélection d'un profil, par exemple, le paquet openscap-scanner sera installé et effectuera un premier test pour s'assurer de la conformité du système installé. Le résultat de ce test sera accessible dans /root/openscap_data.

Pour en finir avec les nouveautés d'Anaconda, signalons que celui-ci n'a plus de timeout dans le cas d'un fichier kickstart présent sur un média optique. Auparavant, l'installeur attendait 30 secondes que l'utilisateur change de CD ou de DVD avant de passer en mode « urgence ». Maintenant, Anaconda affiche un message et attend soit que le fichier soit fourni, soit que le système redémarre.

Laissons Anaconda de côté et passons à GRUB2. Celui-ci souffrait en effet d'un problème dans le tri des noyaux, effectué par la commande grub2-mkconfig. Le résultat ? grub.cfg disposait certes des noyaux installés sur la machine, mais pas forcément dans le bon ordre, ce qui peut empêcher de démarrer sur le noyau le plus récent. Maintenant, GRUB2 utilise le paquet rpmdevtools pour trier les noyaux disponibles et générer correctement un fichier où le noyau le plus récent est listé en haut.

Stockage

Abordons d'abord le stockage par les systèmes de fichiers, dont certains font l'objet d'une mise à jour « d'envergure » :

  • l'outil gfs2-utils passe en version 3.1.8, ne dépend plus de Perl et apporte, entre autres, des améliorations de performances ;
  • ⁠XFS passe en version 4.1 ;
  • CIFS passe en version 3.17.

Outre ces mises à jour, on remarquera que GFS 2 empêche à présent les utilisateurs de dépasser leur quota en essayant de prédire l'augmentation d'espace avant d'effectuer une opération plutôt qu'en vérifiant le quota après celle-ci.

Virtualisation et conteneurs

RHEL 7.2 n'apporte pas de grandes révolutions côté virtualisation, mais quelques petites évolutions toujours appréciables. On commencera par l'exposition de la fonction MPX (Memory Protection Extensions, une fonction présente sur certains processeurs Intel) de l'hôte vers la machine virtuelle.

Une autre nouveauté intéressante est l'ajout d'un script nommé "dump-guest-memory.py". Comme son nom le laisse penser, celui-ci effectue une copie de la mémoire en cas de problème du noyau de la machine virtuelle.

La commande virt-v2v est maintenant pleinement prise en charge par Red Hat. Vous pourrez donc, par exemple, migrer vos machines virtuelles d'un hôte RHEL 5 Xen dom0 vers un RHEL 7 KVM.

Autre amélioration notable, l'arrivée de l'USB 3.0 dans les machines virtuelles, pour le moment en avant-première technologique.

Côté conteneurs, il y a de nombreuses mises à jour de paquets :

  • docker-1.8.2-8.el7 ;
  • flannel-0.5.3-8.el7 ;
  • cockpit-0.77-3.1.el7 ;
  • storaged-2.2.0-3.el7 ;
  • kubernetes-1.0.3-0.2.gitb9a88a7.el7 ;
  • atomic-1.6-6.gitca1e384.el7 ;
  • python-websocket-client-0.32.0-116.el7 ;
  • python-docker-py-1.4.0-118.el7.

Saluons aussi l'arrivée d'un nouveau paquet : docker-distribution. Bien entendu, Red Hat met aussi à jour toutes les images Atomic Host (variante de RHEL 7 optimisée pour les conteneurs Docker) et Docker disponibles.

Réseau

Dans RHEL 7.2, rien de moins que la pile TCP/IP a été mise à jour. Elle est maintenant en version 3.18, et apporte en particulier DCTCP, ainsi que des corrections pour TCP fast open.

De nouvelles API fournies par le noyau, glibc et libpcap permettent d'obtenir un horodatage précis à la nanoseconde. Tcpdump en profite donc aussi, et dispose donc d'options liées à ces nouvelles possibilités, comme par exemple l'option --time-stamp-precision qui permet de modifier la précision de l'horodatage lors de capture de paquets.

NetworkManager dispose lui aussi de son lot d'évolution :

  • son interface avec libreswan a été mise à jour en 1.6, qui appporte plusieurs corrections ;
  • il est possible de paramétrer le MTU d'une interface résultant d'un agrégat (bonding) ;
  • une meilleure gestion des conflits de routage (par exemple deux interfaces ayant la même route) ;
  • une option 'never-default' qui empêche Network Manager de prendre le pas sur les commandes 'ip route add' ;
  • prise en charge de Wake On Lan.

Beaucoup d'autres évolutions sont présentes au sujet des connexions VPN, ainsi que d'autres dont le but est de diminuer le temps de traitement des paquets réseau.

Sécurité

La partie sur l'installation abordait l'intégration d'OpenSCAP à Anaconda. Ce n'était que le début. Celui-ci est maintenant disponible en version 1.2.5, et est accompagné de la version 0.1.25 de sa documentation associée, scap-security-guide. Ces mises à jour permettent de disposer de profils de sécurité actuels et variés, comme un système générique, ou une conformité avec PCI-DSS v3.

SELinux se voit ajouter de nouvelles politiques, qui sont destinées à être utilisées par Red Hat Gluster Storage. En effet, jusqu'à RHEL 7.1, Gluster ne pouvait pas fonctionner lorsque SELinux était en mode Enforcing (sauf à créer soi-même les politiques).

Enfin, il est maintenant possible de désactiver les algorithmes d'échanges de clé GSSAPI, suite à la faille logjam.

Haute-disponibilité

RHEL 7.2 apporte aussi quelques améliorations de ce côté. On appréciera ainsi que systemd et pacemaker s'entendent mieux lors d'un arrêt système. Auparavant, ce manque de coordination provoquait un mauvais arrêt des ressources déclarées dans pacemaker.

Toujours du côté des ressources, les commandes pcs resource move et pcs resource ban affichent maintenant un avertissement afin de clarifier leur comportement. En effet, ces commandes créent des contraintes de localisation qui empêchent une ressource de fonctionner sur une machine donnée, lesquelles ne sont pas toujours claires.

Enfin, dans le cas du fencing, qui permet de cloisonner une ressource indisponible, parfois en effectuant un redémarrage électrique du serveur hébergeant la ressource en question, un correctif permet de redémarrer les deux alimentations d'un système redondé électriquement.

Authentification et interopérabilité

Comme pour RHEL 6.7 et 7.1, ces deux thèmes sont regroupés dans les notes de version. Pour cette version, on remarquera la montée de version d'OpenLDAP, qui passe en version 2.4.0. Au-delà des corrections de bogues, cette version apporte des améliorations, dont l'ajout des règles ORDERING aux descriptions d'attribut policy.

Côté SSSD, il y a plein de choses :

  • un mécanisme de cache est disponible, même en mode en-ligne ;
  • on peut faire correspondre un utilisateur à un UID et GID spécifique ;
  • SSSD peut maintenant interdire un accès SSH à un compte verrouillé ;
  • prise en charge des cartes smart card pour l’authentification locale ;
  • et bien d'autres encore !

NSS n'est pas en reste, avec l'activation de TLS 1.1 et 1.2 par défaut, la prise en compte des certificats ECDSA, ainsi que la possibilité pour les clients OpenLDAP de choisir leur cipher suite par défaut.

Un nouvel utilitaire fait son apparition : ipa-winsync-migrate. Son rôle est de réaliser une migration d'une intégration utilisant WinSync à une intégration utilisant Active Directory. L'utilitaire migre automatiquement les utilisateurs WinSync dans une forêt Active Directory.

Enfin, on soulignera l'arrivée de Ipsilon, un logiciel permettant d'intégrer les protocoles de fédération web comme SAML, OpenID ou Persona. Bien que n'étant présent qu'en avant-première technologique pour le moment, le logiciel est déjà utilisé notamment par le projet Fedora pour offrir une authentification centralisée de type SSO depuis plusieurs mois. De plus en plus de produits SaaS tels que Google Apps ou Office 365 prennent en charge SAML, c'est donc une solution arrivant à point nommé.

Environnement de bureau

Accrochez-vous ! Dans ce thème, il y a du lourd, du très lourd : rien de moins qu'une mise à jour de Gnome. On ne parle pas d'une version corrective, du genre 3e chiffre, mais d'un 2nd. Arrive donc Gnome 3.14, avec en cadeau bonus, quelques ajouts de la version 3.16. Pour mémoire, RHEL 7.0 et 7.1 contenaient Gnome 3.8. Bien entendu, Gnome est accompagné d'une version de GTK+ correspondante.

Ce saut dans les versions de Gnome apporte, entre autres :

  • GNOME Software, bien entendu associé à yum pour installer les logiciels ;
  • le menu "Statut système", regroupant certaines informations systèmes jusqu'alors séparées ;
  • l'affichage d'un menu d'authentification dans le cas d'une connexion à un hot-spot Wi-Fi.

Développement

Démarrons cette dernière partie en abordant la gestion de code source, en particulier l'utilisation de Subversion : il est maintenant compilé avec RELRO (Read-Only RELocation data), ce qui apporte une protection contre des attaques basées sur une corruption de la mémoire. Si des failles de ce type venaient à être découvertes, elles seront(seraient ?) par conséquent plus difficiles à exploiter.

Côté Java, OpenJDK 7 prend maintenant en charge les algorithmes basés sur les courbes elliptiques dans le cas de connexions TLS. Red Hat précise dans ses notes de version que ces algorithmes sont dans la plupart des cas préférables aux anciennes solutions cryptographiques pour créer des connexions réseau sécurisées.

On terminera cette partie en abordant le langage Python, qui se voit lui aussi amélioré d'un point de vue sécurité. Tout d'abord, un certain nombre de fonctionnalités de sécurité sont ajoutées à la bibliothèque standard, lesquelles sont décrites dans le PEP 466. On citera, entre autres, l'apparition de SNI (Server Name Indication), de nouveaux protocoles TLSv1.x, ainsi que de nouveaux algorithmes de hachage dans le module hashlib. Un autre PEP mis en place dans RHEL 7.2 est le 493, qui concerne la vérification certificats SSL/TLS.

Appel à volontaires

Cette dépêche, contrairement à celle sur le noyau, ne mobilise pas de nombreuses personnes lors de sa rédaction, et cela commence à peser sur le moral de votre serviteur (qui avait beaucoup apprécié les apports des 13 contributeurs à la dépêche sur RHEL 7.0) et dont le temps disponible baisse pour celles-ci (alors que l'actualité autour de Red Hat et de certains produits upstream est, au contraire, en hausse : on notera par exemple l'absence de dépêche sur les dernières versions de Katello, ou des avancées de CentOS).

Si vous souhaitez apporter votre pierre à l'édifice, sachez que Red Hat publie plusieurs mois avant une RHEL stable une version bêta, accompagnée de notes de version, généralement assez proches de la version finale (à quelques rares exceptions près). Créer un squelette de dépêche RHEL est simple et généralement réalisé par mes soins dès que j'apprends la disponibilité de la bêta.

  • # Principale nouveauté.

    Posté par . Évalué à 4.

    Pour moi, la principale nouveauté de la RHEL 7.2 est la mise à jour de Systemd passant de v208 à v219. Cette mise à jour, qui n'était pas prévue dans une version intermédiaire, découle semble-t-il de problèmes de backports.

    • [^] # Re: Principale nouveauté.

      Posté par (page perso) . Évalué à 4.

      C'est effectivement une mise à jour importante, d'un point de vue système, puisqu'elle touche un composant important de l'OS. D'ailleurs, si tu crains que je loupe d'autres informations de ce genre pour la prochaine version, tes contributions seront les bienvenues ! Par contre, d'un point de vue commercial, c'est un peu moins vendeur que d'annoncer qu'on a la dernière version de docker et qu'on a des conteneurs en dernière version pour faire fonctionner les dernières applications à la mode.

      J'ai aussi l'impression que ces dernières versions, que ce soit sur les 6.x ou les 7.x, Red Hat effectue moins de backports et plus de montées de version : docker, OpenLDAP, la pile TCP, voire même Gnome ! Je me demande du coup quelle est la politique exacte à ce sujet, mais je crains qu'il ne s'agisse que d'un traitement "au cas par cas". Dans ce cas, on peut se demander quel est le traitement vis-à-vis de PHP 5.3 (par défaut dans RHEL 6) et PHP 5.4 (par défaut dans RHEL 7), qui ne sont plus maintenus par les développeurs de PHP.

      • [^] # Re: Principale nouveauté.

        Posté par . Évalué à 2.

        Par contre, d'un point de vue commercial, c'est un peu moins vendeur que d'annoncer qu'on a la dernière version de docker et qu'on a des conteneurs en dernière version pour faire fonctionner les dernières applications à la mode.

        C'est vrai sur le plan commercial, mais moins net sur le plan technique, puiqu'on peut utiliser des nspawn+machinectl au lieu de Docker pour ses conteneurs. Et c'est là qu'intervient la montée de version de systemd : rien qu'avec la version 219, le changelog mentionne 15 modifications qui concernent nspawn. Par exemple, l'option --port pour qu'une application du conteneur soit publiée de façon transparente sur un port de l'hôte.

  • # conteneurs facile en bonus et pleinement contionel

    Posté par (page perso) . Évalué à 2.

    il y a aussi l option --network-[veth|brifge|…] qui est vraiment sympa.

    ça remplace bien tous les autres systèmes de conteneur, surtout que c est bien pratique pour les mettre au boot, avec des option spécifique en créant les fichiers /etc/systemd/nspawn/containername.nspawn avec dedans les option de boot qui changent, comme par exemple:

    /etc/systemd/nspawn/container1.nspawn

    [Files]
    BindReadOnly=/data/commons
    
    [Network]
    VirtualEthernet=yes
    Bridge=br0
    
    [Exec]
    Boot=yes
    Parameters=--directory=/data/fedora/container1
    

    il me suffit de mettre toutes mes configs, et avec les bons paramètres et la magie de systemd en faisant le reste

    ensuite le machinectl me permet si j avais envie (ou pas) d aller chercher les images chez docker, ou bien en format raw ou même tar.gz.

    le seul truc qui me manque par rapport a lxc, c'est de pouvoir lancer un conteneur en mode non privilégié. cela réduit la surface d attaque en cas de compromission, car le root dans le conteneur (lxc) n'est pas en uid 0 mais avec un subuid.

Suivre le flux des commentaires

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