sources : 

https://wikisi.ensta-bretagne.fr/doku.php?id=linux:infra:puppet:install:dashboard
https://wikisi.ensta-bretagne.fr/doku.php?id=linux:infra:puppet:install:client
https://wikisi.ensta-bretagne.fr/doku.php?id=linux:infra:puppet:install:master

Pourquoi Puppet 8

Suite à l’installation de Red Hat 9 une installation d’une architecture de gestion puppet 8 est requise.

Le réseau de l’Ensta étant sous Puppet 3 & Puppet 5 (ne supportant pas le RedHat 9) il est nécessaire d’opter pour une installation d’une infra Puppet 8.

En premier temps il sera plus pratique d’opérer les changements sur RedHat 8 du fait que les classes opérantes seront possiblement changées sous Puppet 8

Schéma explicatif : 

L’Ensta possède 2 infrastructures puppet.

Le premier sous puppet 3 gérant le centos7

le deuxième sous puppet 5 gérant le RHEL 8

et le 3e qui est l’objectif à créer, une infra sous puppet 8 qui gère le RHEL 9

INSTALLATION 

INSTALLATION Puppet Master 8 (server)

-> VM utilisée puppet master 8 // Définition du bon hostname important pour les certificats

  1. installation du repository avec la commande 

rpm -Uvh https://yum.puppet.com/puppet8-release-el-9.noarch.rpm

  1. installation de chrony pour synchroniser les machines : 

yum install chrony

  1. Installation de Git + ruby

yum install git yum install ruby

  1. Installation de puppet server sur puppet master 8

yum install puppetserver

Configuration du fichier puppet dans /etc/puppetlabs/puppet

Fichier de config /etc/puppetlabs/puppet

INSTALLATION Puppet Agent (client)

-> VM utilisée Redhat 9

  1. installation du repository avec la commande 

rpm -Uvh https://yum.puppet.com/puppet8-release-el-9.noarch.rpm

  1. Installation de l’agent puppet

yum install puppet-agent

  1. Fichier de conf /etc/puppetlabs/puppet/puppet.conf

INSTALLATION Puppet Node 8 (Dashboard)

-> vm utilisée Puppet Nodemanager 8

I/ INSTALLATION 

  1. Modules à installer 

Chrony

yum install chrony

git

yum install git

outils de développement

yum group install development

Dépendances pour application

yum install ruby ruby-devel mariadb-server mariadb-devel nodejs libxml2-devel libxslt-devel libpq-devel

Démarrage et activation de mariadb

systemctl start mariadb

systemctl enable mariadb

  1. Application

Génération d’un compte de service

useradd puppet-dashboard

//Servira à faire tourner l’application

Installation de l’application

cd /usr/share && \

git clone https://github.com/sodabrew/puppet-dashboard.git && \

cd puppet-dashboard

Attribution des droits sur le répertoire

chown -R puppet-dashboard:puppet-dashboard /usr/share/puppet-dashboard

  1. Base de données 

Création bdd + utilisateur // Modifier le mot de passe !!

mysql -p -e »CREATE DATABASE dashboard_production CHARACTER SET utf8; » && \

mysql -p -e »CREATE USER ‘username’@’localhost’ IDENTIFIED BY ‘password’; » && \

mysql -p -e »GRANT ALL PRIVILEGES ON dashboard_production.* TO ‘dashboard’@’localhost’; »

Vérification

mysql –user=’username’ –password=’password’ dashboard_production -e »SHOW GRANTS »

// affiche la base de donnée

Paramétrage de la BDD mariadb -> /etc/my.cnf.d/mariadb-server.cnf

Relancer le serveur mariadb

systemctl restart mariadb

  1. Paramétrage application

-> /usr/share/puppet-dashboard/config/settings.yml.example

Préparation fichiers de configuration

cd /usr/share/puppet-dashboard

cp settings.yml.example settings.yml

cp database.yml.example database.yml

chmod 660 database.yml  

// 660 == Propriétaires = ok lecture +  écriture – execution(4+2+0) Groupe = idem(4+2+0) autres : aucun droit(0+0+0)

Personnalisation fichier settings.yml

ca_server: ‘puppetmaster’

inventory_server: ‘puppetmaster’

file_bucket_server: ‘puppetmaster’

# Key length for SSL certificates

#key_length: 1024

key_length: 4096

# Time zone

time_zone: ‘Paris’

Personnalisation fichier database.yml

// ajout du mdp dans la base de donnée de prod

  1. Dépendances application 

gestionnaire de dépendances ruby

gem install bundle

installation des dépendances

bundle install

Après ce point, je me suis rendu compte que ça ne serait pas possible de continuer l’installation du fait que bundle n’est pas à jour pour supporter puppet 8 et RHEL 9. Une décision à été prise, nous allons cloner le dashboard déjà existant et modifier des éléments afin de l’utiliser avec le nouveau serveur puppet master et puppet agent 

II/ Certificats

Certificats nécessaires :

  • pour la communication entre puppet master et puppet dashboard (uniquement pour la fonction dashboard !!! Un autre certificat est nécessaire si le puppet dashboard est lui-même client puppet)
  • pour l’accès web en https

A priori les mêmes certificats sont utilisés pour ces deux fonctions

Via le dossier /usr/share/puppet-dashboard il faudra se mettre en utilisateur de puppet-dashboard (su -l puppet-dashboard)

Nous devons nous occuper des certificats afin de s’assurer la communication entre serveurs

RAILS_ENV=production /usr/local/bin/bundle exec rake cert:create_key_pair

