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/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.
Il est possible d'établir des règles mdev supplémentaires qui exécutent des actions spécifiques pour l'apparition ou la disparition de certains dispositifs dans les paquetages OPT. Par exemple la variable OPT_AUTOMOUNT dans le paquetage hd, utilise une telle règle pour monter automatiquement un nouveau support de stockage émergentes. Si vous souhaitez intégrer une règle mdev supplémentaire, vous pouvez utiliser le script sous la forme :
/etc/mdev.d/mdev<Nummer>.<Name>
Installation du rootFS, le nombre doit être similaire au début et à la fin du script et constitué de trois chiffres, le nom peut être choisi arbitrairement. Dans ce scénario, toutes les sorties sont intégrés dans le fichier standard /etc/mdev.conf. Exemple avec OPT_AUTOMOUNT mentionné ci-dessus :
#!/bin/sh #---------------------------------------------------------------------------- # /etc/mdev.d/mdev500.automount - mdev HD automounting rules __FLI4LVER__ # # # Last Update: $Id: dev_main_boot_dial.tex 52255 2018-03-27 10:04:25Z florian $ #---------------------------------------------------------------------------- cat <<"EOF" # # mdev500.automount # -SUBSYSTEM=block;DEVTYPE=partition;.+ 0:0 660 */lib/mdev/automount EOF
L'en-tête de la syntaxe des règles du fichier /etc/mdev.conf et la documentation mdev, se trouve sur la page Web http://git.busybox.net/busybox/plain/docs/mdev.txt tout y est référencées. Si le script invoque une règle (comme dans l'exemple ci-dessus /lib/mdev/automount), il déclenchera un accès à toutes les variables "événements" du kernel et en particulier :
Exemple de sous-systèmes du Kernel :
Un exemple pour les deux premiers ports série :
mdev[42]: 30.050644 add@/devices/pnp0/00:04/tty/ttyS0 mdev[42]: ACTION=add mdev[42]: DEVPATH=/devices/pnp0/00:04/tty/ttyS0 mdev[42]: SUBSYSTEM=tty mdev[42]: MAJOR=4 mdev[42]: MINOR=64 mdev[42]: DEVNAME=ttyS0 mdev[42]: SEQNUM=613 mdev[42]: 30.051477 add@/devices/platform/serial8250/tty/ttyS1 mdev[42]: ACTION=add mdev[42]: DEVPATH=/devices/platform/serial8250/tty/ttyS1 mdev[42]: SUBSYSTEM=tty mdev[42]: MAJOR=4 mdev[42]: MINOR=65 mdev[42]: DEVNAME=ttyS1 mdev[42]: SEQNUM=614
Un exemple pour connecter un clavier MF II :
mdev[41]: 4.030653 add@/devices/platform/i8042/serio0/input/input0 mdev[41]: ACTION=add mdev[41]: DEVPATH=/devices/platform/i8042/serio0/input/input0 mdev[41]: SUBSYSTEM=input mdev[41]: PRODUCT=11/1/1/ab41 mdev[41]: NAME="AT Translated Set 2 keyboard" mdev[41]: PHYS="isa0060/serio0/input0" mdev[41]: PROP=0 mdev[41]: EV=120013 mdev[41]: KEY=4 2000000 3803078 f800d001 feffffdf ffefffff ffffffff fffffffe mdev[41]: MSC=10 mdev[41]: LED=7 mdev[41]: MODALIAS=input:b0011v0001p0001eAB41-e0,1,4,11,14,k71,72,73,74,75,76,77,79, 7A,7B,7C,7D,7E,7F,80,8C,8E,8F,9B,9C,9D,9E,9F,A3,A4,A5,A6,AC,AD,B7,B8,B9,D9,E2,ram4,l0, 1,2,sfw mdev[41]: SEQNUM=604
Un exemple pour charger un module kernel USB (uhci_hcd) :
mdev[41]: 6.537506 add@/module/uhci_hcd mdev[41]: ACTION=add mdev[41]: DEVPATH=/module/uhci_hcd mdev[41]: SUBSYSTEM=module mdev[41]: SEQNUM=633
Un exemple pour connecter un disque dur :
mdev[41]: 7.267527 add@/devices/pci0000:00/0000:00:07.1/ata1/host0/target0:0:0/0:0:0:0/block/sda mdev[41]: ACTION=add mdev[41]: DEVPATH=/devices/pci0000:00/0000:00:07.1/ata1/host0/target0:0:0/0:0:0:0/block/sda mdev[41]: SUBSYSTEM=block mdev[41]: MAJOR=8 mdev[41]: MINOR=0 mdev[41]: DEVNAME=sda mdev[41]: DEVTYPE=disk mdev[41]: SEQNUM=688
Ci-dessus est un disque dur ATA/IDE (ata1), le nom du périphérique sda sera utilisé pour le traitement.
Un exemple pour un périphérique de blocage à distance (affecte le marquage d'un fichier d'image de VM-fli4l et a été résolu via virsh detach-device) :
mdev[42]: 52.600646 remove@/devices/pci0000:00/0000:00:0a.0/virtio5/block/vdb/vdb1 mdev[42]: ACTION=remove mdev[42]: DEVPATH=/devices/pci0000:00/0000:00:0a.0/virtio5/block/vdb/vdb1 mdev[42]: SUBSYSTEM=block mdev[42]: MAJOR=254 mdev[42]: MINOR=17 mdev[42]: DEVNAME=vdb1 mdev[42]: DEVTYPE=partition mdev[42]: SEQNUM=776 mdev[42]: 52.644642 remove@/devices/virtual/bdi/254:16 mdev[42]: ACTION=remove mdev[42]: DEVPATH=/devices/virtual/bdi/254:16 mdev[42]: SUBSYSTEM=bdi mdev[42]: SEQNUM=777 mdev[42]: 52.644718 remove@/devices/pci0000:00/0000:00:0a.0/virtio5/block/vdb mdev[42]: ACTION=remove mdev[42]: DEVPATH=/devices/pci0000:00/0000:00:0a.0/virtio5/block/vdb mdev[42]: SUBSYSTEM=block mdev[42]: MAJOR=254 mdev[42]: MINOR=16 mdev[42]: DEVNAME=vdb mdev[42]: DEVTYPE=disk mdev[42]: SEQNUM=778 mdev[42]: 52.644777 remove@/devices/pci0000:00/0000:00:0a.0/virtio5 mdev[42]: ACTION=remove mdev[42]: DEVPATH=/devices/pci0000:00/0000:00:0a.0/virtio5 mdev[42]: SUBSYSTEM=virtio mdev[42]: MODALIAS=virtio:d00000002v00001AF4 mdev[42]: SEQNUM=779 mdev[42]: 52.644973 remove@/devices/pci0000:00/0000:00:0a.0 mdev[42]: ACTION=remove mdev[42]: DEVPATH=/devices/pci0000:00/0000:00:0a.0 mdev[42]: SUBSYSTEM=pci mdev[42]: PCI_CLASS=10000 mdev[42]: PCI_ID=1AF4:1001 mdev[42]: PCI_SUBSYS_ID=1AF4:0002 mdev[42]: PCI_SLOT_NAME=0000:00:0a.0 mdev[42]: MODALIAS=pci:v00001AF4d00001001sv00001AF4sd00000002bc01sc00i00 mdev[42]: SEQNUM=780
Comme vous pouvez le voir, plusiers extration du sous-système du kernel ont été impliquès (avec block, bdi, virtio et pci).
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.