Forums d'entraide informatique - Astuces - Conseils

Nous pouvons maintenant nous attaquer à la partie la plus intéressante. Voici les quelques scripts dont nous aurons besoin
•    mountall : Suite au démarrage du noyau, le système de fichiers racine est monté. C'est ce qui permet le démarrage d' i ni t.Cependant, il l'est en lecture seule et nous devons le remonter en lecture/écriture. Parallèlement, pour que le système soit utilisable, il nous faut monter le pseudo système de fichier /proc
#!/bin/sh PATH=/sbin:/bin
echo "Remounting FS rw" /bin/mount -w -n -oremount /
echo "Oeleting mtab" /bin/rm -f /etc/mtab echo "Mounting PROCFS" /bin/mount /proc
Nous créons / etc / cS . d et plaçons un lien symbolique SlOrnounta 1 1 pointant sur /etc/i ni t .d /mounta 1 1 .Remarquez que le fichier pointé n'existe pas sur le système hôte, mais sera parfaitement valide sur le système cible démarré. N'oubliez pas de créer / p ro c.
Puisque nous en sommes au montage des systèmes de fichiers, profitons-en pour ajouter un /etc / f st a b correct à la cible
/dev/hdal /    ext2 errorszremount-ro 0 1
proc    /proc proc defaults    00
•    keyshel 1 est le script qui va nous permettre de « parler » avec le système
#!/bin/sh PATH=/sbin:/bin
echo "Loading Keyboard'
loadkeys /etc/boottime.kmap.gz HOME=/root
USER=root
export HOME USER
cd SHOME
echo "Starting Shell"
/bin/sh
Comme nous n'avons pas l'intention de nous compliquer la vie, nous chargeons un mappage français pour le clavier. Nous récupérons tout simplement le fichier correspondant sur le système hôte (/etc/consol e/bootti me . kmap. gz) et le copions dans /etc sur système cible. Si votre Debian est correctement configurée, tout est parfait. Dans le cas contraire, i nstal 1 -keymap est votre ami. Pour charger le clavier, nous avons besoin de 1 oad key s. Nous copions le binairé depuis /bi n et n'oublions pas de copier les bibliothèques avec mid bs - copy. Créons les répertoires n!kessaires et ajoutons le lien
% cd /ifint/CF16/etc
% mkdir rd.d rcl.d rc2.d rc3.d \
rc4.d rc5.d rc6.d ../root
% cd rc2.d
% ln -s /etc/init.d/keyshell S2Okeyshel1
•    ,..mount. Pour que le système s'arrête prOprement, nous devons démonter les systèmes de fichiers et remonter, en lecture seule, ceux en cours d'utilisation. Le script est très simple :
/bin/sh
PATH./sbin:/bin
echo "Umounting ALL"
umount -f -a -r
echo "Remouting / RO" mount -n -o remount,ro /
Cette fois, le lien symbolique sera dans /etc/rc0.d et se nommera S60umount.
•    riait est encore plus simple que le script précédent puisqu'il ne fait qu'afficher un message. En fonction du matériel, il sera possible de provoquer un véritable arrêt du système en exécutant un binaire pilotant l'alimentation (ATX ou via un montage à relais). Pour l'heure, nous nous en tenons au simple message
#! /bin/sh PATH./sbin:/bin
echo "SYSTEM DOWN."
Le lien symbolique trouve sa place dans rc0 . d et s'appellera S9Ohalt afin d'être lancé après S60umount.
4.DEVENIR ACCESSIBLE
4.1 SUPPORT RÉSEAU
Notre plate-forme d'expérimentation dispose d'une carte compatible NE2000 sur bus ISA. Cela tombe plutôt bien puisque Bochs est en mesure d'émuler ce type de carte.
Bien entendu, les explications qui vont suivre sont, pour la plupart, valables pour tous types d'interfaces réseau supportées par le noyau. Les expérimentations se feront via l'émulation NE2000, puis il suffira de changer le module à charger au démarrage.
Pour ajouter une interface NE2000 dans la configuration de Bochs, il suffit d'ajouter dans votre . bochsrc une ligne comme (nous la réviserons par la suite) :
rnr 1
beot
:no I
nolrvel.
krobo.,o
.rtc,bont    Ionn
ion SbeI I
job control
in, In
"lit A
"aditthIng to railleur "...mi    prorts,e, (h,
,t
•    Ihorount in.) Ail.
in Ithi
▪    enel
Figure 5

