Rapport Admin Linux Avancee Grp1

Administration Linux Avancée
Industrialiser Linux à l’aide d’Ansible

2ème année M2i - Réseaux et Systèmes
Nathan LE CORRONC
Raphaël MANOURY
Thomas KIEFFER
Sugesh ANANDAN
Année scolaire 2022 - 2023

ESIEE-IT - 2ème année M2I - Réseaux et Systèmes - Année scolaire 2021-
2022
Introduction 3
Infrastructure attendue 3
Qu’est-ce qu’Ansible? 3
Fonctionnement d’Ansible et lexique 4
Mise en place de l’infrastructure 5
Configuration de l’Orchestrateur 5
Configuration des machines virtuelles 6
Création de l’inventaire Ansible 7
hosts.yaml 7
Déploiement du premier playbook 8
playbook.yml 8
Définition du mot de passe SQL ‘root’ et suppression de l’authentification par socket 10
playbook_resetting_mariadb_password_dbservers.yml 10
Autorisation des connexions distantes sur les serveurs de base de données et installation
automatique de WordPress. 11
playbook_wp.yml 11
Installation d’Heartbeat et configuration du cluster Haute Disponibilité 17
playbook_webservers.yml 17
Mise en place de la réplication des serveurs de base de données 19
playbook_dbservers_replication.yml 19
Configuration du serveur Syslog et redirection des logs des serveurs web + des serveurs de base de
données 21
playbook_syslog.yml 21
Synchronisation du temps avec NTP 23
playbook_ntp.yml 23
Configuration d’une tâche de sauvegarde quotidienne au moyen d’un script shell exécuté par
crontab 24
backupsql.sh 24
playbook_dbservers.yml 24
Conclusion 25
2/23
2022
Introduction
L’objectif de ce projet est de déployer une infrastructure redondante et sécurisée de

manière automatisée à l’aide d’Ansible, tout en utilisant Git. Afin d’avoir un suivi des
versions et permettre de voir l’avancement du projet
Dépôt GIT correspondant au projet: https://github.com/NathanLCN/Project-GIT-Groupe-1
Infrastructure attendue
Qu’est-ce qu’Ansible?
Ansible est une brique logicielle Open Source qui permet de manager une
infrastructure automatique: déploiement automatisés multi-environnements, gestion de
configuration systèmes et application de mises à jour. Ansible a été développé en 2012 par
Michael Dehaan, est essentiellement écrit en Python et fonctionne sous environnement
Linux.
3/23
2022
Fonctionnement d’Ansible et lexique

Ansible fonctionne à travers des connexions réseaux. Nous avons un Orchestrateur
Ansible qui initie des connexions, généralement au travers du protocole SSH, vers les
machines clientes afin de leur envoyer des instructions.
Les fichiers utilisés par Ansible sont au format YAML.
Les machines clientes sont définies dans un inventaire (fichier YAML). Les inventaires
Ansible peuvent contenir des groupes parents, des groupes enfants, des variables… Ce qui
nous permet de pouvoir scinder les tâches à effectuer selon le type de machines ou le rôle
d’une machine au sein d’un SI.
Ansible permet d’utiliser différents modules, qui sont exécutés sur les machines clientes
(contenues dans le(s) fichier(s) d’inventaire), au travers de playbooks.
Ces playbooks sont aussi au format YAML et permettent de définir des instructions à lancer
sur les machines. Ces playbooks peuvent être construits de telle manière à cibler une
machine ou un groupement de machines.
4/23
2022
Mise en place de l’infrastructure
Afin de mettre en place l’infrastructure demandée, nous avons besoin tout d’abord
d’un Orchestrateur Ansible, une machine sous Linux.
Comme nos machines physiques sont sous Windows, nous avons utilisé WSL (Windows
Subsystem for Linux) afin de faire tourner une machine virtuelle Debian 11 sur notre
machine physique.
Configuration de l’Orchestrateur
En PowerShell sur la machine hôte:
wsl –install
wsl -l –v permet de verifier la version installé
Génération d’une paire de clé SSH:
ssh-keygen
Création du répertoire Ansible et liaison au dépôt Git:
$ git config --global user.name "Nathan LE CORRONC"

