Comment utiliser un fichier de configuration pour vos scripts Bash ?

I. Présentation

Dans ce tutoriel, nous allons apprendre à utiliser un fichier de configuration pour les scripts bash (langage de script Linux). L’utilisation d’un fichier de configuration signifie qu’un fichier, extérieur au script, contiendra les variables qui seront utilisées dans le script.

Dans un tel contexte, les scripts Bash seront dépourvus de la déclaration des variables principales et utiliseront un fichier de configuration pour récupérer le contenu de ces variables. Les intérêts y sont multiples :

• Une clarification de la construction et de l’utilisation des scripts : nous aurons d’un côté le script, de l’autre les variables. Si notre script est volumineux, nous n’aurons pas à fouiller parmi les nombreuses lignes et fonctions l’endroit où se trouve une variable pour la modifier.
• La possibilité d’utiliser plusieurs configurations différentes sans phase de modification. En effet, il sera facilement possible, dans des environnements différents (production, pré-production, développement) d’utiliser un même script sans avoir à modifier son contenu. Il nous suffira de pointer vers le bon fichier de configuration pour changer les variables utilisées par le script
• Une épuration du script pour une meilleure sécurité. Dans une telle configuration, il devient réaliste d’effectuer une vérification d’intégrité (via l’empreinte) d’un script avant exécution par exemple, car quel que soit l’environnement d’exécution du script, son contenu n’aura pas changé. Cela nous permettra aussi de modifier les permissions du script pour le rendre non modifiable.
• Une réduction du risque d’erreurs manuelles lors de la mise à jour des paramètres. Cela contribue à maintenir la cohérence et l’intégrité des scripts, évitant les problèmes de sécurité liés à des configurations ou modifications incorrectes.

Bref, les apports d’un tel modèle sont multiples, tant en termes d’usage que de sécurité. Passons à l’action !

Si vous n’êtes pas encore à l’aise avec le bash, je vous recommande notre article à ce sujet :

Version originale de l’article : 16 juillet 2016.

II. Fonctionnement global

Dans les faits, l’utilisation d’un fichier de configuration nécessite d’avoir deux fichiers au lieu d’un : un script bash et un fichier de configuration (qui contiendra nos variables). Étant sous Linux, la nomenclature du fichier de configuration importe peu. Cependant, il peut être intéressant de la normaliser pour une meilleure clarté. Cela en utilisant des noms tels que « config.txt« , « config.ini » ou encore « SETTINGS.txt« .

Par ailleurs, l’intérêt est aussi de disposer de plusieurs fichiers de configuration pour un même script, mais contenant des valeurs différentes qui sont propres à chaque environnement ou serveur. Ainsi, la nomenclature peut être adaptée :

• « config-dev.txt » et « config-prod.txt » ;
• « dev.config » et « prod.config » ;
• « serv1-settings.config » et « serv2-settings.config » ;
• Et ainsi de suite !

Imaginons à présent un scénario pour contextualiser une telle utilisation d’un fichier de configuration. Nous souhaitons créer un script qui fait une sauvegarde d’un répertoire dans une archive et change le propriétaire de cette archive. Nous disposons de deux environnements :

• Développement (dev) : sauvegarde de « /opt/tomcat » vers « /home/john/tomcat.zip » et assigner « john » en propriétaire de cette archive ;
• Production (prod) : sauvegarde de « /srv/tomcat » vers « /home/emile/tomcat.zip » et assigner « emile » en propriétaire de cette archive.

Dans tous les cas, j’aurai donc 3 informations :

• Chemin/répertoire source de l’archive : « $aSauvegarder« 
• La destination de la création de l’archive : « $dest« 
• Le nom du nouveau propriétaire : « $owner« 

Pour rappel, le but d’utiliser un fichier de configuration est qu’une fois mon script sera conçu, son contenu ne changera pas, peu importe l’environnement dans lequel il est utilisé. Par contre, lorsque nous lancerons notre script, nous lui indiquerons un fichier de configuration à utiliser et en fonction, il effectuera les actions relatives à l’environnement de production ou de développement.

J’espère que ce contexte est clair, nous allons maintenant voir comment techniquement effectuer cela.

III. Construire son fichier de configuration

Le fichier de configuration n’est rien d’autre qu’un script bash qui déclare des variables, voici un exemple de fichier de configuration :

# Contenu d'un fichier de configuration type
aSauvegarder="Chemin du répertoire à sauvegarder"
dest="Chemin vers la destination"
owner="utilisateur"

Dans notre contexte, j’aurai donc deux fichiers de configuration. Le premier nommé « prod.conf« :

# Fichier de configuration de l'environnement de production
aSauvegarder="/srv/tomcat"
dest="/home/emile/tomcat.zip"*
newOwner="emile"

Le second « dev.conf » :

# Fichier de configuration de l'environnement de developpement
aSauvegarder="/opt/tomcat"
dest="/home/john/tomcat.zip"
newOwner="john"

Voilà, à présent que nos différents fichiers de configuration sont prêts, nous pouvons les utiliser !

IV. Import dans le script bash et utilisation

Très simplement, voici le script bash utilisé pour mon opération. Pour importer un fichier de configuration, nous utiliserons la commande « source » dans mon script :

# Script bash utilisant un fichier de configuration

#!/bin/bash
source config-prod.txt

# Archivage du répertoire
zip -r $dest $aBackuper

# Changement du propriétaire
chown $newOwner:$newOwner $dest

Selon l’utilisation, ce fichier peut être écrit en dur, comme ci-dessus, ou mis dans un paramètre, ce qui nous évitera d’avoir à modifier le script. La seule variable à passer à notre script sera donc le nom du fichier de configuration à utiliser :

# Script bash utilisant un fichier de configuration via une option

#!/bin/bash
source $1

# Archivage du répertoire
zip -r $dest $source

# Changement du propriétaire
chown $newOwner:$newOwner $dest

Ici « $1 » sera remplacé par le premier paramètre que nous passerons à notre script. Pour utiliser notre fichier de configuration de manière dynamique, nous utiliserons la commande suivante :

# Utilisation du script avec la configuration de production
./script.sh prod.config

Ainsi, si nous spécifions le fichier « prod.config« , c’est le répertoire « /srv/tomcat » qui sera sauvegardé dans « /home/emile/tomcat.zip« . Et si nous spécifions, le fichier « dev.config« , c’est le répertoire « /opt/tomcat » qui sera sauvegardé dans « /home/john/tomcat.zip« . Tout cela, sans changer le contenu de notre script !

Également, il est possible de faire en sorte que si aucun fichier de configuration n’est précisé en paramètre, un fichier de configuration « par défaut » sera chargé. Ce qui permet une utilisation rapide :

# Utilisation du script une configuration par défaut

#!/bin/bash

if ( -z "$1" )
then
    source prod.config
else
    source $1

# Archivage du répertoire
zip -r $dest $source

# Changement du propriétaire
chown $newOwner:$newOwner $dest

Ici, si aucun fichier de configuration n’est passé en paramètre, alors par défaut, le fichier « prod.config » sera utilisé. Si un fichier de configuration est passé en paramètre (« $1« ), alors il sera utilisé !

Voici à présent une précision concernant la commande « source » utilisée ici, qui est native sous Linux.

La commande source permet de charger un fichier bash dans le shell actuel. Les opérations, et notamment nos fameux fichiers de configuration, qui ne sont rien d’autres que des fichiers bash définissant des variables. La commande source est souvent mise en comparaison avec le « . » utilisé pour lancer un script habituellement, exemple :

# Exécution d'un script avec le "."
. monscript.sh

La différence majeure entre « . » et « source » est donc que « . » fait naître un nouveau shell (processus enfant) alors que « source » exécute le bash dans le shell actuel. Nous pouvons donc nous en servir dans un script pour importer des variables ou des fonctions ! 🙂

V. Conclusion

Dans ce tutoriel, nous avons vu comment utiliser des fichiers de configuration afin de rendre plus facile l’utilisation des scripts dans différents contextes. Nous sommes maintenant en mesure d’utiliser un même script avec des variables différentes, sans modification du code ou la transmission d’un grand nombre de paramètres dans la ligne de commande.

L’exemple ici présenté ne contient que quelques variables et lignes. Pour des scripts plus complexes dans lesquels les variables sont déclarées un peu partout, un tel fichier de configuration sera d’une grande aide.