x86
ne2k: ioaddr=0x340, irq=9, mac=b0:c4:20:00:00:00, ethmod=null
Le reste se passe dans la configuration du système cible. Plutôt que de placer directement le chargement du module dans un script, nous allons utiliser, comme avec le système hôte, un fichier /etc/modules. Notre script d' i ni t ressemblera donc à ceci :
#! /bin/sh PATH=/sbin:/bin
echo "Loading modules:"
(cat /etc/modules; echo) I # add LF
while read module args do
case Imodule" in
\#*I"") continue ;;
esac
echo Imodule ($args)" modprobe $module $args done
Nous ajoutons dans /et c/ rcS . d un lien S1 2modu 1 es pointant vers /etc/i ni t .d/modul es. Je pars ici du principe que le support de l'interface réseau, au niveau matériel, est intéressant pour tous les niveaux d'exécution, d'où le lancement du script depuis rcS . d.11 ne nous reste plus, ensuite, qu'à ajouter notre fichier listant les modules à charger, contenant une simple ligne ne i o=0x340. Nous ajoutons également les binaires permettant de gérer les modules du noyau :
% cp modprobe insmod insmod.modutils \ rmmod /ifint/CF16/sbin/
% ln -s insmod.modutils modprobe.modutils % ln -s insmod.modutils rmmod.modutils
Les versions . modut i 1 s sont ici par souci de compatibilité. En effet, le noyau du système cible étant un 2.4 nous profitons largement de cette astuce puisque les commandes sont extraites d'un système basé sur un 2.6. Nous pourrons ensuite basculer vers un 2.6 avec un minimum de modifications sur la cible.
A présent que l'interface est prise en charge, il nous reste à la configurer. On trouve habituellement dans les systèmes embarqués des scripts de configuration souvent trop rigides utilisant i fconfi g et route directement. Ici, nous allons piocher dans le système hôte pour arriver à une solution légère et efficace.
Commençons donc par créer l'arborescence nécessaire et typique de Debian sur le système cible :
% mkdir /mnt/CF16/etc/network % cd /mnt/CF16/etc/network
% mkdir if-down.d if-post-down.d \ if-pre-up.d if-up.d
Il ne reste ensuite qu'à créer le fichier de configuration classique /etc/network/interfaces contenant, par exemple :
address 192.168.1.122 netmask 255.255.255.0 network 192.168.1.0 broadcast 192.168.1.255 gateway 192.168.1.10
Ce fichier de configuration est utilisé par les commandes fup et i fdown.11 convient donc de les copier sur le système cible, dans le répertoire /sbin. Ce n'est qu'alors que nous pouvons nous pencher sur le script cri ni t, /etc/ init. d/networki ng. Celui-ci reposera sur le modèle des scripts Debian (en version simplifiée) :
#! /bin/sh PATN=/sbin:/bin
case "$1" in
start)
echo "Networking start" ifup -a
stop)
echo "Networking stop" ifdown -a
*)
echo "Usage: /etc/init.d/network {startIstop}" exit 1
esac
Cette fois, nous ajouterons, dans rc2 .d,un lien pointant sur le script que nous venons d'ajouter, appelé S15networking permettant de configurer l'interface avant le lancement d'un shell. Un second lien sera placé dans rc0 . d sous le nom KO 9 networki ng permettant de « déconfigurer » l'interface. Avant démarrage de Bochs, nous créons /et c/networ k/ run dont i fup et i fdown ont besoin pour gérer le fichier i f state indiquant l'état des interfaces.
Vous pouvez d'ores et déjà lancer Bochs pour constater le bon fonctionnement des scripts et des commandes utilisées. Un i fconf i g une fois le système cible démarré devrait correctement lister les interfaces 10 et et h0.
Mais nous devons correctement configurer Bochs afin d'obtenir un fonctionnement réseau réellement fonctionnel. Il existe plusieurs manières de procéder. Je choisirai ici la plus classique et celle permettant de faire le plus de tests par la suite :TUN/TAR Le principe consiste à créer une nouvelle interface virtuelle sur l'hôte qui sera reliée à l'interface émulée par Bochs.Avant toutes choses, chargez le module t un (en particulier sur vous utilisez udev).
Nous modifions ensuite la configuration présente dans le .bochsrc comme suit (sur une ligne) :
e2k: ioaddr.8041, irq=9, mac=b0:c4:28:00:00:00, ethmod=tuntap, ethdey=/dey/net/tun,
script=/mnt/six2/tunconfig
auto 10
iface lo inet loopback
auto eth0
iface eth0 inet static
La partie importante réside dans le script de configuration de l'interface virtuelle /mnt/si x2/tunconfi g :
#1/bin/bash
/sbin/ifconfig ${1##/*/} 192.168.1.10

Ceci nous permettra de créer automatiquement l'interface via le démarrage de Bochs. Dernière étape pour fournir à notre système cible un accès vers le reste du monde, nous mettons en place un masquerading avec i ptabl es
% iptables -t flot -A POSTROUTING \
-s 192.168.1.0/24 -d ! 192.168.1.0/24 \ -j MASOUERADE
% sysctl -w net.ipv4.ip_forward=1
Dès lors, notre système cible peut pinguer l'hôte et le reste du monde, mais on peut également accéder au système cible depuis l'hôte. Ceci nous permet de passer à la suite.
4.2 INSTALLATION DE SERVICES
Le shell lancé en fin d'initialisation n'est pas une solution définitive. En effet, cela n'est utile que pour les premiers tests, mais dans un environnement de production, il conviendra de lancer un getty appelant 1 og i n qui, après authentification, lancera un shell.Une telle infrastructure risque d'occuper de la place pour rien sur un système embarqué. La plate-forme n'est pas destinée à s'équiper d'une console (écran/clavier). On préférera habituellement un accès via le réseau ou un port série dédié à cet usage.
Voilà donc l'occasion rêvée de pousser plus loin la configuration. Nous allons ajouter un accès Telnet à notre système cible. Pour ce faire, nous utiliserons le super serveur Xinetd en lieu et place de l'habituel Inetd. Comme précédemment, nous commençons par utiliser cp et mk1 I bs -copy pour ajouter le binaire xi netd dans /mnt/CF16/sbi n et les bibliothèques dans /mnt/CF16/1 b.
Xinetd utilise une configuration stockée dans /etcixi netd. conf pour tout ce qui est global et parcourt ensuite (via une ligne dans la configuration) le répertoire /etc/xi netd . d à la recherche de fichiers de configuration spécifiques aux services.
Nous créons donc le fichier de configuration principal contenant simplement
defaults
1
includedi r /etc/xi netd.d
Dans le répertoire /etc/xi netd .d,nous ajoutons un fichier dayti me permettant de faire les premiers tests. Celui-ci contiendra :
service daytime
di sable = no
type    = INTERNAL
Id    = daytime-stream
socket_type    = stream
protocol    = tcp
user    =
wait    = no
Enfin, nous pouvons créer notre script d' i ni t.Nous gérerons les arguments st art et stop et nous lancerons le serveur via st a rt - s top - d a emon (à copier sur le système cible)
#! /bin/sh PATH=/sbin:/bin
case 11" in
start)
echo "Superserver start" start-stop-daemon --start --quiet \
--exec /sbin/xinetd \
-pidfi le /var/run/xinetd.pi
•    •
,
stop)
echo "Superserver stop"
start-stop-daemon --stop --quiet --oknodo \ --pidfile /var/run/xinetd.pid \
--exec /sbin/xinetd
echo "Usage: /etc/init.d/inetd {startIstop}" exit 1
esac
Pour compléter l'ensemble, nous créons /va r / n. sur le système cible. start-stop-daemon nous permet de lancer des processus « démons » de manière unique et' Simplifiée. Pour le démarrage du super serveur, nous demandons .à xi netd lui-même de créer un fichier contenant son PID. Pour arrêter le service, s ta rt - stop-daemon réutilisera le contenu de ce fichier pour tuer le processus.
Nous ajoutons également un certain nombre de fichiers classiques pour les systèmes GNU/Linux. Certains sont
adaptés en fonction de la simplicité du système cible
• /etc/hosts
é /etc/passwd (permissions 644) é /etc/passwd - (permissions 600) é /etc/shadow (permissions 640) é /etc/shadow- (permissions 600) é /etc/g roup (permissions 644) é /etc/group- (permissions 600)
/etc/hostname
On ajoutera à cette occasion la ligne hostname -F /etc/ hostname dans le script Jetc,,i nit . d/networki ng, juste après l'appel à i fup. D'autres fichiers sont simplement copiés depuis le système hôte
•    /etc/rpc
é    /etc/services
é/etc/protocols
•    /etcasswitch.conf
Ce dernier fichier est important. Il s'agit de la configuration utilisée par le système NSS (Nome Service Switch) GNU. Ce fichier est nécessaire, tout autant que les bibliothèques / 1 i b/l ibnss* qui devront être copiées sur le système cible. Ces bibliothèques contiennent les fonctions permettant la lecture des différentes sources de configuration. La fonction getprotobyname de la libc GNU par exemple, semble lire directement /etc/protocol s (dixit la manpage) mais, fait en réalité appel à NSS (chose absolument invisible pour mk1 I bs-copy). NSS est d'ailleurs un sujet qui mériterait un article complet par ailleurs.

                   
                   
    x86               
                   
