Étiquette : KVM

Nouvelle version de RedHat 9 et ses nouvelles influences

Comme vous le savez probablement, Red Hat Enterprise Linux (RHEL) 9 est désormais et généralement disponible. En parallèle de la sortie de la version RHEL release 8.6, cette version est conçue pour répondre aux besoins de l’environnement de cloud hybride. Dorénavant, cette version accentue l’exécution de votre code source plus efficacement, qu’il soit déployé sur une infrastructure physique, dans une machine virtuelle ou dans des conteneurs partir d’ images de base universelles Red Hat (UBI).

Actuellement RHEL 9 peut être téléchargé gratuitement dans le cadre de l’abonnement au programme Red Hat Developer.

Mais sans ressortir les informations commerciales, le mieux c’est de rentrer dans le vif du sujet en comparant les deux versions majeures distribuée par RedHat.

CaractéristiquesRHEL 9RHEL 8
Date de sortie17 mai 20227 mai 2019
Nom de codePlowOotpa
NoyauDistribué avec la version 5.14 du noyauDistribué avec la version 4.18 du noyau
Gestion des packagesDNF, MIAMDNF, MIAM
Architectures prises en chargeArchitectures AMD et Intel 64 bits (x86-64-v2)
L’architecture ARM 64 bits (ARMv8.0-A)
IBM Power Systems, Little Endian (POWER9)
IBM Z 64 bits (z14)
Architectures AMD et Intel 64 bits
L’architecture ARM 64 bits
IBM Power Systems, Little Endian
IBM Z
RéférentielsRed Hat Enterprise Linux 9 est distribué via deux référentiels principaux; ce sont des OS
AppStream
Red Hat Enterprise Linux 8 est distribué via deux référentiels principaux; ce sont des OS
AppStream
La configuration initialeÀ partir de RHEL 9, les écrans de configuration initiale ont été désactivés par défaut pour améliorer l’expérience utilisateur.Les utilisateurs de RHEL doivent configurer les configurations initiales (licences, système (gestionnaire d’abonnements) et paramètres utilisateur) avant les écrans de configuration initiale et de connexion de gnome.
SELinuxAvec cette version, la prise en charge de la désactivation de SELinux via l’option SELINUX=disabled dans le fichier /etc/selinux/config a été supprimée du noyau.La prise en charge de la désactivation de SELinux via l’option SELINUX=disabled dans /etc/selinux/config est prise en charge.
Script réseauRHEL 9 ne contient pas le package network-scripts. Pour configurer les connexions réseau dans RHEL 9, utilisez NetworkManager.Le package network-scripts était toujours disponible mais obsolète dans RHEL 8.
Versions des langages de programmation dynamiquesNode.js 16
PERL 5.32
PHP 8.0
Python 3.9
Rubis 3.0
Node.js 16
PERL 5.26
PHP 7.2
Python 3.6
Rubis 2.5
Python 2.7 est disponible dans le package python2 (aura un cycle de vie plus court)
Filtrage de paquetsnftables est le cadre de filtrage de paquets réseau par défaut et les packages ipset et iptables-nft ont été dépréciés.nftables remplace iptables comme cadre de filtrage de paquets réseau par défaut
Systèmes de fichiersXFS est le système de fichiers par défaut et prend désormais en charge les fonctionnalités bigtime et inobtcount. De plus, le système de fichiers exFAT est désormais pris en charge dans RHEL 9.XFS est le système de fichiers par défaut. Le système de fichiers Btrfs est supprimé dans Red Hat Enterprise Linux 8.
Optimiseur de données virtuel (VDO)Le logiciel de gestion VDO basé sur python n’est plus disponible dans RHEL 9. Au lieu de ce logiciel, utilisez l’implémentation LVM-VDO pour gérer les volumes VDO.VDO est disponible sur toutes les architectures prises en charge par RHEL 8.
Exécution du conteneur par défautcrunrunc et Docker ne sont pas inclus dans RHEL 8.0.
bref comparaison entre versions

Changements majeurs dans RHEL 9.0

Sécurité

L’utilisation du SHA-1 à des fins cryptographiques a été dépréciée dans RHEL 9. Le résumé produit par SHA-1 n’est pas considéré comme sécurisé en raison de nombreuses attaques réussies documentées basées sur la recherche de collisions de hachage. Les composants cryptographiques principaux de RHEL ne créent plus de signatures à l’aide de SHA-1 par défaut. Les applications dans RHEL 9 ont été mises à jour pour éviter d’utiliser SHA-1 dans les cas d’utilisation liés à la sécurité.

OpenSSL est désormais fourni dans la version 3.0.1, qui ajoute un concept de fournisseur, un nouveau schéma de gestion des versions, un client HTTP(S) amélioré, la prise en charge de nouveaux protocoles, formats et algorithmes, et de nombreuses autres améliorations.

Les politiques cryptographiques ont été ajustées pour fournir des valeurs par défaut sécurisées à jour.

OpenSSH est distribué dans la version 8.7p1, qui fournit de nombreuses améliorations, corrections de bogues et améliorations de sécurité par rapport à la version 8.0p1, qui est distribuée dans RHEL 8.5.

Le protocole SFTP remplace le protocole SCP/RCP précédemment utilisé dans OpenSSH . SFTP offre une gestion plus prévisible des noms de fichiers et ne nécessite pas d’extension de glob(3)motifs par la coque du côté distant.

SELinux ont été considérablement améliorées, y compris le temps de chargement de la politique SELinux dans le noyau, la surcharge de mémoire et d’autres paramètres. Pour plus d’informations, consultez le Améliorer les performances et l’efficacité de l’espace de SELinux blog

L’utilisation de SHA-1 pour les signatures est restreinte dans la politique de chiffrement DEFAULT. À l’exception de HMAC, SHA-1 n’est plus autorisé dans les protocoles TLS, DTLS, SSH, IKEv2, DNSSEC et Kerberos.

Consultez la Sécurité dans le Considérations relatives à l’adoption de RHEL 9 pour plus d’informations sur les principales différences liées à la sécurité entre RHEL 9 et RHEL 8.

La mise en réseau

Vous pouvez utiliser le nouveau démon MultiPath TCP (mptcpd) pour configurer les points de terminaison MultiPath TCP (MPTCP) sans utiliser iproute2 . Pour rendre les sous-flux et les points de terminaison MPTCP persistants, utilisez un script de répartiteur NetworkManager.

Par défaut, NetworkManager utilise désormais les fichiers de clés pour stocker les nouveaux profils de connexion. A savoir que format ifcfg est toujours pris en charge.

Pour plus d’informations sur les fonctionnalités introduites dans cette version et les modifications apportées aux fonctionnalités existantes, consultez Nouvelles fonctionnalités – Mise en réseau .

La technologie WireGuard VPN est désormais disponible optionnel mais non supporté. Pour plus de détails, voir Aperçus technologiques – Mise en réseau .

Le service teamdservice etsa librairie libteam sont obsolètes. En remplacement, il faudra configurer une liaison type bond au lieu du service team.

La iptables-nft et ipset sont obsolètes. Ces packages incluent des utilitaires, tels que iptables, ip6tables, ebtableset arptables. Il faut utiliser le framework nftables pour configurer les règles de pare-feu.

Pour plus d’informations sur les fonctionnalités obsolètes, consultez Fonctionnalité obsolète – networking.network-scripts a été supprimé. Utilisez NetworkManager pour configurer les connexions réseau. Pour plus d’informations sur les fonctionnalités qui ne sont pas loin r partie de RHEL, consultez la Mise section Considérations relatives à l’adoption de RHEL 9 .

Langages de programmation dynamiques, serveurs web et bases de données

RHEL 9.0 fournit les langages de programmation dynamique suivants :

  • Node.js 16
  • Perl 5.32
  • PHP 8.0
  • Python 3.9
  • Rubis 3.0

RHEL 9.0 inclut les systèmes de contrôle de version suivants :

  • Gite 2.31
  • Sous-version 1.14

Les serveurs Web suivants sont distribués avec RHEL 9.0 :

  • Serveur HTTP Apache 2.4.51
  • nginx 1.20

Les serveurs de mise en cache proxy suivants sont disponibles :

  • Cache de vernis 6.6
  • Calmar 5.2

RHEL 9.0 propose les serveurs de base de données suivants :

  • MariaDB 10.5
  • MySQL 8.0
  • PostgreSQL 13
  • Redis 6.2

Voir Section 4.13, « Langages de programmation dynamiques, serveurs Web et de base de données » pour plus d’informations.

Implémentations Java dans RHEL 9

Le référentiel RHEL 9 AppStream comprend :

  • La java-17-openjdkpackages, qui fournissent l’environnement d’exécution Java OpenJDK 17 et le kit de développement logiciel OpenJDK 17 Java.
  • La java-11-openjdkpackages, qui fournissent l’environnement d’exécution Java OpenJDK 11 et le kit de développement logiciel OpenJDK 11 Java.
  • La java-1.8.0-openjdkpackages, qui fournissent l’environnement d’exécution Java OpenJDK 8 et le kit de développement logiciel OpenJDK 8 Java.

Pour plus d’informations, consultez la documentation OpenJDK .

Outils Java

Les outils Java suivants sont disponibles avec RHEL 9.0 :

  • Maven 3.6
  • Le 1.10

Voir Section 4.14, « Compilateurs et outils de développement » pour plus d’informations.

Virtualisation

Dans la version de RHEL 9, la bibliothèque libvirt utilise des démons modulaires qui gèrent des ensembles de pilotes de virtualisation individuels sur votre hôte. Cela permet d’affiner une variété de tâches qui impliquent des pilotes de virtualisation, telles que l’optimisation et la surveillance de la charge des ressources.

L’émulateur QEMU est maintenant construit à l’aide du compilateur Clang. Cela permet à l’hyperviseur KVM de RHEL 9 d’utiliser un certain nombre de fonctionnalités avancées de sécurité et de débogage. L’une de ces fonctionnalités est SafeStack, qui rend les machines virtuelles (VM) hébergées sur RHEL 9 beaucoup plus sûres contre les attaques basées sur la programmation orientée retour (ROP).

De plus, Virtual Trusted Platform Module (vTPM) est désormais entièrement pris en charge. À l’aide de vTPM, vous pouvez ajouter un crypto-processeur virtuel TPM à une machine virtuelle, qui peut ensuite être utilisé pour générer, stocker et gérer des clés cryptographiques.

Finalement, le système de gestion de fichiers virtiofs a été implémentée.
Rappel: Il s’agit d’une option que vous pouvez utiliser pour partager plus efficacement des fichiers entre un hôte RHEL 9 et ses machines virtuelles.

Pour plus d’informations sur les fonctionnalités de virtualisation introduites dans cette version, reportez- la Section 4.20, « Virtualisation » .

Mise à niveau sur place

Mise à niveau sur place de RHEL 8 vers RHEL 9

Les passerelles de mise à niveau actuellement en place prennent en charge :

  • De RHEL 8.6 à RHEL 9.0 sur les architectures suivantes :
    • Intel 64 bits
    • AMD 64 bits
    • ARM 64 bits
    • IBM POWER 9 (petit boutiste)
    • Architectures IBM Z, hors z13
  • De RHEL 8.6 à RHEL 9.0 sur des systèmes avec SAP HANA

Pour plus d’informations, consultez Chemins de mise à niveau sur place pris en charge pour Red Hat Enterprise Linux . Pour obtenir des instructions sur la réalisation d’une mise à niveau sur place, consultez Mise à niveau de RHEL 8 vers RHEL 9 .

