Copyright © 2008 Red Hat, Inc.
Copyright © 2008 Red Hat, Inc. This material may only be distributed subject to the terms and conditions set forth in the Open Publication License, V1.0 or later with the restrictions noted below (the latest version of the OPL is presently available at http://www.opencontent.org/openpub/).
Distribution of substantively modified versions of this document is prohibited without the explicit permission of the copyright holder.
Distribution of the work or derivative of the work in any standard (paper) book form for commercial purposes is prohibited unless prior permission is obtained from the copyright holder.
Red Hat and the Red Hat "Shadow Man" logo are registered trademarks of Red Hat, Inc. in the United States and other countries.
All other trademarks referenced herein are the property of their respective owners.
The GPG fingerprint of the security@redhat.com key is:
CA 20 86 86 2B D6 9D FC 65 F6 EC C4 21 91 80 CD DB 42 A6 0E
1801 Varsity Drive Raleigh, NC 27606-2072 USA Phone: +1 919 754 3700 Phone: 888 733 4281 Fax: +1 919 754 3701 PO Box 13588 Research Triangle Park, NC 27709 USA
January 2008
Historique des versions | ||||
---|---|---|---|---|
Version 5.2-11 | Wed May 21 2008 |
Michael Hideo Smith <mhideo@redhat.com>
|
||
|
This Deployment Guide documents relevant information regarding the deployment, configuration and administration of Red Hat Enterprise Linux 5.2.
autofs
/etc/exports
portmap
smb.conf
httpd
httpd.conf
vsftpd
vsftpd
vsftpd
/etc/openldap/schema/
/sysconfig/
/etc/sysconfig/
/etc/sysconfig/amd
/etc/sysconfig/apmd
/etc/sysconfig/arpwatch
/etc/sysconfig/authconfig
/etc/sysconfig/autofs
/etc/sysconfig/clock
/etc/sysconfig/desktop
/etc/sysconfig/dhcpd
/etc/sysconfig/exim
/etc/sysconfig/firstboot
/etc/sysconfig/gpm
/etc/sysconfig/hwconf
/etc/sysconfig/i18n
/etc/sysconfig/init
/etc/sysconfig/ip6tables-config
/etc/sysconfig/iptables-config
/etc/sysconfig/irda
/etc/sysconfig/keyboard
/etc/sysconfig/kudzu
/etc/sysconfig/named
/etc/sysconfig/network
/etc/sysconfig/nfs
/etc/sysconfig/ntpd
/etc/sysconfig/radvd
/etc/sysconfig/samba
/etc/sysconfig/selinux
/etc/sysconfig/sendmail
/etc/sysconfig/spamassassin
/etc/sysconfig/squid
/etc/sysconfig/system-config-securitylevel
/etc/sysconfig/system-config-selinux
/etc/sysconfig/system-config-users
/etc/sysconfig/system-logviewer
/etc/sysconfig/tux
/etc/sysconfig/vncservers
/etc/sysconfig/
Bienvenue au Guide de déploiement de Red Hat Enterprise Linux.
Le Guide de déploiement de Red Hat Enterprise Linux contient des informations sur la personnalisation de votre système Red Hat Enterprise Linux, correspondant à vos besoins. Si vous recherchez un guide approfondi et pratique pour configurer et personnaliser votre système, ce manuel est idéal pour vous.
Ce guide présuppose que vous avez une connaissance de base de votre système Red Hat Enterprise Linux. Si vous avez besoin d'assistance pour installer Red Hat Enterprise Linux, veuillez consulter le Guide d'installation de Red Hat Enterprise Linux.
N'hésitez pas à nous contacter si vous découvrez des erreurs dans le Guide de déploiement de Red Hat Enterprise Linux, ou si vous souhaitez nous faire part de vos suggestions pour améliorer ce manuel ! À cet effet, veuillez soumettre un rapport dans Bugzilla (http://bugzilla.redhat.com/bugzilla/
) en sélectionnant l'option Deployment_Guide
.
Si vous avez des suggestions pour améliorer la documentation, veuillez fournir le plus de précisons possibles. Dans le cas d'une erreur, indiquez le numéro de section où elle se trouve et ajoutez un extrait du texte qui l'entoure, afin que nous puissions facilement la retrouver.
Tous les logiciels dans un système Red Hat Enterprise Linux sont divisés en paquetages RPM qui peuvent être installés, mis à jour ou supprimés. Cette section décrit comment gérer les paquetages RPM dans un système Red Hat Enterprise Linux en utilisant des outils graphiques et de ligne de commande.
Table des matières
Le gestionnaire de paquetages (RPM, de l'anglais Red Hat Package Manager), est un système open de gestion des paquetages qui tourne sur Red Hat Enterprise Linux et qui peut également être exécuté sur d'autres systèmes Linux et UNIX. Red Hat, Inc. encourage d'ailleurs tous les vendeurs à utiliser RPM pour leurs propres produits. RPM est distribué avec les conditions légales fixées par la licence publique générale (GPL).
Cet utilitaire fonctionne uniquement avec des paquetages conçus pour le traitement par le paquetage rpm
. RPM facilite la mise à jour du système pour l'utilisateur final. En effet, il suffit de quelques commandes pour effectuer l'installation, la désinstallation et la mise à jour des paquetages RPM. RPM maintient aussi une base de données des paquetages installés et de leurs fichiers, ce qui vous permet de procéder à des recherches et des vérifications approfondies dans votre système. Si vous préférez travailler au moyen d'une interface graphique, utilisez l'Outil de gestion des paquetages pour exécuter de nombreuses commandes RPM. Reportez-vous au Chapitre 2, Outil de gestion des paquetages pour obtenir de plus amples informations.
Lors de l'installation d'un paquetage, veuillez vous assurer qu'il est compatible avec votre système et votre architecture. Généralement, cela peut être déterminé par le nom du paquetage.
En outre, durant les mises à jour, RPM manipule les fichiers de configuration avec soin afin d'éviter que vos personnalisations ne soient perdues — chose que vous ne pourriez faire avec des fichiers .tar.gz
ordinaires.
Si vous êtes un développeur, RPM vous permet de prendre le code source du logiciel et de le transformer en paquetage source et binaire pour l'utilisateur final. Ce processus est assez simple et il est piloté depuis un seul fichier et des correctifs (ou patches) facultatifs que vous créez. Cette démarcation claire entre le code source d'origine et vos correctifs, ainsi que les instructions de création facilitent la maintenance du paquetage alors que de nouvelles versions du logiciel sont publiées.
Étant donné que RPM apporte des changements au système, il est nécessaire d'être connecté en tant que super-utilisateur (ou root) pour pouvoir installer, supprimer ou mettre à niveau un paquetage RPM.
Pour bien comprendre comment utiliser RPM, il est utile de comprendre les objectifs qui ont guidé sa conception, à savoir :
Grâce à RPM, vous pouvez mettre à niveau les composants individuels de votre système sans devoir tout réinstaller. Lorsque vous obtenez une nouvelle version d'un système d'exploitation fondé sur RPM (comme Red Hat Enterprise Linux), vous n'avez pas à le réinstaller en entier sur votre ordinateur (contrairement à la situation avec des systèmes d'exploitation fondés sur des systèmes de paquetages différents). RPM permet une mise à niveau "intelligente", complètement automatisée et sans démontage de votre système. Les fichiers de configuration des paquetages sont préservés lors de mises à niveau, ainsi, vous ne perdrez pas vos personnalisations. Aucun fichier de mise à niveau spécial n'est requis pour mettre à niveau un paquetage car le même fichier RPM est utilisé pour installer et mettre à niveau le paquetage sur votre système.
RPM est conçu pour offrir de puissantes options de recherche. Vous pouvez ainsi chercher dans votre base de données des paquetages ou des fichiers spécifiques et trouver facilement à quel paquetage appartient un fichier et sa provenance. Les fichiers contenus dans les paquetages RPM sont stockés dans des archives compressées et dotées d'un en-tête binaire qui contient des informations utiles au sujet des paquetages et de leur contenu ; la recherche de paquetages individuels est donc facile et rapide.
La possibilité de vérifier les paquetages est une autre fonctionnalité importante de RPM. Si vous vous inquiétez à l'idée d'avoir supprimé un fichier important d'un des paquetages, vous n'avez qu'à vérifier le paquetage en question. Ce faisant, toute anomalie vous sera rapportée. À ce stade, vous pourrez réinstaller le paquetage si cela s'avère nécessaire. Cependant, tous les fichiers de configuration que vous avez modifiés sont préservés lors de la réinstallation.
L'un des objectifs principaux de l'application était de permettre l'utilisation de sources logicielles d'origine, c'est-à-dire telles qu'elles ont été écrites par les auteurs originaux du logiciel. RPM est fourni avec les sources d'origine et les retouches qui y ont été ajoutées ainsi qu'avec les instructions complètes de création. Cela représente un gros avantage pour de nombreuses raisons. Par exemple, si une nouvelle version est publiée, vous n'avez pas nécessairement à recommencer à zéro pour la compiler. Il vous suffit de jeter un oeil sur les correctifs pour voir ce que vous devez effectuer. Toutes les valeurs par défaut déjà compilées et les changements apportés pour faire en sorte que le logiciel soit créé correctement, peuvent être visualisés au moyen de cette technique.
Le désir de maintenir les sources d'origine ne peut sembler important qu'au développeur, mais cela assure également des logiciels de qualité supérieure pour l'utilisateur final.
RPM a cinq modes d'opération de base (sans compter la construction de paquetages) : installation, désinstallation, mise à jour, recherche et vérification. Cette section vous donne un aperçu de chacun de ces modes. Pour obtenir plus d'informations et connaître les différentes options, consultez rpm --help
ou man rpm
. Reportez-vous également à la Section 1.5, « Ressources supplémentaires ».
Avant d'utiliser un RPM, vous devez savoir où les trouver. Une recherche sur Internet fournit de nombreux référentiels de RPM, mais si vous recherchez des paquetages RPM construits par Red Hat, vous les trouverez aux emplacements suivants :
Les CD-ROM de Red Hat Enterprise Linux
La page d'errata de Red Hat se trouve à l'adresse suivante : http://www.redhat.com/apps/support/errata/
Red Hat Network — Reportez-vous au Chapitre 4, Red Hat Network pour obtenir de plus amples informations sur Red Hat Network
Les noms de fichiers des paquetages RPM ressemblent généralement à ceci : foo-1.0-1.i386.rpm
. Le nom du fichier comprend le nom du paquetage (foo
), la version (1.0
), l'édition(1
) et l'architecture (i386
). Rien de plus simple que d'installer un paquetage ; connectez-vous en tant qu'utilisateur root et saisissez la commande suivante à l'invite du shell :
rpm -ivh foo-1.0-1.i386.rpm
Alternatively, the following command can also be used:
rpm -Uvh foo-1.0-1.i386.rpm
Si l'installation est réussie, la sortie suivante apparaîtra à l'écran :
Preparing... ########################################### [100%] 1:foo ########################################### [100%]
Comme vous pouvez le constater, RPM affiche le nom du paquetage, puis une succession de symboles dièse pour indiquer la progression de l'installation du paquetage.
La signature d'un paquetage est vérifiée automatiquement lors de l'installation ou de la mise à niveau d'un paquetage. La signature confirme que le paquetage a été signé par un utilisateur autorisé. Par exemple, si la vérification de la signature échoue, un message d'erreur semblable à l'extrait ci-dessous apparaîtra à l'écran :
error: V3 DSA signature: BAD, key ID 0352860f
S'il s'agit d'une nouvelle signature (en-tête uniquement), un message d'erreur semblable à l'extrait ci-dessous apparaîtra à l'écran :
error: Header V3 DSA signature: BAD, key ID 0352860f
Si la clé nécessaire à la vérification de la signature n'est pas installée sur votre système, le message contiendra le mot NOKEY
comme dans l'extrait ci-dessous :
warning: V3 DSA signature: NOKEY, key ID 0352860f
Reportez-vous à la Section 1.3, « Vérification de la signature d'un paquetage » pour plus d'informations sur la vérification de la signature d'un paquetage.
Si vous installez un paquetage de noyau, utilisez plutôt la commande rpm -ivh
. Reportez-vous au Chapitre 31, Mise à niveau du noyau manuellement pour plus d'informations.
Si le paquetage du même nom et de la même version est déjà installé, le message ci-dessous apparaîtra à l'écran :
Preparing... ########################################### [100%] package foo-1.0-1 is already installed
Si vous désirez poursuivre l'installation bien que la même version du paquetage soit déjà installée, vous pouvez utiliser l'option --replacepkgs
ci-dessous pour indiquer à RPM de ne pas tenir compte du message d'erreur :
rpm -ivh --replacepkgs foo-1.0-1.i386.rpm
entr
Cette option peut s'avérer utile lorsque des fichiers installés du paquetage RPM ont été supprimés ou lorsque vous voulez installer les fichiers de configuration originaux du paquetage RPM.
Si vous tentez d'installer un paquetage contenant un fichier déjà installé par un autre paquetage, un message d'erreur semblable à l'extrait ci-dessous apparaîtra à l'écran :
Preparing... ########################################### [100%] file /usr/bin/foo from install of foo-1.0-1 conflicts with file from package bar-2.0.20
Pour faire en sorte que RPM ignore cette erreur, utilisez l'option --replacefiles
:
rpm -ivh --replacefiles foo-1.0-1.i386.rpm
Les paquetages RPM peuvent dépendre d'autres paquetages, ce qui signifie qu'ils requièrent l'installation d'autres paquetages pour fonctionner correctement. Si vous essayez d'installer un paquetage pour lequel il existe une dépendance non-résolue, une sortie semblable à l'extrait suivant apparaîtra à l'écran :
error: Failed dependencies: bar.so.2 is needed by foo-1.0-1 Suggested resolutions: bar-2.0.20-3.i386.rpm
Si vous installez un paquetage faisant partie de l'ensemble de CD-ROM de Red Hat Enterprise Linux, il vous proposera généralement le(s) paquetage(s) nécessaire(s) à la résolution de la dépendance. Localisez le paquetage en question sur les CD-ROM de Red Hat Enterprise Linux ou sur Red Hat Network et ajoutez-le à la commande comme dans l'extrait ci-dessous :
rpm -ivh foo-1.0-1.i386.rpm bar-2.0.20-3.i386.rpm
Si l'installation des deux paquetages est réussie, une sortie semblable à l'extrait suivant apparaîtra à l'écran :
Preparing... ########################################### [100%] 1:foo ########################################### [ 50%] 2:bar ########################################### [100%]
Si aucun paquetage n'est suggéré pour résoudre la dépendance, vous pouvez essayer d'utiliser l'option --redhatprovides
pour déterminer le paquetage contenant le fichier requis. Pour utiliser cette option, le paquetage rpmdb-redhat
doit être installé sur votre système.
rpm -q --redhatprovides bar.so.2
Si le paquetage contenant bar.so.2
se trouve dans la base de données installée du paquetage rpmdb-redhat
, le nom du paquetage apparaîtra à l'écran comme dans l'extrait suivant :
bar-2.0.20-3.i386.rpm
Si vous souhaitez néanmoins forcer l'installation, ce qui peut provoquer le mauvais fonctionnement du paquetage, utilisez l'option --nodeps
.
La désinstallation d'un paquetage est aussi simple que son installation. Entrez simplement la commande suivante à l'invite du shell :
rpm -e foo
Notez que nous avons utilisé le nom de paquetage foo
, et non pas celui du fichier original du paquetage foo-1.0-1.i386.rpm
. Pour désinstaller un paquetage, remplacez foo
par le nom d'origine du paquetage en question.
Une erreur de dépendance peut se produire lors de la désinstallation d'un paquetage si un autre paquetage installé dépend de celui que vous essayez de supprimer. Par exemple :
error: Failed dependencies: foo is needed by (installed) bar-2.0.20-3.i386.rpm
Pour que RPM ignore cette erreur et désinstalle le paquetage malgré tout, ce qui peut empêcher le paquetage qui en dépend de fonctionner correctement, utilisez l'option --nodeps
.
La mise à jour d'un paquetage est semblable à son installation. Entrez la commande suivante à l'invite du shell :
rpm -Uvh foo-2.0-1.i386.rpm
Lors de la mise à niveau d'un paquetage, RPM désinstalle automatiquement toutes les anciennes versions du paquetage foo
. Notez que l'option -U
installera également des paquetages, même lorsqu'aucune version antérieure du paquetage n'est installée.
Il n'est pas recommandé d'utiliser l'option -U
pour installer des paquetages du noyau vu que RPM remplace le paquetage du noyau précédent. Cette opération n'affecte pas un système en cours d'exécution, mais si le nouveau noyau ne peut pas démarrer lors de votre prochain redémarrage, aucun autre noyau ne sera disponible.
L'option -i
ajoute le noyau à votre menu de démarrage GRUB (/etc/grub.conf
). De la même manière, si vous supprimez un ancien noyau obsolète, il sera supprimé de GRUB.
Comme RPM effectue une mise à jour intelligente des paquetages avec des fichiers de configuration, le message suivant peut apparaître à l'écran :
saving /etc/foo.conf as /etc/foo.conf.rpmsave
Ce message signifie que les changements que vous avez apportés au fichier de configuration n'offrent peut-être pas de compatibilité descendante avec le nouveau fichier de configuration du paquetage. Aussi, RPM sauvegarde le fichier original et installe le nouveau. Vous devez ensuite déterminer les différences entre les deux fichiers de configuration et trouver une solution le plus rapidement possible, afin d'assurer que votre système continue de fonctionner correctement.
Si vous tentez de mettre à niveau un paquetage avec un ancien numéro de version (c'est-à-dire si une version plus récente du paquetage est déjà installée), la sortie est similaire à ce qui suit :
package foo-2.0-1 (which is newer than foo-1.0-1) is already installed
Pour faire en sorte que le paquetage RPM soit mis à jour malgré tout, utilisez l'option --oldpackage
:
rpm -Uvh --oldpackage foo-1.0-1.i386.rpm
L'actualisation d'un paquetage est semblable à sa mise à niveau, mais seuls des paquetages existants sont mis à niveau. Entrez la commande suivante à l'invite du shell :
rpm -Fvh foo-1.2-1.i386.rpm
L'option d'actualisation de RPM compare les versions de paquetages spécifiées dans la ligne de commande aux versions déjà installées sur le système. Lorsqu'une version plus récente d'un paquetage déjà installé est traitée par l'option d'actualisation de RPM, la mise à niveau vers la version plus récente intervient. Toutefois, l'option d'actualisation de RPM n'installe pas un paquetage si un paquetage du même nom n'a pas été précédemment installé. La situation est différente avec l'option de mise à niveau de RPM, étant donné que la mise à niveau installe effectivement les paquetages, qu'une version antérieure soit déjà installée ou non.
L'option d'actualisation de RPM fonctionne aussi bien pour des paquetages sélectionnés individuellement que pour des groupes de paquetages. Si par exemple, vous venez tout juste de télécharger un grand nombre de paquetages différents et désirez mettre à niveau seulement les paquetages déjà installés sur votre système, utilisez l'option d'actualisation. Ainsi, vous n'aurez pas à supprimer les paquetages indésirables du groupe téléchargé, avant d'utiliser RPM.
Dans ce cas, exécutez la commande suivante :
rpm -Fvh *.rpm
RPM met automatiquement à niveau les paquetages qui sont déjà installés.
La base de données RPM stocke des informations sur tous les paquetages RPM installés dans votre système. Elles sont stockées dans le répertoire /var/lib/rpm/
, et utilisées pour demander quels paquetages sont installés, quelle version est celle de chaque paquetage, et entre autres, tout changement effectué dans chaque fichier du paquetage depuis l'installation.
Pour interroger cette base de données, utilisez l'option -q
. La commande rpm -q
affiche le nom du paquetage, la version, et le numéro de l'édition du paquetage installé package name
. Par exemple, utilisez package name
rpm -q foo
pour interroger le paquetage installé foo
pourra générer la sortie suivante :
foo-2.0-1
Vous pouvez également utiliser les Options de sélection de paquetage avec -q
pour afiner ou qualifier votre demande :
-a
interroge tous les paquetages actuellement installés.
-f
— interroge la base de données RPM pour savoir quel paquetage est propriétaire de <filename>
. Lorsque vous spécifiez un fichier, vous devez indiquer son chemin d'accès complet (par exemple, <filename>
rpm -f
).
/bin/ls
-p
— interroge le paquetage non-installé <packagefile>
.
<packagefile>
Il y a plusieurs manières de spécifier les informations à afficher sur les paquetages recherchés. Les options suivantes sont utilisées pour sélectionner le type d'informations recherchées. Elles sont appelées options de demande d'informations.
-i
affiche des informations sur le paquetage, telles que le nom, la description, la version, la taille, la date de création, l'éditeur, et autres informations diverses.
-l
affiche la liste des fichiers contenus dans le paquetage.
-s
affiche l'état de tous les fichiers du paquetage.
-d
affiche la liste des fichiers de documentation (pages de manuel, pages d'informations, fichiers README, etc.).
-c
affiche la liste des fichiers de configuration. Il s'agit de fichiers que vous modifiez après l'installation pour adapter et personnaliser le paquetage à votre système (par exemple sendmail.cf
, passwd
, inittab
, etc.).
Pour les options qui affichent des listes de fichiers, vous pouvez ajouter -v
à la commande pour obtenir les listes dans un format ls -l
familier.
La vérification d'un paquetage permet de comparer les informations sur les fichiers d'un paquetage installé à celles du paquetage original. La vérification compare, entre autres, la taille, la somme MD5, les autorisations, le type, le propriétaire et le groupe de chaque fichier.
La commande rpm -V
vérifie un paquetage. Vous pouvez utiliser n'importe laquelle des options de spécification de paquetage de la liste pour spécifier les paquetages que vous souhaitez vérifier. Une utilisation simple est rpm -V foo
, qui vérifie si tous les fichiers du paquetage foo
sont tels qu'ils étaient lors de leur installation initiale. Par exemple :
Pour vérifier un paquetage contenant un fichier particulier :
rpm -Vf /usr/bin/foo
Dans cet exemple, /usr/bin/foo
est le chemin absolu vers le fichier utilisé pour interroger un paquetage.
Pour vérifier TOUS les paquetages installés à travers le système :
rpm -Va
Pour comparer un paquetage installé à un fichier de paquetage RPM :
rpm -Vp foo-1.0-1.i386.rpm
Cette commande peut être utile si vous pensez que vos bases de données RPM sont corrompues.
Si la vérification est bonne, elle ne fournit aucune sortie. En revanche, s'il existe des discordances, elles sont affichées. Le format de la sortie est une chaîne de huit caractères (un c
indique un fichier de configuration) et le nom du fichier. Chacun des huit caractères indique le résultat d'une comparaison entre un attribut du fichier et la valeur de cet attribut enregistrée dans la base de données RPM. Un point (.
) signifie que le test a réussi. Les caractères suivants indiquent des discordances spécifiques :
5
— MD5 checksum
S
— taille de fichier
L
— lien symbolique
T
— date de modification du fichier
D
— périphérique
U
— utilisateur
G
— groupe
M
— mode (comprend les permissions et le type de fichier)
?
— fichier non lisible
Si vous voyez un résultat affiché, essayez de déterminer s'il est préférable de supprimer ou de réinstaller le paquetage, ou de résoudre le problème autrement.
Si vous désirez vous assurer qu'un paquetage n'a pas été corrompu ou manipulé, vous n'avez qu'à examiner la somme md5 en entrant la commande suivante à l'invite du shell (remplacez <rpm-file>
par le nom de fichier du paquetage RPM) :
rpm -K --nosignature <rpm-file>
Le message
s'affiche à l'écran. Ce court message indique que le fichier n'a pas été corrompu par le téléchargement. Pour obtenir un message plus détaillé, remplacez <rpm-file>
: md5 OK-K
par -Kvv
dans la commande.
Toutefois, à quel point le développeur du paquetage est-il fiable ? Si le paquetage est signé à l'aide de la clé GnuPG du développeur, vous avez l'assurance que le développeur est bien qui il prétend être.
Un paquetage RPM peut être signé à l'aide de Gnu Privacy Guard (ou GnuPG), pour en assurer la fiabilité lors d'un téléchargement.
GnuPG est un outil permettant de sécuriser les communications ; il s'agit d'un outil de remplacement complet et gratuit de la technologie de cryptage de PGP, un programme de protection électronique de l'information. Avec GnuPG, vous pouvez authentifier la validité de documents, crypter et décrypter des données à destination ou en provenance de vos correspondants. Cet outil peut également décrypter et vérifier des fichiers PGP 5.x
.
Lors de l'installation, GnuPG est installé par défaut. Ainsi, vous pouvez commencer immédiatement à utiliser GnuPG pour vérifier les paquetages que vous recevez de Red Hat. Vous devez d'abord importer la clé publique de Red Hat.
Pour vérifier des paquetages Red Hat, vous devez importer la clé Red Hat GPG. Pour ce faire, exécutez la commande suivante à une invite du shell :
rpm --import /usr/share/rhn/RPM-GPG-KEY
Pour afficher une liste de toutes les clés installées pour une vérification RPM, exécutez la commande :
rpm -qa gpg-pubkey*
Pour la clé Red Hat, la sortie comprendra :
gpg-pubkey-db42a60e-37ea5438
Pour afficher des détails sur une clé spécifique, utilisez rpm -qi
suivie de la sortie de la commande précédente :
rpm -qi gpg-pubkey-db42a60e-37ea5438
Pour vérifier la signature GnuPG d'un fichier RPM après avoir importé la clé GnuPG du constructeur, utilisez la commande suivante (remplacez <rpm-file>
par le nom de fichier du paquetage RPM) :
rpm -K <rpm-file>
Si tout se passe bien, le message : md5 gpg OK
apparaîtra à l'écran pour indiquer que la signature du paquetage a été vérifiée et qu'il n'est pas corrompu.
RPM est un outil pratique pour gérer votre système ainsi que pour identifier et résoudre des problèmes. Pour mieux comprendre toutes ses options, examinons quelques exemples.
Vous avez peut-être supprimé des fichiers par accident, mais ne savez pas exactement lesquels. Pour vérifier le système complet et identifier ce qui pourrait manquer, exécutez la commande suivante :
rpm -Va
Si certains fichiers ont disparu ou ont été corrompus, il vaut mieux réinstaller le paquetage ou désinstaller, puis réinstaller le paquetage.
Il se peut qu'un jour vous tombiez sur un fichier que vous ne reconnaissez pas. Pour connaître le paquetage auquel il appartient, saisissez simplement :
rpm -qf /usr/bin/ggv
Le résultat devrait ressembler à ceci :
ggv-2.6.0-2
Combinons les deux exemples précédents pour créer le scénario suivant et supposons que vous ayez des problèmes avec le programme /usr/bin/paste
. Vous souhaitez vérifier à quel paquetage il appartient, mais vous ne savez pas à quel paquetage appartient paste
. Saisissez simplement la commande suivante :
rpm -Vf /usr/bin/paste
et la vérification du paquetage s'effectuera.
Vous aimeriez obtenir plus de détails sur un programme particulier ? Il vous suffit d'utiliser la commande suivante pour localiser la documentation fournie avec le paquetage auquel appartient le programme :
rpm -qdf /usr/bin/free
Le résultat devrait ressembler à l'extrait suivant :
/usr/share/doc/procps-3.2.3/BUGS /usr/share/doc/procps-3.2.3/FAQ /usr/share/doc/procps-3.2.3/NEWS /usr/share/doc/procps-3.2.3/TODO /usr/share/man/man1/free.1.gz /usr/share/man/man1/pgrep.1.gz /usr/share/man/man1/pkill.1.gz /usr/share/man/man1/pmap.1.gz /usr/share/man/man1/ps.1.gz /usr/share/man/man1/skill.1.gz /usr/share/man/man1/slabtop.1.gz /usr/share/man/man1/snice.1.gz /usr/share/man/man1/tload.1.gz /usr/share/man/man1/top.1.gz /usr/share/man/man1/uptime.1.gz /usr/share/man/man1/w.1.gz /usr/share/man/man1/watch.1.gz /usr/share/man/man5/sysctl.conf.5.gz /usr/share/man/man8/sysctl.8.gz /usr/share/man/man8/vmstat.8.gz
Vous pourriez aussi découvrir un nouveau paquetage RPM sans toutefois savoir à quoi il sert. Pour trouver des informations à son sujet, utilisez la commande suivante :
rpm -qip crontabs-1.10-7.noarch.rpm
Le résultat devrait ressembler à l'extrait suivant :
Name : crontabs Relocations: (not relocatable) Version : 1.10 Vendor: Red Hat, Inc. Release : 7 Build Date: Mon 20 Sep 2004 05:58:10 PM EDT Install Date: (not installed) Build Host: tweety.build.redhat.com Group : System Environment/Base Source RPM: crontabs-1.10-7.src.rpm Size : 1004 License: Public Domain Signature : DSA/SHA1, Wed 05 Jan 2005 06:05:25 PM EST, Key ID 219180cddb42a60e Packager : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla> Summary : Root crontab files used to schedule the execution of programs. Description : The crontabs package contains root crontab files. Crontab is the program used to install, uninstall, or list the tables used to drive the cron daemon. The cron daemon checks the crontab files to see when particular commands are scheduled to be executed. If commands are scheduled, then it executes them.
Maintenant, vous souhaitez peut-être voir quels fichiers le RPM de crontabs
installe. Pour ce faire, entrez la commande suivante :
rpm -qlp crontabs-1.10-5.noarch.rpm
Le résultat devrait ressembler à l'extrait suivant :
/etc/cron.daily /etc/cron.hourly /etc/cron.monthly /etc/cron.weekly /etc/crontab /usr/bin/run-parts
Ce ne sont que quelques exemples. Vous trouverez sûrement d'autres applications de RPM lors de son utilisation.
RPM est un programme utilitaire très complexe, doté de nombreuses options et méthodes de recherche, d'installation, de mise à jour et de désinstallation de paquetages. Consultez les sources d'informations suivantes pour en savoir plus sur RPM.
rpm --help
— Cette commande permet d'afficher une référence rapide des paramètres de RPM.
man rpm
— La page de manuel relative à RPM donne plus de détails sur les paramètres de RPM que la commande rpm --help
.
http://www.rpm.org/ — Le site Web RPM.
http://www.redhat.com/mailman/listinfo/rpm-list/ — L'emplacement où la liste de diffusion RPM est mise en archive. Pour vous y inscrire, envoyez un courriel à l'adresse suivante : <rpm-list-request@redhat.com>
et saisissez le mot subscribe
dans la ligne objet.
Si vous préférez utiliser une interface graphique pour visionner et gérer les paquetages dans votre système, vous pouvez utiliser l'Outil de gestion des paquetages, mieux connu sous le nom pirut. Cet outil vous permet d'effectuer les tâches élémentaires de gestion des paquetages de votre système à travers une interface facile à utiliser pour supprimer des paquetages installés ou télécharger (et installer) des paquetages compatibles à votre système. Il vous permet aussi de visionner les paquetages installés sur votre système et ceux qui sont disponibles au téléchargement depuis Red Hat Network. Par ailleurs, l'Outil de gestion des paquetages résout automatiquement toutes les dépendances critiques quand vous installez ou supprimez des paquetages de la même façon que le fait la commande rpm
.
Alors que l'Outil de gestion des paquetages peut automatiquement résoudre les dépendances durant l'installation et la suppression des paquetages, il ne peut pas effectuer un installer/supprimer forcé de la même façon que rpm -e --nodeps
ou rpm -U --nodeps
.
Le système X Window est nécessaire pour exécuter l'Outil de gestion des paquetages. Pour lancer l'application, allez à Applications (le menu principal sur le panneau) => Ajouter/Supprimer un logiciel. Sinon, vous pouvez saisir la commande system-config-packages
ou pirut
à l'invite du shell.
Vous pouvez utiliser l'Outil de gestion des paquetages pour rechercher et lister tous les paquetages installés dans votre système, de même que tous les paquetages disponibles au téléchargement. Les balises Navigation, Recherche, et Liste présentent différentes options pour le visionnement, l'analyse, l'installation ou la suppression des paquetages.
La balise Navigation vous permet de visionner les paquetages par groupe. Dans la Figure 2.1, « Outil de gestion des paquetages », la fenêtre de gauche affiche un choix de différents types de groupe de paquetages (par exemple, Environnements de bureau, Applications, Développement et autres). Quand un type de groupe de paquetages est sélectionné, la fenêtre appropriée affiche les différents groupes de ce type.
Pour examiner quel paquetage se trouve dans quel groupe, cliquez sur Paquetages optionnels. Les paquetages installés sont vérifiés.
L'onglet Liste affiche une liste de paquetages installés ou disponibles au téléchargement. Les paquetages déjà installés sur votre système sont cochés en vert (
).
Par défaut l'option Tous les paquetages au-dessus de la fenêtre principale est sélectionnée; cela indique que tous les paquetages doivent être affichés. Utilisez l'option Paquetages installés pour afficher uniquement les paquetages déjà installés sur votre système, et l'option Paquetages disponibles pour visionner les paquetages disponibles à l'installation et au téléchargement.
La balise Recherche vous permet d'utiliser des mots clés pour rechercher des paquetages particuliers. Cette balise permet également de visionner une courte description d'un paquetage. Pour ce faire, il vous suffit de sélectionner un paquetage et de cliquer sur le bouton Détails des paquetages au-dessous de la fenêtre principale.
Pour installer un paquetage disponible au téléchargement, cliquez la case à cocher à côté du nom du paquetage. Ce faisant, une icône d'installation (
) apparaît à côté de la case à cocher. Cela indique que le paquetage est placé dans une file d'attente pour le téléchargement et l'installation. Vous pouvez sélectionner de multiples paquetages à installer ou télécharger ; une fois votre sélection établie, cliquez sur le bouton Appliquer.
S'il existe des dépendances de paquetages pour les téléchargements que vous avez sélectionnés, l'Outil de gestion des paquetages vous en informe. Cliquez sur Détails pour visionner les paquetages supplémentaires nécessaires. Pour effectuer le téléchargement et l'installation du paquetage (avec tous les autres paquetages dépendants) cliquez sur Continuer.
La suppression d'un paquetage s'effectue de la même façon. Pour supprimer un paquetage installé sur votre système, cliquez sur la case à cocher à côté du nom du paquetage. Le coche vert apparaissant à côté du nom du paquetage sera remplacé par une icône de suppression (
). Cela indique que le paquetage est placé dans une file d'attente pour sa suppression. Vous pouvez également sélectionner de multiples paquetages à supprimer simultanément. Une fois que vous avez sélectionné les paquetages que vous désirez supprimer, cliquez sur le bouton Appliquer.
Notez que si un quelconque paquetage est dépendant d'un paquetage que vous désirez supprimer, ce dernier sera également supprimé. L'Outil de gestion des paquetages vous informera de telles dépendances. Cliquez sur Détails pour visionner les paquetages dépendants de celui que vous désirez supprimer. Pour effectuer la suppression du/des paquetage/s (avec tous les autres paquetages dépendants) cliquez sur Continuer.
Vous pouvez installer et supprimer de multiples paquetages en sélectionnant les groupes/paquetages à installer/supprimer, puis en cliquant sur Appliquer. La fenêtre Selections des paquetages affiche le nombre de paquetages devant être installés ou supprimés.
Installation et suppression des paquetages simultanément
Yellowdog Update, Modified (YUM) is a package manager that was developed by Duke University to improve the installation of RPMs. yum
searches numerous repositories for packages and their dependencies so they may be installed together in an effort to alleviate dependency issues. Red Hat Enterprise Linux 5.2 uses yum
to fetch packages and install RPMs.
up2date
is now deprecated in favor of yum
(Yellowdog Updater Modified). The entire stack of tools which installs and updates software in Red Hat Enterprise Linux 5.2 is now based on yum
. This includes everything, from the initial installation via Anaconda to host software management tools like pirut
.
yum
also allows system administrators to configure a local (i.e. available over a local network) repository to supplement packages provided by Red Hat. This is useful for user groups that use applications and packages that are not officially supported by Red Hat.
Aside from being able to supplement available packages for local users, using a local yum
repository also saves bandwidth for the entire network. Further, clients that use local yum
repositories do not need to be registered individually to install or update the latest packages from Red Hat Network.
To set up a repository, follow these steps:
yum
commands are typically run as yum
. By default, <command> <package name/s>
yum
will automatically attempt to check all configured repositories to resolve all package dependencies during an installation/upgrade.
The following is a list of the most commonly-used yum
commands. For a complete list of available yum
commands, refer to man yum
.
yum install <package name/s>
Used to install the latest version of a package or group of packages. If no package matches the specified package name(s), they are assumed to be a shell glob, and any matches are then installed.
yum update <package name/s>
Used to update the specified packages to the latest available version. If no package name/s are specified, then yum
will attempt to update all installed packages.
If the --obsoletes
option is used (i.e. yum --obsoletes
, <package name/s>
yum
will process obsolete packages. As such, packages that are obsoleted accross updates will be removed and replaced accordingly.
yum check-update
This command allows you to determine whether any updates are available for your installed packages. yum
returns a list of all package updates from all repositories if any are available.
yum remove <package name/s>
Used to remove specified packages, along with any other packages dependent on the packages being removed.
yum provides <file name>
Used to determine which packages provide a specific file or feature.
yum search <keyword>
This command is used to find any packages containing the specified keyword in the description, summary, packager and package name fields of RPMs in all repositories.
yum localinstall <absolute path to package name/s>
Used when using yum
to install a package located locally in the machine.
yum
options are typically stated before specific yum
commands; i.e. yum
. Most of these options can be set as default using the configuration file.
<options> <command> <package name/s>
The following is a list of the most commonly-used yum
options. For a complete list of available yum
options, refer to man yum
.
-y
Answer "yes" to every question in the transaction.
-t
Sets yum
to be "tolerant" of errors with regard to packages specified in the transaction. For example, if you run yum update package1 package2
and package2
is already installed, yum
will continue to install package1
.
--exclude=<package name>
Excludes a specific package by name or glob in a specific transaction.
By default, yum
is configured through /etc/yum.conf
. The following is an example of a typical /etc/yum.conf
file:
[main] cachedir=/var/cache/yum keepcache=0 debuglevel=2 logfile=/var/log/yum.log pkgpolicy=newest distroverpkg=redhat-release tolerant=1 exactarch=1 obsoletes=1 gpgcheck=1 plugins=1 metadata_expire=1800 [myrepo] name=RHEL 5 $releasever - $basearch baseurl=http://local/path/to/yum/repository/ enabled=1
A typical /etc/yum.conf
file is made up of two types of sections: a [main]
section, and a repository section. There can only be one [main]
section, but you can specify multiple repositories in a single /etc/yum.conf
.
The [main]
section is mandatory, and there must only be one. For a complete list of options you can use in the [main]
section, refer to man yum.conf
.
The following is a list of the most commonly-used options in the [main]
section.
cachedir
This option specifies the directory where yum
should store its cache and database files. By default, the cache directory of yum
is /var/cache/yum
.
keepcache=<1 or 0>
Setting keepcache=1
instructs yum
to keep the cache of headers and packages after a successful installation. keepcache=1
is the default.
reposdir=<absolute path to directory of .repo files>
This option allows you to specify a directory where .repo
files are located. .repo
files contain repository information (similar to the [
section of repository
]/etc/yum.conf
).
yum
collects all repository information from .repo
files and the [
section of the repository
]/etc/yum.conf
file to create a master list of repositories to use for each transaction. Refer to Section 3.4.2, « [
Options » for more information about options you can use for both the repository
][
section and repository
].repo
files.
If reposdir
is not set, yum
uses the default directory /etc/yum.repos.d
.
gpgcheck=<1 or 0>
This disables/enables GPG signature checking on packages on all repositories, including local package installation. The default is gpgcheck=0
, which disables GPG checking.
If this option is set in the [main]
section of the /etc/yum.conf
file, it sets the GPG checking rule for all repositories. However, you can also set this on individual repositories instead; i.e., you can enable GPG checking on one repository while disabling it on another.
assumeyes=<1 or 0>
This determines whether or not yum
should prompt for confirmation of critical actions. The default if assumeyes=0
, which means yum
will prompt you for confirmation.
If assumeyes=1
is set, yum
behaves in the same way that the command line option -y
does.
tolerant=<1 or 0>
When enabled (tolerant=1
), yum
will be tolerant of errors on the command line with regard to packages. This is similar to the yum
command line option -t
.
The default value for this is tolerant=0
(not tolerant).
exclude=<package name/s>
This option allows you to exclude packages by keyword during installation/updates. If you are specifying multiple packages, this is a space-delimited list. Shell globs using wildcards (for example, * and ?) are allowed.
retries=<number of retries>
This sets the number of times yum
should attempt to retrieve a file before returning an error. Setting this to 0 makes yum
retry forever. The default value is 6.
The [
section of the repository
]/etc/yum.conf
file contains information about a repository yum
can use to find packages during package installation, updating and dependency resolution. A repository entry takes the following form:
[repository ID
] name=repository name
baseurl=url, file or ftp
://path to repository
You can also specify repository information in a separate .repo
files (for example, rhel5.repo
). The format of repository information placed in .repo
files is identical with the [
of repository
]/etc/yum.conf
.
.repo
files are typically placed in /etc/yum.repos.d
, unless you specify a different repository path in the [main]
section of /etc/yum.conf
with reposdir=
. .repo
files and the /etc/yum.conf
file can contain multiple repository entries.
Each repository entry consists of the following mandatory parts:
repository ID
]
The repository ID is a unique, one-word string that serves as a repository identifier.
name=repository name
This is a human-readable string describing the repository.
baseurl=http, file or ftp
://path
This is a URL to the directory where the repodata
directory of a repository is located. If the repository is local to the machine, use baseurl=file://
. If the repository is located online using HTTP, use path to local repository
baseurl=http://
. If the repository is online and uses FTP, use link
baseurl=ftp://
.
link
If a specific online repository requires basic HTTP authentication, you can specify your username and password in the baseurl
line by prepending it as username
:password
@link
. For example, if a repository on http://www.example.com/repo/ requires a username of "user" and a password os "password", then the baseurl
link can be specified as baseurl=http://user:password@www.example.com/repo/
.
The following is a list of options most commonly used in repository entries. For a complete list of repository entries, refer to man yum.conf
.
gpgcheck=<1 or 0>
This disables/enables GPG signature checking a specific repository. The default is gpgcheck=0
, which disables GPG checking.
gpgkey=URL
This option allows you to point to a URL of the ASCII-armoured GPG key file for a repository. This option is normally used if yum
needs a public key to verify a package and the required key was not imported into the RPM database.
If this option is set, yum
will automatically import the key from the specified URL. You will be prompted before the key is installed unless you set assumeyes=1
(in the [main]
section of /etc/yum.conf
) or -y
(in a yum
transaction).
exclude=<package name/s>
This option is similar to the exclude
option in the [main]
section of /etc/yum.conf
. However, it only applies to the repository in which it is specified.
includepkgs=<package name/s>
This option is the opposite of exclude
. When this option is set on a repository, yum
will only be able to see the specified packages in that repository. By default, all packages in a repository are visible to yum
.
The following is a list of variables you can use for both yum
commands and yum
configuration files (i.e. /etc/yum.conf
and .repo
files).
$releasever
This is replaced with the package's version, as listed in distroverpkg
. This defaults to the version of the redhat-release
package.
$arch
This is replaced with your system's architecture, as listed by os.uname()
in Python.
$basearch
This is replaced with your base architecture. For example, if $arch
=i686 then $basearch
=i386.
$YUM0-9
This is replaced with the value of the shell environment variable of the same name. If the shell environment variable does not exist, then the configuration file variable will not be replaced.
Red Hat Network est une solution Internet pour la gestion d'un ou plusieurs système(s) Red Hat Enterprise Linux. Toutes les alertes de sécurité, de correction de bogues et d'amélioration (connues sous le nom collectif d'alertes d'errata) peuvent être directement téléchargées depuis Red Hat en utilisant l'application indépendante Mise à des paquetages ou via le site Web de Red Hat Network à l'adresse suivante : https://rhn.redhat.com/.
Red Hat Network vous économise du temps car vous recevez des courriers électroniques lorsque des paquetages actualisés sont publiés. Vous n'avez pas à rechercher sur le Web les paquetages mis à jour ou les alertes de sécurité. Par défaut, Red Hat Network installe également les paquetages. Vous n'avez donc ni à apprendre comment utiliser RPM, ni à vous soucier de résoudre les dépendances des paquetages logiciels. RHN le fait à votre place.
Parmi les caractéristiques de Red Hat Network figurent :
Alertes d'errata — Une notification est envoyée lorsque des alertes de sécurité, de correctifs de bogues et d'amélioration sont publiées pour tous les systèmes de votre réseau.
Notifications automatiques par courrier électronique — Une notification par courrier électronique vous est envoyée lorsqu'une alerte d'errata est publiée pour vos systèmes.
Mises à jour d'errata programmées — La livraison des mises à jour d'errata est programmée.
Installation de paquetages — Vous pouvez programmer l'installation d'un paquetage sur un ou plusieurs systèmes avec un simple clic de souris.
Mise à jour des paquetages — Vous pouvez utiliser l'outil de Mise à jour de paquetages pour télécharger les derniers paquetages logiciels pour votre système (avec une installation de paquetages facultatifs).
Site Web de Red Hat Network — Vous pouvez gérer plusieurs systèmes, télécharger des paquetages individuels et programmer des actions telles que les mises à jour d'errata à partir de tout ordinateur grâce à un navigateur Web utilisant une connexion sécurisée.
Vous devez activer votre produit Red Hat Enterprise Linux avant d'enregistrer votre système à Red Hat Network afin de vous assurer que vous avez bien droit aux services adéquats. Pour activer votre produit, rendez-vous à l'adresse suivante :
http://www.redhat.com/apps/activate/
Après avoir activé votre produit, enregistrez-le à Red Hat Network afin de recevoir les mises à jour d'errata. Le processus d'enregistrement recueille des informations sur le système qui seront nécessaires par la suite pour vous avertir des mises à jour. Par exemple, une liste des paquetages installés sur votre système est compilée de sorte que vous recevrez une notification seulement pour les mises à jour s'appliquant à votre système.
Lors du premier démarrage du système, les invites Assistant d'installation des mises à jour logicielles vous demandent de vous inscrire. Si vous ne l'avez pas fait à ce moment-là, sélectionnez le menu Applications (le menu principal sur votre panneau) => Outils du système => Mise à jour des paquetages sur votre bureau afin de lancer le processus d'enregistrement. Vous pouvez également exécuter la commande yum update
à partir d'une invite du shell.
Après l'enregistrement, utilisez l'une des méthodes suivantes pour commencer à recevoir les mises à jour :
Sélectionnez Applications (le menu principal sur votre panneau) => Outils de système => Mise à jour des paquetages sur votre bureau.
Exécutez la commande yum
à partir d'une invite du shell.
Utilisez le site Web RHN situé à l'adresse suivante : https://rhn.redhat.com/.
Cliquez sur l'icône de paquetage quand elle apparaît sur le panneau pour lancer l'outil de Mise à jour des paquetages.
Pour obtenir des instructions plus détaillées, reportez-vous à la documentation disponible à l'adresse suivante :
http://www.redhat.com/docs/manuals/RHNetwork/
Red Hat Enterprise Linux inclut une icône de panneau pratique servant à afficher des alertes, visibles lorsqu'une mise à jour concernant votre système Red Hat Enterprise Linux est publiée. Cet icône de panneau n'est pas présente si aucune mise à jour n'est disponible.
Après avoir expliqué comment configurer le réseau, cette section examine les sujets associés à la gestion de réseaux comme la façon d'autoriser les connexions distantes, les fichiers et répertoires partagés sur le réseau et comment configurer un serveur Web.
Table des matières
autofs
/etc/exports
portmap
smb.conf
httpd
httpd.conf
vsftpd
vsftpd
vsftpd
/etc/openldap/schema/
Sous Red Hat Enterprise Linux, toutes les communications réseau se font entre des interfaces logicielles configurées et des périphériques réseau physiques connectés au système.
Les fichiers de configuration pour les interfaces réseau et les scripts permettant de les activer et de les désactiver, sont placés dans le répertoire /etc/sysconfig/network-scripts/
. Bien que le nombre et le type de fichiers d'interfaces puissent différer d'un système à l'autre, ce répertoire contient trois types de fichiers :
Fichiers de configuration d'interfaces
Scripts de contrôle d'interfaces
Fichiers des fonctions réseau
Les fichiers faisant partie de chacune de ces catégories fonctionnent en coopération afin de permettre l'activation de divers périphériques réseau.
Ce chapitre explore la relation entre ces fichiers et leur utilisation.
Avant d'examiner les fichiers de configuration d'interfaces, dressons la liste des fichiers de configuration primaires utilisés pour configurer le réseau. Le fait de comprendre le rôle joué par ces fichiers dans la mise en place de la pile réseau peut s'avérer utile lors de la personnalisation d'un système Red Hat Enterprise Linux
Les fichiers de configuration de réseau principaux sont les suivants :
/etc/hosts
L'objectif principal de ce fichier est de résoudre les noms d'hôtes n'ayant pu être résolus d'une autre façon. Il peut également être utilisé pour résoudre des noms d'hôtes sur de petits réseaux ne disposant pas de serveur DNS. Quel que soit le type de réseau utilisé par l'ordinateur, ce fichier doit contenir une ligne spécifiant l'adresse IP du périphérique de bouclage (loopback) (127.0.0.1
) en tant que localhost.localdomain
. Pour obtenir davantage d'informations, consultez la page de manuel de hosts
.
/etc/resolv.conf
Ce fichier précise les adresses IP des serveurs DNS et le domaine de recherche. À moins d'être configuré autrement, les scripts d'initialisation du réseau sont contenus dans ce fichier. Pour obtenir davantage d'informations sur ce fichier, consultez la page de manuel de resolv.conf
.
/etc/sysconfig/network-scripts/ifcfg-<interface-name>
Pour chaque interface réseau, il existe un script de configuration d'interfaces correspondant. Chacun de ces fichiers fournit des informations spécifiques à une interface réseau particulière. Consultez la Section 5.2, « Fichiers de configuration des interfaces » pour obtenir davantage d'informations sur ce type de fichier et les directives qu'il accepte.
Le répertoire /etc/sysconfig/networking/
est utilisé par l'Outil d'administration du réseau (system-config-network
) et son contenu ne doit pas être modifié manuellement. Vu le risque de suppression de configuration, il est fortement recommandé de n'utiliser qu'une seule méthode pour la configuration réseau.
Les fichiers de configuration d'interfaces contrôlent le fonctionnement des interfaces logicielles associées aux périphériques réseau individuels. Lorsque votre système Red Hat Linux démarre, il utilise ces fichiers pour savoir quelles interfaces il doit afficher automatiquement et comment les configurer. Ces fichiers sont en général nommés ifcfg-
, où <name>
<name>
fait référence au nom du périphérique contrôlé par le fichier de configuration.
Le fichier ifcfg-eth0
représente l'un des fichiers d'interfaces les plus courants ; il contrôle la première carte d'interface réseau Ethernet ou NIC (de l'anglais Network Interface Card) du système. Dans un système comportant plusieurs cartes, il y a plusieurs fichiers ifcfg-eth
(où <X>
<X>
correspond à un numéro unique associé à une interface spécifique). Étant donné que chaque périphérique a son propre fichier de configuration, un administrateur peut contrôler le fonctionnement individuel de chaque interface.
Ci-dessous figure un exemple de fichier ifcfg-eth0
pour un système utilisant une adresse IP fixe :
DEVICE=eth0 BOOTPROTO=none ONBOOT=yes NETWORK=10.0.1.0 NETMASK=255.255.255.0 IPADDR=10.0.1.27 USERCTL=no
Les valeurs requises dans un fichier de configuration d'interfaces peuvent changer en fonction d'autres valeurs. Par exemple, le fichier ifcfg-eth0
pour une interface utilisant DHCP est légèrement différent, car les informations IP sont fournies par le serveur DHCP :
DEVICE=eth0 BOOTPROTO=dhcp ONBOOT=yes
Cependant, vous pouvez également modifier manuellement les fichiers de configuration pour une interface réseau donnée.
Vous trouverez ci-dessous une liste de paramètres pouvant être configurés dans un fichier de configuration d'interface Ethernet :
BONDING_OPTS=<parameters>
sets the configuration parameters for the bonding device, and is used in /etc/sysconfig/network-scripts/ifcfg-bond
(see Section 5.2.3, « Interfaces de liaison de canaux »). These parameters are identical to those used for bonding devices in <N>
/sys/class/net/
, and the module parameters for the bonding driver as described in <bonding device>
/bondingbonding
Module Directives.
Cette méthode de configuration est utilisée afin que plusieurs périphériques de liaison puissent avoir des configurations différentes. Si vous utilisez BONDING_OPTS
dans ifcfg-
, n'utilisez pas<name>
/etc/modprobe.conf
pour spécifier les options du périphérique de liaison.
BOOTPROTO=<protocol>
où
correspond à l'une des valeurs suivantes :
<protocol>
none
— Indique qu'aucun protocole de démarrage ne doit être utilisé.
bootp
— Indique que le protocole BOOTP doit être utilisé.
dhcp
— Indique que le protocole DHCP doit être utilisé.
BROADCAST=<address>
où
correspond à l'adresse de diffusion. Cette directive a été abandonnée car la valeur est calculée automatiquement avec <address>
ifcalc
.
DEVICE=<name>
où
correspond au nom du périphérique physique (à l'exception des périphériques PPP à affectation dynamique où il s'agit du nom logique).
<name>
DHCP_HOSTNAME
N'utilisez cette option que si le serveur DHCP a besoin du client pour spécifier un nom d'hôte avant de recevoir une adresse IP.
DNS{1,2}
=<address>
où
correspond à l'adresse d'un serveur devant être placée dans <address>
/etc/resolv.conf
si la directive PEERDNS
est réglée sur la valeur yes
.
ETHTOOL_OPTS=<options>
où
correspond à toutes les options spécifiques au périphérique qui sont prises en charge par <options>
ethtool
. Par exemple, si vous souhaitez forcer 100 Mo en transmission bidirectionnelle simultanée (ou full-duplex), vous choisirez les paramètres suivants :
ETHTOOL_OPTS="autoneg off speed 100 duplex full"
Instead of a custom initscript, use ETHTOOL_OPTS
to set the interface speed and duplex settings. Custom initscripts run outside of the network init script lead to unpredictable results during a post-boot network service restart.
Notez bien que la modification des paramètres de vitesse ou duplex nécessite presque toujours la désactivation de l'auto-négociation à l'aide de l'option autoneg off
. Ce point doit être mentionné en premier car les entrées d'options sont tributaires de l'ordre dans lequel elles apparaissent.
GATEWAY=<address>
où <address>
correspond à l'adresse IP du routeur réseau ou du périphérique de passerelle (s'il existe).
HWADDR=<MAC-address>
où <MAC-address>
correspond à l'adresse matérielle du périphérique Ethernet sous la forme AA:BB:CC:DD:EE:FF
. Cette directive est utile pour les machines possédant de multiples NIC pour s'assurer que les interfaces sont assignées aux bons noms de périphériques indépendamment de l'ordre de chargement configuré pour chaque module de NIC. Cette directive ne devrait pas être utilisée avec MACADDR
.
IPADDR=<address>
où
correspond à l'adresse IP.
<address>
MACADDR=<MAC-address>
où <MAC-address>
correspond à l'adresse matérielle du périphérique Ethernet sous la forme AA:BB:CC:DD:EE:FF
. Cette directive est utilisée pour assigner une adresse MAC à une interface, écrasant celle assignée par le NIC physique. Cette directive ne devrait pas être utilisée avec HWADDR
.
MASTER=<bond-interface>
où
correspond à l'interface de liaison de canaux à laquelle l'interface Ethernet est liée.
<bond-interface>
Cette directive est utilisée en conjonction avec la directive SLAVE
.
Reportez-vous à la Section 5.2.3, « Interfaces de liaison de canaux » pour obtenir davantage d'informations sur les interfaces de liaison de canaux.
NETMASK=<mask>
où
correspond à la valeur du masque réseau.
<mask>
NETWORK=<address>
où
correspond à l'adresse du réseau. Cette directive a été abandonnée car la valeur est calculée automatiquement avec <address>
ifcalc
.
ONBOOT=<answer>
où
correspond à l'une des valeurs suivantes :
<answer>
yes
— Indique que ce périphérique doit être activé au démarrage.
no
— Indique que ce périphérique ne doit pas être activé au démarrage.
PEERDNS=<answer>
où
correspond à l'une des valeurs suivantes :
<answer>
yes
— Modifier /etc/resolv.conf
si la directive DNS est paramétrée. Si DHCP est utilisé, yes
est alors la valeur par défaut.
no
— Ne pas modifier /etc/resolv.conf
.
SLAVE=<bond-interface>
où
correspond à l'une des valeurs suivantes :
<bond-interface>
yes
— Ce périphérique est contrôlé par l'interface de liaison de canaux spécifiée dans la directive MASTER
.
no
— Ce périphérique n'est pas contrôlé par l'interface de liaison de canaux spécifiée dans la directive MASTER
.
Cette directive est utilisée en conjonction avec la directive MASTER
.
Reportez-vous à la Section 5.2.3, « Interfaces de liaison de canaux » pour obtenir davantage d'informations sur les interfaces de liaison de canaux.
SRCADDR=<address>
où
correspond à l'adresse IP source spécifiée pour les paquets sortants.
<address>
USERCTL=<answer>
où
correspond à l'une des valeurs suivantes :
<answer>
yes
— Les utilisateurs autres que le super-utilisateur sont autorisés à contrôler ce périphérique.
no
— Les utilisateurs autres que le super-utilisateur ne sont pas autorisés à contrôler ce périphérique.
L'extrait suivant correspond au fichier ifcfg
d'une connexion IPsec de réseau à réseau pour le LAN A. Le nom unique permettant d'identifier la connexion de notre exemple est ipsec1
, d'où le nom /etc/sysconfig/network-scripts/ifcfg-ipsec1
donné au fichier qui lui correspond.
TYPE=IPsec ONBOOT=yes IKE_METHOD=PSK SRCNET=192.168.1.0/24 DSTNET=192.168.2.0/24 DST=X.X.X.X
Dans cet exemple, la valeur X.X.X.X
correspond à l'adresse IP routable sur un réseau public du routeur IPsec de destination.
Ci-dessous figure une liste des paramètres configurables pouvant s'appliquer à une interface IPsec :
DST=<address>
où <address>
représente l'adresse IP de l'hôte ou du routeur IPsec de destination. Ce paramètre est utilisé aussi bien pour des connexions IPsec d'hôte à hôte que pour des connexions IPsec de réseau à réseau.
DSTNET=<network>
où <network>
représente l'adresse réseau du réseau IPsec de destination. Ce paramètre est seulement utilisé pour des configurations IPsec de réseau à réseau.
SRC=<address>
où <address>
représente l'adresse IP de l'hôte ou du routeur IPsec source. Ce paramètre, disponible en tant qu'option, est seulement utilisé pour des connexions IPsec d'hôte à hôte.
SRCNET=<network>
où <network>
représente l'adresse réseau du réseau Ipsec source. Ce paramètre est seulement utilisé pour des configurations Ipsec de réseau à réseau.
TYPE=<interface-type>
où <interface-type>
a la valeur IPSEC
. Les deux applications font partie du paquetage ipsec-tools
.
Reportez-vous au fichier /usr/share/doc/initscripts-
(remplacez <version-number>
/sysconfig.txt<version-number>
par le numéro de version du paquetage initscripts
installé) pour obtenir des informations sur les paramètres de configuration, si vous utilisez des clés manuelles de cryptage avec Ipsec.
Le démon de gestion des clés IKEv1 baptisé racoon
négocie et configure un ensemble de paramètres pour IPSec. Il peut utiliser des clés pré-partagées, des signatures RSA ou GSS-API. Si racoon
est utilisé pour gérer automatiquement le cryptage des clés, les options suivantes sont alors requises :
IKE_METHOD=<encryption-method>
où <encryption-method>
représente PSK
, X509
ou GSSAPI
. Si la valeur PSK
est spécifiée, le paramètre IKE_PSK
doit lui aussi être défini. Si la valeur X509
est mentionnée, le paramètre IKE_CERTFILE
doit lui aussi être défini.
IKE_PSK=<shared-key>
où <shared-key>
correspond à la valeur secrète et partagée de la méthode PSK (de l'anglais preshared keys).
IKE_CERTFILE=<cert-file>
où <cert-file>
correspond à un fichier de certificats X.509 valide pour l'hôte.
IKE_PEER_CERTFILE=<cert-file>
où <cert-file>
correspond à un fichier de certificats X.509 valide pour l'hôte distant.
IKE_DNSSEC=<answer>
où <answer>
correspond à yes
. Le démon racoon
extrait le certificat X.509 de l'hôte distant via DNS. Si un paramètre IKE_PEER_CERTFILE
est défini, n'incluez pas le paramètre ci-dessus.
Pour obtenir de plus amples informations sur les algorithmes de cryptage disponibles pour IPsec, consultez la page de manuel de setkey
. Pour davantage d'informations sur racoon
, reportez-vous aux pages de manuel de racoon
et racoon.conf
.
Red Hat Enterprise Linux permet aux administrateurs de lier ensemble plusieurs interfaces réseau pour ne former qu'un seul canal à l'aide du module de noyau bonding
et d'une interface de réseau spéciale appelée interface de liaison de canaux. La liaison de canaux permet à plusieurs interfaces réseau d'agir comme une seule interface, augmentant simultanément la largeur de bande et offrant alors une certaine redondance.
Pour créer une interface de liaison de canaux, créez un fichier dans le répertoire /etc/sysconfig/network-scripts/
nommé ifcfg-bond
, en remplaçant <N>
<N>
par le numéro de l'interface, comme par exemple 0
.
Le contenu du fichier peut être identique à tout type d'interface qui sera lié, comme par exemple une interface Ethernet. La seule différence repose sur le fait que la directive DEVICE=
doit correspondre à bond
, où <N>
<N>
représente le numéro de l'interface.
Ci-dessous figure un exemple de fichier de configuration de liaison de canaux :
DEVICE=bond0 BONDING_OPTS="mode=1 miimon=500" BOOTPROTO=none ONBOOT=yes NETWORK=10.0.1.0 NETMASK=255.255.255.0 IPADDR=10.0.1.27 USERCTL=no
Une fois l'interface de liaison de canaux créée, les interfaces réseau à lier ensemble doivent être configurées en ajoutant les directives MASTER=
et SLAVE=
dans leurs fichiers de configuration. Les fichiers de configuration pour chaque interface de liaison de canaux peuvent être pratiquement identiques.
Par exemple, dans le cas de deux interfaces Ethernet de liaison de canaux, eth0
et eth1
peuvent ressembler à l'extrait suivant :
DEVICE=eth<N>
BOOTPROTO=none ONBOOT=yes MASTER=bond0 SLAVE=yes USERCTL=no
Dans cet exemple, remplacez <N>
par la valeur numérique de l'interface.
Il existe deux types de fichiers de configuration d'interfaces d'une utilisation moins courante : les fichiers alias et clone.
Les fichiers de configuration d'interface alias qui sont utilisés principalement pour lier plusieurs adresses à une seule interface, suivent le principe de nommage ifcfg-
.
<if-name>
:<alias-value>
Par exemple, un fichier ifcfg-eth0:0
peut être configuré pour spécifier DEVICE=eth0:0
et une adresse IP statique de 10.0.0.2, servant donc d'alias pour une interface Ethernet déjà configurée pour recevoir ses informations IP via DHCP dans ifcfg-eth0
. Avec une telle configuration, le périphérique eth0
est lié à une adresse IP dynamique, mais la même carte réseau physique peut recevoir des requêtes via l'adresse IP fixe 10.0.0.2.
Les interfaces alias ne prennent pas en charge DHCP.
Le nom d'un fichier de configuration d'interface clone doit suivre le format suivant : ifcfg-
. Alors qu'un fichier alias autorise plusieurs adresses pour une interface existante, un fichier clone lui permet de spécifier des options complémentaires pour une interface. Par exemple, le fichier d'une interface Ethernet DHCP standard appelée <if-name>
-<clone-name>
eth0
, pourrait ressembler à l'extrait ci-dessous :
DEVICE=eth0 ONBOOT=yes BOOTPROTO=dhcp
Puisque la valeur par défaut de la directive USERCTL
est no
si aucune valeur n'est spécifiée, les utilisateurs ne peuvent pas activer ou désactiver cette interface. Pour permettre aux utilisateurs de le faire, créez un clone en copiant ifcfg-eth0
dans ifcfg-eth0-user
, puis ajoutez la ligne suivante dans ifcfg-eth0-user
:
USERCTL=yes
De cette manière, un utilisateur peut activer l'interface eth0
avec la commande /sbin/ifup eth0-user
puisque les options de configuration de ifcfg-eth0
sont combinées à celles de ifcfg-eth0-user
. Bien qu'il s'agisse ici d'un exemple élémentaire, cette méthode peut être utilisée avec des options et interfaces diverses.
Si vous vous connectez à un réseau comme l'Internet par l'intermédiaire d'une connexion commutée PPP, il vous faut un fichier de configuration pour cette interface.
Les fichiers d'interface PPP sont nommés en utilisant le format suivant :
ifcfg-ppp<X>
où <X>
est un numéro unique correspondant à une interface spécifique.
Le fichier de configuration d'interface PPP est créé automatiquement lorsque vous utilisez wvdial
, l'Outil d'administration du réseau ou alors, Kppp est utilisé pour créer un compte de connexion par modem. Vous pouvez également créer et éditer ce fichier manuellement.
Un fichier ifcfg-ppp0
typique ressemble à l'extrait ci-dessous :
DEVICE=ppp0 NAME=test WVDIALSECT=test MODEMPORT=/dev/modem LINESPEED=115200 PAPNAME=test USERCTL=true ONBOOT=no PERSIST=no DEFROUTE=yes PEERDNS=yes DEMAND=no IDLETIMEOUT=600
Le protocole Internet ligne série (SLIP) (de l'anglais Serial Line Internet Protocol) constitue une autre interface de connexion commutée, même s'il est moins fréquemment utilisé. Les fichiers SLIP ont des noms de fichiers de configuration d'interface de type ifcfg-sl0
.
Parmi les options dont nous n'avons pas encore parlé, et qui peuvent être utilisées dans ces fichiers, figurent :
DEFROUTE=<answer>
où
correspond à l'une des valeurs suivantes :
<answer>
yes
— Indique que cette interface doit être configurée comme itinéraire par défaut.
no
— Indique que cette interface ne doit pas être configurée comme itinéraire par défaut.
DEMAND=<answer>
où
correspond à l'une des valeurs suivantes :
<answer>
yes
— Indique que cette interface permettra à pppd
d'initialiser une connexion lorsque quelqu'un essaiera de l'utiliser.
no
— Indique qu'une connexion doit être établie manuellement pour cette interface.
IDLETIMEOUT=<value>
où
correspond au nombre de secondes d'inactivité engendrant la déconnexion automatique de l'interface.
<value>
INITSTRING=<string>
où
correspond à la chaîne d'initialisation transférée au modem. Cette option est principalement utilisée avec les interfaces SLIP.
<string>
LINESPEED=<value>
où
correspond à la vitesse de transmission (en bauds) du périphérique. Parmi les valeurs standard possibles figurent <value>
57600
, 38400
, 19200
et 9600
.
MODEMPORT=<device>
où
correspond au nom du périphérique série utilisé pour établir la connexion pour l'interface.
<device>
MTU=<value>
où
correspond au paramètre unité de transfert maximum (MTU) (de l'anglais Maximum Transfer Unit) pour l'interface. La valeur de MTU correspond au nombre maximal d'octets de données qu'un cadre peut comporter, sans compter les informations d'en-tête. Dans certaines situations de connexion par modem, le réglage de ce paramètre sur la valeur <value>
576
entraîne une réduction du nombre de paquets éliminés et une légère augmentation du débit de connexion.
NAME=<name>
où
correspond à la référence au nom donné à un ensemble de configurations de connexions commutées.
<name>
PAPNAME=<name>
où
correspond au nom d'utilisateur donné lors de l'échange d'informations avec le protocole d'authentification du mot de passe (PAP) (de l'anglais, Password Authentication Protocol) afin de permettre la connexion à un système distant.
<name>
PERSIST=<answer>
où
correspond à l'une des valeurs suivantes :
<answer>
yes
— Spécifie que cette interface doit rester active en permanence, même si elle est désactivée lorsqu'un modem raccroche.
no
— Spécifie que cette interface ne doit pas rester active en permanence.
REMIP=<address>
où
correspond à l'adresse IP du système distant. Cette valeur n'est généralement pas spécifiée.
<address>
WVDIALSECT=<name>
où
associe cette interface à une configuration de composeur dans <name>
/etc/wvdial.conf
. Ce fichier contient le numéro de téléphone à composer et d'autres informations importantes pour l'interface.
Parmi d'autres fichiers de configuration d'interfaces courants figurent :
ifcfg-lo
Une interface de bouclage locale (loopback) est souvent utilisée pour effectuer des tests et pour une utilisation dans un certain nombre d'applications qui nécessitent une adresse IP référant au même système. Toutes les données envoyées au périphérique de bouclage sont immédiatement renvoyées vers la couche réseau de l'hôte.
Ne modifier jamais manuellement le script de l'interface de bouclage, /etc/sysconfig/network-scripts/ifcfg-lo
. Des modifications pourraient provoquer un mauvais fonctionnement du système.
ifcfg-irlan0
Une interface infrarouge permet à des informations de circuler entre des périphériques tels qu'un ordinateur portable et une imprimante, par l'intermédiaire d'un lien infrarouge fonctionnant de la même façon qu'un périphérique Ethernet, sauf qu'il est généralement utilisé dans une connexion de poste à poste.
ifcfg-plip0
Une connexion PLIP (Parallel Line Interface Protocol) fonctionne de la même façon qu'un périphérique Ethernet, sauf qu'elle utilise un port parallèle.
ifcfg-tr0
Les topologies en anneau à jeton (ou Token Ring) ne sont pas aussi courantes sur les Réseaux locaux (ou LAN de l'anglais Local Area Networks) qu'elles ne l'étaient autrefois ; elles ont été supplantées par Ethernet.
Les scripts de contrôle d'interfaces activent et désactivent des connexions d'interfaces. Il existe deux scripts de contrôle principaux, à savoir /sbin/ifdown
et /sbin/ifup
qui utilisent des scripts de contrôle situés dans le répertoire /etc/sysconfig/network-scripts/
.
Les scripts d'interfaces ifup
et ifdown
constituent des liens symboliques vers des scripts du répertoire /sbin/
. Lorsque l'un ou l'autre de ces scripts est appelé, la valeur de l'interface doit être spécifiée, comme par exemple :
ifup eth0
Les scripts d'interfaces ifup
et ifdown
sont les seuls scripts que l'utilisateur devrait employer pour activer et désactiver les interfaces réseau.
Les scripts ci-dessous ne sont décrits qu'à titre de références.
Deux fichiers sont utilisés pour effectuer diverses tâches d'initialisation de réseau durant le processus d'activation d'une interface réseau, à savoir les fichiers /etc/rc.d/init.d/functions
et /etc/sysconfig/network-scripts/network-functions
. Reportez-vous à la Section 5.5, « Fichiers de fonctions réseau » pour de plus amples informations.
Après avoir vérifié qu'une interface a été spécifiée et que l'utilisateur effectuant la requête est autorisé à contrôler l'interface, le script approprié active ou désactive l'interface. La liste ci-dessous énumère les scripts de contrôle d'interfaces les plus courants situés dans le répertoire /etc/sysconfig/network-scripts/
:
ifup-aliases
Configure des alias IP à partir des fichiers de configuration d'interfaces quand plusieurs adresses IP sont associées à une interface.
ifup-ippp
et ifdown-ippp
Permet d'activer ou désactiver un interface RNIS (de l'anglais ISDN pour Integrated Services Digital Network)
ifup-ipsec
et ifdown-ipsec
Permet d'activer ou de désactiver une interface IPsec.
ifup-ipv6
et ifdown-ipv6
Permet d'activer ou de désactiver une interface IPv6.
ifup-ipx
Permet d'activer une interface IPX.
ifup-plip
Permet d'activer une interface PLIP.
ifup-plusb
Permet d'activer une interface USB pour les connexions réseau.
ifup-post
et ifdown-post
Contient certaines commandes qui doivent être exécutées après qu'une interface soit activée ou désactivée.
ifup-ppp
et ifdown-ppp
Permet d'activer ou de désactiver une interface PPP.
ifup-routes
Ajoute des itinéraires statiques pour un périphérique particulier lorsque son interface est activée.
ifdown-sit
et ifup-sit
Contiennent des fonctions associées à l'activation et à la désactivation d'un tunnel IPv6 au sein d'une connexion IPv4.
ifup-sl
et ifdown-sl
Permet d'activer ou de désactiver une interface SLIP.
ifup-wireless
Permet d'activer une interface sans-fil.
La suppression ou la modification de scripts dans le répertoire /etc/sysconfig/network-scripts/
peut provoquer le mauvais fonctionnement ou l'échec de diverses connexions. Seuls les utilisateurs chevronnés devraient modifier les scripts en relation avec une interface réseau.
Pour simplifier la manipulation simultanée de tous les scripts réseau, utilisez la commande /sbin/service
sur le service réseau (/etc/rc.d/init.d/network
), comme ci-dessous :
/sbin/service network <action>
Dans cet exemple, <action>
peut correspondre à start
, stop
, ou restart
.
Pour afficher une liste des périphériques configurés et des interfaces réseau actuellement actives, utilisez la commande suivante :
/sbin/service network status
Routing will be configured on routing devices, therefore it should not be necessary to configure static routes on Red Hat Enterprise Linux servers or clients. However, if static routes are required they can be configured for each interface. This can be useful if you have multiple interfaces in different subnets. Use the route
command to display the IP routing table.
Static route configuration is stored in a /etc/sysconfig/network-scripts/route-
file. For example, static routes for the eth0 interface would be stored in the interface
/etc/sysconfig/network-scripts/route-eth0
file. The route-
file has two formats: IP command arguments and network/netmask directives.
interface
Define a default gateway on the first line. This is only required if the default gateway is not set via DHCP:
defaultX.X.X.X
devinterface
X.X.X.X
is the IP address of the default gateway. The interface
is the interface that is connected to, or can reach, the default gateway.
Define a static route. Each line is parsed as an individual route:
X.X.X.X/X
viaX.X.X.X
devinterface
X.X.X.X/X
is the network number and netmask for the static route. X.X.X.X
and interface
are the IP address and interface for the default gateway respectively. The X.X.X.X
address does not have to be the default gateway IP address. In most cases, X.X.X.X
will be an IP address in a different subnet, and interface
will be the interface that is connected to, or can reach, that subnet. Add as many static routes as required.
The following is a sample route-eth0
file using the IP command arguments format. The default gateway is 192.168.0.1, interface eth0. The two static routes are for the 10.10.10.0/24 and 172.16.1.0/24 networks:
default 192.168.0.1 dev eth0 10.10.10.0/24 via 192.168.0.1 dev eth0 172.16.1.0/24 via 192.168.0.1 dev eth0
Static routes should only be configured for other subnets. The above example is not necessary, since packets going to the 10.10.10.0/24 and 172.16.1.0/24 networks will use the default gateway anyway. Below is an example of setting static routes to a different subnet, on a machine in a 192.168.0.0/24 subnet. The example machine has an eth0 interface in the 192.168.0.0/24 subnet, and an eth1 interface (10.10.10.1) in the 10.10.10.0/24 subnet:
10.10.10.0/24 via 10.10.10.1 dev eth1
If the default gateway is already assigned from DHCP, the IP command arguments format can cause one of two errors during start-up, or when bringing up an interface from the down state using the ifup
command: "RTNETLINK answers: File exists" or 'Error: either "to" is a duplicate, or "X.X.X.X
" is a garbage.', where X.X.X.X
is the gateway, or a different IP address. These errors can also occur if you have another route to another network using the default gateway. Both of these errors are safe to ignore.
You can also use the network/netmask directives format for route-
files. The following is a template for the network/netmask format, with instructions following afterwards:
interface
ADDRESS0=X.X.X.X
NETMASK0=X.X.X.X
GATEWAY0=X.X.X.X
ADDRESS0=
is the network number for the static route.
X.X.X.X
NETMASK0=
is the netmask for the network number defined with X.X.X.X
ADDRESS0=
.
X.X.X.X
GATEWAY0=
is the default gateway, or an IP address that can be used to reach X.X.X.X
ADDRESS0=
X.X.X.X
The following is a sample route-eth0
file using the network/netmask directives format. The default gateway is 192.168.0.1, interface eth0. The two static routes are for the 10.10.10.0/24 and 172.16.1.0/24 networks. However, as mentioned before, this example is not necessary as the 10.10.10.0/24 and 172.16.1.0/24 networks would use the default gateway anyway:
ADDRESS0=10.10.10.0 NETMASK0=255.255.255.0 GATEWAY0=192.168.0.1 ADDRESS1=172.16.1.0 NETMASK1=255.255.255.0 GATEWAY1=192.168.0.1
Subsequent static routes must be numbered sequentially, and must not skip any values. For example, ADDRESS0
, ADDRESS1
, ADDRESS2
, and so on.
Below is an example of setting static routes to a different subnet, on a machine in the 192.168.0.0/24 subnet. The example machine has an eth0 interface in the 192.168.0.0/24 subnet, and an eth1 interface (10.10.10.1) in the 10.10.10.0/24 subnet:
ADDRESS0=10.10.10.0 NETMASK0=255.255.255.0 GATEWAY0=10.10.10.1
DHCP should assign these settings automatically, therefore it should not be necessary to configure static routes on Red Hat Enterprise Linux servers or clients.
Red Hat Enterprise Linux utilise plusieurs fichiers contenant des fonctions importantes utilisées pour activer et désactiver les interfaces. Plutôt que de forcer chaque fichier de contrôle d'interfaces à contenir ces fonctions, elles sont regroupées dans un petit nombre de fichiers qui sont utilisés en fonction des besoins.
Le fichier /etc/sysconfig/network-scripts/network-functions
contient les fonctions IPv4 les plus couramment utilisées par bon nombre de scripts de contrôle d'interfaces. Ces fonctions permettent entre autres de contacter des programmes en cours d'exécution ayant demandé des informations sur les modifications du statut d'une interface, de configurer des noms d'hôte, de trouver un périphérique passerelle, de vérifier le statut d'un périphérique particulier et finalement d'ajouter un itinéraire par défaut.
Les fonctions requises pour les interfaces IPv6 étant différentes de celles requises pour les interfaces IPv4, un fichier /etc/sysconfig/network-scripts/network-functions-ipv6
est spécifiquement conçu pour contenir ces informations. Les fonctions spécifiées dans ce fichier permettent de configurer et de supprimer des routes IPv6 statiques, de créer et de supprimer des tunnels, d'ajouter des adresses IPv6 à des interfaces ou d'en supprimer et finalement de rechercher l'existence d'une adresse IPv6 sur une interface.
Les ressources suivantes traitent des interfaces réseau de manière plus détaillée.
/usr/share/doc/initscripts-<version>
/sysconfig.txt
Un guide des options disponibles pour les fichiers de configuration réseau, y compris les options IPv6 n'ayant pas été abordées dans ce chapitre.
/usr/share/doc/iproute-<version>
/ip-cref.ps
Ce fichier contient un grand nombre d'informations sur la commande ip
pouvant être utilisées, entre autres pour manipuler des tables de routage. Utilisez l'application ggv ou kghostview pour accéder à ce fichier.
Pour communiquer avec d'autres ordinateurs, ces derniers ont besoin d'une connexion réseau. Il faut donc que le système d'exploitation reconnaisse une carte d'interface (Ethernet, modem RNIS ou anneau à jeton) et que l'interface à connecter au réseau soit configurée.
L'Outil d'administration du réseau permet de configurer les types d'interface réseau suivants :
Ethernet
RNIS
modem
xDSL
anneau à jeton
CIPE
périphériques sans fil
Il peut également être utilisé pour configurer les connexions IPsec, gérer les paramètres de DNS et le fichier /etc/hosts
utilisé pour stocker des combinaisons de noms d'hôtes et d'adresses IP supplémentaires.
Pour utiliser l'Outil d'administration du réseau, vous devez avoir les privilèges de super-utilisateur (ou root). Pour lancer l'application, sélectionnez le bouton Applications (the main menu on the panel) => Paramètres de système => Réseau, ou saisissez la commande system-config-network
à l'invite du shell (dans un terminal XTerm ou GNOME terminal par exemple). Si vous saisissez la commande, la version graphique s'affiche si X est en cours d'exécution, sinon, la version basée sur le texte s'affiche.
Pour utiliser la version en ligne de commande, exécutez la commande system-config-network-cmd --help
en tant que super-utilisateur afin d'afficher toutes les options.
Consultez la liste de compatibilité matérielle Red Hat (http://hardware.redhat.com/hcl/) pour savoir si votre périphérique est pris en charge par Red Hat Enterprise Linux.
Pour configurer une connexion réseau avec l'Outil d'administration du réseau, suivez les étapes ci-dessous :
Ajoutez un périphérique réseau associé au périphérique matériel.
Ajoutez le périphérique matériel physique à la liste du matériel si il n'existe pas encore.
Configurez les paramètres de nom d'hôte et DNS.
Configurez tout hôte ne pouvant pas être trouvé par l'intermédiaire de DNS.
Ce chapitre présente chacune de ces étapes pour chaque type de connexion réseau.
Pour établir une connexion Ethernet, différents éléments sont nécessaires : une carte d'interface réseau, un câble réseau (généralement de type CAT5) ainsi qu'un réseau auquel se connecter. Différents réseaux sont configurés pour utiliser différentes vitesses de réseau ; assurez-vous que votre carte soit compatible avec le réseau auquel vous souhaitez vous connecter.
Suivez les étapes suivantes afin d'ajouter une connexion Ethernet :
Cliquez sur l'onglet Périphériques.
Cliquez sur le bouton Nouveau dans la barre d'outils.
Sélectionnez Connexion Ethernet à partir de la liste Type de périphérique et cliquez sur Suivant.
Si vous avez déjà ajouté la carte d'interface réseau à la liste du matériel, sélectionnez-la à partir de la liste Carte Ethernet. Sinon, sélectionnez Autre Carte Ethernet afin d'ajouter le périphérique matériel.
Le programme d'installation détecte généralement les périphériques Ethernet pris en charge et vous invite à les configurer. Si vous en avez configurés au cours de l'installation, ils apparaissent déjà dans la liste du matériel sur l'onglet Matériel.
Si vous avez sélectionné Autre Carte Ethernet, la fenêtre Sélectionner un adaptateur Ethernet apparaît alors. Sélectionnez le fabricant ainsi que le modèle de la carte Ethernet, puis le nom du périphérique. S'il s'agit de la première carte Ethernet du système, sélectionnez eth0 comme nom ; s'il s'agit de la deuxième carte Ethernet, sélectionnez eth1 (et ainsi de suite) L'Outil d'administration du réseau permet également de configurer les ressources pour la carte. Cliquez sur Suivant pour continuer.
Dans la fenêtre Configurer les paramètres réseau, comme le montre la Figure 6.2, « Paramètres Ethernet », choisissez entre DHCP et une adresse IP statique. Si le périphérique reçoit une adresse IP différente à chaque démarrage du réseau, n'indiquez pas de nom d'hôte. Cliquez sur Suivant pour continuer.
Cliquez sur Appliquer sur la page Créer un périphérique Ethernet.
Une fois configuré, le périphérique Ethernet apparaît dans la liste des périphériques, comme le montre la Figure 6.3, « Périphérique Ethernet ».
Assurez-vous de bien sélectionner Fichier => Enregistrer afin d'enregistrer vos modifications.
Après avoir ajouté le périphérique Ethernet, vous pouvez modifier sa configuration en le sélectionnant dans la liste des périphériques puis en cliquant sur Éditer. Par exemple, lorsque le périphérique est ajouté, il est configuré pour être lancé par défaut lors du démarrage. Pour changer ce paramètre, choisissez d'éditer le périphérique, modifiez la valeur Activer le périphérique au démarrage de l'ordinateur et enregistrez les modifications.
Lorsque le périphérique est ajouté, il n'est pas activé immédiatement, comme le montre son statut Désactivé. Afin d'activer le périphérique, sélectionnez-le dans la liste des périphériques et cliquez sur le bouton Activer. Si le système est configuré de telle sorte que le périphérique sera activé lors du démarrage de l'ordinateur (la valeur par défaut), il ne sera pas nécessaire de répéter cette étape.
Si vous associez plus d'un périphérique à une carte Ethernet, ces périphériques sont des alias de périphériques. Un alias de périphériques vous permet de configurer de multiples périphériques virtuels pour un périphérique physique, dotant ainsi ce périphérique physique de plusieurs adresses IP. Par exemple, vous pouvez configurer un périphérique eth1 et un périphérique eth1:1. Pour de plus amples informations, reportez-vous à la Section 6.11, « Alias de périphériques »..
Une connexion RNIS est une connexion Internet établie à l'aide d'une carte modem RNIS au travers d'une ligne téléphonique spéciale installée par la compagnie téléphonique. Les connexions RNIS sont populaires en Europe.
Suivez les étapes suivantes afin d'ajouter une connexion RNIS :
Cliquez sur l'onglet Périphériques.
Cliquez sur le bouton Nouveau dans la barre d'outils.
Sélectionnez Connexion RNIS à partir de la liste Type de périphérique et cliquez sur Suivant.
Sélectionnez la carte RNIS dans le menu déroulant. Configurez ensuite les ressources ainsi que le protocole de canal D pour cette carte. Cliquez sur Suivant pour continuer.
Si votre fournisseur d'accès à Internet (FAI ou ISP de l'anglais "Internet Service Provider") fait partie de la liste pré-configurée, sélectionnez-le. Sinon, fournissez les informations nécessaires sur votre compte FAI. Si vous ne connaissez pas les valeurs de ce dernier, contactez votre FAI. Cliquez alors sur Suivant.
Dans la fenêtre Paramètres IP, sélectionnez le Mode d'encapsulation et choisissez si vous voulez obtenir une adresse IP automatiquement ou si vous voulez en définir une de manière statique. Cliquez sur Suivant à la fin de ces opérations.
Sur la page Créer une connexion via modem, cliquez sur Appliquer.
Après avoir configuré le périphérique ISDN, il apparaît dans la liste des périphériques en tant que périphérique de type ISDN, comme le montre la Figure 6.5, « Périphérique RNIS ».
Assurez-vous de bien sélectionner Fichier => Enregistrer afin d'enregistrer vos modifications.
Après avoir ajouté le périphérique RNIS, vous pouvez modifier sa configuration en sélectionnant le périphérique dans la liste des périphériques, puis en cliquant sur Modifier. Par exemple, lorsque le périphérique est ajouté, il est configuré de façon à ne pas être lancé au démarrage par défaut. Éditez sa configuration pour modifier ce paramètre. D'autres éléments peuvent également être changés, tels que la compression, les options PPP, le nom de connexion, le mot de passe parmi tant d'autres.
Lorsque le périphérique est ajouté, il n'est pas activé immédiatement, comme le montre son statut Désactivé. Afin d'activer le périphérique, sélectionnez-le dans la liste des périphériques et cliquez sur le bouton Activer. Si le système est configuré de telle sorte que le périphérique sera activé lors du démarrage de l'ordinateur (la valeur par défaut), il ne sera pas nécessaire de répéter cette étape.
Un modem peut être utilisé pour configurer une connexion Internet sur une ligne téléphonique active. Un compte de fournisseur d'accès à Internet est requis.
Suivez les étapes suivantes afin d'ajouter une connexion modem :
Cliquez sur l'onglet Périphériques.
Cliquez sur le bouton Nouveau dans la barre d'outils.
Sélectionnez Connexion du modem à partir de la liste Type de périphérique et cliquez sur Suivant.
Si un modem est déjà configuré dans la liste de matériel (sous l'onglet Matériel), l'Outil d'administration du réseau suppose que vous voulez l'utiliser pour établir une connexion modem. Si aucun modem n'est déjà configuré, il essaie de détecter des modems dans le système. Cette opération peut prendre un certain temps. Si aucun modem n'est détecté, un message apparaît pour vous avertir que les paramètres affichés ne correspondent pas aux valeurs obtenues par l'opération de détection.
Après la détection, la fenêtre reproduite dans la Figure 6.6, « Paramètres du modem » apparaît.
Configurez le périphérique du modem, la vitesse de transmission, le contrôle de flux et le volume du modem. Si vous ne connaissez pas ces valeurs, acceptez les valeurs par défaut si le modem a été détecté par le système. Si vous ne disposez pas de la numérotation à touches, décochez l'option correspondante. Cliquez ensuite sur Suivant.
Si votre FAI fait partie de la liste préconfigurée, sélectionnez-le. Sinon, fournissez les informations nécessaires sur votre compte FAI. Si vous ne connaissez pas ces valeurs, contactez votre FAI. Cliquez ensuite sur Suivant.
Dans la page Paramètres IP, sélectionnez si vous souhaitez obtenir votre adresse IP automatiquement ou si vous préférez la configurer de manière statique. Cliquez ensuite sur Suivant une fois ces opérations terminées.
Sur la page Créer une connexion via modem, cliquez sur Appliquer.
Après avoir configuré le périphérique du modem, il apparaît dans la liste des périphériques en tant que type Modem
, comme le montre la Figure 6.7, « Périphérique modem ».
Assurez-vous de bien sélectionner Fichier => Enregistrer afin d'enregistrer vos modifications.
Après avoir ajouté le périphérique modem, vous pouvez modifier sa configuration en le sélectionnant dans la liste des périphériques, puis en cliquant sur Modifier. Par exemple, lorsque le périphérique est ajouté, il est par défaut configuré de façon à ne pas être lancé au démarrage. Modifiez sa configuration afin de changer ce paramètre. De nombreuses options peuvent également être modifiées, telles que la compression, les options PPP, le nom de connexion, le mot de passe parmi tant d'autres.
Lorsque le périphérique est ajouté, il n'est pas activé immédiatement, comme le montre son statut Désactivé. Afin d'activer le périphérique, sélectionnez-le dans la liste des périphériques et cliquez sur le bouton Activer. Si le système est configuré de telle sorte que le périphérique sera activé lors du démarrage de l'ordinateur (la valeur par défaut), il ne sera pas nécessaire de répéter cette étape.
DSL signifie "Digital Subscriber Lines" (lignes d'abonnés numériques). Il existe différents types de DSL, notamment ADSL, IDSL et SDSL. Le terme xDSL employé par l'Outil d'administration du réseau regroupe tous les types de connexions DSL.
Certains fournisseurs DSL demandent que vous configuriez votre système afin d'obtenir une adresse IP par DHCP via une carte Ethernet, alors que d'autres vous demandent de configurer une connexion PPPoE (Point-to-Point Protocol over Ethernet), un protocole point à point sur Ethernet, avec une carte Ethernet. Demandez à votre fournisseur DSL quelle méthode utiliser.
Si vous devez utiliser DHCP, reportez-vous à la Section 6.2, « Mise en place d'une connexion Ethernet » afin de configurer votre carte Ethernet.
Suivez les étapes suivantes si vous devez utiliser PPPoE :
Cliquez sur l'onglet Périphériques.
Cliquez sur le bouton Nouveau.
Sélectionnez Connexion xDSL à partir de la liste Type de périphérique et cliquez sur Suivant comme l'illustre la Figure 6.8, « Sélectionner le type de périphérique »..
Si votre carte Ethernet se trouve déjà dans la liste de matériel, sélectionnez un Périphérique Ethernet à partir du menu déroulant de la page présentée dans la Figure 6.9, « Paramètres xDSL ». Sinon, la fenêtre Sélectionner un adaptateur Ethernet apparaît.
Le programme d'installation détecte généralement les périphériques Ethernet pris en charge et vous invite à les configurer. Si vous en avez configurés au cours de l'installation, ils apparaissent déjà dans la liste du matériel sur l'onglet Matériel.
Entrez le Nom du fournisseur, le Nom de connexion et le Mot de passe. Si vous ne configurez pas un compte T-Online, sélectionnez Normal à partir du menu déroulant Type de compte.
Si vous configurez un compte T-Online, sélectionnez T-Online à partir du menu déroulant Type de compte et saisissez un Nom de connexion et un Mot de passe. Vous pouvez configurer plus en détails votre compte T-Online une fois que la connexion DSL est complètement configurée (reportez-vous à la section suivante : Configurer un compte T-Online).
Cliquez sur Suivant pour aller au menu Créer une connexion DSL. Vérifiez vos paramètres et cliquez sur Appliquer pour terminer.
Une fois configurée, la connexion DSL apparaît dans la liste des périphériques, comme le montre la Figure 6.10, « Périphérique xDSL ».
Après avoir ajouté la connexion xDSL, vous pouvez modifier sa configuration en sélectionnant le périphérique dans la liste de périphériques et en cliquant sur Éditer.
Par exemple, lorsque le périphérique est ajouté, il est configuré pour ne pas être lancé par défaut au démarrage. Éditez sa configuration pour modifier ses paramètres. Cliquez sur Valider lorsque vous avez terminé.
Une fois satisfait par les paramètres de votre connexion xDSL, sélectionnez Fichier => Enregistrer pour enregistrer vos modifications.
Si vous configurez un compte T-Online, effectuez ces étapes supplémentaires :
Sélectionnez le périphérique à partir de la liste de périphériques et cliquez sur Éditer.
Sélectionnez l'onglet Fournisseur à partir du menu Configuration xDSL comme l'illustre la Figure 6.12, « Configuration xDSL - Onglet Fournisseur ».
Cliquez sur le bouton Configuration d'un compte T-Online. Cela ouvre la fenêtre Configuration du compte pour votre compte T-Online comme l'illustre la Figure 6.13, « Configuration du compte ».
Saisissez l'Identifiant de votre adaptateur, le Numéro T-Online associé, le Suffixe/Numéro de l'utilisateur en cours et le Mot de passe personel. Cliquez sur Valider lorsque vous avez terminé afin de fermer la fenêtre Configuration du compte.
Sur la fenêtre Configuration xDSL, cliquez sur Valider. N'oubliez pas de sélectionnez Fichier => Enregistrer à partir de l'Outil d'administration du réseau pour enregistrer les modifications.
Lorsque le périphérique est ajouté, il n'est pas activé immédiatement, comme le montre son statut Désactivé. Afin d'activer le périphérique, sélectionnez-le dans la liste des périphériques et cliquez sur le bouton Activer. Si le système est configuré de telle sorte que le périphérique sera activé lors du démarrage de l'ordinateur (la valeur par défaut), il ne sera pas nécessaire de répéter cette étape.
Un réseau de bus annulaire à jeton ("Token Ring" en anglais) est un réseau auquel tous les ordinateurs sont connectés sur un modèle circulaire. Un jeton, ou un paquet spécial de réseau, voyage autour d'un bus annulaire à jeton et permet ainsi aux ordinateurs de se transmettre des informations.
Pour plus d'informations sur l'utilisation du bus annulaire à jeton sous Linux, reportez-vous au site Web Linux Token Ring Project à l'adresse : http://www.linuxtr.net/.
Suivez les étapes suivantes afin d'ajouter un bus annulaire à jeton :
Cliquez sur l'onglet Périphériques.
Cliquez sur le bouton Nouveau dans la barre d'outils.
Sélectionnez Connexion Token Ring à partir de la liste Type de périphérique et cliquez sur Suivant.
Si vous avez déjà ajouté la carte de bus annulaire à jeton à la liste de matériel, sélectionnez-la à partir de la liste Carte Token Ring. Sinon, sélectionnez Autre carte Token Ring afin d'ajouter le périphérique matériel.
Si vous avez sélectionné Autre carte Token Ring, la fenêtre Sélectionner un adaptateur Token Ring apparaît alors, comme le montre la Figure 6.14, « Paramètres du bus annulaire à jeton ('Token Ring') ». Sélectionnez le fabricant ainsi que le modèle de la carte, puis le nom du périphérique. S'il s'agit de la première carte de bus annulaire à jeton du système, sélectionnez tr0 ; s'il s'agit de la deuxième, sélectionnez tr1 (et ainsi de suite). L'Outil d'administration du réseau permet également à l'utilisateur de configurer les ressources pour l'adaptateur. Cliquez sur Suivant pour continuer.
Paramètres du bus annulaire à jeton ('Token Ring')
Sur la page Configurer les paramètres réseau, choisissez entre DHCP et une adresse IP statique. Vous pouvez également spécifier un nom d'hôte pour le périphérique. Si celui-ci reçoit une adresse IP dynamique à chaque démarrage du réseau, n'indiquez pas de nom d'hôte. Cliquez sur Suivant pour continuer.
Cliquez sur Appliquer sur la page Créer un périphérique Token Ring.
Une fois configuré, le périphérique de bus annulaire à jeton apparaît dans la liste des périphériques, comme le montre la Figure 6.15, « Périphérique de bus annulaire à jeton (Token Ring) ».
Périphérique de bus annulaire à jeton (Token Ring)
Assurez-vous de bien sélectionner Fichier => Enregistrer afin d'enregistrer vos modifications.
Après avoir ajouté le périphérique, vous pouvez modifier sa configuration en le sélectionnant dans la liste des périphériques, puis en cliquant sur Modifier. Vous pouvez par exemple indiquer s'il doit être lancé au démarrage.
Lorsque le périphérique est ajouté, il n'est pas activé immédiatement, comme le montre son statut Désactivé. Afin d'activer le périphérique, sélectionnez-le dans la liste des périphériques et cliquez sur le bouton Activer. Si le système est configuré de telle sorte que le périphérique sera activé lors du démarrage de l'ordinateur (la valeur par défaut), il ne sera pas nécessaire de répéter cette étape.
Les périphériques Ethernet sans fil deviennent de plus en plus populaires. Leur configuration est semblable à la configuration Ethernet, mis à part qu'elle vous permet de configurer des paramètres tels que le ESSID et la clé de votre périphérique sans fil.
Suivez les étapes suivantes afin d'ajouter une connexion Ethernet sans fil :
Cliquez sur l'onglet Périphériques.
Cliquez sur le bouton Nouveau dans la barre d'outils.
Sélectionnez Connexion sans fil à partir de la liste Type de périphérique et cliquez sur Suivant.
Si vous avez déjà ajouté la carte d'interface réseau sans fil à la liste de matériel, sélectionnez-la à partir de la liste Carte sans fil. Sinon, sélectionnez Autre carte sans fil afin d'ajouter le périphérique matériel.
Le programme d'installation détecte généralement les périphériques Ethernet sans fil pris en charge et vous invite à les configurer. Si vous en avez configurés au cours du programme d'installation, ils apparaissent déjà dans la liste de matériel sur l'onglet Matériel.
Si vous avez sélectionné Autre carte sans fil, la fenêtre Sélectionner un adaptateur Ethernet apparaît alors. Sélectionnez le fabricant ainsi que le modèle de la carte Ethernet, puis le périphérique. S'il s'agit de la première carte Ethernet du système, sélectionnez eth0 ; s'il s'agit de la deuxième, sélectionnez eth1 (et ainsi de suite). L'Outil d'administration du réseau permet également à l'utilisateur de configurer les ressources pour la carte d'interface réseau sans fil. Cliquez sur Suivant pour continuer.
Configurez les paramètres pour le périphérique sans fil sur la page Configurer une connexion sans fil comme le montre la Figure 6.16, « Paramètres de connexion sans fil ».
Sur la page Configurer les paramètres réseau, choisissez entre DHCP et une adresse IP statique. Vous pouvez également spécifier un nom d'hôte pour le périphérique. Si celui-ci reçoit une adresse IP dynamique à chaque démarrage du réseau, n'indiquez pas de nom d'hôte. Cliquez sur Suivant pour continuer.
Cliquez sur Appliquer sur la page Créer un périphérique sans fil.
Une fois configuré, le périphérique sans fil apparaît dans la liste des périphériques, comme le montre la Figure 6.17, « Périphérique sans fil ».
Assurez-vous de bien sélectionner Fichier => Enregistrer afin d'enregistrer vos modifications.
Après avoir ajouté le périphérique sans fil, vous pouvez modifier sa configuration en le sélectionnant dans la liste des périphériques, puis en cliquant sur Modifier. Par exemple, vous pouvez le configurer afin qu'il soit activé au démarrage.
Lorsque le périphérique est ajouté, il n'est pas activé immédiatement, comme le montre son statut Désactivé. Afin d'activer le périphérique, sélectionnez-le dans la liste des périphériques et cliquez sur le bouton Activer. Si le système est configuré de telle sorte que le périphérique sera activé lors du démarrage de l'ordinateur (la valeur par défaut), il ne sera pas nécessaire de répéter cette étape.
L'onglet DNS vous permet de configurer le nom d'hôte du système, son domaine, ses serveurs de noms ainsi que le domaine de recherche. Les serveurs de noms sont utilisés pour la recherche d'hôtes supplémentaires sur le réseau.
Si le serveur de noms DNS est récupéré de DHCP ou PPPoE (ou bien à partir du fournisseur d'accès à Internet), n'ajoutez pas de serveurs DNS primaires, secondaires ou tertiaires.
Si le nom d'hôte est récupéré dynamiquement de DHCP ou PPPoE (ou bien à partir du fournisseur d'accès à Internet), ne le changez pas.
La section des serveurs de noms ne configure pas le système comme serveur de noms. À la place, il configure les serveurs de noms à utiliser lors de la résolution de l'adresse IP avec le nom d'hôte et vice versa.
Si le nom d'hôte est changé et system-config-network
est lancé sur la machine locale, il est possible que vous ne puissiez pas démarrer une autre application X11. Vous devez alors vous ré-identifier sur une nouvelle session de bureau.
L'onglet Hôtes vous permet d'ajouter, de modifier ou de supprimer des hôtes du fichier /etc/hosts
. Celui-ci contient les adresses IP ainsi que les noms d'hôtes correspondants.
Lorsque votre système tente de convertir un nom d'hôte en une adresse IP ou de déterminer le nom d'hôte pour une adresse IP, il se réfère au fichier /etc/hosts
avant d'utiliser les serveurs de noms (si vous utilisez la configuration Red Hat Enterprise Linux par défaut). Si l'adresse IP est répertoriée dans le fichier /etc/hosts
, les serveurs de noms ne sont pas utilisés. Si votre réseau comporte des ordinateurs dont les adresses IP ne sont pas répertoriées dans DNS, nous vous recommandons de les ajouter au fichier /etc/hosts
.
Pour ajouter une entrée au fichier /etc/hosts
, utilisez l'onglet Hôtes, cliquez sur le bouton Nouveau dans la barre d'outils et fournissez les informations requises avant de cliquer sur Valider. Sélectionnez Fichier => Enregistrer ou pressez sur les touches Ctrl-S pour enregistrer les modifications dans le fichier /etc/hosts
. Le réseau ou les services du réseau n'ont pas à être relancés étant donné que le système fait appel à la version courante du fichier lors de chaque résolution d'adresse.
Ne supprimez pas l'entrée localhost
. Même si le système n'a pas de connexion réseau ou a une connexion réseau permanente, certains programmes doivent se connecter au système via l'interface de bouclage ("loopback") de l'hôte local.
Pour modifier l'ordre de recherche, modifiez le fichier /etc/host.conf
. La ligne order hosts, bind
spécifie que /etc/hosts
a la priorité sur les serveurs de noms. Si vous changez la ligne en order bind, hosts
vous configurez votre système afin qu'il utilise tout d'abord les serveurs de noms pour la conversion des noms d'hôte ainsi que des adresses IP. Si l'adresse IP ne peut pas être convertie par l'intermédiaire des serveurs de noms, le système recherche alors l'adresse IP dans le fichier /etc/hosts
.
Plusieurs périphériques réseau logiques peuvent être créés pour chaque périphérique matériel physique. Par exemple, si vous avez une carte Ethernet dans votre système (eth0), vous pouvez créer des périphériques réseau logiques avec différents surnoms et différentes options de configuration, tous associés à eth0.
Les périphériques réseau logiques sont différents des alias de périphériques. Les périphériques réseau logiques associés au même périphérique physique doivent exister dans différents profils et ne peuvent pas être activés simultanément. Les alias de périphériques sont également associés au même périphérique matériel, mais les alias de périphériques associés au même matériel peuvent être activés en même temps. Reportez-vous à la Section 6.11, « Alias de périphériques » afin d'obtenir de plus amples informations sur la création d'alias de périphériques.
Les profils peuvent être utilisés pour créer plusieurs ensembles de configuration pour différents réseaux. Un ensemble de configuration peut inclure des périphériques logiques tels que les hôtes et des paramètres DNS. Après la configuration des profils, vous pouvez utiliser l'Outil d'administration du réseau afin de passer de l'un à l'autre.
Par défaut, il existe un profil appelé Commun. Pour créer un nouveau profil sélectionnez Profil => Nouveau dans le menu déroulant, puis entrez un nom unique pour le profil.
Vous modifiez maintenant le nouveau profil, comme l'indique la barre de statut en bas de la fenêtre principale.
Cliquez sur le périphérique figurant déjà dans la liste et sélectionnez le bouton Copier pour copier le périphérique existant sur un périphérique réseau logique. Si vous utilisez le bouton Nouveau, un alias de réseau sera créé, ce qui n'est pas correct. Pour changer les propriétés du périphérique logique, sélectionnez-le parmi la liste, puis cliquez sur Modifier. Par exemple, le surnom peut être changé en un nom plus parlant, comme eth0_office
, afin qu'il puisse être plus facilement identifiable.
Dans la liste des périphériques figure une colonne de cases à cocher intitulée Profil. Vous pouvez cocher ou décocher des périphériques pour chaque profil. Seuls les périphériques cochés sont inclus pour le profil actuellement sélectionné. Par exemple, si vous créez un périphérique logique nommé eth0_office
dans un profil nommé Office
et que vous voulez activer le périphérique logique si le profil est sélectionné, annulez la sélection du périphérique eth0
et retenez à la place le périphérique eth0_office
.
Par exemple, la Figure 6.20, « Profil Office » montre un profil appelé Office avec le périphérique logique eth0_office. Il est configuré de façon à activer la première carte Ethernet à l'aide de DHCP.
Veuillez noter que le profil Home illustré dans la Figure 6.21, « Profil Home » active le périphérique logique eth0_home qui est associé à eth0
.
Vous pouvez également configurer eth0
de façon à ce qu'il ne soit activé que dans le profil Office et n'activer qu'un périphérique ppp (modem) dans le profil Home. Le profil Commun peut également activer eth0
et un profil Away activer un périphérique ppp à utiliser en cas de voyage.
Pour activer un profil au démarrage, modifiez le fichier de configuration du chargeur de démarrage afin qu'il inclut l'option netprofile=
. Par exemple, si le système utilise GRUB en tant que chargeur de démarrage et que <nom-de-profil>
/boot/grub/grub.conf
contient :
title Red Hat Enterprise Linux (2.6.9-5.EL) root (hd0,0) kernel /vmlinuz-2.6.9-5.EL ro root=/dev/VolGroup00/LogVol00 rhgb quiet initrd /initrd-2.6.9-5.EL.img
Remplacez-le par l'exemple suivant (où <profilename>
représente le nom du profil à activer au démarrage) :
title Red Hat Enterprise Linux (2.6.9-5.EL) root (hd0,0) kernel /vmlinuz-2.6.9-5.EL ro root=/dev/VolGroup00/LogVol00 \ netprofile=<profilename>
\ rhgb quiet initrd /initrd-2.6.9-5.EL.img
Pour changer de profil une fois que le système a démarré, sélectionnez le bouton Applications (the main menu on the panel) => Outils de système => Contrôle du périphérique réseau (ou saisissez la commande system-control-network
) pour sélectionner un profil et l'activer. La section pour activer le profil n'apparaît dans l'interface du Contrôle du périphérique réseau que si l'interface Commun par défaut, n'est pas la seule existant.
Sinon, exécutez la commande suivante pour activer un profil (remplacez <profilename>
par le nom du profil) :
system-config-network-cmd --profile <profilename>
--activate
Les alias de périphériques sont des périphériques virtuels associés au même matériel, mais ils peuvent être activés au même moment afin d'avoir des adresses IP différentes. On les représente généralement avec le nom du périphérique suivi du signe deux-points et d'un nombre (eth0:1, par exemple). Ils sont utiles si vous souhaitez qu'un système ait plusieurs adresses IP, mais que le système n'a qu'une seule carte réseau.
Après avoir configuré un périphérique Ethernet — comme eth0
— pour qu'il utilise une adresse IP statique (DHCP ne fonctionne pas avec les alias), cliquez sur l'onglet Périphérique, puis sur sur Nouveau. Sélectionnez la carte Ethernet à configurer avec un alias, configurez l'adresse IP statique pour l'alias et cliquez sur Appliquer pour le créer. Étant donné qu'un périphérique existe déjà pour la carte Ethernet, celui nouvellement créé est l'alias eth0:1
.
Si vous configurez un périphérique Ethernet de façon à ce qu'il ait un alias, ni le périphérique ni l'alias ne pourront être configurés pour utiliser DHCP. Vous devez configurer manuellement les adresses IP.
Figure 6.22, « Exemple d'alias de périphérique réseau » montre un exemple d'alias pour le périphérique eth0
. Veuillez noter le périphérique eth0:1
— le premier alias pour eth0
. Le deuxième alias pour eth0
aurait le nom de périphérique eth0:2
, et ainsi de suite. Pour modifier les paramètres de l'alias de périphérique, comme par exemple, pour indiquer s'il doit être activé au démarrage et le numéro de l'alias, sélectionnez-le dans la liste et cliquez sur le bouton Modifier.
Sélectionnez l'alias et cliquez sur le bouton Activer pour activer l'alias. Si vous avez configuré plusieurs profils, sélectionnez les profils dans lesquels l'inclure.
Afin de vous assurer que l'alias ait bien été activé, utilisez la commande /sbin/ifconfig
. La sortie doit afficher le périphérique ainsi que l'alias de périphérique avec des adresses IP différentes :
eth0 Link encap:Ethernet HWaddr 00:A0:CC:60:B7:G4 inet addr:192.168.100.5 Bcast:192.168.100.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:161930 errors:1 dropped:0 overruns:0 frame:0 TX packets:244570 errors:0 dropped:0 overruns:0 carrier:0 collisions:475 txqueuelen:100 RX bytes:55075551 (52.5 Mb) TX bytes:178108895 (169.8 Mb) Interrupt:10 Base address:0x9000 eth0:1 Link encap:Ethernet HWaddr 00:A0:CC:60:B7:G4 inet addr:192.168.100.42 Bcast:192.168.100.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 Interrupt:10 Base address:0x9000 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:5998 errors:0 dropped:0 overruns:0 frame:0 TX packets:5998 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:1627579 (1.5 Mb) TX bytes:1627579 (1.5 Mb)
La version en ligne de commande de l'Outil d'administration du réseau peut être utilisée pour enregistrer la configuration réseau du système sous un fichier. Ce fichier peut alors être utilisé pour restaurer les paramètres du réseau sur un système Red Hat Enterprise Linux.
Cette fonction peut être utilisée à l'intérieur d'un script de sauvegarde automatisé pour enregistrer la configuration avant une mise à niveau ou réinstallation, ou pour copier la configuration sur un système Red Hat Enterprise Linux différent.
Pour enregistrer ou exporter la configuration réseau du système sous le fichier /tmp/network-config
, exécutez la commande suivante en tant que super-utilisateur :
system-config-network-cmd -e > /tmp/network-config
Pour restaurer ou importer la configuration réseau depuis le fichier créé lors de la commande précédente, exécutez la commande suivante en tant que super-utilisateur :
system-config-network-cmd -i -c -f /tmp/network-config
L'option -i
indique l'import de données, l'option -c
provoque la suppression de la configuration existante avant l'import et l'option -f
spécifie que le fichier à importer est le suivant.
Il est extrêmement important de maintenir la sécurité de votre système. Une des manières de garantir la sécurité de votre système est de gérer méticuleusement l'accès aux services. Il se peut que votre système ait besoin de fournir un accès ouvert à des services particuliers (comme httpd
par exemple, si vous utilisez un serveur Web). Cependant, si vous n'avez pas besoin de fournir un service, nous vous recommandons de le désactiver afin de minimiser les dangers d'éventuels bogues.
Il existe plusieurs méthodes de gestion d'accès aux services du système. Choisissez la méthode que vous souhaitez utiliser en fonction du service, de la configuration de votre système et de votre niveau de connaissances Linux.
La façon la plus simple de refuser l'accès à un service est tout simplement de le désactiver. Les services gérés par xinetd
(dont nous parlerons plus loin) et les services contenus dans la hiérarchie /etc/rc.d/init.d
peuvent être configurés pour démarrer ou s'arrêter en utilisant trois applications différentes :
Outil de configuration des services — Cette application graphique affiche une description de chaque service, indique si chaque service est activé au démarrage du système (pour les niveaux d'exécution 3, 4 et 5) et permet à l'utilisateur de démarrer, d'arrêter et de redémarrer les services.
ntsysv — Cette application en mode texte permet de configurer les services qui seront activés au démarrage du système pour chaque niveau d'exécution. Les services non-xinetd
ne peuvent pas être démarrés, arrêtés ou redémarrés à l'aide de ce programme.
chkconfig
Cet utilitaire en ligne de commande permet d'activer et de désactiver des services pour les différents niveaux d'exécution. Les services Non-xinetd
ne peuvent pas être démarrés, arrêtés ou redémarrés à l'aide de cet utilitaire.
Vous trouverez peut-être que ces outils sont plus faciles à utiliser que d'autres — comme la modification manuelle des nombreux liens symboliques contenus dans les répertoires sous /etc/rc.d
ou celle des fichiers de configuration xinetd
contenus dans /etc/xinetd.d
.
Vous pouvez également gérer l'accès aux services du système en utilisant iptables
pour configurer l'IP d'un pare-feu. Si vous êtes un nouvel utilisateur Linux, notez que iptables
n'est pas forcément la meilleure solution pour vous car la configuration de iptables
peut être compliquée. Pour cette raison, cette option est plutôt recommandée aux administrateurs système UNIX/Linux expérimentés.
Alternatively, if you are looking for a utility to set general access rules for your home machine, and/or if you are new to Linux, try the Outil de configuration du niveau de sécurité (system-config-securitylevel
), which allows you to select the security level for your system, similar to the Firewall Configuration screen in the installation program.
Avant de pouvoir configurer l'accès aux services, vous devez comprendre les niveaux d'exécution de Linux. Un niveau d'exécution est un état, ou mode défini par les services contenus dans le répertoire /etc/rc.d/rc
où <x>
.d<x>
correspond au numéro du niveau d'exécution.
Les niveaux d'exécution suivants existent :
0 — Arrêt
1 — Mode mono-utilisateur
2 — Pas utilisé (peut être défini par l'utilisateur)
3 — Mode multi-utilisateurs complet
4 — Pas utilisé (peut être défini par l'utilisateur)
5 — Mode multi-utilisateurs complet (avec un écran de connexion graphique)
6 — Redémarrage
Si vous utilisez un écran de connexion texte, vous activez le niveau d'exécution 3. Si vous utilisez un écran de connexion graphique, vous activez le niveau d'exécution 5.
Le niveau d'exécution par défaut peut être changé en modifiant le fichier /etc/inittab
, qui, au tout début, contient une ligne qui ressemble à celle figurant ci-dessous :
id:5:initdefault:
Remplacez le numéro de cette ligne par le numéro du niveau d'exécution désiré. Ce changement ne sera pas mis en oeuvre tant que vous ne redémarrerez pas le système.
De nombreux administrateurs système UNIX ont l'habitude d'utiliser les enveloppeurs TCP (ou TCP wrappers) pour gérer l'accès à certains services réseau. Tout service réseau géré par xinetd
(ainsi que tous les programmes contenant un support intégré pour libwrap
) peuvent utiliser les enveloppeurs TCP pour gérer l'accès. xinetd
peut utiliser les fichiers /etc/hosts.allow
et /etc/hosts.deny
pour configurer l'accès aux services du système. Comme son nom l'indique, le fichier hosts.allow
contient une liste de règles qui permettent aux clients d'accéder aux services réseau contrôlés par xinetd
, alors que le fichier hosts.deny
contient des règles qui empêchent l'accès. Le fichier hosts.allow
est prioritaire par rapport au fichier hosts.deny
. Les autorisations pour permettre ou empêcher l'accès peuvent être basées sur des adresses IP individuelles (ou noms d'hôtes) ou sur un modèle de clients. Pour plus d'informations, consultez le hosts_access
dans la section 5 des pages de manuel (man 5 hosts_access
).
Pour contrôler l'accès aux services Internet, vous pouvez utiliser xinetd
, un remplacement plus sûr pour inetd
. Le démon xinetd
conserve les ressources système, fournit le contrôle d'accès et la connexion et peut être utilisé pour lancer des serveurs à buts spéciaux. Ce démon xinetd
peut entre autre, être utilisé pour fournir l'accès ou le refuser à certains hôtes, pour ne fournir l'accès à un service qu'à un moment donné, pour limiter le nombre de connexions et/ou la charge des connexions.
xinetd
fonctionne en permanence et surveille tous les ports des services qu'il gère. Lors de la réception d'une requête de connexion à l'un des services qu'il gère, xinetd
démarre le serveur adapté pour ce service.
Le fichier de configuration de xinetd
est /etc/xinetd.conf
, mais si vous examinez ce fichier vous verrez qu'il contient seulement quelques valeurs par défaut et une instruction pour inclure le répertoire /etc/xinetd.d
. Pour activer ou désactiver un service xinetd
, éditez son fichier de configuration dans le répertoire /etc/xinetd.d
. Si l'attribut disable
(désactiver) a la valeur yes
, le service est désactivé. Si au contraire l'attribut disable
a la valeur no
, le service est alors activé. Vous pouvez éditer tout fichier de configuration xinetd
ou changer le statut d'activation à l'aide de l'Outil de configuration des services, ou de ntsysv, ou de chkconfig
. Pour obtenir une liste des services réseau contrôlés par xinetd
, passez en revue le contenu du répertoire /etc/xinetd.d
à l'aide de la commande ls /etc/xinetd.d
.
L' Outil de configuration des services a été développé par Red Hat pour permettre de configurer les services SysV contenus dans le répertoire /etc/rc.d/init.d
et qui seront lancés au démarrage (pour les niveaux d'exécution 3, 4 et 5) et les services xinetd
qui seront activés. L'application permet également d'une part, de démarrer, arrêter et redémarrer les services SysV et d'autre part, de redémarrer xinetd
.
Pour démarrer l'Outil de configuration des services à partir du bureau, sélectionnez Applications (the main menu on the panel) => Paramètres système => Paramètres Serveur => Services ou saisissez la commande system-config-services
à l'invite du shell (par exemple, dans un terminal XTerm ou un GNOME).
L'Outil de configuration des services affiche le niveau d'exécution en cours d'utilisation ainsi que le niveau d'exécution en cours de modification. Pour éditer un autre niveau d'exécution, sélectionnez Niveau d'exécution dans le menu déroulant et sélectionnez le niveau d'exécution 3, 4 ou 5. Pour une description des niveaux d'exécution, consultez la Section 7.1, « Niveaux d'exécution ».
L'Outil de configuration des services répertorie les services contenus dans le répertoire /etc/rc.d/init.d
ainsi que les services contrôlés par xinetd
. Cliquez sur le nom du service figurant dans la liste à gauche de l'application pour afficher une brève description de ce service ainsi que son statut. Si le service n'est pas un service xinetd
, la fenêtre de statut indiquera si le service est actuellement en cours. Si le service est contrôlé par xinetd
, la fenêtre de statut affiche la mention xinetd service.
Pour démarrer, arrêter ou redémarrer immédiatement un service, sélectionnez le service à partir de la liste et choisissez le bouton approprié dans la barre d'outils (ou sélectionnez l'action désirée dans le menu déroulant Actions). Si le service est un service xinetd
, les boutons d'action ne fonctionnent pas car il ne peuvent pas être démarrés ou arrêtés individuellement.
Si vous activez/désactivez un service xinetd
en sélectionnant ou dé-sélectionnant la case à cocher placée à coté du nom du service, vous devez choisir Fichier => Sauvegarder les modifications dans le menu déroulant (ou le bouton Sauvegarder au-dessus des onglets) afin de redémarrer xinetd
et d'activer/désactiver immédiatement le service xinetd
que vous avez modifié. xinetd
est également configuré de manière à conserver le paramétrage. Vous pouvez activer/désactiver de multiples services xinetd
à un moment donné et enregistrer les changements lorsque vous avez terminé.
Supposons, par exemple, que vous contrôliez rsync
pour l'activer à un niveau d'exécution 3 et que vous sauvegardiez ensuite vos changements. Le service rsync
sera immédiatement activé. Lors du prochain lancement de xinetd
, le service rsync
sera toujours activé.
Lorsque vous sauvegardez des modifications apportées aux services xinetd
, xinetd
est redémarré et les changements sont mis en oeuvre immédiatement. Lorsque vous enregistrez des changements apportés à d'autres services, le niveau d'exécution est reconfiguré, mais les changements ne sont pas mis en oeuvre immédiatement.
Pour activer un service non-xinetd
afin qu'il démarre au moment de l'amorçage au niveau d'exécution actuellement sélectionné, cochez la case à côté du nom du service figurant dans la liste. Après avoir configuré le niveau d'exécution, mettez les changements en oeuvre en choisissant Fichier => Sauvegarder les modifications dans le menu déroulant. La configuration du niveau d'exécution est certes changée, mais le niveau d'exécution n'est pas redémarré ; ainsi, les changements ne sont pas mis en oeuvre immédiatement.
Supposons, par exemple, que vous configuriez le niveau d'exécution 3. Si vous changez la valeur pour le service httpd
en dé-sélectionnant la case appropriée et que vous choisissiez ensuite Sauvegarder les modifications, la configuration du niveau d'exécution 3 changera afin que httpd
ne soit pas lancé lors du démarrage. Le niveau d'exécution 3 n'est toutefois pas réinitialisé et httpd
tourne donc toujours. À ce stade, choisissez l'une des options suivantes :
Arrêt du service httpd
— Arrêtez le service en le sélectionnant dans la liste et en cliquant sur le bouton Arrêter. Un message s'affiche indiquant que le service a bien été arrêté.
Ré-initialisation du niveau d'exécution — Pour réinitialiser le niveau d'exécution, à l'invite du shell, tapez la commande telinit
(où x
x
représente le nombre du niveau d'exécution, dans cet exemple, 3). Cette option est conseillée si vous changez la valeur relative à Démarrer à l'amorçage pour de multiples services et si vous souhaitez que ces changements soient mis en oeuvre immédiatement.
Terminé! — Vous n'avez pas besoin d'arrêter le service httpd
. Pour que le service s'arrête, vous pouvez attendre que le système redémarre. Au prochain démarrage, le niveau d'exécution sera initialisé sans que le service httpd
ne tourne.
Pour ajouter un service à un niveau d'exécution, sélectionnez le niveau d'exécution depuis le menu déroulant Modifier le niveau d'exécution, puis sélectionnez Actions => Ajouter un service. Pour supprimer un service d'un niveau d'exécution, sélectionnez le niveau d'exécution depuis le menu déroulant Modifier le niveau d'exécution, sélectionnez le service à supprimer dans la liste sur la gauche, puis sélectionnez Actions => Supprimer un service.
L'utilitaire ntsysv fournit une interface simple pour activer et désactiver les services. Vous pouvez utiliser ntsysv pour activer ou désactiver un service géré par xinetd
. Vous pouvez également utiliser ntsysv pour configurer des niveaux d'exécution. Par défaut, seul le niveau d'exécution courant est configuré. Pour configurer un niveau d'exécution différent, spécifiez un ou plusieurs niveau(x) d'exécution à l'aide de l'option --level
. La commande ntsysv --level 345
par exemple, configure les niveaux d'exécution 3, 4 et 5.
L'interface ntsysv fonctionne de la même manière que le programme d'installation en mode texte. Utilisez les flèches haut et bas pour faire défiler la liste. La barre espace permet de sélectionner/dé-sélectionner les services et sert également à appuyer sur les boutons Valider et Annuler. Pour passer de la liste des services aux boutons Valider et Annuler, utilisez la touche Tab. Un astérisque (*) signifie que le service est activé. Appuyez sur la touche F1 pour afficher une brève description du service sélectionné.
Les changements apportés aux services gérés par xinetd
au moyen de ntsysv sont mis en oeuvre immédiatement. Pour tous les autres services, les changements ne sont pas mis en oeuvre immédiatement. Vous devez arrêter et démarrer le service spécifique à l'aide de la commande service
(où <daemon>
stop<daemon>
est le nom du service que vous désirez arrêter, par exemple, httpd
). Remplacez stop
par start
ou restart
pour démarrer ou redémarrer le service.
La commande chkconfig
peut également être utilisée pour activer et désactiver les services. Si vous utilisez la commande chkconfig --list
, une liste des services du système apparaîtra et indiquera si les services sont activés (on
) ou arrêtés (off
) aux niveaux d'exécution s'échelonnant entre 0 et 6. À la fin de la liste figure une section pour les services gérés par xinetd
.
Si vous utilisez chkconfig --list
pour envoyer une requête à un service géré par xinetd
, vous verrez si le service xinetd
est activé (on
) ou désactivé (off
). La commande chkconfig --list rsync
par exemple, renverra la sortie suivante :
rsync on
L'exemple ci-dessus montre que rsync
est activé comme un service xinetd
. Si xinetd
est en cours d'exécution, rsync
est activé.
Si vous utilisez chkconfig --list
pour envoyer une requête à un service dans /etc/rc.d
, vous verrez les paramètres du service pour chaque niveau d'exécution. La commande chkconfig --list httpd
renverra par exemple, la sortie suivante :
httpd 0:off 1:off 2:on 3:on 4:on 5:on 6:off
La commande chkconfig
peut également servir à configurer un service de façon à ce qu'il démarre (ou pas) dans un niveau d'exécution spécifique. Par exemple, pour désactiver nscd
dans les niveaux d'exécution 3, 4 et 5, utilisez la commande suivante :
chkconfig --level 345 nscd off
Les services gérés par xinetd
sont immédiatement mis en oeuvre par chkconfig
. Si par exemple, xinetd
est en cours d'exécution, alors que rsync
est désactivé, la commande chkconfig rsync on
est exécutée, et rsync
est immédiatement activé et vous n'avez pas besoin de redémarrer xinetd
manuellement. Les modifications concernant les autres services ne prennent pas effet immédiatement après l'utilisation de chkconfig
. Vous devez arrêter ou démarrer le service spécifique à l'aide de la commande service
(où <daemon>
stop<daemon>
est le nom du service que vous voulez arrêter, comme httpd
par exemple. Remplacez stop
par start
ou restart
pour démarrer ou redémarrer le service.
Pour obtenir plus d'informations, consultez les ressources énumérées ci-dessous.
Les pages de manuel relatives à ntsysv
, chkconfig
, xinetd
et xinetd.conf
.
man 5 hosts_access
— La page de manuel pour le format des fichiers de contrôle d'accès des hôtes (dans la section 5 des pages de manuel).
http://www.xinetd.org — Page Web relative à xinetd
. Elle contient une liste plus détaillée des fonctionnalités et des exemples de fichiers de configuration.
Sur la plupart des réseaux modernes, y compris l'Internet, les utilisateurs localisent les autres ordinateurs au moyen du nom. Ainsi les utilisateurs n'ont pas à se souvenir de l'adresse réseau numérique des ressources réseau. La manière la plus efficace de configurer un réseau afin de permettre des connexions à base de nom consiste à établir un Service de Nom de Domaine (ou DNS, de l'anglais Domain Name Service) ou un serveur de noms qui permet d'associer des noms d'hôte d'un réseau à des adresses numériques et vice-versa.
This chapter reviews the nameserver included in Red Hat Enterprise Linux and the Berkeley Internet Name Domain (BIND) DNS server, with an emphasis on the structure of its configuration files and how it may be administered both locally and remotely.
BIND is also known as the service named
in Red Hat Enterprise Linux. You can manage it via the Outil de configuration des services (system-config-service
).
Le DNS associe les noms d'hôte avec les adresses IP respectives, c'est pour cela que lorsque les utilisateurs veulent se connecter à d'autres machines sur le réseau, ils peuvent s'y référer avec le nom, sans avoir à se rappeler de l'adresse IP.
L'utilisation du DNS et du FQDN offre aux administrateurs système de nombreux avantages et leur permet, en outre, de changer facilement l'adresse IP d'un hôte sans avoir d'impact sur les requêtes basées sur le nom qui sont envoyées à cet ordinateur. Inversement, les administrateurs peuvent décider des machines qui traiteront une requête basée sur le nom.
Le service DNS est normalement mis en oeuvre grâce à des serveurs centralisés qui font autorité pour certains domaines et se réfèrent à d'autres serveurs DNS pour d'autres domaines.
Lorsqu'un hôte client demande des informations au serveur de noms, il se connecte généralement sur le port 53. Le serveur de noms tente alors de résoudre le FQDN d'après sa bibliothèque de solutions qui peut contenir des informations importantes sur l'hôte demandé ou des données mise en cache suite à une requête antérieure. Si le serveur de noms ne possède pas déjà la réponse dans sa bibliothèque de solutions, il se tourne vers d'autres serveurs de noms, appelés serveurs de noms root (ou serveurs de noms racines), afin de déterminer les serveurs de noms faisant autorité pour le FQDN en question. Grâce à ces informations, il effectuera ensuite une requête auprès des serveurs de noms faisant autorité pour déterminer l'adresse IP de l'hôte en question. S'il effectue une opération dans le sens inverse (reverse lookup), la même procédure est utilisée, si ce n'est que la requête est présentée avec une adresse IP inconnue au lieu d'un nom.
Sur Internet, le FQDN d'un hôte peut être structuré en sections. Celles-ci sont ensuite organisées hiérarchiquement, comme un arbre, avec un tronc principal, des branches primaires, des branches secondaires, et ainsi de suite. Prenons, par exemple, le FQDN suivant :
bob.sales.example.com
Lors de l'analyse de la manière selon laquelle un FQDN trouve l'adresse IP qui renvoie à un système particulier, lisez le nom de droite à gauche, chaque niveau de la hiérarchie étant séparé par des points (.
). Dans notre exemple, l'élément com
définit le domaine de niveau supérieur pour ce FQDN. Le nom example
est un sous-domaine de com
alors que sales
est un sous-domaine de example
. Le nom le plus à gauche bob
identifie le nom d'hôte d'une machine particulière.
À l'exception du nom de domaine, chaque section s'appelle une zone et définit un espace de nom particulier. Un espace de nom contrôle l'attribution des noms des sous-domaines à sa gauche. Alors que cet exemple ne contient que deux sous-domaines, un FQDN doit contenir au moins un sous-domaine mais peut en inclure beaucoup plus, selon l'organisation choisie pour l'espace de nom.
Les zones sont définies sur des serveurs de noms qui font autorité par l'intermédiaire de fichiers de zone (décrivant entre autres, l'espace de nom de cette zone), les serveurs de courrier qui doivent être utilisés pour un domaine ou sous-domaine particulier, et bien plus encore. Les fichiers de zone sont stockés sur des serveurs de noms primaires (aussi appelés serveurs de noms maîtres), qui font vraiment autorité et constituent l'endroit où des changements peuvent être apportés aux fichiers ; les serveurs de noms secondaires (aussi appelés serveurs de noms esclaves) quant à eux reçoivent leurs fichiers de zone des serveurs de noms primaires. Tout serveur de noms peut être simultanément maître ou esclave pour différentes zones et peut aussi être considéré comme faisant autorité pour de multiples zones. Tout cela dépend de la configuration du serveur de noms.
Il existe quatre types de configuration possibles pour les serveurs de noms primaires :
Stocke les enregistrements de zone originaux faisant autorité pour un espace de nom particulier et répond aux questions d'autres serveurs de noms qui cherchent des réponses quant à cet espace de nom.
Répond aux requêtes d'autres serveurs de noms concernant les espaces de nom pour lesquels il est considéré comme faisant autorité. Les serveurs de noms esclaves reçoivent leurs informations d'espace de nom des serveurs de noms maîtres.
Offre des services de résolution de nom vers IP mais ne fait pas autorité pour quelque zone que ce soit. Les réponses pour toutes les résolutions sont placées en cache dans une base de données stockée en mémoire pour une période établie qui est spécifiée par l'enregistrement de zone importé.
Fait suivre des requêtes de résolution à une liste spécifique de serveurs de noms. Si aucun des serveurs de noms spécifiés ne peut effectuer la résolution, le processus s'arrête et la résolution a échoué.
Un serveur de noms appartenir à un ou plusieurs de ces types. Par exemple, un serveur de noms peut être non seulement maître pour certaines zones, esclave pour d'autres mais il peut également offrir seulement la transmission d'une résolution pour d'autres zones.
BIND fournit ses services de résolution de noms à l'aide du démon /usr/sbin/named
. BIND contient également un utilitaire d'administration appelé /usr/sbin/rndc
. De plus amples informations sur rndc
sont disponibles dans Section 8.4, « Utilisation de rndc
».
BIND stocke ses fichiers de configuration aux emplacements suivants :
/etc/named.conf
Le fichier de configuration pour le démon named
/var/named/
directory
Le répertoire de travail de named
qui stocke les fichiers de zone, de statistiques et les fichiers de cache.
Si vous avez installé le paquetage bind-chroot
, le service BIND démarrera dan l'environnement /var/named/chroot
. Tous les fichiers de configuration seront déplacés à cet endroit. Au même titre, named.conf
sera placé dans /var/named/chroot/etc/named.conf
, et ainsi de suite.
Si vous avez installé le paquetage caching-nameserver
, le fichier de configuration par défaut est /etc/named.caching-nameserver.conf
. Pour remplacer cette configuration par défaut, vous pouvez créer votre propre fichier de configuration dans /etc/named.conf
. Une fois que vous aurez redémarré, BIND utilisera le fichier personnalisé /etc/named.conf
à place du fichier de configuration par défaut.
Les sections suivantes examinent les fichiers de configuration de manière plus détaillée.
Le fichier named.conf
est une suite de déclarations utilisant des options imbriquées qui sont placées entre accolades, { }
. Lorsqu'ils modifient le fichier named.conf
, les administrateurs doivent veillez tout particulièrement à ne pas faire de fautes de syntaxe car des erreurs mineures en apparence empêcheront le démarrage du service named
.
Un fichier named.conf
typique est organisé de manière semblable à l'extrait ci-dessous :
<statement-1>
["<statement-1-name>
"] [<statement-1-class>
] { <option-1>
; <option-2>
; <option-N>
; }; <statement-2>
["<statement-2-name>
"] [<statement-2-class>
] { <option-1>
; <option-2>
; <option-N>
; }; <statement-N>
["<statement-N-name>
"] [<statement-N-class>
] { <option-1>
; <option-2>
; <option-N>
; };
Les types de déclarations suivants sont couramment utilisés dans /etc/named.conf
:
La déclaration acl
(de l'anglais access control list, ou déclaration de liste de contrôle d'accès) définit des groupes d'hôtes qui peuvent ensuite être autorisés ou non à accéder au serveur de noms.
Une déclaration acl
se présente sous le format suivant :
acl <acl-name>
{ <match-element>
; [<match-element>
; ...] };
Dans cette déclaration, remplacez <acl-name>
par le nom de la liste du contrôle d'accès et remplacez <match-element>
par une liste d'adresses IP séparées entre elles par un point virgule. La plupart du temps, une adresse IP individuelle ou la notation réseau de l'IP (telle que 10.0.1.0/24
) est utilisée pour identifier les adresses IP dans la déclaration acl
.
Les listes de contrôle d'accès suivantes sont déjà définies en tant que mots-clés afin de simplifier la configuration :
any
— Matches every IP address
localhost
— Matches any IP address in use by the local system
localnets
— Matches any IP address on any network to which the local system is connected
none
— Matches no IP addresses
Lorsqu'elles sont utilisées avec d'autres déclarations (telles que la déclaration options
), les déclarations acl
peuvent être très utiles pour éviter la mauvaise utilisation d'un serveur de noms BIND.
L'exemple ci-dessous établit deux listes de contrôle d'accès et utilise une déclaration options
pour définir la manière dont elles seront traitées par le serveur de noms :
acl black-hats { 10.0.2.0/24; 192.168.0.0/24; }; acl red-hats { 10.0.1.0/24; }; options { blackhole { black-hats; }; allow-query { red-hats; }; allow-recursion { red-hats; }; }
Cet exemple comporte deux listes de contôle d'accès, black-hats
et red-hats
. Les hôtes de la liste black-hats
se voient dénier l'accès au serveur de noms, alors que ceux de la liste red-hats
se voient eux donner un accès normal.
La déclaration include
permet à des fichiers d'être inclus dans un fichier named.conf
. Ce faisant, des données de configurations critiques (telles que les clés, keys
) peuvent être placées dans un fichier séparé doté de permissions restrictives.
Une déclaration include
se présente sous le format suivant :
include "<file-name>
"
Dans cette déclaration, <file-name>
est remplacé par le chemin d'accès absolu vers un fichier.
La déclaration options
définit les options globales de configuration serveur et établit des valeurs par défaut pour les autres déclarations. Cette déclaration peut être utilisée entre autres pour spécifier l'emplacement du répertoire de travail named
ou pour déterminer les types de requêtes autorisés.
La déclaration options
se présente sous le format suivant :
options { <option>
; [<option>
; ...] };
Dans cette déclaration, les directives <option>
sont remplacées par une option valide.
Ci-dessous figure une liste des options couramment utilisées :
allow-query
Spécifie les hôtes autorisés à interroger ce serveur de noms. Par défaut, tous les hôtes sont autorisés à interroger le serveur de noms. Il est possible d'utiliser ici une liste de contrôle d'accès ou un ensemble d'adresses IP ou de réseaux afin de n'autoriser que des hôtes particuliers à interroger le serveur de noms.
allow-recursion
Semblable à allow-query
, cette option s'applique à des demandes récursives. Par défaut, tous les hôtes sont autorisés à effectuer des demandes récursives sur le serveur de noms.
blackhole
Spécifie les hôtes qui ne sont pas autorisés à interroger le serveur de noms.
directory
Change le répertoire de travail named
pour une valeur autre que la valeur par défaut, /var/named/
.
forwarders
Spécifie une liste d'adresses IP valides correspondant aux serveurs de noms vers lesquels les requêtes devraient être envoyées pour la résolution.
forward
Contrôle le comportement de retransmission d'une directive forwarders
.
Les options suivantes sont acceptées :
first
— Specifies that the nameservers listed in the forwarders
directive be queried before named
attempts to resolve the name itself.
only
— Specifies that named
does not attempt name resolution itself in the event that queries to nameservers specified in the forwarders
directive fail.
listen-on
Spécifie l'interface réseau sur laquelle named
prend note des requêtes. Par défaut, toutes les interfaces sont utilisées.
De cette manière, si le serveur DNS sert également de passerelle, BIND peut être configuré de telle sorte qu'il réponde seulement aux requêtes en provenance de l'un des réseaux.
Ci-dessous figure un exemple de directive NS
:
options { listen-on { 10.0.1.1; }; };
Dans cet exemple, seules les requêtes qui proviennent de l'interface réseau servant le réseau privé (10.0.1.1
) sont acceptées.
notify
Établit si named
notifie les serveurs esclaves lorsqu'une zone est mise à jour. Les options suivantes sont acceptées :
yes
— Notifies slave servers.
no
— Does not notify slave servers.
explicit
— Only notifies slave servers specified in an also-notify
list within a zone statement.
pid-file
Spécifie l'emplacement du fichier de processus ID créé par named
.
root-delegation-only
Active l'application des propriétés de délégation dans les TLD (de l'anglais top-level domains ou domaines de premier niveau) et les zones root avec une liste d'exclusion facultative. Le procédé dit de Délégation consiste à diviser une zone unique en multiples sous-zones. Afin de créer une zone déléguée, des éléments connus sous le nom NS records sont utilisés. Ces informations NameServer (ou delegation records) précise les serveurs de noms d'autorité pour une zone particulière.
L'exemple suivant de root-delegation-only
spécifie une liste d'exclusion de TLD desquels des réponses non-déléguées sont attendues en toute confiance :
options { root-delegation-only exclude { "ad"; "ar"; "biz"; "cr"; "cu"; "de"; "dm"; "id"; "lu"; "lv"; "md"; "ms"; "museum"; "name"; "no"; "pa"; "pf"; "se"; "sr"; "to"; "tw"; "us"; "uy"; }; };
statistics-file
Spécifie un autre emplacement des fichiers de statistiques. Par défaut, les statistiques named
sont enregistrées dans le fichier /var/named/named.stats
.
De nombreuses autres options sont également disponibles, dont beaucoup dépendent les unes des autres pour fonctionner correctement. Consultez le document BIND 9 Administrator Reference Manual dans Section 8.7.1, « Documentation installée » et la page de manuel de bind.conf
pour obtenir de plus amples informations.
Une déclaration zone
définit les caractéristiques d'une zone tels que l'emplacement de ses fichiers de configuration et les options spécifiques à la zone. Cette déclaration peut être utilisée pour remplacer les déclarations globales d'options
.
Une déclaration zone
se présente sous le format suivant :
zone <zone-name>
<zone-class>
{ <zone-options>
; [<zone-options>
; ...] };
Dans la déclaration, <zone-name>
correspond au nom de la zone, <zone-class>
à la classe optionnelle de la zone et <zone-options>
représente une liste des options caractérisant la zone.
L'attribut <zone-name>
de la déclaration de zone est particulièrement important. Il représente la valeur par défaut assignée à la directive $ORIGIN
utilisée au sein du fichier de zone correspondant qui se trouve dans le répertoire /var/named/
. Le démon named
ajoute le nom de la zone à tout nom de domaine qui n'est pas pleinement qualifié, énuméré dans le fichier de zone.
Si vous avez installé le paquetage caching-nameserver
, le fichier de configuration par défaut se trouvera dans /etc/named.rfc1912.zones
.
Par exemple, si une déclaration zone
définit l'espace de nom pour example.com
, utilisez example.com
comme <zone-name>
afin qu'il soit placé à la fin des noms d'hôtes au sein du fichier de zone example.com
.
Pour obtenir de plus amples informations sur les fichiers de zone, reportez-vous à Section 8.3, « Fichiers de zone ».
Parmi les options les plus courantes de la déclaration de zone
figurent :
allow-query
Spécifie les clients qui sont autorisés à demander des informations à propos de cette zone. Par défaut toutes les requêtes d'informations sont autorisées.
allow-transfer
Spécifie les serveurs esclaves qui sont autorisés à demander un transfert des informations relatvies à la zone. Par défaut toutes les requêtes de transfert sont autorisées.
allow-update
Spécifie les hôtes qui sont autorisés à mettre à jour dynamiquement les informations dans leur zone. Par défaut aucune requête de mise à jour dynamique n'est autorisée.
Soyez très prudent lorsque vous autorisez des hôtes à mettre à jour des informations concernant leur zone. N'activez cette option que si l'hôte est sans aucun doute digne de confiance. De manière générale, il est préférable de laisser un administrateur mettre à jour manuellement les enregistrements de la zone et recharger le service named
.
file
Spécifie le nom du fichier qui figure dans le répertoire de travail named
et qui contient les données de configuration de la zone.
masters
Specifies the IP addresses from which to request authoritative zone information and is used only if the zone is defined as type
slave
.
notify
Détermine si named
notifie les serveurs esclaves lorsqu'une zone est mise à jour. Cette directive accepte les options suivantes :
yes
— Notifies slave servers.
no
— Does not notify slave servers.
explicit
— Only notifies slave servers specified in an also-notify
list within a zone statement.
type
Définit le type de zone.
Ci-après figure une liste des options valides :
delegation-only
— Enforces the delegation status of infrastructure zones such as COM, NET, or ORG. Any answer that is received without an explicit or implicit delegation is treated as NXDOMAIN
. This option is only applicable in TLDs or root zone files used in recursive or caching implementations.
forward
— Forwards all requests for information about this zone to other nameservers.
hint
— A special type of zone used to point to the root nameservers which resolve queries when a zone is not otherwise known. No configuration beyond the default is necessary with a hint
zone.
master
— Designates the nameserver as authoritative for this zone. A zone should be set as the master
if the zone's configuration files reside on the system.
slave
— Designates the nameserver as a slave server for this zone. Also specifies the IP address of the master nameserver for the zone.
zone-statistics
Configure named
pour qu'il conserve des statistiques concernant cette zone en les écrivant soit dans l'emplacement par défaut (/var/named/named.stats
), soit dans le fichier spécifié dans l'option statistics-file
de la déclaration server
. Reportez-vous à Section 8.2.2, « Autres types de déclarations »pour obtenir de plus amples informations sur la déclaration server
.
La plupart des changements apportés au fichier /etc/named.conf
d'un serveur de noms maître ou esclave implique l'ajout, la modification ou la suppression de déclarations de zone
. Alors que ces déclarations de zone
peuvent contenir de nombreuses options, la plupart des serveurs de noms nécessitent seulement quelques options pour fonctionner de manière efficace. Les déclarations de zone
figurant ci-dessous représentent des exemples très élémentaires pour illustrer une relation de serveurs de noms maître/esclave.
Ci-dessous se trouve un exemple de déclaration zone
pour le serveur de noms primaire hébergeant example.com
(192.168.0.1
) :
zone "example.com" IN { type master; file "example.com.zone"; allow-update { none; }; };
Dans cette déclaration, la zone est identifiée en tant que example.com
, le type est défini comme master
et le service named
a comme instruction de lire le fichier /var/named/example.com.zone
. Elle indique à named
de refuser la mise à jour à tout autre hôte.
La déclaration zone
d'un serveur esclave pour example.com
est légèrement différente de l'exemple précédent. Pour un serveur esclave, le type est slave
et une directive indiquant à named
l'adresse IP du serveur maître remplace la ligne allow-update
.
Ci-dessous se trouve un exemple de déclaration zone
de serveur de noms pour la zone example.com
:
zone "example.com" { type slave; file "example.com.zone"; masters { 192.168.0.1; }; };
Cette déclaration zone
configure named
sur le serveur esclave de manière à ce qu'il cherche le serveur maître à l'adresse IP 192.168.0.1
pour y trouver les informations concernant la zone appelée example.com
. Les informations que le serveur esclave reçoit du serveur maître sont enregistrées dans le fichier /var/named/example.com.zone
.
Ci-dessous se trouve une liste de types de déclarations moins fréquemment utilisés mais nénamoins disponibles au sein de named.conf
:
controls
Configure diverses contraintes de sécurité nécessaires â l'utilisation de la commande rndc
pour administrer le service named
.
Consultez Section 8.4.1, « Configuration de /etc/named.conf
» pour acquérir davantage de connaissances sur la structure de la déclaration controls
et sur les options disponibles.
key "<key-name>
"
Définit une clé spécifique par nom. Les clés servent à valider diverses actions, comme les mises à jour sécurisées ou l'utilisation de la commande rndc
. Deux options sont utilisées avec key
:
algorithm
— The type of algorithm used, such as <algorithm-name>
dsa
or hmac-md5
.
secret "
— The encrypted key.
<key-value>
"
Reportez-vous à Section 8.4.2, « Configuration de /etc/rndc.conf
» pour obtenir des instructions sur l'écriture d'une déclaration key
.
logging
Allows for the use of multiple types of logs, called channels. By using the channel
option within the logging
statement, a customized type of log can be constructed — with its own file name (file
), size limit (size
), versioning (version
), and level of importance (severity
). Once a customized channel is defined, a category
option is used to categorize the channel and begin logging when named
is restarted.
Par défaut, named
journalise des messages standards grâce au démon syslog
qui les place dans /var/log/messages
. Ce processus de journalisation a lieu car plusieurs canaux standards sont intégrés dans BIND, avec plusieurs niveaux d'importance (severity levels), comme default_syslog
(celui qui traite les messages de journalisation informationnels) et default_debug
(celui qui traite spécifiquement les messages de débogage). Une catégorie par défaut, appelée default
, utilise les canaux compris dans BIND pour accomplir la journalisation normale, sans configuration spéciale.
La personnalisation de la journalisation peut être un processus très détaillé qui dépasse le cadre du présent chapitre. Pour obtenir davantage d'informations sur la création de journaux personnalisés avec BIND, consultez le document intitulé BIND 9 Administrator Reference Manual dans Section 8.7.1, « Documentation installée ».
server
Définit des options particulières qui affectent la façon selon laquelle named
doit répondre aux serveurs de noms distants, particulièrement pour ce qui est des notifications et des transferts de zone.
L'option transfer-format
détermine si un enregistrement de ressources est envoyé avec chaque message (one-answer
) ou si des enregistrements de ressources multiples sont envoyés avec chaque message (many-answers
). Alors que l'option many-answers
est plus efficace, seuls les serveurs de noms BIND les plus récents peuvent la comprendre.
trusted-keys
Contient des clés publiques variées qui sont utilisées pour des DNS sécurisés (DNSSEC). Consultez Section 8.5.3, « Sécurité » pour obtenir de plus amples informations sur la sécurité avec BIND.
view "<view-name>
"
Crée des vues spéciales en fonction du réseau sur lequel l'hôte interroge le serveur de noms. Ce type de déclaration permet à certains hôtes de recevoir une réponse quant à une zone particulière alors que d'autres hôtes reçoivent des informations totalement différentes. Certains hôtes dignes de confiance peuvent également se voir accorder l'accès à certaines zones alors que d'autres hôtes qui ne sont pas dignes de confiance doivent limiter leurs requêtes à d'autres zones.
Il est possible d'obtenir de multiples vues mais leurs leurs noms doivent être uniques. L'option match-clients
spécifie les adresses IP qui s'appliquent à une vue particulière. Toute déclaration options
peut aussi être utilisée dans une vue, avec priorité sur les options globales déjà configurées pour named
. La plupart des déclarations view
contiennent de multiples déclarations zone
qui s'appliquent à la liste match-clients
. L'ordre dans lequel les déclarations view
sont énumérées est important, puisque c'est la première déclaration view
qui correspond à l'adresse IP d'un client, qui est utilisée.
Consultez Section 8.5.2, « Vues multiples » pour obtenir davantage d'informations sur la déclaration view
.
La liste suivante regroupe les balises (ou tags) de commentaire valides qui sont utilisés dans named.conf
:
//
— When placed at the beginning of a line, that line is ignored by named
.
#
— When placed at the beginning of a line, that line is ignored by named
.
/*
and */
— When text is enclosed in these tags, the block of text is ignored by named
.
Les Fichiers de zone contiennent des informations sur un espace de nom particulier et sont stockés dans le répertoire de travail named
qui est par défaut /var/named/
. Chaque fichier de zone est nommé selon les données d'options de file
dans la déclaration zone
, et ce, généralement d'une manière qui se réfère au domaine en question et identifie le fichier comme contenant des données de zone, telles que example.com.zone
.
Si vous avez installé le paquetage bind-chroot
, le service BIND démarrera dans l'environnement /var/named/chroot
. Tous les fichiers de configuration seront déplacés à cet endroit. Au même titre, vous pouvez trouver les fichiers de zone dans /var/named/chroot/var/named
.
Chaque fichier de zone peut contenir des directives et des enregistrements de ressources. Les directives donnent au serveur de noms l'instruction d'effectuer une certaine tâche ou d'appliquer des paramètres spéciaux à la zone. Les enregistrements de ressources définissent les paramètres de la zone, assignant des identités aux hôtes individuels. Les directives sont facultatives, mais les enregistrements de ressources sont requis pour fournir un service de nom à une zone.
Toutes les directives et enregistrements de ressources doivent être spécifiées sur des lignes individuelles.
Des commentaires peuvent être placés dans les fichiers de zone après les caractères points-virgules (;
).
Les directives sont identifiées par le symbole dollar ($
) suivit du nom de la directive. Elles apparaissent généralement en haut du fichier de zone.
Les directives les plus couramment utilisées sont les suivantes :
$INCLUDE
Configure named
de façon à ce qu'il inclue un autre fichier de zone dans ce fichier de zone à l'endroit où la directive apparaît. Ce faisant, il est possible de stocker des configurations de zone supplémentaires à l'écart du fichier de zone principal.
$ORIGIN
Attache le nom de domaine à des enregistrements non-qualifiés, comme ceux qui spécifient seulement l'hôte et rien de plus.
Par exemple, un fichier de zone peut contenir la ligne suivante :
$ORIGIN example.com.
Tous les noms utilisés dans les enregistrement de ressources qui ne se terminent pas par un point (.
) se verront ajouter example.com
.
L'utilisation de la directive $ORIGIN
n'est pas nécessaire si l'on nomme la zone dans /etc/named.conf
parce que le nom de la zone est utilisé par défaut, comme la valeur de la directive $ORIGIN
$TTL
Règle la valeur par défaut de Time to Live (TTL) (ou temps de vie) pour la zone. Cette valeur exprimée en secondes, correspond à la durée pendant laquelle un enregistrement de ressources de zone est valide. Chaque enregistrement de ressources peut contenir sa propre valeur TTL, qui remplace alors cette directive.
L'aumentation de cette valeur permet aux serveurs de noms distants de mettre en cache ces informations de zone pendant plus longtemps, réduisant ainsi nombre de requêtes effectuées au sujet de cette zone et rallongeant le temps nécessaire pour la prolifération des changements apportés aux enregistrements de ressources.
Les enregistrements de ressources représentent le premier composant d'un fichier de zone.
Il existe de nombreux types d'enregistrements de ressources des fichiers de zone. Ceux énumérés ci-dessous sont néanmoins les plus fréquemment utilisés :
A
Ceci fait référence à un enregistrement d'adresse qui spécifie une adresse IP à assigner à un nom, comme dans l'exemple ci-dessous :
<host>
IN A <IP-address>
Si la valeur <host>
est omise, alors un enregistrement A
renvoie à une adresse IP par défaut pour la partie supérieure de l'espace de nom. Ce système est la cible de toutes les requêtes non-FQDN.
Examinons les exemples d'enregistrements A
suivants pour le fichier de zone example.com
:
server1 IN A 10.0.1.3 IN A 10.0.1.5
Requests for example.com
are pointed to 10.0.1.3 or 10.0.1.5.
CNAME
Ceci fait référence à un enregistrement de nom canonique mappant un nom à un autre. Ce type d'enregistrement est plus connu sous le nom d'enregistrement d'alias.
L'exemple suivant indique à named
que toute requête envoyée à <alias-name>
devrait être dirigée vers l'hôte, <real-name>
. Les enregistrements CNAME
sont généralement utilisés pour pointer vers les services qui utilisent un procédé commun de nommage, comme par exemple, www
pour les serveurs Web.
<alias-name>
IN CNAME <real-name>
Dans l'exemple suivant, un enregistrement A
lie un nom d'hôte à une adresse IP alors qu'un enregistrement CNAME
pointe le nom d'hôte www
le fréquemment utilisé vers l'adresse.
server1 IN A 10.0.1.5 www IN CNAME server1
MX
Ceci fait référence à un enregistrement Mail eXchange, qui indique où devrait aller le courrier envoyé à un nom d'espace particulier contrôlé par cette zone.
IN MX <preference-value>
<email-server-name>
Dans cet exemple, <preference-value>
permet de classer numériquement les serveurs de messagerie pour un espace de nom, en donnant une préférence à certains systèmes de messagerie par rapport à d'autres. L'enregistrement de ressources MX
doté de la valeur <preference-value>
la plus basse est préféré aux autres. Toutefois, de multiples serveurs de messagerie peuvent avoir la même valeur pour distribuer uniformément le trafic d'emails entre eux.
L'option <email-server-name>
peut être un nom d'hôte ou un FQDN.
IN MX 10 mail.example.com. IN MX 20 mail2.example.com.
Dans cet exemple, le premier serveur de messagerie mail.example.com
est préféré au serveur de messagerie mail2.example.com
lors de la réception des courriers électroniques destinés au domaine example.com
.
NS
Ceci fait référence à un enregistrement de serveur de noms (NameServer) annonçant les serveurs de noms faisant autorité pour une zone particulière.
Ci-dessous figure un exemple d'enregistrement NS
:
IN NS <nameserver-name>
Ici, l'élément <nameserver-name>
devrait correspondre à un FQDN.
Ensuite, deux serveurs de noms sont répertoriés comme faisant autorité pour le domaine. Le fait que ces serveurs de noms soient esclaves ou que l'un d'eux soit maître n'a pas d'importance ; ils sont tous les deux considérés comme faisant autorisé.
IN NS dns1.example.com. IN NS dns2.example.com.
PTR
Ceci fait référence à un enregistrement PoinTeR, conçu pour pointer vers une autre partie de l'espace de nom.
Les enregistrements PTR
servent essentiellement à la résolution inverse des noms, puisqu'ils renvoient les adresses IP vers un nom particulier. Consultez Section 8.3.4, « Fichiers de résolution de noms inverse » pour obtenir des exemples supplémentaires d'utilisation des enregistrements PTR
.
SOA
Ceci fait référence à un enregistrement de ressources Start Of Authority, qui proclame des informations importantes faisant autorité sur un espace de nom pour le serveur de noms.
Situé après les directives, un enregistrement de ressources SOA
est le premier enregistrement de ressources dans un fichier de zone.
L'exemple qui suit montre la structure de base d'un enregistrement de ressources SOA
:
@ IN SOA <primary-name-server>
<hostmaster-email>
( <serial-number>
<time-to-refresh>
<time-to-retry>
<time-to-expire>
<minimum-TTL> )
Le symbole @
place la directive $ORIGIN
(ou le nom de zone, si la directive $ORIGIN
n'est pas déterminée) en tant qu'espace de nom défini par le présent enregistrement de ressources SOA
. Le nom d'hôte du serveur de noms primaire faisant autorité pour ce domaine est utilisé pour le <primary-name-server>
et l'adresse électronique de la personne à contacter à propos de cet espace de nom est remplacée par <hostmaster-email>
.
La directive <serial-number>
est incrémentée lors de chaque modification du fichier de zone afin que named
sache qu'il doit recharger cette zone. La valeur <time-to-refresh>
indique à tout serveur esclave combien de temps il doit attendre avant de demander au serveur de noms maître si des changements ont été effectués dans la zone. La valeur <serial-number>
est utilisée par le serveur esclave pour déterminer s'il est en train d'utiliser des données de zone périmées et doit par conséquent les rafraîchir.
La valeur <time-to-retry>
précise au serveur de noms esclave l'intervalle pendant lequel il doit attendre avant d'émettre une autre requête de rafraîchissement, au cas où le serveur de noms maître ne répondrait pas. Si le serveur maître n'a pas répondu à une requête de rafraîchissement avant que la durée indiquée dans <time-to-expire>
ne se soit écoulée, le serveur esclave cesse de répondre en tant qu'autorité pour les requêtes au sujet de cet espace de nom.
La valeur <minimum-TTL>
demande que d'autres serveurs de noms mettent en cache les informations pour cette zone pendant au moins cette durée définie.
Lors de la configuration de BIND, toutes les durées sont exprimées en secondes. Toutefois, il est également possible d'utiliser des abréviations pour des unités de temps autres que des secondes, comme les minutes (H
), les heures (H
), les jours (D
) et les semaines (W
). Le tableau dans Tableau 8.1, « Les secondes comparées à d'autres unités de temps » montre une durée exprimée en secondes et la période équivalente dans un autre format.
Secondes | Autres unités de temps |
---|---|
60
|
1M
|
1800
|
30M
|
3600
|
1H
|
10800
|
3H
|
21600
|
6H
|
43200
|
12H
|
86400
|
1D
|
259200
|
3D
|
604800
|
1W
|
31536000
|
365D
|
L'exemple suivant montre ce à quoi l'enregistrement d'une ressources SOA
peut ressembler lorsqu'il est configuré avec des valeurs réelles.
@ IN SOA dns1.example.com. hostmaster.example.com. ( 2001062501 ; serial 21600 ; refresh after 6 hours 3600 ; retry after 1 hour 604800 ; expire after 1 week 86400 ) ; minimum TTL of 1 day
Si on les observe individuellement, les directives et enregistrements de ressources peuvent être difficiles à comprendre. Cependant, tout devient beaucoup plus simple lorsqu'on peut les observer ensemble dans un seul fichier commun.
L'exemple suivant illustre un fichier de zone très élémentaire.
$ORIGIN example.com. $TTL 86400 @ IN SOA dns1.example.com. hostmaster.example.com. ( 2001062501 ; serial 21600 ; refresh after 6 hours 3600 ; retry after 1 hour 604800 ; expire after 1 week 86400 ) ; minimum TTL of 1 day IN NS dns1.example.com. IN NS dns2.example.com. IN MX 10 mail.example.com. IN MX 20 mail2.example.com. dns1 IN A 10.0.1.1 dns2 IN A 10.0.1.2 server1 IN A 10.0.1.5 server2 IN A 10.0.1.6 ftp IN A 10.0.1.3 IN A 10.0.1.4 mail IN CNAME server1 mail2 IN CNAME server2 www IN CNAME server1
In this example, standard directives and SOA
values are used. The authoritative nameservers are set as dns1.example.com
and dns2.example.com
, which have A
records that tie them to 10.0.1.1
and 10.0.1.2
, respectively.
Les serveurs de messagerie configurés par les enregistrements MX
pointent vers les serveurs server1
et server2
au moyen des enregistrements CNAME
. Puisque les noms des serveurs server1
et server2
ne finissent pas par un point (.
), le domaine $ORIGIN
est attaché, rallongeant le nom en server1.example.com
et server2.example.com
. Grâce aux enregistrements de ressources A
associés, leurs adresses IP peuvent être déterminées.
Les services FTP et Web services, disponibles aux noms ftp.example.com
et www.example.com
standard, sont pointés vers les serveurs appropriés en utilisant les enregistrements CNAME
.
This zone file would be called into service with a zone
statement in the named.conf
similar to the following:
zone "example.com" IN { type master; file "example.com.zone"; allow-update { none; }; };
Un fichier de zone de résolution de nom inverse est utilisé pour traduire une adresse IP dans un espace de nom particulier en un FQDN. Il ressemble beaucoup à un fichier de zone standard, sauf que les enregistrements de ressources PTR
servent à lier les adresses IP au nom d'un domaine pleinement qualifié.
L'exemple qui suit montre la structure de base d'un enregistrement PTR
:
<last-IP-digit>
IN PTR <FQDN-of-system>
L'élément <last-IP-digit>
fait référence au dernier chiffre d'une adresse IP qui pointe vers le FQDN d'un système particulier.
In the following example, IP addresses 10.0.1.1
through 10.0.1.6
are pointed to corresponding FQDNs. It can be located in /var/named/example.com.rr.zone
.
$ORIGIN 1.0.10.in-addr.arpa. $TTL 86400 @ IN SOA dns1.example.com. hostmaster.example.com. ( 2001062501 ; serial 21600 ; refresh after 6 hours 3600 ; retry after 1 hour 604800 ; expire after 1 week 86400 ) ; minimum TTL of 1 day 1 IN PTR dns1.example.com. 2 IN PTR dns2.example.com. 5 IN PTR server1.example.com. 6 IN PTR server2.example.com. 3 IN PTR ftp.example.com. 4 IN PTR ftp.example.com.
This zone file would be called into service with a zone
statement in the named.conf
file similar to the following:
zone "1.0.10.in-addr.arpa" IN { type master; file "example.com.rr.zone"; allow-update { none; }; };
Il existe peu de différences entre cet exemple et une déclaration zone
standard, sauf pour ce qui est de la manière de nommer l'hôte. Notez qu'une zone de résolution de noms inverse nécessite que les trois premiers blocs de l'adresse IP soient inversés, puis suivis de l'entité .in-addr.arpa
. Ce faisant, il est possible d'associer correctement à cette zone le bloc unique de nombres IP utilisé dans le fichier de zone de résolution de nom inverse.
BIND contient un utilitaire appelé rndc
qui permet d'utiliser des lignes de commande pour administrer le démon named
à partir de l'hôte local ou d'un hôte distant.
Afin d'empêcher l'accès non-autorisé au démon named
, BIND utilise une méthode d'authentification à clé secrète partagée pour accorder des privilèges aux hôtes. Ainsi, une clé identique doit être présente aussi bien dans /etc/named.conf
que dans le fichier de configuration de rndc
, à savoir /etc/rndc.conf
Si vous avez installé le paquetage bind-chroot
, le service BIND démarrera dans l'environnement /var/named/chroot
. Tous les fichiers de configuration seront déplacés à cet endroit. Au même titre, le fichier rndc.conf
est placé dans /var/named/chroot/etc/rndc.conf
.
Vous remarquerez que depuis que l'utilitaire rndc
ne démarre pas dans un envirronnement chroot
, /etc/rndc.conf
est un lien symbolique ( de l'anglais symlink) de /var/named/chroot/etc/rndc.conf
.
Pour que rndc
puisse se connecter à un service named
, une déclaration controls
doit être présente dans le fichier /etc/named.conf
du serveur BIND.
La déclaration controls
, décrite dans l'exemple qui suit, permet à rndc
de se connecter à partir d'un hôte local.
controls { inet 127.0.0.1 allow { localhost; } keys { <key-name>
; }; };
Cette déclaration indique à named
qu'il doit écouterle port TCP 953 par défaut de l'adresse inversée et doit 'autoriser les commandes rndc
provenant de l'hôte local, si la clé adéquate est donnée. Le <key-name>
fait référence à la déclaration key
, qui se trouve dans le fichier /etc/named.conf
. L'exemple suivant illustre une déclaration key
.
key "<key-name>
" { algorithm hmac-md5; secret "<key-value>
"; };
Dans ce cas, la déclaration <key-value>
utilise l'algorithme HMAC-MD5. Afin de créer des clés à l'aide de l'algorithme HMAC-MD5, utilisez la commande suivante :
dnssec-keygen -a hmac-md5 -b <bit-length>
-n HOST <key-file-name>
Une clé d'au moins 256 bits de long est un bon choix. La clé qui doit être placée dans la zone <key-value>
se trouve dans le fichier
généré par cette commande.
<key-file-name>
Étant donné que /etc/named.conf
est lisible par tout un chacun, il est judicieux de placer la déclaration key
dans un fichier séparé que seul le super-utilisateur (ou root) peut lire et utiliser ensuite une déclaration include
pour le référencer. Par exemple :
include "/etc/rndc.key";
La déclaration key
représente la déclaration la plus importante du fichier /etc/rndc.conf
.
key "<key-name>
" { algorithm hmac-md5; secret "<key-value>
"; };
Les éléments <key-name>
et <key-value>
doivent être absolument identiques aux paramètres les concernant qui figurent dans /etc/named.conf
.
Pour établir la correspondance entre les clés spécifiées dans le fichier /etc/named.conf
du serveur cible, ajoutez les lignes reproduites ci-dessous au fichier /etc/rndc.conf
.
options { default-server localhost; default-key "<key-name>
"; };
Cette directive détermine une clé globale par défaut. Toutefois, le fichier de configuration rndc
peut également spécifier différentes clés pour différents serveurs, comme le montre l'exemple suivant :
server localhost { key "<key-name>
"; };
Assurez-vous que seul le super-utilisateur (ou root) puisse effectuer des opérations de lecture et d'écriture dans le fichier /etc/rndc.conf
.
Pour obtenir davantage d'informations sur le fichier /etc/rndc.conf
, consultez la page de manuel de rndc.conf
.
Une commande rndc
se présente sous le format suivant :
rndc <options>
<command>
<command-options>
Lors de l'exécution de rndc
sur un hôte local configuré de façon appropriée, les commandes suivantes sont disponibles :
halt
— Stops the named
service immediately.
querylog
— Logs all queries made to this nameserver.
refresh
— Refreshes the nameserver's database.
reload
— Reloads the zone files but keeps all other previously cached responses. This command also allows changes to zone files without losing all stored name resolutions.
Si les changements n'affectent qu'une zone particulière, rechargez seulement cette zone en ajoutant le nom de la zone après la commande reload
.
stats
— Dumps the current named
statistics to the /var/named/named.stats
file.
stop
— Stops the server gracefully, saving any dynamic update and Incremental Zone Transfers (IXFR) data before exiting.
Dans certaines situations, il sera peut-être nécessaire d'annuler les paramètres par défaut contenus dans le fichier /etc/rndc.conf
. Les options suivantes sont disponibles :
-c
— Specifies the alternate location of a configuration file.
<configuration-file>
-p
— Specifies a port number to use for the <port-number>
rndc
connection other than the default port 953.
-s
— Specifies a server other than the <server>
default-server
listed in /etc/rndc.conf
.
-y
— Specifies a key other than the <key-name>
default-key
option in /etc/rndc.conf
.
Des informations supplémentaires sur ces options sont disponibles dans la page de manuel de rndc
.
La plupart des implémentations de BIND utilisent named
pour fournir un service de résolution de noms ou pour faire autorité pour un domaine ou sous-domaine particuliers. Toutefois, la version 9 de BIND possède aussi un certain nombre de fonctionnalités avancées qui permettent d'offrir un service DNS plus efficace et plus sécurisé.
Certaines de ces fonctionnalités avancées, comme DNSSEC, TSIG et IXFR (qui sont définies dans la section suivante), ne doivent être utilisées que dans les environnements réseau ayant des serveurs de noms qui prennent en charge ces fonctionnalités. Si votre environnement réseau inclut des serveurs de noms autres que BIND ou des versions de BIND plus anciennes, vérifiez que chaque fonctionnalité avancée est bien prise en charge avant d'essayer de l'utiliser.
Toutes les fonctionnalités mentionnées ici sont décrites en détail dans le document intitulé BIND 9 Administrator Reference Manual auquel Section 8.7.1, « Documentation installée » fait référence.
BIND prend en charge les transferts de zone incrémentaux (ou IXFR de l'anglais Incremental Zone Transfers) dans lesquels le serveur de noms esclave ne télécharge que les portions mises à jour d'une zone modifiée sur un serveur de noms maître. Le processus de transfert standard nécessite que la zone entière soit transférée vers chaque serveur de noms esclave même pour des changements mineurs. Pour des domaines très populaires avec des fichiers de zones très longs et pour de nombreux serveurs de noms esclaves, IXFR rend la notification et les processus de mise à jour bien moins exigeants en ressources.
Notez que IXFR n'est disponible que si vous utilisez une mise à jour dynamique pour apporter des modifications aux informations de zone maître. Si vous éditez manuellement des fichiers de zone pour effectuer des changements, le processus de transfert AXFR (Automatic Zone Transfer) est utilisé. Davantage d'informations sur les mises à jour dynamiques sont disponibles dans le document intitulé BIND 9 Administrator Reference Manual. Reportez-vous à Section 8.7.1, « Documentation installée » pour obtenir davantage d'informations.
En fonction de l'utilisation de la déclaration view
dans named.conf
, BIND peut fournir différentes informations en fonction du réseau d'où la requête provient.
Cette option est utilisée essentiellement pour refuser des entrées DNS confidentielles depuis des clients externes au réseau local, tout en permettant des requêtes provenant de clients internes au réseau local.
La déclaration view
utilise l'option match-clients
pour établir la correspondance entre des adresses IP ou des réseaux entiers et pour leur attribuer des options et des données de zones spéciales.
BIND supporte plusieurs méthodes différentes pour protéger la mise à jour et le transfert de zones, aussi bien sur les serveurs de noms maîtres qu'esclaves :
Abréviation de DNS SECurity, cette fonctionnalité permet de signer cryptographiquement des zones avec une clé de zone.
De cette façon, on peut vérifier que les informations relatives à une zone spécifique proviennent d'un serveur de noms qui les a signées avec une clé privée particulière, du moment que le receveur possède la clé publique de ce serveur de noms.
La version 9 de BIND prend aussi en charge la méthode d'authentification de messages SIG(0) utilisant un système de clé publique/privée.
Abréviation de Transaction SIGnatures ; cette fonctionnalité permet d'effectuer un transfert de maître à esclave, mais seulement après vérification qu'une clé secrète partagée existe sur le serveur maître et sur le serveur esclave.
Cette fonctionnalité renforce la méthode d'autorisation de transfert basée sur l'adresse IP standard. Un agresseur devra non seulement accéder à l'adresse IP pour transférer la zone, mais il devra aussi connaître la clé secrète.
La version 9 de BIND prend aussi en charge TKEY, qui est une autre méthode de clé secrète partagée pour autoriser les transferts de zone.
La version 9 de BIND prend en charge un service de noms dans des environnements IP version 6 (IPv6) grâce aux enregistrements de zone A6
.
Si votre environnement réseau inclut aussi bien des hôtes IPv4 que des hôtes IPv6, utilisez le démon de résolution léger lwresd
sur tous les clients du réseau. Ce démon est un serveur de noms très efficace, de type caching-only, qui prend en charge les nouveaux enregistrements d'informations A6
et DNAME
utilisés sous IPv6. Consultez la page de manuel de lwresd
pour obtenir davantage d'informations.
De manière générale, les débutants font fréquemment des erreurs en éditant des fichiers de configuration BIND. Évitez les problèmes suivants :
Assurez-vous de bien incrémenter le numéro de série lors de toute modification d'un fichier de zone.
Si le numéro de série n'est pas incrémenté, le serveur de noms maître possède certes les nouvelles informations correctes, mais les serveurs de noms esclaves ne sont jamais notifiés du changement ou ne tentent pas de rafraîchir leurs données concernant cette zone.
Be careful to use ellipses and semi-colons correctly in the /etc/named.conf
file.
Un point-virgule omis ou une ellipse non-fermée empêcheront named
de démarrer.
Remember to place periods (.
) in zone files after all FQDNs and omit them on hostnames.
Un point à la fin d'un nom de domaine indique un nom de domaine pleinement qualifié (en d'autres termes, complet). Si le point est omis, named
ajoutera le nom de la zone ou la valeur $ORIGIN
après le nom pour le compléter.
If a firewall is blocking connections from the named
program to other nameservers, edit its configuration file.
La version 9 de BIND utilise par défaut des ports aléatoires supérieurs à 1024 pour envoyer des requêtes à d'autres serveurs de noms. Toutefois certains pare-feu s'attendent à ce que tous les serveurs de noms communiquent uniquement en utilisant le port 53. Pour forcer named
à utiliser le port 53, ajoutez la ligne reproduite ci-dessous dans la déclaration options
de /etc/named.conf
:
query-source address * port 53;
Les sources d'information mentionnées ci-dessous fournissent de la documentation supplémentaire sur l'utilisation de BIND.
BIND propose une gamme complète de documentation installée couvrant de nombreux sujets, chacun d'eux étant placé dans son propre répertoire thématique. Remplacez <version-number>
par la version de bind
qui est installée sur le système :
/usr/share/doc/bind-<version-number>
/
Ce répertoire liste la plupart des nouvelles fonctionnalités.
/usr/share/doc/bind-<version-number>
/arm/
Ce répertoire contient les versions HTML et SGML du document intitulé BIND 9 Administrator Reference Manual, qui décrit de manière détaillée les ressources nécessaires pour BIND, la façon de configurer différents types de serveurs de noms, d'effectuer la répartition de charges ainsi que d'autres sujets avancés. Pour la plupart des nouveaux utilisateurs de BIND, ces ressources constituent le meilleur point de départ. Remplacez <version-number>
par la version de bind
qui est installée sur le système.
/usr/share/doc/bind-<version-number>
/draft/
Le répertoire contient différents documents techniques qui passent en revu les problèmes liés au service DNS et proposent des méthodes pour les aborder.
/usr/share/doc/bind-<version-number>
/misc/
Ce répertoire contient des documents conçus pour traiter de problèmes spécifiques avancés. Les utilisateurs de la version 8 de BIND devraient consulter le document migration
pour s'informer des modifications importantes à effectuer pour passer à la version 9 de BIND. Le fichier options
dresse une liste de toutes les options implémentées dans BIND 9 qui sont utilisées dans /etc/named.conf
.
/usr/share/doc/bind-<version-number>
/rfc/
Ce répertoire fournit tous les documents RFC associés à BIND.
Il existe un certain nombre de pages de manuel pour les diverses applications et les fichiers de configuration intervenant avec BIND. La liste suivante mentionne certaines des pages de manuel les plus importantes.
man rndc
— Explains the different options available when using the rndc
command to control a BIND nameserver.
man named
— Explores assorted arguments that can be used to control the BIND nameserver daemon.
man lwresd
— Describes the purpose of and options available for the lightweight resolver daemon.
man named.conf
— A comprehensive list of options available within the named
configuration file.
man rndc.conf
— A comprehensive list of options available within the rndc
configuration file.
http://www.isc.org/index.pl?/sw/bind/ — The home page of the BIND project containing information about current releases as well as a PDF version of the BIND 9 Administrator Reference Manual.
http://www.redhat.com/mirrors/LDP/HOWTO/DNS-HOWTO.html — Covers the use of BIND as a resolving, caching nameserver and the configuration of various zone files necessary to serve as the primary nameserver for a domain.
DNS and BIND by Paul Albitz and Cricket Liu; O'Reilly & Associates — A popular reference that explains both common and esoteric BIND configuration options, as well as providing strategies for securing a DNS server.
The Concise Guide to DNS and BIND by Nicolai Langfeldt; Que — Looks at the connection between multiple network services and BIND, with an emphasis on task-oriented, technical topics.
SSH™ (ou Secure SHell) est un protocole qui facilite les communications sécurisées entre deux systèmes en utilisant une architecture client/serveur et permet aux utilisateurs de se connecter à distance aux systèmes hôte de serveurs. Contrairement à d'autres protocoles de communication, tels que FTP ou Telnet, SSH crypte la session de connexion, ce qui rend la connexion difficile aux agresseurs ayant l'intention de recueillir des mots de passe non-cryptés.
SSH est conçu pour remplacer les applications de terminal plus anciennes et moins sécurisées qui sont utilisées pour se connecter à des hôtes distants, comme telnet
ou rsh
. Un programme similaire appelé scp
remplace des programmes moins récents conçus pour copier des fichiers entre des hôtes, tels que rcp
. Étant donné que ces applications plus anciennes ne cryptent pas les mots de passe entre le client et le serveur, il est recommandé d'éviter autant que possible de les utiliser. En effet, l'utilisation de méthodes sécurisées pour se connecter à des systèmes distants, réduit les risques aussi bien pour le système client que pour l'hôte distant.
SSH offre les précautions suivantes au niveau de la sécurité :
Après avoir effectué une connexion initiale, le client peut s'assurer que sa connexion est établie avec le même serveur que lors de sa session précédente.
Le client transmet ses données d'authentification au serveur au moyen d'un cryptage solide 128 bits.
Toutes les données envoyées et reçues lors d'une session sont transférées au moyen d'un cryptage 128 bits, rendant ainsi le décryptage et la lecture de toute transmission interceptée extrêmement difficile.
Le client peut retransmettre des applications X11[1] depuis le serveur. Cette technique appelée retransmission X11, fournit un moyen d'utiliser en toute sécurité des applications graphiques sur un réseau.
Étant donné que le protocole SSH crypte tout ce qu'il envoie et reçoit, il peut être utilisé pour sécuriser des protocoles autrement vulnérables. Grâce à la technique de retransmission de port, un serveur SSH peut être employé pour sécuriser des protocoles non-sécurisés tels que POP, augmentant ainsi la sécurité globale du système et de ses données.
Le serveur et le client OpenSSH peuvent aussi être configurés pour créer un tunnel similaire à un réseau privé virtuel pour le trafic entre les machines client et serveur.
Red Hat Enterprise Linux inclut le paquetage général OpenSSH (openssh
) ainsi que les paquetages OpenSSH pour le serveur (openssh-server
) et client (openssh-clients
). Notez que les paquetages OpenSSH requièrent le paquetage OpenSSL (openssl
) qui installe plusieurs bibliothèques cryptographiques permettant à OpenSSH de fournir des communications cryptées.
Les utilisateurs d'ordinateurs malintentionnés disposent d'une variété d'outils pour interrompre, intercepter et réacheminer le trafic réseau afin de s'octroyer l'accès à un système. D'une manière générale, ces menaces peuvent être répertoriées de la manière suivante :
Interception d'une communication entre deux systèmes — Dans ce scénario, le pirate peut se trouver quelque part sur le réseau entre les parties qui communiquent, pouvant ainsi copier toutes informations transmises entre elles. Le pirate peut intercepter et garder les informations ou peut les modifier avant de les envoyer au destinataire prévu.
Cette attaque peut être orchestrée en utilisant un programme renifleur — un utilitaire réseau courant.
Usurpation de l'identité d'un hôte — Grâce à cette technique, le système d'un agresseur est configuré de telle manière qu'il apparaît comme étant le destinataire souhaité d'une transmission. Si cette stratégie fonctionne, le système de l'utilisateur ne détecte pas qu'il communique en fait avec le mauvais hôte.
Ce type d'attaque peut être organisé grâce à l'utilisation de techniques appelées empoisonnements DNS[2] ou usurpation d'adresse IP[3].
Ces deux techniques permettent d'intercepter des informations potentiellement confidentielles et si cette interception est effectuée pour des raisons hostiles, le résultat peut être catastrophique.
L'utilisation du protocole SSH pour effectuer une connexion au shell à distance ou pour copier des fichiers permet de réduire considérablement ces menaces au niveau de la sécurité. En effet, le client et serveur SSH utilisent des signatures numériques pour vérifier leur identité respective. En outre, toute communication entre le système client et le système serveur est cryptée. Toute tentative d'usurpation d'identité à une extrémité ou à une autre de la communication est impossible puisque chaque paquet est crypté à l'aide d'une clé connue seulement par le système local et le système distant.
Le protocole SSH permet à tout programme client et serveur créé selon les spécifications du protocole, de communiquer de façon sécurisée et d'être utilisé de manière interchangeable.
À l'heure actuelle, il existe deux versions différentes du protocole SSH (la version 1 et la version 2). Sous Red Hat Enterprise Linux, la suite OpenSSH utilise la version SSH 2 dotée d'un algorithme d'échange de clés amélioré offrant une protection contre le type d'agression possible avec la version 1. Cependant, la suite OpenSSH prend en charge les connexions effectuées avec la version 1.
Autant que possible, il est conseillé d'utiliser des serveurs et clients compatibles avec la version 2.
Pour aider à protéger l'intégrité d'une communication SSH entre deux ordinateurs hôte, la série suivante d'événements doit être utilisée.
Une liaison cryptographique est établie afin de permettre au client de vérifier qu'il est bien en communication avec le serveur souhaité.
La couche de transport de la connexion entre le client et tout hôte distant est cryptée au moyen d'un chiffre symétrique.
Le client s'authentifie auprès du serveur.
Le client distant peut interagir avec l'hôte distant au moyen d'une connexion cryptée.
Le rôle principal de la couche de transport est de faciliter une communication sécurisée entre deux hôtes non seulement au moment de l'authentification, mais également lors de communications ultérieures. Pour ce faire, la couche de transport traite le cryptage et décryptage de données et offre une certaine protection quant à l'intégrité des paquets de données lors de leur envoi et de leur réception. De plus, la couche de transport effectue la compression des données permettant d'accélérer la vitesse de transfert des informations.
Lorsqu'un client communique avec un serveur au moyen d'un protocole SSH, de nombreux éléments importants sont échangés afin que les deux systèmes puissent créer correctement la couche de transport. Lors de cet échange, les opérations suivantes ont lieu :
Des clés sont échangées.
L'algorithme de cryptage de clés publiques est déterminé.
L'algorithme de cryptage symétrique est déterminé.
L'algorithme d'authentification de message est déterminé.
L'algorithme de hachage est déterminé.
Pendant l'échange de clé, le serveur s'identifie sur le client avec une clé d'hôte unique. Si auparavant le client n'a jamais communiqué avec ce serveur particulier, la clé d'hôte du serveur est alors inconnue pour le client et il ne se connecte pas. OpenSSH solutionne ce problème en acceptant la clé d'hôte du serveur. Ceci se produit après que l'utilisateur soit notifié et qu'il ait accepté et vérifié la clé d'hôte du serveur. Durant les autres connexions, la clé d'hôte du serveur est vérifiée par rapport à la version sauvegardée sur le client, assurant ainsi que le client communique vraiment avec le serveur désiré. Si, dans le futur, la clé d'hôte ne correspond plus, l'utilisateur doit supprimer la version sauvegardée sur le client avant qu'une connexion puisse avoir lieu.
Il est tout à fait possible pour un pirate de se faire passer pour le serveur SSH lors de la première connexion car le système local ne détecte aucune différence entre le serveur désiré et le faux serveur créé par le pirate. Afin d'éviter une telle situation, contrôlez l'intégrité d'un nouveau serveur SSH en contactant l'administrateur du serveur avant d'établir la première connexion ou au cas où une clé d'hôte ne correspond pas à celle stockée sur le serveur.
Le protocole SSH est conçu pour fonctionner avec n'importe quel algorithme de clé publique ou tout format de codage. Après que l'échange initial des clés crée une valeur de hachage utilisée pour les échanges et une valeur secrète partagée, les deux systèmes commencent immédiatement à calculer de nouveaux algorithmes et de nouvelles clés pour protéger l'authentification et les futures données envoyées via la connexion.
Après la transmission d'une certaine quantité de données au moyen d'une clé et d'un algorithme précis (la quantité exacte dépend de l'implémentation du protocole SSH), un nouvel échange de clés est effectué ; cette opération engendre la création d'un autre ensemble de valeurs de hachage et d'une autre valeur secrète partagée. De cette façon, même si un pirate réussit à déterminer les valeurs de hachage et la valeur secrète partagée, ces informations ne lui seront utiles que pour une durée limitée.
Une fois que la couche de transport a créé un tunnel sécurisé pour envoyer les informations entre les deux systèmes, le serveur indique au client les différentes méthodes d'authentification prises en charge, telles que l'utilisation d'une signature dotée d'une clé codée ou la saisie d'un mot de passe. Le client doit ensuite essayer de s'authentifier auprès du serveur au moyen d'une des méthodes spécifiées.
Les serveurs et clients SSH peuvent être configurés de façon à permettre différents types d'authentification, donnant à chacune des deux parties un niveau de contrôle optimal. Le serveur peut décider des méthodes de cryptage qu'il prend en charge en fonction de son modèle de sécurité et le client peut choisir l'ordre des méthodes d'authentification à utiliser parmi les options disponibles.
Après une authentification réussie sur la couche de transport SSH, de multiples canaux sont ouverts grâce à une technique appelée multiplexing[4]. Chacun de ces canaux traite la communication pour différentes sessions de terminal et pour des sessions X11 retransmises.
Le client et le serveur peuvent créer un nouveau canal. Chaque canal reçoit ensuite un numéro différent à chaque extrémité de la connexion. Lorsque le client essaie d'ouvrir un nouveau canal, il envoie le numéro du canal accompagné de la requête. Ces informations sont stockées par le serveur et utilisées pour diriger la communication vers ce canal. Cette procédure est utilisée afin que des types différents de session ne créent pas de nuisances mutuelles et de sorte qu'à la fin d'une session donnée, son canal puisse être fermé sans que la connexion SSH primaire ne soit interrompue.
Les canaux prennent aussi en charge le contrôle du flux de données, ce qui leur permet d'envoyer et de recevoir des données de façon ordonnée. Ce faisant, aucune donnée n'est envoyée sur le canal tant que l'hôte n'a pas reçu de message lui indiquant que le canal est ouvert.
Le client et le serveur négocient automatiquement la configuration de chaque canal, selon le type de service demandé par le client et la manière dont l'utilisateur est connecté au réseau. Ainsi, le traitement des différents types de connexions distantes est non seulement extrêmement flexible, mais il ne nécessite pas même d'apporter des modifications à la structure de base du protocole.
Pour exécuter un serveur OpenSSH, vous devez vous assurer que les paquetages RPM appropriés sont bien installés. Le paquetage openssh-server
est nécessaire et dépend du paquetage openssh
.
Le démon OpenSSH utilise le fichier de configuration /etc/ssh/sshd_config
. Le fichier de configuration par défaut devrait suffire dans la plupart des cas. Toutefois, si vous souhaitez une configuration du démon différente de celle fournie dans le fichier par défaut sshd_config
, consultez la page de manuel relative à sshd
afin d'obtenir une liste des mots clés pouvant être définis dans le fichier de configuration.
Si vous réinstallez un système, un nouvel ensemble de clés d'identification sera créé. Tous les clients y étant connectés avant la réinstallation avec des outils OpenSSH, verront le message suivant :
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ ATTENTION : L'IDENTIFICATION D'HÔTE À DISTANCE A CHANGÉ ! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IL EST POSSIBLE QUE QUELQU'UN FASSE UNE ACTION MAL INTENTIONNÉE ! Quelqu'un pourrait vous espionner en ce moment (man-in-the-middle attack) ! C'est également possible que la clé d'hôte RSA ait été changée.
Si vous souhaitez conserver les clés d'hôtes générées pour le système, sauvegardez les fichiers /etc/ssh/ssh_host*key*
et restaurez-les après la réinstallation. Ce processus permet de conserver l'identité du système si bien que lorsque les clients essaieront de se connecter au système après la réinstallation, ils ne recevront pas le message d'avertissement.
Pour que le protocole SSH soit vraiment efficace, il est essentiel de n'utiliser aucun protocole de connexion non-sécurisé, tel que Telnet et FTP. Sinon, il est possible de protéger le mot de passe d'un utilisateur en utilisant SSH pour une session, mais il pourra ensuite être intercepté lors d'une connexion ultérieure avec Telnet.
Ci-dessous figurent un certain nombre de services devant être désactivés :
telnet
rsh
rlogin
vsftpd
Pour désactiver des méthodes de connexion au système qui ne sont pas sécurisées, utilisez le programme en ligne de commande nommé chkconfig
, le programme basé sur ncurses appelé /usr/sbin/ntsysv ou l'application graphique Outil de configuration des services (system-config-services
). Tous ces outils nécessitent un accès de niveau super-utilisateur (ou root).
OpenSSH est constitué de deux ensembles de fichiers de configuration, un pour les programmes client (ssh
, scp
et sftp
) et l'autre pour le démon de serveur (sshd
).
Les informations de configuration SSH qui s'appliquent à l'ensemble du système sont stockées dans le répertoire /etc/ssh
:
moduli
— Fichier contenant les groupes Diffie-Hellman utilisés pour l'échange de clés Diffie-Hellman qui est crucial pour la création d'une couche de transport sécurisée. Lorsque les clés sont échangées au début d'une session SSH, une valeur secrète partagée ne pouvant être déterminée que conjointement par les deux parties, est créée. Cette valeur est ensuite utilisée pour effectuer l'authentification de l'hôte.
ssh_config
— Fichier de configuration client SSH pour l'ensemble du système. Il est écrasé si un même fichier est présent dans le répertoire personnel de l'utilisateur (~/.ssh/config
).
sshd_config
— Fichier de configuration pour le démon sshd
.
ssh_host_dsa_key
— Clé DSA privée utilisée par le démon sshd
.
ssh_host_dsa_key.pub
— Clé DSA publique utilisée par le démon sshd
.
ssh_host_key
— Clé RSA privée utilisée par le démon sshd
pour la version 1 du protocole SSH.
ssh_host_key.pub
— Clé RSA publique utilisée par le démon sshd
pour la version 1 du protocole SSH.
ssh_host_rsa_key
— Clé RSA privée utilisée par le démon sshd
pour la version 2 du protocole SSH.
ssh_host_rsa_key.pub
— Clé RSA publique utilisée par le démon sshd
pour la version 2 du protocole SSH.
Les informations de configuration SSH spécifiques à l'utilisateur sont stockées dans son répertoire personnel à l'intérieur du répertoire ~/.ssh/
où figurent :
authorized_keys
— Fichier contenant une liste de clés publiques autorisées pour les serveurs. Lorsque le client se connecte à un serveur, ce dernier authentifie le client en vérifiant sa clé publique signée qui est stockée dans ce fichier.
id_dsa
— Fichier contenant la clé DSA privée de l'utilisateur.
id_dsa.pub
— Clé DSA publique de l'utilisateur.
id_rsa
— Clé RSA privée utilisée par ssh
pour la version 2 du protocole SSH.
id_rsa.pub
— Clé RSA publique utilisée par ssh
pour la version 2 du protocole SSH.
identity
— Clé RSA privée utilisée par ssh
pour la version 1 du protocole SSH.
identity.pub
— Clé RSA publique utilisée par ssh
pour la version 1 du protocole SSH.
known_hosts
— Fichier contenant les clés d'hôtes DSA des serveurs SSH auxquels l'utilisateur a accédé. Ce fichier est très important car il permet de garantir que le client SSH se connecte au bon serveur SSH.
Si la clé d'hôte d'un serveur SSH a changé, le client informe l'utilisateur que le processus de connexion ne peut pas se poursuivre tant que la clé d'hôte du serveur n'a pas été supprimée du fichier known_hosts
à l'aide d'un éditeur de texte. Avant de procéder à cette opération, il est toutefois conseillé de contacter l'administrateur système du serveur SSH pour vous assurer que le serveur n'est pas compromis.
Consultez les pages de manuel de ssh_config
et sshd_config
pour obtenir plus d'informations sur les différentes directives disponibles dans les fichiers de configuration de SSH.
Pour vous connecter à un serveur OpenSSH depuis un ordinateur client, les paquetages openssh-clients
et openssh
doivent être préalablement installés sur cet ordinateur client.
La commande ssh
est un substitut sécurisé des commandes rlogin
, rsh
et telnet
. Elle vous permet de vous connecter à un ordinateur distant et d'y exécuter des commandes.
La connexion à un ordinateur distant au moyen de ssh
est semblable à la connexion utilisant telnet
. Par exemple, pour vous connecter à un ordinateur distant appelé penguin.exemple.net, entrez la commande suivante à l'invite du shell :
ssh penguin.example.net
La première fois que vous effectuez la connexion à un ordinateur distant à l'aide de ssh
, le système affiche un message semblable à celui-ci :
The authenticity of host 'penguin.example.net' can't be established. DSA key fingerprint is 94:68:3a:3a:bc:f3:9a:9b:01:5d:b3:07:38:e2:11:0c. Are you sure you want to continue connecting (yes/no)?
Saisissez yes
pour poursuivre. Ce faisant, le serveur sera ajouté à votre liste d'hôtes connus (~/.ssh/known_hosts
), comme le montre le message suivant :
Warning: Permanently added 'penguin.example.net' (RSA) to the list of known hosts.
Une invite vous demandera ensuite d'entrer votre mot de passe pour l'ordinateur distant. Après l'avoir entré, l'invite du shell apparaîtra sur l'ordinateur distant. Si vous n'indiquez pas de nom d'utilisateur, celui sous lequel vous êtes connecté sur l'ordinateur client local sera transmis à l'ordinateur distant. Si en revanche, vous souhaitez spécifier un nom d'utilisateur différent, utilisez la commande suivante :
ssh username
@penguin.example.net
Vous pouvez aussi avoir recours à la syntaxe ssh -l
.
username
penguin.example.net
La commande ssh
peut être utilisée pour exécuter une commande sur l'ordinateur distant sans vous connecter à une invite du shell. La syntaxe est alors ssh
. Si vous souhaitez, par exemple, exécuter la commande hostname
command
ls /usr/share/doc
sur l'ordinateur distant penguin.example.net, entrez la commande suivante à l'invite du shell :
ssh penguin.example.net ls /usr/share/doc
Une fois le bon mot de passe saisi, le contenu du répertoire distant /usr/share/doc
sera affiché et vous reviendrez ensuite à l'invite du shell.
La commande scp
peut être utilisée pour transférer des fichiers entre des ordinateurs au moyen d'une connexion cryptée sécurisée. Cette commande est semblable à rcp
.
La syntaxe générale correspondant au transfert d'un fichier local vers un système distant est la suivante :
scp<localfile>
username@tohostname:<remotefile>
Le fichier local, <localfile>
, spécifie la source, y compris le chemin au fichier, comme /var/log/maillog
. Le fichier distant <remotefile>
spécifie la destination, qui peut être un nouveau nom de fichier comme /tmp/hostname-maillog
. Pour le système distant, si le chemin ne commence pas par un /
, il correspondra au répertoire personnel de username
, par exemple /home/username/
.
Pour transférer le fichier local shadowman
vers le répertoire personnel de votre compte dans penguin.example.net, saisissez la commande suivante à une invite du shell (remplacez username
par votre propre nom d'utilisateur) :
scp shadowman username
@penguin.example.net:shadowman
Cette opération entraînera le transfert du fichier local shadowman
vers /home/
sur penguin.example.net. Vous pouvez également omettre username
/shadowmanshadowman
dans la commande scp
.
La syntaxe générale correspondant au transfert d'un fichier distant vers un système est la suivante :
scpusername@tohostname:<remotefile>
<newlocalfile>
Le fichier distant, <remotefile>
, spécifie la source, y compris le chemin, et le nouveau fichier local, <newlocalfile>
, spécifie la destination, y compris le chemin.
Il est également possible de spécifier plusieurs fichiers en tant que fichiers source. Par exemple, pour transférer le contenu du répertoire downloads/
vers un répertoire existant nommé uploads/
sur l'ordinateur distant penguin.example.net, saisissez les éléments ci-dessous à une invite du shell :
scp downloads/* username
@penguin.example.net:uploads/
L'utilitaire sftp
peut être utilisé pour ouvrir une session FTP interactive sécurisée. Il est semblable à ftp
mais, contrairement à ce dernier, utilise une connexion cryptée sécurisée. La syntaxe générale de cet utilitaire est sftp
. Une fois authentifié, vous pouvez utiliser un ensemble de commandes semblables à celles de FTP. Reportez-vous à la page de manuel relative à username@hostname.com
sftp
afin de consulter une liste de ces commandes. Pour consulter cette page de manuel, exécutez la commande man sftp
à l'invite du shell. L'utilitaire sftp
n'est disponible que dans les versions 2.5.0p1 ou supérieures d'OpenSSH.
Une interface sécurisée en ligne de commande n'est qu'une utilisation parmi tant d'autres, de SSH. En ayant la quantité nécessaire de bande passante, les sessions X11 peuvent être dirigées sur un canal SSH. Ou, en utilisant la retransmission TCP/IP, les connexions par port entre les systèmes, considérées auparavant comme étant non-sécurisées, peuvent être mappées à des canaux SSH spécifiques.
L'ouverture d'une session X11 par le biais d'une connexion SSH établie est aussi facile que la connexion au serveur SSH en utilisant l'option -Y
et l'exécution d'un programme X sur un ordinateur local.
ssh -Y <user>@example.com
Lorsqu'un programme X est exécuté à partir d'une invite du shell sécurisée, le client et le serveur SSH créent un nouveau canal sécurisé et les données du programme X sont ensuite envoyées à l'ordinateur client via ce canal d'une manière transparente.
La retransmission X11 peut être très utile. Elle peut être utilisée par exemple, pour créer une session interactive sécurisée de l'Outil de configuration de l'imprimante. Pour ce faire, connectez-vous au serveur en utilisant ssh et en saisissant :
system-config-printer &
Après avoir fourni le mot de passe du super-utilisateur pour le serveur, l'Outil de configuration de l'imprimante apparaît et permet à l'utilisateur distant de configurer en toute sécurité l'impression sur le système à distance.
Grâce à SSH, il est possible de sécuriser des protocoles TCP/IP non-sécurisés via la retransmission de port. En utilisant cette technique, le serveur SSH devient un conduit crypté vers le client SSH.
La retransmission de port consiste à mapper un port local du client vers un port distant du serveur. SSH permet de mapper un port quelconque du serveur vers un port quelconque du client ; pour que cette technique fonctionne, il n'est pas nécessaire qu'une correspondance existe entre ces numéros de port.
Pour créer un canal de retransmission de port TCP/IP qui écoute les connexions sur l'hôte local, utilisez la commande suivante :
ssh -Llocal-port
:remote-hostname
:remote-port
username
@hostname
Pour configurer la retransmission de port de manière à ce qu'elle écoute sur les ports inférieurs à 1024, il est nécessaire d'avoir un accès de niveau super-utilisateur (ou root).
Pour vérifier le courrier électronique sur un serveur nommé mail.example.com
en utilisant le protocole POP via une connexion cryptée, utilisez la commande ci-dessous :
ssh -L 1100:mail.example.com:110 mail.example.com
Une fois que le canal de retransmission de port est en place entre l'ordinateur client et le serveur messagerie, indiquez au client de messagerie POP3 d'utiliser le port 1100 sur l'hôte local afin de vérifier le nouveau courrier. Toutes les requêtes envoyées au port 1100 du système client seront transmises de façon sécurisée au serveur mail.example.com
.
Si mail.example.com
n'exécute pas un serveur SSH, mais qu'un autre ordinateur l'exécute, SSH peut toujours être utilisé pour sécuriser une partie de la connexion. Dans ce cas toutefois, une commande légèrement différente est nécessaire :
ssh -L 1100:mail.example.com:110 other.example.com
Dans cet exemple, des requêtes POP3 en provenance du port 1100 de l'ordinateur client sont retransmises vers le serveur SSH, other.example.com
par le biais de la connexion SSH sur le port 22 . Ensuite, other.example.com
se connecte au port 110 sur mail.example.com
pour vérifier la réception de nouveaux courriers. Notez qu'en utilisant cette technique, seule la connexion entre le système client et le serveur SSH other.example.com
est sécurisée.
La retransmission de port peut également être utilisée pour obtenir des informations de façon sécurisée à travers un pare-feu. Si le pare-feu est configuré de façon à permettre le trafic SSH par son port standard (22) mais bloque l'accès aux autres ports, une connexion entre deux ordinateurs hôte utilisant des ports bloqués est tout de même possible en redirigeant leur communication sur une connexion SSH établie.
L'utilisation de la retransmission de port pour transférer des connexions de cette façon permet à tout utilisateur du système client de se connecter à ce service. Si le système client est compromis, les pirates auront également accès aux services retransmis.
Les administrateurs système préoccupés quant à l'utilisation de la retransmission de port peuvent désactiver cette fonction sur le serveur en spécifiant le paramètre No
pour la ligne AllowTcpForwarding
dans /etc/ssh/sshd_config
et en redémarrant ensuite le service sshd
.
Si vous ne voulez pas avoir à entrer votre mot de passe à chaque fois que vous utilisez ssh
, scp
ou sftp
pour vous connecter à un ordinateur distant, vous pouvez créer une paire de clés d'autorisation.
Des clés doivent être créées pour chaque utilisateur. Afin de créer une paire de clés pour un utilisateur donné, suivez les étapes suivantes en tant que l'utilisateur souhaitant se connecter à des ordinateurs distants. Si vous le faites en tant que super-utilisateur, seul celui-ci pourra utiliser les clés.
Depuis la version 3.0 de OpenSSH, ~/.ssh/authorized_keys2
, ~/.ssh/known_hosts2
et /etc/ssh_known_hosts2
sont obsolètes. Les protocles SSH 1 et 2 partagent les fichiers ~/.ssh/authorized_keys
, ~/.ssh/known_hosts
et /etc/ssh/ssh_known_hosts
.
Red Hat Enterprise Linux 5.2 uses SSH Protocol 2 and RSA keys by default.
Si vous réinstallez le système, mais souhaitez conserver votre paire de clés, sauvegardez le répertoire .ssh
dans votre répertoire personnel. Une fois la réinstallation terminée, copiez-le de nouveau dans votre répertoire personnel (home). Ce processus peut être exécuté pour tous les utilisateurs de votre système, y compris le super-utilisateur.
Suivez les étapes indiquées ci-dessous afin de créer une paire de clés RSA pour la version 2 du protocole SSH. Il s'agit du démarrage par défaut avec OpenSSH 2.9
Pour créer une paire de clés RSA que vous utiliserez avec la version 2 du protocole, entrez la commande suivante à l'invite du shell :
ssh-keygen -t rsa
Acceptez l'emplacement par défaut du fichier, à savoir ~/.ssh/id_rsa
. Entrez ensuite une phrase d'accès différente du mot de passe de votre compte et confirmez-la, en la saisissant à nouveau.
La clé publique est enregistrée dans ~/.ssh/id_rsa.pub
, alors que la clé privée est enregistrée dans ~/.ssh/id_rsa
. Ne divulguez jamais votre clé privée.
Changez les autorisations de votre répertoire .ssh
à l'aide de la commande suivante :
chmod 755 ~/.ssh
Copiez le contenu de ~/.ssh/id_rsa.pub
dans le fichier ~/.ssh/authorized_keys
sur l'ordinateur auquel vous désirez vous connecter. Si le fichier ~/.ssh/authorized_keys
existe, vous pouvez ajouter le contenu du fichier ~/.ssh/id_rsa.pub
dans le fichier ~/.ssh/authorized_keys
sur l'autre ordinateur.
Changez les permissions du fichier authorized_keys
à l'aide de la commande suivante :
chmod 644 ~/.ssh/authorized_keys
Si vous utilisez GNOME ou un bureau graphique avec GTK2 + les bibliothèques installées, passez à la Section 9.7.3.4, « Configuration de ssh-agent
avec un GUI ». Si vous n'utilisez pas le système X Window, passez à la Section 9.7.3.5, « Configuration de ssh-agent
».
Suivez les étapes indiquées ci-dessous afin de créer une paire de clés DSA pour la version 2 du protocole SSH.
Pour créer une paire de clés DSA que vous utiliserez avec la version 2 du protocole, entrez la commande suivante à l'invite du shell :
ssh-keygen -t dsa
Acceptez l'emplacement par défaut du fichier, à savoir ~/.ssh/id_dsa
. Entrez ensuite une phrase d'accès différente du mot de passe de votre compte et confirmez-la, en la saisissant à nouveau.
Une phrase d'accès est une chaîne de mots et de caractères utilisée pour authentifier un utilisateur. Les phrases d'accès diffèrent des mots de passe dans le sens où les phrases d'accès peuvent inclure des espaces et des tabulations, contrairement aux mots de passe. De plus, elles sont généralement plus longues que les mots de passe car elles constituent de véritables phrases et non pas de simples mots.
La clé publique est enregistrée dans ~/.ssh/id_dsa.pub
, alors que la clé privée est enregistrée dans ~/.ssh/id_dsa
. Il est important de ne jamais communiquer votre clé privée à qui que ce soit.
Changez les permissions du répertoire .ssh
à l'aide de la commande suivante :
chmod 755 ~/.ssh
Copiez le contenu de ~/.ssh/id_dsa.pub
dans le fichier ~/.ssh/authorized_keys
sur l'ordinateur auquel vous souhaitez vous connecter. Si le fichier ~/.ssh/authorized_keys
existe, vous pouvez ajouter le contenu du fichier ~/.ssh/id_dsa.pub
dans le fichier ~/.ssh/authorized_keys
sur l'autre ordinateur.
Changez les permissions du fichier authorized_keys
à l'aide de la commande suivante :
chmod 644 ~/.ssh/authorized_keys
Si vous utilisez GNOME ou un environnement de bureau graphique avec le GTK2 + les bibliothèques installées, passez à la Section 9.7.3.4, « Configuration de ssh-agent
avec un GUI ». Si vous n'utilisez pas le système X Window, passez à la Section 9.7.3.5, « Configuration de ssh-agent
».
Suivez les étapes indiquées ci-dessous afin de créer une paire de clés RSA pour la version 1 du protocole SSH. Si vos connexions ne se font qu'entre des systèmes utilisant DSA, vous n'avez pas besoin d'une paire de clés RSA version 1.3 ou RSA version 1.5.
Pour générer une paire de clés RSA (pour les versions 1.3 et 1.5 du protocole), entrez la commande suivante à l'invite du shell :
ssh-keygen -t rsa1
Acceptez l'emplacement par défaut du fichier (~/.ssh/identity
). Entrez une phrase d'accès différente du mot de passe de votre compte. Confirmez-la en la saisissant à nouveau.
La clé publique est enregistrée dans ~/.ssh/identity.pub
, alors que la clé privée est enregistrée dans ~/.ssh/identity
. Ne divulguez jamais votre clé privée.
Modifiez les autorisations de votre répertoire .ssh
et de votre clé à l'aide des commandes chmod 755 ~/.ssh
et chmod 644 ~/.ssh/identity.pub
.
Copiez le contenu de ~/.ssh/identity.pub
dans le fichier ~/.ssh/authorized_keys
sur l'ordinateur auquel vous souhaitez vous connecter. Si le fichier ~/.ssh/authorized_keys
n'existe pas, vous pouvez copier le fichier ~/.ssh/identity.pub
dans le fichier ~/.ssh/authorized_keys
sur l'ordinateur distant.
Si vous utilisez GNOME, passez à la Section 9.7.3.4, « Configuration de ssh-agent
avec un GUI ». Si vous n'utilisez pas GNOME, passez à la Section 9.7.3.5, « Configuration de ssh-agent
».
Vous pouvez vous servir de l'utilitaire ssh-agent
pour enregistrer votre phrase d'accès afin de ne pas avoir à l'entrer à chaque fois que vous effectuez une connexion ssh
ou scp
. Si vous utilisez GNOME, le paquetage gnome-ssh-askpass
contient l'application qui peut être utilisée pour obtenir votre phrase d'accès à chaque fois que vous vous connectez à GNOME et pour la garder en mémoire jusqu'à ce que vous quittiez GNOME. Ainsi, vous n'avez pas à entrer votre mot de passe ou votre phrase d'accès lorsque vous effectuez une connexion ssh
ou scp
au cours d'une session GNOME. Si vous n'utilisez pas GNOME, passez à la Section 9.7.3.5, « Configuration de ssh-agent
».
Afin d'enregistrer votre phrase d'accès lors d'une session GNOME, suivez les étapes suivantes :
Le paquetage gnome-ssh-askpass
doit être préalablement installé. Vous pouvez utiliser la commande rpm -q openssh-askpass
afin de déterminer si ce dernier est bien installé. Si ce n'est pas le cas, procédez à son installation à l'aide de votre ensemble de CD-ROM Red Hat Enterprise Linux à partir d'un site miroir FTP Red Hat ou au moyen de Red Hat Network.
Sélectionnez le bouton Menu principal (sur le panneau) => Préférences => Plus de préférences => Sessions, et cliquez sur l'onglet Programmes de démarrage. Cliquez sur Ajouter et entrez /usr/bin/ssh-add
dans la zone texte de Commande de démarrage. Indiquez un numéro de priorité supérieur à toute autre commande existante afin de vous assurer qu'elle sera exécutée en dernier. Le nombre 70 par exemple (ou tout autre nombre plus élevé) est un bon choix de priorité pour ssh-add
. Plus le numéro de priorité est élevé, plus la priorité est basse. Par conséquent, si vous avez d'autres programmes répertoriés, leur numéro de priorité doit être le plus bas. Cliquez sur Arrêter pour sortir du programme.
Quittez GNOME et connectez-vous à nouveau ; en d'autres termes, redémarrez X Window. Une fois GNOME lancé, une boîte de dialogue apparaîtra et vous invitera à saisir votre ou vos phrases d'accès. Entrez la phrase demandée. Si vous avez configuré une paire de clés DSA et une paire de clés RSA, le système vous demandera d'entrer les deux phrases d'accès. À partir de ce moment, ssh
, scp
ou sftp
ne devrait plus vous demander votre mot de passe.
Vous pouvez vous servir de l'utilitaire ssh-agent
pour enregistrer votre phrase-mot de passe afin de ne pas avoir à l'entrer à chaque fois que vous effectuez une connexion ssh
ou scp
. Si vous n'utilisez pas le système X Window, suivez les étapes indiquées ci-dessous depuis l'invite du shell. En revanche, si vous utilisez GNOME, mais si vous ne voulez pas qu'il vous demande votre phrase-mot de passe lorsque vous vous connectez (voir la Section 9.7.3.4, « Configuration de ssh-agent
avec un GUI »), vous pouvez appliquer cette procédure dans une fenêtre de terminal de type Xterm. Si vous utilisez X Window, mais pas GNOME, vous pourrez appliquer cette procédure dans une fenêtre de terminal. Votre phrase-mot de passe ne sera cependant gardée en mémoire que pour cette fenêtre de terminal ; il ne s'agit pas d'un paramètre global.
À l'invite du shell, saisissez la commande suivante :
exec /usr/bin/ssh-agent $SHELL
Saisissez ensuite la commande :
ssh-add
et entrez votre ou vos phrases d'accès. Si vous avez plusieurs paires de clés configurées, le système vous invitera à entrer les phrases d'accès correspondantes.
Dès que vous vous déconnectez, vos phrases d'accès sont effacées de la mémoire du système. Vous devez exécuter ces deux commandes à chaque fois que vous vous connectez à une console virtuelle ou que vous ouvrez une fenêtre de terminal.
Les projets OpenSSH et OpenSSL faisant l'objet d'un développement continu, leur site Web respectif constitue la meilleure source d'informations de mises à jour. Les pages de manuel relatives aux outils OpenSSH et OpenSSL sont également très utiles et offrent de nombreuses informations détaillées.
Les pages de manuel relatives à ssh
, scp
, sftp
, sshd
et ssh-keygen
— Ces pages contiennent des informations sur la façon d'utiliser ces commandes, ainsi que sur les paramètres qui s'y rapportent.
http://www.openssh.com/ — Contient un Forum Aux Questions (FAQ) portant sur OpenSSH, des rapports de bogues, des listes de diffusion, les objectifs du projet ainsi que des explications plus techniques sur les fonctions de sécurité.
http://www.openssl.org/ — Contient un Forum Aux Questions (FAQ) portant sur OpenSSL, des listes de diffusion et une description de l'objectif du projet.
http://www.freessh.org/ — Contient le logiciel client SSH pour d'autres plates-formes.
[1] X11 fait référence au système d'affichage de fenêtres X11R7, généralement appelé X Window System ou X. Red Hat Enterprise Linux inclut X11R7, un système X Window System Open Source.
[2] L'empoisonnement DNS a lieu lorsqu'un intrus pénètre dans un serveur DNS, dirigeant les systèmes client vers la copie d'un hôte avec une intention malveillante.
[3] L'usurpation d'adresse IP se produit lorsqu'un intrus envoie des paquets réseau qui apparaissent faussement comme provenant d'un hôte de confiance du réseau.
[4] Une connexion multiplexée consiste en différents signaux envoyés à travers un milieu partagé et commun. Avec SSH, différents canaux sont envoyés à travers une connexion commune sécurisée.
autofs
/etc/exports
portmap
Un système de fichiers réseau (ou NFS de l'anglais Network File System), permet aux hôtes distants de monter des systèmes de fichiers sur un réseau et de les utiliser exactement comme des systèmes de fichiers locaux. Ceci permet aux administrateurs système de stocker des ressources sur des serveurs centralisés sur le réseau.
Ce chapitre se concentre sur les concepts fondamentaux de NFS et des références supplémentaires.
Actuellement il existe trois versions de NFS. NFS version 2 (NFSv2) est plus ancienne et plus largement prise en charge. NFS version 3 (NFSv3) possède plus de fonctionnalités, y compris le traitement de fichiers 64-bit, les écritures Safe Async et une gestion plus efficace des erreurs. NFS version 4 (NFSv4) fonctionne à travers des pare-feu et sur Internet, n'exige plus un mappeur de port, prend en charge les ACL et utilise des opérations stateful. Red Hat Enterprise Linux prend en charge les clients NFSv2, NFSv3 et NFSv4, et quand un système de fichiers est monté via NFS, Red Hat Enterprise Linux utilise NFSv3 par défaut, si le serveur le prend en charge.
Toutes les versions de NFS peuvent utiliser le protocole TCP (de l'anglais Transmission Control Protocol ) exécuté sur un réseau IP, sachant qu'il est nécessaire pour NFSv4. NFSv2 et NFSv3 peuvent utiliser le protocole UDP (de l'anglais User Datagram Protocol) exécuté sur un réseau IP pour fournir une connexion réseau sans état (aussi qualifiée de stateless) entre le client et le serveur.
Quand on utilise NFSv2 ou NFSv3 avec UDP, la connexion stateless UDP comporte en temps normal moins de coûts de protocole qu'avec TCP, ce qui entraîne de meilleures performances sur des réseaux propres et non congestionnés. Le serveur NFS envoie un traitement de fichiers au client après l'autorisation donnée au client d'accéder au volume partagé. Ce traitement de fichiers est un objet opaque, stocké côté serveur et passé avec les requêtes RPC provenant du client. Le serveur NFS peut être redémarré sans affecter le client et ni le cookie, qui restent intacts. Cependant, étant donné que UDP est stateless, si le serveur se plante subitement, les clients UDP continuent de saturer le réseau avec leurs requêtes au serveur. C'est pourquoi, TCP est le protocole favori pour une connexion au serveur NFS.
NFSv4 n'a aucune interaction avec le mappeur de port, rpc.mountd
, rpc.lockd
, et rpc.statd
, puisque la prise en charge du protocole a été intégrée dans le protocole v4. NFSv4 écoute sur le port TCP (2049) bien connu, qui élimine la nécessité d'interaction du portmapper
. Les protocoles de montage et de verrouillage ont été incorporés dans le protocole V4, qui élimine la nécessité d'interaction avec rpc.mountd
et rpc.lockd
.
TCP est le protocole de transport par défaut pour NFS sous Red Hat Enterprise Linux. UDP peut être utilisé pour la compatibilité si besoin est, mais n'est pas recommandé pour une utilisation plus vaste.
Tous les démons RPC/NFS ont une option de ligne de commande '-p'
qui peut définir le port, ce qui rend la configuration du pare-feu plus facile.
Après que le client ait obtenu l'accès par les enveloppeurs TCP, le serveur NFS réfère /etc/exports
à son fichier de configuration, pour déterminer si le client est autorisé à accéder aux systèmes de fichiers exportés. Une fois la permission donnée, toutes les opérations fichiers et répertoires sont disponibles à l'utilisateur.
Pour le bon fonctionnement de NFS avec une installation par défaut de Red Hat Enterprise Linux, un pare-feu activé, les IPTables avec le port TCP 2049 par défaut doivent être configurés. Sans une configuration correcte des IPTables, NFS ne fonctionnera pas correctement.
Le script d'initialisation NFS et le processus rpc.nfsd
permettent maintenant la liaison à tout port spécifié durant le démarrage du système. Cependant, cela peut entraîner des erreurs si le port n'est pas disponible, ou des conflits avec un autre démon.
Red Hat Enterprise Linux utilise à la fois une prise en charge au niveau du noyau et au niveau des processus démons pour fournir le partage de fichiers à NFS. Toutes les versions NFS, dépendent des Appels de procédure distants (RPC de l'anglais Remote Procedure Calls) entre les clients et les serveurs. Les services RPC sous Linux sont contrôlés par le service portmap
. Pour partager ou monter des systèmes de fichiers NFS, les services suivants fonctionnent en collaboration, selon la version NFS implémentée :
nfs
— (/sbin/service nfs start
) Démarre le serveur NFS et les processus appropriés RPC pour traiter les requêtes pour les systèmes de fichiers NFS partagés.
nfslock
— (/sbin/service nfslock start
) Service obligatoire qui démarre les processus RPC appropriés pour permettre aux clients NFS de verrouiller les fichiers sur le serveur.
portmap
— Accepte les réservations de port des services locaux RPC. Ces ports sont alors rendus disponibles (ou ils sont publiés) afin que les services RPC distants correspondants puissent y accéder. portmap
répond aux requêtes pour les services RPC et établit des connexions au service RPC requis. Ce service n'est pas utilisé avec NFSv4.
Les processus RPC suivants facilitent les services NFS :
rpc.mountd
— Ce processus reçoit la requête de montage en provenance d'un client NFS et vérifie que le système de fichiers demandé est bien exporté. Ce processus est démarré automatiquement par le service nfs
et ne nécessite pas de configuration au niveau de l'utilisateur. Ce processus n'est pas utilisé avec NFSv4.
rpc.nfsd
— Permet aux versions NFS et protocoles explicites que le serveur publie, d'être définis. Il fonctionne avec le noyau Linux pour satisfaire les requêtes dynamiques des clients NFS, comme par exemple pour fournir des fils de serveur (ou threads) chaque fois qu'un client NFS se connecte. Ce processus correspond au service nfs
.
rpc.lockd
— Permet aux clients NFS de verrouiller les fichiers sur le serveur. Si rpc.lockd
n'est pas démarré, le verrouillage du fichier échoue. rpc.lockd
implémente le protocole NLM (de l'anglais Network Lock Manager). Ce processus correspond au service nfslock
. Ce processus n'est pas utilisé avec NFSv4.
rpc.statd
— Ce processus implémente le protocole RPC (de l'anglais Network Status Monitor) qui avertit les clients NFS lorsqu'un serveur est redémarré sans avoir été préalablement arrêté correctement. Ce processus est lancé automatiquement par le service nfslock
et ne nécessite pas de configuration au niveau de l'utilisateur. Ce processus n'est pas utilisé avec NFSv4.
rpc.rquotad
— Ce processus fournit des informations sur les quotas utilisateur s'appliquant aux utilisateurs distants. Il est lancé automatiquement par le service nfs
et ne nécessite pas de configuration au niveau de l'utilisateur.
rpc.idmapd
— Ce processus fournit au client et serveur NFSv4 des appels ascendants (aussi appelés upcalls) qui établissent la correspondance entre les noms NFSv4 (qui sont des chaînes se présentant sous la forme utilisateur@domaine) et les UID et GID locaux. Pour que idmapd
puisse fonctionner avec NFSv4, /etc/idmapd.conf
doit être configuré. Ce service est nécessaire pour une utilisation avec NFSv4.
Les partages NFS sont montés côté client à l'aide de la commande mount
. Le format de la commande est comme suit :
mount -t <nfs-type>
-o <options>
<host>
:</remote/export>
</local/directory>
Remplacez <nfs-type>
avec soit nfs
pour NFSv2 ou les serveurs NFSv3, ou nfs4
pour les serveurs NFSv4. Remplacez <options>
avec une liste d'options séparées par une virgule pour le système de fichiers NFS (consultez la Section 10.4, « Options courantes de montage NFS » pour de plus amples informations). Remplacez <host>
avec l'hôte distant, </remote/export>
avec le répertoire distant en cours de montage, et </local/directory>
avec le répertoire local où le système de fichiers distant doit être monté.
Pour plus d'informations, veuillez consulter la page de manuel mount
.
Quand on accède au partage NFS en saisissant manuellement la commande mount
, le système de fichiers doit être remonté manuellement après le redémarrage du système. Red Hat Enterprise Linux offre deux méthodes pour le montage automatique des systèmes de fichiers distants au moment du lancement : le fichier /etc/fstab
ou le service autofs
.
Pour monter un partage NFS de façon alternative et à partir d'une autre machine, vous pouvez également ajouter une ligne au fichier /etc/fstab
. La ligne doit contenir le nom d'hôte du serveur NFS, le répertoire du serveur qui est exporté et le répertoire de l'ordinateur local où vous désirez monter le partage NFS. Vous devez être connecté en tant que super-utilisateur (ou root) pour pouvoir modifier le fichier /etc/fstab
.
La syntaxe générale de la ligne contenue dans /etc/fstab
est la suivante :
server:/usr/local/pub /pub nfs rsize=8192,wsize=8192,timeo=14,intr
Le point de montage /pub
doit exister sur l'ordinateur client avant que la commande ne puisse être exécutée. Après avoir ajouté cette ligne à /etc/fstab
sur le système client, entrez la commande mount /pub
à l'invite de shell et le point de montage /pub
sera monté à partir du serveur.
Le fichier /etc/fstab
est référencé par le service netfs
au moment du lancement, ainsi les lignes référençant les partages NFS ont le même effet que de saisir manuellement la commande mount
durant le processus de lancement.
Une ligne échantillon /etc/fstab
pour monter un export NFS ressemble à l'exemple suivant :
<server>
:</remote/export>
</local/directory>
<nfs-type>
<options>
0 0
Remplacez
par le nom d'hôte, l'adresse IP ou le nom de domaine pleinement qualifié du serveur exportant le système de fichiers.
<server>
Remplacez
par le chemin vers le répertoire exporté.
</remote/export>
Remplacez
avec le système de fichiers local sur lequel le répertoire exporté est monté. Ce point de montage doit exister avant que </local/directory>
/etc/fstab
ne soit lu ou le montage échoue.
Remplacez
avec soit <nfs-type>
nfs
pour NFSv2 ou les serveurs NFSv3, ou nfs4
pour les serveurs NFSv4.
Remplacez <options>
avec une liste d'options séparées par une virgule pour le système de fichiers NFS (consultez la Section 10.4, « Options courantes de montage NFS » pour plus d'informations). Consultez la page de manuel fstab
pour de plus amples informations.
Un des inconvénients de l'utilisation de /etc/fstab
est que peu importe la rareté des accès d'un utilisateur au système de fichiers monté NFS, le système doit dédier des ressources pour maintenir en place le système de fichiers monté. Cela n'est pas un problème avec un ou deux montages, mais quand le système maintient des montages sur de nombreux systèmes simultanément, les performances générales peuvent en pâtir. Il existe une alternative à /etc/fstab
; elle consiste dans l'utilisation de l'utilitaire d'automontage basé sur le noyau. Un automontage comporte deux composants. L'un est un module de noyau qui implémente un système de fichiers, alors que l'autre est un démon espace utilisateur qui se charge de toutes les autres fonctions. L'utilitaire d'automontage peut monter et démonter les systèmes de fichiers NFS automatiquement (montage sur demande), économisant par là, les ressources de système. L'utilitaire automontage peut être utilisé pour monter d'autres systèmes de fichiers AFS, SMBFS, CIFS et des fichiers de systèmes locaux.
autofs
utilise /etc/auto.master
(fichier de configuration maître) comme son fichier de configuration principal par défaut. Cela peut être modifié afin d'utiliser une autre source et nom de réseau supportés, en utilisant la configuration autofs (dans /etc/sysconfig/autofs
) en conjonction avec le mécanisme de Name Service Switch. Une instance de la version 4 du démon a été exécutée pour chaque point de montage configuré dans le fichier de configuration maître et il pourrait donc être exécuté manuellement à partir de la ligne de commande pour chaque point de montage donné. Cela n'est pas possible avec la version 5 parce qu'elle n'utilise qu'un seul démon pour gérer tous les points de montage configurés, ainsi tous les points de montage doivent être configurés dans le fichier de configuration maître. Cela correspond bien aux exigences communes d'autres automontages standards. Le point de montage, le nom d'hôte, des répertoires exportés et des options peuvent tous être spécifiés dans un ensemble de fichiers (ou autres sources réseau prises en charge) plutôt que de les configurer manuellement pour chaque hôte. Veuillez vous assurer que vous avez installé le paquetage autofs
si vous désirez utiliser ce service.
Les maps directes autofs fournissent un mécanisme pour le montage automatique des systèmes de fichiers à des points arbitraires dans la hiérarchie du système de fichiers. Une map directe est caractérisée par un point de montage de "/-" dans le fichier de configuration maître. Les entrées dans une map directe contiennent un nom de chemin absolu comme une clé (plutôt que les noms de chemin relatifs utilisés dans les maps indirectes).
Les entrées de map multimontages décrivent une hiérarchie de points de montage sous une seule clé. La map "-hosts" en est un bon exemple, communément utilisée pour les automontages de tous les exports à partir d'un hôte sous "/net/<host>
" comme entrée de map multimontages. Quand on utilise la map "-hosts
", un "ls
" de "/net/<host>
" montera des montages de trigger autofs pour chaque export à partir de <host>
, les montera et les supprimera lors de leur accès. Cela peut considérablement réduire le nombre de montages actifs nécessaires quand on accède à un serveur avec un nombre important d'exports.
La prise en charge LDAP (de l'anglais "Lightweight Directory Access Protocol") dans la version 5 autofs a été améliorée de plusieurs manières, comparé à la version 4 autofs. Le fichier de configuration autofs (/etc/sysconfig/autofs
) fournit un mécanisme pour spécifier les schémas autofs qu'un site implémente, excluant ainsi la nécessité de déterminer cela par tâtonnement dans l'application elle-même. Par ailleurs, des liaisons authentifiées vers le serveur LDAP sont maintenant supportées, au moyen de la plupart des mécanismes supportés par les implémentations communes du serveur LDAP. Un nouveau fichier de configuration a été ajouté pour ce support : /etc/autofs_ldap_auth.conf
. Le fichier de configuration par défaut est auto-documenté et utilise un format XML.
nsswitch
)
Le fichier de configuration Name Service Switch existe pour fournir un moyen de déterminer la provenance de données spécifiques de configuration. La raison pour cette configuration est d'accorder aux administrateurs la flexibilité d'utiliser la base de données back end de leur choix, alors qu'ils maintiennent une interface logiciel uniforme pour accéder aux données. Bien que la version 4 d'automontage s'améliore constamment dans la manipulation de la configuration du name service switch, elle n'est toutefois pas encore complète. Par contre, la version 5 Autofs, est une implémentation complète. Consultez la page de manuel nsswitch.conf pour plus d'informations sur la syntaxe supportée de ce fichier. Veuillez noter que toutes les bases de données nss ne sont pas des sources de maps valides et que le parseur rejettera celles qui ne sont pas valides. Les sources valides sont les fichiers yp, nis, nisplus, ldap et hesiod.
Bien qu'elles soient fréquemment utilisées, les entrées multiples des fichiers de configuration maîtres pour les points de montage directs "/-" n'ont pas encore été mentionnées. Les clés de map pour chaque entrée fusionnent et fonctionnent comme une seule map.
Voici un exemple ci-dessous de maps de test connectathon pour les montages directs :
/- /tmp/auto_dcthon /- /tmp/auto_test3_direct /- /tmp/auto_test4_direct
Le fichier de configuration primaire pour l'automontage est /etc/auto.master
, aussi appelé le fichier de configuration maître qui peut être changé comme décrit dans l'introduction ci-dessus. Le fichier de configuration maître liste les points de montage contrôlés par autofs sur le système, et leurs fichiers de configuration correspondants ou les sources réseau connues comme les maps d'automontage. Le format de ce fichier de configuration maître est comme suit :
<mount-point> <map-name> <options>
où :
mount-point
est le point de montage autofs par ex. /home
.
map-name
est le nom d'une source de map qui contient une liste de points de montage, et l'emplacement du système de fichiers à partir duquel ces points de montage devraient être montés. La syntaxe pour une entrée de map est décrite ci-dessous.
Les options
, si spécifiées, seront appliquées pour toutes les entrées dans la map donnée, cela dit, si elles n'ont pas elles-mêmes des options spécifiées. Ce comportement est différent de la version 4 autofs où les options étaient cumulatives. Cela a été modifié pour répondre à notre principal objectif, c'est-à-dire la compatibilité d'environnements mixtes.
Ce qui suit est un fichier échantillon /etc/auto.master
:
$ cat /etc/auto.master /home /etc/auto.misc
Le format général des maps est similaire au fichier de configuration maître, cependant les "options" apparaissent entre le point de montage et l'emplacement au lieu d'apparaître à la fin de l'entrée comme dans le fichier de configuration maître :
<mount-point> [<options>] <location>
où :
<mount-point>
est le point de montage autofs. Cela peut être le nom d'un répertoire unique pour un montage indirect ou le nom complet du chemin du point de montage pour les montages directs. Chaque clé d'entrée de map directe et indirecte (<mount-point>
ci-dessus) peut être suivie d'une liste séparée par un espace, de répertoires offset (les noms de sous-répertoires commençant chacun par un "/") ce qui en fait des entrées mutlimontages.
<options>, si spécifiées, sont les options de montage pour les entrées de map qui ne spécifient pas leurs propres options.
<location> est l'emplacement du système de fichiers comme le chemin du système de fichiers local (précédé du caractère escape pour le format map de Sun ":" pour les noms de map commençant par "/"), un système de fichiers NFS ou autre emplacement valide de système de fichiers.
Ce qui suit est un échantillon de fichier map :
$ cat /etc/auto.misc payroll -fstype=nfs personnel:/dev/hda3 sales -fstype=ext3 :/dev/hda4
La première colonne dans un fichier map indique le point de montage autofs (ventes
et masse salariale
du serveur appelé personnel
). La seconde colonne indique les options pour le montage autofs alors que la troisième colonne indique la source du montage. Selon la configuration ci-dessus, les points de montage autofs seront /acceuil/masse salariale
et /accueil/ventes
. L'option-fstype=
est souvent omise et de façon générale, n'est pas nécessaire.
L'automontage créera les répertoires s'ils n'existent pas déjà. Si les répertoires existent avant que l'automontage ne démarre, l'automontage ne les supprime pas quand il s'arrête. Vous pouvez démarrer ou redémarrer le démon automount en saisissant la commande suivante :
$/sbin/service autofs start
ou$/sbin/service autofs restart
Au moyen de la configuration ci-dessus et si un processus nécessite un accès à un répertoire autofs non-monté comme /home/payroll/2006/July.sxc
, le démon automount monte automatiquement le répertoire. Si un timeout est spécifié, le répertoire sera automatiquement démonté s'il n'est pas accédé durant la période de timeout.
Vous pouvez visionner le statut du démon automount en saisissant la commande suivante dans votre terminal :
$/sbin/service/autofs status
Il est souvent utile de surcharger les valeurs par défaut d'un site pour un point de montage spécifique sur un système client. Par exemple, supposons que les maps d'automontage soient stockées dans NIS et que le fichier /etc/nsswitch.conf
indique la directive suivante :
automontage : fichiers nis
et le fichier map NIS auto.master
contient :
/home auto.home
Supposez également que la map NIS auto.home
contienne ce qui suit :
beth fileserver.example.com:/export/home/beth joe fileserver.example.com:/export/home/joe * fileserver.example.com:/export/home/&
et que le fichier map /etc/auto.home
n'existe pas.
Pour l'exemple ci-dessus, supposons que le système du client nécessite le montage de répertoires home à partir d'un serveur différent. Dans ce cas, le client devra utiliser la map suivante /etc/auto.master
.
/home /etc/auto.home2 +auto.master
Et la map /etc/auto.home2
contient l'entrée :
* labserver.example.com:/export/home/&
Étant donné que seule la première occurrence d'un point de montage est traitée, /home
contiendra le contenu de /etc/auto.home2
au lieu de la map NIS auto.home
.
Alternativement, si vous désirez seulement augmenter la map sur tout le site
auto.home
de quelques entrées, créez une map de fichiers /etc/auto.home
, et mettez-y vos nouvelles entrées. Enfin, incluez la map auto.home NIS. Alors la map de fichiers /etc/auto.home
ressemblera à ce qui suit :
mydir someserver:/export/mydir +auto.home
Selon la map NIS auto.home
ci-dessus, un ls
de /home
donnerait :
$ ls /home
beth joe mydir
Ce dernier exemple fonctionne comme prévu parce que autofs
sait qu'il ne faut pas inclure le contenu d'une map de fichiers du même nom que celle qu'il lit, c'est pourquoi il passe à la prochaine source de map dans la configuration nsswitch
.
Les bibliothèques client LDAP doivent être installées sur tous les systèmes qui doivent récupérer les maps d'automontage depuis LDAP. Avec RHEL 5, le paquetage openldap
devrait être installé automatiquement en tant que dépendance de l'automontage
. Pour configurer l'accès LDAP, modifiez /etc/openldap/ldap.conf
. Assurez-vous que BASE et URI sont configurés correctement pour votre site et de même, que le schéma est configuré dans la configuration.
Le schéma le plus récent pour stocker les maps d'automontage dans LDAP est décrit dans rfc2307bis
. Pour utiliser ce schéma il est nécessaire de le configurer dans la configuration autofs
(/etc/sysconfig/autofs
) en supprimant les caractères de commentaire de la définition du schéma. Par exemple :
DEFAULT_MAP_OBJECT_CLASS="automountMap" DEFAULT_ENTRY_OBJECT_CLASS="automount" DEFAULT_MAP_ATTRIBUTE="automountMapName" DEFAULT_ENTRY_ATTRIBUTE="automountKey" DEFAULT_VALUE_ATTRIBUTE="automountInformation"
Assurez-vous que ce soient les seules entrées de schéma décommentées dans la configuration. Veuillez noter également que automountKey
remplace l'attribut cn
dans le schéma rfc2307bis
. Un LDIF
d'une configuration échantillon est décrit ci-dessous.
# extended LDIF # # LDAPv3 # base <> with scope subtree # filter: (&(objectclass=automountMap)(automountMapName=auto.master)) # requesting: ALL # # auto.master, example.com dn: automountMapName=auto.master,dc=example,dc=com objectClass: top objectClass: automountMap automountMapName: auto.master # extended LDIF # # LDAPv3 # base <automountMapName=auto.master,dc=example,dc=com> with scope subtree # filter: (objectclass=automount) # requesting: ALL # # /home, auto.master, example.com dn: automountMapName=auto.master,dc=example,dc=com objectClass: automount cn: /home automountKey: /home automountInformation: auto.home # extended LDIF # # LDAPv3 # base <> with scope subtree # filter: (&(objectclass=automountMap)(automountMapName=auto.home)) # requesting: ALL # # auto.home, example.com dn: automountMapName=auto.home,dc=example,dc=com objectClass: automountMap automountMapName: auto.home # extended LDIF # # LDAPv3 # base <automountMapName=auto.home,dc=example,dc=com> with scope subtree # filter: (objectclass=automount) # requesting: ALL # # foo, auto.home, example.com dn: automountKey=foo,automountMapName=auto.home,dc=example,dc=com objectClass: automount automountKey: foo automountInformation: filer.example.com:/export/foo # /, auto.home, example.com dn: automountKey=/,automountMapName=auto.home,dc=example,dc=com objectClass: automount automountKey: / automountInformation: filer.example.com:/export/&
Autofs version 4 introduit la notion d'entrée multi-maps dans le fichier de configuration maître. Une entrée multi-maps se présente de la façon suivante :
<mount-point> <maptype1> <mapname1> <options1> -- <maptype2> <mapname2> <options2> -- ...
N'importe quel nombre de maps peut être combiné dans une seule map de cette manière. Cette fonctionnalité n'existe plus dans v5. Cela vient du fait que les prises en charge de la Version 5 incluent des maps qui peuvent être utilisées pour arriver au même résultat. Considérez l'exemple multi-maps suivant : /home file /etc/auto.home -- nis auto.home
Cela peut être remplacé par la configuration suivante pour v5 :
/etc/nsswitch.conf
doit lister :
automontage : fichiers nis
/etc/auto.master
devra contenir :
/home auto.home
/etc/auto.home
devra contenir :
<entries for the home directory> +auto.home
Ainsi, les entrées de /etc/auto.home
et la map NIS auto.home
sont combinées.
Dans autofs version 4, il est possible de fusionner le contenu des fichiers de configuration maîtres de chaque source, comme les fichiers nis, hesiod, et LDAP. La version 4 automontage recherche un fichier de configuration maître pour chacune des sources listées dans /etc/nsswitch.conf
. La map est lue s'il existe et son contenu est fusionné en une map unique auto.master
.
Dans la version 5, ce comportement a changé. Seul le premier fichier de configuration maître de la liste des sources dans nsswitch.conf
est consulté. S'il est nécessaire de fusionner le contenu de multiples fichiers de configuration maîtres, des maps inclues peuvent être utilisées. Considérez l'exemple suivant :
/etc/nsswitch.conf: automount: files nis
/etc/auto.master: /home /etc/auto.home +auto.master
La configuration ci-dessus sera fusionnée avec le contenu de auto.master
basé sur un fichier et auto.master
basé sur NIS. Cependant, étant donné que seules les entrées de maps incluses sont autorisées dans les maps de fichiers, il est impossible d'inclure à la fois un auto.master
NIS et un auto.master
LDAP.
Cette limitation peut être surmontée par la création de fichiers de configuration maîtres qui ont un nom différent dans la source. Dans l'exemple ci-dessus, si nous avions une map appelée auto.master.ldap
, nous serions également en mesure d'ajouter "+auto.master.ldap"
au fichier de configuration maître basé sur un fichier et du moment que "ldap
" est listé en tant que source dans notre configuration nsswitch, il serait lui aussi inclus.
Au-delà du montage de systèmes de fichiers via NFS sur un hôte distant, d'autres options peuvent être spécifiées au moment du montage pour le rendre plus facile à utiliser. Ces options peuvent être utilisées avec des commandes mount
manuelles, des paramètres /etc/fstab
et autofs
.
Ci-dessous figurent les options couramment utilisées pour les montages NFS :
fsid=num
— Force le traitement de fichiers et les paramètres des attributs de fichiers en ligne à être
, au lieu d'un nombre dérivé du nombre majeur et mineur du périphérique blocs sur le système de fichiers monté. La valeur num
0
a une signification particulière avec NFSv4. NFSv4 possède un concept de super-utilisateur de l'ensemble du système de fichiers exporté. Le point d'export exporté avec fsid=0
est utilisé comme ce root.
hard
ou soft
— Spécifie si le programme utilisant un fichier via une connexion NFS doit s'arrêter et attendre (hard
) que le serveur revienne en ligne, si l'hôte fournissant le système de fichiers exporté n'est pas disponible ou s'il doit au contraire émettre un message d'erreur (soft
).
Si l'option hard
est spécifiée, l'utilisateur ne peut pas mettre fin au processus attendant le rétablissement de la communication NFS à moins que l'option intr
ne soit également spécifiée.
Si l'option soft
est spécifiée, l'utilisateur peut ajouter une option timeo=
supplémentaire, où <value>
spécifie le nombre de secondes devant s'écouler avant que le message d'erreur ne soit émis.
<value>
Les montages soft ne sont pas recommandés car ils peuvent générer des erreurs I/O dans tous les réseaux congestionnés ou quand on utilise un serveur particulièrement chargé.
intr
— Autorise l'interruption des requêtes NFS si le serveur est en panne ou ne peut pas être contacté.
nfsvers=2
ou nfsvers=3
— Spécifie quelle version du protocole NFS utiliser. Cela est utile aux hôtes qui exécutent de multiples serveurs NFS. Si aucune version n'est spécifiée, NFS utilise la dernière version prise en charge par le noyau et la commande mount
. Cette option n'est pas prise en charge par NFSv4 et ne devrait pas être utilisée.
noacl
— Éteint tous les traitements ACL. Cela peut être nécessaire quand on utilise des versions plus anciennes de Red Hat Enterprise Linux, Red Hat Linux, ou Solaris, puisque la technologie ACL la plus récente n'est pas compatible avec des systèmes plus anciens.
nolock
— Désactive le verrouillage de fichiers. Cette option peut être nécessaire afin de pouvoir se connecter à d'anciens serveurs NFS.
noexec
— Interdit l'exécution de binaires sur les systèmes de fichiers montés. Cette option est utile si votre système est en train de monter un système de fichiers non-Linux via NFS, contenant des binaires incompatibles.
nosuid
— Désactive les bits setuid et setgid. Cette option empêche que les utilisateurs puissent obtenir des privilèges plus étendus en exécutant un programme setuid.
port=num
— Spécifie la valeur numérique du port de serveur NFS. Si
est num
0
(la valeur par défaut), alors mount
demande au mappeur de port de l'hôte distant le numéro de port à utiliser. Si le démon NFS de l'hôte distant n'est pas enregistré avec ses mappeur de ports, le numéro de port NFS standard, TCP 2049 est utilisé à sa place.
rsize=num
et wsize=num
— Ces paramètres accélèrent la communication NFS pour les opérations de lecture (rsize
) et d'écriture (wsize
) en déterminant une taille de bloc de données supérieure, exprimée en octets, devant être transférée à un moment donné. Une extrême prudence est recommandée lors de la modification de ces valeurs ; certaines cartes réseau et certains noyaux Linux relativement anciens ne fonctionnent pas très bien avec des blocs d'une taille plus grande. Pour NFSv2 ou NFSv3, la valeur par défaut pour les deux paramètres est 8192. Pour NFSv4, la valeur par défaut pour les deux paramètres est 32768.
sec=mode
— Spécifie le type de sécurité à utiliser lors de l'authentification d'une connexion NFS.
sec=sys
représente le paramétrage par défaut, qui utilise des UID et GID UNIX locaux au moyen de AUTH_SYS pour authentifier des opérations NFS.
sec=krb5
utilise Kerberos V5 au lieu des UID et GID UNIX locaux pour authentifier les utilisateurs.
sec=krb5i
utilise Kerberos V5 pour l'authentification des utilisateurs et effectue la vérification de l'intégrité des opérations NFS à l'aide des contrôles de sommes sécurisés pour éviter la falsification de données.
sec=krb5p
utilise Kerberos V5 pour l'authentification des utilisateurs, le contrôle de l'intégrité et le cryptage du trafic NFS afin d'empêcher le reniflage de paquets.Ce paramétrage est certes le plus sûr mais il a également le temps de gestion système le plus élevé au niveau de la performance.
tcp
— Indique au montage NFS d'utiliser le protocole TCP.
udp
— Indique au montage NFS d'utiliser le protocole UDP.
De nombreuses options sont énumérées dans les pages de manuel mount
et nfs
.
Pour exécuter le serveur NFS, le service portmap
doit être exécuté. Pour vérifier que portmap
est actif, saisissez la commande suivante en tant que root :
/sbin/service portmap status
Si le service portmap
est en cours d'exécution, alors le service nfs
peut être démarré. Pour démarrer un serveur NFS, de type root :
/sbin/service nfs start
nfslock
doit également être démarré pour que le client et le serveur NFS fonctionnent correctement. Pour démarrer le verrouillage NFS en tant que type root : /sbin/service nfslock start
. Si NFS est configuré pour démarrer au lancement, veuillez vous assurer que nfslock
démarre également en exécutant chkconfig --list nfslock
. Si nfslock
n'est pas configuré sur on
, cela implique qu'il faudra exécuter manuellement le /sbin/service nfslock start
à chaque fois que l'ordinateur démarre. Pour configurer nfslock
sur un démarrage automatique au lancement, saisissez la commande suivante dans un terminal : chkconfig nfslock on
.
Pour arrêter le serveur, tapez la commande suivante en étant connecté comme super-utilisateur :
/sbin/service nfs stop
L'option restart
est un raccourci pour arrêter, puis redémarrer NFS. Cette option est la manière la plus efficace pour que les changements de configuration prennent effet après la modification du fichier de configuration pour NFS.
Pour redémarrer le serveur, tapez la commande suivante en tant que super-utilisateur :
/sbin/service nfs restart
L'option condrestart
(redémarrage conditionnel) ne démarre nfs
que s'il est en cours d'exécution. Cette option est utile pour les scripts car il ne démarre pas le démon s'il n'est pas en cours d'exécution.
Pour redémarrer le serveur sous certaines conditions, tapez la commande suivante en tant que super-utilisateur :
/sbin/service nfs condrestart
Pour recharger le fichier de configuration du serveur NFS sans redémarrer le service, tapez la commande suivante en tant que super-utilisateur :
/sbin/service nfs reload
Par défaut le service nfs
ne démarre pas automatiquement au lancement. Pour configurer NFS de manière à ce qu'il démarre au lancement, utilisez un utilitaire initscript /sbin/chkconfig
, /usr/sbin/ntsysv, ou le programme Outil de configuration des services. Consultez le Chapitre 7, Contrôle d'accès aux services pour de plus amples informations sur ces outils.
Il y a trois façons de configurer un serveur NFS sous Red Hat Enterprise Linux : en utilisant l'Outil de configuration du serveur NFS (system-config-nfs
), en modifiant manuellement son fichier de configuration (/etc/exports
), ou en utilisant la commande /usr/sbin/exportfs
.
Pour utiliser l'outil de configuration du serveur NFS, le système X Window doit être en cours d'exécution, vous devez être connecté en tant que super-utilisateur (ou root) et le paquetage RPM system-config-nfs doit être installé sur votre système. Pour lancer l'application, sélectionnez le bouton Système => Administration => Paramètres du serveur => NFS. Vous pouvez également saisir la commande system-config-nfs
dans un terminal. La fenêtre de l'outil de configuration du serveur NFS, est illustrée ci-dessous.
Basé sur certains paramètres du pare-feu, il vous faudra sans doute configurer les processus de démon NFS pour utiliser des ports réseau spécifiques. Les paramétrages du serveur NFS vous permettent de spécifier les ports pour chaque processus au lieu d'utiliser les ports au hasard assignés par le mappeur de port. Vous pouvez régler les paramétrages du serveur NFS en cliquant sur le bouton Paramétrage du Serveur. La figure ci-dessous illustre la fenêtre avec les paramètres du serveur NFS.
Le partage de fichiers d'un serveur NFS est appelé export de répertoires. L'Outil de configuration du serveur NFS peut être utilisé pour configurer un système en tant que serveur NFS.
Pour ajouter un partage NFS, cliquez sur le bouton Ajouter. La boîte de dialogue reproduite dans la Figure 10.3, « Ajout d'un partage » s'affiche.
L'onglet Informations de base requiert les informations suivantes :
Répertoire — Indiquez le répertoire à partager, comme par exemple /tmp
.
Hôte(s) — Indiquez le ou les hôtes qui partageront le répertoire. Reportez-vous à la Section 10.6.3, « Formats des noms d'hôtes » pour une explication relative aux différents formats possibles.
Permissions de base — Indiquez si le répertoire doit avoir des permissions en lecture-seule ou en lecture-écriture.
L'onglet Options générales permet de configurer les options suivantes :
Autoriser les connexions depuis les ports 1024 et supérieurs — Les services lancés sur les numéros de ports inférieurs à 1024 doivent être lancés en tant que super-utilisateur (ou root). Sélectionnez cette option pour permettre au service NFS d'être lancé par un utilisateur autre que le super-utilisateur. Cette option correspond à insecure
.
Autoriser le verrouillage des fichiers non sécurisés — Une requête de verrouillage n'est pas nécessaire. Cette option correspond à insecure_locks
.
Désactiver le contrôle de la sous-arborescence — Si un sous-répertoire d'un système de fichiers est exporté, mais pas la totalité de ce système, le serveur vérifie que le fichier requis se trouve bien dans le sous-répertoire exporté. Cette vérification s'appelle vérification de la sous-arborescence. Sélectionnez cette option pour désactiver la vérification de la sous-arborescence. Si tout le système de fichiers est exporté et que cette option est sélectionnée, le taux de transfert sera plus rapide. Cette option correspond à no_subtree_check
.
Synchroniser les opérations d'écriture sur demande — Activée par défaut, cette option ne permet pas au serveur de répondre à des requêtes avant que les modifications effectuées par la requête ne soient enregistrées sur le disque. Cette option correspond à sync
. Si elle n'est pas sélectionnée, l'option async
est utilisée.
Forcer la synchronisation des opérations d'écriture — Cette option permet de ne pas retarder l'enregistrement sur disque, elle correspond à no_wdelay
.
Cacher les systèmes de fichiers en-dessous déclenche ou arrête l'option nohide
. Quand l'option nohide
est arrêtée, les répertoires intégrés sont révélés. Les clients peuvent donc naviguer à travers le système de fichiers depuis le parent sans remarquer aucun changement.
Exporter uniquement si monté configure l'option mountpoint
qui permet uniquement l'export d'un répertoire s'il a été monté.
Point de montage optionnel spécifie le chemin à un point de montage optionnel. Cliquez sur le bouton Parcourir pour naviguer vers le point de montage favori ou le type de chemin s'il est connu.
Configurer un ID de système de fichiers explicite : configure l'option fsid=X
. Cela est utilisé essentiellement dans une installation clusterisée. En utilisant un ID de système de fichiers cohérent dans tous les clusters, vous évitez les anciens traitements de fichiers.
L'onglet Accès utilisateur permet de configurer les options suivantes :
Considérer l'utilisateur root distant comme root local — Par défaut, les ID utilisateur et groupe d'utilisateurs root ont tous deux la valeur 0. L'écrasement de l'utilisateur root lie l'ID utilisateur 0 et l'ID groupe 0 aux ID utilisateur et groupe anonymes afin que le root du client n'ait pas de privilèges super-utilisateur sur le serveur NFS. Si cette option est sélectionnée, l'utilisateur root n'est pas lié à l'utilisateur anonyme et le super-utilisateur d'un client dispose de privilèges root sur les répertoires exportés. Cette option peut considérablement réduire le niveau de sécurité du système. Ne la sélectionnez que si cela s'avère absolument nécessaire. Cette option correspond à no_root_squash
.
Considérer tous les utilisateurs clients comme des utilisateurs anonymes — Si cette option est sélectionnée, tous les ID utilisateur et groupe sont liés à l'utilisateur anonyme. Cette option correspond à all_squash
.
Spécifier l'ID de l'utilisateur local pour les utilisateurs anonymes — Si l'option Considérer tous les utilisateurs clients comme des utilisateurs anonymes est sélectionnée, vous pouvez spécifier un ID utilisateur pour l'utilisateur anonyme. Cette option correspond à anonuid
.
Spécifier l'ID groupe local pour les utilisateurs anonymes — Si l'option Considérer tous les utilisateurs clients comme des utilisateurs anonymes est sélectionnée, vous pouvez spécifier un ID groupe pour l'utilisateur anonyme. Cette option correspond à anongid
.
Pour modifier un partage NFS existant, sélectionnez-le dans la liste et cliquez sur le bouton Propriétés. Pour supprimer un partage NFS existant, sélectionnez-le dans la liste et cliquez sur le bouton Supprimer.
Après avoir cliqué sur Valider pour valider l'ajout, la modification ou la suppression d'un partage NFS de la liste, les modifications prennent effet immédiatement — Le démon serveur est alors relancé et l'ancien fichier de configuration est enregistré en tant que /etc/exports.bak
. Le nouveau fichier de configuration est enregistré dans /etc/exports
.
L'Outil de configuration du serveur NFS lit et enregistre (ou écrit) directement dans le fichier de configuration /etc/exports
. Le fichier peut donc être modifié manuellement après avoir utilisé cet outil qui peut également être utilisé après avoir modifié manuellement le fichier (si toutefois celui-ci a été modifié en respectant la syntaxe).
La prochaine section aborde le sujet des modifications manuelles /etc/exports
et de l'utilisation de la commande /usr/sbin/exportfs
pour l'export des systèmes de fichiers NFS.
Si vous préférez modifier des fichiers de configuration à l'aide d'un éditeur de texte ou si le système X Window n'est pas installé, vous pouvez effectuer les modifications sur le fichier de configuration directement.
Le fichier /etc/exports
contrôle les répertoires que le serveur NFS exporte. Le format du fichier est le suivant :
directory
hostname
(options
)
Seule une des deux options suivantes doit être spécifiée : sync
ou async
(sync
est recommandée). Si l'option sync
est spécifiée, le serveur ne répond aux requêtes qu'après que les changements effectués par la requête aient été enregistrés sur le disque.
Par exemple :
/misc/export
speedy.example.com(sync)
permettrait aux utilisateurs de speedy.example.com
de monter /misc/export
avec des autorisations par défaut en lecture-seule, mais :
/misc/export
speedy.example.com(rw,sync)
permettrait aux utilisateurs de speedy.example.com
de monter /misc/export
avec des privilèges en lecture-écriture.
Reportez-vous à la Section 10.6.3, « Formats des noms d'hôtes » pour une explication relative aux différents formats possibles de noms d'hôtes.
Faites attention aux espaces dans le fichier /etc/exports
. Si le nom d'hôte et les options entre parenthèses ne sont pas séparés par un espace, les options sont appliquées uniquement au nom d'hôte. Si le nom d'hôte et les options sont séparés par un espace, les options s'appliquent au reste du monde. Examinons par exemple les lignes ci-dessous :
/misc/export speedy.example.com(rw,sync) /misc/export speedy.example.com (rw,sync)
La première sortie accorde aux utilisateurs de speedy.example.com
un accès en lecture-écriture et refuse tous les autres utilisateurs. La seconde sortie accorde aux utilisateurs de speedy.example.com
un accès en lecture seule (la valeur par défaut) et accorde à tous les autres utilisateurs un accès en lecture-écriture.
Chaque fois que vous modifiez le fichier /etc/exports
, vous devez informer le démon NFS de la modification ou recharger le fichier de configuration à l'aide de la commande suivante :
/sbin/service nfs reload
Le(s) hôte(s) peuvent avoir les formats suivants :
Ordinateur unique — Un nom de domaine pleinement qualifié (qui peut être résolu par le serveur), un nom d'hôte (qui peut être résolu par le serveur) ou une adresse IP.
Séries de machines spécifiées avec des caractères génériques — Utilisez le caractère * ou ? pour spécifier une correspondance de chaînes. Les caractères génériques ne doivent pas être utilisés avec des adresses IP ; toutefois, ils peuvent parfois fonctionner si les recherches DNS inverses échouent. Lors de la spécification de caractères génériques dans des noms de domaines pleinement qualifiés, les points (.) ne sont pas considérés comme des caractères génériques. Par exemple, *.example.com
inclut one.example.com, mais n'inclut pas one.two.example.com.
Réseaux IP — Utilisez a.b.c.d/z
, où a.b.c.d
représente le réseau et z
le nombre de bits dans le masque réseau (192.168.0.0/24, par exemple). a.b.c.d/netmask
est également acceptable ; a.b.c.d
représente le réseau et netmask
le masque réseau (192.168.100.8/255.255.255.0, par exemple).
Groupes réseau — @group-name
, où group-name
représente le nom du groupe réseau NIS.
Le fichier /etc/exports
contrôle quels systèmes de fichiers sont exportés vers des hôtes distants et spécifie les options. Les lignes vides sont ignorées, les commentaires peuvent être exprimés en commençant une ligne avec le symbole dièse (#
), et des lignes longues peuvent être enveloppées avec une barre oblique inverse (\
). Chaque système de fichiers exporté devrait être sur sa propre ligne individuelle, et toutes les listes d'hôtes autorisés placées après un système de fichiers exporté doivent être séparées par des espaces. Les options de chacun des hôtes doivent êtres placées entre parenthèses directement après l'identifiant de l'hôte, sans aucun espace entre l'hôte et la première parenthèse. Des types d'hôtes valides sont gss/krb5
gss/krb5i
et gss/krb5p
.
La ligne pour un système de fichiers exporté a la structure suivante :
<export>
<host1>
(<options>
) <hostN>
(<options>
)...
Dans cette structure, remplacez <export>
par le répertoire devant être exporté, remplacez <host1>
par l'hôte ou le réseau vers lequel l'export est partagé et remplacez <options>
par les options pour cet hôte ou ce réseau. Des hôtes supplémentaires peuvent être spécifiés dans une liste délimitée par des espaces.
Les méthodes suivantes peuvent être utilisées pour spécifier des noms d'hôtes :
hôte simple — Où un hôte particulier est spécifié avec un nom de domaine pleinement qualifié, un nom d'hôte ou une adresse IP.
caractères génériques — où un caractère *
ou ?
est utilisé pour prendre en considération un groupe de noms de domaines pleinement qualifiés correspondant à une chaîne particulière de lettres. Les caractères génériques ne devraient pas être utilisés avec les adresses IP, cependant il est possible qu'ils fonctionnent par hasard si les recherches DNS inverses échouent.
Soyez prudent quand vous utilisez des caractères génériques avec des noms de domaine pleinement qualifiés, car ils ont tendance à être plus exacts que prévu. Par exemple, l'utilisation de *.example.com
en tant que caractère générique permet à sales.example.com d'accéder à un système de fichiers exporté mais ce n'est pas le cas pour bob.sales.example.com. Pour faire correspondre les deux possibilités, à la fois *.example.com
et *.*.example.com
doivent être spécifiés.
réseaux IP — Permet la correspondance des hôtes sur la base des adresses IP à l'intérieur d'un large réseau. Par exemple, 192.168.0.0/28
permet aux 16 premières adresses IP, de 192.168.0.0 à 192.168.0.15, d'accéder au système de fichiers exporté mais non à 192.168.0.16 et supérieur.
netgroups — Permet à un nom de groupe réseau NIS, écrit comme @
, d'être utilisé. Cela amène effectivement le serveur NIS à prendre en charge le contrôle d'accès pour ce système de fichiers exporté, quand les utilisateurs peuvent être ajoutés et supprimés d'un groupe NIS sans affecter <group-name>
/etc/exports
.
Dans sa forme la plus simple, le fichier /etc/exports
ne spécifie que le répertoire exporté et les hôtes autorisés à y accéder, comme dans l'exemple suivant :
/exported/directory bob.example.com
Dans cet exemple, bob.example.com
peut monter /exported/directory/
. Étant donné qu'aucune option n'est spécifiée dans cet exemple, les options par défaut NFS suivantes prennent effet :
ro
— Les montages du système de fichiers exporté sont en lecture-seule. Les hôtes distants ne peuvent pas modifier les données partagées sur le système de fichiers. Pour autoriser les hôtes à apporter des modifications au système de fichiers, l'option rw
(lecture-écriture) doit être spécifiée.
wdelay
— Cette option entraîne un retard des opérations d'écriture sur le disque par NFS, s'il suspecte qu'une autre requête d'écriture est imminente. Ce faisant, les performances peuvent être améliorées grâce à une réduction du nombre d'accès au disque par des commandes d'écriture séparées, réduisant ainsi le temps d'écriture. L'option no_wdelay
quant à elle, désactive cette fonction mais n'est disponible que lors de l'utilisation de l'option sync
.
root_squash
— Empêche les super-utilisateurs connectés à distance d'obtenir des privilèges root et leur assigne l'ID utilisateur pour l'utilisateur nfsnobody
. Cela a pour effet de "réduire" le pouvoir du super-utilisateur distant à un utilisateur local minimum, évitant ainsi les modifications de fichiers non autorisées sur le serveur distant. Alternativement, l'option no_root_squash
désactive la réduction de pouvoir du super-utilisateur. Pour réduire tout utilisateur distant, y compris le super-utilisateur, utilisez l'option all_squash
. Pour spécifier les ID utilisateur et groupe à utiliser avec les utilisateurs distants depuis un hôte particulier, utilisez les options anonuid
et anongid
respectivement . Dans ce cas un compte utilisateur spécial peut être créé pour les utilisateurs NFS distants afin de partager et spécifier (anonuid=
, où <uid-value>
,anongid=<gid-value>
)
est le numéro de l'ID utilisateur et <uid-value>
est le numéro de l'ID groupe.
<gid-value>
Par défaut, les listes de contrôle d'accès (ACL) sont prises en charge par NFS sous Red Hat Enterprise Linux. Pour désactiver cette fonctionnalité, spécifiez l'option no_acl
quand vous exportez le système de fichiers.
Chaque valeur par défaut pour chaque système de fichiers exporté doit être surchargée explicitement. Par exemple, si l'option rw
n'est pas spécifiée, le système de fichiers exporté est alors partagé en lecture seule. La ligne échantillon suivante de /etc/exports
surcharge deux options par défaut :
/another/exported/directory 192.168.0.3(rw,sync)
Dans cet exemple 192.168.0.3
peut monter /another/exported/directory/
en lecture/écriture et tous les transferts sur le disque sont sauvegardés sur le disque avant que la requête d'écriture du client ne soit complétée.
Par ailleurs, d'autres options sont disponibles quand la valeur par défaut n'est pas spécifiée. Celles-ci incluent la capacité de désactiver la vérification de sous-arborescence, de permettre l'accès à partir de ports non sûrs, et de permettre le verrou de fichiers non sécurisés (nécessaires pour d'anciennes implémentations client NFS. Référez-vous à la page de manuel exports
pour de plus amples informations sur ces options moins utilisées.
Le format du fichier /etc/exports
est très précis, particulièrement en ce qui concerne l'utilisation du caractère espace. Assurez-vous de toujours séparer les systèmes de fichiers exportés des hôtes, et les hôtes les uns des autres par un caractère espace. Cependant, il ne devrait y avoir aucun autre espace dans le fichier, excepté dans les lignes de commentaires.
Par exemple, les deux lignes suivantes n'ont pas la même signification :
/home bob.example.com(rw) /home bob.example.com (rw)
La première ligne accorde aux utilisateurs de bob.example.com
un accès en lecture-écriture au répertoire /home
. La seconde ligne accorde aux utilisateurs de bob.example.com
de monter le répertoire seulement en lecture (la valeur par défaut), et accorde à tous les autres utilisateurs un accès en lecture-écriture.
Tous les systèmes de fichiers exportés aux utilisateurs distants via NFS, de même que le niveau d'accès pour tous ces systèmes de fichiers, sont listés dans le fichier /etc/exports
. Quand le service nfs
démarre, la commande /usr/sbin/exportfs
lance et lit ce fichier, passe le contrôle à rpc.mountd
(si NFSv2 ou NFSv3) pour le processus de montage effectif, puis à rpc.nfsd
et les systèmes de fichiers sont alors disponibles aux utilisateurs distants.
Quand elle est saisie manuellement, la commande /usr/sbin/exportfs
permet à l'utilisateur root d'exporter ou désexporter des fichiers sans redémarrer le service NFS. Quand les options appropriées lui sont disponibles, la commande /usr/sbin/exportfs
écrit les systèmes de fichiers exportés vers /var/lib/nfs/xtab
. Étant donné que rpc.mountd
se réfère au fichier xtab
quand il décide des privilèges d'accès à un système de fichiers, les changements sur la liste de systèmes de fichiers exportés prennent effet immédiatement.
Ce qui suit est une liste d'options utilisées fréquemment et disponibles pour /usr/sbin/exportfs
:
-r
— Entraîne l'export de tous les répertoires listés dans /etc/exports
par la construction d'une nouvelle liste d'exports dans /etc/lib/nfs/xtab
. Cette option a pour effet de réactualiser la liste d'exports avec toutes les modifications effectuées sur /etc/exports
.
-a
— Entraîne l'export de tous les répertoires ou le désexport, d'après les autres options passées à /usr/sbin/exportfs
. Si aucune autre option n'est spécifiée, /usr/sbin/exportfs
exporte tous les systèmes de fichiers spécifiés dans /etc/exports
.
-o
— Spécifie les répertoires à exporter qui ne sont pas listés dans file-systems
/etc/exports
. Remplacez file-systems
par des systèmes de fichiers à exporter. Ces systèmes de fichiers doivent être formattés comme spécifié dans /etc/exports
. Consultez la Section 10.7, « Le fichier de configuration /etc/exports
» pour plus d'informations sur la syntaxe /etc/exports
. Cette option est souvent utilisée pour tester un système de fichiers exporté avant de l'ajouter de façon définitive à la liste des systèmes de fichiers à exporter.
-i
— Ignore /etc/exports
; seules les options fournies par la ligne de commande sont utilisées pour définir les systèmes de fichiers exportés.
-u
— Désexporte tous les répertoires partagés. La commande /usr/sbin/exportfs -ua
suspend le partage de fichiers NFS tout en gardant tous les démons NFS actifs. Pour réactiver le partage NFS, saisissez exportfs -r
.
-v
— Des opérations verbeuses, où les systèmes de fichiers exportés ou désexportés sont affichés de façon plus détaillée quand la commande exportfs
est exécutée.
Si aucune option n'est passée à la commande /usr/sbin/exportfs
, une liste de systèmes de fichiers actuellement exportés est affichée.
Pour plus d'informations sur la commande /usr/sbin/exportfs
, consultez la page de manuel exportfs
.
La commande exportfs
est utilisée pour maintenir la table NFS de systèmes de fichiers exportés. Quand elle est saisie dans un terminal sans arguments, la commande exportfs
affiche tous les répertoires exportés.
Étant donné que NFSv4 n'utilise plus le protocole rpc.mountd
utilisé dans NFSv2 et NFSv3, le montage des systèmes de fichiers a changé.
Un client NFSv4 a maintenant la possibilité de voir tous les exports effectués par le serveur NFSv4 en tant que système de fichiers unique appelé pseudo-système de fichiers NFSv4. Avec Red Hat Enterprise Linux, le pseudo-système de fichiers est identifié en tant que système de fichiers réel et unique, identifié à l'export avec l'option fsid=0
.
Par exemple, les commandes suivantes pourraient être exécutées sur un serveur NFSv4 :
mkdir /exports mkdir /exports/opt mkdir /exports/etc mount --bind /usr/local/opt /exports/opt mount --bind /usr/local/etc /exports/etc exportfs -o fsid=0,insecure,no_subtree_check gss/krb5p:/exports exportfs -o rw,nohide,insecure,no_subtree_check gss/krb5p:/exports/opt exportfs -o rw,nohide,insecure,no_subtree_check gss/krb5p:/exports/etc
Dans cet exemple, les clients obtiennent de multiples systèmes de fichiers à monter, en utilisant l'option --bind
qui crée des liens inaltérables.
À cause de la fonctionnalité des pseudo-systèmes de fichiers, les version NFS 2, 3 et 4 exportent des configurations qui ne sont pas toujours compatibles. Par exemple, selon l'arborescence de répertoires suivante :
/home /home/sam /home/john /home/joe
et l'export :
/home *(rw,fsid=0,sync)
Si vous utilisez les versions NFS 2, 3 et 4 ce qui suit fonctionnerait :
mount server:/home /mnt/home ls /mnt/home/joe
Si vous utilisez v4 ce qui suit fonctionnerait :
mount -t nfs4 server:/ /mnt/home ls /mnt/home/joe
La différence étant "server:/home
" et "server:/
". Pour mettre en place les configurations des exports compatibles pour toutes les versions, on doit exporter (en lecture seule) le système de fichiers root avec un fsid=0
. Les signaux fsid=0
indiquent au serveur NFS que cet export est le root.
/ *(ro,fsid=0) /home *(rw,sync,nohide)
Avec ces exports, "mount server:/home /mnt/home
" et "mount -t nfs server:/home /mnt/home
" fonctionneront comme prévu.
NFS est tout à fait approprié pour le partage de systèmes de fichiers entiers avec un grand nombre d'hôtes connus et d'une manière transparente. Toutefois, étant donné la facilité d'utilisation, divers problèmes potentiels de sécurité peuvent surgir.
Il est important de prendre en considération les points suivants lorsque des systèmes de fichiers NFS sont exportés sur un serveur ou lorsqu'ils sont montés sur un client. Ce faisant, les risques de sécurité NFS seront minimisés et les données stockées sur le serveur seront mieux protégées.
La version de NFS que vous devriez implémenter dépend de votre réseau actuel et de vos craintes en matière de sécurité. Les sections suivantes expliquent les différences qui existent entre l'implémentation de mesures de sécurité avec NFSv2, NFSv3 et NFSv4. Il est recommandé autant que possible, d'utiliser NFSv4 plutôt que d'autres versions de NFS.
NFS contrôle qui peut monter un système de fichiers exporté en se basant sur l'hôte qui effectue la requête de montage et non pas sur l'utilisateur qui exploitera effectivement le système de fichiers. Les hôtes doivent se voir accorder des droits explicites pour pouvoir monter le système de fichiers exporté. Les utilisateurs ne peuvent contrôler l'accès que par l'intermédiaire des permissions accordées aux fichiers et répertoires. En d'autres termes, une fois qu'un système de fichiers est exporté via NFS, tout hôte distant connecté au serveur NFS peut avoir accès aux données partagées. Afin de limiter les risques potentiels, les administrateurs système peuvent restreindre l'accès à une lecture-seule ou peuvent réduire les permissions des utilisateurs à un ID utilisateur et groupe commun. Ceci étant, de telles solutions peuvent empêcher l'utilisation du partage NFS selon l'intention d'origine.
De plus, si un agresseur prend le contrôle du serveur DNS utilisé par le système effectuant l'export du système de fichiers NFS, le système associé avec un nom d'hôte particulier ou un nom de domaine pleinement qualifié peut être renvoyé vers une machine non autorisée. À ce stade, l'ordinateur non-autorisé devient le système ayant l'autorisation de monter le partage NFS, puisqu'aucun nom d'utilisateur ou mot de passe n'est échangé pour fournir une sécurité supplémentaire au montage NFS.
Les caractères génériques doivent être utilisés avec parcimonie lors de l'export de répertoires via NFS car il est possible que le champ d'action de ces caractères génériques englobe un plus grand nombre de systèmes que prévu.
Il est également possible de restreindre l'accès au service portmap
via les enveloppeurs TCP. L'accès aux ports, utilisé par portmap
, rpc.mountd
, et rpc.nfsd
peut aussi être limité en créant des règles de pare-feu avec les iptables
.
Pour plus d'informations afin de sécuriser NFS et sur portmap
, consultez la Section 34.1, « IPTables ».
La publication de NFSv4 a entraîné une révolution en matière d'authentification et de sécurité pour les exports NFS. NFSv4 rend obligatoire l'implémentation du module noyau RPCSEC_GSS, le mécanisme GSS-API de la version 5 de Kerberos, SPKM-3 et LIPKEY. Avec NFSv4, les mécanismes de sécurité obligatoires sont orientés vers l'authentification individuelle des utilisateurs et non pas vers celle des machines clientes comme c'était le cas sous NFSv2 et NFSv3.
Nous supposons qu'un serveur de tickets Kerberos (KDC de l'anglais Kerberos ticket-granting server) est installé et configuré correctement avant la configuration d'un serveur NFSv4. Kerberos est un système d'authentification réseau qui permet aux clients et aux serveurs de s'authentifier les uns les autres à travers l'utilisation de cryptage symétrique et d'une tierce partie de confiance, le KDC.
NFSv4 inclut la prise en charge ACL basée sur le modèle Microsoft Windows NT, et non pas sur le modèle POSIX, en raison de ses fonctionnalités et parce qu'il est d'un déploiement plus répandu. NFSv2 et NFSv3 n'ont pas de prise en charge pour les attributs natifs ACL.
La suppression du démon rpc.mountd
est une autre fonctionnalité de sécurité importante de NFSv4. Le démon rpc.mountd
était à l'origine de brèches de sécurité potentielles en raison de la manière selon laquelle il traitait les gestionnaires de fichiers.
Pour plus d'informations sur le framework RPCSEC_GSS, y compris comment rpc.svcgssd
et rpc.gssd
inter-opèrent, consultez http://www.citi.umich.edu/projects/nfsv4/gssd/.
Une fois le système de fichiers NFS monté en lecture-écriture par un hôte distant, la seule protection de chaque fichier partagé sont ses permissions. Si deux utilisateurs partageant la même valeur ID utilisateur montent le même système de fichiers NFS, ils peuvent modifier leurs fichiers réciproquement. De plus, toute personne connectée en tant que super-utilisateur sur le système du client peut utiliser la commande su -
pour devenir un utilisateur en mesure d'accéder à des fichiers particuliers via le partage NFS.
Par défaut, les listes de contrôle d'accès (ACL) sont prises en charge par NFS avec Red Hat Enterprise Linux. Il n'est pas recommandé de désactiver cette fonctionnalité.
Le comportement par défaut lors de l'export d'un système de fichiers via NFS consiste à utiliser la fonction de réduction du super-utilisateur (ou root squashing). Cette dernière permet de définir l'ID utilisateur d'une personne quelconque accédant au partage NFS en tant que super-utilisateur sur son ordinateur local, une valeur du compte personne (nfsnobody
) du serveur. Il est vivement conseillé de ne jamais désactiver cette fonction.
Si vous exportez un partage NFS en lecture-seule, songez à utiliser l'option all_squash
qui donne à tout utilisateur accédant au système de fichiers exporté, l'ID d'utilisateur de nfsnobody
(personne).
La section suivante est applicable uniquement aux implémentations NFSv2 ou NFSv3 qui requièrent le service portmap
pour la compatibilité inversée.
Le portmapper
mappe les services RPC aux ports qu'il écoute. Les processus RPC informent portmap
quand ils démarrent, enregistrant les ports qu'ils écoutent et les numéros de programmes RPC qu'ils s'attendent à desservir. Le système client contacte alors portmap
sur le serveur avec un numéro de programme RPC particulier. Le service portmap
redirige le client vers le numéro de port correct pour qu'il puisse communiquer avec le service demandé.
Étant donné que les services basés sur RPC dépendent de portmap
pour toutes les connexions avec les requêtes client entrantes, portmap
doit être disponible avant qu'un de ces services ne démarre.
Le service portmap
utilise les enveloppeurs TCP pour le contrôle d'accès, et les règles de contrôle d'accès pour portmap
affectent tous les services basés sur RPC. Alternativement il est possible de spécifier les règles de contrôle d'accès pour chacun des démons RPC NFS. La page de manuel pour rpc.mountd
et rpc.statd
contient des informations sur la syntaxe précise relative à ces règles.
Étant donné que portmap
fournit la coordination entre les services RPC et les numéros de port utilisés pour communiquer avec eux, il est utile de voir le statut des services RPC actuels en utilisant portmap
dans la résolution de problèmes. La commande rpcinfo
affiche chaque service basé sur RPC avec les numéros de port, un numéro de programme RPC, un numéro de version, et un type de protocole IP (TCP ou UDP).
Pour vous assurer que les services NFS basés sur RPC sont activés pour portmap
, saisissez la commande suivante en tant que root :
rpcinfo -p
Ci-dessous figure un exemple de sortie de cette commande :
program vers proto port 100000 2 tcp 111 portmapper 100000 2 udp 111 portmapper 100021 1 udp 32774 nlockmgr 100021 3 udp 32774 nlockmgr 100021 4 udp 32774 nlockmgr 100021 1 tcp 34437 nlockmgr 100021 3 tcp 34437 nlockmgr 100021 4 tcp 34437 nlockmgr 100011 1 udp 819 rquotad 100011 2 udp 819 rquotad 100011 1 tcp 822 rquotad 100011 2 tcp 822 rquotad 100003 2 udp 2049 nfs 100003 3 udp 2049 nfs 100003 2 tcp 2049 nfs 100003 3 tcp 2049 nfs 100005 1 udp 836 mountd 100005 1 tcp 839 mountd 100005 2 udp 836 mountd 100005 2 tcp 839 mountd 100005 3 udp 836 mountd 100005 3 tcp 839 mountd
Si l'un des services NFS ne démarre pas correctement, portmap
est incapable de mapper les requêtes RPC des clients pour ce service au port correct. Dans bien des cas, si NFS n'est pas présent dans la sortie rpcinfo
, le redémarrage de NFS fait que le service s'enregistre correctement avec portmap
et commence ses opérations. Pour des instructions sur le démarrage NFS, consultez la Section 10.5, « Lancement et arrêt de NFS ».
D'autres options utiles sont disponibles pour la commande rpcinfo
. Consultez la page de manuel rpcinfo
pour plus d'informations.
Le protocole de transport par défaut pour NFS est TCP ; toutefois, le noyau 5 de Red Hat Enterprise Linux inclut la prise en charge de NFS sur UDP. Pour utiliser NFS sur UDP, ajoutez l'option -o udp
à mount
lorsque vous montez le système de fichiers exporté par NFS sur le système client.
Il y a trois façons de configurer un export de système de fichiers NFS. À la demande via la ligne de commande (côté client), automatiquement via le fichier /etc/fstab
(côté client), et automatiquement via les fichiers de configuration autofs, comme /etc/auto.master
et /etc/auto.misc
(côté serveur avec NIS).
Par exemple, à la demande via la ligne de commande (côté client) :
mount -o udp shadowman.example.com:/misc/export /misc/local
Quand le montage NFS est spécifié dans /etc/fstab
(côté client) :
server:/usr/local/pub /pub nfs rsize=8192,wsize=8192,timeo=14,intr,udp
Quand le montage NFS est spécifié dans un fichier de configuration autofs pour un serveur NIS ce qui suit est disponible aux postes de travail NIS activés :
myproject -rw,soft,intr,rsize=8192,wsize=8192,udp penguin.example.net:/proj52
Vu que la valeur par défaut est TCP, si l'option -o udp
n'est pas spécifiée, le système de fichiers exporté par NFS est accessible via TCP.
Parmi les avantages de l'utilisation de TCP figurent :
La durabilité de connexion améliorée, réduisant l'apparition de messages NFS stale file handles
.
Le gain de performances sur les réseaux lourdement chargés car TCP reconnaît chaque paquet, contrairement à UDP qui ne reconnaît que la finalisation.
TCP possède un meilleur contrôle de congestion que UDP. Sur un réseau très encombré, les paquets UDP sont les premiers types de paquets qui sont laissés de côté. Cela signifie que si NFS écrit des données (en blocs de 8 Ko), la totalité de ces 8 Ko doit être retransmise sur UDP. Avec TCP, grâce à sa fiabilité, seules des parties de ces données de 8Ko sont transmises à la fois.
Détection d'erreurs. Lorsqu'une connexion TCP stoppe (dû à la défaillance du serveur), le client arrête d'envoyer des données et lance le processus de reconnexion. Avec UDP, puisqu'il est sans connexion, le client continue à charger le réseau de données jusqu'à ce que le serveur rétablisse la connexion.
Le principal inconvénient est que la performance reste faible dû au temps système associé au protocole TCP.
L'administration d'un serveur NFS peut se transformer en un véritable défi. Maintes options, y compris un certain nombre qui ne sont pas mentionnées dans ce chapitre, sont disponibles pour l'export ou le montage de partages NFS. Pour obtenir de plus amples informations, consultez les sources d'information mentionnées ci-dessous.
/usr/share/doc/nfs-utils-
— Remplacez <version-number>
/<version-number>
par le numéro de la version du paquetage NFS installé. Ce répertoire contient un vaste choix d'informations sur les implémentations NFS avec Linux, y compris l'analyse de différentes configurations NFS et leur impact sur les performances de transfert de fichiers.
man mount
— Contient un examen complet des options de montage pour les configurations du serveur et du client NFS.
man fstab
— Fournit les détails du format du fichier /etc/fstab
utilisé pour monter des systèmes de fichiers au lancement.
man nfs
— Fournit les détails sur les options spécifiques à NFS, d'export de système de fichiers et de montage.
man exports
— Affiche les options communes utilisées dans le fichier /etc/exports
lors de l'export des systèmes de fichiers NFS.
http://nfs.sourceforge.net/ — La page d'accueil du projet NFS Linux est un bon endroit pour les mises à jour du statut du projet.
http://www.citi.umich.edu/projects/nfsv4/linux/ — Une ressource pour NFSv4 avec le noyau Linux 2.6.
http://www.nfsv4.org — La page d'accueil du projet NFS version 4 et tous les standards associés.
http://www.vanemery.com/Linux/NFSv4/NFSv4-no-rpcsec.html — Cette page décrit en détail NFSv4 utilisé avec Fedora Core 2 et le noyau 2.6 qu'il contient.
http://www.nluug.nl/events/sane2000/papers/pawlowski.pdf — Un excellent document technique sur les fonctionnalités et améliorations du protocole NFS Version 4.
http://wiki.autofs.net — Le wiki Autofs, les discussions, la documentation et les améliorations.
Managing NFS and NIS de Hal Stern, Mike Eisler, et Ricardo Labiaga; O'Reilly & Associates — Un excellent guide de référence pour les nombreux exports NFS différents et les options de montage disponibles.
NFS Illustrated de Brent Callaghan ; Addison-Wesley Publishing Company — Ce livre fournit des comparaisons de NFS avec d'autres systèmes de fichiers réseau et montre, en détail, comment se déroule une communication NFS.
smb.conf
Samba est une implémentation Open Source du protocole Server Message Block (SMB). Elle permet l'interaction sur un réseau de Microsoft Windows®, Linux, UNIX et d'autres systèmes d'exploitation, autorisant ainsi l'accès à des fichiers basés sur Windows et à des partages d'imprimantes. L'utilisation de SMB par Samba lui permet d'apparaître comme un serveur Windows aux clients Windows.
La troisième version principale de Samba, la version 3.0.0, a incorporé de nombreuses améliorations par rapport aux versions précédentes, y compris :
La possibilité de faire partie d'un domaine Active Directory au moyen de LDAP et Kerberos
La prise en charge intégrée de Unicode pour l'internationalisation
La prise en charge de connexions client Microsoft Windows XP Professional aux serveurs Samba sans devoir toucher à la base de registre locale
L'ajout de deux nouveaux documents développés par l'équipe de Samba.org, qui inclut un manuel de référence de plus de 400 pages et un manuel d'implémentation et d'intégration de plus de 300 pages. Pour obtenir de plus amples informations sur ces titres publiés, reportez-vous à la Section 11.12.2, « Livres sur le sujet ».
Samba est une application serveur performante et versatile. Même les administrateurs système expérimentés doivent connaître les capacités et limitations de Samba avant de tenter d'effectuer son installation et sa configuration.
Ce que Samba peut accomplir :
Mettre des arborescences de répertoires et des imprimantes à la disposition de clients Linux, UNIX et Windows
Aider lors de la navigation sur le réseau (avec ou sans NetBIOS)
Authentifier les connexions de domaines Windows
Fournir la résolution de serveur de noms Windows Internet Name Service (WINS)
Agir en tant que contrôleur principal de domaine (ou PDC, de l'anglais Primary Domain Controller) de type Windows NT®.
Agir en tant que Contrôleur de Domaine Secondaire (ou BDC, de l'anglais Backup Domain Controller) pour un contrôleur principal (PDC) basé sur Samba
Agir comme un serveur membre du domaine Active Directory
Joindre un PDC Windows NT/2000/2003
Ce que Samba ne peut pas effectuer :
Agir comme un BDC pour un PDC Windows (et vice versa)
Agir comme le contrôleur d'un domaine Active Directory
La section suivante offre une brève présentation des démons et services individuels de Samba.
Samba est composé de trois démons (smbd
, nmbd
, et winbindd
). Deux services (smb
et windbind
) contrôlent la manière selon laquelle les démons sont démarrés et arrêtés, ainsi que d'autres fonctionnalités en relation avec les services. Chaque démon est traité en détail, de même que le service spécifique qui le contrôle.
smbd
Le démon serveur smbd
fournit des services de partage de fichiers et d'impression aux clients Windows. En outre, il est responsable de l'authentification des utilisateurs, du verrouillage des ressources et du partage des données par le biais du protocole SMB. Les ports par défaut sur lesquels le serveur est à l'écoute de tout trafic SMB sont les ports TCP 139 et 445.
Le démon smbd
est contrôlé par le service smb
.
nmbd
Le démon serveur nmbd
comprend et répond à toutes les requêtes de service de nom NetBIOS telles que celles produites par SMB/CIFS dans des systèmes basés sur Windows. Ces derniers incluent les clients Windows 95/98/ME, Windows NT, Windows 2000, Windows XP et LanManager. Ce démon joue également un rôle au niveau des protocoles de navigation qui constituent l'affichage du Voisinage réseau (Network Neighborhood) de Windows. Le port par défaut sur lequel le serveur attend du trafic NMB est le port UDP 137.
Le démon nmbd
est contrôlé par le service smb
.
winbindd
Le service winbind
effectue la résolution entre les informations relatives aux utilisateurs et aux groupes sur un serveur Windows NT 2000 ou un serveur Windows 2003. Cela les rend utilisables par des plates-formes UNIX. Cette opération est possible grâce à l'utilisation d'appels RPC de Microsoft, du système PAM (Pluggable AuthenticationModule, ou module d'authentification enfichable) et du NSS (Name Service Switch). Ceci permet aux utilisateurs de domaines Windows NT d'apparaître comme des utilisateurs UNIX sur une machine UNIX. Bien qu'intégré à la distribution Samba, le service winbind
est contrôlé séparément du service smb
.
Le démon winbindd
est contrôlé par le service winbind
et il n'est pas nécessaire que le service smb
soit lancé pour que le démon tourne. Windbind est également utilisé quand Samba est un membre d'Active Directory, et peut aussi fonctionner sur un contrôleur de domaine Samba (pour implémenter les groupes imbriqués et/ou la confiance interdomaines). Étant donné que winbind
est un service côté client, utilisé pour la connexion aux serveurs basés sur Windows NT, une discussion plus approfondie de winbind
dépasse l'objectif de ce manuel.
Pour une liste d'utilitaires inclus dans la distribution Samba, veuillez consulter la Section 11.11, « Programmes de la distribution Samba ».
Vous pouvez utiliser Nautilus pour visionner les partages Samba disponibles sur votre réseau. Sélectionnez Places (sur le panneau) => Serveurs réseau pour visionner une liste de groupes de travail Samba sur votre réseau. Vous pouvez aussi saisir smb:
dans la barre Fichier => Ouvrir l'emplacement de Nautilus pour visionner les groupes de travail.
Comme indiqué dans la Figure 11.1, « Groupes de travail SMB dans Nautilus », une icône apparaît pour chaque groupe de travail SMB disponible sur le réseau.
Double-cliquez sur une des icônes du groupe de travail pour visionner une liste d'ordinateurs à l'intérieur du groupe de travail.
Comme vous pouvez le constater dans la Figure 11.2, « Machines SMB dans Nautilus », il existe une icône pour chaque machine à l'intérieur du groupe de travail. Double-cliquez sur une icône pour visionner les partages Samba sur la machine. Si un nom d'utilisateur et une combinaision de mot de passe sont requis, ils vous seront demandés.
Alternativement, vous pouvez également spécifier le serveur Samba et le nom de partage dans la barre Emplacement : pour Nautilus en utilisant la syntaxe suivante (remplacez <servername>
et <sharename>
par les valeurs appropriées) :
smb://<servername>
/<sharename>
Pour interroger le système sur les serveurs, utilisez la commande findsmb
. Pour chaque serveur trouvé, elle affiche son adresse IP, le nom NetBIOS, le nom du groupe de travail, le système d'exploitation et la version du serveur SMB.
Pour vous connecter à un partage Samba à partir de l'invite du shell, saisissez la commande suivante :
smbclient //<hostname>
/<sharename>
-U <username>
Remplacez <hostname>
avec le nom d'hôte ou l'adresse IP du serveur Samba auquel vous désirez vous connecter, <sharename>
avec le nom du fichier partagé que vous désirez parcourir, et <username>
avec le nom d'utilisateur Samba pour le système. Entrez le mot de passe correct ou appuyez sur Entrée si aucun mot de passe n'est requis pour l'utilisateur.
Si vous apercevez l'invite smb:\>
, vous avez réussi votre connexion. Une fois connecté, saisissez help
pour une liste des commandes. Si vous désirez parcourir le contenu de votre répertoire home, remplacez sharename
par votre nom d'utilisateur. Si le commutateur -U
n'est pas utilisé, le nom d'utilisateur de l'utilisateur courant est passé au serveur Samba.
Pour sortir de smbclient
, saisissez sortie
à l'invite de smb:\>
.
Quelquefois il est utile de monter un partage Samba dans un répertoire de façon à ce que les fichiers dans le répertoire puissent être traités comme s'ils faisaient partie du système de fichiers local.
Pour monter un partage Samba dans un répertoire, créez un répertoire (s'il n'existe pas déjà) dans lequel vous le monterez, et exécutez la commande suivante en tant que root :
mount -t cifs -o <username>
,<password>
//<servername>
/<sharename>
/mnt/point/
Cette commande monte <sharename>
à partir du <servername>
dans le répertoire local /mnt/point/
. Pour plus d'informations sur le montage d'un partage Samba, consultez man mount.cifs
.
Le fichier de configuration par défaut (/etc/samba/smb.conf
) permet aux utilisateurs de visionner leur répertoire home comme un partage Samba. Il partage également toutes les imprimantes configurées sur le système comme des imprimantes partagées Samba. En d'autres termes, vous pouvez attacher une imprimante au système et imprimer avec celle-ci à partir des machines Windows sur votre réseau.
Pour configurer Samba au moyen d'une interface graphique, utilisez l'Outil de configuration du serveur Samba. Pour une configuration en lignes de commande, passez à la Section 11.4.2, « Configuration en lignes de commande ».
L'Outil de configuration du serveur Samba est une interface graphique permettant de gérer les partages Samba, les utilisateurs et les paramètres de base du serveur. Elle modifie les fichiers de configuration dans le répertoire /etc/samba/
. Tout changement dans ces fichiers effectués sans utiliser l'application, sont sauvegardés.
Pour utiliser cette application, vous devez exécuter X Window System, avoir des privilèges super-utilisateur, et avoir installé le paquetage RPM system-config-samba
. Pour démarrer l'Outil de configuration du serveur Samba à partir du bureau, cliquez sur Système (sur le panneau) => Administration => Paramètres du serveur => Samba ou saisissez la commande system-config-samba
à l'invite du shell (par exemple, dans un terminal XTerm ou GNOME).
L'Outil de configuration du serveur Samba n'affiche pas les imprimantes partagées ou les stanza par défaut qui permettent aux utilisateurs de visionner leur propre répertoire home sur le serveur Samba.
La première étape pour configurer un serveur Samba est de configurer les paramètres de base pour le serveur et quelques options de sécurité. Après le démarrage de l'application, sélectionnez Préférences => Paramètres du serveur à partir du menu déroulant. L'onglet Basique est affiché comme indiqué dans la Figure 11.4, « Configuration de base des paramètres du serveur ».
Configuration de base des paramètres du serveur
Sur l'onglet Basique, spécifiez dans quel groupe de travail l'ordinateur devrait se trouver, de même donnez une brève description de l'ordinateur. Ces éléments correspondent aux options workgroup
et server string
dans smb.conf
.
Configuration des paramètres sécurité du serveur
L'onglet Sécurité contient les options suivantes :
Mode d'authentification — Cela correspond à l'option security
. Sélectionnez un des types d'authentification suivants.
ADS — Le serveur Samba agit comme un membre de domaine dans un environnement Active Directory Domain (ADS). Pour cette option, Kerberos doit être installé et configuré sur le serveur, et Samba doit devenir un membre de la zone ADS au moyen de l'utilitaire net
, qui fait partie du paquetage samba-client
. Consultez la page de manuel net
pour de plus amples informations. Cette option ne configure pas Samba pour devenir un contrôleur ADS. Spécifiez la zone du serveur Kerberos dans le champ Zone Kerberos.
Le champ Zone Kerberos doit être fourni en lettres capitales, comme dans EXAMPLE.COM
.
Utiliser un serveur Samba en tant que membre de domaine dans une zone ADS, suppose une configuration de Kerberos correcte, y compris le fichier /etc/krb5.conf
.
Domaine — Le serveur Samba dépend d'un contrôleur de domaine Windows NT principal ou secondaire pour vérifier l'utilisateur. Le serveur passe le nom d'utilisateur et le mot de passe au contrôleur et attend son retour. Spécifiez le nom NetBIOS du contrôleur de domaine principal ou secondaire dans le champ Authentification du serveur.
L'option Mots de passe cryptés doit être configurée à Oui si cela est sélectionné.
Serveur — Le serveur Samba essaie de vérifier la combinaison nom d'utilisateur et mot de passe en les passant à un autre serveur. S'il n'est pas en mesure de le faire, le serveur essaie la vérification au moyen du mode d'authentification utilisateur. Spécifiez le nom NetBIOS de l'autre serveur Samba dans le champ Authenfication du serveur.
Partage — Les utilisateurs de Samba n'ont pas à entrer une combinaison nom d'utilisateur et mot de passe par le biais du serveur Samba. On ne leur demande pas de nom d'utilisateur ou de mot de passe jusqu'à ce qu'ils essaient de se connecter à un répertoire partagé spécifique depuis un serveur Samba.
Utilisateur — (par défaut) Les utilisateurs Samba doivent fournir un nom d'utilisateur et mot de passe par serveur Samba. Sélectionnez cette option si vous désirez que l'option Nom d'utilisateur Windows soit appliquée. Consultez la Section 11.4.1.2, « Gestion des utilisateurs Samba » pour plus d'informations.
Mots de passe cryptés — Cette option doit être activée si les clients sont connectés à partir d'un système avec Windows 98, Windows NT 4.0 avec le Service Pack 3, ou d'autres versions plus récentes de Microsoft Windows. Les mots de passe sont transférés entre le serveur et le client dans un format crypté plutôt qu'en texte clair qui pourrait être intercepté. Ceci correspond à l'option encrypted passwords
. Consultez la Section 11.4.3, « Mots de passe cryptés » pour plus d'informations sur les mots de passe cryptés Samba.
Compte invité — Quand les utilisateurs ou les invités se connectent sur un serveur Samba, ils doivent être liés à un utilisateur valide sur le serveur. Sélectionnez un des noms d'utilisateur existant sur le système comme compte invité Samba. Quand les invités se connectent au serveur Samba, ils ont le même privilège que cet utilisateur. Cela correspond à l'option Compte invité
.
Après avoir cliqué sur Valider, les changements sont enregistrés dans le fichier de configuration et le démon est redémarré ; ainsi les modifications prennent effet immédiatement.
L'Outil de configuration du serveur Samba requiert qu'un compte utilisateur existant soit actif sur le système agissant en tant que serveur Samba avant qu'un utilisateur puisse être ajouté. L'utilisateur Samba est associé au compte utilisateur existant.
Pour ajouter un utilisateur Samba, sélectionnez Préférences => Utilisateurs Samba depuis le menu déroulant, et cliquez sur le bouton Ajouter un utilisateur. Dans la fenêtre Créer un nouvel utilisateur Samba sélectionnez un Utilisateur Unix à partir de la liste des utilisateurs existants sur le système local.
Si l'utilisateur a un nom d'utilisateur différent sur une machine Windows et doit se connecter au serveur Samba à partir d'une machine Windows, spécifiez ce nom d'utilisateur Windows dans le champ Nom d'utilisateur Windows. Le Mode d'authentification sur l'onglet Sécurité des préférences Paramètres du serveur doit être configuré sur Utilisateur pour que cette option fonctionne.
Configurez également un Mot de passe Samba pour l'utilisateur Samba et confirmez en le resaisissant. Même si vous décidez d'utiliser les mots de passe cryptés pour Samba, il est recommandé pour tous les utilisateurs que les mots de passe Samba soient différents de leurs mots de passe système.
Pour modifier un utilisateur existant, sélectionnez l'utilisateur à partir de la liste et cliquez sur Modifier l'utilisateur. Pour supprimer un utilisateur Samba existant, sélectionnez l'utilisateur, et cliquez sur le bouton Supprimer l'utilisateur. La suppression d'un utilisateur Samba ne supprime pas le compte utilisateur système associé.
Les utilisateurs sont modifiés immédiatement après avoir cliqué sur le bouton Valider.
Pour créer un partage Samba, cliquez le bouton Ajouter depuis la fenêtre de configuration principale de Samba.
L'onglet Basique permet de configurer les options suivantes :
Répertoire — Le répertoire à partager via Samba. Le répertoire doit exister avant que vous puissiez l'ouvrir.
Nom de partage — Le nom actuel du partage qui est perçu par les machines distantes. Par défaut, il s'agit de la même valeur que pour Répertoire, mais vous pouvez la configurer.
Descriptions — Une brève description du partage.
Inscriptible — Permet aux utilisateurs de lire et d'écrire dans le répertoire partagé.
Visible — Accorde des droits de lecture-seule aux utilisateurs du répertoire partagé.
L'onglet Accès vous permet d'autoriser l'accès au partage à des utilisateurs spécifiques ou à tous les utilisateurs Samba. Si vous décidez d'autoriser l'accès à des utilisateurs spécifiques, choisissez les utilisateurs à partir de la liste des utilisateurs Samba disponibles.
Le partage est ajouté immédiatement après avoir cliqué Valider.
Samba utilise /etc/samba/smb.conf
comme son fichier de configuration. Si vous changez ce fichier de configuration, les modifications ne prennent effet que lorsque vous redémarrez le démon Samba avec la commande service smb restart
.
Pour spécifier le groupe de travail Samba et une brève description du serveur Samba, éditez les lignes suivantes dans votre fichier smb.conf
:
workgroup =WORKGROUPNAME
server string =BRIEF COMMENT ABOUT SERVER
Remplacez WORKGROUPNAME
par le nom du groupe de travail Windows auquel cette machine devrait appartenir. Le BRIEF COMMENT ABOUT SERVER
est optionnel et il est utilisé comme le commentaire Windows à propos du système Samba.
Pour créer un répertoire de partage Samba sur votre système Linux, ajoutez la section suivante à votre fichier smb.conf
(après l'avoir modifié pour qu'il reflète vos exigences et votre système) :
[sharename
] comment =Insert a comment here
path =/home/share/
valid users =tfox carole
public = no writable = yes printable = no create mask = 0765
L'exemple ci-dessus permet aux utilisateurs tfox
et carole
de lire et d'écrire sur le répertoire /home/share
, sur le serveur Samba, à partir d'un client Samba.
Pour démarrer un serveur Samba, saisissez la commande suivante à l'invite du shell en tant que super-utilisateur :
/sbin/service smb start
Pour configurer un serveur membre du domaine, vous devez d'abord faire partie du domaine ou de l'Active Directory en utilisant la commande net join
avant de démarrer le service smb
.
Pour arrêter le serveur, saisissez la commande suivante à l'invite du shell en tant que super-utilisateur :
/sbin/service smb stop
L'option restart
permet d'arrêter et de redémarrer Samba rapidement. Cette option constitue la manière la plus fiable afin d'appliquer des modifications lorsque le fichier de configuration Samba a été modifié. Notez que l'option de redémarrage (restart) lance le démon même s'il ne tournait pas à l'origine.
Pour redémarrer le serveur, saisissez la commande suivante en tant que super-utilisateur à une invite du shell :
/sbin/service smb restart
L'option condrestart
(redémarrage sous certaines conditions) ne lance smb
que s'il est déjà en cours d'exécution. Cette option est utile pour les scripts car elle ne démarre pas le démon s'il n'est pas déjà en cours d'exécution.
Lorsque le fichier smb.conf
est modifié, Samba le recharge automatiquement après quelques minutes. L'exécution manuelle de la commande restart
ou reload
est tout aussi efficace.
Pour redémarrer le serveur sous certaines conditions, saisissez la commande suivante en tant que super-utilisateur :
/sbin/service smb condrestart
Un rechargement manuel du fichier smb.conf
peut être utile en cas d'échec du rechargement automatique par le service smb
. Pour être certain que le fichier de configuration du serveur Samba est rechargé sans avoir à redémarrer le service, saisissez la commande suivante en tant que super-utilisateur :
/sbin/service smb reload
Par défaut, le service smb
ne démarre pas automatiquement à l'amorçage. Pour configurer Samba afin qu'il se lance au démarrage, employez un utilitaire initscript, tel que /sbin/chkconfig
, /usr/sbin/ntsysv
, ou l'Outil de configuration des services. Reportez-vous au Chapitre 7, Contrôle d'accès aux services pour obtenir de plus amples informations sur ces outils.
La configuration de Samba est une opération assez simple. Toutes les modifications apportées à Samba ont lieu dans le fichier de configuration /etc/samba/smb.conf
. Bien que le fichier par défaut smb.conf
soit bien documenté, il n'aborde pas des sujets complexes tels que LDAP, Active Directory et les nombreuses implémentations de contrôleurs de domaines.
Les sections suivantes décrivent les différentes manières dont un serveur Samba peut être configuré. Gardez bien à l'esprit vos besoins et les modifications devant être apportées au fichier smb.conf
pour effectuer une configuration réussie.
Un serveur autonome peut être le serveur d'un groupe de travail ou un membre de l'environnement d'un groupe de travail. Un serveur autonome n'est pas un contrôleur de domaine et ne joue aucun rôle dans un domaine. Les exemples suivants illustrent plusieurs configurations de sécurité anonyme au niveau du partage et un exemple de configuration de sécurité au niveau de l'utilisateur. Pour obtenir de plus amples informations sur les modes de sécurité au niveau du partage ou au niveau de l'utilisateur, reportez-vous à Section 11.7, « Modes de sécurité pour Samba ».
Le fichier smb.conf
suivant montre un extrait du fichier de configuration nécessaire pour permettre l'implémentation d'un partage de fichiers anonyme en lecture-seule. Le paramètre security = share
rend un partage anonyme. Notez bien que les niveaux de sécurité pour un seul serveur Samba ne peuvent pas être mélangé. La directive de sécurité security
est un paramètre global pour Samba qui se trouve dans la section de configuration [global]
du fichier smb.conf
.
[global] workgroup = DOCS netbios name = DOCS_SRV security = share [data] comment = Documentation Samba Server path = /export read only = Yes guest only = Yes
Le fichier smb.conf
suivant montre un extrait du fichier de configuration nécessaire pour permettre l'implémentation d'un partage de fichiers anonyme en lecture/écriture. Pour permettre le partage anonyme de fichiers en lecture/écriture, donnez à la directive read only
(lecture-seule) la valeur no
. Les directives force user
et force group
sont également ajoutées pour appliquer les règles de propriété à tout fichier ajouté et spécifié comme appartenant au partage.
Bien qu'il soit possible d'avoir un serveur anonyme en lecture/écriture, un tel choix n'est pas recommandé. Tous fichiers placés dans l'espace de partage, indépendemment de l'utilisateur, sont assignés à la combinaison utilisateur/groupe telle qu'elle est spécifiée par un utilisateur générique (force user
) et un groupe (force group
) dans le fichier smb.conf
.
[global] workgroup = DOCS netbios name = DOCS_SRV security = share [data] comment = Data path = /export force user = docsbot force group = users read only = No guest ok = Yes
Le fichier smb.conf
suivant montre un extrait du fichier de configuration nécessaire pour implémenter un serveur d'impression anonyme. Comme nous l'avons montré, le fait de donner à browsable
la valeur no
, n'inclut pas l'imprimante dans la liste Voisinnage réseau de Windows. Bien que n'apparaissant pas lors de la navigation, la configuration explicite de l'imprimante est possible. Grâce à la connexion à DOCS_SRV
en utilisant NetBIOS, le client peut avoir accès à l'imprimante s'il fait également partie du groupe de travail DOCS
. On suppose également que le client a installé le pilote d'impression local approprié puisque la directive use client driver
a la valeur Yes
. Dans ce cas, le serveur Samba n'a aucune responsabilité quant au partage de pilotes d'impression avec le client.
[global] workgroup = DOCS netbios name = DOCS_SRV security = share printcap name = cups disable spools= Yes show add printer wizard = No printing = cups [printers] comment = All Printers path = /var/spool/samba guest ok = Yes printable = Yes use client driver = Yes browseable = Yes
Le fichier smb.conf
suivant montre un extrait du fichier de configuration nécessaire pour implémenter un serveur d'impression sécurisé en lecture/écriture. Le fait de donner à la directive security
la valeur user
force Samba à authentifier les connexions client. Remarquez bien que le partage [homes]
n'a pas de directive force user
ou force group
, contrairement au partage [public]
. Le partage [homes]
utilise les informations relatives à l'utilisateur authentifié pour la création de tout fichier, contrairement aux directives force user
et force group
dans [public]
.
[global] workgroup = DOCS netbios name = DOCS_SRV security = user printcap name = cups disable spools = Yes show add printer wizard = No printing = cups [homes] comment = Home Directories valid users = %S read only = No browseable = No [public] comment = Data path = /export force user = docsbot force group = users guest ok = Yes [printers] comment = All Printers path = /var/spool/samba printer admin = john, ed, @admins create mask = 0600 guest ok = Yes printable = Yes use client driver = Yes browseable = Yes
Un membre d'un domaine, bien qu'étant semblable à un serveur autonome, est connecté à un contrôleur de domaine (soit Windows, soit Samba) et soumis aux règles de sécurité de ce domaine. Le serveur du département d'une entreprise exécutant Samba et ayant un compte machine sur contrôleur de domaine principal (ou PDC, Primary Domain Controller) est un exemple de serveur membre d'un domaine. Tous les clients du département continuent à s'authentifier auprès du PDC et les profiles du bureau ainsi que les fichiers des politiques réseau sont inclus. La différence est que le serveur du département a la capacité de contrôler les partages au niveau de l'impression et les partages de réseau.
Le fichier smb.conf
suivant montre un extrait du fichier de configuration nécessaire pour implémenter un serveur membre du domaine Active Directory. Dans notre exemple, Samba non seulement authentifie les utilisateurs pour les services exécutés localement, mais il est également un client de Active Directory. Assurez-vous que le paramètre de votre zone (realm
) kerberos apparaît bien tout en lettres majuscules (par exemple, realm = EXAMPLE.COM
). Étant donné que Windows 2000/2003 a besoin de Kerberos pour l'authentification de Active Directory, la directive realm
est nécessaire. Si Active Directory et Kerberos sont exécutés sur des serveurs différents, il se peut que la directive password server
soit nécessaire pour permettre la distinction entre les deux.
[global] realm = EXAMPLE.COM security = ADS encrypt passwords = yes # Optional. Use only if Samba cannot determine the Kerberos server automatically. password server = kerberos.example.com
Pour qu'un serveur membre fasse partie d'un domaine Active Directory, il est nécessaire d'effectuer les étapes suivantes :
Configuration du fichier smb.conf
sur le serveur membre
Configuration de Kerberos, y compris le fichier /etc/krb5.conf
, sur le serveur membre
Création du compte machine sur le serveur du domaine Active Directory
Association du serveur membre au domaine Active Directory
Pour créer le compte machine et faire partie de Active Directory de Windows 2000/2003, Kerberos doit tout d'abord être initialisé pour le serveur membre souhaitant faire partie du domaine Active Directory. Pour créer un ticket administratif pour Kerberos, saisissez la commande suivante en étant connecté en tant que super-utilisateur (ou root) sur le serveur membre :
kinit administrator@EXAMPLE.COM
Pour faire partie d'un serveur Active Directory (windows1.example.com), tapez la commande suivante en étant connecté en tant que super-utilisateur (ou root) sur le serveur membre :
net ads join -S windows1.example.com -U administrator%password
Étant donné que la machine windows1
a été trouvée automatiquement dans la zone Kerberos appropriée (la commande kinit
a abouti), la commande net
établit la connexion avec le serveur Active Directory utilisant le compte administrateur et le mot de passe requis. Ainsi, le compte machine est créé sur le serveur Active Directory et les permissions sont accordées pour que le membre serveur du domaine Samba puisse faire partie du domaine.
Étant donné que security = ads
est utilisé, et non pas security = user
, il n'est pas nécessaire d'utiliser un mot de passe secondaire (backend) tel que smbpasswd
. Des clients plus anciens ne prenant pas en charge security = ads
sont authentifiés comme si security = domain
avait été configuré. Ce changement ne touche pas les fonctionnalités et autorise des utilisateurs locaux qui n'étaient pas inclus auparavant dans le domaine.
Le fichier smb.conf
suivant montre un extrait du fichier de configuration nécessaire pour implémenter un serveur membre d'un domaine basé sur Windows NT4. Devenir un serveur membre d'un domaine basé sur Windows NT4 revient en fait comme à se connecter à un Active Directory. La différence essentielle réside dans le fait que les domaines basés sur NT4 n'utilisent pas Kerberos dans leur méthode d'authentification, ce qui simplifie le fichier smb.conf
. Dans ce cas, le serveur membre de Samba joue le rôle d'une machine intermédiaire vers le serveur de domaine basé sur NT4.
[global] workgroup = DOCS netbios name = DOCS_SRV security = domain [homes] comment = Home Directories valid users = %S read only = No browseable = No [public] comment = Data path = /export force user = docsbot force group = users guest ok = Yes
Le fait d'avoir Samba comme un serveur membre d'un domaine peut être utile dans de nombreuses situations. Dans certains cas le serveur Samba peut être utilisé à d'autres fins que le partage de fichiers et d'impression. Il peut s'avérer utile de transformer Samba en serveur membre d'un domaine, dans des situations où des applications exclusivement Linux doivent être utilisées dans l'environnement du domaine. Il est utile pour les administrateurs d'effectuer un suivi de toutes les machines faisant partie du domaine, même s'il n'est pas basé sur Windows. Dans le cas où le matériel du serveur basé sur Windows deviendrait obsolète, il est relativement facile de modifier le fichier smb.conf
pour convertir le serveur en PDC basé sur Samba. Si les serveurs basés sur Windows NT sont mis à niveau vers Windows 2000/2003, le fichier smb.conf
est facilement modifiable pour inclure les changements d'infrastructure dans Active Directory, si nécessaire.
Après avoir configuré le fichier smb.conf
, intégrez le domaine avant de démarrer Samba en tapant la commande suivante en étant connecté en tant que super-utilisateur :
net rpc join -U administrator%password
Notez bien que l'option -S
, qui précise le nom d'hôte du serveur de domaine, ne doit pas obligatoirement être spécifiée dans la commande net rpc join
. Samba utilise le nom d'hôte spécifié par la directive workgroup
dans le fichier smb.conf
plutôt que de demander à ce qu'il soit spécifié explicitement.
Un contrôleur de domaine dans Windows NT joue essentiellement le même rôle qu'un service d'information réseau (ou NIS, Network Information Service) dans un environnement Linux. Les contrôleurs de domaine et les serveurs NIS hébergent tous les deux des bases de données d'informations utilisateurs/groupes sur les hôtes, ainsi que sur les services apparentés. Les contrôleurs de domaine sont principalement utilisés pour la sécurité, y compris l'authentification des utilisateurs accédant aux ressources du domaine. Le service qui maintient l'intégrité de la base de données relative aux utilisateurs/groupes s'appelle gestionnaire des comptes de sécurité (ou SAM, Security Account Manager). La base de données de SAM est stockée de manière différente dans des systèmes Windows et Linux basés sur Samba, si bien que la réplication de SAM ne peut se faire et que les plates-formes ne peuvent pas être mélangées dans un environnement PDC/BDC.
Dans un environnement Samba, il ne peut y avoir qu'un seul PDC et aucun ou plusieurs BDC.
Samba ne peut pas exister dans l'environnement d'un contrôleur de domaine mélangé Samba/Windows (Samba ne peut pas être un BDC d'un PDC Windows ou vice versa). Autrement, les PDC et BDC de Samba peuvent coexister.
L'implémentation la plus simple et la plus courante d'un PDC Samba utilise le backend de la base de données de mot de passe nommé tdbsam
. Conçu dans l'intention de remplacer le backend smbpasswd
désormais un peu passé, tdbsam
est doté de nombreuses améliorations qui sont examinées en revue de manière détaillée dans Section 11.8, « Bases de données d'informations sur les comptes Samba ». La directive passdb backend
contrôle le backend spécifique devant être utilisé pour le PDC.
[global]
workgroup = DOCS
netbios name = DOCS_SRV
passdb backend = tdbsam
security = user
add user script = /usr/sbin/useradd -m %u
delete user script = /usr/sbin/userdel -r %u
add group script = /usr/sbin/groupadd %g
delete group script = /usr/sbin/groupdel %g
add user to group script = /usr/sbin/usermod -G %g %u
add machine script = /usr/sbin/useradd -s /bin/false -d /dev/null -g machines %u
# The following specifies the default logon script
# Per user logon scripts can be specified in the user
# account using pdbedit logon script = logon.bat
# This sets the default profile path.
# Set per user paths with pdbedit
logon drive = H:
domain logons = Yes
os level = 35
preferred master = Yes
domain master = Yes
[homes]
comment = Home Directories
valid users = %S
read only = No
[netlogon]
comment = Network Logon Service
path = /var/lib/samba/netlogon/scripts
browseable = No
read only = No
# For profiles to work, create a user directory under the
# path shown. mkdir -p /var/lib/samba/profiles/john
[Profiles]
comment = Roaming Profile Share
path = /var/lib/samba/profiles
read only = No
browseable = No
guest ok = Yes
profile acls = Yes
# Other resource shares ... ...
Si vous avez besoin de plus d'un contrôleur de domaine ou avez plus de 250 utilisateurs, n'utilisez pas un backend d'authentification tdbsam
. Dans ces cas particuliers, il est plutôt recommandé d'utiliser LDAP.
Il existe seulement deux types de modes de sécurité pour Samba, à savoir share-level (niveau du partage) et user-level (niveau de l'utilisateur) ; collectivement, on fait référence à ces deux modes sous le terme niveaux de sécurité. La sécurité au niveau du partage peut être implémentée d'une seule manière alors que la sécurité au niveau de l'utilisateur peut elle être mise en oeuvre de quatre manières différentes. On appelle modes de sécurité les différentes manières d'implémenter un niveau de sécurité.
La sécurité au niveau de l'utilisateur est le choix par défaut pour Samba. Même si la directive security = user
n'est pas présente dans le fichier smb.conf
, elle est utilisée par Samba. Si le serveur accepte le nom d'utilisateur/mot de passe du client, ce dernier peut alors monter des partages multiples sans devoir saisir un mot de passe à chaque fois. Samba peut aussi accepter des requêtes nom d'utilisateur/mot de passe basées sur les sessions. Le client maintient des contextes d'authentification multiples grâce à l'utilisation d'un identifiant utilisateur unique (ou UID) pour chaque connexion.
Dans smb.conf
, la directive security = user
définissant la sécurité au niveau de l'utilisateur est :
[GLOBAL] ... security = user ...
Les sections suivantes décrivent d'autres implémentations de la sécurité niveau utilisateur.
En mode de sécurité domaine, le serveur Samba dispose d'un compte machine (un compte de confiance pour la sécurité du domaine) qui force toutes les requêtes d'authentification à passer par les contrôleurs de domaine. Le serveur Samba se voit devenir un serveur membre du domaine en utilisant la directive suivante dans smb.conf
:
[GLOBAL] ... security = domain workgroup = MARKETING ...
Si vous avez un environnement Active Directory, il est possible de faire partie du domaine en tant que membre natif d'Active Directory. Même si une politique de sécurité limite l'utilisation de protocoles d'authentification compatibles avec NT, le serveur Samba peut faire partie d'un ADS à l'aide de Kerberos. Samba en mode membre d'Active Directory peut accepter des tickets Kerberos.
Dans smb.conf
, les directives suivantes font de Samba un serveur membre d'Active Directory :
[GLOBAL] ... security = ADS realm = EXAMPLE.COM password server = kerberos.example.com ...
Le mode de sécurité serveur était auparavant utilisé lorsque Samba n'était pas à même d'agir comme un serveur membre d'un domaine.
Il est fortement recommandé de ne pas utiliser ce mode étant donné qu'il existe de nombreux inconvénients au niveau de la sécurité.
Dans smb.conf
, les directives suivantes permettent à Samba de fonctionner en mode sécurité serveur :
[GLOBAL] ... encrypt passwords = Yes security = server password server = "NetBIOS_of_Domain_Controller" ...
Dans la cas de la sécurité au niveau du partage, le serveur accepte seulement un mot de passe sans demander un nom d'utilisateur explicite de la part du client. Le serveur attend la saisie d'un mot de passe pour chaque partage, indépendemment du nom d'utilisateur. Un certain nombre de rapports indiquent que les clients Microsoft Windows rencontrent des problèmes de compatibilité avec les serveurs implémentant la sécurité au niveau du partage. Les développeurs de Samba découragent fortement l'utilisation de la sécurité au niveau du partage.
Dans smb.conf
, la directive security = share
définissant la sécurité au niveau du partage est :
[GLOBAL] ... security = share ...
La dernière version de Samba offre un certain nombre de nouvelles fonctionnalités parmi lesquelles figurent de nouveaux backends pour les bases de données de mots de passe qui n'étaient pas disponibles auparavant. La version 3.0.0 de Samba prend pleinement en charge toutes les bases de données utilisées dans les versions précédentes de Samba. Toutefois, bien que de nombreux backends soient pris en charge, il se peut que certains ne soient pas appropriés pour une utilisation dans un environnement de production.
Ce qui suit est une liste de différents backends que vous pouvez utiliser avec Samba. D'autres backends qui ne sont pas listés ici, peuvent aussi être disponibles.
Les backends en texte clair ne sont rien d'autre que des backends de type /etc/passwd
. Avec des backends en texte clair, tous les noms d'utilisateur et mots de passe sont transmis de manière non cryptée entre le client et le serveur Samba. Cette méthode n'est pas sûre du tout et son utilisation est par conséquent fortement déconseillée. Il est possible que différents clients Windows se connectant au serveur Samba à l'aide de mots de passe en texte clair ne soient pas en mesure de prendre en charge une telle méthode d'authentification.
smbpasswd
smbpasswd
, un backend populaire employé dans des paquetages précédents de Samba utilise une simple structure de texte ASCII qui inclut le compte LanMan et NT de MS Windows LanMan ainsi que des informations cryptées sur les mots de passe. Il manque au backend smbpasswd
le stockage des contrôles étendus du Storage Area Manager (SAM) de Windows NT/2000/2003. Le backend smbpasswd
n'est pas recommandé car il n'est pas facilement modulable et ne comporte aucune information sur Windows, comme les RID (Relative Identifier) pour des groupes basés sur NT. Le backend tdbsam
résout certes ces problèmes pour une utilisation dans une base de données relativement petite (250 utilisateurs), mais il n'en fait toujours pas une solution de niveau entreprise.
ldapsam_compat
Le backend ldapsam_compat
permet la prise en charge continue de OpenLDAP pour une utilisation avec les versions mises à niveau de Samba. Cette option est idéale pour une migration vers Samba 3.0.
tdbsam
Le backend tdbsam
fournit un backend de base de données idéal pour les serveurs locaux, les serveurs ne nécessitant pas de réplication intégrée de base de données et des serveurs ne nécessitant pas modulabilité ou la complexité de LDAP. Le backend tdbsam
inclut toutes les informations de la base de données smbpasswd
, ainsi que les informations de SAM qui n'étaient pas précédemment incluses. L'inclusion des données détaillées de SAM permet à Samba d'implémenter les mêmes contrôles d'accès aux comptes et aux systèmes que ceux en place avec les systèmes basés sur Windows NT/2000/2003.
Le backend tdbsam
est recommandé pour un maximum de 250 utilisateurs. Des organisations plus grandes nécessitent l'intégration d'Active Directory ou de LDAP en raison des problèmes potentiels qu'il pose au niveau de la modulabilité et de l'infrastructure réseau.
ldapsam
Le backend ldapsam
fournit une excellente méthode d'installation distribuée des comptes pour Samba. LDAP est parfait en raison de sa capacité à répliquer sa base de données sur un nombre quelconque de serveurs grâce au démon slurpd
d'OpenLDAP. Les bases de données de LDAP sont légères et modulables et sont donc parfaites pour la plupart des organisations, particulièrement les grandes entreprises.
Si vous faites une mise à niveau vers la version 3.0 de Samba, notez que le schéma /usr/share/doc/samba-
a changé. Ce fichier contient les définitions de la syntaxe des attributs et les définitions des classes d'objets dont le backend <version>
/LDAP/samba.schemaldapsam
aura besoin pour son bon fonctionnement.
Si vous utilisez le backend ldapsam
pour vottre serveur Samba, il vous faudra configurer slapd
pour inclure ce fichier de schéma. Pour ce faire, référez-vous aux instructions de la Section 16.5, « Répertoire /etc/openldap/schema/
».
Vous aurez besoin du paquetage openldap-server
installé si vous désirez utiliser le backend ldapsam
.
mysqlsam
Le backend mysqlsam
utilise un backend de base de données basé sur MySQL. Cette caractéristique est utile pour les sites qui implémentent déjà MySQL. Actuellement, mysqlsam
est empaqueté dans un module séparé de Samba, et en tant que tel, il n'est pas officiellement pris en charge par Samba.
La navigation réseau (Network browsing) est un concept permettant aux serveurs Windows et Samba d'apparaître dans le Voisinnage réseau de Windows. Au sein du Voisinnage réseau apparaissent des icônes qui représentent des serveurs et, lorsque ces icônes sont ouvertes, les partages et imprimantes du serveur qui sont disponibles sont affichés.
Les capacités de navigation réseau nécessitent NetBIOS sur TCP/IP. La mise en réseau basée sur NetBIOS utilise la messagerie de diffusion générale (UDP) pour effectuer la gestion de listes de navigation. Sans NetBIOS et WINS comme méthode primaire pour la résolution de noms d'hôtes sur TCP/IP, d'autres méthodes telles que des fichiers statiques (/etc/hosts
) ou DNS doivent être utilisées.
Un navigateur maître de domaine dresse les listes de navigation à partir des navigateurs maîtres locaux sur tous les sous-réseaux afin que la navigation puisse s'effectuer entre les groupes de travail et les sous-réseaux. De plus, le navigateur maître de domaine devrait de préférence être le navigateur maître local de son propre sous-réseau.
Par défaut, un PDC serveur sous Windows pour un domaine est également le navigateur maître de ce domaine. Un serveur Samba ne doit pas être configuré en tant que serveur maître de domaine dans ce type de situation.
Pour les sous-réseaux qui n'incluent pas le PDC de Windows NT, il est possible d'implémenter un serveur Samba en tant que navigateur maître local. La configuration de smb.conf
pour un navigateur maître local (ou aucune navigation du tout) dans un environnement de contrôleur de domaine est l'équivalent de la configuration d'un groupe de travail.
Un serveur Samba ou un serveur Windows NT peut fonctionner comme un serveur WINS. Lorsqu'un serveur WINS est utilisé avec NetBIOS activé, les paquets UDP unicast peuvent être routés permettant ainsi la résolution de noms à travers les réseaux. Sans serveur WINS, la diffusion UDP est limitée au sous-réseau local et par conséquent, ne peut pas être routée vers les autres sous-réseaux, groupes de travail ou domaines. Si la reproduction est nécessaire, n'utilisez pas Samba comme votre serveur WINS principal car Samba ne prend pas actuellement en charge la réplication WINS.
Dans un environnement mélangé composé de serveurs NT/2000/2003 et Samba, il est recommandé d'utiliser les capacités WINS de Microsoft. Dans un environnement exclusivement Samba, il est recommandé d'utiliser un seul serveur Samba pour WINS.
Ci-dessous figure un extrait du fichier smb.conf
dans lequel le serveur Samba est utilisé comme un serveur WINS :
[global] wins support = Yes
Tous les serveurs (y compris Samba) devraient se connecter à un serveur WINS pour la résolution de noms NetBIOS. Sans WINS, la navigation n'a lieu que sur le sous-réseau local. En outre, même si une liste pour tout le domaine est obtenue d'une manière ou d'une autre, sans WINS, la résolution des hôtes pour le client n'est pas possible.
Samba permet aux machines clientes non seulement de partager les imprimantes reliées au serveur Samba mais il permet également d'envoyer des documents Linux à des partages d'imprimantes Windows. Bien que d'autres systèmes d'impression fonctionnent avec Red Hat Enterprise Linux, CUPS (de l'anglais Common UNIX Print System) est le système d'impression recommandé en raison de son étroite intégration à Samba.
L'exemple ci-dessous illustre une configuration très élémentaire de smb.conf
pour la prise en charge de CUPS :
[global] load printers = Yes printing = cups printcap name = cups [printers] comment = All Printers path = /var/spool/samba/print printer = IBMInfoP browseable = No public = Yes guest ok = Yes writable = No printable = Yes printer admin = @ntadmins [print$] comment = Printer Drivers Share path = /var/lib/samba/drivers write list = ed, john printer admin = ed, john
D'autres configurations d'impression plus compliquées sont possibles. Pour une sécurité et confidentialité accrue lors de l'impression de documents importants, les utilisateurs peuvent avoir leur propre spouleur d'impression ne se trouvant pas sur un chemin d'accès public. De la sorte, si un travail d'impression n'aboutit pas, d'autres utilisateurs n'auront pas accès au fichier.
Le partage print$
contient les pilotes d'impression auxquels les clients peuvent avoir accès s'ils ne sont pas disponibles localement. Le partage print$
est facultatif et n'est pas forcément nécessaire selon le type d'organisation.
En donnant au paramètre browseable
la valeur Yes
, l'imprimante pourra être affichée dans le voisinnage réseau de Windows, à supposé que le serveur Samba soit configuré correctement dans le domaine/groupe de travail.
findsmb
findsmb
<subnet_broadcast_address>
Le programme findsmb
est un script Perl qui permet de recueillir des informations sur les systèmes compatibles avec SMB sur un sous-réseau particulier. Si aucun sous-réseau n'est spécifié, le sous-réseau local est utilisé. Parmi les éléments spécifiés figurent l'adresse IP, le nom, groupe de travail ou nom de domaine NetBIOS, le système d'exploitation et la version.
L'exemple suivant montre la sortie de la commande findsmb
exécutée en tant qu'un utilisateur valide du système :
findsmb
IP ADDR NETBIOS NAME WORKGROUP/OS/VERSION
------------------------------------------------------------------
10.1.59.25 VERVE [MYGROUP] [Unix] [Samba 3.0.0-15]
10.1.59.26 STATION22 [MYGROUP] [Unix] [Samba 3.0.2-7.FC1]
10.1.56.45 TREK +[WORKGROUP] [Windows 5.0] [Windows 2000 LAN Manager]
10.1.57.94 PIXEL [MYGROUP] [Unix] [Samba 3.0.0-15]
10.1.57.137 MOBILE001 [WORKGROUP] [Windows 5.0] [Windows 2000 LAN Manager]
10.1.57.141 JAWS +[KWIKIMART] [Unix] [Samba 2.2.7a-security-rollup-fix]
10.1.56.159 FRED +[MYGROUP] [Unix] [Samba 3.0.0-14.3E]
10.1.59.192 LEGION *[MYGROUP] [Unix] [Samba 2.2.7-security-rollup-fix]
10.1.56.205 NANCYN +[MYGROUP] [Unix] [Samba 2.2.7a-security-rollup-fix]
net
net
<protocol> <function> <misc_options> <target_options>
L'utilitaire net
est semblable à l'utilitaire net
utilisé pour Windows et MS-DOS. Le premier argument est utilisé pour spécifier le protocole à utiliser lors de l'exécution d'une commande. L'option
peut être <protocol>
ads
, rap
ou rpc
pour la spécification du type de connexion serveur. Active Directory utilise ads
, Win9x/NT3 utilise rap
et Windows NT4/2000/2003 utilise rpc
. Si le protocole n'est pas précisé, net
essaie automatiquement de le déterminer.
L'exemple suivant affiche une liste des partages disponibles pour un hôte portant le nom wakko
:
net -l share -S wakko
Password:
Enumerating shared resources (exports) on remote server:
Share name Type Description
---------- ---- -----------
data Disk Wakko data share
tmp Disk Wakko tmp share
IPC$ IPC IPC Service (Samba Server)
ADMIN$ IPC IPC Service (Samba Server)
L'exemple suivant affiche une liste des utilisateurs Samba pour un hôte portant le nom wakko
:
net -l user -S wakko
root password:
User name Comment
-----------------------------
andriusb Documentation
joe Marketing
lisa Sales
nmblookup
nmblookup
<options> <netbios_name>
Le programme nmblookup
effectue la résolution des noms NetBIOS en adresse IP. Le programme diffuse sa demande sur le sous-réseau local jusqu'à ce que la machine cible réponde.
Ci-après figure un exemple :
nmblookup trek
querying trek on 10.1.59.255
10.1.56.45 trek<00>
pdbedit
Le programme pdbedit
gère les comptes présents dans la base de données de SAM. Tous les backends sont pris en charge, y compris smbpasswd
, LDAP, NIS+ et la bibliothèque de base de données tdb
.
Ci-dessous figurent des exemples d'ajout, de suppression et de listage d'utilisateurs :
pdbedit -a kristin
new password: retype new password: Unix username: kristin NT username: Account Flags: [U ] User SID: S-1-5-21-1210235352-3804200048-1474496110-2012 Primary Group SID: S-1-5-21-1210235352-3804200048-1474496110-2077 Full Name: Home Directory: \\wakko\kristin HomeDir Drive: Logon Script: Profile Path: \\wakko\kristin\profile Domain: WAKKO Account desc: Workstations: Munged dial: Logon time: 0 Logoff time: Mon, 18 Jan 2038 22:14:07 GMT Kickoff time: Mon, 18 Jan 2038 22:14:07 GMT Password last set: Thu, 29 Jan 2004 08:29:28 GMT Password can change: Thu, 29 Jan 2004 08:29:28 GMT Password must change: Mon, 18 Jan 2038 22:14:07 GMTpdbedit -v -L kristin
Unix username: kristin NT username: Account Flags: [U ] User SID: S-1-5-21-1210235352-3804200048-1474496110-2012 Primary Group SID: S-1-5-21-1210235352-3804200048-1474496110-2077 Full Name: Home Directory: \\wakko\kristin HomeDir Drive: Logon Script: Profile Path: \\wakko\kristin\profile Domain: WAKKO Account desc: Workstations: Munged dial: Logon time: 0 Logoff time: Mon, 18 Jan 2038 22:14:07 GMT Kickoff time: Mon, 18 Jan 2038 22:14:07 GMT Password last set: Thu, 29 Jan 2004 08:29:28 GMT Password can change: Thu, 29 Jan 2004 08:29:28 GMT Password must change: Mon, 18 Jan 2038 22:14:07 GMTpdbedit -L
andriusb:505: joe:503: lisa:504: kristin:506:pdbedit -x joe
pdbedit -L
andriusb:505: lisa:504: kristin:506:
rpcclient
Le programme rpcclient
exécute des commandes administratives utilisant les RPC de Microsoft, qui fournissent l'accès aux interfaces d'administration graphiques (ou GUI) pour la gestion des systèmes. Ce dernier est le plus souvent utilisé par les utilisateurs expérimentés qui comprennent bien la complexité des RPC de Microsoft.
smbcacls
smbcacls
<//server/share> <filename> <options>
Le programme smbcacls
modifie les ACL de Windows dans les fichiers et répertoires partagés par le serveur Samba.
smbclient
smbclient
<//server/share> <password> <options>
Le programme smbclient
est un client UNIX souple qui fournit des fonctionnalités semblables à ftp
.
smbcontrol
smbcontrol
<options> <destination> <messagetype> <parameters>
Le programme smbcontrol
envoie des messages de contrôle aux démons smbd
ou nmbd
en cours d'exécution. L'exécution de smbcontrol -i
lance la commande de manière interactive jusqu'à ce qu'une ligne blanche ou que la lettre 'q' soit saisie.
smbpasswd
smbpasswd
<options> <username> <password>
Le programme smbpasswd
gère les mots de passe cryptés. Ce programme peut être exécuté aussi bien par un super-utilisateur pour changer le mot de passe d'un utilisateur quelconque que par un utilisateur ordinaire pour changer son propre mot de passe Samba.
smbspool
smbspool
<job> <user> <title> <copies> <options> <filename>
Le programme smbspool
est une interface compatible avec le système d'impression CUPS pour Samba. Bien qu'il soit conçu pour une utilisation avec des imprimantes CUPS, smbspool
peut également fonctionner avec des imprimantes non-CUPS.
smbstatus
Le programme smbstatus
affiche le statut des connexions actuelles à un serveur Samba.
smbtar
Le programme smbtar
effectue la sauvegarde et la restauration de fichiers et de répertoires en partage sous Windows sur une bande d'archive locale. Bien que ce programme soit semblable à la commande tar
, les deux ne sont pas compatibles.
testparm
testparm
<options> <filename> <hostname IP_address>
Le programme testparm
vérifie la syntaxe du fichier smb.conf
. Si votre fichier smb.conf
se trouve dans l'emplacement par défaut (/etc/samba/smb.conf
), il n'est pas nécessaire de préciser l'emplacement. La spécification du nom d'hôte et de l'adresse IP pour le programme testparm
permet de vérifier que les fichiers hosts.allow
et host.deny
sont bien configurés correctement. Le programme testparm
affiche également un résumé de vos fichiers smb.conf
et le rôle du serveur (autonome, domaine, etc.) après avoir effectué les tests. Ce programme est utile lors du débogage étant donné qu'il exclut les commentaires et fournit les informations de manière concise pour des administrateurs expérimentés.
Exemple :
testparm
Load smb config files from /etc/samba/smb.conf Processing section "[homes]" Processing section "[printers]" Processing section "[tmp]" Processing section "[html]" Loaded services file OK. Server role: ROLE_STANDALONE Press enter to see a dump of your service definitions<enter>
# Global parameters [global] workgroup = MYGROUP server string = Samba Server security = SHARE log file = /var/log/samba/%m.log max log size = 50 socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192 dns proxy = No [homes] comment = Home Directories read only = No browseable = No [printers] comment = All Printers path = /var/spool/samba printable = Yes browseable = No [tmp] comment = Wakko tmp path = /tmp guest only = Yes [html] comment = Wakko www path = /var/www/html force user = andriusb force group = users read only = No guest only = Yes
wbinfo
Le programme wbinfo
affiche des informations du démon winbindd
. Logiquement, le démon winbindd
doit être en cours d'exécution pour que wbinfo
fonctionne.
Les sections suivantes offrent la possibilité d'explorer Samba de manière plus détaillée.
/usr/share/doc/samba-<
— Tous les fichiers supplémentaires inclus dans la distribution de Samba. Parmi ces derniers figurent entre autres, tous les scripts d'aide, des exemples de fichiers de configuration et de la documentation.
version-number
>/
Ce répertoire contient également des versions en ligne des guides : The Official Samba-3 HOWTO-Collection et Samba-3 by Example, mentionnés ci-dessous.
The Official Samba-3 HOWTO-Collection de John H. Terpstra et Jelmer R. Vernooij ; Prentice Hall — La documentation officielle en anglais de Samba-3, telle qu'elle est publiée par l'équipe de développement de Samba. Il s'agit plus d'un guide de référence que d'un guide étape par étape.
Samba-3 by Example de John H. Terpstra; Prentice Hall — Une autre version officielle en anglais publiée par l'équipe de développement de Samba qui fournit des exemples détaillés d'OpenLDAP, DNS, DHCP et des fichiers de configuration d'impression. Ce document contient des informations élémentaires en relation avec le sujet qui sont d'une grande aide lors d'une implémentation proprement dite.
Using Samba, 2nd Edition de Jay T's, Robert Eckstein, et David Collier-Brown ; O'Reilly — Une bonne ressource aussi bien pour les débutants que pour les utilisateurs expérimentés, incluant des documents de référence détaillés.
http://www.samba.org/ — Page d'accueil de la distribution Samba où se trouve toute documentation officielle créée par l'équipe de développement de Samba. De nombreuses ressources sont disponibles en formats HTML et PDF, alors que d'autres ne sont disponibles qu'en les achetant. Bien qu'un certain nombre de ces liens ne soient pas spécifiques à Red Hat Enterprise Linux, certains concepts sont tout à fait applicables.
http://samba.org/samba/archives.html — Listes des emails actifs en relation avec la communauté Samba. Il est recommandé d'activer le mode groupé (digest) car les listes sont très actives.
Forums Samba — Divers forums Samba organisés en fils de discussion (ou thread), tels que gmane.org, utilisant le protocole NNTP sont également disponibles. Ces forums sont une alternative à la réception d'emails venant des listes de diffusion.
http://samba.idealx.org/ — Idealx.org distribue des scripts d'installation et de configuration pour l'intégration de Samba et OpenLDAP. Ces derniers sont fortement recommandés pour aider à gérer les ressources associées à LDAP. Ces scripts se trouvent à l'emplacement suivant : /usr/share/doc/samba-
mais peuvent également être téléchargés depuis le site Web de Idealx.
version_number
/LDAP/smbldap-tools
Le protocole DHCP ("Dynamic Host Configuration Protocol") est un protocole réseau permettant d'assigner automatiquement des informations TCP/IP aux ordinateurs client. Chaque client DHCP se connecte au serveur central DHCP, lequel renvoie la configuration réseau du client (y compris l'adresse IP, la passerelle et les serveurs DNS).
DHCP permet de livrer automatiquement la configuration des interfaces réseau du client. Lors de la configuration du système client, l'administrateur peut choisir DHCP et ne pas avoir à entrer d'adresse IP, de masque réseau, de passerelle ou de serveur DNS. Le client récupère ces informations à partir du serveur DHCP. DHCP est également utile lorsqu'un administrateur souhaite modifier les adresses IP d'un nombre important de systèmes. Au lieu de reconfigurer tous les systèmes, il peut se contenter d'éditer un fichier de configuration DHCP sur le serveur pour le nouvel ensemble d'adresses IP. Si les serveurs DNS d'une organisation changent, les modifications sont réalisées sur le serveur DHCP, et non pas sur les clients DHCP. Lorsque l'administrateur redémarre le réseau ou les clients, les changements prennent effet.
Si une organisation a un serveur DHCP fonctionnel correctement connecté à un réseau, les utilisateurs d'ordinateurs portables et autres ordinateurs mobiles peuvent déplacer ces périphériques de bureau en bureau.
Pour configurer un serveur DHCP, le fichier de configuration dhcpd.conf
doit être créé dans le répertoire /etc/
. Vous pouvez trouver un exemple de fichier dans /usr/share/doc/dhcp-<
.
version
>/dhcpd.conf.sample
DHCP utilise également le fichier /var/lib/dhcpd/dhcpd.leases
pour stocker la base de données d'attribution client. Reportez-vous à la Section 12.2.2, « Base de données d'attribution » pour plus d'informations.
The first step in configuring a DHCP server is to create the configuration file that stores the network information for the clients. Use this file to declare options and global options for client systems.
Le fichier de configuration peut contenir des tabulations ou lignes vierges complémentaires pour faciliter le formatage. Les mots-clés sont sensibles à la casse et les lignes commençant par un signe dièse (#) correspondent à des commentaires.
Deux schémas de mise à jour DNS sont actuellement mis en place — le mode de mise à jour DNS ad-hoc et le mode de mise à jour rapide avec interaction DHCP-DNS par intérim. Si ces deux modes sont acceptés comme faisant partie du processus IETF (Internet Engineering Task Force) standard, il y a aura un troisième mode — la méthode de mise à jour DNS standard. Vous devez configurer le serveur DNS pour qu'il soit compatible avec ces schémas. La version 3.0b2pl11 et les versions précédentes utilisaient le mode ad-hoc, qui a cependant été abandonné. Si vous souhaitez conserver le même comportement, ajoutez la ligne suivante en haut du fichier de configuration :
ddns-update-style ad-hoc;
Pour utiliser le deuxième mode, ajoutez la ligne suivante en haut du fichier de configuration :
ddns-update-style interim;
Consultez la page de manuel relative à dhcpd.conf
pour obtenir de plus amples informations sur les différents modes.
Il existe deux types de déclarations dans le fichier de configuration :
Paramètres — Les paramètres règlent l'exécution d'une tâche, la façon dont une tâche est exécutée ou les options de configuration réseau à envoyer au client.
Déclarations — Les déclarations décrivent la topologie du réseau, les clients ; elles fournissent des adresses pour les clients ou appliquent un groupe de paramètres à un groupe de déclarations.
Les paramètres qui commencent avec le mot-clé option sont considérés comme des options. Ces options configurent les options DHCP alors que les paramètres eux, configurent des valeurs qui ne sont pas facultatives ou contrôlent le comportement du serveur DHCP.
Les paramètres (y compris les options) déclarés avant une section entre accolades ({ }) sont considérés comme des paramètres globaux. Ceux-ci s'appliquent à toutes les sections se trouvant en dessous.
Si vous modifiez le fichier de configuration, les modifications ne prendront pas effet tant que vous n'aurez pas redémarré le démon DHCP à l'aide de la commande service dhcpd restart
.
Au lieu de changer le fichier de configuration et de redémarrer le service à chaque fois, vous pouvez utiliser la commande omshell
qui permet, de manière interactive, de se connecter, requêter et changer la configuration d'un serveur DHCP. En utilisant omshell
, tous les changements peuvent être effectués pendant que le serveur est démarré. Pour davantage d'informations sur omshell
, reportez-vous au manuel omshell
.
Dans l'Exemple 12.1, « Déclaration de sous-réseau », les options routers
, subnet-mask
, domain-name
, domain-name-servers
et time-offset
sont utilisées pour les déclarations host
.
De plus, vous pouvez déclarer un subnet
. Pour ce faire, vous devez inclure une déclaration subnet
pour chaque sous-réseau de votre réseau, sinon le serveur DHCP ne démarrera pas.
Dans cet exemple, il existe des options globales pour tous les clients DHCP dans le sous-réseau et une plage, range
, est déclarée. Les clients reçoivent une adresse IP au sein de range
.
subnet 192.168.1.0 netmask 255.255.255.0 { option routers 192.168.1.254; option subnet-mask 255.255.255.0; option domain-name "example.com"; option domain-name-servers 192.168.1.1; option time-offset -18000; # Eastern Standard Time range 192.168.1.10 192.168.1.100; }
Tous les sous-réseaux partageant le même réseau physique doivent être déclarés dans une déclaration shared-network
comme le montre l'Exemple 12.2, « Déclaration de réseau partagé ». Les paramètres se trouvant au sein du fichier shared-network
mais en dehors des déclarations subnet
sont considérés comme des paramètres globaux. Le nom du fichier shared-network
doit correspondre à un titre descriptif du réseau, comme l'utilisation de 'test-lab' pour décrire tous les réseaux dans un environnement de labo de tests.
shared-network name { option domain-name "test.redhat.com"; option domain-name-servers ns1.redhat.com, ns2.redhat.com; option routers 192.168.0.254; more parameters for EXAMPLE shared-network subnet 192.168.1.0 netmask 255.255.252.0 { parameters for subnet range 192.168.1.1 192.168.1.254; } subnet 192.168.2.0 netmask 255.255.252.0 { parameters for subnet range 192.168.2.1 192.168.2.254; } }
Comme l'illustre l'Exemple 12.3, « Déclaration de groupe », la déclaration group
est utilisée pour appliquer des paramètres globaux à un groupe de déclarations. Vous pouvez, par exemple, regrouper des réseaux partagés, des sous-réseaux et des hôtes.
group { option routers 192.168.1.254; option subnet-mask 255.255.255.0; option domain-name "example.com"; option domain-name-servers 192.168.1.1; option time-offset -18000; # Eastern Standard Time host apex { option host-name "apex.example.com"; hardware ethernet 00:A0:78:8E:9E:AA; fixed-address 192.168.1.4; } host raleigh { option host-name "raleigh.example.com"; hardware ethernet 00:A1:DD:74:C3:F2; fixed-address 192.168.1.6; } }
Pour configurer un serveur DHCP qui attribue une adresse IP dynamique à un système dans un sous-réseau, modifiez l'Exemple 12.4, « Paramètre 'range' » avec vos valeurs spécifiques. Un temps d'attribution par défaut, un temps d'attribution maximum et des valeurs de configuration réseau pour les clients sont déclarés. Cet exemple assigne aux systèmes client, des adresses IP dans la gamme range
192.168.1.10 et 192.168.1.100.
default-lease-time 600; max-lease-time 7200; option subnet-mask 255.255.255.0; option broadcast-address 192.168.1.255; option routers 192.168.1.254; option domain-name-servers 192.168.1.1, 192.168.1.2; option domain-name "example.com"; subnet 192.168.1.0 netmask 255.255.255.0 { range 192.168.1.10 192.168.1.100; }
Pour attribuer une adresse IP à un client sur la base de l'adresse MAC de la carte d'interface réseau, utilisez le paramètre hardware ethernet
dans une déclaration host
. Comme le montre l'Exemple 12.5, « Adresse IP statique utilisant DHCP », la déclaration host apex
indique que la carte d'interface réseau avec l'adresse MAC 00:A0:78:8E:9E:AA doit toujours recevoir l'adresse IP 192.168.1.4.
Notez que vous pouvez également utiliser le paramètre facultatif host-name
pour attribuer un nom d'hôte au client.
host apex { option host-name "apex.example.com"; hardware ethernet 00:A0:78:8E:9E:AA; fixed-address 192.168.1.4; }
Vous pouvez utiliser le fichier de configuration d'exemple comme point de départ, puis y ajouter vos propres options de configuration personnalisées. Copiez-le à l'emplacement approprié à l'aide de la commande :
cp /usr/share/doc/dhcp-<version-number>
/dhcpd.conf.sample /etc/dhcpd.conf
(où <version-number>
correspond à la version DHCP que vous utilisez).
Pour obtenir une liste complète des options et de leur fonction, reportez-vous à la page de manuel relative à dhcp-options
.
Sur le serveur DHCP, le fichier /var/lib/dhcpd/dhcpd.leases
stocke la base de données d'attribution client DHCP. Ne modifiez pas ce fichier. Les informations d'attribution DHCP pour toutes les adresses IP récemment attribuées sont automatiquement stockées dans cette base de données. Ces informations incluent la durée de l'attribution, le destinataire de l'adresse IP, les dates de début et de fin pour l'attribution et l'adresse MAC de la carte d'interface réseau qui a été utilisée pour l'attribution.
Toutes les heures de la base de données d'attribution sont des heures "Coordinated Universal Time" (UTC) et non pas des heures locales.
La base de données d'attribution est recréée de temps en temps de façon à ce que sa taille ne soit pas trop grande. Tout d'abord, toutes les attributions connues sont sauvegardées dans une base de données d'attribution temporaire. Le fichier dhcpd.leases
est renommé dhcpd.leases~
et la base de données d'attribution temporaire est copiée dans dhcpd.leases
.
Le démon DHCP peut être anéanti et le système peut se bloquer après le changement de nom de la base de données d'attribution, mais avant la création du nouveau fichier. Si tel est le cas, le fichier dhcpd.leases
n'existe pas, mais il est nécessaire pour lancer le service. Dans ce cas, ne créez pas de nouveau fichier d'attribution. Si vous le faites, toutes les anciennes attributions seront perdues et cela entraînera de nombreux problèmes. Vous devez dans ce cas changer le nom du fichier de sauvegarde dhcpd.leases~
par dhcpd.leases
, puis lancer le démon.
Le serveur DHCP ne fonctionne pas lorsque vous le démarrez pour la première fois, à moins que le fichier dhcpd.leases
existe préalablement. Si le fichier n'existe pas, utilisez la commande touch /var/lib/dhcpd/dhcpd.leases
pour le créer.
Si le même serveur est également entrain de démarrer BIND comme un serveur DNS, cette étape n'est pas nécessaire car le démarrage du service named
vérifie automatiquement si le fichier dhcpd.leases
existe.
Pour lancer le service DHCP, utilisez la commande /sbin/service dhcpd start
. Pour interrompre le serveur DHCP, utilisez la commande /sbin/service dhcpd stop
.
Si vous avez plusieurs interfaces réseau attachées au système, mais que vous voulez le démarrage du serveur DHCP uniquement sur l'une d'entre elles, vous pouvez configurer le serveur DHCP afin qu'il démarre uniquement sur ce périphérique. Dans /etc/sysconfig/dhcpd
, ajoutez le nom de l'interface à la liste de DHCPDARGS
:
# Options de ligne de commande ici DHCPDARGS=eth0
Cela est utile si vous avez un ordinateur protégé par un pare-feu et doté de deux cartes réseau. L'une d'elles peut être configurée comme client DHCP pour récupérer une adresse IP d'internet. L'autre peut servir de serveur DHCP pour le réseau interne se trouvant derrière le pare-feu. En ne spécifiant que la carte réseau connectée au réseau interne, votre système sera plus sûr puisque les utilisateurs ne pourront pas se connecter au démon par le biais de l'internet.
Options de ligne de commande pouvant être spécifiées dans /etc/sysconfig/dhcpd
:
-p
— Spécifie le numéro de port udp sur lequel <portnum>
dhcpd
devrait être en écoute. Le port par défaut est le 67. Le serveur DHCP transmet les réponses aux clients DHCP à un numéro de port supérieur au port udp spécifié. Par exemple, si vous acceptez le port 67 (port par défaut), le serveur attend sur le port 67 les requêtes et sur le port 68 les réponses au client. Si vous spécifiez un port et que vous utilisez l'agent de relais DHCP, vous devez spécifier le même port d'attente pour l'agent de relais DHCP. Pour obtenir de plus amples informations, reportez-vous à la Section 12.2.4, « Agent de relais DHCP ».
-f
— Exécute le démon comme processus de front. Cette option est principalement utilisée pour le débogage.
-d
— Inscrit le démon du serveur DHCP dans le descripteur d'erreurs standard. Cette option est principalement utilisée pour le débogage. Si elle n'est pas spécifiée, l'inscription est faite dans /var/log/messages
.
-cf
— Spécifie l'emplacement du fichier de configuration, par défaut <filename>
/etc/dhcpd.conf
.
-lf
— Spécifie l'emplacement du fichier de la base de données d'attribution. Si ce fichier existe déjà, il est très important que le même fichier soit utilisé chaque fois que le serveur DHCP est démarré. Il est fortement recommandé de n'utiliser cette option qu'à des fins de débogage sur des machines non productives. L'emplacement par défaut est <filename>
/var/lib/dhcpd/dhcpd.leases
.
-q
— N'imprime pas l'intégralité du message de copyright au démarrage du démon.
L'agent de relais DHCP (dhcrelay
) vous permet de relayer les requêtes DHCP et BOOTP d'un sous-réseau ne disposant pas de serveur DHCP vers un ou plusieurs serveurs DHCP sur d'autres sous-réseaux.
Lorsqu'un client DHCP demande des informations, l'agent de relais DHCP transfère la requête à la liste des serveurs DHCP spécifiés lors du démarrage de l'agent de relais DHCP. Lorsqu'un serveur DHCP renvoie une réponse, la réponse est diffusée sur le réseau ayant envoyé la requête d'origine.
L'agent de relais DHCP attend les requêtes DHCP sur toutes les interfaces à moins que les interfaces ne soient spécifiées dans /etc/sysconfig/dhcrelay
avec la directive INTERFACES
.
Pour démarrer l'agent de relais DHCP, utilisez la commande service dhcrelay start
.
Pour configurer manuellement un client DHCP, vous devez modifier le fichier /etc/sysconfig/network
afin d'activer la mise en réseau et le fichier de configuration pour chacun des périphériques réseau dans le répertoire /etc/sysconfig/network-scripts
. Dans ce répertoire, chaque périphérique doit disposer d'un fichier de configuration nommé ifcfg-eth0
, eth0
correspondant au nom du périphérique réseau.
Le fichier /etc/sysconfig/network
doit contenir la ligne suivante :
NETWORKING=yes
La variable NETWORKING
doit être réglée sur yes
pour que la mise en réseau soit activée au démarrage.
Le fichier /etc/sysconfig/network-scripts/ifcfg-eth0
doit contenir les lignes ci-dessous :
DEVICE=eth0 BOOTPROTO=dhcp ONBOOT=yes
Il vous faut un fichier de configuration pour chacun des périphériques que vous souhaitez configurer afin d'utiliser DHCP.
Voici d'autres options pour le script réseau :
DHCP_HOSTNAME
— N'utilisez cette option que si le serveur DHCP nécessite que le client spécifie le nom d'hôte avant de recevoir une adresse IP (Le démon du serveur DHCP dans Red Hat Enterprise Linux ne prend pas en charge cette fonction).
PEERDNS=
, où <answer>
figure parmi :
<answer>
yes
— Modifie /etc/resolv.conf
avec les informations du serveur. Si vous utilisez DHCP, yes
est alors la valeur par défaut.
no
— Ne modifie pas /etc/resolv.conf
.
SRCADDR=
, où <address>
est l'adresse IP source spécifiée pour les paquets sortants.
<address>
USERCTL=
, où <answer>
figure parmi :
<answer>
yes
— Les utilisateurs autres que le super-utilisateur sont autorisés à contrôler ce périphérique.
no
— Les utilisateurs autres que le super-utilisateur ne sont pas autorisés à contrôler ce périphérique.
Si vous préférez utiliser une interface graphique pour la configuration d'un client DHCP, reportez-vous au Chapitre 6, Configuration réseau pour obtenir des instructions sur l'utilisation de l'Outil d'Administration Réseau permettant de configurer une interface réseau qui utilisera DHCP.
Pour obtenir des options avancées sur les configurations du client DHCP comme par exemple le protocole de temps, les pré-requis et requêtes de bail, le support dynamique DNS, les alias, ainsi qu'une grande variété de valeurs à écraser, préfixer ou ajouter aux configurations côté client, reportez-vous aux manuels dhclient
et dhclient.conf
.
Pour des options de configuration supplémentaires, veuillez vous reporter aux ressources suivantes.
La page de manuel relative à dhcpd
— Décrit le fonctionnement du démon DHCP.
La page de manuel relative à dhcpd.conf
— Explique comment configurer le fichier de configuration DHCP et fournit des exemples.
La page de manuel relative à dhcpd.leases
— Explique comment configurer le fichier d'attribution DHCP et fournit des exemples.
La page de manuel relative à dhcp-options
— Explique la syntaxe de déclaration des options DHCP dans dhcpd.conf
et fournit des exemples.
La page de manuel relative à dhcrelay
— Explique le fonctionnement de l'agent de relais DHCP et les options de configuration correspondantes.
/usr/share/doc/dhcp-<
— Contient des fichiers d'exemple, des fichiers README et des notes de mise à jour pour les versions courantes du service DHCP.
version
>/
httpd
httpd.conf
Le serveur HTTP Apache est un serveur Web Open Source robuste de niveau commercial qui a été développé par l'organisation Apache Software Foundation (http://www.apache.org/). Red Hat Enterprise Linux comprend le serveur HTTP Apache version 2.2 ainsi que de nombreux modules serveur conçus pour améliorer sa fonctionnalité.
Le fichier de configuration par défaut installé avec le Serveur HTTP Apache fonctionne dans la plupart des situations sans devoir être modifié. Ce chapitre décrit brièvement de nombreuses directives présentes dans son fichier de configuration (à savoir /etc/httpd/conf/httpd.conf
) pour aider les utilisateurs nécessitant une configuration personnalisée ou devant convertir un fichier de configuration dans l'ancien format 1.3 du Serveur HTTP Apache.
Si vous utilisez l'outil graphique HTTP Configuration Tool (system-config-httpd), n'éditez pas manuellement le fichier de configuration du Serveur HTTP Apache car l'HTTP Configuration Tool crée une nouvelle version de ce fichier chaque fois qu'il est utilisé.
Il existe des différences importantes entre la version 2.2 et la version 2.0 du Serveur HTTP Apache (la version 2.0 faisait partie de la version 4 de Red Hat Enterprise Linux et les versions précédentes). Cette section passe en revue certaines des nouvelles fonctionnalités du Serveur HTTP Apache 2.2 et souligne des changements importants. Si vous effectuez une migration depuis la version 1.3, vous devriez lire les instructions sur la migration d'une version 1.3 vers 2.0. Pour obtenir des informations sur la migration d'un fichier de configuration version 1.3 vers le format 2.0, reportez-vous à la Section 13.2.2, « Migration des fichiers de configuration du Serveur HTTP Apache version 1.3 vers 2.0 ».
La version 2.2 du Serveur HTTP Apache inclut les fonctionnalités suivantes :
Amélioration des modules de mise en cache (mod_cache, mod_disk_cache, mod_mem_cache).
Une nouvelle structure pour le support d'authentification et d'autorisation, remplaçant les modules d'authentification fournis dans les versions précédentes.
Le support pour la répartition de charge du proxy (mod_proxy_balancer).
Le support pour le traitement de gros fichiers (c'est-à-dire, plus gros que 2Go) sur des plateformes 32 bit.
Les changements suivants ont été apportés à la configuration httpd par défaut :
Les modules mod_cern_meta et mod_asis ne sont plus chargés par défaut.
Le module mod_ext_filter est maintenant chargé par défaut.
Lors de la mise à niveau à partir d'une version précédente de Red Hat Enterprise Linux, la configuration httpd a besoin d'être mise à jour pour httpd 2.2. Pour davantage d'informations, reportez-vous à l'adresse suivante : http://httpd.apache.org/docs/2.2/upgrading.html
Cette section explique la migration à partir de la version 2.0 vers la version 2.2. Si vous migrez depuis la version 1.3, veuillez vous reportez à la Section 13.2.2, « Migration des fichiers de configuration du Serveur HTTP Apache version 1.3 vers 2.0 ».
Les fichiers de configuration et les scripts de démarrage de la version 2.0 nécessitent quelques changements mineurs en particulier au niveau des noms de modules qui ont changé. Les modules tiers qui fonctionnent avec la version 2.0 peuvent également fonctionner avec la version 2.2 mais ils doivent être recompilés avant que vous puissiez les charger. Les modules clés qui ont besoin d'être notés sont les modules d'authentification et d'autorisation. Pour chaque module qui a été renommé, la ligne LoadModule
doit être mise à jour.
Le module mod_userdir
agira uniquement sur les requêtes si vous fournissez une directive UserDir
indiquant le nom d'un répertoire. Si vous désirez maintenir les procédures utilisées dans la version 2.0, ajoutez la directive UserDir public_html
dans votre fichier de configuration.
Pour activer SSL, modifiez le fichier httpd.conf
en ajoutant les directives mod_ssl
nécessaires. Utilisez apachectl start
car apachectl startssl
n'est pas disponible dans la version 2.2. Vous pouvez voir un exemple de configuration SSL pour httpd dans le fichier conf/extra/httpd-ssl.conf
.
Pour tester votre configuration, nous vous recommandons d'utiliser service httpd configtest
afin de détecter les erreurs de configuration.
Une liste plus complète des changements est disponible en ligne à l'adresse suivante : http://httpd.apache.org/docs/2.2/upgrading.html.
Cette section présente la migration d'un fichier de configuration du Serveur HTTP Apache version 1.3 en vue d'une utilisation par le Serveur HTTP Apache 2.0.
Lors d'une mise à niveau de la version 2.1 de Red Hat Enterprise Linux à Red Hat Enterprise Linux 5.0.0, il est important de noter que le nouveau fichier de configuration pour le paquetage du Serveur HTTP Apache 2.0 sera installé sous /etc/httpd/conf/httpd.conf.rpmnew
et que la version originale 1.3 httpd.conf
ne sera pas modifiée. Bien sûr, il vous appartient entièrement de choisir entre l'utilisation du nouveau fichier de configuration vers lequel les anciens paramètres seront migrés et l'utilisation du fichier existant comme base et d'y apporter des modifications pour qu'il reflète vos besoins ; cependant, certaines parties du fichier ayant été plus modifiées que d'autres, une approche mixte est généralement préférable. Les fichiers de configuration pour les versions 1.3 et 2.0 sont divisés en trois sections.
Si le fichier /etc/httpd/conf/httpd.conf
est une version modifiée de la version par défaut nouvellement installée et qu'une copie sauvegardée du fichier original est disponible, il sera peut-être plus simple d'invoquer la commande diff
comme dans l'exemple suivant (en étant connecté en tant que super-utilisateur) :
diff -u httpd.conf.orig httpd.conf | less
Cette commande soulignera toutes les modifications apportées. Si une copie du fichier original n'est pas disponible, vous devrez l'extraire du paquetage RPM en utilisant les commandes rpm2cpio
et cpio
, comme dans l'exemple suivant :
rpm2cpio apache-<version-number>
.i386.rpm | cpio -i --make
Dans la commande ci-dessous, remplacez <version-number>
par le numéro de version du paquetage apache
.
Enfin, il est utile de savoir que le Serveur HTTP Apache dispose d'un mode test qui permet de trouver les erreurs de configuration. Pour y accéder, saisissez la commande suivante :
apachectl configtest
La section intitulée Environnement global (Global Environment) du fichier de configuration contient des directives qui modifient tout le fonctionnement du Serveur HTTP Apache, comme par exemple, le nombre de requêtes simultanées qu'il peut traiter et les emplacements des divers fichiers. Cette section nécessite un grand nombre de changements et doit être basée sur le fichier de configuration du Serveur HTTP Apache version 2.0 vers lequel tous les anciens paramètres devront être migrés.
Les directives BindAddress
et Port
n'existent plus ; leur fonctionnalité est désormais fournie par une directive plus flexible nommée Listen
.
Si le Port 80
figurait dans les paramètres du fichier de configuration version 1.3, il est nécessaire de le remplacer par Listen 80
dans le fichier de configuration en version 2.0. Si Port
avait une valeur autre que 80, il est nécessaire d'ajouter le numéro du port au contenu de la directive ServerName
.
L'extrait ci-dessous représente un exemple de directive du Serveur HTTP Apache version 1.3 :
Port 123 ServerName www.example.com
Pour transférer ce paramètre vers le Serveur HTTP Apache 2.0, utilisez la structure suivante :
Listen
123 ServerName www.example.com:123
Pour obtenir davantage d'informations sur le sujet, reportez-vous à la documentation de l'organisation Apache Software Foundation disponible sur le site Web à :
Lorsque le Serveur HTTP Apache accepte les requêtes, il envoie des processus enfants ou des threads pour les traiter. Ce groupe de processus enfants ou de threads (aussi appelés fils) est appelé un server-pool (groupe de serveurs). Avec la version 2.0 du Serveur HTTP Apache, la responsabilité de la création et de la maintenance de ces groupes dépend d'un groupe de modules appelés Modules multitâche (ou MPM, de l'anglais Multi-Processing Modules). Contrairement à d'autres modules, seul un module du groupe MPM peut être chargé par le Serveur HTTP Apache. Trois modules MPM sont inclus dans la version 2.0, à savoir, prefork
, worker
et perchild
. Actuellement, seuls les MPM prefork
et worker
sont disponibles, mais il se peut que le MPM perchild
soit disponible dans le futur.
Le comportement original du Serveur HTTP Apache 1.3 a été déplacé dans le MPM prefork
. Ce dernier accepte les mêmes directives que le Serveur HTTP Apache version 1.3, il est donc possible de migrer les directives suivantes :
StartServers
MinSpareServers
MaxSpareServers
MaxClients
MaxRequestsPerChild
Le MPM worker
implémente un serveur multi-processus, multi-thread offrant une modulabilité plus importante. Lors de l'utilisation de ce MPM, les requêtes sont manipulées par des threads (ou fils) économisant donc les ressources système et permettant ainsi à un grand nombre de requêtes d'être servi de façon efficace. Bien que certaines directives acceptées par le MPM worker
soient les mêmes que celles acceptées par le MPM prefork
, les valeurs de ces directives ne devraient pas être transférées directement depuis une installation de Serveur HTTP Apache 1.3. Il vaut mieux utiliser les valeurs par défaut comme des recommandations et les essayer ensuite afin de déterminer celles qui fonctionnent le mieux.
Pour utiliser le MPM worker
, créez le fichier /etc/sysconfig/httpd
et ajoutez-y la directive suivante :
HTTPD=/usr/sbin/httpd.worker
Pour obtenir davantage d'informations sur le sujet, reportez-vous à la documentation de l'organisation Apache Software Foundation disponible sur le site Web à :
Un grand nombre de changements étant nécessaire ici, il est vivement recommandé à toute personne essayant de modifier une configuration du Serveur HTTP Apache version 1.3 pour l'adapter à la version 2.0 (au lieu de migrer les changements vers la configuration version 2.0) de copier cette section du fichier de configuration Serveur HTTP Apache 2.0.
Les utilisateurs ne souhaitant pas copier la section de la configuration du Serveur HTTP Apache version 2.0 devraient prendre note des informations suivantes :
Les directives AddModule
et ClearModuleList
n'existent plus. Elles étaient utilisées pour assurer l'activation des modules dans la bon ordre. L'API du Serveur HTTP Apache 2.0 permet aux modules de préciser leur d'activation, éliminant ainsi la raison d'être de ces deux directives.
L'ordre des lignes de LoadModule
n'est désormais plus important dans la plupart des cas.
De nombreux modules ont été ajoutés, supprimés, renommés, divisés ou incorporés les uns aux autres.
Les lignes LoadModule
des modules intégrés dans leurs propres RPM (mod_ssl
, php
, mod_perl
et autres) ne sont plus nécessaires puisqu'elles se trouvent dans leur fichier propre inclus dans le répertoire /etc/httpd/conf.d/
.
Les diverses définitions HAVE_XXX
ne sont plus définies.
Lors de la modification du fichier original, notez que le fichier httpd.conf
doit absolument contenir la directive suivante :
Include conf.d/*.conf
L'oubli de cette directive entraînerait l'échec de tous les modules contenus dans leurs propres RPM (tels que mod_perl
, php
et mod_ssl
).
Les directives suivantes ont été supprimées de la configuration du Serveur HTTP Apache 2.0 :
ServerType
— Le Serveur HTTP Apache ne peut être exécuté qu'en tant que ServerType standalone
, rendant ainsi cette directive inutile.
AccessConfig
et ResourceConfig
— Ces directives ont été supprimées puisqu'elles reflétaient la fonctionnalité de la directive Include
. Si les directives AccessConfig
et ResourceConfig
sont définies, il est nécessaire de les remplacer par des directives Include
.
Pour obtenir l'assurance que les fichiers seront lus dans l'ordre désigné par les anciennes directives, il est nécessaire de placer les directives Include
à la fin du fichier httpd.conf
, en prenant bien soin de placer celle correspondant à ResourceConfig
avant celle correspondant à AccessConfig
. Si les valeurs par défaut sont utilisées, elles doivent être incluses explicitement dans les fichiers conf/srm.conf
et conf/access.conf
.
La section relative à la configuration du serveur principal du fichier de configuration installe le serveur principal qui répond à toute les requêtes non-traitées par un hôte virtuel définit dans un conteneur <VirtualHost>
. Des valeurs spécifiées ici offrent aussi des valeurs par défaut pour tous les fichiers conteneurs <VirtualHost>
définis.
Les directives utilisées dans cette section ont été légèrement modifiées entre la version 1.3 du Serveur HTTP Apache et la version 2.0. Si la configuration du serveur principal a un niveau élevé de personnalisation, il sera peut-être plus simple de modifier le fichier de configuration existant pour l'adapter au Serveur HTTP Apache 2.0. Les utilisateurs ayant une configuration peu personnalisée devraient migrer leurs changements vers la configuration 2.0 par défaut.
La directive UserDir
est utilisée pour permettre à des URL telles que http://example.com/~bob/
de se mapper à un sous-répertoire au sein du répertoire personnel de l'utilisateur bob
, comme par exemple /home/bob/public_html
. Cette particularité permettant à un éventuel agresseur de déterminer si un nom d'utilisateur donné est présent sur le système, la configuration par défaut pour le Serveur HTTP Apache 2.0 désactive cette directive.
Pour activer le mappage de UserDir
, changez la directive figurant dans le fichier httpd.conf
de :
UserDir disable
à :
UserDir public_html
Pour obtenir davantage d'informations sur le sujet, reportez-vous à la documentation de l'organisation Apache Software Foundation disponible sur le site Web à :
Les directives de journalisation suivantes ont été supprimées :
AgentLog
RefererLog
RefererIgnore
Cependant, les journaux Agent et Referrer sont encore disponibles en utilisant les directives CustomLog
et LogFormat
.
Pour obtenir davantage d'informations sur le sujet, reportez-vous à la documentation de l'organisation Apache Software Foundation disponible sur le site Web à :
La directive FancyIndexing
étant désormais obsolète a été supprimée. Cette même fonctionnalité est toutefois encore disponible par le biais de l'option FancyIndexing
à l'intérieur de la directive IndexOptions
.
La nouvelle option VersionSort
appliquée à la directive IndexOptions
permet de classer dans un ordre plus naturel les fichiers contenant des numéros de version. Par exemple, httpd-2.0.6.tar
apparaît avant httpd-2.0.36.tar
dans une page d'index de répertoires.
Les paramètres par défaut pour les directives ReadmeName
et HeaderName
ont été transférés des fichiers README
et HEADER
vers les fichiers README.html
et HEADER.html
.
Pour obtenir davantage d'informations sur le sujet, reportez-vous à la documentation de l'organisation Apache Software Foundation disponible sur le site Web à :
La directive CacheNegotiatedDocs
retient désormais les critères on
ou off
. Les cas existants de CacheNegotiatedDocs
devront être remplacés par CacheNegotiatedDocs on
.
Pour obtenir davantage d'informations sur le sujet, reportez-vous à la documentation de l'organisation Apache Software Foundation disponible sur le site Web à :
Afin de pouvoir utiliser un message codé en dur avec la directive ErrorDocument
, le message doit apparaître entre guillemets ("
), plutôt que d'être seulement précédé par des guillemets, comme c'était la cas avec le Serveur HTTP Apache 1.3.
L'extrait ci-dessous représente un exemple de directive du Serveur HTTP Apache version 1.3 :
ErrorDocument 404 "The document was not found
Pour transférer un paramètre ErrorDocument
vers le Serveur HTTP Apache 2.0, utilisez la structure suivante :
ErrorDocument 404 "The document was not found"
Notez bien la présence des guillemets à la fin de l'exemple de directive ErrorDocument
reproduit ci-dessus.
Pour obtenir davantage d'informations sur le sujet, reportez-vous à la documentation de l'organisation Apache Software Foundation disponible sur le site Web à :
Le contenu de tous les répertoires <VirtualHost>
devrait être migré de la même manière que celle utilisée pour la section du serveur principal ; reportez-vous à la Section 13.2.2.2, « Configuration du serveur principal » pour obtenir des instructions sur le sujet.
Notez que la configuration d'un hôte virtuel SSL/TLS a été supprimée du fichier de configuration du serveur principal pour être ajoutée dans le fichier /etc/httpd/conf.d/ssl.conf
.
Dans la version 2.0 du Serveur HTTP Apache, le système de modules a été modifié afin de permettre aux modules d'être désormais liés ensemble ou combinés de plusieurs manières différentes. Les scripts CGI (de l'anglais Common Gateway Interface) par exemple, sont capables de générer des documents HTML analysés par le serveur qui peuvent ensuite être traités par mod_include
. Grâce à ce développement, il existe désormais de nombreuses possibilités de combinaison des modules afin d'atteindre un objectif spécifique.
Cette situation est possible car chaque requête est servie par un seul module handler, suivi d'aucun ou de plusieurs modules filter.
Sous la version 1.3 du Serveur HTTP Apache par exemple, un script Perl serait traité dans son intégralité par le module Perl (mod_perl
). Sous la version 2.0 du Serveur HTTP Apache, en revanche, la requête est initialement traitée par le module principal — qui sert des fichiers statiques — et est ensuite filtrée par mod_perl
.
L'explication exacte de l'utilisation de cette fonction particulière et de toutes les autres nouvelles fonctions du Serveur HTTP Apache 2.0, va bien au-delà de la portée de ce document ; toutefois, la conversion a des ramifications non-négligeables si vous avez utilisé la directive PATH_INFO
pour un document traité par un module qui est désormais traité comme un filtre étant donné que chaque directive contient des informations de chemin peu importantes après le vrai nom de fichier. Le module mémoire, qui traite initialement la requête, ne comprend pas par défaut PATH_INFO
et renverra des erreurs de types 404 Not Found
pour les requêtes qui contiennent de telles informations. Vous pouvez également utiliser la directive AcceptPathInfo
pour obliger le module mémoire à accepter les requêtes contenant PATH_INFO
.
Ci-dessous figure un exemple de cette directive :
AcceptPathInfo on
Pour obtenir davantage d'informations sur le sujet, reportez-vous à la documentation de l'organisation Apache Software Foundation disponible sur le site Web à :
Dans la version du Serveur HTTP Apache 2.0, le module mod_suexec
utilise la directive SuexecUserGroup
(plutôt que les directives User
et Group
) pour la configuration des hôtes virtuels. Les directives User
et Group
peuvent toujours être utilisées d'une manière générale mais ne peuvent plus être utilisées pour la configuration des hôtes virtuels.
L'extrait ci-dessous représente un exemple de directive du Serveur HTTP Apache version 1.3 :
<VirtualHost vhost.example.com:80> User someone Group somegroup </VirtualHost>
Pour transférer ce paramètre vers le Serveur HTTP Apache 2.0, utilisez la structure suivante :
<VirtualHost vhost.example.com:80> SuexecUserGroup someone somegroup </VirtualHost>
La configuration de mod_ssl
a été transférée du fichier httpd.conf
au fichier /etc/httpd/conf.d/ssl.conf
. Pour que ce dernier soit chargé et que mod_ssl
puisse fonctionner, la déclaration Include conf.d/*.conf
doit figurer dans le fichier httpd.conf
, comme l'explique la Section 13.2.2.1.3, « Prise en charge de DSO (Dynamic Shared Object) ».
Les directives ServerName
dans les hôtes virtuels avec SSL doivent explicitement spécifier le numéro de port.
L'extrait ci-dessous représente un exemple de directive du Serveur HTTP Apache version 1.3 :
<VirtualHost _default_:443> # General setup for the virtual host ServerName ssl.example.name ... </VirtualHost>
Pour transférer ce paramètre vers le Serveur HTTP Apache 2.0, utilisez la structure suivante :
<VirtualHost _default_:443> # General setup for the virtual host ServerName ssl.host.name:443
... </VirtualHost>
Il est également important de noter que les deux directives SSLLog
et SSLLogLevel
ont été supprimées. Le module mod_ssl
obéit désormais aux directives ErrorLog
et LogLevel
. Reportez-vous à ErrorLog et à LogLevel pour obtenir de plus amples informations sur ces directives.
Pour obtenir davantage d'informations sur le sujet, reportez-vous à la documentation de l'organisation Apache Software Foundation disponible sur le site Web à :
Les instructions relatives au contrôle de l'accès proxy sont maintenant placées dans un bloc <Proxy>
plutôt que dans un répertoire <Directory proxy:>
.
La fonctionnalité de stockage temporaire de l'ancien mod_proxy
a été divisée en trois modules, à savoir :
mod_cache
mod_disk_cache
mod_mem_cache
Ceux-ci utilisent généralement des directives similaires aux versions plus anciennes du module mod_proxy
. Il est cependant conseillé de vérifier chaque directive avant de migrer tout paramètre de cache.
Pour obtenir davantage d'informations sur le sujet, reportez-vous à la documentation de l'organisation Apache Software Foundation disponible sur le site Web à :
Le module mod_include
fonctionnant désormais comme un filtre, il est activé d'une façon différente. Reportez-vous à la Section 13.2.2.4, « Modules et Serveur HTTP Apache 2.0 » pour obtenir de plus amples informations sur les filtres.
L'extrait ci-dessous représente un exemple de directive du Serveur HTTP Apache version 1.3 :
AddType text/html .shtml AddHandler server-parsed .shtml
Pour transférer ce paramètre vers le Serveur HTTP Apache 2.0, utilisez la structure suivante :
AddType text/html .shtml AddOutputFilter INCLUDES
.shtml
Notez que, comme auparavant, la directive Options +Includes
est toujours nécessaire pour le conteneur <Directory>
ou dans un fichier .htaccess
.
Pour obtenir davantage d'informations sur le sujet, reportez-vous à la documentation de l'organisation Apache Software Foundation disponible sur le site Web à :
Le Serveur HTTP Apache 1.3 prenait en charge deux modules d'authentification, à savoir, mod_auth_db
et mod_auth_dbm
, qui utilisaient respectivement les bases de données Berkeley et DBM. Ces modules ont été rassemblés dans un seul module nommé mod_auth_dbm
dans la version 2.0 du Serveur HTTP Apache, pouvant accéder à plusieurs formats de base de données différents. Pour effectuer une migration depuis le fichier mod_auth_db
, il est nécessaire de modifier les fichiers de configuration en remplaçant AuthDBUserFile
et AuthDBGroupFile
par les équivalents de mod_auth_dbm
à savoir AuthDBMUserFile
et AuthDBMGroupFile
. Il est également nécessaire d'ajouter la directive AuthDBMType DB
pour préciser le type de fichier de base de données utilisé.
Ci-dessous figure un exemple de configuration mod_auth_db
pour le Serveur HTTP Apache 1.3 :
<Location /private/> AuthType Basic AuthName "My Private Files" AuthDBUserFile /var/www/authdb require valid-user </Location>
Pour transférer ce paramètre vers la version 2.0 du Serveur HTTP Apache, utilisez la structure suivante :
<Location /private/> AuthType Basic AuthName "My Private Files" AuthDBMUserFile
/var/www/authdb AuthDBMType DB
require valid-user </Location>
Notez que la directive AuthDBMUserFile
peut également être utilisée dans des fichiers .htaccess
.
Dans la version 2.0 du Serveur HTTP Apache, le script Perl dbmmanage
utilisé pour manipuler les bases de données des noms d'utilisateur et mots de passe a été remplacé par htdbm
. Le programme htdbm
offre des fonctionnalités équivalentes et, tout comme le module mod_auth_dbm
, peut exploiter une grande variété de formats de bases de données ; l'option -T
peut être utilisée sur la ligne de commande pour spécifier le format à utiliser.
Tableau 13.1, « Migration de dbmmanage
vers htdbm
» montre comment migrer d'un format de base de données DBM vers htdbm
en utilisant dbmmanage
.
Action | Commande dbmmanage (1.3) | Équivalent de la commande htdbm (2.0) |
---|---|---|
Ajoute l'utilisateur à la base de données (en utilisant le mot de passe donné) |
dbmmanage authdb add username password
|
htdbm -b -TDB authdb username password
|
Ajoute l'utilisateur à la base de données (invite à fournir le mot de passe) |
dbmmanage authdb adduser username
|
htdbm -TDB authdb username
|
Retire l'utilisateur de la base de données |
dbmmanage authdb delete username
|
htdbm -x -TDB authdb username
|
Répertorie les utilisateurs dans la base de données |
dbmmanage authdb view
|
htdbm -l -TDB authdb
|
Vérifie un mot de passe |
dbmmanage authdb check username
|
htdbm -v -TDB authdb username
|
dbmmanage
vers htdbm
Les options -m
et -s
fonctionnant avec dbmmanage
et htdbm
, il est possible d'utiliser les algorithmes MD5 ou SHA1 respectivement, pour le hachage des mots de passe.
Lors de la création d'une nouvelle base de données avec htdbm
, il est nécessaire d'utiliser l'option -c
.
Pour obtenir davantage d'informations sur le sujet, reportez-vous à la documentation de l'organisation Apache Software Foundation disponible sur le site Web à :
La configuration du module mod_perl
a été transférée du fichier httpd.conf
au fichier /etc/httpd/conf.d/perl.conf
. Pour que ce fichier soit chargé et permette ainsi à mod_perl
de fonctionner correctement, la déclaration Include conf.d/*.conf
doit figurer dans le fichier httpd.conf
, comme le décrit la Section 13.2.2.1.3, « Prise en charge de DSO (Dynamic Shared Object) ».
Les occurrences de Apache::
contenues dans votre fichier httpd.conf
doivent être remplacées par ModPerl::
. En outre, la façon dont les gestionnaires de signaux (ou handlers) sont enregistrés a été modifiée.
Ci-dessous figure un exemple de la configuration du Serveur HTTP Apache 1.3 pour le module mod_perl
:
<Directory /var/www/perl> SetHandler perl-script PerlHandler Apache::Registry Options +ExecCGI </Directory>
Ci-après se trouve le module mod_perl
équivalent pour la version 2.0 du Serveur HTTP Apache :
<Directory /var/www/perl> SetHandler perl-script PerlResponseHandler ModPerl::Registry
Options +ExecCGI </Directory>
La plupart des modules pour mod_perl
1.x devraient fonctionner sans modification, avec mod_perl
2.x. Les modules XS nécessitent une recompilation et des modifications mineures de Makefile seront peut-être également nécessaires.
La configuration du module mod_python
a été transférée du fichier httpd.conf
au fichier /etc/httpd/conf.d/python.conf
. Pour que ce dernier soit chargé et permette ainsi à mod_python
de fonctionner correctement, la déclaration Include conf.d/*.conf
doit figurer dans le fichier httpd.conf
comme le décrit la Section 13.2.2.1.3, « Prise en charge de DSO (Dynamic Shared Object) ».
La configuration de PHP a été transférée du fichier httpd.conf
au fichier /etc/httpd/conf.d/php.conf
. Pour que celui-ci soit chargé, la déclaration Include conf.d/*.conf
doit figurer dans le fichier httpd.conf
, comme le décrit la Section 13.2.2.1.3, « Prise en charge de DSO (Dynamic Shared Object) ».
Toutes les directives de configuration de PHP utilisées avec le Serveur HTTP Apache 1.3 sont désormais entièrement compatibles, lors de la migration vers le Serveur HTTP Apache 2.0 sur Red Hat Enterprise Linux 5.0.0.
Dans PHP 4.2.0 et les versions postérieures, l'ensemble des variables par défaut qui sont prédéfinies et ont généralement une portée globale, a changé. Les variables d'entrée individuelle et les variables de serveur ne sont plus, par défaut, directement placées dans la portée globale. Ce changement risque d'interrompre les scripts. Revenez à l'ancien comportement en réglant register_globals
sur On
dans le fichier /etc/php.ini
.
Pour obtenir davantage d'informations sur le sujet et pour obtenir des renseignements détaillés sur les changements au niveau de la portée globale, reportez-vous à l'URL suivante :
Red Hat Enterprise Linux est fournit avec le module mod_authz_ldap
pour le Serveur HTTP Apache. Ce module utilise le nom raccourci du nom distinct (ou distinguished name) d'un sujet et de l'émetteur du certificat SSL client afin de déterminer le nom distinct de l'utilisateur au sein d'un répertoire LDAP. Il est également à même d'effectuer les tâches suivantes : autoriser un utilisateur en fonction des attributs de l'entrée du répertoire LDAP de cet utilisateur, déterminer l'accès aux ressources en fonction des privilèges octroyés aux utilisateurs et aux groupes quant à ces ressources et peut également refuser l'accès aux utilisateurs dont le mot de passe a expiré. Le module mod_ssl
est nécessaire lorsque le module mod_authz_ldap
est utilisé.
Le module mod_authz_ldap
n'effectue pas l'authentification d'un utilisateur par rapport à un répertoire LDAP au moyen d'un hachage de mots de passe cryptés. Cette fonctionnalité est fournie par le module expérimental mod_auth_ldap
qui ne fait pas partie de Red Hat Enterprise Linux. Pour obtenir de plus amples informations sur le statut de ce module, reportez-vous au site Web de l'organisation Apache Software Foundation qui se trouve à l'adresse suivante : http://www.apache.org/.
Le fichier /etc/httpd/conf.d/authz_ldap.conf
configure le module mod_authz_ldap
.
Pour obtenir de plus amples informations sur la configuration du module tiers mod_authz_ldap
, reportez-vous au fichier /usr/share/doc/mod_authz_ldap-
(en prenant soin de remplacer <version>
/index.html<version>
par le numéro de version du paquetage).
Après l'installation du paquetage httpd
, passez en revue la documentation du Serveur HTTP Apache disponible en ligne à l'adresse suivante : http://httpd.apache.org/docs/2.2/.
Le RPM httpd
installe le script /etc/init.d/httpd
qui est accessible à l'aide de la commande /sbin/service
.
Le démarrage de httpd
en utilisant le script de contrôle apachectl
permet de configurer les variables d'environnement dans /etc/sysconfig/httpd
et de démarrer httpd
. Vous pouvez également configurer les variables d'environnement en utilisant le script init.
Pour démarrer le serveur en utilisant le script de contrôle apachectl
en tant que super-utilisateur :
apachectl start
Vous pouvez également démarrer httpd
en utilisant /sbin/service httpd start
. Cela démarre httpd
mais ne définit pas les variables d'environnement. Si vous utilisez la directive par défaut Listen
dans le fichier httpd.conf
, qui correspond au port 80, vous aurez besoin des privilèges super-utilisateur pour démarrer le serveur Apache.
Pour arrêter le serveur, saisissez la commande suivante en étant connecté en tant que super-utilisateur :
apachectl stop
Vous pouvez également arrêter httpd
en utilisant /sbin/service httpd stop
. L'option restart
est une façon rapide d'arrêter et de redémarrer le Serveur HTTP Apache.
Pour redémarrer le serveur, saisissez la commande suivante en étant connecté en tant que super-utilisateur :
apachectl restart
ou:/sbin/service httpd restart
Apache affichera un message sur la console ou dans le journal ErrorLog
s'il rencontre une erreur pendant le démarrage.
Par défaut, le service httpd
n'est pas lancé automatiquement au démarrage. Si vous voulez que Apache démarre, vous devrez ajouter un appel à apachectl
dans vos fichiers de démarrage situés dans le répertoire rc.N
. Une fichier généralement utilisé est rc.local
. Étant donné que Apache sera démarré avec les privilèges du super-utilisateur, nous vous recommandons de configurer correctement la sécurité et l'authentification avant d'ajouter cet appel.
Pour configurer le service httpd
de manière à ce qu'il soit lancé au démarrage, utilisez un utilitaire de script d'initialisation (ou initscript) tel que /sbin/chkconfig
, /usr/sbin/ntsysv ou l'Outil de configuration des services.
Vous pouvez également afficher le statut de votre serveur httpd en saisissant :
apachectl status
Afin que cela puisse fonctionner, le module de statut mod_status
doit être activé dans votre fichier de configuration httpd.conf
. Pour obtenir davantage d'informations sur le module mod_status
, reportez-vous à la documentation disponible en ligne à l'adresse suivante : http://httpd.apache.org/docs/2.2/mod/mod_status.html.
Lors de l'exécution du Serveur HTTP Apache en tant que serveur sécurisé, le mot de passe de ce dernier doit être saisi après le démarrage de l'ordinateur lorsqu'une clé SSL privée et cryptée est utilisée.
Vous trouverez davantage d'informations à l'adresse suivante : http://httpd.apache.org/docs/2.2/ssl
L'Outil de configuration HTTP vous permet de configurer le fichier de configuration /etc/httpd/conf/httpd.conf
pour le Serveur HTTP Apache. Il n'utilise pas les anciens fichiers de configuration srm.conf
ou access.conf
; vous pouvez donc les laisser vides. Il est possible, à partir de l'interface graphique, de configurer des directives telles que des hôtes virtuels, des attributs de journalisation ou encore un nombre maximal de connexions. Pour démarrer l'Outil de configuration HTTP, cliquez sur Système => Administration => Paramètres de serveur => HTTP
.
Seuls les modules fournis avec Red Hat Enterprise Linux peuvent être configurés avec l'Outil de configuration HTTP. Si des modules supplémentaires sont installés, ils ne peuvent pas être configurés en utilisant cet outil.
Ne modifiez pas le fichier de configuration /etc/httpd/conf/httpd.conf
manuellement si vous utilisez cet outil. L'Outil de configuration HTTP génère ce fichier après que vous ayez enregistré vos changements et quitté le programme. Si vous désirez ajouter des modules supplémentaires ou des options de configuration qui ne sont pas disponibles via l'Outil de configuration HTTP, vous ne pouvez pas utiliser cet outil.
Voici les étapes principales pour configurer le Serveur HTTP Apache en utilisant l'Outil de configuration HTTP :
Configurez les paramètres de base sous l'onglet Principal.
Cliquez sur l'onglet Hôtes virtuels et configurez les paramètres par défaut.
Sous l'onglet Hôtes virtuels, configurez l'hôte virtuel par défaut.
Si vous souhaitez servir plusieurs URL ou hôtes virtuels, ajoutez les hôtes virtuels supplémentaires.
Configurez les paramètres du serveur sous l'onglet Serveur.
Configurez les paramètres de connexion sous l'onglet Réglage des performances.
Copiez tous les fichiers nécessaires dans les répertoires DocumentRoot
et cgi-bin
.
Quittez l'application et choisissez d'enregistrer vos paramètres.
Utilisez l'onglet Principal pour configurer les paramètres de base du serveur.
Entrez un nom de domaine pleinement qualifié pour lequel vous avez des autorisations d'accès dans la zone de texte Nom de serveur. Cette option correspond à la directive ServerName
dans httpd.conf
. Cette directive ServerName
définit le nom d'hôte du serveur Web. Elle est utilisée lors de la création d'URL de retransmission. Si vous ne définissez pas de nom de serveur, le serveur Web essaie de le résoudre à partir de l'adresse IP du système. Le nom de serveur ne doit pas forcément être identique au nom de domaine résolu à partir de l'adresse IP du serveur. Il se peut par exemple que vous souhaitiez donner au serveur le nom www.example.com alors que son véritable nom DNS est en fait foo.example.com.
Entrez l'adresse électronique de la personne qui met à jour le serveur Web dans la zone de texte Adresse électronique du Webmaster. Cette option correspond à la directive ServerAdmin
dans httpd.conf
. Si vous configurez les pages d'erreur du serveur de façon à ce qu'elles contiennent une adresse électronique, celle-ci sera alors utilisée pour transmettre tout problème à l'administrateur du serveur. La valeur par défaut est root@localhost.
Utilisez la zone Adresses disponibles pour définir les ports sur lesquels le serveur acceptera les requêtes entrantes. Cette option correspond à la directive Listen
dans httpd.conf
. Par défaut, Red Hat configure le Serveur HTTP Apache de manière à ce qu'il écoute le port 80 pour des communications Web non-sécurisées.
Cliquez sur le bouton Ajouter pour définir des ports supplémentaires pour la réception de requêtes. Une fenêtre semblable à celle reproduite dans la Figure 13.2, « Adresses disponibles » apparaîtra. Vous pouvez choisir, soit l'option Écouter toutes les adresses pour écouter toutes les adresses IP sur le port défini, ou vous pouvez spécifier une adresse IP spécifique sur laquelle le serveur acceptera des connexions dans le champ d'adresse, Adresse. Ne spécifiez qu'une seule adresse IP par numéro de port. Si vous souhaitez préciser plus d'une adresse IP pour le même numéro de port, saisissez une entrée pour chacune des adresses IP. Dans la mesure du possible, utilisez une adresse IP au lieu d'un nom de domaine afin d'éviter l'échec de la recherche de DNS. Reportez-vous à l'adresse : http://httpd.apache.org/docs/2.2/dns-caveats.html pour de plus amples informations sur les Problèmes en relation avec DNS et Apache.
L'entrée d'un astérisque (*) dans le champ Adresse revient à choisir Écouter toutes les adresses. En cliquant sur le bouton Modifier dans le cadre Adresses disponibles, vous obtiendrez la même fenêtre que celle qui apparaît en pressant sur le bouton Ajouter, mais les champs seront remplis pour les entrées sélectionnées. Pour effacer une entrée, sélectionnez-la et appuyez sur le bouton Supprimer.
Si le Serveur HTTP Apache est configuré pour écouter l'activité sur un port dont le numéro est inférieur à 1024, seul le super-utilisateur peut le lancer. En revanche, pour les ports dont le numéro est égal ou supérieur à 1024, httpd
peut être lancé en tant que simple utilisateur.
Après avoir défini le nom du serveur, l'adresse électronique du Webmaster et les adresses disponibles, cliquez sur l'onglet Hôtes virtuels. La figure ci-dessous illustre l'onglet Hôtes virtuels.
Cliquez sur le bouton Modifier pour afficher la fenêtre Propriétés de l'hôte virtuel à partir de laquelle vous pouvez configurer vos paramètres préférés. Pour ajouter de nouveaux paramètres, cliquez sur le bouton Ajouter qui affiche également la fenêtre Propriétés de l'hôte virtuel. Cliquez sur le bouton Modifier les paramètres par défaut pour afficher la fenêtre Propriétés de l'hôte virtuel sans l'onglet Options générales.
Dans l'onglet Options générales, vous pouvez changer le nom d'hôte, le répertoire racine du document et ajouter l'adresse électronique du Webmaster. Dans la section Informations sur l'hôte, vous pouvez renseigner l'adresse IP et le nom de l'hôte virtuel. La figure ci-dessous illustre l'onglet Options générales.
Si vous ajoutez un hôte virtuel, les paramètres que vous indiquerez auront la priorité pour cet hôte virtuel. Si une directive n'est pas définie dans les paramètres de l'hôte virtuel, la valeur par défaut est utilisée.
La figure ci-dessous illustre l'onglet Options des pages à partir duquel vous pouvez configurer la Liste des pages recherchées pour un répertoire et les Pages d'erreur. Si vous n'avez jamais vu ces paramètres, ne les modifiez pas.
Les entrées énumérées dans la Liste de recherche de pages de répertoires définissent la directive DirectoryIndex
. DirectoryIndex
est la page par défaut renvoyée par le serveur lorsqu'un utilisateur demande l'index d'un répertoire en ajoutant une barre oblique (/) à la fin du nom de ce répertoire.
Lorsqu'un utilisateur demande à accéder à la page http://www.example.com/this_directory/
, il obtient soit la page DirectoryIndex
si elle existe, soit une liste de répertoires générée par le serveur. Le serveur essaie de trouver l'un de ces fichiers et renvoie le premier qu'il trouve.
S'il ne trouve aucun des deux fichiers et que Options Indexes
est paramétrée pour ce répertoire, le serveur génère et renvoie une liste au format HTML, des sous-répertoires et fichiers contenus dans le répertoire.
Utilisez la section Code d'erreur pour configurer le Serveur HTTP Apache afin qu'il redirige le client vers un URL local ou externe en cas de problème ou d'erreur. Cette option correspond à la directive ErrorDocument
. Si un problème ou une erreur survient lorsqu'un client essaie de se connecter au Serveur HTTP Apache, le bref message d'erreur indiqué dans la colonne Code d'erreur s'affiche par défaut. Pour remplacer cette configuration par défaut, sélectionnez le code d'erreur et cliquez sur le bouton Modifier. Choisissez Par défaut afin d'afficher le message d'erreur par défaut. Sélectionnez URL pour rediriger le client vers un URL externe et entrez un URL complet, y compris http://
dans le champ Emplacement. Sélectionnez Fichier pour rediriger le client vers un URL interne et entrez un emplacement de fichier sous le document root du serveur Web. L'emplacement doit commencer par une barre oblique (/) et être relatif au document root.
Par exemple, pour rediriger un code d'erreur "404 Not Found" (impossible de trouver la page) vers une page Web que vous avez créée dans un fichier nommé 404.html
, copiez 404.html
dans
. Dans ce cas, DocumentRoot
/../errors/404.htmlDocumentRoot
correspond au répertoire Document Root que vous avez défini (la valeur par défaut est /var/www/html
). Si le répertoire Document Root est la valeur par défaut, le fichier devrait être copié dans /var/www/error/404.html
. Sélectionnez ensuite Fichier comme comportement pour le code d'erreur 404 - Not Found et entrez /error/404.html
dans le champ Emplacement.
À partir du menu Erreurs affichées par défaut au bas de la page, vous pouvez sélectionnez une des options suivantes :
Afficher le bas de page avec l'adresse électronique — Affiche le bas de page par défaut sur toutes les pages d'erreurs ainsi que l'adresse électronique de l'administrateur du site Web spécifiée par la directive ServerAdmin
.
Afficher le bas de page — Affiche le bas de page par défaut sur les pages d'erreurs.
Aucun bas de page — N'affiche pas de bas de page sur les pages d'erreurs.
L'option mod_ssl
active le cryptage du protocole HTTP sous SSL. Le protocole SSL (de l'anglais Secure Sockets Layer) est utilisé pour la communication et le cryptage à travers les réseaux TCP/IP. L'onglet SSL vous permet de configurer SSL pour votre serveur. Pour configurer SSL vous devez fournir le chemin d'accès à votre :
Fichier de certificat - cette option équivaut à l'utilisation de la directive SSLCertificateFile
qui dirige le chemin d'accès vers le fichier de certificat du serveur encodé PEM (de l'anglais Privacy Enhanced Mail).
Fichier clé - cette option équivaut à l'utilisation de la directive SSLCertificateKeyFile
qui dirige le chemin d'accès vers le fichier clé privé du serveur encodé PEM.
Fichier de chaîne de certification - cette option équivaut à l'utilisation de la directive SSLCertificateChainFile
qui dirige le chemin d'accès vers le fichier certificat qui contient toutes les chaînes de certificats du serveur.
Fichier d'autorité de certification - il s'agit d'un fichier crypté utilisé afin de confirmer l'authenticité ou l'identité des parties communiquant avec le serveur.
Vous pouvez découvrir davantage de directives de configuration pour SSL sur : http://httpd.apache.org/docs/2.2/mod/directives.html#S. Vous devez également déterminer les options SSL à activer. Ceci équivaut à l'utilisation de la directive SSLOptions
avec les options suivantes :
FakeBasicAuth - active les méthodes d'authentification standard utilisées par Apache. Cela signifie que le sujet "Distinguished Name" (DN) du certificat X509 client est traduit en un nom d'utilisateur HTTP basique.
ExportCertData - crée les variables d'environnement CGI dans SSL_SERVER_CERT
, SSL_CLIENT_CERT
et SSL_CLIENT_CERT_CHAIN_n
où n est un nombre 0,1,2,3,4,... Ces fichiers sont utilisés pour davantage de vérifications de certificats par les scripts CGI.
CompatEnvVars - active la compatibilité ascendante pour Apache SSL en ajoutant des variables d'environnement CGI.
StrictRequire - active l'accès strict qui force le refus d'accès chaque fois que les directives SSLRequireSSL
et SSLRequire
indiquent que l'accès est interdit.
OptRenegotiate - permet d'éviter l'établissement de liaisons inutiles par mod_ssl
qui effectue également des contrôles sécurisés de paramètres. Il est recommandé d'activer OptRenegotiate par répertoire.
Davantage d'informations sur les options SSL ci-dessus se trouvent en ligne à l'adresse suivante : http://httpd.apache.org/docs/2.2/mod/mod_ssl.html#ssloptions. La figure ci-dessous illustre l'onglet SSL et les options discutées ci-dessus.
Utilisez l'onglet Connexion afin de configurer les options pour les journaux d'erreurs et de transferts.
Le serveur écrit par défaut le journal de transferts dans le fichier /var/log/httpd/access_log
et le journal d'erreurs dans le fichier /var/log/httpd/error_log
.
Le journal de transferts contient une liste de toutes les tentatives d'accès au serveur Web. Il enregistre l'adresse IP du client qui essaye de se connecter, la date et l'heure de la tentative et le fichier qu'il essaye de récupérer sur le serveur Web. Entrez le nom du chemin d'accès et du fichier dans lequel stocker ces informations. Si le nom du chemin d'accès et du fichier ne commence pas avec une oblique (/), le chemin d'accès est relatif au répertoire root du serveur. Cette option correspond à la directive TransferLog
.
Vous pouvez configurer un format de journalisation personnalisé en cochant Utiliser les options de journalisation personnalisées et en entrant une chaîne journal personnalisée dans le champ Personnaliser la chaîne journal. Cela configure la directive LogFormat
. Reportez-vous à http://httpd.apache.org/docs/2.2/mod/mod_log_config.html#logformat pour davantage de détails sur le format de cette directive.
Le journal d'erreurs contient une liste de toutes les erreurs qui se produisent sur le serveur. Entrez le nom du chemin d'accès et du fichier dans lequel stocker les informations. Si le nom du chemin d'accès et du fichier ne commence pas avec une oblique (/), le chemin d'accès est relatif au répertoire root du serveur. Cette option correspond à la directive ErrorLog
.
Utilisez le menu Niveau de journal pour paramétrer la verbosité des messages d'erreur dans les journaux d'erreur. Il peut être défini (de la plus grande à la moindre verbosité) à emerg, alert, crit, error, warn, notice, info ou debug. Cette option correspond à la directive LogLevel
.
La valeur choisie avec le menu Recherche DNS inverse définit la directive HostnameLookups
. Choisir Pas de recherche inverse définit la valeur à off. Choisir Recherche inverse définit la valeur à on. Choisir Recherche inverse double définit la valeur à double.
Si vous choisissez Recherche inverse, votre serveur résoudra automatiquement l'adresse IP pour chaque connexion qui requiert un document de votre serveur Web. La résolution de l'adresse IP signifie que votre serveur effectue une ou plusieurs connexions au DNS afin de déterminer le nom d'hôte correspondant à une adresse IP particulière.
Si vous choisissez Recherche inverse double, votre serveur effectuera un DNS recherche inverse. C'est-à-dire qu'après une recherche inverse, une recherche directe sera effectuée selon le résultat. Au moins une des adresses IP dans la recherche directe doit correspondre à l'adresse de la première recherche inverse.
Généralement, il est bon de laisser cette option définie à Pas de recherche inverse, parce que les requêtes DNS ajoutent une charge à votre serveur et peuvent le ralentir. Si votre serveur est occupé, les conséquences des essais de ces recherches inverses ou recherches inverses doubles peuvent être notables.
Les recherches inverses et les recherches inverses doubles sont également un problème sur tout l'Internet. Les connexions individuelles recherchant les noms d'hôte finissent par faire beaucoup. Par conséquent, pour votre propre serveur aussi bien que pour l'Internet, vous devriez laisser cette option définie à Pas de recherche inverse.
Utilisez l'onglet Environnement pour configurer les options pour des variables spécifiques à définir, passer ou déparamétrer pour les scripts CGI.
Quelquefois, il est nécessaire de modifier les variables d'environnement pour les scripts CGI ou les pages côté serveur inclus (ou SSI). Le serveur HTTP Apache peut utiliser le module mod_env
pour configurer les variables d'environnement qui sont passées aux scripts CGI et aux pages SSI. Utilisez la page Variables d'environnement pour configurer les directives pour ce module.
Utilisez la section Défini pour les scripts CGI pour définir une variable d'environnement qui est passée aux scripts CGI et aux pages SSI. Par exemple, pour définir la variable d'environnement MAXNUM
à 50
, cliquez sur le bouton Ajouter à l'intérieur de la section Défini pour les scripts CGI, comme indiqué dans la Figure 13.8, « Variables d'environnement », et saisissez MAXNUM
dans le champ de texte Variable d'environnement et 50
dans le champ de texte Valeur à définir. Cliquez sur Valider pour l'ajouter à la liste. La section Défini pour les scripts CGI configure la directive SetEnv
.
Utilisez la section Passer aux scripts CGI pour passer la valeur d'une variable d'environnement aux scripts CGI quand le serveur est démarré initialement. Pour voir cette variable d'environnement, saisissez la commande env
à l'invite du shell. Cliquez sur le bouton Ajouter à l'intérieur de la section Passer aux scripts CGI et saisissez le nom de la variable d'environnement dans la boîte de dialogue qui en résulte. Cliquez sur Valider pour l'ajouter à la liste. La section Passer aux scripts CGI configure la directive PassEnv
.
Pour supprimer une variable d'environnement afin que la valeur ne soit pas passée aux scripts CGI ni aux pages SSI, utilisez la section Déparamétrer pour les scripts CGI. Cliquez sur Ajouter dans la section Déparamétrer pour les scripts CGI, et saisissez le nom de la variable d'environnement à déparamétrer. Cliquez sur Valider pour l'ajouter à la liste. Cela correspond à la directive UnsetEnv
.
Pour éditer n'importe laquelle de ces valeurs d'environnement, sélectionnez-la sur la liste et cliquez le bouton correspondant Éditer. Pour supprimer n'importe quelle entrée sur la liste, sélectionnez-la et cliquez sur le bouton correspondant Supprimer.
Pour en apprendre plus à propos des variables d'environnement dans le Serveur HTTP Apache, reportez-vous à l'adresse suivante : http://httpd.apache.org/docs/2.2/env.html.
Utilisez la page des Répertoires dans l'onglet Performance pour configurer les options pour les répertoires spécifiques. Cela correspond à la directive <Directory>
.
Cliquez sur le bouton Éditer dans le coin en haut, à droite pour configurer les Options de répertoire par défaut pour tous les répertoires qui ne sont pas spécifiés sur la liste Répertoire ci-dessous. Les options que vous avez choisies sont listées comme la directive Options
dans la directive <Directory>
. Vous pouvez configurer les options suivantes :
ExecCGI — Permet l'exécution des scripts CGI. Les scripts CGI ne sont pas exécutés si cette option n'est pas choisie.
FollowSymLinks — Permet de suivre les liens symboliques.
Includes — Permet les inclusions côté serveur.
IncludesNOEXEC — Autorise l'inclusion de fichiers côté serveur mais désactive les commandes #exec
et #include
dans les scripts CGI.
Indexes — Affiche une liste formatée du contenu du répertoire, si aucun DirectoryIndex
(tel que index.html
) existe dans le répertoire demandé.
Multiview — Pend en charge la multivue à contenu variable ; cette option est désactivée par défaut.
SymLinksIfOwnerMatch — Ne suivez les liens symboliques que si le fichier cible ou le répertoire a le même propriétaire que le lien.
Pour spécifier les options pour des répertoires particuliers, cliquez sur le bouton Ajouter à côté de la zone de liste Répertoire. Une fenêtre comme indiqué dans la Figure 13.10, « Paramètres des répertoires » apparaît. Saisissez le répertoire à configurer dans le champ Répertoire au bas de la fenêtre. Sélectionnez les options dans la liste de droite et configurez la directive Order
avec les options sur la gauche. La directive Order
contrôle l'ordre dans lequel les directives de permission et de refus sont évaluées. Dans le champ Autoriser les hôtes à partir de et Refuser les hôtes à partir de, vous pouvez spécifier l'un des éléments suivants :
Autoriser tous les hôtes — Saisissez all
pour autoriser l'accès à tous les hôtes.
Nom de domaine partiel — Autorise tous les hôtes dont le nom correspond à, ou se termine par, une chaîne spécifique.
Adresse IP complète — Accorde l'accès à une adresse IP spécifique.
Un sous-réseau — Par exemple 192.168.1.0/255.255.255.0
Une spécification CIDR de réseau — Par exemple 10.3.0.0/16
Si vous cochez l'option Permettre aux fichiers .htaccess d'écraser les options du répertoire, les directives de configuration dans le fichier .htaccess
ont la priorité.
Le fichier de configuration du Serveur HTTP Apache est /etc/httpd/conf/httpd.conf
. Il y a des nombreux commentaires dans le fichier httpd.conf
qui rendent son contenu très explicite. La configuration par défaut fonctionne dans la plupart des situations ; cependant, il est important de bien connaître certaines des options de configuration les plus importantes.
Avec l'arrivée du Serveur HTTP Apache 2.2, de nombreuses options de configuration ont changé. Pour toute information sur la migration d'un fichier de configuration de la version 1.3 vers le nouveau format, reportez-vous à la Section 13.2.2, « Migration des fichiers de configuration du Serveur HTTP Apache version 1.3 vers 2.0 ».
Lors de la configuration du Serveur HTTP Apache, modifiez /etc/httpd/conf/httpd.conf
puis rechargez, redémarrez ou arrêtez et démarrez le processus httpd
comme l'explique la Section 13.3, « Démarrage et arrêt de httpd
».
Avant de modifier httpd.conf
, faites une copie de sauvegarde du fichier original. Ainsi, si vous commettez une erreur lors de la modification du fichier de configuration, vous pourrez toujours utiliser la copie de sauvegarde pour résoudre d'éventuels problèmes.
Si une erreur est commise et que le serveur Web ne fonctionne pas correctement, passez d'abord en revue les passages modifiés du fichier httpd.conf
afin de corriger toute faute de frappe.
Consultez ensuite le journal d'erreurs du serveur Web, /var/log/httpd/error_log
. Selon votre expérience, le journal d'erreurs peut paraître quelque peu difficile à interpréter. Ceci étant, les dernières entrées du journal d'erreurs devraient fournir des informations utiles.
Les sections suivantes contiennent de brèves descriptions des directives contenues dans le fichier httpd.conf
. Ces descriptions ne sont pas exhaustives. Pour obtenir de plus amples informations, reportez-vous à la documentation de l'organisation Apache disponible en ligne à l'adresse suivante : http://httpd.apache.org/docs/2.2/.
Pour obtenir davantage d'informations sur les directives mod_ssl
, reportez-vous à la documentation disponible en ligne à l'adresse suivante : http://httpd.apache.org/docs/2.2/mod/mod_ssl.html.
AccessFileName
nomme le fichier que le serveur doit utiliser pour les informations de contrôle d'accès dans chaque répertoire. La valeur par défaut est .htaccess
.
Juste après la directive AccessFileName
, une série de balises Files
établit un contrôle d'accès sur tout fichier commençant par .ht
. Ces directives refusent l'accès par le Web à tous les fichiers .htaccess
(ou d'autres commençant par .ht
) pour des raisons de sécurité.
Action
spécifie l'association d'un type de contenu MIME à un script CGI de sorte que lorsqu' un fichier de ce type de support est demandé, un script CGI particulier est exécuté.
Lors de l'utilisation de FancyIndexing
comme paramètre de IndexOptions
, la directive AddDescription
peut être utilisée pour afficher des descriptions spécifiées par l'utilisateur pour certains fichiers ou pour certains types de fichiers dans des listes de répertoires générées par le serveur. La directive AddDescription
prend en charge les fichiers de listes spécifiques, les expressions à caractères génériques ou les extensions de fichiers.
AddEncoding
nomme des extensions de noms de fichiers qui devraient spécifier un type de codage particulier. Il est également possible d'utiliser AddEncoding
pour donner l'instruction à certains navigateurs de décompresser certains fichiers lors de leur téléchargement.
AddHandler
mappe des extensions de fichiers sur des gestionnaires de signaux spécifiques. Par exemple, le module de commande cgi-script
peut être utilisé en association avec l'extension .cgi
pour traiter automatiquement un fichier dont le nom se termine par .cgi
comme un script CGI. L'exemple suivant est un exemple de directive AddHandler
pour l'extension .cgi
.
AddHandler cgi-script .cgi
Cette directive active les scripts CGI en dehors du répertoire cgi-bin
afin qu'ils puissent fonctionner dans tout répertoire se trouvant sur le serveur dont l'option ExecCGI
figure au sein du conteneur de répertoires. Reportez-vous à Directory pour obtenir davantage d'informations sur la définition de l'option ExecCGI
pour un répertoire.
Outre son utilisation avec les scripts CGI, la directive AddHandler
sert aussi au traitement de fichiers HTML et imagemap analysés par le serveur.
AddIcon
spécifie l'icône à afficher dans les listes de répertoires générées par le serveur pour des fichiers avec certaines extensions. Par exemple, le serveur Web est paramétré pour afficher l'icône binary.gif
pour les fichiers portant les extensions .bin
ou .exe
.
Cette directive nomme des icônes qui s'affichent par fichier avec codage MIME, dans des listes de répertoires générées par le serveur. Par exemple, le serveur Web est paramétré par défaut pour afficher l'icône compressed.gif
à côté des fichiers codés MIME x-compress et x-gzip dans des listes de répertoires générées par le serveur.
Cette directive nomme des icônes qui s'affichent à côté des fichiers avec des types MIME dans des listes de répertoires générées par le serveur. Par exemple, le serveur est paramétré pour afficher l'icône text.gif
à côté de fichiers avec un type MIME text
, dans des listes de répertoires générées par le serveur.
AddLanguage
associe des extensions de noms de fichiers à des langues spécifiques. Cette directive est très utilisée pour le Serveur HTTP Apache qui sert des contenus dans une multitude de langues et ce, en fonction de la préférence linguistique définie sur le navigateur client.
Utilisez la directive AddType
pour définir ou annuler un type de MIME par défaut et des paires d'extensions de fichiers. L'exemple de directive suivant indique à Serveur HTTP Apache de reconnaître l'extension de fichier .tgz
:
AddType application/x-tar .tgz
Le paramètre Alias
permet d'accéder aux répertoires se trouvant en dehors du répertoire DocumentRoot
. Tout URL se terminant par l'alias sera automatiquement converti en chemin d'accès vers l'alias. Par défaut, un alias pour un répertoire icons
est déjà configuré. Un répertoire icons
est accessible par le serveur Web, mais le répertoire ne figure pas dans DocumentRoot
.
Allow
spécifie le client pouvant accéder à un répertoire donné. Le client peut être all
, un nom de domaine, une adresse IP, une adresse IP partielle, une paire réseau/masque réseau, etc. Le répertoire DocumentRoot
est configuré afin d'autoriser les requêtes (Allow
) de quiconque (all
), de la sorte, tout le monde peut y accéder.
La directive AllowOverride
définit si des Options
peuvent être annulées par les instructions présente dans un fichier .htaccess
. Par défaut, aussi bien le répertoire racine que le répertoire DocumentRoot
sont paramétrés pour ne permettre aucune annulation via .htaccess
.
La directive BrowserMatch
permet au serveur de définir des variables d'environnement ou de prendre des mesures appropriées en fonction du champ d'en-tête Utilisateur-Agent HTTP (User-Agent HTTP) — qui identifie le type de navigateur du client. Par défaut, le serveur Web utilise BrowserMatch
pour refuser des connexions à certains navigateurs présentant des problèmes connus de même que pour désactiver les activités keepalive et vidages d'en-têtes HTTP pour les navigateurs ayant des problèmes avec ces actions.
Un certain nombre de directives cache commentées sont fournies dans le fichier de configuration par défaut du Serveur HTTP Apache. Dans la plupart des situations, il suffit de supprimer le commentaire en retirant le symbole dièse (#
) placé au début de la ligne. Ci-après figure une liste de certaines des directives associées au cache ayant une grande importance :
CacheEnable
— Spécifie si le cache est un disque, une mémoire ou un cache de description de fichiers. Par défaut, CacheEnable
configure un cache de disque pour les URL au niveau de ou au-dessous de /
.
CacheRoot
— Définit le nom du répertoire qui contiendra les fichiers mis en cache. La valeur par défaut donnée à CacheRoot
est le répertoire /var/httpd/proxy/
.
CacheSize
— Définit la quantité d'espace en kilo-octets (Ko) que le cache peut utiliser. La valeur par défaut pour CacheSize
est 5
Ko.
Ci-dessous figure une liste des autres directives courantes associées au cache.
CacheMaxExpire
— Définit la durée pendant laquelle les documents HTML mis en cache seront conservés (sans rechargement à partir du serveur Web duquel ils proviennent). La valeur par défaut est de 24
heures (86400
secondes).
CacheLastModifiedFactor
— Paramètre la création d'une date d'expiration pour un document qui a été reçu depuis le serveur d'origine sans date d'expiration définie. La valeur par défaut pour CacheLastModifiedFactor
est réglée sur 0.1
, ce qui signifie que la date d'expiration de tout document de ce type est égale à un dixième de la durée écoulée depuis la dernière modification du document.
CacheDefaultExpire
— Détermine la durée exprimée en heures, de l'expiration d'un document qui a été reçu à l'aide d'un protocole ne prenant pas en charge les délais d'expiration. La valeur par défaut est réglée sur 1
heure (3600
secondes).
NoProxy
— Établit une liste de sous-réseaux, d'adresses IP, de domaines ou d'hôtes séparés par des espaces dont le contenu n'est pas mis en cache. Ce paramètre est le plus utile sur les sites Intranet.
Par défaut, votre serveur Web demande aux serveurs proxy de ne pas mettre en cache des documents négociés sur la base du contenu (c'est-à-dire qui peuvent changer avec le temps ou suite à une entrée saisie par le demandeur). Si la valeur de CacheNegotiatedDocs
est paramétrée sur on
, cette fonctionnalité est désactivée et les serveurs proxy seront alors autorisés à mettre en cache de tels documents.
CustomLog
identifie le fichier journal et le format du fichier journal. Par défaut, l'enregistrement se fait dans le fichier /var/log/httpd/access_log
alors que les erreurs sont enregistrées dans le fichier /var/log/httpd/error_log
.
Le format par défaut de CustomLog
est le format du fichier journal combined
illustré ci-dessous :
remotehost rfc931 user date "request" status bytes referrer user-agent
DefaultIcon
spécifie l'icône à afficher dans les listes de répertoires générées par le serveur pour les fichiers pour lesquels aucune autre icône n'est spécifiée. Le fichier image unknown.gif
est la valeur par défaut.
DefaultType
définit un type de contenu par défaut pour le serveur Web devant être utilisé pour des documents dont les types MIME ne peuvent pas être déterminés. La valeur par défaut est text/plain
.
Deny
fonctionne selon le même principe que Allow
, sauf que cette fois-ci, l'accès est refusé à un client donné. Le DocumentRoot
n'est pas configuré par défaut pour refuser (Deny
) des requêtes provenant d'un client quelconque.
Les balises <Directory /path/to/directory>
et </Directory>
créent un conteneur utilisé pour entourer un groupe de directives de configuration devant uniquement s'appliquer à ce répertoire et à ses sous-répertoires. Toute directive applicable à un répertoire peut être utilisée à l'intérieur de balises Directory
.
Par défaut, des paramètres très restrictifs sont appliqués au répertoire racine (/
), à l'aide des directives Options
(voir la directive Options) et AllowOverride
(voir la directive AllowOverride). Sous une telle configuration, tout répertoire du système ayant besoin de paramètres plus permissifs doit contenir explicitement ces paramètres.
Dans la configuration par défaut, un autre conteneur Directory
est également configuré pour DocumentRoot
; ce faisant, des paramètres moins rigides sont assignés à l'arborescence de répertoires, de manière à ce que le Serveur HTTP Apache puisse avoir accès à des fichiers placés dans ce dernier.
Le conteneur Directory
peut également être utilisé pour configurer des répertoires cgi-bin
supplémentaires pour des applications côté-serveur en dehors du répertoire spécifié dans la directive ScriptAlias
(reportez-vous à la directive ScriptAlias pour obtenir de plus amples informations).
Pour ce faire, le conteneur Directory
doit déterminer l'option ExecCGI
pour ce répertoire.
Par exemple, si les scripts CGI se trouvent dans /home/my_cgi_directory
, ajoutez le conteneur Directory
suivant au fichier httpd.conf
:
<Directory /home/my_cgi_directory> Options +ExecCGI </Directory>
Ensuite, il est nécessaire d'enlever le symbole de commentaire présent dans la directive AddHandler
afin de permettre l'identification des fichiers ayant une extension .cgi
en tant que scripts CGI. Reportez-vous à la directive AddHandler pour obtenir des instructions sur le paramétrage de AddHandler
.
Pour que cette opération se déroule parfaitement, il est nécessaire de définir les permissions pour les scripts CGI et pour le chemin d'accès complet vers les scripts en tant que 0755.
DirectoryIndex
est la page servie par défaut lorsqu'un utilisateur demande un index de répertoire en insérant une barre oblique (/) à la fin d'un nom de répertoire.
Lorsqu'un utilisateur demande à accéder à la page http://example
/this_directory
/, il obtient soit la page DirectoryIndex
si elle existe, soit une liste de répertoires générée par le serveur. La valeur par défaut de DirectoryIndex
est le type de topologie index.html
et index.html.var
. Le serveur essaie de trouver l'un de ces fichiers et renvoie le premier qu'il trouve. S'il ne trouve aucun des deux fichiers et que la directive Options Indexes
est paramétrée pour ce répertoire, le serveur génère et renvoie une liste au format HTML, des sous-répertoires et fichiers contenus dans le répertoire (à moins que la fonctionnalité de listage des répertoires ne soit desactivée).
DocumentRoot
est le répertoire contenant la plupart des fichiers HTML qui seront servis en réponse aux requêtes. Le DocumentRoot
par défaut aussi bien pour le serveur Web sécurisé que pour le serveur Web non-sécurisé est le répertoire /var/www/html
. Par exemple, il se peut que le serveur reçoive une demande pour le document suivant :
http://example.com/foo.html
Le serveur recherche le fichier suivant dans le répertoire par défaut :
/var/www/html/foo.html
Pour modifier DocumentRoot
afin qu'il ne soit pas partagé par le serveur Web sécurisé et par le serveur Web non-sécurisé, reportez-vous à la Section 13.7, « Hôtes virtuels ».
La directive ErrorDocument
associe un code de réponse HTTP à un message ou à une URL qui sera renvoyé au client. Par défaut, le serveur Web renvoie un simple message d'erreur, habituellement crypté, lorsqu'une erreur se produit. La directive ErrorDocument
force le serveur Web à renvoyer à la place une page ou un message personnalisé.
Pour que le message soit valide, il doit se trouver entre guillemets "
.
ErrorLog
spécifie le fichier dans lequel sont journalisées les erreurs concernant les serveurs. La valeur par défaut pour cette directive est /var/log/httpd/error_log
.
La directive ExtendedStatus
spécifie si Apache doit produire des informations élémentaires (off
) ou détaillées (on
) sur l'état des serveurs, lorsque le gestionnaire de signal server-status
est appelé. Ce dernier est appelé à l'aide des balises Location
. Pour obtenir davantage d'informations sur l'appel de server-status
, reportez-vous à la directive Location.
Spécifie le nom de groupe des processus du Serveur HTTP Apache.
Cette directive a été supprimée pour la configuration des hôtes virtuels.
La valeur par défaut attribuée à Group
est apache
.
HeaderName
nomme le fichier qui, s'il existe dans le répertoire, est ajouté au début des listes de répertoires générées par le serveur. Comme pour la directive ReadmeName
, le serveur essaie, si possible, de l'inclure sous la forme d'un document HTML ou sinon, comme simple texte.
HostnameLookups
peut être paramétrée sur on
, off
ou double
. Si HostnameLookups
est paramétrée sur on
, le serveur résout automatiquement l'adresse IP pour chaque connexion. La résolution de l'adresse IP suppose que le serveur établisse une ou plusieurs connexions avec un serveur DNS, rallongeant ainsi la durée des opérations de traitement. Si HostnameLookups
est paramétrée sur double
, le serveur établira une recherche DNS double inversée, rallongeant par là-même encore plus la durée des opérations de traitement.
Afin de conserver des ressources sur le serveur, la valeur par défaut donnée à HostnameLookups
est off
.
Si des noms d'hôtes sont nécessaires dans les fichiers journaux de serveurs, songez à exécuter l'un des nombreux outils conçus pour analyser les fichiers journaux ; ces derniers effectuent des recherches DNS non seulement de manière plus efficace mais également en masse lors de la rotation des fichiers journaux de serveurs Web.
Les balises IfDefine
entourent des directives de configuration. Elles s'appliquent si l'état du "test" spécifié dans la balise IfDefine
est vrai. Les directives sont ignorées si l'état du test est faux.
Le test dans les balises IfDefine
est un nom de paramètre (comme par exemple, HAVE_PERL
). Si le paramètre est défini (c'est-à-dire spécifié comme argument de la commande de démarrage du serveur), le test est vrai. Dans ce cas, lorsque le serveur Web est démarré, le test est vrai et les directives contenues dans les balises IfDefine
sont appliquées.
Les balises <IfModule>
et </IfModule>
créent un conteneur conditionnel dont les directives ne sont activées que si le module spécifié est chargé. Les directives placées entre les balises IfModule
sont traitées dans l'un des deux cas suivants. Les directives sont traitées si le module contenu dans la balise de début <IfModule>
est chargé. En revanche, si un point d'exclamation (!) figure devant le nom du module, les directives ne sont traitées que si le module contenu dans la balise <IfModule>
n'est pas chargé.
Pour obtenir de plus amples informations sur les modules du Serveur HTTP Apache, reportez-vous à la Section 13.6, « Ajout de modules ».
Include
permet d'inclure d'autres fichiers de configuration au moment de l'exécution.
Le chemin d'accès vers ces fichiers de configuration peut être absolu ou relatif par rapport au ServerRoot
.
Pour que le serveur utilise individuellement des modules paquetés, tels que mod_ssl
, mod_perl
et php
, la directive suivante doit être intégrée dans la Section 1 : Global Environment
du httpd.conf
:
Include conf.d/*.conf
IndexIgnore
affiche une liste d'extensions de fichiers, de noms de fichiers partiels, d'expressions contenant des caractères génériques ou de noms de fichiers complets. Le serveur Web n'inclura dans les listes de répertoires générées par le serveur, aucun fichier correspondant à l'un de ces paramètres.
IndexOptions
contrôle l'apparence des listes de répertoires générées par le serveur, en ajoutant entre autres, des icônes et des descriptions de fichier. Si Options Indexes
est définie (voir la directive Options), le serveur Web génère une liste des répertoires lorsqu'il reçoit une requête HTTP pour un répertoire sans index.
Le serveur Web recherche tout d'abord, dans le répertoire demandé un fichier correspondant aux noms spécifiés dans la directive DirectoryIndex
(généralement, index.html
). Si le serveur Web ne trouve aucun fichier index.html
, le Serveur HTTP Apache génère une liste HTML des répertoires correspondant au répertoire demandé. L'apparence de cette liste de répertoires est contrôlée, en partie, par la directive IndexOptions
.
La valeur de la configuration par défaut est FancyIndexing
. Ainsi, un utilisateur peut réorganiser une liste de répertoires en cliquant sur les en-têtes des colonnes. En cliquant deux fois sur la même en-tête, le classement passera d'un ordre ascendant à un ordre descendant. La valeur FancyIndexing
affiche également différentes icônes selon les types de fichiers, et ce, en fonction de leur extension.
Si l'option AddDescription
est utilisée avec FancyIndexing
, une brève description du fichier sera incluse dans les listes de répertoires générées par le serveur.
IndexOptions
comprend un certain nombre de paramètres supplémentaires pouvant être utilisés pour contrôler l'apparence des répertoires créés par le serveur. Les paramètres IconHeight
et IconWidth
nécessitent que le serveur des balises HTML HEIGHT
et WIDTH
pour les icônes contenues dans les pages Web générées par le serveur. Le paramètre IconsAreLinks
associe l'icône graphique à l'ancre du lien HTML, qui contient la cible du lien URL.
KeepAlive
définit si votre serveur autorisera plus d'une requête par connexion ; cette directive peut servir à empêcher un client particulier d'utiliser une trop grande quantité des ressources dont le serveur est doté.
Par défaut, la valeur de Keepalive
est réglée sur off
. Si la valeur de Keepalive
est on
et que le serveur devient très occupé, il peut générer rapidement le nombre maximum de processus enfants. Dans ce cas, le serveur sera considérablement ralenti. Si la directive Keepalive
est activée, il est recommandé de donner à KeepAliveTimeout
une valeur basse (reportez-vous à la directive KeepAliveTimeout pour obtenir de plus amples informations) et de contrôler le fichier journal /var/log/httpd/error_log
du serveur. Ce journal indique si le serveur est sur le point d'atteindre le maximum de processus enfants.
KeepAliveTimeout
définit la durée exprimée en secondes pendant laquelle le serveur attend après avoir servi une requête, avant d'interrompre la connexion. Une fois que le serveur reçoit une requête, c'est la directive Timeout
qui s'applique à sa place. Par défaut, la valeur donnée à la directive KeepAliveTimeout
est de 15 secondes.
LanguagePriority
permet de déterminer l'ordre de préférence des langues, au cas où aucune préférence linguistique ne serait paramétrée sur le navigateur client.
La commande Listen
identifie les ports sur lesquels votre serveur Web acceptera les demandes entrantes. Par défaut, le Serveur HTTP Apache est paramétré pour écouter les communications Web non-sécurisées sur le port 80 et (dans le fichier /etc/httpd/conf.d/ssl.conf
définissant tout serveur sécurisé) les communications Web sécurisées sur le port 443.
Si le Serveur HTTP Apache est configuré pour écouter l'activité sur un port dont le numéro est inférieur à 1024, seul le super-utilisateur peut le lancer. En revanche, pour les ports dont le numéro est égal ou supérieur à 1024, httpd
peut être lancée en tant que simple utilisateur.
La directive Listen
peut également être utilisée pour spécifier des adresses IP particulières sur lesquelles le serveur acceptera des connexions.
LoadModule
est utilisée pour charger des modules DSO (de l'anglais Dynamic Shared Object, objet partagé dynamiquement). Pour obtenir davantage d'informations sur la prise en charge DSO du Serveur HTTP Apache, y compris la manière précise d'utiliser la directive LoadModule
, reportez-vous à la Section 13.6, « Ajout de modules ». Notez que l'ordre du chargement des modules n'est plus important avec le Serveur HTTP Apache 2.0. Reportez-vous à la Section 13.2.2.1.3, « Prise en charge de DSO (Dynamic Shared Object) » pour plus d'informations sur la prise en charge DSO du Serveur HTTP Apache 2.0.
Les balises <Location>
et </Location>
permettent de créer un conteneur dans lequel un contrôle d'accès basé sur l'URL peut être spécifié.
Par exemple, pour permettre aux personnes se connectant depuis le domaine du serveur de consulter des rapports sur l'état du serveur, utilisez les directives suivantes :
<Location /server-status> SetHandler server-status Order deny,allow Deny from all Allow from <.example.com>
</Location>
Remplacez <.example.com>
par le nom de domaine de second niveau du serveur Web.
Pour fournir des rapports de configuration des serveurs (y compris des modules installés et des directives de configuration) en réponse à des requêtes en provenance de votre domaine, utilisez les directives suivantes :
<Location /server-info> SetHandler server-info Order deny,allow Deny from all Allow from <.example.com>
</Location>
Ici encore, remplacez <.example.com>
par le nom de domaine de second niveau du serveur Web.
La directive LogFormat
configure le format des fichiers journaux des différents serveurs Web. Le LogFormat
utilisé dépend en fait des paramètres attribués dans la directive CustomLog
(voir la directive CustomLog).
Ci-dessous figurent les options de format s'appliquant si la valeur de la directive CustomLog
est combined
:
%h
(adresse IP de l'hôte distant ou nom d'hôte)
Répertorie l'adresse IP distante du client demandeur. Si la valeur de HostnameLookups
est on
, le nom d'hôte du client est enregistré à moins que le DNS ne puisse le fournir.
%l
(rfc931)
Option non-utilisée. Un tiret (-) apparaît à sa place dans le fichier journal.
%u
(utilisateur authentifié)
Affiche l'identifiant de l'utilisateur enregistré, si l'authentification était nécessaire. Cette option n'étant généralement pas utilisée, dans le fichier journal, un tiret (-) figure dans le champ en question.
%t
(date)
Enregistre la date et l'heure de la requête.
%r
(chaîne de demandes)
Enregistre la chaîne de demandes telle qu'elle a été envoyée depuis le navigateur ou le client.
%s
(état)
Enregistre le code d'état HTTP renvoyé à l'hôte client.
%b
(octets)
Enregistre la taille du document.
%\"%{Referer}i\"
(referrer)
Enregistre l'URL de la page Web qui a renvoyé l'hôte client au serveur Web.
%\"%{User-Agent}i\"
(utilisateur-agent)
Enregistre le type de navigateur Web effectuant la requête.
LogLevel
définit le niveau de détail avec lequel les messages d'erreur devraient être enregistrés dans les journaux d'erreurs. Les valeurs possibles de LogLevel
sont (du niveau le moins détaillé au niveau le plus détaillé) emerg
, alert
, crit
, error
, warn
, notice
, info
ou debug
. La valeur par défaut donnée à LogLevel
est warn
.
Cette directive définit le nombre maximum de requêtes autorisées par connexion persistante. L'organisation Apache Project recommande l'utilisation d'un paramétrage élevé, ce qui entraîne une amélioration des performances du serveur. Par défaut, la valeur de MaxKeepAliveRequests
paramétrée sur 100
est approprié pour la plupart des situations.
La directive NameVirtualHost
associe une adresse IP à un numéro de port, si nécessaire, pour tout hôte virtuel portant un nom. La configuration d'hôtes virtuels nommés permet à un Serveur HTTP Apache de servir différents domaines sans devoir pour ce faire utiliser de multiples adresses IP.
L'utilisation de tout hôte virtuel nommé fonctionne seulement avec des connexions HTTP non-sécurisées. Si vous devez employer des hôtes virtuels avec un serveur sécurisé, utilisez plutôt des hôtes virtuels basés sur l'adresse IP.
Afin d'activer l'hébergement d'hôtes virtuels basés sur le nom, supprimez le symbole de commentaire figurant dans la directive de configuration NameVirtualHost
et ajoutez la bonne adresse IP. Ajoutez ensuite des conteneurs VirtualHost
supplémentaires pour chaque hôte virtuel, en fonction des besoins de votre configuration.
La directive Options
contrôle les fonctionnalités spécifiques du serveur qui sont disponibles dans un répertoire particulier. Par exemple, en vertu des paramètres restrictifs spécifiés pour le répertoire root, Options
est réglée uniquement sur FollowSymLinks
. Aucune fonctionnalité n'est activée, à l'exception du fait que le serveur est autorisé à suivre les liens symboliques dans le répertoire root.
Par défaut, dans le répertoire DocumentRoot
, Options
est paramétrée pour inclure Indexes
et FollowSymLinks
. Indexes
permet au serveur de générer le contenu d'un répertoire si aucun DirectoryIndex
(par exemple, index.html
) n'est spécifié. FollowSymLinks
permet au serveur de suivre des liens symboliques dans ce répertoire.
Les déclarations Options
de la section de configuration du serveur principal doivent être copiées individuellement dans chaque conteneur VirtualHost
. Reportez-vous à la directive VirtualHost pour obtenir de plus amples informations sur le sujet.
La directive Order
contrôle simplement l'ordre dans lequel les directives allow
et deny
sont analysées. Le serveur est configuré pour analyser les directives Allow
avant d'analyser les directives Deny
s'appliquant au répertoire DocumentRoot
.
PidFile
est le nom du fichier dans lequel le serveur enregistre son identifiant de processus (PID). Le PID par défaut est /var/run/httpd.pid
.
Les balises <Proxy *>
et </Proxy>
permettent de créer un conteneur qui renferme un groupe de directives de configuration devant s'appliquer seulement au serveur proxy. À l'intérieur des balises <Proxy>
, il est possible d'utiliser de nombreuses directives s'appliquant à un répertoire.
Pour configurer le Serveur HTTP Apache de manière à ce qu'il fonctionne comme un serveur Proxy, supprimez le symbole dièse (#
) placé au début de la ligne <IfModule mod_proxy.c>
, de la directive ProxyRequests et de chaque ligne figurant dans la section <Proxy>
. Paramétrez la directive ProxyRequests
sur On
et définissez les domaines devant avoir accès au serveur dans la directive Allow from
figurant dans la section <Proxy>
.
ReadmeName
nomme le fichier qui, s'il existe dans le répertoire, est ajouté à la fin des listes de répertoires générées par serveur. Le serveur Web commence par essayer d'inclure le fichier comme un document HTML, puis essaie de l'inclure comme un simple document texte. Par défaut, ReadmeName
est paramétré sur README.html
.
Lorsqu'une page Web est déplacée, Redirect
peut être utilisée pour mapper l'ancien URL vers un autre URL. Le format est le suivant :
Redirect /<old-path>
/<file-name>
http://<current-domain>
/<current-path>
/<file-name>
Dans cet exemple, remplacez d'une part <old-path>
par les informations de l'ancien-chemin vers <file-name>
et d'autre part <current-domain>
et <current-path>
par les informations relatives au domaine et au chemin actuels pour <file-name>
.
Dans cet exemple, toute requête pour <file-name>
à l'ancien emplacement est automatiquement redirigée vers le nouvel emplacement.
Pour obtenir des informations sur les techniques de redirection, utilisez le module mod_rewrite
inclus dans le Serveur HTTP Apache. Pour de plus amples informations sur la configuration du module mod_rewrite
, reportez-vous à la documentation de l'organisation Apache Software Foundation disponible en ligne à l'adresse suivante : http://httpd.apache.org/docs/2.2/mod/mod_rewrite.html.
La directive ScriptAlias
définit l'endroit où se trouvent les scripts CGI. D'une manière générale, il est préférable de ne pas laisser de scripts CGI dans DocumentRoot
, où ils peuvent être consultés comme des documents texte. C'est pour cette raison qu'il existe un répertoire spécial en dehors du répertoire DocumentRoot
, contenant des exécutables et scripts côté-serveur, qui est désigné par la directive ScriptAlias
. Ce répertoire, connu sous le nom cgi-bin
, a /var/www/cgi-bin/
comme valeur par défaut.
Il est possible de créer des répertoires pour stocker des exécutables en dehors du répertoire cgi-bin
. Pour de plus amples informations sur la manière de procéder, reportez-vous à la directive AddHandler et à la directive Directory.
Donnez comme valeur à la directive ServerAdmin
l'adresse électronique de l'administrateur du serveur Web. Cette adresse électronique apparaîtra dans les messages d'erreur sur les pages Web générées par le serveur afin que les utilisateurs puissent signaler un problème en envoyant un message électronique à l'administrateur du serveur.
La valeur par défaut donnée à ServerAdmin
est root@localhost
.
Généralement, la valeur donnée à ServerAdmin
est Webmaster@example.com
. Une fois cette valeur déterminée, créez un alias pour Webmaster
établi au nom de la personne responsable du serveur Web dans /etc/aliases
et exécutez /usr/bin/newaliases
.
ServerName
permet de définir un nom d'hôte et un numéro de port (en accord avec la directive Listen
) pour le serveur. La directive ServerName
ne doit pas forcément correspondre au nom d'hôte de l'ordinateur. Par exemple, le serveur Web pourrait être www.example.com
bien que le nom d'hôte du serveur soit foo.example.com
. La valeur spécifiée dans ServerName
doit être un nom de domaine (ou DNS, de l'anglais Domain Name Service) valide qui peut être résolu par le système — ne vous contentez surtout pas d'en inventer un.
Ci-dessous figure un exemple de directive ServerName
:
ServerName www.example.com:80
Lors de la détermination d'un ServerName
, assurez-vous que son adresse IP et son nom de serveur figurent bien dans le fichier /etc/hosts
.
Le répertoire ServerRoot
est le répertoire de niveau supérieur contenant les fichiers du serveur. Par défaut, la directive ServerRoot
est paramétrée sur "/etc/httpd"
aussi bien pour le serveur sécurisé que pour le serveur non-sécurisé.
La directive ServerSignature
ajoute une ligne contenant la version du Serveur HTTP Apache et le nom du serveur (ServerName
) pour tout document créé par un serveur, comme par exemple, les messages d'erreurs renvoyés aux clients. La valeur par défaut donnée à ServerSignature
est on
.
ServerSignature
peut être paramétré sur EMail
afin qu'une balise HTML mailto:ServerAdmin
soit ajoutée au niveau de la ligne de signature des réponses générées automatiquement. ServerSignature
peut également être paramétré sur Off
afin que le serveur Apache n'envoie plus son numéro de version et les informations de modules. Veuillez également vérifier les paramètres ServerTokens
.
La directive ServerTokens
détermine si le champ de l'entête de la réponse du Serveur renvoyé aux clients devrait inclure les détails du type de système d'exploitation et les informations sur les modules compiled-in. Par défaut, ServerTokens
est défini à Full
qui envoie des informations sur le type de système d'exploitation et les modules compiled-in. Définir les ServerTokens
à Prod
envoie le nom du produit seulement et cela est recommandé, car de nombreux pirates informatique vérifient les informations dans l'entête du Serveur quand ils cherchent des faiblesses. Vous pouvez aussi définir les ServerTokens
à Min
(minimal) ou à OS
(système d'exploitation de l'anglais operating system).
La directive SuexecUserGroup
figurant dans le module mod_suexec
, permet de spécifier les privilèges d'exécution des programmes CGI qui s'applique à l'utilisateur et au groupe. Des requêtes non-CGI continuent à être traitées en fonction de l'utilisateur et du groupe spécifié dans les directives User
et Group
.
De la version 2.0, la directive SuexecUserGroup
a remplacé la configuration du Serveur HTTP Apache 1.3 dans l'utilisation des directives User
et Group
à l'intérieur de la configuration des sections VirtualHosts
.
Timeout
définit la durée, exprimée en secondes, pendant laquelle le serveur attend des réceptions et des émissions pendant les communications. La valeur de Timeout
est paramétrée sur 300
secondes par défaut, ce qui est approprié pour la plupart des situations.
TypesConfig
nomme le fichier qui définit la liste par défaut des correspondances de type MIME (extensions de nom de fichier associées à des types de contenu). Le fichier TypesConfig
par défaut est /etc/mime.types
. Au lieu d'éditer /etc/mime.types
, il est plutôt recommandé d'ajouter des types MIME à l'aide de la directive AddType
.
Pour obtenir de plus amples informations sur AddType
, reportez-vous à la directive AddType.
Lorsque la valeur attribuée à cette directive est on
, elle configure le Serveur HTTP Apache de manière à ce qu'il se référence en utilisant les valeurs précisées dans les directives ServerName
et Port
. En revanche, lorsque la valeur de UseCanonicalName
est off
, le serveur emploie à la place la valeur utilisée par le client envoyant la requête lorsqu'il fait référence à lui-même.
Par défaut, la valeur attribuée à UseCanonicalName
est off
.
La directive User
définit le nom d'utilisateur du processus serveur et détermine les fichiers auxquels le serveur peut avoir accès. Tous les fichiers auxquels cet utilisateur n'aura pas accès seront également inaccessibles aux clients se connectant au Serveur HTTP Apache.
La valeur par défaut donnée à User
est apache
.
Cette directive a été supprimée pour la configuration des hôtes virtuels.
Pour des raisons de sécurité, le Serveur HTTP Apache n'est pas exécuté en tant que super-utilisateur.
UserDir
est le nom du sous-répertoire, au sein du répertoire personnel de chaque utilisateur, où devraient être placés les fichiers HTML personnels devant être servis par le serveur Web. Par défaut, la valeur attribuée à cette directive est disable
(désactiver).
Dans le fichier de configuration par défaut, le nom du sous-répertoire est public_html
. Par exemple, il se peut que le serveur reçoive la requête suivante :
http://example.com
/~username
/foo.html
Le serveur rechercherait alors le fichier :
/home/username/public_html/foo.html
Dans l'exemple ci-dessus, /home/username/
est le répertoire personnel de l'utilisateur (notez que le chemin d'accès par défaut vers les répertoires personnels des utilisateurs peut être différent).
Assurez-vous que les autorisations relatives aux répertoires personnels des utilisateurs sont correctement définies. Les répertoires personnels des utilisateurs doivent avoir des permissions équivalentes à 0711. Les bits de lecture (r) et d'exécution (x) doivent être définis sur les répertoires public_html
des utilisateurs (0755 fonctionnera également). Les fichiers qui seront servis dans les répertoires public_html
des utilisateurs doivent au moins avoir une valeur équivalente à 0644.
Des balises <VirtualHost>
et </VirtualHost>
permettent de créer un conteneur soulignant les caractéristiques d'un hôte virtuel. Le conteneur VirtualHost
accepte la plupart des directives de configuration.
Un conteneur VirtualHost
commenté est fourni dans httpd.conf
et illustre le groupe minimum de directives de configuration nécessaires pour chaque hôte virtuel. Reportez-vous à la Section 13.7, « Hôtes virtuels » pour obtenir de plus amples informations sur les hôtes virtuels.
Le conteneur d'hôtes virtuels SSL par défaut se trouve désormais dans le fichier /etc/httpd/conf.d/ssl.conf
.
Les directives figurant dans le fichier /etc/httpd/conf.d/ssl.conf
peuvent être configurées pour permettre des communications Web sécurisées à l'aide de SSL et TLS.
La directive SetEnvIf
permet de régler des variables d'environnement en fonction des en-têtes des connexions entrantes. Il ne s'agit pas seulement d'une directive SSL, bien qu'elle soit présente dans le fichier /etc/httpd/conf.d/ssl.conf
fourni. Dans le présent contexte, elle sert à désactiver la fonction keep-alive HTTP et à autoriser SSL à fermer la connexion sans générer de notification de fermeture de la part du navigateur client. Ce paramètre est nécessaire pour certains navigateurs qui n'interrompent pas la connexion SSL avec une grande fiabilité.
Pour obtenir de plus amples informations sur d'autres directives présentes dans le fichier de configuration SSL, consultez les documents disponibles aux adresses suivantes :
Dans la plupart des cas, les directives SSL sont configurées de manière appropriée lors de l'installation de Red Hat Enterprise Linux. Faites très attention lors de la modification des directives du serveur sécurisé HTTP Apache car une mauvaise configuration peut être à l'origine de brèches de sécurité, rendant tout système vulnérable.
Comme l'explique la Section 13.2.2.1.2, « Régulation de la taille de server-pool », sous le Serveur HTTP Apache 2.0, la responsabilité de gérer les caractéristiques de server-pool est octroyée à un groupe de modules appelé MPM. Les caractéristiques de server-pool sont différentes selon le MPM spécifique utilisé. C'est la raison pour laquelle un conteneur IfModule
est nécessaire pour définir le server-pool du MPM qui est utilisé.
Par défaut, le Serveur HTTP Apache 2.0 définit le server-pool aussi bien pour le MPM prefork
que le MPM worker
.
Ci-dessous figure une liste des directives figurant dans les conteneurs de server-pool spécifiques aux MPM.
MaxClients
fixe une limite au nombre total de processus serveur ou de clients connectés simultanément qui peuvent s'exécuter en même temps. L'objectif principal de cette directive est d'éviter qu'un Serveur HTTP Apache surchargé n'entraîne le plantage de votre système d'exploitation. Pour des serveurs très solicités, cette valeur devrait être élevée. La valeur par défaut du serveur est 150, indépendamment du MPM utilisé. Toutefois, il n'est pas recommandé d'attribuer à MaxClients
une valeur supérieure à 256
lors de l'utilisation du MPM prefork
.
MaxRequestsPerChild
définit le nombre total de requêtes que chaque processus serveur enfant sert avant de s'arrêter. L'attribution d'une valeur à MaxRequestsPerChild
est importante afin d'éviter des pertes de mémoire induites par des processus longs. La valeur par défaut de MaxRequestsPerChild
pour le MPM prefork
est 4000
et 0
pour le MPM worker
.
Ces valeurs ne sont pas seulement utilisées avec le MPM prefork
. Elles ajustent la façon selon laquelle le Serveur HTTP Apache s'adapte dynamiquement à la charge reçue en maintenant un nombre approprié de processus serveur de secours déterminés en fonction du nombre de requêtes entrantes. Le serveur vérifie le nombre de serveurs attendant une requête et en supprime certains s'ils sont plus nombreux que MaxSpareServers
ou en crée d'autres s'ils sont moins nombreux que MinSpareServers
.
La valeur par défaut donnée à MinSpareServers
est 5
; la valeur par défaut attribuée à MaxSpareServers
est 20
. Ces paramètres par défaut devraient être adaptés à presque toutes les situations. Ne donnez pas à MinSpareServers
une valeur très élevée car un tel choix se traduira en une charge de traitement importante sur le serveur, même si le trafic est faible.
Ces valeurs ne sont pas seulement utilisées avec le MPM worker
. Elles ajustent la façon selon laquelle le Serveur HTTP Apache s'adapte dynamiquement à la charge reçue en maintenant un nombre approprié de processus serveur de secours déterminés en fonction du nombre de requêtes entrantes. Le serveur vérifie le nombre de threads de serveurs attendant une requête et en supprime certains s'ils sont plus nombreux que MaxSpareThreads
ou en crée d'autres s'ils sont moins nombreux que MinSpareThreads
.
La valeur par défaut donnée à MinSpareThreads
est 25
; la valeur par défaut attribuée à MaxSpareThreads
est 75
. Ces paramètres par défaut devraient être appropriés à la plupart des situations. La valeur de MaxSpareThreads
doit être supérieure ou égale à la somme de MinSpareThreads
et de ThreadsPerChild
, dans le cas contraire, le Serveur HTTP Apache la corrigera automatiquement.
La directive StartServers
définit le nombre de processus serveur créés au démarrage. Étant donné que le serveur Web supprime et crée dynamiquement des processus serveur en fonction de la charge du trafic, il n'est pas nécessaire de modifier ce paramètre. Le serveur Web est configuré de manière à lancer 8
processus serveur au démarrage pour le MPM prefork
et 2
pour le MPM worker
.
Cette valeur est utilisée uniquement avec le MPM worker
. Il définit le nombre de threads (ou fils) au sein de chaque processus enfant. La valeur par défaut pour cette directive est 25
.
Le serveur HTTP Apache est distribué avec un nombre de modules. Vous trouverez davantage d'informations sur les modules HTTP Apache en ligne à l'adresse suivante : http://httpd.apache.org/docs/2.2/mod/.
Le Serveur HTTP Apache prend en charge des objets partagés dynamiquement (ou DSO de l'anglais Dynamically Shared Objects) ou des modules qui peuvent facilement être chargés selon les besoins.
À l'adresse suivante : http://httpd.apache.org/docs/2.2/dso.html, l'organisation Apache Project fournit une documentation complète en ligne sur les objets partagés dynamiquement (DSO). Sinon, si le paquetage http-manual
est installé, de la documentation relative aux DSO est disponible en ligne à l'adresse suivante : http://localhost/manual/mod/.
Pour que le Serveur HTTP Apache puisse utiliser un DSO, il doit être spécifié dans une directive LoadModule
du répertoire /etc/httpd/conf/httpd.conf
. Si le module est fourni par un paquetage séparé, la ligne doit apparaître au sein du fichier de configuration des modules dans le répertoire /etc/httpd/conf.d/
. Reportez-vous à la directive LoadModule pour obtenir de plus amples informations sur le sujet.
Lors de l'ajout ou de la suppression de modules du fichier http.conf
, le Serveur HTTP Apache doit être rechargé ou relancé, comme l'explique la Section 13.3, « Démarrage et arrêt de httpd
».
Lors de la création d'un nouveau module, installez tout d'abord le paquetage httpd-devel
qui contient les fichiers à inclure (include files), les fichiers d'en-têtes ainsi que l'application Apache eXtenSion (/usr/sbin/apxs
), qui utilise les fichiers à inclure et les fichiers d'en-têtes pour compiler les DSO.
Après l'écriture d'un module, utilisez /usr/sbin/apxs
pour compiler les sources de votre module en dehors de l'arborescence source d'Apache. Pour obtenir de plus amples informations sur l'utilisation de la commande /usr/sbin/apxs
, reportez-vous à la documentation Apache fournie en ligne à l'adresse suivante : http://httpd.apache.org/docs/2.2/dso.html et à la page de manuel de apxs
.
Une fois le module compilé, placez-le dans le répertoire /usr/lib/httpd/modules/
. Pour les plateformes RHEL utilisant un espace utilisateur par défaut de 64 bits (x86_64, ia64, ?) ce chemin d'accès sera /usr/lib64/httpd/modules/
. Ajoutez ensuite une ligne LoadModule
dans le fichier httpd.conf
en suivant la structure suivante :
LoadModule <module-name> <path/to/module.so>
Où <module-name>
correspond au nom du module et <path/to/module.so>
au chemin d'accès vers le DSO.
L'hébergement intégré des hôtes virtuels du Serveur HTTP Apache permet au serveur de fournir différentes informations en fonction de l'adresse IP, du nom d'hôte ou du port faisant l'objet de la requête. Un guide complet sur l'utilisation des hôtes virtuels est disponible en ligne à l'adresse suivante : http://httpd.apache.org/docs/2.2/vhosts/.
La meilleure façon de créer un hôte virtuel basé sur le nom consiste à utiliser le conteneur d'hôte virtuel fourni à titre d'exemple dans httpd.conf
.
L'exemple de l'hôte virtuel offert se présente de la manière suivante :
#NameVirtualHost *:80 # #<VirtualHost *:80> # ServerAdmin webmaster@dummy-host.example.com # DocumentRoot /www/docs/dummy-host.example.com # ServerName dummy-host.example.com # ErrorLog logs/dummy-host.example.com-error_log # CustomLog logs/dummy-host.example.com-access_log common #</VirtualHost>
Pour activer la fonction d'hôte virtuel nommé, décommentez la ligne NameVirtualHost
en retirant le symbole dièse (#
) et en le remplaçant par le symbole de l'astérisque (*
) accompagné de l'adresse IP attribuée à l'ordinateur.
Configurez ensuite un hôte virtuel, en décommentant et personnalisant le conteneur <VirtualHost>
.
Sur la ligne <VirtualHost>
, remplacez l'astérisque (*
) par l'adresse IP du serveur. Remplacez aussi ServerName
par le nom d'un DNS valide assigné à l'ordinateur et configurez les autres directives selon les besoins.
Étant donné que le conteneur <VirtualHost>
accepte presque toutes les directives disponibles dans le cadre de la configuration du serveur principal, sa capacité à être personnalisé est très élevée.
Si vous configurez un hôte virtuel pour qu'il écoute un port autre que le défaut, ce port doit être ajouté à la directive Listen
dans la partie relative aux paramètres globaux du fichier /etc/httpd/conf/http.conf
.
Afin de pouvoir activer l'hôte virtuel qui vient d'être créé, le Serveur HTTP Apache doit être rechargé ou redémarré. Reportez-vous à la Section 13.3, « Démarrage et arrêt de httpd
» pour obtenir des instructions sur le sujet.
Des informations complètes sur la création et la configuration d'hôtes virtuels sur la base du nom ou de l'adresse IP sont fournies en ligne à l'adresse suivante : http://httpd.apache.org/docs/2.2/vhosts/.
Cette section fournit les informations de base sur le Serveur HTTP Apache avec le module de sécurité mod_ssl
activé pour utiliser la bibliothèque OpenSSL et le kit d'outils. Dans cette section, la combinaison ce ces trois composants est appelée le serveur Web sécurisé ou juste le serveur sécurisé.
Le module mod_ssl
est un module de sécurité pour le Serveur HTTP Apache. Le module mod_ssl
utilise les outils fournis par le projet OpenSSL pour ajouter une fonctionnalité très importante au Serveur HTTP Apache — la possibilité de crypter les communications. Ce faisant, la sécurité est bien meilleure que dans une situation où un protocole HTTP normal est utilisé et où les communications entre un navigateur et un serveur Web se font en texte en clair, les exposant à toute interception et lecture par toute personne se trouvant entre le navigateur et le serveur.
Ce chapitre ne prétend pas fournir une documentation exhaustive et exclusive pour l'un ou l'autre de ces programmes. En revanche, lorsque ce sera possible, ce guide vous indiquera d'autres sources d'informations où vous pourrez trouver des renseignements plus détaillés sur certains sujets.
Cette section vous montre comment installer ces programmes. Vous pouvez aussi apprendre les étapes nécessaires pour créer une clé privée et une requête de certificat, comment créer votre propre certificat auto-signé, et comment installer un certificat pour une utilisation avec un serveur sécurisé.
Le fichier de configuration mod_ssl
se trouve dans /etc/httpd/conf.d/ssl.conf
. Pour que ce dernier soit chargé et que mod_ssl
puisse fonctionner, la déclaration Include conf.d/*.conf
doit figurer dans le fichier /etc/httpd/conf/httpd.conf
. Par défaut, cette déclaration est incluse dans le fichier de configuration du Serveur HTTP Apache.
Pour activer le serveur sécurisé, vous devez avoir au minimum les paquetages suivants installés :
httpd
Le paquetage httpd
contient le démon httpd
et les utilitaires associés de même que les fichiers de configuration, les icônes, les modules du serveur HTTP Apache, les pages de manuel, et autres fichiers utilisés par le serveur HTTP Apache.
mod_ssl
Le paquetage mod_ssl
inclut le module mod_ssl
qui fournit une cryptographie forte for pour le serveur HTTP Apache via la couche de sockets sécurisée (de l'anglais Secure Sockets Layer ou SSL) et les protocoles de sécurité de la couche de transport (de l'anglais Transport Layer Security ou TLS).
openssl
Le paquetage openssl
contient le kit d'outils OpenSSL. Le kit d'outils OpenSSL implémente SSL et les protocoles TLS, et inclut également une bibliothèque de cryptographique universelle.
En outre, d'autres paquetages logiciels comme ceux figurant ci-dessous peuvent offrir certaines fonctionnalités de sécurité (mais ils ne sont pas nécessaires pour que le serveur sécurisé fonctionne) :
Votre serveur sécurisé offre la sécurité à l'aide d'une combinaison du protocole "Secure Sockets Layer" (ou SSL) et (dans la plupart des cas) d'un certificat numérique attribué par un fournisseur de certificats (CA). SSL traite les communications cryptées et l'authentification mutuelle entre les navigateurs et votre serveur sécurisé. Le certificat numérique approuvé par le CA fournit l'authentification pour votre serveur sécurisé (la réputation du CA est à la base du certificat d'identité de votre organisation). Lorsque votre navigateur communique à l'aide de cryptage SSL, le préfixe https://
est employé au début de l'adresse URL ("Uniform Resource Locator") dans la barre de navigation.
Le cryptage dépend de l'utilisation de clés (imaginez ces clés comme étant des codeurs/décodeurs de chaînes de données secrètes). Dans le cas de la cryptographie conventionnelle ou symétrique, les deux extrémités de la transaction ont la même clé, qu'elles utilisent pour décoder leurs transmissions mutuelles. Dans le cas du cryptage public ou asymétrique, il existe deux clés : une clé publique et une clé privée. Les personnes ou les organisations gardent leur clé privée secrète et publie leur clé publique. Les données codées à l'aide de la clé publique ne peuvent être décodées qu'avec la clé privée ; les données codées avec la clé privée ne peuvent être décodées qu'avec la clé publique.
Pour configurer votre serveur sécurisé, utilisez le cryptage public pour créer une paire de clés publique et privée. Dans la plupart des cas, vous envoyez une demande de certificat (ainsi que votre clé publique), une preuve de l'identité de votre société et un paiement à un fournisseur de certificats. Ce dernier vérifiera votre demande et votre identité, puis vous enverra un certificat pour votre serveur sécurisé.
Un serveur sécurisé utilise un certificat pour s'identifier auprès des navigateurs Web. Vous pouvez générer votre propre certificat (appelé certificat "auto-signé") ou en obtenir un d'une autorité de certification (CA). Un certificat provenant d'un CA de bonne réputation garantit qu'un site Web est bel et bien associé à une société ou organisation spécifique.
Alternativement, vous pouvez créer votre propre certificat auto-signé. Notez, toutefois, que les certificats auto-signés ne devraient pas être utilisés dans la plupart des environnements de production. Les certificats auto-signés ne sont pas automatiquement acceptés par le navigateur d'un utilisateur — le navigateur demande aux utilisateurs d'accepter le certificat et de créer la connexion sécurisée. Consultez la Section 13.8.4, « Types de certificats » pour de plus amples informations sur les différences entre les certificats auto-signés et les certificats signés par CA.
Une fois que vous avez un certificat auto-signé ou un certificat de CA de votre choix, vous devez l'installer sur votre serveur sécurisé.
Si vous avez déjà une clé existante et un certificat (par exemple, si vous installez le serveur sécurisé pour remplacer un autre produit de serveur sécurisé de la compagnie), vous pouvez sans doute utiliser votre clé existante et le certificat avec le serveur sécurisé. Les deux situations suivantes fournissent des instances où vous n'êtes pas en mesure d'utiliser votre clé existante et le certificat.
Si vous changez votre adresse IP ou votre nom de domaine — Les certificats sont attribués pour un couple adresse IP/nom de domaine spécifique. Ainsi, si vous modifiez l'un des deux éléments, vous devez obtenir un nouveau certificat.
Si vous avez un certificat de VeriSign et changez de logiciel serveur — VeriSign est une autorité de certification (CA) très utilisée. Si vous avez déjà un certificat VeriSign pour une autre utilisation, vous avez probablement songé à l'utiliser pour votre nouveau serveur sécurisé. Malheureusement, vous ne serez pas autorisé à le faire car VeriSign attribue ses certificats en fonction d'un logiciel serveur et d'une combinaison adresse IP/nom de domaine spécifique.
Si vous changez l'un de ces paramètres (par exemple, si vous avez précédemment utilisé un autre produit du serveur sécurisé), le certificat VeriSign en votre possession, utilisé pour l'ancienne configuration, ne fonctionnera plus avec la nouvelle. Vous devrez donc obtenir un nouveau certificat.
Si vous avez déjà une clé et un certificat pouvant être utilisés, vous n'avez pas à générer une nouvelle clé ou à obtenir un nouveau certificat. Par contre, vous devrez peut-être déplacer et renommer les fichiers qui contiennent votre clé et votre certificat.
Déplacez le fichier clé existant vers :
/etc/pki/tls/private/server.key
Déplacez le fichier certificat existant vers :
/etc/pki/tls/certs/server.crt
Si vous mettez à jour depuis le serveur Web sécurisé de Red Hat, votre vieille clé (httpsd.key
) et le certificat (httpsd.crt
) sont situés dans /etc/httpd/conf/
. Déplacez et renommez votre clé et le certificat afin que le serveur sécurisé puisse les utiliser. Utilisez les deux commandes suivantes pour déplacer et renommer votre clé et les fichiers de certificat :
mv /etc/httpd/conf/httpsd.key /etc/pki/tls/private/server.key mv /etc/httpd/conf/httpsd.crt /etc/pki/tls/certs/server.crt
Ensuite, démarrez votre serveur sécurisé avec la commande :
/sbin/service httpd start
Si vous avez installé votre serveur sécurisé depuis le paquetage RPM fourni par Red Hat, un clé privée, générée de façon aléatoire et un certificat test sont créés et placés dans les répertoires appropriés. Toutefois, avant de commencer à utiliser votre serveur sécurisé, vous devez générer votre propre clé et obtenir un certificat qui identifie correctement votre serveur.
Vous avez besoin d'une clé et d'un certificat pour faire fonctionner votre serveur sécurisé — ce qui signifie que vous avez le choix entre la création d'un certificat auto-signé ou l'achat d'un certificat signé auprès d'une autorité de certification. Quelle différence existe-t-il entre les deux ?
Les certificats signés par un fournisseur offrent deux avantages importants pour votre serveur :
Les navigateurs reconnaissent (généralement) automatiquement ces certificats et autorisent la connexion sécurisée, sans demander à l'utilisateur.
Lorsqu'une autorité de certification attribue un certificat signé, il garantit l'identité de l'organisation qui fournit les pages Web au navigateur.
Si votre serveur sécurisé est utilisé par le grand public, votre serveur sécurisé doit avoir un certificat signé par une autorité de certification de façon à ce que les internautes sachent que le site est bien la propriété de l'organisation qui prétend en être propriétaire. Avant de signer un certificat, le fournisseur vérifie l'identité de l'organisation qui en fait la demande.
La plupart des navigateurs prenant en charge SSL ont une liste des autorités de certification qu'elles acceptent automatiquement. Lorsqu'un navigateur tombe sur un certificat d'un fournisseur ne faisant pas partie de cette liste, il demande à l'utilisateur s'il souhaite accepter ou refuser la connexion.
Vous pouvez générer un certificat auto-signé pour votre serveur sécurisé, mais soyez conscient du fait qu'un certificat auto-signé ne fournit pas la même fonctionnalité que le certificat signé CA. Un certificat auto-signé n'est pas reconnu automatiquement par la plupart des navigateurs Web et ne fournit aucune garantie concernant l'identité de l'organisation qui fournit le site web. Un certificat signé CA fournit ces deux fonctionnalités importantes pour un serveur sécurisé. Si votre serveur sécurisé doit être utilisé dans un environnement de production, un certificat signé CA est recommandé.
La procédure pour obtenir un certificat d'un fournisseur est assez simple. Ci-après figure un bref aperçu de cette dernière :
Création d'une paire de clés privées et publiques de cryptage.
Création d'une demande de certificat basée sur la clé publique. La demande de certificat contient des informations sur votre serveur et la société qui l'héberge.
Envoyez la requête de certificat, de même que les documents prouvant votre identité à un CA. Red Hat ne recommande aucune autorité de certificat. Votre décision pourra être basée sur vos expériences, sur les expériences de vos amis ou collègues, ou purement sur des facteurs budgétaires.
Une fois que vous avez choisi une autorité de certification, vous devrez suivre les instructions fournies par cette dernière afin d'obtenir un certificat.
Quand un CA est satisfait que vous êtes effectivement la personne que vous prétendez être, il vous fournit un certificat digital.
Installez ce certificat sur votre serveur sécurisé et commencez à gérer les transactions sécurisées.
Que vous obteniez un certificat d'une CA ou que vous génériez un certificat auto-signé, la première étape est de générer une clé. Consultez la Section 13.8.5, « Génération d'une clé » pour les instructions.
Pour générer une clé, vous devez être connecté en tant que super-utilisateur (ou root).
Tout d'abord, utilisez la commande cd
pour vous déplacer dans le répertoire /etc/httpd/conf/
. Supprimer la fausse clé et le faux certificat qui ont été générés durant l'installation avec les commandes suivantes :
rm ssl.key/server.key
rm ssl.crt/server.crt
Le paquetage crypto-utils
contient l'utilitaire genkey
que vous pouvez utiliser pour générer les clés comme son nom l'indique. Pour créer votre propre clé privée, veuillez vous assurer que le paquetage crypto-utils
est bien installé. Vous pouvez afficher d'autres options en tapant man genkey
dans votre terminal. Nous supposons que vous désirez générer des clés pour www.example.com en utilisant l'utilitaire genkey
, saisissez alors la commande suivante dans votre terminal :
genkey www.example.com
Veuillez noter que le processus basé sur make
n'est plus distribué avec RHEL 5. Cela démarrera l'interface de l'utilisateur graphique genkey
. La figure ci-dessous illustrate le premier écran. Pour naviguer, utilisez la flèche du clavier et les touches de tabulation. Cette fenêtre indique où votre clé sera stockée et vous invite à continuer ou à annuler l'opération. Pour continuer avec la prochaine étape, sélectionnez Suivant et appuyez sur la touche Entrée.
Le prochain écran vous invite à choisir la taille de votre clé. Comme indiqué, plus la taille de votre clé est petite, plus la réponse de votre serveur sera rapide et plus votre niveau de sécurité sera réduit. Lorsque vous sélectionnez la taille de votre clé en utilisant les touches flèche, sélectionnez Suivant pour continuer vers la prochaine étape. La figure ci-dessous illustre l'écran de sélection de taille de clé.
La sélection de la prochaine étape commencera le processus de génération aléatoire des bits, ce qui pourra prendre du temps selon la taille des clés sélectionnées. Plus la taille de votre clé sera grande, plus elle prendra de temps à être générée.
Quand vous génèrerez votre clé, on vous demandera d'envoyer une requête de certificat (CSR) à une autorité de certificat (CA).
Après avoir sélectionné Oui, on vous demandera l'autorité de certificat à laquelle vous désirez envoyer votre requête. Non vous permet de créer un certificat auto-signé. La prochaine étape pour cela est illustrée avec la Figure 13.17, « Génération d'un certificat auto-signé pour votre serveur ».
Quand vous aurez sélectionné votre option préférée, choisissez Suivant pour passer à l'étape suivante. Le prochain écran vous permet de saisir les détails de votre certificat.
Si vous préférez créer une paire de clé de certificat auto-signé, vous devez générer un CSR. À cet effet, sélectionnez Non comme l'option choisie sur l'écran Créer le CSR. Cela affichera la figure ci-dessous dans laquelle saisir les détails de votre certificat. Saisir les détails de votre certificat et appuyer sur la touche Entrée, affichera la Figure 13.19, « Protection de votre clé privée », c'est là que vous choisirez de chiffrer ou non votre clé privée.
Générer un certificat auto-signé pour votre serveur
À la saisie des détails de votre certificat, sélectionnez Suivant pour continuer. La figure ci-dessous donne un exemple du prochain écran affiché après la saisie des détails pour un certificat à envoyer à Equifax. Veuillez noter que si vous créer une clé auto-signée pour votre serveur, cet écran ne s'affichera pas.
Appuyer sur la touche Entrée, affichera le prochain écran à partir duquel vous pouvez activer ou désactiver le chiffrement de votre clé privée. Utilisez la barre espace pour activer ou désactiver cela. Quand il est activé, un caractère [*] est affiché. Quand vous sélectionnez votre option préférée, sélectionnez Suivant pour passer à l'étape suivante.
Le prochain écran vous permet de définir la phrase de passe de votre clé. Veuillez ne pas perdre cette phrase de passe car vous ne pourrez pas exécuter le serveur sans celle-ci. Il vous faudra recréer une nouvelle paire de clé privée ou publique et demander un nouveau certificat depuis vos CA comme indiqué. Pour des raisons de sécurité, la phrase de passe n'est pas affichée alors que vous tapez. Lorsque vous saisissez votre phrase de passe préférée, sélectionnez Suivant pour revenir à votre terminal.
Si vous tentez d'exécuter genkey makeca
sur un serveur qui possède une paire de clés existante, un message d'erreur s'affichera comme indiqué ci-dessous. Vous devez supprimer votre fichier de clé existant comme indiqué afin de générer une nouvelle paire de clés.
Les étapes pour configurer le Serveur HTTP Apache afin d'utiliser les nouvelles clés sont :
Obtenez le certificat signé du CA après la remise du CSR.
Copiez le certificat sur le chemin, par exemple /etc/pki/tls/certs/www.example.com.crt
Editez /etc/httpd/conf.d/ssl.conf
. Changez le SSLCertificateFile et les lignes de la SSLCertificateKey pour qu'elles deviennent :
SSLCertificateFile /etc/pki/tls/certs/www.example.com.crt SSLCertificateKeyFile /etc/pki/tls/private/www.example.com.key
où la partie "www.example.com" devrait correspondre à l'argument passé à la commande genkey
.
Pour en savoir plus sur le Serveur HTTP Apache, consultez les ressources mentionnées ci-dessous.
http://httpd.apache.org — Le site Web officiel du Serveur HTTP Apache contenant de la documentation non seulement sur toutes les directives mais également sur tous les modules par défaut.
http://www.modssl.org — Le site Web officiel de mod_ssl
.
http://www.apacheweek.com — Une newsletter hebdomadaire complète en ligne concernant Apache.
vsftpd
vsftpd
vsftpd
FTP (de l'anglais File Transfer Protocol) est actuellement l'un des protocoles les plus anciens et les plus utilisés sur Internet. Son but est de transférer de manière sécurisée des fichiers entre les ordinateurs hôtes d'un réseau sans que l'utilisateur ne dusse se connecter directement à l'hôte distant ou ne dusse savoir comment utiliser le système distant. Ce protocole permet aux utilisateurs d'accéder à des fichiers sur des systèmes distants en utilisant un ensemble standard de commandes simples.
Ce chapitre présente les éléments de base du protocole FTP ainsi que les options de configuration pour le serveur FTP primaire intégré dans Red Hat Enterprise Linux, vsftpd
.
Toutefois, en raison de l'utilisation très répandue de FTP sur Internet, il est souvent nécessaire de partager des fichiers avec le public. Les administrateurs système devraient donc être conscients des caractéristiques uniques du protocole FTP.
Contrairement à la plupart des protocoles utilisés sur Internet, FTP a besoin de multiples ports réseau afin de pouvoir fonctionner correctement. Lorsqu'une application FTP client établit une connexion avec un serveur FTP, elle ouvre le port 21 sur le serveur — appelé port de commande. Ce port est utilisé pour exécuter toutes les commandes destinées au serveur. Toute donnée requise du serveur est renvoyée au client via un port de données. Le numéro de port pour les connexions aux données et la manière dont les connexions aux données sont effectuées, varient selon que le client demande les données en mode actif ou en mode passif.
Ces modes sont définis de la manière suivante :
Le mode actif représente la méthode utilisée à l'origine par le protocole FTP pour transférer des données à l'application cliente. Lorsqu'un transfert de données en mode actif est engendré par le client FTP, le serveur établit une connexion depuis le port 20 sur le serveur vers l'adresse IP et un port aléatoire, non-privilégié (supérieur à 1024) spécifié par le client. Dans une telle situation, l'ordinateur client doit être autorisé à accepter des connexions sur tout port supérieur à 1024. Avec le nombre croissant de réseaux non-sécurisés, tels que l'Internet, l'utilisation de pare-feu pour protéger les ordinateurs clients est désormais très répandue. Le mode passif a été conçu parce que les pare-feu côté client refusent souvent les connexions entrantes originaires de serveurs FTP en mode actif.
Le mode passif, tout comme le mode actif, est engendré par l'application client FTP. Lors d'une demande de données auprès du serveur, le client FTP indique qu'il souhaite accéder aux données en mode passif et le serveur fournit une adresse IP et un port aléatoire, non-privilégié (supérieur à 1024) sur le serveur. Le client se connecte alors à ce port sur le serveur afin de télécharger les informations demandées.
Alors que le mode passif résout les problèmes d'interférence du pare-feu côté client avec des connexions aux données, il peut rendre plus complexe l'administration du pare-feu côté serveur. En limitant dans le fichier de configuration du serveur FTP, l'éventail des ports non-privilégiés disponibles pour des connexions passives, il est possible de restreindre le nombre de ports ouverts sur un serveur, ce qui permet également de simplifier la création de règles de pare-feu pour le serveur. Reportez-vous à Section 14.5.8, « Options réseau » pour obtenir de plus amples informations sur la manière de limiter le nombre de ports passifs.
Red Hat Enterprise Linux est fourni avec deux serveurs FTP différents :
Accélérateur de contenu Red Hat — Un serveur Web basé sur le noyau qui fournit un serveur Web haute performance et des services FTP. Étant donné que le but de sa conception est à l'origine la vitesse, ses fonctionnalités sont limitées et son fonctionnement n'est possible que comme serveur FTP anonyme. Pour obtenir de plus amples informations sur la configuration et l'administration de l'Accélérateur de contenu Red Hat, consultez la documentation disponible en ligne à l'adresse suivante : http://www.redhat.com/docs/manuals/tux/.
vsftpd
— Un démon FTP sécurisé et rapide qui est le serveur FTP préféré de Red Hat Enterprise Linux. Le reste de ce chapitre se concentre sur vsftpd
.
Le démon vsftpd
(acronyme de Very Secure FTP Daemon) est depuis sa création rapide, stable et surtout sécurisé. Sa capacité à traiter un grand nombre de connexions de manière efficace et sécurisée explique la raison pour laquelle vsftpd
est le seul FTP autonome distribué avec Red Hat Enterprise Linux.
Le modèle de sécurité utilisé par vsftpd
possède trois caractéristiques essentielles, à savoir :
Séparation claire entre les processus privilégiés et les processus non-privilégiés — Des processus différents traitent différentes tâches et chacun de ces derniers fonctionne avec le minimum de privilèges nécessaires pour la tâche à exécuter.
Les tâches demandant un degré élevé de privilèges sont traitées par des processus dotés du minimum de privilèges nécessaires — En contrôlant les compatibilités, contenues dans la bibliothèque libcap
, des tâches qui nécessitent généralement l'ensemble des privilèges super utilisateur peuvent être exécutées de manière plus sûre depuis un processus doté de privilèges moins étendus.
La plupart des processus sont exécutés dans une prison chroot
— Autant que possible, le répertoire super utilisateur des processus devient le répertoire partagé ; ce répertoire est alors considéré comme une prison chroot
. Par exemple, si le répertoire /var/ftp/
est le répertoire partagé primaire, vsftpd
réassigne alors /var/ftp/
au nouveau répertoire super utilisateur, /
. Cette situation empêche toute activité de la part de pirates malintentionnés sur les répertoires qui ne sont pas présents sous le nouveau répertoire super utilisateur.
L'utilisation de ces pratiques de sécurité entraîne les conséquences suivantes sur la manière dont vsftpd
traite les requêtes :
Le processus parent tourne avec le moins de privilèges requis. — Le processus parent calcule dynamiquement le degré de privilèges dont il a besoin pour minimiser le degré de risque. Les processus enfants traitent l'interaction directe avec les clients FTP et tournent avec aussi peu de privilèges que possible.
Toutes les opérations nécessitant un degré élevé de privilèges sont traitées par un petit processus parent — D'une manière semblable à Apache HTTP Server, vsftpd
lance des processus enfants non-privilégiés pour le traitement des connexions entrantes. Cela permet au processus parent privilégié d'être aussi petit que possible et de traiter relativement peu de tâches.
Le processus parent se méfie de toutes les requêtes provenant de processus enfants non-privilégiés — Toute communication avec des processus enfants est reçue sur un socket et la validité de toute information provenant de processus enfants est vérifiée avant que toute opération ne soit exécutée.
La plupart des relations avec les clients FTP sont traitées par des processus enfants non-privilégiés dans une prison chroot
— Étant donné que ces processus enfants ne sont pas privilégiés et n'ont accès qu'au répertoire partagé, tout processus planté ne permet à un agresseur d'accéder qu'aux fichiers partagés.
Le RPM vsftpd
installe sur le système le démon (/usr/sbin/vsftpd
), ses fichiers de configuration et tout fichier associés, ainsi que les répertoires FTP. Ci-après figure une liste des fichiers et répertoires le plus souvent utilisés pour la configuration de vsftpd
:
/etc/rc.d/init.d/vsftpd
— Le script d'initialisation (initscript) utilisé par la commande /sbin/service
pour démarrer, arrêter ou recharger vsftpd
. Reportez-vous à la Section 14.4, « Démarrage et arrêt de vsftpd
» pour obtenir de plus amples informations sur l'utilisation de ce script.
/etc/vsftpd/vsftpd.conf
— Le fichier de configuration de vsftpd
. Reportez-vous à Section 14.5, « Options de configuration de vsftpd
» pour obtenir une liste des options importantes présentes dans ce fichier.
/etc/vsftpd.ftpusers
— Une liste des utilisateurs qui ne sont pas autorisés à se connecter à vsftpd
. Par défaut, cette liste inclut entre autres les utilisateurs root
, bin
et daemon
.
/etc/vsftpd.user_list
— Ce fichier peut être configuré de manière à refuser ou permettre l'accès aux utilisateurs faisant partie de la liste, selon que la directive userlist_deny
a pour valeur YES
(par défaut) ou NO
dans /etc/vsftpd/vsftpd.conf
. Si /etc/vsftpd.user_list
est utilisé pour accorder l'accès aux utilisateurs, les noms d'utilisateur ne doivent pas apparaître dans /etc/vsftpd.ftpusers
.
/var/ftp/
— Le répertoire contenant les fichiers fournis par vsftpd
. Il contient également le répertoire /var/ftp/pub/
pour les utilisateurs anonymes. Les deux répertoires sont lisibles par tout un chacun, mais sont uniquement modifiables par le super utilisateur.
Le RPM vsftpd
installe le script /etc/rc.d/init.d/vsftpd
qui est accessible à l'aide de la commande /sbin/service
.
Pour démarrer le serveur, connectez-vous en tant que super-utilisateur et tapez la commande suivante :
/sbin/service vsftpd start
Pour arrêter le serveur, connectez-vous en tant que super-utilisateur et tapez la commande suivante :
/sbin/service vsftpd stop
L'option restart
représente une manière raccourcie d'arrêter et de démarrer ensuite vsftpd
. Cette méthode représente la manière la plus efficace d'appliquer des changements apportés au niveau de la configuration, suite à la modification du fichier de configuration de vsftpd
.
Pour redémarrer le serveur, connectez-vous en tant que super-utilisateur et tapez la commande suivante :
/sbin/service vsftpd restart
L'option condrestart
(ou redémarrage conditionnel de l'anglais conditional restart) ne démarre vsftpd
que s'il est actuellement en cours d'exécution. Cette option est utile pour les scripts car elle ne démarre pas le démon s'il n'est pas en cours d'exécution.
Pour redémarrer conditionnellement le serveur, connectez-vous en tant que super-utilisateur et tapez la commande suivante :
/sbin/service vsftpd condrestart
Parfois, un ordinateur est utilisé pour fournir de multiples domaines FTP. Cette technique est appelée multihoming (aussi appeleé hébergement multidomaines). Une possibilité d'effectuer du multihoming à l'aide de vsftpd
consiste à exécuter de multiples copies du démon, chacune disposant de son propre fichier de configuration.
Pour ce faire, assignez d'abord les adresses IP appropriées aux périphériques réseau ou aux alias des périphériques réseau du système. Reportez-vous au Chapitre 6, Configuration réseau pour obtenir de plus amples informations sur la configuration des périphériques réseau et des alias de périphériques réseau. Des informations supplémentaires sur les scripts de configuration réseau sont également disponibles dans le Chapitre 5, Interfaces réseau .
Ensuite, assurez-vous que le serveur DNS pour les domaines FTP est bien configuré pour référencer le bon ordinateur. Pour obtenir de plus amples informations sur BIND et ses fichiers de configuration, consultez le Chapitre 8, Berkeley Internet Name Domain (BIND).
Pour que vsftpd
réponde à des requêtes sur des adresses IP, il est nécessaire que de multiples copies du démon tournent. La première copie doit être exécutée à l'aide des initscripts de vsftpd
, comme il l'est décrit dans la Section 14.4, « Démarrage et arrêt de vsftpd
».Cette copie utilise le fichier de configuration standard, /etc/vsftpd/vsftpd.conf
.
Chaque site FTP supplémentaire doit avoir un fichier de configuration portant un nom unique dans le répertoire /etc/vsftpd/
, comme /etc/vsftpd/vsftpd-site-2.conf
. Chaque fichier de configuration ne doit être lisible et modifiable que par le super-utilisateur. Au sein de chaque fichier de configuration relatif à chaque serveur FTP écoutant sur un réseau IPv4, la directive suivante doit être unique :
listen_address=N.N.N.N
Remplacez N.N.N.N
par l'adresse IP unique du site FTP fourni. Si le site utilise IPv6, employez plutôt la directive listen_address6
.
Une fois que chaque serveur supplémentaire est doté d'un fichier de configuration, le démon vsftpd
doit être exécuté depuis une invite du shell root à l'aide de la commande suivante :
vsftpd /etc/vsftpd/<configuration-file>
[amp ]
Dans la commande ci-dessus, remplacez <configuration-file>
par le nom unique du fichier de configuration du serveur, tel que /etc/vsftpd/vsftpd-site-2.conf
.
Parmi d'autres directives pouvant faire l'objet de modifications sur une base individuelle pour chaque serveur figurent :
anon_root
local_root
vsftpd_log_file
xferlog_file
Pour obtenir une liste détaillée des directives disponibles dans le fichier de configuration de vsftpd
, reportez-vous à la Section 14.5, « Options de configuration de vsftpd
».
Pour configurer tout serveur supplémentaire afin qu'il s'exécute automatiquement au démarrage, ajoutez la commande ci-dessus à la fin du fichier de configuration /etc/rc.local
.
Bien que vsftpd
n'offre pas forcément le même degré de personnalisation que d'autres serveurs FTP courants, il fournit suffisamment d'options pour répondre aux besoins de la plupart des administrateurs. Étant donné que sa gamme de fonctionnalités n'est pas excessivement vaste, les erreurs de programmation et de configuration sont plus restreintes.
Toute configuration de vsftpd
est traitée par son fichier de configuration, /etc/vsftpd/vsftpd.conf
. Chaque directive apparaît sur sa propre ligne au sein du fichier et suit le format suivant :
<directive>
=<value>
Pour chaque directive, remplacez d'une part <directive>
par une directive valide et d'autre part <value>
par une valeur valide.
Dans une directive, aucun espace ne doit figurer entre la <directive>
, le symbole égal et l'élément <value>
.
Les lignes de commentaire doivent être précédées par un signe dièse (#
) et ne sont pas prises en compte par le démon.
Pour obtenir une liste complète de toutes les directives disponibles, reportez-vous à la page de manuel de vsftpd.conf
.
Ci-dessous figure une liste des directives les plus importantes présentes dans /etc/vsftpd/vsftpd.conf
. Toute directive ne se trouvant pas explicitement dans le fichier de configuration de vsftpd
se voit attribuer la valeur par défaut.
Ci-dessous figure une liste des directives contrôlant le comportement général du démon vsftpd
.
listen
— Lorsque cette option est activée, vsftpd
est exécuté en mode autonome. Red Hat Enterprise Linux définit cette valeur à YES
. Cette directive ne peut être utilisée en conjonction avec la directive listen_ipv6
.
La valeur par défaut est NO
.
listen_ipv6
— Lorsque cette option est activée, vsftpd
est exécuté en mode autonome, mais n'écoute que l'interface de connexion (ou socket) IPv6. Cette directive ne peut pas être utilisée de concert avec la directive listen
.
La valeur par défaut est NO
.
Ci-dessous figure une liste des directives contrôlant le comportement de connexion et les mécanismes de contrôle d'accès.
anonymous_enable
— Lorsque cette option est activée, des utilisateurs anonymes sont autorisés à se connecter. Les noms d'utilisateurs anonymes (dits anonymous
) et ftp
sont acceptés.
La valeur par défaut est YES
.
Reportez-vous à la Section 14.5.3, « Options pour les utilisateurs anonymes » pour obtenir une liste des directives ayant un impact sur les utilisateurs anonymes.
banned_email_file
— Si la directive deny_email_enable
a pour valeur YES
, elle spécifie le fichier contenant une liste de mots de passe de messagerie anonymes auxquels l'accès au serveur est refusé.
La valeur par défaut est /etc/vsftpd.banned_emails
.
banner_file
— Spécifie le fichier contenant le texte affiché lorsqu'une connexion est établie avec le serveur . Cette option écrase tout texte spécifié dans la directive ftpd_banner
.
Il n'existe pas de valeur par défaut pour cette directive.
cmds_allowed
— Spécifie une liste de commandes FTP, séparées les unes des autres par des virgules, permises par le serveur. Toutes les autres commandes sont refusées.
Il n'existe pas de valeur par défaut pour cette directive.
deny_email_enable
— Lorsque cette option est activée, tout utilisateur anonyme employant des mots de passe de messagerie spécifiés dans /etc/vsftpd.banned_emails
se voit refuser l'accès au serveur. Le nom du fichier référencé par cette directive peut être spécifié à l'aide de la directive banned_email_file
.
La valeur par défaut est NO
.
ftpd_banner
— Lorsque cette option est activée, la chaîne spécifiée dans cette directive est affichée lorsque qu'une connexion au serveur est établie. Cette option peut être annulée par la directive banner_file
.
Par défaut, vsftpd
affiche sa bannière standard.
local_enable
— Lorsque cette option est activée, les utilisateurs locaux sont autorisés à se connecter au système.
La valeur par défaut est YES
.
Reportez-vous à la Section 14.5.4, « Options pour les utilisateurs locaux » pour obtenir une liste des directives ayant un impact sur les utilisateurs locaux.
pam_service_name
— Spécifie le nom du service PAM pour vsftpd
.
La valeur par défaut est ftp
. Notez qu'avec Red Hat Enterprise Linux, cette valeur est configurée à vsftpd
.
La valeur par défaut est NO
. Notez qu'avec Red Hat Enterprise Linux, la valeur est configurée à YES
.
userlist_deny
— Lorsque cette option est utilisée de concert avec la directive userlist_enable
et que sa valeur est NO
, tous les utilisateurs locaux se voient refuser l'accès à moins que le nom d'utilisateur ne figure dans le fichier spécifié par la directive userlist_file
. Étant donné que l'accès est refusé avant même que le client ne puisse saisir son mot de passe, le choix de la valeur NO
pour cette directive empêche les utilisateurs de soumettre des mots de passe non-cryptés sur le réseau.
La valeur par défaut est YES
.
userlist_enable
— Lorsque cette option est activée, les utilisateurs mentionnés dans le fichier spécifiés par la directive userlist_file
se voient refuser l'accès. Étant donné que l'accès est refusé avant même que le client ne puisse saisir son mot de passe, les utilisateurs n'ont pas la possibilité de soumettre des mots de passe non-cryptés sur le réseau.
La valeur par défaut est NO
, cependant, avec Red Hat Enterprise Linux, la valeur donnée est YES
.
userlist_file
— Spécifie le fichier référencé par vsftpd
lorsque la directive userlist_enable
est activée.
La valeur par défaut est /etc/vsftpd.user_list
; cette dernière est créée durant l'installation.
cmds_allowed
— Spécifie une liste de commandes FTP, séparées les unes des autres par des virgules, que le serveur autorise. Toutes les autres commandes sont refusées.
Il n'existe pas de valeur par défaut pour cette directive.
Ci-dessous figure une liste des directives qui contrôlent l'accès des utilisateurs anonymes au serveur. Pour utiliser ces options, la valeur de la directive anonymous_enable
doit être configurée à YES
.
anon_mkdir_write_enable
— Lorsque cette option est activée de concert avec la directive write_enable
, des utilisateurs anonymes sont autorisés à créer de nouveaux répertoires au sein du répertoire parent qui a des permissions en écriture.
La valeur par défaut est NO
.
anon_root
— Spécifie le répertoire que vsftpd
utilise après la connexion d'un utilisateur anonyme.
Il n'existe pas de valeur par défaut pour cette directive.
anon_upload_enable
— Lorsque cette option est activée de concert avec la directive write_enable
, des utilisateurs anonymes sont autorisés à télécharger vers le serveur des fichiers dans un répertoire parent doté de permissions en écriture.
La valeur par défaut est NO
.
anon_world_readable_only
— Lorsque cette option est activée, des utilisateurs anonymes sont autorisés à télécharger des fichiers lisibles par tout un chacun.
La valeur par défaut est YES
.
ftp_username
— Spécifie le compte de l'utilisateur local (énoncé dans /etc/passwd
) employé pour l'utilisateur FTP anonyme. Le répertoire personnel spécifié dans /etc/passwd
pour l'utilisateur est le répertoire root de l'utilisateur FTP anonyme.
La valeur par défaut est ftp
.
no_anon_password
— Lorsque cette option est activée, l'utilisateur anonyme ne doit pas saisir de mot de passe.
La valeur par défaut est NO
.
secure_email_list_enable
— Lorsque cette option est activée, seule une liste de mots de passe électroniques spécifiée pour les connexions anonymes est acceptée. C'est un moyen commode d'offrir une certaine sécurité à un contenu public sans avoir besoin d'utilisateurs virtuels.
Les connexions anonymes sont refusées à moins que le mot de passe fourni soit contenu dans /etc/vsftpd.email_passwords
. Le format du fichier est un mot de passe par ligne, sans espace à la fin.
La valeur par défaut est NO
.
Ci-dessous figure une liste des directives caractérisant la manière selon laquelle les utilisateurs locaux ont accès au serveur. Pour utiliser ces options, la directive local_enable
doit avoir la valeur YES
.
chmod_enable
— Lorsque cette option est activée, la commande FTP SITE CHMOD
est autorisée pour les utilisateurs locaux. Cette commande permet aux utilisateurs de changer les permissions s'appliquant aux fichiers.
La valeur par défaut est YES
.
chroot_list_enable
— Lorsque cette option est activée, les utilisateurs locaux énumérés dans le fichier qui est spécifié dans la directive chroot_list_file
, sont placés dans une prison chroot
dès qu'ils se connectent.
Si cette option est activée de concert avec la directive chroot_local_user
, les utilisateurs locaux énumérés dans le fichier qui est spécifié dans la directive chroot_list_file
ne sont pas placés dans une prison chroot
lors de la connexion.
La valeur par défaut est NO
.
chroot_list_file
— Spécifie le fichier contenant une liste des utilisateurs locaux référencés lorsque la valeur de la directive chroot_list_enable
est configurée à YES
.
La valeur par défaut est /etc/vsftpd.chroot_list
.
chroot_local_user
— Lorsque cette option est activée, les utilisateurs locaux opèrent dans l'environnement chrooté de leur répertoire personnel après leur connexion.
La valeur par défaut est NO
.
L'activation de l'option chroot_local_user
crée un certain nombre de problèmes de sécurité, particulièrement pour les utilisateurs possédant les privilèges nécessaires pour télécharger sur le serveur. Elle n'est par conséquent pas recommandée.
guest_enable
— Lorsque cette option est activée, tous les utilisateurs autres que les utilisateurs anonymes sont connectés en tant qu'utilisateur invité (guest
) qui est l'utilisateur local spécifié dans la directive guest_username
.
La valeur par défaut est NO
.
guest_username
— Spécifie le nom d'utilisateur vers lequel l'utilisateur invité (guest
) est mappé.
La valeur par défaut est ftp
.
local_root
— Spécifie le répertoire que vsftpd
utilise après la connexion d'un utilisateur local.
Il n'existe pas de valeur par défaut pour cette directive.
local_umask
— Spécifie la valeur donnée à umask pour la création de fichiers. Notez que la valeur par défaut se présente sous la forme octale (un système numérique en base huit), qui inclut un préfixe "0". Sinon la valeur est traitée comme un entier à base 10.
La valeur par défaut est 022
.
passwd_chroot_enable
— Lorsque cette option est activée de concert avec la directive chroot_local_user
, vsftpd
chroote les utilisateurs locaux si l'élément /./
figure dans le champ du répertoire personnel au sein de /etc/passwd
.
La valeur par défaut est NO
.
user_config_dir
— Spécifie le chemin vers un répertoire contenant les fichiers de configuration portant le nom des utilisateurs du système local qui renferment des paramètres spécifiques à ces utilisateurs. Toutes les directives figurant dans le fichier de configuration d'un utilisateur annule celles figurant dans /etc/vsftpd/vsftpd.conf
.
Il n'existe pas de valeur par défaut pour cette directive.
Ci-dessous figure la liste des directives ayant un impact sur les répertoires.
dirlist_enable
— Lorsque cette option est activée, les utilisateurs sont autorisés à visionner les listes de répertoires.
La valeur par défaut est YES
.
dirmessage_enable
— Lorsque cette option est activée, un message apparaît chaque fois qu'un utilisateur ouvre un répertoire avec un fichier message. Ce message se trouve dans le répertoire qui est ouvert. Le nom de ce fichier est spécifié dans la directive message_file
et part défaut prend la valeur .message
.
La valeur par défaut est NO
. Notez qu'avec Red Hat Enterprise Linux, la valeur est configurée à YES
.
force_dot_files
— Lorsque cette option est activée, les fichiers commençant par un point (.
) sont inclus dans les listes de répertoires, à l'exception des fichiers .
et ..
.
La valeur par défaut est NO
.
hide_ids
— Lorsque cette option est activée, toutes les listes de répertoires font apparaître ftp
comme l'utilisateur et le groupe de chaque fichier.
La valeur par défaut est NO
.
message_file
— Spécifie le nom du fichier message lorsque la directive dirmessage_enable
est utilisée.
La valeur par défaut est .message
.
text_userdb_names
— Lorsque cette option est activée, des noms d'utilisateurs et noms de groupes test sont utilisés au lieu des entrées UID et GID. L'activation de cette option peut entraîner un ralentissement des performances du serveur.
La valeur par défaut est NO
.
use_localtime
— Lorsque cette option est activée, les listes de répertoires révèlent l'heure locale de l'ordinateur au lieu de l'heure GMT.
La valeur par défaut est NO
.
Ci-dessous figure la liste des directives ayant un impact sur les répertoires.
download_enable
— Lorsque cette option est activée, le téléchargement de fichiers est autorisé.
La valeur par défaut est YES
.
chown_uploads
— Lorsque cette option est activée, tous les fichiers téléléchargés par des utilisateurs anonymes deviennent la propriété de l'utilisateur spécifié dans la directive chown_username
.
La valeur par défaut est NO
.
chown_username
— Spécifie la propriété de fichiers téléchargés anonymement si la directive chown_uploads
est activée.
La valeur par défaut est root
.
write_enable
— Lorsque cette option est activée, les commandes FTP permettant de modifier le système de fichiers sont permises, telles que DELE
, RNFR
et STOR
.
La valeur par défaut est YES
.
Ci-dessous figure une liste des directives ayant un impact sur le comportement de journalisation de vsftpd
.
dual_log_enable
— Lorsque cette option est activée de concert avec xferlog_enable
, vsftpd
enregistre deux fichiers simultanément : un journal compatible avec wu-ftpd
dans le fichier spécifié dans la directive xferlog_file
(par défaut /var/log/xferlog
) et un fichier journal vsftpd
standard spécifié dans la directive vsftpd_log_file
(par défaut /var/log/vsftpd.log
).
La valeur par défaut est NO
.
log_ftp_protocol
— Lorsque cette option est activée de concert avec xferlog_enable
et lorsque xferlog_std_format
a pour valeur NO
, toutes les commandes et réponses FTP sont journalisées. Cette directive est très utilise lors d'opérations de débogage.
La valeur par défaut est NO
.
syslog_enable
— Lorsque cette option est activée de concert avec xferlog_enable
, toute journalisation normalement enregistrée dans le fichier journal standard vsftpd
spécifié dans la directive vsftpd_log_file
(par défaut /var/log/vsftpd.log
) est envoyée à l'enregistreur du système sous le service FTPD.
La valeur par défaut est NO
.
vsftpd_log_file
— Spécifie le fichier journal vsftpd
. Pour que ce fichier soit utilisé, xferlog_enable
doit être activée et xferlog_std_format
doit avoir pour valeur NO
ou, si la valeur de xferlog_std_format
est YES
, l'activation dedual_log_enable
doit être activée. Il est important de noter ici que si syslog_enable
a pour valeur YES
, le journal du système est utilisé à la place du fichier spécifié dans cette directive.
La valeur par défaut est /var/log/vsftpd.log
.
xferlog_enable
— Lorsque cette commande est activée, vsftpd
journalise les connexions (seulement au format vsftpd
) et les informations de transfert de fichiers dans le fichier journal spécifié dans la directive vsftpd_log_file
(par défaut /var/log/vsftpd.log
). Si xferlog_std_format
a pour valeur YES
, les informations de transfert de fichiers sont journalisées mais les connexions ne le sont pas et le fichier spécifié dans xferlog_file
(par défaut /var/log/xferlog
) est utilisé à la place. Il est important de noter ici que les fichiers journaux aussi bien que les formats de journaux sont utilisés si la valeur de dual_log_enable
est YES
.
La valeur par défaut est NO
. Notez qu'avec Red Hat Enterprise Linux, la valeur est configurée à YES
.
xferlog_file
— Spécifie le fichier journal compatible avec wu-ftpd
. Pour que ce fichier soit utilisé, xferlog_enable
doit être activé et la valeur de xferlog_std_format
doit être YES
. Elle est également utilisée si la valeur de dual_log_enable
est YES
.
La valeur par défaut est /var/log/xferlog
.
xferlog_std_format
— Lorsque cette option est activée de concert avec xferlog_enable
, seul un journal de transfert de fichiers compatible avec wu-ftpd
est enregistré dans le fichier spécifié dans la directive xferlog_file
(par défaut /var/log/xferlog
). Il est important de noter ici que ce fichier journalise seulement les transferts de fichiers et n'enregistre pas les connexions au serveur.
La valeur par défaut est NO
. Notez qu'avec Red Hat Enterprise Linux, la valeur est configurée à YES
.
Pour maintenir la compatibilité avec les fichiers journaux enregistrés par l'ancien serveur FTP wu-ftpd
, la directive xferlog_std_format
prend la valeur YES
sous Red Hat Enterprise Linux. Toutefois, ce paramètre signifie que les connexions au serveur ne sont pas journalisées.
Pour journaliser les connexions au format vsftpd
et maintenir un journal des transferts de fichiers compatible wu-ftpd
, donnez à dual_log_enable
la valeur YES
.
S'il n'est pas important de maintenir un journal des transferts de fichiers compatible wu-ftpd
, vous pouvez donner à xferlog_std_format
la valeur NO
, commenter la ligne à l'aide d'un signe dièse (#
) ou supprimer la ligne complètement.
Ci-dessous figure une liste des directives ayant un impact sur la manière dont vsftpd
interagit avec le réseau.
accept_timeout
— Spécifie la durée donnée à un client utilisant une connexion passive pour se connecter.
La valeur par défaut est 60
.
anon_max_rate
— Spécifie le taux de transfert de données maximal, exprimé en octets par seconde, pour les utilisateurs anonymes.
La valeur par défaut est 0
, ce qui ne limite pas le taux de transfert.
connect_from_port_20
Lorsque cette option est activée, vsftpd
tourne avec suffisamment de privilèges pour ouvrir le port 20 sur le serveur lors des transferts de données en mode actif. La désactivation de cette option permet à vsftpd
de tourner avec moins de privilèges, mais cette option peut-être incompatible avec certains clients FTP.
La valeur par défaut est NO
. Notez qu'avec Red Hat Enterprise Linux, la valeur est configurée à YES
.
connect_timeout
— Spécifie la durée maximale exprimée en secondes, donnée à un client utilisant un mode actif pour répondre à une connexion de données.
La valeur par défaut est 60
.
data_connection_timeout
— Spécifie la durée maximale exprimée en secondes, pendant laquelle les transferts de données peuvent s'arrêter. Une fois cette durée écoulée, la connexion au client distant est fermée.
La valeur par défaut est 300
.
ftp_data_port
— Spécifie le port utilisé pour les connexions actives aux données lorsque connect_from_port_20
a pour valeur YES
.
La valeur par défaut est 20
.
idle_session_timeout
— Spécifie la durée maximale pouvant s'écouler entre des commandes depuis un client distant. Une fois cette durée écoulée, la connexion au client distant est fermée.
La valeur par défaut est 300
.
listen_address
— Spécifie l'adresse IP sur laquelle vsftpd
doit être à l'écoute de connexions réseau.
Il n'existe pas de valeur par défaut pour cette directive.
Si plusieurs copies de vsftpd
tournent et servent différentes adresses IP, le fichier de configuration de chaque copie du démon vsftpd
doit avoir une valeur différente pour cette directive. Reportez-vous à la Section 14.4.1, « Démarrage de multiples copies de vsftpd
» pour obtenir de plus amples informations sur les serveurs FTP en hébergement multidomaine.
listen_address6
— Spécifie l'adresse IPv6 sur laquelle vsftpd
doit être à l'écoute de connexions réseau lorsque listen_ipv6
a pour valeur YES
.
Il n'existe pas de valeur par défaut pour cette directive.
Si plusieurs copies de vsftpd
tournent et servent différentes adresses IP, le fichier de configuration de chaque copie du démon vsftpd
doit avoir une valeur différente pour cette directive. Reportez-vous à la Section 14.4.1, « Démarrage de multiples copies de vsftpd
» pour obtenir de plus amples informations sur les serveurs FTP en hébergement multidomaine.
listen_port
— Spécifie le port sur lequel vsftpd
doit être à l'écoute de connexions réseau.
La valeur par défaut est 21
.
local_max_rate
— Spécifie le taux maximal, exprimé en octets par seconde, auquel les données sont transférées, pour les utilisateurs locaux connectés au serveur.
La valeur par défaut est 0
, ce qui ne limite pas le taux de transfert.
max_clients
— Spécifie le nombre maximal de clients autorisés à se connecter simultanément au serveur lorsqu'il tourne en mode autonome. Toute connexion client supplémentaire provoquerait un message d'erreur.
La valeur par défaut est 0
, ce qui ne limite pas les connexions.
max_per_ip
— Spécifie le nombre maximal de clients autorisés à se connecter depuis l'adresse IP source.
La valeur par défaut est 0
, ce qui ne limite pas les connexions.
pasv_address
— Spécifie l'adresse IP utilisée pour l'adresse IP publique du serveur aux serveurs se trouvant derrière des pare-feu NAT (Network Address Translation). Cette option permet à vsftpd
de fournir la bonne adresse de retour pour des connexions en mode passif.
Il n'existe pas de valeur par défaut pour cette directive.
pasv_enable
— Lorsque cette option est activée, les connexions en mode passif sont permises.
La valeur par défaut est YES
.
pasv_max_port
— Spécifie le port le plus élevé possible qui est envoyé aux clients FTP pour des connexions en mode passif. Ce paramètre est utilisé pour limiter la plage de ports afin que les règles de pare-feu soient faciles à créer.
La valeur par défaut est 0
, ce qui ne limite pas la plage des ports passifs les plus élevés. La valeur ne doit pas dépasser 65535
.
pasv_min_port
— Spécifie le port le plus bas possible qui est envoyé au client FTP pour des connexions en mode passif. Ce paramètre est utilisé pour limiter la plage de ports afin que les règles de pare-feu soient plus faciles à créer.
La valeur par défaut est 0
, ce qui ne limite pas la plage des ports passifs les plus bas. La valeur ne doit pas être inférieure à 1024
.
pasv_promiscuous
— Lorsque cette option est activée, les connexions aux données ne sont pas analysées pour vérifier qu'elles proviennent bien de la même adresse IP. Ce paramètre est seulement utile pour certains types de tunnellisation.
N'activez pas cette option à moins qu'elle ne soit absolument nécessaire. En effet, elle désactive une fonctionnalité de sécurité importante permettant de vérifier que les connexions en mode passif proviennent bien de la même adresse IP que la connexion de contrôle qui lance le transfert de données.
La valeur par défaut est NO
.
port_enable
— Lorsque cette option est activée, les connexions en mode actif sont permises.
La valeur par défaut est YES
.
Pour obtenir de plus amples informations sur vsftpd
, reportez-vous aux ressources mentionnées ci-dessous.
Le répertoire /usr/share/doc/vsftpd-
— Remplacez <version-number>
/<version-number>
par le numéro de la version du paquetage vsftpd
installée sur le système. Ce répertoire contient un document README
fournissant des informations élémentaires sur le logiciel. Le fichier TUNING
contient des astuces de base pour régler la performance alors que le répertoire SECURITY/
contient des informations sur le modèle de sécurité employé par vsftpd
.
Pages de manuels de vsftpd
— Il existe un certain nombre de pages de manuel pour le démon et les fichiers de configuration. Ci-après figure une liste des pages de manuel les plus importantes.
man vsftpd
— Examine les options de ligne de commande disponibles pour vsftpd
.
man vsftpd.conf
— Contient une liste détaillée des options disponibles au sein du fichier de configuration de vsftpd
.
man 5 hosts_access
— Examine le format et les options disponibles au sein des fichiers de configuration des enveloppeurs TCP : hosts.allow
et hosts.deny
.
http://vsftpd.beasts.org/ — La page du projet vsftpd
est très utile pour trouver la documentation la plus récente et pour contacter l'auteur du logiciel.
http://slacksite.com/other/ftp.html — Ce site Web fournit une explication concise des différences existant entre FTP en mode passif et en mode actif.
http://www.ietf.org/rfc/rfc0959.txt — Une liste complète de documents RFC (de l'anglais Request for Comments) en relation avec le protocole FTP de IETF.
L'apparition du courrier électronique (ou email) remonte au début des années 1960. La boîte aux lettres se présentait sous la forme d'un fichier dans le répertoire personnel d'un utilisateur que seul ce dernier pouvait lire. Les applications de messagerie primitives ajoutaient des nouveaux messages de texte au bas du fichier et l'utilisateur devait parcourir tout le fichier qui ne cessait de grandir, afin de retrouver tout message spécifique. Ce système ne pouvait envoyer de messages qu'aux utilisateurs d'un même système.
Le premier transfert réseau d'un courrier électronique a eu lieu en 1971 lorsqu'un ingénieur informatique nommé Ray Tomlinson a envoyé un message test entre deux ordinateurs via ARPANET — le précurseur de l'Internet. De là, la popularité de la communication par email s'est rapidement développée et en moins de deux ans, elle représentait 75% du trafic d'ARPANET.
Au fil du temps, les systèmes de messagerie électronique basés sur des protocoles réseau standardisés ont évolué de telle manière qu'ils font désormais partie des services les plus couramment utilisés sur l'Internet. Red Hat Enterprise Linux offre de nombreuses applications avancées permettant de servir et d'accéder aux emails.
Ce chapitre examine d'une part les protocoles de courrier électronique utilisés à l'heure actuelle et d'autre part, certains des programmes de messagerie électronique conçus pour envoyer et recevoir des emails.
Actuellement, le courrier électronique est délivré à l'aide d'une architecture client/serveur. Un message électronique est créé au moyen d'un programme client de messagerie électronique. Ce programme envoie ensuite le message à un serveur. Ce dernier transmet à son tour le message au serveur de messagerie du destinataire où il est transmis au client de messagerie du destinataire final.
Afin de rendre ce processus possible, une vaste gamme de protocoles réseau standard permettent à différents ordinateurs exécutant souvent différents systèmes d'exploitation et utilisant des programmes de messagerie électroniques différents, d'envoyer et de recevoir des emails.
Les protocoles suivants qui sont abordés dans ce chapitre sont ceux le plus fréquemment utilisés pour le transfert de courrier électronique entre systèmes.
La livraison de courrier d'une application cliente au serveur et d'un serveur d'origine à un serveur de destination est traitée par le protocole nommé Simple Mail Transfer Protocol (ou SMTP).
L'objectif primaire de SMTP consiste à transférer le courrier électronique entre les serveurs de messagerie. Toutefois, il a également une importance critique pour les clients de messagerie. Afin d'envoyer un email, le client envoie le message électronique à un serveur de messagerie sortant, qui à son tour contacte le serveur de messagerie de destination pour la livraison du message. Dans de telles circonstances, il est nécessaire de spécifier un serveur SMTP lors de la configuration d'un client de messagerie.
Sous Red Hat Enterprise Linux, un utilisateur peut configurer un serveur SMTP sur l'ordinateur local afin qu'il traite la livraison du courrier. Toutefois, il est également possible de configurer des serveurs SMTP distants pour le courrier sortant.
Il est important de noter ici que le protocole SMTP n'a pas besoin d'authentification pour fonctionner. Ainsi, quiconque utilisant l'Internet peut envoyer des emails à toute autre personne ou même à de grands groupes de personnes. C'est cette caractéristique de SMTP qui permet l'envoi de pourriel, (aussi appelé junk email), ou spam. L'imposition de restrictions de relais empêche les utilisateurs d'envoyer des emails au travers de votre serveur SMTP à d'autres serveurs sur l'Internet. Les serveurs n'imposant pas ce genre de restrictions sont appelés serveurs relais ouvert.
Par défaut, Sendmail (/usr/sbin/sendmail
) est le programme SMTP par défaut sous Red Hat Enterprise Linux. Néanmoins, une application serveur de messagerie plus simple appelée Postfix (/usr/sbin/postfix
) est également disponible.
Pour récupérer le courrier électronique stocké sur les serveurs de messagerie, les applications client de messagerie utilisent deux protocoles primaires : Post Office Protocol (ou POP) et Internet Message Access Protocol (ou IMAP).
Sous Red Hat Enterprise Linux, le serveur POP par défaut est /usr/lib/cyrus-imapd/pop3d
qui est inclus dans le paquetage cyrus-imapd
. Lors de l'utilisation d'un serveur POP, les messages électroniques sont téléchargés par des applications client de messagerie. Par défaut, la plupart des clients de messagerie POP sont configurés automatiquement pour supprimer les messages sur le serveur une fois le transfert effectué ; toutefois, cette configuration peut souvent être modifiée.
Le protocole POP est compatible à 100 % avec des normes de messagerie Internet importantes, telles que Multipurpose Internet Mail Extensions (ou MIME), qui permet l'envoi de pièces jointes.
Le protocole POP est le plus approprié pour les utilisateurs disposant d'un système sur lequel ils peuvent lire leur courrier électronique. Il fonctionne également bien pour des utilisateurs n'ayant pas de connexion continue à l'Internet ou à un réseau sur lequel le serveur de messagerie se trouve. Malheureusement, pour les utilisateurs ayant des connexions réseau lentes, POP requiert que les programmes client, après authentification, téléchargent la totalité du contenu de chaque message. Cette opération peut être longue si certains messages contiennent des pièces jointes.
La version la plus courante du protocole POP standard est POP3.
Il existe néanmoins de nombreuses variantes moins utilisées du protocole POP :
APOP — POP3 avec authentification MDS. Un hachage codé du mot de passe de l'utilisateur est envoyé du client de messagerie au serveur plutôt qu'une version de ce dernier sous forme non-cryptée.
RPOP — POP3 avec authentification RPOP. Cette variante utilise un identificateur (ID) publié pour chaque utilisateur, semblable à un mot de passe, pour authentifier les requêtes POP. Cependant, étant donné que cet ID n'est pas crypté, RPOP n'est pas plus sécurisé que le POP standard.
Pour une sécurité accrue, il est possible d'utiliser l'encryptage Secure Socket Layer (SSL) pour l'authentification des clients et pour les sessions de transfert de données. Cette fonctionnalité peut être activée en utilisant le service ipop3s
ou le programme /usr/sbin/stunnel
. Reportez-vous à la Section 15.6.1, « Établissement d'une communication sécurisée » pour obtenir de plus amples informations.
Sous Red Hat Enterprise Linux, /usr/lib/cyrus-imapd/imapd
est le serveur IMAP par défaut, fourni par le paquetage cyrus-imapd
. Lors de l'utilisation d'un serveur de messagerie IMAP, le courrier électronique est conservé sur le serveur où les utilisateurs peuvent lire et supprimer les emails. IMAP permet également aux applications client de créer, renommer ou supprimer des répertoires de messagerie sur le serveur afin d'organiser ou de stocker le courrier électronique.
Le protocole IMAP est utile tout particulièrement pour les utilisateurs accédant à leur courrier électronique au moyen d'ordinateurs multiples. Ce protocole est également pratique pour les utilisateurs se connectant au serveur de messagerie par le biais d'une connexion lente, car seule l'information d'en-tête du message est téléchargée jusqu'à ce qu'il soit ouvert, économisant ainsi de la largeur de bande. En outre, l'utilisateur peut également supprimer des messages sans devoir les lire ou les télécharger.
Par commodité, les applications IMAP client peuvent mettre en cache localement des copies des messages afin que l'utilisateur puissent naviguer parmi des messages déjà lus même lorsqu'il n'est pas directement connecté au serveur IMAP.
IMAP, tout comme POP, est compatible à 100 % avec des normes de messagerie Internet importantes, telles que MIME (Multipurpose Internet Mail Extensions) pour permettre l'envoi de pièces jointes.
Pour une sécurité accrue, il est possible d'utiliser l'encryptage SSL pour l'authentification des clients et pour les sessions de transfert de données. Cette fonctionnalité peut être activée en utilisant le service imaps
ou le programme /usr/sbin/stunnel
. Reportez-vous à la Section 15.6.1, « Établissement d'une communication sécurisée » pour obtenir de plus amples informations.
D'autres clients et serveurs IMAP libres et commerciaux sont disponibles ; un certain nombre d'entre eux poussent encore plus les possibilités du protocole IMAP et fournissent des fonctionnalités supplémentaires. Une liste compréhensive de ces derniers est disponible en ligne à l'adresses suivante : http://www.imap.org/products/longlist.htm.
Les démons imap-login
et pop3-login
qui implémentent les protocoles IMAP et POP3 sont inclus dans le paquetage dovecot
. L'utilisation de IMAP et POP est configurée à travers dovecot
; par défaut dovecot
exécute seulement IMAP. Pour configurer dovecot
pour utiliser POP :
Éditez /etc/dovecot.conf
pour obtenir la ligne :
protocols = imap imaps pop3 pop3s
Cette modification devient opétationnelle pour la session courante grâce à l'utilisation de la commande :
/sbin/service dovecot restart
Cette modification sera opérationnelle après le prochain redémarrage grâce à la commande :
chkconfig dovecot on
Veuillez noter que dovecot
indique seulement qu'il démarre le serveur IMAP, mais il démarre aussi le serveur POP3.
Contrairement à SMTP, ces deux protocoles exigent aux clients se connectant de s'authentifier au moyen d'un nom d'utilisateur (aussi appelé identifiant) et d'un mot de passe. Par défaut, les mots de passe pour les deux protocoles sont transmis à travers le réseau de manière non-cryptée.
Pour configurer SSL sur dovecot :
éditez le fichier de configuration /etc/pki/dovecot/dovecot-openssl.conf
de dovecot
comme vous le désirez. Toutefois dans une installation standard, ce fichier ne demande pas d'être modifié.
Renommez, déplacez ou supprimez les fichiers /etc/pki/dovecot/certs/dovecot.pem
et /etc/pki/dovecot/private/dovecot.pem
.
Executez le script /usr/share/doc/dovecot-1.0/examples/mkcert.sh
, qui crée les certificats dovecot auto-signés. Les certificats sont copiés dans les répertoires /etc/pki/dovecot/certs
et /etc/pki/dovecot/private
. Pour implémenter les modifications, redémarrez dovecot
(/sbin/service dovecot restart
).
Pour plus d'informations sur dovecot
reportez-vous à http://www.dovecot.org.
D'une manière générale, toutes les applications de messagerie électronique font partie d'au moins un des trois types d'applications. Chaque type joue un rôle bien précis dans le processus de déplacement et de gestion des messages électroniques. Bien que la plupart des utilisateurs ne connaissent que le programme de courrier électronique qu'ils utilisent pour recevoir et envoyer des messages, chacun de ces trois types d'applications est important pour assurer que les messages arrivent bien à leur destination.
L'Agent de Transfert de Courrier (MTA, de l'anglais Mail Transfer Agent) sert à transférer des messages électroniques entre des hôtes utilisant SMTP. Un message peut requérir l'utilisation de plusieurs MTA lors de sa progression vers sa destination finale.
La livraison de messages entre ordinateurs peut apparaître comme étant une opération assez simple et directe, l'ensemble du processus permettant de décider si un MTA (aussi appelé MTA selon l'acronyme anglais) donné peut ou devrait accepter la livraison d'un message, est en fait assez complexe. De plus, en raison des problèmes créés par les spams, l'utilisation d'un MTA spécifique est généralement limitée par la configuration même du MTA ou par celle de l'accès au réseau sur lequel il se trouve.
De nombreux programmes clients de messagerie peuvent également être utilisés comme des MTA pour envoyer des messages électroniques. Toutefois, il ne faut pas confondre cette opération avec le rôle primaire d'un MTA. La seule raison pour laquelle les programmes clients de messagerie peuvent envoyer des messages comme le fait un MTA réside dans le fait que l'hôte exécutant l'application ne dispose pas de son propre MTA. Cette situation s'applique tout particulièrement aux programmes clients de messagerie faisant partie de systèmes d'exploitation qui ne sont pas basés sur Unix. Cependant, ces programmes clients de messagerie n'envoient que des messages de sortie à un MTA qu'ils sont autorisés à utiliser et n'acheminent pas directement le message au serveur de messagerie du destinataire souhaité.
Étant donné que Red Hat Enterprise Linux installe deux MTA, à savoir Sendmail et Postfix, les programmes clients de messagerie ne sont généralement pas sollicités pour agir en tant que MTA. Red Hat Enterprise Linux inclut également Fetchmail, un MTA doté d'un objectif bien spécifique.
Pour obtenir de plus amples informations sur Sendmail, Postfix et Fetchmail, reportez-vous à la Section 15.3, « Agent de transfert de courrier ».
Un Agent de Distribution de Courrier (MDA de l'anglais Mail Delivery Agent) est utilisé par le MTA pour distribuer le courrier arrivant dans la boîte aux lettres de l'utilisateur approprié. Dans de nombreuses situations, le MDA est en fait un Agent de Distribution Local (LDA de l'anglais Local Delivery Agent), comme mail
ou Procmail.
En fait, tout programme traitant un message à des fins de distribution jusqu'au point où il peut être lu par une application client de messagerie peut être considéré comme un MDA. Telle est la raison pour laquelle certains MTA ( comme Sendmail et Postfix) peuvent aussi jouer le rôle d'un MDA lorsqu'ils ajoutent de nouveaux messages électroniques au fichier spoule (aussi écrit spool) de courrier électronique d'un utilisateur local. En général, les MDA n'acheminent pas de messages entre les deux systèmes et ne fournissent pas d'interface utilisateur ; les MDA distribuent et classent les messages sur un ordinateur local pour qu'une application client de messagerie puisse y accéder.
Un Agent de Gestion de Courrier (MUA, de l'anglais Mail User Agent) est en fait une application client de messagerie. Un MUA est un programme qui, au minimum, permet à un utilisateur de lire et écrire des messages électroniques. De nombreux MUA peuvent récupérer des messages au moyen de protocoles POP ou IMAP, établissant des boîtes aux lettres pour stocker les messages et envoyant des messages de sortie à un MTA.
Les MUA peuvent avoir une interface très simple à base de texte comme mutt
.
Red Hat Enterprise Linux comprend deux agents MTA principaux, à savoir Sendmail et Postfix. Sendmail est configuré comme l'agent de transfert par défaut, bien que Postfix puisse facilement devenir le MTA par défaut.
La tâche principale de Sendmail, comme d'autres MTA, est de déplacer de façon sécurisée des messages électroniques entre des hôtes, utilisant généralement le protocole SMTP. Toutefois, Sendmail étant hautement configurable, il est possible de contrôler presque tous les aspects du traitement des messages, y compris le protocole à utiliser. De nombreux administrateurs système choisissent d'utiliser Sendmail comme MTA en raison de sa puissance et de sa modulabilité.
Il est important de bien comprendre ce qu'est Sendmail et ce qu'il peut faire, de même que ce qu'il n'est pas. À l'heure où des applications monolithiques jouent des rôles multiples, on pourrait penser que Sendmail est la seule application nécessaire pour exécuter un serveur de messagerie au sein d'une organisation. Techniquement parlant, c'est le cas puisque Sendmail peut non seulement spouler du courrier sur les répertoires de chaque utilisateur mais il peut également livrer des messages sortants pour les utilisateurs. Cependant, la plupart des utilisateurs demandent bien plus que le simple acheminement du courrier. Ils veulent en général interagir avec le courrier électronique à l'aide d'un MUA qui utilise POP ou IMAP pour télécharger leurs messages sur leur ordinateur local. Ou il se peut qu'ils préférent avoir une interface Web pour avoir accès à leur boîte aux lettres. Ces autres applications peuvent fonctionner conjointement avec Sendmail, mais elles existent en réalité pour des raisons différentes et peuvent fonctionner indépendamment les unes des autres.
L'explication de tout ce que Sendmail devrait et pourrait faire en fonction de sa configuration va bien au-delà de la portée de cette section. Étant donné la gamme d'options différentes et le nombre de réglages possibles, des volumes entiers ont été écrits pour expliquer toutes les possibilités de Sendmail et les façons de résoudre d'éventuels problèmes. Reportez-vous à la Section 15.7, « Ressources supplémentaires » pour obtenir une liste des ressources dédiées à Sendmail.
Cette section passe en revue les fichiers installés par défaut avec Sendmail et examine certaines modifications de configuration élémentaires, y compris comment éviter de recevoir du pourriel (ou spam) et comment augmenter les capacités de Sendmail avec le protocole Lightweight Directory Access Protocol (LDAP).
Le fichier exécutable de Sendmail est /usr/sbin/sendmail
.
Le fichier de configuration de Sendmail qui est long et détaillé se nomme /etc/mail/sendmail.cf
. Évitez d'éditer le fichier sendmail.cf
directement. Pour apporter des modifications à la configuration de Sendmail, éditez plutôt le fichier /etc/mail/sendmail.mc
, sauvegardez le fichier original /etc/mail/sendmail.cf
et utilisez les alternatives suivantes pour générer un nouveau fichier de configuration :
Utilisez le makefile incorporé dans le /etc/mail
(make all -C /etc/mail
) pour créer un nouveau fichier de configuration /etc/mail/sendmail.cf
. Tous les autres fichiers générés dans /etc/mail
(fichiers db) seront régénérés si nécessaire. Les anciennes commandes de makemap sont encore utilisables. La commande make sera automatiquement utilisée par service sendmail start | restart | reload
si le paquetage make
est installé.
Comme alternative, vous pouvez utiliser le macroprocesseur m4
incorporé pour créer un nouveau /etc/mail/sendmail.cf
.
Pour de plus amples informations sur la configuration de Sendmail reportez-vous à la Section 15.3.1.3, « Modifications courantes de la configuration de Sendmail ».
Divers fichiers de configuration Sendmail sont installés dans /etc/mail/
, notamment :
access
— Spécifie les systèmes qui peuvent utiliser Sendmail pour le courrier électronique sortant.
domaintable
— Spécifie le mappage de noms de domaine.
local-host-names
— Spécifie les alias de l'hôte.
mailertable
— Spécifie des instructions qui annulent le routage de domaines particuliers.
virtusertable
— Spécifie une forme de dénomination par alias spécifique au domaine, ce qui permet à des domaines virtuels multiples d'être hébergés sur un seul ordinateur.
Several of the configuration files in /etc/mail/
, such as access
, domaintable
, mailertable
and virtusertable
, must actually store their information in database files before Sendmail can use any configuration changes. To include any changes made to these configurations in their database files, run the following command:
makemap hash /etc/mail/
<name>
< /etc/mail/<name>
où <name>
doit être remplacé par le nom du fichier de configuration à convertir.
Par exemple, pour que tous les messages électroniques destinés au domaine example.com
soient envoyés à <bob@other-example.com>
, ajoutez la ligne reproduite ci-dessous au fichier virtusertable
:
@example.com bob@other-example.com
Pour finaliser cette modification, le fichier virtusertable.db
doit être mis à jour à l'aide de la commande suivante, en étant connecté en tant que super-utilisateur :
makemap hash /etc/mail/virtusertable < /etc/mail/virtusertable
Cela crée un fichier virtusertable.db
mis à jour, contenant la nouvelle configuration.
Lors de la modification du fichier de configuration Sendmail, il est recommandé de générer un tout nouveau fichier /etc/mail/sendmail.cf
plutôt que de modifier un fichier existant.
Avant de modifier le fichier sendmail.cf
, il est toujours conseillé d'effectuer une copie de sauvegarde de la version courante du fichier.
Pour ajouter la fonctionnalité désirée à Sendmail, éditez le fichier /etc/mail/sendmail.mc
en étant connecté en tant que super-utilisateur. Une fois cette opération terminée, utilisez le macroprocesseur m4
pour générer un nouveau fichier sendmail.cf
en exécutant la commande suivante :
m4 /etc/mail/sendmail.mc > /etc/mail/sendmail.cf
Par défaut, le macroprocesseur m4
est installé avec Sendmail mais fait partie du paquetage m4
.
Après avoir créé un nouveau fichier /etc/mail/sendmail.cf
, redémarrez Sendmail afin que les modifications soient appliquées. Pour ce faire, la meilleure façon de procéder consiste à saisir la commande suivante :
/sbin/service sendmail restart
Le fichier sendmail.cf
par défaut n'autorise pas Sendmail à accepter des connexions réseau venant de tout hôte autre que l'ordinateur local. Afin de configurer Sendmail en tant que serveur pour d'autres clients, éditez /etc/mail/sendmail.mc
et changez l'adresse spécifiée dans l'option Addr=
de la directive DAEMON_OPTIONS
de 127.0.0.1
à l'adresse IP d'un périphérique réseau actif ou supprimez tout simplement les commentaires de la directive DAEMON_OPTIONS
en ajoutant dnl
au début de la ligne. Une fois ces modifications apportées, régénérez le fichier /etc/mail/sendmail.cf
en exécutant la commande suivante :
m4 /etc/mail/sendmail.mc > /etc/mail/sendmail.cf
La configuration par défaut incluse dans Red Hat Enterprise Linux fonctionne avec la plupart des sites exclusivement SMTP, mais non avec des sites utilisant UUCP (de l'anglais UNIX to UNIX Copy). Si l'utilitaire de connexion UUCP est utilisé pour les transferts, le fichier /etc/mail/sendmail.mc
doit être reconfiguré et un nouveau fichier /etc/mail/sendmail.cf
doit être généré.
Consultez le fichier /usr/share/sendmail-cf/README
avant de modifier tout fichier contenu dans les répertoires présents sous le répertoire /usr/share/sendmail-cf
, car ils peuvent affecter la configuration future des fichiers /etc/mail/sendmail.cf
.
L'une des configurations courantes de Sendmail consiste à avoir un seul ordinateur qui agit comme passerelle de messagerie pour tous les ordinateurs sur le réseau. Par exemple, une société pourrait souhaiter qu'un ordinateur appelé mail.example.com
gère tout son courrier électronique et attribue à tous les messages sortants la même adresse de retour.
Dans ce cas de figure, le serveur Sendmail est obligé de masquer le nom des ordinateurs du réseau de la société de façon à ce que leur adresse de retour soit user@example.com
plutôt que user@host.example.com
.
Pour ce faire, ajoutez les lignes suivantes à /etc/mail/sendmail.mc
:
FEATURE(always_add_domain)dnl FEATURE(`masquerade_entire_domain')dnl FEATURE(`masquerade_envelope')dnl FEATURE(`allmasquerade')dnl MASQUERADE_AS(`bigcorp.com.')dnl MASQUERADE_DOMAIN(`bigcorp.com.')dnl MASQUERADE_AS(bigcorp.com)dnl
Une fois qu'un nouveau fichier sendmail.cf
aura été généré à l'aide de m4
, cette configuration donnera l'impression que tous les messages envoyés à partir du réseau ont été été envoyés depuis bigcorp.com
.
Les pourriels (aussi appelés spams) peuvent être définis comme étant des messages électroniques inutiles et indésirables reçus par un utilisateur qui n'a jamais demandé ce genre de communication. Il s'agit d'un abus très perturbateur, coûteux et répandu des normes de communication Internet.
Sendmail rend relativement aisé le blocage des nouvelles techniques utilisées pour envoyer des pourriels. Il bloque même par défaut, un grand nombre des méthodes d'envoi de spams les plus courantes. Les fonctionnalités anti-pourriel disponibles avec sendmail sont vérifications d'entête, déni de relais (le défaut de la version 8.9), vérifications de bases de données et des informations d'expéditeurs.
Par exemple, le réacheminement de messages SMTP, également appelé retransmission (ou relaying), a été désactivé par défaut depuis la version 8.9 de Sendmail. Avant que ce changement n'ait lieu, Sendmail dirigeait l'hôte de messagerie (x.edu
) de façon à ce qu'il accepte des messages d'un individu (y.com
) et les envoie à un autre individu (z.net
). Désormais, Sendmail doit être configuré de façon à autoriser un domaine à retransmettre du courrier par le biais du serveur. Pour configurer les domaines de retransmission, éditez le fichier /etc/mail/relay-domains
et relancez Sendmail.
Cependant, les utilisateurs sont très souvent bombardés de pourriels provenant d'autres serveurs via l'Internet. Dans ce cas, les fonctions de contrôle d'accès de Sendmail, disponibles par l'entremise du fichier /etc/mail/access
peuvent servir à empêcher les connexions en provenance d'hôtes indésirables. L'exemple suivant illustre comment utiliser ce fichier pour non seulement bloquer mais également autoriser l'accès au serveur Sendmail :
badspammer.com ERROR:550 "Go away and do not spam us anymore" tux.badspammer.com OK 10.0 RELAY
Cet exemple stipule que tout message électronique envoyé par badspammer.com
doit être bloqué à l'aide d'un code d'erreur 550 conforme à la norme RFC-821 et qu'un message doit être renvoyé à l'expéditeur de pourriel. Le courrier envoyé par le sous-domaine tux.badspammer.com
est en revanche accepté. La dernière ligne montre que tout message envoyé depuis le réseau 10.0.*.* peut être retransmis au moyen du serveur de messagerie.
Étant donné que /etc/mail/access.db
est une base de données, utilisez makemap
pour activer toute modification. Pour ce faire, tapez la commande suivante en étant connecté en tant que super-utilisateur :
makemap hash /etc/mail/access < /etc/mail/access
L'analyse d'entête de messages vous permet de rejeter le courrier basé sur le contenu de l'entête. Les serveurs SMTP stockent les informations sur le trajet d'un email dans l'entête du message. Alors que le message est acheminé d'un MTA à l'autre, chacun ajoute une entête "Reçu" au-dessus de toutes les autres entêtes "Reçu". Il est cependant important de noter que ces informations peuvent être modifiées par les expéditeurs de pourriels.
Les exemples ci-dessus n'illustrent qu'une toute petite partie du potentiel de Sendmail en termes d'autorisation ou d'interdiction d'accès. Reportez-vous au document /usr/share/sendmail-cf/README
pour obtenir de plus amples renseignements et d'autres exemples sur le sujet.
Étant donné que Sendmail fait appel au MDA Procmail pour la livraison de courriels, il est également possible d'utiliser un programme de filtrage de pourriel comme SpamAssassin, pour identifier et classer ce type de courriel à la place de l'utilisateur. Reportez-vous à la Section 15.5.2.6, « Filtres de spam » pour obtenir de plus amples informations sur l'utilisation du programme SpamAssassin.
L'utilisation de Lightweight Directory Access Protocol (LDAP) est une façon très rapide et puissante de trouver des informations spécifiques sur un utilisateur particulier appartenant à un grand groupe. Par exemple, un serveur LDAP peut servir à chercher une adresse électronique spécifique dans un répertoire d'entreprises courant à partir du nom de famille de l'utilisateur. Au niveau de ce genre d'implémentation, LDAP est très différent de Sendmail ; en effet, LDAP stocke les informations hiérarchiques des utilisateurs alors que Sendmail ne s'occupe que de recevoir le résultat de la recherche LDAP par le biais de messages électroniques pré-adressés.
Toutefois, Sendmail prend en charge une intégration beaucoup plus grande avec LDAP, là où il utilise LDAP pour remplacer des fichiers maintenus séparément, tels que aliases
et virtusertables
, sur divers serveurs de messagerie qui fonctionnent ensemble pour prendre en charge une organisation de taille moyenne ou supérieure. En bref, LDAP extraie le niveau de routage du courrier depuis Sendmail et ses fichiers de configuration séparés pour en faire un cluster LDAP puissant qui peut être influencé par de nombreuses applications différentes.
La version actuelle de Sendmail inclut la prise en charge pour LDAP. Pour étendre les possibilités de votre serveur Sendmail à l'aide de LDAP, prenez d'abord un serveur LDAP, tel que OpenLDAP, opérationnel et correctement configuré. Ensuite, modifiez votre fichier /etc/mail/sendmail.mc
pour y inclure les éléments suivants :
LDAPROUTE_DOMAIN('yourdomain.com
')dnl
FEATURE('ldap_routing')dnl
Ces instructions ne s'appliquent qu'à une configuration très élémentaire de Sendmail avec LDAP. La configuration peut être très différente de celle-ci selon votre implémentation de LDAP, en particulier lors de la configuration de plusieurs ordinateurs Sendmail destinés à utiliser un serveur LDAP commun.
Consultez /usr/share/doc/sendmail/README.cf
pour obtenir aussi bien des instructions détaillées sur la configuration de routage LDAP que des exemples.
Ensuite, recréez le fichier /etc/mail/sendmail.cf
en exécutant m4
et en redémarrant Sendmail. Reportez-vous à la Section 15.3.1.3, « Modifications courantes de la configuration de Sendmail » pour obtenir des instructions sur la manière de procéder.
Pour obtenir davantage d'informations sur LDAP, reportez-vous au Chapitre 16, Protocole LDAP (Lightweight Directory Access Protocol).
Mis au point à l'origine chez IBM par Wietse Venema, programmeur et expert en sécurité, Postfix est un MTA compatible avec Sendmail qui est conçu pour être sécurisé, rapide et facile à configurer.
Afin d'accroître la sécurité, Postfix utilise une conception modulaire dans laquelle de petits processus dotés de privilèges limités sont lancés par un démon maître (ou master). Les petits processus dotés de privilèges limités effectuent des tâches très spécifiques en relation avec les différentes étapes de livraison du courrier et sont exécutés dans un environnement dit chrooté afin de restreindre l'impact des attaques.
Pour configurer Postfix de sorte qu'il accepte des connexions réseau venant d'hôtes autres que l'ordinateur local, il suffit d'apporter quelques modifications mineures dans son fichier de configuration. Pour ceux ayant des besoins plus complexes, Postfix fournit un certain nombre d'options de configuration ainsi que des possibilités d'ajout de tiers, qui font de ce dernier un MTA non seulement riche en fonctionnalités mais également très versatile.
Les fichiers de configuration de Postfix sont lisibles par tout un chacun et prennent en charge plus de 250 directives. Contrairement à Sendmail, aucun macro-traitement n'est nécessaire pour que les modifications prennent effet et la majorité des options les plus couramment utilisées sont décrites dans le fichier contenant de nombreux commentaires.
Avant d'utiliser Postfix, le MTA par défaut doit passer de Sendmail à Postfix.
L'exécutable de Postfix est /usr/sbin/postfix
. Ce démon lance tous les processus connexes nécessaires pour traiter la livraison de courriel.
Postfix stocke ses fichiers de configuration dans le répertoire /etc/postfix/
. Ci-après figure une liste des fichiers les plus couramment utilisés :
access
— Utilisé pour le contrôle d'accès, ce fichier spécifie les hôtes qui sont autorisés à se connecter à Postfix.
aliases
— Fournit une liste configurable requise par le protocole de messagerie.
main.cf
— Représente le fichier de configuration global de Postfix. La majorité des options de configuration sont spécifiées dans ce fichier.
master.cf
— Spécifie comment Postfix interagit avec différents processus pour effectuer la livraison de courrier.
transport
— Mappe les adresses de courrier électronique pour qu'elles prennent le relais des hôtes.
Le fichier /etc/postfix/main.cf
par défaut ne permet pas à Postfix d'accepter des connexions réseau venant d'un hôte autre que l'ordinateur local. Pour obtenir des informations sur la configuration de Postfix en tant que serveur pour d'autres clients, reportez-vous à la Section 15.3.2.2, « Configuration élémentaire de Postfix ».
Lors de la modification de certaines options dans le répertoire /etc/postfix/
, il sera peut-être nécessaire de redémarrer le service postfix
afin que les modifications apportées prennent effet. Pour ce faire, la meilleure façon consiste à taper la commande suivante :
/sbin/service postfix restart
Par défaut, Postfix n'accepte pas de connexions réseau venant d'un hôte autre que l'ordinateur local. Effectuez les étapes suivantes en étant connecté en tant que super-utilisateur afin d'activer la livraison de courrier pour d'autres hôtes du réseau :
Éditez le fichier /etc/postfix/main.cf
à l'aide d'un éditeur de texte tel que vi
.
Décommentez la ligne mydomain
en supprimant le symbole dièse (#
) et remplacez domain.tld
par le nom de domaine que le serveur de messagerie sert, tel que example.com
.
Décommentez la ligne myorigin = $mydomain
.
Décommentez la ligne myhostname
et remplacez host.domain.tld
par le nom d'hôte de l'ordinateur.
Décommentez la ligne mydestination = $myhostname, localhost.$mydomain
.
Décommentez la ligne mynetworks
et remplacez 168.100.189.0/28
par un paramètre de réseau valide pour les hôtes pouvant se connecter au serveur.
Décommentez la ligne inet_interfaces = all
.
Redémarrez le service postfix
.
Une fois ces étapes effectuées, l'hôte est en mesure d'accepter la livraison d'emails venant de l'extérieur
Postfix dispose d'une grande gamme d'options de configuration. Une des meilleures façons d'apprendre comment configurer Postfix consiste à lire les commentaires dans /etc/postfix/main.cf
. Des ressources supplémentaires incluant des informations sur LDAP et l'intégration de SpamAssassin sont disponibles en ligne à l'adresse suivante : http://www.postfix.org/.
Fetchmail est un MTA qui récupère du courrier électronique depuis des serveurs distants et le transfère au MTA local. De nombreux utilisateurs apprécient la possibilité de pouvoir séparer le processus de téléchargement de leurs messages stockés sur un serveur distant, du processus de lecture et d'organisation de leur courrier dans un MUA. Conçu tout spécialement pour les utilisateurs à accès par ligne commutée, Fetchmail se connecte et télécharge rapidement tous les messages électroniques dans le fichier spoule de messagerie à l'aide de nombreux protocoles différents parmi lesquels figurent POP3 et IMAP. Il permet même de réacheminer vos messages vers un serveur SMTP, si nécessaire.
Fetchmail est configuré pour chaque utilisateur grâce à un fichier .fetchmailrc
dans le répertoire personnel de l'utilisateur.
Sur la base des préférences spécifiées dans le fichier .fetchmailrc
, Fetchmail recherche les messages électroniques sur un serveur distant et les télécharge. Il les achemine ensuite sur le port 25 de l'ordinateur local, au moyen du MTA local, pour les placer dans le fichier spoule de l'utilisateur approprié. Si Procmail est disponible, il peut être utilisé pour filtrer les messages et les placer dans une boîte aux lettres de sorte qu'ils puissent être lus avec par un MUA.
Bien qu'il soit possible de passer toutes les options nécessaires pour vérifier le courrier sur un serveur distant depuis la ligne de commande lors de l'exécution de Fetchmail, il est beaucoup plus simple d'utiliser un fichier .fetchmailrc
. Insérez toutes les options de configuration souhaitées dans le fichier .fetchmailrc
et ces options seront alors utilisées lors de chaque exécution de la commande fetchmail
. Il est possible d'annuler toute option lors du lancement de Fetchmail en spécifiant l'option en question sur la ligne de commande.
Le fichier .fetchmailrc
d'un utilisateur contient trois types d'options de configuration :
Options globales — Ce type d'options donne à Fetchmail des instructions qui contrôlent le fonctionnement du programme ou fournit des réglages pour toute connexion afin de vérifier le courrier.
Options serveur — Ce type d'options spécifie les informations nécessaires concernant le serveur sondé, telles que le nom d'hôte ainsi que les préférences relatives aux serveurs de messagerie spécifiques, comme le port à vérifier ou le nombre de secondes devant s'écouler avant l'interruption de la connexion. Ces options affectent tout utilisateur employant ce serveur.
Options utilisateur — Ce type d'options contient des informations, telles que le nom d'utilisateur et le mot de passe, nécessaires à l'authentification et la vérification du courrier à l'aide d'un serveur de messagerie donné.
Les options globales apparaissent en haut du fichier de configuration .fetchmailrc
, suivies d'une ou plusieurs options serveur, précisant chacune un serveur de messagerie différent sur lequel Fetchmail devrait vérifier le courrier. Les options utilisateur suivent les options serveur pour chaque compte utilisateur devant être vérifié sur ce serveur de messagerie. Tout comme pour les options serveur, il est possible de spécifier non seulement de multiples options utilisateur à employer avec un serveur donné, mais il est également possible de vérifier plusieurs comptes de messagerie sur un même serveur.
Les options serveur à utiliser sont appelées dans le fichier .fetchmailrc
grâce à l'emploi d'un verbe d'option spécial, poll
ou skip
, qui précède toute information concernant le serveur. L'action poll
indique à Fetchmail d'utiliser cette option serveur lorsqu'il est exécuté ; il vérifie en fait le courrier à l'aide des différentes options utilisateur. Toute option serveur placée après une action skip
contourne les opérations de vérification, à moins que le nom d'hôte de ce serveur ne soit spécifié lorsque Fetchmail est invoqué. L'option skip
est utile lors du test de configurations dans .fetchmailrc
car elle vérifie les serveurs avec cette option uniquement lorsqu'ils sont invoqués spécifiquement et n'affecte pas les configurations actuelles.
Un exemple de fichier .fetchmailrc
ressemble à l'extrait suivant :
set postmaster "user1" set bouncemail poll pop.domain.com proto pop3 user 'user1' there with password 'secret' is user1 here poll mail.domain2.com user 'user5' there with password 'secret2' is user1 here user 'user7' there with password 'secret3' is user1 here
Dans cet exemple, les options globales sont configurées de façon à ce que l'utilisateur reçoive le courrier seulement en dernier ressort (option postmaster
) et que toutes les erreurs soient envoyées au maître de poste (ou postmaster) plutôt qu'à l'expéditeur (option bouncemail
). L'action set
indique à Fetchmail que cette ligne contient une option globale. Ensuite, deux serveurs de messagerie sont spécifiés ; le premier est configuré pour vérifier POP3 et le second pour essayer divers protocoles afin d'en trouver un qui fonctionne. Deux utilisateurs sont vérifiés dans le cas de la seconde option de serveur, mais tout message électronique trouvé pour l'un ou l'autre des utilisateurs est envoyé dans le fichier spoule de messagerie de l'utilisateur No. 1 (ou user1
). Ainsi, il est possible de vérifier de multiples boîtes aux lettres sur plusieurs serveurs, tout en utilisant une une seule corbeille d'arrivée pour le MUA. Toute information spécifique à chacun des utilisateurs commence par l'action user
.
Les utilisateurs ne doivent pas placer leur mot de passe dans le fichier .fetchmailrc
. Si la section with password '<password>'
est omise, Fetchmail demandera la saisie d'un mot de passe lors de son lancement.
Fetchmail offre de nombreuses options aussi bien globales que locales ou serveur. Beaucoup d'entre elles sont rarement utilisées ou ne s'appliquent qu'à des situations très particulières. La page de manuel de fetchmail
explique chacune de ces options de façon détaillée, mais les options les plus courantes sont énumérées ci-dessous.
Chaque option globale devrait être placée sur une seule ligne après une action set
.
daemon
— Spécifie le mode démon où Fetchmail demeure en tâche de fond. Remplacez <seconds>
<seconds>
par la durée en secondes pendant laquelle Fetchmail doit attendre avant de sonder le serveur.
postmaster
— Spécifie un utilisateur local auquel envoyer le courrier en cas de problèmes de distribution.
syslog
— Spécifie le fichier journal pour l'enregistrement des messages d'erreurs et d'état. La valeur /var/log/maillog
est retenue par défaut.
Les options serveur doivent figurer sur leur propre ligne dans .fetchmailrc
, après une action poll
ou skip
.
auth
— Remplacez <auth-type>
<auth-type>
par le type d'authentification à utiliser. Par défaut, l'authentification password
est utilisée, mais certains protocoles prennent en charge d'autres types d'authentification, notamment kerberos_v5
, kerberos_v4
, et ssh
. Si le type d'authentification any
est retenu, Fetchmail essaiera d'abord des méthodes qui ne nécessitent aucun mot de passe, puis des méthodes qui masquent le mot de passe et, en dernier ressort, il essaiera d'envoyer le mot de passe en texte clair pour effectuer l'authentification auprès du serveur.
interval
— Indique à Fetchmail de sonder seulement le serveur spécifié après avoir vérifié le courrier sur tous les serveurs configurés un certain nombre de fois (où <number>
représente ce nombre de fois). Cette option est généralement utilisée pour les serveurs de messagerie sur lesquels un utilisateur ne reçoit que rarement des messages.
<number>
port
— Remplacez <port-number>
<port-number>
par le numéro du port. Cette valeur annule le numéro du port par défaut pour un protocole spécifié.
proto
— Remplacez <protocol>
<protocol>
par le protocole, tel que pop3
ou imap
, devant être utilisé pour vérifier le courrier sur le serveur.
timeout
— Remplacez <seconds>
<seconds>
par la durée d'inactivité du serveur (exprimée en secondes) après laquelle Fetchmail abandonne une tentative de connexion. Si cette valeur n'est pas configurée, le système retient une valeur par défaut de 300
secondes.
Les options utilisateur peuvent être placées sur leurs propres lignes sous une option serveur ou alors sur la même ligne que l'option serveur. Dans les deux cas, les options définies doivent suivre l'option user
(définie ci-dessous).
fetchall
— Donne l'ordre à Fetchmail de télécharger tous les messages de la file d'attente, y compris les messages qui ont déjà été visualisés. Par défaut, Fetchmail ne récupère que les nouveaux messages.
fetchlimit
— Remplacez <number>
<number>
par le nombre de messages à extraire avant de s'arrêter.
flush
— Donne l'instruction à Fetchmail de supprimer tous les messages de la file d'attente qui ont été lus précédemment avant d'extraire les nouveaux messages.
limit
— Remplacez <max-number-bytes>
<max-number-bytes>
par la taille maximale en octets autorisée pour des messages lors de leur extraction. Cette option est pratique lors de connexions réseau lentes, particulièrement lorsqu'un gros message prend trop de temps à être téléchargé.
password '
— Remplacez <password>
'<password>
par le mot de passe de l'utilisateur.
preconnect "
— Remplacez <command>
"<command>
par une commande à exécuter avant de récupérer les messages pour cet utilisateur.
postconnect "
— Remplacez <command>
"<command>
par une commande à exécuter après avoir récupéré les messages pour cet utilisateur.
ssl
— Active l'encryptage SSL.
user "
— Remplacez <username>
"<username>
par le nom d'utilisateur employé par Fetchmail pour récupérer les messages électroniques. Cette option doit être placée avant toute autre option utilisateur.
La plupart des options utilisées en ligne de commande lors de l'exécution de la commande fetchmail
, répliquent les options de configuration de .fetchmailrc
. Ainsi, Fetchmail peut être utilisé avec ou sans fichier de configuration. Ces options ne sont pas utilisées en ligne de commande par la plupart des utilisateurs car il est plus simple de les laisser dans le fichier .fetchmailrc
.
Toutefois, il se peut que dans certaines situations la commande fetchmail
doive être exécutée avec d'autres options dans un but bien précis. Il est possible d'exécuter des options de commande afin d'annuler temporairement un paramètre de .fetchmailrc
qui crée une erreur étant donné que toute option spécifiée en ligne de commande annule les options contenues dans le fichier de configuration.
Certaines options utilisées après la commande fetchmail
permettent d'obtenir des informations importantes.
--configdump
— Affiche toutes les options possibles sur la base des informations fournies pas .fetchmailrc
et les valeurs par défaut de Fetchmail. Lors de l'utilisation de cette option, aucun message électronique n'est téléchargé pour quelque utilisateur que ce soit.
-s
— Exécute Fetchmail en mode silencieux, empêchant tout message, autre que des messages d'erreurs, d'apparaître après la commande fetchmail
.
-v
— Exécute Fetchmail en mode verbeux, affichant toute communication entre Fetchmail et les serveurs de messagerie distants.
-V
— Affiche des informations détaillées sur la version utilisée, dresse la liste de ses options globales et fournit les paramètres à employer pour chaque utilisateur, y compris le protocole de messagerie et la méthode d'authentification. Lors de l'utilisation de cette option, aucun courrier électronique n'est récupéré pour quelque utilisateur que ce soit.
Ces options peuvent parfois être pratiques pour annuler les valeurs par défaut qui se trouvent souvent dans le fichier .fetchmailrc
.
-a
— Indique à Fetchmail de télécharger tous les messages depuis le serveur de messagerie distant, qu'ils soient nouveaux ou qu'ils aient déjà été consultés. Par défaut, Fetchmail ne télécharge que les nouveaux messages.
-k
— Fetchmail laisse les messages sur le serveur de messagerie distant après les avoir téléchargés. Cette option annule le comportement par défaut consistant à supprimer les messages après les avoir téléchargés.
-l
— Fetchmail ne télécharge pas les messages dont la taille est supérieure à la taille spécifiée et les laisse sur le serveur de messagerie distant.
<max-number-bytes>
--quit
— Quitte le processus du démon Fetchmail.
D'autres commandes et options .fetchmailrc
sont offertes dans la page de manuel de fetchmail
.
Un Agent de transport de courrier (MTA) est essentiel dans l'envoi de courriels. Un Agent de courrier utilisateur (MUA) comme Evolution, Thunderbird, et Mutt, est utilisé pour lire et composer les courriels. Quand un utilisateur envoie un email depuis un MUA, le message est passé au MTA, qui l'envoie à travers une série de MTA jusqu'à ce qu'il atteigne sa destination.
Même si un utilisateur n'a pas l'intention d'envoyer du courrier depuis le système, quelques tâches automatisées ou applications système peuvent utiliser la commande /bin/mail
pour envoyer des courriels contenant des messages journal à l'utilisateur du système local.
Red Hat Enterprise Linux 5 fournit trois MTA : Sendmail, Postfix, et Exim. Si les trois sont installés, sendmail
est le MTA par défaut. Le Commutateur d'agent de transport de courrier permet le sélection de sendmail
, postfix
, ou exim
en tant que MTA par défaut pour le système.
Le paquetage RPM system-switch-mail
doit être installé pour utiliser la version en mode texte du programme du Commutateur d'agent de transport de courrier. Si vous désirez utiliser la version graphique, le paquetage system-switch-mail-gnome
doit aussi être installé.
Pour démarrer le Commutateur d'agent de transport de courrier, sélectionnez Système (le menu principal sur le panneau)=> Administration => Commutateur d'agent de transport de courrier, ou saisissez la commande system-switch-mail
à l'invite du shell (par exemple, dans un terminal XTerm ou GNOME).
Le programme détecte automatiquement si le système X Window est en exécution. S'il l'est, le programme démarre en mode graphique comme indiqué dans la Figure 15.1, « Commutateur d'agent de transport de courrier ». Si X n'est pas détecté, il démarre en mode texte. Pour forcer le Commutateur d'agent de transport de courrier à être exécuté en mode texte, utilisez la commande system-switch-mail-nox
.
La copie d'écran du Commutateur d'agent de transport de courrier
Si vous sélectionnez Valider pour changer le MTA, le démon de courrier sélectionné est activé pour démarrer à l'amorçage, et les démons de courrier qui ne sont pas sélectionnés sont désactivés pour qu'ils ne démarrent pas à l'amorçage. Le démon de courrier sélectionné est démarré et tout autre démon de courrier est arrêté ; ainsi les modifications prennent effet immédiatement.
Red Hat Enterprise Linux inclut deux MDA principaux, à savoir Procmail et mail
. Ces deux applications sont considérées comme des agents de distribution locaux (ou LDA) et elles acheminent toutes les deux le courrier électronique du fichier spoule d'un MDA vers la boîte aux lettres de l'utilisateur. Toutefois, Procmail fournit un système de filtrage robuste.
Cette section examine seulement Procmail de façon détaillée. Pour toute information sur la commande mail
, consultez la page de manuel qui lui est dédié.
Procmail distribue et filtre le courrier électronique dès qu'il est placé dans le fichier spoule de messagerie de l'hôte local. Il est puissant, peu exigeant en matière de ressources système et d'une utilisation courante. Procmail peut jouer un rôle critique dans la distribution du courrier qui sera lu par les applications client de messagerie.
Il existe différentes façons d'invoquer Procmail. Dès qu'un MTA dépose un message dans le fichier spoule de messagerie, Procmail est lancé. Ce dernier filtre et classe alors le message de manière à ce que le MUA puisse le trouver puis il quitte le processus. Le MUA peut également être configuré de sorte qu'il exécute Procmail chaque fois qu'un message est reçu afin que le courrier soit acheminé vers les boîtes aux lettres appropriées. Par défaut, la présence d'un fichier /etc/procmailrc
ou d'un fichier .procmailrc
(aussi appelé un fichier rc) dans le répertoire personnel d'un utilisateur invoquera Procmail dès qu'un MTA reçoit un nouveau message.
Toute action effectuée par Procmail sur un message électronique dépend de la capacité du message à satisfaire un ensemble de conditions ou recettes (aussi appelées recipes selon le terme anglais) particulières contenues dans le fichier rc
. Si un message satisfait une recette, il peut alors être placé dans un fichier donné, être supprimé ou être traité d'une autre façon.
Lors du démarrage de Procmail, ce dernier lit les messages électroniques et sépare les informations relatives au corps du message de celles concernant l'en-tête. Ensuite, Procmail cherche les fichiers /etc/procmailrc
et rc
dans le répertoire /etc/procmailrcs
pour trouver les variables d'environnement et recettes de Procmail s'appliquant par défaut à l'ensemble du système. Procmail cherche ensuite un fichier .procmailrc
dans le répertoire personnel de l'utilisateur. De nombreux utilisateurs créent des fichiers rc
supplémentaires pour Procmail, qui sont référencés dans leur fichier .procmailrc
présent dans leur répertoire personnel.
Par défaut, aucun fichier rc
s'appliquant à l'ensemble du système n'existe dans le répertoire /etc
et aucun fichier .procmailrc
n'existe dans le répertoire personnel de quelque utilisateur que ce soit. Par conséquent, pour utiliser Procmail, chaque utilisateur doit créer un fichier .procmailrc
contenant des variables d'environnement et des règles spécifiques.
Les fichiers de configuration de Procmail contiennent des variables d'environnement importantes. Ces dernières précisent à Procmail les messages spécifiques devant être triés et le sort des messages qui ne satisfont aucune recette.
Ces variables d'environnement qui se trouvent généralement au début du fichier .procmailrc
ont le format suivant :
<env-variable>
="<value>
"
Dans cet exemple,
correspond au nom de la variable alors que l'élément <env-variable>
définit la variable elle-même.
<value>
De nombreuses variables d'environnement ne sont pas employées par la plupart des utilisateurs de Procmail et les plus importantes sont déjà définies par une valeur par défaut. Généralement, les variables suivantes sont utilisées :
DEFAULT
— Définit la boîte aux lettres où seront placés les messages qui ne satisfont aucune recette.
La valeur par défaut de DEFAULT
est la même que $ORGMAIL
.
INCLUDERC
— Spécifie des fichiers rc
supplémentaires qui contiennent d'autres recettes que les messages doivent satisfaire. Ceci permet de diviser les listes de recettes Procmail en fichiers individuels qui jouent différents rôles, tels que le blocage de pourriels et la gestion de listes d'adresses électroniques, qui peuvent ensuite être activées ou désactivées à l'aide de caractères de commentaire dans le fichier .procmailrc
de l'utilisateur.
Par exemple, des lignes présentes dans un fichier .procmailrc
de l'utilisateur peuvent ressembler à l'extrait suivant :
MAILDIR=$HOME/Msgs INCLUDERC=$MAILDIR/lists.rc INCLUDERC=$MAILDIR/spam.rc
Si l'utilisateur souhaite désactiver le filtrage par Procmail de ses listes d'adresses, mais désire garder le contrôle du pourriel, il n'a qu'à commenter la première ligne INCLUDERC
avec le symbole dièse (#
).
LOCKSLEEP
— Définit la durée, en secondes, s'écoulant entre les tentatives de Procmail d'utiliser un fichier de verrouillage spécifique. La valeur par défaut est de huit secondes.
LOCKTIMEOUT
— Définit la durée, en secondes, qui doit s'écouler après la dernière modification d'un fichier de verrouillage avant que Procmail ne considère le fichier de verrouillage comme étant vieux et pouvant par conséquent être supprimé. La valeur par défaut est de 1024 secondes.
LOGFILE
— Représente le fichier dans lequel toutes les informations de Procmail ou tous les messages d'erreurs sont enregistrés.
MAILDIR
— Définit le répertoire de travail courant pour Procmail. Si cette variable est déterminée, tous les autres chemins d'accès vers Procmail sont relatifs à ce répertoire.
ORGMAIL
— Spécifie la boîte aux lettres originale ou un autre endroit où placer les messages s'ils ne peuvent être placés à l'emplacement par défaut ou à celui exigé par les recettes.
Par défaut, une valeur de /var/spool/mail/$LOGNAME
est utilisée.
SUSPEND
— Définit la durée, en secondes, pendant laquelle Procmail s'arrête si une ressource nécessaire, telle que l'espace swap, n'est pas disponible.
SWITCHRC
— Permet à un utilisateur de spécifier un fichier externe contenant des recettes Procmail supplémentaires, plus ou moins comme le fait l'option INCLUDERC
, sauf que la vérification des recettes est arrêtée sur le fichier de configuration traitant et que seules les recettes du fichier spécifié avec SWITCHRC
sont utilisées.
VERBOSE
— Fait en sorte que Procmail journalise davantage d'informations. Cette option est pratique pour le débogage.
D'autres variables d'environnement importantes sont obtenues depuis le shell, comme LOGNAME
, qui est le nom de connexion ; HOME
, qui est l'emplacement du répertoire personnel ; et SHELL
, qui est le shell par défaut.
Consultez la page de manuel de procmailrc
pour obtenir des explications exhaustives sur les variables d'environnement ainsi que sur leurs valeurs par défaut.
Les nouveaux utilisateurs trouvent généralement que les recettes constituent l'élément le plus difficile de l'apprentissage de l'utilisation de Procmail. Ce sentiment est compréhensible jusqu'à un certain point, étant donné que les recettes effectuent la comparaison avec les messages à l'aide d'expressions régulières, qui est un format spécifique utilisé pour spécifier des qualifications de concordance de chaînes. Ceci étant, les expressions régulières ne sont pas très difficiles à créer et sont encore moins difficiles à comprendre en les lisant. De plus, la cohérence avec laquelle les recettes Procmail sont écrites, sans tenir compte des expressions régulières, permet d'acquérir de bonnes connaissances facilement, simplement en examinant les exemples. Pour consulter des exemples de recette Procmail, reportez-vous à la Section 15.5.2.5, « Exemples de recettes ».
Les recettes Procmail se présentent sous la forme suivante :
:0<flags>: <lockfile-name>
* <special-condition-character>
<condition-1>
* <special-condition-character>
<condition-2>
* <special-condition-character>
<condition-N>
<special-action-character>
<action-to-perform>
Les deux premiers caractères d'une recette Procmail sont le symbole des deux-points et un zéro. Divers indicateurs peuvent être placés après le zéro pour contrôler la manière selon laquelle Procmail traite la recette. Le symbole des deux-points placé après la section
spécifie qu'un fichier de verrouillage (lockfile) sera créé pour ce message. Si un fichier de verrouillage est créé, le nom peut être spécifié dans l'espace <flags>
.
<lockfile-name>
Une recette peut contenir plusieurs conditions servant à vérifier la concordance d'un message. S'il aucune condition n'est spécifiée, tous les messages auront une concordance positive avec la recette. Les expressions régulières sont placées dans certaines conditions de façon à faciliter la concordance avec les messages. Si des conditions multiples sont utilisées, elles doivent toutes obtenir la concordance pour que l'action soit exécutée. Les conditions sont vérifiées sur la base des indicateurs spécifiés dans la première ligne de la recette. Des caractères spéciaux facultatifs placés après le caractère *
permettent de contrôler ultérieurement la condition.
L'option
spécifie l'action exécutée lorsque le message correspond à l'une des conditions. Il ne peut y avoir qu'une action par recette. Dans de nombreux cas, le nom d'une boîte aux lettres est utilisé ici pour envoyer dans ce fichier les messages satisfaisant les conditions, permettant ainsi de trier le courrier. Des caractères d'action spéciaux peuvent également être utilisés avant que l'action ne soit spécifiée. Reportez-vous à la Section 15.5.2.4, « Conditions et actions spéciales » pour obtenir de plus amples informations.
<action-to-perform>
L'action utilisée si la recette correspond à un message donné détermine si cette dernière est considérée comme étant une recette de distribution ou de non-distribution. Une recette de distribution contient une action qui écrit le message dans un fichier, envoie le message à un autre programme ou réachemine le message vers une autre adresse électronique. Une recette de non-distribution couvre toutes les autres actions, telles que l'utilisation d'un bloc d'imbrication (également appelé nesting block). Un bloc d'imbrication est un ensemble d'actions contenues entre deux accolades, {
}
, qui sont exécutées sur des messages satisfaisant les conditions de la recette. Les blocs d'imbrication peuvent être emboîtés les uns dans les autres, offrant ainsi plus de contrôle pour l'identification et l'exécution d'actions sur des messages.
Lorsque des messages satisfont une recette de distribution, Procmail effectue l'action spécifiée et arrête de comparer le message à toute autre recette. Les messages qui satisfont les recettes de non-distribution continuent eux à être comparés aux autres recettes.
Les indicateurs (ou flags) sont très importants pour déterminer la façon dont les conditions d'une recette sont comparées à un message. Les indicateurs suivants sont couramment utilisés :
A
— Spécifie que cette recette n'est utilisée que si la recette précédente sans indicateur A
ou a
a également obtenu la concordance avec ce message.
a
— Spécifie que cette recette n'est utilisée que si la recette précédente sans indicateur A
ou a
a également obtenu la concordance avec ce message et a été exécutée avec succès.
B
— Analyse le corps du message et recherche des conditions de concordance.
b
— Utilise le corps du message dans toute action découlant de cet indicateur, comme l'écriture du message dans un fichier ou son réacheminement. Il s'agit du comportement par défaut.
c
— Génère une copie conforme du message électronique. Cette option peut être utile avec les recettes de distribution, étant donné que l'action requise peut être exécutée sur le message et que la copie du message peut continuer à être traitée dans les fichiers rc
.
D
— Rend la comparaison egrep
sensible à la casse. Par défaut, le processus de comparaison n'est pas sensible à la casse.
E
— Semblable à l'indicateur A
sauf que les conditions dans cette recette sont comparées à un message seulement si la recette précédant immédiatement et sans indicateur E
n'a pas obtenu la concordance. Cette action ressemble à une action else.
e
— Établit la comparaison de la recette au message seulement si l'action spécifiée dans la recette présente juste avant échoue.
f
— Utilise le tube comme filtre.
H
— Analyse l'en-tête du message et recherche des conditions de concordance. Cette situation se produit par défaut.
h
— Utilise l'en-tête dans une action découlant de cet indicateur. Ce dernier représente le comportement par défaut.
w
— Indique à Procmail d'attendre que le filtre ou le programme spécifiés aient terminé leurs opérations et rapporte si l'opération précédente a réussi ou échoué, avant de considérer le message comme étant filtré.
W
— Identique à w
sauf que les messages de type "Échec du programme" sont supprimés.
Pour obtenir une liste détaillée d'indicateurs supplémentaires, reportez-vous à la page de manuel de procmailrc
.
Les fichiers de verrouillage sont très utiles avec Procmail pour garantir que seul un processus essaie de modifier un certain message à un moment donné. Il est possible de spécifier un fichier de verrouillage local en plaçant le symbole des deux points (:
) après tout indicateur dans la première ligne d'une recette. Ce faisant, un fichier de verrouillage local est créé en fonction du nom de fichier de destination et de toute valeur contenue dans la variable d'environnement globale LOCKEXT
.
Vous pouvez aussi spécifier le nom du fichier de verrouillage local à utiliser avec cette recette après le symbole des deux points.
Des caractères spéciaux utilisés avant les conditions de recettes et les actions de Procmail modifient la façon dont elles sont interprétées.
Les caractères suivants peuvent être utilisés après le symbole *
au début de la ligne de condition d'une recette :
!
— Placé dans la ligne de condition, ce caractère inverse la condition, de sorte que la concordance sera désormais établie seulement si la condition ne satisfait pas le message.
<
— Vérifie si la taille du message est inférieure à un nombre d'octets spécifié.
>
— Vérifie si la taille du message est supérieure à un nombre d'octets spécifié.
Les caractères suivants sont utilisés pour exécuter des actions spéciales :
!
— Placé dans la ligne d'action, ce caractère indique à Procmail de réacheminer le message vers les adresses électroniques spécifiées.
$
— Renvoie à une variable définie précédemment dans le fichier rc
. Cette option est généralement utilisée pour définir une boîte aux lettres commune à laquelle diverses recettes feront référence.
|
— Démarre un programme spécifié afin qu'il traite le message.
{
et }
— Construit un bloc d'imbrication, utilisé pour contenir des recettes supplémentaires à appliquer aux messages satisfaisant les conditions.
Si aucun caractère spécial n'est utilisé au début de la ligne d'action, Procmail considère que la ligne d'action spécifie la boîte aux lettres où les messages doivent être déposés.
Procmail est certes un programme extrêmement flexible, mais en raison de cette flexibilité, la création de recettes Procmail de toutes pièces peut être une tâche difficile pour de nouveaux utilisateurs.
La meilleure façon de développer les capacités nécessaires pour créer les conditions des recettes Procmail consiste à bien comprendre la notion d'expressions régulières et à examiner de nombreux exemples élaborés par d'autres. Une explication exhaustive des expressions régulières va au-delà de la portée de cette section. La structure des recettes Procmail, ainsi que des exemples de recettes Procmail sont disponibles à différents endroits sur Internet (notamment à l'adresse suivante :http://www.iki.fi/era/procmail/links.html). En examinant ces exemples de recettes, il est possible d'acquérir des connaissances solides sur la bonne utilisation et sur l'adaptation des expressions régulières. En outre, des informations élémentaires sur des règles d'expressions régulières de base se trouvent dans la page de manuel de grep
.
Les simples exemples reproduits ci-dessous illustrent la structure élémentaire de recettes Procmail et peuvent servir de base pour des conceptions plus élaborées.
Une recette élémentaire ne contient pas forcément de conditions, comme le montre l'exemple ci-dessous :
:0: new-mail.spool
La première ligne spécifie qu'un fichier de verrouillage local doit être créé, mais n'indique aucun nom. Procmail utilise donc le nom du fichier de destination et y ajoute la valeur spécifiée dans la variable d'environnement LOCKEXT
. Étant donné qu'aucune condition n'est spécifiée, tous les messages satisfont cette recette et sont par conséquent placés dans le fichier spoule unique appelé new-mail.spool
qui se trouve dans le répertoire spécifié par la variable d'environnement MAILDIR
. Un MUA peut ensuite visualiser les messages dans ce fichier.
Une recette de base, telle que celle-ci, peut être placée à la fin de tous les fichiers rc
afin que les messages soient acheminés vers un emplacement par défaut.
L'exemple ci-dessous illustre l'etablissement de la concordance avec des messages d'une adresse électronique spécifique et le dépôt de ces derniers dans la corbeille.
:0 * ^From: spammer@domain.com /dev/null
Dans cet exemple, tout message envoyé par spammer@domain.com
est acheminé vers le périphérique /dev/null
où il est supprimé.
Assurez-vous que les règles fonctionnent bien comme vous le désirez avant d'acheminer les messages concernés vers /dev/null
afin qu'ils soient supprimés de façon permanente. Si les conditions de votre recette retiennent accidentellement des messages qui ne devraient pas l'être et qu'ils disparaissent sans laisser de trace, il est alors difficile de résoudre tout problème lié à la règle.
Une solution plus appropriée consiste à pointer l'action de la recette vers une boîte aux lettres spéciale qui peut être vérifiée de temps en temps, afin de voir si elle contient de fausses concordances. Une fois convaincu qu'aucun message ne fait l'objet d'une concordance accidentelle, supprimez la boîte aux lettres et établissez l'action de façon à ce qu'elle envoie les messages vers /dev/null
.
La recette ci-dessous retient les messages envoyés depuis une liste de diffusion spécifique et les place dans un dossier déterminé.
:0: * ^(From|CC|To).*tux-lug tuxlug
Tout message envoyé depuis la liste de diffusion tux-lug@domain.com
est automatiquement placé dans la boîte aux lettres tuxlug
pour le MUA. Notez que la condition dans cet exemple a une concordance avec le message si l'adresse électronique de la liste de diffusion se trouve sur l'une des lignes suivantes : From
(De), CC
ou To
(À).
Pour obtenir des informations plus détaillées et plus puissantes sur les recettes, consultez l'une des nombreuses ressources disponibles dans la Section 15.7, « Ressources supplémentaires ».
Puisque Procmail est appelé par Sendmail, Postfix et Fetchmail lors de la réception de nouveaux messages, il peut être utilisé comme un outil puissant pour combattre le pourriel.
Le combat contre le pourriel est encore plus efficace lorsque Procmail est utilisé de concert avec SpamAssassin. En effet, grâce à une double action ces deux applications peuvent rapidement identifier des messages-pourriel, les trier et les détruire.
SpamAssassin recours à une analyse de l'en-tête et du texte, à des listes noires et à des bases de données de localisation de spam ainsi qu'à une analyse bayesienne auto-organisatrice de pourriel pour identifier et étiqueter rapidement et précisément tout pourriel (aussi appelé spam).
Pour un utilisateur local, la meilleure façon d'utiliser SpamAssassin consiste à insérer la ligne suivante vers le haut du fichier ~/.procmailrc
:
INCLUDERC=/etc/mail/spamassassin/spamassassin-default.rc
Le programme /etc/mail/spamassassin/spamassassin-default.rc
contient une simple règle Procmail permettant d'activer SpamAssassin pour tout courrier électronique reçu. Si un message est reconnu comme étant un pourriel, il est étiqueté en tant que tel dans l'en-tête et la mention suivante est ajoutée au sujet :
*****SPAM*****
Le corps du message de l'email est précédé d'un compte-rendu des éléments ayant justifié le diagnostique de spam.
Pour classer les emails étiquetés en tant que pourriel, il est possible d'utiliser une règle semblable à celle reproduite ci-dessous :
:0 Hw * ^X-Spam-Status: Yes spam
Selon cette règle, tous les messages étiquetés en tant que spam dans l'en-tête sont rangés dans une boîte aux lettres nommée spam
.
Étant donné que SpamAssassin est un script Perl, il sera peut-être nécessaire d'utiliser le démon binaire SpamAssassin (spamd
) et l'application client (spamc
) sur des serveurs très sollicités. Pour configurer SpamAssassin de la sorte, il est nécessaire d'avoir un accès super-utilisateur à l'hôte.
Pour lancer le démon spamd
, tapez la commande suivante en étant connecté en tant que super-utilisateur :
/sbin/service spamassassin start
Pour lancer le démon SpamAssassin lors du démarrage du système, utilisez un utilitaire initscript, comme l'Outil de configuration des services (system-config-services
), pour activer le service spamassassin
. Veuillez-vous y reporter pour de plus amples informations.
Pour configurer Procmail afin qu'il utilise l'application client SpamAssassin au lieu du script Perl, placez le ligne suivante vers le haut du fichier ~/.procmailrc
. Pour une configuration s'appliquant à tout le système, placez cette dernière dans /etc/procmailrc
:
INCLUDERC=/etc/mail/spamassassin/spamassassin-spamc.rc
De nombreux progammes de messagerie sont disponibles sous Red Hat Enterprise Linux. Ce sont des programmes clients de messagerie graphiques et riches en fonctionnalités, tels que Ximian Evolution, ainsi que des programmes de messagerie basés sur du texte tel que mutt
.
Le reste de cette section se concentre sur l'établissement d'une communication sécurisée entre le client et le serveur.
Parmi les MUA très utilisés fournis avec Red Hat Enterprise Linux figurent Ximian Evolution et mutt
qui offrent des sessions de messagerie cryptées avec SSL.
Comme pour tout autre service voyageant sur un réseau non-crypté, des informations de messagerie importantes comme les noms d'utilisateur, mots de passe voire des messages entiers, peuvent être interceptées et lues par des utilisateurs du réseau. En outre, étant donné que les protocoles POP et IMAP standards transfèrent les informations d'authentification en texte clair, un pirate peut obtenir l'accès aux comptes utilisateur en recueillant les noms d'utilisateur et mots de passe lors de leur transfert sur le réseau.
La plupart des MUA Linux conçus pour vérifier le courrier sur des serveurs distants prennent en charge l'encryptage SSL. Afin d'utiliser SSL lors de la récupération de courrier, son activation est nécessaire aussi bien sur le client de messagerie que sur le serveur de messagerie.
L'activation de SSL du côté client est une opération simple, il suffit même parfois de cliquer sur un bouton dans la fenêtre de configuration du MUA ou de l'activer au moyen d'une option dans le fichier de configuration du MUA. IMAP et POP sécurisés ont des numéros de port connus (respectivement 993 et 995) que le MUA utilise pour authentifier et télécharger les messages.
L'utilisation du système de l'encryptage SSL pour les utilisateur d'IMAP et POP sur le serveur de messagerie est une opération relativement simple.
Créez tout d'abord un certificat SSL. Pour ce faire, il existe deux possibilités : vous pouvez faire la demande d'un certificat SSL auprès d'une Autorité de certification (CA de l'anglais Certificate Authority) ou vous pouvez créer vous-même un certificat auto-signé.
Les certificats auto-signés ne devraient être utilisés qu'à des fins de test. Tout serveur utilisé dans un environnement de production devrait avoir recours à un certificat obtenu auprès d'une CA.
Pour créer un certificat SSL auto-signé pour IMAP, allez dans le répertoire /etc/pki/tls/certs/
et saisissez les commandes suivantes en étant connecté en tant que super-utilisateur :
rm -f cyrus-imapd.pem make cyrus-imapd.pem
Pour achever le processus de création du certificat, répondez à toutes les questions.
Afin de créer un certificat SSL auto-signé pour POP, allez dans le répertoire /etc/pki/tls/certs/
> et saisissez les commandes suivantes en étant connecté en tant que super-utilisateur :
rm -f ipop3d.pem make ipop3d.pem
Ici encore, répondez à toutes les questions afin d'achever le processus de création du certificat.
Assurez-vous de bien supprimer les fichiers imapd.pem
et ipop3d.pem
par défaut avant d'exécuter chaque commande make
.
Quand vous avez terminé, exécutez la commande /sbin/service xinetd restart
pour redémarrer le démon xinetd
qui contrôle imapd
et ipop3d
.
Il est également possible d'utiliser la commande stunnel
en tant qu'enveloppeur de l'encryptage SSL placé autour des démons non-sécurisés standards imapd
ou pop3d
.
Le programme stunnel
utilise des bibliothèques OpenSSL externes fournies avec Red Hat Enterprise Linux pour offrir un encryptage fort et pour protéger les connexions. Il est recommandé de faire une demande de certificat SSL auprès d'une autorité de certification (CA), mails il est également possible de créer un certificat auto-signé.
Pour créer un certificat SSL auto-signé, allez dans le répertoire /etc/pki/tls/certs/
et tapez la commande suivante :
make stunnel.pem
Ici encore, répondez à toutes les questions afin d'achever le processus de création du certificat.
Une fois le certificat créé, il est possible d'utiliser la commande stunnel
pour démarrer le démon imapd
à l'aide de la commande suivante :
/usr/sbin/stunnel -d 993 -l /usr/sbin/imapd imapd
Après l'exécution de cette commande, il est possible d'ouvrir un client de messagerie IMAP et d'établir une connexion au serveur de messagerie utilisant le système d'encryptage SSL.
Pour lancer pop3d
à l'aide de la commande stunnel
, tapez la commande suivante :
/usr/sbin/stunnel -d 995 -l /usr/sbin/pop3d pop3d
Pour obtenir de plus amples informations sur la façon d'utiliser stunnel
, lisez la page de manuel de stunnel
ou consultez les documents présents dans le répertoire /usr/share/doc/stunnel-
/, où <version-number>
<version-number>
correspond au numéro de version de stunnel
.
Ci-dessous figure une liste de la documentation supplémentaire relative aux applications de messagerie.
Les paquetages sendmail
et sendmail-cf
contiennent des informations sur la manière de configurer Sendmail.
/usr/share/sendmail-cf/README
— Contient entre autres des informations sur m4
, sur les emplacements des fichiers pour Sendmail, sur les boîtes de messagerie prises en charge et sur les façons d'accéder à des fonctionnalités avancées.
En outre, les pages de manuel de sendmail
et aliases
contiennent des informations utiles sur les différentes options de Sendmail et sur la configuration adéquate du fichier Sendmail /etc/mail/aliases
.
/usr/share/doc/postfix-
— Contient de nombreuses informations sur la manière de configurer Postfix. Remplacez <version-number>
<version-number>
par le numéro de version de Postfix.
/usr/share/doc/fetchmail-
— Contient une liste complète des fonctions Fetchmail dans le fichier <version-number>
FEATURES
et un document FAQ
d'introduction. Remplacez <version-number>
par le numéro de version de Fetchmail.
/usr/share/doc/procmail-
— Contient un fichier <version-number>
README
qui offre un aperçu de Procmail, un fichier FEATURES
qui explore toutes les fonctions du programme et un fichier FAQ
qui offre les réponses à de nombreuses questions de configuration courantes. Remplacez <version-number>
par le numéro de version de Procmail.
Lors de l'apprentissage comment Procmail fonctionne et comment créer de nouvelles recettes, les pages de manuel suivantes sont d'une aide très précieuses :
procmail
— Offre un aperçu du fonctionnement de Procmail et des étapes de filtrage du courrier.
procmailrc
— Explique le format de fichier rc
utilisé pour créer des recettes.
procmailex
— Donne des exemples pratiques utiles de recettes Procmail.
procmailsc
— Explique la technique de weighted scoring utilisée par Procmail pour vérifier s'il y a concordance entre une recette donnée et un message.
/usr/share/doc/spamassassin-
— Contient de nombreuses informations sur SpamAssassin. Remplacez <version-number>
/<version-number>
par le numéro de version du paquetage spamassassin
.
http://www.sendmail.org/ — Offre une explication technique très détaillée des fonctions de Sendmail et des exemples de configuration.
http://www.sendmail.com/ — Contient des informations récentes, entrevues et articles relatifs à Sendmail, notamment un aperçu détaillé des nombreuses options disponibles.
http://www.postfix.org/ — Représente la page d'accueil du projet Postfix contenant de nombreuses informations sur Postfix. La liste de diffusion représente une excellente source d'informations.
http://fetchmail.berlios.de/ — Représente la page d'accueil de Fetchmail, comprenant un manuel en ligne et un forum aux questions (FAQ) complet.
http://www.procmail.org/ — Représente la page d'accueil de Procmail, avec des liens menant à diverses listes d'adresses de participants dédiées à Procmail, de même que de nombreux documents FAQ.
http://partmaps.org/era/procmail/mini-faq.html — Constitue un excellent FAQ sur Procmail, offrant des conseils en matière de résolution de problèmes, des informations sur le verrouillage de fichiers et l'utilisation de caractères génériques (de l'anglais wildcards).
http://www.uwasa.fi/~ts/info/proctips.html — Contient de nombreux conseils rendant l'utilisation de Procmail plus aisée. Ce site inclut des instructions sur la manière de tester les fichiers .procmailrc
et d'utiliser le marquage de Procmail pour décider si une action donnée doit être exécutée ou non.
http://www.spamassassin.org/ — Représente le site officiel du projet SpamAssassin.
Sendmail Milters: A Guide for Fighting Spam de Bryan Costales et Marcia Flynt; Addison-Wesley — Un bon guide Sendmail qui aide à personnaliser vos filtres de courrier.
Sendmail de Bryan Costales avec Eric Allman et al ; O'Reilly & Associates — Une bonne référence pour Sendmail, écrite avec l'aide du créateur de Delivermail et Sendmail.
Removing the Spam : Email Processing and Filtering de Geoff Mulligan ; Addison-Wesley Publishing Company — Un livre examinant les diverses méthodes utilisées par les administrateurs de messagerie ayant recours à des outils établis, tels que Sendmail et Procmail, pour gérer les problèmes causés par le pourriel.
Internet Email Protocols : A Developer's Guide de Kevin Johnson ; Addison-Wesley Publishing Company — Un recueil d'informations détaillées sur les principaux protocoles de messagerie et la sécurité offerte par ceux-ci.
Managing IMAP de Dianna Mullet et Kevin Mullet ; O'Reilly & Associates — Une explication des étapes nécessaires à la configuration d'un serveur IMAP.
/etc/openldap/schema/
Le protocole Lightweight Directory Access Protocol (ou LDAP) est en fait un ensemble de protocoles ouverts utilisés pour accéder à des informations stockées localement sur un réseau. Il est basé sur le standard X.500 pour le partage de répertoires, mais est moins complexe et moins gourmand en ressources, d'où la référence à LDAP sous le terme "X.500 Lite." Le standard X.500 est un répertoire qui contient des informations hiérarchisées et organisées pouvant inclure des renseignements tels que des noms, des adresses et des numéros de téléphone.
Comme X.500, LDAP organise des informations d'une manière hiérarchique en utilisant des répertoires. Ces répertoires peuvent stocker diverses informations et peuvent même être utilisés d'une manière semblable au service d'informations réseau (ou NIS de l'anglais Network Information Service), permettant à tout un chacun d'accéder à son compte depuis une machine quelconque présente sur un réseau sous LDAP.
Dans la plupart des cas, LDAP sert d'annuaire téléphonique virtuel, permettant aux utilisateurs d'accéder facilement aux informations de contact d'autres utilisateurs. Mais le protocole LDAP est beaucoup plus flexible qu'un annuaire téléphonique traditionnel. En effet, de par sa conception, il est destiné à prendre en charge la propagation vers des serveurs LDAP sur tout l'Internet, fournissant ainsi un accès mondial aux informations. Actuellement, cependant, le protocole LDAP est plus généralement utilisé au sein de grandes organisations comme des universités, des départements gouvernementaux et entreprises du secteur privé.
Le protocole LDAP est un système client/serveur. Le serveur peut utiliser diverses bases de données pour stocker un répertoire, chacune d'elles étant optimisée de façon à permettre des opérations de consultation rapides et en grande quantité. Lorsqu'un client LDAP se connecte à un serveur LDAP, il peut soit consulter un répertoire, soit y apporter des modifications. Lors de l'arrivée d'une requête, le serveur y répond localement ou la renvoie à un serveur LDAP de niveau supérieur qui aura la réponse. Si l'application cliente tente de changer des informations dans un répertoire LDAP, le serveur vérifie d'abord que l'utilisateur est bien autorisé à effectuer des changements et ensuite ajoute ou met à jour les informations.
Ce chapitre décrit la configuration et l'utilisation de OpenLDAP 2.0, une implémentation Open Source des protocoles LDAPv2 et LDAPv3.
Le principal avantage du protocole LDAP réside dans la possibilité de réunir les informations concernant toute une organisation dans un lieu central. Par exemple, plutôt que de gérer des listes d'utilisateurs pour chaque groupe au sein d'une organisation, LDAP peut être utilisé comme un répertoire central accessible sur tout le réseau. De plus, puisque LDAP prend en charge les fonctions Secure Sockets Layer (SSL) et Transport Layer Security (TLS), des données confidentielles peuvent être protégées contre toute intrusion.
LDAP prend aussi en charge diverses bases de données parallèles pour y enregistrer des répertoires. Ainsi, les administrateurs disposent de la flexibilité nécessaire pour déployer la base de données la plus adaptée au type d'informations que le serveur doit disséminer. De plus, comme LDAP comporte une API (de l'anglais Application Programming Interfaces) bien définie, le nombre d'applications compatibles avec LDAP est vaste et croissant aussi bien en quantité qu'en qualité.
OpenLDAP comprend un certain nombre de caractéristiques importantes parmi lesquelles figurent :
Prise en charge de LDAPv3 — OpenLDAP prend en charge SASL (de l'anglais Simple Authentication and Security Layer), TLS (Transport Layer Security) et SSL (Secure Sockets Layer) entre autres améliorations. De nombreux changements apportés au protocole depuis LDAPv2 visent à augmenter la sécurité de LDAP.
Prise en charge de IPv6 — OpenLDAP prend en charge le protocole de la prochaine génération, Internet Protocol version 6.
LDAP sur IPC — OpenLDAP peut communiquer au sein d'un système en utilisant IPC (de l'anglais interprocess communication). Il en résulte une sécurité améliorée car il n'est plus nécessaire de communiquer à travers un réseau.
Mise à jour de C API — Améliore la manière dont les programmeurs se connectent aux serveurs de répertoires LDAP et les utilisent.
Prise en charge de LDIFv1 — Grâce à cette prise en charge, OpenLDAP 2.0 est pleinement compatible avec la version 1 du format LDIF (ou LDAP Data Interchange Format).
Amélioration du serveur autonome LDAP — À présent le serveur inclut entre autres un système de contrôle d'accès mis à jour, un pool de conversation et des outils plus performants.
Toute discussion concernant LDAP nécessite une compréhension élémentaire d'un certain nombre de termes spécifiques à LDAP :
entrée — Correspond à une seule unité dans un répertoire LDAP. Chaque entrée est identifiée par son Nom distinctif ou DN (de l'anglais Distinguished Name) unique.
attributs — Des attributs sont des éléments d'information directement associés à une entrée. Par exemple, une organisation pourrait être représentée en tant qu'une entrée LDAP. Parmi les attributs associés à l'organisation, on pourrait avoir son numéro de fax, son adresse, etc. Des personnes peuvent également être représentées par des entrées dans un répertoire LDAP, avec par exemple des attributs courants tels que le numéro de téléphone de la personne en question et son adresse électronique.
Certains attributs sont obligatoires, tandis que d'autres sont facultatifs. Une déclaration classe d'objets (objectclass) détermine les attributs spécifiques qui sont obligatoires pour chaque entrée. Des définitions de classes d'objets figurent dans différents fichiers schéma contenus dans le répertoire /etc/openldap/schema/
. Pour obtenir de plus amples informations sur le sujet, consultez la Section 16.5, « Répertoire /etc/openldap/schema/
».
On appelle l'assertion d'un attribut et sa valeur correspondante un Nom relatif distingué (de l'anglais Relative Distinguished Name ou RDN). Un RDN est seulement unique par entrée, alors qu'un DN est unique globalement.
LDIF — Le format d'échange de données Format d'interchange de données (de l'anglais Data Interchange Format ou LDIF) est un format de texte ASCII pour les entrées LDAP. Les fichiers qui échangent des données avec des serveurs LDAP doivent avoir le format LDIF. Une entrée LDIF ressemble à l'extrait ci-dessous :
[<id
>] dn: <distinguished name
> <attrtype
>: <attrvalue
> <attrtype
>: <attrvalue
> <attrtype
>: <attrvalue
>
Toute entrée peut contenir autant de paires <
quil n'est nécessaire. Une ligne blanche indique que l'entrée est terminée.
attrtype
>: <attrvalue
>
Toutes les paires <
et attrtype
><
doivent être définies dans un fichier de schéma correspondant pour pouvoir utiliser ces informations.
attrvalue
>
Toute valeur figurant entre un <
et un >
représente une variable que vous pouvez paramétrer lorsqu'une nouvelle entrée LDAP est créée. Toutefois, cette règle ne s'applique pas à <
. Cet élément id
><
représente un nombre paramétré par l'application utilisée pour modifier l'entrée.
id
>
La suite de bibliothèques et d'outils OpenLDAP est incluse dans les paquetages suivants :
openldap
— Contient les bibliothèques nécessaires pour faire fonctionner le serveur OpenLDAP et les applications clientes.
openldap-clients
— Contient les outils en ligne de commande pour visualiser et modifier les répertoires d'un serveur LDAP.
openldap-servers
— Contient les serveurs et autres utilitaires nécessaires pour configurer et faire fonctionner un serveur LDAP.
Deux serveurs sont contenus dans le paquetage openldap-servers
: le démon autonome LDAP (/usr/sbin/slapd
) et le démon autonome LDAP de réplication de mise à jour (/usr/sbin/slurpd
).
Le démon slapd
est un serveur LDAP autonome, tandis que le démon slurpd
sert à synchroniser les changements d'un serveur LDAP vers les autres serveurs LDAP du réseau. Le démon slurpd
n'est utilisé que pour des opérations avec de multiples serveurs LDAP.
Pour effectuer des tâches administratives, le paquetage openldap-servers
installe les utilitaires suivants dans le répertoire /usr/sbin/
:
slapadd
— Ajoute des entrées d'un fichier LDIF dans un répertoire LDAP. Par exemple, la commande /usr/sbin/slapadd -l
lit le fichier LDIF ldif-input
contenant les nouvelles entrées.
ldif-input
Seul le super-utilisateur peut utiliser /usr/sbin/slapadd
. Toutefois, le serveur de répertoires tourne en tant qu' utilisateur ldap
. Par conséquent, le serveur de répertoires n'est pas en mesure de modifier un fichier quelconque créé par slapadd
. Pour résoudre ce problème, après avoir utilisé slapadd
, tapez la commande suivante :
chown -R ldap /var/lib/ldap
slapcat
— Extrait des données d'un répertoire LDAP dans le format par défaut, à savoir le système Berkeley DB de Sleepycat Software, et les enregistre dans un fichier LDIF. Par exemple, la commande /usr/sbin/slapcat -l
renvoie un fichier LDIF nommé ldif-output
contenant les entrées du répertoire LDAP.
ldif-output
slapindex
— Indexe à nouveau le répertoire slapd
sur la base du contenu actuel. Cet outil devrait être exécuté chaque fois que les options d'indexation de /etc/openldap/slapd.conf
sont modifiées.
slappasswd
— Crée une valeur pour le mot de passe utilisateur crypté à utiliser avec ldapmodify
ou la valeur rootpw
dans le fichier de configuration de slapd
, /etc/openldap/slapd.conf
. Exécutez la commande /usr/sbin/slappasswd
pour créer le mot de passe.
Vous devez arrêter slapd
en exécutant la commande /sbin/service lapd stop
avant d'utiliser slapadd
, slapcat
ou slapindex
. Dans le cas contraire, l'intégrité du répertoire LDAP risque d'être compromise.
Pour obtenir de plus amples informations sur l'utilisation de ces utilitaires, consultez leurs pages de manuel respectives.
Le paquetage openldap-clients
installe dans /usr/bin/
des outils permettant d'ajouter, de modifier et de supprimer des entrées dans un répertoire LDAP. Parmi ces outils figurent :
ldapadd
— Ajoute des entrées dans un répertoire LDAP en acceptant la saisie d'entrées par le biais d'un fichier ou par une saisie standard ; ldapadd
est en fait un lien dur vers la commande ldapmodify -a
.
ldapdelete
— Supprime des entrées dans un répertoire LDAP en acceptant la saisie de l'utilisateur à une invite du shell ou par le biais d'un fichier.
ldapmodify
— Modifie les entrées dans un répertoire LDAP, acceptant leur saisie par un fichier ou par une saisie standard.
ldappasswd
— Définit le mot de passe pour un utilisateur LDAP.
ldapsearch
— Recherche des entrées dans un répertoire LDAP en utilisant une invite du shell.
ldapcompare
— Ouvre une connexion à un serveur LDAP, lie et effectue une comparaison en utilisant les paramètres spécifiés.
ldapwhoami
— Ouvre une connexion à un serveur LDAP, lie et effectue une opération whoami
.
ldapsearch
— Ouvre une connexion à un serveur LDAP, lie et modifie les RDN des entrées.
À l'exception de la commande ldapsearch
, chacun de ces utilitaires est plus facilement utilisé en référençant un fichier contenant les changements à effectuer plutôt qu'en tapant une commande pour chaque entrée devant être modifiée dans le répertoire LDAP. Le format d'un tel fichier est expliqué dans les pages de manuel de chaque utilitaire.
Outre les paquetages OpenLDAP, Red Hat Enterprise Linux comprend un paquetage nommé nss_ldap
, qui améliore la capacité de LDAP à s'intégrer aussi bien dans un environnement Linux que dans tout autre environnement UNIX.
Le paquetage nss_ldap
fournit les modules suivants (où <version>
renvoie à la version de libnss_ldap
utilisée) :
/lib/libnss_ldap-
<version>
.so
/lib/security/pam_ldap.so
Le paquetage nss_ldap
fournit les modules suivants pour les architectures Itanium ou AMD64 :
/lib64/libnss_ldap-
<version>
.so
/lib64/security/pam_ldap.so
Le module libnss_ldap-
permet aux applications de rechercher des utilisateurs, des groupes, des hôtes et d'autres informations en utilisant un répertoire LDAP via l'interface Nameservice Switch (ou NSS) de <glibc-version>
.soglibc
. NSS permet l'authentification d'applications en utilisant LDAP avec le service de noms Network Information Service (NIS) et les fichiers simples pour l'authentification.
Le module pam_ldap
permet aux applications fonctionnant avec PAM d'authentifier les utilisateurs en utilisant les informations stockées dans un répertoire LDAP. Les applications fonctionnant avec PAM comprennent la connexion console, les serveurs de messagerie POP et IMAP ainsi que Samba. En déployant un serveur LDAP sur votre réseau, toutes ces applications peuvent, pour leur authentification, utiliser la même combinaison identifiant d'utilisateur/mot de passe, ce qui simplifie considérablement l'administration.
Red Hat Enterprise Linux comprend un paquetage avec un module LDAP pour le langage de scripts PHP côté serveur.
Le paquetage php-ldap
ajoute la prise en charge LDAP au langage de script PHP4 avec intégration HTML grâce au module /usr/lib/php4/ldap.so
. Ce module permet aux scripts PHP4 d'accéder aux informations stockées dans un répertoire LDAP.
Red Hat Enterprise Linux est vendu avec le module mod_authz_ldap
pour le Serveur HTTP Apache. Ce module utilise la forme courte du nom distinct d'un sujet et le fournisseur du certificat SSL client afin de déterminer le nom distinct de l'utilisateur au sein d'un répertoire LDAP. Il est également capable d'autoriser des utilisateurs selon les attributs de l'entrée du répertoire LDAP de cet utilisateur, en déterminant l'accès aux éléments selon les privilèges de l'utilisateur et du groupe sur celui-ci et en refusant l'accès aux utilisateurs dont les mots de passe ont expiré. Le module mod_ssl
est requis lors de l'utilisation du module mod_authz_ldap
.
Le module mod_authz_ldap
n'authentifie pas un utilisateur auprès d'un répertoire LDAP à l'aide d'un mot de passe crypté. Cette fonctionnalité est fournie par le module expérimental nommé mod_auth_ldap
qui n'est pas inclus dans Red Hat Enterprise Linux. Pour obtenir de plus amples informations sur le statut de ce module, reportez-vous au site Web de l'organisation Apache Software Foundation à l'adresse suivante : http://www.apache.org/
Il existe des clients LDAP graphiques prenant en charge la création et la modification de répertoires, mais ces applications ne sont pas incluses dans Red Hat Enterprise Linux. C'est le cas de l'application LDAP Browser/Editor — Cet outil basé sur Java est disponible en ligne à l'adresse suivante : http://www.iit.edu/~gawojar/ldap/.
La plupart des autres clients LDAP accèdent aux répertoires en lecture-seule et les utilisent pour référencer, et non pas modifier, les informations relatives à toute l'entreprise. Parmi ces applications figurent Sendmail, Mozilla, Gnome Meeting, et Evolution.
Les fichiers de configuration d'OpenLDAP sont installés dans le répertoire /etc/openldap/
. Ci-dessous figure une brève liste des répertoires et fichiers les plus importants :
/etc/openldap/ldap.conf
— Ce fichier est le fichier de configuration pour toutes les applications clientes qui utilisent les bibliothèques OpenLDAP telles que ldapsearch
, ldapadd
, Sendmail, Evolution et Gnome Meeting.
/etc/openldap/slapd.conf
— Ce fichier est le fichier de configuration du démon slapd
. Pour obtenir davantage d'informations sur ce fichier, reportez-vous à la Section 16.6.1, « Édition de /etc/openldap/slapd.conf
».
Le répertoire /etc/openldap/schema/
— Ce sous-répertoire contient le schéma utilisé par le démon slapd
. Pour obtenir davantage d'informations sur ce répertoire, reportez-vous à la Section 16.5, « Répertoire /etc/openldap/schema/
».
Si le paquetage nss_ldap
est installé, il crée un fichier nommé /etc/ldap.conf
. Ce fichier est utilisé par les modules PAM et NSS fournis par le paquetage nss_ldap
. Pour obtenir davantage d'informations, consultez la Section 16.7, « Configuration d'un système pour l'authentification avec OpenLDAP ».
Le répertoire /etc/openldap/schema/
contient des définitions LDAP précédemment placées dans les fichiers slapd.at.conf
et slapd.oc.conf
. Le fichier /etc/openldap/schema/redhat/
contient des schémas personnalisés distribués par Red Hat pour Red Hat Enterprise Linux.
Toutes les définitions de syntaxe d'attribut et définitions de la classe d'objet sont maintenant placées dans des fichiers schéma différents. Ces derniers sont référencés dans /etc/openldap/slapd.conf
en utilisant les lignes include
, comme dans l'exemple ci-dessous :
include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/nis.schema include /etc/openldap/schema/rfc822-MailMember.schema include /etc/openldap/schema/redhat/autofs.schema
Ne modifiez aucun élément schéma défini dans les fichiers schéma installés par OpenLDAP.
Ceci étant, vous pouvez étendre le schéma utilisé par OpenLDAP afin de prendre en charge d'autres types d'attributs et classes d'objets en utilisant comme guide les fichiers schéma par défaut. Pour ce faire, créez un fichier local.schema
dans le répertoire /etc/openldap/schema
. Référencez ce nouveau schéma dans slapd.conf
en ajoutant la ligne suivante en dessous de vos lignes schéma include
par défaut :
include /etc/openldap/schema/local.schema
Ensuite, définissez vos nouveaux types d'attributs et classes d'objets dans le fichier local.schema
. Beaucoup d'organisations utilisent les types d'attributs et classes d'objet existants dans les fichiers schéma installés par défaut et ajoutent de nouvelles classes d'objets dans le fichier local.schema
.
L'extension d'un schéma pour qu'il corresponde à des besoins spécialisés est une tâche complexe qui dépasse la portée du présent chapitre. Pour obtenir de plus amples d'informations sur le sujet, consultez l'adresse suivante : http://www.openldap.org/doc/admin/schema.html.
Cette section fournit une présentation rapide des opérations à accomplir pour installer et configurer un annuaire OpenLDAP (aussi appelé répertoire). Pour obtenir de plus amples informations sur le sujet, reportez-vous aux URL suivantes :
http://www.openldap.org/doc/admin/quickstart.html — Le guide rapide pour commencer (Quick-Start Guide) sur le site Web d'OpenLDAP.
http://www.tldp.org/HOWTO/LDAP-HOWTO/index.html — Le document LDAP Linux HOWTO du Projet de documentation Linux (Linux Documentation Project).
Ci-dessous figurent les étapes de base pour créer un serveur LDAP :
Installez les RPM d'openldap
, openldap-servers
et de openldap-clients
.
Éditez le fichier /etc/openldap/slapd.conf
afin de spécifier le domaine et le serveur LDAP. Reportez-vous à la Section 16.6.1, « Édition de /etc/openldap/slapd.conf
» afin d'obtenir davantage d'informations.
Lancez slapd
à l'aide de la commande :
/sbin/service ldap start
Après avoir configuré LDAP, utilisez chkconfig
, /usr/sbin/ntsysv
, ou l'Outil de configuration des services pour configurer LDAP de façon à le lancer au démarrage. Pour de plus amples informations sur la configuration des services, consultez le Chapitre 7, Contrôle d'accès aux services .
Ajoutez des entrées à un répertoire LDAP à l'aide de ldapadd
.
Utilisez ldapsearch
afin de vérifier si slapd
accède correctement aux informations.
À ce stade, le répertoire LDAP devrait fonctionner correctement et peut donc être configuré avec des applications compatibles avec LDAP.
Afin d'utiliser le serveur LDAP slapd
, modifiez son fichier de configuration, /etc/openldap/slapd.conf
de façon à spécifier le domaine et le serveur corrects.
La ligne de suffix
nomme le domaine pour lequel le serveur LDAP fournira les informations et devrait être changée comme suit :
suffix "dc=your-domain,dc=com"
Éditez le de façon appropriée pour qu'il reflète un nom de domaine pleinement qualifié. Par exemple :
suffix "dc=example,dc=com"
L'entrée rootdn
est le Nom distinct (ou DN selon l'acronyme anglais) pour un utilisateur dont l'activité n'est pas limitée par les paramètres de contrôle d'accès ou de limites administratives définis pour toute opération sur le répertoire LDAP. L'utilisateur rootdn
peut être considéré comme le super-utilisateur pour le répertoire LDAP. Dans le fichier de configuration, modifiez la ligne rootdn
pour changer la valeur par défaut comme dans l'exemple suivant :
rootdn "cn=root,dc=example,dc=com"
Si vous avez l'intention de peupler le répertoire LDAP sur le réseau, modifiez la ligne rootpw
— en remplaçant la valeur par défaut par une chaîne de mot de passe cryptée. Afin de créer une chaîne de mots de passe cryptée, tapez la commande suivante :
slappasswd
Lorsque le système vous le demandera, saisissez et confirmez un mot de passe. Le programme affiche alors à l'invite du shell, le mot de passe crypté résulant de la commande.
Ensuite, copiez le mot de passe crypté que vous venez de créer dans /etc/openldap/slapd.conf
sur une des lignes rootpw
et supprimez le signe dièse (#
).
Une fois cette modification apportée, la ligne devrait ressembler à l'exemple reproduit ci-dessous :
rootpw {SSHA}vv2y+i6V6esazrIv70xSSnNAJE18bb2u
Les mots de passe LDAP, y compris la directive rootpw
spécifiée dans /etc/openldap/slapd.conf
, sont envoyés sur le réseau en texte clair, à moins que le cryptage TLS ne soit activé.
Pour permettre le cryptage TLS, passez en revue les commentaires figurant dans /etc/openldap/slapd.conf
et consultez la page de manuel de slapd.conf
.
Pour une sécurité accrue, la directive rootpw
devrait être désactivée après avoir peuplé le répertoire LDAP. Pour ce faire, ajoutez un signe dièse devant cette directive (#
).
Si vous utilisez l'outil en ligne de commande /usr/sbin/slapadd
localement pour peupler le répertoire, il n'est pas nécessaire d'utiliser la directive rootpw
.
Seul le super-utilisateur peut utiliser /usr/sbin/slapadd
. Toutefois, le serveur de répertoires tourne en tant qu'utilisateur ldap
. Par conséquent, le serveur de répertoires ne peut modifier aucun fichier créé par slapadd
. Pour résoudre ce problème, après avoir utilisé slapadd
tapez la commande ci-dessous :
chown -R ldap /var/lib/ldap
Cette section donne un bref aperçu de la manière de configurer l'authentification des utilisateurs à l'aide d'OpenLDAP. À moins d'être un expert d'OpenLDAP, vous aurez probablement besoin de plus de documentation que vous n'en trouverez ici. Reportez-vous aux références fournies dans la Section 16.9, « Ressources supplémentaires » pour obtenir davantage d'informations.
Commencez par vérifier que les paquetages appropriés sont installés aussi bien sur le serveur LDAP que sur les machines LDAP clientes. Le serveur LDAP nécessite le paquetage openldap-servers
.
Les paquetages openldap
, openldap-clients
et nss_ldap
doivent être installés sur tous les ordinateurs clients LDAP.
Sur le serveur LDAP, éditez le fichier /etc/openldap/slapd.conf
pour vous assurer qu'il correspond bien aux éléments spécifiques de votre organisation. Pour obtenir des instructions sur la manière d'éditer slapd.conf
, reportez-vous à la Section 16.6.1, « Édition de /etc/openldap/slapd.conf
».
Sur les ordinateurs clients, /etc/ldap.conf
et /etc/openldap/ldap.conf
doivent contenir le bon serveur et les bonnes informations de la base de recherche pour l'organisation.
Pour ce faire, lancez l'Outil de configuration de l'authentification graphique (system-config-authentication
) et sélectionnez Activer le support LDAP sous l'onglet Informations utilisateur.
Vous pouvez également modifier ces fichiers manuellement.
Sur les ordinateurs clients, le fichier /etc/nsswitch.conf
doit être édité afin de pouvoir utiliser LDAP.
Pour ce faire, lancez l'Outil de configuration de l'authentification (system-config-authentication
) et sélectionnez Activer le support LDAP sous l'onglet Informations utilisateur.
Si vous éditez /etc/nsswitch.conf
manuellement, ajoutez ldap
aux lignes appropriées.
Comme par exemple :
passwd: files ldap shadow: files ldap group: files ldap
Le répertoire /usr/share/openldap/migration/
contient un ensemble de scripts shell et Perl pour la migration des informations d'authentification vers un format LDAP.
Perl doit être installé sur votre système pour que vous puissiez utiliser ces scripts.
Tout d'abord, modifiez le fichier migrate_common.ph
de manière à ce qu'il reflète le domaine approprié. La valeur par défaut du domaine DNS par défaut devrait être modifiée de manière semblable à l'extrait suivant :
$DEFAULT_MAIL_DOMAIN = "example
";
La base par défaut devrait également être changée, pour ressembler à ceci :
$DEFAULT_BASE = "dc=example
,dc=com
";
Le travail de migration d'une base de données d'utilisateurs vers un format lisible par LDAP incombe à un groupe de scripts de migration installés dans le même répertoire. À l'aide du Tableau 16.1, « Scripts de migration LDAP », déterminez le script à utiliser pour la migration de base de données d'utilisateurs.
Exécutez le script approprié en fonction du service de noms existant.
Les fichiers README
et migration-tools.txt
du répertoire /usr/share/openldap/migration/
fournissent davantage de renseignements sur la migration d'informations.
Service de noms existant | LDAP est-il en exécution ? | Script à utiliser |
---|---|---|
Fichiers plats /etc
|
oui |
migrate_all_online.sh
|
Fichiers plats /etc
|
non |
migrate_all_offline.sh
|
NetInfo | oui |
migrate_all_netinfo_online.sh
|
NetInfo | non |
migrate_all_netinfo_offline.sh
|
NIS (YP) | oui |
migrate_all_nis_online.sh
|
NIS (YP) | non |
migrate_all_nis_offline.sh
|
With Red Hat Enterprise Linux, OpenLDAP uses Sleepycat Software's Berkeley DB system as its on-disk storage format for directories. Earlier versions of OpenLDAP used GNU Database Manager (gdbm). For this reason, before upgrading an LDAP implementation to Red Hat Enterprise Linux 5.2, original LDAP data should first be exported before the upgrade, and then reimported afterwards. This can be achieved by performing the following steps:
Exécutez la commande /usr/sbin/slapcat -l
qui produira un fichier LDIF nommé ldif-output
contenant les entrées du répertoire LDAP, avant de mettre à niveau le système d'exploitation.
ldif-output
Mettez à niveau le système d'exploitation, en faisant bien attention de ne pas reformater la partition contenant le fichier LDIF.
Importez de nouveau le répertoire LDAP sur le format Berkeley DB mis à niveau en exécutant la commande /usr/sbin/slapadd -l
.
ldif-output
Les ressources suivantes fournissent des informations supplémentaires sur LDAP. Il est fortement recommandé de les consulter, en particulier le site Web d'OpenLDAP et le HOWTO LDAP, avant de configurer LDAP sur un ou plusieurs systèmes.
/usr/share/docs/openldap-
— Contient un document <numéro-version>
README
général ainsi que des informations diverses.
Pages de manuel de LDAP — Il existe un nombre de pages de manuel pour les diverses applications et fichiers de configuration utilisés avec LDAP. La liste suivante contient certaines des pages de manuel les plus importantes.
man ldapadd
— Décrit comment ajouter des entrées à un répertoire LDAP.
man ldapdelete
— Décrit comment supprimer des entrées dans un répertoire LDAP.
man ldapmodify
— Décrit comment modifier des entrées dans un répertoire LDAP.
man ldapsearch
— Décrit comment rechercher des entrées dans un répertoire LDAP.
man ldappasswd
— Décrit comment définir ou modifier le mot de passe d'un utilisateur de LDAP.
man ldapcompare
— Décrit comment utiliser l'outil ldapcompare
.
man ldapwhoami
— Décrit comment utiliser l'outil ldapwhoami
.
man ldapmodrdn
— Décrit comment modifier les RDN des entrées.
man slapd
— Décrit les options de ligne de commande pour le serveur LDAP.
man slurpd
— Décrit les options en ligne de commande pour le serveur de réplication LDAP.
man slapadd
— Décrit les options en ligne de commande utilisées pour ajouter des entrées dans une base de données slapd
.
man slapcat
— Décrit les options en ligne de commande utilisées pour générer un fichier LDIF à partir d'une base de données slapd
.
man slapindex
— Décrit les options en ligne de commande utilisées pour regénérer un index selon le contenu d'une base de données slapd
.
man slappasswd
— Décrit les options en ligne de commande utilisées pour générer des mots de passe d'utilisateur pour les répertoires LDAP.
man ldap.conf
— Décrit le format et les options disponibles au sein du fichier de configuration pour les clients LDAP.
man slapd.conf
— Décrit le format et les options disponibles au sein du fichier de configuration référencé aussi bien par les applications serveur de LDAP (slapd
et slurpd
) que par les outils administratifs de LDAP (slapadd
, slapcat
et slapindex
).
http://www.openldap.org/ — Page d'accueil du projet de l'organisation OpenLDAP. Ce site Web contient de nombreuses informations sur la configuration d'OpenLDAP ainsi que sur la feuille de route future et sur les changements apportés à la version.
http://www.padl.com/ — Développeurs de nss_ldap
et pam_ldap
et d'autres outils LDAP utiles.
http://www.kingsmountain.com/ldapRoadmap.shtml — Feuille de route LDAP de Jeff Hodges contenant des liens vers différents Forums aux questions (FAQ) et de nouvelles informations concernant le protocole LDAP.
http://www.ldapman.org/articles/ — Articles offrant une bonne introduction à LDAP, y compris des méthodes pour concevoir une arborescence de répertoires et personnaliser des structures de répertoire.
Lorsqu'un utilisateur se connecte à un système Red Hat Enterprise Linux, la combinaison nom d'utilisateur/mot de passe doit être vérifiée, ou authentifiée, en tant qu'utilisateur valide et actif. Dans certaines situations, les informations nécessaires à la vérification de l'utilisateur se trouvent sur le système local et parfois, le système demande à une base de données utilisateur se trouvant sur un système distant d'effectuer l'authentification.
L'Outil de configuration de l'authentification fournit une interface graphique permettant non seulement de configurer NIS, LDAP et Hesiod de manière à ce qu'ils extraient les informations d'utilisateur, mais permettant également la configuration de LDAP, Kerberos et SMB en tant que protocoles d'authentification.
Si vous avez choisi un niveau de sécurité moyen ou élevé lors de l'installation (ou avec l'Outil de configuration du niveau de sécurité), le pare-feu empêchera l'authentification NIS (de l'anglais Network Information Service).
Ce chapitre ne se concentre pas en détails sur chacun des différents types d'authentification. Il explique plutôt la manière d'utiliser l'Outil de configuration de l'authentification afin de les configurer.
Pour démarrer la version graphique de l'Outil de configuration de l'authentification à partir du bureau, sélectionnez System (on the panel) => Administration => Authentification ou tapez la commande system-config-authentication
à une invite du shell (par exemple, dans un terminal XTerm ou GNOME).
Les changements apportés prennent effet dès que vous quittez le programme d'authentification.
L'onglet Informations utilisateur offre plusieurs options. Pour activer une option, cochez la case située à côté d'elle. Pour désactiver une option, cliquez sur la case située à côté d'elle pour qu'elle soit désélectionnée. Cliquez sur Valider afin de sortir du programme et mettre en oeuvre les modifications apportées.
La liste ci-dessous explique l'élément que chaque option configure :
Activer le support NIS — Sélectionnez cette option pour configurer le système en tant que client NIS qui se connecte à un serveur NIS pour l'authentification de l'utilisateur et du mot de passe. Cliquez sur le bouton Configurer NIS... pour spécifier le domaine NIS et le serveur NIS. Si le serveur NIS n'est pas spécifié, le démon essaiera de le trouver par le biais de la diffusion.
Le paquetage ypbind
doit être installé pour que cette option puisse fonctionner. Si la prise en charge NIS est activée, les services portmap
et ypbind
sont non seulement lancés mais sont également activés de manière à être lancés au démarrage.
Activer le support LDAP — Sélectionnez cette option afin de permettre à des applications supportant PAM d'utiliser LDAP pour l'authentification. Cliquez sur le bouton Configurer LDAP... pour spécifier les éléments suivants :
DN de la base de recherche de LDAP — Cette option spécifie que les informations utilisateur doivent être récupérées en utilisant le nom distinct listé (ou DN de l'anglais "Distinguished Name").
Serveur LDAP — Cette option permet de spécifier l'adresse IP du serveur LDAP.
Utiliser TLS pour encrypter des connexions — Quand il est activé, TLS (de l'anglais Transport Layer Security) est utilisé pour encrypter des mots de passe envoyés au serveur LDAP. L'option Télécharger le certificat CA vous permet de spécifier un URL pour le téléchargment d'un Certificat CA (Certificate Authority) valide. Un Certificat CA valide doit être dans un format PEM (de l'anglais Privacy Enhanced Mail).
Le paquetage openldap-clients
doit être installé pour que cette option puisse fonctionner.
Activer le support Hesiod — Cette option configure le système afin qu'il puisse récupérer des informations (y compris des informations utilisateur) depuis une base de données Hesiod distante. Cliquez sur le bouton Configurer Hesiod... pour spécifier ce qui suit :
Hesiod LHS — Spécifie le préfixe de domaine utilisé pour les requêtes Hesiod.
Hesiod RHS — Spécifie le domaine Hesiod par défaut.
Le paquetage hesiod
doit être installé pour que cette option puisse fonctionner.
Pour davantage d'informations sur Hesiod, consultez la page de manuel en utilisant la commande man hesiod
. Vous pouvez également voir la page de manuel hesiod.conf
(man hesiod.conf
) pour plus d'informations sur LHS et RHS.
Activer le support Winbind — Sélectionnez cette option pour configurer le système de manière à ce qu'il se connecte à Window Active Directory ou à un contrôleur de domaines Windows. Vous avez alors accès aux informations utilisateur, depuis le répertoire spécifié ou le contrôleur de domaines et les options d'authentification du serveur peuvent être configurées. Cliquez le bouton Configurer Winbind... pour spécifier ce qui suit :
Domaine Windbind — Spécifie le Windows Active Directory ou le contrôleur de domaines auquel se connecter.
Modèle de sécurité — Vous permet de sélectionner un modèle de sécurité, qui configure la façon dont les clients doivent répondre à Samba. La liste déroulante vous permet de sélectionner une des options suivantes :
Utilisateur — Il s'agit du mode par défaut. Avec ce niveau de sécurité, un client doit d'abord se connecter avec un mot de passe et un nom d'utilisateur valides. Les mots de passe encryptés peuvent également être utilisés dans ce mode de sécurité.
Serveur — Dans ce mode, Samba tentera de valider le nom d'utilisateur/mot de passe en l'authentifiant par le biais d'un autre serveur SMB (par exemple, un serveur Windows NT). Si la tentative échoue, le mode utilisateur prendra effet à sa place.
Domaine — Dans ce mode, Samba tentera de valider le nom d'utilisateur/mot de passe en l'authentifiant par le biais d'un Windows NT Primary ou d'un Backup Domain Controller, de la même manière que le ferait un serveur Windows NT.
ads — Ce mode indique à Samba d'agir en tant que membre de domaine dans une zone Active Directory Server (ADS). Pour opérer dans ce mode, le paquetage krb5-server
doit être installé, et Kerberos doit être configuré correctement.
Cadre Winbind ADS — Quand le modèle de sécurité ads est sélectionné, cela permet de spécifier à la zone ADS, que le serveur Samba devrait agir en tant que membre de domaine.
Modèle de Shell — Quand vous remplissez le formulaire d'informations pour l'utilisateur Windows NT, le démon winbindd
utilise la valeur choisie ici pour spécifier le shell de connexion pour cet utilisateur.
L'onglet Authentification permet la configuration des méthodes d'authentification réseau. Pour activer une option, cliquez sur la case vierge placée à côté d'elle. Pour désactiver une option, cliquez sur la case située à côté d'elle et tout choix précédent sera annulé.
Les informations suivantes expliquent l'élément que chaque option configure :
Activer le support Kerberos — Sélectionnez cette option pour activer l'authentification Kerberos. Cliquez sur le bouton Configurer Kerberos... pour ouvrir les Paramètres Kerberos et effectuer la configuration des options suivantes :
Zone — Cette option permet de configurer la zone (ou 'Realm') du serveur Kerberos. La zone correspond au réseau utilisant Kerberos, composée d'un ou plusieurs KDC et potentiellement, d'un nombre important de clients.
KDC — Définit le Key Distribution Center (KDC), qui est le serveur émettant les tickets Kerberos.
Serveurs Admin — Cette option permet de spécifier les serveurs d'administration exécutant kadmind
.
La boîte de dialogue Paramètres Kerberos permet également d'utiliser DNS pour résoudre les hôtes aux zones et localiser les KDC pour les zones.
Activer le support LDAP — Sélectionnez cette option afin de permettre à des applications standards supportant PAM, d'utiliser LDAP pour l'authentification. Le bouton Configurer LDAP... vous permet de configurer le support LDAP avec des options identiques à celles présentes dans Configurer LDAP... sous l'onglet Informations utilisateur. Pour plus d'informations sur ces options, consultez la Section 17.1, « Informations utilisateur ».
Le paquetage openldap-clients
doit être installé pour que cette option puisse fonctionner.
Activer le support Smart Card — Sélectionnez cette option pour activer l'authentification Smart Card. Cela permet de se connecter en utilisant un certificat et une clé associés et stockés dans un carte à puce. Cliquez le bouton Configurer la Smart Card... pour plus d'options.
Activer le support SMB — Cette option permet de configurer les PAM (les modules d'authentification enfichables) de manière à ce qu'ils utilisent un serveur SMB pour authentifier les utilisateurs. SMB représente un protocole client-serveur utilisé pour la communication entre systèmes ; c'est aussi le protocole utilisé par Samba quand il apparaît en tant que serveur Windows aux clients Windows. Cliquez sur le bouton Configurer SMB... pour spécifier les éléments suivants :
Workgroup — Cette option permet de spécifier le groupe de travail SMB à utiliser.
Contrôleurs de domaines — Cette option permet de spécifier les contrôleurs de domaines SMB à utiliser.
Activer le support Windbind — Sélectionnez cette option pour configurer le système afin qu'il se connecte à Windows Active Directory ou à un contrôleur de domaines Windows. Vous pouvez accéder aux informations utilisateur depuis le répertoire spécifié ou au contrôleur de domaines, et les options d'authentification peuvent être configurées.
Les options Configurer Winbind... sont identiques à celles du bouton Configurer Winbind... de l'onglet Informations utilisateur. Veuillez consulter Winbind (sous la Section 17.1, « Informations utilisateur ») pour plus d'informations.
Cet onglet permet d'autres options de configuration, comme listées ci-dessous.
Sélectionnez cette option pour activer le démon de cache du service de nommage (nscd
) et configurez-le pour qu'il démarre au démarrage.
Le paquetage nscd
doit être installé pour que cette option puisse fonctionner. Pour de plus amples informations sur nscd
, consultez ses pages de manuel en utilisant la commande man nscd
.
Sélectionnez cette option pour stocker les mots de passe dans un format de mot de passe masqué dans le fichier /etc/shadow
au lieu de /etc/passwd
. Les mots de passe masqués sont activés par défaut durant l'installation et sont fortement recommandés pour augmenter la sécurité du système.
Sélectionnez cette option pour activer les mots de passe MD5, qui peuvent avoir une longueur allant jusqu'à 256 caractères au lieu de huit ou moins. Cette option est sélectionnée par défaut lors de l'installation et leur utilisation est fortement recommandée afin d'augmenter la sécurité du système.
Quand cette option est activée, le système ne vérifiera pas l'autorisation des services réseau (comme LDAP ou Kerberos) pour les comptes d'utilisateur maintenus dans sonfichier /etc/passwd
.
Activer cette option configure le système pour permettre aux services réseau (comme LDAP ou Kerberos) d'authentifier les comptes de système (y compris les comptes root) dans la machine.
L'Outil de configuration de l'authentification peut également être exécuté comme un outil en ligne de commande et donc, sans interface. La version en ligne de commande peut être utilisée dans un script de configuration ou dans un script kickstart. Les options d'authentification sont résumées dans le Tableau 17.1, « Options de la ligne de commande ».
Il est possible de trouver ces options dans la page de manuel relative à authconfig
ou en tapant authconfig --help
à une invite du shell.
Option | Description |
---|---|
--enableshadow
|
Activer les mots de passe masqués |
--disableshadow
|
Désactiver les mots de passe masqués |
--enablemd5
|
Activer les mots de passe MD5 |
--disablemd5
|
Désactiver les mots de passe MD5 |
--enablenis
|
Activer NIS |
--disablenis
|
Désactiver NIS |
--nisdomain=
|
Spécifier un domaine NIS |
--nisserver=
|
Spécifier un serveur NIS |
--enableldap
|
Activer LDAP pour les informations utilisateur |
--disableldap
|
Désactiver LDAP pour les informations utilisateur |
--enableldaptls
|
Activer l'utilisation de TLS avec LDAP |
--disableldaptls
|
Désactiver l'utilisation de TLS avec LDAP |
--enableldapauth
|
Activer LDAP pour l'authentification |
--disableldapauth
|
Désactiver LDAP pour l'authentification |
--ldapserver=
|
Spécifier un serveur LDAP |
--ldapbasedn=
|
Spécifier le DN de la base LDAP |
--enablekrb5
|
Activer Kerberos |
--disablekrb5
|
Désactiver Kerberos |
--krb5kdc=
|
Spécifier le centre distributeur de tickets (ou KDC) de Kerberos |
--krb5adminserver=
|
Spécifier le serveur d'administration de Kerberos |
--krb5realm=
|
Spécifier la zone (ou 'realm') Kerberos |
--enablekrb5kdcdns
|
Activer l'utilisation de DNS pour trouver les KDC Kerberos |
--disablekrb5kdcdns
|
Désactiver l'utilisation de DNS pour trouver les KDC Kerberos |
--enablekrb5realmdns
|
Activer l'utilisation de DNS pour trouver les zones Kerberos |
--disablekrb5realmdns
|
Désactiver l'utilisation de DNS pour trouver les zones Kerberos |
--enablesmbauth
|
Activer SMB |
--disablesmbauth
|
Désactiver SMB |
--smbworkgroup=
|
Spécifier le groupe de travail SMB |
--smbservers=
|
Spécifier les serveurs SMB |
--enablewinbind
|
Activer Winbind pour les informations utilisateur par défaut |
--disablewinbind
|
Désactiver Winbind pour les informations utilisateur par défaut |
--enablewinbindauth
|
Activer winbindauth pour l'authentification par défaut |
--disablewinbindauth
|
Désactiver winbindauth pour l'authentification par défaut |
--smbsecurity=
|
Mode de sécurité à utiliser pour Samba et Winbind |
--smbrealm=
|
La zone par défaut pour Samba et winbind quand security=ads
|
--smbidmapuid=
|
L'étendue UID que winbind assigne au domaine ou aux utilisateurs ADS |
--smbidmapgid=
|
L'étendue GID que winbind assigne au domaine ou aux utilisateurs ADS |
--winbindseparator=
|
Caractère utilisé pour séparer le domaine de la partie utilisateur des noms d'utilisateur winbind si winbindusedefaultdomain n'est pas activé
|
--winbindtemplatehomedir=
|
Le répertoire que les utilisateurs winbind utilisent comme leur home |
--winbindtemplateprimarygroup=
|
Le groupe que les utilisateurs winbind utilisent comme leur group principal |
--winbindtemplateshell=
|
Le shell que les utilisateurs winbind utilisent comme leur shell de connexion par défaut |
--enablewinbindusedefaultdomain
|
Configure winbind afin qu'il suppose que les utilisateurs sans domaine dans leurs noms d'utilisateur, sont des utilisateurs du domaine |
--disablewinbindusedefaultdomain
|
Configure winbind pour présumer (en supposant) que les utilisateurs sans domaines dans leurs noms d'utilisateur sont des utilisateurs du domaine |
--winbindjoin=
|
Rejoint maintenant le domaine winbind ou la zone ADS comme cet administrateur |
--enablewins
|
Activer WINS pour la résolution du nom d'hôte |
--disablewins
|
Désactiver WINS pour la résolution du nom d'hôte |
--enablehesiod
|
Activer Hesiod |
--disablehesiod
|
Désactiver Hesiod |
--hesiodlhs=
|
Spécifier Hesiod LHS |
--hesiodrhs=
|
Spécifier Hesiod RHS |
--enablecache
|
Activer nscd
|
--disablecache
|
Désactiver nscd
|
--nostart
|
Ne pas démarrer ou arrêter les services portmap , ypbind ou nscd , même s'ils sont configurés
|
--kickstart
|
Ne pas afficher l'interface utilisateur |
--probe
|
Détecter et afficher les valeurs par défaut du réseau |
Une des fonctions d'un administrateur système est de configurer le système pour différentes tâches, les types d'utilisateurs et les configurations de matériel. Cette section expose comment configurer un système Red Hat Enterprise Linux.
Table des matières
/sysconfig/
/etc/sysconfig/
/etc/sysconfig/amd
/etc/sysconfig/apmd
/etc/sysconfig/arpwatch
/etc/sysconfig/authconfig
/etc/sysconfig/autofs
/etc/sysconfig/clock
/etc/sysconfig/desktop
/etc/sysconfig/dhcpd
/etc/sysconfig/exim
/etc/sysconfig/firstboot
/etc/sysconfig/gpm
/etc/sysconfig/hwconf
/etc/sysconfig/i18n
/etc/sysconfig/init
/etc/sysconfig/ip6tables-config
/etc/sysconfig/iptables-config
/etc/sysconfig/irda
/etc/sysconfig/keyboard
/etc/sysconfig/kudzu
/etc/sysconfig/named
/etc/sysconfig/network
/etc/sysconfig/nfs
/etc/sysconfig/ntpd
/etc/sysconfig/radvd
/etc/sysconfig/samba
/etc/sysconfig/selinux
/etc/sysconfig/sendmail
/etc/sysconfig/spamassassin
/etc/sysconfig/squid
/etc/sysconfig/system-config-securitylevel
/etc/sysconfig/system-config-selinux
/etc/sysconfig/system-config-users
/etc/sysconfig/system-logviewer
/etc/sysconfig/tux
/etc/sysconfig/vncservers
/etc/sysconfig/
Lorsque les utilisateurs normaux (c'est-à-dire les utilisateurs qui ne sont pas des super-utilisateurs) se connectent localement à un ordinateur, ils ont deux types de permissions spéciales :
Ils peuvent exécuter certains programmes qu'ils n'auraient pas le droit d'exécuter autrement.
Ils peuvent accéder à certains fichiers (habituellement des fichiers de périphériques spéciaux permettant d'accéder aux disquettes, CD-ROM, etc.) auxquels ils ne pourraient pas accéder autrement.
Étant donné qu'il existe plusieurs consoles sur un ordinateur et que plusieurs utilisateurs peuvent être simultanément connectés à l'ordinateur localement, l'un des utilisateurs doit "gagner la course" pour l'accès aux fichiers. Le premier utilisateur à se connecter à la console est propriétaire de ces fichiers. Une fois que le premier utilisateur se déconnecte, l'utilisateur qui se connecte ensuite devient propriétaire des fichiers.
Par contraste, tous les utilisateurs se connectant à la console seront autorisés à exécuter des programmes accomplissant des tâches normalement réservées au super-utilisateur. Si X est en cours d'exécution, ces actions peuvent être incluses en tant qu'éléments de menu dans une interface utilisateur graphique. Les programmes accessibles de la console comprennent halt
, poweroff
et reboot
.
Par défaut, /etc/inittab
spécifie que votre système est configuré pour arrêter et redémarrer en réponse à la combinaison de touches Ctrl-Alt-Suppr utilisée sur la console. Si vous voulez désactiver cette fonction, mettez en commentaire la ligne suivante de /etc/inittab
en la faisant précéder d'un signe dièse (#
) :
ca::ctrlaltdel:/sbin/shutdown -t3 -r now
Ceci étant, vous préférez peut-être autoriser certains utilisateurs normaux à arrêter ou redémarrer le système de la console à l'aide de la combinaison Ctrl-Alt-Suppr. Pour réserver ce privilège à certains utilisateurs, suivez les étapes ci-dessous :
Ajoutez l'option -a
à la ligne /etc/inittab
indiquée ci-dessus, afin qu'elle devienne :
ca::ctrlaltdel:/sbin/shutdown -a -t3 -r now
L'option -a
signale à la commande shutdown
qu'elle doit rechercher le fichier /etc/shutdown.allow
.
Créez un fichier appelé shutdown.allow
dans /etc
. Le fichier shutdown.allow
doit répertorier les noms d'utilisateurs des personnes qui auront le droit d'arrêter le système à l'aide de la combinaison Ctrl-Alt-Suppr. Le fichier shutdown.allow
contient une liste d'utilisateurs énumérés un par un, ligne par ligne, ressemblant à l'extrait suivant :
stephen jack sophie
Selon cet exemple de fichier shutdown.allow
, stephen
, jack
et sophie
ont le droit d'arrêter le système à partir de la console en utilisant la combinaison de touches Ctrl-Alt-Suppr. Lorsque cette combinaison de touches est utilisée, la commande shutdown -a
dans /etc/inittab
vérifie si des utilisateurs mentionnés dans /etc/shutdown.allow
(ou le super-utilisateur) sont connectés sur une console virtuelle. Si c'est le cas, la procédure d'arrêt du système continuera ; sinon, un message d'erreur apparaîtra sur la console du système.
Pour obtenir de plus amples informations sur shutdown.allow
, reportez-vous à la page de manuel relative à shutdown
.
Pour désactiver l'accès des utilisateurs aux programmes de la console, exécutez la commande suivante en étant connecté en tant que super-utilisateur :
rm -f /etc/security/console.apps/*
Dans les environnements où la console est sécurisée (mots de passe BIOS et chargeur de démarrage configurés, combinaison Ctrl-Alt-Suppr désactivée, commutateurs d'alimentation et de ré-initialisation désactivés, etc.), vous préférez peut-être qu'aucun utilisateur ne puisse exécuter les commandes poweroff
, halt
et reboot
, accessibles à partir de la console par défaut.
Pour les désactiver, exécutez les commandes suivantes en tant que super-utilisateur :
rm -f /etc/security/console.apps/poweroff
rm -f /etc/security/console.apps/halt
rm -f /etc/security/console.apps/reboot
Le module pam_console.so
utilise le fichier /etc/security/console.perms
pour déterminer les permissions des utilisateurs à la console du système. La syntaxe du fichier est très flexible ; vous pouvez éditer le fichier de façon à ce que ces instructions ne s'appliquent plus. Cependant, le fichier par défaut possède une ligne ressemblant à celle qui suit :
<console>=tty[0-9][0-9]* vc/[0-9][0-9]* :[0-9]\.[0-9] :[0-9]
Lorsque les utilisateurs se connectent, ils sont attachés à un genre de terminal nommé, soit un serveur X avec un nom comme :0
ou mymachine.example.com:1.0
, soit un dispositif comme /dev/ttyS0
ou /dev/pts/2
. Par défaut, les consoles virtuelles locales et les serveurs X locaux sont considérés comme locaux, mais si vous souhaitez considérer le terminal série se trouvant près de vous sur le port /dev/ttyS1
comme local lui aussi, changez cette ligne de façon à ce qu'elle devienne :
<console>=tty[0-9][0-9]* vc/[0-9][0-9]* :[0-9]\.[0-9] :[0-9] /dev/ttyS1
Les paramètres par défaut pour les catégories individuelles de périphériques et les définissions de permissions sont définis dans /etc/security/console.perms.d/50-default.perms
. Pour modifier les permissions des fichiers et des périphériques, nous vous recommandons de créer un nouveau fichier par défaut dans /etc/security/console.perms.d/
qui contient vos paramètres préférés pour un groupe spécifique de fichiers et périphériques. Le nom du nouveau fichier par défaut doit commencer avec un nombre supérieure à 50 (par exemple, 51-default.perms
) afin de surcharger 50-default.perms
.
Pour cela, créez un nouveau fichier appelé 51-default.perms
dans /etc/security/console.perms.d/
:
touch /etc/security/console.perms.d/51-default.perms
Ouvrez le fichier original par défaut perms
, 50-default.perms
. Les lignes de la première section définissant les classes de périphériques ressemblent à ce qui suit :
<floppy>=/dev/fd[0-1]* \ /dev/floppy/* /mnt/floppy* <sound>=/dev/dsp* /dev/audio* /dev/midi* \ /dev/mixer* /dev/sequencer \ /dev/sound/* /dev/beep \ /dev/snd/* <cdrom>=/dev/cdrom* /dev/cdroms/* /dev/cdwriter* /mnt/cdrom*
Les éléments entre parenthèses nomment le périphérique, dans l'exemple ci-dessus, <cdrom>
fait référence à un lecteur de CD-ROM. Pour ajouter un nouveau périphérique, ne le définissez pas dans le fichier par défaut 50-default.perms
; à la place, définissez-le dans 51-default.perms
. Par exemple, pour définir un scanner, ajoutez la ligne suivante dans 51-default.perms
:
<scanner>=/dev/scanner /dev/usb/scanner*
Évidemment, vous devez utiliser le nom approprié pour le périphérique. Assurez-vous que /dev/scanner
soit bien votre scanner et non un autre périphérique tel que votre disque dur.
Une fois que vous avez défini correctement un périphérique ou un fichier, la deuxième étape conciste à spécifier ses définitions de permissions. Les lignes de la deuxième section du fichier /etc/security/console.perms.d/50-default.perms
définissent cela. Elles ressemblent à ce qui suit :
<console> 0660 <floppy> 0660 root.floppy <console> 0600 <sound> 0640 root <console> 0600 <cdrom> 0600 root.disk
Afin de définir les permissions pour un scanner, ajoutez une ligne semblable à celle qui suit, dans 51-default.perms
:
<console> 0600 <scanner> 0600 root
Ensuite, lorsque vous vous connecterez à la console, vous deviendrez propriétaire du périphérique /dev/scanner
et les permissions seront 0600 (lecture et écriture par vous uniquement). Lorsque vous vous déconnectez, le périphérique est détenu par le super-utilisateur et les permissions 0600 sont maintenues (lecture et écriture par le super-utilisateur).
Vous ne devez jamais modifier le fichier par défaut 50-default.perms
. Pour modifier les permissions d'un périphérique qui est déjà défini dans 50-default.perms
, ajoutez la permission désirée pour ce périphérique dans 51-default.perms
. Les permissions définies dans 50-default.perms
seront alors surchargées.
Si vous souhaitez que les utilisateurs de la console aient accès à d'autres applications, suivez les étapes ci-dessous.
Tout d'abord, l'accès console fonctionne uniquement pour les applications résidant dans /sbin/
ou /usr/sbin/
; l'application souhaitée doit donc s'y trouver. Une fois que vous avez vérifié sa présence, suivez la procédure ci-dessous :
Créez un lien à partir du nom de votre application, comme le programme foo
de notre exemple, vers l'application /usr/bin/consolehelper
:
cd /usr/bin ln -s consolehelper foo
Créez le fichier /etc/security/console.apps/foo
:
touch /etc/security/console.apps/foo
Créez un fichier de configuration PAM pour le service foo
dans /etc/pam.d/
. Vous pouvez le faire facilement en copiant le fichier de configuration PAM du service halt
, puis en modifiant le fichier pour en changer le comportement :
cp /etc/pam.d/halt /etc/pam.d/foo
Désormais, lorsque vous exécuterez /usr/bin/
, le programme appellera foo
consolehelper
, qui authentifiera l'utilisateur à l'aide de /usr/sbin/userhelper
. Pour l'authentification, consolehelper
demandera le mot de passe de l'utilisateur, si /etc/pam.d/
est une copie de foo
/etc/pam.d/halt
(sinon, la commande fera ce qui est spécifié dans /etc/pam.d/
) et exécutera foo
/usr/sbin/
avec les permissions du super-utilisateur.
foo
Dans le fichier de configuration de PAM, une application peut être configurée pour utiliser le module pam_timestamp afin de mémoriser (ou mettre en cache) une tentative d'authentification réussie. Lorsqu'une application est démarrée et que l'authentification correcte est fournie (le mot de passe root), un fichier de référence temporelle (timestamp) est créé. Par défaut, une authentification réussie est mémorisée pendant cinq minutes. Pendant ce temps, toute autre application configurée pour utiliser pam_timestamp
et être lancée à partir de la même session, est authentifiée automatiquement pour l'utilisateur — l'utilisateur n'a donc plus besoin de ressaisir le mot de passe root.
Ce module est inclus dans le paquetage pam
. Pour activer cette fonctionnalité, ajoutez les lignes suivantes dans le fichier de configuration PAM présent dans etc/pam.d/
:
auth include config-util account include config-util session include config-util
Ces lignes peuvent être copiées à partir de l'un des fichiers de configuration /etc/pam.d/system-config-
. Notez que ces lignes doivent être ajoutées sous toute autre ligne *
auth sufficient
session optional
dans votre fichier de configuration PAM.
Si une application configurée pour utiliser pam_timestamp
est authentifiée avec succès depuis le menu Applications (the main menu on the panel), l'icône
est affichée dans la zone de notification du tableau de bord si vous utilisez l'environnement de bureau GNOME ou KDE. Lorsque l'authentification arrive à expiration (la valeur par défaut est de cinq minutes), l'icône disparaît.
L'utilisateur peut choisir d'oublier l'authentification mémorisée en cliquant sur l'icône et en sélectionnant l'option appropriée.
Si, pour une raison quelconque, l'accès console ne vous convient pas et que vous souhaitez octroyer aux utilisateurs autres que le super-utilisateur, l'accès au lecteur de disquettes de votre système, vous pouvez le faire en utilisant le groupe floppy
. Il vous suffit d'ajouter l'utilisateur ou les utilisateurs au groupe floppy
en vous servant de l'outil de votre choix. Ci-dessous figure un exemple illustrant l'utilisation de gpasswd
pour l'ajout de l'utilisateur fred
au groupe floppy
:
gpasswd -a fred floppy
L'utilisateur fred
pourra à présent accéder au lecteur de disquettes du système à partir de la console.
/etc/sysconfig/
/etc/sysconfig/amd
/etc/sysconfig/apmd
/etc/sysconfig/arpwatch
/etc/sysconfig/authconfig
/etc/sysconfig/autofs
/etc/sysconfig/clock
/etc/sysconfig/desktop
/etc/sysconfig/dhcpd
/etc/sysconfig/exim
/etc/sysconfig/firstboot
/etc/sysconfig/gpm
/etc/sysconfig/hwconf
/etc/sysconfig/i18n
/etc/sysconfig/init
/etc/sysconfig/ip6tables-config
/etc/sysconfig/iptables-config
/etc/sysconfig/irda
/etc/sysconfig/keyboard
/etc/sysconfig/kudzu
/etc/sysconfig/named
/etc/sysconfig/network
/etc/sysconfig/nfs
/etc/sysconfig/ntpd
/etc/sysconfig/radvd
/etc/sysconfig/samba
/etc/sysconfig/selinux
/etc/sysconfig/sendmail
/etc/sysconfig/spamassassin
/etc/sysconfig/squid
/etc/sysconfig/system-config-securitylevel
/etc/sysconfig/system-config-selinux
/etc/sysconfig/system-config-users
/etc/sysconfig/system-logviewer
/etc/sysconfig/tux
/etc/sysconfig/vncservers
/etc/sysconfig/
Le répertoire /etc/sysconfig/
contient de nombreux fichiers de configuration différents pour Red Hat Enterprise Linux.
Ce chapitre souligne certains des fichiers présents dans le répertoire /etc/sysconfig/
, leur fonction et leur contenu. Ces informations ne prétendent pas être exhaustives car nombre de ces fichiers sont une série d'options qui ne sont utilisées que dans des circonstances bien spécifiques et plutôt rares.
La section suivante fournit une description des fichiers qui se trouvent habituellement dans le répertoire /etc/sysconfig/
. Les fichiers qui ne sont pas mentionnés ici ainsi que les options de fichiers supplémentaires se trouvent dans le fichier /usr/share/doc/initscripts-
(remplacez <version-number>
/sysconfig.txt<version-number>
par le numéro de version du paquetage initscripts
). Il peut également s'avérer utile d'examiner les scripts d'initialisation dans le répertoire /etc/rc.d/
.
Si certains des fichiers énumérés ci-dessus ne sont pas présents dans le répertoire /etc/sysconfig/
, le programme correspondant n'est peut-être pas installé.
Le fichier /etc/sysconfig/amd
contient différents paramètres utilisés par amd
; ces derniers permettent le montage automatique et le démontage de systèmes de fichiers.
Le fichier /etc/sysconfig/apmd
est utilisé par apmd
pour configurer les paramètres d'alimentation spécifiques qui doivent être démarrés/arrêtés/modifiés en cas de suspension ou de reprise des opérations. Ce fichier configure le mode de fonctionnement de apmd
selon que le matériel prend en charge ou non la gestion avancée de l'énergie (ou APM de l'anglais Advanced Power Management) ou selon que l'utilisateur a configuré le système pour utiliser cette fonctionnalité. Le démon apm
est un programme de contrôle qui fonctionne avec le code de gestion d'énergie au sein du noyau Linux. Il est capable d'avertir les utilisateurs d'ordinateurs portables lorsque le niveau de la batterie est bas ou lorsqu'il y a un problème avec des paramètres liés à la source d'énergie.
Le fichier /etc/sysconfig/arpwatch
est utilisé pour transmettre des arguments au démon arpwatch
lors du démarrage. Le démon arpwatch
maintient une table d'adresses Ethernet MAC et leurs parités d'adresses IP. Par défaut, ce fichier attribue la propriété du processus arpwatch
à l'utilisateur pcap
et envoie tout message à la file d'attente de messages de root
. Pour obtenir de plus amples informations sur les paramètres que vous pouvez utiliser dans ce fichier, reportez-vous à la page de manuel de arpwatch
.
Le fichier /etc/sysconfig/authconfig
détermine l'autorisation devant être utilisée sur l'hôte. Il contient une ou plusieurs des lignes suivantes :
USEMD5=
, où <value>
correspond à un des éléments ci-dessous :
<value>
yes
— MD5 est utilisé pour l'authentification.
no
— MD5 n'est pas utilisé pour l'authentification.
USEKERBEROS=
, où <value>
correspond à un des éléments ci-dessous :
<value>
yes
— Kerberos est utilisé pour l'authentification.
no
— Kerberos n'est pas utilisé pour l'authentification.
USELDAPAUTH=
, où <value>
correspond à un des éléments ci-dessous :
<value>
yes
— LDAP est utilisé pour l'authentification.
no
— LDAP n'est pas utilisé pour l'authentification.
Le fichier /etc/sysconfig/autofs
définit les options personnalisées pour le montage automatique des périphériques. Il contrôle le fonctionnement des démons automount qui montent automatiquement des systèmes de fichiers lorsqu'ils sont utilisés et les démontent après une certaine période d'inactivité. Les systèmes de fichiers peuvent inclure des systèmes de fichiers réseau, des CD-ROM, des disquettes et bien d'autres supports.
Le fichier /etc/sysconfig/autofs
peut contienir les éléments suivants :
LOCALOPTIONS="
,où <value>
"<value>
représente une chaîne permettant de définir les règles automount spécifiques à la machine. La valeur par défaut est une chaîne vide (""
).
DAEMONOPTIONS="
, où <value>
"<value>
représente la durée du délai d'attente exprimée en secondes, avant que le périphérique ne soit démonté. La valeur par défaut est de 60 secondes ("--timeout=60"
).
UNDERSCORETODOT=
, où <value>
<value>
est une valeur binaire qui contrôle si les soulignements faisant partie dses noms de fichiers doivent être convertis en points. Par exemple, auto_home
en auto.home
et auto_mnt
en auto.mnt
. La valeur par défaut est 1 (vrai).
DISABLE_DIRECT=
, où <value>
<value>
est un binaire qui contrôle si la prise en charge du montage direct doit être désactivée, étant donné que l'implémentation de Linux ne se conforme pas au comportement de automonteur de Microsystems. La valeur par défaut de 1 (vrai) permet la compatibilité avec la syntaxe de spécification des options de l'automonteur de Sun.
Le fichier /etc/sysconfig/clock
contrôle l'interprétation des valeurs lues à partir de l'horloge matérielle du système.
Les valeurs correctes sont les suivantes :
UTC=
, où <value>
correspond à l'une des valeurs booléennes suivantes :
<value>
true
ou yes
— Indique que l'horloge matérielle est réglée sur l'heure universelle (celle du méridien de Greenwich).
false
ou no
— Indique que l'horloge matérielle est réglée sur l'heure locale.
ARC=
, où <value>
correspond à un des éléments suivants :
<value>
false
ou no
— Indique que l'époque normale UNIX est en cours d'utilisation. Les autres valeurs sont utilisées par des systèmes qui ne sont pas supportés par Red Hat Enterprise Linux.
SRM=
, où <value>
correspond à ce qui suit :
<value>
false
ou no
— Indique que l'époque normale UNIX est en cours d'utilisation. Les autres valeurs sont utilisées par des systèmes qui ne sont pas supportés par Red Hat Enterprise Linux.
ZONE=
— Indique le fichier de fuseau horaire dans <filename>
/usr/share/zoneinfo
dont /etc/localtime
est une copie, comme par exemple :
ZONE="America/New York"
Notez que le paramètre ZONE
est lu par Outil des propriétés d'heure et de date (system-config-date
), et l'éditer manuellement ne change pas le fuseau horaire du système.
Des versions précédentes de Red Hat Enterprise Linux utilisaient les valeurs suivantes (qui ne sont désormais plus valables) :
CLOCKMODE=
, où <value>
correspond à l'une des valeurs suivantes :
<value>
GMT
— Indique que l'horloge est réglée sur l'heure universelle (UTC : Universal Time Clock ou GMT : Greenwich Mean Time).
ARC
— Indique que le décalage de 42 ans de la console ARC est activé (pour les systèmes basés sur Alpha seulement).
Le fichier /etc/sysconfig/desktop
spécifie le bureau pour les nouveaux utilisateurs et le gestionnaire d'affichage à exécuter au niveau d'exécution 5.
Les valeurs correctes sont les suivantes :
DESKTOP="
, où <value>
""
correspond à l'une des valeurs suivantes :
<value>
"
GNOME
— Sélectionne l'environnement de bureau GNOME.
KDE
— Sélectionne l'environnement de bureau KDE.
DISPLAYMANAGER="
, où <value>
""
correspond à l'une des valeurs suivantes :
<value>
"
GNOME
— Sélectionne le gestionnaire d'affichage GNOME.
KDE
— Sélectionne le gestionnaire d'affichage KDE.
XDM
— Sélectionne le gestionnaire d'affichage X.
Pour de plus amples informations, reportez-vous au Chapitre 22, Système X Window.
Le fichier /etc/sysconfig/dhcpd
est utilisé pour transmettre des arguments au démon dhcpd
lors du démarrage. Le démon dhcpd
met en oeuvre les protocoles DHCP (Dynamic Host Configuration Protocol) et BOOTP (Internet Bootstrap Protocol). DHCP et BOOTP assignent des noms d'hôtes aux ordinateurs sur le réseau. Pour de plus amples informations sur les paramètres pouvant être utilisés dans ce fichier, consultez la page de manuel relative à dhcpd
.
Le fichier /etc/sysconfig/exim
permet d'envoyer des messages à un ou plusieurs clients, en acheminant les messages sur les réseaux nécessaires, quels qu'ils soient. Le fichier définit les valeurs par défaut pour l'exécution de exim. Ses valeurs par défaut sont définies de sorte qu'il soit exécuté comme un démon en tâche de fond et que sa file d'attente soit contrôlée une fois par heure, au cas où quelque chose aurait été sauvegardé.
Parmi ces valeurs figurent :
DAEMON=
, où <value>
correspond à une des valeurs suivantes :
<value>
yes
— exim
doit être configuré de sorte qu'il contrôle le port 25 afin de détecter le courrier entrant. La valeur yes
implique l'utilisation des options -bd
de l'application Exim.
no
— exim
ne doit pas être configuré pour contrôler le port 25 afin de détecter le courrier entrant.
QUEUE=1h
qui est donné à exim
en tant que -q$QUEUE
. L'option -q
n'est pas donnée à exim
si /etc/sysconfig/exim
existe et si la valeur de QUEUE
est vide ou non-définie.
Lors du premier démarrage du système, le programme /sbin/init
appelle le script etc/rc.d/init.d/firstboot
qui à son tour lance l' Agent de configuration. Cette application permet à l'utilisateur d'installer les dernières mises à jour ainsi que les applications et la documentation supplémentaires.
Le fichier /etc/sysconfig/firstboot
indique à l'application Agent de configuration de ne pas s'exécuter lors de prochains démarrages. Pour la lancer lors du prochain démarrage du système, supprimez /etc/sysconfig/firstboot
et exécutez chkconfig --level 5 firstboot on
.
Le fichier /etc/sysconfig/gpm
est utilisé pour transmettre des arguments au démon gpm
lors du démarrage. Le démon gpm
est le serveur souris qui permet l'accélération de la souris et le collage en cliquant sur le bouton central de la souris. Pour obtenir de plus amples informations sur les paramètres pouvant être utilisés dans ce fichier, consultez la page de manuel de gpm
. Par défaut, la directive DEVICE
a la valeur /dev/input/mice
.
Le fichier /etc/sysconfig/hwconf
affiche la liste de tout le matériel que kudzu
a détecté sur l'ordinateur, ainsi que des informations sur les pilotes utilisés, l'ID du fabricant et du périphérique. Le programme kudzu
détecte et configure le matériel nouveau et/ou changé sur un système. Le fichier /etc/sysconfig/hwconf
n'est pas supposé être modifié manuellement. Dans le cas où il le serait, certains périphériques pourraient soudainement apparaître comme étant des p'eriphériques ajoutés ou supprimés.
Le fichier /etc/sysconfig/i18n
règle la langue par défaut, toute langue prise en charge et la police de caractères par défaut. Par exemple :
LANG="en_US.UTF-8" SUPPORTED="en_US.UTF-8:en_US:en" SYSFONT="latarcyrheb-sun16"
Le fichier /etc/sysconfig/init
contrôle l'aspect et le fonctionnement du système pendant le processus de démarrage.
Les valeurs suivantes peuvent être utilisées :
BOOTUP=
, où <value>
correspond à un des éléments suivants :
<value>
color
— L'affichage couleur standard au démarrage, où la réussite ou l'échec de l'exécution des périphériques et des services est représentée par des couleurs différentes.
verbose
— Un affichage de style ancien qui fournit des informations plus détaillées qu'un simple message de réussite ou d'échec.
Toute autre valeur indique un nouvel affichage, mais sans formatage ANSI.
RES_COL=
, où <value>
correspond au numéro de la colonne de l'écran où commencer les étiquettes d'état. La valeur par défaut est 60.
<value>
MOVE_TO_COL=
, où <value>
déplace le curseur sur la valeur indiquée dans la ligne <value>
RES_COL
via la commande echo -en
.
SETCOLOR_SUCCESS=
, où <value>
configure la couleur indiquant la réussite via la commande <value>
echo -en
. Vert (green) est la couleur par défaut.
SETCOLOR_FAILURE=
, où <value>
configure la couleur indiquant un échec via la commande <value>
echo -en
. Rouge (red) est la couleur par défaut.
SETCOLOR_WARNING=
, où <value>
configure la couleur indiquant un avertissement via la commande <value>
echo -en
. Jaune (yellow) est la couleur par défaut.
SETCOLOR_NORMAL=
, où <value>
configure la couleur sur 'normal' via la commande <value>
echo -en
.
LOGLEVEL=
, où <value>
définit le niveau de journalisation initial de la console pour le noyau. La valeur par défaut est 3 ; 8 signifie tout (y compris le débogage) alors que 1 signifie seulement les paniques du noyau. Le démon <value>
syslogd
écrase ce paramètre lorsqu'il est lancé.
PROMPT=
, où <value>
correspond à l'une des valeurs booléennes suivantes :
<value>
yes
— Active le contrôle du mode interactif au clavier.
no
— Désactive le contrôle du mode interactif au clavier.
Le fichier /etc/sysconfig/ip6tables-config
stocke des informations utilisées par le noyau pour configurer des services de filtrage de paquets IPv6 au moment du démarrage ou chaque fois que le service ip6tables
est lancé.
Ne modifiez pas ce fichier manuellement à moins que vous ne soyez familier avec la manière de construire des règles ip6tables
. Il est possible de créer des règles manuellement à l'aide de la commande /sbin/ip6tables
. Une fois créées, ajoutez les règles dans le fichier /etc/sysconfig/ip6tables
en tapant la commande suivante :
/sbin/service ip6tables save
Une fois que ce fichier existe, toutes les règles de pare-feu sauvegardées ici seront conservées lors d'un redémarrage du système ou lors du redémarrage d'un service.
Le fichier /etc/sysconfig/iptables
stocke des informations utilisées par le noyau pour configurer des services de filtrage de paquets au démarrage ou chaque fois que le service est lancé.
Do not modify this file by hand unless you are familiar with constructing iptables
rules. The easiest way to add rules is to use the Outil de configuration du niveau de sécurité (system-config-securitylevel
) application to create a firewall. These applications automatically edit this file at the end of the process.
Il est également possible de créer des règles manuellement à l'aide de la commande /sbin/iptables
. Une fois créée(s), ajoutez la ou le(s) règle(s) au fichier /etc/sysconfig/iptables
en tapant la commande suivante :
/sbin/service iptables save
Une fois que ce fichier existe, toutes les règles de pare-feu sauvegardées ici seront conservées lors d'un redémarrage du système ou lors du redémarrage d'un service.
Le fichier /etc/sysconfig/irda
contrôle la configuration des périphériques à infrarouge de votre système lors du démarrage.
Les valeurs suivantes peuvent être utilisées :
IRDA=
, où <value>
correspond à une des valeurs booléennes suivantes :
<value>
yes
— irattach
est exécuté et vérifie de façon périodique si un périphérique quelconque essaie de se connecter au port infrarouge, comme par exemple, un autre ordinateur portable qui tente d'effectuer une connexion réseau. Pour que des périphériques à infrarouge fonctionnent sur le système. cette ligne doit avoir la valeur yes
.
no
— irattach
n'est pas exécutée, empêchant ainsi toute communication avec les périphériques à infrarouge.
DEVICE=
, où <value>
correspond au périphérique (habituellement un port série) qui traite les connexions à infrarouge. Une entrée pour un périphérique série pourrait être <value>
/dev/ttyS2
.
DONGLE=
, où <value>
spécifie le type de clé électronique utilisée pour une communication par infrarouge. Ce paramètre existe pour les personnes utilisant une clé électronique série plutôt que de vrais ports infrarouge. Une clé électronique est un dispositif qui est branché à un port série traditionnel pour la communication par infrarouge. Cette ligne est, par défaut, décommentée car les ordinateurs potables dotés de vrais ports à infrarouge sont beaucoup plus fréquents que ceux dotés de clés électroniques ajoutées. Une entrée pour une clé électronique pourrait être <value>
actisys+
.
DISCOVERY=
, où <value>
correspond à une des valeurs booléennes suivantes :
<value>
yes
— Lance irattach
en mode découverte, ce qui signifie qu'il cherche activement d'autres périphériques à infrarouge. Cette fonction doit être activée pour que l'ordinateur puisse chercher de façon active une connexion infrarouge (c'est-à-dire que l'élément ne prend pas l'initiative de la connexion).
no
— Ne lance pas irattach
en mode découverte.
Le fichier /etc/sysconfig/keyboard
contrôle le comportement du clavier. Il est possible d'utiliser les valeurs suivantes :
KEYBOARDTYPE="sun|pc"
, où la valeur sun
signifie qu'un clavier Sun est relié à /dev/kbd
et la valeur pc
indique qu'un clavier PS/2 est connecté à un port PS/2.
KEYTABLE=
, où <file>
représente le nom d'un fichier tableau de touches (keytable).
<file>
Comme, par exemple : KEYTABLE="us"
. Les fichiers pouvant être utilisés comme fichiers de clavier commencent dans /lib/kbd/keymaps/i386
et se ramifient de là, en différents types de claviers, portant tous l'étiquette
. Le premier fichier qui se trouve sous <fichier>
.kmap.gz/lib/kbd/keymaps/i386
et qui correspond au paramètre KEYTABLE
est utilisé.
Le fichier /etc/sysconfig/kuzdu
vous permet de spécifier la détection sécuritaire du matériel de votre ordinateur par kudzu
au moment du démarrage. Une détection sécuritaire désactive la détection de ports série.
SAFE=
, où <value>
correspond à une des valeurs suivantes :
<value>
yes
— kuzdu
exécute une détection sécuritaire.
no
— kuzdu
exécute une détection normale.
Le fichier /etc/sysconfig/named
est utilisé pour transmettre des arguments au démon named
au moment du démarrage. Le démon named
est un serveur Domain Name System (DNS) qui met en oeuvre le Berkeley Internet Name Domain (BIND) version 9. Ce serveur maintient une table dont les noms d'hôtes sont attachés à des adresses IP sur le réseau.
Actuellement, seules les valeurs suivantes peuvent être utilisées :
ROOTDIR=
, où "</some/where>"
fait référence au chemin d'accès du répertoire d'un environnement chroot sous lequel </some/where>
named
sera exécuté. Cet environnement chroot doit préalablement être configuré. Tapez info chroot
pour obtenir de plus amples informations sur la manière de procéder.
OPTIONS=
, où "<valeur>"
correspond à toute option listée dans la page de manuel relative à <value>
named
, à l'exception de -t
. Au lieu de -t
, utilisez la ligne de commande ROOTDIR
ci-dessus.
Pour obtenir de plus amples informations sur les différents paramètres pouvant être utilisés dans ce fichier, consultez la page de manuel relative à named
. Pour des renseignements détaillés sur la façon de configurer un serveur BIND DNS, reportez-vous au Chapitre 8, Berkeley Internet Name Domain (BIND). Par défaut, le fichier ne contient aucun paramètre.
Le fichier /etc/sysconfig/network
est utilisé pour spécifier des informations sur la configuration réseau désirée. Les valeurs suivantes peuvent être utilisées :
NETWORKING=
, où <value>
correspond à une des valeurs booléennes suivantes :
<value>
yes
— La mise en réseau devrait être configurée.
no
— La mise en réseau ne devrait pas être configurée.
HOSTNAME=
, où <value>
devrait être le le nom de domaine complet (FQDN de l'anglais Fully Qualified Domain Name), comme par exemple <value>
hostname.domain.com
, mais vous pouvez tout à fait utiliser le nom d'hôte de votre choix.
GATEWAY=
, où <value>
est l'adresse IP de la passerelle réseau.
<value>
GATEWAYDEV=
, where <value>
is the gateway device, such as <value>
eth0
. Configure this option if you have multiple interfaces on the same subnet, and require one of those interfaces to be the preferred route to the default gateway.
NISDOMAIN=
, où <value>
est le nom de domaine NIS.
<value>
NOZEROCONF=
, où le paramètre <value>
à <value>
true
désactive la route zeroconf.
Par défaut, la route zeroconf (169.254.0.0) est active lorsque le système démarre. Pour davantage d'informations à propos de zeroconf, visitez le lien suivant : http://www.zeroconf.org/.
Do not use custom initscripts to configure network settings. When performing a post-boot network service restart, custom initscripts configuring network settings that are run outside of the network init script lead to unpredictable results.
NFS requires the portmap, which dynamically assigns ports for RPC services. This causes problems for configuring firewall rules. To overcome this problem, use the /etc/sysconfig/nfs
file to control which ports the required RPC services run on.
The /etc/sysconfig/nfs
may not exist by default on all systems. If it does not exist, create it and add the following variables (alternatively, if the file exists, un-comment and change the default entries as required):
MOUNTD_PORT="x
"
control which TCP and UDP port mountd (rpc.mountd) uses. Replace x
with an unused port number.
STATD_PORT="x
"
control which TCP and UDP port status (rpc.statd) uses. Replace x
with an unused port number.
LOCKD_TCPPORT="x
"
control which TCP port nlockmgr (rpc.lockd) uses. Replace x
with an unused port number.
LOCKD_UDPPORT="x
"
control which UDP port nlockmgr (rpc.lockd) uses. Replace x
with an unused port number.
If NFS fails to start, check /var/log/messages
. Normally, NFS will fail to start if you specify a port number that is already in use. After editing /etc/sysconfig/nfs
restart the NFS service by running the service nfs restart
command. Run the rpcinfo -p
command to confirm the changes.
To configure a firewall to allow NFS:
Allow TCP and UDP port 2049 for NFS.
Allow TCP and UDP port 111 (portmap/sunrpc).
Allow the TCP and UDP port specified with MOUNTD_PORT="
x
"
Allow the TCP and UDP port specified with STATD_PORT="
x
"
Allow the TCP port specified with LOCKD_TCPPORT="
x
"
Allow the UDP port specified with LOCKD_UDPPORT="
x
"
Le fichier /etc/sysconfig/ntpd
est utilisé pour transmettre des arguments au démon ntpd
au moment du démarrage. Le démon ntpd
paramètre et maintient l'horloge du système pour qu'elle soit synchronisée avec un serveur de temps standard Internet. Il implémente la version 4 du protocole NTP (de l'anglais Network Time Protocol). Pour de plus amples informations sur les paramètres que vous pouvez utiliser dans ce fichier, consultez la page suivante à l'aide de votre navigateur Web : /usr/share/doc/ntp-
(où <version>
/ntpd.htm<version>
correspond au numéro de la version de ntpd
). Par défaut, ce fichier attribue la propriété du processus ntpd
à l'utilisateur ntp
.
Le fichier /etc/sysconfig/radvd
est utilisé pour transmettre des arguments au démon radvd
au moment du démarrage. Le démon radvd
est à l'écoute des requêtes du routeur et envoie des annonces pour le protocole IP version 6. Ce service permet aux hôtes sur un réseau de modifier de façon dynamique leurs routeurs par défaut, sur la base de ces annonces de routeur. Pour obtenir de plus amples informations sur les paramètres que vous pouvez utiliser dans ce fichier, consultez la page de manuel relative à radvd
. Par défaut, ce fichier attribue la propriété du processus radvd
à l'utilisateur radvd
.
Le fichier /etc/sysconfig/samba
est utilisé pour transmettre des arguments aux démons smbd
et nmbd
au moment du démarrage. Le démon smbd
offre une connectivité de partage de fichiers pour les clients Windows sur le réseau. Le démon nmbd
offre NetBIOS sur les services de nommage IP. Pour de plus amples informations sur les paramètres pouvant être utilisés dans ce fichier, consultez la page de manuel relative à smbd
. Par défaut, ce fichier règle le fonctionnement de smbd
et nmbd
en mode démon.
Le fichier /etc/sysconfig/selinux
contient les options de configuration élémentaires pour SELinux. Ce dernier est un lien symbolique vers /etc/selinux/config
.
Le fichier /etc/sysconfig/sendmail
permet d'envoyer des messages à un ou plusieurs clients, en acheminant les messages sur les réseaux nécessaires, quels qu'ils soient. Le fichier définit les valeurs par défaut pour que l'application Sendmail soit exécutée. Ses valeurs par défaut sont déterminées de sorte que l'application soit exécutée comme un démon en tâche de fond et qu'elle contrôle sa file d'attente une fois par heure, au cas où quelque chose aurait été sauvegardé.
Parmiles valeurs figurent :
DAEMON=
, où <value>
correspond à une des valeurs suivantes :
<value>
yes
— Sendmail doit être configuré pour contrôler le port 25 afin de détecter le courrier entrant. La valeur yes
implique l'utilisation des options -bd
avec Sendmail.
no
— Sendmail ne doit pas être configuré pour contrôler le port 25 afin de détecter le courrier entrant.
QUEUE=1h
qui est donné à Sendmail en tant que -q$QUEUE
. L'option -q
n'est pas donnée à Sendmail si le fichier /etc/sysconfig/sendmail
existe et que QUEUE
est vide ou non-défini.
Le fichier /etc/sysconfig/spamassassin
est utilisé pour transmettre des arguments au démon spamd
(une version 'démonisée' de Spamassassin) lors du démarrage. Spamassassin est une application de messagerie pour le filtrage de pourriel (spam). Pour obtenir une liste des options disponibles, consultez la page de manuel de spamd
. Par défaut, il configure spamd
de sorte qu'il soit exécuté en mode démon, qu'il crée des préférences utilisateur et qu'il crée automatiquement des listes blanches (expéditeurs de courrier en gros autorisés).
Pour de plus amples informations sur Spamassassin, consultez Section 15.5.2.6, « Filtres de spam ».
Le fichier /etc/sysconfig/squid
est utilisé pour transmettre des arguments au démon squid
au moment du démarrage. Le démon squid
est un serveur proxy de cache pour des applications clientes par le Web. Pour de plus amples informations sur la configuration d'un serveur proxy squid
, ouvrez le répertoire /usr/share/doc/squid-
à l'aide de votre navigateur (remplacez <version>
/<version>
par le numéro de la version squid
installée sur votre système). Par défaut, ce fichier règle le démarrage de squid
en mode démon et détermine la durée devant s'écouler avant un arrêt automatique.
Le fichier /etc/sysconfig/system-config-users
est le fichier de configuration pour l'application graphique Gestionnaire d'utilisateurs. Ce fichier est utilisé pour filtrer les utilisateurs du système tels que root
, daemon
, ou lp
. Ce fichier peut être édité depuis le menu déroulant Préférences => Filtrer les utilisateurs et les groupes du système dans le Gestionnaire d'utilisateurs et ne devrait jamais être modifié manuellement. Pour de plus amples informations sur l'utilisation de cette application, reportez-vous à la Section 24.1, « Configuration des utilisateurs et des groupes ».
Le fichier /etc/sysconfig/system-logviewer
est le fichier de configuration pour l'application graphique et interactive d'affichage de journal, Afficheur de journal. Ce fichier peut être édité depuis le menu déroulant Éditer => Préférences dans l'Afficheur de journal et ne doit pas être modifié manuellement. Pour de plus amples informations sur l'utilisation de cette application, reportez-vous à la Chapitre 27, Fichiers journaux.
Le fichier /etc/sysconfig/tux
est le fichier de configuration de Red Hat Content Accelerator (précédemment appelé TUX), le serveur Web basé sur le noyau. Pour de plus amples informations sur la configuration de Red Hat Content Accelerator, ouvrez /usr/share/doc/tux-
à l'aide de votre navigateur (remplacez <version>
/tux/index.html<version>
par le numéro de la version de TUX installée sur votre système). Les paramètres disponibles pour ce fichier sont énumérés dans /usr/share/doc/tux-
.
<version>
/tux/parameters.html
Le fichier /etc/sysconfig/vncservers
configure la façon dont le serveur Virtual Network Computing (ou VNC) démarre.
VNC est un système d'affichage à distance qui vous permet de visualiser un environnement de bureau non seulement sur l'ordinateur où il est exécuté mais également sur différents réseaux présents sur des architectures variées.
Ce dernier peut contenir les éléments suivants :
VNCSERVERS=
, où <value>
est réglée sur une valeur de type <value>
"1:fred"
, pour indiquer qu'un serveur VNC devrait être démarré par l'utilisateur fred sur l'écran :1. L'utilisateur fred doit avoir configuré un mot de passe VNC en utilisant la commande vncpasswd
avant d'essayer de se connecter au serveur VNC distant.
Les répertoires suivants se trouvent normalement dans /etc/sysconfig/
.
apm-scripts/
Ce répertoire contient le script APM suspendre/reprendre. N'éditez pas directement ce fichier. Si vous devez le personnaliser, il suffit de créer un fichier nommé /etc/sysconfig/apm-scripts/apmcontinue
qui estinvoqué à la fin du script. Vous pouvez également contrôler le script en éditant /etc/sysconfig/apmd
.
cbq/
Ce répertoire contient les fichiers de configuration nécessaires pour le Class Based Queuing (rangement selon la classe) pour la gestion de la largeur de bande sur les interfaces réseau. CBQ organise le trafic des utilisateurs en une hiérarchie de classes basée sur une combinaison quelconque des éléments adresse IP, protocoles et types d'applications.
networking/
Ce répertoire est utilisé par l'Outil d'administration du réseau (system-config-network
) et son contenu ne devrait pas être modifié manuellement. Pour de plus amples informations sur la configuration des interfaces réseau à l'aide de l' Outil d'administration du réseau, reportez-vous au Chapitre 6, Configuration réseau.
network-scripts/
Ce répertoire contient les fichiers de configuration relatifs au réseau ci-dessous :
Les fichiers de configuration réseau pour chaque interface réseau configurée, comme par exemple, ifcfg-eth0
pour l'interface Ethernet eth0
.
Les scripts utilisés pour activer et désactiver des interfaces réseau, comme par exemple, ifup
et ifdown
.
Les scripts utilisés pour activer et désactiver des interfaces réseau ISDN, comme par exemple, ifup-isdn
et ifdown-isdn
.
Divers scripts de fonctions réseau partagés, qu'il est vivement déconseillé de modifier directement.
Pour de plus amples informations sur le répertoire network-scripts
, reportez-vous au Chapitre 5, Interfaces réseau .
rhn/
Ce répertoire contient les fichiers de configuration ainsi que les clés GPG pour Red Hat Network. Aucun fichier de ce répertoire ne devrait être édité manuellement. Pour de plus amples informations sur Red Hat Network, consultez son site Web de Red Hat Network à l'adresse suivante : https://rhn.redhat.com/.
L'intention de ce chapitre est seulement de fournir une introduction aux fichiers contenus dans le répertoire /etc/sysconfig/
. Pour obtenir des renseignements plus détaillés, consultez la source d'informations mentionnée ci-dessous.
/usr/share/doc/initscripts-
— Ce fichier contient une liste plus complète des fichiers se trouvant dans le répertoire <version-number>
/sysconfig.txt/etc/sysconfig/
et des options qu'ils acceptent. L'élément <version-number>
dans le chemin d'accès vers ce fichier correspond à la version installée du paquetage initscripts
.
L'Outil des propriétés d'heure et de date permet à l'utilisateur de changer l'heure et la date du système, de configurer le fuseau horaire utilisé par le système et de régler le démon "Network Time Protocol" (NTP) pour synchroniser l'horloge du système avec un serveur de temps.
Vous devez démarrer le système X Window et avoir les privilèges super-utilisateur pour utiliser l'outil. Il y a trois manières différentes afin de démarrer l'application :
À partir du bureau, aller à Applications (the main menu on the panel) => Configurations du système => Date & Heure
À partir du bureau, cliquez avec le bouton droit de la souris sur l'heure dans la barre d'outils et sélectionnez Ajuster la date et l'heure.
Tapez la commande suivante à l'invite shell (par exemple, dans un terminal XTerm ou GNOME) : system-config-date
, system-config-time
, ou dateconfig
.
Comme indiqué dans la Figure 20.1, « Propriétés d'heure et de date », la première fenêtre qui apparaît permet de configurer l'heure et la date du système.
Pour modifier la date, utilisez les flèches situées à gauche et à droite du mois pour changer le mois, utilisez les flèches situées à gauche et à droite de l'année pour changer l'année et cliquez sur le jour de la semaine pour le changer.
Pour modifier l'heure, utilisez les flèches haut et bas situées à côté des éléments Heure, Minute et Seconde dans la section Heure.
Une fois que vous cliquez sur le bouton Valider, tous les changements que vous avez apportés à l'heure et à la date, à la configuration du démon NTP et à la configuration du fuseau horaire seront appliqués. Ensuite, le programme sera fermé.
Comme indiqué dans la Figure 20.2, « Propriétés NTP », la deuxième fenêtre qui apparaît permet de configurer NTP.
Le démon 'Network Time Protocol' (NTP) synchronise l'horloge du système avec un serveur de temps ou une source de temps distant. L'application vous permet de configurer un démon NTP pour synchroniser l'horloge de votre système avec un serveur distant. Pour activer cette fonction, cliquez sur le bouton Activer le protocole de synchronisation de réseau. Ce faisant, la liste et les autres options des Serveurs NTP seront activées. Vous pouvez choisir l'un des serveurs prédéfinis, modifier un serveur prédéfini en cliquant sur Modifier ou ajouter un nouveau nom de serveur en cliquant sur Ajouter. Votre système ne commencera pas la synchronisation avec le serveur NTP tant que vous n'aurez pas cliqué sur le bouton Valider. Une fois vos choix confirmés en cliquant sur Valider, la configuration sera enregistrée et le démon NTP sera lancé (ou relancé s'il est déjà en cours d'exécution).
Une fois que vous cliquez sur le bouton Valider, tous les changements que vous avez apportés à l'heure et à la date, à la configuration du démon NTP et à la configuration du fuseau horaire seront appliqués. Ensuite, le programme sera fermé.
Comme indiqué dans la Figure 20.3, « Propriétés du fuseau horaire », la troisième fenêtre qui apparaît permet de configurer l'heure et la date du système.
Pour configurer le fuseau horaire du système, cliquez sur l'onglet Fuseau horaire. Vous pouvez modifier le fuseau horaire en utilisant la carte interactive ou en choisissant le fuseau souhaité dans la liste figurant sous la carte du monde. Pour utiliser cette carte, cliquez sur la ville représentant le fuseau horaire désiré. Un X rouge apparaîtra alors et la sélection du fuseau horaire changera dans la liste figurant sous la carte.
Alternativement, vous pouvez également utiliser la liste figurant sous la carte. Comme la carte vous permet de choisir une région avant de sélectionner la ville, la liste des fuseaux est maintenant une liste arborescente, avec les villes et les pays groupés par continent. Des fuseaux non-géographiques ont également été ajoutés pour répondre aux besoins de la communauté scientifique.
Cliquez sur Valider pour que les changements prennent effet et quitter le programme.
Si l'horloge de votre système est réglée pour utiliser le temps UTC, sélectionnez l'option Horloge système en UTC. UTC correspond au fuseau horaire universel (Universal Time, Coordinated), également connu sous le nom de Greenwich Mean Time (GMT). Les autres fuseaux horaires sont déterminés par l'addition à ou la soustraction de l'heure UTC.
Le programme d'installation vous permet de configurer la disposition du clavier pour votre système. Pour configurer une disposition différente après l'installation, utilisez l'Outil de configuration du clavier.
Pour démarrer l'Outil de configuration du clavier, sélectionnez System (on the panel) => Administration => Clavier, ou exécutez la commande system-config-keyboard
à l'invite du shell.
Sélectionnez la disposition du clavier à partir de la liste (par exemple, U.S. English) et cliquez sur le bouton Valider.
Les changements prennent effet immédiatement.
Alors que le coeur de Red Hat Enterprise Linux est son noyau, pour beaucoup d'utilisateurs, le visage du système d'exploitation est l'environnement graphique fourni par le Système X Window, également appelé X.
D'autres environnements de fenêtrage ont existé dans le monde UNIX, y compris certains qui sont apparus avant la sortie du Système X Window en juin 1984. Néanmoins, X a été l'environnement graphique par défaut pour la plupart des systèmes d'exploitation de type UNIX. Red Hat Enterprise Linux l'utilise depuis de nombreuses années.
L'environnement graphique pour Red Hat Enterprise Linux est fourni par X.Org Foundation, un consortium Open Source créé pour gérer le développement et la stratégie du système X Window et des technologies connexes. X.Org est un projet de grande envergure qui se développe rapidement grâce à des centaines de développeurs résidant dans le monde entier. Il offre non seulement une prise en charge étendue pour une grande variété de périphériques et d'architectures, mais a également la capacité de tourner sur différents systèmes d'exploitation et sur des plates-formes variées. Cette version de Red Hat Enterprise Linux inclut tout particulièrement la version X11R7.1 du système X Window.
Le système X Window utilise une architecture client-serveur. Le serveur X (le binaire Xorg
) est à l'écoute de connexions venant d'applications client X par le biais d'un réseau ou d'une interface de boucle locale (loopback interface). Le serveur communique avec le matériel, comme la carte vidéo, le moniteur, le clavier et la souris. Les applications client X se trouvent dans l'espace utilisateur, créant une interface utilisateur graphique (ou GUI de l'anglais Graphical User Interface) pour l'utilisateur et transmettant les requêtes de ce dernier au serveur X.
Red Hat Enterprise Linux 5.0.0 utilise maintenant la version X11R7.1 comme le système X Window de base, qui inclut plusieurs pilotes vidéo, EXA et des améliorations de support de plateforme par rapport aux versions précédentes. De plus, cette version inclut également plusieurs fonctionnalités de configuration automatique pour le serveur X.
X11R7.1 is the first release to take specific advantage of the modularization of the X Window System. This modularization, which splits X into logically distinct modules, makes it easier for open source developers to contribute code to the system.
Red Hat Enterprise Linux ne fournit plus les paquetages serveur XFree86™. Avant d'effectuer une mise à niveau vers la dernière version de Red Hat Enterprise Linux, assurez-vous que la carte vidéo du système est bien compatible avec la version X11R7.1 ; pour ce faire, consultez la liste de compatibilité matérielle de Red Hat disponible en ligne à l'adresse suivante : http://hardware.redhat.com/.
Dans la version X11R7.1, toutes les librairies, en-têtes et tous les binaires se trouvent maintenant sous /usr/
à la place de /usr/X11R6
. Le répertoire /etc/X11/
contient des fichiers de configuration pour les applications client X et serveur X. Parmi ceux-ci figurent les fichiers de configuration pour le serveur X lui-même, le serveur de polices xfs
, les gestionnaires d'affichage X et bien d'autres composants de base.
Il est important de noter ici que le fichier de configuration pour la nouvelle architecture de polices basée sur Fontconfig est encore /etc/fonts/fonts.conf
. Pour de plus amples informations sur la configuration et l'ajout de polices, reportez-vous à la Section 22.4, « Polices ».
Étant donné que le serveur X effectue des tâches avancées sur une large gamme de matériel, il requiert des informations détaillées à propos du matériel sur lequel il travaille. Le serveur X détecte automatiquement certaines de ces informations ; les autres doivent être configurées.
Le programme d'installation met en place et configure X automatiquement, à moins que les paquetages de la version X11R7.1 ne soient pas sélectionnés pour l'installation. Toutefois, si le moniteur, la carte vidéo ou d'autres périphériques changent, X devra être reconfiguré. Pour ce faire, la meilleure façon consiste à utiliser l'Outil de configuration X (system-config-display
), en particulier pour les périphériques qui ne sont pas détectés manuellement.
Dans l'environnement graphique par défaut de Red Hat Enterprise Linux, l'Outil de configuration X est disponible sous System (on the panel) => Administration => Affichage.
Les changements effectués avec l'Outil de configuration X prennent effet après que vous vous soyez reconnecté.
Pour obtenir de plus amples informations sur l'Outil de configuration X, reportez-vous au Chapitre 23, Configuration du système X Window.
Dans certaines situations, il sera peut-être nécessaire de reconfigurer manuellement le serveur X en éditant son fichier de configuration /etc/X11/xorg.conf
. Pour obtenir de plus amples informations sur la structure de ce fichier, reportez-vous à la Section 22.3, « Fichiers de configuration du serveur X ».
Une fois qu'un serveur X tourne, les applications client X peuvent s'y connecter et créer une GUI pour l'utilisateur. Avec Red Hat Enterprise Linux, il existe une grande variété de GUI qui vont de l'interface rudimentaire du gestionnaire de fenêtres Tab Window Manager à celle hautement sophistiquée et interactive de l'environnement de bureau GNOME que la plupart des utilisateurs Red Hat Enterprise Linux utilisent.
Afin de créer cette dernière interface très perfectionnée, deux catégories principales d'applications client X doivent être connectées au serveur X : un environnement de bureau et un gestionnaire de fenêtres.
Un environnement de bureau intègre des clients X variés pour créer un environnement d'utilisateur graphique commun ainsi qu'une plateforme de développement.
Les environnements de bureau contiennent des fonctions plus avancées qui permettent aux clients X et autres processus en cours de communiquer les uns avec les autres. Ce faisant, toutes les applications écrites pour cet environnement peuvent également effectuer des tâches avancées comme les opérations de glisser-déposer.
Red Hat Enterprise Linux fournit deux environnements de bureau :
GNOME — L'environnement de bureau par défaut pour Red Hat Enterprise Linux qui est basé sur la boîte à outils graphique GTK+ 2.
KDE — Un autre environnement de bureau basé sur la boîte à outils graphique Qt 3.
Aussi bien GNOME que KDE disposent non seulement d'applications de productivité avancées, comme des traitements de texte, des tableurs et des navigateurs Web, mais fournissent également des outils permettant de personnaliser l'apparence de la GUI. De plus, si les deux bibliothèques GTK+ 2 et Qt sont installées, les applications de KDE peuvent être exécutées dans un environnement GNOME et vice versa.
Les gestionnaires de fenêtres sont des programmes client X qui font partie d'un environnement de bureau ou, dans certains cas, sont des applications à part entière. Leur objectif principal est de contrôler le positionnement, le redimensionnement et le déplacement des fenêtres graphiques. Les gestionnaires de fenêtres contrôlent également les barres de titres, le comportement de la cible de saisie (ou focus) de la fenêtre et les liaisons personnalisées des touches et des boutons souris.
Quatre gestionnaires de fenêtres sont compris dans Red Hat Enterprise Linux :
kwin
Le gestionnaire de fenêtres KWin est le choix par défaut pour l'environnement de bureau KDE. Il s'agit d'un gestionnaire simple et efficace qui supporte des thèmes personnalisés.
metacity
Le gestionnaire de fenêtres Metacity est le choix par défaut pour l'environnement de bureau GNOME. Il s'agit d'un gestionnaire simple et efficace qui supporte des thèmes personnalisés. Pour démarrer ce gestionnaire de fenêtres, vous devez installer le paquetage metacity
.
mwm
Le gestionnaire de fenêtres Motif (mwm
) est un gestionnaire de fenêtres autonome doté de fonctions élémentaires. Étant donné qu'il est supposé être un gestionnaire de fenêtres autonome, il ne devrait pas être utilisé de concert avec les environnements de bureau GNOME ou KDE. Pour démarrer ce gestionnaire de fenêtres, vous devez installer le paquetage openmotif
.
twm
Le gestionnaire de fenêtres minimaliste Tab Window Manager (twm
) qui fournit la panoplie d'outils la plus élémentaire de tous les gestionnaires de fenêtres peut être utilisé de manière autonome ou avec un environnement de bureau. Il est installé en tant que composant de la version X11R7.1.
Pour démarrer un des gestionnaires de fenêtres susmentionnés, vous devrez d'abord démarrer en niveau d'exécution 3. Pour davantage d'instructions sur la façon de procéder, reportez-vous à la Section 7.1, « Niveaux d'exécution ».
Une fois que vous êtes connecté en niveau d'exécution 3, on vous présentera une invite de terminal et non pas un environnement graphique. Pour démarrer un gestionnaire de fenêtres, tapez xinit -e
à l'invite.
<path-to-window-manager>
correspond à l'emplacement du fichier binaire du gestionnaire de fenêtres. Vous pourrez trouver ce fichier binaire en tapant <path-to-window-manager>
which
, où window-manager-name
correspond au nom du gestionnaire de fenêtres que vous voulez démarrer.
window-manager-name
Par exemple :
user@host#which twm
/usr/bin/twm
user@host#xinit -e /usr/bin/twm
La première commande ci-dessus retourne le chemin absolu au gestionnaire de fenêtres twm
, la deuxième commande démarre twm
.
Pour quitter un gestionnaire de fenêtres, fermez la dernière fenêtre ou appuyez sur Ctrl-Alt-Retour arrière. Une fois que vous avez quitté le gestionnaire de fenêtres, vous pouvez vous reconnecter en niveau d'exécution 5 en tapant startx
à l'invite.
Le serveur X est un exécutable binaire unique (/usr/bin/Xorg
). Des fichiers de configuration associés sont stockés dans le répertoire /etc/X11/
(as est un lien symbolique — X — qui pointe vers /usr/bin/Xorg
). Le fichier de configuration pour le serveur X est /etc/X11/xorg.conf
.
Le répertoire /usr/lib/xorg/modules/
contient des modules du serveur X qui peuvent être chargés dynamiquement à l'exécution. Par défaut, seuls certains modules dans la /usr/lib/xorg/modules/
sont automatiquement chargés par le serveur X.
Pour charger des modules optionnels, vous devez les ajouter dans le fichier de configuration du serveur X, /etc/X11/xorg.conf
. Pour davantage d'informations à propos des modules de chargement, reportez-vous à la Section 22.3.1.5, « Module
».
When Red Hat Enterprise Linux 5.2 is installed, the configuration files for X are created using information gathered about the system hardware during the installation process.
Bien qu'il soit rarement nécessaire de modifier manuellement le fichier de configuration /etc/X11/xorg.conf
, il est utile d'avoir une certaine compréhension des différentes sections et des paramètres optionnels qui existent, surtout lors de la résolution de problèmes.
Le fichier /etc/X11/xorg.conf
est composé de nombreuses sections différentes qui traitent d'aspects spécifiques du matériel du système.
Chaque section commence par une ligne Section "
(où <section-name>
"<section-name>
correspond au titre de la section) et finit par une ligne EndSection
. Dans chacune de ces sections se trouvent des lignes contenant des noms d'options et au moins une valeur d'option, qui peut se trouver entre guillemets ("
).
Les lignes commençant par un symbole dièse (#
) ne sont pas lues par le serveur X et sont utilisées pour des commentaires lisibles par les utilisateurs.
Certaines options contenues dans le fichier /etc/X11/xorg.conf
acceptent une valeur booléenne qui permet d'activer ou de désactiver la fonctionnalité. Parmi les valeurs booléennes acceptables figurent :
1
, on
, true
ou yes
— Ces valeurs permettent d'activer l'option.
0
, off
, false
ou no
— Ces valeurs permettent de désactiver l'option.
La liste suivante contient certaines des sections les plus importantes d'un fichier /etc/X11/xorg.conf
typique ; ces dernières sont énumérées dans l'ordre précis dans lequel elles apparaissent dans le fichier. Des informations plus détaillées sur le fichier de configuration du serveur X sont disponibles dans la page de manuel de xorg.conf
.
La section facultative ServerFlags
contient divers paramètres globaux du serveur X. Tous les réglages figurant dans cette section peuvent être surchargés par les options spécifiées dans la section ServerLayout
(reportez-vous à la Section 22.3.1.3, « ServerLayout
» pour davantage d'informations).
Les entrées dans la section ServerFlags
se trouvent sur leurs propres lignes et commencent par le terme Option
suivi d'une option spécifiée entre guillemets ("
).
Ci-dessous figure un exemple de section ServerFlags
:
Section "ServerFlags" Option "DontZap" "true" EndSection
Parmi certaines des options les plus utiles figurent :
"DontZap" "
— La valeur de <boolean>
"<boolean>
définie comme vraie (true) empêche l'utilisation de la combinaison de touches Ctrl-Alt-Retour arrière pour arrêter instantanément le serveur X.
"DontZoom" "
— La valeur de <boolaen>
"<boolean>
définie comme vraie (true) empêche la commutation entre résolutions vidéo configurées par les combinaisons de touches Ctrl-Alt-Plus et Ctrl-Alt-Signe-Moins.
La section ServerLayout
lie les périphériques d'entrée et de sortie contrôlés par le serveur X. Au minimum, cette section doit spécifier un périphérique de sortie et un périphérique d'entrée. Par défaut, un moniteur (périphérique de sortie) et un clavier (périphérique d'entrée) sont spécifiés.
Ci-dessous figure un exemple typique de section ServerLayout
:
Section "ServerLayout" Identifier "Default Layout" Screen 0 "Screen0" 0 0 InputDevice "Mouse0" "CorePointer" InputDevice "Keyboard0" "CoreKeyboard" EndSection
Les entrées suivantes sont couramment utilisées dans la section ServerLayout
:
Identifier
— Spécifie un nom unique utilisé pour cette section ServerLayout
.
Screen
— Spécifie le nom d'une section Screen
devant être utilisée avec le serveur X. Il est possible d'avoir plus d'une option Screen
.
Ci-dessous figure un exemple typique d'entrée Screen
:
Screen 0 "Screen0" 0 0
Dans cet exemple d'entrée, le premier nombre Screen
(0
) indique que le premier connecteur du moniteur ou que la tête de la carte vidéo utilise la configuration spécifiée dans la section Screen
avec l'identificateur "Screen0"
.
Une exemple d'une section Screen
avec l'identificateur "Screen0"
peut être trouvé dans Section 22.3.1.9, « Screen
».
Si la carte vidéo a plus d'une tête, il faudra ajouter une entrée Screen
avec un numéro différent et un identificateur différent pour la section Screen
.
Les nombres figurant à la droite de "Screen0"
donnent les coordonnées absolues X et Y pour le coin supérieur gauche de l'écran (par défaut 0 0
).
InputDevice
— Spécifie le nom d'une section InputDevice
à utiliser avec le serveur X.
Il doit y avoir au moins deux entrées InputDevice
: une pour la souris par défaut et une pour le clavier par défaut. Les options CorePointer
et CoreKeyboard
indiquent qu'il s'agit du clavier et de la souris primaires.
Option "
— Correspond à une entrée facultative qui précise des paramètres supplémentaires pour cette section. Tout paramètre spécifié ici remplacent ceux mentionnés dans la section <option-name>
"ServerFlags
.
Remplacez <option-name>
par une option valide pour cette section choisie parmi celles énumérées dans la page de manuel de xorg.conf
.
Il est possible de mettre plus d'une section ServerLayout
dans le fichier /etc/X11/xorg.conf
. Cependant, par défaut, le serveur lit uniquement le premier qu'il rencontre.
Si il y a une section alternative ServerLayout
, elle peut être spécifiée en tant qu'argument de ligne de commande lors du démarrage d'une session X.
La section Files
établit les chemins d'accès vers des services vitaux pour le serveur X, comme le chemin des polices. Il s'agit d'une section optionnelle, ces chemins d'accès sont habituellement détectés automatiquement. Cette section peut être utilisée pour surcharger les chemins d'accès par défaut.
L'exemple suivant illustre une section Files
typique :
Section "Files" RgbPath "/usr/share/X11/rgb.txt" FontPath "unix/:7100" EndSection
Parmi les entrées les plus communément utilisées dans la section Files
figurent :
RgbPath
— Spécifie l'emplacement de la base de données de couleurs RVB (ou RGB de l'anglais Red Green Blue). Cette base de données définit tous les noms de couleurs valides dans X et les associe aux valeurs RVB particulières.
FontPath
— Spécifie l'endroit où le serveur X doit se connecter pour obtenir les polices du serveur de polices xfs
.
Par défaut, la valeur de FontPath
est unix/:7100
. Cette dernière instruit le serveur X qu'il doit obtenir des informations de polices en utilisant les sockets de domaine UNIX pour les communications inter-processus (IPC) sur le port 7100.
Consultez la Section 22.4, « Polices » pour obtenir de plus amples informations sur X et sur les polices.
ModulePath
— Représente un paramètre facultatif qui spécifie d'autres répertoires stockant des modules du serveur X.
Par défaut, le serveur X charge automatiquement les modules suivants à partir du répertoire /usr/lib/xorg/modules/
:
extmod
dbe
glx
freetype
type1
enregistrement
dri
Le répertoire par défaut pour charger ces modules peut être modifié en spécifiant un autre répertoire avec le paramètre optionnel ModulePath
dans la section Files
. Reportez-vous à la Section 22.3.1.4, « Files
» pour davantage d'informations.
L'ajout d'une section Module
dans /etc/X11/xorg.conf
indique au serveur X de charger les modules listés dans cette section plutôt que les modules par défaut.
Par exemple la section suivante typique Module
:
Section "Module" Load "fbdevhw" EndSection
indique au serveur X de charger fbdevhw
plutôt que les modules par défaut.
Ainsi, si vous ajoutez une section Module
dans /etc/X11/xorg.conf
, vous devrez spécifier tous les modules par défaut que vous voulez charger ainsi que les modules supplémentaires.
Chaque section InputDevice
configure un périphérique d'entrée pour le serveur X. Les systèmes possèdent en général au moins une section InputDevice
pour le clavier. Il est parfaitement normal de ne pas avoir d'entrée pour la souris étant donné que la plupart des paramètres de la souris sont détectés automatiquement.
L'exemple suivant illustre une section InputDevice
typique :
Section "InputDevice" Identifier "Keyboard0" Driver "kbd" Option "XkbModel" "pc105" Option "XkbLayout" "us" EndSection
Parmi les entrées les plus communément utilisées dans la section InputDevice
figurent :
Identifier
— Spécifie un nom unique pour cette section InputDevice
. Cette entrée est nécessaire.
Driver
— Spécifie le nom du pilote de périphérique que X doit charger pour le périphérique.
Option
— Spécifie des options nécessaires concernant le périphérique.
Une souris peut aussi être spécifiée pour annuler toute valeur détectée automatiquement pour le périphérique. Les options suivantes sont typiquement inclues lors de l'ajout d'une souris dans le fichier xorg.conf
:
Protocol
— Spécifie le protocole utilisé par la souris, comme par exemple IMPS/2
.
Device
— Spécifie l'emplacement du périphérique physique.
Emulate3Buttons
— Spécifie si une souris à deux boutons doit se comporter comme une souris à trois boutons lorsque les deux boutons sont pressés simultanément.
Consultez la page de manuel de xorg.conf
pour obtenir une liste des options valides pour cette section.
Chaque section Monitor
permet de configurer le type de moniteur utilisé par le système. Il s'agit également d'une entrée optionnelle car la plupart des moniteurs sont maintenant détectés automatiquement.
La meilleure façon d'effectuer la configuration d'un moniteur consiste à configurer X lors du processus d'installation ou à utiliser l'Outil de configuration X. Pour obtenir de plus amples informations sur l'utilisation de l'Outil de configuration X, reportez-vous au Chapitre 23, Configuration du système X Window.
Ci-dessous figure l'exemple d'une section Monitor
typique pour un moniteur :
Section "Monitor" Identifier "Monitor0" VendorName "Monitor Vendor" ModelName "DDC Probed Monitor - ViewSonic G773-2" DisplaySize 320 240 HorizSync 30.0 - 70.0 VertRefresh 50.0 - 180.0 EndSection
Faites très attention si vous éditez manuellement les valeurs de la section Monitor
de /etc/X11/xorg.conf
. En effet, l'utilisation de valeurs inappropriées peut endommager ou même détruire un moniteur. Consultez la documentation accompagnant le moniteur pour obtenir une liste des paramètres disponibles pour un bon fonctionnement.
Parmi les entrées les plus communément utilisées dans la section Monitor
figurent :
Identifier
— Spécifie un nom unique utilisé pour cette section Monitor
. Cette entrée est nécessaire.
VendorName
— Correspond à un paramètre facultatif précisant le nom du fabricant du moniteur.
ModelName
— Correspond à un paramètre facultatif précisant le nom de modèle du moniteur.
DisplaySize
— Correspond à un paramètre facultatif précisant en millimètres, la taille physique de la partie image du moniteur.
HorizSync
— Spécifie la gamme de fréquences sync horizontales compatible avec le moniteur en kHz. Ces valeurs aident le serveur X à déterminer la validité des entrées Modeline
prédéfinies ou spécifiées pour le moniteur.
VertRefresh
— Spécifie la gamme des fréquences de rafraîchissement verticales prise en charge par le moniteur, en kHz. Ces valeurs aident le serveur X à déterminer la validité des entrées Modeline
prédéfinies ou spécifiées pour le moniteur.
Modeline
— Représente un paramètre facultatif qui spécifie les modes vidéo supplémentaires utilisés par le moniteur pour des résolutions particulières, avec certaines résolutions de sync horizontal et de rafraîchissement vertical. Pour obtenir de plus amples explications sur les entrées Modeline
, consultez la page de manuel de xorg.conf
.
Option "
— Représente une entrée facultative qui précise des paramètres supplémentaires pour la section. Remplacez <option-name>
"<option-name>
par une option valide pour cette section, choisie parmi celles énumérées dans la page de manuel de xorg.conf
.
Chaque section Device
configure une carte vidéo utilisée par le système. Alors qu'une section Device
est le minimum requis, il tout à fait possible d'en avoir d'autres pour chaque carte vidéo installée sur l'ordinateur.
La meilleure façon de configurer une carte vidéo consiste à configurer X lors du processus d'installation ou à utiliser l'Outil de configuration X. Pour obtenir de plus amples informations sur l'utilisation de l'Outil de configuration X, reportez-vous au Chapitre 23, Configuration du système X Window.
Ci-après figure l'exemple d'une section Device
typique pour une souris :
Section "Device" Identifier "Videocard0" Driver "mga" VendorName "Videocard vendor" BoardName "Matrox Millennium G200" VideoRam 8192 Option "dpms" EndSection
Parmi les options les plus communément utilisées dans la section Device
figurent :
Identifier
— Spécifie un nom unique utilisé pour la section Device
. Cette entrée est nécessaire.
Driver
— Spécifie le pilote particulier que le serveur X doit charger afin que la carte vidéo puisse être utilisée. Une liste de pilotes est disponible dans le fichier /usr/share/hwdata/videodrivers
, qui est installé avec le paquetage hwdata
.
VendorName
— Correspond à un paramètre facultatif précisant le nom du fabricant du moniteur.
BoardName
— Correspond à un paramètre facultatif précisant le nom de la carte vidéo.
VideoRam
— Représente un paramètre facultatif précisant la quantité de mémoire RAM en kilobits, disponible sur la carte vidéo. Ce paramètre n'est nécessaire que pour les cartes vidéo que X ne peut pas détecter pour déterminer la quantité de RAM vidéo.
BusID
— Une entrée qui spécifie l'emplacement du bus de la carte vidéo. Sur les systèmes avec une seule carte vidéo, une entrée BusID
est optionnelle et peut même ne pas être dans le fichier par défaut /etc/X11/xorg.conf
. Cependant, sur les systèmes avec plus d'une carte vidéo, une entrée BusID
doit être spécifiée.
Screen
— Correspond à une entrée facultative précisant le connecteur du moniteur ou la tête de la carte vidéo que la section Device
configure. Cette option n'est nécessaire que pour les cartes vidéo à têtes multiples.
Si de multiples moniteurs sont connectés à des têtes différentes sur la même carte vidéo, il est nécessaire non seulement d'avoir des sections Device
séparées mais chacune de ces sections doit également avoir une valeur Screen
différente.
Les valeurs associées à l'entrée Screen
doivent être entières. La première tête de la carte vidéo à une valeur de 0
. La valeur de chaque tête supplémentaire augmente d'une unité.
Option "
— Représente une entrée facultative qui précise des paramètres supplémentaires pour la section. Remplacez <option-name>
"<option-name>
par une option valide pour cette section, choisie parmi celles énumérées dans la page de manuel de xorg.conf
.
"dpms"
(pour Display Power Management Signaling, un standard VESA) est une des options très couramment utilisées afin d'activer le paramètre de conformité aux normes Service Star de l'alimentation pour le moniteur.
Chaque section Screen
lie une carte vidéo (ou tête de carte vidéo) à un moniteur en référençant la section Device
et la section Monitor
pour chaque. Bien qu'une section Screen
soit le minimum requis, il est possible d'avoir d'autres instances pour chaque combinaison vidéo et moniteur existant sur l'ordinateur.
Ci-dessous figure l'exemple d'une section Screen
typique :
Section "Screen" Identifier "Screen0" Device "Videocard0" Monitor "Monitor0" DefaultDepth 16 SubSection "Display" Depth 24 Modes "1280x1024" "1280x960" "1152x864" "1024x768" "800x600" "640x480" EndSubSection SubSection "Display" Depth 16 Modes "1152x864" "1024x768" "800x600" "640x480" EndSubSection EndSection
Parmi les entrées les plus communément utilisées dans la section Screen
figurent :
Identifier
— Spécifie un nom unique utilisé pour cette section Screen
. Cette entrée est nécessaire.
Device
— Spécifie le nom unique d'une section Device
. Cette entrée est nécessaire.
Monitor
— Spécifie le nom unique d'une section Monitor
. Cette entrée est uniquement nécessaire si une section spécifique Monitor
est définie dans le fichier xorg.conf
. Habituellement, les moniteurs sont automatiquement détectés.
DefaultDepth
— Spécifie l'intensité des couleurs par défaut, en bits. Dans l'exemple précédent, la valeur par défaut (qui fournit des milliers de couleurs) est 16
. Seule une entrée DefaultDepth
est acceptée mais cette valeur peut être surchargée avec l'option en ligne de commande Xorg -depth
, où <n>
correspond à tout autre profondeur spécifiée.
<n>
SubSection "Display"
— Spécifie les modes écran disponibles à une intensité de couleur donnée. La section Screen
peut contenir de multiples sous-sections Display
qui sont optionnelles depuis que les modes écran sont automatiquement détectés.
Cette sous-section est habituellement utilisée pour surcharger les modes détectés automatiquement.
Option "
— Représente une entrée facultative qui précise des paramètres supplémentaires pour la section. Remplacez <option-name>
"<option-name>
par une option valide pour cette section, choisie parmi celles énumérées dans la page de manuel de xorg.conf
.
La section facultative DRI
spécifie les paramètres pour Direct Rendering Infrastructure (DRI). DRI est une interface dont la fonction principale est de permettre aux applications logicielles 3D de profiter des capacités d'accélération matérielle 3D intégrées dans la plupart du matériel vidéo moderne. De plus, DRI peut améliorer les performances 2D grâce à l'accélération matérielle, dans le cas où elle serait prise en charge par le pilote de la carte vidéo.
Cette section apparaît rarement étant donné que le groupe et le mode DRI sont automatiquement initialisés avec les valeurs par défaut. Si un mode ou un groupe différent est désiré, l'ajout de cette section au fichier xorg.conf
surchargera ces valeurs par défaut.
Ci-dessous figure l'exemple d'une section DRI
typique :
Section "DRI" Group 0 Mode 0666 EndSection
Étant donné que différentes cartes vidéo utilisent la DRI de différentes manières, n'ajoutez pas de valeurs à cette section sans consulter le lien suivant : http://dri.sourceforge.net/.
Red Hat Enterprise Linux utilise deux sous-systèmes pour gérer et afficher les polices sous X. Fontconfig et xfs
.
Le sous-système de polices Fontconfig qui est relativement nouveau simplifie la gestion des polices et fournit des fonctions d'affichage avancées, comme le lissage. Ce système est utilisé automatiquement pour des applications programmées à l'aide de la boîte à outils graphiques Qt 3 ou GTK+ 2.
Pour des raisons de compatibilité, Red Hat Enterprise Linux fournit le sous-système de polices original core X font subsystem. Ce système, qui a plus de 15 ans, s'articule autour du Serveur de polices X (xfs).
Cette section examine la configuration des polices pour X utilisant les deux systèmes.
Le sous-système de polices Fontconfig permet à des applications d'accéder directement aux polices du système et utilise Xft ou tout autre mécanisme de rendu des polices de Fontconfig avec un lissage avancé. Des applications graphiques peuvent utiliser la bibliothèque Xft avec Fontconfig afin de créer du texte à l'écran.
Au fil du temps, le sous-système de polices Fontconfig/Xft remplacera le sous-système de polices core X font subsystem.
Le sous-système de polices Fontconfig ne peut pas encore être utilisé avec OpenOffice.org qui utilise sa propre technologie de rendu des polices.
Il est important de noter que Fontconfig utilise le fichier de configuration /etc/fonts/fonts.conf
et que ce dernier ne doit pas être modifié manuellement.
En raison de la transition vers le nouveau système de polices, les applications GTK+ 1.2 ne sont affectées par aucun changement apporté par le bais de la boîte de dialogue Font Preferences (accessible en sélectionnant System (on the panel) => Préférences => Polices). Pour ces applications, une police peut être configurée en ajoutant les lignes suivantes au fichier ~/.gtkrc.mine
:
style "user-font" { fontset = "<font-specification>
" } widget_class "*" style "user-font"
Remplacez <font-specification>
par la spécification de police dans le style utilisé par les applications X classiques, comme par exemple, -adobe-helvetica-medium-r-normal--*-120-*-*-*-*-*-*
. Il est possible d'obtenir une liste complète des polices de base en exécutant xlsfonts
ou d'en créer une de manière interactive en utilisant xfontsel
.
L'ajout de nouvelles polices au sous-système Fontconfig est un processus relativement simple.
Pour ajouter des polices à l'ensemble du système, copiez les nouvelles polices dans le répertoire /usr/share/fonts/
. Il est judicieux de créer un nouveau sous-répertoire, tel que local/
ou quelque chose de semblable, afin de pouvoir distinguer facilement les polices installées par l'utilisateur et celles installées par défaut.
Pour ajouter de nouvelles polices pour un utilisateur spécifique, copiez les nouvelles polices dans le répertoire .fonts/
du répertoire personnel (ou home) de l'utilisateur.
Pour mettre à jour le cache des informations de polices, utilisez la commande fc-cache
comme dans l'exemple suivant :
fc-cache <path-to-font-directory>
Dans cette commande, remplacez <path-to-font-directory>
par le répertoire contenant les nouvelles polices (soit /usr/share/fonts/local/
, soit /home/
).
<user>
/.fonts/
Des utilisateurs individuels peuvent aussi installer des polices graphiquement en tapant fonts:///
dans la barre d'adresse de Nautilus et en y faisant glisser les nouveaux fichiers de polices.
Si le nom du fichier de polices se termine par une extension .gz
, il s'agit d'un fichier compressé qui ne pourra pas être utilisé à moins d'être préalablement décompressé. Pour ce faire, utilisez la commande gunzip
ou cliquez deux fois sur le fichier et faites glisser la police vers un répertoire dans Nautilus.
Pour des raisons de compatibilité, Red Hat Enterprise Linux inclut toujours le sous-système de polices core X font subsystem qui utilise le serveur de polices X (xfs
) pour fournir les polices aux applications clients X.
Le serveur X recherche un serveur de polices spécifié dans la directive FontPath
dans la section Files
du fichier de configuration /etc/X11/xorg.conf
. Pour obtenir de plus amples informations sur l'entrée FontPath
, reportez-vous à la Section 22.3.1.4, « Files
».
Le serveur X se connecte au serveur xfs
sur un port déterminé afin d'obtenir des informations sur les polices. Dans de telles circonstances, le service xfs
doit être en cours d'exécution pour que X puisse démarrer. Pour obtenir de plus amples informations sur la configuration de services à un niveau d'exécution particulier, reportez-vous au Chapitre 7, Contrôle d'accès aux services .
Le script /etc/rc.d/init.d/xfs
lance le serveur xfs
. Il est possible de configurer plusieurs options dans son fichier de configuration /etc/X11/fs/config
.
Ci-dessous figure une liste des options courantes :
alternate-servers
— Spécifie une liste d'autres serveurs de polices à utiliser si ce serveur de polices n'est pas disponible. Chaque serveur dans cette liste doit être séparé par une virgule.
catalogue
— Spécifie une liste classée de chemins de polices à utiliser. Chaque chemin de polices dans cette liste doit être séparé par une virgule.
Utilisez la chaîne :unscaled
immédiatement après le chemin de polices pour faire charger en premier les polices non-proportionnées dans cette liste. Spécifiez ensuite à nouveau le chemin de polices complet, pour que les autres polices proportionnées soient également chargées.
client-limit
— Spécifie le nombre maximum de clients que ce serveur de polices va approvisionner. La valeur par défaut est 10
.
clone-self
— Autorise le serveur de polices à reproduire une autre version de lui-même lorsque la limite de clients (client-limit
) est atteinte. La valeur par défaut pour cette option est on
.
default-point-size
— Spécifie la taille de point par défaut pour toute police qui ne spécifie pas cette valeur. La valeur par défaut est exprimée en décipoints. La valeur par défaut de 120
correspond à une police de 12 points.
default-resolutions
— Spécifie une liste de résolutions prises en charge par le serveur X. Chaque résolution figurant dans la liste doit être séparée par une virgule.
deferglyphs
— Spécifie si le chargement de glyphs (le graphique utilisé pour la représentation visuelle d'une police) doit être différé. Pour désactiver cette fonction, utilisez none
, pour l'activer pour toutes ces polices, utilisez all
ou pour ne l'activer que pour les polices 16-bit, utilisez 16
.
error-file
— Spécifie le chemin et le nom du fichier de l'endroit où les erreurs xfs
doivent être enregistrées.
no-listen
— Empêche xfs
d'être attentif à des protocoles spécifiques. Cette option a par défaut la valeur tcp
afin d'empêcher xfs
de recevoir des connexions sur les ports TCP, surtout pour des raisons de sécurité.
Si vous utilisez xfs
pour servir des polices à travers le réseau, supprimez cette ligne.
port
— Spécifie le port TCP sur lequel xfs
recevra des connexions si l'option no-listen
n'existe pas ou est désactivée par un commentaire.
use-syslog
— Spécifie si le journal d'erreurs système doit être utilisé.
Pour ajouter des polices au sous-système de polices core X font subsystem (xfs
), suivez les étapes suivantes :
À moins qu'il n'existe déjà, créez un répertoire nommé /usr/share/fonts/local/
à l'aide de la commande suivante, en étant connecté en tant que super-utilisateur (aussi appelé root) :
mkdir /usr/share/fonts/local/
Si la création du répertoire /usr/share/fonts/local/
est nécessaire, il faut ajouter ce dernier au chemin xfs
à l'aide de la commande suivante, en étant connecté en tant que super-utilisateur :
chkfontpath --add /usr/share/fonts/local/
Copiez le nouveau fichier de polices dans le répertoire /usr/share/fonts/local/
Mettez à jour les informations de polices à l'aide de la commande suivante, en étant connecté en tant que super-utilisateur :
ttmkfdir -d /usr/share/fonts/local/ -o /usr/share/fonts/local/fonts.scale
Redémarrez le fichier de configuration du serveur de polices xfs
à l'aide de la commande suivante, en étant connecté en tant que super-utilisateur :
service xfs reload
Dans la plupart des cas, l'installation de Red Hat Enterprise Linux configure l'ordinateur pour qu'il démarre dans un environnement de connexion graphique, connu en tant que niveau d'exécution 5. Il est toutefois possible de démarrer en mode multi-utilisateur texte-seul, connu en tant que niveau d'exécution 3 et de démarrer ainsi une session X.
Pour obtenir de plus amples informations sur les niveaux d'exécution, reportez-vous à la Section 7.1, « Niveaux d'exécution ».
Les sous-sections suivantes examinent la manière selon laquelle X démarre aussi bien au niveau d'exécution 3 qu'au niveau d'exécution 5.
Au niveau d'exécution 3, la meilleure façon de lancer une session X consiste à se connecter et à taper la commande startx
. Cette commande startx
est une commande frontale (ou front-end) à la commande xinit
, qui lance le serveur X (Xorg
) et y connecte les applications client X. Étant donné que l'utilisateur est déjà connecté au système au niveau d'exécution 3, startx
ne lance pas un gestionnaire d'affichage et n'authentifie pas les utilisateurs. Pour obtenir de plus amples informations sur les gestionnaires d'affichage, reportez-vous à la Section 22.5.2, « Niveau d'exécution 5 ».
Lorsque la commande startx
est exécutée, elle recherche un fichier .xinitrc
dans le répertoire personnel de l'utilisateur pour définir l'environnement de bureau et éventuellement d'autres applications client X à lancer. Si aucun fichier .xinitrc
n'existe, elle utilisera à sa place le fichier /etc/X11/xinit/xinitrc
par défaut du système.
Le script xinitrc
par défaut recherche alors les fichiers définis par l'utilisateur et les fichiers système par défaut, y compris .Xresources
, .Xmodmap
et .Xkbmap
dans le répertoire personnel de l'utilisateur d'une part, et Xresources
, Xmodmap
et Xkbmap
dans le répertoire /etc/X11/
d'autre part. Les fichiers Xmodmap
et Xkbmap
, s'ils existent, sont utilisés par l'utilitaire xmodmap
pour configurer le clavier. Le fichier Xresources
est lu afin d'assigner des valeurs préférentielles spécifiques aux applications.
Après avoir paramétré ces options, le script xinitrc
exécute tous les scripts situés dans le répertoire /etc/X11/xinit/xinitrc.d/
. Parmi les scripts importants faisant partie de ce répertoire figure xinput
, permettant de configurer des paramètres comme la langue par défaut.
Ensuite, le script xinitrc
essaie d'exécuter .Xclients
dans le répertoire personnel (home) de l'utilisateur et recourt à /etc/X11/xinit/Xclients
s'il ne peut pas le trouver. Le rôle du fichier Xclients
est de démarrer l'environnement de bureau ou éventuellement un simple gestionnaire de fenêtres élémentaire. Le script .Xclients
dans le répertoire personnel de l'utilisateur lance l'environnement de bureau spécifié par l'utilisateur dans le fichier .Xclients-default
. Si le fichier .Xclients
n'existe pas dans le répertoire personnel de l'utilisateur, le script standard /etc/X11/init/Xclients
tente de lancer un autre environnement de bureau, en premier GNOME et en second KDE, suivi de twm
.
L'utilisateur revient à une session utilisateur en mode texte après s'être déconnecté de X au niveau d'exécution 3.
Lorsque le système démarre au niveau d'exécution 5, une application client X spéciale appelée gestionnaire d'affichage, est lancée. Un utilisateur doit s'authentifier en utilisant le gestionnaire d'affichage avant que tout environnement de bureau ou gestionnaire de fenêtres ne puisse être lancé.
Selon les environnements de bureau installés sur le système, trois gestionnaires d'affichage différents sont disponibles pour assurer l'authentification de l'utilisateur.
GNOME
— Le gestionnaire d'affichage par défaut pour Red Hat Enterprise Linux, GNOME
permet à l'utilisateur de configurer des paramètres de langue, l'arrêt, le redémarrage et la connexion au système.
KDE
— Le gestionnaire d'affichage de KDE qui permet à l'utilisateur de démarrer, arrêter et se connecter au système.
xdm
— Un gestionnaire d'affichage rudimentaire ne permettant que la connexion de l'utilisateur au système.
Lors du démarrage au niveau d'exécution 5, le script prefdm
détermine le gestionnaire d'affichage de préférence en consultant le fichier /etc/sysconfig/desktop
. Pour obtenir une liste des options disponibles pour ce fichier, reportez-vous au fichier :
/usr/share/doc/initscripts-<version-number>
/sysconfig.txt
où <version-number>
correspond au numéro de la version du paquetage initscripts
.
Chacun des gestionnaires d'affichage référence le fichier /etc/X11/xdm/Xsetup_0
pour paramétrer l'écran de connexion. Une fois que l'utilisateur s'est connecté au système, le script /etc/X11/xdm/GiveConsole
s'exécute pour assigner à l'utilisateur la propriété de la console. Ensuite, le script /etc/X11/xdm/Xsession
se lance pour effectuer de nombreuses tâches habituellement exécutées par le script xinitrc
lorsque X est démarré au niveau d'exécution 3, y compris le paramétrage du système et des ressources de l'utilisateur ainsi que le lancement des scripts contenus dans le répertoire /etc/X11/xinit/xinitrc.d/
.
Les utilisateurs peuvent spécifier l'environnement de bureau qu'ils souhaitent utiliser quand ils s'authentifient avec des gestionnaires d'affichage GNOME
ou KDE
en faisant leur choix dans le menu Sessions (accessible en sélectionnant System (on the panel) => Préférences => Préférences supplémentaires => Sessions). Si l'environnement de bureau n'est pas spécifié dans le gestionnaire de fenêtres, le script /etc/X11/xdm/Xsession
vérifie les fichiers .xsession
et .Xclients
dans le répertoire personnel de l'utilisateur pour décider quel environnement de bureau charger. En dernier ressort, le fichier /etc/X11/xinit/Xclients
est utilisé pour sélectionner un environnement de bureau ou gestionnaire de fenêtres à utiliser, de la même façon que pour le niveau d'exécution 3.
Lorsque l'utilisateur termine une session X sur l'affichage par défaut (:0
) et se déconnecte, le script /etc/X11/xdm/TakeConsole
s'exécute et réassigne la propriété de la console au super-utilisateur (ou root). Le gestionnaire d'affichage original, qui ne s'est pas arrêté depuis la connexion de l'utilisateur, prend le contrôle en lançant un nouveau gestionnaire d'affichage. Ce faisant, le serveur X est redémarré, un nouvel écran d'authentification est affiché et tout le processus recommence à nouveau.
L'utilisateur revient au gestionnaire d'affichage après s'être déconnecté de X au niveau d'exécution 5.
Pour obtenir de plus amples informations sur le contrôle de l'authentification des utilisateurs par les gestionnaires d'affichage, reportez-vous d'une part au fichier /usr/share/doc/gdm-
(où <version-number>
/README<version-number>
correspond au numéro de version du paquetage gdm
installé) et d'autre part à la page de manuel de xdm
.
Il existe de nombreuses informations détaillées concernant le serveur X, les clients qui s'y connectent et les environnements de bureau et gestionnaires de fenêtres variés.
/usr/share/X11/doc/
— contient de la documentation détaillée sur l'architecture du système X Window ainsi que des instructions afin d'obtenir des informations supplémentaires à propos du projet Xorg en tant que nouvel utilisateur.
man xorg.conf
— Page de manuel contenant des informations sur les fichiers de configuration xorg.conf
, y compris la signification et la syntaxe des différentes sections figurant dans les fichiers.
man Xorg
— Décrit le serveur d'affichage Xorg
.
http://www.X.org/ — Page d'accueil du projet de la fondation X.Org, qui produit la version X11R7.1 du système X Window. La version X11R7.1 est offerte avec Red Hat Enterprise Linux pour contrôler le matériel nécessaire et fournir un environnement d'interface graphique (ou GUI).
http://dri.sourceforge.net/ — Page d'accueil du projet DRI (Direct Rendering Infrastructure). La DRI est le composant central de l'accélération matérielle 3D pour X.
http://www.gnome.org/ — Page d'accueil du projet GNOME.
http://www.kde.org/ — Page d'accueil de l'environnement de bureau KDE.
Durant l'installation, les paramètres du système concernant le moniteur, la carte vidéo et l'affichage sont configurés. Pour modifier l'un de ces paramètres après l'installation, utilisez l'Outil de configuration X.
Pour lancer l'Outil de configuration X, allez à System (on the panel) => Administration => Affichage, ou tapez la commande system-config-display
à l'invite du shell (par exemple, dans un terminal XTerm ou GNOME). Si le système X Window n'est pas en cours d'exécution, une petite version de X est lancée pour exécuter le programme.
Après la modification des paramètres, déconnectez-vous du bureau graphique et connectez-vous de nouveau pour activer les changements.
L'onglet Paramètres permet aux utilisateurs de modifier la résolution et la profondeur des couleurs. L'affichage d'un moniteur est composé de petits points appelés pixels. Le nombre de pixels affichés est appelé la résolution. Par exemple, la résolution 1024x768 signifie que 1024 pixels horizontaux et 768 pixels verticaux sont utilisés. Plus la résolution est élevée, plus les images apparaissent petites.
La profondeur des couleurs de l'affichage détermine le nombre de couleurs affichées. Plus la profondeur de couleurs est élevée, plus le contraste entre couleurs est approfondi.
Au lancement, l'Outil de configuration X détecte le moniteur et la carte vidéo. Si le matériel est détecté correctement, ses informations sont affichées dans l'onglet Matériel comme l'illustre la Figure 23.2, « Afficher les paramètres matériels ».
Pour changer le type de moniteur ou un autre de ses paramètres, cliquez sur le bouton Configurer correspondant. Pour changer le type de carte vidéo ou un autre de ses paramètres, cliquez sur le bouton Configurer à côté de ses paramètres.
Si plusieurs cartes vidéo sont installées sur le système, le support double écran est disponible et configurable via l'onglet Double écran, comme l'illustre la Figure 23.3, « Paramètres d'affichage du double écran ».
Pour activer l'utilisation du double écran, cochez la case Utiliser le double écran.
Pour configurer le second type de moniteur, cliquez sur le bouton Configurer correspondant. Vous pouvez également configurer les autres paramètres du double écran en utilisant la liste déroulante correspondante.
Pour l'option Disposition du bureau, sélectionner Bureaux multi-écran permet aux deux moniteurs d'utiliser un espace élargi. Sélectionner Bureaux individuels permet le partage de la souris et du clavier entre les affichages mais restreint les fenêtres à un seul affichage.
Le contrôle des utilisateurs et des groupes est un élément central de l'administration système de Red Hat Enterprise Linux.
Les utilisateurs peuvent être aussi bien des personnes (avec des comptes attachés à des utilisateurs physiques), que des comptes existant pour une utilisation par des applications spécifiques.
Les groupes sont des expressions logiques qui permettent une certaine organisation en regroupant des utilisateurs oeuvrant pour un but commun. Les utilisateurs appartenant à un groupe donné peuvent lire, écrire ou exécuter des fichiers appartenant à ce groupe.
Chaque utilisateur et chaque groupe se voit attribuer un identificateur numérique unique appelé respectivement un userid (UID) et un groupid (GID).
L'utilisateur qui crée un fichier devient le propriétaire et le groupe propriétaire du fichier. Ce fichier reçoit également des permissions séparées de lecture, d'écriture et d'exécution pour le propriétaire, le groupe ou tout autre utilisateur. Le propriétaire du fichier peut seulement être modifié par le super-utilisateur et les permissions d'accès quant à elles peuvent être modifiées aussi bien par le super-utilisateur et que par le propriétaire du fichier.
Le Gestionnaire d'utilisateurs vous permet de voir, modifier, ajouter et supprimer des utilisateurs et groupes locaux.
Pour utiliser le Gestionnaire d'utilisateurs, le système X Window doit être en cours d'exécution, vous devez avoir les privilèges super-utilisateur ainsi que le paquetage RPM system-config-users
installé. Pour démarrer le Gestionnaire d'utilisateurs à partir du bureau, allez sous System (on the panel) => Administration => Utilisateurs & Groupes. Vous pouvez également tapez la commande system-config-users
à l'invite du shell (par exemple, dans un terminal XTerm ou GNOME).
Pour afficher une liste des utilisateurs locaux du système, cliquez sur l'onglet Utilisateurs. Pour afficher une liste des groupes locaux du système, cliquez sur l'onglet Groupes.
Pour trouver un utilisateur ou un groupe spécifique, tapez les premières lettres du nom dans le champ Filtre de recherche. Appuyez sur Entrée ou cliquez sur le bouton Appliquer le filtre. La liste filtrée s'affiche alors.
Pour trier les utilisateurs et groupes, cliquez sur le nom de la colonne. Les utilisateurs et groupes sont triés selon la valeur de cette colonne.
Red Hat Enterprise Linux réserve les ID utilisateur inférieurs à 500 aux utilisateurs système. Par défaut, le Gestionnaire d'utilisateurs n'affiche pas les utilisateurs système. Pour voir tous les utilisateurs, y compris les utilisateurs système, sélectionnez Modifier => Préférences et décochez Cacher les utilisateurs et groupes système à partir de la boîte de dialogue.
Pour ajouter un nouvel utilisateur, cliquez sur le bouton Ajouter un utilisateur. Comme le montre la Figure 24.2, « Nouvel utilisateur », une fenêtre apparaît. Entrez le nom d'utilisateur et le nom complet du nouvel utilisateur dans les champs appropriés. Entrez le mot de passe de l'utilisateur dans les champs Mot de passe et Confirmer le mot de passe. Le mot de passe doit compter au minimum six caractères.
Nous vous recommandons d'utiliser un mot de passe avec beaucoup de caractères car c'est plus difficile pour un intrus de le deviner et d'accéder au compte sans autorisation. Nous vous recommandons également de ne pas utiliser un mot de passe basé sur les termes du dictionnaire. Utilisez une combinaison de lettres, nombres et caractères spéciaux.
Sélectionnez un shell de connexion. Si vous n'êtes pas certain du shell à sélectionner, acceptez la valeur par défaut de /bin/bash
. Le répertoire personnel par défaut est /home/
. Vous pouvez changer le répertoire personnel qui est créé pour l'utilisateur, ou choisir de ne pas créer de répertoire personnel en dé-sélectionnant l'option Créer un répertoire personnel.
<username>
/
Si vous décidez de créer un répertoire personnel (home), sachez que les fichiers de configuration par défaut seront copiés du répertoire /etc/skel/
dans le nouveau répertoire personnel.
Red Hat Enterprise Linux utilise un système dit groupe privé d'utilisateurs (UPG de l'anglais User Private Group). Le système UPG n'ajoute et ne change rien dans la manière UNIX standard de traiter les groupes ; il offre seulement une nouvelle convention. Chaque fois que vous créez un nouvel utilisateur, un groupe unique avec le même nom de cet utilisateur est aussi créé. Si vous ne souhaitez pas créer ce groupe, désélectionnez l'option Créer un groupe privé pour l'utilisateur.
Pour spécifier un ID utilisateur pour l'utilisateur, sélectionnez l'option Spécifier l'ID utilisateur manuellement. Si l'option n'est pas sélectionnée, le prochain ID utilisateur libre à partir du numéro 500 sera assigné au nouvel utilisateur. Étant donné que Red Hat Enterprise Linux réserve les ID utilisateur inférieurs à 500 pour les utilisateurs système, nous ne vous recommandons pas d'assigner manuellement les ID utilisateur 1-499.
Cliquez sur Valider pour créer l'utilisateur.
Pour configurer des propriétés d'utilisateur plus avancées, comme l'expiration des mots de passe, modifiez les propriétés de l'utilisateur après l'avoir ajouté. Consultez la Section 24.1.2, « Modification des propriétés de l'utilisateur » pour plus d'informations.
Pour afficher les propriétés d'un utilisateur existant, cliquez sur l'onglet Utilisateurs, sélectionnez l'utilisateur dans la liste des utilisateurs et cliquez sur Propriétés (ou sélectionnez Fichiers => Propriétés dans le menu déroulant). Une fenêtre semblable à celle reproduite dans la Figure 24.3, « Propriétés de l'utilisateur » apparaîtra alors.
La fenêtre Propriétés de l'utilisateur est divisée en pages contenant des onglets :
Données d'utilisateur — Des informations de base sur l'utilisateur sont configurées lorsque vous ajoutez l'utilisateur. Utilisez cet onglet pour changer le nom complet, le mot de passe, le répertoire personnel ou le shell pour la connexion.
Informations sur le compte — Sélectionnez Activer l'expiration du compte si vous souhaitez que le compte expire à une certaine date. Entrez la date dans les champs affichés. Sélectionnez l'option Le mot de passe local est verrouillé pour verrouiller le compte utilisateur afin qu'il ne puisse plus se connecter au système.
Informations sur le mot de passe — Affiche la date à laquelle l'utilisateur a changé son mot de passe pour la dernière fois. Pour forcer l'utilisateur à changer de mot de passe après un certain nombre de jours, sélectionnez Activer l'expiration du mot de passe et entrez une valeur désirée dans le champ Nombre de jours avant que le changement soit requis :. Vous pouvez aussi sélectionner le nombre de jours avant l'expiration du mot de passe de l'utilisateur, le nombre de jours avant que l'utilisateur ne reçoive un message lui demandant de changer de mot de passe et le nombre de jours avant que le compte ne devienne inactif.
Groupes — Vous permet de visualiser et configurer les groupes auxquels vous souhaitez que l'utilisateur fasse partie ainsi que le groupe primaire de l'utilisateur.
Pour ajouter un nouveau groupe utilisateur, cliquez sur le bouton Ajouter un groupe. Une fenêtre semblable à celle reproduite avec la Figure 24.4, « Nouveau groupe » s'affichera à l'écran. Entrez le nom du nouveau groupe. Pour spécifier un ID groupe pour le nouveau groupe, sélectionnez Spécifier l'ID groupe manuellement et sélectionnez le GID. Notez que Red Hat Enterprise Linux réserve les ID groupe inférieurs à 500 aux groupes du système.
Cliquez sur Valider pour créer le groupe. Le nouveau groupe apparaîtra dans la liste des groupes.
Pour afficher les propriétés d'un groupe existant, choisissez le groupe voulu dans la liste et cliquez sur Propriétés à partir du menu (ou choisissez Fichier => Propriétés dans le menu déroulant). Une fenêtre semblable à celle reproduite dans la Figure 24.5, « Propriétés des groupes » apparaîtra.
L'onglet Utilisateurs du groupe affiche les utilisateurs qui sont membres du groupe. Utilisez cet onglet pour ajouter ou retirer des utilisateurs du groupe. Cliquez sur Valider pour enregistrer vos modifications.
La gestion des utilisateurs et des groupes peut être une tâche laborieuse ; c'est pourquoi Red Hat Enterprise Linux fournit des outils et conventions facilitant cette gestion.
La manière la plus simple de gérer des utilisateurs et des groupes consiste à utiliser l'application graphique Gestionnaire d'utilisateurs (system-config-users
). Pour obtenir de plus amples informations sur le Gestionnaire d'utilisateurs, reportez-vous à la Section 24.1, « Configuration des utilisateurs et des groupes ».
Les outils en ligne de commande mentionnés ci-dessous peuvent également servir à gérer les utilisateurs et les groupes :
useradd
, usermod
et userdel
— Méthodes conformes aux standards de l'industrie permettant d'ajouter, de supprimer et de modifier des comptes d'utilisateurs.
groupadd
, groupmod
et groupdel
— Méthodes conformes aux standards de l'industrie permettant d'ajouter, de supprimer et de modifier des groupes d'utilisateurs.
gpasswd
— Méthode conforme aux standards de l'industrie permettant d'administrer le fichier /etc/group
.
pwck
, grpck
— Outils permettant de vérifier le mot de passe, le groupe et les fichiers masqués connexes.
pwconv
, pwunconv
— Outils permettant la conversion de mots de passe standard en mots de passe masqués et vice versa.
Si vous préférez des outils en ligne de commande ou si ne disposez pas d'un système X Window installé, utilisez cette section pour configurer les utilisateurs et les groupes.
Pour ajouter un nouvel utilisateur au système :
Les options en ligne de commande pour useradd
sont détaillées dans le Tableau 24.1, « Options en ligne de commande pour useradd
».
Option | Description |
---|---|
-c '<comment> '
|
<comment> peut être remplacé par n'importe quelle chaîne de caractères. Cette option est généralement utilisée pour spécifier le nom complet d'un l'utilisateur.
|
-d <home-dir>
|
Répertoire personnel à utiliser à la place du répertoire par défaut /home/
|
-e <date>
|
Date à laquelle le compte deviendra inactif dans le format AAAA--MM-JJ. |
-f <days>
|
Nombre de jours pouvant s'écouler après l'expiration du mot de passe et avant que le compte ne soit désactivé. Si 0 est la valeur choisie, le compte deviendra inactif aussitôt après l'expiration du mot de passe. Si le choix est -1 , le compte ne deviendra pas inactif après l'expiration du mot de passe.
|
-g <group-name>
|
Nom ou numéro du groupe pour le groupe par défaut de l'utilisateur. Le groupe doit préalablement exister. |
-G <group-list>
|
Liste des noms ou numéros de groupes supplémentaires (autres que ceux par défaut), séparés par des virgules, auxquels le membre appartient. Les groupes doivent préalablement exister. |
-m
|
Crée le répertoire personnel s'il n'existe pas. |
-M
|
Ne crée pas le répertoire personnel. |
-n
|
Évite la création d'un groupe privé d'utilisateurs pour l'utilisateur. |
-r
|
Entraîne la création d'un compte système avec un ID utilisateur (UID) inférieur à 500 et sans répertoire personnel. |
-p <password>
|
Le mot de passe crypté avec crypt .
|
-s
|
Shell de connexion de l'utilisateur, qui prend la valeur par défaut /bin/bash .
|
-u <uid>
|
ID utilisateur pour l'utilisateur, qui doit être unique et supérieur à 499. |
useradd
Pour ajouter un groupe au système, utilisez la commande groupadd
:
groupadd <group-name>
Les options en ligne de commande pour groupadd
sont détaillées dans le Tableau 24.2, « Options en ligne de commande pour groupadd
».
Option | Description |
---|---|
-g <gid>
|
ID groupe pour le groupe, qui doit être unique et supérieur à 499. |
-r
|
Entraîne la création d'un groupe système avec un ID groupe (GID) inférieur à 500. |
-f
|
Lorsqu'elle est utilisée avec -g <gid> et que <gid> existe déjà, groupadd choisira un autre <gid> unique pour le groupe.
|
groupadd
Pour des raisons de sécurité, il est recommandé aux utilisateurs de changer leurs mots de passe régulièrement. Ceci peut être réalisé lors de l'ajout ou de la modification de l'utilisateur sous l'onglet Informations sur le mot de passe du Gestionnaire d'utilisateurs.
Pour configurer l'expiration du mot de passe d'un utilisateur à partir de l'invite du shell, utilisez la commande chage
suivie d'une des options figurant dans le Tableau 24.3, « Options en ligne de commande chage
» et du nom d'utilisateur de l'utilisateur de mot de passe.
Les mots de passe masqués doivent être activés afin de pouvoir utiliser la commande chage
.
Option | Description |
---|---|
-m <days>
|
Spécifie la durée minimale, en jours, pendant laquelle l'utilisateur doit changer son mot de passe. Si la valeur choisie est 0, le mot de passe n'expire pas. |
-M <days>
|
Spécifie la durée maximale, en jours, pendant laquelle le mot de passe est valide. Lorsque le nombre de jours spécifié par cette option ajouté au nombre de jours précisé avec l'option -d est inférieur au jour actuel, l'utilisateur doit changer son mot de passe avant d'utiliser son compte.
|
-d <days>
|
Spécifie le nombre de jours écoulés entre le 1er janvier 1970 et le jour où le mot de passe a été changé. |
-I <days>
|
Spécifie le nombre de jours inactifs après l'expiration du mot de passe, avant que le compte ne soit verrouillé. Si la valeur est 0, le compte ne sera pas verrouillé après l'expiration du mot de passe. |
-E <date>
|
Spécifie la date à laquelle le compte sera verrouillé, selon le format AAAA-MM-JJ. Au lieu de la date, il est possible d'utiliser le nombre de jours écoulés depuis le 1er janvier 1970. |
-W <days>
|
Spécifie le nombre de jours devant s'écouler avant la date d'expiration du mot de passe, avant d'avertir l'utilisateur. |
chage
Si la commande chage
est suivie directement d'un nom d'utilisateur (sans option), les valeurs courantes de l'expiration du mot de passe s'afficheront et il sera alors possible de les modifier.
Vous pouvez configurer un mot de passe pour qu'il expire lors de la première connexion de l'utilisateur. Ainsi, les utilisateurs sont obligés de changer de mot de passe lors de leur première connexion.
Ce processus ne fonctionnera pas si l'utilisateur se connecte en utilisant le protocole SSH.
Verrouiller le mot de passe de l'utilisateur — Si l'utilisateur n'existe pas, utilisez la commande useradd
pour créer le compte de l'utilisateur mais ne lui donnez pas un mot de passe afin qu'il reste verrouillé.
Si le mot de passe est déjà activé, verrouillez-le avec la commande :
usermod -L username
Forcez l'expiration immédiate du mot de passe — Pour ce faire, tapez la commande suivante :
chage -d 0 username
Cette commande détermine la valeur correspondant à la date à laquelle le mot de passe a été changé la dernière fois (à partir du 1er janvier 1970). Cette valeur entraîne une expiration immédiate forcée du mot de passe, indépendemment de la politique d'expiration en place (s'il y en a une).
Déverrouillez le compte — Pour ce faire, il existe deux approches courantes : l'administrateur peut soit assigner un mot de passe initial, soit assigner un mot de passe blanc.
N'utilisez pas la commande passwd
pour établir le mot de passe car cette commande désactivera l'expiration immédiate du mot de passe que vous venez juste de configurer.
Pour attribuer un mot de passe initial, suivez les étapes ci-dessous :
Lancez l'interpréteur en ligne de commande Python à l'aide de la commande python
. La sortie suivante s'affichera :
Python 2.4.3 (#1, Jul 21 2006, 08:46:09) [GCC 4.1.1 20060718 (Red Hat 4.1.1-9)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>>
À l'invite, tapez les commandes suivantes. Remplacez <password>
par le mot de passe à crypter et <salt>
par une combinaison aléatoire d'au moins deux des éléments suivants : les caractères alphanumériques, la barre oblique en avant (/), ou le point (.) :
import crypt; print crypt.crypt("<password>
","<salt>
")
La sortie produite sera un mot de passe crypté semblable à l'exemple suivant : '12CsGd8FRcMSM'
.
Appuyez sur Ctrl-D pour quitter l'interpréteur Python.
À l'invite shell, saisissez la commande suivante (remplacez <encrypted-password>
avec la sortie cryptée de l'interpréteur Python) :
usermod -p "<encrypted-password>
" <username>
Autrement, vous pouvez assigner un mot de passe blanc à la place d'un mot de passe initial. Pour ce faire, utilisez la commande suivante :
usermod -p "" username
Bien que l'utilisation d'un mot de passe blanc soit très pratique, il s'agit d'une méthode non sécurisée car n'importe qu'elle tierce personne peut se connecter puis accéder au système avec ce nom d'utilisateur non sécurisé. Assurez-vous que l'utilisateur soit prêt à se connecter avant de déverrouiller un compte avec un mot de passe blanc.
Dans les deux cas, l'utilisateur devra saisir un nouveau mot de passe lors de la première connexion.
Les étapes suivantes illustrent le processus engendré par l'exécution de la commande useradd juan
sur un système disposant de mots de passe masqués activés :
Une nouvelle ligne pour juan
est créée dans /etc/passwd
. Cette dernière affiche les caractéristiques suivantes :
Elle commence par le nom d'utilisateur, juan
.
Le champ du mot de passe contient un x
indiquant que le système utilise des mots de passe masqués.
Un UID supérieur à 499 est créé (sous Red Hat Enterprise Linux, les UID et GID inférieurs à 500 sont réservés pour les opérations système).
Un GID supérieur à 499 est créé.
Les informations GECOS facultatives demeurent vierges.
Le répertoire personnel de l'utilisateur juan
est établi à /home/juan/
.
Le shell par défaut est défini en tant que /bin/bash
.
Une nouvelle ligne pour juan
est créée dans /etc/shadow
. Cette dernière affiche les caractéristiques suivantes :
Elle commence par le nom d'utilisateur, juan
.
Deux points d'exclamation (!!
) apparaissent dans le champ de mot de passe du fichier /etc/shadow
, verrouillant le compte.
Si un mot de passe crypté est passé à l'aide de l'indicateur -p
, il est placé dans le fichier /etc/shadow
sur la nouvelle ligne relative à l'utilisateur.
Le mot de passe est établi de manière à ne jamais expirer.
Une nouvelle ligne pour un groupe nommé juan
est créée dans /etc/group
. Un groupe portant le même nom qu'un utilisateur est appelé un groupe privé d'utilisateurs. Pour obtenir de plus amples informations sur les groupes privés d'utilisateurs, reportez-vous à la Section 24.1.1, « Ajout d'un nouvel utilisateur ».
La ligne créée dans /etc/group
affiche les caractéristiques suivantes :
Elle commence par le nom du groupe, juan
.
Un x
apparaît dans le champ du mot de passe, indiquant que le système utilise des mots de passe masqués pour les groupes.
Le GID correspond à celui qui est établi pour l'utilisateur juan
dans /etc/passwd
.
Une nouvelle ligne pour un groupe nommé juan
est créée dans /etc/gshadow
. Cette dernière affiche les caractéristiques suivantes :
Elle commence par le nom du groupe, juan
.
Un point d'exclamation (!
) apparaît dans le champ de mot de passe du fichier /etc/gshadow
, verrouillant le groupe.
Tous les autres champs sont vierges.
Un répertoire pour l'utilisateur juan
est créé dans le répertoire /home/
. Ce dernier est la propriété de l'utilisateur juan
et du groupe juan
. Toutefois, seul l'utilisateur juan
dispose des privilèges de lecture, d'écriture et d'exécution. Toute autre permission est refusée.
Les fichiers placés dans le répertoire /etc/skel/
(qui contient les paramètres par défaut de l'utilisateur) sont copiés dans le nouveau répertoire /home/juan/
.
À ce stade, un compte verrouillé portant le nom juan
existe sur le système. Afin de l'activer, l'administrateur doit tout d'abord attribuer un mot de passe au compte à l'aide de la commande passwd
et doit ensuite, s'il le désire, établir des directives quant à l'expiration de ce dernier.
Tableau 24.4, « Utilisateurs ordinaires » liste les utilisateurs standards configurés dans le fichier /etc/passwd
par une installation Tout. Le groupid (GID) figurant dans ce tableau correspond au groupe primaire pour l'utilisateur. Reportez-vous à la Section 24.4, « Groupes ordinaires » pour une liste des groupes standards.
Utilisateur | UID | GID | Répertoire personnel | Shell |
---|---|---|---|---|
root | 0 | 0 |
/root
|
/bin/bash
|
bin | 1 | 1 |
/bin
|
/sbin/nologin
|
daemon | 2 | 2 |
/sbin
|
/sbin/nologin
|
adm | 3 | 4 |
/var/adm
|
/sbin/nologin
|
lp | 4 | 7 |
/var/spool/lpd
|
/sbin/nologin
|
sync | 5 | 0 |
/sbin
|
/bin/sync
|
shutdown | 6 | 0 |
/sbin
|
/sbin/shutdown
|
halt | 7 | 0 |
/sbin
|
/sbin/halt
|
8 | 12 |
/var/spool/mail
|
/sbin/nologin
|
|
news | 9 | 13 |
/etc/news
|
|
uucp | 10 | 14 |
/var/spool/uucp
|
/sbin/nologin
|
operator | 11 | 0 |
/root
|
/sbin/nologin
|
games | 12 | 100 |
/usr/games
|
/sbin/nologin
|
gopher | 13 | 30 |
/var/gopher
|
/sbin/nologin
|
ftp | 14 | 50 |
/var/ftp
|
/sbin/nologin
|
nobody | 99 | 99 |
/
|
/sbin/nologin
|
rpm | 37 | 37 |
/var/lib/rpm
|
/sbin/nologin
|
vcsa | 69 | 69 |
/dev
|
/sbin/nologin
|
dbus | 81 | 81 |
/
|
/sbin/nologin
|
ntp | 38 | 38 |
/etc/ntp
|
/sbin/nologin
|
canna | 39 | 39 |
/var/lib/canna
|
/sbin/nologin
|
nscd | 28 | 28 |
/
|
/sbin/nologin
|
rpc | 32 | 32 |
/
|
/sbin/nologin
|
postfix | 89 | 89 |
/var/spool/postfix
|
/sbin/nologin
|
mailman | 41 | 41 |
/var/mailman
|
/sbin/nologin
|
named | 25 | 25 |
/var/named
|
/bin/false
|
amanda | 33 | 6 |
var/lib/amanda/
|
/bin/bash
|
postgres | 26 | 26 |
/var/lib/pgsql
|
/bin/bash
|
exim | 93 | 93 |
/var/spool/exim
|
/sbin/nologin
|
sshd | 74 | 74 |
/var/empty/sshd
|
/sbin/nologin
|
rpcuser | 29 | 29 |
/var/lib/nfs
|
/sbin/nologin
|
nsfnobody | 65534 | 65534 |
/var/lib/nfs
|
/sbin/nologin
|
pvm | 24 | 24 |
/usr/share/pvm3
|
/bin/bash
|
apache | 48 | 48 |
/var/www
|
/sbin/nologin
|
xfs | 43 | 43 |
/etc/X11/fs
|
/sbin/nologin
|
gdm | 42 | 42 |
/var/gdm
|
/sbin/nologin
|
htt | 100 | 101 |
/usr/lib/im
|
/sbin/nologin
|
mysql | 27 | 27 |
/var/lib/mysql
|
/bin/bash
|
webalizer | 67 | 67 |
/var/www/usage
|
/sbin/nologin
|
mailnull | 47 | 47 |
/var/spool/mqueue
|
/sbin/nologin
|
smmsp | 51 | 51 |
/var/spool/mqueue
|
/sbin/nologin
|
squid | 23 | 23 |
/var/spool/squid
|
/sbin/nologin
|
ldap | 55 | 55 |
/var/lib/ldap
|
/bin/false
|
netdump | 34 | 34 |
/var/crash
|
/bin/bash
|
pcap | 77 | 77 |
/var/arpwatch
|
/sbin/nologin
|
radiusd | 95 | 95 |
/
|
/bin/false
|
radvd | 75 | 75 |
/
|
/sbin/nologin
|
quagga | 92 | 92 |
/var/run/quagga
|
/sbin/login
|
wnn | 49 | 49 |
/var/lib/wnn
|
/sbin/nologin
|
dovecot | 97 | 97 |
/usr/libexec/dovecot
|
/sbin/nologin
|
Tableau 24.5, « Groupes ordinaires » liste les groupes standards configurés par une installation Tout. Les groupes sont stockés dans le fichier /etc/group
.
Groupe | GID | Membres |
---|---|---|
root | 0 | root |
bin | 1 | root, bin, daemon |
daemon | 2 | root, bin, daemon |
sys | 3 | root, bin, adm |
adm | 4 | root, adm, daemon |
tty | 5 | |
disk | 6 | root |
lp | 7 | daemon, lp |
mem | 8 | |
kmem | 9 | |
wheel | 10 | root |
12 | mail, postfix, exim | |
news | 13 | news |
uucp | 14 | uucp |
man | 15 | |
games | 20 | |
gopher | 30 | |
dip | 40 | |
ftp | 50 | |
lock | 54 | |
nobody | 99 | |
users | 100 | |
rpm | 37 | |
utmp | 22 | |
floppy | 19 | |
vcsa | 69 | |
dbus | 81 | |
ntp | 38 | |
canna | 39 | |
nscd | 28 | |
rpc | 32 | |
postdrop | 90 | |
postfix | 89 | |
mailman | 41 | |
exim | 93 | |
named | 25 | |
postgres | 26 | |
sshd | 74 | |
rpcuser | 29 | |
nfsnobody | 65534 | |
pvm | 24 | |
apache | 48 | |
xfs | 43 | |
gdm | 42 | |
htt | 101 | |
mysql | 27 | |
webalizer | 67 | |
mailnull | 47 | |
smmsp | 51 | |
squid | 23 | |
ldap | 55 | |
netdump | 34 | |
pcap | 77 | |
quaggavt | 102 | |
quagga | 92 | |
radvd | 75 | |
slocate | 21 | |
wnn | 49 | |
dovecot | 97 | |
radiusd | 95 |
Red Hat Enterprise Linux utilise un système de groupe privé d'utilisateurs (ou UPG de l'anglais User Private Group) qui facilite considérablement la gestion de groupes UNIX.
Un UPG est créé chaque fois qu'un nouvel utilisateur est ajouté au système. Les UPG portent le même nom que l'utilisateur pour lequel ils ont été créés et seul cet utilisateur est un membre de l'UPG.
Grâce à l'utilisation d'UPG, il est possible de déterminer en toute sécurité des permissions par défaut pour un nouveau fichier ou répertoire afin que l'utilisateur et le groupe de cet utilisateur puissent modifier le fichier ou répertoire.
Le paramètre qui détermine les permissions spécifiques à accorder à de nouveaux fichiers ou répertoires s'appelle umask ; ce dernier est configuré dans le fichier /etc/bashrc
. Sur des systèmes UNIX, umask
a traditionnellement une valeur de 022
, permettant uniquement l'utilisateur qui a créé le fichier ou répertoire de le modifier. Sous ce système, aucun autre utilisateur, même les membres appartenant au groupe du créateur, n'est autorisé à apporter quelque modification que ce soit. Cependant, étant donné que chaque utilisateur a son propre groupe privé dans le système UPG, cette "protection de groupe" n'est pas nécessaire.
Dans de nombreuses sociétés du secteur informatique il est courant de créer un groupe pour chaque grand projet et d'y assigner ensuites des personnes, si ces dernières doivent avoir accès aux fichiers du projet. Avec ce système traditionnel, un fichier est créé, il est associé au groupe primaire auquel son créateur appartient. Ainsi, lorsqu'une même personne travaille sur plusieurs projets, il devient difficile d'associer les bons fichiers au bon groupe. Toutefois, en utilisant le système UPG, les groupes sont automatiquement assignés aux fichiers créés dans un répertoire avec un bit setgid déterminé. Ce dernier facilite considérablement la gestion des projets de groupe qui partagent un répertoire commun étant donné que tous les fichiers créés par un utilisateur au sein du répertoire appartiennent au groupe propriétaire du répertoire.
Supposons par exemple qu'un groupe de personnes travaille sur des fichiers figurant dans le répertoire /usr/share/emacs/site-lisp/
. Certaines personnes dignes de confiance peuvent certes être autorisées à modifier le répertoire, mais tout le monde ne peut pas jouir de ce privilège. Il est donc nécessaire de créer d'abord un groupe emacs
, comme le fait la commande suivante :
/usr/sbin/groupadd emacs
Afin d'associer le contenu du répertoire au groupe emacs
, tapez :
chown -R root.emacs /usr/share/emacs/site-lisp
Il est maintenant possible d'ajouter les utilisateurs appropriés au groupe à l'aide de la commande gpasswd
:
/usr/bin/gpasswd -a <username>
emacs
Afin d'autoriser les utilisateurs à créer des fichiers dans le répertoire, utilisez la commande suivante :
chmod 775 /usr/share/emacs/site-lisp
Lorsqu'un utilisateur crée un nouveau fichier, il se voit assigner le groupe privé par défaut du groupe de l'utilisateur. Ensuite, donnez une valeur au bit setgid, qui donne à tout fichier créé dans le répertoire la même permission de groupe que le répertoire lui-même (emacs
). Utilisez la commande suivante :
chmod 2775 /usr/share/emacs/site-lisp
À ce stade, comme l'umask par défaut de chaque utilisateur est 002, tous les membres du groupe emacs
peuvent créer et modifier des fichiers dans le répertoire /usr/lib/emacs/site-lisp/
, sans que l'administrateur n'aie à changer les permissions de fichiers chaque fois que des utilisateurs enregistrent de nouveaux fichiers.
Dans un environnement multi-utilisateurs, il est primordial d'utiliser des mots de passe masqués (fournis par le paquetage shadow-utils
). Ce faisant, la sécurité des fichiers d'authentification du système se voit accrue. C'est pour cette raison que le programme d'installation active des mots de passe masqués par défaut.
Ci-dessous figure une liste des avantages associés aux mots de passe masqués par rapport à l'ancienne manière de stocker des mots de passe sur des systèmes basés sur UNIX :
Amélioration de la sécurité du système en déplaçant les hachages de mots de passe cryptés d'un fichier /etc/passwd
lisible par quiconque à un fichier /etc/shadow
lisible uniquement par le super-utilisateur.
Stockage d'informations sur l'expiration des mots de passe.
Possibilité d'utiliser le fichier /etc/login.defs
pour mettre en oeuvre les politiques de sécurité.
La plupart des utilitaires fournis par le paquetage shadow-utils
fonctionnent correctement, que des mots de passe masqués soient activés ou non. Toutefois, comme les informations sur l'expiration des mots de passe sont stockées exclusivement dans le fichier /etc/shadow
, aucune commande créant ou modifiant les informations sur l'expiration des mots de passe ne fonctionnera.
Ci-après figure une liste des commandes ne fonctionnant pas sans que les mots de passe masqués ne soient préalablement activés :
chage
gpasswd
/usr/sbin/usermod
options -e
ou -f
/usr/sbin/useradd
options -e
ou -f
Afin d'obtenir davantage d'informations sur les utilisateurs et les groupes ainsi que sur les outils permettant leur gestion, reportez-vous aux ressources mentionnées ci-dessous.
Pages de manuel sur le sujet — Il existe un certain nombre de pages de manuel pour les différentes applications et divers fichiers de configuration intervenant dans la gestion des utilisateurs et des groupes. La liste suivante présente certaines des pages de manuel les plus importantes :
man chage
— Une commande pour modifier les politiques d'expiration des mots de passe et des comptes.
man gpasswd
— Une commande pour gérer le fichier /etc/group
.
man groupadd
— Une commande pour ajouter des groupes.
man grpck
— Une commande pour vérifier le fichier /etc/group
.
man groupdel
— Une commande pour supprimer des groupes.
man groupmod
— Une commande pour modifier le propriétaire d'un groupe.
man pwck
— Une commande pour vérifier les fichiers /etc/passwd
et /etc/shadow
.
man pwconv
— Un outil permettant la conversion de mots de passe standard en mots de passe masqués.
man pwunconv
— Un outil permettant la conversion de mots de passe masqués en mots de passe standard.
man useradd
— Une commande pour ajouter des utilisateurs.
man userdel
— Une commande pour supprimer des utilisateurs.
man usermod
— Une commande pour modifier des utilisateurs.
man 5 group
— Le fichier contenant les informations de groupes pour le système.
man 5 passwd
— Le fichier contenant les informations d'utilisateurs pour le système.
man 5 shadow
— Le fichier contenant les informations d'expiration des mots de passe et des comptes pour le système.
L'Outil de configuration de l'imprimante permet aux utilisateurs de configurer une imprimante. Il permet de maintenir le fichier de configuration de l'imprimante, d'imprimer les répertoires de spoule (ou spool), les filtres et les catégories d'imprimantes.
Red Hat Enterprise Linux 5.2 uses the Common Unix Printing System (CUPS). If a system was upgraded from a previous Red Hat Enterprise Linux version that used CUPS, the upgrade process preserves the configured queues.
Afin de pouvoir utiliser l'Outil de configuration de l'imprimante, vous devez disposez des privilèges du super-utilisateur (ou root). Pour lancer l'application, sélectionnez le menu System (on the panel) => Administration => Impression ou saisissez la commande system-config-printer
.
Il est possible de configurer les types de files d'attente d'impression suivants :
AppSocket/HP JetDirect — une imprimante directement connectée au réseau avec l'interface HP JetDirect ou Appsocket au lieu d'être reliée à un ordinateur.
Protocole d'impression Internet (IPP) — une imprimante accessible sur un réseau TCP/IP par le biais du protocole d'impression Internet, également connu sous le nom IPP (de l'anglais Internet Printing Protocol) (par exemple, une imprimante reliée à un autre système Red Hat Enterprise Linux exécutant CUPS sur le réseau).
Hôte ou imprimante LPD/LPR — une imprimante reliée à un autre système d'impression UNIX auquel l'accès est possible par un réseau TCP/IP (par exemple, une imprimante reliée à un autre système Red Hat Enterprise Linux exécutant LPD sur le réseau).
Windows réseau (SMB) — une imprimante reliée à un autre système qui partage une imprimante sur un réseau SMB (par exemple, une imprimante reliée à un ordinateur Microsoft Windows™).
JetDirect réseau — une imprimante directement connectée au réseau par HP JetDirect au lieu d'être reliée à un ordinateur.
Si vous ajoutez une nouvelle file d'attente d'impression ou si vous en modifiez une existante, vous devez appliquer les modifications afin qu'elles prennent effet.
Cliquez sur le bouton Appliquer pour redémarrer le démon de l'imprimante avec les changements que vous avez effectués.
Cliquez sur le bouton Revenir pour annuler les changements effectués.
Pour ajouter une imprimante locale, comme par exemple une imprimante reliée au port parallèle ou USB de votre ordinateur, cliquez sur le bouton Nouveau dans la fenêtre principale de l'Outil de configuration de l'imprimante pour afficher la fenêtre de la Figure 25.2, « Ajout d'une imprimante ».
Cliquez sur Suivant pour continuer.
Entrez un nom unique pour l'imprimante dans le champ de texte Nom de l'imprimante. Le nom de l'imprimante peut contenir des lettres, des nombres, des tirets (-) et des tirets bas (_). En revanche, il ne peut pas contenir d'espaces.
Vous pouvez également utiliser les champs Description et Emplacement pour mieux distinguer une imprimante qui serait configurée sur votre système. Ces deux champs sont optionnels et peuvent contenir des espaces.
Cliquez sur Suivant pour ouvrir la boîte de dialogue Nouvelle imprimante (reportez-vous à la Figure 25.3, « Ajout d'une imprimante locale »). Si l'imprimante a été détectée automatiquement, le modèle d'imprimante apparaît dans Choisir la connexion. Pour continuer, sélectionnez le modèle d'imprimante et cliquez sur Suivant.
Si il n'apparaît automatiquement, sélectionnez le périphérique auquel l'imprimante est connectée (par exemple LPT #1 ou Port série #1) dans Choisir le type de la connexion.
L'étape suivante consiste à sélectionner le type d'imprimante. Reportez-vous à la Section 25.5, « Sélection d'un modèle d'imprimante et fin du processus » pour obtenir de plus amples informations.
Une imprimante IPP est une imprimante reliée à un autre système sur le même réseau TCP/IP. Le système auquel l'imprimante est reliée peut exécuter CUPS ou être simplement configuré pour utiliser IPP.
Si vous avez un pare-feu configuré sur le serveur d'impression, il doit être en mesure d'envoyer et de recevoir des connexions sur le port UDP entrant, 631. Si vous avez un pare-feu configuré sur le client (l'ordinateur envoyant la requête d'impression), il doit être configuré pour accepter et créer des connexions sur le port 631.
Vous pouvez ajouter une imprimante IPP réseau en cliquant sur le bouton Nouvelle imprimante de la fenêtre principale Outil de configuration de l'imprimante. La fenêtre reproduite par la Figure 25.2, « Ajout d'une imprimante » apparaît. Saisissez le Nom de l'imprimante (les noms d'imprimante peuvent contenir des lettres, nombres, tirets (-) et tirets bas (_) mais aucun espace), la Description et l'Emplacement afin de distinguer l'imprimante que vous configurez sur votre système. Cliquez sur Suivant pour continuer.
Comme l'illustre la fenêtre reproduite dans la Figure 25.4, « Ajout d'une imprimante IPP », entrez le nom d'hôte de l'imprimante IPP dans le champ Nom d'hôte ainsi qu'un nom unique pour l'imprimante dans le champ Nom de l'imprimante.
Cliquez sur Suivant pour continuer.
L'étape suivante consiste à sélectionner le type d'imprimante. Reportez-vous à la Section 25.5, « Sélection d'un modèle d'imprimante et fin du processus » pour obtenir de plus amples informations.
Vous pouvez ajouter un partage d'imprimante de type Samba (SMB) en cliquant sur le bouton Nouvelle imprimante de la fenêtre principale Outil de configuration de l'imprimante. La fenêtre reproduite par la Figure 25.2, « Ajout d'une imprimante » apparaît. Saisissez un nom unique pour l'imprimante dans le champ Nom de l'imprimante. Le nom de l'imprimante peut contenir des lettres, nombres, tirets (-) et tirets bas (_) ; il ne doit pas contenir d'espaces.
Vous pouvez également utiliser les champs Description et Emplacement pour mieux distinguer une imprimante qui serait configurée sur votre système. Ces deux champs sont optionnels et peuvent contenir des espaces.
Comme l'illustre la Figure 25.5, « Ajout d'une imprimante SMB », les partages SMB disponibles sont automatiquement détectés et listés dans la colonne Partage. Cliquez sur la flèche (
) à côté d'un groupe de travail pour l'étendre. À partir de la liste étendue, sélectionnez une imprimante.
Si l'imprimante que vous souhaitez partager n'apparaît pas dans la liste, entrez l'adresse SMB dans le champ smb://. Utilisez le format nom de l'ordinateur/partage d'imprimante
. Dans la Figure 25.5, « Ajout d'une imprimante SMB », le nom de l'ordinateur
est dellbox
, alors que le partage de l'imprimante
est r2
.
Dans le champ Nom d'utilisateur, saisissez le nom de l'utilisateur devant accéder à l'imprimante. L'utilisateur doit exister sur le système SMB et doit avoir les permissions pour accéder à l'imprimante. Le nom d''utilisateur par défaut est typiquement guest
pour les serveurs Windows ou nobody
pour les serveurs Samba.
Saisissez le Mot de passe (si requis) pour l'utilisateur spécifié dans le champ Nom d'utilisateur.
Vous pouvez ensuite tester la connexion en cliquant sur Verifier. Si la vérification réussie, une boîte de dialogue apparaît confirmant l'accessibilité au partage d'imprimante.
L'étape suivante consiste à sélectionner le type d'imprimante. Reportez-vous à la Section 25.5, « Sélection d'un modèle d'imprimante et fin du processus » pour obtenir de plus amples informations.
Les noms d'utilisateur et mots de passe Samba sont stockés sur le serveur d'impression en tant que fichiers non-cryptés lisibles par le super-utilisateur (ou root) et lpd. De cette manière, les utilisateurs qui ont un accès super-utilisateur au serveur d'impression peuvent voir le nom d'utilisateur et mot de passe que vous utilisez pour accéder à l'imprimante Samba.
Ainsi, lorsque vous choisissez un nom d'utilisateur et mot de passe pour accéder à l'imprimante Samba, nous vous recommandons de choisir un mot de passe différent de celui que vous utilisez pour accéder à votre système local Red Hat Enterprise Linux.
S'il y a des fichiers partagés sur le serveur d'impression Samba, il est recommandé qu'ils utilisent également un mot de passe différent de celui utilisé par la file d'attente d'impression.
Pour ajouter un partage d'imprimante connecté au réseau avec l'interface JetDirect ou AppSocket, cliquez sur le bouton Nouvelle imprimante de la fenêtre principale Outil de configuration de l'imprimante. La fenêtre reproduite dans la Figure 25.2, « Ajout d'une imprimante » apparaît. Saisissez un nom unique pour l'imprimante dans le champ Nom de l'imprimante. Le nom de l'imprimante peut contenir des lettres, nombres, tirets (-) et tirets bas (_) ; il ne doit pas contenir d'espaces.
Vous pouvez également utiliser les champs Description et Emplacement pour mieux distinguer une imprimante qui serait configurée sur votre système. Ces deux champs sont optionnels et peuvent contenir des espaces.
Cliquez sur Suivant pour continuer.
Les champs de texte pour les options suivantes apparaissent :
Nom d'hôte — Le nom d'hôte ou l'adresse IP de l'imprimante JetDirect.
Numéro de port — Le port de l'imprimante JetDirect qui en attente de travaux d'impression. Le port par défaut est 9100.
L'étape suivante consiste à sélectionner le type d'imprimante. Reportez-vous à la Section 25.5, « Sélection d'un modèle d'imprimante et fin du processus » pour obtenir de plus amples informations.
Une fois que vous avez sélectionné correctement un type de file d'attente d'impression, vous pouvez choisir l'une ou l'autre de ces options :
Sélectionner une imprimante à partir de la base de données - Si vous sélectionnez cette option, choisissez le modèle de votre imprimante à partir de la liste de Modèles. Si votre imprimante n'est pas listée, choisissez Générique.
Fournir un fichier PPD - Un fichier de description de l'imprimante PostScript (PPD) peut être fourni avec votre imprimante. Ce fichier est généralement fourni par le fabriquant. Si vous possédez un fichier PPD, vous pouvez choisir cette option et utiliser la barre de navigation sous la description de l'option pour sélectionner le fichier PPD.
Reportez-vous à la Figure 25.7, « Sélection d'un modèle d'imprimante ».
Après avoir choisi une option, cliquez sur Suivant pour continuer. La Figure 25.7, « Sélection d'un modèle d'imprimante » apparaît. Vous devez maintenant choisir le modèle et le pilote de l'imprimante.
Le pilote d'impression recommandé est choisi automatiquement en fonction du modèle d'imprimante retenu. Le pilote d'impression traite les données que vous souhaitez imprimer dans un format que l'imprimante comprend. Étant donné qu'une imprimante locale est reliée directement à votre ordinateur, vous avez besoin d'un pilote d'impression pour traiter les données envoyées à l'imprimante.
Si vous avez un fichier PPD pour le périphérique (habituellement fourni par le fabriquant), vous pouvez le sélectionner en choisissant Fournir un fichier PPD. Vous pouvez ensuite parcourir le système de fichiers pour rechercher le fichier PPD en cliquant sur Parcourir.
La dernière étape consiste à confirmer votre configuration d'imprimante. Cliquez sur Appliquer pour ajouter la file d'attente d'impression si les paramètres sont corrects. Cliquez sur Précédent pour modifier la configuration de l'imprimante.
Après avoir appliqué les modifications, imprimez une page de test pour vérifier que la configuration est bien correcte. Reportez-vous à la Section 25.6, « Impression d'une page de test » pour obtenir de plus amples informations.
Une fois la configuration de l'imprimante terminée, il est recommandé d'imprimer une page de test afin de vous assurer du bon fonctionnement de l'imprimante. Pour ce faire, sélectionnez dans la liste des imprimantes celle que vous souhaitez tester, puis cliquez sur Imprimer une page de test sur l'onglet Paramètres de l'imprimante.
Si vous avez changé le pilote d'impression ou modifié les options du pilote, nous vous recommandons d'imprimer une page de test pour vérifier le bon fonctionnement de la nouvelle configuration.
Pour supprimer une imprimante existante, sélectionnez l'imprimante et cliquez sur le bouton Supprimer dans la barre d'outils. L'imprimante est retirée de la liste une fois que vous confirmez la suppression de la configuration de l'imprimante.
Pour configurer l'imprimante par défaut, sélectionnez l'imprimante à partir de la liste et cliquez sur le bouton Faire de cette imprimante l'imprimante par défaut dans l'onglet Paramètres.
Pour changer la configuration du pilote de l'imprimante, cliquez sur le nom correspondant dans la liste d'Imprimantes et cliquez sur l'onglet Paramètres.
Vous pouvez modifier les paramètres d'une imprimante tels que la marque et le modèle, faire d'une imprimante l'imprimante par défaut, imprimer une page de test, changer l'emplacement du périphérique (URI), etc.
Pour changer les paramètres au niveau de la sortie d'impression, cliquez sur l'onglet Politiques.
Par exemple, pour créer une bannière de page (une page qui décrit les aspects de la tâche d'impression comme par exemple l'origine de l'imprimante, le nom d'utilisateur de la personne qui a créé la tâche et le statut de sécurité du document en cours d'impression) cliquez sur le menu déroulant Bannière de début ou Bannière de fin et choisissez l'option qui décrit le mieux la nature des tâches d'impression (par exemple top secret, classifié ou confidentiel).
Vous pouvez également configurer
Vous pouvez changer le niveau d'accès utilisateur de l'imprimante configurée en cliquant sur l'onglet Contrôle d'accès.
Ajoutez des utilisateurs en utilisant la zone de texte et cliquez sur le bouton Ajouter. Vous pouvez ensuite choisir d'autoriser ou interdire l'usage de cette imprimante uniquement à ce sous-groupe d'utilisateurs.
L'onglet Options de l'imprimante contient divers options de configuration pour la source et la sortie de l'imprimante.
Format de la page — Vous permet de sélectionner le format de la page. Les options incluent A4, A3, US légal et US lettre.
Source de support — Cette option est configurée par défaut sur Automatique. Modifiez-la pour utiliser du papier provenant d'un plateau différent.
Type de média — Vous permet de changer le type de papier. Ces options incluent : ordinaire, épais, "bond" et transparent.
Résolution — Vous permet de configurer la qualité et le détail de l'impression (par défaut la résolution est de 300 points par pouce (dpi)).
Économie de la poudre d'encre — Vous permet de choisir si l'imprimante doit utiliser moins de poudre d'encre afin d'économiser les ressources.
Vous pouvez également configurer les options des tâches d'impression en utilisant l'onglet Options des tâches d'impression. Utilisez le menu déroulant et choisissez les options des tâches d'impression telles que les modes Paysage (impression horizontale ou verticale), copies, ou à l'échelle (augmentez ou réduisez la surface à imprimer, qui peut être utilisée pour aller sur une surface d'impression plus grande, sur une feuille physiquement plus petite du média d'impression).
Lorsque vous envoyez un travail d'impression au démon d'impression, comme par exemple l'impression d'un texte depuis Emacs ou d'une image depuis The GIMP, ce travail est ajouté à la file de spoule d'impression. Cette dernière est une liste des travaux d'impression qui ont été envoyés à l'imprimante et d'informations sur chaque requête d'impression, comme par exemple, l'état de la requête, le numéro du travail, etc.
Durant l'impression, l'icône de statut de l'imprimante apparaît dans la Zone de notification du panneau. Pour vérifier le statut de la tâche d'impression, cliquez deux fois sur le statut de l'imprimante afin d'afficher une fenêtre similaire à la Figure 25.12, « Statut d'impression GNOME ».
Afin d'annuler un travail d'impression spécifique listé dans le Statut d'impression GNOME, choisissez-le dans la liste et sélectionnez Édition => Annuler les documents dans le menu déroulant.
Afin d'afficher la liste des travaux d'impression dans le spoule d'impression à partir d'une invite du shell, tapez la commande lpq
. Les dernières lignes ressembleront à l'extrait ci-dessous :
Rank Owner/ID Class Job Files Size Time active user@localhost+902 A 902 sample.txt 2050 01:20:46
lpq
Si vous voulez annuler un travail d'impression, trouvez le numéro de travail de la requête au moyen de la commande lpq
, puis utilisez la commande lprm
. Par exemple, numéro de travail
lprm 902
annule le travail d'impression dans l'Exemple 25.1, « Exemple de sortie lpq
». Vous devez disposer des autorisations adéquates pour annuler un travail d'impression. Vous ne pouvez pas annuler ceux qui ont été lancés par d'autres utilisateurs à moins que vous ne soyez connecté en tant que super-utilisateur (ou root) sur la machine à laquelle l'imprimante est reliée.
Vous pouvez également imprimer un fichier directement depuis une invite de shell. Par exemple, la commande lpr sample.txt
imprimera le fichier sample.txt
. Le filtre d'impression détermine le type de fichier dont il s'agit et le convertit dans un format que l'imprimante pourra interpréter.
Pour en savoir plus sur l'impression avec Red Hat Enterprise Linux, consultez les ressources mentionnées ci-dessous.
map lpr
— La page de manuel relative à la commande lpr
qui vous permet d'imprimer des fichiers depuis la ligne de commande.
man lprm
— La page de manuel relative à l'utilitaire de ligne de commande permettant de supprimer les travaux d'impression de la file d'attente.
man mpage
— La page de manuel relative à l'utilitaire de ligne de commande afin d'imprimer plusieurs pages sur une seule feuille.
man cupsd
— La page de manuel relative au démon d'impression du système CUPS.
man cupsd.conf
— La page de manuel relative au fichier de configuration du démon d'impression du système CUPS.
man classes.conf
— La page de manuel relative au fichier de configuration de classe pour le système d'impression CUPS.
http://www.linuxprinting.org — GNU/Linux Printing contient une grande quantité d'informations sur l'impression sous Linux.
http://www.cups.org/ — Documentation, Forum Aux Questions (FAQ) et groupes de discussion sur CUPS.
Dans Linux, des tâches peuvent être configurées pour être exécutées automatiquement pendant une période de temps ou à une date donnée, ou encore, lorsque la moyenne de chargement du système se situe en dessous d'un certain niveau. Red Hat Enterprise Linux est préconfiguré pour l'exécution de certaines tâches système importantes permettant de garder votre système à jour. Par exemple, la base de données slocate utilisée par la commande locate
est mise à jour quotidiennement. Un administrateur système peut utiliser des tâches automatisées pour effectuer des sauvegardes périodiques, contrôler le système, exécuter des scripts personnalisés, etc.
Red Hat Enterprise Linux est livré avec plusieurs utilitaires de tâches automatisées : cron
, at
et batch
.
Cron est un démon qui peut être utilisé pour programmer l'exécution de tâches récurrentes en fonction d'une combinaison de l'heure, du jour du mois, du mois, du jour de la semaine et de la semaine.
Cron suppose que le système est allumé en permanence. Si le système n'est pas allumé au moment où une tâche doit être exécutée, l'exécution n'a pas lieu. Pour configurer des tâches qui ne seront exécutées qu'une seule fois, reportez-vous à la Section 26.2, « At et Batch ».
Afin de pouvoir utiliser le service cron, le paquetage RPM vixie-cron
doit être installé et le service crond
doit être en cours d'exécution. Pour savoir si le paquetage est installé, utilisez la commande rpm -q vixie-cron
. Pour savoir si le service est en cours d'exécution, utilisez la commande /sbin/service crond status
.
Le fichier de configuration principal de cron, /etc/crontab
, contient les lignes suivantes :
SHELL=/bin/bash PATH=/sbin:/bin:/usr/sbin:/usr/bin MAILTO=root HOME=/ # run-parts 01 * * * * root run-parts /etc/cron.hourly 02 4 * * * root run-parts /etc/cron.daily 22 4 * * 0 root run-parts /etc/cron.weekly 42 4 1 * * root run-parts /etc/cron.monthly
Les quatre premières lignes représentent des variables servant à configurer l'environnement dans lequel les tâches cron sont exécutées. La valeur de la variable SHELL
indique au système quel environnement shell utiliser (le shell bash dans cet exemple) et la variable PATH
définit le chemin d'accès utilisé pour l'exécution des commandes. Le résultat des tâches cron est envoyé par courrier électronique au nom d'utilisateur défini par la variable MAILTO
. Si la variable MAILTO
est définie comme étant une chaîne vide (MAILTO=""
), aucun courrier électronique n'est envoyé. La variable HOME
peut être utilisée pour définir le répertoire personnel à utiliser lors de l'exécution de commandes ou de scripts.
Chacune des lignes du fichier /etc/crontab
représente une tâche et se présente sous le format suivant :
minute hour day month dayofweek command
minute
— tout nombre entier compris entre 0 et 59
hour
— tout nombre entier compris entre 0 et 23, pour l'heure
day
— tout nombre entier compris entre 1 et 31 pour le jour (si le mois est spécifié, le jour doit être valide)
month
— tout nombre entier compris entre 1 et 12 pour le mois (ou abréviation du nom du mois comme jan pour janvier, feb pour février, etc.)
dayofweek
— tout nombre entier compris entre 0 et 7 pour le jour de la semaine, 0 ou 7 représentant le dimanche (ou l'abréviation du jour de la semaine comme sun pour dimanche ou mon pour lundi)
command
— la commande à exécuter (il peut s'agir d'une commande telle que ls /proc >> /tmp/proc
ou de la commande d'exécution d'un script personnalisé)
Pour toute valeur ci-dessus, un astérisque (*) peut être utilisé afin d'indiquer toutes les valeurs valides. Par exemple, un astérisque utilisé pour la valeur du mois signifie une exécution mensuelle de la commande, en tenant compte bien sûr des contraintes liées aux autres valeurs.
Un trait d'union (-) placé entre deux nombres entiers indique une fourchette de nombres entiers. Par exemple, 1-4
correspond aux nombres entiers 1, 2, 3 et 4.
Une série de valeurs séparées par des virgules (,) détermine une liste. Par exemple, 3, 4, 6, 8
correspond à ces quatre nombres entiers spécifiques.
La barre oblique en avant (/) peut être utilisée pour spécifier des valeurs échelonnées. Pour sauter la valeur d'un nombre entier dans une fourchette, faites suivre la fourchette de /<
. Par exemple, nombre entier
>0-59/2
permet de définir une minute sur deux dans le champ des minutes. Ces valeurs échelonnées peuvent également être utilisées avec un astérisque. Par exemple, la valeur */3
peut être utilisée dans le champ des mois pour exécuter la tâche tous les trois mois.
Toute ligne commençant par le signe dièse (#) correspond à un commentaire et n'est pas traitée.
Comme le montre le fichier /etc/crontab
, le script run-parts
est utilisé pour exécuter les scripts des répertoires /etc/cron.hourly/
, /etc/cron.daily/
, /etc/cron.weekly/
et /etc/cron.monthly/
sur une base respectivement horaire, quotidienne, hebdomadaire ou mensuelle. Les fichiers de ces répertoires doivent être des scripts shell.
Si une tâche cron doit être exécutée sur une base qui n'est ni horaire, ni quotidienne, ni hebdomadaire, ni mensuelle, elle peut être ajoutée au répertoire /etc/cron.d/
. Tous les fichiers de ce répertoire utilisent la même syntaxe que /etc/crontab
. Reportez-vous à l'Exemple 26.1, « Exemples de crontab » pour obtenir différents exemples.
# record the memory usage of the system every monday # at 3:30AM in the file /tmp/meminfo 30 3 * * mon cat /proc/meminfo >> /tmp/meminfo # run custom script the first day of every month at 4:10AM 10 4 1 * * /root/scripts/backup.sh
Les utilisateurs autres que le super-utilisateur (root) peuvent configurer des tâches cron à l'aide de l'utilitaire crontab
. Tous les crontabs définis par l'utilisateur sont stockés dans le répertoire /var/spool/cron/
et exécutés en utilisant les noms des utilisateurs qui les ont créés. Pour créer un crontab en tant qu'un utilisateur, connectez-vous sous le nom de cet utilisateur et tapez la commande crontab -e
afin de modifier le crontab de l'utilisateur à l'aide de l'éditeur déterminé par la variable d'environnement VISUAL
ou EDITOR
. Le fichier utilise le même format que /etc/crontab
. Lorsque les modifications apportées à crontab sont enregistrées, crontab est stocké en fonction du nom d'utilisateur et est enregistré dans le fichier /var/spool/cron/
.
username
Le démon cron vérifie le fichier /etc/crontab
, le répertoire /etc/cron.d/
ainsi que le répertoire /var/spool/cron/
toutes les minutes afin de voir si des modifications ont été apportées. S'il en trouve, celles-ci sont chargées dans la mémoire. Il n'est par conséquent pas nécessaire de redémarrer le démon si un fichier crontab est modifié.
Les fichiers /etc/cron.allow
et /etc/cron.deny
sont utilisés pour limiter l'accès à cron. Le format de ces deux fichiers de contrôle d'accès requiert la présence d'un nom d'utilisateur sur chaque ligne. Les espaces blancs ne sont pas acceptés. Le démon cron (crond
) n'a pas à être redémarré si les fichiers de contrôle d'accès sont modifiés. Ces derniers sont lus chaque fois qu'un utilisateur essaie d'ajouter ou de supprimer une tâche cron.
Le super-utilisateur (root) est toujours en mesure d'utiliser cron, indépendamment des noms d'utilisateurs répertoriés dans les fichiers de contrôle d'accès.
Si le fichier cron.allow
existe, seuls les utilisateurs qui y sont répertoriés peuvent utiliser cron et le fichier cron.deny
n'est pas pris en compte.
En revanche, si le fichier cron.allow
n'existe pas, les utilisateurs répertoriés dans cron.deny
ne sont pas autorisés à utiliser cron.
Tandis que cron sert à programmer des tâches récurrentes, la commande at
est utilisée pour programmer une tâche unique à exécuter à un moment précis. La commande batch
sert à programmer une tâche qui doit être exécutée une seule fois lorsque la moyenne de chargement du système descend en dessous de 0.8.
Pour utiliser at
ou batch
, le paquetage RPM at
doit être installé et le service atd
doit être en cours d'exécution. Pour savoir si le paquetage est installé, utilisez la commande rpm -q at
. Pour savoir si le service est en cours d'exécution, utilisez la commande /sbin/service atd status
.
Pour programmer une tâche qui ne sera exécutée qu'une fois à un moment donné, entrez la commande at
, où moment
correspond au moment d'exécution de la commande.
moment
L'argument moment
peut prendre l'une des valeurs suivantes :
Format HH:MM — Par exemple, 04:00 signifie 4:00 du matin. Si l'heure est déjà passée, le processus sera exécuté le lendemain à l'heure spécifiée.
midnight — Signifie minuit, soit 12:00AM.
noon — Signifie midi, soit12:00 PM.
teatime — Signifie 16:00 heures, soit 4:00PM.
Format mois jour année — Par exemple, "January 15 2002" signifie le 15ème jour du mois de janvier de l'année 2002. L'année est facultative.
Formats MMJJAA, MM/JJ/AA, ou MM.JJ.AA — Par exemple, 011502 correspond au 15ème jour du mois de janvier de l'année 2002.
now + temps — Le temps est indiqué en minutes, heures, jours ou semaines. Par exemple, "now + 5 days" indique que la commande sera exécutée à la même heure dans cinq jours.
L'heure doit être spécifiée en premier, suivie de la date facultative. Pour plus d'informations sur le format s'appliquant à l'heure, lisez le fichier texte /usr/share/doc/at-
.
<version>
/timespec
Après avoir tapé la commande at
avec l'argument de temps, l'invite at>
s'affiche. Entrez la commande à exécuter, appuyez sur la touche Entrée et appuyez sur Ctrl-D. Vous pouvez spécifier plusieurs commandes en entrant chacune d'elles puis en tapant sur la touche Entrée. Après avoir tapé toutes les commandes, appuyez sur la touche Entrée afin d'afficher une ligne vierge, puis appuyez sur Ctrl-D. Un script shell peut également être saisi à l'invite en appuyant sur la touche Entrée après chaque ligne du script et en tapant Ctrl-D sur une ligne vierge pour quitter. Si un script est entré, le shell utilisé est celui qui est défini dans l'environnement SHELL
de l'utilisateur, le shell de connexion de l'utilisateur ou /bin/sh
(celui qui est trouvé en premier).
Si l'ensemble de commandes ou de scripts essaie d'afficher des informations dans la sortie standard, ces informations sont envoyées par courrier électronique à l'utilisateur.
Utilisez la commande atq
pour afficher les tâches en attente. Reportez-vous à la Section 26.2.3, « Affichage des tâches en attente » afin d'obtenir davantage d'informations.
L'utilisation de la commande at
peut être restreinte. Reportez-vous à la Section 26.2.5, « Contrôle de l'accès à at et batch » pour de plus amples informations.
Pour exécuter une seule fois une tâche spécifique lorsque la moyenne de chargement est inférieure à 0.8, utilisez la commande batch
.
Une fois la commande batch
saisie, l'invite at>
s'affiche. Entrez la commande à exécuter, appuyez sur la touche Entrée, puis sur Ctrl-D. Vous pouvez spécifier plusieurs commandes en entrant chacune d'elles suivie de Entrée. Après avoir tapé toutes les commandes, appuyez sur la touche Entrée afin d'afficher une ligne vide, puis appuyez sur Ctrl-D. Un script shell peut également être saisi à l'invite en appuyant sur la touche Entrée après chaque ligne du script et en appuyant sur Ctrl-D sur une ligne vide pour quitter. Si un script est saisi, le shell utilisé est celui défini dans l'environnement SHELL
de l'utilisateur, le shell de connexion de l'utilisateur ou /bin/sh
(celui qui est trouvé en premier). L'ensemble de commandes ou de scripts est exécuté dès que la moyenne de chargement se situe en dessous de 0.8.
Si l'ensemble de commandes ou de scripts essaie d'afficher des informations dans la sortie standard, ces informations sont envoyées par courrier électronique à l'utilisateur.
Utilisez la commande atq
pour afficher les tâches en attente. Reportez-vous à la Section 26.2.3, « Affichage des tâches en attente » afin d'obtenir davantage d'informations.
L'utilisation de la commande batch
peut être restreinte. Reportez-vous à la Section 26.2.5, « Contrôle de l'accès à at et batch » pour obtenir des d'informations plus détaillées.
Pour afficher les tâches at
et batch
en attente, utilisez la commande atq
. Elle affiche une liste des tâches en attente, une tâche par ligne. Chaque ligne se présente sous le format suivant : numéro de la tâche, date, heure, classe de la tâche et nom d'utilisateur. Les utilisateurs ne peuvent afficher que leurs propres tâches. Si le super-utilisateur (root) exécute la commande atq
, toutes les tâches de tous les utilisateurs sont affichées.
Parmi les options de ligne de commande supplémentaires pour at
et batch
, figurent :
Option | Description |
---|---|
-f
|
Lit les commandes ou le script shell depuis un fichier au lieu de les spécifier à l'invite. |
-m
|
Envoie un courrier électronique à l'utilisateur une fois la tâche accomplie. |
-v
|
Affiche l'heure à laquelle la tâche sera exécutée. |
at
et batch
Les fichiers /etc/at.allow
et /etc/at.deny
peuvent servir à limiter l'accès aux commandes at
et batch
. Le format de ces deux fichiers de contrôle d'accès requiert un nom d'utilisateur sur chaque ligne. Les espaces blancs n'y sont pas acceptés. Le démon at
(atd
) n'a pas à être redémarré si les fichiers de contrôle d'accès sont modifiés. Ces fichiers sont lus chaque fois qu'un utilisateur essaie d'exécuter les commandes at
ou batch
.
Le super-utilisateur peut toujours exécuter les commandes at
et batch
indépendamment des fichiers de contrôle d'accès.
Si le fichier at.allow
existe, seuls les utilisateurs qui y sont répertoriés peuvent utiliser at
ou batch
et le fichier at.deny
n'est pas pris en considération.
Si le fichier at.allow
n'existe pas, les utilisateurs répertoriés dans at.deny
ne sont pas autorisés à utiliser at
ou batch
.
Pour en savoir plus sur la configuration de tâches automatisées, reportez-vous aux ressources suivantes.
La page de manuel relative à cron
— Offre un aperçu de cron.
Les pages de manuel relatives à crontab
dans les sections 1 et 5 — La page de manuel dans la section 1 contient un aperçu du fichier crontab
. La page de manuel de la section 5 contient le format du fichier ainsi que des exemples d'entrées.
/usr/share/doc/at-
— Contient des informations plus détaillées sur les dates pouvant être spécifiées pour les tâches cron.
<version>
/timespec
La page de manuel relative à at
— Description de at
et batch
ainsi que leurs options de ligne de commande.
Les fichiers journaux sont des fichiers qui contiennent des messages relatifs au système, y compris au noyau, aux services et aux applications qui s'y rapportent. Les fichiers journaux diffèrent en fonction du type d'informations qu'ils contiennent. Il y a par exemple un fichier journal système par défaut, un fichier journal réservé aux messages de sécurité et un fichier journal réservé aux tâches cron.
Les fichiers journaux peuvent s'avérer très utiles si vous essayez de réparer un problème au niveau du système, par exemple si vous essayez de charger un pilote de noyau, ou si vous recherchez des tentatives de connexion non-autorisée au système. Ce chapitre indique où trouver les fichiers journaux, comment les consulter et les éléments à rechercher dans ces derniers.
Certains fichiers journaux sont contrôlés par un démon nommé syslogd
. Vous pouvez trouver une liste des messages de journaux gérée par syslogd
dans le fichier de configuration /etc/syslog.conf
.
La plupart des fichiers journaux sont situés dans le répertoire /var/log
. Certaines applications telles que httpd
et samba
disposent d'un répertoire situé dans /var/log
, qui contient leurs fichiers journaux.
Vous remarquerez que plusieurs fichiers du répertoire contenant les fichiers journaux sont suivis de numéros. Ils sont créés lorsqu'une rotation est opérée sur les fichiers journaux. Cette rotation est effectuée afin que la taille de ces fichiers ne devienne pas trop importante. Le paquetage logrotate
contient une tâche cron qui effectue automatiquement une rotation des fichiers journaux en fonction du fichier de configuration /etc/logrotate.conf
ainsi que des fichiers de configuration du répertoire /etc/logrotate.d/
. Par défaut, l'opération de rotation est effectuée toutes les semaines et conserve les fichiers journaux des quatre semaines précédentes.
La plupart des fichiers journaux sont en format texte clair. Vous pouvez les visualiser à l'aide de n'importe quel éditeur de texte tel que Vi ou Emacs. Certains fichiers journaux sont lisibles par tous les utilisateurs du système ; vous devez toutefois être connecté en tant que super-utilisateur pour lire la plupart des fichiers journaux.
Pour afficher les fichiers journaux système dans une application interactive en temps réel, utilisez l'Afficheur de journaux système. Pour lancer l'application, sélectionnez Applications (sur le panneau) => Système => Journaux système ou tapez la commande gnome-system-log
à l'invite du shell.
L'application n'affiche que les fichiers journaux qui existent ; par conséquent, la liste reproduite dans la Figure 27.1, « Afficheur de journaux système » sera peut-être différente de la vôtre.
Pour filtrer le contenu du fichier journal sélectionné, cliquez sur Afficher à partir du menu et sélectionnez Filtrer comme illustré ci-dessous.
Afficheur de journaux système - Menu Afficher
La sélection de l'élément Filtrer du menu affiche le champ texte Filtrer où vous pouvez saisir les mots-clés qui seront utilisés pour le filtre. Pour nettoyer votre filtre cliquez sur le bouton Nettoyer.
Pour ajouter un fichier journal à la liste, sélectionnez Fichier => Ouvrir. Cela affichera la fenêtre Ouvrir un journal où vous pouvez sélectionner le répertoire et le nom du fichier journal que vous voulez afficher. La figure ci-dessous illustre la fenêtre Ouvrir un journal.
Cliquez sur le bouton Ouvrir pour ouvrir le fichier. Ce dernier est immédiatement ajouté à la liste où vous pouvez le sélectionner et voir son contenu.
Veuillez également noter que l'afficheur de journaux système vous permet d'ouvrir des journaux zippés dont les noms de fichiers terminent par ".gz".
L'Afficheur de journaux système contrôle par défaut tous les journaux ouverts. Si une nouvelle ligne est ajoutée à un fichier journal contrôlé, le nom du journal apparaît en caractères gras dans la liste de journaux. Si le fichier journal est sélectionné ou affiché, les nouvelles lignes apparaissent en caractères gras au bas du fichier journal et après cinq secondes elles sont affichées avec une police normale. Ceci est illustré dans les figures qui suivent. La figure ci-dessous représente une nouvelle alerte dans le fichier journal messages. Le fichier journal est listé en caractères gras.
En cliquant sur le fichier journal messages vous affichez les journaux dans le fichier avec les nouvelles lignes en caractères gras comme ci-dessous.
Les nouvelles lignes sont affichées en caractères gras pendant cinq secondes avant que la police normale soit utilisée.
Contenu de fichiers journaux après cinq secondes
Les administrateurs système contrôlent également les performances du système. Red Hat Enterprise Linux contient des outils qui assistent les administrateurs dans ces tâches.
Table des matières
SystemTap fournit une interface en ligne de commande et un langage de script pour simplifier le regroupement d'informations à propos du noyau Linux en cours d'exécution afin que ce dernier puisse être analysé. Les données peuvent être extraites, filtrées et résumées rapidement et sans risque pour permettre le diagnostique de problèmes fonctionnels ou de performance complexes.
SystemTap autorise les scripts écrits dans un langage de script SystemTap, qui sont par la suite compilés en code C pour le module noyau et insérés dans le noyau.
L'idée essentielle derrière un script systemtap et de nommer des évènements et de leurs donner des gestionnaires. Lorsqu'un évènement se produit, le noyau Linux exécute le gestionnaire comme s'il s'agissait d'une sous-routine rapide et ensuite continue. Il y a plusieurs types d'évènements, tels que l'entrée ou la sortie dans une fonction, l'expiration d'un compteur, le démarrage ou l'arrêt d'une session systemtap entière. Un gestionnaire est constitué d'une série de déclarations du langage script qui spécifient le travail devant être effectué lorsqu'un évènement se produit. Ce travail inclut habituellement l'extraction des données à partir du contexte d'évènements, le stockage dans des variables internes ou l'impression de résultats.
System Tap est une approche orientée compilateur afin de générer l'instrumentation. Consultez la Figure 28.1, « Flux des données dans System Tap » pour visualiser un diagramme général du System Tap utilisé dans cette discussion. En haut à droite du diagramme se trouve probe.stp, le script de sonde écrit par le développeur. Ce dernier est analysé par l'interpréteur en arborescences parsées. Pendant ce temps, les entrées sont vérifiées afin de déterminer d'éventuelles erreurs de syntaxe. L'interpréteur effectue alors l'élaboration, l'ajout de code supplémentaire depuis la librairie de scripts et le choix des emplacements des points de sonde et des variables provenant des informations de débogage. Après la finalisation de l'élaboration, l'interpréteur peut générer probe.c, le module de noyau dans C.
Le fichier probe.c est compilé dans un module de noyau régulier, probe.ko, à l'aide du compilateur GCC. La compilation peut ajouter du code de support depuis les librairies d'exécution. Après que le GCC ait généré probe.ko, le démon SystemTap est lancé pour collecter les sorties du module d'instrumentation. Le module d'instrumentation est chargé dans le noyau et la collection de données est démarrée. Les données provenant du module d'instrumentation sont transférées vers l'espace utilisateur via relayfs et sont affichées par le démon. Quand un utilisateur tape Control-C le démon décharge le module, ce qui arrête également le processus de collection de données.
Systemtap fonctionne en traduisant un script SystemTap en C, et en exécutant le compilateur C du système pour créer un module de noyau. Quand le module est chargé, il active tous les évènements sondés en se branchant au noyau. Ensuite, étant donné que les évènements se produisent sur les processeurs, les gestionnaires compilés s'exécutent. Finalement, la session s'arrête, les crochets sont déconnectés, et le module supprimé. Le processus complet est géré avec un seul programme en ligne de commande, stap
.
La sonde la plus simple est celle qui trace un évènement. C'est le résultat de l'insertion de déclarations écrites, placées stratégiquement dans un programme. C'est souvent la première étape pour résoudre des problèmes : explorer en examinant l'historique de ce qui s'est passé.
Ce style d'instrumentation est le plus simple. Il demande juste à systemtap d'imprimer quelque chose à chaque évènement. Pour exprimer cela en langage script, vous devez indiquer ce qu'il faut sonder et ce qu'il faut imprimer.
Systemtap supporte différents évènements imbriqués. La librarie de scripts qui accompagne systemtap, chacun d'eux étant appelé "tapset", peut en définir d'autres, définis en termes de famille imbriquée. Consultez la page de manuel de stapprobes
pour plus d'informations. Tous ces évènements sont nommés à l'aide d'une syntaxe unifiée qui ressemble à des identificateurs paramétrés séparés par un point :
Évènement | Description |
---|---|
begin
|
Le lancement de la session systemtap. |
end
|
La fin de la session systemtap. |
kernel.function("sys_open")
|
L'entrée dans la fonction appelée sys_open dans le noyau. |
syscall.close.return
|
Le retour à partir de l'appel système de fermeture. |
module("ext3").statement(0xdeadbeef)
|
L'instruction adressée dans le pilote du système de fichiers ext3. |
timer.ms(200)
|
Un minuteur qui se déclenche toutes les 200 millisecondes. |
Nous utilisons un cas de démonstration dont l'objectif est de tracer toutes les entrées et sorties des fonctions d'un fichier source, par exemple net/socket.c
dans le noyau. Le point de sonde kernel.function
vous laisse exprimer cela facilement, puisque systemtap examine les informations de débogage du noyau pour lier le code objet au code source. Cela fonctionne comme un débogueur : si vous êtes en mesure de le nommer ou de le placer, vous serez en mesure de le sonder. Utilisez kernel.function("*@net/socket.c")
pour les entrées des fonctions, et kernel.function("*@net/socket.c").return
pour les sorties. Notez l'utilisation de caractères génériques dans la partie du nom de la fonction, et la partie subséquente @FILENAME
. Vous pouvez également placer des caractères génériques dans le nom du fichier et même ajouter deux points (:) et un numéro de ligne, si vous le désirez, dans le but de restreindre la recherche aussi précisément que cela. Étant donné que systemtap place une sonde indépendante dans chaque emplacement qui correspond à un point de sonde, quelques caractères génériques peuvent devenir des centaines ou des milliers de sondes, faites ainsi attention à ce que vous demandez.
Une fois que vous identifiez les points de sonde, le squelette du script systemtap apparaît. Le mot clé probe
introduit un point de sonde, ou une liste séparée par des virgules. Les accolades suivantes { et } incluent le gestionnaire pour tous les points de sonde listés.
Vous pouvez exécuter ce script tel quel, bien qu'avec des gestionnaires vides il n'y ait pas de sortie. Placer les deux lignes dans un nouveau fichier. Exécutez stap -v FILE
. Arrêtez-le quand vous voulez avec ^C
. (L'option -v
indique à systemtap d'imprimer des messages plus détaillés durant son traitement. Essayez l'option -h
pour voir plus d'options).
Puisque vous êtes intéressé par toutes les entrées et sorties des fonctions, une ligne devrait être imprimée pour chacune d'elle, avec le nom de la fonction. Pour rendre cette liste plus lisible, systemtap devrait indenter les lignes de façon à ce que des fonctions appelées par d'autres fonctions tracées soient imbriquées. Pour distinguer les processus exécutés simultanément les uns des autres, systemtap devrait également imprimer l'ID du processus dans la ligne.
Avant d'apprendre à configurer votre système, il est recommandé d'apprendre comment recueillir des informations essentielles sur celui-ci. Par exemple, vous devez être en mesure de déterminer la quantité de mémoire ou d'espace libre, la façon dont est partitionné votre disque dur et les processus en cours d'exécution. Ce chapitre vous explique comment recueillir ce type d'informations sur votre système Red Hat Enterprise Linux à l'aide de commandes et de quelques programmes simples.
La commande ps ax
affiche une liste des processus système en cours, y compris les processus appartenant à d'autres utilisateurs. Pour afficher également le propriétaire de ces processus, utilisez la commande ps aux
. Cette liste est statique ; il s'agit d'un instantané de ce qui était en cours d'exécution lorsque vous avez appelé la commande. Pour obtenir une liste des processus en cours mise à jour constamment, utilisez la commande top
décrite ci-dessous.
Les résultats de la commande ps
peuvent être longs. Pour les empêcher d'être trop importants, vous pouvez les restreindre grâce à la commande suivante :
ps aux | less
Vous pouvez utiliser la commande ps
combinée à la commande grep
pour savoir si un processus est en cours d'exécution. Par exemple, pour déterminer si Emacs est en cours d'exécution, utilisez la commande suivante :
ps ax | grep emacs
La commande top
affiche les processus en cours d'exécution et d'importantes informations sur ceux-ci, telles que l'utilisation de la mémoire et de l'unité centrale (CPU). La liste est interactive et en temps réel. Ci-dessous figure un exemple de liste produite par la commande top
:
top - 15:02:46 up 35 min, 4 users, load average: 0.17, 0.65, 1.00 Tasks: 110 total, 1 running, 107 sleeping, 0 stopped, 2 zombie Cpu(s): 41.1% us, 2.0% sy, 0.0% ni, 56.6% id, 0.0% wa, 0.3% hi, 0.0% si Mem: 775024k total, 772028k used, 2996k free, 68468k buffers Swap: 1048568k total, 176k used, 1048392k free, 441172k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 4624 root 15 0 40192 18m 7228 S 28.4 2.4 1:23.21 X 4926 mhideo 15 0 55564 33m 9784 S 13.5 4.4 0:25.96 gnome-terminal 6475 mhideo 16 0 3612 968 760 R 0.7 0.1 0:00.11 top 4920 mhideo 15 0 20872 10m 7808 S 0.3 1.4 0:01.61 wnck-applet 1 root 16 0 1732 548 472 S 0.0 0.1 0:00.23 init 2 root 34 19 0 0 0 S 0.0 0.0 0:00.00 ksoftirqd/0 3 root 5 -10 0 0 0 S 0.0 0.0 0:00.03 events/0 4 root 6 -10 0 0 0 S 0.0 0.0 0:00.02 khelper 5 root 5 -10 0 0 0 S 0.0 0.0 0:00.00 kacpid 29 root 5 -10 0 0 0 S 0.0 0.0 0:00.00 kblockd/0 47 root 16 0 0 0 0 S 0.0 0.0 0:01.74 pdflush 50 root 11 -10 0 0 0 S 0.0 0.0 0:00.00 aio/0 30 root 15 0 0 0 0 S 0.0 0.0 0:00.05 khubd 49 root 16 0 0 0 0 S 0.0 0.0 0:01.44 kswapd0
Pour quitter top
, appuyez sur la touche q.
Tableau 29.1, « Commandes top
interactives » contient des commandes interactives utiles que vous pouvez utiliser avec top
. Pour de plus amples informations, consultez la page de manuel top
(1).
Commande | Description |
---|---|
Espace | Réactualise immédiatement l'affichage des données. |
h | Affiche un écran d'aide. |
k | Arrête un processus. Le système vous demande l'ID du processus et le signal à lui envoyer. |
n | Change le nombre de processus affichés. Le système vous demande de saisir le nombre désiré. |
u | Trie les processus par utilisateur. |
M | Trie les processus par utilisation de la mémoire. |
P | Trie les processus par utilisation de l'unité centrale. |
top
interactives
Si vous préférez une interface graphique pour la commande top
, vous pouvez utiliser l'outil Moniteur système GNOME. Pour lancer cette application à partir du bureau, sélectionnez Système => Administration => Moniteur Système ou saisissez gnome-system-monitor
à une invite du shell (comme XTerm). Sélectionnez ensuite l'onglet Liste des processus.
L'application Moniteur système GNOME vous permet de rechercher des processus dans la liste des processus en cours et d'afficher tous les processus, vos processus ou les processus actifs.
L'élément de menu Éditer permet :
D'arrêter un processus.
De continuer ou de lancer un processus.
De terminer un processsus.
De "tuer" un processus.
De changer la priorité d'un processus sélectionné.
D'éditer les préférences du Moniteur système. Celles-ci incluent le changement des secondes de l'intervalle pour actualiser la liste et la sélection des champs de processus à afficher dans la fenêtre Moniteur système.
L'élément de menu Affichage permet :
De visionner uniquement les processus actifs.
De visionner tous les processus.
De visionner mes processus.
De visionner les dépendances des processus.
De cacher un processus.
De visionner des processus cachés.
De visionner les cartes de la mémoire.
De visionner les fichiers ouverts par les processus sélectionnés.
Pour arrêter un processus, sélectionnez-le et cliquez sur Arrêter le processus. Vous pouvez également arrêter un processus en le sélectionnant et en cliquant Éditer sur votre menu et en sélectionnant Arrêter le processus.
Pour trier les informations d'une colonne spécifique, cliquez sur le nom de la colonne. Cela trie les informations selon la colonne sélectionnée en ordre ascendant. Cliquez à nouveau sur le nom de la colonne pour inverser l'ordre du tri ascendant vers descendant.
La commande free
affiche la quantité totale de mémoire physique et d'espace de pagination du système, de même que la quantité de mémoire utilisée, libre, partagée, tampon dans le noyau et mise en cache.
total used free shared buffers cached Mem: 645712 549720 95992 0 176248 224452 -/+ buffers/cache: 149020 496692 Swap: 1310712 0 1310712
La commande free -m
affiche les mêmes informations, mais en méga-octets, ce qui rend leur lecture plus facile.
total used free shared buffers cached Mem: 630 536 93 0 172 219 -/+ buffers/cache: 145 485 Swap: 1279 0 1279
Si vous préférez utiliser une interface graphique pour free
, vous pouvez utiliser l'outil Moniteur système GNOME. Pour lancer cette application à partir du bureau, sélectionnez Système => Administration => Moniteur système ou saisissez gnome-system-monitor
à une invite de shell (comme XTerm). Cliquez ensuite sur l'onglet Ressources.
La commande df
affiche l'utilisation de l'espace disque du système. Si vous entrez la commande df
à l'invite du shell, le résultat ressemblera à l'extrait suivant :
Filesystem 1K-blocks Used Available Use% Mounted on /dev/mapper/VolGroup00-LogVol00 11675568 6272120 4810348 57% / /dev/sda1 100691 9281 86211 10% /boot none 322856 0 322856 0% /dev/shm
Par défaut, cet utilitaire affiche la taille de partitions en blocs de 1 kilo-octets et la quantité d'espace disque libre utilisé, en kilo-octets. Pour visualiser les informations en méga-octets et giga-octets, utilisez la commande df -h
. L'argument -h
signifie format lisible. La sortie ressemble alors plus ou moins à l'extrait suivant :
Filesystem Size Used Avail Use% Mounted on /dev/mapper/VolGroup00-LogVol00 12G 6.0G 4.6G 57% / /dev/sda1 99M 9.1M 85M 10% /boot none 316M 0 316M 0% /dev/shm
Dans la liste de partitions montées, il y a une entrée pour /dev/shm
. Cette entrée représente le système de fichiers de mémoire virtuelle du système.
La commande du
affiche une estimation de la quantité d'espace utilisé par des fichiers dans un répertoire. Si vous saisissez du
à l'invite du shell, l'utilisation d'espace disque de chaque sous-répertoire sera également affichée dans une liste. De plus, le total du répertoire courant et de ses sous-répertoires est indiqué sur la dernière ligne de la liste. Si vous ne voulez pas voir les totaux de tous les sous-répertoires, utilisez la commande du -hs
pour ne visionner que le grand total du répertoire et ce, dans un format lisible. Utilisez la commande du --help
pour afficher d'autres options.
Pour visionner les partitions du système et l'utilisation de l'espace du disque dans une interface graphique, utilisez Moniteur système Gnome en cliquant Système => Administration => Moniteur système ou saisissez gnome-system-monitor
à une invite de shell (comme XTerm). Sélectionnez l'onglet Systèmes de fichiers pour visionner les partitions système. La figure ci-dessous illustre l'onglet Systèmes de fichiers.
L'onglet Systèmes de fichiers du gnome-system-monitor
Si vous avez des problèmes lors de la configuration de votre matériel ou vous désirez simplement savoir quel matériel se trouve sur votre système, utilisez l'application Navigateur matériel pour afficher le matériel qui peut être sondé. Pour démarrer le programme à partir du bureau, sélectionnez Système (menu principal sur le panneau) => Administration => Matériel ou saisissez hwbrowser
à une invite du shell. Comme le montre la Figure 29.4, « Navigateur matériel », le programme affiche les lecteurs de CD-ROM, de disquettes, les disques durs et leurs partitions, les périphériques réseau, les dispositifs de pointage, les périphériques système et les cartes vidéo. Pour afficher des informations sur l'un de ces éléments, cliquez sur le nom de catégorie dans le menu de gauche.
L'application Gestionnaire de périphériques peut être utilisée pour afficher le matériel de votre système. Cette application est lancée en sélectionnant Système (menu principal sur le panneau) => Administration => Matériel comme pour le Navigateur matériel. Pour lancer l'application à partir du terminal, saisissez hal-device-manager
. Selon vos préférences d'installation, le menu graphique ci-dessus peut lancer votre application ou, cliquez sur le Navigateur matériel. La figure ci-dessous illustrate la fenêtre du Gestionnaire de périphériques.
La commande lspci
permet d'afficher tous les périphériques PCI. Utilisez la commande lspci -v
pour obtenir plus d'informations, ou lspci -vv
pour des résutlats encore plus détaillés.
Par exemple, lspci
peut être utilisé pour déterminer le fabricant, le modèle et la taille de la mémoire d'une carte vidéo du système :
00:00.0 Host bridge: ServerWorks CNB20LE Host Bridge (rev 06) 00:00.1 Host bridge: ServerWorks CNB20LE Host Bridge (rev 06) 00:01.0 VGA compatible controller: S3 Inc. Savage 4 (rev 04) 00:02.0 Ethernet controller: Intel Corp. 82557/8/9 [Ethernet Pro 100] (rev 08) 00:0f.0 ISA bridge: ServerWorks OSB4 South Bridge (rev 50) 00:0f.1 IDE interface: ServerWorks OSB4 IDE Controller 00:0f.2 USB Controller: ServerWorks OSB4/CSB5 OHCI USB Controller (rev 04) 01:03.0 SCSI storage controller: Adaptec AIC-7892P U160/m (rev 02) 01:05.0 RAID bus controller: IBM ServeRAID Controller
lspci
permet également d'en savoir plus sur la carte réseau de votre système si vous n'en connaissez pas le fabricant ou le numéro de modèle.
Pour en savoir plus sur la collecte d'informations du système, consultez les sources d'informations suivantes.
ps --help
— Affiche une liste d'options qui peuvent être utilisées avec ps
.
Page de manuel relative à top
— Saisissez man top
pour en savoir plus sur top
et ses nombreuses options.
Page de manuel relative à free
— Saisissez man free
pour en savoir plus sur free
et ses nombreuses options.
Page de manuel relative à df
— Saisissez man df
pour en savoir plus sur la commande df
et ses nombreuses options.
Page de manuel relative à du
— Saisissez man du
pour en savoir plus sur la commande du
et ses nombreuses options.
Page de manuel relative à lspci
— Saisissez man lspci
pour en savoir plus sur la commande lspci
et ses nombreuses options.
Répertoire /proc/
— Le contenu du répertoire /proc/
peut également être utilisé pour recueillir des informations système plus détaillées.
OProfile est un outil de contrôle de performance sur tout le système. Il utilise le matériel de contrôle de performance sur le processeur pour récupérer des informations sur le noyau et les exécutables du système, comme lorsqu'il s'agit de mémoire, le nombre de requêtes de cache L2 et le nombre d'interruptions matérielles reçues. Sur un système Red Hat Enterprise Linux, le paquetage RPM oprofile
doit être installé afin d'utiliser cet outil.
De nombreux processeurs incluent du matériel de contrôle dédié à la performance. Ce matériel permet de détecter lorsque certains évènements se produisent (comme les données demandées ne se trouvant pas en cache). Le matériel prend généralement la forme d'un ou plusieurs compteurs qui sont incrémentés chaque fois qu'un évènement se produit. Lorsque la valeur du compteur "redémarre", une interruption est générée, permettant de contrôler la quantité de détails (et ainsi, de coûts) produits par le contrôle de performance.
OProfile utilise ce matériel (ou un substitut basé sur une horloge dans le cas où le matériel de contrôle de performance n'est pas présent) pour recueillir des échantillons de données associées aux performances chaque fois qu'un compteur produit une interruption. Ces échantillons sont écrits périodiquement sur disque ; à une date ultérieure, les données contenues dans ces échantillons peuvent être utilisées pour produire des rapports sur la performance au niveau du système ou des applications.
OProfile est un outil utile, mais faites attention à certaines restrictions lors de son utilisation :
Utilisation de bibliothèques partagées — Les exemples de code dans les bibliothèques partagées ne sont pas attribués à des applications particulières à moins que l'option --separate=library
ne soit utilisée.
Les échantillons de contrôle de performance sont inexacts — Lorsqu'un gestionnaire de contrôle de performance déclenche un échantillon, la gestion d'interruptions n'est pas précise comme l'exception d'une division par zéro. Vu que l'exécution d'instructions par le processeur ne fonctionne pas, l'échantillon peut être enregistré sur une instruction voisine.
opreport
n'associe pas correctement des échantillons pour les fonctions inline — opreport
utilise un simple mécanisme de gamme d'adresses afin de déterminer dans quelle fonction se trouve une adresse. Les échantillons de fonctions inline ne sont pas attribués à la fonction inline, mais plutôt à la fonction dans laquelle la fonction inline a été insérée.
OProfile accumule les données de plusieurs exécutions — OProfile est un profileur système et s'attend à ce que les processus démarrent et s'arrêtent de nombreuses fois. Ainsi, les échantillons de multiples exécutions s'accumulent. Utilisez la commande opcontrol --reset
pour supprimer les échantillons d'exécutions précédentes.
Problèmes de performance qui ne sont pas limités au CPU — OProfile trouve en général des problèmes de processus qui sont liés au CPU. OProfile n'identifient pas les processus qui sont endormis vu qu'ils attendent que des verroux ou d'autres évènements se produisent (par exemple, un périphérique d'E/S qui doit terminer une opération).
Tableau 30.1, « Commandes de OProfile » offre un bref aperçu des outils fournis avec le paquetage oprofile
.
Commande | Description |
---|---|
ophelp
|
Affiche les évènements disponibles pour le processeur du système avec une courte description pour chacun. |
opimport
|
Convertit des fichiers de base de données échantillons de format binaire étranger en format natif au système. Utilisez cette option uniquement lors de l'analyse d'une base de données échantillon d'une architecture différente. |
opannotate
|
Crée une source annotée pour un exécutable si l'application a été compilée avec des symboles de débogage. Reportez-vous à la Section 30.5.4, « Utiliser opannotate » pour de plus amples informations.
|
opcontrol
|
Configure les données recueillies. Reportez-vous à la Section 30.2, « Configuration de OProfile » pour des informations plus détaillées. |
opreport
|
Récupère les données du profil. Reportez-vous à la Section 30.5.1, « Utiliser |
oprofiled
|
Fonctionne comme un démon pour écrire périodiquement des données échantillon sur le disque. |
Avant de pouvoir l'exécuter, OProfile doit être configuré. Il est requis, au minimum, de sélectionner le contrôle de noyau (ou de ne pas le sélectionner). Les sections suivantes décrivent comment utiliser l'utilitaire opcontrol
pour configurer OProfile. Lorsque les commandes opcontrol
sont exécutées, les options de configuration sont enregistrées dans le fichier /root/.oprofile/daemonrc
.
Tout d'abord, spécifiez si OProfile devrait contrôler le noyau. Cette option de configuration est la seule requise avant le lancement de OProfile. Toutes les autres sont facultatives.
Pour contrôler le noyau, exécutez la commande suivante en tant que super-utilisateur :
opcontrol --setup --vmlinux=/usr/lib/debug/lib/modules/`uname -r`/vmlinux
Le paquetage debuginfo
doit être installé (qui contient le noyau décompressé) afin de contrôler le noyau.
Pour configurer OProfile de façon à ce qu'il ne contrôle pas le noyau, exécutez la commande suivante en tant que super-utilisateur :
opcontrol --setup --no-vmlinux
Cette commande charge également le module de noyau oprofile
s'il n'est pas déjà chargé, et crée le répertoire /dev/oprofile/
s'il n'existe pas déjà. Reportez-vous à la Section 30.6, « Comprendre le /dev/oprofile/
» afin d'obtenir de plus amples informations sur ce répertoire.
Même si OProfile est configuré de façon à ne pas créer le profil du noyau, le noyau SMP doit quand même être en cours d'exécution afin que le module oprofile
puisse être chargé.
Le fait de définir si les échantillons devraient être recueillis au sein du noyau ne change que le type de données à recueillir et non, la façon ou l'emplacement où les données recueillies sont stockées. Pour produire des fichiers d'échantillons différents pour le noyau ou les bibliothèques d'applications, reportez-vous à la Section 30.2.3, « Séparation des profils du noyau et de l'espace utilisateur ».
La plupart des processeurs contiennent des compteurs, qui sont utilisés par OProfile pour contrôler des évènements spécifiques. Comme l'illustre le Tableau 30.2, « Processeurs et compteurs OProfile », le nombre de compteurs disponibles dépend du processeur.
Processeur |
cpu_type
|
Nombre de compteurs |
---|---|---|
Pentium Pro | i386/ppro | 2 |
Pentium II | i386/pii | 2 |
Pentium III | i386/piii | 2 |
Pentium 4 (non-hyper-threaded) | i386/p4 | 8 |
Pentium 4 (hyper-threaded) | i386/p4-ht | 4 |
Athlon | i386/athlon | 4 |
AMD64 | x86-64/hammer | 4 |
Itanium | ia64/itanium | 4 |
Itanium 2 | ia64/itanium2 | 4 |
TIMER_INT | timer | 1 |
IBM eServer iSeries et pSeries | timer | 1 |
ppc64/power4 | 8 | |
ppc64/power5 | 6 | |
ppc64/970 | 8 | |
IBM eServer S/390 et S/390x | timer | 1 |
IBM eServer zSeries | timer | 1 |
Utilisez le Tableau 30.2, « Processeurs et compteurs OProfile » pour vérifier que le bon type de processeur a été détecté et pour déterminer le nombre d'évènements pouvant être contrôlés simultanément. timer
est utilisé comme type de processeur si le processeur n'a pas de matériel de contrôle de performance pris en charge.
Si timer
est utilisé, des évènements ne peuvent pas être définis pour un autre processeur car le matériel ne prend pas en charge les compteurs de performance matérielle. L'interruption d'horloge est utilisée à la place pour le profilage.
Si timer
n'est pas utilisé comme type de processeur, les évènements contrôlés peuvent être changés et le compteur 0 pour le processeur est réglé sur un évènement basé sur le temps, par défaut. S'il existe plusieurs compteurs sur le processeur, les compteurs autres que le compteur 0 ne sont pas configurés sur un évènement, par défaut. Les évènements contrôlés par défaut sont représentés dans le Tableau 30.3, « Évènements par défaut ».
Processeur | Évènements par défaut pour le compteur | Description |
---|---|---|
Pentium Pro, Pentium II, Pentium III, Athlon, AMD64 | CPU_CLK_UNHALTED | L'horloge du processeur n'est pas arrêtée. |
Pentium 4 (HT et non-HT) | GLOBAL_POWER_EVENTS | La période de temps pendant laquelle le processeur n'est pas arrêté. |
Itanium 2 | CPU_CYCLES | Cycles du CPU |
TIMER_INT | (aucun) | Échantillon pour chaque arrêt d'horloge. |
ppc64/power4 | CYCLES | Cycles du processeur |
ppc64/power5 | CYCLES | Cycles du processeur |
ppc64/970 | CYCLES | Cycles du processeur |
Le nombre d'évènements qui peuvent être contrôlés à un moment donné est déterminé par le nombre de compteurs pour le processeur. Toutefois, ceci n'est pas une corrélation de un à un ; sur certains processeurs, des évènements doivent être mappés à des compteurs donnés. Afin de déterminer le nombre de compteurs disponibles, exécutez la commande suivante :
ls -d /dev/oprofile/[0-9]*
Les évènements disponibles varient selon le type de processeur. Afin de les déterminer pour le profilage, exécutez la commande suivante en tant que super-utilisateur (la liste est spécifique au type de processeur du système) :
ophelp
Les évènements pour chaque compteur peuvent être configurés via la ligne de commande ou avec une interface graphique. Pour plus d'informations sur l'interface graphique, consultez la Section 30.8, « Interface graphique ». Si le compteur ne peut pas être défini sur un évènement spécifique, un message d'erreur apparaît.
Pour définir un évènement pour chaque compteur configurable via la ligne de commande, utilisez opcontrol
:
opcontrol --event=<event-name>
:<sample-rate>
Remplacez <event-name>
par le nom exact de l'évènement depuis ophelp
, et remplacez <sample-rate>
avec le nombre d'évènements entre les échantillons.
Par défaut, un ensemble d'évènements basés sur le temps est sélectionné. Il crée un échantillon tous les 100,000 cycles horloge par processeur. Si l'interruption d'horloge est utilisée, l'horloge est réglée sur le taux jiffy quelqu'il soit et l'utilisateur ne peut pas le modifier. Si le cpu_type
n'est pas timer
, chaque évènement peut avoir un taux d'échantillonnage défini. Le taux d'échantillonnage est le nombre d'évènements entre chaque instantané d'échantillons.
Lors de la définition d'un évènement pour le compteur, un taux d'échantillonnage peut également être spécifié :
opcontrol --event=<event-name>
:<sample-rate>
Remplacez <sample-rate>
par le nombre d'évènements attendu avant de lancer un autre échantillonnage. Plus le nombre est petit, plus les échantillons seront fréquents. Pour les évènements qui ne se produisent pas fréquemment, un nombre plus bas peut être nécessaire pour capturer les évènements.
Soyez extrêmement vigilant lors de la définition de taux d'échantillonnage. Si vous effectuez cette procédure trop fréquemment, le système peut devenir surchargé. Ainsi, le système peut apparaître gelé ou peut être réellement gelé.
Certains évènements de contrôle de performance d'utilisateur peuvent également exiger des masques d'unité pour définir l'évènement plus précisément.
Les masques d'unité pour chaque évènement sont énumérés avec la commande ophelp
. Les valeurs de chaque masque d'unité sont listées en format hexadécimal. Pour spécifier plusieurs masques d'unité, ces valeurs hexadécimales doivent être associées à l'aide d'une opération or (OU) de manipulation de bits.
opcontrol --event=<event-name>
:<sample-rate>
:<unit-mask>
Par défaut, les informations du mode noyau et du mode utilisateur sont rassemblées pour chaque évènement. Pour configurer OProfile afin qu'il ne compte pas les évènements dans le mode noyau pour un compteur donné, exécutez la commande suivante :
opcontrol --event=<event-name>
:<sample-rate>
:<unit-mask>
:0
Exécutez la commande suivante pour recommencer le profilage du mode noyau pour le compteur :
opcontrol --event=<event-name>
:<sample-rate>
:<unit-mask>
:1
Pour configurer OProfile afin qu'il ne compte pas les évènements en mode utilisateur pour un compteur donné, exécutez la commande suivante :
opcontrol --event=<event-name>
:<sample-rate>
:<unit-mask>
:<kernel>
:0
Exécutez la commande suivante pour recommencer le profilage du mode utilisateur pour le compteur :
opcontrol --event=<event-name>
:<sample-rate>
:<unit-mask>
:<kernel>
:1
Lorsque le démon de OProfile écrit les données sur des fichiers échantillons, il peut séparer les données de profil du noyau et des bibliothèques en fichiers d'échantillons séparés. Pour configurer la façon dont le démon écrit sur les fichiers échantillons, exécutez la commande suivante en tant que super-utilisateur :
opcontrol --separate=<choice>
<choice>
peut avoir l'une des valeurs suivantes :
none
(aucun)— Ne pas séparer les profils (par défaut).
library
— Générer des profils par application pour les bibliothèques.
kernel
— Générer des profils par application pour le noyau et ses modules.
all
— Générer des profils par application pour les bibliothèques et pour le noyau et ses modules.
Si --separate=library
est utilisée, le nom du fichier échantillon inclut le nom de l'exécutable ainsi que le nom de la bibliothèque.
Ces changements de configuration prendront effet quand oprofile
sera redémarré.
Pour commencer à contrôler le système avec OProfile, exécutez la commande suivante en tant que super-utilisateur :
opcontrol --start
Une sortie similaire à l'exemple suivant sera affichée :
Using log file /var/lib/oprofile/oprofiled.log Daemon started. Profiler running.
Les paramètres dans /root/.oprofile/daemonrc
sont utilisés.
Le démon OProfile, oprofiled
, est lancé ; il écrit périodiquement les données échantillons dans le répertoire /var/lib/oprofile/samples/
. Le fichier journal du démon se trouve dans /var/lib/oprofile/oprofiled.log
.
Pour arrêter le profileur, exécutez la commande suivante en tant que super-utilisateur :
opcontrol --shutdown
Il est parfois utile de sauvegarder des échantillons à un moment donné. Par exemple, lors du profilage d'un exécutable, il peut s'avérer utile de rassembler différents échantillons basés sur différents ensembles de données d'entrée. Si le nombre d'évènements à contrôler dépasse le nombre de compteurs disponibles pour le processeur, plusieurs exécutions de OProfile peuvent être utilisées pour recueillir des données, tout en sauvegardant les données échantillons sur différents fichiers à chaque fois.
Pour enregistrer l'ensemble courant de fichiers d'échantillons, exécutez la commande suivante, en remplaçant <name>
par un nom descriptif unique pour la session courante.
opcontrol --save=<name>
Le répertoire /var/lib/oprofile/samples/
est créé et les fichiers d'échantillons courants y sont copiés.
name
/
Périodiquement, le démon OProfile, oprofiled
, recueille les échantillons et les écrit dans le répertoire /var/lib/oprofile/samples/
. Avant de les lire, assurez-vous que toutes les données sont bien écrites dans ce répertoire en exécutant la commande suivante en tant que super-utilisateur :
opcontrol --dump
Chaque nom de fichier échantillon est basé sur le nom de l'exécutable. Par exemple, les échantillons pour l'évènement par défaut sur un processeur Pentium III pour /bin/bash
devient :
\{root\}/bin/bash/\{dep\}/\{root\}/bin/bash/CPU_CLK_UNHALTED.100000
Les outils suivants sont disponibles pour profiler les données d'échantillons une fois recueillies :
opreport
opannotate
Utilisez ces outils ainsi que les binaires profilés pour générer des rapports qui peuvent être analysés plus en détails.
L'exécutable en cours de profilage doit être utilisé avec ces outils pour analyser les données. S'il doit changer après que les données soient recueillies, sauvegardez l'exécutable utilisé pour créer les échantillons ainsi que les fichiers d'échantillons. Veuillez noter que le fichier échantillon et le binaire doivent s'accorder. S'ils ne s'accordent pas une sauvegarde ne fonctionnera pas. oparchive
peut être utilisé pour adresser ce problème.
Les échantillons pour chaque exécutable sont écrits sur un seul fichier d'échantillons. Les échantillons de chaque bibliothèque liée dynamiquement sont également écrits sur un seul fichier d'échantillons. Lorsque OProfile est en cours d'exécution, si l'exécutable surveillé change et si un fichier d'échantillons existe pour l'exécutable, le fichier d'échantillons existant sera automatiquement supprimé. Ainsi, si le fichier d'échantillons existant est nécessaire, il doit être sauvegardé avec l'exécutable utilisé pour le créer avant que l'exécutable ne soit remplacé par une nouvelle version. Les outils d'analyse oprofile utilisent le fichier exécutable qui crée les échantillons durant l'analyse. Si l'exécutable change, les outils d'analyse ne seront pas en mesure d'analyser les échantillons associés. Reportez-vous à la Section 30.4, « Sauvegarde de données » afin d'obtenir davantage d'informations sur la manière de sauvegarder le fichier d'échantillons.
L'outil opreport
offre un aperçu sur tous les exécutables en cours de profilage.
Ci-dessous figure l'exemple d'une sortie :
Profiling through timer interrupt TIMER:0| samples| %| ------------------ 25926 97.5212 no-vmlinux 359 1.3504 pi 65 0.2445 Xorg 62 0.2332 libvte.so.4.4.0 56 0.2106 libc-2.3.4.so 34 0.1279 libglib-2.0.so.0.400.7 19 0.0715 libXft.so.2.1.2 17 0.0639 bash 8 0.0301 ld-2.3.4.so 8 0.0301 libgdk-x11-2.0.so.0.400.13 6 0.0226 libgobject-2.0.so.0.400.7 5 0.0188 oprofiled 4 0.0150 libpthread-2.3.4.so 4 0.0150 libgtk-x11-2.0.so.0.400.13 3 0.0113 libXrender.so.1.2.2 3 0.0113 du 1 0.0038 libcrypto.so.0.9.7a 1 0.0038 libpam.so.0.77 1 0.0038 libtermcap.so.2.0.8 1 0.0038 libX11.so.6.2 1 0.0038 libgthread-2.0.so.0.400.7 1 0.0038 libwnck-1.so.4.9.0
Chaque exécutable est répertorié sur sa propre ligne. La première colonne représente le nombre d'échantillons enregistrés pour l'exécutable. La seconde colonne représente le pourcentage d'échantillons relatif au nombre total d'échantillons. La troisième colonne représente le nom de l'exécutable.
Consultez la page de manuel relative à opreport
afin d'obtenir une liste de toutes les options de ligne de commande disponibles, comme l'option -r
utilisée pour trier la sortie de l'exécutable avec le nombre d'échantillons le plus petit à celui avec le nombre d'échantillons le plus grand.
Pour récupérer des informations plus détaillées sur un exécutable donné, utilisez opreport
:
opreport <mode>
<executable>
<executable>
doit être le chemin complet de l'exécutable à analyser. <mode>
doit avoir l'une des valeurs suivantes :
-l
Affiche les données d'échantillons par symbole. Par exemple, l'exemple suivant fait partie de la sortie obtenue en exécutant la commande opreport -l /lib/tls/libc-
:
<version>
.so
samples % symbol name 12 21.4286 __gconv_transform_utf8_internal 5 8.9286 _int_malloc 4 7.1429 malloc 3 5.3571 __i686.get_pc_thunk.bx 3 5.3571 _dl_mcount_wrapper_check 3 5.3571 mbrtowc 3 5.3571 memcpy 2 3.5714 _int_realloc 2 3.5714 _nl_intern_locale_data 2 3.5714 free 2 3.5714 strcmp 1 1.7857 __ctype_get_mb_cur_max 1 1.7857 __unregister_atfork 1 1.7857 __write_nocancel 1 1.7857 _dl_addr 1 1.7857 _int_free 1 1.7857 _itoa_word 1 1.7857 calc_eclosure_iter 1 1.7857 fopen@@GLIBC_2.1 1 1.7857 getpid 1 1.7857 memmove 1 1.7857 msort_with_tmp 1 1.7857 strcpy 1 1.7857 strlen 1 1.7857 vfprintf 1 1.7857 write
La première colonne représente représente le nombre d'échantillons pour le symbole, la seconde colonne représente le pourcentage d'échantillons pour ce symbole relatif aux échantillons dans l'ensemble pour l'exécutable, et la troisième colonne est le nom du symbole.
Pour trier la sortie du nombre d'échantillons le plus grand au plus petit (ordre inverse), utilisez -r
avec l'option -l
.
-i <symbol-name>
Affiche les données d'échantillons spécifiques à un nom de symbole. Par exemple, la sortie suivante est obtenue en exécutant la commande opreport -l -i __gconv_transform_utf8_internal /lib/tls/libc-
:
<version>
.so
samples % symbol name 12 100.000 __gconv_transform_utf8_internal
La première ligne est un résumé de la combinaison symbole/exécutable.
La première colonne représente le nombre d'échantillons pour le symbole de mémoire. La seconde colonne représente le pourcentage d'échantillons pour l'adresse de mémoire relative au nombre total d'échantillons pour le symbole. La troisième colonne représente le nom du symbole.
-d
Affiche les données d'échantillons par symbole avec plus de détails qu'avec -l
. Par exemple, la sortie suivante est obtenue en exécutant la commande opreport -l -d __gconv_transform_utf8_internal /lib/tls/libc-
:
<version>
.so
vma samples % symbol name 00a98640 12 100.000 __gconv_transform_utf8_internal 00a98640 1 8.3333 00a9868c 2 16.6667 00a9869a 1 8.3333 00a986c1 1 8.3333 00a98720 1 8.3333 00a98749 1 8.3333 00a98753 1 8.3333 00a98789 1 8.3333 00a98864 1 8.3333 00a98869 1 8.3333 00a98b08 1 8.3333
Les données sont les mêmes qu'avec l'option -l
sauf que chaque adresse de mémoire virtuelle utilisée est affichée pour chaque symbole. Pour chacune d'entre elles, le nombre d'échantillons et le pourcentage d'échantillons relatif au nombre d'échantillons pour le symbole sont affichés.
-x
<symbol-name>
Exclut la liste de symboles séparés par des virgules de la sortie.
session
:<name>
Spécifie le chemin complet à la session ou à un répertoire associé au répertoire /var/lib/oprofile/samples/
.
OProfile collecte des données sur tout le système pour le code noyau et espace utilisateur en exécution sur votre ordinateur. Cependant, une fois un module chargé dans le noyau, les informations sur l'origine du module du noyau sont perdues. Le module pourra être issu du fichier initrd au démarrage, le répertoire avec les différents modules du noyau, ou un module du noyau créé localement. Par conséquent, quand OProfile enregistre des échantillons pour un module, il liste uniquement les échantillons pour les modules d'un exécutable dans le répertoire super-utilisateur, mais il est peu probable que ce soit l'emplacement avec le code actuel pour le module. Il vous faudra suivre certaines étapes afin de vous assurer que les outils d'analyse obtiennent bien l'exécutable.
Par exemple sur un ordinateur AMD64, l'échantillon est configuré pour enregistrer "Les accès au cache de données" et "Les accès manqués au cache de données" et en supposant que vous désirez voir les données pour le module ext3 :
$ opreport /ext3
CPU: AMD64 processors, speed 797.948 MHz (estimated)
Counted DATA_CACHE_ACCESSES events (Data cache accesses) with a unit mask of 0x00 (No unit mask) count 500000
Counted DATA_CACHE_MISSES events (Data cache misses) with a unit mask of 0x00 (No unit mask) count 500000
DATA_CACHE_ACC...|DATA_CACHE_MIS...|
samples| %| samples| %|
------------------------------------
148721 100.000 1493 100.000 ext3
Pour obtenir une vue plus détaillées des actions du module, il vous faudra avoir le module unstripped (par ex. installé à partir d'une installation personnalisée) ou avoir le RPM debuginfo installé pour le noyau.
Trouvez quel est le noyau en exécution, "uname -a", obtenez les informations debuginfo rpm appropriées, et installez sur votre ordinateur.
Ensuite créez un lien symbolique de façon à ce que oprofile trouve le code pour le module à l'emplacement correct :
# ln -s /lib/modules/`uname -r`/kernel/fs/ext3/ext3.ko /ext3
. Ensuite les informations peuvent être obtenues avec :
# opreport image:/ext3 -l|more
warning: could not check that the binary file /ext3 has not been modified since the profile was taken. Results may be inaccurate.
CPU: AMD64 processors, speed 797.948 MHz (estimated)
Counted DATA_CACHE_ACCESSES events (Data cache accesses) with a unit mask of 0x00 (No unit mask) count 500000
Counted DATA_CACHE_MISSES events (Data cache misses) with a unit mask of 0x00 (No unit mask) count 500000
samples % samples % symbol name
16728 11.2479 7 0.4689 ext3_group_sparse
16454 11.0637 4 0.2679 ext3_count_free_blocks
14583 9.8056 51 3.4159 ext3_fill_super
8281 5.5681 129 8.6403 ext3_ioctl
7810 5.2514 62 4.1527 ext3_write_info
7286 4.8991 67 4.4876 ext3_ordered_writepage
6509 4.3767 130 8.7073 ext3_new_inode
6378 4.2886 156 10.4488 ext3_new_block
5932 3.9887 87 5.8272 ext3_xattr_block_list
...
L'outil opannotate
essaie de faire correspondre les échantillons pour certaines instructions aux lignes correspondantes dans le code source. Les fichiers qui en résultent devraient avoir les échantillons pour les lignes sur la gauche. Un commentaire est également ajouté au début de chaque fonction affichant tous les échantillons pour la fonction.
Afin que cet utilitaire fonctionne, l'exécutable doit être compilé avec l'option -g
de GCC. Par défaut, les paquetages de Red Hat Enterprise Linux ne sont pas compilés avec cette option.
La syntaxe générale pour opannotate
est comme suit :
opannotate --search-dirs <src-dir>
--source <executable>
Le répertoire contenant le code source et l'exécutable à analyser doivent être spécifiés. Consultez la page de manuel relative à opannotate
afin d'obtenir une liste d'options de ligne de commande supplémentaires.
Le répertoire /dev/oprofile/
contient le système de fichiers pour OProfile. Utilisez la commande cat
pour afficher les valeurs des fichiers virtuels dans ce système de fichiers. Par exemple, la commande suivante affiche le type de processeur détecté par OProfile :
cat /dev/oprofile/cpu_type
Un répertoire existe dans /dev/oprofile/
pour chaque compteur. Par exemple, s'il existe deux compteurs, les répertoires /dev/oprofile/0/
et dev/oprofile/1/
existent.
Chaque répertoire pour un compteur contient les fichiers suivants :
count
— L'intervalle entre échantillons.
enabled
— Si la valeur est 0, le compteur est désactivé et aucun échantillon n'est recueilli. Si la valeur est 1, le compteur est activé et les échantillons sont recueillis.
event
— L'évènement à contrôler.
kernel
— Si la valeur est 0, les échantillons ne sont pas recueillis pour cet évènement de compteur lorsque le processeur est en espace noyau. Si la valeur est 1, les échantillons sont recueillis même si le processeur est en espace noyau.
unit_mask
— définit les masques d'unité activés pour le compteur.
user
— Si la valeur est 0, les échantillons ne sont pas recueillis pour l'évènement de compteur lorsque le processeur est en espace utilisateur. Si la valeur est 1, les échantillons sont recueillis même si le processeur est en espace utilisateur.
Les valeurs de ces fichiers peuvent être récupérées grâce à la commande cat
. Par exemple :
cat /dev/oprofile/0/count
Alors que OProfile peut être utilisé par des développeurs pour analyser les performances d'applications, il peut également être utilisé par les administrateurs système pour effectuer des analyses de systèmes. Par exemple :
Déterminer les applications et les services les plus utilisés sur un système — opreport
peut être utilisé pour déterminer le temps de processeur qu'une application ou un service peut utiliser. Si le système est utilisé pour plusieurs services, mais que ses performances sont décevantes, les services qui utilisent le plus de temps de processeur peuvent être déplacés sur des systèmes dédiés.
Déterminer l'utilisation de processeur — L'évènement CPU_CLK_UNHALTED
peut être contrôlé afin de déterminer la charge du processeur sur une période de temps donnée. Ces données peuvent alors être utilisées pour déterminer si des processeurs supplémentaires ou un processeur plus rapide pourraient améliorer les performances du système.
Certaines préférences de OProfile peuvent être définies avec une interface graphique. Pour la lancer, exécutez la commande oprof_start
en tant que super-utilisateur à l'invite d'un shell. Pour utiliser l'interface graphique, il vous faudra avoir les paquetages oprofile-gui
installés.
Après avoir changé les options, vous pouvez les enregistrer en cliquant sur le bouton Enregistrer et quitter. Ces préférences sont écrites dans /root/.oprofile/daemonrc
, puis l'application se ferme. Le fait de quitter l'application n'arrête pas l'échantillonnage de OProfile.
Sur l'onglet Installation, pour définir des évènements pour les compteurs de processeur comme la Section 30.2.2, « Configuration d'évènements à contrôler » l'explique, sélectionnez le compteur du menu déroulant et sélectionnez l'évènement de la liste. Une brève description de l'évènement apparaît dans le champ de texte au-dessous de la liste. Seuls les évènements disponibles pour le compteur donné et l'architecture spécifique sont affichés. L'interface affiche également si le profileur est en cours d'exécution de même que quelques brèves statistiques.
Sur le côté droit de l'onglet, sélectionnez l'option Profiler le noyau pour compter les évènements en mode noyau pour l'évènement sélectionné, comme l'explique, la Section 30.2.3, « Séparation des profils du noyau et de l'espace utilisateur ». Si cette option n'est pas sélectionnée, aucun échantillon n'est collecté pour le noyau.
Sélectionnez l'option Profiler les binaires utilisateur pour compter les évènements en mode utilisateur pour l'évènement sélectionné, comme la Section 30.2.3, « Séparation des profils du noyau et de l'espace utilisateur » l'explique. Si cette option n'est pas sélectionnée, aucun échantillon n'est collecté pour les applications utilisateur.
Utilisez le champ de texte Compter pour définir le taux d'échantillonnage pour l'évènement sélectionné comme la Section 30.2.2.1, « Taux d'échantillonnage » l'explique.
Si des masques d'unité sont disponibles pour les évènements sélectionnés, comme la Section 30.2.2.2, « Masques d'unité » l'explique, ils sont affichés dans la zone masques d'unité sur le côté droit de l'onglet Installation.Sélectionnez la case à côté du masque d'unité afin de l'activer pour cet évènement.
Sur l'onglet Configuration, pour profiler le noyau, entrez le nom et l'emplacement du fichier vmlinux
à contrôler par le noyau dans le champ de texte fichier image du noyau. Pour configurer OProfile de façon à ce qu'il ne contrôle pas le noyau, sélectionnez aucune image du noyau.
Si l'option Verbose est sélectionnée, le journal du démon oprofiled
inclut davantage d'informations.
Si l'option Fichiers d'échantillons du noyau par application est sélectionnée, OProfile génère des profils par application pour le noyau et ses modules comme l'explique la Section 30.2.3, « Séparation des profils du noyau et de l'espace utilisateur ». Ceci est l'équivalent de la commande opcontrol --separate=kernel
.Si l'option Fichiers d'échantillons de bibliothèques partagées par application est sélectionnée, OProfile génère des profils par application pour les bibliothèques. Ceci est l'équivalent de la commande opcontrol --separate=library
.
Pour forcer les données à être écrites sur des fichiers d'échantillons comme l'explique la Section 30.5, « Analyse des données », cliquez sur le bouton Supprimer les données du profileur. Ceci est l'équivalent de la commande opcontrol --dump
.
Pour lancer OProfile depuis l'interface graphique, cliquez sur Lancer le profileur. Pour l'arrêter, cliquez sur Arrêter le profileur. Le fait de quitter l'application n'arrête pas l'échantillonnage de OProfile.
Ce chapitre ne met en évidence que OProfile, la manière de le configurer et de l'utiliser. Pour en savoir plus, reportez-vous aux ressources suivantes.
/usr/share/doc/oprofile-
— OProfile Manual
<version>
/oprofile.html
La page de manuel de oprofile
— Examine opcontrol
, opreport
, opannotate
, et ophelp
http://oprofile.sourceforge.net/ — Contient les dernières documentations, listes de diffusion, canaux IRC et bien plus encore.
Les administrateurs système peuvent en apprendre plus sur leurs noyaux et comment les personnaliser. Red Hat Enterprise Linux contient des outils de noyau pour aider les administrateurs système avec leurs personnalisations.
Table des matières
Le noyau Red Hat Enterprise Linux a été construit de façon personnalisée par l'équipe du noyau de Red Hat afin d'assurer son intégrité ainsi que sa compatibilité avec le matériel pris en charge. Avant que Red Hat ne publie un noyau, celui-ci doit subir toute une série de tests d'assurance qualité.
Les noyaux Red Hat Enterprise Linux sont empaquetés dans un format RPM afin qu'ils soient facile à mettre à niveau et à vérifier en utilisant l'Outil de gestion des paquetages, ou la commande yum
. L'Outil de gestion des paquetages interroge automatiquement les serveurs Red Hat Enterprise Linux et détermine quels paquetages doivent être mis à jour sur votre machine, y compris le noyau. Ce chapitre n'est utile qu'aux personnes qui exigent la mise à jour des paquetages de noyau, sans utiliser la commande yum
.
La construction d'un noyau personnalisé n'est pas supportée par l'équipe GSS de Red Hat ("Global Services Support"), par conséquent ce sujet n'est pas abordé dans ce manuel.
L'utilisation de yum
est vivement recommandée par Red Hat pour l'installation de noyaux mis à niveau.
Pour plus d'informations sur l'Outil de gestion des paquetages et yum
de Red Hat Network, consultez le Chapitre 4, Red Hat Network.
Red Hat Enterprise Linux contient les paquetages de noyau suivants (certains d'entre eux peuvent ne pas s'appliquer à votre architecture) :
kernel
— Contient le noyau pour les systèmes à multiples processeurs. Pour le système x86, seul les premiers 4Go de RAM sont utilisés. En tant que tels, les systèmes x86 avec plus de 4Go de RAM devraient utiliser le kernel-PAE
.
kernel-devel
— Contient les en-têtes de noyau et des makefiles suffisants pour construire des modules pour le paquetage kernel
.
kernel-PAE
(uniquement pour les systèmes i686) — Ce paquetage offre les options de configuration clé (en plus des options déjà activées pour le paquetage kernel
) :
Prise en charge pour une mémoire RAM supérieure à 4 Go (jusqu'à 64 Go pour x86).
PAE (extension de l'adresse physique, de l'anglais Physical Address Extension) ou pagination à 3 niveaux sur les processeurs x86 qui prennent en charge PAE.
Partage 4Go/4Go — 4 Go d'espace d'adressage virtuel pour le noyau et pratiquement 4 Go pour chaque processus utilisateur sur les systèmes x86.
kernel-PAE-devel
— Contient les en-têtes de noyau et les makefiles requis pour construire les modules pour le paquetage kernel-PAE
kernel-doc
— Contient les fichiers de documentation de la source du noyau. Différentes portions du noyau Linux et les pilotes de périphérique qui l'accompagnent sont documentés dans ces fichiers. L'installation de ce paquetage fournit une référence aux options qui peuvent être passées aux modules de noyau Linux au moment du chargement.
Par défaut ces fichiers sont placés dans le répertoire /usr/share/doc/kernel-doc-
.
<version>
/
kernel-headers
— Inclut les fichiers d'en-tête C qui spécifient une interface entre le noyau Linux et les bibliothèques espace utilisateur et les programmes. Les fichiers d'en-tête définissent les structures et les constantes nécessaires à la construction de la plupart des programmes standards.
kernel-xen
— Inclut une version du noyau Linux nécessaire à l'exécution de la Virtualisation.
kernel-xen-devel
— Contient des en-têtes de noyau et des makefiles nécessaires à la construction de modules contre le paquetage kernel-xen
.
Le paquetage kernel-source
a été supprimé et remplacé par un RPM qui ne peut être extrait que de Red Hat Network. Ce paquetage *.src.rpm
doit alors être reconstruit localement en utilisant la commande rpmbuild
. Pour davantage d'informations sur la façon d'obtenir et d'installer le paquetage de la source du noyau, consultez les dernières Notes de mise à jour (avec toutes les mises à jour) à http://www.redhat.com/docs/manuals/enterprise/RHEL-5-manual/index.html
Avant de procéder à la mise à niveau du noyau, vous devez prendre quelques mesures de précaution. Si votre système possède un lecteur de disquettes, vous devez tout d'abord vous assurer de bien avoir une disquette de démarrage opérationnelle pour votre système, au cas où un problème surviendrait. En effet, si le chargeur d'amorçage n'est pas correctement configuré pour démarrer le nouveau noyau, vous ne pourrez pas lancer votre système Red Hat Enterprise Linux à moins d'être en possession d'un support de démarrage opérationnel.
Pour créer un support de démarrage, connectez-vous en tant que super-utilisateur (ou root) et tapez la commande suivante /sbin/mkbootdisk `uname -r`
à une invite du shell :
Consultez la page de manuel mkbootdisk
pour plus d'options. Vous pouvez créer le support de démarragage via les périphériques CD-R, CD-RW, USB flash du moment que votre système BIOS le prend en charge.
Redémarrez votre ordinateur avec le support de démarrage afin de vous assurer qu'il fonctionne bien avant de poursuivre.
Pour déterminer les paquetages installés sur votre système, exécutez la commande rpm -qa | grep kernel
à une invite du shell :
La sortie résultante contient certains ou la totalité des paquetages suivants, en fonction de l'architecture du système (les numéros de version et de paquetages pourraient toutefois être différents) :
kernel-2.6.9-5.EL kernel-devel-2.6.9-5.EL kernel-utils-2.6.9-5.EL kernel-doc-2.6.9-5.EL kernel-smp-2.6.9-5.EL kernel-smp-devel-2.6.9-5.EL kernel-hugemem-devel-2.6.9-5.EL
À partir de cette sortie, déterminez les paquetages à télécharger pour la mise à niveau du noyau. Pour un système n'utilisant qu'un seul processeur, le seul paquetage kernel
est nécessaire. Reportez-vous à la Section 31.1, « Aperçu sur les paquetages du noyau » afin d'obtenir les descriptions des différents paquetages.
Dans le nom de fichier, chaque paquetage de noyau contient l'architecture pour laquelle il a été construit. Le format est le suivant : kernel-<variant>
-<version>
.<arch>
.rpm, où <variant>
est l'un des PAE
, xen
, et ainsi de suite. Remplacez <arch>
par l'un des éléments suivants :
x86_64
pour architectures AMD64 et Intel EM64T
ia64
pour l'architecture Intel®Itanium™
ppc64
pour l'architecture IBM®eServer™pSeries™
s390
pour l'architecture IBM®S/390®
s390x
pour l'architecture IBM®eServer™System z®
i686
pour les systèmes Intel®Pentium® II, Intel®Pentium® III, Intel®Pentium® 4, AMD Athlon®, et AMD Duron®
Il existe plusieurs façons de déterminer s'il existe une mise à niveau disponible du noyau pour votre système.
Errata de sécurité ; rendez-vous à l'adresse suivante http://www.redhat.com/security/updates/ afin d'obtenir des informations sur les errata de sécurité, y compris les mises à niveau de noyau qui corrigent les problèmes de sécurité.
Via Red Hat Network — Téléchargez et installez les paquetages RPM du noyau. Red Hat Network peut télécharger le dernier noyau, mettre à niveau le noyau du système, créer une image de disque RAM initial si nécessaire et configurer le chargeur d'amorçage de façon à ce qu'il démarre le nouveau noyau. Pour davantage d'informations, reportez-vous à http://www.redhat.com/docs/manuals/RHNetwork/.
Si Red Hat Network a servi à télécharger et installer le noyau mis à jour, suivez les instructions contenues dans les Section 31.5, « Vérification de l'image de disque RAM initial » et Section 31.6, « Vérification du chargeur d'amorçage », mais ne modifiez pas la configuration du noyau pour qu'il démarre par défaut, car Red Hat Network remplace automatiquement le noyau par défaut par la version la plus récente. Afin d'installer le noyau manuellement, passez à la Section 31.4, « Exécution de la mise à niveau ».
Après avoir extrait tous les paquetages nécessaires, c'est le moment de mettre à niveau le noyau existant.
Il est vivement recommandé de conserver l'ancien noyau au cas où le nouveau noyau aurait des problèmes de fonctionnement.
À l'invite du shell, passez au répertoire contenant les paquetages RPM du noyau. Utilisez l'argument -i
avec la commande rpm
afin de conserver l'ancien noyau. N'utilisez pas l'option -U
, étant donné qu'elle surcharge le noyau installé actuellement, ce qui cause des problèmes de chargeur de démarrage. Par exemple :
rpm -ivh kernel-
<kernel version>
.<arch>
.rpm
L'étape suivante consiste à vérifier que l'image de disque RAM initial à bien été créée. Reportez-vous à la Section 31.5, « Vérification de l'image de disque RAM initial » pour de plus amples informations.
Si le système utilise le système de fichiers ext3, un contrôleur SCSI ou s'il utilise des étiquettes pour faire référence aux partitions dans /etc/fstab
, il est nécessaire d'avoir un disque RAM initial. Le rôle de ce dernier est de permettre à un noyau modulaire d'avoir accès aux modules dont il pourrait avoir besoin pour démarrer avant que le noyau ait accès au périphérique où les modules se trouvent normalement.
Sur les architectures de Red Hat Enterprise Linux autres que les iSeries eServer IBM, le disque RAM initial peut être créé à l'aide de la commande mkinitrd
. Toutefois, cette étape se déroule automatiquement si le noyau et les paquetages qui lui sont associés, sont installés ou mis à niveau à partir des paquetages RPM distribués par Red Hat ; il n'est donc pas nécessaire d'effectuer cette étape manuellement. Afin de vous assurer que le disque RAM initial a bien été créé, utilisez la commande ls -l /boot
et vérifiez par là-même l'existence du fichier (la version devrait correspondre à la version du noyau qui vient d'être installé).
Sur les systèmes iSeries, le fichier du disque RAM initial et le fichier vmlinux
forment un seul fichier qui est créé à l'aide de la commande addRamDisk
. Cette étape se déroule automatiquement si le noyau et les paquetages qui lui sont associés sont installés ou mis à niveau à partir des paquetages RPM distribués par Red Hat, Inc. ; il n'est donc pas nécessaire d'effectuer cette étape manuellement. Afin de vous assurer qu'il a bien été créé, utilisez la commande ls -l /boot
et vérifiez par là-même l'existence du fichier /boot/vmlinitrd-
(la version <kernel-version>
devrait correspondre à la version du noyau qui vient d'être installé).
<kernel-version>
Il est maintenant nécessaire de vérifier que le chargeur d'amorçage a bien été configuré de façon à ce qu'il démarre le nouveau noyau. Consultez la Section 31.6, « Vérification du chargeur d'amorçage » pour plus d'informations.
Le paquetage RPM kernel
configure le chargeur d'amorçage de façon à ce que le noyau nouvellement installé soit démarré (sauf pour les systèmes iSeries eServer IBM). Il ne configure toutefois pas le chargeur d'amorçage afin qu'il démarre par défaut le nouveau noyau.
Il est vivement recommandé de vérifier que le chargeur d'amorçage a été correctement configuré. Il s'agit en effet d'une étape cruciale. S'il n'est pas correctement configuré, le système ne pourra pas démarrer Red Hat Enterprise Linux correctement. Dans ce cas, démarrez votre système à l'aide du support de démarrage préalablement créé et essayez de reconfigurer le chargeur d'amorçage.
Tous les systèmes x86 (y compris les systèmes AMD64) utilisent GRUB en tant que chargeur d'amorçage.
Confirme que le fichier /boot/grub/grub.conf
contient une section title
avec la même version que le paquetage kernel
qui vient d'être installé.
# Note that you do not have to rerun grub after making changes to this file # NOTICE: You have a /boot partition. This means that # all kernel and initrd paths are relative to /boot/, eg. # root (hd0,0) # kernel /vmlinuz-version ro root=/dev/hda2 # initrd /initrd-version.img #boot=/dev/hda default=1 timeout=10 splashimage=(hd0,0)/grub/splash.xpm.gz title Red Hat Enterprise Linux (2.6.9-5.EL) root (hd0,0) kernel /vmlinuz-2.6.9-5.EL ro root=LABEL=/ initrd /initrd-2.6.9-5.EL.img title Red Hat Enterprise Linux (2.6.9-1.906_EL) root (hd0,0) kernel /vmlinuz-2.6.9-1.906_EL ro root=LABEL=/ initrd /initrd-2.6.9-1.906_EL.img
Si une partition /boot/
séparée a été créée, les chemins d'accès au noyau ainsi qu'à l'image initrd
sont relatifs à la partition /boot/
.
Notez bien que la valeur par défaut ne correspond pas au nouveau noyau. Pour configurer GRUB de façon à ce qu'il démarre le nouveau noyau par défaut, remplacez la valeur de la variable default
par le numéro de la section du titre qui contient le nouveau noyau. La numérotation commence à 0. Ainsi, si le nouveau noyau correspond à la première section du titre, donnez à default
la valeur 0
.
Vous pouvez maintenant commencer à tester votre nouveau noyau en redémarrant l'ordinateur et en lisant bien les messages qui apparaîtront pour vous assurer que tout le matériel est correctement détecté.
Les systèmes Itanium utilisent ELILO comme chargeur d'amorçage, qui utilise le fichier de configuration /boot/efi/EFI/redhat/elilo.conf
. Vérifiez que ce fichier contient une section image
portant la même version que le paquetage kernel
que vous venez d'installer :
prompt timeout=50 default=old image=vmlinuz-2.6.9-5.EL label=linux initrd=initrd-2.6.9-5.EL.img read-only append="root=LABEL=/" image=vmlinuz-2.6.9-1.906_EL label=old initrd=initrd-2.6.9-1.906.img read-only append="root=LABEL=/"
Notez bien que la valeur par défaut ne correspond pas au nouveau noyau. Pour configurer ELILO de façon à ce qu'il démarre le nouveau noyau, donnez à la variable default
la valeur de label
pour la section image
contenant le nouveau noyau.
Vous pouvez maintenant commencer à tester votre nouveau noyau en redémarrant l'ordinateur et en lisant bien les messages qui apparaîtront pour vous assurer que tout le matériel est correctement détecté.
Les systèmes S/390 IBM et zSeries eServer IBM utilisent z/IPL comme chargeur d'amorçage, qui utilise le fichier de configuration /etc/zipl.conf
. Vérifiez que le fichier contient bien une section portant la même version que le paquetage noyau que vous venez d'installer :
[defaultboot] default=old target=/boot/ [linux] image=/boot/vmlinuz-2.6.9-5.EL ramdisk=/boot/initrd-2.6.9-5.EL.img parameters="root=LABEL=/" [old] image=/boot/vmlinuz-2.6.9-1.906_EL ramdisk=/boot/initrd-2.6.9-1.906_EL.img parameters="root=LABEL=/"
Notez bien que la valeur par défaut ne correspond pas au nouveau noyau. Pour configurer z/IPL de façon à ce qu'il démarre le nouveau noyau par défaut, remplacez la valeur de la variable default
par le nom de la section qui contient le nouveau noyau. La première ligne de chaque section contient le nom entre parenthèses.
Après avoir modifié le fichier de configuration, exécutez la commande /sbin/zipl
en tant que super-utilisateur afin d'activer les changements.
Vous pouvez maintenant commencer à tester votre nouveau noyau en redémarrant l'ordinateur et en lisant bien les messages qui apparaîtront pour vous assurer que tout le matériel est correctement détecté.
Le fichier /boot/vmlinitrd-
est installé lorsque vous effectuez la mise à niveau du noyau. Toutefois, vous devez utiliser la commande <version-noyau>
dd
pour configurer le système afin qu'il démarre le nouveau noyau :
En tant que super-utilisateur, exécutez la commande cat /proc/iSeries/mf/side
afin de déterminer le côté par défaut (A, B ou C).
En tant que super-utilisateur, exécutez la commande suivante où <kernel-version>
correspond à la version du nouveau noyau et <side>
au côté de la commande précédente :
dd if=/boot/vmlinitrd-
<kernel-version>
of=/proc/iSeries/mf/<side>
/vmlinux bs=8k
Vous pouvez maintenant commencer à tester votre nouveau noyau en redémarrant l'ordinateur et en lisant bien les messages qui apparaîtront pour vous assurer que tout le matériel est correctement détecté.
Les systèmes pSeries eServer IBM utilisent YABOOT comme chargeur d'amorçage, qui utilise le fichier de configuration /etc/aboot.conf
. Vérifiez que le fichier contient bien une section image
portant la même version que le paquetage kernel
que vous venez d'installer :
boot=/dev/sda1 init-message=Welcome to Red Hat Enterprise Linux! Hit <TAB> for boot options partition=2 timeout=30 install=/usr/lib/yaboot/yaboot delay=10 nonvram image=/vmlinux--2.6.9-5.EL label=old read-only initrd=/initrd--2.6.9-5.EL.img append="root=LABEL=/" image=/vmlinux-2.6.9-5.EL label=linux read-only initrd=/initrd-2.6.9-5.EL.img append="root=LABEL=/"
Notez que la valeur par défaut n'est pas le nouveau noyau. Le noyau de la première image est lancé par défaut. Pour modifier le noyau par défaut à lancer, changez son stanza d'image afin qu'il soit le premier de la liste ou ajoutez la directive default
et donnez lui la valeur label
du stanza d'image contenant le nouveau noyau.
Vous pouvez maintenant commencer à tester votre nouveau noyau en redémarrant l'ordinateur et en lisant bien les messages qui apparaîtront pour vous assurer que tout le matériel est correctement détecté.
Ce chapitre a pour objectif d'illustrer certains des paramètres possibles pour les pilotes[5] périphériques matériels courants qui, sous Red Hat Enterprise Linux, sont appelés modules noyau. Dans la plupart des cas, les paramètres par défaut fonctionnent. Néanmoins, dans certaines situations, des paramètres de module supplémentaires sont nécessaires pour qu'un périphérique puisse fonctionner correctement ou pour annuler les paramètres par défaut du module pour ce périphérique.
Durant l'installation, Red Hat Enterprise Linux utilise un sous-ensemble limité de pilotes de périphériques afin de créer un environnement d'installation stable. Bien que le programme d'installation prenne en charge une installation sur des types de matériel très variés, certains pilotes (y compris ceux pour des adaptateurs SCSI et réseau) ne sont pas inclus dans le noyau d'installation. Ils doivent en fait être chargés par l'utilisateur en tant que modules lors du démarrage.
Une fois l'installation terminée, la prise en charge de nombreux périphériques est assurée grâce à des modules noyau.
De nombreux pilotes de périphériques qui ne sont pas pris en charge sont fournis par Red Hat Inc. dans des groupes de paquetages nommés kernel-smp-unsupported-
et <kernel-version>
kernel-hugemem-unsupported-
. Remplacez <kernel-version>
<kernel-version>
par la version du noyau installée sur le système. Ces paquetages ne sont pas installés par le programme d'installation de Red Hat Enterprise Linux et les modules fournis ne sont pas pris en charge par Red Hat, Inc..
Un groupe de commandes pour gérer les modules de noyau est disponible si le paquetage module-init-tools
est installé. Utilisez ces commandes pour déterminer si un module a été chargé avec succès ou quand vous essayez différents modules avec du nouveau matériel.
La commande /sbin/insmod
affiche une liste de modules chargés. Par exemple :
Module Size Used by tun 11585 1 autofs4 21573 1 hidp 16193 2 rfcomm 37849 0 l2cap 23873 10 hidp,rfcomm bluetooth 50085 5 hidp,rfcomm,l2cap sunrpc 153725 1 dm_mirror 29073 0 dm_mod 57433 1 dm_mirror video 17221 0 sbs 16257 0 i2c_ec 5569 1 sbs container 4801 0 button 7249 0 battery 10565 0 asus_acpi 16857 0 ac 5701 0 ipv6 246113 12 lp 13065 0 parport_pc 27493 1 parport 37001 2 lp,parport_pc uhci_hcd 23885 0 floppy 57317 1 sg 34653 0 snd_ens1371 26721 1 gameport 16073 1 snd_ens1371 snd_rawmidi 24897 1 snd_ens1371 snd_ac97_codec 91360 1 snd_ens1371 snd_ac97_bus 2753 1 snd_ac97_codec snd_seq_dummy 4293 0 snd_seq_oss 32705 0 serio_raw 7493 0 snd_seq_midi_event 8001 1 snd_seq_oss snd_seq 51633 5 snd_seq_dummy,snd_seq_oss,snd_seq_midi_event snd_seq_device 8781 4 snd_rawmidi,snd_seq_dummy,snd_seq_oss,snd_seq snd_pcm_oss 42849 0 snd_mixer_oss 16833 1 snd_pcm_oss snd_pcm 76485 3 snd_ens1371,snd_ac97_codec,snd_pcm_oss snd_timer 23237 2 snd_seq,snd_pcm snd 52933 12 snd_ens1371,snd_rawmidi,snd_ac97_codec,snd_seq_oss,snd_seq,snd_seq_device,snd_pcm_oss,snd_mixer_oss,snd_pcm,snd_timer soundcore 10145 1 snd i2c_piix4 8909 0 ide_cd 38625 3 snd_page_alloc 10569 1 snd_pcm i2c_core 21697 2 i2c_ec,i2c_piix4 pcnet32 34117 0 cdrom 34913 1 ide_cd mii 5825 1 pcnet32 pcspkr 3521 0 ext3 129737 2 jbd 58473 1 ext3 mptspi 17353 3 scsi_transport_spi 25025 1 mptspi mptscsih 23361 1 mptspi sd_mod 20929 16 scsi_mod 134121 5 sg,mptspi,scsi_transport_spi,mptscsih,sd_mod mptbase 52193 2 mptspi,mptscsih
For each line, the first column is the name of the module, the second column is the size of the module, and the third column is the use count.
La sortie /sbin/lsmod
est moins complexe et plus facile à lire que la sortie de /proc/modules
.
Pour charger un module de noyau, utilisez la commande /sbin/modprobe
suivi du nom de module de noyau. Par défaut, modprobe
tente de charger le module depuis les sous-répertoires /lib/modules/
. Il y a un sous-répertoire pour chaque type de module, comme le sous-répertoire <kernel-version>
/kernel/drivers/net/
pour les pilotes d'interface réseau. Certains modules de noyau ont des dépendances de modules, c'est-à-dire que d'autres modules doivent être chargés d'abord avant qu'il ne charge lui-même. La commande /sbin/modprobe
vérifie ces dépendances et charge les dépendances de modules avant de charger le module spécifié.
Par exemple, la commande
/sbin/modprobe e100
charge toutes les dépendances de modules et ensuite le module e100
.
Pour imprimer à l'écran toutes les commandes comme /sbin/modprobe
exécutez-les et utilisez l'option -v
option. Par exemple :
/sbin/modprobe -v e100
Des sorties similaires à ce qui suit sont affichées :
/sbin/insmod /lib/modules/2.6.9-5.EL/kernel/drivers/net/e100.ko Using /lib/modules/2.6.9-5.EL/kernel/drivers/net/e100.ko Symbol version prefix 'smp_'
La commande /sbin/insmod
existe également pour charger les modules de noyau cependant cela ne résout pas les dépendances. Ainsi il est recommandé d'utiliser la commande /sbin/modprobe
.
Pour décharger les modules de noyau, utilisez la commande /sbin/rmmod
suivi du nom du module. L'utilitaire rmmod
ne décharge que des modules qui ne sont pas utilisés et qui ne dépendent pas d'autres modules utilisés.
Par exemple, la commande
/sbin/rmmod e100
décharge le module noyau e100
.
Voici un autre utilitaire de module noyau utile modinfo
. Utilisez la commande /sbin/modinfo
pour afficher les informations sur le module noyau. La syntaxe courante est :
/sbin/modinfo [options]
<module>
Les options incluent -d
, qui affiche une brève description du module, et -p
, qui liste les paramètres pris en charge par le module. Pour une liste complète des options, consultez la page de manuel modinfo
(man modinfo
).
Kernel modules are usually loaded directly by the facility that requires them, which is given correct settings in the /etc/modprobe.conf
file. However, it is sometimes necessary to explicitly force the loading of a module at boot time.
Red Hat Enterprise Linux vérifie l'existence du fichier /etc/rc.modules
au démarrage, celui-ci contient différentes commandes pour charger les modules. rc.modules
doit être utilisé et nonrc.local
parce que rc.modules
est exécuté avant le processus de démarrage.
Par exemple, les commandes suivantes configurent le chargement du module foo
au démarrage (en tant que root) :
# echo modprobe foo >> /etc/rc.modules # chmod +x /etc/rc.modules
Cette approche n'est pas nécessaire pour le réseau et les interfaces SCSI parce qu'ils possèdent leurs propres mécanismes spécifiques.
Dans certaines situations, il peut s'avérer nécessaire de fournir certains paramètres à un module lors de son chargement, afin qu'il puisse fonctionner correctement.
Par exemple, afin de permettre un duplex total à une vitesse de connexion de 100Mbps pour une carte Intel Ether Express/100, chargez le pilote e100
avec l'option e100_speed_duplex=4
.
Lorsqu'un paramètre contient une virgule, assurez-vous de ne pas mettre d'espace après la virgule.
La commande modinfo
est également utile pour obtenir une liste de différentes informations relatives au module noyau, telles que la version, les dépendances, les options de paramètres et les alias.
Matériel | Module | Paramètres |
---|---|---|
3ware Storage Controller and 9000 series |
3w-xxxx.ko, 3w-9xxx.ko
|
|
Adaptec Advanced Raid Products, Dell PERC2, 2/Si, 3/Si, 3/Di, HP NetRAID-4M, IBM ServeRAID, and ICP SCSI driver |
aacraid.ko
|
|
Adaptec 28xx, R9xx, 39xx AHA-284x, AHA-29xx, AHA-394x, AHA-398x, AHA-274x, AHA-274xT, AHA-2842, AHA-2910B, AHA-2920C, AHA-2930/U/U2, AHA-2940/W/U/UW/AU/, U2W/U2/U2B/, U2BOEM, AHA-2944D/WD/UD/UWD, AHA-2950U2/W/B, AHA-3940/U/W/UW/, AUW/U2W/U2B, AHA-3950U2D, AHA-3985/U/W/UW, AIC-777x, AIC-785x, AIC-786x, AIC-787x, AIC-788x , AIC-789x, AIC-3860 |
aic7xxx.ko
|
|
IBM ServeRAID |
ips.ko
|
|
Pilote de boîte aux lettres LSI Logic MegaRAID |
megaraid_mbox.ko
|
|
Emulex LightPulse Fibre Channel SCSI driver |
lpfc.ko
|
|
HP Smart Array | cciss.ko | |
LSI Logic MPT Fusion | mptbase.ko mptctl.ko mptfc.ko mptlan.ko mptsas.ko mptscsih.ko mptspi.ko |
|
QLogic Fibre Channel Driver | qla2xxx.ko |
after which an interrupt response is generated
|
NCR, Symbios and LSI 8xx and 1010 | sym53c8xx |
|
De nos jours, la plupart des cartes d'interface réseau basées sur Ethernet (ou NIC) ne nécessitent pas de paramètres de module pour modifier les paramétrages. Ils peuvent par contre être configurés à l'aide de ethtool
ou de mii-tool
. Les paramètres de module ne devraient être ajustés que si ces outils ne fonctionnent pas. Les paramètres de module peuvent être affichés à l'aide de la commande modinfo
.
Pour obtenir de plus amples informations sur l'utilisation de ces outils, reportez-vous aux pages de manuel de ethtool
, mii-tool
, et modinfo
.
Matériel | Module | Paramètres |
---|---|---|
3Com EtherLink PCI III/XL Vortex (3c590, 3c592, 3c595, 3c597) Boomerang (3c900, 3c905, 3c595) |
3c59x.ko
|
|
RTL8139, SMC EZ Card Fast Ethernet, cartes RealTek utilisant RTL8129 ou RTL8139 Fast Ethernet chipsets. |
8139too.ko
|
|
Broadcom 4400 10/100 PCI ethernet driver |
b44.ko
|
|
Broadcom NetXtreme II BCM5706/5708 Driver |
bnx2.ko
|
|
Pilote Intel Ether Express/100 |
e100.ko
|
|
Intel EtherExpress/1000 Gigabit |
e1000.ko
|
|
Myricom 10G driver (10GbE) |
myri10ge.ko
|
|
NatSemi DP83815 Fast Ethernet |
natsemi.ko
|
|
AMD PCnet32 et AMD PCnetPCI |
pcnet32.ko
|
|
PCnet32 and PCnetPCI |
pcnet32.ko
|
|
RealTek RTL-8169 Gigabit Ethernet driver |
r8169.ko
|
|
Neterion Xframe 10GbE Server Adapter |
s2io.ko
|
|
SIS 900/701G PCI Fast Ethernet |
sis900.ko
|
|
Adaptec Starfire Ethernet driver |
starfire.ko
|
|
Broadcom Tigon3 |
tg3.ko
|
|
ThunderLAN PCI |
tlan.ko
|
|
Cartes Ethernet PCI Digital 21x4x Tulip SMC EtherPower 10 PCI(8432T/8432BT) SMC EtherPower 10/100 PCI(9332DST) DEC EtherWorks 100/10 PCI(DE500-XA) DEC EtherWorks 10 PCI(DE450) DEC QSILVER's, Znyx 312 etherarray Allied Telesis LA100PCI-T Danpex EN-9400, Cogent EM110 |
tulip.ko
|
io io_port
|
Cartes PCI Fast Ethernet VIA Rhine PCI avec soit VIA VT86c100A Rhine-II PCI ou 3043 Rhine-I D-Link DFE-930-TX PCI 10/100 |
via-rhine.ko
|
|
It is possible to use multiple Ethernet cards on a single machine. For each card there must be an alias
and, possibly, options
lines for each card in /etc/modprobe.conf
.
Pour obtenir davantage d'informations sur l'utilisation de multiples cartes Ethernet, consultez le document intitulé Linux Ethernet-HOWTO disponible en ligne et en anglais à l'adresse suivante : http://www.redhat.com/mirrors/LDP/HOWTO/Ethernet-HOWTO.html.
Red Hat Enterprise Linux allows administrators to bind NICs together into a single channel using the bonding
kernel module and a special network interface, called a channel bonding interface. Channel bonding enables two or more network interfaces to act as one, simultaneously increasing the bandwidth and providing redundancy.
Afin de lier plusieurs interfaces réseau, l'administrateur doit effectuer les étapes suivantes :
Add the following line to /etc/modprobe.conf
:
alias bond
<N>
bonding
Replace <N>
with the interface number, such as 0
. For each configured channel bonding interface, there must be a corresponding entry in /etc/modprobe.conf
.
Configure a channel bonding interface as outlined in Section 5.2.3, « Interfaces de liaison de canaux ».
To enhance performance, adjust available module options to ascertain what combination works best. Pay particular attention to the miimon
or arp_interval
and the arp_ip_target
parameters. Refer to Section 32.5.2.1, « bonding
Module Directives » for a listing of available options.
After testing, place preferred module options in /etc/modprobe.conf
.
Before finalizing the settings for the bonding
module, it is a good idea to test which settings work best. To do this, open a shell prompt as root and type:
tail -f /var/log/messages
Open another shell prompt and use the /sbin/insmod
command to load the bonding
module with different parameters while observing the kernel messages for errors.
The /sbin/insmod
command is issued in the following format:
/sbin/insmod bond<N>
<parameter=value>
Remplacez <N>
par le numéro de l'interface de liaison. Remplacez <parameter=value>
par une liste de paramètres pour l'interface dont les éléments sont séparés les uns des autres par un espace.
Once satisfied with the performance of the bonding interface (and verifying that there are no errors), add the appropriate bonding
module parameters to ifcfg-bond
(where <N>
is the number of the interface). These parameters are set as <N>
BONDING_OPTS="
. For more information, refer to Section 5.2.3, « Interfaces de liaison de canaux ».
<parameters>
"
The following is a list of available parameters for the bonding
module:
mode=
— Specifies one of four policies allowed for the bonding
module. Acceptable values for this parameter are:
0
— Sets a round-robin policy for fault tolerance and load balancing. Transmissions are received and sent out sequentially on each bonded slave interface beginning with the first one available.
1
— Sets an active-backup policy for fault tolerance. Transmissions are received and sent out via the first available bonded slave interface. Another bonded slave interface is only used if the active bonded slave interface fails.
2
— Sets an XOR (exclusive-or) policy for fault tolerance and load balancing. Using this method, the interface matches up the incoming request's MAC address with the MAC address for one of the slave NICs. Once this link is established, transmissions are sent out sequentially beginning with the first available interface.
3
— Sets a broadcast policy for fault tolerance. All transmissions are sent on all slave interfaces.
4
— Sets an IEEE 802.3ad dynamic link aggregation policy. Creates aggregation groups that share the same speed and duplex settings. Transmits and receives on all slaves in the active aggregator. Requires a switch that is 802.3ad compliant.
5
— Sets a Transmit Load Balancing (TLB) policy for fault tolerance and load balancing. The outgoing traffic is distributed according to the current load on each slave interface. Incoming traffic is received by the current slave. If the receiving slave fails, another slave takes over the MAC address of the failed slave.
6
— Sets an Active Load Balancing (ALB) policy for fault tolerance and load balancing. Includes transmit and receive load balancing for IPV4 traffic. Receive load balancing is achieved through ARP negotiation.
miimon=
— Specifies (in milliseconds) how often MII link monitoring occurs. This is useful if high availability is required because MII is used to verify that the NIC is active. To verify that the driver for a particular NIC supports the MII tool, type the following command as root:
ethtool
<interface-name>
| grep "Link detected:"
Dans cette commande, remplacez <interface-name>
par le nom de l'interface du périphérique, tel que eth0
et non pas par l'interface bond
. Si MII est pris en charge, la commande renvoie l'extrait suivant :
Link detected: yes
Si une interface de liaison est utilisée à des fin de haute disponibilité, le module de chaque NIC doit prendre en charge MII.
Setting the value to 0
(the default), turns this feature off. When configuring this setting, a good starting point for this parameter is 100
.
downdelay=
— Specifies (in milliseconds) how long to wait after link failure before disabling the link. The value must be a multiple of the value specified in the miimon
parameter. The value is set to 0
by default, which disables it.
updelay=
— Specifies (in milliseconds) how long to wait before enabling a link. The value must be a multiple of the value specified in the miimon
parameter. The value is set to 0
by default, which disables it.
arp_interval=
— Specifies (in milliseconds) how often ARP monitoring occurs.
If using this setting while in mode
0
or 2
(the two load-balancing modes), the network switch must be configured to distribute packets evenly across the NICs. For more information on how to accomplish this, refer to
/usr/share/doc/kernel-doc-
<kernel-version>
/Documentation/networking/ bonding.txt
The value is set to 0
by default, which disables it.
arp_ip_target=
— Specifies the target IP address of ARP requests when the arp_interval
parameter is enabled. Up to 16 IP addresses can be specified in a comma separated list.
arp_validate=
— validate source/distribution of ARP probes; default is none
. Other valid values are active
, backup
, and all
.
lacp_rate=
— Specifies the rate at which link partners should transmit LACPDU packets in 802.3ad mode. Possible values are:
slow
or 0
— Default setting. This specifies that partners should transmit LACPDUs every 30 seconds.
fast
or 1
— Specifies that partners should transmit LACPDUs every 1 second.
primary=
— Specifies the interface name, such as eth0
, of the primary device. The primary
device is the first of the bonding interfaces to be used and is not abandoned unless it fails. This setting is particularly useful when one NIC in the bonding interface is faster and, therefore, able to handle a bigger load.
Ce paramétrage est seulement valide lorsque l'interface de liaison (bonding) est en mode active-backup. Consultez :
/usr/share/doc/kernel-doc-
<kernel-version>
/Documentation/networking/ bonding.txt
pour obtenir de plus amples informations.
use_carrier=
— Specifies whether or not miimon
should use MII/ETHTOOL ioctls or netif_carrier_ok()
to determine the link state. The netif_carrier_ok()
relies on the device driver to maintains its state with netif_carrier_
; most device drivers support this function.
on/off
The MII/ETHROOL ioctls tools utilize a deprecated calling sequence within the kernel. However, this is still configurable in case your device driver does not support netif_carrier_
.
on/off
Valid values are:
1
— Default setting. Enables the use of netif_carrier_ok()
.
0
— Enables the use of MII/ETHTOOL ioctls.
If bonding
insists that the link is up when it should not be, it is possible that your network device driver does not support netif_carrier_
.
on/off
xmit_hash_policy
— Selects the transmit hash policy used for slave selection in balance-xor
and 802.3ad modes. Possible values are:
0
or layer2
— Default setting. This option uses the XOR of hardware MAC addresses to generate the hash. The formula used is:
(<source> <MAC> <XOR> <destination> <MAC>) <modulo slave count>
This algorithm will place all traffic to a particular network peer on the same slave, and is 802.3ad compliant.
1
or layer3+4
— Uses upper layer protocol information (when available) to generate the hash. This allows for traffic to a particular network peer to span multiple slaves, although a single connection will not span multiple slaves.
The formula for unfragmented TCP and UDP packets used is:
((<source> <port> <XOR> <destination>) <XOR> ((<source> <IP> <XOR> <destination> <IP>) AND 0xffff) <modulo slave count>
For fragmented TCP or UDP packets and all other IP protocol traffic, the source and destination port information is omitted. For non-IP traffic, the formula is the same as the layer2
transmit hash policy.
This policy intends to mimic the behavior of certain switches; particularly, Cisco switches with PFC2 as well as some Foundry and IBM products.
The algorithm used by this policy is not 802.3ad compliant.
It is essential that either the arp_interval
and arp_ip_target
or miimon
parameters are specified. Failure to due so can cause degradation of network performance in the event a link fails.
Refer to the following file for more information (note that you must have the kernel-doc
package installed to read this file):
/usr/share/doc/kernel-doc-<kernel-version>
/Documentation/networking/ bonding.txt
pour obtenir des instructions détaillées sur la liaison d'interfaces.
For more information on kernel modules and their utilities, refer to the following resources.
lsmod
man page — description and explanation of its output.
insmod
man page — description and list of command line options.
modprobe
man page — description and list of command line options.
rmmod
man page — description and list of command line options.
modinfo
man page — description and list of command line options.
/usr/share/doc/kernel-doc-
— how to compile and use kernel modules. Note you must have the <version>
/Documentation/kbuild/modules.txtkernel-doc
package installed to read this file.
http://tldp.org/HOWTO/Module-HOWTO/ — Linux Loadable Kernel Module HOWTO from the Linux Documentation Project.
[5] Un pilote est un type de logiciel qui permet à Linux d'utiliser un périphérique matériel donné. Sans pilote, le noyau ne peut pas communiquer avec les périphériques attachés.
Que ce soit pour sécuriser leurs systèmes, leurs services ou des données, Red Hat Enterprise Linux fournit aux administrateurs système un choix d'outils et de méthodes afin d'élaborer une stratégie de sécurité approfondie.
Ce chapitre introduit la sécurité de façon générale et en particulier du point de vue de Red Hat Enterprise Linux. Il fournit des informations conceptuelles concernant les secteurs d'évaluation de la sécurité, les exploits communs et les réponses aux intrusions et incidents. De même il offre des informations de configuration conceptuelles et spécifiques sur l'utilisation de SELinux pour renforcer les stations de travail, serveurs, VPN, pare-feu et autres implémentations.
Ce chapitre présuppose que vous possédez déjà une connaissance de la sécurité informatique, et par conséquent ne fournit qu'une couverture limitée des pratiques de sécurité communes comme le contrôle d'accès physique, les politiques et procédures d'une bonne gestion de compte, l'audit, etc. Le cas échéant, des références à des ressources externes et à des informations se rapportant à ces sujets seront mentionnées.
Table des matières
Parce que notre dépendance est de plus en plus prononcée vis à vis des ordinateurs puissants mis en réseau pour faire des affaires et garder des archives de nos informations personnelles, de nombreuses industries ont émergées dans le domaine de la sécurité réseau et informatique. Maintes entreprises ont recours aux services d'experts en sécurité afin qu'ils analysent leurs systèmes de manière adéquate et élaborent des solutions adaptées aux besoins opérationnels de la société. Parce que la plupart des sociétés sont dynamiques par nature, les employés accédant aux ressources IT localement et à distance, la nécessité de disposer d'environnements informatiques sécurisés est de plus en plus prononcée.
Malheureusement, la plupart des sociétés (et des utilisateurs individuels) voient la sécurité comme une considération après coup, un processus négligé au profit d'une puissance et productivité accrues et de considérations budgétaires. L'implémentation d'une sécurité appropriée a souvent lieu de manière rétrospective — par exemple, suite à une intrusion non autorisée. Les experts en sécurité reconnaissent que le fait de prendre les mesures appropriées avant même de connecter un site à un réseau qui n'est pas digne de confiance, tel que l'internet, représente la meilleure façon de contrer la plupart des tentatives d'intrusion.
Avec du temps, des ressources et de la motivation, un pirate peut rentrer dans pratiquement n'importe quel système. À la fin, toutes les procédures et les technologies de sécurité actuellement disponibles ne peuvent pas vous garantir que vos systèmes sont protégés contre les intrusions. Les routeurs peuvent aider à sécuriser les passerelles vers l'internet. Les pare-feu peuvent aider à sécuriser les bords du réseau. Les réseaux privés virtuels peuvent transmettre vos données en toute sécurité dans un flux crypté. Les systèmes de détection d'intrusions peuvent vous prévenir de toute activité malveillante. Cependant, la réussite de chacune de ces technologies dépend d'un certain nombre de variables, y compris :
Les compétences du personnel responsable de la configuration, du contrôle et de la maintenance des technologies.
La capacité d'insérer des correctifs et de mettre à jour des services et des noyaux rapidement et efficacement.
La capacité des responsables à rester vigilants sur le réseau.
Vu l'état dynamique des technologies et des systèmes de données, la sécurisation de vos ressources d'entreprise peut devenir complexe. À cause de cette complexité, il est souvent difficile de trouver des ressources spécialisées pour tous vos systèmes. Alors qu'il est possible d'avoir un personnel avec des connaissances de haut niveau dans de nombreux domaines de la sécurité de l'information, il est plus difficile de garder les employés qui sont spécialistes dans plusieurs domaines. Cela vient principalement du fait que chaque sujet en sécurité de l'information demande une attention et une concentration constantes. La sécurité de l'information ne reste pas en place.
Supposez que vous administrez un réseau d'entreprise. De tels réseaux sont couramment constitués de systèmes d'exploitation, d'applications, de serveurs, de contrôleurs de réseau, de pare-feu, de systèmes de détection d'intrusions et bien plus encore. Imaginez maintenant d'essayer de rester à jour pour chacun d'entre eux. Vu la complexité des environnements réseaux et logiciels d'aujourd'hui, les exploits et les bogues sont d'une certitude. Rester au courant des correctifs et des mises à jour pour un réseau entier peut s'avérer devenir une tâche décourageante dans une grande société avec des systèmes hétérogènes.
En combinant les besoins d'expertise avec la tâche de rester au courant, il devient inévitable que des incidents négatifs se produisent, que les protections de systèmes soient brisées, que des données soient corrompues et que le service soit interrompu.
Pour augmenter les technologies de sécurité et aider à protéger les systèmes, les réseaux et les données, essayez de penser comme un pirate et mesurez la sécurité des systèmes en vérifiant leurs faiblesses. Des évaluations de vulnérabilités préventives sur vos propres systèmes et ressources réseaux peuvent révéler des problèmes possibles qui peuvent être traités avant qu'un pirate ne les trouve.
Si vous deviez effectuer une évaluation des vulnérabilités de votre maison, vous vérifieriez sûrement chaque porte pour voir si elles sont bien fermées et verrouillées. Vous vérifieriez également chaque fenêtre, vous assurant qu'elles sont bien fermées. Le même concept s'applique aux systèmes, réseaux et données électroniques. Les utilisateurs malveillants sont les voleurs et les vandales de vos données. Concentrez vous sur leurs outils, leur mentalité et leurs motivations et vous pourrez alors réagir rapidement à leurs actions.
Les évaluations de vulnérabilités peuvent être séparées en deux types : de l'extérieur vers l'intérieur et de l'intérieur vers l'intérieur.
Lors d'une évaluation de vulnérabilités de l'extérieur vers l'intérieur, vous essayez de compromettre vos systèmes de l'extérieur. Être en dehors de votre société vous offre le point de vue du pirate. Vous pouvez voir ce qu'un pirate voit — les adresses IP routables de façon publique, les systèmes sur votre DMZ, les interfaces externes de votre pare-feu et bien plus encore. DMZ signifie zone démilitarisée (de l'anglais demilitarized zone) et correspond à un ordinateur ou un petit sous-réseau qui se situe entre un réseau interne de confiance, comme un LAN privé, et un réseau externe qui n'est pas de confiance, comme l'internet public. Une DMZ contient normalement des périphériques accessibles au trafic Internet, comme les serveurs Web (HTTP), les serveurs FTP, les serveurs SMTP (courrier électronique) et les serveurs DNS.
Lors d'une évaluation de vulnérabilités de l'intérieur vers l'intérieur, vous avez un avantage vu que vous êtes interne et que votre statut devient de confiance. Ceci est le point de vue que vos collègues et vous possédez une fois connectés sur vos systèmes. Vous verrez les serveurs d'impression, les serveurs de fichiers, les bases de données et d'autres ressources.
Il existe de grandes différences entre ces deux types d'évaluation de vulnérabilités. Être à l'intérieur de votre société vous donne des privilèges élevés supérieurs à toute autre personne de l'extérieur. De nos jours, dans la plupart des sociétés, la sécurité est toujours configurée de manière à garder les intrus dehors. Peu est fait pour sécuriser les internes de la société (comme les pare-feu de départements, les contrôles d'accès au niveau de l'utilisateur, les procédures d'authentification pour les ressources internes et autres). En général, il existe bien plus de ressources de l'intérieur vu que la plupart des systèmes sont internes à la société. Une fois que vous devenez externe à la société, votre statut n'est immédiatement plus de confiance. Les systèmes et les ressources qui vous sont disponibles de l'extérieur sont généralement bien plus limités.
Considérez la différence entre les évaluations de vulnérabilités et les essais de pénétration. Pensez à l'évaluation de vulnérabilités comme la première étape d'un essai de pénétration. Les informations glanées depuis l'évaluation seront utilisées dans les essais. Alors que l'évaluation vérifie les trous et les vulnérabilités potentielles, les essais de pénétration essaient en fait d'exploiter les conclusions.
L'évaluation d'une infrastructure réseau est un processus dynamique. La sécurité, des informations et physique, est dynamique. Effectuer une évaluation offre une vue d'ensemble, qui peut trouver des faux positifs et des faux négatifs.
Les administrateurs de sécurité sont aussi compétents que les outils qu'ils utilisent et les connaissances qu'ils retiennent. Prenez n'importe quel outil d'évaluation actuellement disponible, exécutez-le sur votre système et il est pratiquement garanti qu'il existera au moins plusieurs faux positifs. Que ce soit une faute de programme ou une erreur d'utilisateur, les résultats seront les mêmes. L'outil peut trouver des vulnérabilités qui, en fait, n'existent pas (faux positifs) ; ou, au pire, l'outil peut ne pas trouver des vulnérabilités qui existent bien (faux négatifs).
Maintenant que la différence entre l'évaluation de vulnérabilités et l'essai de pénétration a été établie, il est souvent de bonne habitude de rassembler les conclusions de l'évaluation et de les passer en revue avec attention avant de procéder à un essai de pénétration.
Essayer d'exploiter les vulnérabilités de ressources de production peut avoir des effets négatifs sur la productivité et l'efficacité de vos systèmes et réseaux.
La liste suivante examine certains avantages liés au fait d'effectuer des évaluations de vulnérabilités.
Accent proactif porté sur la sécurité des informations
Exploits potentiels découverts avant que les pirates ne les trouvent
Systèmes habituellement à jour et avec des correctifs
Amélioration et aide au développement de l'expertise du personnel
Réduction de perte financière et de mauvaise publicité
Pour aider à sélectionner les outils pour des évaluations de vulnérabilités, il est utile d'établir une méthodologie d'évaluation de vulnérabilités. Malheureusement, il n'existe à ce jour aucune méthodologie approuvée par l'industrie ou prédéfinie ; cependant, du bon sens et de bonnes habitudes peuvent suffisamment servir de guide.
Quelle est la cible ? Faisons-nous face à un serveur ou à notre réseau entier et tout ce qui s'y trouve ? Sommes-nous externes ou internes à la société ? Les réponses à ces questions sont importantes vu qu'elles vous aideront à déterminer non seulement les outils à sélectionner, mais également la manière de les utiliser.
Pour en savoir plus sur l'établissement de méthodologies, veuillez consulter les sites Web suivants :
http://www.isecom.org/projects/osstmm.htmLe manuel Open Source de méthodologie de test de la sécurité (OSSTMM)
http://www.owasp.org/Le projet de sécurité des applications Open Web
Une évaluation typique peut commencer en utilisant un outil pour rassembler des informations. Lors de l'évaluation du réseau entier, faites une projection de la structure pour trouver les hôtes qui sont en cours d'exécution. Une fois situés, examinez chaque hôte individuellement. Cela demandera l'utilisation d'un autre ensemble d'outils. Savoir quels outils utiliser représente l'étape la plus cruciale dans la détermination de vulnérabilités.
Comme dans les aspects de la vie de tous les jours, il existe de nombreux outils différents pour effectuer la même tâche. Ce concept s'applique également aux évaluations de vulnérabilités. Certains outils sont spécifiques aux systèmes d'exploitation, aux applications et même aux réseaux (selon les protocoles utilisés). Certains outils sont gratuits. Certains outils sont intuitifs et faciles à utiliser, alors que d'autres sont plus compliqués et mal documentés, mais possèdent des fonctionnalités que d'autres outils n'ont pas.
Trouver les bons outils peut être une tâche difficile. À la fin, l'expérience compte. Si possible, configurez un exercice de tests et essayez autant d'outils que vous le pouvez, notant les qualités et les faiblesses de chacun. Passez en revue le fichier README ou la page de manuel de l'outil. De plus, regardez sur l'internet pour trouver davantage d'informations, comme des articles, des guides étape-par-étape ou même des listes de diffusion spécifiques à l'outil.
Les outils examinés ci-dessous ne sont qu'un échantillon des outils disponibles.
Nmap est un outil populaire inclus dans Red Hat Enterprise Linux qui peut être utilisé pour déterminer la structure d'un réseau. Nmap est disponible depuis de nombreuses années et est sûrement l'outil le plus souvent utilisé pour rassembler des informations. Une excellente page de manuel est incluse qui fournit une description détaillée de ses options et de son utilisation. Les administrateurs peuvent utiliser Nmap sur un réseau pour trouver les systèmes hôtes et les ports ouverts sur ces systèmes.
Nmap est une première étape compétente dans l'évaluation de vulnérabilités. Vous pouvez déterminer tous les hôtes sur votre réseau et même passer une option qui lui permettra d'identifier le système d'exploitation en cours d'exécution sur un hôte particulier. Nmap est une bonne base pour établir une politique sur l'utilisation de services sécurisés et l'arrêt de services non utilisés.
Nmap peut être exécuté depuis une invite de shell. Saisissez la commande nmap
suivie du nom d'hôte ou de l'adresse IP de la machine que vous souhaitez analyser.
nmap foo.example.com
Les résultats de l'analyse (qui peut prendre quelques minutes selon l'emplacement de l'hôte) devrait ressembler à l'exemple suivant :
Starting nmap V. 3.50 ( www.insecure.org/nmap/ ) Interesting ports on localhost.localdomain (127.0.0.1): (The 1591 ports scanned but not shown below are in state: closed) Port State Service 22/tcp open ssh 25/tcp open smtp 111/tcp open sunrpc 443/tcp open https 515/tcp open printer 950/tcp open oftep-rpc 6000/tcp open X11 Nmap run completed -- 1 IP address (1 host up) scanned in 71.825 seconds
Nmap teste les ports de communication réseau les plus courants pour identifier des services en écoute ou en attente. Un administrateur qui souhaite fermer tout service non nécessaire, trouvera ces informations utiles.
Pour de plus amples informations sur l'utilisation de Nmap, veuillez consulter la page d'accueil officielle à l'URL suivant :
Nessus est un scanneur de sécurité de services entiers. L'architecture plugin de Nessus permet aux utilisateurs de le personnaliser pour leurs systèmes et réseaux. Comme avec tout scanneur, Nessus n'offre qu'autant que la base de données de signatures sur laquelle il dépend. Heureusement, Nessus est fréquemment mis à jour. Ses fonctions comprennent un rapportage complet, la vérification d'hôtes et des recherches de vulnérabilités en temps réel. Souvenez-vous qu'il peut exister des faux positifs et des faux négatifs, même dans un outil aussi puissant et fréquemment mis à jour que Nessus.
Nessus n'est pas inclus dans Red Hat Enterprise Linux et n'est pas supporté. Il a été inclus dans ce document en tant que référence pour les utilisateurs qui sont intéressés par cette application populaire.
Pour de plus amples informations sur l'utilisation de Nessus, veuillez consulter la page d'accueil officielle à l'URL suivant :
Nikto est un excellent scanneur de scripts CGI (common gateway interface). Nikto peut non seulement vérifier les vulnérabilités de CGI, mais également le faire d'une manière évasive, pour échapper aux systèmes de détection d'intrusions. Sa documentation est excellente et devrait être lue attentivement avant d'exécuter le programme. Lorsque vous avez des serveurs Web qui servent des scripts CGI, Nikto peut alors être une ressource excellente pour vérifier la sécurité de ces serveurs.
Nikto n'est pas inclus dans Red Hat Enterprise Linux et n'est pas supporté. Il a été inclus dans ce document en tant que référence pour les utilisateurs qui sont intéressés par cette application populaire.
De plus amples informations sur Nikto se trouvent à l'URL suivant :
VLAD est un scanneur de vulnérabilités développé par l'équipe RAZOR à Bindview, Inc. qui peut être utilisé pour vérifier les vulnérabilités. Il utilise la liste des dix problèmes de sécurité les plus courants de SANS (problèmes de SNMP, partage de fichiers, etc). Bien qu'il ne possède pas autant de fonctionnalités que Nessus, VLAD vaut la peine d'être examiné.
VLAD n'est pas inclus dans Red Hat Enterprise Linux et n'est pas supporté. Il a été inclus dans ce document en tant que référence pour les utilisateurs qui sont intéressés par cette application populaire.
De plus amples informations sur VLAD se trouvent sur le site Web de l'équipe RAZOR à l'URL suivant :
Selon votre objectif et vos ressources, de nombreux outils sont disponibles. Il existe des outils pour les réseaux sans-fil, les réseaux Novell, les systèmes Windows, les systèmes Linux et autres. Une autre partie essentielle des évaluations inclut la revue de la sécurité physique, la sélection du personnel ou l'évaluation du réseau voice/PBX. De nouveaux concepts, comme « war walking » analysant le périmètre des structures physiques de votre entreprise pour trouver des vulnérabilités de réseau sans fil sont des concepts prometteurs que vous pouver examiner et, au besoin, incorporer dans vos évaluations. L'imagination et l'exposition sont les seules limites pour planifier et conduire des évaluations de vulnérabilités.
Tableau 33.1, « Exploits courants » détaille certains des exploits et des points d'entrée les plus courants utilisés par les intrus pour accéder aux ressources réseau organisationnelles. La clé de ces exploits courants vient des explications sur la manière dont ils sont effectués et la manière dont les administrateurs peuvent protéger correctement leur réseau contre de telles attaques.
Exploit | Description | Remarques | |||
---|---|---|---|---|---|
Mots de passe par défaut ou vides | Laisser les mots de passe d'administration vides ou utiliser un mot de passe par défaut fourni par le vendeur du produit. Ceci est des plus courants dans le matériel comme les routeurs et les pare-feu, bien que certains services qui sont exécutés sur Linux peuvent contenir des mots de passe d'administration par défaut (bien que Red Hat Enterprise Linux 5 ne soit pas vendu avec). |
|
|||
Clés partagées par défaut | Les services sécurisés contiennent parfois des clés de sécurité par défaut pour le développement ou le test d'évaluation. Si ces clés ne sont pas modifiées et sont placées dans un environnement de production sur l'internet, tous les utilisateurs avec les mêmes clés par défaut auront accès aux ressources de cette clé partagée et toutes les informations importantes qu'elle contient. |
|
|||
Usurpation d'identité (IP spoofing) | Une machine distante agit comme un noeud sur votre réseau local, trouve les vulnérabilités de vos serveurs et installe un programme de porte dérobée ou cheval de Troie pour obtenir le contrôle sur vos ressources réseau. |
|
|||
Écoute clandestine | Rassembler des données qui passent entre deux noeuds activés sur un réseau en écoutant sur la connexion entre les deux noeuds. |
|
|||
Vulnérabilités des services | Un pirate trouve une faille ou une lacune dans un service exécuté sur l'internet ; à travers cette vulnérabilité, le pirate compromet le système entier et toutes les données qu'il peut contenir et peut également compromettre d'autres systèmes sur le réseau. |
|
|||
Vulnérabilités des applications | Les pirates trouvent des fautes dans les applications de bureau et de poste de travail, comme les clients de messagerie électronique, et exécutent le code binaire, implantent des chevaux de Troie pour de futurs compromis ou bloquent les systèmes. Le système peut être bien plus exploité si le poste de travail compromis a des privilèges d'administration sur le reste du réseau. |
|
|||
Attaques par déni de service (Denial of Service ou Dos) | Un pirate ou un groupe de pirates coordonnent une attaque sur le réseau ou sur les ressources du serveur d'une organisation en envoyant des paquets non autorisés vers la machine cible (soit le serveur, le routeur ou le poste de travail). Cela oblige la ressource à devenir indisponible pour les utilisateurs légitimes. |
|
Lorsque des vulnérabilités de sécurité sont découvertes, les logiciels touchés doivent être corrigés afin de limiter les risques de sécurité possibles. Si le logiciel fait partie d'un paquetage au sein d'une distribution Red Hat Enterprise Linux actuellement supportée, Red Hat, Inc. se doit de publier des paquetages mis à jour réparant les brèches de sécurité dès que possible. Souvent, l'annonce d'un exploit de sécurité est accompagné d'un correctif (ou de code source corrigeant le problème). Le correctif est alors appliqué au paquetage de Red Hat Enterprise Linux testé par l'équipe d'assurance qualité de Red Hat et édité en tant que mise à jour d'errata. Toutefois, si l'annonce n'inclut pas de correctif, un développeur de Red Hat travaillera avec la personne qui s'occupe du logiciel pour résoudre le problème. Une fois le problème corrigé, le paquetage est testé et édité en tant que mise à jour d'errata.
Si une mise à jour d'errata est publiée pour un logiciel utilisé sur votre système, il est fortement recommandé que vous mettiez à jour les paquetages concernés dès que possible, afin de réduire la période pendant laquelle votre système est potentiellement exploitable.
Lors de la mise à jour de logiciels sur votre système, il est important de télécharger ces mises à jour à partir d'une source digne de confiance. Un pirate peut facilement reconstruire la version d'un paquetage avec le même numéro de version que celui qui est supposé corriger le problème, mais avec un exploit de sécurité différent et le publier sur l'internet. Dans une telle situation, l'utilisation de mesures de sécurité consistant à vérifier les fichiers avec le RPM original, ne détecteront pas l'exploit. Il est donc très important de télécharger les RPM de sources dignes de confiance comme le site Red Hat, Inc., et de vérifier la signature du paquetage afin de contrôler son intégrité.
Red Hat offre deux méthodes pour obtenir des informations sur les mises à jour d'errata :
Répertoriées et disponibles par téléchargement sur Red Hat Network
Répertoriées et sans liens sur le site Web d'errata de Red Hat
En commençant par la ligne de produits de Red Hat Enterprise Linux, les paquetages mis à jour peuvent uniquement être téléchargés depuis Red Hat Network. Bien que le site Web d'errata de Red Hat contienne des informations à jour, il ne contient pas les paquetages actuels prêts à être téléchargés.
Red Hat Network vous permet d'automatiser la plupart des processus de mises à jour. Il détermine les paquetages RPM nécessaires pour votre système, les télécharge depuis un dépôt sécurisé, vérifie la signature RPM pour s'assurer qu'ils n'ont pas été modifiés et les met à jour. L'installation de paquetages peut se produire immédiatement ou peut être programmée lors d'une certaine période de temps.
Red Hat Network requiert un profil de système pour chaque ordinateur devant être mis à jour. Le profil de système contient des informations matérielles et logicielles sur le système. Ces informations sont confidentielles et ne sont données à personne d'autre. Elles sont seulement utilisées pour déterminer les mises à jour d'errata qui peuvent être appliquées à chaque système. Sans elles, Red Hat Network ne peut pas déterminer si un système a besoin de mises à jour. Lorsqu'un errata de sécurité (ou tout type d'errata) est publié, Red Hat Network envoie un message électronique avec une description de l'errata ainsi qu'une liste des systèmes affectés. Pour appliquer la mise à jour, utilisez l'agent de mise à jour Red Hat ou programmez la mise à jour du paquetage grâce au site Web http://rhn.redhat.com.
Red Hat Enterprise Linux inclut l'Outil de notification d'alertes de Red hat Network, une icône de tableau de bord pratique qui affiche des alertes visibles lorsqu'une mise à jour pour un système Red Hat Enterprise Linux existe. Reportez-vous à l'URL suivant pour de plus amples informations sur l'applet : http://rhn.redhat.com/help/basic/applet.html
Avant d'installer tout errata de sécurité, assurez-vous de bien lire toutes les instructions spéciales contenues dans le rapport d'errata et appliquez-les comme il l'est demandé. Reportez-vous à Section 33.3.1.5, « Application des changements » pour obtenir des instructions générales sur l'application des modifications résultant d'une mise à jour d'errata.
Lorsque les rapports d'errata de sécurité sont publiés, ils se trouvent sur le site Web d'errata de Red Hat disponible à l'adresse http://www.redhat.com/security/. Depuis cette page, sélectionnez le produit et la version s'appliquant à votre système, puis choisissez security (sécurité) en haut de la page pour n'afficher que les alertes de sécurité de Red Hat Enterprise Linux. Si le synopsis de l'une des alertes décrit un paquetage utilisé sur votre système, cliquez sur le synopsis pour obtenir davantage d'informations.
La page de détails décrit l'exploit de sécurité et toutes autres instructions spéciales qui doivent être effectuées en plus de la mise à jour pour réparer le trou de sécurité.
Pour télécharger le(s) paquetage(s) mis à jour, cliquez sur le lien pour vous connecter à Red Hat Network, cliquez sur le(s) nom(s) de paquetage et enregistrez-le(s) sur le disque dur. Il est fortement recommandé de créer un nouveau répertoire, comme /tmp/updates
et d'y enregistrer tous les paquetages téléchargés.
Tous les paquetages de Red Hat Enterprise Linux portent la signature de la clé GPG de Red Hat, Inc. GPG signifie GNU Privacy Guard, ou GnuPG, un paquetage de logiciel libre utilisé pour assurer l'authenticité des fichiers distribués. Par exemple, une clé privée (clé secrète) appartenant à Red Hat verrouille le paquetage alors que la clé publique déverrouille et vérifie le paquetage. Si la clé publique distribuée par Red Hat ne correspond pas à la clé privée durant la vérification de RPM, il se peut que le paquetage ait été modifié. Il n'est donc pas digne de confiance.
L'utilitaire RPM dans Red Hat Enterprise Linux essaie automatiquement de vérifier la signature GPG d'un paquetage RPM avant de l'installer. Si la clé GPG de Red Hat n'est pas installée, installez la depuis un emplacement sécurisé et statique comme par exemple un CD-ROM d'installation Red Hat Enterprise Linux.
En supposant que le CD-ROM soit monté sur /mnt/cdrom
, utilisez la commande suivante pour l'importer dans le porte-clés (une base de données de clés sécurisées sur le système) :
rpm --import /mnt/cdrom/RPM-GPG-KEY
Pour afficher la liste de toutes les clés installées pour la vérification de RPM, exécutez la commande suivante :
rpm -qa gpg-pubkey*
Pour la clé de Red Hat, la sortie inclut les éléments suivants :
gpg-pubkey-db42a60e-37ea5438
Pour afficher les détails d'une clé spécifique, utilisez la commande rpm -qi
suivie de la sortie de la commande précédente, comme dans l'exemple ci-après :
rpm -qi gpg-pubkey-db42a60e-37ea5438
Il est extrêmement important que vous vérifiez la signature des fichiers RPM avant de les installer afin d'obtenir la garantie qu'ils n'ont pas été modifiés par rapport à l'édition Red Hat, Inc. des paquetages. Pour vérifier l'ensemble des paquetages téléchargés en une seule opération, exécutez la commande suivante :
rpm -K /tmp/updates/*.rpm
Pour chaque paquetage, si la clé GPG est bien vérifiée, la commande renvoie en sortie gpg OK
. Si elle ne l'est pas, assurez-vous que vous utilisez la bonne clé publique de Red Hat et que vous vérifiez la source du contenu. Les paquetages qui ne passent pas les vérifications GPG ne devraient pas être installés. En effet, il est possible qu'ils aient été modifiés par un tiers.
Après la vérification de la clé GPG et le téléchargement de tous les paquetages associés au rapport d'errata, installez ces derniers depuis une invite du shell en étant connecté en tant que super-utilisateur.
Cette opération peut être effectuée en toute sécurité pour la plupart des paquetages (à l'exception des paquetages du noyau) en exécutant la commande suivante :
rpm -Uvh /tmp/updates/*.rpm
Pour les paquetages du noyau, utilisez la commande suivante :
rpm -ivh /tmp/updates/<kernel-package>
Remplacez <kernel-package>
dans l'exemple précédent par le nom du RPM du noyau.
Une fois que l'ordinateur a été redémarré en toute sécurité en utilisant le nouveau noyau, il est possible de supprimer l'ancien à l'aide de la commande suivante :
rpm -e <old-kernel-package>
Remplacez <old-kernel-package>
dans l'exemple précédent par le nom du RPM de l'ancien noyau.
Vous n'avez pas besoin de supprimer l'ancien noyau. Le chargeur de démarrage par défaut, GRUB, permet d'installer de multiples noyaux, sélectionnés depuis un menu au démarrage.
Avant d'installer tout errata de sécurité, assurez-vous de bien lire toutes les instructions spéciales contenues dans le rapport d'errata et appliquez-les comme il l'est demandé. Reportez-vous à Section 33.3.1.5, « Application des changements » pour obtenir des instructions générales sur l'application des modifications résultant d'une mise à jour d'errata.
Après le téléchargement et l'installation d'errata de sécurité via Red Hat Network ou le site Web d'errata de Red Hat, il est important de ne plus utiliser les anciens logiciels et de n'utiliser que les nouveaux. La manière de procéder dépend du type des logiciels qui ont été mis à jour. La liste suivante énumère de manière détaillée les catégories générales des logiciels et fournit des instructions quant à l'utilisation des versions mises à jour après la mise à niveau d'un paquetage.
D'une manière générale, le redémarrage du système est la manière la plus sûre de garantir que la nouvelle version d'un paquetage de logiciels est bien utilisée ; néanmoins, cette option n'est pas toujours offerte à l'administrateur système.
Les applications de l'espace utilisateur représentent tout programme pouvant être démarré par un utilisateur du système. De manière générale, de telles applications sont utilisées seulement lorsqu'un utilisateur, un script ou un utilitaire de tâches automatisées les lance et que l'opération ne dure pas longtemps.
Une fois qu'une application de l'espace utilisateur est mise à jour, arrêtez toute instance de l'application sur le système et relancez le programme afin d'utiliser la version mise à jour.
Le noyau est l'élément logiciel de base du système d'exploitation Red Hat Enterprise Linux. Il gère l'accès à la mémoire, le processeur et les périphériques ainsi que toutes les tâches programmées.
En raison de sa fonction centrale, le noyau ne peut pas être redémarré sans arrêter également l'ordinateur. Par conséquent, une version mise à jour du noyau ne peut être utilisée avant que le système ne soit redémarré.
Les bibliothèques partagées sont des unités de code, comme glibc
, qui sont utilisées par un certain nombre d'applications et de services. Étant donné que les applications utilisant une bibliothèque partagée chargent le code lors de leur initialisation, il est nécessaire d'arrêter et de redémarrer toute application utilisant une bibliothèque mise à jour.
Afin de déterminer les applications en cours d'exécution qui sont liées à une bibliothèque particulière, utilisez la commande lsof
, comme dans l'exemple suivant :
lsof /usr/lib/libwrap.so*
Cette commande renvoie une liste de tous les programmes en cours d'exécution qui utilisent les enveloppeurs TCP pour le contrôle de l'accès des hôtes. Par conséquent, tout programme faisant partie de la liste doit être arrêté et redémarré si le paquetage tcp_wrappers
est mis à jour.
Les services SysV sont des programmes serveur persistants lancés lors du processus de démarrage. Parmi des exemples de services sysV figurent sshd
, vsftpd
et xinetd
.
Parce que ces programmes restent en mémoire tant que l'ordinateur est opérationnel, chaque service SysV mis à jour doit être arrêté et redémarré après la mise à niveau du paquetage. Pour ce faire, utilisez l'outil de configuration des services ou connectez-vous dans un shell root et à l'invite exécutez la commande /sbin/service
comme dans l'exemple ci-après :
/sbin/service <service-name>
restart
Dans l'exemple précédent, remplacez <service-name>
par le nom du service, tel que sshd
.
xinetd
Les services contrôlés par le super-service xinetd
tournent seulement lorsqu'une connexion active existe. Parmi des exemples de services contrôlés par xinetd
figurent Telnet, IMAP et POP3.
Étant donné que de nouvelles instances de ces services sont lancées par xinetd
lors de la réception de toute nouvelle requête, les connexions établies après une mise à niveau sont traitées par le logiciel mis à jour. Toutefois, s'il existe des connexions actives lors de la mise à niveau du service contrôlé par xinetd
, ces dernières seront traitées par l'ancienne version du logiciel.
Pour arrêter d'anciennes instances d'un service particulier contrôlé par xinetd
, mettez à niveau le paquetage de ce service, puis arrêtez tous les processus actuellement en cours d'exécution. Pour déterminer si le processus tourne, utilisez la commande ps
, puis utilisez kill
ou killall
pour arrêter les instances courantes du service.
Par exemple, si des paquetages imap
d'errata de sécurité sont publiés, mettez à niveau les paquetages, puis, en tant que super-utilisateur, saisissez la commande suivante à une invite du shell :
ps -aux | grep imap
Cette commande renvoie toutes les sessions IMAP actives. Des sessions individuelles peuvent alors être arrêtées en exécutant la commande suivante :
kill <PID>
Si il n'est pas possible de terminer la session, utiliser cette commande à la place :
kill -9 <PID>
Dans l'exemple précédent, remplacez <PID>
par le numéro d'identification du processus (qui se trouve dans la deuxième colonne de la commande ps
) correspondant à une session IMAP.
Pour mettre fin à toutes les sessions IMAP, exécutez la commande suivante :
killall imapd
Avec Red Hat Enterprise Linux sont installés des outils avancés permettant le filtrage de paquets réseau — le processus consistant à contrôler les paquets réseau lorsqu'ils entrent, traversent et sortent de la pile réseau au sein du noyau. Les versions de noyaux antérieures à 2.4 utilisaient ipchains
pour le filtrage de paquets et faisaient appel à des listes de règles appliquées aux paquets à chaque étape du processus de filtrage. Avec l'arrivée du noyau 2.4 est apparu iptables
(aussi appelé netfilter), qui est semblable à la commande ipchains
mais multiplie les potentialités et le degré de contrôle disponible en matière de filtrage de paquets réseau.
Ce chapitre décrit en détail les principes de base en matière de filtrage de paquets, explique les différences entre ipchains
et iptables
, présente les différentes options disponibles avec iptables
et finalement montre comment maintenir l'intégrité des règles de filtrage entre les démarrages du système.
Pour obtenir des instructions sur la construction de règles iptables
ou sur la configuration d'un pare-feu basé sur ces règles, reportez-vous à la Section 34.1.7, « Ressources supplémentaires ».
Le mécanisme de pare-feu par défaut avec le noyau 2.4 et des noyaux plus récents est iptables
, mais iptables
ne peut pas être utilisé si ipchains
est déjà en cours d'exécution. Si ipchains
est présent au démarrage, le noyau émet un message d'erreur et ne réussit pas à démarrer iptables
.
Ces messages d'erreur n'affectent pas la fonctionnalité d'ipchains
.
Le noyau Linux utilise Netfilter, la capacité de filtrer des paquets, permettant à certains d'entre eux d'être reçus par le système ou de le traverser alors que d'autres sont bloqués. Le netfilter du noyau contient trois tables ou listes de règles intégrées, à savoir :
filter
— Table par défaut pour le traitement des paquets réseau.
nat
— Table utilisée pour modifier les paquets qui créent une nouvelle connexion et utilisée pour la traduction d'adresses réseau (ou NAT de l'anglais Network Address Translation).
mangle
— Table utilisée pour la modification de types spécifiques de paquets.
Chacune de ces tables comporte à son tour un groupe de chaînes intégrées qui correspondent aux actions effectuées par netfilter
sur le paquet.
Les chaînes pour la table filter
sont les suivantes :
INPUT — Cette chaîne s'applique aux paquets ciblés pour l'hôte.
OUTPUT — Cette chaîne s'applique aux paquets réseau générés localement.
FORWARD — Cette chaîne s'applique aux paquets routés à travers l'hôte.
Les chaînes pour la table nat
sont les suivantes :
PREROUTING — Cette chaîne modifie les paquets lorsqu'ils arrivent.
OUTPUT — Cette chaîne modifie des paquets réseau générés localement avant qu'ils ne soient envoyés.
POSTROUTING — Cette chaîne modifie les paquets avant qu'ils ne soient envoyés.
Les chaînes intégrées pour la table mangle
sont les suivantes :
INPUT — Cette chaîne modifie des paquets réseau ciblés pour l'hôte.
OUTPUT — Cette chaîne modifie des paquets réseau générés localement avant qu'ils ne soient envoyés.
FORWARD — Cette chaîne modifie des paquets réseau routés à travers l'hôte.
PREROUTING — Cette chaîne modifie les paquets réseau entrants avant qu'ils ne soient routés.
POSTROUTING — Cette chaîne modifie les paquets avant qu'ils ne soient envoyés.
Chaque paquet réseau reçu ou envoyé par un système Linux est soumis à au moins une règle. Un paquet peut toutefois être soumis à plusieurs règles à l'intérieur de chaque table avant d'arriver à la fin de la chaîne. La structure et le rôle de ces règles peuvent changer, mais elles visent généralement à identifier un paquet en provenance ou à destination d'une adresse IP donnée ou d'un groupe d'adresses, lors de l'utilisation d'un protocole et d'un service réseau particuliers.
Par défaut, les règles pare-feu sont sauvegardées dans les fichiers /etc/sysconfig/iptables
ou /etc/sysconfig/ip6tables
.
Les services iptables
commencent avant tout service lié à DNS quand un système Linux est démarré. Cela signifie que les règles pare-feu ne peuvent référencer que des adresses IP numériques (par exemple, 192.168.0.1). Dans de telles règles, les noms de domaine (par exemple, host.example.com) causent des erreurs.
Indépendamment de leur destination, lorsque les paquets correspondent à une règle précise présente dans une des tables, ils se voient assigner une cible ou font l'objet d'une certaine action. Si la règle spécifie une cible de type ACCEPT
pour un paquet vérifié, il évite les autres contrôles de règles et peut procéder vers sa destination. En revanche, si une règle spécifie une cible de type DROP
, le paquet est abandonné et se voit refuser l'accès au système ; rien n'est envoyé en retour à l'hôte qui a expédié le paquet. Si une règle spécifie une cible de type QUEUE
, le paquet est mis en attente dans l'espace-utilisateur (aussi appelé user-space). Finalement, si une règle spécifie une cible de type REJECT
en option, le paquet est "abandonné" par rejet et dans ce cas, un "paquet d'erreur" est envoyé en retour à l'expéditeur.
Chaque chaîne dispose d'une politique par défaut pour accepter ACCEPT
, DROP
, REJECT
, ou QUEUE
. Si aucune des règles présentes dans la chaîne ne s'applique au paquetage, celui-ci est traité en fonction de la politique par défaut de la chaîne.
La commande iptables
permet de configurer ces tables et d'en créer de nouvelles si nécessaire.
Au premier abord, ipchains
et iptables
semblent assez similaires. Les deux méthodes de filtrage de paquets font appel à des chaînes de règles actives à l'intérieur du noyau Linux pour décider du traitement des paquets qui répondent à certaines règles. Cependant, la commande iptables
représente une manière plus flexible de filtrer les paquets en donnant à l'administrateur un degré de contrôle plus élevé, sans pour autant ajouter un degré plus élevé de complexité dans le système.
Remarquez qu'il existe des différences notables entre ipchains
et iptables
:
iptables
, chaque paquet filtré est traité en utilisant les règles d'une seule chaîne plutôt que de multiples chaînes.
Par exemple, un paquet identifié comme FORWARD pénétrant dans un système à l'aide de ipchains
devrait passer à travers les chaînes INPUT, FORWARD et OUTPUT afin de pouvoir poursuivre sa progression vers sa destination. Toutefois, iptables
envoie les paquets uniquement à la chaîne INPUT s'ils sont destinés au système local et les envoie seulement à la chaîne OUTPUT, s'ils ont été créés par le système local. Pour cette raison, il est très important de bien placer la règle destinée au contrôle d'un paquet spécifique dans la règle qui effectue le traitement proprement dit du paquet.
Dans ipchains
, les paquets qui répondaient aux critères d'une règle présente dans une chaîne pouvaient être dirigés vers la cible DENY. Cette cible doit être remplacée par une cible DROP dans iptables
.
Dans ipchains
, l'ordre des options de règles n'est pas important.
La commande iptables
utilise une syntaxe plus stricte. Ainsi, dans la commande iptables
, le protocole spécifique (ICMP, TCP ou UDP) doit être précisé avant les ports d'origine ou de destination.
Par exemple, lorsque le type d'interface réseau à utiliser dans une règle est précisé, seules des interfaces entrantes (option -i
) peuvent être employées avec les chaînes INPUT ou FORWARD et des interfaces sortantes (option -o
) avec les chaînes FORWARD ou OUTPUT.
En d'autres termes, les chaînes INPUT et les interfaces entrantes collaborent ; les chaînes OUTPUT et les interfaces sortantes collaborent. Les chaînes FORWARD travaillent à la fois avec les interfaces entrantes et sortantes.
Les chaînes OUTPUT ne sont plus utilisées par les interfaces entrantes, et les chaînes INPUT ne sont pas vues par les paquets qui traversent les interfaces sortantes.
Ceci n'est pas une liste complète des modifications. Pour des informations plus spécifiques, consultez la Section 34.1.7, « Ressources supplémentaires ».
Les règles permettant le filtrage de paquets sont mises en oeuvre en exécutant la commande iptables
. Les aspects suivants du paquet sont le plus souvent utilisés comme critères :
Type de paquet — Spécifie le type de paquets que la commande filtre.
Origine/Destination du paquet — Spécifie les paquets que la commande filtre en fonction de l'origine ou de la destination du paquet.
Cible — Spécifie l'action à appliquer sur les paquets répondant aux critères évoqués ci-dessus.
Consultez les Section 34.1.3.4, « Options de concordance des IPTables » et Section 34.1.3.5, « Options de cible » pour plus d'informations sur les options spécifiques qui traitent des aspects d'un paquet.
Les options utilisées avec des règles iptables
données doivent être regroupées logiquement en fonction du but et des conditions de la règle globale, afin que la règle soit valide. Le reste de cette section examine des options couramment utilisées avec la commande iptables
.
Beaucoup de commandes iptables
ont la structure suivante :
iptables [-t <table-name>
] <command>
<chain-name>
\ <parameter-1>
<option-1>
\ <parameter-n>
<option-n>
<table-name>
— Spécifie la table à laquelle la règle s'applique. Si elle est omise, la table filter
est utilisée.
<command>
— Spécifie l'action à effectuer comme ajouter ou supprimer la règle.
<chain-name>
— Spécifie la chaîne à éditer, créer ou supprimer.
Les paires <parameter>-<option>
— Les paramètres et options associés qui spécifient comment traiter un paquet qui correspond à la règle.
La longeur et la complexité d'une commande iptables
peuvent changer significativement, selon son objectif.
Par exemple, une commande pour supprimer une règle d'une chaîne peut être très courte :
iptables -D
<chain-name> <line-number>
Par contre, une commande qui ajoute une règle qui filtre des paquets d'un sous-réseau particulier à l'aide d'une variété de paramètres et d'options spécifiques peut être plutôt longue. À la construction de commandes iptables
, il est important de savoir que les paramètres et les options requièrent des paramètres et des options supplémentaires pour construire une règle valide. Cela peut entraîner un effet de cascade, avec des paramètres supplémentaires nécessitant encore plus de paramètres. Jusqu'à ce que chaque paramètre et option nécessitant un autre ensemble d'options soit satisfait, la règle n'est pas valide.
Saisissez la commande iptables -h
pour obtenir une liste exhaustive de structures de la commande iptables
.
Les options de commande donnent à iptables
l'instruction d'exécuter une action spécifique. Une seule option de commande est autorisée pour chaque commande iptables
. À l'exception de la commande d'aide, toutes les autres commandes doivent être écrites en majuscules.
Les commandes iptables
sont comme suit :
-A
— Ajoute la règle à la fin de la chaîne spécifique. Contrairement à l'option -I
décrite ci-dessous, elle ne prend pas d'argument integer. Elle ajoute toujours la règle à la fin de la chaîne spécifique.
-C
— Vérifie une règle donnée avant de l'ajouter à la chaîne spécifiée par l'utilisateur. Cette commande peut vous aider à écrire des règles iptables
compliquées en vous demandant des paramètres et des options supplémentaires.
-D <integer> | <rule>
— Élimine une règle à l'intérieur d'une chaîne donnée de façon numérique (comme par exemple en utilisant 5
pour la cinquième règle d'une chaîne) ou selon la spécification de la règle. La spécification de la règle doit correspondre exactement à une règle existante.
-E
— Renomme une chaîne définie par l'utilisateur. Une chaîne définie par l'utilisateur représente toute chaîne autre que les chaînes pré-existantes par défaut. (Référez-vous à l'option -N
ci-dessous, pour des informations sur la création de chaînes définies par l'utilisateur.) Ce n'est qu'une modification mineure puisqu'elle n'affecte pas la structure de la table.
Si vous tentez de renommer une des chaînes par défaut, le système rapporte une erreur Match not found
. Vous ne pouvez pas renommer les chaînes par défaut.
-F
— Purge la chaîne sélectionnée, entraînant par là-même l'élimination de toutes les règles de la chaîne. Si aucune chaîne n'est spécifiée, cette commande supprime chaque règle contenue dans chaque chaîne.
-h
— Fournit une liste des structures des commandes, ainsi qu'un bref résumé des paramètres et options des commandes.
-I [<integer>]
— Insère une règle à l'intérieur d'une chaîne, à un point précis, spécifié par un argument integer défini par l'utilisateur. Si aucun argument n'est spécifié, la règle est insérée en haut de la chaîne.
Comme mentionné précédemment, l'ordre des règles dans une chaîne détermine quelle règles s'appliquent à quels paquets. Cela est important quand vous ajoutez des règles à l'aide de l'option -A
ou de -I
.
Cela est particulièrement important quand vous ajoutez des règles à l'aide de -I
avec un argument integer. Si vous spécifiez un numéro quand vous ajoutez une règle à une chaîne, iptables
ajoute la nouvelle règle avant (ou au-dessus) de la règle existante.
-L
— Établit la liste complète des règles dans la chaîne indiquée après la commande. Pour dresser une liste de toutes les règles présentes dans toutes les chaînes contenues dans la table filter
par défaut, ne précisez ni chaîne, ni table. Sinon, la syntaxe à utiliser pour établir la liste des règles contenues dans une chaîne donnée d'une table précise, doit être la suivante :
iptables -L <chain-name>
-t <table-name>
Pour toute information sur les options supplémentaires utilisées avec l'option de commande -L
qui fournit les numéros des règles et permet une description plus détaillée de ces dernières, consultez la Section 34.1.3.6, « Options de listing ».
-N
— Crée une nouvelle chaîne avec un nom spécifié par l'utilisateur. Le nom de la chaîne doit être exclusif, sinon un message d'erreur est affiché.
-P
— Définit la politique par défaut d'une chaîne donnée, de façon à ce que des paquets traversant une chaîne entière sans satisfaire les critères d'une règle soient envoyés vers la cible spécifiée, telle que ACCEPT ou DROP.
-R
— Remplace une règle dans une chaîne donnée. Il est impératif d'utiliser un numéro de règle après le nom de chaîne. La première règle dans une chaîne correspond à la règle numéro un.
-X
— Supprime une chaîne spécifiée par un utilisateur. L'élimination d'une chaîne intégrée appartenant à une table quelconque n'est pas permise.
-Z
— Remet à zéro les compteurs d'octets et de paquets dans toutes les chaînes pour une table spécifique.
Une fois que certaines commandes iptables
ont été spécifiées (y compris celles utilisées pour l'ajout, l'élimination, l'insertion ou le remplacement de règles à l'intérieur d'une chaîne donnée), il est nécessaire d'ajouter d'autres paramètres pour la construction d'une règle de filtrage de paquets.
-c
— Effectue une remise à zéro des compteurs pour une règle donnée. Ce paramètre accepte les options PKTS
(paquets) et BYTES
(octets) pour spécifier le compteur à remettre à zéro.
-d
— Définit le nom d'hôte du destinataire, l'adresse IP ou le réseau du paquetage qui correspond à la règle. Lorsqu'un réseau répond aux critères de la règle, les formats suivants sont pris en charge pour l'adresse IP/masque réseau :
— où N.N.N.N
/M.M.M.M
N.N.N.N
correspond à la plage d'adresses IP et M.M.M.M
au masque réseau.
— où N.N.N.N
/M
N.N.N.N
correspond à la plage d'adresses IP et M
au masque réseau.
-f
— Applique cette règle uniquement aux paquets fragmentés.
En utilisant le point d'exclamation comme option (!
) après ce paramètre, vous spécifiez que seuls les paquets non-fragmentés seront comparés aux critères des règles.
Il est recommnandé de faire la distinction entre les paquets fragmentés et non fragmentés même si les paquets fragmentés font partie intégrante du protocole IP.
Conçus à l'origine pour permettre aux paquets IP de traverser les réseaux avec des tailles de cadre différentes, aujourd'hui la fragmentation est utilisée plus communément pour générer des attaques DoS à l'aide de paquets mal formés. Il est bon de noter que IPv6 ne permet aucune fragmentation.
-i
— Règle l'interface réseau entrante, telle que eth0
ou ppp0
. Avec iptables
, ce paramètre optionnel ne peut être utilisé qu'avec des chaînes INPUT et FORWARD lorsqu'elles sont utilisées avec la table filter
et la chaîne PREROUTING lorsqu'elle est utilisée avec les tables nat
et mangle
.
Ce paramètre prend également en charge les options spéciales ci-dessous :
Point d'exclamation (!
) — Inverse la directive, c'est-à-dire que toutes les interfaces spécifiées sont exclues de cette règle.
Le symbole plus (+
) — Représente un caractère générique utilisé pour comparer toutes les interfaces qui correspondent à la chaîne spécifiée. Par exemple, le paramètre -i eth+
appliquerait cette règle à toutes les interfaces Ethernet, mais ne prendrait pas en compte les autres interfaces, comme ppp0
.
Si le paramètre -i
est utilisé sans qu'aucune interface ne soit spécifiée, toutes les interfaces sont affectées par la règle.
-j
— Passe à la cible spécifiée quand un paquet correspond à une règle particulière.
Les cibles standards sont ACCEPT
, DROP
, QUEUE
, et RETURN
.
Des options étendues sont disponibles grâce aux modules chargés par défaut avec le paquetage RPM iptables
de Red Hat Enterprise Linux. Les cibles valides dans ces modules incluent parmi d'autres LOG
, MARK
et REJECT
. Consultez la page de manuel d'iptables
pour obtenir plus d'informations sur les cibles mentionnées ici et sur d'autres cibles.
Il est également possible de diriger un paquet correspondant à une règle vers une chaîne définie par l'utilisateur, située en dehors de la chaîne actuelle, afin que d'autres règles puissent être appliquées à ce paquet.
Si aucune cible n'est spécifiée, le paquet continue sans qu'aucune autre action ne soit entreprise. Ceci étant, le compteur de cette règle avance tout de même d'une unité.
-o
— Paramètre l'interface sortante pour une règle donnée et ne peut être utilisée qu'avec des chaînes OUTPUT et FORWARD dans la table filter
et la chaîne POSTROUTING dans les tables nat
et mangle
. Les options de ce paramètre sont les mêmes que pour les paramètres relatifs aux interfaces réseau entrantes (-i
).
-p <protocol>
— Paramètre le protocole IP pour la règle, qui peut être icmp
, tcp
, udp
ou all
, afin qu'il corresponde à tous les protocoles possibles. De plus, il est possible d'utiliser tout protocole inclus dans le fichier /etc/protocols
.
Le protocole "all
" signifie que la règle est applicable à tous les protocoles pris en charge. Si aucun protocole n'est listé avec cette règle, il devient par défaut "all
".
-s
— Définit l'origine d'un paquet particulier en utilisant la même syntaxe que pour le paramètre de destination (-d
).
Différents protocoles réseau offrent des options de contrôle de concordance spécifiques qui peuvent être configurées de manière à comparer un paquet donné en utilisant ce protocole. Cependant, il est nécessaire d'identifier préalablement le protocole en question dans la commande iptables
. Par exemple, -p
active des options pour un protocole spécifié. Notez que vous pouvez également utiliser l'ID du protocole, plutôt que son nom. Consultez les exemples suivants, tous ont le même effet :
<protocol-name>
iptables -A INPUT -p icmp --icmp-type any -j ACCEPT
iptables -A INPUT -p 5813 --icmp-type any -j ACCEPT
Les définitions de services sont fournies dans le fichier /etc/services
. Pour une meilleure lisibilité, il est recommandé d'utiliser les noms de services plutôt que les numéros de port.
Sécurisez le fichier /etc/services
pour éviter les corrections non autorisées. Si ce fichier est modifiable, les pirates peuvent l'utiliser pour activer les ports sur la machine que vous avez fermée. Pour sécuriser ce fichier, tapez la commande suivante comme racine :
[root@myServer ~]# chown root.root /etc/services [root@myServer ~]# chmod 0644 /etc/services [root@myServer ~]# chattr +i /etc/services
Cela évite que le fichier soit renommé, supprimé ou la création de liens.
Les options de concordance disponibles pour le protocole TCP (-p tcp
) sont les suivantes :
--dport
— Définit le port de destination pour le paquet.
Pour configurer cette option, utilisez un nom de service de réseau (comme www ou smtp); un numéro de port; ou une plage de numéros de ports.
Pour indiquer une plage de numéros de port, il suffit de séparer les deux numéros par le symbole des deux points (:
), comme dans l'exemple suivant : -p tcp --dport 3000:3200
. La plus grande plage valide est 0:65535
.
Utilisez un point d'exclamation (!
) après l'option --dport
pour comparer tous les paquets qui n'utilisent pas ce service réseau ou port.
Pour naviguer les noms et les alias de services de réseau et les numéros de ports qu'ils utilisent, consultez le fichier /etc/services
.
L'option de concordance --destination-port
est identique à --dport
.
--sport
— Paramètre le port d'origine du paquet, en utilisant les mêmes options que --dport
. L'option de concordance --source-port
est identique à l'option --sport
.
--syn
— S'applique à tous les paquets TCP, appelés communément paquets SYN, conçus pour initier la communication. Aucun paquet transportant des données de charge utiles n'est touché.
Utilisez un point d'exclamation (!
) après l'option --syn
pour faire correspondre tous les paquets non-SYN.
--tcp-flags <tested flag list> <set flag list>
— Permet aux paquets TCP qui ont des ensembles de bits spécifiques (indicateurs) à correspondre à une règle.
L'option de concordance --tcp-flags
accepte deux paramètres. Le premier paramètre est le masque, une liste d'indicateurs séparés par une virgule à examiner dans le paquet. Le second se rapporte à une liste d'indicateurs séparés par une virgule qui doit être définie pour la concordance pour que la règle corresponde.
Les indicateurs disponibles sont les suivants :
ACK
FIN
PSH
RST
SYN
URG
ALL
NONE
Par exemple, une règle iptables
contenant les spécifications suivantes ne comparera que les paquets TCP ayant l'indicateur SYN défini et les indicateurs ACK et FIN non-définis.
--tcp-flags ACK,FIN,SYN SYN
Utilisez un point d'exclamation (!
) après l'option --tcp-flags
pour inverser l'effet de l'option de concordance.
--tcp-option
— Essaie de comparer des options spécifiques à TCP qui peuvent être définies dans un paquet donné. Cette option de concordance peut aussi être inversée en utilisant un point d'exclamation (!
).
Les options de concordance suivantes s'appliquent au protocole UDP (-p udp
) :
--dport
— Spécifie le port de destination du paquet UDP, utilisant le nom du service, le numéro de port ou une plage de numéros de ports. L'option de concordance --destination-port
est identique à l'option --dport
.
--sport
— Spécifie le port d'origine du paquet UDP, utilisant le nom du service, le numéro de port ou une plage de numéros de ports. L'option de concordance --source-port
est identique à l'option --sport
.
Pour les options --dport
et --sport
pour indiquer une plage de numéros de port, il suffit de séparer les deux numéros par le symbole des deux points (:
), comme dans l'exemple suivant : -p tcp --dport 3000:3200
. La plus grande plage valide est 0:65535
.
Les options de concordance suivantes sont disponibles pour le protocole Internet Control Message Protocol (ICMP) (-p icmp
) :
--icmp-type
— Détermine le nom ou le numéro du type d'ICMP à comparer avec cette règle. Une liste de noms ICMP valides est disponible en tapant la commande iptables -p icmp -h
.
Des options de concordance supplémentaires sont disponibles à travers les modules chargés par la commande iptables
.
Pour utiliser un module d'option de concordance, chargez le module en l'appelant par son nom à l'aide de l'option -m
, où <module-name>
<module-name>
correspond au nom du module.
Un nombre important de modules est disponible par défaut. Il est même possible de créer des modules qui fournissent des fonctionnalités supplémentaires.
Ci-dessous figure une liste partielle des modules les plus couramment utilisés :
le module limit
— limite le nombre de paquets correspondant à une règle particulière.
Utilisé avec la cible LOG
, le module limit
peut empêcher une inondation de paquets correspondants se propageant dans le journal du système avec des messages répétitifs ou utilisant des ressources du système.
Reportez-vous à la Section 34.1.3.5, « Options de cible » pour obtenir davantage d'informations sur la cible LOG
.
Le module limit
active les options suivantes :
--limit
— Détermine le nombre maximum de concordances pour un espace-temps donné, grâce à un modificateur nombre et temps paramétré selon le format suivant :
. Par exemple, en écrivant <value>/<period>
--limit 5/hour
, une règle effectue son contrôle de concordance seulement cinq fois en une heure.
Les périodes peuvent être spécifiées en secondes, minutes, heures, ou jours.
Si aucun modificateur nombre ou temps n'est précisé, une valeur par défaut de 3/hour
(3 fois en une heure) sera retenue.
--limit-burst
— Détermine le nombre de paquets pouvant être comparés à une règle, à un moment donné.
Cette option est spécifiée en tant qu'integer et devrait être utilisée conjointement avec l'option --limit
.
Si aucun modificateur nombre ou temps n'est précisé, une valeur par défaut de cinq (5 fois en une heure) sera retenue.
le module state
— Active la concordance d'état.
Le module state
active les options suivantes :
--state
— Établit la correspondance d'un paquet avec les états de connexion suivants :
ESTABLISHED
— Le paquet concordant est associé à d'autres paquets dans une connexion établie. Vous devez accepter cet état si vous le voulez pour maintenir une connexion entre le client et le serveur.
INVALID
— Ce paquet concordant ne peut être pas lié à une connexion connue.
NEW
— Le paquet concordant crée une nouvelle connexion ou fait partie d'une connexion à double sens qui n'a pas été vue précédemment. Vous devez accepter cet état si vous désirez autoriser de nouvelles connexions à un service.
RELATED
— Le paquet concordant établit une nouvelle connexion qui est d'une manière ou d'une autre apparentée à une connexion existante. FTP en est un exemple, il utilise une connexion pour le contrôle du trafic (port 21), et une connexion séparée pour le transfert des données (port 20).
Ces états de connexion peuvent être employés de concert avec d'autres à condition qu'ils soient séparés par des virgules, comme par exemple : -m state --state INVALID,NEW
.
Le module mac
— Active la concordance d'une adresse MAC matérielle.
Le module mac
active l'option suivante :
--mac-source
— Établit la correspondance avec une adresse MAC de la carte d'interface réseau qui a envoyé le paquet. Pour exclure une adresse MAC d'une règle, placez un point d'exclamation (!
) après l'option de concordance --mac-source
.
Consultez la page de manuel pour les iptables
pour plus d'options de concordance disponibles à travers les modules.
Une fois qu'un paquet concorde avec une règle spécifique, cette dernière peut diriger le paquet vers un certain nombre de cibles qui décideront de son traitement et, si possible, effectueront des actions supplémentaires. Chaque chaîne possède une cible par défaut qui est utilisée si aucune des règles de cette chaîne ne correspond à un paquet ou si aucune des règles qui correspondent au paquet ne spécifie de cible particulière.
Ci-dessous figurent les cibles standard :
— Le nom d'une chaîne définie par l'utilisateur au sein de cette table. Les noms de chaîne définis par l'utilisateur doivent être exclusifs. Cette cible transmet le paquet à la chaîne cible.
<user-defined-chain>
ACCEPT
— Autorise le paquet à continuer sa progression vers sa destination ou une autre chaîne.
DROP
— Abandonne le paquet sans répondre au demandeur. Le système ayant expédié ce paquet n'est pas informé de l'échec de l'opération.
QUEUE
— Met le paquet en attente pour un traitement par une application de l'espace-utilisateur (user-space).
RETURN
— Arrête le contrôle du paquet en fonction des règles en vigueur dans la chaîne actuelle. Si le paquet avec la cible RETURN
correspond à une certaine règle appelée depuis une autre chaîne, le paquet est renvoyé à la première chaîne pour que le contrôle de la règle reprenne au point où il s'était arrêté. Dans le cas où la règle RETURN
est utilisée dans une chaîne intégrée et que le paquet ne peut pas aller vers sa chaîne précédente, la cible par défaut pour la chaîne actuelle est utilisée.
Par ailleurs, des extensions sont disponibles qui permettent la spécification d'autres cibles. Ces extensions sont appelées modules cibles ou modules d'options de concordance et correspondent essentiellement à des tables et des situations spécifiques. Pour de plus amples informations sur les modules d'options de concordance, consultez la Section 34.1.3.4.4, « Modules avec options de concordance supplémentaires ».
Il existe de nombreux modules cibles étendus ; la plupart d'entre eux s'appliquent à des tables ou à des situations spécifiques. Ci-dessous figurent certains des modules cibles les plus répandus, inclus par défaut dans Red Hat Enterprise Linux :
LOG
— Journalise tous les paquets correspondant à cette règle. Étant donné que les paquets sont journalisés par le noyau, le fichier /etc/syslog.conf
détermine l'emplacement où ces entrées de journal sont enregistrées. Par défaut, elles sont placées dans le fichier /var/log/messages
.
D'autres options peuvent être utilisées après la cible LOG
pour spécifier le processus de journalisation :
--log-level
— Détermine le niveau de priorité d'un événement de journalisation. Une liste des niveaux de priorité est disponible dans la page de manuel de syslog.conf
.
--log-ip-options
— Journalise toute option indiquée dans l'en-tête d'un paquet IP.
--log-prefix
— Ajoute une chaîne d'un maximum de 29 caractères avant la ligne de journal, lorsqu'elle est écrite. Cette option est utile lors de l'écriture de filtres syslog utilisés conjointement avec la journalisation de paquets.
À cause d'un problème lié à cette option, vous devez ajouter un espace en fin de ligne à la valeur log-prefix
.
--log-tcp-options
— Journalise toute option précisée dans l'en-tête d'un paquet TCP.
--log-tcp-sequence
— Écrit le numéro de séquence TCP relatif au paquet dans le journal.
REJECT
— Renvoie un paquet d'erreur au système distant et abandonne le paquet.
La cible REJECT
accepte une option --reject-with
(où <type>
<type>
correspond au type de rejet) qui permet d'inclure des informations plus détaillées avec le paquet d'erreur. Le message d'erreur port-unreachable
(impossible d'atteindre le port) représente le type d'erreur par défaut envoyée si aucune autre option n'est utilisée. Pour obtenir une liste complète des options disponibles pour
, consultez la page de manuel d'<type>
iptables
.
D'autres extensions de cibles, dont bon nombre sont très utiles pour le masquage d'IP à l'aide de la table nat
ou avec la modification de paquets à l'aide de la table mangle
, figurent dans la page de manuel iptables
.
La commande de listing par défaut, iptables -L [<chain-name>]
, fournit un aperçu très élémentaire des chaînes actuelles contenues dans la table de filtres par défaut. L'utilisation d'options supplémentaires telles que celles énumérées ci-dessous, permettent d'obtenir davantage d'informations :
-v
— Affiche une sortie détaillée, incluant le nombre de paquets et d'octets lus par chaque chaîne, le nombre de paquets et d'octets correspondant à chaque règle et l'identité des interfaces applicables à une règle particulière.
-x
— Étend les nombres dans leurs valeurs exactes. Sur un système très chargé, le nombre de paquets et d'octets vus par une chaîne donnée peut être abrégé en utilisant Kilobytes
, Megabytes
ou Gigabytes
. Cette option force l'affichage du nombre complet.
-n
— Affiche les adresses IP et les numéros de port dans un format numérique, plutôt que d'utiliser le format par défaut constitué du nom d'hôte et du service réseau.
--line-numbers
— Énumère les règles dans chaque chaîne à côté de leur ordre numérique dans la chaîne. Cette option est utile lors de la tentative de suppression d'une règle donnée dans une chaîne ou lors de la localisation de l'emplacement d'une règle à insérer dans une chaîne.
-t
— Spécifie un nom de table. Si omis, il devient par défaut la table filtre.
Les exemples suivants illustrent l'utilisation de plusieurs de ces options. Notez la différence dans l'affichage d'octets en incluant l'option -x
.
[root@myserver ~]# iptables -L OUTPUT -v -n -x Chain OUTPUT (policy ACCEPT 64005 packets, 6445791 bytes) pkts bytes target prot opt in out source destination 1593 133812 ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 [root@myserver ~]#iptables -L OUTPUT -v -n Chain OUTPUT (policy ACCEPT 64783 packets, 6492K bytes) pkts bytes target prot opt in out source destination 1819 153K ACCEPT icmp -- * * 0.0.0.0/0 0.0.0.0/0 [root@myserver ~]#
Les règles créées avec la commande iptables
sont stockées en mémoire. Si le système est redémarré avant l'enregistrement de l'ensemble de règles iptables
, toutes les règles sont perdues. Pour que des règles de filtrage réseau soient conservées lors d'un redémarrage, elles doivent être enregistrées. Pour ce faire, connectez-vous en tant que super-utilisateur et tapez les éléments suivants :
/sbin/service iptables save
Cette commande exécute l'init script d'iptables
, qui lance le programme /sbin/iptables-save
et enregistre la configuration actuelle d'iptables
dans le fichier /etc/sysconfig/iptables
. Le fichier /etc/sysconfig/iptables
existant est enregistré en tant que /etc/sysconfig/iptables.save
.
Lors du prochain démarrage, le script d'initialisation de iptables
applique à nouveau les règles enregistrées dans /etc/sysconfig/iptables
à l'aide de la commande /sbin/iptables-restore
.
Alors qu'il est toujours préférable de tester une nouvelle règle iptables
avant de l'enregistrer dans le fichier /etc/sysconfig/iptables
, il est possible de copier des règles iptables
dans ce fichier à partir d'une version de ce dernier provenant d'un autre ordinateur. Cette opération permet de répandre facilement des ensembles de règles iptables
à de multiples ordinateur.
Vous pouvez également enregistrer les règles iptables dans un fichier séparé pour la distribution, le backup ou autres raisons. Pour sauvegarder vos règles iptables, tapez la commande suivante en tant que super utilisateur :
[root@myserver ~]# iptables-save >
where<filename>
<filename>
is a user-defined name for your ruleset.
Si le fichier /etc/sysconfig/iptables
est distribué sur d'autres machines, il suffit de taper /sbin/service iptables restart
pour que ces nouvelles règles prennent effet.
Notez la différence entre la commande (/sbin/iptables
) iptables
qui est utilisée pour manipuler les tables et les chaînes qui constituent la fonctionnalité iptables
et le serviceiptables
(/sbin/iptables service
) utilisé pour activer ou désactiver le service iptables
lui-même.
Il existe deux méthodes élémentaires pour contrôler iptables
dans Red Hat Enterprise Linux :
/sbin/service iptables
— Utilisé pour manipuler des fonctions diversers d'<option>
iptables
en utilisant son script d'initialisation. Les options suivantes sont disponibles :
start
— Si un pare-feu est configuré (ce qui signifie que /etc/sysconfig/iptables
existe), toutes les iptables
en cours d'exécution seront complètement arrêtées, puis redémarrées à l'aide de la commande /sbin/iptables-restore
. La directive ne fonctionne que si le module de noyau ipchains
n'est pas chargé. Pour vérifier si le noyau est chargé, tapez la commande suivante en tant que super utilisateur :
[root@MyServer ~]# lsmod | grep ipchains
Si cette commande ne retourne aucune sortie, cela signifie que le module n'est pas chargé. Si nécessaire, utilisez la commande /sbin/rmmod
pour supprimer le module.
stop
— Si un pare-feu est en cours d'exécution, les règles de pare-feu en mémoire sont supprimées et tous les modules et les aides d'iptables sont déchargés.
Si la directive IPTABLES_SAVE_ON_STOP
au sein du fichier de configuration /etc/sysconfig/iptables-config
passe de sa valeur par défaut à la valeur yes
, les règles courantes sont enregistrées dans /etc/sysconfig/iptables
et toutes les règles existantes sont déplacées vers le fichier /etc/sysconfig/iptables.save
.
Reportez-vous à la Section 34.1.5.1, « Fichier de configuration des scripts de contrôle de IPTables » pour obtenir davantage d'informations sur le fichier iptables-config
.
restart
— Si un pare-feu est en cours d'exécution, les règles de pare-feu en mémoire sont vidées et le pare-feu est redémarré s'il est configuré dans /etc/sysconfig/iptables
. Cette option ne fonctionne que si le module de noyau ipchains
n'est pas chargé.
Si la directive IPTABLES_SAVE_ON_RESTART
au sein du fichier de configuration /etc/sysconfig/iptables-config
passe de sa valeur par défaut à la valeur yes
, les règles courantes sont enregistrées dans /etc/sysconfig/iptables
et toutes les règles existantes sont déplacées vers le fichier /etc/sysconfig/iptables.save
.
Reportez-vous à la Section 34.1.5.1, « Fichier de configuration des scripts de contrôle de IPTables » pour obtenir davantage d'informations sur le fichier iptables-config
.
status
— Affiche le statut du pare-feu et liste toutes les règles actives.
La configuration par défaut de cette option affiche des adresses IP au sein de chaque règle. Pour afficher des informations de domaine et de nom d'hôte, éditez le fichier /etc/sysconfig/iptables-config
et changez la valeur de /etc/sysconfig/iptables-config
à no
. Pour plus d'informations sur le fichier iptables-config
, consultez la Section 34.1.5.1, « Fichier de configuration des scripts de contrôle de IPTables ».
panic
— Supprime toutes les règles de pare-feu. La politique de toutes les tables configurées est définie en tant que DROP
.
Cette option pourrait être utile si un serveur est compromis. Plutôt que de déconnecter physiquement du réseau ou d'arrêter le système, vous pouvez utiliser cette option pour arrêter tout trafic de réseau supplémentaire mais laisser fonctionner la machine dans un statut prêt à l'analyse ou autres examens.
save
— Enregistre les règles de pare-feu dans /etc/sysconfig/iptables
à l'aide de iptables-save
. Reportez-vous à la Section 34.1.4, « Enregistrement des règles IPTables » pour obtenir davantage d'informations sur le sujet.
Il est possible d'utiliser les mêmes commandes init script pour contrôler le filtrage réseau pour IPv6, en remplaçant ip6tables
par iptables
dans les commandes /sbin/service
présentes dans cette section. Pour obtenir davantage d'informations sur IPv6 et sur le filtrage réseau, consultez la Section 34.1.6, « IPTables et IPv6 ».
Le comportement des scripts d'initialisation d'iptables
est contrôlé par le fichier de configuration /etc/sysconfig/iptables-config
. Ci-dessous figure une liste des directives contenues dans ce fichier :
IPTABLES_MODULES
— Spécifie une liste de modules iptables
supplémentaires (séparés les uns des autres par des espaces) qui doivent être chargés lorsqu'un pare-feu est activé. Parmi ces derniers peuvent figurer les assistants du suivi des connexions et de NAT.
IPTABLES_MODULES_UNLOAD
— Décharge les modules à l'arrêt et au démarrage. Cette directive accepte les valeurs suivantes :
yes
— Cette option doit être définie pour qu'un pare-feu puisse redémarrer ou s'arrêter correctement. Cette valeur est retenue comme défaut.
no
— Cette option ne devrait être définie que s'il existe des problèmes lors du déchargement des modules netfilter.
IPTABLES_SAVE_ON_STOP
— Enregistre les règles courantes du pare-feu dans /etc/sysconfig/iptables
lorsque le pare-feu est arrêté. Cette directive accepte les valeurs suivantes :
yes
— Enregistre les règles existantes dans /etc/sysconfig/iptables
lorsque le pare-feu est arrêté et déplace la version précédente vers le fichier /etc/sysconfig/iptables.save
.
no
— N'enregistre pas les règles existantes lorsque le pare-feu est arrêté. Cette valeur est retenue comme défaut.
IPTABLES_SAVE_ON_RESTART
— Enregistre les règles courantes de pare-feu lorsque le pare-feu est redémarré. Cette directive accepte les valeurs suivantes :
yes
— Enregistre les règles existantes dans /etc/sysconfig/iptables
lorsque le pare-feu est redémarré et déplace la version précédente vers le fichier /etc/sysconfig/iptables.save
.
no
— N'enregistre pas les règles existantes lorsque le pare-feu est redémarré. Cette valeur est retenue comme défaut.
IPTABLES_SAVE_COUNTER
— Enregistre et restaure tous les paquets et les compteurs d'octets dans toutes les chaînes et règles. Cette directive accepte les valeurs suivantes :
yes
— Enregistre les valeurs du compteur.
no
— N'enregistre pas les valeurs du compteur. Cette valeur est retenue comme défaut.
IPTABLES_STATUS_NUMERIC
— Affiche une sortie de statut pour les adresses IP à la place du domaine et des noms d'hôtes. Cette directive accepte les valeurs suivantes :
yes
— Renvoie uniquement les adresses IP avec une sortie de statut. Cette valeur est retenue comme défaut
no
— Renvoie le domaine ou les noms d'hôtes dans une sortie de statut.
Si le paquet iptables-ipv6
est installé, le filtrage réseau dans Red Hat Enterprise Linux peut filtrer le protocole de la prochaine génération IPv6 Internet. La commande utilisée pour manipuler le filtrage réseau IPv6 est ip6tables
.
La plupart des directives de cette commande sont identiques à celles utilisées pour iptables
, cependant la table nat
n'est pas encore prise en charge. Cela signifie qu'il n'est pas encore possible d'effectuer des tâches de traduction d'adresses réseau pour IPv6, telles que le masquage et la redirection de ports.
Les règles enregistrées pour ip6tables
sont stockées dans le fichier /etc/sysconfig/ip6tables
. Les anciennes règles enregistrées par les scripts d'initialisation de ip6tables
sont stockées dans le fichier /etc/sysconfig/ip6tables.save
.
Les options de configuration pour le script d'initialisation de ip6tables
sont stockées dans /etc/sysconfig/ip6tables-config
, et les noms de chaque directive varient légèrement de leurs homologues iptables
.
Par exemple, IPTABLES_MODULES
de la directive iptables-config
:l'équivalent dans le fichier ip6tables-config
est IP6TABLES_MODULES
.
Veuillez consulter les informations ci-dessous pour obtenir des informations supplémentaires sur le filtrage de paquets avec iptables
.
man iptables
— Contient une description des commandes iptables
ainsi qu'une liste complète des cibles, options et extensions de concordance.
http://www.netfilter.org/ — La page d'accueil du projet netfilter/iptables. Contient une série d'informations sur iptables
, y compris un FAQ traitant de problèmes spécifiques et plusieurs guides rédigés par Rusty Russell, le responsable du pare-feu IP de Linux. Les documents HOWTO sur le site couvrent en anglais des sujets tels que les concepts élémentaires de mise en réseau, le filtrage de paquets et les configurations NAT.
http://www.linuxnewbie.org/nhf/Security/IPtables_Basics.html — Une présentation simple concernant le déplacement de paquets dans le noyau Linux, ainsi qu'une introduction à la construction de commandes iptables
simples.