Forums d'entraide informatique - Astuces - Conseils

La première ligne indique le nom du paquet source. Elle est automatiquement complétée, tout comme la valeur pour Mai ntainer (le responsable du paquet, vous), Standards-Version (qui est la version de la charte Debian), Package (le nom du paquet binaire),Pri ori ty (l'importance du paquet, optional est parfait dans la plupart des cas) et Archi tecture. Ce dernier point est, dans le cas présent bien déterminé, mais il est possible qu'un programme ne fonctionne que sur un type d'architecture donné. Il faut alors le spécifier manuellement.
Secti on détermine la section et sous-section dans laquelle placer le paquet. Comme le précise l'article sur le système Debtags, l'utilisation des sections n'est pas idéale. Cependant, en tant que responsable de paquet, même amateur, vous devez vous plier à la règle. Vous pouvez prendre connaissance des différents choix possibles en utilisant cat /var/1 i b/apt/l i sts/*_Packages I grep "Section" I sort I uni d.Trois sections sont disponibles, main (qui est sous-entendu en l'absence de mention spécifique), contri b (logiciel dépendant de logiciel non libres) et non-free (logiciel non libre au sens DFSG).A vous de déterminer au mieux où placer votre paquet en ayant conscience des limitations du système. Ici, nous utiliserons uti ls (sous- entendu mai n/uti 1 s donc).
Description permet de préciser la description courte (60 caractères maxi). C'est celle qui apparaît, par exemple, avec apt -cache search ou dpkg -1 Juste en dessous se trouve la description longue, affichée lors d'un apt - cache show. Ici, un certain nombre de règles sont d'usage
•    La première colonne de chaque ligne est vide.
•    La description doit tenir en un paragraphe
•    Si vous utilisez plusieurs paragraphes, n'utilisez pas de ligne vide, mais une ligne contenant un simple point dans la seconde colonne.
Nous utiliserons donc ici
Enfin, Bui 1 d- Depends informe sur les dépendances de construction du paquet. C'est cette liste qui sera utilisée par apt-get build-dep. Pour déterminer le contenu de ce champ, le « Guide du nouveau responsable Debian » fournit une astuce. Désarchivez votre tarball source dans un répertoire temporaire, puis utilisez dans ce dernier les commandes
NOTE
Depends permet de définir les dépendances de votre paquet. Celles qui s'installeront lorsqu'on l'installera via apt-ge: ou aptitude. Mais il existe aussi d'autres manières de lier votre paquet avec d'autres, de manière mois radicale que Depends.Ainsi, nous avons
•    Recommends pour spécifier les paquets qui ne sont pas vraiment indispensables, mais qui sont normalement utilisés avec le logiciel.
•    Suggests pour les paquets qui contiennent des données ou des applications qui fonctionnent parfaitement avec le logiciel. La nuance avec Recommends est subtile.
Nous avons aussi des liens spéciaux entre les paquets
•    Confl icts permet de ne pas installer votre paquet à moins que celui ou ceux spécifiés ici ne soient désinstallés. C'est le cas, par exemple, si votre paquet fournit un programme qui remplit les mêmes fonctions que celui installé par un autre paquet : un super-serveur i netd, par exemple.
•    Provi des est en rapport avec les paquets virtuels. Le paquet exim4, par exemple, fournit le paquet virtuel mail -transport-agent qui est nécessaire au fonctionnement du système. Le paquet ssmtp fait de même. Le simple fait d'installer l'un de ces paquets satisfait les dépendances liées.
Description: The classic french helloworld program
The helloworld program produces a familiar, friendly greeting in french.
Passons maintenant aux deux éléments plus délicats Depends renseigne sur les dépendances de votre paquet binaire.Vous n'avez, en principe, pas à toucher la valeur actuelle définie par dh_make. En effet, Sfshl bs:Dependsl, par exemple, est une variable qui sera complétée lors de la première construction et analyse de votre paquet. Un script spécifique analysera le binaire (via 1 dd entre autres) et déterminera les noms des paquets contenant les bibliothèques dynamiques utilisées. Il en va de même pour ${mi sc:Depends}.Pour un programme aussi simple que celui utilisé ici, vous n'avez pas à vous inquiéter. En revanche, le script d'analyse,dh_shli bdeps,sera incapable de donner des résultats satisfaisants avec un programme plus complexe chargeant à la demande des bibliothèques partagées.
Dans le cas présent, vous devez obtenir une sortie comme ceci
base-files (>= 3.1.16 ), binutils (>= 2.17-2 ), coreutils (>= 5.96-5 ), gcc-4.1 (>= 4.1.1-13 ), libacll (>= 2.2.41-1 ), libattrl (>= 2.4.32-1 ), libc6 (>= 2.3.6.ds1-4 ), libc6-dev (>= 2.3.6.ds1-4 ), libncurses5 (>= 5.5-5 ), libselinuxl (>= 1.32-3 ), libsepoll (>= 1.14-1 ), locales (>= 2.3.6.ds1-4 )
% strate -f -o /tmp/log ./configure
% for x in 'dpkg -S $(grep open /tmp/log I \
Perl -Pe 's!.* 0Pen\(\"(["\"]*).*!$11' 1 \
grep "'/"I sort I uniq I \
grep -v ""Wtmp\l/dev\l/proc\l" ) 2>/dev/null I \
tut -fi -d":" I sort I uniq';
do \
echo -n "$x (>=" 'dpkg -s $xlgrep 'Versionlcut -f2 -d":"' "),
done

La plupart de ces paquets ne nécessitent pas de mention particulière puisqu'ils seront déjà installés avec debhel Der. Une autre solution consiste à compiler le logiciel, puis à utiliser la commande objdump -p sur le binaire en redirigeant la sortie vers grep NEEDED.II suffit alors de rechercher à quel paquet appartiennent les bibliothèques listées avec dpkg -S et vérifier s'il existe un paquet -dev correspondant. Les deux méthodes peuvent être utilisées de concert, mais comprenez bien que c'est bien vous qui devrez finalement tirer les conclusions qui s'imposent et définir les dépendances de construction. Notre ligne sera ici : Bui d-Depends : debhelper (>= 5), autotools-dev, libc6-dev (>= 2.3.6.ds1-4 )
RULES
Le fichier debian/rul es est un Makefi 1 e utilisé par dpkgbui 1 dpackage pour créer le paquet. On y trouve ainsi différentes cibles comme bui 1 d:, i nstal : ou bi nary - arch:. Le travail du fichier rul es est de centraliser les informations et le lancement des scripts de construction et de vérification (d h_*).
On retrouve dans ce fichier le lancement du script autoconf, . /confi gure avec l'option --prefix,/usr.La variable CFLAGS permet également de passer des options au compilateur.
Le fichier cules est le cœur du système de création de paquet. Bien entendu, pour quelque chose d'aussi simple qu'un « bonjour monde », il n'y a pas grand-chose à dire ou faire.Cependant, vous remarquerez que les scripts d h_* inutilisés sont présents sous la forme de commentaires. Libre à vous donc de parcourir les pages de manuel des différents scripts.
p AUTRES FICHIERS
Le fichier copyri ght résume les informations sur le projet amont comme l'auteur du logiciel, les sites Web ou FTP d'où vient le logiciel, etc. Complétez simplement le fichier en suivant les indications placées là par dh_make.
change] og résume l'évolution du paquet au cours de ses différents changements de versions. Là encore, dh_make vous a facilité le travail en proposent un canevas.
README. Debi an est le document texte qui décrit les différences entre la version standard du logiciel et la version Debian. Le fichier peut être supprimé s'il n'y a rien à dire.
conffiles.ex devra être renommé conf f i 1 es et devra contenir la liste (un élément par ligne) des fichiers à considérer comme des éléments de configuration (voir article sur le détournement).
ducs liste les fichiers de documentation se trouvant à la racine de l'arborescence source. Ils seront déplacés ensuite dans /usr/share/doc/nom_du_paquet.
manpage. 1.ex est un exemple de page de manuel au format roff. Normalement, votre logiciel doit avoir une page de manuel.
di rs contient la liste des répertoires qui doivent exister sur le système cible, mais que le paquet ne va pas créer.
@ CONSTRUCTION
Il est maintenant temps de lancer la création du paquet ou plus exactement des paquets, puisque ceci concerne à la fois le paquet binaire et un paquet source propre et distribuable. Placez-vous dans le répertoire des sources amont et utilisez dpkg- bui 1 dpackage -rfakeroot.Si vous avez lu l'article sur la reconstruction de paquets, cette commande vous est sans doute familière. Notez cependant l'absence de l'option -b limitant le processus de construction au paquet binaire.
% dpkg-buildpackage -rfakeroot
dpkg-buildpackage: source package is bonjour
dpkg-buildpackage: source version is 0.1.1
dpkg-buildpackage: source changed by Denis Bodor dpkg-buildpackage: host architecture i386
[...] dh_testdir
dh_testroot
rm -f build-stamp
dh_clean
dpkg-source -b bonjour-0.I
dpkg-source: building bonjour using existing bonjour_ 0.1.orig.tar.gz
dpkg-source: building bonjour in bonjour_0.1-1.diff.gz
[...]
Dès le lancement, les scripts vont commencer par construire le paquet source en utilisant le tarball amont et en produisant un patch (fichier di ff) compressé Gzip.
[...]
dh_testdir
# Add here commands to configure the package.
./configure --host=i486-linux-gnu --build=i486-linux-gnu
[...]
[...]
Le script confi gure est ensuite lancé en utilisant les paramètres permettant l'installation dans une arborescence correspondant aux besoins de la distribution. Suit, directement après, la compilation elle-même :
[...]
Making all in src
make[2]: entrant dans le répertoire " /mnt/HS28ex/bonjour0.1/src "
if i486-linux-gnu-gcc -DPACKAGE_NAME=Ybonjour\" -DPACKAGE_TARNAME=Ybonjour\" -DPACKAGE_VERSION=\"0.1\" -DPACKAGE_STRING=\"bonjour\ 0.1\" -DPACKAGEBUGREPORT=\"lefinnoisOlefinnois.net\" -DPACKAGE=\"bonjour\" -DVERSION=\"0.1\" -I. -I.
-Wall -g -02 -MT main.o -MO -MP -MF ".deps/main.Tpo" -c -o main.o main.c[...]
[...]
Les scripts prennent ensuite le « dépouillage » du logiciel en charge en se chargeant de répartir les éléments un peu partout dans le système, en fonction des données spécifiées dans les fichiers de configuration de debi an/.
[...]
touch build-stamp