// génère une paire de clés privée et publique

RAILS_ENV=production /usr/local/bin/bundle exec rake cert:request

//génère une demande de certificat SSL

(SUR PUPPET MASTER -> vérifier la création du certificat SSL) //firewall peut poser problème pour la création 

puppetserver ca list –all

si l’auto sign n’est pas configuré, il faut signer le certificat manuellement 

puppetserver ca sign –certname dashboard

III/ Relations puppet master et puppet dashboard

Sur Puppet master dans /etc/puppetlabs/puppet/puppet.conf ajouter la configuration des agents et indiquer L’URL permettant d’envoyer les reports au puppet dashboard

Dashboard for Node Classification (external)

Récupérer des informations sur les machines gérées de l’infrastructure.

  node_terminus = exec

  external_nodes = /usr/bin/env PUPPET_DASHBOARD_URL=http://puppetnodemanager.ensieta.ecole:3000 /opt/puppet-dashboard/bin/external_node                                                                                                               

Test du dashboard depuis l’agent puppet non fonctionnel. Plusieurs paramètres à changer.

-> Firewall, via le serveur puppet il faut ouvrir le port 8140 afin d’autoriser la communication 

-> fichier config puppet sur le serveur. Vérifier que la config est exacte

->Copier le fichier external_node présent dans le dashboard puppet (même endroit) dans le /opt/puppet-dashboard/bin du serveur puppet

Test fonctionnel vérifiable depuis le dashboard accessible via https://puppetnodemanager8

communication effectuée 

Bootpxe

Reprise du fichier kickstart afin de rajouter Puppet 8; lors de l’installation 

Puppet=true puppetversion=8 paramètres nécessaires pour zziniOS.sh

Rajout de la version8 de puppet dans l’initialisation 

Lignes du fichier  kickstart à commenter car obsolète

Le fichier ZZinitOS.sh va s’occuper d’installer l’agent puppet sur la machine virutelle, de ce fait l’installation sera automatique tout en étant lancé dès lors de l’installation.

Le fichier de log de ZZinitOS se situe dans le /var/log

CLASSES

Le but désormais va être de définir des classes du serveur puppet afin de faires fonctionner ces dernières en prenant en compte puppet 8 et redhat 9 suite à un push git sur le serveur puppet 

voici les classes à modifier

Nous avons rencontré plusieurs problèmes récurrents liés à la ressource file_line qui n’était pas reconnue, de ce fait il fallait installer le module stdlib dans /etc/puppetlabs/code/environments/production/modules/common/manifests

puis faire un puppetserver reload afin de prendre en compte les changements.

Common (Fonctionnelle)

dest_install_set.pp

Dest_install n’était pas défini dans le nodemanager8

Validate_re soit une ressource du module stdlib n’est pas reconnu, après recherches il est possible que la fonction soit obsolète de ce fait il faut la remplacer dans les fichiers où elle était présente comme dans 

selinux_set.pp

commentation pour l’instant

Init.pp

Puppet agent retourne cette erreur ::set_selinux n’est pas reconnu et n’existe plus sur puppet8

via init.pp définition de set_selinux dans le dashboard + remplacement de operatingsystemajrelease par $facts[‘os’][‘distro’][‘release’][‘major’] 

Ajout de la version 9 dans les différents case

Suppression des versions inutiles et mise à jour des paquets disponibles pour redhat9.

paquets dispo sous redhat8

paquets dispo pour redhat 9

tmux remplaçant de screen obsolète depuis redhat7

selinux.pp

osfamily,selinux et operatingsystemmajrelease à changer 

set_key.pp

ligne commenté pour l’instant

ce fichier est obsolète car s’occupant d’une fonction dont on ne s’occupe plus 

cockpit.pp

lancement d’un test de l’agent puppet, la classe common est opérationnelle avec redhat9

Yum

params.pp

modification de operatingsystemmajrelease et ajout de Rhel9

—————————————————————————————————————————–

modif $::architecture

—————————————————————————————————————————–

modif $::architecture , $::operatingsystemmajrelease

—————————————————————————————————————————–

modif $::operatingsystemmajrelease $::remi_repo

Puppet

init.pp

possibles modifications : 

  • family à la place de osfamily

migrate.pp

Rien à modifier 

params.pp

possibles modifications : 

$::dashboard_migrate n’existe pas

$migrate_server = ‘puppetmaster8.ensieta.ecole’

$migrate_puppet_version = ‘8’

// changements pour serveur mrepo conf,puppetrpm ?

  • mettre valeures à jour

case ‘8’ :{

$server = puppetmaster8.ensieta.ecole

$puppetv = 8.6.0

puppet_environment non existent

Redhat.pp

possibles modifications 

  • update la version pour 9 (RHEL)

// à changer potentiellement par l’une de ces valeurs 

PUPPET/TEMPLATES

Rien à changer au premier balayage

PUPPET/DATA

puppet::redhat::: 8

SITE.PP

Site.pp (puppet agent echec)

problème 1 

le case $::osfamily n’est pas reconnu à remplacer par case $facts[‘family’]

problème 2

le $::operatingsystem n’est pas reconnu

En remplaçant les valeurs précédentes par celles-ci ça fonctionne, tests avec variables concluant 

problème 3

Impression que la location n’est pas définie dans la commande  facter -p | grep set_location.

En effet, certaines variables comme set_location n’était pas présente directement dans le server il fallait donc les importer(set_location en faisait partit)

Catégories : Non classé

0 commentaire

Laisser un commentaire

Emplacement de l’avatar

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *