«« sommaire »»

IV.2 – Configuration des utilitaires système

Christophe BLAESS - janvier 2020

Dans la séquence précédente, nous avons configuré le réseau à notre convenance. Toutefois, un problème persiste avec le Raspberry Pi…

Gestion de l'heure système

Mon Raspberry Pi a démarré depuis près d'une heure, comme l'indique la commande «uptime» :

root@mybox:/tmp# uptime
08:45:25 up 51 min,  1 user,  load average: 0.00, 0.00, 0.00 

Je consulte l'heure du système avec la commande «date» :

root@mybox:/tmp# date
Fri Jan  3 08:46:40 UTC 2020
root@mybox:/tmp# 

L'heure est correcte à quelques minutes près. Je décide alors de redémarrer mon Raspberry Pi :

root@mybox:/tmp# reboot

Broadcast message from root@mybox (ttyS0) (Fri Jan  3 08:47:41 2020):

The system is going down for reboot NOW!

Puis, une fois le redémarrage terminé, je consulte à nouveau l'heure système :

Poky (Yocto Project Reference Distro) 3.0.1 mybox ttyS0

mybox login: root
Password: (linux)
root@mybox:~# date
Fri Jan  3 07:54:02 UTC 2020
root@mybox:~# 

Surprise ! Nous avons voyagé dans le temps et sommes revenus près d'une heure en arrière…

Le Raspberry Pi n'a pas de composant RTC (Real Time Clock) pour maintenir l'heure lorsqu'il est éteint. Aussi au démarrage le système est-il à l'heure zéro d'Unix (aussi appelée l'«epoch») : le premier janvier 1970 à 00:00:00 UTC.

Outre le fait qu'un système évoluant en janvier 1970 paraît un peu ridicule à l'utilisateur, des problèmes peuvent se poser avec certains protocoles réseaux par exemple qui ne veulent pas accepter de certificats générés dans le lointain futur. Aussi, Yocto s'arrange-t-il pour que l'heure système soit initialisée avec une valeur réaliste : celle de production de l'image, qu'il a inscrite dans le fichier /etc/timestamp sous forme «année, mois, jour, heure, minute, seconde» juxtaposés :

root@mybox:~# cat  /etc/timestamp 
20200103075346

L'inconvénient est qu'à chaque redémarrage le système reprend à la même heure, et qu'au fil du temps on s'éloigne de plus en plus de l'heure réelle. On préfèrerait une mise à l'heure automatique à partir du réseau. Pour cela il existe des serveurs NTP (Network Time Protocol) disponibles librement, il nous faut simplement un programme client ntpd pour les interroger.

root@mybox:~# ntpd
-sh: ntpd: command not found

Sur les systèmes embarqué, le client ntpd fait partie du package busybox, mais il n'a pas été intégré dans sa configuration. À nous de l'ajouter…

Configuration de Busybox

Busybox est un projet assez incontournable dans les systèmes restreints. Il est d'ailleurs surnommés «le couteau suisse de l'embarqué»…

Il s'agit d'un unique exécutable qui adapte son comportement en fonction du nom sous lequel il a été appelé. Cet exécutable implémente plus de 400 commandes Linux courantes (on choisit la liste des commandes à la configuration avant compilation), et des liens symboliques permettent de l'invoquer avec des noms différents. Lorsqu'on appelle busybox sans aucun argument il nous affiche la liste des commandes qu'il implémente :

root@mybox:~# busybox
BusyBox v1.31.0 (2019-12-26 11:35:27 UTC) multi-call binary.
BusyBox is copyrighted by many authors between 1998-2015.
Licensed under GPLv2. See source distribution for detailed
copyright notices.

Usage: busybox [function [arguments]...]
   or: busybox --list
   or: function [arguments]...

        BusyBox is a multi-call binary that combines many common Unix
        utilities into a single executable.  Most people will create a
        link to busybox for each function they wish to use and BusyBox
        will act like whatever it was invoked as.

