Red Hat : Satellite 6

De Justine's wiki
Aller à la navigation Aller à la recherche

Features sur le site de Red Hat Bases A VOIR : Power Using


Généralités

Sat. est une solution de gestion de systèmes qui permet de déployer, configurer et maintenir les systèmes sur différentes plateformes. Sat. offre du provisionning, de la gestion à distance et du monitoring. Les fonctionnalités incluent la gestion du cycle de vie, la gestion des utilisateurs et groupes, la gestion des souscriptions, ainsi que CLI, GUI, API.

Il fait partie d'un ensemble de technologies de management, comme Insights et Ansible. Le but est donc d'amener un ensemble de workflows de travail, qui sont faciles à retrouver au travers de tout ces est Red Hat. Leur but est de pouvoir gérer toute la vie du système à l'aide de leur technos.

Il y'a deux bécanes principales: le serveur Satellite et la capsule Satellite.

  • Le serveur gère les dépôts, offre du RBAC (Role Based Access Control), offre des UI et gère les souscriptions.
  • La capsule Permet de scaler l'environnement Satellite, fournit contenu /intégration/prov. local, et peut découvrir les nouvelles machines.

Les capsules peuvent reprendre tous les rôles d'un serveur : l'idée est par ex. d'en avoir une par datacenter.

Patching et gestion de software avec Sat

Vidéo d'explications

Sat permet de finir un "SOE" : *standard operating environment*. Un SOE couvre deux idées:

  • Définir les builds, applications et charges de travails qui tournent sur Red Hat;
  • Définir comment manager et intégrer ces applications dans la boîte, en voyant tout ça comme un ensemble pour avoir les outils pour gérer une app de a à z.

Un SOE permet de faciliter le patch et l'utilisation de stratégies de sécurité. On peut non seulement ajouter des contenus Red Hat, mais aussi d'autres contenu dans les sources de Satellite. Une fois cela en place, Sat possède ce contenu et on peut s'en servir facilement.

Processus de déploiement d'un patch avec Satellite

On va commencer par déployer un patch sur un hôte.

On commence par aller sur la liste des hôtes, et on va voir dans la colonne les 4 types de patches que l'on peut déployer : Sécurité, Bugfix, Améliorations, et Updates de paquets. En partant sur un patch de sécurité :

  • Je clique sur l'hote
  • Onglet Errata
  • J'ai une liste. Je peux cliquer sur un errata pour avoir plus d'infos.
  • Sur la liste, je peux cocher un ou plusieurs errata et "Apply selected".

Avec un groupe d'hôtes:

  • Content > Errata
  • Dans la colonne "Content Host Counts", je vois le nombre d'hôtes concernés.
  • En cliquant sur un errata, je peux voir les hotes concernés.
  • Au même endroit, je peux choisir mes errata et les appliquer à tous les hôtes concernés.

Quand je lance une install d'errata, je peux voir les détails en allant dans Monitor > Tasks.

Source logicielle tierce et composite content view

Avec un software tierce partie, on va passer par epel ici. Epel utilise GPG, alors il va falloir créer des creds.

  • Content > Content Credentials
  • Create...
  • Nommer "EPEL", choisir Clef GPG, et rentrer la clef récupérée chez Epel.
  • Save.
  • On va ensuite créer un produit. Content > Products > Create Product
  • On lui donne un nom, la Clef GPG qu'on vient de faire.
  • Pas besoin de clefs SSL. On peut donner une description, puis save.
  • On a créé le produit comme catégorie, mais il faut encore ajouter les repos à y associer. Donc, "new repo"
  • On donne un nom et un label.
  • Type : yum
  • Restrict to architecture en fonction des besoins
  • Upstream URL : url du repo
  • Choisir la clef GPG
  • Save.

On va synchroniser le contenu.

  • Cocher la case du repo, puis "sync now".

On peut ensuite créer une content view avec ces repos.

On peut créer une content view de base avec ce repo, si on le veut. C'est d'ailleurs la première étape, car nous allons ici créer une CV composite. On part du principe que j'ai une CV "rhel" déjà prête.

  • Je crée une content view "epel", qui ne contient que le repo EPEL. Je ne la publie pas, et je ne la promote pas.
  • Je créée une CV "rhel + epel", avec un nom et un label identiques.
  • Je coche "composite content view" et "auto-publish". L'auto publish ne s'applique qu'aux CV composites, et permet de republier la CV quand une de ses CV composantes et mise à jour.
  • Je vais sur la CV epel et je la publie.
  • Puisque ses deux composants sont déjà publiés et qu'elle est auto-publish, la CV "epel+rhel est auto publiée.

Je peux ensuite la donner ensuite à un hôte qui serait en environnement library en allant dans host > content host, cliquer sur un hôte et lui donner la CV.

Je peux maintenant patcher mes hôtes.



Update une CV en rajoutant un repo puis utiliser ce nouveau repo sur les clients

  • On commence par ajouter les repos à la CV, puis la promouvoir dans le bon environnement.
  • Ensuite, sur la bécane :

<source> subscription-manager refresh subscription-manager repos –list #Récupérer l’ID subscription-manager repos –enable <identifiant ID> yum makecache </source>

Logs de subscription-manager

Ils se trouvent dans /var/log/rhsm