Plus : 8.4 Conditions générales de En haute : 8. Documentation pour développeur Retour : 8.2 Compiler les programmes
Depuis la version 2.0, fli4l est réparti en modules (ou paquetages), par exemple
Avec le paquetage base, fli4l est un simple routeur Ethernet. Pour ISDN et/ou DSL, vous devez décompacter le paquetage ISDN et/ou DSL dans le répertoire fli4l. Il en va de même pour les autres paquetages.
À partir des paquetages et en fonction des paramètres spécifiques des fichiers de configurations, les fichiers suivants seront créés, le fichier avec les configurations, rc.cfg et deux archives rootfs.img et opt.img, ces fichiers sont produits à l'aide du programme mkfli4l, celui-ci lie les différents paquetages et contrôle les fichiers de configurations pour repérer d'éventuelles erreurs.
mkfli4l accepte les options indiqués dans le tableau 8.1. Si aucune valeur n'est indiquée, les valeurs par défaut entre les parenthèses seront prises en compte. Vous pouvez voir la liste complète des options dans (le tableau 8.1) avec la commande :
mkfli4l -h
| Option | Signification | |
| -c, - -config | Avec cette option, on défini le répertoire dans lequel mkfli4l recherche les fichiers de config des paquetages; (par défaut: config) | |
| -x, - -check | On place ici la liste des fichiers des paquets, dans le quel mkfli4l doit contrôler et rechercher les erreurs (<PAQUETAGE>.txt, <PAQUETAGE>.exp et <PAQUETAGE>.ext; (par défaut: check) | |
| -l, - -log | On place ici le fichier jounal, dans le quel mkfli4l enregistre les messages d'erreurs et les avertissements; (par défaut: img/mkfli4l.log) | |
| -p, - -package | On place ici le paquetage qui doit être examiné, on peut indiquer dans cette option plusieurs paquetages à la fois pour qu'ils soient examinés. Cependant si vous utilisez l'option -p, l'option <check_dir>/base.exp est en principe d'abord vérifier, afin de gérer les paramètres général du paquetage de base. | |
| -i, - -info | Avec cette option, on affiche des informations sur le déroulement de la construction (lecture des fichiers, vérification des fichiers, les problèmes rencontrés seront affichés lors du processus de contrôle). | |
| -v, - -verbose | Même signification que la variante -i | |
| -h, - -help | Avec cette option, on affiche l'aide | |
| -d, - -debug | Avec cette option, vous pouvez déboguer le processus de construction. Cette option sert surtout pour les développeurs de paquetage, qui souhaitent en savoir un peu plus, sur le déroulement du contrôle des paquetages. | |
| Debugoption | Signification | |
| check | show check process | |
| zip-list | show generation of zip list | |
| zip-list-skipped | show skipped files | |
| zip-list-regexp | show regular expressions for ziplist | |
| opt-files | check all files in opt/<PAQUETAGE>.txt | |
| ext-trace | show trace of extended checks | |
Un paquetage peut contenir plusieurs opts, mais si en général le paquetage contient seulement un opt, il est opportun de nommer le paquetage du même nom que l'OPT. Vous pourrez ensuite remplacer <PAQUETAGE> par le nom des paquetages respectif. Un paquetage comprend les éléments suivants :
Les différentes parties sont détaillées ci-dessous.
Dans le fichier config/<PAQUETAGE>.txt, les modifications de la configuration du paquetage sont réalisées par l'utilisateur. Toutes les variables du fichier de configuration doivent commencer uniformèment par le nom de ou des OPTs, par exemple :
#-------------------------------------------------------------------
# Optional package: TELNETD
#-------------------------------------------------------------------
OPT_TELNETD='no' # install telnetd: yes or no
TELNETD_PORT='23' # telnet port, see also FIREWALL_DENY_PORT_x
Le fichier de configuration de l'OPT doit être configuré en conséquence avec une en-tête (voir ci-dessus). Cela augmente la clarté, en particulier si le paquetage contient plusieurs OPTs. Les variables associées à l'OPT - ne doivent pas être écrites en retrait - également pour plus de clarté. Les commentaires et lignes vides sont autorisés, les commentaires doivent commencer de manière uniforme jusqu'à la 33ème colonne. Si une variable ou un commentaire occupe plus de 32 caractères, la ligne sera décalés à la 33ème colonne. Les commentaires plus longs doivent être séparés dès la 33ème colonne pour commençer une nouvelle ligne. Cette mesure vise à améliorer la lisibilité du fichier de configuration.
Toutes les valeurs derrière le signe égale doivent être écrite entre des guillemets 8.1, autrement, lors du boot vous pouvez avoir des problèmes.
Les variables incluses (voir plus bas) dans le fichier rc.cfg sont activées, toutes les autres sont ignorées. La seule exception est la variable qui porte le nom <PAQUETAGE>_DO_DEBUG. Celle-ci sert pour déboguer des paquetages et est enregistrée en globalitée.
Le fichier opt/<PAQUETAGE>.txt doit contenir les instructions suivantes.
Quand mkfli4l est exécuté il se base sur les archives nécessaires à l'installation.
Les lignes vides et commençant par «#» sont ignorées. Dans l'une des deux premières lignes, vous devez indiquer la version du format du paquetage, qui doit être :
<première colonne> <deuxième colonne> <troisième colonne>
opt_format_version 1 -
Les autres lignes ont la syntaxe suivante :
<première colonne> <deuxième colonne> <troisième colonne> <colonne suivante>
Variable valeur Fichier Option
Si plusieurs variables doivent être testés avec la même valeur, une liste de variables peut être utilisée (elles seront séparés par une virgule). Dans ce cas, il sera suffisant d'enregistrer au moins une valeur requise dans la deuxième colonne pour toutes les variables. Il est important de ne pas mettre d'espace entre les variables !
Pour les variables OPT (se sont les variables qui commence par OPT_ et qui accepte les valeurs YESNO) le préfixe ogOPT_fg peut être omis. En outre, il n'y a pas d'importance si les variables sont indiquées en majuscule, en minuscule (ou mixte).
Il est possible d'indiquer le caractère og!fg devant la valeur. Dans ce cas, le test est annulé, ce qui signifie que le fichier sera copié seulement si la variable ne contient pas de valeur.
Si le nom du fichier commence par rootfs:-préfixe, le fichier sera copié dans la liste et sera inclus dans le RootFS avec les autre fichiers. Si il y a un préfixe au fichier il sera supprimé avant la copie.
Si le fichier se trouve dans le sous répertoire config, il sera ajouté dans la liste des fichiers du répertoire config, mais ce fichier ne pourra pas avoir de préfixe rootfs:, comme les fichiers qui proviennent du sous répertoire opt.
Si le fichier à copier est un module-kernel, on peut remplacer le nom de la version du kernel par ${KERNEL_VERSION}. mkfli4l prendra alors la version configurée et l'intègrera. Cela permet d'avoir un paquetage de module-kernel pour chaque versions différente, en plus la bonne version du kernel sera toujours copiée sur le routeur. Au sujet des modules-kernel le chemin peut être complètement omis, car mkfli4l trouve le chemin des modules en utilisant les fichiers modules.dep et modules.alias, reportez-vous à la section «Résolution automatique pour la traçabilité des modules-kernel»
| Option | Signification | Valeur standard | ||||||||||
| type= | type d'entrée :
Si elle est présente, cette option doit venir en premier. Le type «local» représente un type d'objet existant dans le fichier système et correspond donc (le cas échéant) à «file», «dir», «node» ou «symlink». Les autres types, à l'exception de «file» peuvent être utilisés pour enregistrer des archives, il ne doivent pas être présent dans le fichier système local. Par ex., vous pouvez les utiliser pour créer des fichiers de périphérique dans l'archive-RootFS. |
local | ||||||||||
| uid= | Propriété du fichier, soit numériquement, soit en tant que mot de passe | root | ||||||||||
| gid= | Groupe du fichier, soit numériquement, soit en tant que nom de groupe | root | ||||||||||
| mode= | Pour les droits d'accès |
Les Fichiers et matériels :
rw-r--r-- (644)
Les Répertoires : rwxr-xr-x (755)
Les liens : rwxrwxrwx (777)
|
||||||||||
|
Les flags=
(type=file) |
Conversion avant l'enregistrement dans l'archive :
|
|||||||||||
| name= | Nom alternatif sous lequel l'entrée est enregistrée dans l'archive | |||||||||||
|
devtype=
(type=node) |
Décrit le type de matériel («c» pour s'orienter vers la marque et «b» pour s'orienter vers le matériel de bloc. Doit être à la deuxième place. | |||||||||||
|
major=
(type=node) |
Décrit le nombre soi-disant «Majeur» -Numéro de fichier du périphérique. Doit être à la troisième place. | |||||||||||
|
minor=
(type=node) |
Décrit le nombre soi-disant «Mineur» -Numéro de fichier du périphérique. Doit être à la quatrième place. | |||||||||||
|
linktarget=
(type=symlink) |
Décrit la cible du lien symbolique. Doit être à la deuxième place. |
Quelques exemples :
OPT_TELNETD='yes',
placez uid/gid pour le root et placez les droits sur 755 (rwxr-xr-x).
telnetd yes files/usr/sbin/in.telnetd mode=755
r-xr-xr-x) et converti le fichier dans le format Unix en même
temps il supprime tous les caractères superflus.
base yes etc/rc0.d/rc500.killall mode=555 flags=sh
PCMCIA_PCIC='i82365', placez
uid/gid pour le root et placez les droits sur 644 (rw--r--r)
pcmcia_pcic i82365 files/lib/modules/${KERNEL_VERSION}/pcmcia/i82365.ko
rw--r--r)
net_drv_% 3c503 3c503.ko
powermanagement !none etc/rc.d/rc100.pm mode=555 flags=sh
myopta,myoptb yes files/usr/local/bin/myopt-common.sh mode=555 flags=sh
Cet exemple est juste un raccourci pour :
myopta yes files/usr/local/bin/myopt-common.sh mode=555 flags=sh
myoptb yes files/usr/local/bin/myopt-common.sh mode=555 flags=sh
Et celui-ci est un raccourci pour :
opt_myopta yes files/usr/local/bin/myopt-common.sh mode=555 flags=sh
opt_myoptb yes files/usr/local/bin/myopt-common.sh mode=555 flags=sh
base yes rootfs:files/usr/bin/beep.sh mode=555 flags=sh name=bin/beep
Les fichiers sont uniquement copiés, si les conditions indiquées plus
haut sont remplies, si la variable est placé sur OPT_PAQUETAGE='yes'.
Quelle variable-OPT est associée? Pour la vérification voir le fichier
check/<PAQUETAGE>.txt
Si une variable est référencée dans le paquetage et que celle-ci n'est pas définie, il peut arriver que le paquetage correspondant n’est pas installé. Cela mènerait à un message d'erreur du programme mkfli4l, car mkfli4l attend que toutes les variables référencées dans le fichier opt/<PAQUETAGE>.txt soient définis.
Pour gérer correctement cette situation, on introduit la fonction-«weak» dans le format suivant :
weak variable -
Si la variable est définie, même si elle n’est pas disponible la valeur de celle-ci sera indiquée «undefiniert». Toutefois, il convient de noter ici que le préfixe «OPT_» ne doit pas être omis (s'il existe), sinon la variable sera définie sans ce préfixe.
Un exemple du fichier opt/rrdtool.txt :
weak opt_openvpn -
[...]
openvpn yes files/usr/lib/collectd/openvpn.so
Sans la définition weak, la commande mkfli4l affichera un message d'erreur si vous utilisez le paquetage «rrdtool» et si le paquetage «openvpn» n'est pas aussi présent. La définition weak est également utilisé dans le cas où le paquetage «openvpn» n'existe pas, il n'y aura aucun message d'erreur.
Dans certaine situations, on aimerait remplacer des fichiers de configurations originaux par des fichiers spécifiques, qui serait compacté dans l’archive opt.img, par exemple, ajouter une Key-hôte ou ajouter son propre Scripte-Firewall, ... varmkfli4l supporte ce scénario, il vérifie si un fichier est disponible dans le répertoire config, dans ce cas, ce fichier sera ajouté dans la liste des fichiers de l’archive opt.img ou rootfs.img.
Une autre façon d’ajouter des fichiers de configurations spécifiques dans l'archive, est décrit dans le chapitre Contrôle de la configuration avancée.
Dans certaine circonstance un module-kernel a parfois besoin d'autres modules-kernel. Ces modules doivent être chargés avant et serons également inclus dans l'archive. mkfli4l détermine la traçabilité des modules avec les fichiers modules.dep et modules.alias (les deux fichiers sont générés à la compilation du kernel) ainsi ils ajouteront automatiquement tous les modules nécessaires dans l’archive. Par exemple l’enregistrement peut être le suivant
net_drv_% ne2k-pci ne2k-pci.ko
Le pilote ne2k_pci dépend des fichiers suivant 8390.ko, et crc32.ko ils seront ajoutés en premiers dans l'archive.
L’enregistrement du modules.dep et du modules.alias dans le RootFS est nécessaire, ensuite modprobe utilise ces fichiers pour charger les pilotes.
Avec le fichier check/<PAQUETAGE>.txt les variables peuvent être contrôlés pour leurs validités. Ce contrôle était intégré dans les versions précédentes du programme mkfli4l, mais les paquetages fli4l sont modulaire et nous avons du installé un second-contrôle dans ce fichier. Dans ce fichier, une ligne est accessible pour chaque variable du fichier de configuration. Ces lignes se composent de quatre à cinq colonnes, qui ont les fonctions suivantes :
Dans certaine situation, nous pouvons avoir besoin de variable optionnelle supplémentaire dans le fichier config. Ces variables sont présentes dans le fichier de contrôle, elles sont marquées et précédées du signe «+». Dans le tableau, vous pouvez voir aussi des variables précédées du signe «++». Avec le signe «+», ces variables sont présentes ou absente du fichier config. Avec le signe «++», ces variables sont totalement absente du fichier config. Vous pouvez les rajouter manuellement, si vous en avez besoin dans le fichier config.
Si une variable ne dépend d'aucune variables OPT, elle sera considérée comme active. Si elle dépende d'une variable OPT, elle sera explicitement active, si
Dans tous les autres cas, la variable est inactive.
Remarque : les variables OPT inactifs seront replacées sur «no» par mkfli4l
si elle sont réglées sur «yes» dans le fichier de configuration, un message
d'avertissement sera alors généré (c'est à dire «OPT_Y='yes' ignoré, parce que OPT_X='no'»).
Pour les chaînes de dépendance transitive (OPT_Z dépend de OPT_Y
qui à son tour dépend de OPT_X) cela fonctionnera de manière fiable, si
les noms de tous les variables OPT commencent par «OPT_».
Pour la compatibilité avec les futures versions de fli4l la variable spécifiée ici doit être identique à la variable qui est dans OPT_VARIABLE et le dernier signe «%» sera remplacé par un «N» tout ce qui suit sera retiré. Pour la liste HOST_%_IP4 vous devez assigner N-Variable HOST_N et pour la liste PF_USR_CHAIN_%_RULE_% vous devez aussi assigner N-Variable PF_USR_CHAIN_%_RULE_N. Toutes les autres définitions de N-variable ne seront pas compatibles avec les versions futures de fli4l !
| Nom | Signification |
| NONE | ne déclenche aucun contrôle |
| YESNO | La variable doit être sur «yes» ou sur «no» |
| NOTEMPTY | La variable ne peut pas être vide |
| NOBLANK | La variable ne devrait pas contenir d'espaces |
| NUMERIC | La variable doit être numérique |
| IPADDR | La variable doit être une adresse IP |
| DIALMODE | La variable doit être sur «on», «off» ou «auto» |
Si vous indiquez le préfixe «WARN_», la valeur sera irrégulière et sera indiqué par un message, mkfli4l ne s’arrêtera pas, mais affichera seulement un avertissement.
Le contrôle est défini par des expressions régulières dans le fichier check/base.exp. Ce fichier à été récemment étendu, il contient maintenant des contrôles complémentaires suivants : HEX, NUMHEX, IP_ROUTE, DISK et PARTITION.
Si les développeurs-opt ont besoin de rajouter une entrée, le nombre de termes peut, à tout moment être étendu.
En outre, les expressions régulières peuvent être ajoutées directement dans le fichier du répertoire check, on peut également se référer à des expressions existantes. Par exemple au lieu d’utiliser YESNO on pourrait également écrire
RE:yes|no
cela est utile pour un test qui est effectué qu’une seule fois, il est
relativement simple. Pour de plus amples informations, voir le chapitre suivant.
Remarque : à présent si cela ne fonctionne pas pour les variables de la liste. La variable ne doit pas être facultative, donc il ne doit pas avoir le signe «+» devant le nom de la variable.
Exemple :
OPT_TELNETD - - YESNO "no"
La variable OPT_TELNETD est maintenant manquante dans le fichier de configuration, mais dans le fichier rc.cfg elle sera affichée avec la valeur «no».
La variable avec le signe pourcentage peut être mieux expliquée avec un exemple. Voici une partie du fichier check/base.txt :
NET_DRV_N - - NUMERIC
NET_DRV_% - NET_DRV_N NONE
NET_DRV_%_OPTION - NET_DRV_N NONE
En d'autres termes, en fonction de la valeur indiquée dans NET_DRV_N les variables NET_DRV_N, NET_DRV_1_OPTION, NET_DRV_2_OPTION, NET_DRV_3_OPTION, etc. seront vérifiées.
Dans la version 2.0, il y a que 7 expressions, susceptibles d’examinées les variables: NONE, NOTEMPTY, NUMERIC, IPADDR, YESNO, NOBLANK, DIALMODE. Ces expressions ont été fixé dans mkfli4l pour la vérification, ils ne sont pas extensibles et se limite à essentielle aux «types de données», avec juste se qu’il faut pour pouvoir faire le contrôle.
Dans la version 2.1 un nouveau contrôle a été créé. L'objectif de cette nouvelle création est de faite un contrôle plus flexible des variables, qui sera en mesure d'examiner des expressions plus complexes. C'est la raison pour laquelle les expressions régulières seront utilisées dans un ou plusieurs fichiers séparés. Il sera possible, d'une part, de vérifier les variables avant le contrôle par mkfli4l et d'autre part, les développeurs pourront définir leurs propres expressions, pour la configuration et le contrôle de leur paquetage.
Vous pouvez trouver une description des expressions régulières, dans «man 7 regex», ou par exemple ici : http://unixhelp.ed.ac.uk/CGI/man-cgi?regex+7.
On peut spécifier des expressions de deux manières différentes :
Ce fichier se trouve dans le répertoire-check et porte le même nom que son paquetage, par ex. base.exp. Les expressions contiennent les définitions, qui sont référencé dans le fichier check/<PAQUETAGE>.txt. Ainsi, check/base.exp peut contrôler les définitions. Bien connu le fichier check/isdn.exp qui contrôle la définition de la variable ISDN_CIRC_?_ROUTE (à l'origine le contrôle de cette variable était absente cela a été modifié).
Chaque définition sera écrite entre deux apostrophes, la syntaxe est la suivante :
<Name> = '<expression régulière>' : '<le message d'erreur>'
Autre exemple de la check/base.exp :
NOTEMPTY = '.*[^ ]+.*' : 'should not be empty'
YESNO = 'yes|no' : 'only yes or no are allowed'
NUMERIC = '0|[1-9][0-9]*' : 'should be numeric (decimal)'
OCTET = '1?[0-9]?[0-9]|2[0-4][0-9]|25[0-5]'
: 'should be a value between 0 and 255'
IPADDR = '((RE:OCTET)\.){3}(RE:OCTET)' : 'invalid ipv4 address'
EIPADDR = '()|(RE:IPADDR)'
: 'should be empty or contain a valid ipv4 address'
NOBLANK = '[^ ]+' : 'should not contain spaces'
DIALMODE = 'auto|manual|off' : 'only auto, manual or off are allowed'
NETWORKS = '(RE:NETWORK)([[:space:]]+(RE:NETWORK))*'
: 'no valid network specification, should be one or more
network address(es) followed by a netmask,
for instance 192.168.6.0/24'
Dans les expressions régulières, vous pouvez toujours rajouter une référence, dans une définition existante. Cela est plus facile que de construire une expression régulière. Il suffit simplement d’insérer la référence de cette manière '(RE:référence)'. (Voir la définition de l'expression NETWORKS ci-dessus pour un exemple approprié.)
Les messages d'erreur ont tendance à être trop longs. Il est donc possible, de les afficher sur plusieurs lignes. Vous devez toujours utiliser au début de la ligne un espace ou une tabulation. Lors de la lecture du fichier check/<PAQUETAGE>.exp des espaces supplémentaires sont réduits à un seul espace et une tabulation sera remplacé par des espaces.
La configuration du fichier check/<PAQUETAGE>.exp pourrait alors ressembler à ce qui suit :
NUM_HEX = '0x[[:xdigit:]]+'
: 'should be a hexadecimal number
(a number starting with "0x")'
Certaines expressions sont utilisé qu’une seule fois, ce n’est pas la peine de définir ces expressions régulières dans le fichier check/<PAQUETAGE>.exp. Nous pouvons alors, enregistrer simplement ces expressions dans le fichier-Check, par ex. :
# Variable OPT_VARIABLE VARIABLE_N VALUE
MOUNT_BOOT - - RE:ro|rw|no
La variable MOUNT_BOOT ne peut qu’accepter les valeurs «ro», «rw» ou «no» toutes les autres sont rejetées
Si vous voulez référencer une expression régulière existants, vous devez simplement ajouter la référence de cette manière «(RE:...)», par ex.:
# Variable OPT_VARIABLE VARIABLE_N VALUE
LOGIP_LOGDIR OPT_LOGIP - RE:(RE:ABS_PATH)|auto
Si vous ajoutez un paquetage optionnel supplémentaire, vous devez ajouter une expression régulière pour que la valeur de la variable soit examinée, l'expression régulière doit être agrandie, cela se passe simplement par l’ajout une nouvelle définition des valeurs dans l’expression régulière (comme décrit plus haut). Le complément de l'expression régulière existante est copié dans le fichier check/<PAQUETAGE>.exp. L’expression existante sera modifiée, par le caractère «+» qui sera ajouté au premier plan. L’expression existante sera complétée par une nouvelle valeur, ainsi la nouvelle valeur est ajoutée comme l'alternative à la valeur existante. Si une autre expression utilise l'expression qui a été complétée, le complément de cette expression sera aussi valable. Vous pouvez indiquer un message d'erreur, il sera simplement ajouté après l’expression.
Voici un exemple pour les pilotes-Ethernet :
NET_DRV = '3c503|3c505|3c507|...'
: 'invalid ethernet driver, please choose one'
' of the drivers in config/base.txt'
PCMCIA_NET_DRV = 'pcnet_cs|xirc2ps_cs|3c574_cs|...' : ''
+NET_DRV = '(RE:PCMCIA_NET_DRV)' : ''
Maintenant, vous pouvez également sélectionner les pilotes PCMCIA supplémentaires.
Après avoir ajouté le pilote PCMCIA dans NET_DRV comme décrit plus haut. Si le paquetage «pcmcia» est désactivé et si vous voulez quand même choisir un pilote PCMCIA dans config/base.txt, sans avoir de message d'erreur à la création du support de boot. Vous pouvez modifier l'expression régulière avec la variable YESNO dans la configuration. Pour cela vous devez ajouter des parenthèses immédiatement après le nom de la variable sur l'expression pour déterminer si l'expression est étendu. Si la variable est active avec la valeur «yes», l'expression sera étendu, autrement elle ne l'est pas.
PCMCIA_NET_DRV = 'pcnet_cs|xirc2ps_cs|3c574_cs|...' : ''
+NET_DRV(OPT_PCMCIA) = '(RE:PCMCIA_NET_DRV)' : ''
Maintenant si on veut utiliser par ex. le pilote xirc2ps_cs dans config/base.txt et
si la variable est paramétré sur OPT_PCMCIA='no', il y aura un message
d’erreur à la création des archives.
Remarque : si cela ne fonctionne pas, la variable n'est peut être pas définie explicitement dans le fichier de configuration mais elle obtient une valeur avec un paramètre par défaut dans check/<PAQUETAGE>.txt. Dans ce cas, vous devez définir explicitement la variable et enlever le paramètre par défaut si nécessaire.
Vous pouvez alternativement utiliser toutes les valeurs de la variable, à condition, que la syntaxe apparaît comme indiquer ci-dessous :
+NET_DRV(KERNEL_VERSION=~'^3\.16\..*$') = ...
Si l'expression KERNEL_VERSION correspond au donné, c'est-à-dire ici à utilisation du kernel version 3.16, alors la liste complète des pilotes réseaux qui tournent avec celui-ci seront autorisés.
Remarque : si cela ne fonctionne pas, la variable n'est peut être pas définie explicitement dans le fichier de configuration mais elle obtient une valeur avec un paramètre par défaut dans check/<PAQUETAGE>.txt. Dans ce cas, vous devez définir explicitement la variable et enlever le paramètre par défaut si nécessaire.
Si pendant le contrôle, mkfli4l trouve une erreur, un message de cette erreur apparaîtra exemple :
Error: wrong value of variable HOSTNAME: '' (may not be empty)
Error: wrong value of variable MOUNT_OPT: 'rx' (user supplied regular expression)
La première erreur, a été définie dans le fichier check/<PAQUETAGE>.exp, une indication sur l'erreur sera affichée. La deuxième erreur à été spécifié directement dans le fichier check/<PAQUETAGE>.txt, il n'y aura aucune indication supplémentaire sur la raison de l'erreur.
Les expressions régulières sont définies comme indiqué ci-dessous :
Expression régulière : vous pouvez paramétrer une ou plusieurs options, vous devez les séparer par le signe «|», par ex. «ro|rw|no». Si l’une des options s'applique, alors l'expression sera appliquée (ici les expressions valides sont «ro», «rw» et «no»).
Une option est une concaténation de tronçon, qui sont simplement reliés entre eux.
Un tronçon est un «Atome», suivi pas un signe quantificateur «*», «+», «?» ou «{min, max}». La signification est la suivante :
Un «atome» est
Signification d'une expression entre des crochets, lire la suite.
Jetons un coup d'oeil sur quelques exemples :
NUMERIC : Valeur numérique qui est constitué d’au moins de un, mais aussi d'un nombre quelconque de chiffres. Avec le signe «+» la valeur peut être répéter au moins une ou plusieurs fois à partir d'un nombre, voici un exemple pour obtenir un nombre composé :
NUMERIC = '[0-9]+'
ou alors
NUMERIC = '[[:digit:]]+'
NOBLANK : valeur qui ne contient pas d'espace, les caractères peuvent être quelconque (à l'exception de l'espace), voici un exemple avec divers caractères :
NOBLANK = '[^ ]*'
De plus cette valeur, ne doit pas être vide :
NOBLANK = '[^ ]+'
IPADDR: Une adresse IP se compose de 4 octet ils sont séparés par un «.» point. Un octet
peut être un nombre compris entre 0 et 255. Si nous voulons définir le première
octet, il faut.
| Avoir un chiffre entre 0 et 9: | [0-9] |
| un nombre compris entre 10 et 99: | [1-9][0-9] |
| un nombre compris entre 100 et 199: | 1[0-9][0-9] |
| un nombre compris entre 200 et 249: | 2[0-4][0-9] |
| Avoir un nombre entre 250 et 255: | 25[0-5] |
Suite de la solution, nous allons séparer tout simplement par le signe '|' chaque partie de l'adresse-IPv4 avec l'expression : «[0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5]» ainsi nous avons tous les octets. Cela nous permet désormais d'avoir notre adresse-IPv4 de 4 octets séparé par un point (pour écrire un point vous devez placer un Backslashs (ou barre oblique inversée) sinon, il remplacera tout caractère). Vous pouvez voir ci-dessous la syntaxe tiré du fichier exp :
OCTET = '[0-9]|[1-9][0-9]|1[0-9][0-9]|2[0-4][0-9]|25[0-5]'
IPADDR = '((RE:OCTET)\.){3}(RE:OCTET)'
Si vous voulez créer et tester les expressions régulières, vous pouvez utiliser l'outil regexp pour l'expression rationnelle, qui est situé dans le répertoire unix ou windows du paquetage «base». Avec la syntaxe suivante :
utilisation de~: regexp [-c <check dir>] <regexp> <string>
Courte explication des paramètres :
'...' ou "..." ils sont nécessaires
si les apostrophes veulent apparaître dans l'expression)
Voici quelques exemples :
./i586-linux-regexp -c ../check '[0-9]' 0
adding user defined regular expression='[0-9]' ('^([0-9])$')
checking '0' against regexp '[0-9]' ('^([0-9])$')
'[0-9]' matches '0'
./i586-linux-regexp -c ../check '[0-9]' a
adding user defined regular expression='[0-9]' ('^([0-9])$')
checking 'a' against regexp '[0-9]' ('^([0-9])$')
regex error 1 (No match) for value 'a' and regexp '[0-9]' ('^([0-9])$')
./i586-linux-regexp -c ../check IPADDR 192.168.0.1
using predefined regular expression from base.exp
adding IPADDR='((RE:OCTET)\.){3}(RE:OCTET)'
('^(((1?[0-9]?[0-9]|2[0-4][0-9]|25[0-5])\.){3}(1?[0-9]?[0-9]|2[0-4][0-9]|25[0-5]))$')
'IPADDR' matches '192.168.0.1'
./i586-linux-regexp -c ../check IPADDR 192.168.0.256
using predefined regular expression from base.exp
adding IPADDR='((RE:OCTET)\.){3}(RE:OCTET)'
('^(((1?[0-9]?[0-9]|2[0-4][0-9]|25[0-5])\.){3}(1?[0-9]?[0-9]|2[0-4][0-9]|25[0-5]))$')
regex error 1 (No match) for value '192.168.0.256' and regexp
'((RE:OCTET)\.){3}(RE:OCTET)'
(unknown:-1) wrong value of variable cmd_var: '192.168.0.256' (invalid ipv4 address)
Il est parfois nécessaire d'effectuer des contrôles plus ou moins complexes. Exemple de choses complexe. Avoir une relation entre les paquetages ou avoir une condition à remplir lorsque des variables prennent certaines valeurs. Par ex. lors du choix d’un adaptateur-PCMCIA-ISDN dans le paquetage «pcmcia».
Pour effectuer ces contrôles, on peut écrire dans le fichier check/<PAQUETAGE>.ext (également appelé ext-script) différent petit test. Ce langage se compose des éléments suivants :
~, copy_pending, samenet, subnet
C'est-à-dire que les types de données de la variable sont associées à une expression régulière et sont affectés en permanence à un type de données :
Cela signifie, entre autres chose, qu'une variable de type ENUMERIC ne peut pas être utilisé comme un indice, lors d'un accès à une liste de variables même si vous avez d'abord vérifié si elle n'était pas vide. Le code suivant ne fonctionnera pas comme prévu :
# TEST should be a variable of type ENUMERIC
if (test != "")
then
# Error: You can't use a non-numeric ID in a numeric
# context. Check type of operand.
set i=my_array[test]
# Error: You can't use a non-numeric ID in a numeric
# context. Check type of operand.
set j=test+2
fi
Voici une solution à ce problème split :
if (test != "")
then
# all elemente of test_% are numeric
split(test, test_%, ' ', numeric)
# OK
set i=my_array[test_%[1]]
# OK
set j=test_%[1]+2
fi
À divers moments les chaînes sont nécessaires, par ex. lorsque vous devez émettre Attention un avertissement. Certains cas, sont décrits dans cette documentation, une telle chaîne est recherchée pour une variable précise, si elle est trouvé, elle est remplacé par son contenu ou par d'autres attributs. Ce remplacement est appelé substitution de variable.
Cela va être illustré par un exemple. Supposons cette configuration :
# config/base.txt
HOSTNAME='fli4l'
# config/dns_dhcp.txt
HOST_N='1' # Nombre d'hôtes
HOST_1_NAME='client'
HOST_1_IP4='192.168.1.1'
Ensuite, les chaînes de caractères sont réécrits comme ceci, si la substitution de variable est actif dans ce contexte :
"Mon routeur s'appel $HOSTNAME"
# --> "Mon routeur s'appel fli4l"
"HOSTNAME fait partie du paquetage %{HOSTNAME}"
# --> "HOSTNAME fait partie du paquetage base"
"@HOST_N est $HOST_N"
# --> "Nombre d'hôte est 1"
Comme vous pouvez le voir, il y a essentiellement trois options pour le remplacement :
Remarque : Les éléments de liste de variables ne peuvent pas être intégré dans des chaînes de caractères de cette façon, parce qu'il n'y a aucune possibilité de fournir un index.
En général, seule une constante peut être utilisé pour la substitution de variable, les chaînes qui proviennet d'une variable restent inchangées. Un exemple permettra de clarifier cela - voici la configuration suivante :
HOSTNAME='fli4l'
TEST='${HOSTNAME}'
Ensuite, le code :
warning "${TEST}"
Produit la sortie suivante :
Warning: ${HOSTNAME}
Et pas la sortie :
Warning: fli4l
Dans les sections suivantes, on notera explicitement les conditions des chaînes qui font l'objet d'une substitution de variable.
Cela permet par exemple un OPT peut déclarer et mettre à disposition un serveur d'impression ou un service Web. Un seul paquetage, fourni un certain service. Cela empêche par exemple d'installer deux serveurs web en parallèle, cela ne fonctionnerais pas pour des raisons évidentes, puisque les deux serveurs utiliseraient le port 80. En outre, la version actuelle du service est prévu pour est mise à jour régulièrement. Le numéro de version se compose de deux ou trois nombres séparés par des points, comme ڲ.0» ou ڰ.1.23».
Les services proviennent généralement de l'OPT, pas du paquetage. Par exemple, dans
le paquetage «tools» il y a une série de programmes, qui ont chacun leur propre
instruction provides elle sera activée via OPT_...='yes'.
La syntaxe est :
provides <Name> version <Version>
Exemple avec le paquetage «easycron»:
provides cron version 3.10.0
Le numéro de version doit être incrémenté par le développeur de l'OPT dans le troisième volet, si les fonctionnalitées ont été seulement améliorations et que l'interface est toujours compatible avec l'OPT. Le numéro de version doit être augmentée avec le premier ou le deuxième chiffre, si l'interface a été modifiée et est incompatible (par exemple, en raison de variables renommées, des chemins changés, manquant ou le programme de service a été renommés, etc.).
Si un autre service est nécessaire pour assurer la fonction de votre propre service (par exemple un serveur web), on peut définir une dépendance par une version spécifique pour le service. La version peut être indiquée par deux (par ex. ڰ.1») ou trois chiffres (par ex. ڰ.1.11»), la version à deux chiffres accepte toutes les versions à partir de ce nombre et la version à trois chiffres accepte seulement la version spécifié. En outre, vous pouvez spécifier une liste de numéros de version si plusieurs versions du service est compatible avec le paquetage.
La syntaxe est la suivante :
depends on <Name> version <Version>+
Exemple : le paquetage «serveur» contient :
provides server version 1.0.1
Avec le paquetage «client». vous indiquez l'instruction depends dans cette exemple 8.2
depends on server version 1.0 # OK, '1.0' s'adapte '1.0.1'
depends on server version 1.0.1 # OK, '1.0.1' s'adapte '1.0.1'
depends on server version 1.0.2 # Erreur, '1.0.2' s'adapte pas '1.0.1'
depends on server version 1.1 # Erreur, '1.1' s'adapte pas '1.0.1'
depends on server version 1.0 1.1 # OK, '1.0' s'adapte '1.0.1'
depends on server version 1.0.2 1.1 # Erreur, ni '1.0.2' ni '1.1' ne s'adapte '1.0.1'
Avec l'aide de ces trois fonctions, on peut avertir et signaler l’utilisateur, d’une erreur ou interrompre immédiatement le traitement de contrôle. La syntaxe est la suivante :
warning "text"
error "text"
fatal_error "text"
Toutes les chaînes utilisées avec ces fonctions sont soumis à une substitution de variable.
Si vous avez besoin d’utiliser une variable temporaire pour une raison quelconque, vous pouvez la créer avec «set var [= value]». La variable ne peut pas être une variable de configuration ! 8.3 Si vous omettez «= value» la variable sera alors simplement placée sur «yes», ensuite vous pouvez tester facilement la variable avec l’instruction if. Vous pouvez spécifier les données suivant après le signe égal, variable normale, variable indexée, nombre, chaîne de caractère, versions.
Il convient de noter de par l'assignation le type sera défini dans la variable temporaire. Si un numéro est attribué mkfli4l se «souviendra» que la variable contient un numéro et permettra plus tard de faire un calcul avec celui-ci. Si vous essayez de faire un calcul avec une variable de type différent, il échouera. Exemple :
set i=1 # OK, i est une variable numérique
set j=i+1 # OK, j est une variable numérique et contient la valeur 2
set i="1" # OK, i est maintenant une variable de chaîne
set j=i+1 # Erreur "Vous ne pouvez pas utiliser un ID non numérique dans un
# contexte numérique. Vérifiez le type de l'opérande."
# --> Pas de calculs avec des chaînes~!
Vous pouvez également créer des listes temporaires (voir ci-dessous). Exemple :
set prim_%[1]=2
set prim_%[2]=3
set prim_%[3]=5
warning "${prim_n}"
Le nombre de liste d'éléments est géré par mkfli4l et par la variable prim_n. Le code ci-dessus conduit donc à la sortie suivante :
Warning: 3
Si le côté droit de la cession est une constante de chaîne, elle est soumise à une substitution de variable. L'exemple suivant montre le code :
set s="a"
set v1="$s" # v1="a"
set s="b"
set v2="$s" # v2="b"
if (v1 == v2)
then
warning "égal"
else
warning "pas égal"
fi
La sortie produite n'est «pas égale», parce que les variables v1 et v2 sont remplacées par le contenu de la variable s déjà en cours de cession.
Remarque : Un ensemble de variables dans un script est visible lors du traitement des autres scripts - actuellement il n'existe pas de principe de localisation pour ces variables introduites. L'ordre dans lequel les scripts sont traitées dans divers paquetages, n'est pas définie, vous ne devez pas compter sur une variable ayant des valeurs définies dans un autre paquetage.
Si vous voulez accéder aux éléments d'une %-variable (ou de la liste), vous devez utiliser le nom original de la variable comme mentionné dans le fichier check/<PAQUETAGE>.txt et d'ajouter un index pour chaque signe «%» en utilisant «[Index]».
Exemple : Si vous voulez accéder aux éléments de la variable PF_USR_CHAIN_%_RULE_% vous avez besoin de deux index car la variable a deux signes «%». Tous les éléments peuvent être enregistrés par exemple en utilisant la (boucle foreach et voir ci-dessous) :
foreach i in pf_usr_chain_n
do
# un seul index nécessaire, seul un '%' dans la variable
set j_n=pf_usr_chain_%_rule_n[i]
# Attention: a
# foreach j in pf_usr_chain_%_rule_n[i]
# n'est pas possible, d'où l'utilisation de j_n~!
foreach j in j_n
do
# deux index nécessaires, deux '%' dans la variable
set rule=pf_usr_chain_%_rule_%[i][j]
warning "Rule $i/$j: ${rule}"
done
done
Exemple de configuration
PF_USR_CHAIN_N='2'
PF_USR_CHAIN_1_NAME='usr-chain_a'
PF_USR_CHAIN_1_RULE_N='2'
PF_USR_CHAIN_1_RULE_1='ACCEPT'
PF_USR_CHAIN_1_RULE_2='REJECT'
PF_USR_CHAIN_2_NAME='usr-chain_b'
PF_USR_CHAIN_2_RULE_N='1'
PF_USR_CHAIN_2_RULE_1='DROP'
la sortie suivante est imprimé :
Warning: Rule 1/1: ACCEPT
Warning: Rule 1/2: REJECT
Warning: Rule 2/1: DROP
Alternativement, vous pouvez parcourir directement toutes les valeurs du tableau, mais les indices exacts ne sont pas toujours connus (car se n'est pas nécessaire) :
foreach rule in pf_usr_chain_%_rule_%
do
warning "Rule %{rule}='${rule}'"
done
Cela produit la sortie suivante avec l'exemple de configuration à partir des information ci-dessus :
Warning: Rule PF_USR_CHAIN_1_RULE_1='ACCEPT'
Warning: Rule PF_USR_CHAIN_1_RULE_2='REJECT'
Warning: Rule PF_USR_CHAIN_2_RULE_1='DROP'
Le deuxième exemple montre bien le sens de la syntaxe %<Name> : la chaîne %rule est substitué par le nom de la variable en question (par exemple PF_USR_CHAIN_1_RULE_1), tandis que $rule est substitué par son contenu (exemple ACCEPT).
Dans le fichier rc.cfg certaines variables contiennent des mots de passe qui ne doivent pas apparaitre en clair. Ces variables peuvent être cryptées en utilisant crypt et seront transférées dans un format qui est également utilisé par le routeur. On utilise pour cela :
crypt (<variable>)
La fonction crypt est seulement un endroit où la variable de configuration peut être modifiée.
stat vous permet de rechercher les propriétés d'un fichier. Il indique pour l'instant que la taille du fichier. Si vous souhaitez tester des fichiers de configuration dans le répertoire courant, vous pouvez utiliser la variable interne config_dir. La syntaxe est :
stat (<nom de fichier>, <clé>)
La commande ressemble à ceci (les paramètres utilisés ne sont que des exemples) :
foreach i in openvpn_%_secret
do
stat("${config_dir}/etc/openvpn/$i.secret", keyfile)
if (keyfile_res != "OK")
then
error "OpenVPN: missing secretfile <config>/etc/openvpn/$i.secret"
fi
done
L'exemple suivant vérifie si un fichier existe dans le répertoire de configuration
actuelle. Si la variable OPENVPN_1_SECRET='test' est définie dans le fichier
de configuration, lors du premier contrôle d'exécution la boucle vérifira l'existence du fichier
etc/openvpn/test.secret dans le répertoire de configuration actuelle.
Après l'exécution deux variables sont définies :
Cela pourrait alors ressembler à ceci :
stat ("unix/Makefile", test)
if ("$test_res" == "OK")
then
warning "test_size = $test_size"
else
error "Error '$test_res' while trying to get size of 'unix/Makefile'"
fi
Un nom de fichier passé comme une constante de la chaîne est soumis à une substitution de variable.
Si vous voulez rechercher un fichier avec «grep», 8.4 vous avez aussi la possibilité d'utiliser la commande fgrep, la syntaxe est :
fgrep (<nomdefichier>, <regex>)
Si le fichier <nom de fichier> n'existe pas alors mkfli4l s’arrête et affiche une erreur fatale ! Si vous n'êtes pas sûr que le fichier est toujours présent, vous devez avant utiliser la commande stat pour savoir si le <nom de fichier> existe. Après avoir exécuté fgrep le résultat de recherche sera présent dans un tableau et FGREP_MATCH_% sera disponible, avec l'indice x comme d'habitude vous allez avoir FGREP_MATCH_N. FGREP_MATCH_1 fait référence à toute les lignes l'expression régulière correspondantes, tandis que FGREP_MATCH_2 pour FGREP_MATCH_N contient la nième n-1 partie entre parenthèses.
Un premier exemple simple vous montrer comment l'utiliser. Le fichier opt/etc/shells contient la ligne :
/bin/sh
Le code est le suivant
fgrep("opt/etc/shells", "^/(.)(.*)/")
foreach v in FGREP_MATCH_%
do
warning "%v='$v'"
done
Produit la sortie suivante :
Warning: FGREP_MATCH_1='/bin/'
Warning: FGREP_MATCH_2='b'
Warning: FGREP_MATCH_3='in'
Le RegEx correspond (seulement) à «/bin/», (seul) cette partie de ligne est contenue dans la variable FGREP_MATCH_1. La première partie entre les paranthéses de l'expression correspond au premier caractère après le premier signe «/», c'est pourquoi «b» est contenu dans FGREP_MATCH_2. La deuxième partie restante contient entre les paranthéses «b» jusqu'au dernière signe «/», donc «in» est dans la variable FGREP_MATCH_3.
Le deuxième exemple suivant vous montrer une utilisation pratique de fgrep avec le fichier check/base.ext. Il sera testé si toutes les références tmpl: indiquées, sont vraiment présent dans PF_FORWARD_x :
foreach n in pf_forward_n
do
set rule=pf_forward_%[n]
if (rule =~ "tmpl:([^[:space:]]+)")
then
foreach m in match_%
do
stat("$config_dir/etc/fwrules.tmpl/$m", tmplfile)
if(tmplfile_res == "OK")
then
add_to_opt "etc/fwrules.tmpl/$m"
else
stat("opt/etc/fwrules.tmpl/$m", tmplfile)
if(tmplfile_res == "OK")
then
add_to_opt "etc/fwrules.tmpl/$m"
else
fgrep("opt/etc/fwrules.tmpl/templates", "^$m[[:space:]]+")
if (fgrep_match_n == 0)
then
error "Can't find tmpl:$m for PF_FORWARD_${n}='$rule'!"
fi
fi
fi
done
fi
done
La valeur du nom de fichier ainsi que l'expression régulière passée comme une constante de chaîne sont soumis à une substitution de variable.
Souvent plusieurs paramètres sont appliqués dans une variable, ensuite dans le script de démarrage ces paramètres sont désassemblés séparément. Si vous voulez effectuer des tests lors du désassemblage, c’est la commande split qu’il vous faut. La syntaxe est :
split (<Chaîne>, <Liste>, <Séparateur>)
Une chaîne peut être spécifié par une variable ou directement en tant que constante. mkfli4l décompose la chaîne là ou apparaît un séparateur et génère un élément pour chaque partie de la liste. Vous pouvez parcourir ces éléments plus tard et effectuer des tests. Si rien n'est trouvé entre deux séparateurs un élément de la liste est générée comme une valeur pour une chaîne vide. L'exception « » est : tous les espaces sont supprimés et aucune variable vide n'est créé.
Lors de la décomposition des éléments, si un contexte numérique apparait dans la variable (par exemple sous forme d'indice) cela doit être précisé dans la commande split. Vous devez ajouter un attribut supplémentaire 'numéric'. Cette exécution se présente comme ceci :
split (<Chaîne>, <Liste>, <Séparateur>, numeric)
Voici un exemple :
set bar="1.2.3.4"
split (bar, tmp_%, '.', numeric)
foreach i in tmp_%
do
warning "%i = $i"
done
Produit la sortie suivante :
Warning: TMP_1 = 1
Warning: TMP_2 = 2
Warning: TMP_3 = 3
Warning: TMP_4 = 4
Remarque : si vous utilisez une variable «numeric» mkfli4l ne vérifira pas les parties de chaîne générés si elle ne sont pas vraiment numérique ! Si vous utilisez une telle construction dans un contexte numérique mkfli4l déclenchera une erreur fatale si une telle variable n'est pas numérique. Exemple :
set bar="a.b.c.d"
split (bar, tmp_%, '.', numeric)
# Fehler: invalid number 'a'
set i=tmp_%[1]+1
Une valeur utilisée dans le première paramètre de la constant de chaîne est soumis à une substitution de variable.
Avec la fonction add_to_opt des fichiers supplémentaires peuvent être ajoutés dans une archive OPT ou dans le RootFS. Il est possible de sélectionner tous les fichiers du sous-répertoire opt/ ou à partir du répertoire de configuration. Il n'y a pas de restriction sur l’ajout de fichiers dans un paquetage. Si un fichier doit être à la fois dans opt/ et dans le répertoire de configuration, add_to_opt choisira de copie les fichiers dans le répertoire de configuration. La fonction add_to_opt est complexe et est en règle général logique, la fonction décide quel fichier sera copié en premier dans l'archive.
La syntaxe est la suivante :
add_to_opt <nom de fichier> [<Flags>]
Le Flags est optionnel. Les valeurs par défaut de la table 8.2 sont utilisés si aucun Flags n'est indiqué.
Ci-après un exemple à partir du paquetage «sshd» :
if (opt_sshd)
then
foreach pkf in sshd_public_keyfile_%
do
stat("$config_dir/etc/ssh/$pkf", publickeyfile)
if(publickeyfile_res == "OK")
then
add_to_opt "etc/ssh/$pkf" "mode=400 flags=utxt"
else
error "sshd: missing public keyfile %pkf=$pkf"
fi
done
fi
Utiliser d'abord stat pour vérifier si le fichier existe bien dans le répertoire config. Si le fichier existe, il sera ajouté à l'archive, sinon mkfli4l renvoie un message d'erreur.
Remarque : mkfli4l vérifie aussi avec la fonction add_to_opt si le fichier à copier, se trouve bien dans le répertoire config.
Les noms de fichiers et des Flags qui sont utilisés en tant que constantes de chaîne sont soumis à une substitution de variable.
if (expr)
then
statement
else
statement
fi
Un cas classique de restinction, comme nous connaissons. Si la condition est vraie, alors, l’expression then est exécutée, si la condition est fausse, l’expression else sera exécutée.
Si vous voulez effectuer des tests de %-variable, il faudra tester chaque variable. Pour éviter cela, il y a la boucle foreach en deux variantes.
foreach <contrôle variable> in <Liste-Variable>
do
<instruction>
done
foreach <contrôle variable> in <liste-Variable-1> <liste-Variable-2> ...
do
<instruction>
done
Cette boucle parcourt tous le tableau de variables spécifié, en commençant par le premier et le dernier élément, le nombre d'éléments de cette liste est extraites du N-variable associée à ce tableau. La contrôle variable prend les valeurs des variables du tableau respectifs. Il est à noter vous pouvez ajouter un processus optionnel pour les variables du tableau si une valeur n'est pas présents dans la configuration, un élément vide sera généré. Vous pourriez en tenir compte dans le script, par exemple comme ceci :
foreach i in template_var_opt_%
do
if (i != "")
then
warning "%i is present (%i='$i')"
else
warning "%i is undefined (empty)"
fi
done
Comme vous pouvez le voir dans l'exemple, le nom des variables du tableau respectives peut être déterminée avec l'instruction %<contrôle variable>.
L'instruction dans la boucle ci-dessus peut être l'un des éléments de contrôle ou de fonctions (if, foreach, provides, depends, ...).
Si vous souhaitez accéder exactement à un élément du tableau, vous pouvez y remédier en utilisant la syntaxe <Liste>[<Index>]. L'index peut être une variable normale, une constante numérique ou encore un tableau indexé.
foreach <contrôle variable> in <N-Variable>
do
<instruction>
done
Cette boucle s'exécute de 1 à la valeur qui est indiqué dans la N-variable. Vous pouvez utiliser contrôle variable dans un tableau de variables indexé. Donc, si vous voulez parcourir non seulement un tableau de variable, mais plusieurs tableaux de variables en même temps, tous contrôlés par la même N-variable, vous prenez la variante de boucle et vous utilisez le contrôle variable pour l'indexation de plusieurs tableaux de variables. Exemple :
foreach i in host_n
do
set name=host_%_name[i]
set ip4=host_%_ip4[i]
warning "$i: name=$name ip4=$ip4"
done
Le résultat du contenu du tableua de la liste HOST_%_NAME et de la liste HOST_%_IP4 pour cet exemple :
Warning: 1: name=berry ip4=192.168.11.226
Warning: 2: name=fence ip4=192.168.11.254
Warning: 3: name=sandbox ip4=192.168.12.254
Une expression est liée à une valeur et un opérateur à une autre valeur. Cette valeur peut être une variable normale, un élément d'un tableau, ou une constante (nombre, chaîne de caractère ou numéro de version). Toutes les constantes de chaîne dans les expressions sont soumises à une substitution de variable.
Les opérateurs vous permettent de fait à peu près tout ce que vous attendez d'un language de programmation. Un test pour l'égalité de deux variables pourrait donc ressembler à ceci :
var1 == var2
"$var1" == "$var"
À noter, que la comparaison selon le type de variables se li dans le fichier check/<PAQUETAGE>.txt où ils ont été créés. Si l'une des deux variables est numérique, la comparaison se fait sur une base numérique, c'est-à-dire que les chaînes de caractère sont converties en nombres, puis comparées. La comparaison est fondée par une chaîne, si on compare "05" == "5" cela donne un résultat «faux», une comparaison "18" < "9" donne «vrai» selon l'ordre lexicographique des chaînes de caractère : le chiffre گ» précède le chiffre ڷ» dans le jeu de caractères ASCII.
Pour introduire la comparaison des numéros de version de construction vous devez utiliser numeric(version), cela génère la valeur numérique du numéro de version à des fins de comparaison. Ici on applique :
numeric(version) := major * 10000 + minor * 1000 + sub
«major» représente la première partie, «minor» la deuxième partie et «sub» la troisième partie du numéro de version. Si «sub» est manquant le nombre dans l'addition ci-dessus sera omis (en d'autres termes «sub» sera égale à zéro).
Vous trouverez dans le tableau 8.3 une liste complète de toutes les expressions. «val» indique une valeur de n'importe quel type, «number» une valeur numérique et «string» une chaîne de caractère.
| expression | vraie si |
| id | id == «yes» |
| val == val | valeurs de type identique sont égaux |
| val != val | valeurs de type identique sont inégaux |
| val == number | numérique la valeur de val == nombre |
| val != number | numérique la valeur de val != nombre |
| val < number | numérique la valeur de val < number |
| val > number | numérique la valeur de val > number |
| val == version | numeric(val) == numeric(version) |
| val < version | numeric(val) < numeric(version) |
| val > version | numeric(val) > numeric(version) |
val =~ string |
val correspond à une chaîne expression régulière |
| ( expr ) | l'expression entre les parenthèses est vraie |
| expr && expr | les deux expressions sont vraies |
| expr || expr | au moins une des deux expressions est vraie |
| copy_pending(id) | voir la description ci-dessous |
| samenet (string1, string2) | chaîne1 décrit le même réseau que la chaîne2 |
| subnet (string1, string2) | chaîne1 décrit un sous-réseau de chaîne2 |
Avec l'opérateur-match =~ vous pouvez vérifier, si une expression
régulière correspond à la valeur d'une variable. En outre,
l'opérateur peut également l’utiliser pour extraire une partie de l’expression
de la variable. Après avoir appliqué avec succès une expression régulière à
une variable, une table MATCH_% contiendra toutes les parties trouvées de
la variable. Cela pourrait par exemple ressembler à ceci :
set foo="foobar12"
if ( foo =~ "(foo)(bar)([0-9]*)" )
then
foreach i in match_%
do
warning "match %i: $i"
done
fi
Après une exécution de mkfli4l, cela conduira vers la sortie suivante :
Warning: match MATCH_1: foo
Warning: match MATCH_2: bar
Warning: match MATCH_3: 12
Lors de l'utilisation de =~ on peut faire référence à toutes les expressions
régulières existantes. Si l'on veut par exemple vérifier, si le pilote de la carte
Ethernet-PCMCIA a été sélectionné, sans que la variable OPT_PCMCIA soit sur le
paramétrée sur «yes», vous pouvez écrire :
if (!opt_pcmcia)
then
foreach i in net_drv_%
do
if (i =~ "^(RE:PCMCIA_NET_DRV)$")
then
error "If you want to use ..."
fi
done
fi
Comme démontré dans l'exemple, il est important d'ancrer l'expression régulière avec ˆ et $, si vous avez l'intention d'appliquer une expression dans la variable entière. Sinon, l'expression renvoi une valeur «vrai» si une partie de la variable est couverte par l'expression régulière, ce qui n'est certainement pas souhaitable dans ce cas.
Avec le processus de vérification copy_pending vous pouvez vérifier si le fichier a été copié ou non en fonction de la valeur d'une variable. On peut l’utiliser, par exemple pour tester un pilote spécifié par l'utilisateur, pour savoir s’il existe bien et s’il a bien été copié. copy_pending accepte les noms à tester, sous forme d'une variable ou d'une chaîne. 8.5 copy_pending vérifie si
la fonction copy_pending renverra «vrai», s'il ne détecte emphpas le fichier a copier lors de la dernière étape, le processus de copie sera donc (encore en «attente»).
Vous pouvez trouver un petit exemple de l'utilisation de toutes ces fonctions dans le fichier check/base.ext :
foreach i in net_drv_%
do
if (copy_pending("%i"))
then
error "No network driver found for %i='$i', check config/base.txt"
fi
done
Tous les éléments de la liste NET_DRV_% seront détectés pour lesquelles aucune copie n'a été faite car il n'existe pas de configuration correspondante dans le fichier opt/base.txt.
Pour vérifier la communication entre les réseaux, nous avons besoin d'un test, pour savoir si les deux réseaux sont identiques ou si l'un des deux est un sous-réseau donc différent. Pour cela, vous avez deux fonctions samenet et subnet qui vous permez de vérifier le réseau.
samenet (netz1, netz2)
Le retour est «vrai», si les deux réseaux sont identiques, et
subnet (netz1, netz2)
Le retour est «vrai», si «netz1» est un sous-réseau de «netz2».
Obligatoire pour certain OPT, elle est utilisée pour rajouter d'autres paramètres dans le Kernel lors du Boot, on peut contrôler la variable KERNEL_BOOT_OPTION, pour savoir si les valeurs ont bien été incluses et au cas échéant un message d'avertissement ou d'erreur sera envoyé. Maintenant avec la variable interne KERNEL_BOOT_OPTION_EXT vous pouvez ajouter une option nécessaire mais manquante directement dans le script-ext. Un exemple tiré du fichier check/base.ext :
if (powermanagement =~ "apm.*|none")
then
if ( ! kernel_boot_option =~ "acpi=off")
then
set kernel_boot_option_ext="${kernel_boot_option_ext} acpi=off"
fi
fi
Le paramétre «acpi=off» sera transmis au Kernel si aucune gestion d'alimentation ou aucun type «d'APM» n'est nécessaire.
Les différents choix de version du Kernel se distinguent souvent de quelques détails :
Ces différences sont en grande partie traitées automatiquement par mkfli4l. Pour définir ces modules disponibles, vous pouvez d’une part, les tester et examiner en fonction de la version les (expressions régulières conditionnelles) d'autre part, cela vous permez avec mkfli4l d'utilisée le fichier opt/<PAQUETAGE>.txt selon la version utilisée. ils seront ensuite renommés avec un tiret bas opt/<PAQUETAGE>_<Kernel-Version>.txt, ainsi, les composants selon la version du Kernel seront séparés les uns des autres. Le fichier du paquetage «base» sera dans le répertoire opt :
Le premier fichier (base.txt) est toujours traité. Les deux autres
fichiers sont traités si la version du Kernel ڱ.16(.*)» ou ڱ.17(.*)» est utilisée. Comme
on peut le voir, certaines parties de la version peuvent être omis dans le nom du
fichier, si vous avez un groupe de Kernels les numéros de version seront «écrasés».
En supposant que l'on utilise la VERSION_KERNEL='3.16.41' les fichiers suivants
(si existant) seront lues et traitées pour plusieurs installation :
Les fichiers de la documentation sont placés dans
Les fichiers HTML peuvent également être divisés, c'est-à-dire être inclus dans chaque OPT différent. Il faut tout de même qu'un <PAQUETAGE>.html, soit le fichier référent pour tous les autres. Les modifications d'un paquetage doivent être documentées dans l'un des fichiers suivants :
L'ensemble de la documentation, ne doit pas contenir des tabulateurs et doit contenir un maximum de 79 caractères après un retour à la ligne. Vous devez vous assurer que la documentation pourra être lue correctement avec un éditeur sans retour de ligne automatique.
La documentation peut être produit dans le format LATEX et ensuite être transformé en format HTML et PDF. À titre d'exemple, cette documentation peut servir à fli4l. Dans la documentation qui se trouver dans le paquetage «template» traite du minimum requis pour les Macros-LATEX. Vous pouvez voir une brève description générale dans les paragraphes suivantes.
La documentation de fli4l est actuellement disponible dans les langues suivantes : allemande, anglaise (<LANGUE> = «english») et française (<LANGUE> = «french»). C'est le responsable du paquetage qui prend la décision pour documenter son paquetage dans n'importe quelle langue. Pour plus de clarté, il est recommandé de créer une documentation en allemand et/ou en anglais (idéalement dans les deux langues).
Pour créer des documents à partir des sources-LATEX, vous avez certaines exigences à respecter relatives à l'environnement :
Les fichiers de la documentation sont désignés selon le schéma suivant :
Ces fichiers sont stockés dans le répertoire fli4l/<PAQUETAGE>/doc/<LANGUE>/tex/<PAQUETAGE>. Vous pouvez voir ci-dessous un exemple du paquetage «sshd» :
$ ls fli4l/doc/deutsch/tex/sshd/
Makefile sshd_appendix.tex sshd_main.tex sshd.tex
Makefile est chargé de générer la documentation, le fichier sshd.tex fournir la structure pour la documentation actuelle et son annexe, qui est situé dans les deux autres fichiers. Vous pouvez consulter des exemples dans la documentation du paquetage «template».
LATEX fonctionne un peu comme HTML «orienté balise», seulement les balises
sont appelées ici «commandes», le format est le suivant : \commande
ou \begin{environnement} ... \end{environnement}.
Dans la mesure du possible, vous devez utiliser ces commandes qui accentu l'importance du texte et moins sa présentation. Il est donc avantageux de les utiliser par exemple.
\warning{ne fait ... pas}
Au lieu d'utiliser
\emph{ne fait ... pas}
cette commande.
Chaque commande ou environnement peut absorber plusieurs paramètres
supplémentaires, on peut écrire \commande{paramètre1}{paramètre2}{paramètreN}.
Certaines commandes ont des paramètres optionnels (au lieu des accolades) pour fermer
la commande vous utilisez les crochets : \kommando[optionalerParameter]{parameter1}
... Habituellement, un seul paramètre optionnel est utilisé, dans des cas plus
rares, il peut y en avoir plus.
Dans le document, certains paragraphes sont séparés par des lignes blanches. LATEX gardera ces sauts de ligne pour séparés les paragraphes dans le texte.
Les caractères suivants ont une signification spéciale dans LATEX ils
doivent être précédé du caractère dans le texte pour être écrit normalement :
# $ & _ % { }. Le caractère «~» et «^», doit
être écrit comme ceci : \verb?~? \verb?^?.
Les principales commandes LATEX sont expliquées dans la documentation du paquetage «template».
Dans le paquetage tous les fichiers texte (la documentation et les scripts d’installation qui sont sur le routeur) doivent être placés au format DOS, c'est à dire avec un CR/LF au lieu d'un simplement fin de ligne LF. Cela garantit que les utilisateurs Windows pourront également lire la documentation avec «Notepad» (ou bloc-notes), et pourront modifier les scripts sous Windows, ensuite ils seront toujours susceptibles de fonctionner sur le routeur. Les Scriptes sont convertis à la construction des archives dans le format utilisé par le routeur (voir la description des flags dans le tableau 8.2).
Si vous devez définir un programme pour une nouvelle interface, à partir d'un paquetage et qui sera utilisé par d'autres programmes, la documentation de cette interface, sera séparée du reste de la documentation et se trouvera dans doc/dev/<PAQUETAGE>.txt.
Si vous ajoutez un programme-client pour un paquetage supplémentaire, il sera placé dans le répertoire windows/ pour les clients-Windows et dans le répertoire unix/ pour les clients-Unix et Linux.
Les Programmes personnalisés et les codes sources peuvent être récupéré dans le répertoire src/<PACKAGE>/. Le programme peut être construit comme le programme-fli4l, merci de jeter un œil à la documentation du paquetage «src».
Tous les fichiers stockés sur le routeur sont dans les répertoires opt/etc/ et dans opt/files/. Voici une description :
Les scripts dans opt/etc/boot.d/, opt/etc/rc.d/ et opt/etc/rc0.d/ sont nommés de façon suivante :
rc<numéro>.<nom>
Le numéro détermine l'ordre d'exécution de l’installation, le nom donne une indication, pour quel programme/paquetage le script est traité.