Mise à niveau sur place de RHEL 7 vers RHEL 9

Il n’est pas possible d’effectuer une mise à niveau sur place directement de RHEL 7 vers RHEL 9. Cependant, vous pouvez effectuer une mise à niveau sur place de RHEL 7 vers RHEL 8, puis effectuer une deuxième mise à niveau sur place vers RHEL 9. Pour plus plus d’informations, consultez Mise à niveau de RHEL 7 vers RHEL 8 .

Les nouvelles limites supportées et théoriques

Que peut faire Red Hat® Enterprise Linux® ? Découvrez dans ce tableau les limites supportées et théoriques de la plateforme.

Cet article fournit des informations sur les versions du système d’exploitation actuellement gérées. Pour plus d’informations sur les anciennes versions retirées qui ne sont plus maintenues, veuillez consulter l’article complémentaire de la base de connaissances intitulé Red Hat Enterprise Linux Technology Capabilities and Limits for Retired, Non-Maintained Releases .

Les limites prises en charge reflètent l’état actuel des tests du système par Red Hat et ses partenaires pour le matériel grand public. Les systèmes dépassant ces limites prises en charge peuvent être inclus dans le catalogue matériel après des tests conjoints entre Red Hat et ses partenaires. Si elles dépassent les limites prises en charge affichées ici, les entrées du catalogue de matériel incluront une référence aux détails des limites spécifiques au système et sont entièrement prises en charge. En plus des limites prises en charge reflétant la capacité matérielle, il peut y avoir des limites supplémentaires dans les conditions d’abonnement à Red Hat Enterprise Linux.

Les limites prises en charge sont susceptibles d’être modifiées à mesure que les tests en cours se terminent.

Les valeurs suivantes sont formatées comme testées et prises en charge [théorique] .

CPU logiques maximales

Red Hat définit un CPU logique comme n’importe quelle entité planifiable. Ainsi, chaque cœur/thread d’un processeur multicœur/thread est un processeur logique.

ArchitectureRHEL 6RHEL 7RHEL 8RHEL 9
x8632N/A 1N/A 1N/A 1
x86_64448 [4096] 2768 [5120] 3768 [8192]1792 [8192]
POWER128768 [2048] 4POWER8 : 768 [2048]
POWER9 : 1536 [2048] 5
POWER10 : 1920 [2048] 6
POWER9 : 1536 [2048]
POWER10 : 1536 [2048]
IBM Zz13 : 64z13 : 256z13 : 256
z14 : 340
z14 : 340
z15 : 380
BRASN / AN / A256512 [4096]

Mémoire maximale

Les limites architecturales sont basées sur les capacités du noyau Red Hat Enterprise Linux et du matériel physique. La limite de Red Hat Enterprise Linux 6 est basée sur un adressage de mémoire physique de 46 bits. La limite de Red Hat Enterprise Linux 5 est basée sur un adressage de mémoire physique de 40 bits. Toute la mémoire système doit être équilibrée entre les nœuds NUMA dans un système compatible NUMA.

ArchitectureRHEL 6RHEL 7RHEL 8RHEL 9
x8616 GBN/A 1N/A 1N/A 1
x86_6412 To [64 To] 712 To [64 To] 824 To [64 To]48 To [64 To]
POWER2 To32 To 9POWER8 : 32 To [128 To]
POWER9 : 64 To [128 To] 10
POWER10 : 32 To [128 To] 11
POWER9 : 64 To [128 To]
POWER10 : 32 To [128 To]
IBM Zz13 : 4 Toz13 : 10 Toz13 : 10 To
z14 : 16 To
z14 : 16 To
z15 : 16 To
BRASN / AN / A1,5 To [256 To]1,5 To [256 To]
Espace d’adressage virtuel x86 maximum par processusEnviron. 3 GoN/A 1N/A 1N/A 1
Espace d’adressage virtuel maximal x86_64 par processus128 To128 To128 To128 To
Espace d’adressage virtuel de puissance maximale par processus4PB 124PB 12

Mémoire minimale requise

ArchitectureRHEL 6RHEL 7RHEL 8RHEL 9
x86512 Mo minimum, 1 Go par processeur logique recommandéN/A 1N/A 1N/A 1
x86_641 Go minimum, 1 Go par processeur logique recommandé1 Go minimum, 1 Go par processeur logique recommandé 131,5 Go minimum, 1,5 Go par processeur logique recommandé 131,5 Go minimum, 1,5 Go par processeur logique recommandé 13
POWER2 Go minimum, 2 Go requis par installation2 Go minimum, 2 Go requis par installation2 Go minimum, 2 Go requis par installation2 Go minimum, 2 Go requis par installation
IBM Z512 Mo1 Go1 Go minimum, 2 Go requis pour l’installation1 Go minimum, 2 Go requis pour l’installation
BRASN / AN / A2 Go2 Go

Espace disque minimum requis

RHEL 6RHEL 7RHEL 8RHEL 9
1 Go minimum, 5 Go recommandés10 Go minimum, 20 Go recommandés10 Go minimum, 20 Go recommandés10 Go minimum, 20 Go recommandés

Systèmes de fichiers et limites de stockage

Ext3

CaractéristiqueRHEL 6RHEL 7RHEL 8RHEL 9
Taille de fichier maximale2 To2 To2 To2 To
Taille maximale du système de fichiers16 To16 To16 To16 To
Nombre maximal de sous-répertoires32000320003200032000
Profondeur maximale du lien symbolique8888
Prise en charge de la LCAOuiOuiOuiOui

Ext4

CaractéristiqueRHEL 6RHEL 7RHEL 8RHEL 9
Taille de fichier maximale16 To16 To16 To16 To
Taille maximale du système de fichiers16 To [1 EB]50 To [1 EB]50 To [1 EB]50 To [1 EB]
Nombre maximal de sous-répertoires65000/illimité65000/illimité65000/illimité65000/illimité
Profondeur maximale du lien symbolique8888
Prise en charge de la LCAOuiOuiOuiOui