$ git config --global user.email "nathan.lcn01@gmail.com"
$ git init
$ git remote add origin git@github.com:username/Ansible
5/23
2022
Nous avons utilisé Ansible Vault afin de chiffrer les mots de passe utilisés lors du lancement
des playbooks. Ainsi, un fichier chiffré contient l’ensemble des mots de passe que nous
utilisons. Nous utiliserons le paramètre ‘--ask-vault-pass’ lors du lancement de nos
playbooks, et y saisirons le super mot de passe, afin qu’Ansible puisse déchiffrer et utiliser
les mots de passe de manière sécurisés.
Configuration des machines virtuelles

Nous avons choisi d’utiliser VirtualBox pour gérer nos 5 machines virtuelles. Elles
tournent toutes sous Ubuntu Server 20.04 et disposent de la même configuration dès le
déploiement, à savoir la même combinaison user/pwd pour faciliter le déploiement du
premier playbook.
Cela revient donc à dire qu’afin de déployer l’infrastructure attendue, les seuls prérequis
sont d'avoir 5 VM Vierges sous Linux et un Orchestrateur Ansible.
6/23
2022
Création de l’inventaire Ansible

Ce fichier d’inventaire va recenser l’ensemble de nos machines clientes,
l'interpréteur python à utiliser sur ces machines pour le lancement des instructions, et
l’utilisateur avec lequel ces instructions seront lancées.
$ cd ansible
$ touch hosts.yaml
hosts.yaml
all:
vars:
ansible_python_interpreter: /usr/bin/python3
ansible_user: user
children:
webservers:
hosts:
webserver1:
ansible_host: 192.168.77.50
webserver2:
dbservers:
hosts:
dbserver1:
mysql_server_id: 1
mysql_log_basename: master1
dbserver2:
mysql_server_id: 2
mysql_log_basename: master2
syslogservers:
hosts:
syslogserver1:
7/23
2022
Déploiement du premier playbook

Ce premier playbook va nous permettre de déployer la clé publique SSH de
l’Orchestrateur, afin de pouvoir déployer les playbooks suivants au travers de SSH. Il va
par ailleurs créer un groupe ‘admin’ et créer un utilisateur ‘sfleury’ (anciennement ‘esiee’)
puis l’intégrer au groupe ‘admin’.
Ensuite, il va autoriser les membres du groupe ‘admin’ a effectuer des sudo sans mots de
passe et va, au travers d’une boucle, mettre à jour les fichiers /etc/hosts des machines
clientes dynamiquement afin de ne pas avoir de problème lors de la résolution de noms.
Enfin, il va installer certains paquets nécessitant d’être installés dès lors: mariadb-server et
PyMySql sur les serveurs BDD.
$ ansible-playbook playbook.yml -i hosts.yaml -K --ask-vault-pass -e

"ansible_user=user" --ask-pass
Cette commande va nous permettre de lancer le playbook ‘playbook.yml’ avec comme

fichier d’inventaire ‘hosts.yaml’ en s’authentifiant avec le compte local de chaque machine
cliente.
playbook.yml
---
- hosts: all
become: true
vars:
users:
-"user"
tasks:
- name: "Create admin group"

group:
name: "admin"
state: present
- name: "Add sudoers users to 'admin' group"

user:
name: "{{ item }}"
groups: "admin"
8/23
2022
append: yes
state: present
createhome: yes
with_items: "{{ users }}"
- name: "Create directory"

file:
path: "/home/{{ item }}/.ssh"
state: directory
with_items: "{{ users }}"
- name: "Set up authorized keys to be able to SSH through

VMs" ansible.posix.authorized_key:
user: user
state: present
key: '{{ item }}'
with_file:
- ./id_rsa.pub
- ./id_rsa_2.pub
- ./id_rsa_fleury.pub
- name: "Allow 'admin' group to sudo without

password" lineinfile:
dest: /etc/sudoers
state: present
regexp: '^%admin'
line: '%admin ALL=(ALL) NOPASSWD: ALL'
validate: 'visudo -cf %s'
- name: "Build hosts file and dispatch it automatically through all the
VMs" lineinfile:
path: /etc/hosts
regexp: '.*{{ item }}$'
line: "{{ hostvars[item].ansible_default_ipv4.address }} {{item}}"
state: present
when: hostvars[item].ansible_default_ipv4.address is defined
with_items: "{{groups.all}}"
- hosts: [dbservers]
become: true
tasks:
- name: "apt-get update"

