Red Hat Training

A Red Hat training course is available for Red Hat Satellite

Guide de configuration du client

Red Hat Network Satellite 5.4

Red Hat Network Satellite

Édition 1

Résumé

Bienvenue sur le guide de configuration du client Red Hat Network Satellite

Chapitre 1. IntroductionIntroduction

Ce guide est conçu pour aider les clients du RHN Satellite Server et du RHN Proxy Server à configurer plus facilement leurs systèmes client.
Par défaut, toutes les applications client Red Hat Network sont configurées pour communiquer avec les serveurs Red Hat Network centraux. Si vous connectez des clients à un RHN Satellite Server ou un RHN Proxy Server à la place, nombreux de ces paramètres doivent être modifiés. Modifier les paramètres client d'un système ou deux est une opération relativement simple. Un grand environnement d'entreprise, contenant des centaines ou des milliers de systèmes, bénéficieront des étapes de reconfiguration en groupe décrites ici.
Vu la complexité de ce projet, les clients peuvent utiliser un script déjà écrit qui automatise de nombreuses tâches nécessaires pour accéder à leur serveur Satellite ou Proxy. Consultez le Chapitre 5, Utilisation de RHN Bootstrap pour davantage d'informations. Red Hat pense que comprendre les implications de ces changements est utile et décrit donc les étapes du manuel pour la reconfiguration dans les premiers chapitres. Utilisez votre jugement pour déterminer la meilleure solution pour votre organisation.
Bien que nombreuses des commandes fournies dans ce guide peuvent être appliquées comme elles apparaissent, il est impossible de prédire toutes les configurations réseau potentielles adoptées par les clients. Red Hat vous encourage donc d'utiliser ces commandes comme références qui prennent en compte les paramètres individuels de votre organisation.

Note

Des informations sur la configuration de clients Unix se trouvent dans le Guide de référence du RHN Satellite Server dans le chapitre Support Unix.

Chapitre 2. Applications client

Pour utiliser la plupart des fonctions de classe entreprise de Red Hat Network, comme l'enregistrement avec un Satellite RHN, la configuration des applications client les plus récentes est requise. Il peut être difficile d'obtenir ces applications avant que le client ne soit enregistré avec Red Hat Network. Ce paradoxe est particulièrement problématique pour les clients qui migrent de grands nombres de vieux systèmes vers Red Hat Network. Ce chapitre identifie les techniques pour résoudre ce dilemme.

Important

Red Hat recommande fortement que les clients connectés à un RHN Proxy Server ou un RHN Satellite Server exécutent la dernière mise à jour de Red Hat Enterprise Linux pour assurer la bonne connectivité.
De plus, si les pare-feu du client sont configurés, les ports 80 et 443 doivent être ouverts pour qu'ils puissent fonctionner correctement avec Red Hat Network.

2.1. Déploiement des derniers RPM client de Red Hat Network

L'applicationPackage Updater (Mise à jour des paquetages) (pup), yum, et Red Hat Network Registration Client (rhn_register) sur Red Hat Enterprise Linux 5 (up2date sur des anciennes versions de Red Hat Enterprise Linux) sont des pré-requis pour utiliser la plupart des fonctionnalités de Red Hat Network. Il est crucial de les installer sur les systèmes client avant d'essayer d'utiliser le RHN Proxy Server ou le RHN Satellite Server dans votre environnement.
Il existe plusieurs approches raisonnables pour accomplir cette mise à jour de logiciels client de RHN. L'une d'entre elles implique le stockage des RPM dans un emplacement qui est accessible à tous les systèmes client et le déploiement des paquetages avec la commande la plus simple possible. Dans pratiquement tous les cas, un déploiement manuel de yum, pup, et rhn_register (up2date pour une ancienne version de Red Hat Enterprise Linux) n'a pas à être effectué. Ces outils client ne devraient avoir aucun problème à se connecter à votre environnement de Satellite ou Proxy RHN. La discussion ci-dessous assume que les commandes yum, pup, et rhn_register (ou up2date) installées de la boîte, ne sont pas les plus récentes et ne fonctionnent pas pour votre environnement.
Souvenez-vous que seuls les systèmes qui exécutent Red Hat Enterprise Linux 5 doivent utiliser firstboot après installation ou rhn_register pour s'enregistrer avec RHN. Les systèmes qui exécutent Red Hat Enterprise Linux 3 et 4 peuvent utiliser la fonction d'enregistrement intégrée dans l'Red Hat Update Agent.
Ce document présume que le client a installé au moins un RHN Satellite Server et/ou un RHN Proxy Server sur son réseau. L'exemple ci-dessous démontre une approche simple pour déployer yum, pup, et rhn_register (ou up2date) pour la première fois par un administrateur, en supposant que les machines n'ont pas encore un RHN fonctionnant. L'administrateur a rempli le répertoire /var/www/html/pub/ avec une copie des RPM de yum, pup, et rhn_register (ou up2date) dont ses systèmes client ont besoin, puis a simplement déployé ces RPM sur ses systèmes client avec une commande rpm -Uvh. Exécutée depuis un client, cette commande installe les RPM sur ce client, en supposant que le nom de domaine, les chemins et les versions de RPM sont corrects (remarquez que cette commande a été divisée sur de multiples lignes afin de pouvoir être imprimée ou mise sous le format PDF mais que celle-ci doit être saisie sur une seule ligne dans une invite shell) :
rpm -Uvh
http://your_proxy_or_sat.your_domain.com/pub/rhn-setup-0.4.17-8.el5.i386.rpm
http://your_proxy_or_sat.your_domain.com/pub/yum-3.2.8-9.el5.i386.rpm
http://your_proxy_or_sat.your_domain.com/pub/pirut-1.3.28-13.3l5.noarch.rpm
N'oubliez pas que l'architecture (dans ce cas, i386) peut être changée selon les systèmes à servir.

2.2. Configuration des applications client

Tous les clients n'ont pas à se connecter de manière sécurisée à un RHN Satellite Server ou un RHN Proxy Server au sein de leur organisation. Tous les clients n'ont pas à construire et déployer une clé GPG pour les paquetages personnalisés. (Ces deux sujets sont expliqués plus en détails ultérieurement). Chaque client qui utilise le RHN Satellite Server ou le RHN Proxy Server doit reconfigurer l'Red Hat Update Agent (up2date) et probablement le Red Hat Network Registration Client (rhn_register) pour le rediriger de Red Hat Network à leur RHN Satellite Server ou RHN Proxy Server.

Important

Bien que cela ne soit pas configurable, notez que le port utilisé par l'up2date est 443 pour les HTTP sécurisés (HTTPS) et 80 pour les autres (HTTP). Par défaut, sur Red Hat Enterprise Linux 5, yum utilise uniquement SSL. Pour cette raison, les utilisateurs devraient s'assurer que leurs pare-feu autorisent les connexions sur le port 443. Pour contourner SSL, changez le protocole pour serverURL, remplacez https par http dans /etc/sysconfig/rhn/up2date. De manière similaire, pour utiliser la fonction Monitoring et les sondes de RHN nécessitant le Red Hat Network Monitoring Daemon, notez que les systèmes client doivent autoriser les connexions sur le port 4545 (ou le port 22, si vous utilisez sshd à la place).
Par défaut, le rhn_register et up2date font référence aux principaux serveurs Red Hat Network. Les utilisateurs doivent reconfigurer les systèmes client pour faire référence à leur RHN Satellite Server ou RHN Proxy Server.
Remarquez que les dernières versions de l'Red Hat Update Agent peuvent être configurées pour satisfaire plusieurs serveurs RHN, fournissant ainsi une protection contre les défaillances au cas où le serveur primaire n'est pas accessible. Consultez la Section 2.2.4, « Implémentation du failover du serveur » pour obtenir des instructions sur l'activation de cette fonction.
The next sections describe different methods of configuring the client systems to access your RHN Satellite Server or RHN Proxy Server. To see how virtually all reconfiguration can be scripted, see Chapitre 6, Écrire manuellement la configuration dans un script.

2.2.1. Enregistrement avec les clés d'activation

Red Hat recommande l'utilisation de clés d'activation pour l'enregistrement et la configuration de systèmes client qui accèdent au RHN Proxy Server ou au RHN Satellite Server. Les clés d'activation peuvent être utilisées pour enregistrer, donner droit et abonner des systèmes par lots. Reportez-vous à la section "Clés d'activation" du Guide de référence RHN Satellite Server pour des instructions sur l'activation des clés.
L'enregistrement avec une clé d'activation suit quatre étapes de base :
  1. Générer une clé d'activation
  2. Importer les clés GPG personnalisées.
  3. Télécharger et installer le RPM de certificat SSL du répertoire /pub/ du RHN Proxy Server ou du RHN Satellite Server. La commande pour cette étape peut ressembler à l'exemple suivant :
    rpm -Uvh http://your-satellite-FQDN/pub/rhn-org-trusted-ssl-cert-1.0-1.noarch.rpm
    
  4. Enregistrer le système avec votre RHN Proxy Server ou RHN Satellite Server. La commande pour cette étape peut ressembler à l'exemple suivant :
     rhnreg_ks --activationkey mykey --serverUrl https://your-satellite-FQDN/XMLRPC 
Alternativement, la plupart des étapes décrites ci-dessus peuvent être combinées en un script shell incluant les lignes suivantes (remarquez que cette commande a été divisée sur de multiples lignes afin de pouvoir être imprimée ou mise sous le format PDF mais celle-ci doit être saisie sur une seule ligne dans une invite shell) :
wget -0 - http://your-satellite-FQDN/pub/bootstrap.sh | bash
&& rhnreg_ks --activation-key my_key --serverUrl
https://your-satellite-FQDN/XMLRPC
Le script bootstrap, généré à l'installation et disponible pour le RHN Satellite Server et RHN Proxy Server, est l'un de ces scripts. Le script et RHN Bootstrap qui le génère sont examinés en détails dans le Chapitre 5, Utilisation de RHN Bootstrap.

