Plus : 8.5 Utiliser le filtrage En haute : 8. Documentation pour développeur Retour : 8.3 Concept modulaire
Nous n'avons pas écrit d'introduction générale pour le Scripts-Shell, mais vous pouvez lire cette introduction sur Internet, ici nous traitons que des situations particulières pour fli4l. Des informations complémentaires sont disponibles dans les différentes pages du manuel Unix-/Linux-. Les liens suivants peuvent servir de point de dépard pour ce sujet :
Dans le monde Unix, il est essentiel de démarrer le script avec le nom de l'interpréteur de commande, à la première ligne vous devez indiquer :
#!/bin/sh
Pour que l'on puisse identifier plus facilement le script, à savoir, à quoi il sert, qui l'a écrit, il faut maintenant que celui-ci soit suivi d'une en-tête à peu près comme ceci :
#--------------------------------------------------------------------
# /etc/rc.d/rc500.dummy - start my cool dummy server
#
# Creation: 19.07.2001 Toller Hecht <toller-hecht@example.net>
# Last Update: 11.11.2001 Süße Maus <suesse-maus@example.net>
#--------------------------------------------------------------------
Vous pouvez maintenant poursuivre le script ...
La composition de la configuration de fli4l est dans le fichier config/<PAQUETAGE>.txt. Cette documentation contient les Variables actives et la création du support de boot avec le fichier rc.cfg. Lors du boot du routeur, ce fichier est lu avant tous les scripts-rc (les scripts sont dans /etc/rc.d/). Ce script peut accéder avec le $<nom de variable> à toutes les variables de configuration du routeur.
Avez-vous besoin des valeurs des variables de configuration, même après le boot ? Vous pouvez à partir du fichier /etc/rc.cfg, avec lequel vous avez écrit la configuration pour le support de boot. Par exemple, vous pouvez lire la valeur de la variable OPT_DNS, avec un script, vous devez le faire de la manière suivante :
eval $(grep "^OPT_DNS=" /etc/rc.cfg)
Cela fonctionne également avec plusieurs variables (c'est-à-dire en utilisant une seul fois le programme grep) :
eval $(grep "^\(HOSTNAME\|DOMAIN_NAME\|OPT_DNS\|DNS_LISTEN_N\)=" /etc/rc.cfg)
Les paquetages on parfois besoins de stocker des données sur un support persistant, ils pourront survivre au redémarrage du routeur. Il existe une fonction map2persistent, elle peut être utilisée depuis un script qui sera enregistré dans /etc/rc.d/. Ce script doit contenir la variable avec le chemin et le sous-répertoire. L'idée est que la variable est configurée avec un chemin réel - Alors, ce chemin sera utilisé, car l'utilisateur l'a souhaité ou la variable sera configurée sur «auto» - Alors, un sous-répertoire correspondant sera créé en-dessous du répertoire sur un support persistant selon le deuxième paramètre. La fonction retourne le résultat de la variable, avec le nom qui à été indiqué dans le premier paramètre.
Un exemple permettra de clarifier cela. Soit la variable VBOX_SPOOLPATH, qui est paramétrée avec un chemin ou avec la valeur «auto». Pour l'activation
begin_script VBOX "Configuring vbox ..."
[...]
map2persistent VBOX_SPOOLPATH /spool
[...]
end_script
Cela signifie que la variable VBOX_SPOOLPATH, ne sera pas modifié (si elle contient un chemin) ou le chemin sera remplacé par /var/lib/persistent/vbox/spool (Si elle contient la valeur «auto»). La valeur se réfère 8.6/var/lib/persistent est le répertoire pour enregistrer les données sur un support de stockage non volatile, <SCRIPT> représente un minuscule script d'exécution (ce nom est dérivé du premier argument exécute begin_script). Si aucun support convenable n'existe (cela peut être possible), le répertoire /var/lib/persistent sera enregistré dans le disque RAM.
Il convient de noter, que le chemin utilisé par map2persistent n'est pas généré automatiquement - Cela doit être fait soi-même (peut-être avec la commande mkdir -p <chemin>).
Dans le fichier /var/run/persistent.conf vous pouvez vérifier si le support de stockage persistant pour les données est possible. Exemple :
. /var/run/persistent.conf
case $SAVETYPE in
persistent)
echo "Stockage persistant possible!"
;;
transient)
echo "Stockage persistant PAS possible!"
;;
esac
Au démarrage d'un script, il est souvent utile d’activer le mode débogage, pour déterminer si «un ver est dans le script» et pour savoir s'il est inséré au début ou à la fin du texte :
begin_script <OPT-Name> "start message"
<script code>
end_script
En fonctionnement normal, un texte apparait au démarrage du script et à la fin de se même texte le préfixe «finished» sera spécifié.
Si vous voulez déboguer un script, vous devez faire deux choses :
<OPT-Name>_DO_DEBUG='yes'
Maintenant vous pourrez voir sur la console, la représentation exact de l'exécution du programme.
Si cette variable est placée sur «yes», elle permet de créer un core-Dumps (ou image mémoire). Si un programme se bloque en raison d'une erreur, un fichier image enregistre l'état actuel du système, il pourra ensuite être utilisée pour une analyser du problème. L'image core-Dumps sera enregistrée dans le dossier /var/log/dumps.
Si cette variable est placée sur «yes», tous les appels du programme par le protocol ip seront enregistrés.
Si cette variable est placée sur «yes», lors de l'exécution des scripts ip-up/ip-down les instructions exécutées seront stockées dans le système de journalisation.
Si cette variable est placée sur «yes», elle enregistre dans bootlogd tous le processus de Boot visible sur la console. Cette variable est placée par défaut sur «yes».
Normalement bootlogd se termine à la fin du processus de boot. Si on active cette variable, cela permet l'enregistrement au-delà de l'arrêt du processus de boot visible sur la console.
Si on active cette variable cela génère le protocole Démons-mdev et produit un fichier sur tous les périphériques dans le dossier /dev
{ echo "cpu"; echo "quit"; } | ...
Équivaut à :
{
echo "cpu"
echo "quit"
} | ...