SFP

Veuillez consulter l’article de la base de connaissances intitulé Red Hat Enterprise Linux Technology Capabilities and Limits for Retired, Non-Maintained Releases pour plus d’informations sur la prise en charge de GFS.

GFS2

CaractéristiqueRHEL 6RHEL 7RHEL 8RHEL 9
Taille de fichier maximale100 To [8 EB]100 To [8 EB]100 To [8 EB]100 To [8 EB]
Taille maximale du système de fichiers100 To [8 EB]100 To [8 EB]100 To [8 EB]100 To [8 EB]
Nombre maximal de sous-répertoiresillimitéillimitéillimitéillimité
Profondeur maximale du lien symboliqueillimitéillimitéillimitéillimité
Prise en charge de la LCAOuiOuiOuiOui

XFS

CaractéristiqueRHEL 6RHEL 7RHEL 8RHEL 9
Taille de fichier maximale100 To [8 EB]500 To [8 EB]8EB8EB
Taille maximale du système de fichiers300 To [16 EB] 14500 To [16 EB]1PB1PB
Nombre maximal de sous-répertoiresillimitéillimitéillimitéillimité
Profondeur maximale du lien symbolique8888
Prise en charge de la LCAOuiOuiOuiOui

Stockage

CaractéristiqueRHEL 6RHEL 7RHEL 8RHEL 9
Taille maximale du LUN de démarrage (BIOS)2 To 152 To 152 To2 To
Taille maximale du LUN de démarrage (UEFI)32 bits (i686) – 2 To,
64 bits – 16 To (limite testée)
50 To8EB8EB
Nombre maximal de chemins d’accès aux périphériques ( sddispositifs)8,192 16,1710,000 16,1710,000 16,1710,000 16,17

Fonctionnalités du noyau et du système d’exploitation

CaractéristiqueRHEL 6RHEL 7RHEL 8RHEL 9
Fondation du noyau2.6.32 – 2.6.343.104.185.14
Compilateur/chaîne d’outilsCCG 4.4CCG 4.8.2CCG 8.2.1CCG 11.2.1
Langues prises en charge2222À déterminerÀ déterminer
Certifié NIAP/CCOui (4+)En cours d’évaluation (4+)En discussionEn discussion
KVM certifié Critères CommunsÉvaluéEn cours d’évaluation
IPv6Prêt Logo Phase 2En cours d’évaluationEn discussionEn discussion
Certifié FIPSOui (8 modules)En cours d’évaluation (9 modules)En discussionEn discussion
Conforme à l’environnement d’exploitation commun (COE)N / AN / AEn discussionEn discussion
Conforme au LSBOui – 4.0En cours d’évaluation (4.1)En discussionEn discussion
GB18030OuiOuiOuiEn discussion

Environnement clients

CaractéristiqueRHEL 6RHEL 7RHEL 8RHEL 9
Interface graphique du bureauGnome 2.28Gnome 3.8Gnome 3.28 18Gnome 40, plus mises à jour 18
GraphiqueX.org 7.4X.org 7.7Wayland 1.15 18Wayland 1.19 18
Suite bureautiqueOpen Office v3.2 18Libre Office v4.1.4 18Libre Office v6.0.6.1 18Libre Office v7.1.8.1 18
Évolution de GNOMEv2.28v3.8.5v3.28.5 18v3.40.4 18
Navigateur par défautFirefox 3.6 18Firefox 24.5 18Firefox 60.5.1 18Firefox 91.8.0 18
Caractéristique environnement client