Avertissement

Les systèmes qui exécutent Red Hat Enterprise Linux 2.1 et des versions de Red Hat Linux inférieures à 8.0 peuvent rencontrer des problèmes lors de l'utilisation de clés d'activation pour migrer les paramètres du certificat SSL de rhn_register à up2date. Les informations du certificat SSL sur ces systèmes doivent donc être définies manuellement. Tous les autres paramètres, comme l'URL du serveur, sont transférés proprement.

2.2.2. Utilisation de l'option up2date --configure

Le Red Hat Update Agent de Red Hat Enterprise Linux 3 et 4 fournissent une interface pour la configuration de divers paramètres. Pour obtenir la liste complète de ces paramètres, reportez-vous aux pages de manuel up2date (man up2date à une ligne de commande).
Pour reconfigurer l'Red Hat Update Agent, exécutez la commande suivante en tant que super-utilisateur :
 up2date --configure 
Une boîte de dialogue est affichée offrant divers paramètres qui peuvent être reconfigurés. Dans l'onglet Général, sous Sélectionnez un serveur Red Hat Network à utiliser, remplacez la valeur par défaut par le nom de domaine (FQDN) du RHN Satellite Server ou du RHN Proxy Server, comme par exemple https://votre_proxy_ou_sat.votre_domaine.com/XMLRPC. Gardez la partie /XMLRPC à la fin. Une fois terminé, cliquez sur Valider.
Configuration GUI de l'Red Hat Update Agent

Figure 2.1. Configuration GUI de l'Red Hat Update Agent

Assurez-vous de saisir correctement le nom de domaine de votre RHN Satellite Server ou RHN Proxy Server. La saisie d'un domaine incorrect ou laisser le champ vide peut empêcher le lancement de up2date --configure. Ce problème peut cependant être résolu en modifiant la valeur dans le fichier de configuration up2date. Reportez-vous à la Section 2.2.3, « Mise à jour manuelle des fichiers de configuration » pour des instructions précises.

Avertissement

Les systèmes qui exécutent Red Hat Enterprise Linux 3 ou 4 ont la fonction d'enregistrement intégrée dans l'Red Hat Update Agent et n'installent donc pas le Red Hat Network Registration Client. Les systèmes qui exécutent Red Hat Enterprise Linux 5 n'utilisent pas la commande up2date, et ont besoin de rhn_register pour enregistrer leurs systèmes dans RHN ou Satellite et les commandes yum et pup pour mettre leurs paquetages à jour.

2.2.3. Mise à jour manuelle des fichiers de configuration

Comme alternative à l'interface GUI décrite dans la section précédente, les utilisateurs peuvent également reconfigurer le Red Hat Update Agent en éditant les fichiers de configuration des applications.
Pour configurer l'Red Hat Update Agent sur les systèmes client qui se connectent au RHN Proxy Server ou au RHN Satellite Server, éditez les valeurs des paramètres serverURL et noSSLServerURL dans le fichier de configuration /etc/sysconfig/rhn/up2date (en tant que super-utilisateur). Remplacez l'URL de Red Hat Network par défaut par le nom de domaine (FQDN) pour le RHN Proxy Server ou le RHN Satellite Server. Par exemple :
serverURL[comment]=Remote server URL
serverURL=https://your_primary.your_domain.com/XMLRPC

noSSLServerURL[comment]=Remote server URL without SSL
noSSLServerURL=http://your_primary.your_domain.com/XMLRPC

Avertissement

Le paramètre httpProxy dans /etc/sysconfig/rhn/up2date ne réfère pas au RHN Proxy Server. Il est utilisé pour configurer un proxy HTTP optionnel pour le client. Avec un RHN Proxy Server en place, le paramètre httpProxy doit être vide (défini à aucune valeur).

2.2.4. Implémentation du failover du serveur

En commençant par up2date-4.2.38, l'Red Hat Update Agent peut être configuré pour chercher des mises à jour depuis une série de serveurs RHN. Ceci peut être particulièrement utile pour garder des mises à jour constantes si votre RHN Proxy Server ou RHN Satellite Server primaire peut être mis hors ligne.
Pour utiliser cette fonction, assurez-vous tout d'abord que vous exécutez la version requise de up2date. Puis, ajoutez manuellement les serveurs secondaires aux paramètres serverURL et noSSLServerURL dans le fichier de configuration /etc/sysconfig/rhn/up2date (en tant que super-utilisateur). Ajoutez les noms de domaine (FQDN) pour le Proxy ou le Satellite immédiatement après le serveur primaire, séparés par un point-virgule (;). Par exemple :
serverURL[comment]=Remote server URL
serverURL=https://your_primary.your_domain.com/XMLRPC; 
https://your_secondary.your_domain.com/XMLRPC;

noSSLServerURL[comment]=Remote server URL without SSL
noSSLServerURL=http://your_primary.your_domain.com/XMLRPC; 
https://your_secondary.your_domain.com/XMLRPC;
La connexion aux serveurs est temptée dans l'ordre fourni ici. Vous pouvez inclure autant de serveurs que vous souhaitez. Vous pouvez également lister les serveurs RHN centraux. Cela n'a cependant de sens que si les systèmes client peuvent atteindre Internet.

2.3. L'applet de mise à jour de paquetage

Red Hat Enterprise Linux 5 comprend un programme d'exécution sur l'écran graphique du bureau, qui vérifie périodiquement les mises à jour à partir des serveurs RHN ou Satellite et qui vont alerter les utilisateurs quand une nouvelle mise à jour sera rendue disponible.
Applet de mise à jour de paquetage

Figure 2.2. Applet de mise à jour de paquetage

L'applet de mise à jour de paquetage demeure dans le plateau de notification de le tableau de bord du bureau et vérifie les nouvelles mises à jour périodiquement. Cet applet vous permet également d'effectuer quelques tâches de maintenance de paquetages à partir de ce applet en cliquant l'icône de notification et en choisissant une des actions suivantes :
  • Rafraîchir - Vérifier RHN ou le Satellite pour les nouvelles mises à jour
  • Voir les mises à jour - lance l'application de mise à jour des paquetages afin que vous puissiez voir toute mise à jour de disponible en détails et que vous puissiez configurer les mises à jour de vos spécifications.
  • Appliquer les mises à jour - Décharger et installer les paquetages mis à jour.
  • Quitter - fermer l'applet

2.4. Configuration de l'Red Hat Network Alert Notification Tool avec le Satellite