shell: 'apt-get update'
9/23
2022
- name: "Install some packages"
apt:
name:
- mariadb-server
- mariadb-client
- python3-pymysql
state: latest
Définition du mot de passe SQL ‘root’ et suppression de

l’authentification par socket
Lors de l’installation de mariadb (ou de mysql), le mot de passe ‘root’ n’est pas
défini. Nous allons alors, grâce à ce playbook, le définir en nous authentifiant par le socket
de connexion. Puis, une fois celui-ci supprimé, le playbook va supprimer la connexion par
socket par mesure de sécurité. A noter qu’à partir de maintenant, nos playbooks sont
lancés au travers de SSH et avec l’utilisateur que nous avons précédemment créé (‘user’).
$ ansible-playbook playbook_resetting_mariadb_password_dbservers.yml -i hosts.yaml

--ask-vault-pass
playbook_resetting_mariadb_password_dbservers.yml
---
become: true
tasks:
- name: "Check if root password is unset"

shell: >
mysql -u root
-h localhost
-S /var/run/mysqld/mysqld.sock
-e "quit"
changed_when: false
ignore_errors: true
register: root_pwd_check
tags: mariadb
- name: "Check if the specified root password is already

set" shell: >
mysqladmin -u root -p{{ mysql_root_password }} status
changed_when: false
no_log: true
10/23
2022
when: root_pwd_check.rc != 0
tags: mariadb
- name: "Check for previously set unix_socket in plugin

column" command: >
mysql -N -s -S /var/run/mysqld/mysqld.sock -u root -e
"SELECT plugin from mysql.user WHERE user = 'root'"
register: plugin_root_result
changed_when: plugin_root_result.stdout is search('unix_socket')
when: root_pwd_check.rc == 0
tags: mariadb
- name: "Set MariaDB root password for the first time"

mysql_user:
name: root
password: "{{ mysql_root_password }}"
host: localhost
login_unix_socket: /var/run/mysqld/mysqld.sock
state: present
tags: mariadb
Autorisation des connexions distantes sur les serveurs de

base de données et installation automatique de WordPress.
Nous avons utilisé les templates au format Jinga2 afin de construire préalablement
des fichiers de configuration et les pousser sur les machines clientes. Ainsi, ce playbook va
pousser deux fichiers de configuration: l’un pour le serveur maître de la réplication SQL,
l’autre pour le serveur élève de la réplication SQL.
Ensuite, ce playbook téléchargera WordPress et l’installera automatiquement.
$ ansible-playbook playbook_glpi.yml -i hosts.yaml --ask-vault-pass
playbook_wp.yml
---
become: true
handlers:
- name: "Restart mysql service"
service:
name: mysql
state: restarted
11/23
2022
tasks:
- name: "Create MariaDB Directories"

file:
path: /data/MariaDB
state: directory
owner: mysql
group: mysql
recurse: yes
with_items:
- db
- log
- name: "Count files in

/data/db" find:
path: /data/db
patterns: '\*'
register: db_files
- name: "Run mysql_install_db only if /data/db is

empty" command: mysql_install_db --datadir=/data/db
when: db_files.matched|int == 0
- name: "Push MariaDB config file to dbserver

master" template:
src: "{{ item }}"
dest: /etc/mysql/mariadb.conf.d/{{ item | basename | regex_replace('\.j2$',
'') }}
with_fileglob:
- files/50-server.cnf.j2
notify: Restart mysql service
when: mysql_server_id==1
- name: "Push MariaDB config file to dbserver

