[ 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
Chapitre 10 - Les fichiers


10.1 Les fichiers binaires

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.

noopt

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.

nostrip

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.


10.2 Les bibliothèques

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.


10.3 Les bibliothèques partagées

Cette section a été déplacée dans Les bibliothèques partagées, Chapitre 8.


10.4 Les scripts

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.


10.5 Les liens symboliques

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.)


10.6 Les fichiers de périphérique

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*.


10.7 Les fichiers de configuration


10.7.1 Définitions

fichier de configuration

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.

conffile

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.


10.7.2 Emplacement

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.


10.7.3 Comportement

La gestion des fichiers de configuration doit se conformer aux principes suivants :

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.


10.7.4 Partager des fichiers de configuration

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).


    10.7.5 Les fichiers de configuration de l'utilisateur (« dotfiles »)

    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.


    10.8 Les fichiers-journaux (« log file »)

    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).


    10.9 Permissions et propriétaires

    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.


    10.9.1 L'utilisation du programme 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

    La liste de diffusion Debian-Policy