[ précédent ] [ Table des matières ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ A ] [ B ] [ C ] [ D ] [ E ] [ F ] [ G ] [ suivant ]
Deux paquets ne doivent pas installer des programmes qui ont des fonctions différentes tout en ayant le même nom. Le cas de deux programmes avec les mêmes fonctionnalités mais des implémentations différentes est traité via « alternatives » ou par le mécanisme « Conflicts ». Voir Les scripts du responsable de paquet, Section 3.9 et Mettre en conflit des paquets binaires -- le champ Conflicts, Section 7.3. Si ce cas se produit, un des deux programmes doit changer de nom. Les responsables rapporteront ce problème sur la liste de distribution debian-devel pour essayer de trouver un consensus. Si aucun consensus n'est trouvé, le nom des deux programmes doit être changé.
Par défaut, lors de la construction d'un paquet, tous les binaires créés incluront des informations pour le débogage et seront compilés avec optimisation. Vous mettrez aussi tous les avertissements de compilation qui vous semblent raisonnables : cela facilite la vie des responsables de portage qui peuvent consulter les journaux de construction en cas de problèmes. Pour le cas de la programmation en C, on utilisera les paramètres de compilation suivants :
CC = gcc CFLAGS = -O2 -g -Wall # les bonnes options peuvent différer selon les programmes LDFLAGS = # aucun INSTALL = install -s # (ou bien utiliser strip sur les fichiers dans debian/tmp)
On remarquera que tous les binaires installés sont épurés de tout symbole, soit
en utilisant l'option -s de install
, soit en
appliquant le programme strip
sur les binaires après qu'ils ont
été copiés dans debian/tmp mais avant qu'une arborescence ne soit
faite pour le paquet.
Bien que les binaires dans l'arbre de construction soient compilés par défaut avec des informations pour le débogage, il est souvent difficile de déboguer les programmes qui sont soumis à des optimisations pour compilateur. Pour cette raison, il est conseillé de reconnaître la variable d'environnement standard DEB_BUILD_OPTIONS. Cette variable peut contenir plusieurs drapeaux de manière à pouvoir modifier la construction et la compilation d'un paquet.
La présence de cette chaîne signifie que le paquet ne sera soumis qu'à un minimum d'optimisation. Pour les programmes en C, il vaut mieux ajouter -O0 à CFLAGS (bien que ce soit la valeur par défaut). Il peut arriver que quelques programmes ne se construisent pas ou ne fonctionnent pas à ce niveau d'optimisation : il peut être nécessaire, par exemple, d'utiliser -O1.
Cette chaîne signifie que les symboles de débogage ne seront pas enlevés du binaire pendant l'installation de manière à ce que les informations pour le débogage puissent être incluses dans le paquet.
Le petit makefile suivant explique comment implémenter les options de construction ; vous aurez sans doute à l'adapter aux conditions de votre paquet.
CFLAGS = -Wall -g INSTALL = install INSTALL_FILE = $(INSTALL) -p -o root -g root -m 644 INSTALL_PROGRAM = $(INSTALL) -p -o root -g root -m 755 INSTALL_SCRIPT = $(INSTALL) -p -o root -g root -m 755 INSTALL_DIR = $(INSTALL) -p -d -o root -g root -m 755 ifneq (,$(findstring noopt,$(DEB_BUILD_OPTIONS))) CFLAGS += -O0 else CFLAGS += -O2 endif ifeq (,$(findstring nostrip,$(DEB_BUILD_OPTIONS))) INSTALL_PROGRAM += -s endif
C'est au responsable du paquet de décider des meilleures options de compilation. Certains binaires (comme ceux qui font des calculs intensifs) fonctionnent mieux avec certaines options (p. ex. -O3) ; faites comme vous voulez. Utilisez ces options avec discernement : pour de bonnes raisons, pas seulement pour elles-mêmes. Ne craignez pas de remplacer les options qu'avait choisies l'auteur du programme original : elles sont souvent inappropriées dans votre environnement.
Si le paquet est architecture: any, alors les options de compilation et de liaison de la bibliothèque partagée doivent inclure -fPIC, sinon le paquet ne se construira pas sur certaines des architectures prises en charge[55]. Toute exception à cette règle doit être discutée sur la liste de diffusion debian-devel@lists.debian.org et un consensus général obtenu. Les raisons pour ne pas compiler avec l'option -fPIC doivent être notifiées dans un fichier README.Debian et une attention particulière doit être prise pour restreindre l'architecture ou pour s'arranger pour que -fPIC soit utilisé sur les architectures où cela est nécessaire.[56]
Pour les bibliothèques statiques, le cas général est de ne pas avoir de code relogeable car il n'y a pas de bénéfice sauf dans des cas spécifiques ; c'est pourquoi la version statique ne doit pas être compilée avec l'option -fPIC. Toute exception à cette règle doit être discutée sur la liste de diffusion debian-devel@lists.debian.org et les raisons pour compiler avec l'option -fPIC doivent être notifiées dans le fichier README.Debian. [57]
En d'autres mots, si à la fois une bibliothèque partagée et une bibliothèque statique sont à construire, chaque source (fichiers *.c pour les sources C, par exemple) devra être compilé deux fois dans le cas normal.
Vous devez indiquer l'option -D_REENTRANT de gcc
quand vous compilez une bibliothèque (statique ou dynamique) pour qu'elle soit
compatible avec les threads Linux.
Bien que les outils de construction ne respectent pas cette règle, les bibliothèques partagées, tout comme les binaires, doivent être liées à toute bibliothèque dont elles utilisent les symboles. Cela permet le bon fonctionnement du système shlibs et cela garantit que toutes les bibliothèques peuvent être ouvertes avec dlopen(). Les responsables de paquet peuvent utiliser gcc avec l'option -Wl,-z,defs lors de la construction d'une bibliothèque partagée. Cette option effectuant la résolution des symboles au moment de la construction, une référence à une bibliothèque manquante sera rapidement transformée en erreur fatale.
Toutes les bibliothèques partagées qu'on installe seront épurées de tout symbole par :
strip --strip-unneeded votre-bibliothèque
L'option --strip-unneeded fait que strip
enlève
uniquement les symboles qui ne sont pas utiles au mécanisme de réallocation.
Les bibliothèques partagées fonctionnent parfaitement bien quand elles sont
épurées, car les symboles de liens dynamiques sont dans une autre partie du
fichier objet « ELF » [58].
Il faut noter que dans certaines circonstances, il peut être utile d'installer une bibliothèque non épurée, p. ex. pour la construction d'un paquet d'aide au débogage.
Les fichiers objet partagés (comme les fichiers .so
) qui ne sont
pas des bibliothèques publiques, c'est-à-dire que des exécutables tiers (les
binaires d'autres paquets) ne peuvent s'y lier, seront installés dans des
sous-répertoires de /usr/lib. De tels fichiers n'ont pas à se
plier aux règles qui gouvernent les bibliothèques partagées ordinaires ;
mais ils ne doivent pas être exécutables et seront épurés [59].
Les paquets contenant des bibliothèques partagées qui peuvent être liées à d'autres binaires mais qui, pour quelque raison contraignante, ne peuvent être installées dans le répertoire /usr/lib, peuvent installer les bibliothèques partagées dans des sous-répertoires de /usr/lib ; dans ce cas, ils ajouteront ce répertoire dans /etc/ld.so.conf avec le script de post-installation du paquet et le supprimeront avec le script de post-removal.
Un nombre toujours croissant de paquets utilisent libtool
pour
l'édition de liens. La plus récente version de « GNU libtools (>=
1.3a) » peut se servir avantageusement des meta-données contenues dans les
fichiers (*.la) de libtool
. Le principal avantage de
ces fichiers est que libtool
peut conserver ces meta-données et
donc y accéder en fonction des bibliothèques qu'il construit.
Libtool
cherche ces fichiers et les renseignements utiles qu'ils
contiennent à propos des bibliothèques (p. ex. les bibliothèques nécessaires
pour une édition de liens statiques). Ils sont aussi indispensables
aux programmes utilisant libltdl [60].
Les paquets qui se servent de libtool
pour créer des bibliothèques
partagées mettront les fichiers .la dans les paquets
-dev ; dans le cas où un paquet compte sur la bibliothèque
libltdl de libtool
, les fichiers .la
iront dans le paquet de la bibliothèque.
Vous devez vous assurer que vous n'utilisez que les versions diffusées des bibliothèques partagées pour construire vos paquets ; dans le cas contraire, les autres utilisateurs ne pourront pas exécuter vos binaires correctement. Produire des paquets sources qui dépendent de compilateurs non diffusés est habituellement une mauvaise idée.
Cette section a été déplacée dans Les bibliothèques partagées, Chapitre 8.
Tous les scripts de commandes, y compris les scripts inclus dans un paquet par
le responsable et utilisés par dpkg
, commenceront par
#! et le nom du shell interpréteur.
Pour les scripts Perl, c'est #!/usr/bin/perl.
Quand des scripts sont installés dans un répertoire du PATH système, le nom du script ne devrait pas inclure d'extension comme .sh ou .pl indiquant le langage de programmation actuellement utilisé pour l'implémenter.
Les scripts shell (sh
et bash
) commenceront presque
systématiquement par set -e pour que les erreurs soient détectées.
Tous les scripts utiliseront set -e ou vérifieront l'état de
sortie de toutes les commandes.
L'interpréteur shell de base /bin/sh peut être un lien symbolique
vers n'importe quel shell compatible POSIX, si echo -n ne produit
pas une nouvelle ligne [61].
Les scripts shell indiquant /bin/sh comme interpréteur ne doivent
donc utiliser que des caractéristiques POSIX. Si un script a besoin des
caractéristiques non-POSIX d'un interpréteur, celui-ci doit être spécifié dans
la première ligne du script (par exemple #!/bin/bash). Son paquet
doit dépendre du paquet qui fournit le shell (à moins que le paquet ne soit
marqué « Essential », comme par exemple pour bash
).
Quand c'est possible, on peut vouloir limiter les scripts aux caractéristiques
POSIX de manière à utiliser l'interpréteur /bin/sh
. Si votre
script fonctionne avec dash
(anciennement ash
), il
est probablement conforme à POSIX, mais en cas de doute, utilisez
/bin/bash.
Les scripts Perl détecteront les erreurs survenant lors de tous les appels système, comme open, print, close, rename et system.
Les shells csh
et tcsh
seront évités comme langage de
script. Référez-vous au document Csh Programming Considered Harmful
(Pourquoi programmer en Csh est risqué), l'une des FAQ du groupe usenet
comp.unix.*. Il peut être trouvé sur http://www.faqs.org/faqs/unix-faq/shell/csh-whynot/
.
Si un paquet original utilise des scripts csh
vous devez vous
assurer qu'ils commencent par #!/bin/csh et vous devez rendre
votre paquet dépendant du paquet virtuel c-shell
.
Tout script qui crée des fichiers dans des répertoires où tout le monde peut écrire, (p. ex. dans /tmp) doit utiliser un mécanisme qui provoquera une erreur de façon atomique si un fichier de même nom existe déjà.
À cet usage, le système Debian de base fournit les utilitaires
tempfile
et mktemp
.
En général, les liens symboliques à l'intérieur d'un répertoire de premier niveau seront relatifs alors que les liens symboliques qui pointent d'un répertoire de premier niveau vers un autre répertoire de premier niveau seront absolus. Un répertoire de premier niveau est un sous-répertoire du répertoire racine /.
De plus, les liens symboliques doivent utiliser un nom de chemin le plus court possible ; on évitera par exemple le chemin foo/../bar.
On remarquera que pour créer un lien relatif avec ln
, il n'est pas
nécessaire que le fichier cible soit relatif au répertoire où est exécuté
ln
; de même il n'est pas nécessaire de se déplacer dans le
répertoire où vous désirez créer le lien. Donnez simplement à ln
comme premier argument la chaîne de caractères qui représentera la cible du
lien (cette chaîne doit être un chemin relatif au répertoire contenant le
lien).
Par exemple, dans votre Makefile
ou dans
debian/rules, vous pouvez écrire :
ln -fs gcc $(prefix)/bin/cc ln -fs gcc debian/tmp/usr/bin/cc ln -fs ../sbin/sendmail $(prefix)/bin/runq ln -fs ../sbin/sendmail debian/tmp/usr/bin/runq
Un lien symbolique vers un fichier comprimé aura toujours le même suffixe que le fichier référencé. (Par exemple, si le fichier foo.gz est référencé par un lien symbolique, le nom du lien doit aussi se terminer par « .gz », comme par exemple bar.gz.)
Un paquet ne doit pas contenir de fichiers de périphérique dans son arborescence.
Si un paquet a besoin d'un fichier de périphérique particulier qui n'est pas
inclus dans le système de base, il doit appeler MAKEDEV
dans le
script postinst
, après avoir prévenu l'utilisateur [62].
Un paquet ne doit pas supprimer de fichier de périphérique dans le script
postrm
ou dans un autre script. Ceci doit être laissé à
l'initiative de l'administrateur système.
Debian utilise les périphériques série /dev/ttyS*. Les programmes qui utilisent les anciens périphériques /dev/cu* seront modifiés pour utiliser /dev/ttyS*.
C'est un fichier qui influe sur le fonctionnement d'un programme, ou bien qui donne des renseignements particuliers à un site ou à un hôte, autrement dit un fichier qui singularise le comportement d'un programme. Classiquement, les fichiers de configuration sont faits pour être modifiés par l'administrateur système (s'il en a besoin ou s'il le souhaite) de manière à se conformer aux règles locales ou bien à obtenir un fonctionnement plus utile au site.
C'est un fichier répertorié dans le fichier conffiles d'un
paquet ; dpkg
en fait un usage particulier (voir Précisions sur la
configuration, Section 6.7).
Cette distinction est importante : ce ne sont pas des concepts interchangeables. Presque tous les conffiles sont des fichiers de configuration, mais beaucoup de fichiers de configuration ne sont pas des conffiles.
Il faut noter que les scripts qui renferment des informations de configuration (ainsi la plupart des fichiers de /etc/default et de /etc/cron.{daily,weekly,monthly}) sont de facto des fichiers de configuration et seront traités comme tels.
Tout fichier de configuration créé ou utilisé par un paquet doit se trouver
dans le répertoire /etc
. S'ils sont nombreux, on envisagera la
création d'un sous-répertoire de /etc
qu'on nommera d'après le le
nom du paquet.
Quand un paquet crée ou utilise des fichiers de configuration qui ne sont pas
dans /etc
et qu'il n'est pas facile de modifier ce programme pour
qu'il utilise /etc
, on mettra quand même les fichiers dans
/etc
et on créera des liens symboliques vers ces fichiers depuis
les emplacements voulus par le paquet.
La gestion des fichiers de configuration doit se conformer aux principes suivants :
les changements locaux doivent être préservés pendant la mise à jour d'un paquet ;
les fichiers de configuration doivent être préservés quand le paquet est supprimé ; ils ne sont détruits que si le paquet est supprimé avec « purge ».
La façon simple d'obtenir cela, c'est que le fichier de configuration soit un conffile. C'est parfait quand on peut distribuer une version par défaut qui marche pour la plupart des installations, bien que quelques administrateurs puissent vouloir la modifier. Cela suppose que la version par défaut fasse partie du paquet et que les scripts du responsable du paquet ne la modifient pas pendant l'installation (ou à quelque autre moment).
Pour faire que les changements locaux soient préservés correctement, nul paquet ne peut contenir des liens « en dur », ou en créer, vers des « conffiles »[63].
L'autre façon, c'est d'utiliser les scripts du responsable de paquet. Dans ce
cas, le fichier de configuration ne doit pas être un conffile et
ne doit pas faire partie du paquet. Si la configuration correcte d'un paquet
demande un fichier, c'est au responsable du paquet, via ses scripts,
de créer, mettre à jour, maintenir et supprimer un tel fichier. Voir Les scripts du responsable de paquet et la
procédure d'installation, Chapitre 6 pour des précisions. Ces scripts
doivent être idempotents (c.-à-d. qu'ils doivent fonctionner correctement si
dpkg
a besoin de les relancer à cause d'erreurs survenues pendant
l'installation ou la suppression) ; ils doivent comprendre toutes les
manières de dpkg
en ce qui concerne l'appel des scripts ; ils
ne doivent pas remplacer ou même déformer la configuration de l'utilisateur
sans lui demander ; ils ne doivent pas poser des questions sans intérêt
(surtout pendant les mises à jour) ; bref, ils doivent être de bons
citoyens.
Ces scripts n'ont pas à configurer toutes les options possibles d'un paquet, mais seulement celles qui sont nécessaires à son bon fonctionnement sur un système donné. Idéalement, un sysadmin ne devrait faire aucune autre configuration que celle faite presque automatiquement par le script postinst.
Une manière commune de faire est de créer un script
paquet-configure
qu'appellera le script
postinst
du paquet si et seulement si le fichier de configuration
n'existe pas déjà. Parfois, il est bon d'avoir un fichier d'exemple ou un
fichier modèle utilisable par les scripts du responsable. On mettra ces
fichiers dans /usr/share/paquet
ou dans
/usr/lib/paquet
(selon qu'ils sont dépendants d'une
architecture ou non). On créera des liens symboliques vers ces fichiers dans
/usr/share/doc/paquet/examples
si ce sont des fichiers
d'exemples ; ces fichiers sont des fichiers parfaitement ordinaires pour
dpkg
(ce ne sont pas des fichiers de configuration).
On ne doit pas mélanger ces deux manières de gérer les fichiers de
configuration car alors la folie guette : dpkg
voudra
remplacer le fichier à chaque mise à jour du paquet.
On doit indiquer un conflit entre des paquets qui ont le même fichier
conffile. C'est une application de la règle générale qui veut
qu'on ne partage pas des fichiers. Ni les alternatives ni les
diversions ne sont appropriés dans ce cas ; en particulier,
dpkg
ne gère pas bien les conffiles déviés
(diverted).
Les scripts d'un responsable de paquet ne doivent modifier le conffile d'aucun paquet, même celui du paquet auquel ils appartiennent.
Quand deux paquets ou plus ont le même fichier de configuration et qu'il est raisonnable d'installer les deux paquets, on doit définir l'un des paquets comme le propriétaire du fichier de configuration, et ce sera le paquet qui gère ce fichier comme un fichier de configuration. Les autres paquets qui utilisent le fichier de configuration doivent déclarer une dépendance envers ce paquet s'ils ont besoin de ce fichier de configuration pour leur fonctionnement. Quand ils ne l'utilisent que s'il est présent et qu'ils sont capables de fonctionner sans lui, ces paquets n'ont pas besoin de déclarer de dépendance.
Si l'on veut que deux ou plusieurs paquets apparentés partagent un fichier de configuration et que chacun d'eux soit capable de le modifier, il faut faire ce qui suit :
L'un des paquets apparentés (le paquet « propriétaire ») doit gérer le fichier de configuration avec les scripts du responsable de paquet comme il est décrit dans les sections précédentes ;
le paquet « propriétaire » fournira aussi un programme que les autres paquets utiliseront pour modifier le fichier de configuration ;
les paquets apparentés doivent se servir de ce programme pour faire les modifications voulues sur le fichier de configuration. Ils dépendront alors de la garantie donnée quant à la disponibilité de ce programme, ou bien ils accepteront avec élégance de ne pouvoir modifier le fichier de configuration si ce programme n'est pas disponible. C'est une addition au fait que le fichier de configuration pourrait même ne pas exister dans ce dernier scénario.
Quelques fois, il convient de créer un nouveau paquet qui fournit l'infrastructure de base pour les autres paquets et qui gère les fichiers de configuration partagés (on peut consulter le paquet sgml-base comme exemple).
Les fichiers dans /etc/skel
sont copiés automatiquement dans les
comptes des nouveaux utilisateurs par adduser
. Aucun programme ne
devra référencer les fichiers dans /etc/skel
.
Ainsi, quand un programme, pour fonctionner correctement, a besoin qu'un
fichier « .fichier » existe par avance dans $HOME, le
paquet installera ce fichier dans /etc/skel
et le traitera comme
un fichier de configuration.
Cependant, avoir un programme qui, pour fonctionner correctement, a besoin de fichiers « .fichier » est une mauvaise idée, à moins que ce programme ne crée automatiquement ces fichiers.
L'installation par défaut de Debian devrait configurer les programmes d'une manière aussi proche que possible de la configuration originelle par défaut.
Ainsi, le programme d'un paquet Debian, qui a besoin d'une quelconque
configuration pour fonctionner correctement, sera configuré globalement pour le
système à l'aide d'un fichier placé dans /etc
. C'est uniquement
dans le cas où le programme n'accepte pas de configuration globale au site, et
si le responsable du paquet n'a pas le temps d'ajouter un fichier de
configuration par défaut, qu'un tel fichier pourra être placé dans
/etc/skel
.
/etc/skel
sera aussi vide que possible. C'est d'autant plus
nécessaire qu'il n'existe pas de mécanisme simple (ou même désirable) pour
s'assurer que les fichiers « .fichier » nécessaires sont copiés dans
les comptes des utilisateurs existants à l'installation du paquet.
Les fichiers-journaux se nomment habituellement /var/log/paquet.log. Si vous avez de nombreux fichiers-journaux ou si vous avez besoin d'un répertoire pour des raisons de droits (/var/log ne peut être modifié que par root), vous créerez habituellement un répertoire nommé /var/log/paquet où vous mettrez ces fichiers.
Une rotation des fichiers-journaux doit être assurée de manière qu'ils ne
grandissent pas indéfiniment ; la meilleure façon de procéder est de
mettre un fichier de configuration pour la rotation des fichiers dans le
répertoire /etc/logrotate.d et d'utiliser les facilités apportées
par logrotate [64].
Voici un bon exemple de fichier de configuration de « logrotate »
(pour plus de renseignements voir logrotate(8)
) :
/var/log/foo/*.log { rotate 12 weekly compress postrotate /etc/init.d/foo force-reload endscript }
Cela fait tourner tous les fichiers sous /var/log/foo, sauve 12 compressions, et demande au démon de recharger ses informations de configuration après la rotation des fichiers.
Les fichiers-journaux seront supprimés quand le paquet est « purgé »
(mais pas quand le paquet est simplement supprimé). Ce sera fait par le script
postrm
quand il sera appelé avec l'argument purge
(voir Précisions sur la
phase de suppression sans ou avec suppression des fichiers de configuration,
Section 6.8).
Les règles de cette section sont des directives pour une utilisation
élémentaire. Quand c'est nécessaire, vous pouvez vous écarter de certains
détails. Cependant, dans ce cas, sécurisez ce que vous faites et restez aussi
cohérent que possible avec le système. Vous devriez probablement en discuter
aussi dans debian-devel
.
Les fichiers appartiendront à root.root. Ils seront modifiables uniquement par le propriétaire et seront lisibles par tous (exécutables si nécessaire) c'est-à-dire 644 ou 755.
Les répertoires auront le mode 755 ou, pour ceux qui doivent être modifiables par un groupe, le mode 2775. La propriété du répertoire sera cohérente avec le mode -- si le répertoire a comme mode 2775, il appartiendra au groupe qui a besoin d'y accéder.[65]
Les exécutables qui sont « setuid » et « setgid » auront respectivement les modes 4755 et 2755, et ils appartiendront à l'utilisateur ou au groupe approprié. On n'interdira pas leur lecture (par des modes comme 4711 ou 2711 ou même 4111) ; en effet cela n'apporte aucun gain de sécurité puisque n'importe qui peut obtenir les binaires dans les paquets Debian qui sont librement disponibles ; c'est simplement gênant. Pour la même raison vous ne restreindrez pas les droits en lecture ou en exécution des exécutables « non-set-id ».
Certains programmes « setuid » doivent être restreints à certains groupes d'utilisateurs en se servant des permissions sur les fichiers. Dans ce cas, ils appartiendront à l'« uid » pour lesquels ils sont « set-id » et au groupe qui aura des droits d'exécution. Ils auront le mode 4754 ; cela ne sert à rien d'empêcher leur lecture aux utilisateurs qui n'ont pas les droits d'exécution.
On peut permettre que, pour suivre sa politique locale de sécurité, un
administrateur système puisse reconfigurer un paquet en changeant les
permissions des fichiers binaires : il peut utiliser
dpkg-statoverride
pour cela, comme c'est décrit plus bas [66]. Une autre méthode est de
créer un groupe comprenant les utilisateurs autorisés à utiliser le programme
et de rendre tous les exécutables setuid exécutables seulement par ce
groupe.
Si vous avez besoin d'un nouvel utilisateur ou groupe pour votre paquet, vous avez deux possibilités. La première est de rendre cet utilisateur ou ce groupe propriétaire d'un ou plusieurs fichiers de votre paquet. La deuxième est de compiler l'identifiant (plutôt que le nom) d'utilisateur ou de groupe dans le binaire. Dans ce cas vous avez besoin d'un identifiant attribué de façon fixe.
Si vous avez besoin d'un identifiant attribué de façon fixe, vous devez alors
demander un identifiant d'utilisateur ou de groupe au responsable du système de
base, base-passwd et vous ne devez pas livrer votre paquet avant
d'avoir reçu un tel identifiant. Quand vous l'avez reçu, vous devez faire
dépendre votre paquet d'une version du système de base dans laquelle
l'identifiant est présent dans /etc/passwd ou dans
/etc/group. Alternativement, vous pouvez modifier votre paquet
pour qu'il crée lui-même l'utilisateur ou le groupe avec le bon identifiant (en
utilisant adduser) dans les scripts preinst
ou
postinst
. (Utiliser postinst
est préférable si c'est
possible ; sinon, il faudra une pré-dépendance envers le paquet
adduser.)
D'un autre côté, un programme peut être capable, en fonctionnement, de
déterminer l'« uid » ou le « gid » à partir du nom d'un
groupe de façon à utiliser un identifiant attribué de façon dynamique. Dans ce
cas vous choisirez un nom d'utilisateur ou de groupe approprié, vous en
discuterez dans debian-devel
, vous vérifierez avec le responsable
du paquet base-passwd
que ce nom est unique et vous vous assurerez
qu'ils (la liste debian-devel
) ne préfèrent pas un identifiant
attribué de manière fixe. Quand tout cela a été vérifié, vous devez modifier
votre paquet pour qu'il crée, si nécessaire, l'utilisateur ou le groupe avec
adduser
dans les scripts preinst
ou
postinst
(à nouveau, ces derniers sont préférables si c'est
possible).
Il faut noter que changer la valeur numérique d'un identifiant associé à un nom est une opération très difficile. Elle implique de rechercher dans le système de fichier tous les fichiers concernés. Réfléchissez sérieusement au meilleur choix entre « id » statique ou dynamique, car modifier votre choix ultérieurement posera des problèmes.
dpkg-statoverride
Cette section ne se veut pas normative : c'est une description de
l'utilisation du programme dpkg-statoverride
.
Le programme dpkg-statoverride
remplace le paquet
suidmanager. Les paquets qui utilisaient suidmanager
auront un champ Conflicts: suidmanager (<<0.50) et les
appels à suidregister et à suidunregister seront
simplement supprimés des scripts des responsables de paquet.
Quand un administrateur système souhaite installer un fichier (un répertoire,
etc.) avec un système de permissions différent de celui du paquet Debian
distribué, il peut se servir de dpkg-statoverride
pour dire à
dpkg
d'utiliser un système particulier à chaque installation du
fichier. Ainsi, le responsable du paquet distribuera les fichiers avec un
système de permissions normal et laissera faire ses modifications. Par
exemple, un démon, qui est normalement setuid root mais qui pourrait
parfois être utilisé sans être setuid, sera installé setuid
dans le fichier .deb. Puis, l'administrateur système local
changera cela s'il le souhaite. Quand il y a deux façons de faire, le
responsable de paquet peut utiliser debconf pour trouver la
préférée, et appeler dpkg-statoverride
dans ses scripts pour
prendre en compte les choix de l'administrateur système. Une attention
particulière doit être prise pendant les mises à jour pour ne pas supprimer un
paramétrage existant.
Le programme dpkg-statoverride
est donc essentiellement un outil
pour administrateur système et les scripts de responsable de paquet ne
devraient pas en avoir besoin. Il y a cependant une situation où des appels à
dpkg-statoverride
peuvent être nécessaires dans ces scripts ;
il s'agit des paquets qui se servent d'identifiants d'utilisateur ou de groupe
attribués dynamiquement. Dans cette situation, où sysuser est un
identifiant dynamiquement attribué, il peut être utile de se servir, dans le
postinst
du paquet, de quelque chose comme :
for i in /usr/bin/foo /usr/sbin/bar do # ne faire quelque chose que si aucun paramétrage n'existe if ! dpkg-statoverride --list $i >/dev/null then #inclus : traitement debconf, question à propos de foo et bar if [ "$RET" = "true" ] ; then dpkg-statoverride --update --add sysuser root 4755 $i fi fi done
Quand le paquet est purgé, on peut faire sans condition les appels correspondants dpkg-statoverride --remove.
[ précédent ] [ Table des matières ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ A ] [ B ] [ C ] [ D ] [ E ] [ F ] [ G ] [ suivant ]
La Charte Debian
version 3.7.2.2