L'Red Hat Network Alert Notification Tool, l'icône ronde dans le tableau de bord de votre bureau Red Hat Enterprise Linux 3 ou 4, peut être configuré sur les systèmes qui exécutent Red Hat Enterprise Linux 3 ou une version supérieure pour reconnaître les mises à jour disponibles depuis les canaux personnalisés sur votre RHN Satellite Server. Vous devez vous assurer que le RHN Satellite Server est configuré pour supporter cette fonction. (Le RHN Proxy Server supporte l'applet sans modification du client ou du serveur.) Les étapes pour configurer l'Red Hat Network Alert Notification Tool sont les suivantes :
  1. Assurez-vous que votre RHN Satellite Server est la version 3.4 ou supérieure et que vous avez le paquetage rhns-applet installé sur le Satellite. Le paquetage se trouve dans le canal logiciel du Satellite RHN pour les versions 3.4 ou plus récentes.
  2. Obtenez le paquetage rhn-applet-actions avec up2date ou via le canal logiciel Red Hat Network Tools. Installez le paquetage sur tous les systèmes client Red Hat Enterprise Linux 3 et plus récents pour qu'ils soient avertis de mises à jour personnalisées avec l'Red Hat Network Alert Notification Tool. Les systèmes client doivent avoir droit au niveau de service Management ou Provisioning.
  3. Dans la version du site Web de RHN du Satellite, rendez-vous sur la page Détails sur le système pour chaque système et cliquez sur le lien dans la zone Applet RHN pour rediriger l'Red Hat Network Alert Notification Tool vers le Satellite.
Au prochain lancement de l'applet, il appliquera sa nouvelle configuration et se connectera au RHN Satellite Server pour des mises à jour.

Chapitre 3. Infrastructure SSL

Pour les clients de Red Hat Network, le sujet de la sécurité est de la plus grande importance. L'une des forces de Red Hat Network est sa capacité de traiter chaque requête sur SSL (Secure Sockets Layer, couche de sockets sécurisés). Pour garder ce niveau de sécurité, les clients qui installent Red Hat Network dans leurs infrastructures doivent générer des clés et des certificats SSL personnalisés.
La création et le déploiement manuels des clés et des certificats SSL peuvent demander une implication importante. Le RHN Proxy Server et le RHN Satellite Server vous permettent de construire vos propres clés et certificats SSL selon votre propre CA (Certificate Authority) privé durant l'installation. De plus, un utilitaire en ligne commande, l'RHN SSL Maintenance Tool, existe dans ce but. Dans tous les cas, ces clés et certificats doivent ensuite être déployés sur tous les systèmes au sein de votre infrastructure gérée. Dans de nombreux cas, le déploiement de ces clés et ces certificats SSL est automatisé pour vous. Ce chapitre décrit des méthodes efficaces pour mener toutes ces tâches à bien.
Veuillez noter que ce chapitre n'explique pas SSL en profondeur. L'RHN SSL Maintenance Tool a été conçu pour cacher la plus grande partie de la complexité impliquée dans la configuration et la maintenance de cette infrastructure de clé publique (PKI, public-key infrastructure). Pour davantage d'informations, consultez parmi les bonnes références disponibles dans votre librairie.

3.1. Une brève introduction à SSL

SSL, de l'anglais Secure Sockets Layer ou couche de sockets sécurisés, est un protocole qui permet aux applications client-serveur de transmettre des informations de manière sécurisée. SSL utilise un système de paires de clés publiques et privées pour crypter les communications passées entre les clients et les serveurs. Les certificats publics peuvent être accessibles, alors que les clés privées doivent être sécurisées. La relation mathématique (une signature numérique) entre la clé privée et son certificat public de paire fait en sorte que ce système fonctionne. Grâce à cette relation, une connexion de confiance est établie.

Note

Tout au long de ce document, nous étudierons les clés privées et les certificats publics SSL. D'un point de vue technique, les deux peuvent être appelés clés (clés publiques et privées). Cependant, la convention, au sujet de SSL, est de faire référence à la moité publique d'une paire de clés SSL (ou ensemble de clés) en tant que le certificat SSL public.
L'infrastructure SSL d'une organisation est en général composée des clés et des certificats SSL suivants :
  • La clé privée et le certificat public SSL CA (Certificate Authority) — généralement seulement une paire de valeurs générée par organisation. Le certificat public est signé numériquement par sa clé privée. Le certificat public est distribué à chaque système.
  • La clé privée et le certificat public SSL du serveur Web — une paire de valeurs par serveur d'applications. Le certificat public est signé numériquement par sa clé privée et la clé privée SSL CA. Nous faisons souvent référence à l'ensemble de clés d'un serveur Web. En effet, une requête de certificat SSL intermédiaire est générée. Les détails de l'utilisation de cette requête ne sont pas importants dans le cas présent. Les trois sont déployés sur un serveur RHN.
Voici un scénario : si vous avez un RHN Satellite Server et cinq RHN Proxy Server, vous générerez une paire de clés SSL CA et six ensembles de clés SSL du serveur Web. Le certificat SSL CA public est distribué à tous les systèmes et utilisé par tous les clients pour établir une connexion avec leurs serveurs supérieurs respectifs. Chaque serveur possède son propre ensemble de clés SSL qui est lié spécifiquement au nom d'hôte de ce serveur et généré à l'aide de sa propre clé SSL privée et de la clé SSL CA privée. Cela établit une association vérifiable numériquement entre le certificat SSL public du serveur Web et la paire de clé SSL CA et la clé privée du serveur. L'ensemble de clés du serveur Web ne peut pas être partagé avec d'autres serveurs Web.

Important

La partie la plus critique de ce système est la paire de clés SSL CA. De cette clé privée et de ce certificat public, un administrateur peut régénérer tout ensemble de clés SSL du serveur Web. Cette paire de clés SSL CA doit être sécurisée. Il est hautement recommandé que, une fois que l'infrastructure SSL entière de serveurs est configurée et en cours d'exécution, vous archivez le répertoire de construction SSL généré par cet outil et/ou les installateurs sur un média séparé, écrivez le mot de passe CA et mettez en sécurité le média et le mot de passe.

3.2. L'RHN SSL Maintenance Tool

Red Hat Network fournit un outil en ligne de commande pour faciliter la gestion de votre infrastructure sécurisée : l'RHN SSL Maintenance Tool, connu habituellement par sa commande rhn-ssl-tool. Cet outil est disponible comme faisant partie du paquetage rhns-certs-tools. Ce paquetage se trouve dans les canaux logiciels pour le dernier RHN Proxy Server et le dernier RHN Satellite Server (ainsi que l'ISO du RHN Satellite Server). L'RHN SSL Maintenance Tool vous permet de générer votre propre paire de clés SSL CA, ainsi que les ensembles de clés SSL du serveur Web (parfois appelés paires de clés).
Cet outil est uniquement un outil de construction. Il génère toutes les clés et tous les certificats SSL qui sont requis. Il met également en paquetages les fichiers en format RPM pour une distribution et une installation rapides sur toutes les machines client. Par contre, il ne les déploie pas, l'administrateur doit le faire, ou dans de nombreux cas, cette opération est automatisée par le RHN Satellite Server.

Note

Le fichier rhns-certs-tools, qui contient rhn-ssl-tool, peut être installé et exécuté sur tout système Red Hat Enterprise Linux courant avec des besoins minimums. Cette facilité est offerte aux administrateurs qui souhaitent gérer leur infrastructure SSL depuis leur poste de travail ou un autre système autre que leur(s) serveur(s) RHN.
Voici les cas où l'outil est requis :
  • Lors de la mise à jour de votre certificat CA public, ce qui est rare.
  • Lors de l'installation d'un RHN Proxy Server version 3.6 ou une version supérieure qui se connecte aux serveurs RHN centraux comme son service de plus haut niveau - le service hébergé, pour des raisons de sécurité, ne peut pas être un dépôt pour votre clé et votre certificat SSL CA, qui sont privés à votre organisation.
  • Lors de la reconfiguration de votre infrastructure RHN pour utiliser SSL quand elle ne l'utilisait pas avant.
  • Lors de l'ajout de RHN Proxy Server de versions inférieures à 3.6 dans votre infrastructure RHN.
  • Lors de l'ajout de plusieurs RHN Satellite Server à votre infrastructure RHN - consultez un représentant de Red Hat pour obtenir des instructions à ce sujet.
Voici les cas où l'outil n'est pas requis :
  • Durant l'installation d'un RHN Satellite Server - tous les paramètres SSL sont configurés durant l'installation. Les clés et le certificat SSL sont construits et déployés automatiquement.
  • Durant l'installation d'un RHN Proxy Server version 3.6 ou une version supérieure si il est connecté à un RHN Satellite Server version 3.6 ou une version supérieure comme son plus haut niveau de service - le RHN Satellite Server contient toutes les informations SSL nécessaires pour configurer, construire et déployer les clés et certificats SSL du RHN Proxy Server.
Les procédures d'installation du RHN Satellite Server et du RHN Proxy Server assurent que le certificat SSL CA publique est déployé dans le répertoire /pub de chaque serveur. Ce certificat public est utilisé par les systèmes client pour se connecter au serveur RHN. Consultez la Section 3.3, « Déploiement du certificat SSL CA public sur les clients » pour davantage d'informations.
En bref, si l'infrastructure RHN de votre organisation déploie la dernière version du RHN Satellite Server comme son plus haut niveau de service, vous n'aurez sûrement pas besoin d'utiliser l'outil. Sinon, familiarisez vous à son utilisation.

3.2.1. Génération de SSL expliquée

Les avantages primaires de l'utilisation de l'RHN SSL Maintenance Tool sont les suivants : sécurité, flexibilité et portabilité. La sécurité est accomplie via la création de clés et de certificats SSL distincts du serveur Web pour chaque serveur RHN, tous signés par une seule paire de clés SSL CA créée par votre organisation. La flexibilité est fournie par la capacité de l'outil à fonctionner sur toute machine qui a le paquetage rhns-certs-tools installé. La portabilité existe dans une structure de construction qui peut être stockée n'importe où en garde et qui peut ensuite être installée n'importe où le besoin se présente.
Une fois de plus, si le serveur RHN supérieur de votre infrastructure est le RHN Satellite Server le plus récent, il se peut que tout ce que vous aurez à faire est de restaurer votre arborescence ssl-build d'une archive dans le répertoire /root/ et d'utiliser les outils de configuration fournis sur le site Web du RHN Satellite Server.
Pour utiliser l'RHN SSL Maintenance Tool à son maximum, exécutez les tâches suivantes de haut niveau dans l'ordre suivant. Reportez-vous aux sections restantes pour les informations requises :
  1. Installez le paquetage rhns-certs-tools sur un système dans votre organisation, peut-être mais pas forcément le RHN Satellite Server ou le RHN Proxy Server.
  2. Créez une seule paire de clés SSL CA pour votre organisation et installez le RPM ou le certificat public résultant sur tous les systèmes client.
  3. Créez un ensemble de clés SSL du serveur Web pour chaque Proxy et Satellite à déployer et installez les RPM résultants sur les serveurs RHN, en redémarrant le service httpd plus tard :
     /sbin/service httpd restart 
  4. Archivez l'arborescence de construction SSL - composée du répertoire de construction primaire et de tous les sous-répertoires et fichiers - sur un média amovible, comme une disquette. (Les besoins d'espace disque sont insignifiants.)
  5. Vérifiez puis stockez cette archive dans un endroit sécurisé, comme celui décrit pour les sauvegardes dans les sections Besoins supplémentaires du guide d'installation du Proxy ou du Satellite.
  6. Enregistrez et sécurisez le mot de passe CA pour une prochaine utilisation.
  7. Supprimez l'arborescence de construction depuis le système de construction pour des raisons de sécurité, mais uniquement lorsque l'entière infrastructure RHN est en place et configurée.
  8. Lorsque des ensembles de clés SSL du serveur Web sont nécessaires, restaurez l'arborescence de construction sur un système qui exécute l'RHN SSL Maintenance Tool et répétez les étapes 3 à 7.

3.2.2. Options de l'RHN SSL Maintenance Tool

