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
- La possibilité d’utiliser plusieurs configurations différents sans phase de modification. En effet, il sera facilement possible, dans le cadre d’environnements multiples (production, pré-production, développement) d’utiliser un même script sans avoir à modifier son contenu. Il suffira simplement 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’emprunte) d’un script avant exécution par exemple car quelque soit l’environnement d’exécution du script, son contenu n’aura pas changé (encore une fois, seul le contenu du fichier de configuration change
). Également, les droits assignés aux scripts pourront être modifiés afin d’interdire toute modification (et n’autoriser les modifications qu’au niveau du fichier de configuration).
Bref, les apports d’un tel modèle sont multiples, tant en terme d’usage que de sécurité. Passons maintenant à l’action ! 
II. Fonctionnement global
Techniquement, ce n’est pas très compliqué. Il nous faut deux fichiers :
- notre script bash (*.sh)
- un fichier texte standard qui contiendra nos variables
Étant sous Linux, la nomenclature du fichier de configuration import peu. Cependant, il peut être intéressant de la normaliser au sein de votre SI pour une meilleure clarté. Par exemple :
- config.txt
- config.ini
- SETTINGS.txt
Également, l’intérêt de disposer de plusieurs fichiers de configuration pour un même script, mais contenant des valeurs différentes, propres à chaque environnement ou serveur, comme expliqué précédemment. Ainsi, la nomenclature peut être adaptée :
- config-dev.txt
- prod.config
- serv2-settings.config
- Et ainsi de suite !
Imaginons maintenant un scénario pour contextualiser une telle utilisation d’un fichier de configuration. Je souhaite écrire un script qui va faire un backup d’un répertoire, vers un autre répertoire, et qui va ensuite changer les droits de l’archive crée pour rendre cette archive disponible à un autre utilisateur. Je dispose de deux environnements :
- Développement : dev – je souhaite backuper /opt/tomcat vers /home/john/tomcat.zip et assigner john en propriétaire de cette archive
- Production : prod – je souhaite backuper /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 : $aBackuper
- La destination de la création de l’archive : $dest
- Le nom du nouveau propriétaire : $owner
Le fonctionnement global va donc être le suivant :
Une fois mon script bien conçu, son contenu ne changera pas peut importe l’environnement dans lequel je l’utilise.
Par contre, lorsque je lancerai mon script, je lui indiquerai 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 :
# fichier de configuration : script.sh
aBackuper="Chemin du répertoire à sauvegarder"
dest="Chemin vers la destination"
owner="utilisateur"
Dans notre contexte, j’aurai donc deux fichiers de configuration (ou plus si nécessaire :). Le premier nommé « config-prod.txt« :
# fichier de configuration : script.sh
aBackuper="/srv/tomcat"
dest="/home/emile/tomcat.zip"*
newOwner="emile"
Le second « config-dev.txt » :
# fichier de configuration : script.sh
aBackuper="/opt/tomcat"
dest="/home/john/tomcat.zip"
newOwner="john"
Voila, maintenant 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 :
#!/bin/bash
# Archivage du répertoire
zip -r $dest $source
# Changement du propriétaire
chown $newOwner:$newOwner $dest
Pour importer un fichier de configuration, j’utiliserais la commande « source » dans mon script :
#!/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 hardcodé (écrit en dur, comme ci-dessus) ou variabilisé. La seule variable à passer à notre script sera donc le nom du fichier de configuration à utiliser :
#!/bin/bash
source $1
# Archivage du répertoire
zip -r $dest $source
# Changement du propriétaire
chown $newOwner:$newOwner $dest
Pour utiliser mon fichier de configuration, j’utiliserais la commande suivante, par exemple pour l’environnement de production
./script.sh config-prod.txt
Ainsi, si je pointe vers config-prod.txt, c’est le répertoire /srv/tomcat qui sera sauvegardé dans /home/emile/tomcat.zip. Si je pointe vers le fichier config-dev.txt, 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 aucune 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 :
#!/bin/bash
if [ -z "$1" ]
then
source config-prod.txt
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 le fichier « par défaut » config-prod.txt est utilisé. Si un fichier de configuration est passé en paramètre (« $1« ), alors il sera utilisé !
Je vous dois un petit mot sur la commande « source« , native sous Linux, qui nous permet d’effectuer tout cela.
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 lancé un script habituellement, exemple :
. monscript.sh
La différence majeur 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 !
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 peut être d’une grande aide.