II ne reste maintenant plus qu'à créer les liens permettant le démarrage et l'arrêt automatique du super serveur :S1 7xi netd dans rc 2 . d et K09networking dans rcS . d. Le système est maintenant prêt pour un test simpliste :une connexion Telnet sur le port 13 depuis le système hôte :
% teinet 192.168.1.122 13 Trying 192.168.1.122... Connected to 192.168.1.122. Escape character is "P.
28 MAR 2006 1 5 : 29: 19 UTC
Connection closed by foreign host.
Embrayons joyeusement sur la suite en ajoutant Telnet avec le duo cp/mkl i bs-copy. Le binaire utilisé est celui fourni par le paquet i n et ut i 1 s-telnetd. Nous ajoutons un fichier tel net dans le /etc/xi netd. d de la cible :
service tel net
disable    no
protocol    tcp
socket_type    stream
user
wait    no
server    /sbin/telnetd
1
Nous n'avons presque plus besoin de notre shell lancé depuis le script key s he 1 1.A présent, le système est accessible depuis le port 22. A ce stade, nous avons un système fonctionnel minimal communicant, le tout pour environ 5.2 Mo. Il reste presque les deux tiers de la capacité de la carte CF pour les applications.
4.3 UNE CONSOLE SÉRIE
Lorsqu'on parle d'embarqué, il est rare de prévoir écran et clavier à proximité du système. Ici, bien qu'il s'agisse d'une carte mère PC standard, et donc d'une taille conséquente, nous souhaitons également nous passer de ces périphériques. La liaison Telnet offre déjà un accès au système cible, mais un problème réseau est vite arrivé. Il nous faut une solution de secours.
Pas de miracle ou d'extravagance ici, la solution la plus simple est d'utiliser l'un des ports série de la future machine cible en guise de console. Ce choix est parfaitement justifié, mais pas innocent. En effet, l'émulation d'un port série par Bochs fait partie de l'aspect didactique de cette section.A l'instar de l'émulation d'une interface réseau, il existe plusieurs méthodes permettant de donner accès à un port série. Nous allons utiliser ici un TTY (PTS) en guise de port ou plus exactement en guise d'un des côtés d'un pseudo câble null-modem.
Pour ce faire, ouvrez un terminal (Xterm ou autre) non loin de celui d'où vous lancez Bochs et identifiez le TTY avec la commande, bien nommée, t ty. Ici, se sera ï de v pt s/4. Dans la configuration de Bochs, ajoutez une ligne :
coml: enabled=1, mode.term, dev./dev/pts/4
Dès le prochain démarrage de Bochs, tout ce qui part depuis le système cible sur le premier port série (ttyS0 sous GNU/Linux) arrivera dans le terminal identifié par / d ev/pt s /4.0n prendra soin de lancer une commande type sl eep 500000 sur le terminal en question pour éviter que le shell ne s'en mêle.
Côté système cible, nous n'avons plus qu'à copier g et ty dans Isbi n, puis à modifier notre / et ch ni ttab en ajoutant :
T0:23:respawn:/sbin/getty 38400 ttyS0 linux
Ceci aura pour effet d'être à l'écoute des connexions sur ttyS0 et, au besoin, de lancer 1 ogi n gracieusement fourni par Busybox. Puisque nous en sommes à ajouter g etty, profitons-en pour nous débarrasser de l'appel au shell depuis un script d'i ni t et ajoutons :
1:2345:respawn:/sbin/getty 38400 ttyl
Dans /etc/i ni t .d/keyshel 1, nous ne conservons que le chargement du mappage clavier avec 1 oadkeys.Nousobtenons ainsi un système parfaitement « normal ».
CONCLUSION
ENCORE DU TRAVAIL...
Tout cela constitue une simple base de travail. Beaucoup de choses peuvent ou doivent être ajoutées.Voici quelques exemples :
•    Standardiser les scripts d'i ni t.
•    Le démarrage/montage/démontage du système est pour l'instant géré de manière barbare. Un certain nombre de vérifications et de nettoyages (i fstate ou xi netd . pi d) sont nécessaires après un arrêt brutal du système.
•    Étant donné le volume de mémoire à notre disposition, il est possible d'envisager d'utiliser un système de fichiers tmpfs pour /tmp et /var.
♦    En fonction du type d'application visé, il pourra être nécessaire d'installer un sysl og ou sysl og-ng.
•    Un serveur Web à faible empreinte mémoire comme Boa
ou Thttpd pourrait faire office d'interface utilisateur.
♦    Il est possible d'étendre le système ou de le cloner, de manière à ce que GRUB, en cas de problème puisse démarrer sur une autre carte CF.
•    Un système de watchdog pourra être ajouté, permettant, en cas de blocage, de redémarrer le système.
Ensuite, l'étendue des possibilités n'est limitée que par votre imagination et le matériel à votre disposition. Notez que la construction d'un système comme celui-ci est également possible pour une cible non-x86. Cela nécessitera la recompilation des binaires, mais vous apportera la maîtrise de l'ensemble. C'est une question de temps. Pour conclure, je tiens à remercier Pierre Ficheux pour les explications données dans son livre Linux embarqué et basées sur la distribution Red Hat. Celles-ci ont été le déclencheur des premières expérimentations sous le motif, certes douteux, de « faire pareil avec Debian ».
Enfin, je signalerais que deux images sont disponibles dès à présent sur http:llwww.gnulinuxmag.com/pubJLM_HS/HS25. sda . i mg . bz2 contient l'intégralité des données de la carte CF (16 Mo) et sda 1 . i mg . bz2 est l'image de la partition qu'il est possible de directement monter. Libre à vous de les réutiliser comme base de travail ou pour simplement vérifier des points restés obscurs dans les explications précédentes.