L'RHN SSL Maintenance Tool offre une pléthore d'options en ligne de commande pour générer votre paire de clés SSL CA et pour gérer vos certificats et clés SSL de serveur. L'outil offre principalement trois listes d'aide sur les options en ligne de commande : rhn-ssl-tool --help (général), rhn-ssl-tool --gen-ca --help (Certificate Authority) et rhn-ssl-tool --gen-server --help (serveur Web). La page de manuel pour rhn-ssl-tool est également bien détaillée et disponible pour toute aide : man rhn-ssl-tool.
Les deux tables ci-dessous classifient les options par tâche associée, la génération d'ensembles de clés SSL CA ou du serveur Web.
Cet ensemble d'options doit être précédé de l'argument --gen-ca :

Tableau 3.1. Options SSL CA (rhn-ssl-tool --gen-ca --help)

Option Description
--gen-ca Génère une paire de clés et un RPM public CA (Certificate Authority). Elle doit être utilisée avec l'une des options restantes de cette table.
-h, --help Affiche l'écran d'aide avec une liste d'options de base spécifiques à la génération et la gestion d'un CA.
-f, --force Crée de force une nouvelle clé privée et/ou un nouveau certificat public CA.
-p=, --password=PASSWORD Le mot de passe CA. Le système vous le demandera si il n'est pas présent. Enregistrez le de manière sécurisée.
-d=, --dir=BUILD_DIRECTORY Requis pour la plupart des commandes - Le répertoire où les certificats et les RPM sont construits. La valeur par défaut est ./ssl-build.
--ca-key=FILENAME Le nom de fichier de la clé privée CA. La valeur par défaut est RHN-ORG-PRIVATE-SSL-KEY.
--ca-cert=FILENAME Le nom de fichier du certificat public CA. La valeur par défaut est RHN-ORG-TRUSTED-SSL-CERT.
--cert-expiration=CA_CERT_EXPIRE La date d'expiration du certificat public CA. La valeur par défaut est le nombre de jours jusqu'au jour avant le retour d'époque (ou 01-18-2038).
--set-country=COUNTRY_CODE Le code de deux lettres du pays. La valeur par défaut est US.
--set-state=STATE_OR_PROVINCE L'état ou la région du CA. La valeur par défaut est ''.
--set-city=CITY_OR_LOCALITY La ville ou le quartier. La valeur par défaut est ''.
--set-org=ORGANIZATION La société ou l'organisation, comme Red Hat. La valeur par défaut est Example Corp. Inc.
--set-org-unit=SET_ORG_UNIT L'unité organisationnelle, comme RHN. La valeur par défaut est ''.
--set-common-name=HOSTNAME Généralement pas défini pour le CA. - Le nom commun.
--set-email=EMAIL Généralement pas défini pour le CA. - L'adresse électronique.
--rpm-packager=PACKAGER Par qui le RPM généré est mis en paquetage, comme "RHN Admin (rhn-admin@example.com)."
--rpm-vendor=VENDOR Vendeur du RPM généré, comme "IS/IT Example Corp."
-v, --verbose Affiche des messages verbeux. Accumulatif - tout "v" supplémentaire augmente les détails.
--ca-cert-rpm=CA_CERT_RPM Rarement modifié - Le nom du RPM qui héberge le certificat CA (le nom de fichier de base, et non pas nomfichier-version-publication.noarch.rpm).
--key-only Rarement utilisé - Génère uniquement une clé privée CA. Consultez --gen-ca --key-only --help pour davantage d'informations.
--cert-only Rarement utilisé - Génère uniquement un certificat public CA. Consultez --gen-ca --cert-only --help pour davantage d'informations.
--rpm-only Rarement utilisé - Génère uniquement un RPM pour le déploiement. Consultez --gen-ca --rpm-only --help pour davantage d'informations.
--no-rpm Rarement utilisé - Exécute toutes les étapes concernant CA sauf la génération de RPM.
L'ensemble d'options suivant doit être précédé de l'argument --gen-server :

Tableau 3.2. Options SSL du serveur Web (rhn-ssl-tool --gen-server --help)

Option Description
--gen-server Génère l'ensemble de clés du serveur Web, le RPM et l'archive tar. Elle doit être utilisée avec l'une des options restantes de cette table.
-h, --help Affiche l'écran d'aide avec une liste d'options de base spécifiques à la génération et la gestion d'une paire de clés du serveur.
-p=, --password=PASSWORD Le mot de passe CA. Le système vous le demandera si il n'est pas présent. Enregistrez le de manière sécurisée.
-d=, --dir=BUILD_DIRECTORY Requis pour la plupart des commandes - Le répertoire où les certificats et les RPM sont construits. La valeur par défaut est ./ssl-build.
--server-key=FILENAME Le nom de fichier de la clé privée SSL du serveur Web. La valeur par défaut est server.key.
--server-cert-req=FILENAME Le nom de fichier de la requête de certificat SSL du serveur Web. La valeur par défaut est server.csr.
--server-cert=FILENAME Le nom de fichier du certificat SSL du serveur Web. La valeur par défaut est server.crt.
--startdate=YYMMDDHHMMSSZ La date de début pour la validité du certificat du serveur dans le format exemple : année, mois, jour, heure, minute, seconde (deux caractères par valeur). Z signifie Zulu et est requis. La valeur par défaut est une semaine avant la génération.
--cert-expiration=SERVER_CERT_EXPIRE La date d'expiration du certificat du serveur. La valeur par défaut est le nombre de jours jusqu'au jour avant le retour d'époque (ou 01-18-2038).
--set-country=COUNTRY_CODE Le code de deux lettres du pays. La valeur par défaut est US.
--set-state=STATE_OR_PROVINCE L'état ou la région du CA. La valeur par défaut est "North Carolina".
--set-city=CITY_OR_LOCALITY La ville ou le quartier. La valeur par défaut est "Raleigh".
--set-org=ORGANIZATION La société ou l'organisation, comme Red Hat. La valeur par défaut est Example Corp. Inc.
--set-org-unit=SET_ORG_UNIT L'unité organisationnelle, comme RHN. La valeur par défaut est "unit".
--set-hostname=HOSTNAME Le nom d'hôte du serveur RHN qui recevra la clé. La valeur par défaut est définie dynamiquement comme le nom d'hôte de la machine de construction.
--set-email=EMAIL L'adresse électronique du contact du certificat. La valeur par défaut est admin@example.corp.
--rpm-packager=PACKAGER Par qui le RPM généré est mis en paquetage, comme "RHN Admin (rhn-admin@example.com)."
--rpm-vendor=VENDOR Vendeur du RPM généré, comme "IS/IT Example Corp."
-v, --verbose Affiche des messages verbeux. Accumulatif - tout "v" supplémentaire augmente les détails.
--key-only Rarement utilisé - Génère uniquement une clé privée du serveur. Consultez --gen-server --key-only --help pour davantage d'informations.
--cert-req-only Rarement utilisé - Génère uniquement une requête de certificat du serveur. Consultez --gen-server --cert-req-only --help pour davantage d'informations.
--cert-only Rarement utilisé - Génère uniquement un certificat du serveur. Consultez --gen-server --cert-only --help pour davantage d'informations.
--rpm-only Rarement utilisé - Génère uniquement un RPM pour le déploiement. Consultez --gen-server --rpm-only --help pour davantage d'informations.
--no-rpm Rarement utilisé - Exécute toutes les étapes concernant le serveur sauf la génération de RPM.
--server-rpm=SERVER_RPM Rarement modifié - Le nom du RPM qui héberge l'ensemble de clés SSL du serveur Web (le nom de fichier de base, et non pas nomfichier-version-publication.noarch.rpm).
--server-tar=SERVER_TAR Rarement modifié - Nom de l'archive .tar de l'ensemble de clés SSH du serveur Web et du certificat CA public qui est uniquement utilisé par les routines d'installation du RHN Proxy Server hébergé (le nom de fichier de base, et non pas nomfichier-version-publication.tar).

3.2.3. Génération de la paire de clés SSL CA

Avant de créer l'ensemble de clés SSL requis par le serveur Web, vous devez générer une paire clés SSL CA. Un certificat SSL CA public est distribué aux systèmes client du Satellite ou du Proxy. L'RHN SSL Maintenance Tool vous permet de générer une paire de clés SSL CA au besoin et de la réutiliser pour tous les autres déploiements du serveur RHN.
Le processus de construction crée automatiquement la paire de clés et le RPM public pour la distribution aux clients. Tous les composants CA finissent dans le répertoire de construction spécifié sur la ligne de commande, en général /root/ssl-build (ou /etc/sysconfig/rhn/ssl pour les Satellites et les Proxies). Pour générer une paire de clés SSL CA, exécutez une commande semblable à l'exemple suivant :
rhn-ssl-tool --gen-ca --password=MY_CA_PASSWORD --dir="/root/ssl-build" \ 
--set-state="North	Carolina" --set-city="Raleigh" --set-org="Example Inc." \
--set-org-unit="SSL CA Unit"
Remplacez les valeurs exemples avec les valeurs appropriées à votre organisation. Les fichiers suivants seront alors présents dans le répertoire de construction spécifié :
  • RHN-ORG-PRIVATE-SSL-KEY — la clé privée SSL CA
  • RHN-ORG-TRUSTED-SSL-CERT — le certificat SSL CA public
  • rhn-org-trusted-ssl-cert-VER-REL.noarch.rpm — le RPM préparé pour la distribution aux systèmes client. Il contient le certificat SSL CA public (ci-dessus) et l'installe à cet endroit : /usr/share/rhn/RHN-ORG-TRUSTED-SSL-CERT
  • rhn-ca-openssl.cnf — le fichier de configuration SSL CA
  • latest.txt — liste toujours les dernières versions des fichiers appropriés.
Une fois terminé, vous êtes prêt à distribuer le RPM aux systèmes client. Reportez-vous à la Section 3.3, « Déploiement du certificat SSL CA public sur les clients ».

