[ précédent ] [ Table des matières ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ 13 ] [ 14 ] [ 15 ] [ 16 ] [ suivant ]


La FAQ Debian GNU/Linux
Chapitre 11 - Personnaliser votre installation de Debian GNU/Linux


11.1 Comment puis-je m'assurer que tous les programmes utilisent le même format de papier ?

Installez le paquet libpaper1, il vous sera demandé d'indiquer le format de papier utilisé sur le système. Cette configuration sera sauvegardée dans le fichier /etc/papersize.

Les utilisateurs peuvent modifier la configuration du format de papier en utilisant la variable d'environnement PAPERSIZE. Pour plus d'informations, reportez-vous à la page de manuel papersize(5).


11.2 Comment autoriser l'accès aux périphériques matériels sans compromettre la sécurité ?

La plupart des fichiers de périphérique dans le répertoire /dev appartiennent à des groupes prédéfinis. Par exemple, /dev/fd0 appartient au groupe floppy et /dev/dsp au groupe audio.

Si vous souhaitez que certains utilisateurs puissent accéder à ces périphériques, vous devez juste ajouter les utilisateurs dans le groupe du périphérique. Faites

     adduser utilisateur groupe

Cette méthode vous permet de ne pas changer les permissions sur le fichier du périphérique.

Si vous effectuez cette opération depuis l'interpréteur de commandes d'un utilisateur ou en utilisant une interface graphique, vous devez vous déconnecter puis vous reconnecter pour devenir effectivement un membre de ce groupe. Pour vérifier à quels groupes vous appartenez, lancez la commande groups.

Faites attention, car depuis l'introduction de udev, il se peut que vous modifiez les droits d'un périphérique qui seront de toute manière réglés au démarrage du système. Si cela vous arrive, vous devez ajuster les règles dans /etc/udev.


11.3 Comment charger une police pour la console au démarrage de Debian ?

Les paquets kbd et console-tools permettent cela. Éditez les fichiers /etc/kbd/config ou /etc/console-tools/config.


11.4 Comment configurer les paramètres par défaut des programmes X11 ?

Les programmes X de Debian installent leurs données de configuration dans le répertoire /etc/X11/app-defaults/. Si vous souhaitez personnaliser globalement les applications X, mettez vos personnalisations dans ces fichiers. Ils sont considérés comme fichiers de configuration, donc leur contenu sera conservé pendant les mises à jour.


11.5 Chaque distribution semble avoir une méthode de démarrage différente. Qu'en est-il de Debian ?

Like all Unices, Debian boots up by executing the program init [6]. The configuration file for init (which is /etc/inittab) specifies that the first script to be executed should be /etc/init.d/rcS. This script runs all of the scripts in /etc/rcS.d/ by forking subprocess to perform initialization such as to check and to mount file systems, to load modules, to start the network services, to set the clock, and to perform other initialization.

Après avoir fini le processus de démarrage, init exécute tous les scripts de démarrage du niveau d'exécution (« runlevel ») par défaut (ce niveau d'exécution est indiqué par le champs id du fichier /etc/inittab ). Comme la plupart des Unix compatibles System V, Linux a sept niveaux d'exécution :

Les systèmes Debian sont configurés avec id=2, ce qui implique que le niveau d'exécution par défaut est '2' lorsqu'on entre dans l'état multi-utilisateur et ce sont les scripts de /etc/rc2.d/ qui seront exécutés.

Debian uses dependency-based boot ordering through insserv, using the LSB headers in each script under /etc/init.d/, as well as parallel concurrent booting through the use of startpar to speed up the boot process.

The scripts in any of the directories, /etc/rcN.d/ are just symbolic links back to scripts in /etc/init.d/. However, the names of the files in each of the /etc/rcN.d/ directories are selected to indicate the way the scripts in /etc/init.d/ will be run. Specifically, before entering any runlevel, all the scripts beginning with 'K' are run; these scripts kill services. Then all the scripts beginning with 'S' are run; these scripts start services. The two-digit number following the 'K' or 'S' indicates the order in which the script is run. Lower numbered scripts are executed first.

Cette approche fonctionne parce que les scripts de /etc/init.d/ prennent tous un paramètre qui peut être « start », « stop », « reload », « restart » ou « force-reload » et puis exécuteront la fonction indiquée par le paramètre. Ces scripts peuvent être aussi utilisés après le démarrage du système, pour contrôler divers services.

Par exemple, avec l'argument « reload » la commande

     /etc/init.d/sendmail reload

sends the sendmail daemon a signal to reread its configuration file.

Note that invoke-rc.d should not be used to call the /etc/init.d/ scripts, service should be used instead.


11.6 What other facilities are provided to customize the boot process besides rc.local?

The rc.local script is executed at the end of each multiuser runlevel. In Debian it is configured to do nothing. This provides customisation of the boot process, but might not be sufficient for all situations.

Supposons que vous ayez besoin d'exécuter le script foo au démarrage ou lors du passage à un niveau d'exécution (System V) particulier. L'administrateur devrait :

