[ 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 ]
Quand un programme doit fournir une chaîne de spécification d'architecture, il devra choisir l'une des chaînes fournies par dpkg-architecture -L. Les chaînes sont au format : os-arch, bien que la partie OS soit parfois omise quand l'OS est Linux.[67]
On remarquera que nous ne voulons pas utiliser arch-debian-linux dans la chaîne architecture-vendor-os car cela rendrait nos programmes incompatibles avec les autres distributions Linux. Notez aussi que nous n'utilisons pas arch-unknown-linux, car unknown ne sonne pas très bien.
Les fichiers de configuration /etc/services
,
/etc/protocols
et /etc/rpc
sont gérés par le paquet
netbase
et ne doivent pas être modifiés par d'autres paquets.
Quand un paquet a besoin d'une nouvelle entrée dans l'un de ces fichiers, son
responsable contactera le responsable du paquet netbase
, qui
ajoutera cette entrée et produira une nouvelle version du paquet
netbase
.
Le fichier de configuration /etc/inetd.conf
ne doit pas être
modifié par les scripts d'un paquet sauf si c'est via le script
update-inetd
ou le module Perl DebianNet.pm
. Voir la
documentation pour savoir comment ajouter des entrées.
Quand un paquet veut ajouter un exemple d'entrée dans
/etc/inetd.conf
, cette entrée doit être précédée par un seul
caractère « # ». De telles lignes sont traitées comme des
commentaires de l'utilisateur par le script update-inetd
et ne
seront pas modifiées ou activées lors des mises à jour des paquets.
Certains programmes ont besoin de créer des pseudo-ttys. On doit le faire avec les « Unix98 » ptys si la bibliothèque « C » le permet. Le programme résultant ne doit pas être installé « setuid root », à moins que d'autres fonctions ne le demandent.
Les fichiers /var/run/utmp, /var/log/wtmp et /var/log/lastlog doivent être modifiables par le groupe utmp. Les programmes qui ont besoin de modifier ces fichiers doivent appartenir au groupe utmp.
Certains programmes peuvent appeler un éditeur ou un pagineur pour modifier ou afficher un document texte. Comme de nombreux éditeurs et pagineurs sont disponibles dans la distribution Debian, l'administrateur système et les utilisateurs pourront choisir leur éditeur ou leur pagineur préféré.
De plus, chaque programme choisira un éditeur ou un pagineur par défaut si l'utilisateur ou l'administrateur système n'en a pas choisi un.
Ainsi chaque programme qui appelle un éditeur ou un pagineur doit utiliser les variables d'environnement EDITOR ou PAGER pour déterminer l'éditeur ou le pagineur que l'utilisateur souhaite employer. Si ces variables ne sont pas définies, les programmes /usr/bin/editor et /usr/bin/pager seront, respectivement, utilisés.
Ces deux fichiers sont gérés par l'outil de dpkg
,
« alternatives ». Tout paquet, fournissant un éditeur ou un
pagineur, doit employer le script « update-alternatives » pour
déclarer ces programmes.
Lorsqu'il est très difficile d'adapter un programme pour qu'il utilise les variables EDITOR et PAGER, ce programme peut être configuré pour utiliser respectivement /usr/bin/sensible-editor et /usr/bin/sensible-pager comme éditeur ou pagineur. Ce sont deux scripts fournis par le système Debian de base qui testent les variables EDITOR ou PAGER et lancent les programmes appropriés ou bien exécutent par défaut /usr/bin/editor ou /usr/bin/pager quand la variable n'est pas définie.
Un programme peut aussi se servir de la variable d'environnement VISUAL pour connaître l'éditeur choisi par l'utilisateur. Si elle existe, elle prend le pas sur la variable EDITOR. Et c'est ce que fait /usr/bin/sensible-editor.
Un paquet n'a pas besoin de dépendre d'editor ou de pager, et il n'y a pas besoin de paquets virtuels pour cela [68].
Cette section décrit les emplacements et les « URL » qui seront employés par tous les serveurs et applications Web dans le système Debian.
Les fichiers exécutables cgi-bin sont installés dans le répertoire
/usr/lib/cgi-bin/cgi-bin-name
et seront référencés par
http://localhost/cgi-bin/cgi-bin-name
L'accès aux documents HTML
Les documents HTML d'un paquet sont conservés dans /usr/share/doc/package et peuvent être référencés par
http://localhost/doc/paquet/nom-de-fichier
Le serveur web restreindra l'accès à l'arborescence des documents pour que seuls les clients appartenant à cette machine puissent consulter ces documents. Quand le serveur ne peut contrôler les accès, il ne fournira aucun accès, ou questionnera, pendant l'installation, au sujet d'un tel accès.
L'accés au images
Il est recommandé de mettre les images d'un paquet dans /usr/share/images/paquet et de les référencer par un alias comme dans cet exemple :
http://localhost/images/<package>/<filename>
La racine des documents Web
Les applications Web éviteront de conserver des fichiers dans la racine des
documents Web. Il faut utiliser, à la place, le répertoire
/usr/share/doc/paquet pour les documents et déclarer l'application
Web via le paquet doc-base
. Si l'accès à la racine des
documents Web est inévitable alors il faut utiliser
/var/www
comme racine des documents. Cela peut être juste un lien symbolique vers l'emplacement où l'administrateur a mis la véritable racine des documents.
Fournir httpd et/ou httpd-cgi
Tous les serveurs web devraient fournir le paquet virtuel httpd. Si un serveur intègre une gestion des CGI, il devrait de plus fournir httpd-cgi.
Toutes les applications web ne contenant pas de scripts CGI devraient dépendre de httpd, toutes les applications web contenant des scripts CGI, devraient dépendre de httpd-cgi.
Les paquets Debian qui traitent le courrier électronique, que ce soient les agents utilisateurs (MUA: Mail User Agents) ou les agents de transport (MTA: Mail Transport Agent), doivent respecter les directives de configuration qui suivent. Le non-respect de celles-ci peut entraîner la perte de messages, la présence de lignes From: incorrectes et d'autres dommages sérieux !
Le répertoire pour le courrier est /var/mail et l'interface pour envoyer des courriers est /usr/sbin/sendmail (conformément au FHS). Sur des systèmes plus anciens, le répertoire du courrier peut être physiquement situé dans /var/spool/mail mais les accès à ce répertoire se feront par le lien symbolique /var/mail. Le répertoire pour le courrier fait partie du système de base et n'appartient pas au paquet MTA.
Dans le système Debian, tous les MUA, MTA, MDA et autres programmes de gestions des boîtes aux lettres (comme les démons IMAP) doivent verrouiller les boîtes aux lettres de façon à permettre l'usage de NFS. Cela signifie que le verrouillage de type fcntl() doit être associé avec celui de type point (« dot locking »). Pour éviter les situations inextricables, un programme utilisera d'abord fcntl() et ensuite le verrouillage « point » ou bien implantera si possible les deux méthodes à la fois[69]. Pour faire cela, il est conseillé d'employer les fonctions maillock et mailunlock présentes dans le paquet liblockfile*[70].
Les boîtes aux lettres ont généralement le mode 660 utilisateur.mail à moins que l'administrateur système n'en ait décidé autrement. Un MUA peut supprimer une boîte aux lettres (sauf si elle n'a pas les permissions standards). Dans ce cas, le MTA ou un autre MUA doit la recréer au besoin. Le groupe mail doit pouvoir modifier les boîtes aux lettres.
La file d'attente du courrier a le mode 2775 root.mail et les MUA doivent appartenir au groupe mail pour effectuer le verrouillage mentionné précédemment (et doivent évidemment s'interdire l'accès aux boîtes aux lettres des autres utilisateurs en employant ce privilège).
/etc/aliases
est le fichier contenant les alias du système de
messagerie (par exemple postmaster, usenet, etc.) — c'est l'un des
fichiers que l'administrateur système et les scripts postinst
peuvent modifier. Après avoir modifié /etc/aliases
, le programme
ou l'administrateur doit exécuter newaliases
. Tous les paquets
MTA doivent contenir un programme newaliases
, même s'il ne fait
rien. Cependant les anciens paquets MTA ne le faisant pas, les programmes ne
doivent pas échouer si newaliases
ne peut être trouvé. À cause de
cela, tous les MTA doivent posséder les champs Provides,
Conflicts et Replaces: mail-transport-agent dans leur
fichier de contrôle.
La convention consistant à écrire forward to adresse dans la boîte aux lettres elle-même n'est pas supportée. Utilisez un fichier .forward à la place.
L'emplacement du programme rmail
utilisé par UUCP pour les
messages entrants sera /usr/sbin/rmail. De même le programme
rsmtp
, qui reçoit des lots SMTP via UUCP, sera placé dans
/usr/sbin/rsmtp s'il est supporté.
Quand un programme veut savoir quel nom d'hôte employer, par exemple, pour les messages sortants (courrier et nouvelles) qui sont créés localement, il utilisera le fichier /etc/mailname. Il contient la partie située après le nom d'utilisateur et le signe @ (at) des adresses électroniques des utilisateurs de la machine (suivi par un retour à la ligne).
Un tel programme s'assurera de l'existence de ce fichier. S'il existe, il sera
employé sans commentaire (le script de configuration d'un MTA peut vouloir
interroger l'utilisateur même s'il trouve ce fichier). S'il n'existe pas, il
demandera une valeur à l'utilisateur (en utilisant de préférence
debconf
) et la stockera dans /etc/mailname puis
l'emploiera pour la configuration du paquet. Le message d'invite sera
explicite afin d'indiquer que ce nom ne sera pas utilisé seulement par ce
paquet. Par exemple dans cette situation, le paquet INN pourrait
dire :
Please enter the "mail name" of your system. This is the hostname portion of the address to be shown on outgoing news and mail messages. The default is syshostname, your system's host name. Mail name ["syshostname">']:
où syshostname est la sortie de hostname --fqdn.
Tous les fichiers de configuration relatifs aux serveurs et aux clients NNTP
(nouvelles) seront placés dans le répertoire /etc/news
.
Quelques points de configuration s'appliquent à de nombreux paquets concernant les nouvelles (clients et serveurs) sur la machine :
c'est une chaîne qui apparaîtra dans le champ organisation de l'en-tête de chaque message posté par les clients NNTP de la machine.
contient soit le FQDN du serveur NNTP principal soit localhost si la machine locale est un serveur NNTP.
D'autres fichiers de portée générale peuvent être ajoutés s'ils sont requis pour la configuration commune à plusieurs paquets concernant les nouvelles.
On doit configurer pour le système X Window les programmes qui peuvent l'être, et on doit déclarer toutes les dépendances nécessaires à leur fonctionnement sous « X ». Quand ces dépendances sont pour un paquet dont la priorité est une priorité supérieure à celles des paquets X dont il dépend, les binaires spécifiques à « X » peuvent être mis dans un paquet distinct, ou bien des versions alternatives du paquet avec support de « X » peuvent être fournies, ou bien encore la priorité du paquet peut être abaissée.
Les paquets qui fournissent un serveur « X » et qui, directement ou indirectement, communiquent avec le matériel d'entrée et d'affichage, déclareront dans leurs données de contrôle qu'ils fournissent le paquet virtuel xserver [71].
Les paquets qui fournissent un émulateur de terminal pour le système X Window
et qui correspondent aux critères énumérés plus bas, déclareront dans leurs
données de contrôle qu'ils fournissent le paquet virtuel
x-terminal-emulator. Ils se déclareront comme une alternative
pour /usr/bin/x-terminal-emulator
, avec une priorité égale à 20.
Pour être un x-terminal-emulator, un programme doit :
se comporter comme un terminal DEC VT100 ou un terminal compatible ;
accepter l'option de ligne de commande -e commande qui crée une nouvelle fenêtre de terminal[72] et exécuter la commande spécifiée, en interprétant tout le reste de la ligne de commande comme une commande à donner directement à exec, à la manière de xterm ;
accepter l'option de ligne de commande -T titre qui crée une nouvelle fenêtre de terminal avec comme titre titre.
Les paquets qui fournissent des gestionnaires de fenêtres déclareront dans leurs données de contrôle qu'ils fournissent le paquet virtuel x-window-manager. Ils se déclareront comme une alternative pour /usr/bin/x-window-manager, avec une priorité qu'on calculera ainsi :
Commencez avec une priorité égale à 20.
Si le gestionnaire de fenêtres permet le système des menus de Debian, on ajoutera 20 points si cela se fait avec la configuration par défaut du paquet (c.-à-d. qu'il n'y a pas besoin, pour obtenir cette fonctionnalité, de modifier des fichiers de configuration appartenant au système ou à l'utilisateur) ; si l'on doit modifier des fichiers de configuration, on ajoutera seulement 10 points.
Si le gestionnaire de fenêtres est conforme au Projet pour la
spécification des gestionnaires de fenêtres (The Window Manager Specification
Project)
, écrit par le Free Desktop Group
, on ajoutera 20
points.
Si le gestionnaire de fenêtres autorise, dans sa configuration par défaut, le redémarrage d'une session X avec un nouveau gestionnaire de fenêtres (sans tuer le serveur X), on ajoutera 10 points ; sinon, rien.
Les paquets qui fournissent des polices pour le système X Window [73] doivent faire un certain nombre de choses pour s'assurer à la fois qu'ils sont disponibles sans avoir à modifier la configuration du serveur X ou du serveur de polices, et qu'ils n'abîment pas les fichiers utilisés par d'autres paquets pour déclarer les renseignements qui les concernent.
Les polices de tout type offertes pour le système X Window doivent être dans des paquets distincts des binaires, bibliothèques ou de la documentation (sauf celle liée à la police fournie, par exemple leur licence). Quand une ou plusieurs polices sont nécessaires à l'exploitation correcte du paquet auquel elles sont associées, le paquet qui les contient peut être placé dans un champ Recommends ; si elles n'apportent que des améliorations, on peut utiliser un champ Suggests. Les paquets ne doivent pas dépendre de paquets contenants des polices[74].
Les polices BDF seront converties en polices PCF avec le programme
bdftopcf
(disponible dans le paquet xfonts-utils),
gzip
ées, et placées dans un répertoire qui correspond à leur
définition :
Les polices à 100 dpi seront mises dans /usr/share/fonts/X11/100dpi/ ;
Les polices à 75 dpi seront mises dans /usr/share/fonts/X11/75dpi/ ;
Les polices à chasse fixe, les polices pour le curseur, ainsi que d'autres polices de faible définition seront mises dans /usr/share/fonts/X11/misc/.
les polices « Speedo » seront mises dans /usr/share/fonts/X11/Speedo/.
les polices « Type 1 » seront mises dans /usr/share/fonts/X11/Type1/. Si des fichiers de métrique sont disponibles, ils peuvent aussi être placés là.
On ne doit pas créer ni utiliser d'autres répertoires dans /usr/share/fonts/X11/ que ceux répertoriés dans la liste qui précède. Les répertoires PEX, CID et cyrillic font exception pour des raisons historiques, mais l'installation de fichiers dans ces répertoires reste déconseillée.
Au lieu de mettre directement des fichiers dans les répertoires cités dans la liste qui précède, les paquets peuvent fournir des liens symboliques dans le répertoire des polices pointant vers l'emplacement réel des fichiers dans l'arborescence. Un tel emplacement doit se conformer au « FHS ».
Les paquets ne contiendront pas à la fois les versions à 75 dpi et les versions à 100 dpi d'une police. Si les deux sont disponibles, elles seront fournies dans des paquets distincts dont les noms seront étiquetés -75dpi ou -100dpi.
Les polices destinées au répertoire misc ne doivent pas être mises dans les mêmes paquets que ceux des polices à 75 dpi ou 100 dpi mais elles seront fournies dans un paquet distinct étiqueté -misc.
Les paquets ne doivent pas fournir les fichiers fonts.dir, fonts.alias ou fonts.scale dans un répertoire de polices.
les fichiers fonts.dir ne doivent en aucun cas être fournis ;
si besoin est, les fichiers fonts.alias et fonts.scale seront fournis dans le répertoire /etc/X11/fonts/fontdir/paquet.extension où fontdir est le nom du répertoire de /usr/share/fonts/X11/ dans lequel sont conservées les polices du paquet correspondant (p. ex. 75dpi ou misc), où paquet est le nom du paquet qui fournit ces polices, et où extension correspond au contenu du fichier, soit scale soit alias.
Les paquets doivent déclarer une dépendance envers le paquet xfonts-utils dans leurs données de contrôle.
Les paquets qui fournissent un ou plusieurs fichiers fonts.scale
tels qu'ils sont décrits plus haut, doivent appeler le programme
update-fonts-scale
, pour chaque répertoire où est installée une
police, avant d'appeler le programme update-fonts-dir
pour ce répertoire. Cet appel doit se faire à la fois dans le script
postinst
(pour tous les arguments) et dans le script
postrm
(pour tous les arguments sauf upgrade).
Les paquets qui fournissent un ou plusieurs de ces fichiers
fonts.alias dont on vient de parler, doivent appeler le programme
update-fonts-alias
pour chaque répertoire où ils installent des
polices. Cet appel doit se faire à la fois dans le script
postinst
(pour tous les arguments) et dans le script
postrm
(pour tous les arguments sauf upgrade).
Les paquets doivent appeler le programme update-fonts-dir
pour
chaque répertoire où ils installent des polices. Cet appel doit se faire à la
fois dans le script postinst
(pour tous les arguments) et dans le
script postrm
(pour tous les arguments sauf upgrade).
Les paquets ne doivent pas proposer, pour les noms des polices qu'ils fournissent, des alias qui entrent en conflit avec les alias déjà utilisés par des polices d'autres paquets.
Les paquets ne doivent pas fournir des polices qui ont le même nom pour l'enregistrement XLFD que celui donné par une police déjà en usage.
Les fichiers « défaut » des applications doivent être installés dans le
répertoire /etc/X11/app-defaults/ (on peut utiliser un répertoire
particulier dans /etc/X11/
comme l'indique le manuel X Toolkit
Intrinsics - C Language Interface). On ne les déclarera pas comme des
conffiles et on ne les traitera pas non plus comme des fichiers de
configuration. Les paquets ne doivent pas fournir le répertoire
/usr/X11R6/lib/X11/app-defaults/.
Le paramétrage des ressources X des programmes peut aussi se faire par l'intermédiaire d'un fichier portant le même nom que celui du paquet mis dans le répertoire /etc/X11/Xresources/ et qui doit être enregistré comme conffile ou traité comme un fichier de configuration [75]. Important : les paquets qui installent des fichiers dans le répertoire /etc/X11/Xresources/ doivent déclarer un conflit avec le paquet xbase (<<3.3.2.3a-2) ; si ce n'est pas fait, le paquet peut détruire un fichier /etc/X11/Xresources préexistant qui a pu être paramétré par l'administrateur système.
Les paquets qui utilisent le système X Window ne seront pas configurés pour installer des fichiers sous le répertoire /usr/X11R6/. La hiérarchie du répertoire /usr/X11R6/ sera tenue comme obsolète.
Les programmes qui utilisent les programmes GNU autoconf
et
automake
sont facilement configurés au moment de la compilation
pour utiliser /usr/
au lieu de /usr/X11R6/
, et cela
sera fait à chaque fois que c'est possible. On placera les fichiers de
configuration des gestionnaires de fenêtres et des gestionnaires d'affichage
dans un sous-répertoire de /etc/X11/
correspondant au nom du
paquet ; cela est dû à l'interpénétration étroite de ces programmes et du
mécanisme du système X Window. Les programmes applicatifs utiliseront le
répertoire /etc/
sauf si cette charte impose autre chose.
L'installation de fichiers dans des sous-répertoires de
/usr/X11R6/include/X11/
et de /usr/X11R6/lib/X11/
est
maintenant interdite ; les responsables de paquet détermineront s'ils
peuvent utiliser des sous-répertoires de /usr/lib/
et de
/usr/share/
.
Les paquets devraient installer tout fichier pertinent dans les répertoires
/usr/include/X11/
et /usr/lib/X11/
, mais s'ils le
font, ils doivent avoir une pré-dépendance sur x11-common (>=
1:7.0.0).[76]
Les programmes qui demandent les bibliothèque OSF-Motif et OpenMotif[77], bibliothèques non conformes aux « DFSG », seront compilés et testés avec « LessTif » (une libre ré-implémentation de « Motif »). Quand le responsable du paquet juge que le programme ne fonctionne pas suffisamment bien avec « LessTif » pour être distribué et supporté, mais qu'il fonctionne correctement quand il est compilé avec « Motif », il créera alors deux versions du paquet ; l'une qui sera liée de façon statique à « Motif » et dont le nom sera étiqueté « -smotif », et l'autre qui sera liée de façon dynamique à « Motif » et dont le nom sera étiqueté « -dmotif ».
Les deux versions liées à « Motif » sont dépendantes de logiciels non conformes aux « DFSG » et donc ne peuvent être mises dans la section « main » de la distribution ; si le logiciel lui-même est conforme aux « DFSG » il peut être mis dans la section « contrib ». Toutes les versions connues de « OSF-Motif » autorisent la redistribution sans restriction de binaires liés de façon statique ou dynamique à cette bibliothèque, mais c'est au responsable de paquet de déterminer si la licence de la version de « Motif » qu'il possède le permet.
Les programmes et modules Perl suivront les règles concernant Perl.
On peut trouver ces règles dans le fichier perl-policy du paquet
debian-policy. Elles sont aussi disponibles sur les miroirs web
de Debian, /doc/packaging-manuals/perl-policy/
.
Veuillez consulter le « Debian Emacs Policy » pour les détails concernant la création de paquets de programmes emacs lisp.
On peut trouver les règles concernant Emacs dans le fichier
debian-emacs-policy.gz
du paquet emacsen-common
package. Elles sont aussi disponibles sur les miroirs web de Debian,
/doc/packaging-manuals/debian-emacs-policy
.
Les permissions de /var/lib/games sont 755 , propriétaire root et groupe root.
Chaque jeu décide de ses propres règles de sécurité.
Les jeux qui demandent des accès privilégiés et protégés à des fichiers de scores, de sauvegardes de parties, etc., peuvent appartenir à root.games et être exécutables par le groupe games (mode 2755) et doivent utiliser des fichiers et des répertoires avec des permissions appropriées (770 root.games par exemple). Ils ne doivent pas être exécutable par un utilisateur (set-user-id), car cela entraîne des problèmes de sécurité. Si un attaquant arrive à corrompre un jeu « set-user-id », il peut alors remplacer l'exécutable d'autres utilisateurs, forçant les autres joueurs de ces jeux à exécuter un cheval de Troie. Avec un programme « set-group-id », l'attaquant n'a accès qu'à des données de jeu moins importantes. S'il veut accéder aux comptes des autres joueurs, cela lui demandera des efforts beaucoup plus importants.
Certains paquets, comme les programmes « fortune », sont configurés par leurs auteurs originaux pour interdire la lecture de leurs fichiers de données ou d'autres informations statiques, de manière qu'ils ne puissent être accessibles que par les programmes « set-id » fournis. Vous ne ferez pas de même dans un paquet Debian : n'importe qui peut télécharger le fichier .deb et y lire les données, cela n'a donc pas de sens d'avoir des fichiers non lisibles. Créer des fichiers accessibles en lecture implique aussi que vous n'avez pas à construire des programmes « set-id », ce qui réduit le risque de failles de sécurité.
Conformément au « FHS », les binaires des jeux seront installés dans
le répertoire /usr/games
. Cela s'applique aussi aux jeux
utilisant le système X Window. On installera les pages de manuel des
jeux (« X » et « non-X ») dans
/usr/share/man/man6
.
[ 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