Currently defined functions:
        [, [[, addgroup, adduser, ash, awk, basename, blkid, bunzip2, bzcat, bzip2, cat, chattr, chgrp,
        chmod, chown, chroot, chvt, clear, cmp, cp, cpio, cut, date, dc, dd, deallocvt, delgroup,
        deluser, depmod, df, diff, dirname, dmesg, dnsdomainname, du, dumpkmap, dumpleases, echo, egrep,
        env, expr, false, fbset, fdisk, fgrep, find, flock, free, fsck, fstrim, fuser, getopt, getty,
        grep, groups, gunzip, gzip, head, hexdump, hostname, hwclock, i2ctransfer, id, ifconfig, ifdown,
        ifup, insmod, ip, kill, killall, klogd, less, ln, loadfont, loadkmap, logger, logname, logread,
        losetup, ls, lsmod, lzcat, md5sum, mesg, microcom, mkdir, mkfifo, mknod, mkswap, mktemp,
        modprobe, more, mount, mountpoint, mv, nc, netstat, nohup, nproc, nslookup, od, openvt, patch,
        pidof, pivot_root, printf, ps, pwd, rdate, readlink, realpath, reboot, renice, reset, resize,
        rfkill, rm, rmdir, rmmod, route, run-parts, sed, seq, setconsole, setsid, sh, sha1sum, sha256sum,
        shuf, sleep, sort, start-stop-daemon, stat, strings, stty, sulogin, swapoff, swapon, switch_root,
        sync, sysctl, syslogd, tail, tar, tee, telnet, test, tftp, time, top, touch, tr, true, ts, tty,
        udhcpc, udhcpd, umount, uname, uniq, unlink, unzip, uptime, users, usleep, vi, watch, wc, wget,
        which, who, whoami, xargs, xzcat, yes, zcat

Notre système est basé sur l'image «core-image-base» de Poky qui est assez complète, avec de nombreux packages, et le rôle de Busybox est relativement réduit. Si toutefois nous retournons sur l'image «core-image-minimal» que nous avons compilée dans la séquence I.3, nous voyons que Busybox est invoqué — par l'intermédiaire de liens symboliques — pour presque chaque appel de commande :

root@raspberrypi4:~# ls -l /bin/
lrwxrwxrwx    1 root     root            19 Dec 26 12:49 ash -> /bin/busybox.nosuid
lrwxrwxrwx    1 root     root            14 Dec 26 11:38 busybox -> busybox.nosuid
-rwxr-xr-x    1 root     root        476920 Dec 26 11:49 busybox.nosuid
-rwsr-xr-x    1 root     root         42440 Dec 26 11:49 busybox.suid
lrwxrwxrwx    1 root     root            19 Dec 26 12:49 cat -> /bin/busybox.nosuid
lrwxrwxrwx    1 root     root            19 Dec 26 12:49 chattr -> /bin/busybox.nosuid
lrwxrwxrwx    1 root     root            19 Dec 26 12:49 chgrp -> /bin/busybox.nosuid
lrwxrwxrwx    1 root     root            19 Dec 26 12:49 chmod -> /bin/busybox.nosuid
lrwxrwxrwx    1 root     root            19 Dec 26 12:49 chown -> /bin/busybox.nosuid
lrwxrwxrwx    1 root     root            19 Dec 26 12:49 cp -> /bin/busybox.nosuid
lrwxrwxrwx    1 root     root            19 Dec 26 12:49 cpio -> /bin/busybox.nosuid
lrwxrwxrwx    1 root     root            19 Dec 26 12:49 date -> /bin/busybox.nosuid
lrwxrwxrwx    1 root     root            19 Dec 26 12:49 dd -> /bin/busybox.nosuid
lrwxrwxrwx    1 root     root            19 Dec 26 12:49 df -> /bin/busybox.nosuid
lrwxrwxrwx    1 root     root            19 Dec 26 12:49 dmesg -> /bin/busybox.nosuid
lrwxrwxrwx    1 root     root            19 Dec 26 12:49 dnsdomainname -> /bin/busybox.nosuid
lrwxrwxrwx    1 root     root            19 Dec 26 12:49 dumpkmap -> /bin/busybox.nosuid
lrwxrwxrwx    1 root     root            19 Dec 26 12:49 echo -> /bin/busybox.nosuid
lrwxrwxrwx    1 root     root            19 Dec 26 12:49 egrep -> /bin/busybox.nosuid
lrwxrwxrwx    1 root     root            19 Dec 26 12:49 false -> /bin/busybox.nosuid
lrwxrwxrwx    1 root     root            19 Dec 26 12:49 fgrep -> /bin/busybox.nosuid
lrwxrwxrwx    1 root     root            19 Dec 26 12:49 getopt -> /bin/busybox.nosuid
lrwxrwxrwx    1 root     root            19 Dec 26 12:49 grep -> /bin/busybox.nosuid
lrwxrwxrwx    1 root     root            19 Dec 26 12:49 gunzip -> /bin/busybox.nosuid
lrwxrwxrwx    1 root     root            19 Dec 26 12:49 gzip -> /bin/busybox.nosuid
lrwxrwxrwx    1 root     root            19 Dec 26 12:49 hostname -> /bin/busybox.nosuid
lrwxrwxrwx    1 root     root            19 Dec 26 12:49 kill -> /bin/busybox.nosuid
lrwxrwxrwx    1 root     root            19 Dec 26 12:49 ln -> /bin/busybox.nosuid
lrwxrwxrwx    1 root     root            17 Dec 26 12:49 login -> /bin/busybox.suid
lrwxrwxrwx    1 root     root            19 Dec 26 12:49 ls -> /bin/busybox.nosuid
lrwxrwxrwx    1 root     root            19 Dec 26 12:49 mkdir -> /bin/busybox.nosuid

Le suffixe «.nosuid» signifie simplement que c'est une commande ne nécessitant pas de privilège particulier pour son exécution.

Busybox nous propose une implémentation du client ntpd qui n'avait pas été sélectionnée dans la configuration par défaut. Pour accéder à la configuration, nous pouvons exécuter la commande suivante dans notre répertoire de build :

[build-rpi]$ bitbake  -c menuconfig  busybox

Cette commande demande à bitbake d'exécuter l'étape menuconfig de la recette correspondant à busybox. Il s'agit d'un menu de configuration proposé par le Makefile de Busybox. En principe une nouvelle fenêtre s'ouvre (ou un nouvel onglet de terminal) avec le menu de configuration de la figure IV.2-1

Dans certaines circonstances (connexion à distance, etc.) l’écran de configuration peut refuser de s’afficher. Dans ce cas, on peut contourner le problème en remplissant dans le fichier conf/local.conf la variable OE_TERMINAL avec la valeur «screen».

Nous accédons au menu «Networking Utilities» pour activer l'utilitaire ntpd comme sur la figure IV.2-2

Avant de quitter la configuration nous validons la sauvegarde de la configuration modifiée comme sur la figure IV.2-3

La configuration de Busybox a été modifiée uniquement dans le sous-répertoire que Yocto utiise pour son build. Mais nous souhaitons pérenniser cette modification dans notre image. Nous devons appeler bitbake pour réaliser une étape particulière de la recette :

[build-rpi]$ bitbake  -c  diffconfig  busybox
  [...]
Config fragment has been dumped into:
 /home/cpb/Yocto-lab/build-rpi/tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/busybox/1.31.0-r0/fragment.cfg

Cette étape a priori un peu obscure demande à bitbake de créer un fragment de fichier de configuration qui regroupe les modifications par rapport à la configuration par dédaut de la recette. Le fragment se trouve dans le chemin indiqué en fin de commande.

Nous devons intégrer ce fragment dans une extension de recette pour Busybox dans notre layer. Pour nous aider l'outil recipetool que nous avons déjà rencontré lors de séquence II.3 va prendre le relais ainsi :

[build-rpi]$ recipetool  appendsrcfile  -w  ../meta-my-layer/  busybox  tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/busybox/1.31.0-r0/fragment.cfg
NOTE: Starting bitbake server...
Loading cache: 100% |######################################################################| Time: 0:00:00
Loaded 2252 entries from dependency cache.
NOTE: Writing append file /home/cpb/Yocto-lab/meta-my-layer/recipes-core/busybox/busybox_%.bbappend
NOTE: Copying tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-gnueabi/busybox/1.31.0-r0/fragment.cfg to /home/cpb/Yocto-lab/meta-my-layer/recipes-core/busybox/busybox/fragment.cfg
[build-rpi]$ 

On copie sur la ligne de commande de recipetool le chemin vers le fragment obtenu précédemment. Puis recipetool nous indique qu'il crée un fichier .bbappend et qu'il copie le fragment à l'endroit attendu par cette extension de recette.

Il nous reste à recompiler notre image. Nous effaçons la précédente compilation de Busybox d'abord pour éviter un warning de Yocto («do_compile is tainted from a forced run»).

[build-rpi]$ bitbake -c clean busybox
  [...]
[build-rpi]$ bitbake my-image

Après avoir recompilé et redémarré notre image, nous pouvons appeler ntpd implémenté par Busybox pour interroger le serveur de temps pool.ntp.org.

root@mybox:~# which  ntpd
/usr/sbin/ntpd
root@mybox:~# ls  -l  /usr/sbin/ntpd
lrwxrwxrwx 1 root root 19 Jan  3 12:51 /usr/sbin/ntpd -> /bin/busybox.nosuid
root@mybox:~# date
Fri Jan  3 12:54:38 UTC 2020
root@mybox:~# ntpd  -d  -n  -q  -p pool.ntp.org
ntpd: 'pool.ntp.org' is 51.15.182.163
ntpd: sending query to 51.15.182.163
ntpd: reply from 51.15.182.163: offset:+658.425551 delay:0.009482 status:0x24 strat:2 refid:0x42e6bec1 ro1
ntpd: sending query to 51.15.182.163
ntpd: reply from 51.15.182.163: offset:+658.425554 delay:0.009643 status:0x24 strat:2 refid:0x42e6bec1 ro3
ntpd: setting time to 2020-01-03 13:05:55.585718 (offset +658.425554s)
root@mybox:~# date
Fri Jan  3 13:05:58 UTC 2020
root@mybox:~#

Le système est maintenant à l'heure. Mais bien évidemment, au redémarrage…

root@mybox:~# reboot

Broadcast message from root@mybox (ttyS0) (Fri Jan  3 13:07:11 2020):
The system is going down for reboot NOW!
 [...]

Poky (Yocto Project Reference Distro) 3.0.1 mybox ttyS0

mybox login: root
Password: (linux)
root@mybox:~# date
Fri Jan  3 12:54:32 UTC 2020
root@mybox:~# 

Il faudrait que la mise à l'heure soit automatiquement réalisée au démarrage du système. C'est ce que nous allons écrire à présent.

Démarrage d'un service

Il existe sous Linux plusieurs mécanismes pour lancer une tâche au démarrage. Les plus connues sont «sysvinit» («System V Init») et «systemd». De nos jours la plupart des PC et des serveurs utilisent «systemd». Les systèmes embarqués quant à eux utilisent encore majoritairement «System V Init».

Yocto choisit par défaut «System V Init» mais nous offre la possibilité d'utiliser «systemd» si on le préfère en configurant une recette de distribution spécifique. Ceci est un peu compliqué pour le cadre de ce cours en ligne, aussi allons-nous conserver l'environnement «sysvinit».

Le processus «init» lancé automatiquement par le noyau au boot consulte le fichier /etc/inittab pour savoir comment agir. Ce fichier configure le runlevel du système (son niveau de fonctionnement) à la valeur 5. Puis lance successivement le script shell /etc/init.d/rcS suivi de tous les scripts se trouvant dans le répertoire /etc/rc5.d/ (le 5 correspondant au runlevel). Dans ce répertoire, on trouve :

root@mybox:~# ls  /etc/rc5.d/
S01networking  S12rpcbind      S20bluetooth     S22ofono         S99stop-bootlogd 
S02dbus-1      S15mountnfs.sh  S20syslog        S64neard
S10dropbear    S20apmd         S21avahi-daemon  S99rmnologin.sh

Les scripts présents commencent tous par la lettre «S» comme Start pour indiquer qu'ils sont lancés au démarrage du système, suivie d'un numéro d'ordre de démarrage. En réalité tous ces fichiers sont des liens symboliques vers des scripts se trouvant de /etc/init.d :

root@mybox:~# ls  -l  /etc/rc5.d/
total 0
lrwxrwxrwx 1 root root 20 Jan  3 12:51 S01networking -> ../init.d/networking
lrwxrwxrwx 1 root root 16 Jan  3 12:52 S02dbus-1 -> ../init.d/dbus-1
lrwxrwxrwx 1 root root 18 Jan  3 12:52 S10dropbear -> ../init.d/dropbear
lrwxrwxrwx 1 root root 17 Jan  3 12:52 S12rpcbind -> ../init.d/rpcbind
lrwxrwxrwx 1 root root 21 Dec 26 09:01 S15mountnfs.sh -> ../init.d/mountnfs.sh
lrwxrwxrwx 1 root root 14 Jan  3 12:51 S20apmd -> ../init.d/apmd
lrwxrwxrwx 1 root root 19 Jan  3 12:52 S20bluetooth -> ../init.d/bluetooth
lrwxrwxrwx 1 root root 16 Jan  3 12:52 S20syslog -> ../init.d/syslog
lrwxrwxrwx 1 root root 22 Jan  3 12:52 S21avahi-daemon -> ../init.d/avahi-daemon
lrwxrwxrwx 1 root root 15 Jan  3 12:52 S22ofono -> ../init.d/ofono
lrwxrwxrwx 1 root root 15 Jan  3 12:52 S64neard -> ../init.d/neard
lrwxrwxrwx 1 root root 22 Dec 26 09:01 S99rmnologin.sh -> ../init.d/rmnologin.sh
lrwxrwxrwx 1 root root 23 Dec 26 11:48 S99stop-bootlogd -> ../init.d/stop-bootlogd 

Les liens symboliques sont créés au moment de la préparation du système de fichiers en prenant en compte les runlevels auxquels les services doivent démarrer et les dépendances entre ces services.

Nous pouvons créer un script qui lance automatiquement ntpd avec le nom du serveur NTP en argument. Pour être intégré correctement dans le système de démarrage, le script doit débuter avec un en-tête précis :

#! /bin/sh
### BEGIN INIT INFO
# Provides:             ntpd
# Required-Start:       $networking
# Required-Stop:        
# Default-Start:        2 3 4 5
# Default-Stop:         1
# Short-Description:    Network Time Protocol client Daemon
### END INIT INFO
#

Cet en-tête indique le nom du service fourni par ce script (lignes «Provides» et «Short-Description»), la liste des services dont il a besoin pour démarrer, ce qui permet de les ordonner. Nous demandons seulement la présence de «networking». Enfin on indique les runlevels dans lesquels le script doit être démarré et ceux où il doit être arrêté. Les listes «2 3 4 5» d'une part et «1» se retrouvent dans la plupart des packages. On consultera les scripts de /etc/init.d/ pour avoir plus d'exemples.

C'est la classe «update-rc.d» fournie par Poky qui crée les liens en fonction des dépendances. Notre recette devra donc en hériter.

Le code permettant de lancer le service proprement dit vient à la suite de cet en-tête. On peut l'écrirer de différentes manières. La plus simple à mon avis est la suivante qui s'appuie sur la commande «start-stop-daemon» implémentée par Busybox :

do_start()
{
	start-stop-daemon --start --exec ntpd -- -p pool.ntp.org 
}

do_stop()
{
	start-stop-daemon --stop --name ntpd
}


case "$1" in
  start) do_start ;;
  stop)  do_stop  ;;
  restart) do_stop; do_start ;;
  *) echo "Usage: $0 {start|stop|restart}" >&2; exit 1 ;; 