slave" template:
src: "{{ item }}"
dest: /etc/mysql/mariadb.conf.d/{{ item | basename | regex_replace('\.j2$',
'.cnf') }}
with_fileglob:
- files/50-server.j2
notify: Restart mysql service
tags: conf
- name: "Create user 'user1' with password, all database privileges and
'WITH GRANT OPTION' in db1 and db2"
12/23
2022
community.mysql.mysql_user:
login_host: localhost
login_user: root
login_password: "{{ mysql_root_password }}"
state: present
name: glpi
password: password
host: "%"
priv:
'*.*': 'ALL,GRANT'
- hosts: [webservers]
become: true
- vars_files:
- - vars/default.yml
-
- tasks:
- - name: Install prerequisites
- apt: name=aptitude update_cache=yes state=latest force_apt_get=yes
- tags: [ system ]
-
- - name: Install LAMP Packages
- apt: name={{ item }} update_cache=yes state=latest
- loop: [ 'apache2', 'mysql-server', 'python3-pymysql', 'php', 'php-mysql',
'libapache2-mod-php' ]
- tags: [ system ]
-
- - name: Install PHP Extensions
- apt: name={{ item }} update_cache=yes state=latest
- loop: "{{ php_modules }}"
- tags: [ system ]
-
- # Apache Configuration
- - name: Create document root
- file:
- path: "/var/www/{{ item.name }}"
- state: directory
- owner: "www-data"
- group: "www-data"
- mode: '0755'
- with_items: "{{clients}}"
- tags: [ apache ]
-
- - name: Set up Apache VirtualHost
- template:
- src: "files/apache.conf.j2"
- dest: "/etc/apache2/sites-available/{{ item.domain }}"
- notify: Reload Apache
13/23
2022
- tags: [ apache ]
-
- - name: Enable rewrite module
- shell: /usr/sbin/a2enmod rewrite
- tags: [ apache ]
-
- - name: Enable new site
- shell: /usr/sbin/a2ensite {{ item.domain }}
- tags: [ apache ]
-
- - name: Disable default Apache site
- shell: /usr/sbin/a2dissite 000-default.conf
- notify: Restart Apache
- tags: [ apache ]
-
- # MySQL Configuration
- - name: Set the root password
- mysql_user:
- name: root
- password: "{{ mysql_root_password }}"
- login_unix_socket: /var/run/mysqld/mysqld.sock
- tags: [ mysql, mysql-root ]
-
- - name: Remove all anonymous user accounts
- mysql_user:
- name: ''
- host_all: yes
- state: absent
- login_user: root
- login_password: "{{ mysql_root_password }}"
- tags: [ mysql ]
-
- - name: Remove the MySQL test database
- mysql_db:
- name: test
- state: absent
- login_user: root
- tags: [ mysql ]
-
- - name: Creates database for WordPress
- mysql_db:
- name: "{{ mysql_db }}"
- state: present
14/23
2022
- login_user: root
- tags: [ mysql ]
-
- - name: Create MySQL user for WordPress
- mysql_user:
- name: "{{ mysql_user }}"
- password: "{{ mysql_password }}"
- priv: "{{ mysql_db }}.*:ALL"
- state: present
- login_user: root
- tags: [ mysql ]
-
- # UFW Configuration
- - name: "UFW - Allow HTTP on port {{ http_port }}"
- ufw:
- rule: allow
- port: "{{ http_port }}"
- proto: tcp
- tags: [ system ]
-
- # WordPress Configuration
- - name: Download and unpack latest WordPress
- unarchive:
- src: https://wordpress.org/latest.tar.gz
- dest: "/var/www/{{ item.name }}"
- remote_src: yes
- creates: "/var/www/{{ item.name }}/wordpress"
- tags: [ wordpress ]
-
- - name: Set ownership
- file:
- path: "/var/www/{{ item.name }}"
- state: directory
- recurse: yes
- owner: www-data
- group: www-data
-
- - name: Set permissions for directories
- shell: "/usr/bin/find /var/www/{{ item.name }}/wordpress/ -type d -exec chmod
750 {} \\;"
-
15/23
2022
- - name: Set permissions for files
- shell: "/usr/bin/find /var/www/{{ item.name }}/wordpress/ -type f -exec chmod
640 {} \\;"
-
- - name: Set up wp-config
- template:
- src: "files/wp-config.php.j2"
- dest: "/var/www/{{ item.name }}/wordpress/wp-config.php"
-
- handlers:
- - name: Reload Apache
- service:
- name: apache2
- state: reloaded
-
- - name: Restart Apache
- service:
- name: apache2
- state:
restarted
16/23
2022
Installation d’Heartbeat et configuration du cluster Haute

Disponibilité
Ce playbook va installer Heartbeat sur les deux serveurs web et pousser des
fichiers de configuration que nous avons préalablement construits au moyen de templates
Jinga2.
Nous poussons ici des fichiers de configuration Apache2 (notamment pour la configuration
du VHost Apache), et des fichiers de configuration Heartbeat (notamment pour la VIP à
utiliser et tout un ensemble de paramètres à définir), en somme pour la construction du
cluster.
Enfin, ce playbook va activer la configuration de site que nous venons de créer, nommée
‘webapp’ et désactiver celle par défaut, afin de pouvoir joindre en http sur le port 80 notre
serveur web au travers de l’IP du cluster.
$ ansible-playbook playbook_webservers.yml -i hosts.yaml --ask-vault-pass
playbook_webservers.yml
---
- hosts: [webservers]
become: true
tasks:
- name: "Apt-get update"
shell: 'apt-get update'
- name: "Install Heartbeat on webservers"

