Red Hat Training

A Red Hat training course is available for Red Hat Satellite

Guide de mise en route

Red Hat Network Satellite 5.5

Approvisionnement et déploiement avec Red Hat Network Satellite

Édition 2

Red Hat Engineering Content Services

Résumé

Ce document contient des détails et instructions précises pour utiliser la fonctionnalité d'approvisionnement kickstart dans Red Hat Network Satellite. Pour obtenir plus d'informations sur Satellite, reportez-vous au Guide d'utilisation Satellite.

Chapitre 1. Introduction

L'approvisionnement est le processus de configuration d'une machine physique ou virtuelle sur un état connu prédéfini. Red Hat Network (RHN) Satellite approvisionne des systèmes en utilisant le processus kickstart. Pour utiliser la fonctionnalité, un ou plusieurs machines cibles sont requises. Les machines cibles peuvent être physiques, bare metal, ou des machines virtuelles. Pour utiliser la fonctionnalité d'approvisionnement de machines virtuelles de RHN Satellite, veuillez créer les machine virtuelles à l'aide de Xen ou de KVM.

Définitions

Quelques termes utilisés dans cet ouvrage :
Kickstarter
Processus d'installation d'un système Red Hat de manière automatisée qui ne requiert que peu ou pas d'intervention de la part de l'utilisateur. D'un point de vue technique, kickstart fait référence à un mécanisme dans le programme d'installation Anaconda qui permet d'écrire une description précise du contenu et de la configuration d'une machine dans l'installateur, qui procédera ensuite. Cette définition de système très précise est appelée un Profil Kickstart.
Profil Kickstart
Le fichier kickstart est un fichier texte qui spécifie toutes les options nécessaires pour kickstarter une machine, y compris les informations de partitionnement, la configuration réseau, et les paquetages à installer. Dans RHN Satellite, un profil kickstart est un sur-ensemble d'une définition kickstart d'Anaconda traditionnelle, car l'implémentation de Satellite est construite sur les améliorations apportées par Cobbler aux kickstarts. Un profil Kickstart suppose l'existence d'une arborescence kickstart.
Arborescence kickstart
Logiciel et fichiers de support nécessités pour utiliser kickstart sur une machine. Ceci est aussi appelé une « arborescence d'installation ». Il s'agit ici de la structure des répertoires et des fichiers tirés du média d'installation fourni avec une version particulière. Dans la terminologie de Cobbler, un arbre (ou une arborescence) Kickstart fait partie d'une distribution.
PXE (Preboot eXecution Environment)
Protocole de bas niveau permettant de faire un kickstart sur des machines bare-metal (habituellement des machines physiques, ou réelles) lors du lancement et sans qu'il n'y ait de pré-configuration sur la machine-cible elle-même. PXE repose sur un serveur DHCP pour informer ses clients sur les serveurs bootstrap (dans le cas de ce document, sur les installations Satellite 5.5 ou plus récentes). Pour pouvoir être utilisé, PXE doit être pris en charge par le micrologiciel de la machine cible. Il est possible d'utiliser la virtualisation et de réinstaller les installations de Satellite sans PXE, même si PXE se révèle très utile pour le démarrage de nouvelles machines physiques ou pour la ré-installation de machines qui ne sont pas enregistrées avec Satellite.

Scénarios d'approvisionnement

Types de scénarios d'approvisionnement pris en charge par RHN Satellite :
Nouvelles installations
Approvisionner un système qui n'a jamais possédé de système d'exploitation auparavant (ces installations sont aussi appelées des installations bare metal).
Installations virtuelles
Satellite prend en charge KVM, les invités totalement virtualisés Xen et les invités paravirtualisés Xen.
Réapprovisionner
Tant qu'ils ont été enregistrés avec la même instance de Satellite, les systèmes physiques et invités peuvent être réapprovisionnés. Reportez-vous à la Section 2.5.2, « Réapprovisionnement ».

Chapitre 2. Kickstart

2.1. Paquetages prérequis

Si le système utilise une distribution personnalisée, vous aurez besoin des paquetages suivants, disponibles sur tous les canaux Red Hat Network rhn-tools :
  • koan
  • spacewalk-koan
Il est préférable de cloner un canal existant rhn-tools afin d'accéder à ces paquetages depuis votre canal personnalisé.
RHN Satellite s'attend à ce que les fichiers kernel et initrd se trouvent dans des emplacements spécifiques dans l'arborescence kickstart. Cependant, ces emplacements sont différents selon les architectures. Le tableau ci-dessous explique les différents emplacements :

Tableau 2.1. Fichiers de distribution requis par architecture

Architecture noyau Image du disque virtuel initial
IBM System z TREE_PATH/images/kernel.img TREE_PATH/images/initrd.img
PowerPC TREE_PATH/ppc/ppc64/vmlinuz TREE_PATH/images/pxeboot/vmlinux
Toutes les autres architectures TREE_PATH/images/pxeboot/vmlinuz TREE_PATH/images/pxeboot/initrd.img

2.2. Arborescences kickstart

Au moins une arborescence kickstart doit être installée sur le Satellite afin de pouvoir utiliser l'approvisionnement kickstart. Les arborescences kickstart peuvent être installées manuellement ou automatiquement.

Procédure 2.1. Installer des arborescences kickstart automatiquement

Pour toutes les distributions possédant un canal de base dans RHN, les arborescences kickstart peuvent être installées automatiquement. Cela fait partie de la synchronisation normale du canal via satellite-sync.
  1. Choisissez la distribution à partir de laquelle vous souhaitez baser les kickstarts et localisez le canal de base de cette distribution ainsi que son canal RHN Tools correspondant.
    Par exemple, si vous souhaitez utiliser Red Hat Enterprise Linux 5 sur une architecture x86, vous aurez besoin du canal rhel-i386-server-5 et du canal RHN Tools correspondant rhn-tools-rhel-i386-server-5.
  2. Si vous utilisez un Satellite connecté, synchronisez votre serveur Satellite directement avec les serveurs de Red Hat en utilisant satellite-sync. Si votre serveur Satellite est déconnecté, vous devrez obtenir des vidages de canaux déconnectés depuis les serveurs Red Hat et le synchroniser avec ceux-ci.
  3. Synchroniser le canal créera automatiquement une arborescence kickstart pour cette distribution.

Procédure 2.2. Installer des arborescences kickstart manuellement