esac

exit 0

Si notre script est appelé avec «start» en argument, il démarre le client NTP en enregistrant le numéro de processus (PID, Process IDentifier) dans un fichier. Par défaut start-stop-daemon le stocke dans /var/run/<nom-du-service>.pid. Si on appelle le script avec l'argument «stop», il arrête le client NTP en lui envoyant un signal (grâce au PID enregistré au démarrage).

Préparons un répertoire dans notre layer pour accueillir la recette et le script :

[build-rpi]$ mkdir  -p  ../meta-my-layer/recipes-custom/ntpd-start/files/ 

Dans le sous-répertoire files/ de ma recette, j'écris le script complet décrit ci-dessus.

[build-rpi]$ nano  ../meta-my-layer/recipes-custom/ntpd-start/files/ntpd 
   [...]

Puis je rédige la recette suivante qui hérite de la classe update-rc.d et copie le script dans le répertoire /etc/init.d/ de la cible en indiquant son nom dans la variable INITSCRIPT_NAME :

[build-rpi]$ nano  ../meta-my-layer/recipes-custom/ntpd-start/ntpd-start_1.0.bb

SUMMARY = "Script to start ntpd client service"
SECTION = "custom"

LICENSE = "MIT"
LIC_FILES_CHKSUM = "file://${COMMON_LICENSE_DIR}/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302" 