3.2.4. Génération d'ensembles de clés SSL du serveur Web

Bien que vous devez avoir une paire de clés SSL CA déjà générée, vous générerez sûrement plus fréquemment des ensembles de clés SSL du serveur Web, surtout si plusieurs Proxies ou Satellites sont déployés. Notez que la valeur de --set-hostname est différente pour chaque serveur. En d'autres termes, un ensemble distinct de clés et de certificats SSL doit être généré et installé pour chaque nom d'hôte de serveur RHN distinct.
Le processus de construction du certificat du serveur fonctionne comme la génération de paires de clés SSL CA avec une exception. Tous les composants du serveur finissent dans les sous-répertoires du répertoire de construction qui reflète le nom de la machine du système de construction, comme /root/ssl-build/NOM_MACHINE. Pour générer des certificats du serveur, exécutez une commande comme la suivante :
rhn-ssl-tool --gen-server --password=MY_CA_PASSWORD --dir="/root/ssl-build" \ 
--set-state="North	Carolina" --set-city="Raleigh" --set-org="Example	Inc." \
--set-org-unit="IS/IT" --set-email="admin@example.com" \
--set-hostname="rhnbox1.example.com
Remplacez les valeurs exemples avec les valeurs appropriées à votre organisation. Les fichiers suivants seront alors présents dans un sous-répertoire spécifique à la machine du répertoire de construction :
  • server.key — la clé SSL privée du serveur Web
  • server.csr — la requête de certificat SSL du serveur Web
  • server.crt — le certificat SSL public du serveur Web
  • rhn-org-httpd-ssl-key-pair-NOM_MACHINE-VER-REL.noarch.rpm — le RPM préparé pour la distribution aux serveurs RHN. Son fichier src.rpm associé est également généré. Ce RPM contient les trois fichiers ci-dessus. Il les installera dans les emplacements suivants :
    • /etc/httpd/conf/ssl.key/server.key
    • /etc/httpd/conf/ssl.csr/server.csr
    • /etc/httpd/conf/ssl.crt/server.crt
  • rhn-server-openssl.cnf — le fichier de configuration SSL du serveur Web
  • latest.txt — liste toujours les dernières versions des fichiers appropriés.
Une fois terminé, vous êtes prêt à distribuer et installer le RPM sur son serveur RHN respectif. Notez que le service httpd doit être redémarré après l'installation :
 /sbin/service httpd restart 

3.3. Déploiement du certificat SSL CA public sur les clients

Les processus d'installation du RHN Proxy Server et du RHN Satellite Server rendent le déploiement sur les clients relativement facile en générant un certificat SSL CA public et un RPM. Ces processus d'installation les rendent public en plaçant une copie de l'un ou des deux dans le répertoire /var/www/html/pub/ du serveur RHN.
Ce répertoire public peut être facilement inspecté simplement en s'y rendant via tout navigateur Web : http://proxy-or-sat.example.com/pub/.
Le certificat SSL CA public dans ce répertoire peut être téléchargé sur un système client à l'aide de wget ou curl. Par exemple :
curl -O	http://proxy-or-sat.example.com/pub/RHN-ORG-TRUSTED-SSL-CERT
wget http://proxy-or-sat.example.com/pub/RHN-ORG-TRUSTED-SSL-CERT
Alternativement, si le RPM du certificat SSL CA public se trouve dans le répertoire /pub/, il peut être directement installé sur sur un système client :
rpm -Uvh \
http://proxy-or-sat.example.com/pub/rhn-org-trusted-ssl-cert-VER-REL.noarch.rpm
Confirmez le nom actuel du certificat ou du RPM avant d'exécuter ces commandes.

3.4. Configuration de systèmes client

Une fois que le RPM ou le certificat brut a été déployé sur un système client, l'administrateur de ce système doit alors modifier les fichiers de configuration de l'Red Hat Update Agent et du Red Hat Network Registration Client (au besoin) pour utiliser le nouveau fichier de certificat SSL CA public et se connecter au RHN Proxy Server ou au RHN Satellite Server approprié. L'emplacement généralement accepté pour ce certificat SSL CA public est dans le répertoire /usr/share/rhn/.
Le RHN Proxy Server et le RHN Satellite Server ont l'RHN Bootstrap installé par défaut, qui peut réduire considérablement ces étapes répétitives et simplifier le processus d'enregistrement et de configuration de systèmes client. Consultez le Chapitre 5, Utilisation de RHN Bootstrap pour davantage d'informations.

Chapitre 4. Import de clés GPG personnalisées

Pour les clients qui prévoient de construire et de distribuer leurs propres RPM de manière sécurisée, il est fortement recommandé que tous les RPM personnalisés soient signés à l'aide de GPG (GNU Privacy Guard). La génération de clés GPG et la construction de paquetages signés GPG sont examinées dans le Guide de gestion de canaux de Red Hat Network.
Une fois les paquetages signés, la clé publique doit être déployée sur tous les systèmes qui importent ces RPM. Cette tâche a deux étapes : créez tout d'abord un emplacement central pour la clé publique afin que les clients puissent l'obtenir, et ajoutez ensuite la clé au porte-clés GPG local pour chaque système.
La première étape est commune et peut être effectuée en utilisant l'approche du site Web recommandée pour le déploiement d'applications client RHN (reportez-vous à la Section 2.1, « Déploiement des derniers RPM client de Red Hat Network »). Pour ce faire, créez un répertoire public sur le serveur Web et placez-y la signature GPG publique :
cp /some/path/YOUR-RPM-GPG-KEY /var/www/html/pub/
La clé peut être téléchargée par les systèmes client à l'aide de Wget :
wget -O- -q http://your_proxy_or_sat.your_domain.com/pub/YOUR-RPM-GPG-KEY
L'option -O- envoie les résultats vers la sortie standard alors que l'option -q configure l'exécution de Wget en mode quiet (sortie désactivée). Souvenez-vous de remplacer la variable YOUR-RPM-GPG-KEY par le nom de fichier de votre clé.
Une fois que la clé est disponible sur le système de fichiers client, importez la dans le porte-clés GPG local. Différents systèmes d'exploitation requièrent différentes méthodes.
Pour Red Hat Enterprise Linux 3 ou une version supérieure, utilisez la commande suivante :
rpm --import /path/to/YOUR-RPM-GPG-KEY
Pour Red Hat Enterprise Linux 2.1, utilisez la commande suivante :
gpg $(up2date --gpg-flags) --import /path/to/YOUR-RPM-GPG-KEY
Une fois que la clé GPG a bien été ajoutée au client, le système devrait pouvoir valider les RPM personnalisés signés avec la clé correspondante.

Chapitre 5. Utilisation de RHN Bootstrap

Red Hat Network fournit un outil qui automatise la plus grande partie de la reconfiguration manuelle décrite dans les chapitres précédents : RHN Bootstrap. Cet outil joue un rôle intégral dans le Programme d'installation du RHN Satellite Server, permettant la génération du script bootstrap durant l'installation.
Les clients du RHN Proxy Server et les clients ayant des paramètres de Satellite mis à jour nécessitent un outil bootstrap qui peut être utilisé indépendamment. L'outil RHN Bootstrap, appelé avec la commande /usr/bin/rhn-bootstrap, est utilisé dans ce but et est installé par défaut sur le RHN Satellite Server et le RHN Proxy Server.
Si il est utilisé correctement, le script généré par cet outil, peut être exécuté depuis tout système client pour mener les tâches suivantes :
  • Rediriger les applications client vers le Proxy ou Satellite RHN
  • Importer les clés GPG personnalisées
  • Installer les certificats SSL
  • Enregistrer le système à RHN et des groupes de systèmes et des canaux particuliers à l'aide des clés d'activation
  • Effectuer diverses activités après la configuration, comme la mise à jour de paquetages, des redémarrages et la modification de la configuration RHN
Les clients devraient cependant noter les risques implicites liés à l'utilisation d'un script pour mener la configuration. Des outils de sécurité comme les certificats SSL sont installés par le script même. Ils n'existent donc pas encore sur les systèmes et ne peuvent pas être utilisés pour traiter les transactions. Cela crée la possibilité d'une personne imitant le Satellite et transmettant de mauvaises données. Cela est mitigé par le fait que pratiquement tous les Satellites et les systèmes client fonctionnent derrière les pare-feu de clients et sont restreints du trafic extérieur. L'enregistrement est effectué via SSL et est ainsi protégé.
Le script bootstrap bootstrap.sh est automatiquement placé dans le répertoire /var/www/html/pub/bootstrap/ du serveur RHN. De cet endroit, il peut être téléchargé et exécuté sur tous les systèmes client. Notez qu'une certaine préparation et certaine édition après la génération seront requises, comme indiqué dans les sections suivantes. Reportez-vous à la Section 5.4, « Options de RHN Bootstrap » pour obtenir la liste complète des options de l'outil. Reportez-vous enfin à l'Annexe A, Exemple de script bootstrap pour un exemple de script.

5.1. Préparation