Pour kickstarter une distribution personnalisée, qui est une distribution non-prise en charge par Red Hat, ou une version beta de Red Hat Enterprise Linux, vous devrez créer l'arborescence kickstart correspondante manuellement. Vous aurez besoin de l'ISO d'installation pour la distribution que vous souhaitez kickstarter.
  1. Copiez l'ISO d'installation sur votre serveur Satellite et montez-le sur /mnt/iso
  2. Copiez le contenu de l'ISO dans un emplacement personnalisé. Il est recommandé de créer un répertoire dans /var/satellite pour toutes vos distributions personnalisées. Par exemple, vous pourriez copier le contenu d'une distribution beta de RHEL sur /var/satellite/custom-distro/rhel-i386-server-5.3-beta/
  3. Utilisez l'interface web du RHN Satellite pour créer un canal logiciel personnalisé. Utilisez CanauxGérer les canaux logicielsCréer un nouveau canal pour créer un canal parent avec un nom et une étiquette appropriés. Pour l'exemple utilisé ci-dessus, vous pourriez utiliser l'étiquette rhel-5.3-beta.
  4. Envoyez les paquetages logiciel depuis l'emplacement de l'arborescence vers le canal logiciel nouvellement créé à l'aide de la commande rhnpush :
    rhnpush --server=http://localhost/APP -c 'rhel-5.3-beta' \  -d /var/satellite/custom-distro/rhel-i386-server-5.3-beta/Server/
    Le sous-répertoire dans l'arborescence pourrait être différent selon votre distribution.
  5. Une fois que les paquetages logiciel ont été envoyés, ils peuvent être supprimés depuis le chemin d'accès de l'arborescence à l'aide de la commande rm. Ces paquetages sont toujours stockés sur le serveur Satellite dans le canal, mais ne sont plus nécessités dans l'arborescence.
    rm /var/satellite/custom-distro/rhel-i386-server-5.3-beta/Server/*.rpm

    Note

    Vous pouvez choisir de laisser les paquetages logiciels dans l'arborescence kickstart. Cela leur permettra d'être installés avec la commande yum dans le futur.
  6. Utilisez l'interface web RHN Satellite pour créer la distribution. Utilisez SystèmesKickstartDistributionsCréer une nouvelle distribution pour créer la distribution, en utilisant une étiquette appropriée et le chemin d'accès complet de l'arborescence (tel que /var/satellite/custom-distro/rhel-i386-server-5.3-beta/). Sélectionnez le canal de base que vous avez créé auparavant ainsi que l'« Installer Generation » correct (tel que Red Hat Enterprise Linux 5). Sélectionnez Créer la distribution kickstart pour terminer.
  7. Pour maintenir le même logiciel à travers de multiples environnements et systèmes, le canal enfant RHN Tools d'un canal de base Red Hat Enterprise Linux existant peut être cloné en tant que canal enfant du canal de base récemment créé. Le clonage d'un canal enfant peut être effectué comme suit :
    1. Sur l'interface web Satellite, veuillez cliquer sur CanauxGérer les canaux logicielsCloner le canal
    2. Choisissez le canal enfant que vous souhaitez cloner depuis la boîte déroulante Cloner à partir de : et choisissez l'état du clone.
    3. Cliquez sur Créer le canal.
    4. Remplissez les informations nécessaires et choisissez le canal parent sous lequel le canal enfant cloné devra se trouver.
    5. Cliquez sur Créer le canal.
Créer une distribution Kickstart

Figure 2.1. Créer une distribution Kickstart

2.3. Profils kickstart

Les profils kickstart spécifient les options de configuration à utiliser pour l'installation.
Les profils kickstart peuvent être créés à l'aide de l'interface d'un Assistant, qui génère un profil basé sur les réponses que vous fournissez à une série de questions. Ils peuvent aussi être créés à l'aide d'une méthode brute qui vous laisse un contrôle total sur le contenu du profil.

Procédure 2.3. Créer un profil Kickstart avec un Assistant

  1. Sélectionnez SystèmesKickstartCréer un nouveau profil kickstart
  2. Fournissez une Étiquette appropriée, puis sélectionnez le Canal de base et l'Arborescence kickstart que vous souhaitez
  3. Sélectionnez le Type de virtualisation. Reportez-vous aux Types de virtualisation pour obtenir plus d'informations sur les types de virtualisation. Cliquez sur Suivant pour continuer.
  4. Sélectionnez l'emplacement du téléchargement pour le profil kickstart. Pour les distributions personnalisées, saisissez l'emplacement de son arborescence comme URL (HTTP et FTP sont tous deux pris en charge), sinon, utilisez l'option par défaut. Cliquez sur Suivant pour continuer.
  5. Saisissez le mot de passe root et cliquez sur Finir pour terminer la création du profil.
  6. Le profil kickstart complet sera créé. Vous pouvez voir le profil en cliquant sur Fichier kickstart.

Procédure 2.4. Créer un profil Kickstart avec la méthode brute

  1. Sélectionnez SystèmesKickstartTélécharger un nouveau fichier kickstart
  2. Fournissez une Étiquette appropriée, puis sélectionnez la distribution que vous souhaitez.
  3. Sélectionnez le Type de virtualisation. Reportez-vous aux Types de virtualisation pour obtenir plus d'informations sur les types de virtualisation.
  4. Si vous possédez un profil kickstart existant, téléchargez le fichier. Sinon, saisissez le profil kickstart dans la boîte de texte Contenu du fichier.
    Voici un échantillon de kickstart brut pouvant être utilisé comme point de commencement :
    install
    text
    network --bootproto dhcp
    url --url http://$http_server/ks/dist/org/1/ks-rhel-i386-server-5
    lang en_US
    keyboard us
    zerombr
    clearpart --all
    part / --fstype=ext3 --size=200 --grow
    part /boot --fstype=ext3 --size=200
    part swap --size=1000   --maxsize=2000
    bootloader --location mbr
    timezone America/New_York
    auth --enablemd5 --enableshadow
    rootpw --iscrypted $1$X/CrCfCE$x0veQO88TCm2VprcMkH.d0
    selinux --permissive
    reboot
    firewall --disabled
    skipx
    key --skip
    
    %packages 
    @ Base
    
    %post
    $SNIPPET('redhat_register')
    
  5. Le serveur RHN Satellite ne gère pas la distribution spécifiée comme l'url dans le kickstart. Ainsi, n'oubliez pas d'inclure l'option url --url dans le profil, de manière similaire à ce qui suit :
    url --url http://satellite.example.com/ks/dist/org/1/my_distro
    Remplacez my_distro par l'étiquette de distribution et 1 avec votre l'ID de votre organisation.
  6. Les profils kickstart bruts utilisent $http_server à la place du nom d'hôte du Satellite. Cela sera automatiquement rempli lorsque le modèle kickstart sera rendu.
  7. Le snippet redhat_register est utilisé pour gérer l'enregistrement.
Kickstart brut

Figure 2.2. Kickstart brut

Types de virtualisation

Tous les profils kickstart possèdent un type de virtualisation qui leur est associé. Ce tableau souligne les différentes options :

Tableau 2.2. Types de virtualisation

Type Description Utilisations
none Pas de virtualisation Utilisez ce type pour un approvisionnement normal, pour des installations bare metal et pour les installations qui ne sont ni Xen, ni KVM (comme VMware ou Virtage)
KVM Virtualized Guest Invités KVM Utilisez ce type pour l'approvisionnement des invités KVM
Xen Fully-Virtualized Guest Invités Xen Utilisez ce type pour l'approvisionnement des invités Xen

Note

Cette option requiert la prise en charge du matériel sur l'hôte, mais ne nécessite pas de système d'exploitation modifié sur l'invité.
Xen Para-Virtualized Guest Invités Xen Utilisez ce type pour approvisionner un invité virtuel avec la paravirtualisation Xen. La paravirtualisation est le mode de virtualisation le plus rapide. Elle requiert un indicateur PAE sur le CPU du système et un système d'exploitation modifié. Red Hat Enterprise Linux 5 prend en charge les invités sous paravirtualisation.
Xen Virtualization Host Hôtes Xen Utilisez ce type pour l'approvisionnement d'un hôte virtuel avec la paravirtualisation Xen. Si le matériel est compatible, les hôtes et invités paravirtualisés Xen sont pris en charge.
Les profils kickstart créés afin d'être utilisés en tant qu'hôtes Xen doivent inclure le paquetage kernel-xen dans la section %packages.
Les profils kickstart créés afin d'être utilisés en tant qu'hôtes KVM doivent inclure le paquetage qemu dans la section %packages.
Les systèmes totalement virtualisés peuvent avoir besoin que la prise en charge de la virtualisation soit activée dans le menu BIOS de l'ordinateur.

Note

Pour obtenir plus d'informations sur kickstart, reportez-vous au chapitre Installations Kickstart du Guide d'installation Red Hat Enterprise Linux.

2.4. Création de modèles

La création de modèles Kickstart (de l'anglais, « Kickstart templating ») vous permet d'inclure des variables, des snippets ainsi que des structures de contrôle telles que les boucles for et les instructions if dans les fichiers kickstart. Cela est effectué à l'aide de l'outil cheetah.
Diverses raisons expliquent pourquoi la création de modèles peut se révéler utile :
  • La ré-utilisation d'une section particulière d'un kickstart, comme la section de partitionnement d'un disque, entre de multiples kickstarts.
  • Pour effectuer certaines actions %post de manière consistante sur de multiples kickstarts.
  • Pour définir un snippet sur les multiples rôles des serveurs, comme un serveur DNS, un serveur proxy et un serveur web. Par exemple, un serveur web pourrait posséder le snippet suivant défini :
    httpd
    mod_ssl
    mod_python
    
    Pour créer un profil de serveur web, incluez le snippet du serveur web dans la section %package du fichier kickstart. Pour qu'un profil soit à la fois un serveur web et un serveur proxy, veuillez inclure les deux snippets dans la section paquetage. Pour ajouter un autre paquetage au snippet du serveur web, par exemple mod_perl, mettez le snippet à jour, et tous les profils qui utilisent ce snippet seront dynamiquement mis à jour.
Variables

La création de modèles vous permet de définir une variable à utiliser dans un fichier kickstart. Les variables sont sujettes à une forme d'héritage qui leur permet d'être définies à un niveau et d'être outrepassées à des niveaux plus bas. Ainsi, si une variable est définie au niveau du système, la même variable définie au niveau du profil ou aux niveaux de l'arborescence kickstart sera outrepassée. De la même manière, si une variable est définie au niveau du profil, la même variable au niveau de l'arborescence kickstart sera outrepassée.

Note

Remarquez que les variables d'arborescences kickstart ne peuvent pas être définies pour les arborescences kickstart générées automatiquement comme celles qui sont créées lorsqu'une synchronisation du Satellite est effectuée.
Snippets

Les snippets réutilisent des portions de code entre de multiples modèles kickstart. Ils peuvent s'étirer sur de nombreuses lignes et inclure des variables. Ils peuvent être inclus dans un profil kickstart à l'aide du texte $SNIPPET('snippet_name'). Un snippet peut être créé pour une liste de paquetages, pour un script %post, ou pour tout texte qui aurait été normalement inclus dans un fichier kickstart.

Pour gérer les snippets, naviguez sur SystèmesKickstartSnippets Kickstart.
La page Snippets Kickstart affiche plusieurs snippets par défaut qui ne peuvent pas être modifiés, mais qui peuvent être utilisés par n'importe quelle organisation. Les snippets par défaut peuvent être utilisés dans des kickstarts qui ont été écrits ou téléchargés sur le serveur RHN Satellite. Les snippets par défaut sont stockés sur le système de fichiers du serveur RHN Satellite dans /var/lib/cobbler/snippets/. Il existe un modèle provenant d'un kickstart de type Assistant situé dans /var/lib/rhn/kickstarts/wizard/, ce qui explique les différents snippets par défaut et leur utilisation.
Le snippet redhat_register est un snippet par défaut qui est utilisé pour enregistrer des machines sur un serveur RHN Satellite en tant que partie d'un kickstart. Il utilise une variable nommée redhat_management_key pour enregistrer la machine. Pour utiliser le snippet définissez la variable redhat_management_key au niveau du système, du profil, ou de la distribution, puis ajoutez $SNIPPET('redhat_register') à une section %post du kickstart. Tous les kickstarts de type Assistant générés par le serveur RHN Satellite inclueront déjà ce snippet dans la section %post.
L'onglet Snippets personnalisés vous permet de voir et de modifier les snippets créés pour être utilisés par l'organisation. De nouveaux snippets peuvent être créés en cliquant sur Créer un nouveau snippet. Les snippets personnalisés sont stockés dans le répertoire /var/lib/rhn/kickstarts/snippets/. RHN Satellite stocke les snippets pour différentes organisations dans différents répertoires, avec un nom de fichier similaire au suivant, où le 1 représente l'ID de l'organisation :
$SNIPPET('spacewalk/1/snippet_name')
Pour déterminer le texte à utiliser pour insérer le snippet dans le kickstart, cherchez la colonne Macro snippet dans la liste de snippets ou sur la page des détails du snippet.

Note

Des snippets existent au niveau global et ne partagent pas la même structure d'héritage que les variables. Cependant, les variables peuvent être utilisées dans les snippets pour modifier la manière dont ils se comportent lorsque différents systèmes requièrent un kickstart.
Snippets Kickstart

Figure 2.3. Snippets Kickstart

Caractères spéciaux d'échappement

Les caractères $ et # sont utilisés pendant la modélisation pour spécifier les variables et les structures de contrôle. Si ces caractères sont nécessaires pour toute autre chose dans un script, ils devront être placés dans un séquence d'échappement afin de ne pas être reconnus en tant que variables. Ceci peut être accompli de plusieurs manières :

  • En plaçant une barre oblique inverse (\) devant chaque instance de $ ou de # que vous souhaitez ignorer pendant la modélisation.
  • En incluant la totalité du script dans #raw ... #end raw
    Tous les scripts %pre et %post créés à l'aide de kickstarts de type Assistant sont inclus par défaut dans #raw...#end raw. Ceci peut être basculé avec la case à cocher Template (Modèle), disponible lors de la modification d'un script %post ou %pre.
  • En incluant #errorCatcher Echo dans la première ligne du snippet.

Exemple 2.1. Caractères spéciaux d'échappement dans les modèles

Cet exemple décrit comment créer une séquence d'échappement de caractères spéciaux dans des modèles kickstart.
Le script bash suivant doit être inséré dans une section %post :
%post 
echo $foo > /tmp/foo.txt
Si le caractère $ n'est pas « échappé », le moteur de modélisation essaiera de trouver une variable nommée $foo et échouera car foo n'existe pas en tant que variable.
La plus simple manière de mettre le caractère $ dans une séquence d'échappement est d'utiliser une barre oblique (\) :
%post 
echo \$foo > /tmp/foo.txt
Ceci causera à \$foo d'être rendu en tant que $foo.
Une autre méthode consiste à inclure le script bash entier dans #raw ... #end raw comme suit :
%post 
#raw  
echo $foo > /tmp/foo.txt 
#end raw
La méthode finale est d'inclure #errorCatcher Echo dans la première ligne du modèle kickstart. Celle-ci ordonne au moteur de modélisation d'ignorer toute variable qui n'existe pas et d'imprimer le texte tel qu'il est. Cette option est déjà incluse dans les kickstarts de type Assistant et peut être incluse dans tout kickstart brut (de l'anglais, « raw kickstart ») que vous créez manuellement.

2.5. Kickstarter une machine

2.5.1. Effectuer un kickstart à partir d'une machine Bare Metal

Lorsqu'une machine ne possède pas de système d'exploitation, ou lorsque le mauvais système d'exploitation est installé, cette machine est nommée bare metal. Il existe trois manières d'approvisionner une machine à partir d'un état bare metal :
  • Média d'installation de système d'exploitation standard
  • Démarrage PXE

Procédure 2.5. Démarrage à partir du média d'installation

  1. Insérez le média d'installation dans la machine. Le média doit correspondre au kickstart que vous souhaitez utiliser. Par exemple, si le kickstart est configuré pour utiliser l'arborescence kickstart ks-rhel-i386-server-5-u2, utilisez alors le média Red Hat Enterprise Linux 5.2 i386.
  2. Lorsque l'invite de démarrage vous est présentée, activez le kickstart en saisissant cette commande :
    linux ks=http://satellite.example.com/path/to/kickstart
    
  3. Une fois le système démarré, téléchargez le fichier kickstart, puis procédez à l'installation automatique.

Procédure 2.6. Démarrage PXE

Pour pouvoir effectuer un démarrage PXE, chaque système doit prendre en charge le démarrage PXE au niveau du BIOS. Pratiquement tous les types de matériel récents devraient être en mesure de le prendre en charge. En outre, vous devez posséder un serveur DHCP, même si les systèmes seront configurés de manière statique après l'installation.
  1. Important

    Si un serveur DHCP est déployé sur un autre système du réseau, il sera nécessaire d'avoir un accès administratif au serveur DHCP afin de pouvoir modifier le fichier de configuration DHCP.
    Si vos machines résident sur de multiples réseaux, vous devrez vous assurer que toutes les machines peuvent bien se connecter au serveur DHCP. Cela peut être accompli en effectuant un hébergement multiple du serveur DHCP (à l'aide d'un VLAN réel ou à ressources partagées) et en configurant tous les routeurs ou interrupteurs afin qu'ils passent le protocole DHCP au-delà des limites du réseau.
    Configurez le serveur DHCP afin qu'il pointe vers le serveur PXE en paramétrant l'adresse next-server pour les systèmes devant être gérés par RHN Satellite.
    Pour utiliser des noms d'hôte lorsqu'une installation est effectuée, veuillez configurer le serveur DHCP pour pointer vers le domaine et les adresses IP, en incluant les lignes suivantes :
    option domain-name DOMAIN_NAME;
    option domain-name-servers IP_ADDRESS1, IP_ADDRESS2;
    
  2. Sur le serveur DHCP, passez à l'utilisateur root et ouvrez le fichier /etc/dhcpd.conf. Ajoutez une nouvelle classe avec des options pour effectuer une installation en démarrage PXE :
    allow booting;
    allow bootp;
    class "PXE" {
      match if substring(option vendor-class-identifier, 0, 9) = "PXEClient";
      next-server 192.168.2.1;
      filename "pxelinux.0";
    }
    
    Cette classe va effectuer les actions suivantes :
    1. Activez le démarrage réseau avec le protocole bootp
    2. Créez une classe nommée PXE. Si un système est configuré pour que PXE soit en premier dans ses priorités de démarrage, il s'identifiera en tant que PXEClient.
    3. Le serveur DHCP dirige le système vers le serveur Cobbler se trouvant à l'adresse IP suivante : 192.168.2.1
    4. Le serveur DHCP se réfère au fichier image de démarrage qui se trouve dans /var/lib/tftpboot/pxelinux.0
  3. Configurez Xinetd. Xinetd est un démon qui gère une suite de services, y compris TFTP, le serveur FTP utilisé pour transférer l'image de démarrage sur un client PXE.
    Exécutez Xinetd avec la commande chkconfig :
    chkconfig xinetd on
    
    Alternativement, passez à l'utilisateur root et ouvrez le fichier /etc/xinetd.d/tftp. Localisez la ligne disable = yes et modifiez-la de manière à voir disable = no à la place.
  4. Lancez le service Xinetd afin que TFTP puisse commencer à servir l'image de démarrage pxelinux.0 :
    chkconfig --level 345 xinetd on
    /sbin/service xinetd start
    
    La commande chkconfig active le service xinetd pour tous les niveaux d'exécution d'utilisateurs, tandis que la commande /sbin/service active xinetd immédiatement.

2.5.2. Réapprovisionnement

Le réapprovisionnement fait référence à la réinstallation d'un système existant. Le réapprovisionnement peut être effectué à l'aide de l'interface web du RHN Satellite et le système utilisera le même profil système qu'il possédait avant son réapprovisionnement. Cela permet de conserver de nombreuses informations paramètres concernant le système.
Le réapprovisionnement peut être planifié à partir de l'onglet Approvisionnement lorsque vous affichez un système. Pour configurer des options supplémentaires, rendez-vous sur la page Configurations avancées, qui permet de configurer des détails tels que les options du noyau, les informations du réseau et la synchronisation du profil de paquetages. La section Options du noyau offre accès aux options du noyau utilisées pendant le kickstart et les Options post-noyau sont les options du noyau qui seront utilisées une fois que le kickstart est terminé et que le système démarre pour la première fois.

Exemple 2.2. Configurer les options du noyau et les options post-noyau

Cet exemple décrit les différences entre les options du noyau et les options post-noyau dans le processus de configuration du réapprovisionnement.
Pour établir une connection VNC afin de surveiller le kickstart à distance, incluez vnc vncpassword=PASSWORD dans la ligne Kernel Options.
Pour démarrer le noyau du système résultant avec l'option du noyau noapic, ajoutez noapic à la ligne Post Kernel Options.

Procédure 2.7. Conservation de fichiers

La fonctionnalité Conservation de fichiers peut être utilisée afin de protéger les fichiers d'une perte éventuelle lors d'un réapprovisionnement. Cette fonctionnalité stocke les fichiers temporairement pendant le kickstart et les restaure une fois que le réapprovisionnement est terminé.

Note

Les listes de conservation de fichiers sont uniquement disponibles avec les kickstarts de type Assistant et peuvent uniquement être utilisées pendant le réapprovisionnement.
  1. Rendez-vous sur SystèmesKickstartConservation de fichiersliste de conservation de fichiers et créez une liste des fichiers à conserver.
  2. Rendez-vous sur SystèmesKickstartProfils et associez la liste de conservation de fichiers avec un kickstart en sélectionnant le profil souhaité.
  3. Rendez-vous sur Détails du systèmeConservation de fichiers et sélectionnez la liste de conservation de fichiers.

2.5.3. Approvisionnement de l'invité virtualisé

L'approvisionnement d'invité virtualisé est pris en charge dans RHN Satellite 5.5 à l'aide des technologies de virtualisation suivantes :
  • Invité virtualisé KVM
  • Invité totalement virtualisé Xen
  • Invité parvirtualisé Xen

Procédure 2.8. Approvisionner un invité virtualisé

  1. Vérifiez que le système hôte possède un droit d'accès système Virtualisation ou Plateforme de virtualisation.
  2. Sur la page Systèmes, sélectionnez l'hôte virtuel approprié, puis sélectionnez VirtualisationApprovisionnement. Sélectionnez le profil kickstart approprié et saisissez un nom d'invité.
  3. Pour configurer des paramètres supplémentaires, tel que la mémoire de l'invité et l'utilisation du CPU, cliquez sur le bouton Configuration avancée. Les options suivantes peuvent être configurées :
    • Réseau : statique ou DHCP
    • Options du noyau
    • Synchronisation de profil de paquetage : lorsque le kickstart se termine, le système synchronisera son profil paquetage avec celui d'un autre système ou d'un autre profil stocké.
    • Allocation de mémoire : RAM (512 Mo par défaut)
    • Taille du disque virtuel
    • CPU virtuels (1 par défaut)
    • Pont virtuel : pont réseau utilisé pour l'installation. Par défaut xenbr0 pour l'approvisionnement Xen et virbr0 pour KVM.

      Note

      Le pont réseau virbr0 ne permettra pas de mise en réseau extérieure. Si un réseau extérieur est requis, configurez l'hôte pour créer un pont réel. xenbr0 est un réel pont, il vous est donc recommandé de l'utiliser si possible.
    • Chemin de stockage virtuel : chemin d'accès vers un fichier, un volume logique LVM, un répertoire, ou un périphérique bloc avec lequel stocker les informations de disque de l'invité, ce chemin peut être tel que /dev/sdb, /dev/LogVol00/mydisk, VolGroup00, ou /var/lib/xen/images/myDisk.
  4. Cliquez sur Planifier le kickstart et terminer.

2.5.4. Approvisionnement à travers un proxy RHN

L'approvisionnement peut aussi être accompli à l'aide de RHN Proxy qui a été installé et enregistré sur RHN Satellite.
  1. Lors de l'approvisionnement d'un invité virtuel ou lorsque vous effectuez le réapprovisionnement d'un système, sélectionnez le proxy souhaité depuis la boîte déroulante Sélection du Proxy Satellite.
  2. Pour une installation bare metal, remplacez le nom de domaine complet (FQDN) de RHN Satellite par celui du proxy. Par exemple, si l'URL du fichier kickstart est :
    http://satellite.example.com/ks/cfg/org/1/label/myprofile
    
    Alors pour effectuer un kickstart via le proxy, utilisez :
    http://proxy.example.com/ks/cfg/org/1/label/myprofile
    

Chapitre 3. Multiples Satellites

La Synchronisation inter-satellite (aussi appellée ISS) vous permet de coordonner le contenu entre Satellites. Cette fonctionnalité peut être utilisée de plusieurs différentes manières, en fonction des besoins de l'organisation. Ce chapitre contient une section sur les cas d'utilisation et sur comment installer ISS de manière à convenir au mieux à votre organisation.

Prérequis ISS

Ci-dessous figurent les conditions requises pour pouvoir utiliser ISS :
  • Deux serveurs Satellites, ou plus
  • Au moins un RHN Satellite rempli avec au moins un canal
  • Pour les connexions sécurisées, chaque RHN Satellite esclave aura besoin d'un certificat SSL d'un RHN Satellite maître

3.1. Synchronisation ISS (Inter-Satellite Sync)

Procédure 3.1. Configurer le serveur maître

Le serveur maître est utilisé pour déterminer quels fichiers seront synchronisés aux autres Satellites.
  1. Activez la fonctionnalité de synchronisation Inter-Satellite Sync. Ouvrez le fichier /etc/rhn/rhn.conf et ajoutez ou amendez la ligne suivante :
    disable_iss=0
    
  2. Dans le fichier /etc/rhn/rhn.conf, localisez la ligne allowed_iss_slaves=. Par défaut, aucun Satellite esclave n'est spécifié pour être synchronisé. Saisissez donc le nom d'hôte de chaque serveur Satellite esclave, séparé par une virgule. Par exemple :
    allowed_iss_slaves=slave1.satellite.example.org,slave2.satellite.example.org
    
  3. Enregistrez le fichier de configuration, puis redémarrez le service httpd :
    service httpd restart
    

Procédure 3.2. Configurer les serveurs esclaves

Les serveurs Satellites esclaves sont les machines dont le contenu sera synchronisé avec le serveur maître.
  1. Pour transférer le contenu des serveurs esclaves de manière sécurisée, vous devrez posséder le certificat ORG-SSL du serveur maître. Celui-ci peut être téléchargé via HTTP depuis le répertoire /pub/ de n'importe quel Satellite. Le fichier est nommé RHN-ORG-TRUSTED-SSL-CERT, mais il peut être renommé et placé n'importe où dans le système de fichiers local de l'esclave, par exemple dans le répertoire /usr/share/rhn/.
  2. Affichez la liste des canaux disponibles pour synchronisation depuis le serveur maître avec la commande suivante. Cela affichera les canaux Red Hat officiels ainsi que tout canal personnalisé disponible :
    satellite-sync --iss-parent=master.satellite.example.com --ca-cert=/usr/share/rhn/RHN-ORG-TRUSTED-SSL-CERT --list-channels
    
    Remplacez master.satellite.example.com par le nom d'hôte du serveur maître.

Procédure 3.3. Effectuer une synchronisation Inter-Satellite Sync

Une fois que les serveurs maîtres et esclaves sont configurés, une synchronisation peut être effectuée entre eux.
  1. Sur les serveurs esclaves, ouvrez le fichier /etc/rhn/rhn.conf dans un éditeur de texte, puis ajoutez le nom d'hôte et les détails du chemin d'accès du certificat SSL du serveur maître :
    iss_parent      = master.satellite.example.com
    iss_ca_chain    = /usr/share/rhn/RHN-ORG-TRUSTED-SSL-CERT
    
  2. Lancez la synchronisation en exécutant la commande satellite-sync :
    satellite-sync -c your-channel

    Note

    Toute option de ligne de commande fournie avec la commande satellite-sync remplacera tous les paramètres personnalisés dans le fichier /etc/rhn/rhn.conf.

3.2. Synchronisation organisationnelle

La synchronisation ISS peut aussi être utilisée pour importer un contenu vers n'importe quelle organisation spécifique. Ceci peut être effectué localement ou en utilisant une synchronisation à distance. Cette fonction est utile pour un Satellite déconnecté avec de multiples organisations, où le contenu est retrouvé via des vidages de canaux ou en l'exportant depuis des Satellites connectés, puis en l'important sur le Satellite déconnecté. La synchronisation organisationnelle peut être utilisée pour exporter des canaux personnalisés depuis des Satellite connectés. Elle peut aussi être utilisée efficacement pour déplacer un contenu entre de multiples organisations.
La synchronisation organisationnelle comprend certaines règles qui sont suivies afin de maintenir l'intégrité de l'organisation source :
  • Si le contenu de la source appartient à l'organisation NULL (ou à tout autre contenu Red Hat), il se mettra par défaut sur l'organisation NULL même si une organisation destinataire est spécifiée. Ceci assure que le contenu spécifié se trouve toujours dans l'organisation privilégiée NULL.
  • Si une organisation est spécifiée dans la ligne de commande, le contenu sera importé depuis celle-ci.
  • Si aucune organisation n'est spécifiée, il se mettra par défaut sur organisation 1.
Ci-dessous figurent trois scénarios-exemples où des ID organisationnels (orgid) sont utilisés pour effectuer une synchronisation entre Satellites :

Exemple 3.1. Import de contenu depuis le Satellite maître vers le Satellite esclave

Cet exemple importe le contenu depuis le Satellite maître vers le Satellite esclave :
satellite-sync --parent-sat=master.satellite.example.com -c channel-name --orgid=2

Exemple 3.2. Import de contenu depuis le vidage exporté d'une organisation

Cet exemple importe le contenu depuis le vidage exporté d'une organisation spécifique :
$ satellite-sync -m /dump -c channel-name --orgid=2

Exemple 3.3. Import de contenu depuis Red Hat Network Hosted

Cet exemple importe un contenu depuis Red Hat Network Hosted (en supposant que le système est enregistré et activé) :
$ satellite-sync -c channel-name

3.3. Cas d'utilisation ISS

La synchronisation ISS peut être utilisée de plusieurs manières, en fonction des besoins de l'organisation. Cette section propose des exemples de la façon dont vous pouvez choisir d'utiliser la synchronisation ISS ainsi que des méthodes de paramétrage et d'opération.

Exemple 3.4. Satellite de pré-production

Dans cet exemple, un Satellite de pré-production (de l'anglais, « Staging Satellite ») est utilisé pour préparer le contenu et assurer le travail d'assurance qualité (QA) sur les paquetages afin de vérifier qu'ils sont corrects pour une utilisation en milieu de production. Une fois que le contenu est approuvé pour partir en production, le Satellite de production synchronisera le contenu du Satellite de pré-production.
  1. Exécutez la commande satellite-sync pour synchroniser des données avec rhn_parent (habituellement Red Hat Network Hosted) :
    satellite-sync -c your-channel
    
  2. Exécutez la commande suivante pour synchroniser des données depuis le serveur de pré-production :
    satellite-sync --iss-parent=staging-satellite.example.com -c custom-channel

Exemple 3.5. Esclaves synchronisés

Dans cet exemple, le Satellite maître fournit des données directement à ses esclaves, ces changements sont régulièrement synchronisés.

Exemple 3.6. Contenu esclave personnalisé

Cet exemple utilise le Satellite maître comme canal de développement, à partir duquel le contenu est distribué vers tous les Satellites esclaves de production. Certains Satellites esclaves auront un contenu supplémentaire qui n'est pas présent dans les canaux Satellite maîtres. Ces paquetages sont préservés, mais tout changement dans le Satellite maître sera synchronisé avec les Satellites esclaves.

Exemple 3.7. Synchronisation bi-directionnelle

Dans cet environnement, deux serveurs RHN Satellite agissent en tant que maîtres de l'un et de l'autre et peuvent synchroniser leurs contenus respectifs.
  1. Assurez-vous que les deux Satellites peuvent partager les certificats SSL.
  2. Sur le premier Satellite, ouvrez le fichier /etc/rhn/rhn.conf et paramétrez l'option iss_parent pour qu'elle pointe vers le nom d'hôte du second Satellite.
  3. Sur le second Satellite, ouvrez le fichier /etc/rhn/rhn.conf et paramétrez l'option iss_parent pour qu'elle pointe vers le nom d'hôte du premier Satellite.

Chapitre 4. Méthodes et commandes avancées d'API

4.1. L'API XML-RPC

RHN Satellite 5.5 prend en charge l'approvisionnement (« provisioning ») à l'aide de l'API XML-RPC.
Les méthodes d'API suivantes sont utilisées pour la maintenance des profils et des arborescences kickstart :

Tableau 4.1. Méthodes XML-RPC

Nom d'espace XML-RPC Usage
kickstart Crée, importe et supprime des profils kickstart. Aussi utilisée pour répertorier les arborescences et profils kickstart disponibles.
kickstart.tree Crée, renomme, met à jour et supprime les arborescences kickstart.
kickstart.filepreservation Répertorie, crée et supprime des listes de conservation de fichiers qui peuvent être associées à un profil kickstart. Une fois qu'une liste de conservation a été créée, elle peut être associée à un profil kickstart à l'aide de l'appel de la méthode API kickstart.profile.system.add_file_preservations.
kickstart.keys Répertorie, crée et supprime des clés de chiffrement (GPG/SSL) qui peuvent être associées à différents profils kickstart.

Note

Une fois qu'une clé de chiffrement a été créée, elle peut être associée à un profil kickstart à l'aide de l'appel de la méthode API kickstart.profile.system.add_keys.
kickstart.profile Manipule les plages IP, modifie l'arborescence kickstart et les canaux enfants, télécharge les fichiers kickstart associés à un profil, manipule les options avancées, manipule les options personnalisées et ajoute des pré-scripts et post-scripts à un profil kickstart.
kickstart.profile.keys Répertorie, ajoute (associe) et supprime (dissocie) les clés d'activation associées à un profil kickstart.
kickstart.profile.software Manipule la liste des paquetages associée à un profil kickstart.
kickstart.profile.system Gère les conservations de fichiers, gère les clés de chiffrement, active/désactive la gestion de la configuration et les commandes à distance, installe les schémas de partitionnement et les paramètres régionaux associés à un profil kickstart donné.
Les appels de méthodes API qui suivent sont utilisés pour réapprovisionner un hôte et planifier des installations d'invités :
  • system.provision_system
  • system.provision_virtual_guest
Pour obtenir plus d'informations sur les appels API, reportez-vous à la documentation API disponible à l'adresse suivante : https://satellite.example.com/rpc/api

4.2. Cobbler

RHN Satellite utilise Cobbler pour l'approvisionnement. Lorsque les profils kickstart, les arborescences (distributions), et les systèmes d'approvisionnement sont mis à jour dans RHN Satellite, ils sont synchronisés avec l'instance Cobbler sur l'hôte RHN Satellite. Cela signifie que Cobbler peut directement être utilisé pour gérer l'approvisionnement.
Le tableau suivant décrit les commandes de Cobbler :

Tableau 4.2. Commandes Cobbler

Commande Usage
cobbler profile list Exécutez cette commande sur l'hôte RHN Satellite pour afficher une liste des profils
cobbler distro list Affiche une liste des arborescences kickstarts, des noyaux, des disques virtuels et d'autres options
cobbler system list Affiche une liste des enregistrements système créés lorsqu'un kickstart est planifié.
cobbler profile report --name=profile-name or cobbler system report --name=system-name Affiche une sortie plus détaillée concernant un objet spécifique
cobbler profile edit --name=profile-name --virt-ram=1024 Modifie divers paramètres. Cet exemple va allouer 1 Go de RAM à chaque installation virtualisée d'un profil donné.
cobbler system edit --name=system-name --netboot-enabled=1 Force un système a être réinstallé au prochain redémarrage
cobbler system edit --name=system-name --profile=new-profile-name --netboot-enabled=1 Assigne un système à un nouveau profil pour une réinstallation
cobbler system find --profile=profile-name Répertorie tous les systèmes assignés à un profil
cobbler system find --profile="abc" | xargs -n1 --replace cobbler system edit \ --name={} --profile="def" --netboot-enabled=1 Assigne tous les systèmes actuellement assignés au profil abc au profil def et les réinstalle au prochain redémarrage
cobbler profile edit --name=profilename --kopts="variablename=3" --in-place Installe une variable modèle supplémentaire sur un profil sans modifier aucune autre variable
cobbler system edit --name=systemname --kopts="selinux=disabled asdf=jkl" Assigne diverses variables à un enregistrement système et ne tient pas compte des anciennes variables qui auraient pu être installées
cobbler profile find --name="*webserver*" | xargs -n1 --replace cobbler profile edit --name={} --profile="RHEL5-i386" Paramètre toutes les nouvelles installations de tout profil contenant la balise webserver afin qu'elles utilisent un profil nommé RHEL5-i386
Autres paramètres de Cobbler

Seuls quelques paramètres Cobbler doivent être directement modifiés dans /etc/cobbler/settings. L'option pxe_just_once en est un exemple (comme le décrit la Procédure 4.3, « Configurer Cobbler pour utiliser PXE »). L'option server peut aussi être modifiée pour refléter l'adresse ou le nom d'hôte du serveur RHN Satellite.

Après avoir modifié /etc/cobbler/settings, exécutez la commande suivante pour effectuer les changements :
/sbin/service cobblerd restart
cobbler sync

Important

N'ajustez pas d'autres paramètres dans /etc/cobbler/settings. RHN Satellite requiert que ce fichier reste configuré dans la manière déterminée par l'installateur RHN Satellite. Similairement, le fichier /etc/cobbler/modules.conf, qui contrôle les sources d'authentification, doit rester comme l'installateur RHN Satellite l'a créé. Plus particulièrement, le module d'authentification doit rester sous la forme authn_spacewalk et ne peut pas être modifié.

Procédure 4.1. Configurer SELinux pour une utilisation avec Cobbler

Le support SELinux ainsi qu'un pare-feu sécurisé sont installé avec Red Hat Enterprise Linux par défaut. Pour configurer un serveur Red Hat Enterprise Linux pour qu'il utilise Cobbler correctement, SELinux doit être configuré de manière à autoriser les connexions vers et depuis le serveur Cobbler.
  1. Pour activer la prise en charge de Cobbler par SELinux, définissez le booléen SELinux de manière à autoriser les composants du service web HTTPD à l'aide de la commande suivante :
    setsebool -P httpd_can_network_connect true
    
    Le commutateur -P est essentiel car il active les connexions HTTPD de manière persistante sur tous les redémarrages système.
  2. Définissez les règles de contexte du fichier SELinux pour que TFTP serve le fichier image de démarrage à l'aide de la commande suivante sur le serveur Cobbler :
    semanage fcontext -a -t public_content_t "var/lib/tftpboot/.*"
    
  3. IPTables doit être configuré de manière à autoriser le trafic réseau entrant et sortant sur le serveur Cobbler.
    Si vous possédez un ensemble de règles de pare-feu existant qui utilise iptables, veuillez ajouter les règles suivantes pour ouvrir les ports liés à Cobbler :
    Pour TFTP :
    /sbin/iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 69 -j ACCEPT
    /sbin/iptables -A INPUT -m state --state NEW -m udp -p udp --dport 69 -j ACCEPT
    
    Pour HTTPD :
    /sbin/iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 80 -j ACCEPT
    /sbin/iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 443 -j ACCEPT
    
    Pour Cobbler :
    /sbin/iptables -A INPUT -m state --state NEW -m udp -p udp --dport 25150 -j ACCEPT
    
    pour Koan :
    /sbin/iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 25151 -j ACCEPT
    
  4. Enregistrez la configuration du pare-feu :
    /sbin/iptables-save
    
  5. Assurez-vous que les fichiers de configuration sont tous synchronisés en exécutant la commande suivante :
    cobbler sync
    
  6. Démarrez le serveur Satellite :
    /usr/sbin/rhn-satellite start
    

    Avertissement

    Ne démarrez et n'arretez pas le service cobblerd indépendament du service Satellite, cela peut provoquer des erreurs et autres problèmes.
    Assurez-vous de toujours utiliser /usr/sbin/rhn-satellite pour démarrer ou arrêter RHN Satellite.

Procédure 4.2. Configurer les enregistrements système Cobbler

Les enregistrements systèmes Cobbler sont des objets au sein de Cobbler qui conserve la trace d'un système et du profil kickstart qui lui est associé. Pour effectuer un kickstart PXE, un profil kickstart Satellite doit être attaché aux enregistrements système Cobbler pour les machines que vous souhaitez kickstarter.
  1. Rendez-vous sur Détails systèmeApprovisionnement pour chaque système et sélectionnez le profil kickstart à associer.
  2. Cliquez sur Créer un enregistrement système Cobbler afin d'effectuer l'association.
  3. Cette association restera telle quelle indéfiniment à moins que vous ne définissiez l'option pxe_just_once sur « true » pour toute machine donnée. Dans ce cas, l'association sera cassée après la réussite du kickstart. Reportez-vous à la Procédure 4.3, « Configurer Cobbler pour utiliser PXE » pour obtenir plus d'informations sur ce paramètre.

Procédure 4.3. Configurer Cobbler pour utiliser PXE

Cobbler est paramétré pour générer des configurations PXE par défaut, mais pour obtenir le meilleur de flux de travail possible dans le BIOS, l'option de configuration pxe_just_once peut être ajustée.
  1. Souvent, l'ordre BIOS sera défini de manière à ce que le démarrage PXE se produise en premier. Cela signifie que le système ne démarrera pas depuis le disque local à moins que le serveur PXE ne lui en donne l'instruction à distance. Cette installation peut créer un démarrage en boucle (de l'anglais, « boot loop »), dans lequel le système se réinstalle continuellement.
    Pour éviter les démarrages en boucle, ouvrez le fichier /etc/cobbler/settings et ajoutez-y la ligne suivante :
    pxe_just_once: 1
    
    Ce paramètre ajout une macro $kickstart_done dans un modèle kickstart qui dit au système de démarrer localement après avoir terminé l'installation, au lieu de démarrer depuis le réseau.
  2. Si le paramètre pxe_just_once: 1 est inclus et que le système sera réinstallé ultérieurement, vous devrez basculer l'indicateur netboot-enabled sur le système. Ceci peut être effectué à l'aide de l'interface web RHN Satellite ou directement dans Cobbler. Lorsque le système redémarrera, il effectuera une installation PXE, puis recommencera à démarrer à partir du disque local jusqu'à ce que l'indicateur soit réinitialisé.
    Si le BIOS est défini pour démarrer depuis les disques durs locaux en premier, il n'est pas nécessaire d'activer pxe_just_once. Cependant, pour réapprovisionner le système à l'aide de PXE, il sera nécessaire de réinitialiser le MBR (de l'anglais, « Master Boot Record »).

Conventions de dénomination

Pour que les données restent synchronisées entre RHN Satellite et Cobbler, RHN Satellite utilise des conventions de dénomination pour les distributions et les profils. Ces conventions de dénomination sont importantes si vous interagissez avec Cobbler en utilisant l'interface en ligne de commande.
Distributions
$tree_name:$org_id:$org_name (si créé manuellement)
$tree_name (si synchronisé par RHN Satellite)
Profils
$profile_name:$org_id:$org_name

Important

Ne modifiez pas les noms qui ont été automatiquement générés par RHN Satellite. Si le nom est modifié, RHN Satellite ne pourra plus maintenir ces éléments.

Note

Pour assister dans la résolution de problèmes, Cobbler journalise des données dans les journaux RHN Satellite et dans le fichier /var/log/cobbler/

4.3. Koan

L'utilitaire koan (kickstarter sur un réseau, de l'anglais, « Kickstart Over A Network ») permet à RHN Satellite d'être accédé à distance par des hôtes ayant déjà été approvisionnés. Koan vous permet d'effectuer des approvisionnements kickstart, de créer des invités virtuels (sur de hôtes virtuels) et de répertorier les kickstarts disponibles depuis l'hôte RHN Satellite. Il est disponible dans le paquetage koan.

Tableau 4.3. Commandes Koan

Commande Usage
man koan Lisez la page koan du manuel.
koan --replace-self --server=satellite.example.org --profile=profile-name ou koan --replace-self --server=satellite.example.org --system=system-name Réapprovisionne un système existant. Redémarrez après avoir exécuté cette commande pour installer le nouveau système d'exploitation. Ceci peut aussi être utilisé pour mettre à niveau les kickstarts (par exemple pour mettre à niveau un grand nombre de machines depuis une version de Red Hat Enterprise Linux vers la suivante).
koan --virt --server=satellite.example.org --profile=profile-name ou koan --virt --server=satellite.example.org --system=system-name Approvisionner un invité virtuel
koan --list=profiles --server=satellite.example.org ou koan --list=systems --server=satellite.example.org Faire afficher à Cobbler une liste des profils ou systèmes disponibles pour une installation à distance

Note

Pour assister dans la résolution de problèmes, remarquez que Koan journalise des données dans /var/log/koan/.

Chapitre 5. Résolution de problèmes

5.1. Interface web
Q : J'ai des problèmes avec l'interface utilisateur RHN Satellite. Quels fichiers de journalisation devrais-je vérifier ?
5.2. Anaconda
Q : Je rencontre une erreur disant : Erreur lors du téléchargement du fichier kickstart. Quel est le problème et comment puis-je le résoudre ?
Q : Je reçois une erreur d'installation de paquetage disant Le fichier chkconfig-1.3.30.1-2.i386.rpm ne peut pas être ouvert.. Quel est le problème et comment puis-je le résoudre ?
5.3. Tracebacks
Q : Je reçois des courriers électroniques avec « WEB TRACEBACK » pour sujet. Que devrais-je faire à ce propos ?
5.4. Enregistrement
Q : La commande rhnreg_ks échoue lorsque je l'exécute, elle retourne ERROR: unable to read system id (ERREUR : lecture de l'ID du système impossible). Quel est le problème ?
5.5. Kickstarts et snippets
Q : Quelle est la structure des répertoires des kickstarts ?
Q : Quelle est la structure des répertoires des snippets de Cobbler ?

5.1. Interface web

Q :
J'ai des problèmes avec l'interface utilisateur RHN Satellite. Quels fichiers de journalisation devrais-je vérifier ?
R :
Si vous rencontrez des erreurs pendant la visualisation, la planification ou lorsque vous travaillez avec des kickstarts dans l'interface utilisateur RHN Satellite, vérifiez le fichier de journalisation /var/log/tomcat5/catalina.out.
Pour toutes les autres erreurs d'interface utilisateur, vérifiez le fichier de journalisation /var/log/httpd/error_log.

5.2. Anaconda

Q :
Je rencontre une erreur disant : Erreur lors du téléchargement du fichier kickstart. Quel est le problème et comment puis-je le résoudre ?
R :
Cette erreur est habituellement le résultat d'un problème réseau. Pour localiser le problème, exécutez la commande cobbler check, et lisez la sortie. Elle devrait ressembler à ceci :
# cobbler check
The following potential problems were detected:
#0: reposync is not installed, need for cobbler reposync, install/upgrade yum-utils?
#1: yumdownloader is not installed, needed for cobbler repo add with --rpm-list parameter, install/upgrade yum-utils?
#2: The default password used by the sample templates for newly installed machines (default_password_crypted in /etc/cobbler/settings) is still set to 'cobbler' and should be changed
#3: fencing tools were not found, and are required to use the (optional) power management features. install cman to use them
Si cobbler check ne fournit pas de réponse, vérifiez les éléments suivants :
  • Vérifiez que httpd est en cours d'exécution : service httpd status
  • Vérifiez que cobblerd est en cours d'exécution : service cobblerd status
  • Vérifiez qu'il est possible de récupérer le fichier kickstart à l'aide de wget depuis un autre hôte :
    wget http://satellite.example.com/cblr/svc/op/ks/profile/rhel5-i386-u3:1:Example-Org
Q :
Je reçois une erreur d'installation de paquetage disant Le fichier chkconfig-1.3.30.1-2.i386.rpm ne peut pas être ouvert.. Quel est le problème et comment puis-je le résoudre ?
R :
Les clients vont récupérer le contenu de RHN Satellite en se basant sur le paramètre --url dans le kickstart. Par exemple :
url --url http://satellite.example.com/ks/dist/ks-rhel-i386-server-5-u3
Si vous recevez des erreurs d'Anaconda disant qu'il ne peut pas trouver d'image(s) ou de paquetage(s), vérifiez que l'URL du kickstart générera bien une réponse 200 OK. Ceci peut être effectué en tentant de récupérer le fichier se trouvant dans cet URL à l'aide de wget :
wget http://satellite.example.com/ks/dist/ks-rhel-i386-server-5-u3
--2011-08-19 15:06:55--  http://satellite.example.com/ks/dist/ks-rhel-i386-server-5-u3
Resolving satellite.example.com... 10.10.77.131
Connecting to satellite.example.com|10.10.77.131|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 0 [text/plain]
Saving to: `ks-rhel-i386-server-5-u3.1'
2011-08-19 15:06:55 (0.00 B/s) - `ks-rhel-i386-server-5-u3.1' saved [0/0]
Si vous recevez une réponse différente de 200 OK, vérifiez les journaux de l'erreur pour découvrir le problème. Vous pouvez aussi vérifier le fichier qu'Anaconda a essayé de télécharger en cherchant dans le fichier access_log :
# grep chkconfig /var/log/httpd/access_log
10.10.77.131 - - [19/Aug/2011:15:12:36 -0400] "GET /rhn/common/DownloadFile.do?url=/ks/dist/ks-rhel-i386-server-
5-u3/Server  /chkconfig-1.3.30.1-2.i386.rpm HTTP/1.1" 206 24744 "-" "urlgrabber/3.1.0 yum/3.2.19"
10.10.76.143 - - [19/Aug/2011:15:12:36 -0400] "GET /ks/dist/ks-rhel-i386-server-5-u3/Server/chkconfig-
1.3.30.1-2.i386.rpm HTTP/1.1" 206 24744 "-" "urlgrabber/3.1.0 yum/3.2.19"
10.10.76.143 - - [19/Aug/2011:15:14:20 -0400] "GET /ks/dist/ks-rhel-i386-server-5-u3/Server/chkconfig-  
1.3.30.1-2.i386.rpm HTTP/1.1" 200 162580 "-" "urlgrabber/3.1.0 yum/3.2.19"
10.10.77.131 - - [19/Aug/2011:15:14:20 -0400] "GET /rhn/common/DownloadFile.do?url=/ks/dist/ks-rhel-i386-server- 
5-u3/Server/chkconfig-1.3.30.1-2.i386.rpm HTTP/1.1" 200 162580 "-" "urlgrabber/3.1.0 yum/3.2.19"
Si les requêtes n'apparaissent pas dans le fichier access_log, le système pourrait avoir des problèmes avec l'installation réseau. Si les erreurs apparaissent mais génèrent des erreurs, alors vérifiez les journaux des erreurs.
Vous pouvez aussi tenter de télécharger les fichiers manuellement afin de voir si le paquetage est disponible :
wget http://satellite.example.com/ks/dist/ks-rhel-i386-server-5-u3/Server/chkconfig-1.3.30.1-2.i386.rpm

5.3. Tracebacks

Q :
Je reçois des courriers électroniques avec « WEB TRACEBACK » pour sujet. Que devrais-je faire à ce propos ?
R :
Typiquement, un email traceback ressemble typiquement à ceci :
Subject: WEB TRACEBACK from satellite.example.com
Date: Wed, 19 Aug 2011 20:28:01 -0400
From: RHN Satellite <dev-null@redhat.com>
To: admin@example.com

java.lang.RuntimeException: XmlRpcException calling cobbler.
	at com.redhat.rhn.manager.kickstart.cobbler.CobblerXMLRPCHelper.invokeMethod(CobblerXMLRPCHelper.java:72)
	at com.redhat.rhn.taskomatic.task.CobblerSyncTask.execute(CobblerSyncTask.java:76)
	at com.redhat.rhn.taskomatic.task.SingleThreadedTestableTask.execute(SingleThreadedTestableTask.java:54)
	at org.quartz.core.JobRunShell.run(JobRunShell.java:203)
	at org.quartz.simpl.SimpleThreadPool$WorkerThread.run(SimpleThreadPool.java:520)
Caused by: redstone.xmlrpc.XmlRpcException: The response could not be parsed.
	at redstone.xmlrpc.XmlRpcClient.handleResponse(XmlRpcClient.java:434)
	at redstone.xmlrpc.XmlRpcClient.endCall(XmlRpcClient.java:376)
	at redstone.xmlrpc.XmlRpcClient.invoke(XmlRpcClient.java:165)
	at com.redhat.rhn.manager.kickstart.cobbler.CobblerXMLRPCHelper.invokeMethod(CobblerXMLRPCHelper.java:69)
	... 4 more
Caused by: java.io.IOException: Server returned HTTP response code: 503 for URL: http://someserver.example.com:80/cobbler_api
	at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1236)
	at redstone.xmlrpc.XmlRpcClient.handleResponse(XmlRpcClient.java:420)
	... 7 more
Ceci indique qu'un problème s'est produit lors de la communication de Cobbler avec le service taskomatic. Essayez de vérifier les éléments suivants :
  • Vérifiez que httpd est en cours d'exécution : service httpd status
  • Vérifiez que cobblerd est en cours d'exécution : service cobblerd status
  • Vérifiez qu'il n'existe pas de règle de pare-feu qui pourrait prévenir les connexions localhost

5.4. Enregistrement

Q :
La commande rhnreg_ks échoue lorsque je l'exécute, elle retourne ERROR: unable to read system id (ERREUR : lecture de l'ID du système impossible). Quel est le problème ?
R :
Il existe une section %post qui enregistre la machine sur RHN Satellite à la fin du fichier kickstart :
# begin Red Hat management server registration
mkdir -p /usr/share/rhn/
wget http://satellite.example.com/pub/RHN-ORG-TRUSTED-SSL-CERT -O /usr/share/rhn/RHN-ORG-TRUSTED-SSL-CERT   
perl -npe 's/RHNS-CA-CERT/RHN-ORG-TRUSTED-SSL-CERT/g' -i /etc/sysconfig/rhn/*  
rhnreg_ks --serverUrl=https://satellite.example.com/XMLRPC --sslCACert=/usr/share/rhn/RHN-ORG-TRUSTED-SSL-CERT --activationkey=1-c8d01e2f23c6bbaedd0f6507e9ac079d
# end Red Hat management server registration
En interprétant ceci dans l'ordre d'ajout, ceci va :
  • Créer un répertoire pour héberger le certificat SSL personnalisé utilisé par RHN.
  • Récupérer le certificat SSL à utiliser pendant l'enregistrement.
  • Chercher et remplacer les chaînes du certificat SSL depuis les fichiers de configuration de rhn-register, puis enregistrer sur RHN Satellite à l'aide du certificat SSL et d'une clé d'activation. Chaque profil kickstart inclut une clé d'activation qui assure que le système se voit assigné une base et des canaux enfants corrects, ainsi que les bons droits d'accès. S'il s'agit du réapprovisionnement d'un système existant, la clé d'activation assurera aussi que celui-ci soit bien associé au profil système précédent.
Si la commande rhnreg_ks échoue, vous pourriez voir des erreurs comme celle-ci dans le fichier de journalisation ks-post.log :
ERROR: unable to read system id.
Ces erreurs se produiront aussi si vous tentez d'effectuer rhn_check et que votre système n'a pas été enregistré sur RHN Satellite.
La meilleure manière de résoudre ce problème est d'afficher le fichier kickstart et de directement copier et coller les quatres étapes lors de l'invite de commande une fois que le kickstart est terminé. Cela produira des messages d'erreurs plus détaillés qui vous aideront à localiser le problème.

5.5. Kickstarts et snippets

Q :
Quelle est la structure des répertoires des kickstarts ?
R :
Le chemin de base où les kickstarts sont stockés est /var/lib/rhn/kickstarts/. Dans ce répertoire, les kickstarts bruts se trouvent dans le sous-répertoire upload, et les kickstarts générés par assistant se trouvent dans le répertoire wizard :
Raw Kickstarts: /var/lib/rhn/kickstarts/upload/$profile_name--$org_id.cfg
Wizard Kickstarts: /var/lib/rhn/kickstarts/wizard/$profile_name--$org_id.cfg
Q :
Quelle est la structure des répertoires des snippets de Cobbler ?
R :
Les snippets de Cobbler sont stockés dans /var/lib/rhn/kickstarts/snippets. Cobbler accède aux snippets à l'aide du lien symbolique /var/lib/cobbler/snippets/spacewalk.
Snippets:  /var/lib/rhn/kickstarts/snippets/$org_id/$snippet_name

Important

Les RPM de RHN Satellite s'attendent à ce que les répertoires des snippets et kickstarts de Cobbler se trouvent à leurs emplacements par défaut, ne les modifiez pas.

Annexe A. Historique des versions

Historique des versions
Version 4-2.2.4002013-10-31Rüdiger Landmann
Rebuild with publican 4.0.0
Version 4-2.2Tue Mar 26 2013Sam Friedmann
Fichiers de traduction synchronisés avec les sources XML 4-2
Version 4-2.1Thu Feb 21 2013Sam Friedmann
Translation files synchronised with XML sources 4-2
Version 4-2Wed Sept 19 2012Dan Macpherson
Mise en paquetage finale pour 5.5
Version 4-1Thu Aug 9 2012Athene Chan
Mise en pré-production pour publication
Version 4-0Mon June 25 2012Athene Chan
Mise à jour des chapitres 1 et 2 pour RHN Satellite 5.5
Modification des chapitres 3 - 5 pour RHN Satellite 5.5
BZ#787348 Ligne iptables Cobbler incorrecte
BZ#702529 Ajout d'informations supplémentaires sur Kickstart
BZ#797688 ISO de démarrage de Cobbler non pris en charge
Version 3-0Thu May 31 2012Athene Chan
BZ#826803 - Correction de la ponctuation dans la section « Kickstarter une machine »
Modifications mineures de grammaire apportées à la section kickstart.
Version 2-0Thu May 24 2012Athene Chan
BZ#783339 - Restructuration de phrases dans la section « Approvisionnement de résolution de problèmes Taskomatic »
BZ#783340 - Mise à jour de "s390x" vers "IBM System z"
Version 1-3Mon Aug 15 2011Lana Brindley
Version du flux z plié dans le flux y
Version 1-2Wed Jun 15 2011Lana Brindley
Préparation pour traduction
Version 1-1Fri May 27 2011Lana Brindley
Mises à jour de la part des traducteurs
Version 1-0Fri May 6, 2011Lana Brindley
Modifications de la révision QE finale
Préparé pour traduction
Version 0-8Thu May 5, 2011Lana Brindley
BZ#701822 - Révision QE
Version 0-7Thu April 14, 2011Lana Brindley
Commentaires de la révision technique
Version 0-6Wed March 23, 2011Lana Brindley
Préparation pour la révision technique
Version 0-5Tue March 22, 2011Lana Brindley
BZ#666435
BZ#666846
BZ#678080
BZ#682364
Version 0-4Tue March 22, 2011Lana Brindley
Résolution de problèmes
Version 0-3Mon March 21, 2011Lana Brindley
Multiples Satellites
Version 0-2Thu March 17, 2011Lana Brindley
Introduction
Kickstart
Commandes avancées
Restructuration de chapitre
Version 0-1Wed Jan 5, 2011Lana Brindley
Nouvelle structure de chapitre terminée
Version 0-0Tue Dec 21, 2010Lana Brindley
Création de nouveau document à partir du Guide de déploiement RHN Satellite original

Note légale

Copyright © 2011 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.