Remarques

  1. Red Hat Enterprise Linux 7 et les versions plus récentes n’incluent pas la prise en charge de l’architecture x86 32 bits.
  2. Red Hat Enterprise Linux 6.7 ou plus récent est requis pour la prise en charge de 448 CPU. Le nombre maximal de processeurs pris en charge pour les versions antérieures était de 288 processeurs.
  3. Red Hat Enterprise Linux 7.3 avec le noyau d’errata 3.10.0-514.26.2.el7 ou plus récent est requis pour la prise en charge du processeur 768. Red Hat Enterprise Linux 7.2 avec le noyau d’errata 3.10.0-327.18.2.el7 ou plus récent est requis pour la prise en charge du processeur 576. Red Hat Enterprise Linux 7.2 ou plus récent est requis pour la prise en charge de 384 CPU. Le nombre maximal de processeurs pris en charge pour les versions antérieures était de 288 processeurs. De même, pour la version 7.2 ou ultérieure, veuillez consulter l’article suivant de la base de connaissances Red Hat : L’échange de mémoire se produit pendant la récupération du cache de page .
  4. Red Hat Enterprise Linux 7.5 ou plus récent, Red Hat Enterprise Linux 7.4 Extended Update Support (EUS) kernel version 3.10.0-693.25.2.el7 ou plus récent, ou Red Hat Enterprise Linux 7.3 Extended Update Support (EUS) kernel version 3.10.0 -514.48.1.el7 ou plus récent est requis pour la prise en charge du processeur 768. Le nombre maximal de processeurs pris en charge pour les versions de mise à jour antérieures ou les noyaux EUS de Red Hat Enterprise Linux 7 était de 192 processeurs.
  5. Red Hat Enterprise Linux 8.2 ou plus récent est requis pour prendre en charge les processeurs 1536 sur les systèmes IBM POWER9. Le nombre maximal de CPU pris en charge sur Red Hat Enterprise Linux 8.0 et 8.1 pour POWER9 est de 768 CPU.
  6. Les tests initiaux ont démontré la prise en charge complète des processeurs 1536 sur les systèmes IBM Power10 exécutant Red Hat Enterprise Linux 8.4 ou une version plus récente. Des tests supplémentaires nous ont permis d’augmenter le nombre maximal de processeurs pris en charge à 1920 processeurs lors de l’exécution de Red Hat Enterprise Linux 8.4 ou plus récent sur les systèmes IBM Power10.
  7. Red Hat Enterprise Linux 6.7 est requis pour la prise en charge de 12 To de RAM. Red Hat Enterprise Linux 6.6 peut prendre en charge jusqu’à 6 To de RAM. Les versions précédentes de Red Hat Enterprise Linux 6, à commencer par Red Hat Enterprise Linux 6.3, prennent en charge jusqu’à 3 To de RAM. Les versions de Red Hat Enterprise Linux antérieures à Red Hat Enterprise Linux 6.3 prennent en charge jusqu’à 1 To de RAM.
  8. Red Hat Enterprise Linux 7.2 est requis pour la prise en charge de 12 To de RAM. Red Hat Enterprise Linux 7.1 peut prendre en charge jusqu’à 6 To de RAM. Les versions précédentes de Red Hat Enterprise Linux 7 (c’est-à-dire Red Hat Enterprise Linux 7.0) prennent en charge jusqu’à 3 To de RAM. Red Hat Enterprise Linux 7.2 est requis pour la prise en charge de 12 To de RAM. Red Hat Enterprise Linux 7.1 peut prendre en charge jusqu’à 6 To de RAM. Les versions précédentes de Red Hat Enterprise Linux 7 (c’est-à-dire Red Hat Enterprise Linux 7.0) prennent en charge jusqu’à 3 To de RAM.
  9. Red Hat Enterprise Linux 7.5 ou plus récent, Red Hat Enterprise Linux 7.4 Extended Update Support (EUS) kernel version 3.10.0-693.25.2.el7 ou plus récent, ou Red Hat Enterprise Linux 7.3 Extended Update Support (EUS) kernel version 3.10.0 -514.48.1.el7 ou plus récent est requis pour la prise en charge de 32 To de RAM. Les versions de mise à jour précédentes ou les noyaux EUS de Red Hat Enterprise Linux 7 pouvaient prendre en charge jusqu’à 2 To de RAM.
  10. Red Hat Enterprise Linux 8.2 ou plus récent est requis pour prendre en charge 64 To de RAM sur les systèmes IBM POWER9. La quantité maximale de RAM prise en charge sur Red Hat Enterprise Linux 8.0 et 8.1 pour POWER9 est de 32 To.
  11. Red Hat Enterprise Linux 8.4 ou plus récent est requis pour prendre en charge 32 To de RAM sur les systèmes IBM Power10.
  12. Pour les processeurs prenant en charge l’adressage virtuel 52 bits.
  13. L’installation réseau / PXE nécessite au moins 1,5 Go de RAM pour la procédure d’installation uniquement.
  14. Red Hat Enterprise Linux 6.8 ou plus récent est requis pour la prise en charge du système de fichiers XFS de 300 To sur RHEL 6.x. La taille maximale du système de fichiers XFS précédemment prise en charge dans RHEL 6.7 et versions antérieures était de 100 To.
  15. La prise en charge d’UEFI et de GPT est requise pour une prise en charge de LUN de démarrage supérieure à 2 To, comme détaillé dans l’article de la base de connaissances intitulé Configuration requise du lecteur de démarrage pour Red Hat Enterprise Linux .
  16. Des nombres plus importants sont possibles, en fonction des tests et de la prise en charge par le fournisseur de matériel spécifique. Consultez votre fournisseur de matériel pour déterminer leur limite et confirmez avec votre représentant du support Red Hat. En aucun cas, Red Hat ne prendra en charge une limite qui dépasse la limite prise en charge par le fournisseur de matériel.
  17. Il peut être nécessaire d’augmenter certains paramètres du pilote pour atteindre ces limites. Consultez votre représentant de l’assistance Red Hat. Il peut être nécessaire d’augmenter certains paramètres du pilote pour atteindre ces limites. Consultez votre représentant de l’assistance Red Hat.
  18. Les applications de l’espace utilisateur seront mises à jour pendant la durée de vie de la version.

Cycle de vie de Red Hat Enterprise Linux

Liée à ces nouvelles versions, les influences du support et garanties indiquées sur le tableau ci-contre:

DescriptionPlein soutienEntretien
Soutien 1
(RHEL 7) 12
Entretien
Prise en charge (RHEL 8 et 9) 13