On pourrait par exemple, exécuter le script foo au démarrage, en le mettant dans /etc/init.d/ et en lançant la commande update-rc.d foo defaults 19. Le paramètre defaults se rapporte aux niveaux d'exécution, c'est-à-dire (du moins en l'absence de tout paragraphe de commentaires LSB) que le service est démarré des niveaux 2 à 5 et est arrêté aux niveaux 0, 1 et 6. Toute directive LSB Default-Start ou Default-Stop in dans le script foo a la priorité dans la version sysv-rc de update-rc.d, mais est ignorée dans l'actuelle (v0.8.10) version file-rc de update-rc.d. Le paramètre 19 permet de s'assurer que le script foo sera exécuté après la fin de l'exécution de tous les scripts avec un paramètre inférieur à 19 et avant tous les scripts avec un nombre supérieur ou égal à 20.


11.7 Comment le système de gestion de paquets traite-t-il les paquets qui contiennent des fichiers de configuration pour d'autres paquets ?

Certains utilisateurs souhaitent créer, par exemple, un nouveau serveur en installant des paquets provenant de Debian et un paquet créé localement, contenant des fichiers de configuration. Ce n'est généralement pas une bonne idée, parce que dpkg ne connaîtra pas ces fichiers de configuration s'ils sont dans un paquet différent et risque de modifier les fichiers de configuration quand l'un des paquets initiaux sera mis à jour.

Au lieu de cela, créez un paquet local pour modifier les fichiers de configuration des paquets de Debian. Puis dpkg et le reste du système de gestion de paquets verront que les fichiers ont été modifiés par l'administrateur et n'essayeront pas de les écraser quand ces paquets sont mis à jour.


11.8 Comment remplacer un fichier installé par un paquet, de sorte qu'une version différente puisse être employée à la place ?

Supposez qu'un administrateur ou un utilisateur local souhaite utiliser un programme « login-local » plutôt que le programme « login » fourni par le paquet Debian login.

Ne pas faire :

Le système de gestion des paquets ne saura rien de ce changement et écrasera simplement votre /bin/login personnalisé à chaque fois que login (ou tout autre paquet fournissant /bin/login) sera installé ou mis à jour.

Faites, plutôt

Exécutez dpkg-divert --list pour obtenir la liste des remplacements actuellement actifs sur votre système.

Pour plus d'informations, lisez la page de manuel dpkg-divert(8).


11.9 Comment puis-je inclure mon paquet construit localement dans la liste des paquets disponibles connus par le système de gestion des paquets ?

Lancer la commande :

     dpkg-scanpackages BIN_DIR OVERRIDE_FILE [PATHPREFIX] > mes_Paquets

Où :

Une fois que vous avez construit le fichier mes_Paquets, appelez le système de gestion des paquets en utilisant la commande :

     dpkg --merge-avail mes_Paquets

Si vous utilisez APT, vous pouvez aussi ajouter votre dépôt local dans votre fichier sources.list(5).


11.10 Certains utilisateurs apprécient mawk, d'autres gawk ; certains utilisent vim, d'autres elvis ; certains préfèrent trn, d'autres tin ; comment Debian gère-t-elle la diversité ?

Il y a plusieurs cas où deux paquets fournissent deux versions différentes d'un programme et où tous les deux fournissent la même fonctionnalité. Les utilisateurs pourraient préférer un plutôt qu'un autre inhabituel, ou parce que l'interface utilisateur d'un paquet est d'une façon ou d'une autre plus agréable que l'interface des autres. D'autres utilisateurs sur le même système pourraient faire des choix différents.

Debian emploie un système de paquets « virtuels » pour permettre aux administrateurs de choisir (ou laisser les utilisateurs choisir) leurs outils favoris quand il y en a plusieurs qui fournissent la même fonctionnalité de base, en répondant aux exigences de dépendance du paquet sans indiquer de paquet particulier.

Par exemple, il peut y avoir sur un système deux versions différentes d'un programme de lecture de nouvelles. L'installation d'un serveur de nouvelles peut recommander la présence d'un programme de lecture de nouvelles sur le système et laisser le choix de tin ou de trn aux utilisateurs. Ceci est possible parce que les paquets tin et trn fournissent le paquet virtuel news-reader. Le programme qui sera appelé est déterminé par le lien symbolique /etc/alternatives/news-reader pointant vers le programme choisi, par exemple /usr/bin/trn.

Un lien simple est insuffisant pour gérer l'utilisation complète d'un programme alternatif ; normalement, les pages de manuel et probablement d'autres fichiers de support doivent être aussi accessibles. Le script Perl update-alternatives fournit le moyen de s'assurer que le système choisit bien par défaut tous les fichiers associés au paquet indiqué.

Par exemple, pour vérifier quel exécutable fournit le gestionnaire de fenêtres (x-window-manager), exécutez :

     update-alternatives --display x-window-manager

Si vous souhaitez le modifier, tapez la commande :

     update-alternatives --config x-window-manager

et suivez les instructions affichées à l'écran (saisissez le nombre correspondant à votre choix)

Si un paquet ne s'enregistre pas lui-même comme gestionnaire de fenêtres pour différentes raisons, (remplissez un rapport de bogue si c'est une erreur) ou si vous utilisez un gestionnaire de fenêtres présent dans le répertoire /usr/local, les choix sur l'écran ne contiendront pas votre entrée préférée. Vous pouvez mettre à jour le lien par des options de ligne de commande, comme ceci :

     update-alternatives --install /usr/bin/x-window-manager \
       x-window-manager /usr/local/bin/wmaker-cvs 50

Le premier paramètre de l'option « --install » est un lien symbolique qui pointe vers /etc/alternatives/NOM, où NOM est le deuxième paramètre. Le troisième paramètre est le programme vers lequel /etc/alternatives/NOM pointe et le quatrième paramètre est la priorité (une plus grande valeur signifie que l'alternative sera très probablement sélectionnée automatiquement).

Pour supprimer une alternative que vous avez ajoutée, lancez simplement :

     update-alternatives --remove x-window-manager /usr/local/bin/wmaker-cvs

[ précédent ] [ Table des matières ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] [ 8 ] [ 9 ] [ 10 ] [ 11 ] [ 12 ] [ 13 ] [ 14 ] [ 15 ] [ 16 ] [ suivant ]


La FAQ Debian GNU/Linux

version 5.0.3, 16 October 2014

Vous trouverez la liste des auteurs à Auteurs de la FAQ Debian