amuse
dh_testdi r dh_testroot dh_clean -k dh_installdirs [...]
dh_testdir dh_testroot dh_installchangelogs ChangeLog
dh_installdocs
dh_installexamples
dh_installman dh_link
dh_strip
dh_compress dh_fixperms dh_ipstalldeb dh_shlibdeps dh_gencontrol dh_md5sums dh_builddeb [...]
Enfin,i1 est temps de construire le fichier .deb,puis d'authentifier les fichiers importants, à commencer par bonjour_0.1-1.dsc
[...]
dpkg-deb: construction du paquet "bonjour"
dans "../bonjour_0.1-1_i386.deb".
tar: -: file name read contains nul character signfile bonjour_0.1-1.dsc
Vous avez besoin d'une phrase de passe pour déverrouiller la clé secrète pour l'utilisateur: " Denis Bodor lefinnois@lefinnois.net
clé de 1024 bits DSA, ID 43C4B3C8, créée le 2000-05-14 Entrez la phrase de passe: ***************************
Si une version utilisable de GnuPG est détectée, une clef secrète est recherchée pour l'utilisateur spécifié dans le fichier debi an/control . Si la clef est trouvée, la phrase de passe est demandée pour signer le fichier . ds c. L'opération est renouvelée pour le fichier bonjour_0.1-1_1 386. changes tiré du change] og original du paquet source
[...]
dpkg-genchanges
dpkg-genchanges: including full source code in upload dpkg-buildpackage: full upload (original source is included) signfile ../bonjour_0.1-1_i386.changes
Vous avez besoin d'une phrase de passe pour déverrouiller la clé secrète pour l'utilisateur: " Denis Bodor lefinnois@lefinnois.net
clé de 1024 bits ISA, ID 43C4B3C8, créée le 2000-05-14 Entrez la phrase de passe: ***************************
La procédure terminée, vous devez trouver les fichiers suivants dans le répertoire parent
bonjourj .1. on i g .tar gz : le tarball des sources amont
bonjour_0.1-1 di ff .gz : le patch à appliquer aux sources amont pour obtenir les sources Debian.
bonjour_O .1-1 . dsc : le fichier de description à destination de la commande dpkg - source -x permettant, à partir des
sources amont et du patch, d'obtenir l'arborescence des sources Debian prêtes à être compilées/construites.
bonjour_0 .1-1_1386 . changes : la liste des modifications apportées au paquet source.
bonjour_0.1-1_i386.deb : le paquet binaire.
Avant d'utiliser notre paquet binaire, nous allons vérifier notre travail. Pour cela, faisons appel à 1 i nti an. Cet outil, comme 1 i nda. recherche les erreurs courantes et vous informe de ses découvertes
% lintian    bonjour_0.1-1_i386.changes
W: bonjour: binary-without-manpage bonjour
N:
N:    Each binary in /usr/bin, /Là/sbin, /bin, /sbin or
N:    /usr/games should have a manual page
N:
N:    Note, that though the 'man' program has the
N:    capability to check for several program names
N:    in the NAMES section, each of these programs
N:    should have its own manual page (a symbolic
N:    link to the appropriate manual page is sufficient)
N:    because other manual page viewers such as xman
N:    or tkman dont support this.
N:
N:    Refer tu Policy Manual, section 12.1 for details.
N:
E: bonjour: spelling-error-in-description french French
N:
N:    Lintian found a spelling error in the package
N:    description. Lintian has a list of common misspellings
N:    that it looks for; it does not have a dictionary like
N:    a spelling checker does.
Notre paquet ne contient pas de page de manuel.Nous aurions dû en créer une en tant que responsable du paquet. De plus, nous avons fait une erreur d'anglais relativement classique dans la description du paquet (fort intéressant pour un français).
Il ne nous reste plus qu'à corriger les problèmes et reconstruire le paquet. Enfin, nous pouvons l'installer avec dpkg - i .
CO CONCLUSION
Cet article n'a pas la prétention de faire de vous un responsable de paquet Debian, mais simplement de vous faire découvrir, à l'aide d'un exemple simple, les principes utilisés. Il existe une documentation officielle Debian expliquant, plus en détail et en français, les étapes et les manipulations présentées ici. C'est le Guide du nouveau responsable Debian.Vous la trouverez sur
http://www.debian.orgIdocimanualsimaint-guide/.
Il ne s'agit que d'un guide et il est loin de détailler tous les cas de figure.Voyez ce document comme la seconde marche (la première étant cet article) d'un grand escalier où il est facile de trébucher.
Après avoir lu le Guide du nouveau responsable Debian, la meilleure solution est d'utiliser apt-get source à tout va, afin d'étudier le debi an/rul es de paquets importants.Tout comme avec la programmation, observer le travail des autres est la meilleure source d'apprentissage qui soit...