Entretien
Soutien 2
(RHEL 7) 12
Durée de vie prolongée Phase 7Module complémentaire ELS (Extended Life Cycle Support) 8Module complémentaire de prise en charge étendue des mises à jour (EUS) 8
Accès au contenu précédemment publié via le portail client Red HatOuiOuiOuiOuiOuiOui
Auto-assistance via le portail client Red HatOuiOuiOuiOuiOuiOui
Assistance technique 1IllimitéIllimitéIllimitéLimité 9IllimitéIllimité
Errata de sécurité asynchrone (RHSA) 10 11OuiOuiOuiNonOui 8Oui 8
Errata de correction de bogue asynchrone (RHBA) 2 11OuiOuiOuiNonOuiOui
Versions mineuresOuiOuiOui (RHEL 7) ; Non applicable (RHEL 8 & 9)NonNonNon
Activation matérielle actualisée 3Originaire deLimité 4 natifUtilisation de la virtualisationUtilisation de la virtualisationUtilisation de la virtualisationUtilisation de la virtualisation
Améliorations du logiciel 5Oui 6NonNonNonNonNon
Mise à jour des images d’installationOuiOuiOui 14NonNonNon
Cycle de vie de Red Hat Enterprise Linux
  1. L’accès au support technique dépend du niveau de service inclus dans votre abonnement Red Hat Enterprise Linux.
  2. Red Hat peut choisir, à titre de mesure temporaire, de résoudre ces problèmes catastrophiques ayant un impact significatif sur l’activité du client avec un correctif pendant que l’avis d’errata de correction de bogue (RHBA) est en cours de création.
  3. L’activation du matériel natif est fournie par le rétroportage des pilotes matériels, etc., vers la version appropriée de Red Hat Enterprise Linux. L’activation du matériel à l’aide de la virtualisation est obtenue en exécutant une version antérieure de Red Hat Enterprise Linux en tant qu’invité virtuel sur une version plus récente de Red Hat Enterprise Linux. Voir la virtualisation description de REMARQUE : La certification matérielle (y compris les limites matérielles associées) s’applique à la version de Red Hat Enterprise Linux qui est utilisée comme hôte.
  4. L’activation du matériel natif dans la phase de support de maintenance 1 est limitée à l’activation du matériel qui ne nécessite pas de modifications logicielles substantielles. Voir la support de maintenance 1 ci-dessous pour plus de détails.
  5. Les améliorations logicielles sont des ajouts de nouvelles fonctionnalités au-delà de la correction des défauts ou de l’activation de fonctionnalités existantes sur une nouvelle génération de matériel.
  6. Les versions majeures sont le principal vecteur d’améliorations logicielles importantes, bien que des améliorations logicielles à faible impact puissent également être fournies dans des versions mineures.
  7. Voir la phase de durée de vie prolongée description
  8. La prise en charge étendue des mises à jour (EUS) et la prise en charge étendue du cycle de vie (ELS) sont disponibles en tant que modules complémentaires en option. Voir les EUS et ELS descriptions
  9. Uniquement pour les installations existantes. Voir les détails dessous pour les autres limitations.
  10. Consultez la Classification de la gravité des problèmes pour les classifications de gravité de la sécurité.
  11. Tous les errata sont fournis à la discrétion de Red Hat.
  12. S’applique à la version 7 de RHEL ; ne s’applique pas à RHEL 8 & 9.
  13. Le support de maintenance pour RHEL 8 et 9 est l’équivalent du support de maintenance 2 pour toute la phase de maintenance.
  14. Image d’installation mise à jour fournie à la date de la première version mineure GA.

Guide de planification RHEL

Installation de VyOS sur KVM/Qemu

VyOS est un système d’exploitation de routeur et firewall opensource. Vous trouverez leur site ici. On le retrouve dans les clouds AWS, Azure… et bien évidemment sur KVM. Très pratique, avec OpenVSwitch, il fait partie des petits blocs d’infra qui vous font économiser beaucoup d’heures de recherche et d’argent… Il s’interconnecte avec par exemple une “Azure VNet Gateway”, Wireguard, GRE, BGP over IKEv2/IPsec. L’OS consomme moins de 512M de RAM et prend quelques centaines de Mo de place en stockage.

Installation de l’OS

On va chercher la bonne image sur la bonne page du site de l’éditeur. Je suis sympa, je vous mets l’url. Dans mon infra de test KVM/libvirt, j’ai un switch virtuel (OpenVSwitch) sur une IP WAN (ext-br-network) et un réseau isolé (internal). On va créer une nouvelle VM dans libvirt :

virt-install -n vyos_r1 \
   --ram 4096 \
   --vcpus 2 \
   --cdrom /var/lib/libvirt/images/vyos-1.3-rolling-202012041912-amd64.iso \
   --os-type linux \
   --os-variant debian10 \
   --network network=ext-br-network,model=virtio \ # c'est un réseau sur mon OpenVSwitch sur le WAN 
   --network network=internal,model=virtio \ # c'est un réseau isolé
   --graphics vnc,port=5999 \
   --hvm \
   --virt-type kvm \
   --disk path=/var/lib/libvirt/images/vyos_r1.qcow2,bus=virtio,size=8 \
   --noautoconsole

On entre dans l’OS, on change les locales et on installe l’OS (ou pas, dans ce cas il est chargé en ram et il faut créer une image avec les scripts de configuration)

sudo loadkeys fr
sudo dpkg-reconfigure keyboard-configuration
install image

Configuration simple avec deux cartes réseau

configure
set interfaces ethernet eth0 address dhcp
set interfaces ethernet eth1 address '192.168.200.254/24'
set service ssh port '22' # à partir de là le routeur est accessible en ssh, donc la conf peut-être terminée via SSH, Ansible
set nat source rule 100 outbound-interface 'eth0'
set nat source rule 100 source address '192.168.200.0/24'
set nat source rule 100 translation address masquerade
commit
save
exit

show interface
ping 8.8.8.8 interface 192.168.1.80 (en fonction)
ping 8.8.8.8 interface 192.168.200.254

Configuration du DHCP si besoin

set service dhcp-server disabled 'false' # version <~ 1.1.8
set service dhcp-server shared-network-name LAN subnet 192.168.200.0/24 default-router '192.168.200.254'
set service dhcp-server shared-network-name LAN subnet 192.168.200.0/24 dns-server '192.168.200.254'
set service dhcp-server shared-network-name LAN subnet 192.168.200.0/24 domain-name 'internal.domain.tld'
set service dhcp-server shared-network-name LAN subnet 192.168.200.0/24 lease '86400'
set service dhcp-server shared-network-name LAN subnet 192.168.200.0/24 start '192.168.200.10' stop '192.168.200.253' # version <~ 1.1.8
set service dhcp-server shared-network-name LAN subnet 192.168.200.0/24 range 0 start '192.168.200.9'
set service dhcp-server shared-network-name LAN subnet 192.168.200.0/24 range 0 stop '192.168.200.253'

On configure le DNS forwarding

set service dns forwarding cache-size '0'
#set service dns forwarding listen-on 'eth1' # version <~ 1.1.8
set service dns forwarding listen-address '192.168.200.254'
set service dns forwarding allow-from '192.168.200.0/24'
set service dns forwarding name-server '8.8.8.8'
set service dns forwarding name-server '8.8.4.4'