apt:
name:
- heartbeat
update_cache: yes
state: latest
17/23
2022
- name: "Push Heartbeat config files to

webservers" template:
src: "{{ item }}"
dest: /etc/ha.d/{{ item | basename | regex_replace('\.j2$', '') }}
with_fileglob:
- templates/*.j2
- name: "Change authkeys file rights to 600"

shell: 'chmod 600 /etc/ha.d/authkeys'
- name: "Push Apache2 config file to

webservers" template:
src: "{{ item }}"
dest: /etc/apache2/sites-available/{{ item | basename |
regex_replace('\.j2$', '') }}.conf
with_fileglob:
- files/webapp.j2
- name: "Start Heartbeat service on hosts"

ansible.builtin.service:
name: heartbeat
state: started
- name: "Deactivate the default http conf"

shell: /usr/sbin/a2dissite 000-default.conf
- name: "Activate our http conf"

shell: /usr/sbin/a2ensite webapp.conf
- name: "Reload apache2"

shell: systemctl reload apache2
- name: "Reload Heartbeat"

shell: systemctl restart heartbeat.service
- name: "Check services status"

command: systemctl status "{{ item }}"
with_items:
- heartbeat
- apache2
register: result
ignore_errors: yes
18/23
2022
Mise en place de la réplication des serveurs de base de

données
Ce playbook va tout d’abord créer un utilisateur mysql sur le serveur de base de
données principal. Cet utilisateur sera le seul à avoir les droits de réplications.
Ensuite, il va exécuter la commande SHOW MASTER STATUS; sur le serveur principal afin d’y
récupérer deux valeurs utilisées pour configurer le serveur élève: File: xxxx et Position:
xxxx. Ces informations sont récupérées dynamiquement, stockées dans une variable au
moyen de l’option ‘register:’ d’Ansible, et ré-utilisées dans une seconde tâche.
Ces indicateurs servent au serveur élève pour qu’il se cale sur la position du pointeur de
réplication, savoir s’il est en déphasage ou pas.
$ ansible-playbook playbook_dbservers_replication.yml -i hosts.yaml

--ask-vault-pass
playbook_dbservers_replication.yml
---
become: true
tasks:
- name: "Create replication_user inside of the database"

community.mysql.mysql_query:
login_user: root
query: CREATE USER IF NOT EXISTS 'replication_user'@'%' IDENTIFIED BY '{{
mysql_replication_password }}';
- name: "Grant REPLICATION SLAVE privileges to

replication_user" community.mysql.mysql_query:
login_user: root
query: GRANT REPLICATION SLAVE ON *.* TO 'replication_user'@'%';
- name: "Restart mysql service"

service:
name: mysql
state: restarted
19/23
2022
- block:
- name: "Get master status"

login_user: root
query: SHOW MASTER STATUS;
register: File
- debug:
msg: "{{ item }}"
with_items:
- "{{ File }}"
- name: "Stop slave"

login_user: root
query: STOP SLAVE;
- name: "Change master to"

login_user: root
query: CHANGE MASTER TO MASTER_HOST='dbserver1',
MASTER_USER='replication_user', MASTER_PASSWORD='{{ mysql_replication_password }}',
MASTER_PORT=3306, MASTER_LOG_FILE='{{ item.file }}', MASTER_LOG_POS={{
item.position }}, MASTER_CONNECT_RETRY=10;
with_items:
- file: "{{ hostvars['dbserver1']['File'].query_result[0][0].File}}"
position: "{{
hostvars['dbserver1']['File'].query_result[0][0].Position}}"
- name: "Start slave"

login_user: root
query: START SLAVE;
20/23
2022
Configuration du serveur Syslog et redirection des logs des

serveurs web + des serveurs de base de données
Ce playbook va installer le paquet rsyslog sur l’ensemble des machines clientes. Il
va ensuite modifier le fichier /etc/rsyslog.conf afin d’y ajouter des lignes permettant
d'activer l’écoute TCP sur le port 10514 et l’écoute UDP sur le port 514 sur le serveur de
logs.
Sur les machines clientes, il va modifier ce même fichier pour ajouter le serveur sur lequel
les logs doivent être envoyés, dynamiquement au moyen d’une variable Ansible allant
récupérer l’adresse IP du serveur Syslog dans l’inventaire, le tout en utilisant le port 514.
Enfin, et afin de tester, le playbook va envoyer des logs de tests au moyen de la

commande logger depuis les serveurs web.
$ ansible-playbook playbook_syslog.yml -i hosts.yaml --ask-vault-pass
playbook_syslog.yml
---
- hosts: [syslogservers]
become: true
tasks:
- name: "Install rsyslog on syslogserver(s)"
apt:
name: rsyslog
update_cache: yes
state: present
- name: "UDP Activation"

ansible.builtin.lineinfile:
path: /etc/rsyslog.conf
regexp: '^(.)module(load="imudp")$'
line: 'module(load="imudp")'
- name: "UDP Port 514 Activation"

regexp: '^(.)input(type="imudp" port="514")$'
line: 'input(type="imudp" port="514")'
- name: "TCP Activation"
21/23
2022
regexp: '^(.)module(load="imtcp")$'
line: 'module(load="imtcp")'
- name: "TCP 10514 Activation"

regexp: '^(.)input(type="imtcp" port="514")$'
line: 'input(type="imtcp" port="10514")'
- name: "Syslog service reboot"

service:
name: rsyslog
state: restarted
- hosts: [webservers, dbservers]

become: true
tasks:
- name: "Install rsyslog on client servers"
apt:
name: rsyslog
update_cache: yes
state: present
- name: "Modify rsyslog.conf to add syslogserver "

line: '*.* @{{ hostvars[item].ansible_default_ipv4.address }}:514'
with_items: "{{groups['syslogservers']}}"
- name: "Syslog service reboot"

service:
name: rsyslog
state: restarted
- name: "Logger test"

shell: 'logger -p local0.err "Les logs de "{{ item }}" sont bien redirigés
vers le serveur Syslog."'
with_items:
- "{{groups['webservers']}}"
22/23
2022
Synchronisation du temps avec NTP

Nous avons eu le temps d’avancer sur les User Story du jour 2 et avons par
conséquent pu mettre en place un playbook pour la synchronisation du temps.
Ce playbook va simplement installer le paquet ntp sur l’ensemble des machines clientes,
s’assurer que le service est lancé et lui définir manuellement une zone de temps, CET pour
Central European Time dans notre cas d’utilisation.
$ ansible-playbook playbook_ntp.yml -i hosts.yaml --ask-vault-pass
playbook_ntp.yml
---
- name: "Installing and configuring NTP"
hosts: all
become: true
vars:
timezone: CET #Central European Time
tasks:
- name: "Install NTP"
apt:
name: ntp
- name: "Ensure NTP is started"

service:
name: ntp
state: started
enabled: yes
- name: "Set the timezone registered as a variable"

timezone:
name: "{{ timezone }}"
23/23
2022
Configuration d’une tâche de sauvegarde quotidienne au

moyen d’un script shell exécuté par crontab
Afin de sauvegarder la base de données depuis le serveur élève de réplication,
celui qui, en réalité, a le moins de charge constante et est donc plus disponible, nous avons
mis en place un simple script shell qui va exécuter la commande mysqldump afin d’avoir un
dump de la base en question.
Nous utilisons encore une fois les templates Jinga2 pour pousser ce fichier vers le serveur
en question.
backupsql.sh
#!/bin/sh
mysqldump -u root -p"{{mysql_root_password}}" glpi > /etc/backups/GLPI-$(date "+
%F").sql
Enfin, le playbook va ajouter une tâche cron qui exécutera le fichier .sh poussé tous les
jours à 15h25, et changera les droits sur le script afin qu’il puisse être exécuté.
Comme évoqué lors de la démonstration, nous poussons le script au mauvais endroit

(/etc/backups). Nous aurions dû le pousser dans le répertoire /var/backup, répertoire
beaucoup plus approprié.
playbook_dbservers.yml
---
become: true
tasks:
- name: "Create local backup directory"

file:
path: "/etc/backups/"
state: directory
- name: "Push backup script"

template:
src: "{{ item }}"
24/23
2022
dest: /etc/backups/{{ item | basename | regex_replace('\.j2$', '') }}.sh
with_fileglob:
- files/backupsql.j2
- name: "Creates daily backup cronjob"

cron:
minute: "25"
hour: "15"
weekday: "*"
name: "Backup mysql GLPI DB"
cron_file: "glpidailybackups.daily"
user: "root"
job: '/etc/backups/backupsql.sh'
- name: "Change backup script rights"

shell: 'chmod +x /etc/backups/backupsql.sh'
Conclusion
Au travers des différents cours dispensés et après avoir pratiqué, nous nous
sommes rendus compte qu’Ansible était un outil puissant permettant de manager son ou
ses infrastructures de manière centralisée.
Il est certain que nous ré-utiliserons cet outil à des fins scolaires et professionnelles.
Enfin, nous avons vu qu’Ansible pouvait être couplé à Vagrant, outil permettant de déployer
des VM selon des templates prédéfinies.
25/23

Rapport Admin Linux Avancee Grp1

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Rapport Admin Linux Avancee Grp1

Transféré par

Droits d'auteur :

Formats disponibles

Administration Linux Avancée

Industrialiser Linux à l’aide d’Ansible

Année scolaire 2022 - 2023

L’objectif de ce projet est de déployer une infrastructure redondante et sécurisée de

Dépôt GIT correspondant au projet: https://github.com/NathanLCN/Project-GIT-Groupe-1

Fonctionnement d’Ansible et lexique

Les ﬁchiers utilisés par Ansible sont au format YAML.

Mise en place de l’infrastructure

wsl -l –v permet de verifier la version installé

Génération d’une paire de clé SSH:

Création du répertoire Ansible et liaison au dépôt Git:

$ git config --global user.name "Nathan LE CORRONC"

Conﬁguration des machines virtuelles

Création de l’inventaire Ansible

Déploiement du premier playbook

$ ansible-playbook playbook.yml -i hosts.yaml -K --ask-vault-pass -e

Cette commande va nous permettre de lancer le playbook ‘playbook.yml’ avec comme

- name: "Create admin group"

- name: "Add sudoers users to 'admin' group"

- name: "Create directory"

- name: "Set up authorized keys to be able to SSH through

- name: "Allow 'admin' group to sudo without

- name: "apt-get update"

Déﬁnition du mot de passe SQL ‘root’ et suppression de

$ ansible-playbook playbook_resetting_mariadb_password_dbservers.yml -i hosts.yaml

- name: "Check if root password is unset"

- name: "Check if the specified root password is already

- name: "Check for previously set unix_socket in plugin

- name: "Set MariaDB root password for the first time"

Autorisation des connexions distantes sur les serveurs de

Ensuite, ce playbook téléchargera WordPress et l’installera automatiquement.

$ ansible-playbook playbook_glpi.yml -i hosts.yaml --ask-vault-pass

- name: "Create MariaDB Directories"

- name: "Count files in

- name: "Run mysql_install_db only if /data/db is

- name: "Push MariaDB config file to dbserver

- name: "Push MariaDB config file to dbserver

Installation d’Heartbeat et conﬁguration du cluster Haute

$ ansible-playbook playbook_webservers.yml -i hosts.yaml --ask-vault-pass

- name: "Install Heartbeat on webservers"

- name: "Push Heartbeat config files to

- name: "Change authkeys file rights to 600"

- name: "Push Apache2 config file to

- name: "Start Heartbeat service on hosts"

- name: "Deactivate the default http conf"

- name: "Activate our http conf"

- name: "Reload apache2"

- name: "Reload Heartbeat"

- name: "Check services status"

Mise en place de la réplication des serveurs de base de

$ ansible-playbook playbook_dbservers_replication.yml -i hosts.yaml

- name: "Create replication_user inside of the database"

- name: "Grant REPLICATION SLAVE privileges to

- name: "Restart mysql service"

- name: "Get master status"

- name: "Stop slave"

- name: "Change master to"

- name: "Start slave"

Conﬁguration du serveur Syslog et redirection des logs des

Enﬁn, et aﬁn de tester, le playbook va envoyer des logs de tests au moyen de la

$ ansible-playbook playbook_syslog.yml -i hosts.yaml --ask-vault-pass

- name: "UDP Activation"

- name: "UDP Port 514 Activation"

- name: "TCP Activation"