Vu que l'outil RHN Bootstrap (rhn-bootstrap) dépend de la bonne configuration des systèmes client par d'autres composants de l'infrastructure de Red Hat Network, ces composants doivent être préparés avant la génération du script. La liste suivante identifie les mesures initiales suggérées :
  • Générez les clés d'activation à appeler par le(s) script(s). Les clés d'activation peuvent être utilisées pour enregistrer les systèmes Red Hat Enterprise Linux, leur donner droit à un niveau de service RHN et les abonner à des canaux et des groupes de systèmes spécifiques, tout en une seule action. Notez que vous devez avoir des droits d'accès Management disponibles pour utiliser une clé d'activation, alors que l'inclusion de plusieurs clés d'activation en même temps requiert des droits d'accès Provisioning. Générez les clés d'activation sur la page Clés d'activation dans la catégorie Systèmes du site Web de RHN (soit les serveurs RHN centraux pour le Proxy soit le nom de domaine complet du Satellite). Reportez-vous aux chapitres sur l'Red Hat Update Agent et le site Web de RHN du Guide de référence RHN pour obtenir des instructions sur leur création et leur utilisation.
  • Red Hat recommande que vos RPM soient signés par une clé GPG GNU personnalisée. Faites en sorte que la clé soit disponible pour pouvoir y faire référence dans un script. Générez la clé comme le Guide de gestion de canaux de RHN le décrit et mettez la clé dans le répertoire /var/www/html/pub/ du serveur RHN, selon le Chapitre 4, Import de clés GPG personnalisées.
  • Si vous souhaitez utiliser le script pour déployer votre certificat SSL CA public, faites en sorte que le certificat ou le paquetage (RPM) contenant ce certificat soit disponibles sur ce serveur RHN et incluez-le durant la génération du script avec l'option --ssl-cert. Consultez le Chapitre 3, Infrastructure SSL pour davantage d'informations.
  • Faites en sorte que les valeurs soient prêtes pour développer un ou plusieurs scripts bootstrap, selon la variété des systèmes à reconfigurer. Vu que l'RHN Bootstrap fournit un ensemble complet d'options de reconfiguration, vous pouvez l'utiliser pour générer différents scripts bootstrap pour satisfaire chaque type de systèmes. Par exemple, bootstrap-web-servers.sh peut être utilisé pour reconfigurer vos serveurs Web, alors que bootstrap-app-servers.sh peut traiter les serveurs d'applications. Consultez la Section 5.4, « Options de RHN Bootstrap » pour obtenir une liste complète.

5.2. Génération

Maintenant que tous les composants nécessaires sont en place, vous pouvez utiliser l'outil RHN Bootstrap pour générer les scripts requis. Connectez-vous sur votre RHN Satellite Server ou RHN Proxy Server en tant que super-utilisateur et exécutez la commande rhn-bootstrap suivie des options et des valeurs désirées. Si aucune option n'est incluse, un fichier bootstrap.sh est créé dans le sous-répertoire bootstrap/ qui contient les valeurs principales dérivées du serveur, y compris le nom d'hôte, le certificat SSL, si il existe, les paramètres SSL et GPG et un appel pour le fichier client-config-overrides.txt.
Au minimum, Red Hat recommande fortement que vos scripts prennent en compte les clés d'activation, les clés GPG et les options de configuration avancées de la manière suivante.
  • Utilisez l'option --activation-keys pour inclure les clés, prenant en compte les besoins de droits d'accès identifiés dans la Section 5.1, « Préparation ».
  • Utilisez l'option --gpg-key pour identifier le chemin et le nom de fichier de la clé durant la génération du script. Sinon, utilisez l'option --no-gpg pour désactiver cette vérification sur les systèmes client. Red Hat recommande de garder cette mesure de sécurité.
  • Incluez l'option --allow-config-actions pour autoriser la gestion de configuration à distance sur tous les systèmes client touchés par le script. Cette fonction est utile dans la reconfiguration simultanée de plusieurs systèmes.
  • Incluez l'option --allow-remote-commands pour autoriser l'utilisation du script à distance sur tous les systèmes client. Tout comme la gestion de configuration, cette fonction aide à reconfigurer plusieurs systèmes.
Une fois terminé, votre commande ressemblera à l'exemple suivant :
	rhn-bootstrap --activation-keys KEY1,KEY2 \
		--gpg-key /var/www/html/pub/MY_CORPORATE_PUBLIC_KEY \
		--allow-config-actions \
		--allow-remote-commands
Incluez, bien évidemment, les noms de clés. Reportez-vous à la Section 5.4, « Options de RHN Bootstrap » pour obtenir la liste complète des options.

5.3. Utilisation du script

Finalement, lorsque vous avez terminé de préparer le script, vous êtes prêt à l'exécuter. Connectez-vous sur le RHN Satellite Server ou le RHN Proxy Server, rendez-vous dans le répertoire /var/www/html/pub/bootstrap/ et exécutez la commande suivante, en modifiant le nom d'hôte et le nom du script selon le type de système :
cat bootstrap-EDITED-NAME.sh | ssh root@CLIENT_MACHINE1 /bin/bash
Une alternative moins sécurisée est d'utiliser soit wget soit curl pour obtenir et exécuter le script de chaque système client. Connectez-vous sur chaque machine client et exécutez la commande suivante, en modifiant le script et le nom d'hôte selon :
wget -qO - \
https://your-satellite.example.com/pub/bootstrap/bootstrap-EDITED-NAME.sh \
| /bin/bash
Ou avec, curl :
curl -Sks \
https://your-satellite.example.com/pub/bootstrap/bootstrap-EDITED-NAME.sh \
| /bin/bash
Lorsque ce script a été exécuté sur chaque système client, tout devrait être configuré pour utiliser le serveur RHN.

5.4. Options de RHN Bootstrap

L'outil RHN Bootstrap offre de nombreuses options en ligne de commande pour la création de scripts bootstrap client. Bien que les descriptions de ces options se trouvent dans la table suivante, assurez-vous qu'elles sont disponibles dans la version de l'outil installé sur votre serveur RHN en exécutant la commande rhn-bootstrap --help ou en consultant sa page man.

Tableau 5.1. Options de RHN Bootstrap

Option Description
-h, --help Affiche l'écran d'aide avec une liste d'options spécifiques à la génération du script bootstrap
--activation-keys=ACTIVATION_KEYS Les clés d'activation comme elles sont définies dans le site Web de RHN avec plusieurs entrées séparées par une virgule et aucun espace
--overrides=OVERRIDES Le nom de fichier overrides de configuration. La valeur par défaut est client-config-overrides.txt
--script=SCRIPT Le nom de fichier du script bootstrap. La valeur par défaut est bootstrap.sh
--hostname=HOSTNAME Le nom de domaine (FQDN) du serveur auquel les systèmes client se connecteront
--ssl-cert=SSL_CERT Le chemin du certificat SSL public de votre organisation, soit un paquetage soit un certificat brut. Il sera copié dans l'option --pub-tree. La valeur "" forcera une recherche de --pub-tree
--gpg-key=GPG_KEY Le chemin de la clé GPG publique de votre organisation, si elle est utilisée. Elle sera copiée dans l'emplacement spécifié par l'option --pub-tree
--http-proxy=HTTP_PROXY Le paramètre Proxy HTTP pour les systèmes client sous la forme nomhôte:port. La valeur "" désactive ce paramètre
--http-proxy-username=HTTP_PROXY_USERNAME Si un proxy HTTP d'authentification est utilisé, spécifiez un nom d'utilisateur. La valeur "" désactive ce paramètre
--http-proxy-password=HTTP_PROXY_PASSWORD Si un proxy HTTP d'authentification est utilisé, spécifiez un mot de passe
--allow-config-actions Booléen. L'inclusion de cette option configure le système de façon à autoriser toutes les actions de configuration via RHN. Cela requiert l'installation de certains paquetages rhncfg-*, possiblement via une clé d'activation
--allow-remote-commands Booléen. L'inclusion de cette option configure le système de façon à autoriser les commandes à distance arbitraires via RHN. Cela requiert l'installation de certains paquetages rhncfg-*, possiblement via une clé d'activation
--no-ssl Non recommandé - Booléen. L'inclusion de cette option désactive SSL sur le système client
--no-gpg Non recommandé - Booléen. L'inclusion de cette option désactive la vérification GPG sur le système client
--no-up2date Non recommandé - Booléen. L'inclusion de cette option assure que up2date ne sera pas exécuté une fois que le système a été installé
--pub-tree=PUB_TREE Changement non recommandé - L'arborescence de répertoires publique où le certificat SSL CA et le paquetage se trouveront ; le répertoire et les scripts bootstrap. La valeur par défaut est /var/www/html/pub/
--force Non recommandé - Booléen. L'inclusion de cette option force la génération du script bootstrap malgré les avertissements
-v, --verbose Affiche les messages avec commentaires. Accumulatif ; -vvv affiche les messages avec extrêmement de commentaires

Chapitre 6. Écrire manuellement la configuration dans un script

Notez que ce chapitre offre une alternative à l'utilisation de RHN Bootstrap pour générer le script bootstrap. Avec ces instructions, vous devriez pouvoir créer votre propre script bootstrap.
Toutes les techniques initiales ont partagées un thème commun : le déploiement de fichiers nécessaires dans un emplacement centralisé qui peuvent être obtenus et installés à l'aide de simples commandes scriptables exécutées sur chaque client. Dans le chapitre présent, nous explorons le rassemblement de toutes ces pièces pour créer un seul script qui peut être appelé par tout système dans votre organisation.
Lorsque nous rassemblons toutes les commandes des chapitres précédents dans l'ordre le plus raisonnable, nous obtenons le script suivant. N'oubliez pas que rhn_register n'existe pas sur Red Hat Enterprise Linux 3 ou 4 :
# First, install the latest client RPMs to the system.
rpm -Uvh \
	http://proxy-or-sat.example.com.com/pub/rhn_register-2.8.27-1.7.3.i386.rpm \
	http://proxy-or-sat.example.com.com/pub/rhn_register-gnome-2.8.27-1.7.3.i386.rpm \
	http://proxy-or-sat.example.com.com/pub/up2date-3.0.7-1.i386.rpm \
	http://proxy-or-sat.example.com.com/pub/up2date-gnome-3.0.7-1.i386.rpm