Voilà, à ce niveau le routeur est fonctionnel !

Mise en place des firewalls

set firewall name OUTSIDE-IN default-action 'drop'
set firewall name OUTSIDE-IN rule 10 action 'accept'
set firewall name OUTSIDE-IN rule 10 state established 'enable'
set firewall name OUTSIDE-IN rule 10 state related 'enable'

set firewall name OUTSIDE-LOCAL default-action 'drop'
set firewall name OUTSIDE-LOCAL rule 10 action 'accept'
set firewall name OUTSIDE-LOCAL rule 10 state established 'enable'
set firewall name OUTSIDE-LOCAL rule 10 state related 'enable'
set firewall name OUTSIDE-LOCAL rule 20 action 'accept'
set firewall name OUTSIDE-LOCAL rule 20 icmp type-name 'echo-request'
set firewall name OUTSIDE-LOCAL rule 20 protocol 'icmp'
set firewall name OUTSIDE-LOCAL rule 20 state new 'enable'
set firewall name OUTSIDE-LOCAL rule 30 action 'drop'
set firewall name OUTSIDE-LOCAL rule 30 destination port '22'
set firewall name OUTSIDE-LOCAL rule 30 protocol 'tcp'
set firewall name OUTSIDE-LOCAL rule 30 recent count '4'
set firewall name OUTSIDE-LOCAL rule 30 recent time '60'
set firewall name OUTSIDE-LOCAL rule 30 state new 'enable'
set firewall name OUTSIDE-LOCAL rule 31 action 'accept'
set firewall name OUTSIDE-LOCAL rule 31 destination port '22'
set firewall name OUTSIDE-LOCAL rule 31 protocol 'tcp'
set firewall name OUTSIDE-LOCAL rule 31 state new 'enable'

et on applique la configuration à la carte réseau :

set interfaces ethernet eth0 firewall in name 'OUTSIDE-IN'
set interfaces ethernet eth0 firewall local name 'OUTSIDE-LOCAL'

Automatisation

On peut exécuter un script pour automatiser la configuration, il doit être appelé par le groupe vyattacfg avec la commande switch group sg, ce qui donne :

sg vyattacfg -c ./conf-network.sh

#!/bin/vbash
source /opt/vyatta/etc/functions/script-template
configure
set interfaces ethernet eth0 address dhcp
set interfaces ethernet eth1 address '192.168.200.254/24'
set service ssh port '22'
set nat source rule 100 outbound-interface 'eth0'
set nat source rule 100 source address '192.168.200.0/24'
set nat source rule 100 translation address masquerade
set service dhcp-server shared-network-name LAN subnet 192.168.200.0/24 default-router '192.168.200.254'
set service dhcp-server shared-network-name LAN subnet 192.168.200.0/24 dns-server '192.168.200.254'
set service dhcp-server shared-network-name LAN subnet 192.168.200.0/24 domain-name 'internal.domain.tld'
set service dhcp-server shared-network-name LAN subnet 192.168.200.0/24 lease '86400'
set service dhcp-server shared-network-name LAN subnet 192.168.200.0/24 range 0 start '192.168.200.9'
set service dhcp-server shared-network-name LAN subnet 192.168.200.0/24 range 0 stop '192.168.200.253'
set service dns forwarding cache-size '0'
set service dns forwarding listen-address '192.168.200.254'
set service dns forwarding allow-from '192.168.200.0/24'
set service dns forwarding name-server '8.8.8.8'
commit
save
exit

Autre solution “maison”, un vieux script des familles qui permet de tout faire depuis l’hyperviseur :

#!/bin/bash
name="vyos_r1"
user="vyos"
password="vyos"
dns_ip="192.168.1.34"

function main() {
  launch
  sleep 40
  install
  sleep 10
  config
}

function launch() {
  sudo virt-install -n $name \
   --ram 4096 \
   --vcpus 2 \
   --cdrom /var/lib/libvirt/images/vyos-1.3-rolling-202012041912-amd64.iso \
   --os-type linux \
   --os-variant debian10 \
   --network network=ext-br-network,model=virtio \
   --network network=internal,model=virtio \
   --graphics vnc,port=5999 \
   --hvm \
   --virt-type kvm \
   --disk path=/var/lib/libvirt/images/$name.qcow2,bus=virtio,size=8 \
   --noautoconsole
}

function install() {
  sudo expect <<EOF
  set timeout 600
  spawn virsh console $name
  expect "Escape character is ^] (Ctrl + ])" {send "\n"}
  expect "vyos login:" {send "$user\r"}
  expect "Password:" {send "$password\r"}
  expect "vyos:~" {send "install image\r"}   expect "Would you like to continue? (Yes/No): " {send "Yes\n"}
  expect "Partition (Auto/Parted/Skip):" {send "Auto\n"}   expect "Install the image on?:" {send "\n"}
  expect "Continue? (Yes/No):" {send "Yes\n"}   expect "How big of a root partition should I create? (2000MB - 8589MB):" {send "8589MB\n"}
  expect "What would you like to name this image?:" {send "\n"}   expect "Which one should I copy to vda?:" {send "\n"}
  expect "Enter password for user 'vyos':" {send "$password\n"}
  expect "Retype password for user 'vyos':" {send "$password\n"}
  expect "Which drive should GRUB modify the boot partition on?:" {send "\n"}   expect "vyos:~" {send "sudo reboot\r"}
  expect "Are you sure you want to reboot this system?" {send "Yes\r"}
EOF
}