'.1Er    ure complexe reposant n. Nous allons, dans cet ème Debian GNU/Li
Le demarrage d'un système GNU/L nux-e    e pr   
sur un mécanisme en partie spécifique à la- istribL article, détailler les étapes du démarrage d'un s   
afin de vous permettre de mieux comprendre la structure du système
Les informations qui vont suivre sont, en grande partie, génériques à l'ensemble des systèmes GNU/Linux. Les distributions suivant l'évolution des fonctionnalités du noyau et des utilitaires, on retrouve souvent les même techniques et processus mis en ceuvre.Cependant, certaines spécificités font de Debian GNU/Linux une distribution plus structurée (à mon goût) que d'autres et donc plus facile à comprendre.
ET LE COURANT FUT
Dès l'allumage d'une machine x86 de type PC (attention aux machinesApple/Intel qui sont maintenant une catégorie x86 à part), la machine et la mémoire sont dans un état indéterminé. Le processeur exécute alors automatiquement un code placé en ROM (ou en mémoire Flash) : le BIOS. Celui-ci initialise les composants les plus importants de la machine durant une procédure appelée « POST » (pour Power-On Self Test). L'ensemble des systèmes vitaux, dont la mémoire et les contrôleurs de disques sont inspectés. C'est à ce stade qu'un éventuel problème est rapporté à l'utilisateur via différent « bips », codes et messages d'erreur à l'écran.
Ceci fait, il parcourt ensuite les périphériques de stockage ou autre (boot PXE) qu'il peut utiliser pour exécuter le démarrage du système. Dans le cas des périphériques de stockage, le premier secteur est inspecté à la recherche d'un code de boot. Dans le cas d'un disque dur, ce secteur est le MBR (Moster Boot Record) qui, une fois chargé et exécuté, chargera le vrai secteur de boot sur la première partition marquée « active ».
BOOT
Le secteur de boot prend le relais (via le MBR). Dans le cas d'un système GNU/Linux, c'est la première étape du chargement du bootloader. L'un de ceux-là, GRUB (GRand United Bootloader), est composé d'un minimum de deux éléments logiciels. Nous avons d'une part le code de boot qui doit tenir dans les 512 octets du premier secteur et qui se nomme stagel. Celui-ci à pour seul but de trouver et charger le second élément, stage2, le code principal du bootloader.
En effet, un bootloader aussi complet, souple et configurable que GRUB ne peut pas « tenir » dans 512 malheureux octets. Le code principal de GRUB est en mesure de lire divers supports de stockage et différents types de partitions. Il est également en mesure de charger un fichier de configuration regroupant les options de démarrage qui apparaissent sous la forme d'un menu à l'écran. A la demande de l'utilisateur ou automatiquement (après un délai configure), GRUB charge le code principal du système d'exploitation, le noyau. Il existe également un certain nombre de jf s_*_1_5.11 s'agit de codes plus réduits (moins le IO Ko) pouvant être placés dans une zone juste après le MBR. Cette zone d'une taille correspondant au nombre de secteurs par tête moins I est habituellement inutilisée. Ceci permet de placer stage2 sur un système de fichiers correspondant à la version de stage1.5(ReiserFS, XFS, JFS, etc.).
GRUB n'est, bien sûr, pas le seul bootloader. LILO ou SYSLinux sont deux autres implémentations. L'utilisation de GRUB reste cependant majoritaire, bien que les besoins en « boot graphique » de certains utilisateurs poussent les distributions orientées desktop vers des solutions différentes. Enfin, précisons que la notion de « bootloader », sans être spécifique aux plateformes PC, est un concept caractéristique de ces architectures. En effet, le BIOS est sans doute la pire invention du monde informatique en raison du nombre de limitations imposées dès son invention. D'autres architectures comme les Sparc ou les Mac utilisent un firmware intégrant, entre autres, un grand nombre des fonctionnalités offertes par
St NOTE
GRUB procède également à un certain nombre de vérifications et passe le processeur en mode protégé. Au démarrage de la machine, le processeur est dans un mode particulier appelé « mode réel ». Il s'agit d'un mode correspondant au fonctionnement des processeurs 8086. Eh oui, lorsque vous mettez la machine sous tension, votre beau Core 2 Duo E6600 tout neuf ne vaut guère plus qu'un 8086 cadencé à 2,4 GHz. C'est stagel qui remet les choses au goût du jour.

