Plus : 8.8 Paquetage Template En haute : 8. Documentation pour développeur Retour : 8.6 Création d'un CGI
fli4l 2.0 peut être installé sur différent média, disque-dur ou carte-Compact-Flash(TM), il est aussi possible de l’installer sur un support Zip ou sur un CD-ROM amorçable. En outre, l’installation d’une version sur un disque-dur n'est pas fondamentalement différente que sur une disquette. 8.10
Ces exigences ont été réalisé grâce à l’archive opt.img, jusqu'ici il était installé sur un disque-RAM maintenant il peut être placé sur d’autre média. Il peut s'agir d'une partition sur un disque dur ou une carte-CF. Pour ce second volume, le répertoire /opt sera monté et les programmes auront des liens symboliques et seront intégrés dans le rootfs. La structure apparaissant dans le système de fichier RootFS correspond au répertoire opt de la distribution fli4l à une exception prète - le préfixe des fichiers seront omis. Le fichier opt/etc/rc se trouve directement dans /etc/rc et pour le fichier opt/files/bin/busybox il est dans /bin/busybox. Ces fichiers sont seulement des liens dans le média monté en lecture seule, on peut les ignorer, tant que les fichiers ne sont pas modifiés. Si vous voulez les modifier, il faut d'abord rendre ces fichiers accessibles en écriture avec la commande mk_writable (voir ci-dessous).
Les Scripts qui sont exécutés lors du boot système, sont dans les répertoires opt/etc/boot.d et opt/etc/rc.d ils sont également exécutés dans l'ordre.
Important: Quand ces scripts sont exécutés aucun processus particulier
n'est produit, ils ne peuvent pas être arrêtés avec la commande «exit».
Cette commande conduirait à une rupture du processus de Boot !
Les scripts de ce répertoire sont exécutés les premiers. Ils ont pour mission, de monter le périphérique de boot, le fichier de configuration rc.cfg se trouve sur le support de boot et décompresse l'archive opt.img. Selon le type de Boot il est plus ou moins complexe et font les choses suivantes :
Lors de la construction des scripts, vous avez la chance d'en apprendre davantage sur la configuration de fli4l, le fichier de configuration est également intégré dans l'archive rootfs, dans ce fichier /etc/rc.cfg vous trouverez les variables de configuration qui seront analysées puis les scripts de démarrage seront exécutés depuis le répertoire opt/etc/boot.d/. Après le montage du volume de boot, le fichier /etc/rc.cfg est remplacé par le fichier de configuration dans le volume de boot, de sorte que les scripts de démarrage dans opt/etc/rc.d/ soit disponible pour l'actuel configutation du volume de boot (voir ci-dessous). 8.11
C'est les commandes qui sont exécutées à chaque démarrage du routeur, elles peuvent être stockés dans le répertoire opt/etc/rc.d/. Les conventions suivantes s'appliquent :
rc<nombre à trois chiffres>.<nom de l'OPT>
Les scripts sont démarrés dans l'ordre croissant des numéros. Si plusieurs scripts ont le même numéro attribué, c’est le caractère alphabétique après le point qui détermine l'ordre. L’installation des paquetages s’effectue les uns après les autres, ils sont définis par un numéro.
Voici une estimation approximative, des numéros pouvant être utilisé pour une installation :
| Numéro | Fonction |
| 000-099 | Système de base (hardware, fuseau horaire, système de fichiers) |
| 100-199 | Module Kernel (drivers) |
| 200-299 | Connexions externe (PPPoE, ISDN4Linux, PPtP) |
| 300-399 | Réseau (routage, interface, filtrage de paquet) |
| 400-499 | Serveur (DHCP, HTTPD, Proxy, etc.) |
| 500-900 | Tout le reste |
| 900-997 | Tout ce qui peut générer un dial-up |
| 998-999 | Réservé (ne pas utiliser!) |
Important: mk_writable doit être utilisé sur les fichiers qui sont dans le
rootfs et non pas par le biais du dossier /opt. Si vous voulez modifier
/usr/local/bin/foo vous exécutez mk_writable /usr/local/bin/foo.
if [ "$OPT_<OPT-Name>" = "yes" ]
then
...
# ici OPT start!
...
fi
if [ "$OPT_<OPT-Name>" = "yes" ]
then
begin_script FOO "configuring foo ..."
...
end_script
fi
Pour juste déboguer de script au démarrage, vous devez simplement activer
la variable FOO_DO_DEBUG='yes'.
Chaque ordinateur a besoin d’un temps pour s’arrêter ou redémarrer. Il se pourrait bien que vous pouvez avoir à effectuer des opérations avant que l'ordinateur s'éteigne ou redémarre. Les commandes officielles sont «halt» et «reboot». Ces commandes sont également placées dans IMONC ou dans le Web-GUI si vous l’avez installé, un clique sur le bouton suffira pour arrêter ou redémarrer le routeur.
Tous les scripts d'arrêt se trouvent dans le répertoire opt/etc/rc0.d/. Le nom du fichier est analogue à celui du script de démarrage. Ils sont également exécutées dans ordre croissant des numéros.
Dans /etc/boot.d/base-helper différentes fonctions sont mises à disposition, elles peuvent être utilisées pour les scripts de démarrage. Cela se applique pour certaines choses comme pour un support de débogage, pour le chargement des modules du Kernel ou pour la sortie des messages.
Les différentes fonctions sont les suivantes et brièvement décrites.
if do_modprobe -q acpi-cpufreq
then
# pas de contrôle de fréquence du CPU via ACPI
log_error "le contrôle de fréquence du CPU via ACPI n'est pas disponible."
# [...]
else
log_info "le contrôle de fréquence du CPU via ACPI est activé."
# [...]
fi
Important: Le module doit exister précisément par ce nom, aucun alias ne peuvent être utilisé.
Lorsque vous utilisez un alias do_modprobe sera exécuté immédiatement.
Le résultat de la traduction est mémorisée dans la variable dont le nom est transmis dans le troisième paramètre, si ce paramètre est manquant, le résultat sera stocké dans la variable res. Le nom de la variable qui est transmis dans le second paramètre est utilisé uniquement pour les messages d'erreur si la traduction échoue, cela permet d'appeler la source de la valeur à traduire. Si une erreur se produit, un message est alors exécuté.
Unable to translate value '<Valeur>' contained in <Nom de Variable>.
La valeur nulle est retourée si la traduction a réussie et une valeur non nulle sera retounée si une erreur s'est produite.
Au sujet les périphériques ttyI, vous pouvez utiliser (/dev/ttyI0 .../dev/ttyI15), pour la création d’un «émulateur de modem» avec plusieurs cartes ISDN (ou RNIS), il existe un compteur pour les conflits entre les différents OPTs et les utilisations de ces périphériques, c'est un dispositif à éviter. Ces émulateur seront créés lors du démarrage du routeur, dans le fichier /var/run/next_ttyI, avec l'utilisation un compteur. Dans l'exemple de script suivant, la valeur est interrogé et peut être augmentée de un, il sera exporté de nouveau dans le prochain OPT.
ttydev_error=
ttydev=$(cat /var/run/next_ttyI)
if [ $ttydev -le 16 ]
then # ttyI device available? yes
ttydev=$((ttydev + 1)) # ttyI device + 1
echo $ttydev >/var/run/next_ttyI # save it
else # ttyI device available? no
log_error "No ttyI device for <Nom de votre OPT> available!"
ttydev_error=true # set error for later use
fi
if [ -z "$ttydev_error" ] # start OPT only if next tty device
then # was available to minimize error
... # messages and minimize the
# risk of uncomplete boot
fi
Après avoir établi ou coupé une connexion par modem, les scripts /etc/ppp/ sont traitées. Voici les actions qui sont nécessaires pour activer ou déactiver une connexion, qui seront stocker dans l'OPT. Le schéma des noms de fichier est le suivant :
| ip-up<numéro à trois chiffres>.<nom d'OPT> |
| ip-down<numéro à trois chiffres>.<nom d'OPT> |
Le script ip-up est exécuté après la connexion et le script ip-down est exécuté après la déconnexion
Important: Dans le script ip-down aucune intervention ne doit être réalisé,
autrement cela conduirait à une nouvelle connexion Internet, avec uniquement un accès
à l’état online permanent, pour les utilisateurs qui non pas de forfait illimité,
cela peut couter très cher.
Important: Car pour ce script, il n’y a aucun processus qui est généré, en plus, ce
script ne peut pas être arrêté avec la commande «exit»!
Remarque : le scripts ip-up peut être examiné lors qu'il est exécuté, pour cela le fichier rc400 sera vérifier avec la variable ip_up_events. Si c'est réglé sur "yes", une connexion par modem existe et le script ip-up sera exécuté. Si c'est réglé sur "no", une connexion par modem n'existe pas et le script ip-up ne sera pas exécuté. Il y a une exception pour cette règle : Si un routeur Ethernet pur n'est pas configuré pour des connexions commutées, mais configuré pour une route par défaut (0.0.0.0/0), le script ip-up sera exécuté qu'une fois, exactement à la fin du processus de boot. (De même le script ip-down sera exécuté qu'une fois avant l'arrêt du routeur).
Grâce au concept d'appel spécial les scripts ip-up et ip-down sont exécutés et les variables suivantes sont utilisées :
| real_interface | L'interface actuelle, par ex. ppp0, ippp0, ... |
| interface | Interface-IMOND, avec pppoe, ippp0, ... |
| tty | Terminal de connexion, peut-être vide ! |
| speed | Vitesse de connexion, par ex. avec ISDN 64000 |
| local | Adresse-IP spécifique |
| remote | Adresse-IP d'ordinatuer auquel vous êtes connecté |
| is_default_route | Indique si l'actuel ip-up/ip-down est utilisé pour l'interface de la route par défaut peut-être «yes» ou «no») |
Depuis la version 2.1.0, les scripts ip-up et ip-down sont exécutés non seulement pour l'interface sur laquelle la route par défaut est configurée, mais aussi pour toutes les connexions qui ont besoin les scripts ip-up et ip-down. Pour émuler des comportements anciens, vous devez inclure les éléments à déclencher dans les scripts ip-up et ip-down la requête suivante doit être insérée :
# is a default-route-interface going up?
if [ "$is_default_route" = "yes" ]
then
# Les actions à déclencher
fi
Naturellement, les nouveaux comportements doivent être utilisés, pour des actions spécifiques.