# Second, reconfigure the clients to talk to the correct server.

perl -p -i -e 's/s/www\.rhns\.redhat\.com/proxy-or-sat\.example\.com/g' \
	/etc/sysconfig/rhn/rhn_register \
	/etc/sysconfig/rhn/up2date


# Third, install the SSL client certificate for your company's 
# RHN Satellite Server or RHN Proxy Server.
rpm -Uvh http://proxy-or-sat.example.com/pub/rhn-org-trusted-ssl-cert-*.noarch.rpm

# Fourth, reconfigure the clients to use the new SSL certificate.
perl -p -i -e 's/^sslCA/#sslCA/g;' \
	/etc/sysconfig/rhn/up2date /etc/sysconfig/rhn/rhn_register
echo "sslCACert=/usr/share/rhn/RHN-ORG-TRUSTED-SSL-CERT" \
	>> /etc/sysconfig/rhn/up2date
echo "sslCACert=/usr/share/rhn/RHN-ORG-TRUSTED-SSL-CERT" \
	>> /etc/sysconfig/rhn/rhn_register


# Fifth, download the GPG key needed to validate custom packages.
wget -O - -q http://proxy-or-sat.example.com.com/pub/YOUR-RPM-GPG-KEY


# Sixth, import that GPG key to your GPG keyring.
rpm --import /path/to/YOUR-RPM-GPG-KEY
Souvenez-vous que la sixième étape est documentée ici vu qu'elle concerne les systèmes qui exécutent Red Hat Enterprise Linux 3 ou une version supérieure.
Ce script est composé d'un processus propre et répétable qui devrait entièrement configurer tout client Red Hat Network potentiel en préparation à l'enregistrement à un RHN Proxy Server ou RHN Satellite Server. Souvenez-vous que les valeurs clés, comme l'URL de votre serveur RHN, son répertoire public et votre clé GPG actuelle doivent être insérées dans les paramètres substituables listés dans le script. De plus, selon votre environnement, des modifications supplémentaires peuvent être requises. Bien que ce script peut fonctionner pratiquement mot à mot, il devrait être utilisé comme guide.
Tout comme ses composants, ce script peut être situé centralement. En plaçant ce script dans le répertoire /pub/ du serveur, en exécutant wget -O- dessus et en redirigeant la sortie vers une session shell, nous pouvons exécuter le processus bootstrap entier avec une seule commande de chaque client :
wget -O - http://proxy-or-sat.example.com.com/pub/bootstrap_script | bash

Avertissement

L'exécution d'un script shell directement de l'entrée redirigée sur une connexion Web pose évidemment des risques de sécurité implicites. Il est donc vital d'assurer la sécurité du serveur source dans cet exemple.
Cette commande d'une ligne peut ensuite être appelée pour tous les systèmes sur un réseau. Si l'administrateur a un accès SSH sur tous les systèmes en question, il serait simple de passer en boucle une liste de ces systèmes et d'exécuter la commande à distance sur tous. Ce script serait également un ajout parfait à la section %post d'un script kickstart existant.

Chapitre 7. Implémentation de Kickstart

Il est évident que le meilleur moment d'apporter des changements à la configuration d'un système est lorsque ce système est installé la première fois. Pour les clients qui utilisent déjà kickstart de manière efficace, le script de démarrage est un ajout idéal à ce processus.
Une fois que tous les problèmes de configuration ont été résolus, un système peut également s'enregistrer avec les serveurs Red Hat Network locaux à l'aide de l'utilitaire rhnreg_ks qui vient avec les RPM up2date et rhn_register. Ce chapitre présente la bonne utilisation de rhnreg_ks pour enregistrer des systèmes.
L'utilitaire rhnreg_ks utilise les clés d'activation pour enregistrer, donner droit et abonner des systèmes à des canaux spécifiés en une seule action. Pour en savoir plus sur les clés d'activation, reportez-vous aux chapitres sur l'Red Hat Update Agent et le site Web de RHN dans le Guide de référence de Red Hat Network.
Le fichier kickstart commenté suivant est un exemple idéal de la manière dont un système peut être configuré du début à la fin à l'aide de Red Hat Network.
# Generic 7.2 kickstart for laptops in the Widget Corporation (widgetco)

# Standard kickstart options for a network-based install. For an
# explanation of these options, consult the Red Hat Linux Customization 
# Guide.

lang en_US
langsupport --default en_US en_US
keyboard defkeymap
network --bootproto dhcp
install
url --url ftp://ftp.widgetco.com/pub/redhat/linux/7.2/en/os/i386
zerombr yes
clearpart --all
part /boot	 --size 128 --fstype ext3 --ondisk hda
part /			 --size 2048 --grow --fstype ext3 --ondisk hda
part /backup --size 1024 --fstype ext3 --ondisk hda
part swap		--size 512 --ondisk hda
bootloader --location mbr
timezone America/New_York
rootpw --iscrypted $1$78Jnap82Hnd0PsjnC8j3sd2Lna/Hx4.
auth --useshadow --enablemd5 --krb5realm .COM --krb5kdc auth.widgetco.com \
	--krb5adminserver auth.widgetco.com
mouse --emulthree genericps/2
xconfig --card "S3 Savage/MX" --videoram 8192	--resolution 1024x768 \
	--depth 16 --defaultdesktop=GNOME --startxonboot --noprobe \
	 --hsync 31.5-48.5 --vsync 40-70

reboot

# Define a standard set of packages.	Note: Red Hat Network client 
# packages are found in Base.	This is quite a minimal set of packages;
# your mileage may vary.

%packages
@ Base
@ Utilities
@ GNOME
@ Laptop Support
@ Dialup Support
@ Software Development
@ Graphics and Image Manipulation
@ Games and Entertainment
@ Sound and Multimedia Support


# Now for the interesting part.

%post
( # Note that we run the entire %post section as a subshell for logging.

# Remember that nifty one-line command for the bootstrap script that we
# went through? This is an ideal place for it. And assuming that the
# script has been properly configured, it should prepare the system
# fully for usage of local Red Hat Network Servers.

wget -O- http://proxy-or-sat.example.com/pub/bootstrap_script | /bin/bash

# The following is an example of the usage of rhnreg_ks, the kickstart
# utility for rhn_register. This demonstrates the usage of the 
# --activationkey flag, which describes an activation key. For example,
# this activation key could be set up in the Web interface to join this 
# system to the "Laptops" group and the local Widgetco "Laptop Software" 
# channel. Note that this section applies only to Proxy users, as this 
# step is handled by the Satellite bootstrap script. 
#
# For more information about activation keys, consult the Red Hat Network
# Management Reference Guide.

/usr/sbin/rhnreg_ks --activationkey=6c933ea74b9b002f3ac7eb99619d3374

# End the subshell and capture any output to a post-install log file.
) 1>/root/post_install.log 2>&1

Annexe A. Exemple de script bootstrap

Le script /var/www/html/pub/bootstrap/bootstrap.sh généré par le programme d'installation du RHN Satellite Server offre la capacité de reconfigurer les systèmes client pour accéder facilement à votre serveur RHN. Il est disponible aux clients du RHN Satellite Server et du RHN Proxy Server via l'outil RHN Bootstrap. Après avoir modifié le script pour votre utilisation particulière, il peut être exécuté sur chaque machine client.
Examinez l'exemple et ses commentaires, commençant par un signe dièse (#), pour des informations supplémentaires. Suivez les étapes dans le Chapitre 5, Utilisation de RHN Bootstrap pour préparer le script à utiliser.

#!/bin/bash
echo "RHN Server Client bootstrap script v3.6"

# This file was autogenerated. Minor manual editing of this script (and
# possibly the client-config-overrides.txt file) may be necessary to complete
# the bootstrap setup. Once customized, the bootstrap script can be triggered
# in one of two ways (the first is preferred):
#
#	 (1) centrally, from the RHN Server via ssh (i.e., from the
#			 RHN Server):
#				cd /var/www/html/pub/bootstrap/
#				cat bootstrap-<edited_name>.sh | ssh root@<client-hostname> /bin/bash
#
#	 ...or...
#
#	 (2) in a decentralized manner, executed on each client, via wget or curl:
#				wget -qO-
# https://<hostname>/pub/bootstrap/bootstrap-<edited_name>.sh \
# | /bin/bash
#				 ...or...
#				curl -Sks
# https://<hostname>/pub/bootstrap/bootstrap-<edited_name>.sh \
# | /bin/bash

# SECURITY NOTE:
#	 Use of these scripts via the two methods discussed is the most expedient
#	 way to register machines to your RHN Server. Since "wget" is used
#	 throughout the script to download various files, a "Man-in-the-middle"
#	 attack is theoretically possible.
#
#	 The actual registration process is performed securely via SSL, so the risk
#	 is minimized in a sense. This message merely serves as a warning.
#	 Administrators need to appropriately weigh their concern against the
#	 relative security of their internal network.

# PROVISIONING/KICKSTART NOTE:
#	 If provisioning a client, ensure the proper CA SSL public certificate is
#	 configured properly in the post section of your kickstart profiles (the
#	 RHN Satellite or hosted web user interface).

# UP2DATE/RHN_REGISTER VERSIONING NOTE:
#	 This script will not work with very old versions of up2date and
#	 rhn_register.