function config() {
  sudo virsh start $name
  sleep 50
  sudo expect <<EOF
  set timeout 600
  spawn virsh console $name
  expect "Escape character is ^] (Ctrl + ])" {send "\n"}
  expect "vyos login:" {send "$user\r"}
  expect "Password:" {send "$password\r"}
  send "sudo loadkeys fr\r"
  send "configure\r"
  send "set interfaces ethernet eth0 address dhcp\r"
  send "set interfaces ethernet eth1 address '192.168.200.254/24'\r"
  send "set service ssh port '22'\r"
  send "set nat source rule 100 outbound-interface 'eth0'\r"
  send "set nat source rule 100 source address '192.168.200.0/24'\r"
  send "set nat source rule 100 translation address masquerade\r"
  send "set service dhcp-server shared-network-name LAN subnet 192.168.200.0/24 default-router '192.168.200.254'\r"
  send "set service dhcp-server shared-network-name LAN subnet 192.168.200.0/24 dns-server '192.168.200.254'\r"
  send "set service dhcp-server shared-network-name LAN subnet 192.168.200.0/24 domain-name 'internal.domain.tld'\r"
  send "set service dhcp-server shared-network-name LAN subnet 192.168.200.0/24 lease '86400'\r"
  send "set service dhcp-server shared-network-name LAN subnet 192.168.200.0/24 range 0 start '192.168.200.9'\r"
  send "set service dhcp-server shared-network-name LAN subnet 192.168.200.0/24 range 0 stop '192.168.200.253'\r"
  send "set service dns forwarding cache-size '0'\r"
  send "set service dns forwarding listen-address '192.168.200.254'\r"
  send "set service dns forwarding allow-from '192.168.200.0/24'\r"
  send "set service dns forwarding name-server '$dns_ip'\r"
  send "commit\r"
  send "save\r"
  send "exit\r"
EOF
}
main
exit 0

Et voilà, un routeur fonctionnel avec un seul script… Pensez à modifier ce script pour durcir la sécurité d’accès au routeur en changeant le second mot de passe et en modifiant la config ssh pour accepter les clés. Je mets le lien vers les blueprints de VyOS (notamment dans des environnements Cloud) :

https://docs.vyos.io/en/latest/configexamples/index.html

@+

Créer un module scalable avec Terraform

Je profite de la fin du confinement qui n’en finit plus de finir pour continuer de jouer avec ma récente découverte : Terraform. Comme j’en parlais dans de précédents articles, la force de Terraform vient d’une part de sa capacité à pouvoir “dialoguer” avec différents fournisseurs de Cloud, d’autre part de rendre trivial la “scalabilité” de l’infra. On peut parfaitement en cas de montée de charge sur une application, décider de créer par exemple, un serveur supplémentaire dédié au cache (un slave Redis).

Poursuivre la lecture « Créer un module scalable avec Terraform »

Installer Nextcloud sur Fedora Servers Cloud grâce à Terraform et Ansible, part2

Vue d’ensemble du code de provision des VMs

Maintenant que l’on a notre code pour l’infra, il est temps de passer à la partie provision des vms. Pour cela, comme je vous le disais, j’utilise Ansible. Pourquoi ? Parce qu’il est de plus en plus inclus dans l’écosystème RedHat, que la communauté autour du projet est très vivante et que l’on n’a aucun de mal à trouver des infos. Je vous rappelle que ce code met à disposition des serveurs dans un réseau isolé. Je vous montre l’arborescence des rôles et playbooks en fonction de mon architecture :

Poursuivre la lecture « Installer Nextcloud sur Fedora Servers Cloud grâce à Terraform et Ansible, part2 »

Installer Nextcloud sur Fedora Servers Cloud grâce à Terraform et Ansible, part1

Aujourd’hui, je vais vous exposer un de mes POC. Je voulais installer Nexcloud sur Fedora server et pour plus de sécurité et plus d’efficacité, séparer les middlewares et les applications sur ces différents serveurs. Je pars sur 3 serveurs, on peut faire évoluer le code pour en ajouter plus, notamment Redis en master-slave, Mariadb en Master/Slave et un loadbalancer nginx. Je mets en ligne un de mes premiers codes Terraform fonctionnel. Il est plus simple à comprendre mais pas super optimisé/industrialisé. Dans des articles ultérieurs, je mettrai des codes Terraform pour de l’infra scalable, c’est plus sexy. J’ai essayé dans les playbooks ansible d’adapter les règles SElinux pour que l’application Nextcloud fonctionne en mode enforcing, et ça passe: c’est toujours mieux avec. Un truc sympa à faire également au niveau sécu, serait de relier le chiffrement de Nextcloud à la puce TPM émulée du serveur, dans le même registre je n’ai pas mis de rôle pour le durcissement des souches Fedora. Tout un programme…

Poursuivre la lecture « Installer Nextcloud sur Fedora Servers Cloud grâce à Terraform et Ansible, part1 »

Installer Openvswitch sous Fedora avec NetworkManager

Introduction

On ne présente plus Openvswitch, une brique importante du SDN (Software-defined networking). OpenvSwitch est destiné aux déploiements de virtualisation multi-serveurs. Les possibilités d’OVS sont nombreuses, il gère les vlans, la QoS, OpenFlow, le bonding, le mirroring. Il supporte Xen, KVM, Proxmox, Virtualbox et est intégré dans Openstack, openQRM, OpenNebula et oVirt. Poursuivre la lecture « Installer Openvswitch sous Fedora avec NetworkManager »

Penser sa chaîne d’automatisation de A à Z en mode #DevOps


Continuous Delivery

De nos jours, il faut aller de plus en plus rapidement pour délivrer du contenu, des services, des applications et même des serveurs. Pour se faire, la technologie de virtualisation a pris une place importante voire primordiale dans l’informatique et le monde des SI. La virtualisation mais aussi … le code !
Qui dit rapidité dit automatisation, pas de rapidité avec des clics next… next… next… devant un écran. C’est la dure loi de l’informatique moderne.

Poursuivre la lecture « Penser sa chaîne d’automatisation de A à Z en mode #DevOps »