les bootloaders. Il est logique, en effet, d'estimer que la place d'un bootloader est en ROM et non sur un disque, du moins la plus grande partie.
p BOOTLOADER ET NOYAU
GRUB charge le noyau Linux sous la forme d'un fichier image et saute à la première instruction  de cette image. Le noyau est compressé (Zlib) et l'en-tête d'image contient le code permettant la décompression et le chargement en mémoire.
Si une image de disque d'initialisation ((nit RAM Disk) est spécifiée dans la configuration de GRUB, celui-ci la charge également en mémoire et informe le noyau de sa présence au moment du démarrage. Ce RAM Disk maintenant au format i ni tramf s est toujours appelé i ni trd, ce qui correspond au nom du format utilisé avec les versions plus anciennes du noyau Linux. C'est le code décompressé du noyau qui va alors monter le RAM Disk comme un système de fichiers contenant l'arborescence racine du système.
Le noyau Linux peut également intégrer le support d'un ou plusieurs systèmes de stockage (SCSI, IDE, SATA) et systèmes de fichiers (ext3, ReiserFS, etc.). Il peut alors se passer de RAM Disk et utiliser directement la partition désignée comme système de fichiers racine. Nous verrons par ailleurs en quoi cela peut être encore utile aujourd'hui.
Le système de fichier racine fourni par un RAM Disk est temporaire.II sert principalement au chargement de modules noyau permettant la prise en charge d'autres systèmes de fichiers, de périphériques nécessaires au démarrage du système et à la prise en charge de fonctionnalités particulières (RAID logiciel, LVM,etc.).Une fois le processus de démarrage suffisamment avancé, le système de fichier racine est changé (via pivot_root qui ne fait qu'appeler la fonction du même nom). On permute ainsi le RAM Disk et le vrai système de fichiers racine du système pour poursuivre le chargement et terminer le processus de boot. C'est également le système en RAM Disk qui monte les pseudo-systèmes de fichiers comme /proc, /sys, /tmp ou /dev.
Le remplaçant de l'initrd au format CRAMFS (Compressed ROM/RAM FS), appelé initramfs a fait son apparition dans le noyau Linux de développement 2.5.46. Contrairement à son prédécesseur, l'i ni tramf s n'est pas vraiment un système de fichier. Il donc pas possible de le monter avec muant -ro loop image /point/de/montage.
Il s'agit en réalité d'une archive cpio compressée avec Gzip. Le noyau, lors du démarrage, ne monte donc pas directement le système de fichier, mais crée un RAM Disk, puis copie le contenu de l'archive cpi o.L'i nitramfs est un système utilisant ramfs qui présente l'avantage d'avoir un taille dynamique (la mémoire est allouée en fonction des besoins).
Si vous souhaitez inspecter le contenu d'une image initramfs, créez un répertoire, placez-vous dedans et utilisez gunzip -c /chemin/initrd.img I cpic - v.'Vous retrouverez ainsi toute l'arborescence du futur RAM Disk temporaire dans le répertoire courant. Vous pourrez alors inspecter le script shell init à la racine de l'arborescence pour en apprendre plus sur le déroulement du processus en ce qui concerne l'i nitramfs.
Dans tous les cas, une fois les fonctions d'initialisation exécutée par le noyau, il est temps de lancer le premier programme utilisateur : i nit.
p INIT
Pour démarrer tous les services ou utilitaires qui composent un système GNU/Linux, un programme unique est utilisé. C'est le processus ayant le PID I, le parent de tous les processus du système. Son fichier de configuration est inittab qui décrit la liste des programmes à lancer, ce sont les services.
Unit le plus largement utilisé avec les systèmes GNU/ Linux est un clone de l'Init utilisé dans UNIX System-V (Système cinq) développé par AT&T et rendu public en janvier 1983. Ce système utilisant des niveaux d'exécution (runlevel) est depuis longtemps critiqué. On cherche donc, plus ou moins activement, à le remplacer.
1k' NOTE
La dernière version 6.10 de la distribution Ubuntu basée sur Debian annonce parmi ses nouveautés l'utilisation d'un remplaçant au vieillissant Init System- V appelé « Upstart ». Bien qu'il s'agisse effectivement d'un code différent destiné à gérer les services avec une philosophie novatrice, Upstart se borne pour l'heure à singer le comportement de l'Init classique. Le renouveau du système de gestion des services n'est pas pour aujourd'hui, en tout cas, pas chez Ubuntu.
lait est un programme relativement simple. Il prend, entre autres comme argument, une valeur numérique (ou « Sis ») et l'utilise pour déterminer les programmes ou scripts qui doivent être lancés. Cette valeur est le runlevel dans lequel le système passe alors. Les scripts