echo
echo
echo "MINOR MANUAL EDITING OF THIS FILE MAY BE REQUIRED!"
echo
echo "If this bootstrap script was created during the initial installation"
echo "of an RHN Satellite, the ACTIVATION_KEYS, and ORG_GPG_KEY values will"
echo "probably *not* be set (see below). If this is the case, please do the"
echo "following:"
echo "	- copy this file to a name specific to its use."
echo "		(e.g., to bootstrap-SOME_NAME.sh - like bootstrap-web-servers.sh.)"
echo "	- on the website create an activation key or keys for the system(s) to"
echo "		be registered."
echo "	- edit the values of the VARIABLES below (in this script) as"
echo "		appropriate:"
echo "		- ACTIVATION_KEYS needs to reflect the activation key(s) value(s)"
echo "			from the website. XKEY or XKEY,YKEY"
echo "		- ORG_GPG_KEY needs to be set to the name of the corporate public"
echo "			GPG key filename (residing in /var/www/html/pub) if appropriate."
echo
echo "Verify that the script variable settings are correct:"
echo "		- CLIENT_OVERRIDES should be only set differently if a customized"
echo "			client-config-overrides-VER.txt file was created with a different"
echo "			name."
echo "		- ensure the value of HOSTNAME is correct."
echo "		- ensure the value of ORG_CA_CERT is correct."
echo
echo "Enable this script: comment (with #'s) this block (or, at least just"
echo "the exit below)"
echo
exit 1

# can be edited, but probably correct (unless created during initial install):
# NOTE: ACTIVATION_KEYS *must* be used to bootstrap a client machine.
ACTIVATION_KEYS=insert_activation_key_here
ORG_GPG_KEY=insert_org_gpg_pub_key_here

# can be edited, but probably correct:
CLIENT_OVERRIDES=client-config-overrides.txt
HOSTNAME=your_rhn_server_host.example.com

ORG_CA_CERT=RHN-ORG-TRUSTED-SSL-CERT
ORG_CA_CERT_IS_RPM_YN=0

USING_SSL=1
USING_GPG=1

REGISTER_THIS_BOX=1

ALLOW_CONFIG_ACTIONS=0
ALLOW_REMOTE_COMMANDS=0

FULLY_UPDATE_THIS_BOX=1

#
# -----------------------------------------------------------------------------
# DO NOT EDIT BEYOND THIS POINT -----------------------------------------------
# -----------------------------------------------------------------------------
#

# an idea from Erich Morisse (of Red Hat).
# use either wget *or* curl
# Also check to see if the version on the 
# machine supports the insecure mode and format
# command accordingly.
if [ -x /usr/bin/wget ] ; then
		output=`/usr/bin/wget --no-check-certificate 2>&1`
		error=`echo $output | grep "unrecognized option"`
		if [ -z "$error" ] ; then
				FETCH="/usr/bin/wget -q -r -nd --no-check-certificate"
		else
				FETCH="/usr/bin/wget -q -r -nd"
		fi
		
else
		if [ -x /usr/bin/curl ] ; then
				output=`/usr/bin/curl -k 2>&1`
				error=`echo $output | grep "is unknown"`
				if [ -z "$error" ] ; then
						FETCH="/usr/bin/curl -SksO"
				else
						FETCH="/usr/bin/curl -SsO"
				fi
		fi
fi

HTTP_PUB_DIRECTORY=http://${HOSTNAME}/pub
HTTPS_PUB_DIRECTORY=https://${HOSTNAME}/pub
if [ $USING_SSL -eq 0 ] ; then
		HTTPS_PUB_DIRECTORY=${HTTP_PUB_DIRECTORY}
fi
echo
echo "UPDATING RHN_REGISTER/UP2DATE CONFIGURATION FILES"
echo "-------------------------------------------------"
echo "* downloading necessary files"
echo "	client_config_update.py..."
rm -f client_config_update.py
$FETCH ${HTTPS_PUB_DIRECTORY}/bootstrap/client_config_update.py
echo "	${CLIENT_OVERRIDES}..."
rm -f ${CLIENT_OVERRIDES}
$FETCH ${HTTPS_PUB_DIRECTORY}/bootstrap/${CLIENT_OVERRIDES}

if [ ! -f "client_config_update.py" ] ; then
		echo "ERROR: client_config_update.py was not downloaded"
		exit 1
fi
if [ ! -f "${CLIENT_OVERRIDES}" ] ; then
		echo "ERROR: ${CLIENT_OVERRIDES} was not downloaded"
		exit 1
fi

echo "* running the update scripts"
if [ -f "/etc/sysconfig/rhn/rhn_register" ] ; then
		echo "	. rhn_register config file"
		/usr/bin/python -u client_config_update.py /etc/sysconfig/rhn/rhn_register \
		 ${CLIENT_OVERRIDES}
fi
echo "	. up2date config file"
/usr/bin/python -u client_config_update.py /etc/sysconfig/rhn/up2date \
 ${CLIENT_OVERRIDES}

if [ ! -z "$ORG_GPG_KEY" ] ; then 
		echo
		echo "* importing organizational GPG key"
		rm -f ${ORG_GPG_KEY}
		$FETCH ${HTTPS_PUB_DIRECTORY}/${ORG_GPG_KEY}
		# get the major version of up2date
		res=$(rpm -q --queryformat '%{version}' up2date | sed -e 's/\..*//g')
		if [ $res -eq 2 ] ; then
				gpg $(up2date --gpg-flags) --import $ORG_GPG_KEY
		else
				rpm --import $ORG_GPG_KEY
		fi
fi

echo
echo "* attempting to install corporate public CA cert"
if [ $USING_SSL -eq 1 ] ; then
		if [ $ORG_CA_CERT_IS_RPM_YN -eq 1 ] ; then
				rpm -Uvh ${HTTP_PUB_DIRECTORY}/${ORG_CA_CERT}
		else
				rm -f ${ORG_CA_CERT}
				$FETCH ${HTTP_PUB_DIRECTORY}/${ORG_CA_CERT}
				mv ${ORG_CA_CERT} /usr/share/rhn/
		fi
fi

echo
echo "REGISTRATION"
echo "------------"
# Should have created an activation key or keys on the RHN Server's
# website and edited the value of ACTIVATION_KEYS above.
#
# If you require use of several different activation keys, copy this file and
# change the string as needed.
#
if [ -z "$ACTIVATION_KEYS" ] ; then
		echo "*** ERROR: in order to bootstrap RHN clients, an activation key or keys"
		echo "			must be created in the RHN web user interface, and the"
		echo "			corresponding key or keys string (XKEY,YKEY,...) must be mapped to"
		echo "			the ACTIVATION_KEYS variable of this script."
		exit 1
fi

if [ $REGISTER_THIS_BOX -eq 1 ] ; then
		echo "* registering"
		/usr/sbin/rhnreg_ks --force --activationkey "$ACTIVATION_KEYS"
		echo
		echo "*** this system should now be registered, please verify ***"
		echo
else
		echo "* explicitely not registering"
fi

echo
echo "OTHER ACTIONS"
echo "------------------------------------------------------"
if [ $FULLY_UPDATE_THIS_BOX -eq 1 ] ; then
		echo "up2date up2date; up2date -p; up2date -uf (conditional)"
else
		echo "up2date up2date; up2date -p"
fi
echo "but any post configuration action can be added here.	"
echo "------------------------------------------------------"
if [ $FULLY_UPDATE_THIS_BOX -eq 1 ] ; then
		echo "* completely updating the box"
else
		echo "* ensuring up2date itself is updated"
fi
/usr/sbin/up2date up2date
/usr/sbin/up2date -p
if [ $FULLY_UPDATE_THIS_BOX -eq 1 ] ; then
		/usr/sbin/up2date -uf
fi
echo "-bootstrap complete-"

Annexe B. Historique de révision

Historique des versions
Version 1-3.4002013-10-31Rüdiger Landmann
Rebuild with publican 4.0.0
Version 1-32012-07-18Anthony Towns
Rebuild for Publican 3.0
Version 1-7Fri Feb 27 2009

Index

Symboles

--configure
utilisation de, Utilisation de l'option up2date --configure

B

bootstrap.sh
exemple de fichier, Exemple de script bootstrap
préparation et utilisation, Utilisation de RHN Bootstrap

K

kickstart
utilisation de, Implémentation de Kickstart

R

Red Hat Network Alert Notification Tool
configuration pour Satellite, Configuration de l'Red Hat Network Alert Notification Tool avec le Satellite
Red Hat Update Agent
configurer pour utiliser RHN Proxy Server ou RHN Satellite Server, Mise à jour manuelle des fichiers de configuration
RHN Bootstrap
générer le script, Génération
options de la ligne de commande, Options de RHN Bootstrap
préparation, Préparation
utiliser, Utilisation de RHN Bootstrap
utiliser le using the script, Utilisation du script
RHN SSL Maintenance Tool
génération du CA, Génération de la paire de clés SSL CA
génération du certificat du serveur, Génération d'ensembles de clés SSL du serveur Web
la génération expliquée, Génération de SSL expliquée
options, Options de l'RHN SSL Maintenance Tool
rhn-ssl-tool , L'RHN SSL Maintenance Tool
rhn-ssl-tool
génération du CA, Génération de la paire de clés SSL CA
génération du certificat du serveur, Génération d'ensembles de clés SSL du serveur Web
la génération expliquée, Génération de SSL expliquée
options, Options de l'RHN SSL Maintenance Tool
RHN SSL Maintenance Tool , L'RHN SSL Maintenance Tool

S

SSL (Secure Sockets Layer)
introduction, Une brève introduction à SSL

Note légale

Copyright © 2010 Red Hat, Inc.
This document is licensed by Red Hat under the Creative Commons Attribution-ShareAlike 3.0 Unported License. If you distribute this document, or a modified version of it, you must provide attribution to Red Hat, Inc. and provide a link to the original. If the document is modified, all Red Hat trademarks must be removed.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat Software Collections is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.