SRC_URI  = "file://ntpd"

inherit update-rc.d

INITSCRIPT_NAME = "ntpd"

do_install() {
  install -d ${D}${sysconfdir}
  install -d ${D}${sysconfdir}/init.d
  install -m 755 ${WORKDIR}/ntpd ${D}${sysconfdir}/init.d/ntpd
}

Après installation de l'image, le service est lancé dès le démarrage et le système est à l'heure :

Poky (Yocto Project Reference Distro) 3.0.1 mybox ttyS0

mybox login: root
Password: (linux)
root@mybox:~# date
Sat Jan  4 09:52:18 UTC 2020
root@mybox:~# ls  /var/run/
agetty.reload  dropbear.pid  ld.so.cache  ntpd.pid     rpcbind.lock  udev
avahi-daemon   ifstate       lock         resolv.conf  rpcbind.sock  utmp
dbus           klogd.pid     mount        resolvconf   syslogd.pid   wpa_supplicant
root@mybox:~# cat  /var/run/ntpd.pid
403
root@mybox:~# ps  aux
  [...]
root       403  0.0  0.0   2636  1432 ?        Ss   09:52   0:00 ntpd -p pool.ntp.org
  [...]
root@mybox:~# ls -l /etc/rc5.d/
total 0
  [...]
lrwxrwxrwx 1 root root 19 Jan  4 09:41 S20bluetooth -> ../init.d/bluetooth
lrwxrwxrwx 1 root root 14 Jan  4 09:42 S20ntpd -> ../init.d/ntpd
lrwxrwxrwx 1 root root 16 Jan  4 09:41 S20syslog -> ../init.d/syslog
  [...]

Conclusion

Cette séquence nous a permis de voir comment modifier la configuration de Busybox et lancer un service au démarrage par l'intermédiaire d'un script de lancement.

Dans la séquence suivante, nous allons continuer l'adaptation de notre image pour une cible personnalisée, en s'intéressant cette fois aux interactions avec le matériel.

Ce document est placé sous licence Creative Common CC-by-nc. Vous pouvez copier son contenu et le réemployer à votre gré pour une utilisation non-commerciale. Vous devez en outre mentionner sa provenance.

«« sommaire »»