ÉTUDE DU DÉMARRAGE D'UN SYSTÈME DEBIAN
lancés sont spécifiés dans le fichier /etc/inittab. Le choix d'utiliser un runlevel donné pour tel ou tel « état » du système est complètement arbitraire, mais les distributions s'entendent pour la plupart sur quelques points :
0 :Arrêt du système.
I : Mode mono-utilisateur (habituellement pour réparer le système).
2 : Fonctionnement normal. 6 : Redémarrage du système.
S : est utilisé pour le démarrage du système. Dans ce runlevel, le système est dit « on boot ». Si vous avez la main dans ce runlevel, c'est qu'un problème est survenu lors du démarrage (habituellement lors de la vérification des systèmes de fichiers avec f sck).
SCRIPTS D'INIT
Dans un système Debian, les scripts à utiliser pour chaque niveau d'exécution sont lancés via un seul et même script shell : /etc/ini t.d/rc qui prend en argument le numéro de runlevel. Ce script utilise alors l'arborescence /etc/rcN. d/ où N est le runlevel. Ces répertoires contiennent des liens symboliques pointant vers des fichiers stockés dans /etc/init.d. C'est le nom du lien symbolique qui détermine le comportement du script.
Si le nom du lien débute par un « S », le script dans /etc/i ni t.d/ est lancé avec l'argument start, s'il s'agit d'un « K », l'argument est stop. Une valeur numérique suit ce premier caractère. Il est utilisé pour déterminer l'ordre dans lequel exécuter les scripts lors d'un passage d'un niveau à un autre. Les liens débutants par un « K » sont lancés en premier, puis ceux débutant pas un « S ».
On notera également, comme il est précisé dans /etc/i ni t. d/rc, qu'un script configuré pour lancer un service dans le runlevel précédent ne sera pas lancer à nouveau lors du passage au nouveau runlevel.
Un script d'init est relativement complet. Il prend en argument une action qui peut être start ou stop, mais également rel oad pour demander au démon qu'il gère de recharger sa configuration ou encore restart pour provoquer un arrêt suivi d'un redémarrage du démon. Il peut également vérifier un certain nombre de points de configuration comme l'existence d'une variable d'environnement évaluée après le chargement d'un autre script présent dans /etc/defaul t.Ceci permet, par exemple, de conditionner le démarrage du service en fonction d'options comme start_smartd.yes (pour le service de surveillance des disques).C'est également là qu'on trouvera ces options spécifiques au système local, comme les options
à passer au serveur OpenSSH, l'utilisation de FetchMail en démon, la langue pour GDM ou encore l'emplacement du fichier de configuration de Nagios.
Pour lancer et arrêter un démon (exécutable binaire du service), les scripts utilisent start-stop-daemon. Ce petit programme permet de lancer des exécutables tout en gardant leur trace en stockant leur numéro de processus dans un fichier . pi d placé dans /var/run.Ainsi, start-stopdaemor est en mesure de tuer le processus correspondant au service ou de lui demander de recharger sa configuration en lui envoyant un signal HUP. start-stop-daemon présente un avantage évident : il rend générique le comportement des binaires et sert de « wropper » à ces derniers. C'est ce qui rend si facile l'écriture de nouveau scripts d'init.
Vous l'aurez compris, les scripts d'init servent non seulement pour le démarrage du système et la gestion des runlevel, mais également pour lancer et stopper des services à la convenance de l'administrateur système.
Si vous souhaitez créer un script d'init spécifique, je vous recommande la lecture et l'étude du script exemple /etc/ init.d/skeleton.Très complet et parfaitement commenté, il constitue comme son nom l'indique le squelette pour tout nouveau script d'init. Bien entendu, il convient de respecter l'intégrité du système Debian et donc d'éviter au maximum l'ajout de fichier indépendant de tous paquets. Reportez-vous à l'article sur la création de paquet le cas échéant.
Un reproche qui est souvent fait aux distributions Debian concerne l'interface de gestion des runlevels. L'édition et la mise à jour des liens symboliques entre /etc/ini t.d et les /etc/rc*.d sont souvent réputées pénibles et peu ergonomiques. Pourtant, de base, le système Debian contient un utilitaire permettant de manipuler facilement ces liens. La commande update-rc .d permet de facilement gérer des configurations personnalisées. Par exemple, update-rc.d ssh remove supprimera complètement le service OpenSSH du système d'init. Notez que /etc/init. d/ssh doit avoir été supprimé au préalable (ce qui n'est pas « bien » au sens Debian) ou que vous devez utiliser l'option -f pour forcer la suppression. L'option -n est également très intéressante, puisqu'elle permet de simuler l'action à des fins de test.
update-rc.d monservi ce defaults permet de créer les liens automatiquement pour un démarrage du service dans les runlevels 2, 3, 4 et 5 ainsi qu'un arrêt de ce service dans les runlevels 0, I et 6. Par défaut, le code numérique est égal à 20, mais vous pouvez le préciser en fin de ligne de commande (et même en définir un différent pour start et stop). Enfin, dernier exemple, vous pouvez personnaliser à l'extrême en utilisant, update-rc.d monservice start 20 2 3 4 5 stop 50 0 1 6. Ici, monservi ce sera presque configuré comme
par défaut (démarrage en 2,3,4 et 5 et arrêt en 0, I et 6) à la différence que nous utilisons des valeurs numériques différentes pour start (20) et stop (50). Consultez la page de manuel de update-rc.d pour en savoir plus.
Si l'outil livré par défaut ne vous convient pas,vous pouvez toujours opter pour des interfaces plus conviviales (en mode console toujours). Les paquets sysv -rc-conf et sysvconfi g fournissent une interface permettant une vision plus globale et plus illustrée des liens pour les scripts d'init. Les deux outils proposent sensiblement la même chose et il faudra les tester pour se faire un avis de leur ergonomie. Personnellement, je préfère largement configurer les scripts d'init avec le bon vieux update- rc . d.
POURQUOI NE PAS UTILISER D'INITRD ?
Le principal intérêt d'un RAM Disk de démarrage réside dans le fait d'ajouter dynamiquement des fonctions dans le noyau. Autrement dit, de charger des modules pour pouvoir supporter le matériel sur lequel on boote.
Cependant, il faut savoir que le support des modules chargeables dynamiquement n'est pas nécessairement une bonne chose. Dans le cas d'un serveur dont vous connaissez parfaitement la configuration matérielle, il n'est pas nécessaire de faire appel à ce type de fonctionnalités. En effet, la configuration d'un serveur ne change pas fréquemment et la généricité du système n'est absolument pas intéressante, au contraire. Tout le support du matériel peut donc être inclus statiquement dans une image du noyau qui est alors compilée sans le support des modules.
Dernier avantage pour un serveur, l'absence de fonctionnalité de chargement dynamique de modules empêche l'installation de la pire forme de rootkit qui soit : celle d'un module noyau. L'utilisation d'un noyau statiquement compilé est donc un gain de sécurité non négligeable. C'est d'ailleurs la raison pour laquelle les noyaux installés par les hébergeurs sur leurs serveurs loués sous Debian GNU/Linux ne sont pas ceux de la distribution, mais des versions spécifiquement prévues.
Bien entendu, sans support des modules, il faut inclure dans le noyau le support du contrôleur de disque, de l'interface réseau, du système de fichier utilisé, etc. Ce dernier point fait que le noyau est alors capable de trouver lui-même la partition racine et monter seul le système de fichier correspondant. Le RAM disk de démarrage perd alors tout son intérêt.
• • • MI ..1•811.7•MMT7WZ
I • •    I
[dit links for a Service
Use the up and down arrose ta nove between fields and the left and right arrows to nove within a field. You must delete characters with the backspace before entering ces once. Links must consist of the letter K or S followed by tau digits. To delete a link just leave the field blank. When you are finished. use TUB ta select <OK> and ENTER to nove on to the next item.
acct    4;41    #    #
alsa    liifihi
alsa-utils apache   
asterisk   
atd   
bittorrent bootclean bootlogd bootnisc.sh checkfs.sh checkroot.sh   
<Accepter>    <Annuler >
Sysvconfig permet de configurer les runlevels et scripts d'init via une interface à menu. On aime ou on n'aime pas.
QUICK TIP COMMENT FAIRE UNE CAPTURE D'UNE CONSOLE EN FRAMEBUFFER ?
Vous vous demandez peut-être comment a été faite la capture qui se trouve quelques pages plus loin dans l'article sur la console BootSplash. Forcément, vous avez dû feuilleter le magazine et vous arrêter sur la capture (tout le monde aime les captures d'écran).Voici la méthode.
Le principe du frame buffering est un mappage mémoire. /dev/fb* fournit une méthode d'accès depuis l'espace utilisateurAinsi, il nous est possible de très simplement récupérer les valeurs brutes de ce qui se trouve à l'écran avec sudo cat /ded/fb0 > ecran . raw.
Ces données brutes ne sont pas utilisables directement avec une application de retouche ou un convertisseur de formats graphiques, car elles ne comprennent pas d'informations sur la résolution de l'écran. Il nous faut donc passer par un petit script Perl
#!/usr/bin/perl -w $w = shift 11 320; $h = shift 11 240; $pixels = $w * $11; open OUT, "Ipnmtopng" or die "Can't pipe pnmtopng: $!\n";
printf OUT "P6%d %d\n255\n", $w, $11;
while ((read STDIN, fraw, 2) and Spixels--) {
$short    unpack('S', $raw);
print OUT pack("C3",
($short & Oxf800) >> 8,
($short & 0x7e0) >> 3,
($short & Oxlf) << 3);
close OUT;
Il vous faudra l'utilitaire onmtoong du paquet netpbm pour le faire fonctionner. A cette seule condition, vous pourrez utiliser ensuite