Red Hat Training

A Red Hat training course is available for Red Hat Enterprise Linux

Guide de l'administrateur systèmes

Red Hat Enterprise Linux 7

Déploiement, configuration, et administration de Red Hat Enterprise Linux 7

Maxim Svistunov

Red Hat Customer Content Services

Marie Doleželová

Red Hat Customer Content Services

Stephen Wadeley

Red Hat Customer Content Services

Tomáš Čapek

Red Hat Customer Content Services

Jaromír Hradílek

Red Hat Customer Content Services

Douglas Silas

Red Hat Customer Content Services

Jana Heves

Red Hat Customer Content Services

Petr Kovář

Red Hat Customer Content Services

Peter Ondrejka

Red Hat Customer Content Services

Petr Bokoč

Red Hat Customer Content Services

Martin Prpič

Red Hat Sécurité Produit

Eliška Slobodová

Red Hat Customer Content Services

Eva Kopalová

Red Hat Customer Content Services

Miroslav Svoboda

Red Hat Customer Content Services

David O'Brien

Red Hat Customer Content Services

Michael Hideo

Red Hat Customer Content Services

Don Domingo

Red Hat Customer Content Services

John Ha

Red Hat Customer Content Services

Résumé

Le Guide de l'administrateur systèmes documente les informations importantes concernant le déploiement, la configuration et l'administration de Red Hat Enterprise Linux 7. Ce guide est conçu pour les administrateurs systèmes possédant une connaissance de base du système.

Note

En vue d'élargir vos connaissances, vous serez sans doute interessés par les formations suivantes Red Hat System Administration I (RH124), Red Hat System Administration II (RH134), Red Hat System Administration III (RH254), ou RHCSA Rapid Track (RH199).

Partie I. Configuration de base du système

Cette partie traite des tâches de base de l'administration de système, telles que la configuration du clavier, la configuration de la date et de l'heure, la gestion des utilisateurs et des groupes, et l'obtention de privilèges.

Chapitre 1. Paramètres régionaux et configuration du clavier

Les paramètres régionaux indiquent les paramètres de langue des services et interfaces utilisateur du système. Les paramètres d'agencement du clavier contrôlent l'agencement utilisé sur la console texte et sur les interfaces utilisateur graphique.
Ces paramètres peuvent être effectués en modifiant le fichier de configuration /etc/locale.conf ou en utilisant l'utilitaire localectl. Ainsi, vous pouvez utiliser l'interface utilisateur graphique pour effectuer la tâche. Pour obtenir une description de la méthode, veuillez consulter le Guide d'installation Red Hat Enterprise Linux 7.

1.1. Définir les paramètres régionaux

Les paramètres régionaux globaux sont stockés dans le fichier /etc/locale.conf, qui est lu au début du démarrage par le démon systemd. Les paramètres régionaux configurés dans /etc/locale.conf sont hérités par chaque service ou utilisateur, à moins qu'un programme ou utilisateur individuel ne l'outrepasse.
Le format de base de /etc/locale.conf est une liste séparée par des lignes d'affectation de variables. Voici des paramètres allemands avec des messages en anglais dans /etc/locale.conf : 
LANG=de_DE.UTF-8
LC_MESSAGES=C
Ici, l'option LC_MESSAGES détermine les paramètres régionaux utilisés pour les messages de diagnostique écrits sur la sortie d'erreurs standard. Pour spécifier les paramètres régionaux dans /etc/locale.conf, vous pouvez utiliser plusieurs autres options. Les plus courantes sont résumées dans Tableau 1.1, « Options configurables dans /etc/locale.conf ». Veuillez consulter la page du manuel locale(7) pour obtenir des informations détaillées sur ces options. Veuillez remarquer que l'option LC_ALL, qui représente toutes les options possibles, ne doit pas être configurée dans /etc/locale.conf.

Tableau 1.1. Options configurables dans /etc/locale.conf

OptionDescription
LANGFournit une valeur par défaut pour les paramètres régionaux.
LC_COLLATEModifie le comportement des fonctions qui comparent les chaînes dans l'alphabet local.
LC_CTYPEModifie le comportement des fonctions de gestion et de classification des caractères et les fonctions des caractères multioctets.
LC_NUMERICDécrit la manière par laquelle les chiffres sont habituellement imprimés, avec des détails tels que le point décimal versus la virgule décimale.
LC_TIMEModifie l'affichage de l'heure actuelle, 24 heures versus 12 heures.
LC_MESSAGESDétermine les paramètres régionaux utilisés pour les messages de diagnostique écrits dans la sortie d'erreur standard.

1.1.1. Afficher le statut actuel

La commande localectl peut être utilisée pour effectuer des requêtes et modifier les paramètres régionaux et les paramètres d'agencement du clavier. Pour afficher les paramètres actuels, veuilles utiliser l'option status : 
localectl status

Exemple 1.1. Afficher le statut actuel

La sortie de la commande précédente répertorie les paramètres régionaux et la structure du clavier actuellement configurés pour la console et le système de fenêtres X11. 
~]$ localectl status
   System Locale: LANG=en_US.UTF-8
       VC Keymap: us
      X11 Layout: n/a

1.1.2. Répertorier les paramètres régionaux disponibles

Pour répertorier tous les paramètres régionaux disponibles pour votre système, veuillez saisir : 
localectl list-locales

Exemple 1.2. Répertorier les paramètres régionaux

Imaginez que vous souhaitiez sélectionner un paramètre régional anglais en particulier, mais que vous n'êtes pas sûr qu'il se trouve sur le système. Vous pourrez vérifier cela en répertoriant tous les paramètres régionaux anglais avec la commande suivante : 
~]$ localectl list-locales | grep en_
en_AG
en_AG.utf8
en_AU
en_AU.iso88591
en_AU.utf8
en_BW
en_BW.iso88591
en_BW.utf8

output truncated

1.1.3. Définir les paramètres régionaux

Pour définir les paramètres régionaux du système par défaut, veuillez utiliser la commande suivante en tant qu'utilisateur root : 
localectl set-locale LANG=locale
Remplacez locale par le nom du paramètre régional, trouvé par la commande localectl list-locales. La syntaxe ci-dessus peut également être utilisée pour configurer les paramètres de Tableau 1.1, « Options configurables dans /etc/locale.conf ».

Exemple 1.3. Modifier les paramètres régionaux par défaut

Ainsi, si vous souhaitez définir l'anglais britannique (« British English ») comme paramètre régional par défaut, commencez par trouver le nom du paramètre régional en utilisant list-locales. Puis, en tant qu'utilisateur root, saisir une commande du modèle suivant : 
~]# localectl set-locale LANG=en_GB.utf8

1.2. Modifier l'agencement du clavier

Les paramètres d'agencement du clavier permettent à l'utilisateur de contrôler la structure utilisée sur la console de texte et les interfaces utilisateur graphique.

1.2.1. Afficher les paramètres actuels

Comme mentionné précédemment, vous pouvez vérifier la configuration de l'agencement du clavier par la commande suivante : 
localectl status

Exemple 1.4. Afficher les paramètres du clavier

Dans la sortie suivante, vous pouvez observer l'agencement du clavier configuré pour la console virtuelle et pour le système de fenêtres X11. 
~]$ localectl status
   System Locale: LANG=en_US.utf8
       VC Keymap: us
      X11 Layout: us

1.2.2. Répertorier les agencements de clavier disponibles

Pour répertorier tous les agencements de clavier disponibles pouvant être configurés sur votre système, veuillez saisir : 
localectl list-keymaps

Exemple 1.5. Rechercher un agencement de clavier particulier

La commande grep peut être utilisée pour rechercher un nom d'agencement de clavier particulier dans la sortie de la commande précédente. De multiples agencements de clavier sont souvent compatibles avec vos paramètres régionaux actuels. Par exemple, pour trouver des agencements de clavier tchèques, veuillez saisir : 
~]$ localectl list-keymaps | grep cz
cz
cz-cp1250
cz-lat2
cz-lat2-prog
cz-qwerty
cz-us-qwertz
sunt5-cz-us
sunt5-us-cz

1.2.3. Définir l'agencement du clavier

Pour définir la structure du clavier par défaut de votre système, veuillez utiliser la commande suivante en tant qu'utilisateur root : 
localectl set-keymap map
Remplacez map par le nom de l'agencement du clavier pris à partir de la sortie de la commande localectl list-keymaps. À moins que l'option --no-convert ne soit passée, le paramètre sélectionné est également appliqué au mappage du clavier par défaut du système de fenêtres X11, après l'avoir converti au mappage de clavier X11 correspondant le mieux. Ceci s'applique à l'inverse, vous pouvez spécifier les deux agencements de clavier avec la commande suivante en tant qu'utilisateur root : 
localectl set-x11-keymap map
Si vous souhaitez que votre structure X11 diffère de la structure de la console, veuillez utiliser l'option --no-convert. 
localectl --no-convert set-x11-keymap map
Avec cette option, l'agencement du clavier X11 est indiqué sans changer le paramètre de structure de la console précédente.

Exemple 1.6. Définir l'agencement du clavier X11 séparément

Imaginez que vous souhaitiez utiliser une structure de clavier allemande dans l'interface graphique, mais que vous souhaitiez conserver un agencement de clavier en anglais américain (« US English ») pour les opérations de la console. Dans ce cas, en tant qu'utilisateur root, veuillez saisir : 
~]# localectl --no-convert set-x11-keymap de
Puis, vous pouvez vérifier si ce paramétrage a fonctionné en examinant le statut actuel : 
~]$ localectl status
   System Locale: LANG=de_DE.UTF-8
       VC Keymap: us
      X11 Layout: de
Hormis la structure de clavier (map), trois autres options peuvent être spécifiées : 
localectl set-x11-keymap map model variant options
Remplacez model par le nom de modèle du clavier, et variant et options par la variante du clavier et les composants d'option, qui peuvent être utilisés pour améliorer le comportement du clavier. Ces options ne sont pas définies par défaut. Pour obtenir davantage d'informations sur le modèle X11, la variante X11, et sur les options X11, veuillez consulter la page man kbd(4).

1.3. Ressources supplémentaires

Pour obtenir davantage d'informations sur la manière de configurer la structure du clavier sur Red Hat Enterprise Linux, veuillez consulter les ressources ci-dessous :

Documentation installée

  • localectl(1) — la page du manuel de l'utilitaire de ligne de commande localectl documente comment utiliser cet outil pour configurer les paramètres régionaux du système et la structure du clavier.
  • loadkeys(1) — la page du manuel de la commande loadkeys fournit des informations supplémentaires sur la manière d'utiliser cet outil pour modifier la structure du clavier dans une console virtuelle.

Voir aussi

Chapitre 2. Configurer l'heure et la date

Les systèmes d'exploitation modernes font la distinction entre les deux types d'horloges suivants :
  • Une horloge temps réel (« Real-Time Clock », ou RTC), communément appelée horloge matérielle, (habituellement un circuit intégré sur la carte système) est complètement indépendante de l'état actuel du système d'exploitation et fonctionne même lorsque l'ordinateur est éteint.
  • Une horloge système, également appelée horloge logicielle, est habituellement maintenue par le noyau et sa valeur initiale est basée sur l'horloge temps réel. Une fois le système démarré et l'horloge système initialisée, celle-ci est entièrement indépendante de l'horloge temps réel.
Le temps système est toujours conservé sous le format du temps universel coordonné (« Coordinated Universal Time », ou UTC) puis converti dans les applications au temps local selon les besoins. Le temps local correspond à l'heure réelle dans votre fuseau horaire et prend en compte l'heure d'été (« daylight saving time », ou DST). L'horloge temps réel peut utiliser l'heure UTC ou l'heure locale. L'heure UTC est recommandée.
Red Hat Enterprise Linux 7 offre trois outils de ligne de commande pouvant être utilisés pour configurer et afficher des informations sur l'heure et la date du système : l'utilitaire timedatectl, qui est nouveau sur Red Hat Enterprise Linux 7 et fait partie de systemd ; la commande traditionnelle date ; et l'utilitaire hwclock pour accéder à l'horloge matérielle.

2.1. Utilisation de la commande timedatectl

L'utilitaire timedatectl est distribué dans le cadre du gestionnaire de services et systèmes systemd et permet de réviser et modifier la configuration de l'horloge système. Vous pouvez utiliser cet outil pour modifier l'heure et la date actuelle, pour définir le fuseau horaire, ou pour activer la synchronisation automatique de l'horloge système avec un serveur distant.
Pour obtenir des informations sur la manière d'afficher l'heure et la date actuelle sous un format personnalisé, veuillez également consulter la Section 2.2, « Utiliser la commande date ».

2.1.1. Afficher l'heure et la date actuelle

Pour afficher l'heure et la date actuelle, ainsi que des informations détaillées sur la configuration de l'horloge système et de l'horloge matérielle, veuillez exécuter la commande timedatectl sans aucune autre option de ligne de commande : 
timedatectl
Ceci affiche l'heure locale et universelle, le fuseau horaire en cours d'utilisation, le statut de la configuration NTP (« Network Time Protocol »), ainsi que des informations supplémentaires liées à DST.

Exemple 2.1. Afficher l'heure et la date actuelle

Voici un exemple de la sortie de commande timedatectl sur un système qui n'utilise pas NTP pour synchroniser l'horloge système avec un serveur distant : 
~]$ timedatectl
      Local time: Mon 2013-09-16 19:30:24 CEST
  Universal time: Mon 2013-09-16 17:30:24 UTC
        Timezone: Europe/Prague (CEST, +0200)
     NTP enabled: no
NTP synchronized: no
 RTC in local TZ: no
      DST active: yes
 Last DST change: DST began at
                  Sun 2013-03-31 01:59:59 CET
                  Sun 2013-03-31 03:00:00 CEST
 Next DST change: DST ends (the clock jumps one hour backwards) at
                  Sun 2013-10-27 02:59:59 CEST
                  Sun 2013-10-27 02:00:00 CET

Important

Les changements au statut de chrony ou à ntpd ne seront pas notés immédiatement par timedatectl. S'il y a eu des changements de configuration ou de statut à ces outils, saisir la commande suivante : 
~]# systemctl restart systemd-timedated.services

2.1.2. Modifier l'heure actuelle

Pour modifier l'heure actuelle, veuillez saisir ce qui suit dans l'invite de shell en tant qu'utilisateur root: 
timedatectl set-time HH:MM:SS
Veuillez remplacer HH par les heures, MM par les minutes, et SS par les secondes, le tout doit être saisi sous un format à deux chiffres.
Cette commande met à jour l'heure système et l'horloge matérielle. Le résultat est similaire à l'utilisation des commandes date --set et hwclock --systohc.
La commande échouera si un service NTP est activé. Voir Section 2.1.5, « Synchroniser l'horloge système avec un serveur à distance » pour désactiver le service de façon temporaire.

Exemple 2.2. Modifier l'heure actuelle

Pour modifier l'heure actuelle à 11:26 p.m. (23h26), veuillez exécuter la commande suivante en tant qu'utilisateur root : 
~]# timedatectl set-time 23:26:00
Par défaut, le système est configuré pour utiliser l'heure UTC. Pour configurer votre système à maintenir l'horloge à l'heure locale, veuillez exécuter la commande timedatectl avec l'option set-local-rtc en tant qu'utilisateur root : 
timedatectl set-local-rtc boolean
Pour configurer votre système afin de maintenir l'horloge à l'heure locale, veuillez remplacer boolean par yes (ou bien par y, true, t, ou 1). Pour configurer le système de manière à utiliser UTC, veuillez remplacer boolean par no (ou bien par, n, false, f, ou 0). L'option par défaut est no.

2.1.3. Modifier la date actuelle

Pour modifier la date actuelle, veuillez saisir ce qui suit dans l'invite de shell en tant qu'utilisateur root: 
timedatectl set-time YYYY-MM-DD
Veuillez remplacer YYYY par une année à quatre chiffres, MM par un mois à deux chiffres, et DD par un jour du mois à deux chiffres.
Veuillez remarquer que modifier la date sans spécifier l'heure actuelle fera que l'heure sera paramétrée sur 00:00:00.

Exemple 2.3. Modifier la date actuelle

Pour modifier la date actuelle sur le 2 juin 2013 et garder la même heure (11:26 p.m., ou 23h26), veuillez exécuter la commande suivante en tant qu'utilisateur root : 
~]# timedatectl set-time '2013-06-02 23:26:00'

2.1.4. Modifier le fuseau horaire

Pour répertorier tous les fuseaux horaire disponibles, veuillez saisir ce qui suit dans une invite de shell : 
timedatectl list-timezones
Pour modifier le fuseau horaire en cous d'utilisation, veuillez saisir ce qui suit en tant qu'utilisateur root : 
timedatectl set-timezone time_zone
Veuillez remplacer time_zone par l'une des valeurs répertoriées par la commande timedatectl list-timezones.

Exemple 2.4. Modifier le fuseau horaire

Pour identifier le fuseau horaire le plus proche de votre location actuelle, veuillez utiliser la commande timedatectl avec l'option de ligne de commande list-timezones. Par exemple, pour répertorier tous les fuseaux horaires en Europe, veuillez saisir : 
~]# timedatectl list-timezones | grep Europe
Europe/Amsterdam
Europe/Andorra
Europe/Athens
Europe/Belgrade
Europe/Berlin
Europe/Bratislava…
Pour changer le fuseau horaire sur Europe/Prague, veuillez saisir ce qui suit en tant qu'utilisateur root : 
~]# timedatectl set-timezone Europe/Prague

2.1.5. Synchroniser l'horloge système avec un serveur à distance

Contrairement aux ajustements manuels décrits dans les sections précédentes, la commande timedatectl vous permet également d'activer la synchronisation automatique de votre horloge système avec un groupe de serveurs à distance en utilisant le protocole NTP. L'activation de NTP active chronyd ou ntpd, selon le service installé.
Le service NTP peut être activé et désactivé par une commande sur le modèle suivant : 
timedatectl set-ntp boolean
Pour activer votre système pour synchroniser l'horloge système avec un serveur NTP à distance, veuillez remplacer boolean par yes (option par défaut). Pour désactiver cette fonctionnalité, veuillez remplacer boolean par no.

Exemple 2.5. Synchroniser l'horloge système avec un serveur à distance

Pour activer la synchronisation automatique de l'horloge système avec un serveur à distance, veuillez saisir : 
~]# timedatectl set-ntp yes
La commande échouera si un service NTP n'est pas installé. Voir Section 15.3.1, « Installer Chrony » pour plus d'informations.

2.2. Utiliser la commande date

L'utilitaire date est disponible sur tous les systèmes Linux et vous permet d'afficher et de configurer l'heure et la date actuelle. Celle-ci est fréquemment utilisée dans les scripts pour afficher des informations détaillées sur l'horloge système sous un format personnalisé.
Pour obtenir des informations sur la manière de modifier le fuseau horaire ou pour activer la synchronisation automatique de l'horloge système avec un serveur à distance, veuillez consulter la Section 2.1, « Utilisation de la commande timedatectl ».

2.2.1. Afficher l'heure et la date actuelle

Pour afficher l'heure et la date actuelle, veuillez exécuter la commande date sans aucune autre option de ligne de commande : 
date
Celle-ci affiche le jour de la semaine, suivi de la date, de l'heure locale, de l'abbréviation du fuseau horaire, et de l'année.
Par défaut, la commande date affiche l'heure local. Pour afficher l'heure UTC, veuillez exécuter la commande avec l'option de ligne de commande --utc ou -u : 
date --utc
Il est également possible de personnaliser le format des informations affichées en ajoutant l'option +"format" sur la ligne de commande : 
date +"format"
Remplacez format par une ou plusieurs séquences de contrôle prises en charge, comme illustré dans l'Exemple 2.6, « Afficher l'heure et la date actuelle ». Veuillez consulter Tableau 2.1, « Séquences de contrôle couramment utilisées » pour une liste des options de formatage les plus fréquemment utilisées, ou la page de manuel date(1) pour une liste complète de ces options.

Tableau 2.1. Séquences de contrôle couramment utilisées

Séquence de contrôleDescription
%HHeures sous le format HH (par exemple, 17).
%MMinutes sous le format MM (par exemple, 30).
%SSecondes sous le format SS (par exemple, 24).
%dJour du mois sous le format DD (par exemple, 16).
%mMois sous le format MM (par exemple, 09).
%YAnnée sous le format YYYY (par exemple, 2013).
%ZAbbréviation du fuseau horaire (par exemple, CEST).
%FDate complète sous le format YYYY-MM-DD (par exemple, 2013-09-16). Cette option correspond à %Y-%m-%d.
%THeure complète sous le format HH:MM:SS (par exemple, 17:30:24). Cette option correspond à %H:%M:%S

Exemple 2.6. Afficher l'heure et la date actuelle

Pour afficher l'heure et la date locale, veuillez saisir ce qui suit dans une invite de shell : 
~]$ date
Mon Sep 16 17:30:24 CEST 2013
Pour afficher l'heure et la date UTC, veuillez saisir ce qui suit dans une invite de shell : 
~]$ date --utc
Mon Sep 16 15:30:34 UTC 2013
Pour personnaliser la sortie de la commande date, veuillez saisir : 
~]$ date +"%Y-%m-%d %H:%M"
2013-09-16 17:30

2.2.2. Modifier l'heure actuelle

Pour modifier l'heure actuelle, veuillez exécuter la commande date avec l'option --set ou -s en tant qu'utilisateur root : 
date --set HH:MM:SS
Veuillez remplacer HH par les heures, MM par les minutes, et SS par les secondes, le tout doit être saisi sous un format à deux chiffres.
Par défaut, la commande date définit l'horloge système sur l'heure locale. Pour définir l'horloge système sur UTC, exécutez la commande avec l'option de ligne de commande --utc ou -u : 
date --set HH:MM:SS --utc

Exemple 2.7. Modifier l'heure actuelle

Pour modifier l'heure actuelle à 11:26 p.m. (23h26), veuillez exécuter la commande suivante en tant qu'utilisateur root : 
~]# date --set 23:26:00

2.2.3. Modifier la date actuelle

Pour modifier la date actuelle, veuillez exécuter la commande date avec l'option --set ou -s en tant qu'utilisateur root : 
date --set YYYY-MM-DD
Veuillez remplacer YYYY par une année à quatre chiffres, MM par un mois à deux chiffres, et DD par un jour du mois à deux chiffres.
Veuillez remarquer que modifier la date sans spécifier l'heure actuelle fera que l'heure sera paramétrée sur 00:00:00.

Exemple 2.8. Modifier la date actuelle

Pour modifier la date actuelle sur le 2 juin 2013 et garder la même heure (11:26 p.m., ou 23h26), veuillez exécuter la commande suivante en tant qu'utilisateur root : 
~]# date --set 2013-06-02 23:26:00

2.3. Utilisation de la commande hwclock

hwclock est un utilitaire pour accéder à l'horloge matérielle, également appelée horloge RTC (« Real Time Clock »). L'horloge matérielle est indépendante du système d'exploitation utilisé et fonctionne même lorsque l'ordinateur est éteint. Cet utilitaire est utilisé pour afficher l'heure de l'horloge matérielle. hwclock offre aussi la possibilité de compenser pour la dérive systématique de l'horloge matérielle.
L'horloge matérielle stocke les valeurs de l'année, du mois, du jour, de l'heure, des minutes, et des secondes. Celle-ci n'est pas capable de stocker l'heure standard, l'heure locale, ou l'heure UTC (« Coordinated Universal Time »), ni de définir l'heure d'été (« Daylight Saving Time », ou DST).
L'utilitaire hwclock enregistre ses paramètres dans le fichier /etc/adjtime, qui est créé lors du premier changement effectué. Par exemple, lorsque l'heure est définie manuellement ou lorsque l'horloge matérielle est synchronisée avec l'heure système.

Note

Sur Red Hat Enterprise Linux 6, la commande hwclock était exécutée automatiquement à chaque fermeture ou redémarrage du système, mais ceci n'est pas le cas sur Red Hat Enterprise Linux 7. Lorsque l'horloge système est synchronisée par le protocole NTP (« Network Time Protocol ») ou PTP (« Precision Time Protocol »), le noyau synchronise automatiquement l'horloge matérielle avec l'horloge système toutes les 11 minutes.
Pour obtenir des détails sur NTP, veuillez consulter le Chapitre 15, Configurer NTP en utilisant Chrony Suite et le Chapitre 16, Configurer NTP à l'aide de ntpd. Pour obtenir des informations sur PTP, veuillez consulter le Chapitre 17, Configurer PTP en utilisant ptp4l. Pour obtenir des informations sur le paramétrage de l'horloge matérielle après avoir exécuté ntpdate, veuillez consulter la Section 16.18, « Configurer la mise à jour de l'horloge matérielle ».

2.3.1. Afficher l'heure et la date actuelle

Exécuter hwclock sans aucun option de ligne de commande en tant qu'utilisateur root retourne l'heure et la date locale sur la sortie standard. 
hwclock
Remarquez qu'utiliser les options --utc ou --localtime avec la commande hwclock ne signifie pas que vous tentiez d'afficher l'heure de l'horloge matérielle en temps UTC ou en temps local. Ces options sont utilisées pour définir l'horloge matérielle de manière à conserver l'heure. L'heure est toujours affichée en heure locale. En outre, l'utilisation des commandes hwclock --utc ou hwclock --local ne modifie pas l'enregistrement dans le fichier /etc/adjtime. Cette commande peut être utile lorsque vous savez que le paramètre enregistré dans /etc/adjtime est incorrect mais que vous ne souhaitez pas modifier ce paramètre. D'autre part, vous pourriez recevoir des informations risquant de vous induire en erreur si vous utilisez une commande de la mauvaise manière. Veuillez consulter la page man de hwclock(8) pour obtenir davantage de détails.

Exemple 2.9. Afficher l'heure et la date actuelle

Pour afficher la date et l'heure locale actuelle à partir de l'horloge matérielle, veuillez exécuter ceci en tant qu'utilisateur root : 
~]# hwclock
Tue 15 Apr 2014 04:23:46 PM CEST     -0.329272 seconds
CEST est une abbréviation de fuseau horaire et signifie heure d'été d'Europe centrale (« Central European Summer Time »).
Pour obtenir des informations sur la manière de modifier le fuseau horaire, veuillez consulter la Section 2.1.4, « Modifier le fuseau horaire ».

2.3.2. Paramétrer l'heure et la date

En plus d'afficher l'heure et la date, vous pouvez manuellement paramétrer l'horloge matérielle sur une heure particulière.
Lorsque vous aurez besoin de changer l'heure et la date de l'horloge matérielle, vous pourrez le faire en ajoutant les options --set et --date dans vos spécifications : 
hwclock --set --date "dd mmm yyyy HH:MM"
Remplacez dd par un jour (un nombre à deux chiffres), mmm par un mois (une abbréviation à trois lettres), yyyy par une année (nombre à quatre chiffres), HH par l'heure (un nombre à deux chiffres), MM par les minutes (un nombre à deux chiffres).
Au même moment, vous pouvez également définir l'horloge matérielle pour conserver l'heure UTC ou locale en ajoutant l'option --utc ou --localtime, respectivement. Dans ce cas, UTC ou LOCAL est enregistré dans le fichier /etc/adjtime.

Exemple 2.10. Paramétrer l'horloge matérielle à une heure et date en particulier

Si vous souhaitez paramétrer l'heure et la date avec des valeurs particulières, par exemple « 21h17, 21 octobre, 2014 », et laisser l'horloge matérielle réglée sur UTC, veuillez exécuter la commande en tant qu'utilisateur root sous le format suivant : 
~]# hwclock --set --date "21 Oct 2014 21:17" --utc

2.3.3. Synchroniser l'heure et la date

Vous pouvez synchroniser l'horloge matérielle et l'heure système actuelle dans les deux directions.
  • Vous pouvez définir l'horloge matérielle sur l'heure système actuelle à l'aide de cette commande : 
    hwclock --systohc
    Remarquez que si vous utilisez NTP, l'horloge matérielle est automatiquement synchronisée à l'horloge système toutes les 11 minutes, et cette commande n'est utile que pendant le démarrage pour obtenir une heure système initiale raisonnable.
  • Vous pouvez également définir l'heure système à partir de l'horloge matérielle en utilisant la commande suivante : 
    hwclock --hctosys
Lorsque vous synchronisez l'horloge matérielle et l'heure système, vous pouvez également spécifier si vous souhaitez conserver l'horloge matérielle en heure locale ou en heure UTC en ajoutant l'option --utc ou --localtime. De même qu'avec --set, UTC ou LOCAL est enregistré dans le fichier /etc/adjtime.
La commande hwclock --systohc --utc est fonctionnellement similaire à timedatectl set-local-rtc false et la commande hwclock --systohc --local est une alternative à timedatectl set-local-rtc true.

Exemple 2.11. Synchroniser l'horloge matérielle avec l'heure système

Pour définir l'horloge matérielle sur l'heure actuelle du système tout en gardant l'horloge matérielle en heure locale, veuillez exécuter la commande suivante en tant qu'utilisateur root : 
~]# hwclock --systohc --localtime
Pour éviter les problèmes liés aux fuseaux horaires et aux changements d'heure d'été, il recommandé de garder l'horloge matérielle en heure UTC. L'Exemple 2.11, « Synchroniser l'horloge matérielle avec l'heure système » affiché est utile, par exemple pour les cas de démarrages multiples avec un système Windows, qui suppose que l'horloge matérielle soit exécutée en heure locale par défaut, et que tous les autres systèmes doivent s'y accommoder en utilisant également l'heure locale. Cela peut également être utile avec une machine virtuelle ; si l'horloge matérielle virtuelle fournie par l'hôte est exécutée en heure locale, le système invité devra être configuré de manière à utiliser l'heure locale aussi.

2.4. Ressources supplémentaires

Pour obtenir des informations supplémentaires sur la manière de configurer l'heure et la date dans Red Hat Enterprise Linux 7, veuillez consulter les ressources répertoriées ci-dessous.

Documentation installée

  • timedatectl(1) — la page du ma de l'utilitaire de ligne de commande timedatectl documente comment utiliser cet outil pour effectuer des requêtes et modifier l'horloge système et ses paramètres.
  • date(1) — la page du man de la commande date fournit une liste complète des options de ligne de commande prises en charge.
  • hwclock(8) — la page du man de la commande hwclock fournit une liste complète des options de ligne de commande.

Voir aussi

Chapitre 3. Gérer les utilisateurs et les groupes

Le contrôle des utilisateurs et des groupes est un élément essentiel de l'administration des systèmes Red Hat Enterprise Linux. Ce chapitre explique comment ajouter, gérer, et supprimer des utilisateurs et des groupes dans l'interface utilisateur graphique et en ligne de commande, des sujets avancés sont également traités, comme la création de répertoires de groupes.

3.1. Introduction aux utilisateurs et aux groupes

Tandis que les utilisateurs peuvent être des personnes (des comptes liés à des utilisateurs physiques), ou des comptes existants pour des applications spécifiques, les groupes sont des expressions logiques qui permettent une certaine organisation en regroupant des utilisateurs œuvrant dans un but commun. Les utilisateurs appartenant à un groupe donné partagent les mêmes permissions, leur permettant de lire, d'écrire, ou d'exécuter les fichiers appartenant à ce groupe.
Chaque utilisateur peut être associé avec un numéro d'identification numérique unique, également appelé un ID d'utilisateur (« user ID », ou UID). Similairement, chaque groupe est associé avec un ID de groupe (« group ID », ou 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 l'utilisateur root, et les permissions d'accès quant à elles peuvent être modifiées aussi bien par l'utilisateur root, que par le propriétaire du fichier.
En outre, Red Hat Enterprise Linux prend en charge les listes de contrôle d'accès (ACL) pour les fichiers et répertoires qui permettent d'octroyer des permissions à des utilisateurs spécifiques en dehors du propriétaire. Pour obtenir davantage d’informations sur cette fonctionnalité, veuillez consulter Chapitre 4, Listes des contrôle d'accès (ACL).

ID d'utilisateurs et de groupes réservés

Red Hat Enterprise Linux réserve les ID de groupe de d'utilisateur inférieurs à 100 pour les groupes et les utilisateurs du système. User Manager n'affiche pas les utilisateurs du système. Les ID de groupe et d'utilisateurs sont documentés dans le package setup. Pour afficher la documentation, exécuter la commande : 
cat /usr/share/doc/setup*/uidgid
La pratique courante est d'assigner des ID non réservés à partir de 5000, car cette gamme pourrait augmenter dans le futur. Pour que les ID assignés aux nouveaux utilisateurs par défaut puissent commencer à 5000, modifier les directives UID_MIN et GID_MIN dans le fichier /etc/login.defs : 
[file contents truncated]
UID_MIN                  5000[file contents truncated]
GID_MIN                  5000[file contents truncated]

Note

Pour les utilisateurs qui auraient été créés avant le changement des directives UID_MIN et GID_MIN, les UID démarreront toujours par la valeur par défaut de 1000.
Même avec le nouvel utilisateur et les ID de groupe commençant par 5000, il est conseillé de ne pas augmenter les ID réservés par le système et supérieurs à 1000 pour éviter un conflit de systèmes retenant une limite de 1000.

3.1.1. Groupes privés d'utilisateurs

Red Hat Enterprise Linux utilise un schéma de groupe privé d'utilisateurs (ou UPG), qui rend la gestion des groupes UNIX plus facile. Un groupe privé d'utilisateurs est créé lorsqu'un nouvel utilisateur est ajouté au système. Il possède le même nom qu l'utilisateur pour lequel il a été créé et cet utilisateur est le seul membre du groupe privé d'utilisateurs.
Grâce à l'utilisation des groupes privés d'utilisateurs, 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 quelles permissions sont appliquées au nouveau fichier ou répertoire créé s'appelle un umask et est configuré dans le fichier /etc/bashrc. Habituellement sur les système basés UNIX, l'umask a pour valeur 022, ce qui permet uniquement à l'utilisateur ayant créé le fichier ou le répertoire d'effectuer des modifications. Sous ce schéma, tous les autres utilisateurs, y compris les membres du groupe du créateur, ne sont pas autorisés à effectuer des modifications. Cependant, sous le schéma UPG, cette « protection de groupe » n'est pas nécessaire puisque chaque utilisateur possède son propre groupe privé.
Une liste de tous les groupes est stockée dans le fichier de configuration /etc/group.

3.1.2. Mots de passe cachés (« Shadow Passwords »)

Dans les environnements avec de multiples utilisateurs, il est très important d'utiliser des « mots de passe cachés » fournis par le paquet shadow-utils afin d'améliorer la sécurité des fichiers d'authentification du système. Pour cette raison, le programme d'installation active les mots de passe cachés par défaut.
Ci-dessous figure une liste des avantages présentés par les mots de passe cachés comparé à la manière traditionnelle de stockage de mots de passe sur les systèmes basés UNIX 
  • Les mots de passe cachés améliorent la sécurité du système en déplaçant les hachages de mots de passe chiffrés depuis le fichier lisible /etc/passwd sur le fichier /etc/shadow, qui est uniquement lisible par l'utilisateur root.
  • Les mots de passe cachés stockent des informations sur l'ancienneté du mot de passe.
  • Les mots de passe cachés permettent d'appliquer les politiques de sécurité définies dans le fichier /etc/login.defs .
La plupart des utilitaires fournis par le paquet shadow-utils fonctionnent correctement, que les mots de passe cachés soient activés ou non. Cependant, comme les informations sur l'ancienneté des mots de passe sont exclusivement stockées dans le fichier /etc/shadow, certains utilitaires et certaines commandes ne fonctionneront pas si les mots de passe cachés ne sont pas activés :
  • Utilitaire chage pour définir les paramètres d'ancienneté de mot de passe. Pour obtenir des détails, veuillez consulter la section Sécurité du mot de passe dans le Guide de sécurité Red Hat Enterprise Linux 7.
  • Utilitaire gpasswd pour administrer le fichier /etc/group.
  • Commande usermod avec l'option -e, --expiredate ou -f, --inactive.
  • La commande useradd avec l'option -e, --expiredate ou -f, --inactive.

3.2. Gestion des utilisateurs dans un environnement graphique

L'utilitaire Users vous permet d'afficher, de modifier, d'ajouter, et de supprimer des utilisateurs locaux dans l'interface utilisateur graphique.

3.2.1. Utiliser l'outil des paramètres d'utilisateurs « Users Settings Tool »

Veuillez appuyer sur la touche Super pour accéder à « Vue d'ensembles des activités », saisissez Users puis appuyez sur Entrée. L'outil des paramètres Users s'affiche. La touche Super apparaît sous une variété de formes, selon le clavier et matériel, mais le plus souvent, il s'agit de la touche Windows ou Commande, et elle se trouve habituellement à gauche de la barre d'espace. Alternativement, vous pouvez ouvrir l'utilitaire Users à partir du menu Paramètres après avoir cliqué sur votre nom d'utilisateur dans le coin supérieur droit de l'écran.
Pour effectuer des changements sur les comptes utilisateurs, veuillez commencer par sélectionner le bouton de déverrouillage « Unlock » et authentifiez-vous comme indiqué par la boîte de dialogue qui apparaît. Remarquez qu'à moins que vous ne possédiez des privilèges de super-utilisateur, l'application vous demandera de vous authentifier en tant qu'utilisateur root. Pour ajouter et supprimer des utilisateurs, veuillez sélectionner les boutons + et - respectivement. Pour ajouter un utilisateur au groupe administratif wheel, veuillez changer le Type de compte de Standard à Administrateur. Pour modifier le paramètre de langue d'un utilisateur, veuillez sélectionner la langue et un menu déroulant apparaîtra.
Outil des paramètres d'utilisateurs « Users Settings Tool »

Figure 3.1. Outil des paramètres d'utilisateurs « Users Settings Tool »

Lorsqu'un nouvel utilisateur est créé, le compte est désactivé jusqu'à ce qu'un mot de passe soit défini. Le menu déroulant Password, affiché dans la Figure 3.2, « Menu Password », contient des options pour que l'administrateur définisse un mot de passe immédiatement, pour que l'utilisateur choisisse un mot de passe à la première connexion, ou crée un compte invité sans qu'un mot de passe ne soit requis pour se connecter. Un compte peut également être activé ou désactivé à partir de ce menu.
Menu Password

Figure 3.2. Menu Password

3.3. Utiliser des outils de ligne de commande

À l'exception de l'outil de configuration de Users décrit dans la Section 3.2, « Gestion des utilisateurs dans un environnement graphique », qui est conçu pour la gestion de base des utilisateurs, il est possible d'utiliser des outils de ligne de commande pour gérer les utilisateurs et les groupes répertoriés dans la Tableau 3.1, « Utilitaires en ligne de commande pour gérer les utilisateurs et les groupes ».

Tableau 3.1. Utilitaires en ligne de commande pour gérer les utilisateurs et les groupes

UtilitairesDescription
idAffiche les ID d'utilisateur et de groupe.
useradd, usermod, userdelUtilitaires standard pour ajouter, modifier, et supprimer des comptes utilisateur.
groupadd, groupmod, groupdelUtilitaires standard pour ajouter, modifier, et supprimer des groupes.
gpasswdUtilitaire utilisé surtout pour modifier le mot de passe du groupe dans le fichier /etc/gshadow utilisé par la commande newgrp.
pwck, grpckUtilitaires pouvant être utilisés pour la vérification du mot de passe, du groupe et des fichiers cachés associés.
pwconv, pwunconvUtilitaires pouvant être utilisés pour la conversion de mots de passe en mots de passe cachés, ou au contraire de mots de passe cachés en mots de passe standard.
grpconv, grpunconvDe manière similaire à ce qui précède, ces utilitaires peuvent être utilisés pour la conversion d'informations cachées pour les comptes de groupe.

3.3.1. Ajout d'un nouvel utilisateur

Pour ajouter un nouvel utilisateur sur le système, veuillez saisir ce qui suit dans une invite de shell en tant qu'utilisateur root : 
useradd [options] username
…où les options sont des options de ligne de commande comme décrit dans la Tableau 3.2, « Options de ligne de commande useradd communes ».
Par défaut, la commande useradd crée un compte utilisateur verrouillé. Pour déverrouiller le compte, veuillez exécuter la commande suivante en tant qu'utilisateur root pour assigner un mot de passe : 
passwd username
Optionnellement, vous pouvez définir une politique d'ancienneté de mot de passe. Veuillez consulter la section Sécurité du mot de passe du Guide de sécurité Red Hat Enterprise Linux 7 .

Tableau 3.2. Options de ligne de commande useradd communes

OptionDescription
-c 'comment'comment peut être remplacé par n'importe quelle chaîne. Cette option est généralement utilisée pour spécifier le nom complet d'un utilisateur.
-d home_directoryRépertoire personnel à utiliser à la place de /home/username/.
-e dateDate à laquelle le compte sera désactivé sous le format YYYY-MM-DD.
-f daysNombre de jours après l'expiration du mot de passe avant que le compte soit désactivé. Si 0 est spécifié, le compte est désactivé immédiatement après l'expiration du mot de passe. Si -1 est spécifié, le compte n'est pas désactivé après l'expiration du mot de passe.
-g group_nameNom de groupe ou numéro de groupe du groupe (principal) par défaut de l'utilisateur. Le groupe doit exister avant d'être spécifié ici.
-G group_listListe des noms ou numéros de groupes supplémentaires (autres que ceux par défaut), séparés par des virgules, dont l'utilisateur est membre. Les groupes doivent exister avant d'être spécifiés ici.
-mCréer le répertoire personnel s'il n'existe pas.
-MNe pas créer de répertoire personnel.
-fNe pas créer de groupe privé d'utilisateurs pour l'utilisateur.
-p passwordMot de passe chiffré avec crypt.
-rEntraîne la création d'un compte système avec un ID utilisateur (UID) inférieur à 1000 et sans répertoire personnel.
-sShell de connexion de l'utilisateur, qui est par défaut /bin/bash.
-u uidID utilisateur de l'utilisateur, qui doit être unique et supérieur à 999.
Les options de ligne de commande associées à la commande usermod sont essentiellement les mêmes. Remarquez que si vous souhaitez ajouter un utilisateur à un autre groupe supplémentaire, vous devrez utiliser l'option -a, --append avec l'option -G. Sinon, la liste des groupes supplémentaires de l'utilisateur sera remplacée par ceux spécifiés par la commande usermod -G.

Important

La gamme des ID par défaut des utilisateurs normaux et système a été modifiée dans Red Hat Enterprise Linux 7 comparé aux versions antérieures. Auparavant, les UID 1 à 499 étaient utilisés pour les utilisateurs système et des valeurs supérieures étaient utilisées pour les utilisateurs normaux. La gamme par défaut des maintenant de 1-999 pour les utilisateurs système. Ce changement peut causer des problèmes lors de la migration vers Red Hat Enterprise Linux 7 avec des utilisateurs existants pouvant avoir des UID et des GID entre 500 et 999. Les gammes par défaut des UID et GID peuvent être modifiées dans le fichier /etc/login.defs.

Explication du processus

Les étapes suivantes illustrent ce qu'il se produit si la commande useradd juan est exécutée sur un système sur lequel les mots de passe cachés sont activés :
  1. Une nouvelle ligne pour juan est créée dans /etc/passwd : 
    juan:x:1001:1001::/home/juan:/bin/bash
    La ligne possède les caractéristiques suivantes :
    • Celle-ci commence par le nom d'utilisateur juan.
    • Un x se trouve dans le champ du mot de passe, indiquant que le système utilise des mots de passe cachés.
    • Un UID supérieur à 999 est créé. Dans Red Hat Enterprise Linux 7, les UID inférieurs à 1000 sont réservés à l'utilisation système et ne doivent pas être assignés aux utilisateurs.
    • Un GID supérieur à 999 est créé. Dans Red Hat Enterprise Linux 7, les GID inférieurs à 1000 sont réservés à l'utilisation système et ne doivent pas être assignés aux utilisateurs.
    • Les informations optionnelles GECOS sont laissées vides. Le champ GECOS peut être utilisé pour fournir des informations supplémentaires sur l'utilisateur, comme son nom complet ou son numéro de téléphone.
    • Le répertoire personnel de juan est défini sur /home/juan/.
    • Le shell par défaut est défini sur /bin/bash.
  2. Une nouvelle ligne pour juan est créée dans /etc/shadow: 
    juan:!!:14798:0:99999:7:::
    La ligne possède les caractéristiques suivantes :
    • Celle-ci commence par le nom d'utilisateur juan.
    • Deux points d'exclamation (!!) apparaissent dans le champ du mot de passe du fichier /etc/shadow, qui verrouille le compte.

      Note

      Si un mot de passe chiffré est saisi en utilisant l'indicateur -p, il sera placé dans le fichier /etc/shadow sur la nouvelle ligne pour l'utilisateur.
    • Le mot de passe est paramétré de manière à ne jamais expirer.
  3. Une nouvelle ligne pour un groupe nommé juan est créée dans /etc/group : 
    juan:x:1001:
    Un groupe avec le même nom qu'un utilisateur est appelé un groupe privé d'utilisateurs. Pour obtenir davantage d'informations sur les groupes privés d'utilisateurs, veuillez consulter la section Section 3.1.1, « Groupes privés d'utilisateurs ».
    La ligne créée dans /etc/group possède les caractéristiques suivantes :
    • Celle-ci commence par le nom de groupe juan.
    • Un x apparaît dans le champ du mot de passe, indiquant que le système utilise des mots de passe de groupe cachés.
    • Le GID correspond à celui qui est répertorié pour le groupe principal de juan dans /etc/passwd.
  4. Une nouvelle ligne pour un groupe nommé juan est créée dans /etc/gshadow : 
    juan:!::
    La ligne possède les caractéristiques suivantes :
    • Celle-ci commence par le nom de groupe juan.
    • Un point d'exclamation (!) apparaît dans le champ du mot de passe du fichier /etc/gshadow, qui verrouille le groupe.
    • Tous les autres champs sont vierges.
  5. Un répertoire pour l'utilisateur juan est créé dans le répertoire /home : 
    ~]# ls -ld /home/juan
drwx------. 4 juan juan 4096 Mar  3 18:23 /home/juan
    Ce répertoire appartient à l'utilisateur juan et au groupe juan. Il possède les privilèges read (lecture), write (écriture), et execute (exécution) uniquement pour l'utilisateur juan. Toutes les autres permissions sont refusées.
  6. Les fichiers 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/ : 
    ~]# ls -la /home/juan
total 28
drwx------. 4 juan juan 4096 Mar  3 18:23 .
drwxr-xr-x. 5 root root 4096 Mar  3 18:23 ..
-rw-r--r--. 1 juan juan   18 Jun 22  2010 .bash_logout
-rw-r--r--. 1 juan juan  176 Jun 22  2010 .bash_profile
-rw-r--r--. 1 juan juan  124 Jun 22  2010 .bashrc
drwxr-xr-x. 4 juan juan 4096 Nov 23 15:09 .mozilla
À ce moment, un compte verrouillé nommé juan existe sur le système. Pour l'activer, l'administrateur doit assigner un mot de passe au compte en utilisant la commande passwd et optionnellement, paramétrer des directives concernant l'ancienneté du mot de passe (veuillez consulter la section Sécurité du mot de passe dans le Guide de sécurité Red Hat Enterprise Linux 7 pour obtenir des détails supplémentaires).

3.3.2. Ajout d'un nouveau groupe

Pour ajouter un nouveau groupe au système, veuillez saisir ce qui suit dans l'invite de shell en tant qu'utilisateur root : 
groupadd [options] group_name
…où les options sont des options de ligne de commande comme décrit dans la Tableau 3.3, « Options de ligne de commande groupadd communes ».

Tableau 3.3. Options de ligne de commande groupadd communes

OptionDescription
-f, --forceLorsqu'utilisé avec -g gid et que gid existe déjà, groupadd choisira un nouveau gid unique pour le groupe.
-g gidID de groupe du groupe, qui doit être unique et supérieur à 999.
-K, --key key=valueRemplace les valeurs par défaut de /etc/login.defs.
-o, --non-uniquePermet la création de groupes avec un GID dupliqué.
-p, --password passwordUtilise ce mot de passe chiffré pour le nouveau groupe.
-rEntraîne la création d'un groupe système avec un GID inférieur à 1000.

3.3.3. Création de répertoire de groupes

Les administrateurs système préfèrent habituellement créer un groupe pour chaque projet majeur et assigner des personnes à ce groupe lorsqu'elles ont besoin d'accéder aux fichiers de ce projet. Avec ce schéma traditionnel, la gestion de fichiers est difficile. Lorsque quelqu'un crée un fichier, celui-ci est associé au groupe principal auquel il appartient. Lorsqu'une seule personne travaille sur de multiples projets, il devient difficile d'associer les fichiers corrects au bon groupe. Cependant, avec le schéma UPG, les groupes sont automatiquement assignés aux fichiers créés dans un répertoire sur lequel setgid est défini. « Setgid » rend la gestion des projets de groupes qui partagent un répertoire commun très simple car tout fichier créé par un utilisateur dans le répertoire appartiendra au groupe propriétaire de ce répertoire.
Par exemple, un groupe de personnes a besoin de travailler sur des fichiers du répertoire /opt/myproject/. Il est fait confiance à certaines personnes pour modifier le contenu de ce répertoire, mais pas à tout le monde.
  1. En tant qu'utilisateur root, veuillez créer le répertoire /opt/myproject/ en saisissant ce qui suit dans l'invite de shell : 
    mkdir /opt/myproject
  2. Ajoutez le groupe myproject au système : 
    groupadd myproject
  3. Associez le contenu du répertoire /opt/myproject/ au groupe myproject : 
    chown root:myproject /opt/myproject
  4. Autorisez les utilisateurs du groupe à créer des fichiers dans le répertoire et paramétrez le setgid : 
    chmod 2775 /opt/myproject
    À ce moment, tous les membres du groupe myproject peuvent créer et modifier des fichiers dans le répertoire /opt/myproject/ sans que l'administrateur ne soit obligé de modifier les permissions de fichier à chaque fois qu'un utilisateur écrit un nouveau fichier. Pour vérifier si les permissions ont été paramétrées correctement, veuillez exécuter la commande suivante : 
    ~]# ls -ld /opt/myproject
drwxrwsr-x. 3 root myproject 4096 Mar  3 18:31 /opt/myproject
  5. Ajoutez les utilisateurs au groupe myproject : 
    usermod -aG myproject username

3.4. Ressources supplémentaires

Pour obtenir davantage d'informations sur la manière de gérer les utilisateurs et les groupes dans Red Hat Enterprise Linux, veuillez consulter les ressources répertoriées ci-dessous.

Documentation installée

Pour obtenir des informations sur les divers utilitaires servant à gérer les utilisateurs et les groupes, veuillez consulter les pages de manuel ci-dessous :
  • useradd(8) — la page du manuel de la commande useradd documente comment l'utiliser pour créer de nouveaux utilisateurs.
  • userdel(8) — la page du manuel de la commande userdel documente comment l'utiliser pour supprimer des utilisateurs.
  • usermod(8) — la page du manuel de la commande usermod documente comment l'utiliser pour modifier les utilisateurs.
  • groupadd(8) — la page du manuel de la commande groupadd documente comment l'utiliser pour créer de nouveaux groupes.
  • groupdel(8) — la page du manuel de la commande groupdel documente comment l'utiliser pour supprimer des groupes.
  • groupmod(8) — la page du manuel de la commande groupmod documente comment l'utiliser pour modifier les appartenances aux groupes.
  • gpasswd(1) — la page du manuel de la commande gpasswd documente comment gérer le fichier /etc/group.
  • grpck(8) — la page du manuel de la commande grpck documente comment l'utiliser pour vérifier l'intégrité du fichier /etc/group.
  • pwck(8) — la page du manuel de la commande pwck documente comment l'utiliser pour vérifier l'intégrité des fichiers /etc/passwd et /etc/shadow.
  • pwconv(8) — la page du manuel des commandes pwconv, pwunconv, grpconv, et grpunconv documentent comment convertir des informations cachées pour des mots de passe et des groupes.
  • id(1) — la page du manuel de la commande id documente comment afficher les ID d'utilisateur et de groupe.
Pour obtenir des informations concernant les fichiers de configuration, veuillez consulter :
  • group(5) — la page du manuel du fichier /etc/group documente comment utiliser ce fichier pour définir les groupes de système.
  • passwd(5) — la page du manuel du fichier /etc/passwd documente comment utiliser ce fichier pour définir les informations d'utilisateur.
  • shadow(5) — la page du manuel du fichier /etc/shadow documente comment utiliser ce fichier pour définir les informations d'expiration des mots de passe et des comptes sur ce système.

Documentation en ligne

  • Guide de sécurité Red Hat Enterprise Linux 7 — Le Guide de sécurité de Red Hat Enterprise Linux 7 fournit des informations supplémentaires sur la manière d'assurer le sécurité du mot de passe et de sécuriser la station de travail en activant l'ancienneté des mots de passe et le verrouillage des comptes utilisateur.

Voir aussi

Chapitre 4. Listes des contrôle d'accès (ACL)

Les fichiers et répertoires possèdent des ensembles de permissions pour le propriétaire du fichier, le groupe associé au fichier, ainsi que pour tous les autres utilisateurs du système. Cependant, ces ensembles de permissions sont limités. Par exemple, différentes permissions ne peuvent ne pas être configurées pour différents utilisateurs. Donc, des listes de contrôle d'accès (ACL, de l'anglais (« Access Control Lists ») ont été implémentées.
Le noyau Red Hat Enterprise Linux offre la prise en charge des ACL sur les systèmes de fichiers ext3 et les systèmes de fichiers exportés NFS. On trouve aussi des ACL sur les systèmes de fichiers ext3 auxquels on peut accéder via Samba.
Le paquet acl et la prise en charge dans le noyau sont requis pour implémenter les ACL. Ce paquet contient les utilitaires nécessaires pour l'ajout, la modification, la suppression et la récupération d'informations sur les ACL.
Les commandes cp et mv copient ou déplacent toutes les ACL associées à des fichiers et répertoires.

4.1. Monter des systèmes de fichiers

Avant d'utiliser des ACL pour un fichier ou un répertoire, la partition du fichier ou répertoire doit être montée avec la prise en charge des ACL. S'il s'agit d'un système de fichiers ext3 local, celui-ci peut être monté avec la commande suivante :
mount -t ext3 -o acl device-name partition
For example:
mount -t ext3 -o acl /dev/VolGroup00/LogVol02 /work
De manière alternative, si la partition est répertoriée dans le fichier /etc/fstab, l'entrée de la partition peut inclure l'option acl : 
LABEL=/work      /work       ext3    acl        1 2
Si un système de fichiers ext3 est accédé via Samba et que les ACL ont été activées pour cela, ces ACL seront reconnues car Samba a été compilé avec l'option --with-acl-support. Aucun indicateur particulier n'est requis lors de l'accession ou du montage d'un partage Samba.

4.1.1. NFS

Par défaut, si le système de fichiers exporté par un serveur NFS prend en charge les ACL et le client NFS peut lire les ACL, alors les ACL sont utilisés par le système client.
Pour désactiver les ACL sur les partages NFS lorsque vous configurez le serveur, inclure l'option no_acl dans le fichier /etc/exports. Pour désactiver les ACL d'un partage NFS quand vous la montez sur un client, montez-la avec l'option no_acl via la ligne de commandes ou par le fichier /etc/fstab

4.2. Définir les ACL d'accès

Il existe deux types d'ACL : les ACL d'accès et les ACL par défaut. Une ACL d'accès est une liste de contrôle d'accès pour un fichier ou répertoire particulier. Une ACL par défaut peut uniquement être associée à un répertoire. Si un fichier dans le répertoire ne possède pas d'ACL d'accès, alors il utilise les règles de l'ACL par défaut du répertoire. Les ACL par défaut sont optionnelles.
Les ACL peuvent être configurées :
  1. Par utilisateur
  2. Par groupe
  3. Via le masque des droits en vigueur
  4. Pour les utilisateur ne se trouvant pas dans le groupe d'utilisateurs du fichier
L'utilitaire setfacl définit les ACL pour les fichiers et répertoires. Veuillez utiliser l'option -m pour ajouter ou modifier l'ACL d'un fichier ou répertoire : 
# setfacl -m rules files
Des règles (rules) doivent être spécifiées sous les formats suivants. De multiples règles peuvent être spécifiées dans la même commande si celles-ci sont séparées par des virgules.
u:uid:perms
Définit l'ACL d'accès d'un utilisateur. Le nom d'utilisateur, ou UID, peut être spécifié. L'utilisateur peut être tout utilisateur valide sur le système.
g:gid:perms
Définit l'ACL d'accès d'un groupe. Le nom du groupe, ou GID, peut être spécifié. Le groupe peut être tout groupe valide sur le système.
m:perms
Définit le masque des permissions. Le masque est l'union de toutes les permissions du groupe propriétaire et des toutes les entrées d'utilisateur et de groupe.
o:perms
Définit l'ACL d'accès du fichier pour les utilisateurs ne faisant pas partie du groupe.
Les permissions (perms) doivent être une combinaison des caractères r, w et x pour lecture, écriture, et exécution.
Si un fichier ou répertoire possède déjà une ACL et que la commande setfacl est utilisée, les règles supplémentaires sont ajoutées à l'ACL existante ou la règle existante sera modifiée.

Exemple 4.1. Donner des permissions de lecture et écriture

Par exemple, pour donner les permissions de lecture et écriture à l'utilisateur andrius : 
# setfacl -m u:andrius:rw /project/somefile
Pour supprimer toutes les permissions d'un utilisateur, d'un groupe, ou autres, veuillez utiliser l'option -x et ne spécifier aucune permission : 
# setfacl -x rules files

Exemple 4.2. Supprimer toutes les permissions

Par exemple, pour supprimer toutes les permissions de l'utilisateur possédant l'UID 500 : 
# setfacl -x u:500 /project/somefile

4.3. Définit les ACL par défaut

Pour définir une ACL par défaut, veuillez ajouter d: avant la règle et spécifiez un répertoire à la place d'un nom de fichier.

Exemple 4.3. Définir les ACL par défaut

Par exemple, pour définir l'ACL par défaut du répertoire /share/ afin de pouvoir effectuer des lectures et exécutions pour les utilisateurs ne se trouvant pas dans le groupe d'utilisateurs (une ACL d'accès pour un fichier individuel peut la remplacer) : 
# setfacl -m d:o:rx /share

4.4. Récupérer des ACL

Pour déterminer les ACL existantes pour un fichier ou répertoire, veuillez utiliser la commande getfacl. Dans l'exemple ci-dessous, getfacl est utilisé pour déterminer les ACL existantes pour un fichier.

Exemple 4.4. Récupérer des ACL

# getfacl home/john/picture.png
La commande ci-dessus retourne la sortie suivante : 
# file: home/john/picture.png 
# owner: john 
# group: john 
user::rw- 
group::r-- 
other::r--
Si un répertoire avec une ACL par défaut est spécifié, l'ACL par défaut est aussi affichée comme illustré ci-dessous. Par exemple, getfacl home/sales/ affichera une sortie similaire à la suivante : 
# file: home/sales/ 
# owner: john 
# group: john 
user::rw- 
user:barryg:r-- 
group::r-- 
mask::r-- 
other::r-- 
default:user::rwx 
default:user:john:rwx 
default:group::r-x 
default:mask::rwx 
default:other::r-x

4.5. Archiver des systèmes de fichiers avec des ACL

Par défaut, la commande dump préserve désormais les ACL pendant les opérations de sauvegarde. Lors de l'archivage d'un fichier ou d'un système de fichiers avec tar, utilisez l'option --acls pour préserver les ACL. De manière similaire, lors de l'utilisation de cp pour copier des fichiers avec des ACL, veuillez inclure l'option --preserve=mode afin de vous assurer que les ACL soient également copiées. En outre, l'option -a (équivalente à -dR --preserve=all) de cp préserve également les ACL lors des opérations de sauvegarde ainsi que d'autres informations, commes les horodatages, les contextes SELinux, etc. Pour obtenir davantage d'informations sur dump, tar, ou cp, veuillez consulter les pages man respectives.
L'utilitaire star est similaire à l'utilitaire tar car il peut être utilisé pour générer des archives de fichiers ; cependant, certaines de ses options sont différentes. Veuillez consulter le Tableau 4.1, « Options de ligne de commande pour star » pour obtenir une liste des options communément utilisées. Pour toutes les options disponibles, veuillez consulter man star. Le paquet star est requis pour faire usage de cet utilitaire.

Tableau 4.1. Options de ligne de commande pour star

OptionDescription
-cCrée un fichier archive.
-nNe pas extraire les fichiers. À utiliser en conjonction avec -x pour afficher le résultat provoqué par l'extraction de fichiers.
-rRemplace les fichiers dans l'archive. Les fichiers sont écrits à la fin du fichier archive, remplaçant tout fichier ayant le même chemin et le même nom de fichier.
-tAffiche le contenu du fichier archive.
-uMet à jour le fichier archive. Les fichiers sont écrits à la fin de l'archive si ceux-ci n'existent pas dans l'archive, ou si les fichiers sont plus récents que les fichiers de même nom dans l'archive. Cette option fonctionne uniquement si l'archive est un fichier ou une bande non-bloquée pouvant être inversé.
-xExtrait les fichiers de l'archive. Si utilisé avec -U et qu'un fichier dans l'archive est plus ancien que le fichier correspondant sur le système de fichers, le fichier ne sera pas extrait.
-helpAffiche les options les plus importantes.
-xhelpAffiche les options les moins importantes.
-/Ne pas supprimer les barres obliques des noms de fichiers lors de l'extraction de fichiers d'une archive. Par défaut, celles-ci sont supprimées lorsque les fichiers sont extraits.
-aclPendant la création ou l'extraction, archive ou restaure toute ACL associée aux fichiers et répertoires.

4.6. Compatibilité avec d'anciens systèmes

Si une ACL a été définie sur un fichier quelconque dans un système de fichiers donné, ce système de fichiers possèdera l'attribut ext_attr. Cet attribut peut être affiché à l'aide de la commande suivante : 
# tune2fs -l filesystem-device
Un système de fichier ayant acquis l'attribut ext_attr peut être monté avec d'anciens noyaux, mais ces noyaux n'appliqueront aucune ACL définie.
Les versions de l'utilitaire e2fsck incluses dans la version 1.22 et dans les versions supérieures du paquet e2fsprogs (y compris les versions dans Red Hat Enterprise Linux 2.1 et 4) peuvent vérifier un système de fichiers avec l'attribut ext_attr. Les versions plus anciennes refuseront de le vérifier.

4.7. Références des ACL

Veuillez consulter les pages man pour obtenir davantage d'informations.
  • man acl — Description des ACL
  • man getfacl — Traite de la manière d'obtenir des listes de contrôle d'accès
  • man setfacl — Explique comment définir des listes de contrôle d'accès aux fichiers
  • man star — Explique l'utilitaire star et ses nombreuses options

Chapitre 5. Obtention de privilèges

Les administrateurs système, et dans certains cas les utilisateurs, doivent effectuer certaines tâches avec un accès administratif. L'accès au système en tant qu'utilisateur root est potentiellement dangereux et peut causer des dommages qui se répandent sur le système et sur les données. Ce chapitre couvre les manières d'obtenir des privilèges administratifs en utilisant des programmes setuid tels que su et sudo. Ces programmes autorisent des utilisateurs spécifiques à effectuer des tâches qui seraient normalement uniquement disponibles à l'utilisateur root tout en conservant un niveau de contrôle et de sécurité du système élevés.
Veuillez consulter le Guide de sécurité Red Hat Enterprise Linux 7 pour obtenir davantage d'informations sur les contrôles administratifs, sur les dangers potentiels et sur les manières de prévenir les pertes de données résultant d'une utilisation incorrecte d'un accès privilégié.

5.1. La commande su

Lorsqu'un utilisateur exécute la commande su, il lui est demandé le mot de passe de l'utilisateur root. Une invite de shell root s'ouvrira après l'authentification.
Une fois connecté par le biais de la commande su, l'utilisateur devient l'utilisateur root et possède un accès administratif absolu sur le système. Veuillez remarquer que cet accès reste sujet aux restrictions imposées par SELinux, si activé. En outre, une fois qu'un utilisateur est connecté en tant qu'utilisateur root, il est lui est possible d'utiliser la commande su pour modifier tout autre utilisateur sur le système sans avoir à saisir de mot de passe.
Comme ce programme est puissant, les administrateurs d'une organisation pourraient souhaiter limiter l'accès à cette commande.
L'une des simple manières de prcéder consiste à ajouter des utilisateurs à un groupe administratif particulier appelé wheel. Pour cela, veuillez saisir la commande suivante en tant qu'utilisateur root : 
~]# usermod -a -G wheel username
Dans la commande précédente, veuillez remplacer username par le nom d'utilisateur que vous souhaitez ajouter au groupe wheel.
Vous pouvez également utiliser l'outil des paramètres Utilisateurs pour modifier les appartenances aux groupes comme suit. Veuillez remarquer que vous aurez besoin de privilèges d'administrateur pour effectuer cette procédure.
  1. Veuillez appuyer sur la touche Super pour accéder à « Vue d'ensembles des activités », saisissez Utilisateurs puis appuyez sur Entrée. L'outil des paramètres Utilisateurs s'affiche. La touche Super apparaît sous une variété de formes, selon le clavier et autre matériel, mais le plus souvent, il s'agit de la touche Windows ou Commande, et elle se trouve habituellement à gauche de la Barre d'espace.
  2. Pour autoriser les modifications, veuillez cliquer sur le bouton Déverrouiller, puis saisissez un mot de passe d'administrateur valide.
  3. Veuillez cliquer sur l'icône dans la colonne de gauche pour afficher les propriétés de l'utilisateur dans le volet du côté droit.
  4. Modifiez le Type de compte de Standard à Administrateur. Cela aura pour effet d'ajouter l'utilisateur au groupe wheel.
Veuillez consulter la Section 3.2, « Gestion des utilisateurs dans un environnement graphique » pour obtenir davantage d'informations sur l'outil Utilisateurs.
Après avoir ajouté les utilisateurs souhaités au groupe wheel, il est recommandé d'autoriser ces utilisateurs spécifiques uniquement à utiliser la commande su. Pour faire cela, veuillez modifier le fichier de configuration Pluggable Authentication Module (PAM) de su, /etc/pam.d/su. Ouvrez ce fichier dans un éditeur de texte et enlevez la ligne suivante du commentaire en supprimant le caractère # : 
#auth           required        pam_wheel.so use_uid
Ce changement signifie que seuls les membres du groupe administratif wheel peuvent basculer sur un autre utilisateur en utilisant la commande su.

Note

L'utilisateur root fait partie du groupe wheel par défaut.

5.2. La commande sudo

La commande sudo offre une autre approche pour donner un accès administratif aux utilisateurs. Lorsque des utilisateurs de confiance ajoutent sudo avant une commande administrative, il leur est demandé leur propre mot de passe. Puis, lorsqu'ils ont été authentifié et en supposant que la commande soit autorisée, la commande administrative est exécutée comme s'ils étaient un utilisateur root.
Le format de base de la commande sudo est comme suit : 
sudo command
Dans l'exemple ci-dessus, command sera remplacé par une commande normalement réservée à l'utilisateur root, telle que mount.
La commande sudo offre un haut niveau de flexibilité. Par exemple, seuls les utilisateurs répertoriés dans le fichier de configuration /etc/sudoers sont autorisés à utiliser la commande sudo et la commande est exécutée dans le shell de l'utilisateur, et non dans un shell root. Cela signifie que le shell root peut être complètement désactivé, comme indiqué dans le Guide de sécurité Red Hat Enterprise Linux 7.
Chaque authentification réussie en utilisant la commande sudo est journalisée sur le fichier /var/log/messages et la commande passée avec le nom d'utilisateur de son émetteur est journalisée sur le fichier /var/log/secure. Si davantage de détails sont requis, veuillez utiliser le module pam_tty_audit pour activer les audits TTY pour des utilisateurs spécifiques en ajoutant la ligne suivante à votre fichier /etc/pam.d/system-auth : 
session required pam_tty_audit.so disable=pattern enable=pattern
où pattern représente une liste séparée par des virgules d'utilisateurs avec un usage optionnel de globs. Par exemple, la configuration suivante activera les audits TTY pour l'utilisateur root et les désactivera pour tous les autres utilisateurs : 
session required pam_tty_audit.so disable=* enable=root

Important

Configurer le module PAM pam_tty_audit pour les audits TTY n'enregistre que les entrées TTY. Cela signifie que, lorsque l'utilisateur audité se connecte, pam_tty_audit enregistre les saisies de touches précises de l'utilisateur dans le fichier /var/log/audit/audit.log. Pour plus d'informations, voir la page man pam_tty_audit(8).
Un autre avantage de la commande sudo est qu'un administrateur peut autoriser différents utilisateurs à accéder à des commandes spécifiques en fonction de leurs besoins.
Les administrateurs souhaitant modifier le fichier de configuration sudo, /etc/sudoers, doivent utiliser la commande visudo.
Pour octroire à quelqu'un la totalité des privilèges administratifs, veuillez saisir visudo et ajoutez une ligne similaire à la suivante dans la section de spécification des privilèges utilisateur : 
juan ALL=(ALL) ALL
Dans cet exemple, l'utilisateur juan peut utiliser sudo à partir de n'importe quel hôte et peut exécuter n'importe quelle commande.
L'exemple ci-dessous illustre le niveau de granularité possible lors de la configuration de sudo : 
%users localhost=/usr/sbin/shutdown -h now
Cet exemple montre que tout membre du groupe de système users peut exécuter la commande /sbin/shutdown -h now tant que c'est à partir de la console.
La page man sudoers offre une liste détaillée des options pour ce fichier.

Important

Il existe plusieurs risques potentiels à ne pas oublier lors de l'utilisation de la commande sudo. Vous pouvez les éviter en modifier le fichier de configuration /etc/sudoers en utilisant visudo, comme indiqué ci-dessus. Laisser le ficher /etc/sudoers dans son état par défaut donnera à tout utilisateur du groupe wheel un accès root illimité.
  • Par défaut, sudo stocke le mot de passe de l'utilisateur sudo pour une période de cinq minutes. Toute utilisation de la commande pendant cette période ne demandera pas à l'utilisateur de saisir à nouveau le mot de passe. Ceci peut être exploité par une personne malveillante si l'utilisateur laisse son poste de travail connecté, sans surveillance et déverrouillé. Ce comportement peut être modifié en ajoutant la ligne suivante au fichier /etc/sudoers : 
    Defaults    timestamp_timeout=value
    où value est la longueur souhaitée du délai en minutes. Définir value sur 0 amène sudo à réclamer un mot de passe à chaque fois.
  • Si le compte sudo d'utilisateur est compromis, une personne malveillante peut utiliser sudo pour ouvrir un nouveau shell avec des privilèges administratifs : 
    sudo /bin/bash
    L'ouverture d'un nouveau shell en tant qu'utilisateur root de cette manière, ou d'une manière similaire, peut offrir un accès administratif à une personne malveillante sur une durée théoriquement illimitée, outrepassant ainsi la limite de la durée du délai spécifiée dans le fichier /etc/sudoers et il ne sera pas demandé à cette personne malveillante de ressaisir le mot de passe sudo tant que la session ouverte n'est pas fermée.

5.3. Ressources supplémentaires

Même si les programmes permettant aux utilisateurs d'obtenir des privilèges administratifs présentent des risques de sécurité potentiels, les questions sur la sécurité, en général, est au-delà de l'étendue de ce livre particulier. Veuillez donc consulter les ressources répertoriées ci-dessous pour obtenir davantage d'informations concernant la sécurité et les accès privilégiés.

Documentation installée

  • su(1) — la page man de su offre des informations concernant les options dispionibles avec cette commande.
  • sudo(8) — la page man de sudo inclut une description détaillée de la commande et répertorie les options disponibles pour personnaliser son comportement.
  • pam(8) — page du manuel décrivant l'utilisation des modules PAM manual (« Pluggable Authentication Modules ») pour Linux.

Documentation en ligne

  • Guide de sécurité Red Hat Enterprise Linux 7 — le Guide de sécurité de Red Hat Enterprise Linux 7 traite de manière plus approfondie des problèmes de sécurité pertinents aux programmes setuid, ainsi que des techniques utilisées pour réduire ces risques.

Voir aussi

Partie II. Abonnement et support

Pour recevoir des mises à jour de logiciels sur un système Red Hat Enterprise Linux, celui-ci doit être abonné au réseau de remise de contenu « Red Hat Content Delivery Network » (ou CDN) et les référentiels appropriés doivent être activés. Cette partie décrit comment abonner un système au réseau CDN de Red Hat (« Red Hat Content Delivery Network »).
Red Hat fournit un support technique via le Portail Client. Ce support est également accessible directement à partir de la ligne de commande en utilisant l'outil « Red Hat Support Tool ». Cette partie décrit l'utilisation de cet outil de ligne de commande.

Chapitre 6. Enregistrer le système et Gérer les abonnements

Le service d'abonnement fournit un mécanisme pour gérer l'ensemble des logiciels Red Hat et vous permet d'installer des logiciels supplémentaires ou de mettre à jour les programmes déjà installés à des versions plus récentes, en utilisant le gestionnaire de paquets yum. Dans Red Hat Enterprise Linux 7, pour enregistrer votre système et attacher des abonnements, il est recommandé d'utiliser Red Hat Subscription Management.

Note

Il est également possible d'enregistrer le système et d'y ajouter des abonnements après l'installation pendant le processus initial d'installation. Pour plus d'informations sur le processus initial d'installation, consulter le chapitre Installation initiale du Guide d'installation de Red Hat Enterprise Linux 7. Notez que le processus initial d'installation n'apparaît que sur les systèmes possédant une installation Window Xau moment de l'installation.

6.1. Enregistrer le système et y ajouter des abonnnements

Veuillez effectuer les étapes suivantes pour enregistrer votre système et attacher un ou plusieurs abonnements en utilisant Red Hat Subscription Management. Remarquez que toutes les commandes subscription-manager sont censées être exécutées en tant qu'utilisateur root.
  1. Exécutez la commande suivante pour enregistrer votre système. Votre nom d'utilisateur et votre mot de passe vous seront demandés. Remarquez que le nom d'utilisateur et le mot de passe sont les mêmes que vos identifiants de connexion pour le Portail Client Red Hat. 
    subscription-manager register
  2. Déterminer l'ID du pool d'un abonnement dont vous avez besoin. Pour ce faire, tapez ce qui suit à une invite du shell pour afficher une liste de tous les abonnements qui sont disponibles pour votre système : 
    subscription-manager list --available
    Pour chaque abonnement disponible, cette commande affiche son nom, son identifiant unique, sa date d'expiration et autres détails liés à votre abonnement. Pour répertorier les abonnements de toutes les architectures, ajouter l'option --all. L'ID du pool est répertorié sur une ligne commençant par Pool ID.
  3. Attachez un abonnement qui convient au système en saisissant la commande suivante : 
    subscription-manager attach --pool=pool_id
    Remplacez pool_id par l'ID de pool déterminé dans l'étape précédente.
    Pour vérifier la liste des abonnements actuellement attachés à votre système, exécutez, à tout moment : 
    subscription-manager list --consumed
Pour obtenir davantage d'informations sur la manière d'enregistrer votre système en utilisant Red Hat Subscription Management et d'y associer des abonnements, veuillez consulter l'article de solution concerné. Pour obtenir des informations sur les abonnements, voir la collection de guides Red Hat Subscription Management.

6.2. Gérer des référentiels de logiciels

Lorsqu'un système est abonné à « Red Hat Content Delivery Network » (Réseau de remise de contenu Red Hat), un fichier référentiel est créé dans le répertoire /etc/yum.repos.d/. Pour vérifier cela, veuillez utiliser yum pour répertorier les référentiels activés : 
yum repolist
Red Hat Subscription Management vous permet également de manuellement activer ou désactiver les référentiels de logiciels fournis par Red Hat. Pour répertorier tous les référentiels disponibles, veuillez utiliser la commande suivante : 
subscription-manager repos --list
Les noms de référentiel dépendent de la version spécifique de Red Hat Enterprise Linux que vous utilisez et sont sous le format suivant : 
rhel-variant-rhscl-version-rpms
rhel-variant-rhscl-version-debug-rpms
rhel-variant-rhscl-version-source-rpms
Quand variant est la variante du système Red Hat Enterprise Linux (server ou workstation), et version est la version du système Red Hat Enterprise Linux (6 ou 7), par exemple : 
rhel-server-rhscl-7-eus-rpms
rhel-server-rhscl-7-eus-source-rpms
rhel-server-rhscl-7-eus-debug-rpms
Pour activer un référentiel, saisir la commande suivante : 
subscription-manager repos --enable repository
Remplacez référentiel par le nom d'un référentiel à activer.
De même, pour désactiver un référentiel, veuillez exécuter la commande suivante : 
subscription-manager repos --disable repository
La Section 8.5, « Configurer Yum et les référentiels Yum  » fournit des informations détaillées sur la gestion de référentiels de logiciels en utilisant yum.

6.3. Supprimer des abonnements

Pour supprimer un abonnement particulier, veuillez effectuer les étapes suivantes.
  1. Déterminez le numéro de série de l'abonnement que vous souhaitez supprimer en répertoriant les informations sur les abonnements déjà attachés : 
    subscription-manager list --consumed
    Le numér de série est le numéro répertorié en tant que sériel (« serial »). Par exemple, 744993814251016831 ci-dessous : 
    SKU:               ES0113909
Contract:          01234567
Account:           1234567
Serial:            744993814251016831
Pool ID:           8a85f9894bba16dc014bccdd905a5e23
Active:            False
Quantity Used:     1
Service Level:     SELF-SUPPORT
Service Type:      L1-L3
Status Details:    
Subscription Type: Standard
Starts:            02/27/2015
Ends:              02/27/2016
System Type:       Virtual
  2. Saisissez une commande comme suit pour supprimer l'abonnement sélectionné : 
    subscription-manager remove --serial=serial_number
    Remplacez serial_number par le numéro de série déterminé dans l'étape précédente.
Pour supprimer tous les abonnements attachés au système, exécutez la commande suivante : 
subscription-manager remove --all

6.4. Ressources supplémentaires

Pour obtenir davantage d'informations sur la manière d'enregistrer votre système en utilisant Red Hat Subscription Management et d'y associer des abonnements, veuillez consulter les ressources ci-dessous.

Documentation installée

  • subscription-manager(8) — la page du manuel de Red Hat Subscription Management fournit une liste complète des options et commandes prises en charge.
  • Collection de guides Red Hat Subscription Management — Ces guides contiennent des informations détaillées sur la manière d'utiliser Red Hat Subscription Management.
  • Guide d'installation — veuillez consulter le chapitre Installation initiale pour obtenir des informations détaillées sur la manière de s'enregistrer pendant le processus d'installation initiale.

Voir également

  • Le Chapitre 5, Obtention de privilèges documente la façon d'obtenir des privilèges administratifs en utilisant les commandes su et sudo.
  • Le Chapitre 8, Yum fournit des informations sur l'utilisation du gestionnaire de paquets yum pour installer et mettre à jour des logiciels.

Chapitre 7. Accéder au support en utilisant l'outil « Red Hat Support Tool »

L'outil Red Hat Support Tool, dans le paquet redhat-support-tool, peut fonctionner comme shell interactif ou comme programme à exécution unique. Il peut être exécuté sur SSH ou à partir de n'importe quel terminal. Par exemple, il permet d'effectuer des recherches dans la base de connaissances Red Hat (« Red Hat Knowledgebase ») à partir de la ligne de commande, de copier les solutions directement sur la ligne de commande, de créer et de mettre à jour des dossiers de support, et d'envoyer des fichier à Red Hat pour les analyser.

7.1. Installer l'outil Red Hat Support Tool

L'outil Red Hat Support Tool est installé par défaut sur Red Hat Enterprise Linux. Si requis, pour s'assurer qu'il soit bien installé, saisissez la commande suivante en tant qu'utilisateur root : 
~]# yum install redhat-support-tool

7.2. Enregistrer l'outil Red Hat Support Tool en utilisant la ligne de commande

Pour enregistrer Red Hat Support Tool sur le portail client en utilisant la ligne de commande, veuillez procéder comme suit : 
  1. ~]# redhat-support-tool config user nom d'utilisateur
    Quand nom d'utilisateur correspond au nom d'utilisateur du compte sur le Portail Client Red Hat. 
  2. ~]# redhat-support-tool config password
Please enter the password for username:

7.3. Utiliser Red Hat Support Tool en mode shell interactif

Pour lancer l'outil en mode interactif, veuillez saisir la commande suivante : 
~]$ redhat-support-tool
Welcome to the Red Hat Support Tool.
Command (? for help):
L'outil peut être exécuté en tant qu'utilisateur non privilégié avec un ensemble de commandes par conséquent réduit, ou en tant qu'utilisateur root.
Les commandes peuvent être répertoriées en saisissant le caractère ?. Le programme ou la sélection du menu peuvent être « quittés » en saisissant le caractère q ou e. Votre nom d'utilisateur et votre mot de passe du Portail Client Red Hat vous seront demandés lors de votre première recherche sur la base de connaissances ou des dossiers de support. Alternativement, définissez le nom d'utilisateur et le mot de passe de votre compte Portail Client Red Hat en utilisant le mode interactif, et optionnellement, enregistrez-le sur le fichier de configuration.

7.4. Configurer l'outil Red Hat Support Tool

Lorsqu'en mode interactif, les options de configuration peuvent être répertoriées en saisissant la commande config --help : 
~]# redhat-support-tool
Welcome to the Red Hat Support Tool.
Command (? for help): config --help

Usage: config [options] config.option <new option value>

Use the 'config' command to set or get configuration file values.
Options:
  -h, --help    show this help message and exit
  -g, --global  Save configuration option in /etc/redhat-support-tool.conf.
  -u, --unset   Unset configuration option.

The configuration file options which can be set are:
 user      : The Red Hat Customer Portal user.
 password  : The Red Hat Customer Portal password.
 debug     : CRITICAL, ERROR, WARNING, INFO, or DEBUG
 url       : The support services URL.  Default=https://api.access.redhat.com
 proxy_url : A proxy server URL.
 proxy_user: A proxy server user.
 proxy_password: A password for the proxy server user.
 ssl_ca    : Path to certificate authorities to trust during communication.
 kern_debug_dir: Path to the directory where kernel debug symbols should be downloaded and cached. Default=/var/lib/redhat-support-tool/debugkernels

Examples:
- config user
- config user my-rhn-username
- config --unset user

Procédure 7.1. Enregistrer l'outil Red Hat Support Tool en utilisant le mode interactif

Pour enregistrer Red Hat Support Tool sur le portail client en utilisant le mode interactif, veuillez procéder comme suit :
  1. Lancez l'outil en saisissant la commande suivante : 
    ~]# redhat-support-tool
  2. Saisissez votre nom d'utilisateur du Portail Client Red Hat : 
    Command (? for help): config user nom d'utilisateur
    Pour enregistrer votre nom d'utilisateur dans le fichier de configuration globale , veuillez ajouter l'option -g.
  3. Saisissez votre mot de passe du Portail Client Red Hat : 
    Command (? for help): config password
Please enter the password for username:

7.4.1. Enregistrer les paramètres dans les fichiers de configuration

L'outil Red Hat Support Tool, sauf contre-indication, stocke les valeurs et options localement dans le répertoire personnel de l'utilisateur actuel, en utilisant le fichier de configuration ~/.redhat-support-tool/redhat-support-tool.conf. Si requis, il est recommandé d'enregistrer les mots de passe dans ce fichier car il est uniquement lisible par cet utilisateur particulier. Lorsque l'outil est lancé, il lira les valeurs du fichier de configuration globale /etc/redhat-support-tool.conf ainsi que celles du fichier de configuration local. Les valeurs et options stockées localement ont priorité sur les paramètres stockés globalement.

Avertissement

Il est recommandé de ne pas enregistrer de mot de passe dans le fichier de configuration globale /etc/redhat-support-tool.conf car le mot de passe est uniquement chiffré base64 et peut facilement être déchiffré. En outre, le fichier est lisible par tous.
Pour enregistrer une valeur ou une option sur le fichier de configuration globale, veuillez ajouter l'option -g, --global comme suit : 
Command (? for help): config setting -g value

Note

Pour être en mesure d'enregistrer les paramètres globalement, en utilisant l'option -g, --global, l'outil Red Hat Support Tool doit être exécuté en tant qu'utilisateur root car les utilisateurs normaux n'ont pas les permissions requises pour écrire sur /etc/redhat-support-tool.conf.
Pour supprimer une valeur ou une option du fichier de configuration local, veuillez ajouter l'option -u, --unset comme suit : 
Command (? for help): config setting -u value
Cela supprimera et annulera la définition du paramètre de l'outil, et réutilisera le paramètre équivalent situé dans le fichier de configuration globale, si disponible.

Note

Lorsqu'exécuté en tant qu'utilisateur non privilégié, les valeurs stockées dans le fichier de configuration globale ne peuvent pas être supprimées en utilisant l'option -u, --unset, mais elles peuvent être effacées, et annulées de la définition, à partir de l'instance actuellement en cours d'utilisation de l'outil en utilisant l'option -g, --global simultanément avec l'option -u, --unset. Si exécuté en tant qu'utilisateur root, les valeurs et options peuvent être supprimées du fichier de configuration globale en utilisant -g, --global simultanément avec l'option -u, --unset.

7.5. Créer et mettre à jour des dossiers de support en utilisant le mode interactif

Procédure 7.2. Créer un nouveau dossier de support en utilisant le mode interactif

Pour créer un nouveau dossier de support en utilisant le mode interactif, veuillez procéder comme suit :
  1. Lancez l'outil en saisissant la commande suivante : 
    ~]# redhat-support-tool
  2. Saisissez la commande opencase : 
    Command (? for help): opencase
  3. Suivez les invites affichées sur l'écran pour sélectionner un produit, puis une version.
  4. Saisissez un récapitulatif du dossier.
  5. Saisissez une description du dossier, puis appuyez sur Ctrl+D sur une ligne vide lorsque vous aurez terminé.
  6. Sélectionnez une sévérité pour le dossier.
  7. Optionnellement, vous pouvez choisir si une solution au problème existe avant de créer un dossier de support.
  8. Confirmez que vous souhaitez tout de même créer le dossier de support. 
    Le dossier de support 0123456789 a été créé
  9. Optionnellement, vous pouvez choisir d'attacher un rapport SOS.
  10. Optionnellement, vous pouvez choisir d'attacher un fichier.

Procédure 7.3. Afficher et mettre à jour un dossier de support existant en utilisant le mode interactif

Pour afficher et mettre à jour un dossier de support existant en utilisant le mode interactif, veuillez procéder comme suit :
  1. Lancez l'outil en saisissant la commande suivante : 
    ~]# redhat-support-tool
  2. Saisissez la commande getcase : 
    Command (? for help): getcase case-number
    Quand numéro de cas correspond au numéro du dossier que vous souhaitez afficher et mettre à jour.
  3. Suivez les invites à l'écran pour afficher le dossier, modifier ou ajouter des commentaires, et pour obtenir ou ajouter des pièces jointes.

Procédure 7.4. Modifier un dossier de support existant en utilisant le mode interactif

Pour modifier les attributs d'un dossier de support existant en utilisant le mode interactif, veuillez procéder comme suit :
  1. Lancez l'outil en saisissant la commande suivante : 
    ~]# redhat-support-tool
  2. Saisissez la commande modifycase : 
    Command (? for help): modifycase numéro de cas
    Quand numéro de cas correspond au numéro du dossier que vous souhaitez afficher et mettre à jour.
  3. La liste de modification de sélection s'affiche : 
    Type the number of the attribute to modify or 'e' to return to the previous menu.
 1 Modify Type
 2 Modify Severity
 3 Modify Status
 4 Modify Alternative-ID
 5 Modify Product
 6 Modify Version
End of options.
    Suivez les invites affichées sur l'écran pour modifier une ou plusieurs des options.
  4. Par exemple, pour modifier le statut, veuillez saisir 3 : 
    Selection: 3
 1   Waiting on Customer                                                        
 2   Waiting on Red Hat                                                         
 3   Closed                                                                     
Please select a status (or 'q' to exit):

7.6. Afficher des dossiers de support sur la ligne de commande

L'affichage du contenu d'un dossier sur la ligne de commande offre une manière simple et rapide d'appliquer des solutions à partir de la ligne de commande.
Pour afficher un dossier de support existant sur la ligne de commande, veuillez saisir une commande comme suit : 
~]# redhat-support-tool getcase case-number
Avec numéro de cas comme numéro du dossier que vous souhaitez télécharger.

7.7. Ressources supplémentaires

L'article de la base de connaissances Red Hat Knowledgebase Red Hat Support Tool offre des informations supplémentaires, des exemples, et des tutoriels vidéos.

Partie III. Installer et gérer un logiciel

Tous les logiciels sur un système Red Hat Enterprise Linux sont divisés en paquets RPM pouvant être installés, mis à niveau, ou supprimés. Cette partie décrit comment gérer des paquets sur Red Hat Enterprise Linux en utilisant Yum.

Chapitre 8. Yum

Yum est le gestionnaire de paquets de Red Hat qui peut rechercher des informations sur les paquets disponibles, extraire des paquets de référentiels, les installer et les désinstallez, et mettre à jour un système complet à la dernière version disponible. Yum assure la résolution de dépendances automatiquement lorsque l'on met à jour, installe ou supprime des paquets, et donc, est capable de déterminer, chercher et installer tous les paquets dépendants disponibles automatiquement.
Yum peut être configuré avec des référentiels ou sources de paquets supplémentaires, et fournit également de nombreux greffons qui améliorent et étendent ses capacités. Yum est capable d'effectuer de nombreuses tâches que RPM peut effectuer. De plus, bon nombre des options de ligne de commande sont similaires. Yum permet une gestion des paquets simple et aisée sur une même machine ou sur un groupe de machines.
Les sections suivantes assument que votre système a été enregistré avec Red Hat Subscription Management au moment de l'intallation selon les instructions qui se trouvent dans Red Hat Enterprise Linux 7 Installation Guide. Si votre système n'est pas enregistré, consulter Chapitre 6, Enregistrer le système et Gérer les abonnements.

Important

Yum fournit une gestion de paquets sécurisée grâce à l'activation d'un contrôle de signatures GPG (de l'anglais Gnu Privacy Guard ; également connu sous le nom GnuPG) sur tous les référentiels de paquets (sources de paquets), ou sur des référentiels individuels. Lorsque le contrôle des signatures est activé, yum refusera d'installer tous les paquets qui ne sont pas signés-GPG avec la clé appropriée pour ce référentiel. Cela signifie que vous pouvez être rassurés que les paquets RPM que vous téléchargez et installez sur votre système sont d'une source fiable, comme Red Hat et qu'ils n'ont pas été modifiés pendant le transfert. Voir Section 8.5, « Configurer Yum et les référentiels Yum  » pour plus d'informations sur l'activation du contrôle de signature avec yum, ou Section A.3.2, « Vérification des signatures de paquets » pour plus d'informations sur la façon de travailler et vérifier des paquets GPG RPM signés GPG, en général.
Yum vous permet également d'installer aisément vos propres référentiels de paquets RPM pour pouvoir les télécharger et les installer sur d'autres machines. Quand c'est possible, yum utilise le téléchargement parallèle de plusieurs packages et métadonnées pour accélérer le téléchargement.
Apprendre comment yum opère est un investissement rentable car c'est souvent le moyen le plus rapide pour effectuer des tâches d'administration de système, et il fournit des fonctionnalités qui vont au-delà de celles fournies par les outils graphiques de gestion de paquets de PackageKit.

Note

Vous devez disposer des privilèges de superutilisateur pour utiliser yum afin d'installer, mettre à jour ou supprimer des paquets sur votre système. Tous les exemples de ce chapitre supposent que vous avez déjà obtenu des privilèges de superutilisateur en utilisant la commande su ou sudo.

8.1. Recherche et Mise à jour des paquets

Yum vous permet de vérifier si votre système possède des mises à jour en attente d'être appliquées. Vous pouvez lister les paquets qui ont besoin d'être mis à jour et les mettre à jour ensemble, ou bien, vous pouvez mettre à jour des packages idividuels.

8.1.1. Vérifier les mises à jour

Pour voir quels paquets installés sur votre système disposent de mises à jour disponibles, veuillez utiliser la commande suivante : 
yum check-update

Exemple 8.1. Exemple de sortie de la commande yum check-update :

La sortie de yum check-update peut être similaire à la suivante : 
~]# yum check-update
Loaded plugins: product-id, search-disabled-repos, subscription-manager
dracut.x86_64                         033-360.el7_2      rhel-7-server-rpms
dracut-config-rescue.x86_64           033-360.el7_2      rhel-7-server-rpms
kernel.x86_64                         3.10.0-327.el7     rhel-7-server-rpms
rpm.x86_64                            4.11.3-17.el7      rhel-7-server-rpms
rpm-libs.x86_64                       4.11.3-17.el7      rhel-7-server-rpms
rpm-python.x86_64                     4.11.3-17.el7      rhel-7-server-rpms
yum.noarch                            3.4.3-132.el7      rhel-7-server-rpms
Les paquets dans la sortie ci-dessus sont répertoriées comme ayant des mises à jour disponibles,. Le premier paquet de la liste est dracut. Chaque ligne dans l'exemple de sortie consiste en plusieurs lignes, dans le cas de dracut :
  • dracut — nom du paquet
  • x86_64 — architecture du CPU pour laquelle le paquet a été créé,
  • 0.5.8 — version du paquet mis à jour à installer,
  • 360.el7 — version du paquet mis à jour,
  • _2 — version ajoutée dans le cadre de la mise à jour z-stream,
  • rhel-7-server-rpms — référentiel dans lequel le paquet mis à jour se trouve.
La sortie montre également que l'on peut mettre à jour le noyau (le paquet kernel), yum et RPM (paquets yum et rpm), ainsi que leurs dépendances (tels que les paquets rpm-libs, et rpm-python), tout en utilisant la commande yum.

8.1.2. Mise à jour de paquets

Vous pouvez choisir de mettre à jour un paquet unique, de multiples paquets, ou tous les paquets à la fois. Si l'une des dépendances du ou des paquets que vous mettez à jour possède elle-même des mises à jour disponibles, alors elle sera également mise à jour.

Mise à jour d'un paquet unique

Pour mettre à jour un paquet unique, veuillez exécuter la commande suivante en tant qu'utilisateur root : 
yum update package_name

Exemple 8.2. Mise à jour du paquet rpm

Pour mettre à jour le paquet rpm, veuillez saisir : 
~]# yum update rpm
Loaded plugins: langpacks, product-id, subscription-manager
Updating Red Hat repositories.
INFO:rhsm-app.repolib:repos updated: 0
Setting up Update Process
Resolving Dependencies
--> Running transaction check
---> Package rpm.x86_64 0:4.11.1-3.el7 will be updated
--> Processing Dependency: rpm = 4.11.1-3.el7 for package: rpm-libs-4.11.1-3.el7.x86_64
--> Processing Dependency: rpm = 4.11.1-3.el7 for package: rpm-python-4.11.1-3.el7.x86_64
--> Processing Dependency: rpm = 4.11.1-3.el7 for package: rpm-build-4.11.1-3.el7.x86_64
---> Package rpm.x86_64 0:4.11.2-2.el7 will be an update
--> Running transaction check
...
--> Finished Dependency Resolution

Dependencies Resolved
=============================================================================
 Package                   Arch        Version         Repository       Size
=============================================================================
Updating:
 rpm                       x86_64      4.11.2-2.el7    rhel            1.1 M
Updating for dependencies:
 rpm-build                 x86_64      4.11.2-2.el7    rhel            139 k
 rpm-build-libs            x86_64      4.11.2-2.el7    rhel             98 k
 rpm-libs                  x86_64      4.11.2-2.el7    rhel            261 k
 rpm-python                x86_64      4.11.2-2.el7    rhel             74 k

Transaction Summary
=============================================================================
Upgrade  1 Package (+4 Dependent packages)

Total size: 1.7 M
Is this ok [y/d/N]:
Cette sortie contient plusieurs éléments présentant un interêt particulier :
  1. Loaded plugins: langpacks, product-id, subscription-manager — Yum vous informe toujours quels greffons yum sont installés et activés. Veuillez consulter la Section 8.6, « Greffons Yum » pour des informations générales sur les greffons yum, ou la Section 8.6.3, « Utiliser des greffons Yum » pour des descriptions de greffons particuliers.
  2. rpm.x86_64 — il est possible de télécharger et d'installer un nouveau paquet rpm ainsi que ses dépendances. Une vérification de transaction est effectuée pour chacun de ces paquets.
  3. Yum présente les informations de mise à jour et vous demande de confirmer la mise à jour ; yum est exécuté interactivement par défaut. Si vous savez déjà quelles transactions la commande yum planifie d'effectuer, vous pouvez utiliser l'option -y pour répondre automatiquement oui (« yes ») à toute question posée par yum (dans ce cas, l'exécution n'est pas interactive). Cependant, vous devriez toujours examiner les changements que yum planifie d'effectuer sur le système afin de pouvoir facilement résoudre tout problème qui se pose. Il est également possible de télécharger le paquet sans l'installer. Pour faire cela, veuillez sélectionner l'option d dans l'invite du téléchargement. Cela lance le téléchargement en arrière-plan du paquet sélectionné.
    Si une transaction échoue, vous pouvez afficher l'historique des transactions yum en utilisant la commande yum history comme décrit dans la Section 8.4, « Utiliser l'historique des transactions ».

Important

Yum installe toujours un nouveau noyau, que vous utilisez la commande yum update ou yum install.
D'autre part, lors de l'utilisation de RPM, il est important d'utiliser la commande rpm -i kernel qui installe un nouveau noyau, au lieu de rpm -u kernel qui remplace le noyau actuel. Veuillez consulter la Section A.2.1, « Installation et mise à niveau des paquets » pour obtenir davantage d'informations sur l'installation et la mise à niveau de noyaux avec RPM.
Similairement, il est possible de mettre à jour un groupe de paquets. Veuillez saisir en tant qu'utilisateur root : 
yum group update group_name
Remplacez ici group_name par le nom du groupe de paquets que vous souhaitez mettre à jour. Pour obtenir davantage d'informations sur les groupes de paquets, veuillez consulter la Section 8.3, « Utiliser des groupes de paquets ».
Yum offre également la commande upgrade qui est égale à update avec une option de configuration obsoletes (veuillez consulter la Section 8.5.1, « Définir les options [main] »). Par défaut, obsoletes est activé dans /etc/yum.conf, ce qui rend ces deux commandes équivalentes.

Mettre à jour tous les paquets et leurs dépendances

Pour mettre à jour tous les paquets et leurs dépendances, veuillez utiliser la commande yum update sans aucun argument : 
yum update
Si les paquets ont des mises à jour de sécurité, vous ne pourrez les mettre à jour qu'à leur dernière version. Veuillez saisir en tant qu'utilisateur root : 
yum update --security
Vous pouvez également mettre ces paquets à jour aux versions contenant les dernières mises à jour en matière de sécurité. Pour cela, veuillez saisir en tant qu'utilisateur root : 
yum update-minimal --security
Ainsi, dans la mesure où :
  • le paquet kernel-3.10.0-1 est installé sur votre système ;
  • le paquet kernel-3.10.0-2 est une mise à jour de sécurité ;
  • la paquet kernel-3.10.0-3 est une mise à jour de correctif,
Ensuite, yum update-minimal --security mettra à jour le paquet à kernel-3.10.0-2, et yum update --security mettra à jour le paquet à kernel-3.10.0-3.

8.1.3. Préserver les changements au fichier de configuration

Vous apporterez inévitablement des modifications aux fichiers de configuration installés par des paquets pendant l'utilisation de votre système Red Hat Enterprise Linux. RPM, que yum utilise pour apporter des modifications au système, fournit un mécanisme pour assurer leur intégrité. Veuillez consulter la Section A.2.1, « Installation et mise à niveau des paquets » pour obtenir des détails sur la manière de gérer les changements apportés aux fichiers de configuration pendant les mises à niveau de paquets.

8.1.4. Mise à jour du système hors ligne avec ISO et Yum

Pour les systèmes disconnectés de l'Internet ou de Red Hat Network, utiliser la commande yum update avec l'image ISO d'installation de Red Hat Enterprise Linux est un façon simple et rapide de mettre à niveau les systèmes à la dernière version mineure. Les étapes suivantes nous montrent le processus de mise à niveau :
  1. Créer un répertoire cible dans lequel monter votre image ISO. Le répertoire n'est pas créé automatiquement lors du montage, donc, il vous faudra le créer avant de procéder à l'étape suivante. En tant qu'utilisateur root, saisissez : 
    mkdir mount_dir
    Remplacer mount_dir par un chemin menant au répertoire de montage. Normalement, les utilisateurs le créent en tant que sous-répertoire du répertoire /media.
  2. Monter l'image ISO d'installation de Red Hat Enterprise Linux 7 dans le répertoire cible préalablement créé. En tant qu'utilisateur root, saisir : 
    mount -o loop iso_name mount_dir
    Remplacez iso_name par le nom du chemin de votre image ISO et mount_dir par le nom du chemin du répertoire cible. Là, l'option -o loop est exigée pour pouvoir monter le fichier en tant que périphérique bloc.
  3. Copier le fichier media.repo du répertoire de montage /etc/yum.repos.d/. Notez que les fichiers de configuration de ce répertoire doivent posséder l'extension .repo pour pouvoir fonctionner correctement. 
    cp mount_dir/media.repo /etc/yum.repos.d/new.repo
    Cela créera un fichier de configuration pour le référentiel yum. Remplacer new.repo par le nom du fichier, comme par exemple rhel7.repo.
  4. Modifiez le nouveau fichier de configuration de façon à ce qu'il puisse pointer vers l'ISO d'installation de Red Hat Enterprise Linux. Ajouter la ligne suivante au fichier /etc/yum.repos.d/new.repo : 
    baseurl=file:///mount_dir
    Remplacez mount_dir par un chemin qui mène au point de montage.
  5. Mettez à jour tous les référentiels yum, y compris /etc/yum.repos.d/new.repo créé dans les étapes précédentes. En tant qu'utilisateur root, saisissez : 
    yum update
    Cela mettra à jour votre système à la version fournie par l'image ISO montée.
  6. Après la mise à niveau, vous pourrez dé-monter l'image ISO. En tant qu'utilisateur root, saisissez : 
    umount mount_dir
    avec mount_dir comme chemin qui mène à votre répertoire de montage. Aussi, vous pourrez supprimer le répertoire de montage créé dans la première étape. En tant qu'utilisateur root, saisissez : 
    rmdir mount_dir
  7. Si vous ne souhaitez pas utiliser le fichier de configuration déjà créé pour une autre installation ou mise à jour, vous pouvez le supprimer. En tant qu'utilisateur root, saisissez : 
    rm /etc/yum.repos.d/new.repo

Exemple 8.3. Mise à niveau de Red Hat Enterprise Linux 7.0 à 7.1

Si vous devez mettre à niveau un système et que vous n'ayiez pas accès à l'internet, en utilisant une image ISO contenant la dernière version du système, appelée, par exemple rhel-server-7.1-x86_64-dvd.iso, créer un répertoire cible de montage, comme /media/rhel7/. En tant qu'utilisateur root, allez dans le répertoire avec votre image ISO et saisissez : 
~]# mount -o loop rhel-server-7.1-x86_64-dvd.iso /media/rhel7/
Puis, créez un référentiel yum pour votre image en copiant le fichier media.repo à partir du répertoire de montage : 
~]# cp /media/rhel7/media.repo /etc/yum.repos.d/rhel7.repo
Pour que yum reconnaisse le point de montage comme référentiel, ajouter la ligne suivante au fichier /etc/yum.repos.d/rhel7.repo copié dans l'étape précédente : 
baseurl=file:///media/rhel7/
Miantenant, en mettant à jour le référentiel yum, vous mettez ainsi votre système à jour à la version fournie par rhel-server-7.1-x86_64-dvd.iso. En tant qu'utilisateur root, exécutez : 
~]# yum update
Une fois que votre système sera mis à jour, vous pourrez dé-monter l'image, supprimer le répertoire cible et le fichier de configuration : 
~]# umount /media/rhel7/
~]# rmdir /media/rhel7/
~]# rm /etc/yum.repos.d/rhel7.repo

8.2. Utiliser des paquets

Yum vous permet d'effectuer un ensemble complet d'opérations avec des paquets logiciels, y compris rechercher des paquets, d'afficher leurs informations, des les installer et de les supprimer.

8.2.1. Rechercher des paquets

Vous pouvez rechercher tous les noms, descriptions et résumés des paquets RPM en utilisant la commande suivante : 
yum search term…
Remplacez term par le nom du paquet que vous souhaitez rechercher.

Exemple 8.4. Rechercher les paquets correspondants à une chaîne spécifique

Pour répertorier tous les paquets qui correspondent à « vim » ou « gvim », or « emacs », veuillez saisir : 
~]$ yum search vim gvim emacs
Loaded plugins: langpacks, product-id, search-disabled-repos, subscription-manager
============================= N/S matched: vim ==============================
vim-X11.x86_64 : The VIM version of the vi editor for the X Window System
vim-common.x86_64 : The common files needed by any version of the VIM editor[sortie tronquée]

============================ N/S matched: emacs =============================
emacs.x86_64 : GNU Emacs text editor
emacs-auctex.noarch : Enhanced TeX modes for Emacs[sortie tronquée]

  Name and summary matches mostly, use "search all" for everything.
Warning: No matches found for: gvim
La commande yum search est utile pour rechercher des paquets dont vous ne connaissez pas le nom, mais dont vous connaissez un terme connexe. Remarquez que par défaut, yum search retourne les correspondances par nom de paquet et résumé, ce qui rend les recherches plus rapides. Veuillez utiliser la commande yum search all pour effectuer une recherche plus exhaustive mais également plus lente.

Filtrer les résultats

Toutes les commandes de la liste de yum vous permettent de filtrer les résultats en ajoutant une ou plusieurs expressions glob comme arguments. Les expressions glob sont des chaînes de caractères normales qui contiennent un ou plusieurs caractères génériques * (qui s'étend pour correspondre à tout sous-ensemble de caractères) et ? (qui s'étend pour correspondre à tout caractère unique).
Prenez soin d'échapper les expressions glob lorsque vous les passez en tant qu'argument sur une commande yum, sinon le shell Bash les interprétera comme des expansions de nom de fichier, et pourrait potentiellement faire passer tous les fichiers du répertoire actuel correspondant aux expressions globales sur yum. Pour vous assurer que les expressions glob soient passées sur yum comme souhaité, veuillez utiliser l'une des méthodes suivantes :
  • échappez les caractères génériques en les faisant précéder du caractère de la barre oblique inversée
  • mettez l'expression glob entre guillemets simples ou entre guillemets doubles.
Les exemples dans la section suivante démontrent l'usage de ces deux méthodes.

8.2.2. Répertorier les paquets

Pour répertorier des informations sur tous les paquets installés et disponibles, veuillez saisir ce qui suit dans l'invite shell : 
yum list all
Pour répertorier les paquets installés et disponibles qui correspondent aux expressions glob insérées, veuillez utiliser la commande suivante : 
yum list glob_expression…

Exemple 8.5. Répertorier les paquets liés à ABRT

Les paquets avec divers modules complémentaires et greffons ABRT commencent par « abrt-addon- » ou par « abrt-plugin- ». Pour répertorier ces paquets, veuillez saisir la commande suivante à l'invite shell. Remarquez que les caractères génériques sont échappés avec le caractère de la barre oblique inversée : 
~]$ yum list abrt-addon\* abrt-plugin\*
Loaded plugins: langpacks, product-id, search-disabled-repos, subscription-manager
Installed Packages
abrt-addon-ccpp.x86_64                   2.1.11-35.el7             @rhel-7-server-rpms
abrt-addon-kerneloops.x86_64             2.1.11-35.el7             @rhel-7-server-rpms
abrt-addon-pstoreoops.x86_64             2.1.11-35.el7             @rhel-7-server-rpms
abrt-addon-python.x86_64                 2.1.11-35.el7             @rhel-7-server-rpms
abrt-addon-vmcore.x86_64                 2.1.11-35.el7             @rhel-7-server-rpms
abrt-addon-xorg.x86_64                   2.1.11-35.el7             @rhel-7-server-rpms
Pour répertorier tous les paquets installés sur votre système, veuillez utiliser le mot-clé installed. La colonne la plus à droite dans la sortie répertorie le référentiel à partir duquel le paquet a été récupéré. 
yum list installed glob_expression…

Exemple 8.6. Répertorier tous les versions installées du paquet krb

L'exemple suivant montre comment répertorier tous les paquets installés qui commencent par « krb » suivis d'exactement un caractère et d'un tiret. Ceci est utile lorsque vous souhaitez répertorier toutes les versions d'un certain composant, car ceux-ci se distinguent par leur numéro. L'expression glob toute entière est citée pour assurer que le traitement soit correct. 
~]$ yum list installed "krb?-*"
Loaded plugins: langpacks, product-id, search-disabled-repos, subscription-manager
Installed Packages
krb5-libs.x86_64                  1.13.2-10.el7                   @rhel-7-server-rpms
Pour répertorier tous les paquets dans des référentiels activés qui seraient disponibles à installer, veuillez utiliser la commande sous la forme suivante : 
yum list available glob_expression…

Exemple 8.7. Répertorier les greffons gstreamer disponibles

Par exemple, pour répertorier tous les paquets disponibless avec des noms qui contiennent « gstreamer » puis « plugin », veuillez exécuter la commande suivante : 
~]$ yum list available gstreamer\*plugin\*
Loaded plugins: langpacks, product-id, search-disabled-repos, subscription-manager
Available Packages
gstreamer-plugins-bad-free.i686             0.10.23-20.el7         rhel-7-server-rpms
gstreamer-plugins-base.i686                 0.10.36-10.el7         rhel-7-server-rpms
gstreamer-plugins-good.i686                 0.10.31-11.el7         rhel-7-server-rpms
gstreamer1-plugins-bad-free.i686            1.4.5-3.el7            rhel-7-server-rpms
gstreamer1-plugins-base.i686                1.4.5-2.el7            rhel-7-server-rpms
gstreamer1-plugins-base-devel.i686          1.4.5-2.el7            rhel-7-server-rpms
gstreamer1-plugins-base-devel.x86_64        1.4.5-2.el7            rhel-7-server-rpms
gstreamer1-plugins-good.i686                1.4.5-2.el7            rhel-7-server-rpms

Répertorier les référentiels

Pour répertorier l'ID du référentiel, le nom, et le numéro des paquets de chaque référentiel activé sur votre système, veuillez utiliser la commande suivante : 
yum repolist
Pour répertorier davantage d'informations sur ces référentiels, veuillez ajouter l'option -v. Avec cette option activée, les informations comprenant le nom du fichier, la taille générale, la date de la dernière mise à jour, et l'URL de base sont affichées pour chaque référentiel répertorié. Alternativement, vous pouvez utiliser la commande repoinfo qui produira la même sortie. 
yum repolist -v
yum repoinfo
Pour répertorier les référentiels activés et désactivés, veuillez utiliser la commande suivante. Une colonne de statut est ajoutée à la liste de sorties pour afficher quels sont les référentiels activés. 
yum repolist all
En passant disabled en tant que premier argument, vous pouvez limiter la sortie de la commande aux référentiels désactivés. Pour des spécifications plus précises, vous pouvez passer l'ID ou le nom des référentiels ou des glob_expressions comme arguments. Remarquez que s'il y a une correspondance exacte entre l'ID ou le nom du référentiel et l'argument inséré, ce référentiel est répertorié, même s'il ne passe pas le filtre enabled ou disabled.

8.2.3. Afficher des informations sur le paquet

Pour afficher des informations sur un ou plusieurs paquets, veuillez utiliser la commande suivante (ici, les expressions glob sont également valides) : 
yum info package_name…
Remplacez package_name par le nom du paquet.

Exemple 8.8. Afficher des informations sur le paquet abrt

Pour afficher des informations sur le paquet abrt, veuillez saisir : 
~]$ yum info abrt
Loaded plugins: langpacks, product-id, search-disabled-repos, subscription-manager
Installed Packages
Name        : abrt
Arch        : x86_64
Version     : 2.1.11
Release     : 35.el7
Size        : 2.3 M
Repo        : installed
From repo   : rhel-7-server-rpms
Summary     : Automatic bug detection and reporting tool
URL         : https://fedorahosted.org/abrt/
License     : GPLv2+
Description : abrt is a tool to help users to detect defects in applications and
            : to create a bug report with all information needed by maintainer to fix
            : it. It uses plugin system to extend its functionality.
La commande yum info package_name est similaire à la commande rpm -q --info package_name, mais elle fournit des informations supplémentaires, comme le nom du référentiel yum dans lequel le paquet RPM était installé (consultez la ligne From repo: dans la sortie).

Utiliser yumdb

Vous pouvez également effectuer des requêtes sur la base de données yum pour trouver d'autres informations utiles sur un paquet en utilisant la commande suivante : 
yumdb info package_name
Cette commande fournit des informations supplémentaires sur un paquet, y compris le checksum du paquet (et l'algorithme utilisé pour le produire, comme SHA-256), la commande donnée sur la ligne de commande qui a été invoquée pour installer le paquet (s'il y en a une), et la raison pour laquelle le paquet est installé sur le système (où user indique une installation par l'utilisateur, et dep indique une installation pour raison de dépendance).

Exemple 8.9. Exécuter une requête yumdb pour trouver des informations sur le paquet yum

Pour afficher des informations supplémentaires sur le paquet yum, veuillez saisir : 
~]$ yumdb info yum
Loaded plugins: langpacks, product-id
yum-3.4.3-132.el7.noarch
     changed_by = 1000
     checksum_data = a9d0510e2ff0d04d04476c693c0313a11379053928efd29561f9a837b3d9eb02
     checksum_type = sha256
     command_line = upgrade
     from_repo = rhel-7-server-rpms
     from_repo_revision = 1449144806
     from_repo_timestamp = 1449144805
     installed_by = 4294967295
     origin_url = https://cdn.redhat.com/content/dist/rhel/server/7/7Server/x86_64/os/Packages/yum-3.4.3-132.el7.noarch.rpm
     reason = user
     releasever = 7Server
     var_uuid = 147a7d49-b60a-429f-8d8f-3edb6ce6f4a1
Pour obtenir davantage d'informations sur la commande yumdb, veuillez consulter la page man de yumdb(8).

8.2.4. Installation de paquets

Pour installer un paquet unique et toutes ses dépendances non installées, veuillez saisir une commande sous la forme suivante en tant qu'utilisateur root : 
yum install package_name
Vous pouvez également installer de multiples paquets simultanément en ajoutant leurs noms en tant qu'arguments. Pour faire cela, veuillez saisir en tant qu'utilisateur root : 
yum install package_name package_name…
Si vous installez des paquets sur un système multilib, tel que sur un ordinateur AMD64 ou Intel64, vous pourrez spécifier l'architecture du paquet (tant qu'il est disponible dans un référérentiel activé) en ajoutant .arch au nom du paquet : 
yum install package_name.arch

Exemple 8.10. Installer des paquets sur un système multilib

Pour installer le paquet sqlite pour l'architecture i686, veuillez saisir : 
~]# yum install sqlite.i686
Vous pouvez utiliser des expressions glob pour installer rapidement de multiples paquets avec des noms similaires. En tant qu'utilisateur root, veuillez exécuter : 
yum install glob_expression…

Exemple 8.11. Installer tous les greffons audacieux

Les expressions globales sont utiles lorsque vous souhaitez installer plusieurs paquets avec des noms similaires. Pour installer tous les greffons audacieux, veuillez utiliser la commande sous la forme suivante : 
~]# yum install audacious-plugins-\*
En plus des noms de paquets et des expressions glob, vous pouvez également fournir des noms de fichier à yum install. Si vous connaissez le nom du binaire que vous souhaitez installer, mais pas son nom de paquet, vous pouvez donner le nom du chemin à yum install. En tant qu'utilisateur root, veuillez saisir : 
yum install /usr/sbin/named
Yum effectue la recherche dans ses listes de paquets, trouve le paquet qui fournit /usr/sbin/named, s'il existe, et vous demande si vous souhaitez l'installer.
Comme vous pouvez le voir dans les exemples ci-dessus, la commande yum install ne requiert pas d'arguments strictement définis. Il peut traiter divers formats de noms de paquets et d'expressions glob, ce qui rend l'installation plus facile pour les utilisateurs. D'autre part, yum peut prendre longtemps à analyser l'entrée correctement, particulièrement si vous spécifiez un grand nombre de paquets. Pour optimiser la recherche de paquets, vous pouvez utiliser les commandes suivantes pour définir de manière explicite comment analyser les arguments : 
yum install-n name
yum install-na name.architecture
yum install-nevra name-epoch:version-release.architecture
Avec install-n, yum interprète name comme étant le nom exact du paquet. La commande install-na indique à yum que l'argument suivant contient le nom du paquet et l'architecture divisés par le caractère « point ». Avec install-nevra, yum s'attendra à un argument sous la forme name-epoch:version-release.architecture. Similairement, vous pouvez utiliser yum remove-n, yum remove-na, et yum remove-nevra lorsque vous cherchez des paquets à supprimer.

Note

Si vous êtes sûr(e) de souhaiter installer le paquet contenant le binaire named, mais que vous ne savez pas dans quel répertoire bin/ ou sbin/ le fichier est installé, veuillez utiliser la commande yum provides avec une expression glob : 
~]# yum provides "*bin/named"
Loaded plugins: langpacks, product-id, search-disabled-repos, subscription-
              : manager
32:bind-9.9.4-14.el7.x86_64 : The Berkeley Internet Name Domain (BIND) DNS
                            : (Domain Name System) server
Repo        : rhel-7-server-rpms
Matched from:
Filename    : /usr/sbin/named
yum provides "*/file_name" est une astuce utile pour trouver le paquet ou les paquets qui contiennent le file_name.

Exemple 8.12. Processus d'installation

L'exemple suivant offre une vue d'ensemble d'une installation en utilisant yum. Pour télécharger et installer la dernière version du paquet httpd, veuillez exécuter en tant qu'utilisateur root : 
~]# yum install httpd
Loaded plugins: langpacks, product-id, subscription-manager
Resolving Dependencies
--> Running transaction check
---> Package httpd.x86_64 0:2.4.6-12.el7 will be updated
---> Package httpd.x86_64 0:2.4.6-13.el7 will be an update
--> Processing Dependency: 2.4.6-13.el7 for package: httpd-2.4.6-13.el7.x86_64
--> Running transaction check
---> Package httpd-tools.x86_64 0:2.4.6-12.el7 will be updated
---> Package httpd-tools.x86_64 0:2.4.6-13.el7 will be an update
--> Finished Dependency Resolution

Dependencies Resolved
Après avoir exécuté la commande ci-dessus, yum charge les greffons nécessaires et exécute la vérification de transaction. Dans ce cas, httpd est déjà installé. Comme le paquet installé est plus ancien que la version disponible la plus récente, il sera mis à jour. La même chose s'applique au paquet httpd-tools dont httpd dépend. Puis, un résumé de la transaction est affiché : 

================================================================================
 Package        Arch      Version                 Repository               Size
================================================================================
Updating:
 httpd          x86_64    2.4.6-13.el7            rhel-x86_64-server-7    1.2 M
Updating for dependencies:
 httpd-tools    x86_64    2.4.6-13.el7            rhel-x86_64-server-7     77 k

Transaction Summary
================================================================================
Upgrade  1 Package (+1 Dependent package)

Total size: 1.2 M
Is this ok [y/d/N]:
Dans cette étape, yum vous demande de confirmer l'installation. Hormis les options y (oui) et N (non), vous pouvez également choisir d (télécharger uniquement) pour télécharger les paquets sans les installer directement. Si vous choisissez y, l'installation continuera avec les messages suivants jusqu'à ce qu'elle se termine. 
Downloading packages:
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
  Updating   : httpd-tools-2.4.6-13.el7.x86_64                             1/4 
  Updating   : httpd-2.4.6-13.el7.x86_64                                   2/4 
  Cleanup    : httpd-2.4.6-12.el7.x86_64                                   3/4 
  Cleanup    : httpd-tools-2.4.6-12.el7.x86_64                             4/4 
  Verifying  : httpd-2.4.6-13.el7.x86_64                                   1/4 
  Verifying  : httpd-tools-2.4.6-13.el7.x86_64                             2/4 
  Verifying  : httpd-tools-2.4.6-12.el7.x86_64                             3/4 
  Verifying  : httpd-2.4.6-12.el7.x86_64                                   4/4 

Updated:
  httpd.x86_64 0:2.4.6-13.el7

Dependency Updated:
  httpd-tools.x86_64 0:2.4.6-13.el7

Complete!
Pour installer un paquet téléchargé au préalable se trouvant dans un répertoire local sur votre système, veuillez utiliser la commande suivante : 
yum localinstall path
Remplacez path par le chemin du paquet que vous souhaitez installer.

8.2.5. Télécharger des paquets

Comme indiqué dans l'Exemple 8.12, « Processus d'installation », à un certain moment pendant le processus d'installation, il vous sera demandé de confirmer l'installation avec le message suivant : 
...
Total size: 1.2 M
Is this ok [y/d/N]:    
...
With the d option, yum downloads the packages without installing them immediately. You can install these packages later offline with the yum localinstall command or you can share them with a different device. Downloaded packages are saved in one of the subdirectories of the cache directory, by default /var/cache/yum/$basearch/$releasever/packages/. The downloading proceeds in background mode so that you can use yum for other operations in parallel.

8.2.6. Supprimer des paquets

De même que pour l'installation de paquets, yum permet également de les désinstaller. Pour désinstaller un paquet particulier, ainsi que tout paquet en dépendant, veuillez exécuter la commande suivante en tant qu'utilisateur root : 
yum remove package_name…
Comme lors de l'installation de plusieurs paquets, il est possible d'en supprimer plusieurs à la fois en ajoutant des noms de paquets supplémentaires à la commande.

Exemple 8.13. Supprimer plusieurs paquets

Pour supprimer totem, veuillez saisir ce qui suit à l'invite shell : 
~]# yum remove totem
Similairememt à install, remove peut prendre ces arguments :
  • noms de paquet
  • expressions glob
  • listes de fichiers
  • ce que le paquet fournit

Avertissement

Yum n'est pas en mesure de supprimer un paquet sans également supprimer les paquets qui en dépendent. Ce type d'opération, qui peut uniquement être effectué par RPM, n'est pas publicisé et peut potentiellement laisser votre système dans un état ne fonctionnant pas, ou causer à des applications de ne pas fonctionner correctement ou de tomber en panne. Pour obtenir des informations supplémentaires, veuillez consulter la Section A.2.2, « Désinstaller les paquets » dans le chapitre RPM.

8.3. Utiliser des groupes de paquets

Un groupe de paquets est une collection de paquets qui servent un but commun, par exemple System Tools (Outils système) ou Sound and Video (Son et vidéo). Installer un groupe de paquets inclut également un ensemble de paquets dépendants, ce qui permet de faire des économies de temps considérables. La commande yum groups est une commande de haut niveau qui couvre toutes les opérations agissant sur les groupes de paquets dans yum.

8.3.1. Répertorier les groupes de paquets

L'option summary (résumé) est utilisée pour afficher le nombre de groupes installés, les groupes disponibles, les groupes d'environnement disponibles, ainsi que les deux groupes de langues disponibles et installés : 
yum groups summary

Exemple 8.14. Exemple de sortie de résumé des groupes yum

~]$ yum groups summary 
Loaded plugins: langpacks, product-id, subscription-manager
Available Environment Groups: 12
Installed Groups: 10
Available Groups: 12
Pour répertorier tous les groupes de paquets des référentiels yum, veuillez ajouter l'option list. Vous pouvez également filtrer la sortie de la commande par nom de groupe. 
yum group list glob_expression…
Plusieurs arguments optionnels peuvent être passés sur cette commande, y compris hidden pour répertorier les groupes qui ne sont pas marqués comme étant visibles par les utilisateurs, et ids pour répertorier les ID de groupe. Vous pouvez ajouter les options language, environment, installed, ou available pour réduire la sortie de la commande à un type de groupe spécifique.
Pour répertorier les paquets obligatoires et optionnels contenus dans un groupe particulier, veuillez utiliser la commande suivante : 
yum group info glob_expression…

Exemple 8.15. Afficher des informations sur le groupe de paquets LibreOffice

 ~]$ yum group info LibreOffice
Loaded plugins: langpacks, product-id, subscription-manager

Group: LibreOffice
 Group-Id: libreoffice
 Description: LibreOffice Productivity Suite
 Mandatory Packages:
  =libreoffice-calc
   libreoffice-draw
  -libreoffice-emailmerge
   libreoffice-graphicfilter
  =libreoffice-impress
  =libreoffice-math
  =libreoffice-writer
  +libreoffice-xsltfilter
 Optional Packages:
   libreoffice-base
   libreoffice-pyuno
Comme indiqué dans l'exemple ci-dessus, les paquets inclus dans le groupe de paquets peuvent avoir différents états marqués à l'aide des symboles suivants :
  • « - » — le paquet n'est pas installé et ne sera pas installé comme s'il faisait partie du groupe de paquets.
  • « + » — le paquet n'est pas installé mais sera installé lors de la prochaine mise à niveau yum upgrade ou yum group upgrade.
  • « = » — le paquet est installé et a été installé en faisant partie du groupe de paquets.
  • « no symbol » — le paquet est installé mais il a été installé hors du groupe de paquets. Cela signifie que yum group remove ne supprimera pas ce paquet.
Ces distinctions se produisent uniquement lorsque le paramètre de configuration group_command est défini sur objects, qui est le paramètre par défaut. Définissez ce paramètre sur une autre valeur si vous ne souhaitez pas que yum vérifie si un paquet a été installé en tant que faisant partie d'un groupe ou séparément, ce qui rendra les paquets « no symbol » équivalents aux paquets « = ».
Vous pouvez altérer les états des paquets ci-dessus en utilisant la commande yum group mark. Par exemple, yum group mark packages marque les paquets installés donnés en tant que membre d'un groupe spécifié. Pour éviter l'installation de nouveaux paquets sur une mise à jour de groupe, veuillez utiliser yum group mark blacklist. Consultez la page man de yum(8) pour obtenir davantage d'informations sur les capacités de yum group mark.

Note

Vous pouvez identifier un groupe environnemental en utilisant le préfixe @^ et un groupe de paquets peut être précédé de @. Lors de l'utilisation de yum group list, info, install, ou remove, veuillez inclure @group_name pour spécifier un groupe de paquets, @^group_name pour spécifier un groupe environnemental, ou group_name pour inclure les deux.

8.3.2. Installer un groupe de paquets

Chaque groupe de paquets possède un nom et un ID de groupe (groupid). Pour répertorier les noms de tous les groupes de paquets et leurs ID de groupe, qui sont affichés entre parenthèses, veuillez saisir : 
yum group list ids

Exemple 8.16. Trouver le nom et l'ID de groupe d'un groupe de paquets

Pour trouver le nom ou l'ID d'un groupe de paquets, par exemple un groupe lié à l'environnement du bureau KDE, veuillez saisir : 
~]$ yum group list ids kde\*
Available environment groups:
   KDE Plasma Workspaces (kde-desktop-environment)
Done
Certains groupes sont cachés par des paramètres dans les référentiels configurés. Par exemple, sur un serveur, vous pouvez utiliser l'option de commande hidden pour répertorier les groupes cachés également : 
~]$ yum group list hidden ids kde\*
Loaded plugins: product-id, subscription-manager
Available Groups:
   KDE (kde-desktop)
Done
Vous pouvez installer un groupe de paquets en passant son nom de groupe complet, sans la partie « groupid », à la commande group install. En tant qu'utilisateur root, veuillez saisir : 
yum group install "group name"
Vous pouvez également effectuer des installations par « groupid ». En tant qu'utilisateur root, veuillez exécuter la commande suivante : 
yum group install groupid
Vous pouvez inclure le « groupid » ou le nom de groupe entre guillemets dans la commande install si vous ajoutez également le symbole @ comme préfixe, ce qui indique à yum que vous souhaitez effectuer une installation de type group install. En tant qu'utilisateur root, veuillez saisir : 
yum install @group
Remplacez group par le « groupid » ou le nom de groupe entre guillements. La même logique s'applique aux groupes environnementaux : 
yum install @^group

Exemple 8.17. Quatre manières équivalentes d'installer le groupe KDE Desktop

Comme mentionné précédemment, il existe quatre alternatives équivalentes pour installer un groupe de paquets. Pour le groupe KDE Desktop, les commandes sont comme suit : 
~]# yum group install "KDE Desktop"
~]# yum group install kde-desktop
~]# yum install @"KDE Desktop"
~]# yum install @kde-desktop

8.3.3. Supprimer un groupe de paquets

Vous pouvez supprimer un groupe de paquets en utilisant une syntaxe similaire à la syntaxe install, en utilisant le nom du groupe de paquets ou son ID. En tant qu'utilisateur root, veuillez saisir : 
yum group remove group_name
yum group remove groupid
Vous pouvez également inclure le « groupid » ou le nom entre guillemets dans la commande remove si vous ajoutez également le symbole @ comme préfixe, ce qui indique à yum que vous souhaitez effectuer une suppression de type group remove. En tant qu'utilisateur root, veuillez saisir : 
yum remove @group
Remplacez group par le « groupid » ou le nom de groupe entre guillements. Vous pouvez remplacer un groupe environnement de manière similaire : 
yum remove @^group

Exemple 8.18. Quatre manières équivalentes de supprimer le groupe KDE Desktop.

De même que pour l'installation, il existe quatre alternatives équivalentes pour supprimer un groupe de paquets. Pour le groupe KDE Desktop, les commandes sont comme suit : 
~]# yum group remove "KDE Desktop"
~]# yum group remove kde-desktop
~]# yum remove @"KDE Desktop"
~]# yum remove @kde-desktop

8.4. Utiliser l'historique des transactions

La commande yum history permet aux utilisateurs d'examiner des informations sur la chronologie des transactions yum, les dates et heures auxquelles elles se sont produites, le nombre de paquets affectés, si ces transactions ont réussi ou échoué, et si la base de données RPM a été modifiées entre les transactions. En outre, cette commande peut être utilisée pour annuler ou refaire certaines transactions. Tout l'historique des données est stocké dans la base de données de l'historique (history DB) dans le répertoire /var/lib/yum/history/.

8.4.1. Répertorier les transactions

Pour afficher une liste des vingt transactions les plus récentes, en tant qu'utilisateur root, veuillez exécuter yum history sans argument supplémentaire, ou saisissez ce qui suit dans une invite shell : 
yum history list
Pour afficher toutes les transactions, veuillez ajouter le mot-clé all : 
yum history list all
Pour uniquement afficher des transactions pendant une période donnée, veuillez utiliser la commande sous le format suivant : 
yum history list start_id..end_id
Vous pouvez également répertorier les transactions qui concernent un ou plusieurs paquets particuliers. Pour faire cela, veuillez utiliser la commande avec un nom de paquet ou une expression glob : 
yum history list glob_expression…

Exemple 8.19. Répertorier les cinq transactions les plus anciennes

Dans la sortie de yum history list, la transaction la plus récente est affichée en haut de la liste. Pour afficher des informations sur les cinq plus anciennes transactions stockées dans la base de données de l'historique, veuillez saisir : 
~]# yum history list 1..5
Loaded plugins: langpacks, product-id, subscription-manager
ID     | Login user               | Date and time    | Action(s)      | Altered
-------------------------------------------------------------------------------
     5 | User <user>              | 2013-07-29 15:33 | Install        |    1
     4 | User <user>              | 2013-07-21 15:10 | Install        |    1
     3 | User <user>              | 2013-07-16 15:27 | I, U           |   73
     2 | System <unset>           | 2013-07-16 15:19 | Update         |    1
     1 | System <unset>           | 2013-07-16 14:38 | Install        | 1106
history list
Toutes les formes de la commande yum history list produisent une sortie tabulaire dont chaque ligne comporte les colonnes suivantes :
  • ID — valeur d'entier identifiant une transaction particulière.
  • Login user — nom de l'utilisateur dont la session de connexion a été utilisée pour initier une transaction. Cette information est typiquement présentée sous la forme Full Name <username>. Pour les transactions qui n'ont pas été effectuées par un utilisateur (comme les mises à jour automatiques du système), System <unset> est utilisé à la place.
  • Date and time — la date et l'heure à laquelle une transaction a été effectuée.
  • Action(s) — liste d'actions effectuées au cours d'une transaction, comme décrit dans Tableau 8.1, « Valeurs possibles du champ « Action(s) » ».
  • Altered — nombre de paquets qui ont été affectés par une transaction, probablement suivis d'informations supplémentaires comme décrit dans Tableau 8.2, « Les valeurs possibles du champ « Altered » ».

Tableau 8.1. Valeurs possibles du champ « Action(s) »

ActionAbbréviationDescription
DowngradeDUn paquet au moins a été mis à niveau à une version antérieure.
EraseEUn paquet au moins a été supprimé.
InstallIUn nouveau paquet au moins a été installé.
ObsoletingOUn paquet au mons a été marqué comme obsolète.
ReinstallRUn paquet au moins a été réinstallé.
UpdateUUn paquet au moins a été mis à jour à une version plus récente.

Tableau 8.2. Les valeurs possibles du champ « Altered »

SymboleDescription
<Avant que la transaction se termine, la base de données rpmdb a été modifiée hors de yum.
>Une fois la transaction terminée, la base de données rpmdb a été modifiée hors de yum.
*La transaction ne s'est pas terminée correctement.
#La transaction s'est terminée correctement, mais yum a retourné un code de sortie différent de zéro.
ELa transaction s'est terminée correctement, mais une erreur ou un avertissement s'est affiché.
PLa transaction s'est terminée correctement, mais des problèmes existaient déjà dans la base de données rpmdb.
sLa transaction s'est terminée correctement, mais l'option de ligne de commande --skip-broken a été utilisée et certains paquets ont été ignorés.
Pour synchroniser le contenu de la base de données rpmdb ou yumdb pour tout paquet installé avec la base de données rpmdb ou yumdb actuellement utilisée, veuillez saisir ce qui suit : 
yum history sync
Pour afficher certaines statistiques générales sur la base de données de l'historique actuellement utilisée, veuillez utiliser le format suivant : 
yum history stats

Exemple 8.20. Exemple de sortie de yum history stats

~]# yum history stats
Loaded plugins: langpacks, product-id, subscription-manager 
File        : //var/lib/yum/history/history-2012-08-15.sqlite
Size        : 2,766,848
Transactions: 41
Begin time  : Wed Aug 15 16:18:25 2012
End time    : Wed Feb 27 14:52:30 2013
Counts      :
  NEVRAC :  2,204
  NEVRA  :  2,204
  NA     :  1,759
  NEVR   :  2,204
  rpm DB :  2,204
  yum DB :  2,204
history stats
Yum permet également d'afficher un résumé de toutes les ancennes transactions. Pour cela, veuillez exécuter la commande sous la forme suivante en tant qu'utilisateur root : 
yum history summary
Pour afficher les transactions d'une période donnée uniquement, veuillez saisir : 
yum history summary start_id..end_id
De même qu'avec la commande yum history list, vous pouvez également afficher un résumé des transactions concernant un ou plusieurs paquets particuliers en fournissant un nom de paquet ou une expression glob : 
yum history summary glob_expression…

Exemple 8.21. Résumé des cinq transactions les plus récentes

~]# yum history summary 1..5
Loaded plugins: langpacks, product-id, subscription-manager
Login user                 | Time                | Action(s)        | Altered 
-------------------------------------------------------------------------------
Jaromir ... <jhradilek>    | Last day            | Install          |        1
Jaromir ... <jhradilek>    | Last week           | Install          |        1
Jaromir ... <jhradilek>    | Last 2 weeks        | I, U             |       73
System <unset>             | Last 2 weeks        | I, U             |     1107
history summary
Toutes les formes de la commande yum history summary produisent une sortie tabulaire simplifiée similaire à la sortie de yum history list.
Comme indiqué ci-dessus, les commandes yum history list et yum history summary sont orientées vers les transactions, et même si elles permettent d'uniquement afficher les transactions concernant un ou plusieurs paquets en particulier, des détails cruciaux seront manquants, comme la version des paquets. Pour répertorier les transactions depuis la perspective du paquet, veuillez exécuter la commande suivante en tant qu'utilisateur root : 
yum history package-list glob_expression…

Exemple 8.22. Traçage de l'historique d'un paquet

Par exemple, pour tracer l'historique de subscription-manager et de ses paquets connexes, veuillez saisir ce qui suit dans l'invite shell : 
~]# yum history package-list subscription-manager\*
Loaded plugins: langpacks, product-id, search-disabled-repos, subscription-manager
ID     | Action(s)      | Package
-------------------------------------------------------------------------------
     2 | Updated        | subscription-manager-1.13.22-1.el7.x86_64          EE
     2 | Update         |                      1.15.9-15.el7.x86_64          EE
     2 | Obsoleted      | subscription-manager-firstboot-1.13.22-1.el7.x86_64 EE
     2 | Updated        | subscription-manager-gui-1.13.22-1.el7.x86_64      EE
     2 | Update         |                          1.15.9-15.el7.x86_64      EE
     2 | Obsoleting     | subscription-manager-initial-setup-addon-1.15.9-15.el7.x86_64 EE
     1 | Install        | subscription-manager-1.13.22-1.el7.x86_64
     1 | Install        | subscription-manager-firstboot-1.13.22-1.el7.x86_64
     1 | Install        | subscription-manager-gui-1.13.22-1.el7.x86_64
history package-list
Dans cet exemple, trois paquets ont été installés pendant l'installation initiale du système : subscription-manager, subscription-manager-firstboot, et subscription-manager-gui. Dans la troisième transaction, tous les paquets ont été mis à jour de la version 1.10.11 à la version 1.10.17.

8.4.2. Examiner les transactions

Pour afficher le résumé d'une transaction unique, en tant qu'utilisateur root, utilisez la commande yum history summary sous la forme suivante : 
yum history summary id
Ici, id correspond à l'ID de la transaction.
Pour examiner une ou plusieurs transactions en particulier de manière plus détaillée, veuillez exécuter la commande suivante en tant qu'utilisateur root : 
yum history info id…
L'argument id est optionnel et yum utilise automatiquement la dernière transaction lorsque vous l'omettez. Remarquez que vous pouvez également utiliser une gamme de transaction lorsque vous souhaitez spécifiez plus d'une transaction : 
yum history info start_id..end_id

Exemple 8.23. Exemple de sortie de yum history info

Ci-dessous figure un exemple de sortie de deux transactions, installant chacune un nouveau paquet : 
~]# yum history info 4..5
Loaded plugins: langpacks, product-id, search-disabled-repos, subscription-manager
Transaction ID : 4..5
Begin time     : Mon Dec  7 16:51:07 2015
Begin rpmdb    : 1252:d2b62b7b5768e855723954852fd7e55f641fbad9
End time       :            17:18:49 2015 (27 minutes)
End rpmdb      : 1253:cf8449dc4c53fc0cbc0a4c48e496a6c50f3d43c5
User           : Maxim Svistunov <msvistun>
Return-Code    : Success
Command Line   : install tigervnc-server.x86_64
Command Line   : reinstall tigervnc-server
Transaction performed with:
    Installed     rpm-4.11.3-17.el7.x86_64                  @rhel-7-server-rpms
    Installed     subscription-manager-1.15.9-15.el7.x86_64 @rhel-7-server-rpms
    Installed     yum-3.4.3-132.el7.noarch                  @rhel-7-server-rpms
Packages Altered:
    Reinstall tigervnc-server-1.3.1-3.el7.x86_64 @rhel-7-server-rpms
history info
Vous pouvez également voir des informations supplémentaires, comme les options de configuration utilisées au moment de la transaction, ou à partir de quel référentiel et pour quelles raisons certains paquets ont été installés. Pour déterminer quelles sont les informations disponibles pour une transaction donnée, veuillez saisir ce qui suit à l'invite shell en tant qu'utilisateur root : 
yum history addon-info id
De même qu'avec yum history info, lorsqu'aucun id n'est fourni, yum utilise automatiquement la dernière transaction. Une autre manière de faire référence à la traduction la plus récente consiste à utiliser le mot-clé last : 
yum history addon-info last

Exemple 8.24. Exemple de sortie de yum history addon-info

Pour la quatrième transaction dans l'historique, la commande yum history addon-info fournit la sortie suivante : 
~]# yum history addon-info 4
Loaded plugins: langpacks, product-id, subscription-manager
Transaction ID: 4
Available additional history information:
  config-main
  config-repos
  saved_tx

history addon-info
Dans la sortie de la commande yum history addon-info, trois types d'informations sont disponibles :
  • config-main — options yum globales qui étaient utilisées pendant la transaction. Veuillez consulter la Section 8.5.1, « Définir les options [main] » pour obtenir des informations sur la manière de modifier les options globales.
  • config-repos — options des référentiels yum individuels. Veuillez consulter la Section 8.5.2, « Définir les options [repository] » pour obtenir des informations sur la manière de modifier les options de référentiels individuels.
  • saved_tx — les données pouvant être utilisées par la commande yum load-transaction afin de répéter la transaction sur une autre machine (voir ci-dessous).
Pour affciher un type sélectionné d'informations supplémentaires, veuillez exécuter la commande suivante en tant qu'utilisateur root : 
yum history addon-info id information

8.4.3. Restaurer et répéter des transactions

Hormis le fait de permettre d'examiner l'historique des transactions, la commande yum history fournit un moyen de restaurer ou de répéter une transaction sélectionnée. Pour restaurer une transaction, veuillez saisir ce qui suit dans l'invite shell en tant qu'utilisateur root : 
yum history undo id
Pour répéter une transaction en particulier, veuillez exécuter la commande suivante en tant qu'utilisateur root : 
yum history redo id
Les deux commandes acceptent également le mot-clé last pour annuler ou répéter la dernière transaction.
Remarquez que les commandes yum history undo et yum history redo restaurent ou répètent uniquement les étapes qui ont été effectuées pendant une transaction. Si la transaction a installé un nouveau paquet, la commande yum history undo le désinstallera, et si la transaction a désinstallé un paquet, la commande l'installera à nouveau. Cette commande tente également de faire une mise à niveau inférieur de tous les paquets mis à jour vers leur version précédente si ces paquets plus anciens sont toujours disponibles.
Lors de la gestion de plusieurs systèmes identiques, yum vous permet également d'effectuer une transaction sur l'un d'entre eux, de stocker les détails de celle-ci dans un fichier, et après une période de tests, de répéter la même transaction sur les systèmes restants. Pour stocker les détails de la transaction dans une fichier, veuillez saisir ce qui suit dans l'invite shell en tant qu'utilisateur root : 
yum -q history addon-info id saved_tx > file_name
Une fois ce fichier copié sur le système cible, vous pouvez répéter la transaction en utilisant la commande suivante en tant qu'utilisateur root : 
yum load-transaction file_name
Vous pouvez configurer load-transaction de manière à ignorer les paquets manquants ou la version rpmdb. Pour obtenir davantage d'informations sur ces options de configuration, veuillez consulter la page man yum.conf(5).

8.4.4. Lancer un nouvel historique des transactions

Yum stocke l'historique des transactions dans un fichier de base de données SQLite unique. Pour lancer un nouvel historique des transactions, veuillez exécuter la commande suivante en tant qu'utilisateur root : 
yum history new
Cela créera un nouveau fichier de base de données vide dans le répertoire /var/lib/yum/history/. L'ancien historique des transactions sera conservé, mais il ne sera pas accessible tant qu'un fichier de base de données plus récent sera présent dans le répertoire.

8.5. Configurer Yum et les référentiels Yum

Note

En vue d'élargir vos connaissances, vous serez sans doute interessés par les formations suivantes Red Hat System Administration III (RH254) et RHCSA Rapid Track (RH199).
Les informations de configuration de yum et de ses utilitaires connexes sont situées dans le fichier /etc/yum.conf. Ce fichier contient une section [main] obligatoire, qui vous permet de définir les options yum qui ont un effet global, et peut également contenir une ou plusieurs section(s) [repository], ce qui vous permet de définir des options spécifiques au référentiel. Cependant, il est recommandé de définir des référentiels individuels dans les fichiers .repo existants ou nouveaux, qui se trouvent dans le répertoire /etc/yum.repos.d/. Les valeurs que vous définissez dans les sections [repository] du fichier /etc/yum.conf remplacent les valeurs définies dans la section [main].
Cette section indique comment :
  • définir des options yum globales en modifiant la section [main] du fichier de configuration /etc/yum.conf ;
  • définir des options de référentiels individuels en modifiant les sections [repository] des fichiers /etc/yum.conf et .repo dans le répertoire /etc/yum.repos.d/ ;
  • utiliser des variables yum dans /etc/yum.conf et des fichiers dans le répertoire /etc/yum.repos.d/ afin que la version dynamique et les valeurs de l'architecture soient gérées correctement ;
  • ajouter, activer, et désactiver des référentiels yum sur la ligne de commande ;
  • définir votre propre référentiel yum personnalisé.

8.5.1. Définir les options [main]

Le fichier de configuration /etc/yum.conf contient une seule section [main] précisément, et même si certaines des paires clés-valeurs dans cette section affectent la manière dont yum opère, d'autres affectent la manière dont yum traite les référentiels. Vous pouvez ajouter de nombreuses options sous l'en-tête de la section [main] dans /etc/yum.conf.
Un exemple du fichier de configuration /etc/yum.conf ressemble à ceci : 
[main]
cachedir=/var/cache/yum/$basearch/$releasever
keepcache=0
debuglevel=2
logfile=/var/log/yum.log
exactarch=1
obsoletes=1
gpgcheck=1
plugins=1
installonly_limit=3
[commentaires abrégés]

# PUT YOUR REPOS HERE OR IN separate files named file.repo
# in /etc/yum.repos.d
Ci-dessous figurent les options de la section [main] les plus couramment utilisées :
assumeyes=value
L'option assumeyes permet de déterminer si yum demande de confirmer les actions critiques ou non. Remplacez value par l'une des valeurs suivantes :
0 (par défaut) — yum demande de confirmer les actions critiques effectuées.
1 — ne demande pas de confirmer les actions critiques de yum. Si assumeyes=1 est défini, yum se comportera de la même manière qu'avec les options de ligne de commande -y et --assumeyes.
cachedir=directory
Veuillez utiliser cette option pour définir le répertoire dans lequel yum stockera son cache et ses fichiers de base de données. Remplacez directory par un chemin complet vers le répertoire. Par défaut, le répertoire du cache de yum est le suivant : /var/cache/yum/$basearch/$releasever/.
Veuillez consulter la Section 8.5.3, « Utiliser des variables Yum » pour les descriptions des variables yum $basearch et $releasever.
debuglevel=value
Cette option indique le niveau de détails de la sortie de débogage produite par yum. Ici, value est un entier entre 1 et 10. Définir une valeur debuglevel plus élevée amènera yum à afficher une sortie de débogage plus détaillée. debuglevel=2 est la valeur par défaut, tandis que debuglevel=0 désactive la sortie de débogage.
exactarch=value
Avec cette option, vous pouvez définir yum pour que l'architecture exacte soit prise en considération lors de la mise à jour de paquets installés au préalable. Veuillez remplacer value par :
0 — ne pas prendre en compte l'architecture exacte pendant la mise à jour des paquets.
1 (par défaut) — prendre en considération l'architecture exacte pendant la mise à jour des paquets. Avec ce paramètre, yum n'installera pas de paquets pour une architecture 32 bits pour mettre à jour un paquet déjà installé sur un système avec une architecture 64 bits.
exclude=package_name [more_package_names]
L'option exclude vous permet d'exclure des paquets par mot-clé pendant une installation ou une mise à jour du système. Il est possible de sélectionner plusieurs paquets les exclure en indiquant une liste de paquets délimités par des espaces. Les expression glob du shell utilisant des caractères génériques (par exemple, * et ?) sont autorisées.
gpgcheck=value
Veuillez utiliser l'option gpgcheck pour spécifier si yum doit effectuer une vérification des signatures GPG sur les paquets. Remplacez value par :
0 — désactive la vérification des signatures GPG sur les paquets de tous les référentiels, y compris l'installation de paquets locaux.
1 (par défaut) — active la vérification de signatures GPG sur tous les paquets dans tous les référentiels, y compris l'installation de paquets locaux. Lorsque gpgcheck est activé, les signatures de tous les paquets sont vérifiées.
Si cette option est définie dans la section [main] du fichier /etc/yum.conf, elle définit une règle de vérification GPG pour tous les référentiels. Cependant, vous pouvez également définir gpgcheck=value pour les référentiels individuels à la place ; c'est-à-dire que vous pouvez activer la vérification GPG sur un référentiel tout en le désactivant sur un autre. Définir gpgcheck=value pour un référentiel individuel dans son fichier .repo correspondant remplace la valeur par défaut si elle est présente dans /etc/yum.conf.
Pour obtenir davantage d'informations sur la vérification de signatures GPG, veuillez consulter la Section A.3.2, « Vérification des signatures de paquets ».
group_command=value
Utilisez l'option group_command pour spécifier de quelle manière les commandes yum group install, yum group upgrade, et yum group remove gèrent un groupe de paquets. Remplacez value par l'une des valeurs suivantes :
simple — installe tous les membres d'un groupe de paquets. Met à niveau les paquets installés antérieurement uniquement, mais n'installe pas de paquets qui ont été ajoutés au groupe entretemps.
compat — est similaire à simple mais yum upgrade installe également des paquets qui ont été ajoutés au groupe depuis la mise à niveau précédente.
objects — (par défaut.) Avec cette option, yum garde sous surveillance les groupes installés antérieurement et fait une distinction entre les paquets installés faisant partie du groupe et les paquets installés séparément. Veuillez consulter l'Exemple 8.15, « Afficher des informations sur le groupe de paquets LibreOffice »
group_package_types=package_type [more_package_types]
Vous pouvez spécifier ici quel type de paquet (optionnel, par défaut ou obligatoire) est installé lorsque la commande yum group install est appelé. Les types de paquets par défaut et obligatoire sont choisis par défaut.
history_record=value
Avec cette option, vous pouvez définir yum pour enregistrer l'historique des transactions. Remplacez value par l'une des valeurs suivantes :
0 — yum ne doit pas enregistrer d'entrées de l'historique pour les transactions.
1 (par défaut) — yum devrait enregistrer les entrées de l'historique des transactions. Cette opération prend une certaine quantité d'espace disque et un certain temps supplémentaire avec les transactions, mais elle fournit également de nombreuses informations concernant les anciennes opérations, qui peuvent être affichées par la commande yum history. history_record=1 est la valeur par défaut.
Pour obtenir davantage d'informations sur la commande yum history, veuillez consulter la Section 8.4, « Utiliser l'historique des transactions ».

Note

Yum utilise des enregistrements de l'historique pour détecter les modifications apportées à la base de données rpmdb qui ont été effectuées hors de yum. Dans de tels cas, yum affiche un avertissement et recherche automatiquement les problèmes possibles causés par l'altération de rpmdb. Lorsque history_record est éteint, yum n'est pas en mesure de détecter ces changements et aucune vérifications automatique n'est effectuée.
installonlypkgs=space separated list of packages
Ici vous pouvez fournir une liste de paquets séparés par des virgules que yum peut installer, mais ne mettra jamais à jour. Veuillez consulter la page man yum.conf(5) pour obtenir la liste des paquets qui sont par défaut « install-only » (uniquement pour installation).
Si vous ajoutez la directive installonlypkgs à /etc/yum.conf, vous devriez vous assurer de répertorier tous les paquets install-only, y compris ceux répertoriés sous la section installonlypkgs de yum.conf(5). Particulièrement, les paquets du noyau doivent toujours être répertoriés dans installonlypkgs (comme ils le sont par défaut), et installonly_limit devrait toujours être défini sur une valeur supérieure à 2 afin qu'un noyau de secours soit toujours disponible en cas d'échec du démarrage du noyau par défaut.
installonly_limit=value
Cette option définit combien de paquets répertoriés dans la directive installonlypkgs peuvent être installés au même moment. Remplacez value par un entier représentant le nombre maximal de versions pouvant être installées simultanément pour tout paquet unique répertorié dans installonlypkgs.
Les valeurs par défaut de la directive installonlypkgs incluent plusieurs paquets de noyaux différents. Ainsi, veuillez ne pas oublier que modifier la valeur de installonly_limit affecte également le nombre maximal de versions installées pour un paquet de noyau unique. La valeur par défaut répertoriée dans /etc/yum.conf est installonly_limit=3, et il n'est pas recommandé de réduire cette valeur, et plus particulièrement à une valeur inférieure à 2.
keepcache=value
L'option keepcache détermine si yum garde le cache des en-têtes et des paquets après une installation réussie. Ici, value correspond à l'une des valeurs suivantes :
0 (par défaut) — ne pas retenir le cache des en-têtes et des paquets après une installation réussie.
1 — retenir le cache après une installation réussie.
logfile=file_name
Pour spécifier l'emplacement de journalisation de la sortie, veuillez remplacer file_name par un chemin complet vers le fichier dans lequel yum écrira la sortie journalisée. Par défaut, yum enregistre les journaux dans /var/log/yum.log.
max_connenctions=number
value correspond au nombre maximal de connexions simultanées, la valeur par défaut est 5.
multilib_policy=value
L'option multilib_policy définit le comportement de l'installation si plusieurs versions de l'architecture sont disponibles pour une installation de paquet. Ici, value correspond à :
best — installe le meilleur choix d'architecture pour ce système. Par exemple, paramétrer multilib_policy=best sur un système AMD64 amène yum à installer les versions 64 bits de tous les paquets.
all — installe à chaque fois toutes les architectures possibles pour chaque paquet. Par exemple, avec multilib_policy défini sur all sur un système AMD64, yum installerait les versions i686 et AMD64 d'un paquet, si ces deux versions étaient disponibles.
obsoletes=valeur
L'option obsoletes active la logique de traitement obsolète pendant les mises à jour. Lorsqu'un paquet déclare dans son fichier de spécifications qu'il rend un autre paquet obsolète, ce dernier est remplacé par l'ancien paquet lorsque le premier est installé. Les fichiers obsolètes sont déclarés, par exemple, lorsqu'un paquet est renommé. Remplacez valeur par soit :
0 — désactive la logique de traitement obsolète de yum lorsque des mises à jour sont effectuées.
1 (par défaut) — active la logique de traitement obsolète de yum lorsque des mises à jour sont effectuées.
plugins=value
Interrupteur global pour activer ou désactiver les greffons yum, value est l'une des valeurs suivantes :
0 — désactive tous les greffons yum globalement.

Important

La désactivation de tous les greffons n'est pas recommandée car certains greffons fournissent des services yum importants. En particulier, les greffons product-id et subscription-manager fournissent la prise en charge du Content Delivery Network (CDN) basé certificats. La désactivation globale des greffons est offerte en tant qu'option pratique, et n'est généralement recommandée que lors du diagnostique d'un problème potentiel avec yum.
1 (par défaut) — active tous les greffons yum globalement. Avec plugins=1, vous pouvez toujours désactiver un greffon yum spécifique en paramétrant enabled=0 dans le fichier de configuration de ce greffon.
Pour obtenir davantage d'informations sur les divers greffons yum, veuillez consulter la Section 8.6, « Greffons Yum ». Pour obtenir des informations supplémentaires sur le contrôle des greffons, veuillez consulter la Section 8.6.1, « Activer, configurer, et désactiver des greffons Yum ».
reposdir=directory
Ici, directory est un chemin complet vers le répertoire où se trouvent les fichiers .repo. Tous les fichiers .repo contiennent des informations de référentiel (similairement aux sections [référentiel] de /etc/yum.conf). Yum collecte toutes les informations des référentiels des fichiers .repo et la section [référentiel] du fichier /etc/yum.conf pour créer une liste maître des référentiels à utiliser pour des transactions. Si reposdir n'est pas défini, yum utilisera le répertoire par défaut /etc/yum.repos.d/.
retries=valeur
Cette option définit le nombre de fois que yum doit tenter de récupérer un fichier avant de retourner une erreur. value est un entier 0 ou supérieur. Définir la valeur sur 0 fait que yum effectuera des tentatives indéfiniement. La valeur par défaut est 10.
Pour obtenir la liste complète des options [main] disponibles, veuillez consulter la section [main] OPTIONS de la page man de yum.conf(5).

8.5.2. Définir les options [repository]

Les sections [repository], où repository est un ID de référentiel unique, tel que my_personal_repo (les espaces ne sont pas autorisés), vous permet de définir des référentiels yum individuels. Afin d'éviter tout conflit, les référentiels personnalisés ne doivent pas utiliser des noms utilisés dans les référentiels Red Hat.
Ci-dessous figure un exemple du strict minimum de la forme prise par la section [repository] : 
[repository]
name=repository_name
baseurl=repository_url
Chaque section [référentiel] doit contenir les directives suivantes :
name=nom référentiel
Ici, nom référentiel est une chaîne lisible par l'utilitsateur décrivant le référentiel.
baseurl=url référentiel
Remplacez url référentiel par un URL vers le répertoire où se trouve le référentiel repodata d'un référentiel :
  • Si le référentiel est disponible sur HTTP, veuillez utiliser : http://path/to/repo
  • Si le référentiel est disponible sur FTP, veuillez utiliser : ftp://path/to/repo
  • Si le référentiel est local à la machine, veuillez utiliser : file:///path/to/local/repo
  • Si un référentiel en ligne spécifique requiert une authentification HTTP de base, vous pouvez spécifier votre nom d'utilisateur et mot de passe en les ajoutant au début de l'URL comme ceci : nom d'utilisateur:mot de âsse@lien. Par exemple, si un référentiel sur http://www.example.com/repo/ requiert un nom d'utilisateur « user » et un mot de passe « password », alors le lien baseurl link pourra être spécifié comme suit : http://user:password@www.example.com/repo/.
Habituellement, cet URL est un lien HTTP, tel que : 
baseurl=http://path/to/repo/releases/$releasever/server/$basearch/os/
Remarquez que yum étend toujours les variables $releasever, $arch, et $basearch dans les URL. Pour obtenir davantage d'informations sur les variables yum, veuillez consulter la Section 8.5.3, « Utiliser des variables Yum ».
D'autres directives de [référentiel] utiles incluent :
enabled=valeur
Ceci est une manière simple de dire à yum d'utiliser ou d'ignorer un référentiel en particulier, la value correspond à l'une des valeurs suivantes :
0 — ne pas inclure ce référentiel en tant que source de paquet lorsque vous effectuez des mises à jour et des installations. Ceci est une manière simple d'activer et de désactiver des référentiels, ce qui est utile lorsque vous souhaitez un certain paquet d'un référentiel que vous ne souhaitez pas activer pour les mises à jour ou les installations.
1 — inclure ce référentiel en tant que source de paquets.
Activer et désactiver des référentiels peut également être effectué en passant l'option --enablerepo=repo_name ou --disablerepo=repo_name sur yum, ou par la fenêtre Ajouter/Supprimer un logiciel de l'utilitaire PackageKit.
async=valeur
Contrôle le téléchargement parallèle de paquets de référentiels. La valeur correspond à :
auto (par défaut) — un téléchargement parallèle est utilisé si possible, ce qui signifie que yum le désactive automatiquement pour les référentiels créés par les greffons afin d'éviter des échecs.
on — téléchargement parallèle activé pour le référentiel.
off — téléchargement parallèle désactivé pour le référentiel.
De nombreuses autres options [référentiel] existent. Quelques-unes d'entre elles ont la même forme et fonction que certaines options [main]. Pour une liste complète, veuillez consulter la section [repository] OPTIONS de la page man deyum.conf(5).

Exemple 8.25. Exemple de fichier /etc/yum.repos.d/redhat.repo

Ci-dessous figure un exemple du fichier /etc/yum.repos.d/redhat.repo : 
#
# Red Hat Repositories
# Managed by (rhsm) subscription-manager
#

[red-hat-enterprise-linux-scalable-file-system-for-rhel-6-entitlement-rpms]
name = Red Hat Enterprise Linux Scalable File System (for RHEL 6 Entitlement) (RPMs)
baseurl = https://cdn.redhat.com/content/dist/rhel/entitlement-6/releases/$releasever/$basearch/scalablefilesystem/os
enabled = 1
gpgcheck = 1
gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release
sslverify = 1
sslcacert = /etc/rhsm/ca/redhat-uep.pem
sslclientkey = /etc/pki/entitlement/key.pem
sslclientcert = /etc/pki/entitlement/11300387955690106.pem

[red-hat-enterprise-linux-scalable-file-system-for-rhel-6-entitlement-source-rpms]
name = Red Hat Enterprise Linux Scalable File System (for RHEL 6 Entitlement) (Source RPMs)
baseurl = https://cdn.redhat.com/content/dist/rhel/entitlement-6/releases/$releasever/$basearch/scalablefilesystem/source/SRPMS
enabled = 0
gpgcheck = 1
gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release
sslverify = 1
sslcacert = /etc/rhsm/ca/redhat-uep.pem
sslclientkey = /etc/pki/entitlement/key.pem
sslclientcert = /etc/pki/entitlement/11300387955690106.pem

[red-hat-enterprise-linux-scalable-file-system-for-rhel-6-entitlement-debug-rpms]
name = Red Hat Enterprise Linux Scalable File System (for RHEL 6 Entitlement) (Debug RPMs)
baseurl = https://cdn.redhat.com/content/dist/rhel/entitlement-6/releases/$releasever/$basearch/scalablefilesystem/debug
enabled = 0
gpgcheck = 1
gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release
sslverify = 1
sslcacert = /etc/rhsm/ca/redhat-uep.pem
sslclientkey = /etc/pki/entitlement/key.pem
sslclientcert = /etc/pki/entitlement/11300387955690106.pem

8.5.3. Utiliser des variables Yum

Vous pouvez utiliser et faire référence aux variables intégrées suivantes présentes dans les commandes yum et dans tous les fichiers de configuration yum (c'est-à-dire /etc/yum.conf et tous les fichiers .repo dans le répertoire /etc/yum.repos.d/) :
$releasever
Vous pouvez utiliser cette variable pour faire référence à la version Red Hat Enterprise Linux. Yum obtient la valeur de $releasever à partir de la ligne distroverpkg=value dans le fichier de configuration /etc/yum.conf. Si cette ligne n'existe pas dans /etc/yum.conf, alors yum déduira la valeur correcte en dérivant la numéro de version à partir du paquet redhat-releaseproduit qui fournit le fichier redhat-release .
$arch
Vous pouvez utiliser cette variable pour faire référence à l'architecture du CPU du système comme retourné lors d'un appel à la fonction os.uname() de Python. Les valeurs valides de $arch incluent : i586, i686 et x86_64.
$basearch
Vous pouvez utiliser $basearch pour faire référence à l'architecture de base du système. Par exemple, les machines i686 et i586 ont toutes deux une architecture de base i386, et les machines AMD64 et Intel64 ont une architecture de base x86_64.
$YUM0-9
Ces dix variables sont chacunes remplacées par la valeur d'une variable d'environnement shell du même nom. Si l'une de ces variables est référencée (par exemple dans /etc/yum.conf) et qu'une variable d'environnement shell du même nom n'existe pas, alors la variable du fichier de configuration ne sera pas remplacée.
Pour définir une variable personnalisée ou pour remplacer la valeur d'une variable existante, créez un fichier du même nom que la variable (sans le caractère « $ ») dans le répertoire /etc/yum/vars/, et ajoutez la valeur souhaitée sur la première ligne.
Par exemple, les descriptions de référentiels incluent souvent le nom du système d'exploitation. Pour définir une nouvelle variable nommée $osname, créez un nouveau fichier avec « Red Hat Enterprise Linux » sur la première ligne et enregistrez-le sous /etc/yum/vars/osname : 
~]# echo "Red Hat Enterprise Linux 7" > /etc/yum/vars/osname
Au lieu de « Red Hat Enterprise Linux 7 », vous pouvez désormais utiliser ce qui suit dans les fichiers .repo : 
name=$osname $releasever

8.5.4. Afficher la configuration actuelle

Pour afficher les valeurs actuelles des options yum globales (c'est-à-dire les options spécifiées dans la section [main] du fichier /etc/yum.conf), veuillez exécuter la commande yum-config-manager sans aucune option de ligne de commande : 
yum-config-manager
Pour répertorier le contenu d'une ou plusieurs sections de configuration différentes, veuillez utiliser la commande sous la forme suivante : 
yum-config-manager section…
Vous pouvez également utiliser une expression glob pour afficher la configuration de toutes les sections correspondantes : 
yum-config-manager glob_expression…

Exemple 8.26. Afficher la configuration de la section principale

Pour répertorier toutes les options de configuration de la section principale ainsi que leurs valeurs correspondantes, veuillez saisir ce qui suit dans l'invite shell : 
~]$ yum-config-manager main \*
Loaded plugins: langpacks, product-id, subscription-manager
================================== main ===================================
[main]
alwaysprompt = True
assumeyes = False
bandwith = 0
bugtracker_url = https://bugzilla.redhat.com/enter_bug.cgi?product=Red%20Hat%20Enterprise%20Linux%206&component=yum
cache = 0[sortie tronquée]

8.5.5. Ajouter, activer, et désactiver un référentielr Yum

Note

Afin de gagner en expertise, vous serez sans doute intéressé par le cours de formation Red Hat System Administration II (RH254).
La Section 8.5.2, « Définir les options [repository] » décrit les diverses options que vous pouvez utiliser pour définir un référentiel yum. Cette section explique comment ajouter, activer, et désactiver un référentiel en utilisant la commande yum-config-manager.

Important

Lorsque le système est enregistré dans Red Hat Subscription Management sur le Content Delivery Network (CDN) basé sur certificats, les outils Red Hat Subscription Manager sont utilisés pour gérer des référentiels dans le fichier /etc/yum.repos.d/redhat.repo.

Ajouter un référentiel Yum

Pour définir un nouveau référentiel, vous pouvez ajouter une section [référentiel] dans le fichier /etc/yum.conf, ou au fichier .repo du répertoire /etc/yum.repos.d/. Tous les fichiers avec l'extension de fichier .repo présents dans ce répertoire sont lus par yum, et il est recommandé de définir vos référentiels ici plutôt que dans /etc/yum.conf.

Avertissement

Obtenir et installer des paquets logiciels de sources logicielles non vérifiées ou qui ne sont pas de confiance et proviennent de sources autres que le Content Delivery Network (CDN) basé sur certificats de Red Hat constitue un risque de sécurité potentiel, et pourrait provoquer des problèmes de sécurité, de stabilité, de compatibilité, et de maintenance.
Les référentiels Yum fournissent normalement leur propre fichier .repo. Pour ajouter un tel référentiel à votre système et pour l'activer, veuillez exécuter la commande suivante en tant qu'utilisateur root : 
yum-config-manager --add-repo repository_url
…où repository_url est un lien vers le fichier .repo.

Exemple 8.27. Ajouter example.repo

Pour ajouter un référentiel situé sur http://www.example.com/example.repo, veuillez saisir ce qui suit dans l'invite shell : 
~]# yum-config-manager --add-repo http://www.example.com/example.repo
Loaded plugins: langpacks, product-id, subscription-manager
adding repo from: http://www.example.com/example.repo
grabbing file http://www.example.com/example.repo to /etc/yum.repos.d/example.repo
example.repo                                             |  413 B     00:00
repo saved to /etc/yum.repos.d/example.repo

Activer un référentiel Yum

Pour activer un ou plusieurs référentiels en particulier, veuillez saisir ce qui suit dans une invite shell en tant qu'utilisateur root : 
yum-config-manager --enable repository…
…où référentiel est l'ID unique du référentiel (utilisez yum repolist all pour répertorier les ID des référentiels disponibles). Alternativement, vous pouvez utiliser une expression glob pour activer tous les référentiels correspondants : 
yum-config-manager --enable glob_expression…

Exemple 8.28. Activer les référentiels définis dans des sections personnalisées de /etc/yum.conf.

Pour activer les référentiels définis dans les sections [example], [example-debuginfo], et [example-source], veuillez saisir : 
~]# yum-config-manager --enable example\*
Loaded plugins: langpacks, product-id, subscription-manager
============================== repo: example ==============================
[example]
bandwidth = 0
base_persistdir = /var/lib/yum/repos/x86_64/7Server
baseurl = http://www.example.com/repo/7Server/x86_64/
cache = 0
cachedir = /var/cache/yum/x86_64/7Server/example[sortie tronquée]

Exemple 8.29. Activer tous les référentiels

Pour activer tous les référentiels définis dans le fichier /etc/yum.conf et dans le répertoire /etc/yum.repos.d/, saisissez : 
~]# yum-config-manager --enable \*
Loaded plugins: langpacks, product-id, subscription-manager
============================== repo: example ==============================
[example]
bandwidth = 0
base_persistdir = /var/lib/yum/repos/x86_64/7Server
baseurl = http://www.example.com/repo/7Server/x86_64/
cache = 0
cachedir = /var/cache/yum/x86_64/7Server/example[sortie tronquée]
Si elle fonctionne correctement, la commande yum-config-manager --enable affiche la configuration du référentiel actuel.

Désactiver un référentiel Yum

Pour désactiver un référentiel yum, veuillez exécuter la commande suivante en tant qu'utilisateur root : 
yum-config-manager --disable repository…
…où référentiel est l'ID unique du référentiel (utilisez yum repolist all pour répertorier les ID des référentiels disponibles). De même qu'avec yum-config-manager --enable, vous pouvez utiliser une expression glob pour désactiver tous les référentiels correspondants en même temps : 
yum-config-manager --disable glob_expression…

Exemple 8.30. Désactiver tous les référentiels

Pour désactiver tous les référentiels définis dans le fichier /etc/yum.conf et dans le répertoire /etc/yum.repos.d/, saisissez : 
~]# yum-config-manager --disable \*
Loaded plugins: langpacks, product-id, subscription-manager
============================== repo: example ==============================
[example]
bandwidth = 0
base_persistdir = /var/lib/yum/repos/x86_64/7Server
baseurl = http://www.example.com/repo/7Server/x86_64/
cache = 0
cachedir = /var/cache/yum/x86_64/7Server/example[sortie tronquée]
Si elle fonctionne correctement, la commande yum-config-manager --disable affiche la configuration actuelle.

8.5.6. Création d'un référentiel Yum

Pour définir un référentiel yum, effectuez les étapes suivantes :
  1. Installez le paquet createrepo. Pour faire cela, veuillez saisir ce qui suit dans l'invite shell en tant qu'utilisateur root : 
    yum install createrepo
  2. Copiez tous les paquets que vous souhaitez avoir dans votre référentiel dans un seul répertoire, comme /mnt/local_repo/.
  3. Déplacez-vous sur ce répertoire et exécutez la commande suivante : 
    createrepo --database /mnt/local_repo
    Ceci crée les métadonnées nécessaires pour votre référentiel yum, ainsi que la base de données sqlite pour accélérer les opérations yum.

8.5.7. Ajouter les référentiels « Optional » (Optionnel) et « Supplementary » (Supplémentaire)

Les canaux d'abonnements « Optional » et « Supplementary » fournissent des paquets logiciels supplémentaires pour Red Hat Enterprise Linux qui offrent des logiciels sous licence open source (dans le canal « Optional ») et sous licence propriétaire (dans le canal « Supplementary »).
Avant de vous abonner aux canaux « Optional » et « Supplementary », veuillez consulter les Détails de l'étendue de la couverture. Si vous décidez d'installer des paquets à partir de ces canaux, veuillez suivre les étapes documentées dans l'article nommé Comment accéder aux canaux « Optional » et « Supplementary » et aux paquets -devel en utilisant Red Hat Subscription Manager (RHSM) ? sur le Portail Client Red Hat.

8.6. Greffons Yum

Yum fournit des greffons qui étendent et améliorent ses opérations. Certains greffons sont installés par défaut. S'il y en a, Yum vous informera toujours sur les greffons chargés et actifs lorsque vous exécutez une commande yum. Exemple : 
~]# yum info yum
Loaded plugins: langpacks, product-id, subscription-manager[sortie tronquée]
Remarquez que les noms de greffons qui suivent Loaded plugins sont les noms que vous pouvez fournir à l'option --disableplugin=plugin_name.

8.6.1. Activer, configurer, et désactiver des greffons Yum

Pour activer des greffons yum, assurez-vous qu'une ligne commençant par plugins= soit effectivement présente dans la section [main] du fichier /etc/yum.conf, et que sa valeur soit égale à 1 : 
plugins=1
Vous pouvez désactiver tous les greffons en modifiant cette ligne comme suit : plugins=0.

Important

La désactivation de tous les greffons n'est pas recommandée car certains greffons fournissent des services yum importants. En particulier, les greffons product-id et subscription-manager fournissent la prise en charge du Content Delivery Network (CDN) basé sur certificats. La désactivation globale des greffons est offerte en tant qu'option pratique, et est généralement uniquement recommandée lors du diagnostique d'un problème potentiel avec yum.
Chaque greffon installé possède son propre fichier de configuration dans le répertoire /etc/yum/pluginconf.d/. Vous pouvez définir des options spécifiques aux greffons dans ces fichiers. Par exemple, ci-dessous figure le fichier de configuration du greffon aliases nommé aliases.conf : 
[main]
enabled=1
De même qu'avec le fichier /etc/yum.conf, les fichiers de configuration des greffons contiennent toujours une section [main] où l'option enabled= contrôle si le greffon est activé lorsque vous exécutez des commandes yum. Si cette option est manquante, vous pouvez l'ajouter manuellement au fichier.
Si vous désactivez tous les greffons en paramétrant enabled=0 dans /etc/yum.conf, alors tous les greffons seront désactivés, peu importe s'ils étaient activés dans leurs fichiers de configuration individuels.
Si vous souhaitez simplement désactiver tous les greffons yum pour une commande yum unique, veuillez utiliser l'option --noplugins.
Si vous souhaitez désactiver un ou plusieurs greffons yum pour une seule commande yum, ajoutez l'option --disableplugin=plugin_name à la commande. Par exemple, pour désactiver le greffon aliases pendant une mise à jour du système, veuillez saisir : 
~]# yum update --disableplugin=aliases
Les noms des greffons que vous fournissez à l'option --disableplugin= sont les mêmes que ceux répertoriés après la ligne Loaded plugins dans la sortie de toute commande yum. Vous pouvez désactiver de multiples greffons en séparant leurs noms par des virgules. En outre, vous pouvez faire correspondre plusieurs noms de greffons ou raccourcir les plus longs en utilisant des expressions glob : 
~]# yum update --disableplugin=aliases,lang*

8.6.2. Installer des greffons Yum supplémentaires

Les greffons Yum adhèrent habituellement à la convention de dénomination de paquets yum-plugin-plugin_name, ,mais pas toujours : par exemple, le paquet qui fournit le greffon kabi est nommé kabi-yum-plugins. Vous pouvez installer un greffon yum de la même manière que si vous installiez d'autres paquets. Par exemple, pour installer le greffon yum-aliases, veuillez saisir ce qui suit dans l'invite shell : 
~]# yum install yum-plugin-aliases

8.6.3. Utiliser des greffons Yum

La liste suivante fournit les descriptions et instructions d'utilisation de plusieurs greffons yum utiles. Les greffons sont répertoriés par nom, les crochets contiennent le nom du paquet.
search-disabled-repos (subscription-manager)
Le greffon search-disabled-repos permet d'activer temporairement ou de façon permanente des référentiels désactivés afin de vous aider à résoudre des problèmes de dépendances. Avec ce greffon activé, quand Yum échoue à l'installation d'un paquet à cause d'une erreur de résolution de dépendance, il propose d'activer temporairement les référentiels désactivés pour essayer à nouveau. Si l'installation réussit, Yum propose également d'activer les référentiels utilisés de façon permanente. Notez que le greffon ne fonctionne qu'avec les référentiels qui sont gérés par le subscription-manager et ne fonctionne pas avec les référentiels personnalisés.

Important

Quand yum exécute avec l'option --assumeyes ou -y, ou si la directive assumeyes est activée dans /etc/yum.conf, le greffon active les référentiels désactivés, à la fois temporairement et de façon permanente, sans invitation de confirmation. Cela peut mener à des problèmes, comme par exemple, d'activer des référentiels que vous ne souhaitez pas activer.
Pour configurer le greffon search-disabled-repos, modifiez le fichier de configuration situé dans /etc/yum/pluginconf.d/search-disabled-repos.conf. Une liste de directives pouvant être utilisées dans la section [main] est affichée dans le tableau suivant.

Tableau 8.3. Directives search-disabled-repos.conf prises en charge

DirectiveDescription
enabled=valeurVous permet d'activer ou de désactiver le greffon. La valeur doit être 1 (activé), ou 0 (désactivé). Le greffon est activé par défaut.
notify_only=valeurVous permet de limiter le comportement du greffon aux notifications uniquement. La valeur doit correspondre à 1 (notifie sans modifier le comportement de Yum), ou 0 (modifie le comportement de Yum). Par défaut, le greffon ne notifie que l'utilisateur.
ignored_repos=référentielsVous permet de spécifier les référentiels qui ne seront pas activés par le greffon.
kabi (kabi-yum-plugins)
Le greffon kabi vérifie si un paquet de mise à jour de pilote est conforme à l'interface binaire d'application du noyau officielle de Red Hat (« kernel Application Binary Interface », ou kABI). Avec l'activation de ce greffon, lorsqu'un utilisateur tente d'installer un paquet qui utilise des symboles du noyau ne se trouvant pas sur une liste blanche, un message d'avertissement est écrit sur le journal système. En outre, configurer le greffon pour qu'il soit exécuté en mode « enforcing » empêche de tels paquets d'être installés.
Pour configurer le greffon kabi, modifiez le fichier de configuration situé dans /etc/yum/pluginconf.d/kabi.conf. Une liste de directives pouvant être utilisées dans la section [main] est affichée dans le tableau ci-dessous.

Tableau 8.4. Directives kabi.conf prises en charge

DirectiveDescription
enabled=valeurVous permet d'activer ou de désactiver le greffon. La valeur valeur doit être 1 (activé), ou 0 (désactivé). Une fois installé, le greffon est activé par défaut.
whitelists=répertoirePermet de spécifier le répertoire dans lequel les fichiers avec les symboles du noyau pris en charge se trouvent. Par défaut, le greffon kabi utilise des fichiers fournis par le paquet kernel-abi-whitelists (c'est-à-dire le répertoire /usr/lib/modules/kabi-rhel70/).
enforce=valeurVous permet d'activer ou de désactiver le mode « enforcing ». La valeur doit être égale à 1 (activé), ou à 0 (désactivé). Par défaut, cette option est mise en commentaire et le greffon kabi n'affiche qu'un message d'avertissement.
product-id (subscription-manager)
Le greffon product-id gère les certificats d'identité des produits installés à partir du CDN. Le greffon product-id est installé par défaut.
langpacks (yum-langpacks)
Le greffon langpacks est utilisé pour rechercher les paquets des paramètres régionaux d'une langue sélectionnée pour chaque paquet ayant été installé. Le greffon langpacks est installé par défaut.
aliases (yum-plugin-aliases)
Le greffon aliases offre l'option de ligne de commande alias qui autorise la configuration et l'utilisation d'alias pour les commandes yum.
yum-changelog (yum-plugin-changelog)
Le greffon yum-changelog offre l'option de ligne de commande --changelog qui permet d'afficher les journaux des changements d'un paquet avant et après une mise à jour.
yum-tmprepo (yum-plugin-tmprepo)
Le greffon yum-tmprepo offre l'option de ligne de commande --tmprepo qui prend l'URL d'un fichier référentiel, le télécharge et l'active pour une seule transaction. Ce greffon essaie d'assurer une utilisation temporaire sécurisée de ses référentiels. Par défaut, il ne permet pas de désactiver la vérification GPG.
yum-verify (yum-plugin-verify)
Le greffon yum-verify offre les options de ligne de commande verify, verify-rpm, et verify-all pour afficher les données de vérification sur le système.
yum-versionlock (yum-plugin-versionlock)
Le greffon yum-versionlock exclut les autres versions des paquets sélectionnés, ce qui permet de protéger des paquets de mise à jour vers de nouvelles versions. Avec l'option de ligne de commande versionlock, vous pouvez afficher et modifier la liste des paquets verrouillés.

8.7. Ressources supplémentaires

Pour obtenir davantage d'informations sur la manière de gérer les paquets logiciels dans Red Hat Enterprise Linux, veuillez consulter les ressources répertoriées ci-dessous.

Documentation installée

  • yum(8) — la page du man de l'utilitaire de ligne de commande yum fournit une liste complète des options et des commandes prises en charge.
  • yumdb(8) — la page du man de l'utilitaire de ligne de commande yumdb documente comment utiliser cet outil pour effectuer des requêtes, et altérer la base de données yum si nécessaire.
  • yum.conf(5) — la page du man de yum.conf documente les options de configuration yum disponibles.
  • yum-utils(1) — la page du man de yum-utils répertorie et décrit brièvement les utilitaires supplémentaires pour gérer des configurations yum, manipuler des référentiels, et utiliser une base de données yum.

Ressources en ligne

  • Yum Guides — la page des Guides Yum sur la page d'accueil du projet fournit des liens vers une documentation supplémentaire.
  • Red Hat Access Labs — les Red Hat Access Labs incluent un « Yum Repository Configuration Helper ».

Voir aussi

  • Chapitre 5, Obtention de privilèges documente comment obtenir des privilèges administratifs en utilisant les commandes su et sudo.
  • Annexe A, RPM décrit le gestionnaire de paquets RPM (« RPM Package Manager », ou RPM), qui est le système de mise en paquet utilisé par Red Hat Enterprise Linux.

Partie IV. Services d'infrastructure

Cette partie fournit des informations sur la manière de configurer les services et démons, et sur la manière d'activer l'accès distant à une machine Red Hat Enterprise Linux.

Chapitre 9. Gérer les services avec systemd

9.1. Introduction à systemd

Systemd est un gestionnaire de systèmes et de services pour les systèmes d'exploitation Linux. Il est conçu pour être rétro-compatible avec les scripts SysV init, et fournit un certain nombre de fonctionnalités, comme le lancement en parallèle des services système pendant l'initialisation, l'activation des démons à la demande, la prise en charge des instantanés d'état du système, ou la logique de contrôle de service basée sur dépendances. Sur Red Hat Enterprise Linux 7, systemd remplace Upstart comme système init par défaut.
Systemd introduit le concept d'unités systemd (« systemd units »). Ces unités sont représentées par les fichiers de configuration d'unités dans l'un de répertoires qui se trouve dans Tableau 9.2, « Emplacements des fichiers d'unités systemd », et inclut des informations sur les services système, les sockets d'écoute, les instantanés d'état de système enregistré, et d'autres objets pertinents au système init. Pour obtenir la liste complète des types d'unité systemd disponibles, veuillez consulter Tableau 9.1, « Types d'unités systemd disponibles ».

Tableau 9.1. Types d'unités systemd disponibles

Type d'unitéExtension de fichierDescription
Unité du service.serviceService système.
Unité cible.targetUn groupe d'unités systemd.
Unité Automount.automountUn point Automount du système de fichiers.
Unité du périphérique.deviceFichier du périphérique reconnu par le noyau.
Unité de montage.mountPoint de montage du système de fichiers.
Unité de chemin.pathUn fichier ou répertoire dans un système de fichiers.
Unité scope.scopeUn processus créé de manière externe.
Unité de tranche.sliceUn groupe d'unités organisées de manière hiérarchique qui gèrent des processus système.
Unité d'instantané.snapshotUn état enregistré du gestionnaire systemd.
Unité de socket.socketUn socket de communication inter-processus.
Unité swap.swapUn périphérique ou fichier swap.
Unité minuteur.timerUn minuteur systemd.

Tableau 9.2. Emplacements des fichiers d'unités systemd

RépertoireDescription
/usr/lib/systemd/system/Fichiers d'unités systemd distribuées avec des paquets RPM installés.
/run/systemd/system/Les fichiers d'unités systemd créées pendant l'exécution. Ce répertoire a priorité sur le répertoire de fichiers d'unités de service installées.
/etc/systemd/system/Les fichiers d'unités systemd créées par systemctl enable ainsi que les fichiers d'unités ajoutés pour étendre un service. Ce répertoire a priorité sur le répertoire de fichiers d'unités de service installées.

9.1.1. Fonctionnalités principales

Sur Red Hat Enterprise Linux 7, le gestionnaire de systèmes et services systemd fournit les fonctionnalités principales suivantes :
  • Activation basée socket — pendant l'initialisation, systemd crée des sockets d'écoute pour tous les services système qui prennent en charge ce type d'activation, et passe les sockets à ces services dès qu'ils sont lancés. Ceci permet à systemd de lancer les services en parallèle, mais rend également possible le redémarrage d'un service sans perdre de message qui lui aurait été envoyé pendant son indisponibilité : le socket correspondant reste accessible et tous les messages sont mis en file d'attente.
    Systemd utilise des unités de socket « socket units » pour une activation basée socket.
  • Activation basée sur Bus — les services système qui utilisent D-Bus pour les communications inter-processus peuvent être lancés à la demande la première fois qu'une application cliente tente de communiquer avec eux. Systemd utilise des fichiers de service « D-Bus service files » pour une activation basée bus.
  • Activation basée périphérique — les services système qui prennent en charge l'activation basée périphérique peuvent être lancés à la demande lorsqu'un type particulier de matériel physique est branché ou devient disponible. Systemd utilise des unités de périphérique « device units » pour l'activation basée périphérique.
  • Activation basée chemin — les services système qui prennent en charge l'activation basée chemin peuvent être lancés à la demande lorsqu'un fichier ou répertoire particulier change d'état. Systemd utilise les unités de chemin « path units » pour l'activation basée chemin.
  • Instantanés d'état système — Systemd peut temporairement enregistrer l'état actuel de toutes les unités ou restaurer un état précédent du système à partir d'un instantané créé dynamiquement. Pour stocker l'état actuel du système, systemd utilise des unités d'instantané « snapshot units » créées dynamiquement.
  • Gestion des points de montage et des points Automount — Systemd surveille et gère tous les points de montage et d'Automount. Systemd utilise « mount units » pour les points de montage et « automount units » pour les points d'Automount.
  • Parallélisation aggressive — à cause de l'activation basée socket, systemd peut lancer des services système en parallèle une fois que tous les sockets d'écoute sont en place. Lorsque combinés aux services système qui prennent en charge l'activation à la demande, l'activation en parallèle réduit largement le temps qu'il faut pour démarrer le système.
  • Logique d'activation d'unité transactionnelle — avant d'activer ou de désactiver une unité, systemd calcule ses dépendances, crée une transaction temporaire, et vérifie que celle-ci soit bien cohérente. Si une transaction est incohérente, systemd tente automatiquement de la corriger et d'en supprimer les tâches non essentielles avant de rapporter une erreur.
  • Rétro-compatibilité avec SysV init — Systemd prend en charge les scripts SysV init comme décrit dans la spécification « Linux Standard Base Core Specification », ce qui facilite le chemin de mise à niveau des unités de service Systemd.

9.1.2. Changements de compatibilité

Le gestionnaire de systèmes et Systemd sont conçus pour être principalement compatibles avec SysV init et Upstart. Ci-dessous figurent les principaux changements de compatibilité par rapport à la dernière version majeure du système Red Hat Enterprise Linux :
  • Systemd n'offre qu'une prise en charge limitée des niveaux d'exécution. Il fournit un certain nombre d'unités cibles pouvant être directement mappées à ces niveaux d'exécution et est également distribué avec l'ancienne commande runlevel pour des raisons de compatibilité. Les cibles Systemd ne peuvent pas toutes être directement mappées aux niveaux d'exécution. Par conséquent, cette commande peut retourner N, pour indiquer un niveau d'exécution inconnu. Il est recommandé d'éviter d'utiliser la commande runlevel si possible.
    Pour obtenir davantage d'informations sur les cibles Systemd et leurs comparaisons aux niveaux d'exécution, veuillez consulter la Section 9.3, « Travailler avec des cibles Systemd ».
  • L'utilitaire systemctl ne prend pas en charge les commandes personnalisées. En plus des commandes standards, comme start, stop, et status, les auteurs de scripts SysV init peuvent implémenter un nombre de commandes arbitraires afin de fournir des fonctionnalités supplémentaires. Par exemple, le script init d'iptables sur Red Hat Enterprise Linux 6 peut être exécuté avec la commande panic, qui active immédiatement le mode de panique et reconfigure le système pour ne plus recevoir de paquets entrants et ne plus pouvoir envoyer de paquets sortants. Ceci n'est pas pris en charge sur Systemd et systemctl n'accepte que les commandes documentées.
    Pour obtenir davantage d'informations sur l'utilitaire systemctl et sa comparaison avec l'ancien utilitaire service, veuillez consulter la Section 9.2, « Gérer les services système ».
  • L'utilitaire systemctl ne communique pas avec les services qui n'ont pas été lancés par Systemd. Lorsque Systemd lance un service système, il stocket l'ID de son processus principal afin d'en garder la trace. L'utilitaire systemctl utilise ensuite ce PID pour effectuer des requêtes et pour gérer le service. Par conséquent, si un utilisateur lance un démon particulier directement sur la ligne de commande, systemctl sera incapable de déterminer son statut actuel ou de l'arrêter.
  • Systemd arrête uniquement les services en cours d'exécution. Précédemment, lorsque la séquence de fermeture était initiée, Red Hat Enterprise Linux 6 et les versions plus anciennes du système utilisaient des liens symboliques situés dans le répertoire /etc/rc0.d/ pour arrêter tous les services systèmes, quel que soit leur statut. Avec Systemd, seuls les services en cours d'exécution sont arrêtés pendant la fermeture.
  • Les services système sont incapables de lire le flux d'entrées standard. Lorsque Systemd lance un service, il connecte son entrée standard sur /dev/null pour empêcher toute interaction avec l'utilisateur.
  • Les services système n'héritent d'aucun contexte (comme les variables d'environnement HOME et PATH) provenant de l'utilisateur les invoquant et de sa session. Chaque service est exécuté dans un contexte d'exécution épuré.
  • Lors du chargement d'un script SysV init, systemd lit les informations de dépendance codées dans l'en-tête LSB (« Linux Standard Base ») et les interprète pendant l'exécution.
  • Toutes les opérations sur les unités de service sont sujettes à un délai par défaut de 5 minutes pour empêcher à tout service malfonctionnant de geler le système. Cette valeur est codée en dur pour les services générés à partir d’initscripts et ne peut pas être modifiée. Toutefois, des fichiers de configuration individuels peuvent servir à spécifier une valeur de délai d’attente plus longue pour chaque service individuel, voir Exemple 9.21, « Modifier la limite du délai d'attente »
Pour obtenir une liste détaillée des changements de compatibilité apportés avec systemd, veuillez consulter le Guide de planification de migration de Red Hat Enterprise Linux 7.

9.2. Gérer les services système

Note

Afin de gagner en expertise, vous serez sans doute intéressé par le cours de formation Red Hat System Administration II (RH134).
Les versions précédentes de Red Hat Enterprise Linux, qui étaient distribuées avec SysV init ou Upstart, utilisaient des scripts init (« init scripts ») situés dans le répertoire /etc/rc.d/init.d/. Ces scripts init étaient habituellement écrits en Bash, et autorisaient l'administrateur systèmes à contrôler l'état des services et des démons dans leurs systèmes. Sur Red Hat Enterprise Linux 7, ces scripts init ont été remplacés par des unités de service (« service units »).
Les unités de service se terminent par l'extension de fichier .service et ont un but similaire à celui des scripts init. Pour afficher, lancer, arrêter, redémarrer, activer ou désactiver des services système, veuillez utiliser la commande systemctl décrite dans Tableau 9.3, « Comparaison du service Utility avec systemctl », Tableau 9.4, « Comparaison de l'utilitaire chkconfig avec systemctl », et un peu plus bas dans cette section. Les commandes service et chkconfig sont toujours disponibles dans le système et fonctionnent comme prévu, mais sont uniquement incluses pour des raisons de compatibilité et doivent être évitées.

Tableau 9.3. Comparaison du service Utility avec systemctl

servicesystemctlDescription
service nom start
systemctl start nom.service
Lance un service.
service nom stop
systemctl stop nom.service
Arrête un service.
service nom restart
systemctl restart nom.service
Redémarre un service.
service nom condrestart
systemctl try-restart nom.service
Redémarre un service uniquement s'il est en cours d'exécution.
service nom reload
systemctl reload nom.service
Recharge la configuration.
service nomstatus
systemctl status nom.service
systemctl is-active nom.service
Vérifie si un service est en cours d'exécution.
service --status-all
systemctl list-units --type service --all
Affiche le statut de tous les services.

Tableau 9.4. Comparaison de l'utilitaire chkconfig avec systemctl

chkconfigsystemctlDescription
chkconfig nom on
systemctl enable nom.service
Active un service.
chkconfig nom off
systemctl disable nom.service
Désactive un service.
chkconfig --list nom
systemctl status nom.service
systemctl is-enabled nom.service
Vérifie si un service est activé.
chkconfig --list
systemctl list-unit-files --type service
Répertorie tous les services et vérifie s'ils sont activés.
chkconfig --list
systemctl list-dependencies --after
Répertorie les services qui doivent démarrer avant l'unité spécifiée.
chkconfig --list
systemctl list-dependencies --before
Répertorie les services qui doivent démarrer aprés l'unité spécifiée.

Spécifier les unités de service

Par souci de clarté, tous les exemples de commande dans le reste de cette section utilisent des noms d'unité complets avec l'extension de fichier .service. Exemple : 
~]# systemctl stop nfs-server.service
Cependant, il est possible d'omettre cette extension de fichier, dans lequel cas, l'utilitaire systemctl assume que l'argument suppose qu'il s'agit d'une unité de service. La commande suivante équivaut à celle se trouvant ci-dessus : 
~]# systemctl stop nfs-server
De plus, certaines unités ont des alias correspondants. Ces noms peuvent avoir des noms plus courts que les unités, qui peuvent être utilisés à la place des noms d'unité. Pour trouver les alias pouvant être utilisés pour une unité particulière : 
~]# systemctl show nfs-server.service -p Names

9.2.1. Répertorier les services

Pour répertorier toutes les unités de service actuellement chargées, veuillez saisir ce qui suit dans une invite de shell : 
systemctl list-units --type service
Cette commande affiche le nom complet de chaque fichier d'unités de service (UNIT) suivi d'une note indiquant si le ficiers d'unités a été chargée (LOAD), son état d'activation de haut niveau (ACTIVE) et de bas niveau (SUB), ainsi qu'une courte description (DESCRIPTION).
Par défaut, la commande systemctl list-units affiche uniquement les unités actives. Si vous souhaitez afficher toutes les unités chargées, quel que soit leur état, veuillez exécuter cette commande avec l'option de ligne de commande --all ou -a : 
systemctl list-units --type service --all
Vous pouvez également répertorier toutes les unités de service disponibles pour voir si elles sont activées. Pour faire cela, veuillez saisir : 
systemctl list-unit-files --type service
Cette commande affiche le nom complet de chaque unité de service (UNIT FILE) suivi d'informations indiquant si l'unité de service est activée ou non (STATE). Pour obtenir des informations sur la manière de déterminer le statut des unités de service individuelles, veuillez consulter la Section 9.2.2, « Afficher le statut du service ».

Exemple 9.1. Répertorier les services

Pour répertorier toutes les unités de service actuellement chargées, veuillez exécuter la commande suivante : 
~]$ systemctl list-units --type service
UNIT                           LOAD   ACTIVE SUB     DESCRIPTION
abrt-ccpp.service              loaded active exited  Install ABRT coredump hook
abrt-oops.service              loaded active running ABRT kernel log watcher
abrt-vmcore.service            loaded active exited  Harvest vmcores for ABRT
abrt-xorg.service              loaded active running ABRT Xorg log watcher
abrtd.service                  loaded active running ABRT Automated Bug Reporting Tool
...
systemd-vconsole-setup.service loaded active exited  Setup Virtual Console
tog-pegasus.service            loaded active running OpenPegasus CIM Server

LOAD   = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB    = The low-level unit activation state, values depend on unit type.

46 loaded units listed. Pass --all to see loaded but inactive units, too.
To show all installed unit files use 'systemctl list-unit-files'
Pour répertorier tous les fichiers d'unités de service installées afin de déterminer si elles sont activées, veuillez saisir : 
~]$ systemctl list-unit-files --type service
UNIT FILE                                   STATE
abrt-ccpp.service                           enabled
abrt-oops.service                           enabled
abrt-vmcore.service                         enabled
abrt-xorg.service                           enabled
abrtd.service                               enabled
...
wpa_supplicant.service                      disabled
ypbind.service                              disabled

208 unit files listed.

9.2.2. Afficher le statut du service

Pour afficher des informations détaillées sur une unité de service qui correspond à un service système, veuillez saisir ce qui suit dans une invite de shell : 
systemctl status name.service
Veuillez remplacer name par le nom de l'unité de service que vous souhaitez inspecter (par exemple, gdm). Cette commande affiche le nom de l'unité de service sélectionnée suivi d'une courte description, un ou plusieurs champs décrit dans la Tableau 9.5, « Informations sur les unités de service disponibles », et si elle est exécutée par l'utilisateur root, les entrées de journal les plus récentes seront également incluses.

Tableau 9.5. Informations sur les unités de service disponibles

ChampDescription
LoadedInformations indiquant si l'unité de service est chargée, le chemin absolu vers le fichier de l'unité, et une note indiquant si l'unité est activée.
ActiveInformations indiquant si l'unité de service exécutée est suivie d'un horodatage.
Main PIDLe PID du service système correspondant est suivi par son nom.
StatusInformations supplémentaires sur le service système correspondant.
ProcessInformations supplémentaires sur les processus connexes.
CGroupInformations supplémentaires sur les Groupes de contrôle connexes (cgroups).
Pour vérifier qu'une unité de service particulière est en cours d'exécution, veuillez exécuter la commande suivante : 
systemctl is-active name.service
Similairement, pour déterminer si une unité de service particulière est activée, veuillez saisir : 
systemctl is-enabled name.service
Remarquez que systemctl is-active et systemctl is-enabled retournent un statut de sortie (« exit status ») de 0 si l'unité de service spécifiée est en cours d'exécution ou si elle est activée. Pour obtenir des informations sur la manière de répertorier toutes les unités de service actuellement chargées, veuillez consulter la Section 9.2.1, « Répertorier les services ».

Exemple 9.2. Afficher le statut du service

L'unité de service du gestionnaire d'affichage GNOME se nomme gdm.service. Pour déterminer le statut actuel de cette unité de service, veuillez saisir ce qui suit dans une invite de shell : 
~]# systemctl status gdm.service
gdm.service - GNOME Display Manager
   Loaded: loaded (/usr/lib/systemd/system/gdm.service; enabled)
   Active: active (running) since Thu 2013-10-17 17:31:23 CEST; 5min ago
 Main PID: 1029 (gdm)
   CGroup: /system.slice/gdm.service
           ├─1029 /usr/sbin/gdm
           ├─1037 /usr/libexec/gdm-simple-slave --display-id /org/gno...
           └─1047 /usr/bin/Xorg :0 -background none -verbose -auth /r...

Oct 17 17:31:23 localhost systemd[1]: Started GNOME Display Manager.

Exemple 9.3. Pour afficher les services qui doivent démarrer avant un service.

Pour déterminer quels services doivent démarrer avant le service indiqué, saisir ce qui suit dans une invite de shell : 
~]# systemctl list-dependencies --after gdm.service
gdm.service
├─dbus.socket
├─getty@tty1.service
├─livesys.service
├─plymouth-quit.service
├─system.slice
├─systemd-journald.socket
├─systemd-user-sessions.service
└─basic.target[sortie tronquée]

Exemple 9.4. Pour afficher les services qui doivent démarrer après un service.

Pour déterminer quels services doivent démarrer après le service indiqué, saisir ce qui suit dans une invite de shell : 
~]# systemctl list-dependencies --before gdm.service
gdm.service
├─dracut-shutdown.service
├─graphical.target
│ ├─systemd-readahead-done.service
│ ├─systemd-readahead-done.timer
│ └─systemd-update-utmp-runlevel.service
└─shutdown.target
  ├─systemd-reboot.service
  └─final.target
    └─systemd-reboot.service

9.2.3. Lancer un service

Pour lancer une unité de service qui correspond à un service système, veuillez saisir ce qui suit dans une invite de shell en tant qu'utilisateur root : 
systemctl start name.service
Veuillez remplacer name par le nom de l'unité de service que vous souhaitez lancer (par exemple, gdm). Cette commande lance l'unité de service sélectionnée dans la session actuelle. Pour obtenir des informations sur la manière d'activer une unité de service pour qu'elle soit lancée pendant l'initialisation, veuillez consulter la Section 9.2.6, « Activer un service ». Pour obtenir des informations sur la façon de déterminer le statut d'une unité de service particulière, veuillez consulter la Section 9.2.2, « Afficher le statut du service ».

Exemple 9.5. Lancer un service

L'unité de service pour le serveur HTTP Apache est nommé httpd.service. Pour activer cette unité de service et lancer le démon httpd dans la session actuelle, veuillez exécuter la commande suivante en tant qu'utilisateur root : 
~]# systemctl start httpd.service

9.2.4. Arrêter un service

Pour arrêter une unité de service qui correspond à un service système, veuillez saisir ce qui suit dans une invite de shell en tant qu'utilisateur root : 
systemctl stop name.service
Veuillez remplacer name par le nom de l'unité de service que vous souhaitez arrêter (par exemple, bluetooth). Cette commande arrête l'unité de service sélectionnée dans la session actuelle. Pour obtenir des informations sur la manière de désactiver une unité de service pour l'empêcher d'être lancée pendant l'initialisation, veuillez consulter la Section 9.2.7, « Désactiver un service ». Pour obtenir des informations sur comment déterminer le statut d'une unité de service particulière, veuillez consulter la Section 9.2.2, « Afficher le statut du service ».

Exemple 9.6. Arrêter un service

L'unité de service du démon bluetoothd est nommée bluetooth.service. Pour désactiver cette unité de service et arrêter le démon bluetoothd dans la session actuelle, veuillez exécuter la commande suivante en tant qu'utilisateur root : 
~]# systemctl stop bluetooth.service

9.2.5. Redémarrer un service

Pour redémarrer une unité de service qui correspond à un service système, veuillez saisir ce qui suit dans une invite de shell en tant qu'utilisateur root : 
systemctl restart name.service
Veuillez remplacer name par le nom de l'unité de service que vous souhaitez redémarrer (par exemple, httpd). Cette commande arrête l'unité de service sélectionnée dans la session actuelle et la redémarre immédiatement. De manière plus importante, si l'unité de service n'est pas en cours d'exécution, cette commande la lancera également. Pour ordonner à Systemd de redémarrer une unité de service uniquement si le service correspondant est déjà en cours d'exécution, veuillez exécuter la commande suivante en tant qu'utilisateur root : 
systemctl try-restart name.service
Certains services système permettent de recharger leur configuration sans interrompre leur exécution. Pour faire cela, en tant qu'utilisateur root, veuillez saisir : 
systemctl reload name.service
Remarquez que les services système qui ne prennent pas en charge cette fonctionnalité ignoreront simplement cette commande. Pour plus de commodité, la commande systemctl prend également en charge les commandes reload-or-restart et reload-or-try-restart qui redémarrent de tels services. Pour obtenir des informations sur la manière de déterminer le statut d'une certaine unité de service, veuillez consulter la Section 9.2.2, « Afficher le statut du service ».

Exemple 9.7. Redémarrer un service

Pour empêcher les utilisateurs de rencontrer des messages d'erreur non nécessaires ou des pages web dont le rendu est partiel, le serveur HTTP Apache vous permet de modifier et de recharger sa configuration sans avoir à le redémarrer et à interrompre les requêtes activement traitées. Pour cela, veuillez saisir ce qui suit dans une invite de shell en tant qu'utilisateur root : 
~]# systemctl reload httpd.service

9.2.6. Activer un service

Pour configurer une unité de service qui correspond à un service système afin qu'elle soit automatiquement lancée pendant l'initialisation, veuillez saisir ce qui suit dans une invite de shell en tant qu'utilisateur root : 
systemctl enable name.service
Veuillez remplacer name par le nom de l'unité de service que vous souhaitez activer (par exemple, httpd). Cette commande lit la section [Install] de l'unité de service sélectionnée et crée les liens symboliques appropriés vers le fichier /usr/lib/systemd/system/name.service dans le répertoire /etc/systemd/system/ et ses sous-répertoires. Cependant, cette commande ne réécrit pas les liens qui existent déjà. Si vous souhaitez vous assurer que les liens symboliques soient créés à nouveau, veuillez exécuter la commande suivante en tant qu'utilisateur root : 
systemctl reenable name.service
Cette commande désactive l'unité de service sélectionnée et la réactive immédiatement. Pour obtenir des informations sur la manière de déterminer si une unité de service particulière est autorisée à se lancer pendant l'initialisation, veuillez consulter la Section 9.2.2, « Afficher le statut du service ». Pour obtenir des informations sur la manière de lancer un service dans la session actuelle, veuillez consulter la Section 9.2.3, « Lancer un service ».

Exemple 9.8. Activer un service

Pour configurer le serveur HTTP Apache de manière à ce qu'il puisse être lancé automatiquement pendant l'initialisation, veuillez utiliser la commande suivante en tant qu'utilisateur root : 
~]# systemctl enable httpd.service
Created symlink from /etc/systemd/system/multi-user.target.wants/httpd.service to /usr/lib/systemd/system/httpd.service.

9.2.7. Désactiver un service

Pour empêcher une unité de service qui correspond à un service système d'être automatiquement lancée pendant l'initialisation, veuillez saisir ce qui suit dans une invite de shell en tant qu'utilisateur root : 
systemctl disable name.service
Veuillez remplacer name par le nom de l'unité de service que vous souhaitez désactiver (par exemple, bluetooth). Cette commande lit la section [Install] de l'unité de service sélectionnée et supprime les liens symboliques appropriés pointant vers le fichier /usr/lib/systemd/system/name.service du répertoire /etc/systemd/system/ et de ses sous-répertoires. En outre, vous pouvez masquer toute unité de service pour l'empêcher d'être lancée manuellement ou par un autre service. Pour faire cela, veuillez exécuter la commande suivante en tant qu'utilisateur root : 
systemctl mask name.service
Cette commande remplace le fichier /etc/systemd/system/name.service par un lien symbolique pointant vers /dev/null, ce qui rend le fichier de l'unité inaccessible à Systemd. Pour inverser cette action et démasquer une unité de service, veuillez saisir en tant qu'utilisateur root : 
systemctl unmask name.service
Pour obtenir des informations sur la manière de déterminer si une unité de service particulière est autorisée à être lancée en cours d'initialisation, veuillez consulter la Section 9.2.2, « Afficher le statut du service ». Pour obtenir des informations sur la manière d'arrêter un service dans la session actuelle, veuillez consulter la Section 9.2.4, « Arrêter un service ».

Exemple 9.9. Désactiver un service

L'Exemple 9.6, « Arrêter un service » illustre comment arrêter l'unité bluetooth.service dans la session actuelle. Pour empêcher cette unité de service d'être lancée pendant l'initialisation, veuillez saisir ce qui suit dans une invite de shell en tant qu'utilisateur root : 
~]# systemctl disable bluetooth.service
Removed symlink /etc/systemd/system/bluetooth.target.wants/bluetooth.service.
Removed symlink /etc/systemd/system/dbus-org.bluez.service.

9.3. Travailler avec des cibles Systemd

Les versions précédentes de Red Hat Enterprise Linux, qui étaient distribuées avec SysV init ou Upstart, implémentaient un ensemble prédéfini de niveaux d'exécution (« runlevels ») qui représentaient des modes d'opération spécifiques. Ces niveaux d'exécution étaient numérotés de 0 à 6 et étaient définis par une sélection de services système à exécuter lorsqu'un niveau d'exécution particulier était activé par l'administrateur systèmes. Sur Red Hat Enterprise Linux 7, le concept des niveaux d'exécution a été remplacé par les cibles Systemd.
Les cibles Systemd sont représentées par des unités de cible (« target units »). Les unités de cible se terminent par l'extension de fichier .target et leur unique but consiste à regrouper d'autres unités Systemd dans une chaîne de dépendances. Par exemple, l'unité graphical.target, qui est utilisée pour lancer une session graphique, lance des services système comme le gestionnaire d'affichage GNOME (gdm.service) ou le services des comptes (accounts-daemon.service) et active également l'unité multi-user.target. De manière similaire, l'unité multi-user.target lance d'autres services système essentiels, tels que NetworkManager (NetworkManager.service) ou D-Bus (dbus.service) et active une autre unité cible nommée basic.target.
Red Hat Enterprise Linux 7 est distribué avec un certain nombre de cibles prédéfinies plus ou moins similaires à l'ensemble standard des niveaux d'exécution des versions précédentes de ce système. Pour des raisons de compatibilité, des alias sont également fournis pour ces cibles, et les font correspondre directement aux niveaux d'exécution SysV. La Tableau 9.6, « Comparaison des niveaux d'exécution SysV avec les cibles Systemd » offre une liste complète des niveaux d'exécution SysV et des cibles Systemd correspondantes.

Tableau 9.6. Comparaison des niveaux d'exécution SysV avec les cibles Systemd

Niveau d'exécutionUnités de cibleDescription
0runlevel0.target, poweroff.targetQuitter et éteindre le système.
1runlevel1.target, rescue.targetInstaller un shell de secours.
2runlevel2.target, multi-user.targetInstaller un système multi-utilisateurs non graphique.
3runlevel3.target, multi-user.targetInstaller un système multi-utilisateurs non graphique.
4runlevel4.target, multi-user.targetInstaller un système multi-utilisateurs non graphique.
5runlevel5.target, graphical.targetInstaller un système graphique multi-utilisateurs.
6runlevel6.target, reboot.targetQuitter et redémarrer le système.
Pour afficher, modifier, ou configurer des cibles Systemd, veuillez utiliser l'utilitaire systemctl comme décrit dans la Tableau 9.7, « Comparaison des commandes SysV init avec systemctl » ainsi que dans les sections ci-dessous. Les commandes runlevel et telinit sont toujours disponibles dans le système et fonctionnent comme prévu, mais ne sont incluses que pour des raisons de compatibilité et doivent être évitées.

Tableau 9.7. Comparaison des commandes SysV init avec systemctl

Ancienne commandeNouvelle commandeDescription
runlevelsystemctl list-units --type targetRépertorie les unités de cible actuellement chargées.
telinit runlevelsystemctl isolate name.targetModifie la cible actuelle.

9.3.1. Afficher la cible par défaut

Pour déterminer l'unité de cible qui est utilisée par défaut, veuillez exécuter la commande suivante : 
systemctl get-default
Cette commande résout le lien symbolique situé sur /etc/systemd/system/default.target et affiche le résultat. Pour obtenir des informations sur comment modifier la cible par défaut, veuillez consulter la Section 9.3.3, « Modifier la cible par défaut ». Pour obtenir des informations sur comment répertorier toutes les unités de cible actuellement chargées, veuillez consulter la Section 9.3.2, « Afficher la cible actuelle ».

Exemple 9.10. Afficher la cible par défaut

Pour afficher l'unité cible par défaut, veuillez saisir : 
~]$ systemctl get-default
graphical.target

9.3.2. Afficher la cible actuelle

Pour répertorier toutes les unités de cible actuellement chargées, veuillez saisir la commande suivante dans une invite de shell : 
systemctl list-units --type target
Cette commande affiche le nom complet de chaque unité de cible (UNIT) suivi d'une note indiquant si l'unité a été chargée (LOAD), son état d'activation de haut niveau (ACTIVE) et de bas niveau (SUB), ainsi qu'une courte description (DESCRIPTION).
Par défaut, la commande systemctl list-units affiche uniquement les unités actives. Si vous souhaitez afficher toutes les unités chargées, quel que soit leur état, veuillez exécuter cette commande avec l'option de ligne de commande --all ou -a : 
systemctl list-units --type target --all
Veuillez consulter la Section 9.3.1, « Afficher la cible par défaut » pour obtenir des informations sur la manière d'afficher la cible par défaut. Pour obtenir des informations sur la manière de modifier la cible actuelle, veuillez consulter la Section 9.3.4, « Modifier la cible actuelle ».

Exemple 9.11. Afficher la cible actuelle

Pour répertorier toutes les unités de cible actuellement chargées, veuillez exécuter la commande suivante : 
~]$ systemctl list-units --type target
UNIT                  LOAD   ACTIVE SUB    DESCRIPTION
basic.target          loaded active active Basic System
cryptsetup.target     loaded active active Encrypted Volumes
getty.target          loaded active active Login Prompts
graphical.target      loaded active active Graphical Interface
local-fs-pre.target   loaded active active Local File Systems (Pre)
local-fs.target       loaded active active Local File Systems
multi-user.target     loaded active active Multi-User System
network.target        loaded active active Network
paths.target          loaded active active Paths
remote-fs.target      loaded active active Remote File Systems
sockets.target        loaded active active Sockets
sound.target          loaded active active Sound Card
spice-vdagentd.target loaded active active Agent daemon for Spice guests
swap.target           loaded active active Swap
sysinit.target        loaded active active System Initialization
time-sync.target      loaded active active System Time Synchronized
timers.target         loaded active active Timers

LOAD   = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB    = The low-level unit activation state, values depend on unit type.

17 loaded units listed. Pass --all to see loaded but inactive units, too.
To show all installed unit files use 'systemctl list-unit-files'.

9.3.3. Modifier la cible par défaut

Pour configurer le système de manière à utiliser une unité de cible différente par défaut, veuillez saisir ce qui suit dans une invite de shell en tant qu'utilisateur root : 
systemctl set-default name.target
Veuillez remplacer name par le nom de l'unité de cible que vous souhaitez utiliser par défaut (par exemple, multi-user). Cette commande remplace le fichier /etc/systemd/system/default.target par un lien symbolique pointant vers /usr/lib/systemd/system/name.target, où name est le nom de l'unité cible que vous souhaitez utiliser. Pour obtenir davantage d'informations sur la manière de modifier la cible actuelle, veuillez consulter la Section 9.3.4, « Modifier la cible actuelle ». Pour obtenir des informations sur la manière de répertorier toutes les unités de cible actuellement chargées, veuillez consulter la Section 9.3.2, « Afficher la cible actuelle ».

Exemple 9.12. Modifier la cible par défaut

Pour configurer le système de manière à utiliser l'unité multi-user.target par défaut, veuillez saisir la commande suivante dans une invite de shell en tant qu'utilisateur root : 
~]# systemctl set-default multi-user.target
rm '/etc/systemd/system/default.target'
ln -s '/usr/lib/systemd/system/multi-user.target' '/etc/systemd/system/default.target'

9.3.4. Modifier la cible actuelle

Pour passer à une unité de cible différente dans la session actuelle, veuillez saisir ce qui suit dans l'invite de shell en tant qu'utilisateur root : 
systemctl isolate name.target
Veuillez remplacer name par le nom de l'unité de cible que vous souhaitez utiliser par défaut (par exemple, multi-user). Cette commande remplace l'unité de cible nommée name et toutes ses unités dépendantes, et arrête immédiatement toutes les autres. Pour obtenir des informations sur la manière de modifier la cible par défaut, veuillez consulter la Section 9.3.3, « Modifier la cible par défaut ». Pour obtenir des informations sur la manière de répertorier toutes les unités de cible actuellement chargées, veuillez consulter la Section 9.3.2, « Afficher la cible actuelle ».

Exemple 9.13. Modifier la cible actuelle

Pour éteindre l'interface utilisateur graphique et modifier l'unité en multi-user.target dans la session actuelle, veuillez saisir la commande suivante en tant qu'utilisateur root : 
~]# systemctl isolate multi-user.target

9.3.5. Passer en mode de secours

Le mode de secours (« Rescue mode ») fournit un environnement simple utilisateur pratique, et vous permet de réparer votre système dans les cas où il est impossible d'effectuer un processus de démarrage normal. En mode de secours, le système tente de monter tous les systèmes de fichiers locaux et de lancer plusieurs services système importants, mais n'active pas d'interface réseau ou ne permet pas à d'autres d'utilisateurs de se connecter au système au même moment. Sur Red Hat Enterprise Linux 7, le mode de secours est équivalent au mode utilisateur seul (single user mode) et requiert le mot de passe root.
Pour modifier la cible actuelle et entrer en mode de secours dans la session actuelle, veuillez saisir ce qui suit dans l'invite de shell en tant qu'utilisateur root : 
systemctl rescue
Cette commande est similaire à systemctl isolate rescue.target, mais elle envoie également un message informatif à tous les utilisateurs actuellement connectés au système. Pour empêcher Systemd d'envoyer ce message, veuillez exécuter cette commande avec l'option de ligne de commande --no-wall : 
systemctl --no-wall rescue
Pour obtenir des informations sur la manière d'entrer en mode d'urgence, veuillez consulter Section 9.3.6, « Passer en mode d'urgence ».

Exemple 9.14. Passer en mode de secours

Pour entrer en mode de secours dans la session actuelle, veuillez exécuter la commande suivante en tant qu'utilisateur root : 
~]# systemctl rescue

Broadcast message from root@localhost on pts/0 (Fri 2013-10-25 18:23:15 CEST):

The system is going down to rescue mode NOW!

9.3.6. Passer en mode d'urgence

Le mode d'urgence (« Emergency mode ») fournit l'environnement le plus minimaliste possible et vous permet de réparer votre système même dans des situations où le système est incapable d'entrer en mode de secours. Dans le mode d'urgence, le système monte le système de fichiers root uniquement en lecture, il ne tentera pas de monter d'autre système de fichiers locaux, n'activera pas d'interface réseau et lancera quelques services essentiels. Sur Red Hat Enterprise Linux 7, le mode d'urgence requiert le mot de passe root.
Pour modifier la cible actuelle et entrer en mode d'urgence dans la session actuelle, veuillez saisir ce qui suit dans l'invite de shell en tant qu'utilisateur root : 
systemctl emergency
Cette commande est similaire à systemctl isolate emergency.target, mais elle envoie également un message informatif à tous les utilisateurs actuellement connectés au système. Pour empêcher Systemd d'envoyer ce message, veuillez exécuter cette commande avec l'option de ligne de commande --no-wall : 
systemctl --no-wall emergency
Pour obtenir des informations sur la manière d'entrer en mode de secours, veuillez consulter Section 9.3.5, « Passer en mode de secours ».

Exemple 9.15. Passer en mode d'urgence

Pour entrer en mode d'urgence sans envoyer de message à tous les utilisateurs actuellement connectés au système, veuillez exécuter la commande suivante en tant qu'utilisateur root : 
~]# systemctl --no-wall emergency

9.4. Arrêter, suspendre, et mettre le système en hibernation

Sur Red Hat Enterprise Linux 7, l'utilitaire systemctl remplace un certain nombre de commandes de gestion de l'alimentation utilisées dans des versions précédentes du système Red Hat Enterprise Linux. Les commandes répertoriées dans la Tableau 9.8, « Comparaison des commandes de gestion de l'alimentation avec systemctl » sont toujours disponibles sur le système pour des raisons de compatibilité, mais il est conseillé d'utiliser systemctl lorsque possible.

Tableau 9.8. Comparaison des commandes de gestion de l'alimentation avec systemctl

Ancienne commandeNouvelle commandeDescription
haltsystemctl haltArrête le système.
poweroffsystemctl poweroffMet le système hors-tension.
rebootsystemctl rebootRedémarre le système.
pm-suspendsystemctl suspendSuspend le système.
pm-hibernatesystemctl hibernateMet le système en hibernation.
pm-suspend-hybridsystemctl hybrid-sleepMet en hibernation et suspend le système.

9.4.1. Arrêter le système

L’utilitaire systemctl fournit des commandes de fermeture du système, mais la commande traditionnelle shutdown est également prise en charge. Bien que la commande shutdown fasse appel à l’utilitaire systemctl pour la fermeture, elle présente l'avantage d'intégrer un argument de temps. C'est particulièrement utile pour la maintenance et pour laisser plus de temps aux utilisateurs pour réagir à une notification de fermeture du système. La possibilité de pouvoir annuler le fermeture peut également être un plus.

Utilisation de la commande systemctl

Pour arrêter le système et mettre la machine hors-tension, veuillez saisir ce qui suit dans une invite de shell en tant qu'utilisateur root : 
systemctl poweroff
Pour arrêter et interrompre le système sans mettre la machine hors-tension, veuillez exécuter la commande suivante en tant qu'utilisateur root : 
systemctl halt
Par défaut, l'exécution de l'une de ces commandes amène Systemd à envoyer un message informatif à tous les utilisateurs actuellement connectés au système. Pour empêcher Systemd d'envoyer ce message, veuillez exécuter cette commande avec l'option de ligne de commande --no-wall. Exemple : 
systemctl --no-wall poweroff

Utilisation de la commande Shutdown

Pour arrêter le système et mettre la machine hors-tension à une heure précise, veuillez saisir ce qui suit dans une invite de shell en tant qu'utilisateur root : 
shutdown --poweroff hh:mm
avec hh:mm comme l'heure au format militaire (24h). Le fichier /run/nologin est créé 5 minutes avant la fermeture du système pour éviter les nouvelles connexions. Quand un argument de temps est utilisé, un message en option, le wall message, pourra être ajouté à la commande.
Pour arrêter et interrompre le système au bout d'un moment sans mettre la machine hors-tension, veuillez exécuter la commande sous le format suivant en tant qu'utilisateur root : 
shutdown --halt +m
avec +m comme durée en minutes. Le mot clé now est un alias de +0.
Une fermeture à venir pourra être annulée par l'utilisateur root comme suit : 
shutdown -c
Voir la page man de shutdown(8) pour obtenir des options de commandes supplémentaires.

9.4.2. Redémarrer le système

Pour redémarrer le système, exécutez la commande suivante en tant qu'utilisateur root : 
systemctl reboot
Par défaut, cette commande amène Systemd à envoyer un message informatif à tous les utilisateurs actuellement connectés au système. Pour empêcher Systemd d'envoyer ce message, veuillez exécuter cette commande avec l'option de ligne de commande --no-wall : 
systemctl --no-wall reboot

9.4.3. Suspendre le système

Pour suspendre le système, veuillez saisir ce qui suit dans une invite de shell en tant qu'utilisateur root : 
systemctl suspend
Cette commande enregistre l'état du système dans la RAM et, à l'exception du module RAM, met hors-tension la plupart des périphériques dans la machine. Lorsque vous rallumez la machine, le système restaure son état à partir la RAM sans avoir à redémarrer. Comme l'état du système est enregistré dans la RAM et non sur le disque dur, restaurer le système à partir du mode de suspension est bien plus rapide que de le restaurer suite à une hibernation. En revanche, un état de système en suspension est également vulnérable aux pannes d'électricité.
Pour obtenir des informations sur la manière de mettre le système en hibernation, veuillez consulter la Section 9.4.4, « Hiberner le système ».

9.4.4. Hiberner le système

Pour hiberner le système, veuillez saisir ce qui suit dans une invite de shell en tant qu'utilisateur root : 
systemctl hibernate
Cette commande enregistre l'état du système sur le disque dur et met la machine hors-tension. Lorsque vous rallumez la machine, le système restaure son état à partir des données enregistrées sans avoir à démarrer à nouveau. Comme l'état du système est enregistré sur le disque dur et non sur la RAM, la machine n'a pas besoin de maintenir une alimentation électrique sur le module RAM. En revanche, restaurer le système suite à une hibernation est bien plus lent que de le restaurer suite au mode de suspension.
Pour hiberner et suspendre le système, exécutez la commande suivante en tant qu'utilisateur root : 
systemctl hybrid-sleep
Pour obtenir des informations sur la manière de suspendre le système, veuillez consulter la Section 9.4.3, « Suspendre le système ».

9.5. Contrôler systemd sur une machine distante

En plus de contrôler le système systemd et le gestionnaire de services localement, l'utilitaire systemctl permet également d'interagir avec systemd pendant une exécution sur une machine distante à traver le protocole SSH. Si le service sshd est en cours d'exécution sur la machine distante, vous pourrez vous connecter à cette machine en exécutant la commande systemctl avec l'option de ligne de commande --host ou -H : 
systemctl --host user_name@host_name command
Remplacez user_name par le nom de l'utilisateur distant, host_name par le nom d'hôte de la machine, et command par n'importe quelle commande systemctl décrite ci-dessus. Remarquez que la machine distante doit être configurée afin d'autoriser l'accès distant à l'utilisateur sélectionné par le protocole SSH. Pour obtenir davantage d'informations sur la manière de configurer un serveur SSH, veuillez consulter le Chapitre 10, OpenSSH.

Exemple 9.16. Gestion à distance

Pour se connecter à une machine distante nommée server-01.example.com en tant qu'utilisateur root et déterminer le statut actuel de l'unité httpd.service, veuillez saisir ce qui suit dans une invite de shell : 
~]$ systemctl -H root@server-01.example.com status httpd.service
>>>>>>> systemd unit files -- update
root@server-01.example.com's password:
httpd.service - The Apache HTTP Server
   Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled)
   Active: active (running) since Fri 2013-11-01 13:58:56 CET; 2h 48min ago
 Main PID: 649
   Status: "Total requests: 0; Current requests/sec: 0; Current traffic:   0 B/sec"
   CGroup: /system.slice/httpd.service

9.6. Créer et modifier des fichiers d'unité systemd

Un fichier d'unité contient des directives de configuration qui décrivent l'unité et définissent son comportement. Plusieurs commandes systemctl fonctionnent avec des fichiers d'unité dans l'arrière-plan. Pour faire des ajustements plus précis, l'administrateur systèmes doit modifier ou créer des fichiers d'unité manuellement. La Tableau 9.2, « Emplacements des fichiers d'unités systemd » répertorie trois répertoires principaux sur lesquels les fichiers d'unités sont stockés sur le système, le répertoire /etc/systemd/system/ est réservé aux fichiers d'unité créés ou personnalisés par l'administrateur systèmes.
Les noms des fichiers d'unité prennent la forme suivante : 
unit_name.type_extension
Ici, unit_name correspond au nom de l'unité et type_extension identifie le type de l'unité, veuillez consulter la Tableau 9.1, « Types d'unités systemd disponibles » pour afficher la liste complète des types d'unité. Par exemple, une unité sshd.service et une unité sshd.socket sont habituellement présentes sur votre système.
Les fichiers d'unité peuvent être complétés d'un répertoire pour des fichiers de configuration supplémentaires. Par exemple, pour ajouter des options de configuration personnalisées à sshd.service, veuillez créer le fichier sshd.service.d/custom.conf et insérez-y les directives supplémentaires. Pour obtenir davantage d'informations sur les répertoires de configuration, veuillez consulter la Section 9.6.4, « Modifier les fichiers d'unité existants ».
Les répertoires sshd.service.wants/ et sshd.service.requires/ peuvent également être créés. Ces répertoires contiennent des liens symboliques vers les fichiers d'unités qui sont des dépendances du service sshd. Les liens symboliques sont automatiquement créés pendant l'installation selon les options du fichiers de l'unité [Install] (veuillez consulter la Tableau 9.11, « Options importantes de la section [Install] ») ou pendant le temps d'exécution basé sur les options [Unit] (veuillez consulter la Tableau 9.9, « Options importantes de la section [Unit] »). Il est également possible de créer ces répertoires et les liens symboliques manuellement.
De nombreuses options de fichiers d'unité peuvent être définies en utilisant des spécificateurs d'unités – des chaînes de caractères génériques dynamiquement remplacées par des paramètres d'unités lorsque le fichier d'unité est chargé. Ceci permet la création de fichiers d'unité génériques qui serviront de modèle pour générer des unités instanciées. Veuillez consulter la Section 9.6.5, « Travailler avec des unités instanciées » pour obtenir plus de détails.

9.6.1. Comprendre la structure des fichiers d'unité

Les fichiers d'unité consistent habituellement de trois sections :
  • [Unit] — contient des options génériques qui ne sont pas dépendantes du type de l'unité. Ces options fournissent une description de l'unité, spécifient le comportement de l'unité, et définissent les dépendances avec d'autres unités. Pour une liste des options [Unit] les plus fréquemment utilisées, veuillez consulter la Tableau 9.9, « Options importantes de la section [Unit] ».
  • [unit type] — si une unité possède des directives spécifiques au type, celles-ci seront regroupées dans une section nommée par le type d'unité. Par exemple, les fichiers de l'unité de service contiennent la section [Service], veuillez consulter la Tableau 9.10, « Options importantes de la section [Service] » pour voir les options [Service] les plus fréquemment utilisées.
  • [Install] — contient des informations sur l'installation de l'unité utilisée par les commandes systemctl enable et disable, veuillez consulter la Tableau 9.11, « Options importantes de la section [Install] » pour voir une liste des options [Install].

Tableau 9.9. Options importantes de la section [Unit]

Option[a]Description
DescriptionDescription significative de l'unité. En tant qu'exemple, le texte est affiché dans la sortie de la commande systemctl status.
DocumentationFournit une liste des URI référençant la documentation de l'unité.
After[b]Définit l'ordre dans lequel les unités sont lancées. L'unité est lancée uniquement après l'activation des unités spécifiées dans After. Contrairement à Requires, After n'active pas explicitement les unités spécifiées. L'option Before offre une fonctionnalité contraire à After.
RequiresConfigure les dépendances sur d'autres unités. Les unités répertoriées dans Requires sont activées ensembles avec l'unité. Si le lancement de l'une des unités requises échoue, l'unité n'est pas activée.
WantsConfigure les dépendances plus faibles que Requires. Si l'une des unités répertoriées ne démarre pas, cela n'aura pas d'impact sur l'activation de l'unité. C'est la méthode recommandée pour établir des dépendances d'unité personnalisées.
ConflictsConfigure des dépendances négatives, à l'opposé de Requires.
[a] Pour une liste complète des options configurables dans la section [Unit], veuillez consulter la page man de systemd.unit(5).
[b] Dans la plupart des cas, il est suffisant de ne déterminer que les dépendances d'ordonnancement qu'avec les options de fichier After et Before. Si vous définissez aussi une dépendance avec Wants (conseillé) ou Requires, la dépendance d'ordonnancement devra toujours être spécifiée. C'est parce que l'ordonnancement et les exigences de dépendances fonctionnent indépendamment.

Tableau 9.10. Options importantes de la section [Service]

Option[a]Description
TypeConfigure le type de démarrage de processus d'unité qui affecte la fonctionnalité d'ExecStart et des options connexes. L'une des options suivantes :
  • simple – valeur par défaut. Le processus lancé par ExecStart est le processus principal du service.
  • forking – le processus lancé par ExecStart engendre un processus enfant qui devient le processus principal du service. Le processus parent s'arrête lorsque le startup est terminé.
  • oneshot – ce type est similaire à simple, mais le processus s'arrête avant de lancer les unités suivantes.
  • dbus – ce type est similaire à simple, mais les unités suivantes sont lancées uniquement après que le processus principal ait obtenu un nom D-Bus.
  • notify – ce type est similaire à simple, mais les unités suivante sont lancées uniquement après l'envoi d'un message de notification via la fonction sd_notify().
  • idle – similaire à simple, l'exécution du binaire du service est retardée jusqu'à ce que toutes les tâches soient terminées, ce qui permet d'éviter de mélanger la sortie du statut avec la sortie shell des services.
ExecStartSpécifie les commandes ou scripts à exécuter lorsque l'unité est lancée. ExecStartPre et ExecStartPost spécifient des commandes personnalisées à exécuter avant et après ExecStart. Type=oneshot permet de spécifier des commandes multiples personnalisées exécutées de manière séquentielle par la suite.
ExecStopSpécifie les commandes ou scripts à exécuter lorsque l'unité est arrêtée.
ExecReloadSpécifie les commandes ou scripts à exécuter lorsque l'unité est rechargée.
RestartAvec cette option activée, le service est redémarré après que son processus se soit arrêté, à l'exception d'un arrêt gracieux avec la commande systemctl.
RemainAfterExitSi défini sur True, le service est considéré comme actif, même lorsque tous ses processus sont arrêtés. La valeur par défaut est False. Cette option est particulièrement utile si Type=oneshot est configuré.
[a] Pour une liste complète des options configurables dans la section [Service], veuillez consulter la page man de systemd.service(5).

Tableau 9.11. Options importantes de la section [Install]

Option[a]Description
AliasFournit une liste de noms supplémentaires de l'unité séparés par des espaces. La plupart des commandes systemctl, sauf systemctl enable, peuvent utiliser des alias à la place du nom de l'unité.
RequiredByUne liste des unités qui dépendent de l'unité. Lorsque cette unité est activée, les unités répertoriées dans RequiredBy obtiennent une dépendance Require de l'unité.
WantedByUne liste des unités qui dépendent faiblement de l'unité. Lorsque cette unité est activée, les unités répertoriées dans WantedBy obtiennent une dépendance Want de l'unité.
AlsoIndique une liste des unités à installer ou désinstaller avec l'unité.
DefaultInstanceLimitée aux unités instanciées, cette option indique l'instance par défaut pour laquelle l'unité est activée. Veuillez consulter la Section 9.6.5, « Travailler avec des unités instanciées »
[a] Pour voir une liste complète des options configurables dans la section [Install], veuillez consulter la page man de systemd.unit(5).
Une gamme entière d'options qui peuvent être utilisées pour régler de manière détaillée la configuration de l'unité, l'Exemple 9.17, « Fichier d'unité postfix.service » montre un exemple d'unité de service installée sur le système. En outre, les options de fichier d'unité peuvent être définies d'une manière permettant la création dynamique d'unités, comme décrit dans la Section 9.6.5, « Travailler avec des unités instanciées ».

Exemple 9.17. Fichier d'unité postfix.service

Ci-dessous figure le contenu du fichier de l'unité /usr/lib/systemd/system/postifix.service tel qu'il est fourni par le paquet postfix : 
[Unit]
Description=Postfix Mail Transport Agent
After=syslog.target network.target
Conflicts=sendmail.service exim.service

[Service]
Type=forking
PIDFile=/var/spool/postfix/pid/master.pid
EnvironmentFile=-/etc/sysconfig/network
ExecStartPre=-/usr/libexec/postfix/aliasesdb
ExecStartPre=-/usr/libexec/postfix/chroot-update
ExecStart=/usr/sbin/postfix start
ExecReload=/usr/sbin/postfix reload
ExecStop=/usr/sbin/postfix stop

[Install]
WantedBy=multi-user.target
La section [Unit] décrit le service, spécifie les dépendances d'ordre, ainsi que les unités contradictoires. Dans [Service], une séquence de scripts personnalisés est spécifiée pour être exécutée pendant l'activation de l'unité, pendant l'arrêt, et le rechargement. EnvironmentFile désigne l'emplacement où les variables d'environnement du service sont définies, PIDFile spécifie un PID stable pour le processus principale du service. Finalement, la section [Install] répertorie les unités qui dépendent de ce service.

9.6.2. Créer des fichiers d'unité personnalisés

Il existe plusieurs cas dans lesquels il est nécessaire de créer des fichiers d'unité depuis le début : vous pourriez devoir exécuter un démon personnalisé, créer une seconde instance d'un service existant (comme dans l'Exemple 9.19, « Création d'une seconde instance du service sshd »), ou importer un script init SysV (consultez la Section 9.6.3, « Convertir des scripts init SysV en fichiers d'unité »). En revanche, si vous souhaitez simplement modifier ou étendre le comportement d'une unité existante, veuillez utiliser les instructions de la Section 9.6.4, « Modifier les fichiers d'unité existants ». La procédure suivante décrit le processus général de création d'un service personnalisé :
  1. Préparez le fichier exécutable avec le service personnalisé. Il peut s'agir d'un script créé et personnalisé, ou d'un exécutable remis par un fournisseur de logiciels. Si requis, veuillez préparer un fichier PID pour contenir un PID constant pour le processus principal du service personnalisé. Il est également possible d'inclure des fichiers d'environnement pour stocker des variables shell pour le service. Assurez-vous que le script source soit exécutable (en exécutant chmod a+x) et qu'il ne soit pas interactif.
  2. Créez un fichier d'unité dans le répertoire /etc/systemd/system/ et assurez-vous qu'il possède les permissions de fichier correctes. Veuillez exécuter en tant qu'utilisateur root : 
    touch /etc/systemd/system/name.service
chmod 664 /etc/systemd/system/name.service
    Remplacez name par le nom du service à créer. Remarquez que le fichier n'a pas besoin d'être exécutable.
  3. Ouvrez le fichier name.service créé dans l'étape précédente, et ajoutez les options de configuration du service. Une variété d'options peut être utilisée selon le type de service que vous souhaitez créer, consulter Section 9.6.1, « Comprendre la structure des fichiers d'unité ». Voici un exemple de configuration d'unité pour un service concernant le réseau : 
    [Unit]
Description=service_description
After=network.target

[Service]
ExecStart=path_to_executable
Type=forking
PIDFile=path_to_pidfile

[Install]
WantedBy=default.target
    Quand :
    • service_description est une description informative affichée dans les fichiers journaux et dans la sortie de la commande systemctl status.
    • le paramètre After permet de s'assurer que le service est démarré uniquement après l'exécution du réseau. Ajoutez une liste séparée par des espaces d'autres services ou cibles connexes.
    • path_to_executable correspond au chemin vers l'exécutable du service.
    • Type=forking est utilisé pour les démons effectuant l'appel système « fork ». Le processus principal du service est créé avec le PID spécifié dans path_to_pidfile. D'autres types de démarrage se trouvent dans la Tableau 9.10, « Options importantes de la section [Service] ».
    • WantedBy fait état de la cible ou des cibles sous laquelle ou sous lesquelles le service devrait être lancé. Ces cibles peuvent être vues comme remplaçant l'ancien concept des niveaux d'exécution, veuillez consulter la Section 9.3, « Travailler avec des cibles Systemd » pour obtenir des détails supplémentaires.
  4. Notifier systemd qu'un nouveau fichier name.service existe en exécutant la commande suivante en tant qu'utilisateur root : 
    systemctl daemon-reload
systemctl start name.service

    Avertissement

    Exécutez la commande systemctl daemon-reload à chaque fois que vous créez des nouveaux fichiers d'unités ou lorsque vous modifiez des fichiers d'unités existants. Sinon, les commandes systemctl start ou systemctl enable peuvent échouer à cause d'une mauvaise correspondance entre les états de systemd et les fichiers d'unités de service qui se trouvent sur le disque.
    L'unité name.service peut désormais être gérée comme tout autre service système par des commandes décrites dans la Section 9.2, « Gérer les services système ».

Exemple 9.18. Créer le fichier emacs.service

Lors de l'utilisation de l'éditeur de texte Emacs, il est souvent plus rapide et plus pratique de le laisser exécuter en arrière-plan plutôt que de lancer une nouvelle instance du programme à chaque fois qu'un fichier doit être modifié. Les étapes suivantes montrent comment créer un fichier d'unité pour Emacs afin qu'il puisse être géré en tant que service.
  1. Créez un fichier d'unité dans le répertoire /etc/systemd/system/ et assurez-vous qu'il possède les permissions de fichier correctes. Veuillez exécuter en tant qu'utilisateur root : 
    ~]# touch /etc/systemd/system/emacs.service
~]# chmod 664 /etc/systemd/system/emacs.service
  2. Ajouter le contenu suivant au fichier de configuration : 
    [Unit]
Description=Emacs: the extensible, self-documenting text editor
           
[Service]
Type=forking
ExecStart=/usr/bin/emacs --daemon
ExecStop=/usr/bin/emacsclient --eval "(kill-emacs)"
Environment=SSH_AUTH_SOCK=%t/keyring/ssh
Restart=always
           
[Install]
WantedBy=default.target
    Avec la configuration ci-dessus, l'exécutable /usr/bin/emacs est lancé en mode démon pendant le démarrage du service. La variable d'environnement SSH_AUTH_SOCK est paramétrée en utilisant le spécificateur d'unité « %t » qui correspond au répertoire du runtime. Le service redémarre également le processus Emacs s'il s'arrête de manière inattendue.
  3. Veuillez exécuter les commandes suivantes pour recharger la configuration et lancer le service personnalisé : 
    ~]# systemctl daemon-reload
~]# systemctl start emacs.service
Comme l'éditeur est désormais enregistré en tant que service systemd, vous pouvez utiliser toutes les commandes systemctl standard. Ainsi, exécutez systemctl status emacs pour afficher le statut de l'éditeur ou systemctl enable emacs pour le lancer automatiquement pendant le démarrage système.

Exemple 9.19. Création d'une seconde instance du service sshd

Les administrateurs système ont souvent besoin de configurer et d'exécuter de multiples instances d'un service. Ceci est effectué en créant des copies des fichiers de configuration du service d'origine et en modifiant certains paramètres pour éviter les conflits avec l'instance principale du service. La procédure suivante montre comment créer une seconde instance du service sshd :
  1. Veuillez créer une copie du fichier sshd_config qui sera utilisée par le second démon : 
    ~]# cp /etc/ssh/sshd{,-second}_config
  2. Veuillez modifier le fichier sshd-second_config créé dans l'étape précédente pour assigner un numéro de port différent et un fichier PID au second démon : 
    Port 22220
PidFile /var/run/sshd-second.pid
    Veuillez consulter la page man de sshd_config(5) pour obtenir plus d'informations sur les options Port et PidFile. Assurez-vous que le port choisi n'est pas en cours d'utilisation par un autre service. Le fichier PID ne doit pas forcément exister avant l'exécution du service, il est généré automatiquement lors du démarrage du service.
  3. Veuillez créer une copie du fichier d'unité systemd pour le service sshd. 
    ~]# cp /usr/lib/systemd/system/sshd.service /etc/systemd/system/sshd-second.service
  4. Veuillez altérer le fichier sshd-second.service créé pendant l'étape précédente comme suit:
    1. Modifiez l'option Description : 
      Description=OpenSSH server second instance daemon
    2. Veuillez ajouter sshd.service aux services spécifiés dans l'option After, afin que la seconde instance soit lancée uniquement après le lancement de la première : 
      After=syslog.target network.target auditd.service sshd.service
    3. La première instance de sshd inclut la génération de clés, veuillez donc supprimer la ligne ExecStartPre=/usr/sbin/sshd-keygen.
    4. Ajoutez le paramètre -f /etc/ssh/sshd-second_config à la commande sshd afin que le fichier de configuration alternatif soit utilisé : 
      ExecStart=/usr/sbin/sshd -D -f /etc/ssh/sshd-second_config $OPTIONS
    5. Après les modifications indiquées ci-dessus, le fichier sshd-second.service devrait ressembler à ce qui suit : 
      [Unit]
Description=OpenSSH server second instance daemon
After=syslog.target network.target auditd.service sshd.service

[Service]
EnvironmentFile=/etc/sysconfig/sshd
ExecStart=/usr/sbin/sshd -D -f /etc/ssh/sshd-second_config $OPTIONS
ExecReload=/bin/kill -HUP $MAINPID
KillMode=process
Restart=on-failure
RestartSec=42s

[Install]
WantedBy=multi-user.target
  5. Si vous utilisez SELinux, veuillez ajouter le port pour la seconde instance de sshd sur les ports SSH, sinon la seconde instance de sshd sera rejetée pour lier le port : 
    ~]# semanage port -a -t ssh_port_t -p tcp 22220
  6. Veuillez activer sshd-second.service, afin qu'il soit lancé automatiquement pendant le démarrage : 
    ~]# systemctl enable sshd-second.service
    Vérifiez si sshd-second.service est en cours d'utilisation par la commande systemctl status. Veuillez également vérifier si le port est activé correctement en effectuant une connexion au service : 
    ~]$ ssh -p 22220 user@server
    Si le pare-feu est en cours d'utilisation, veuillez vous assurer qu'il soit correctement configuré de manière à permettre des connexions à la seconde instance de sshd.

9.6.3. Convertir des scripts init SysV en fichiers d'unité

Avant de prendre le temps de convertir un script init SysV en fichier d'unité, assurez-vous que la conversion n'a pas déjà été effectuée ailleurs. Tous les services de base installés sur Red Hat Enterprise Linux 7 sont offerts avec des fichiers d'unité par défaut, et la même chose s'applique à de nombreux paquets logiciels de tierce partie.
Convertir un script init en fichier d'unité requiert d'analyser le script et d'en extraire les informations nécessaires. En se basant sur ces données, il est possible de créer un fichier d'unité comme décrit dans la Section 9.6.2, « Créer des fichiers d'unité personnalisés ». Comme les scripts init peuvent largement varier en fonction du type de service, vous pourriez devoir employer davantage d'options de configuration pour la traduction que ce qui est indiqué dans ce chapitre. Veuillez remarquer que certains niveaux de personnalisation qui étaient disponibles avec les scripts init ne sont plus pris en charge par les unités systemd, veuillez consulter la Section 9.1.2, « Changements de compatibilité ».
La majorité des informations nécessaires à une conversion est fournie dans l'en-tête du script. L'exemple suivant montre la section au début du script init utilisée pour lancer le service postfix sur Red Hat Enterprise Linux 6 : 
#!/bin/bash
#
# postfix      Postfix Mail Transfer Agent
#
# chkconfig: 2345 80 30
# description: Postfix is a Mail Transport Agent, which is the program \
#              that moves mail from one machine to another.
# processname: master
# pidfile: /var/spool/postfix/pid/master.pid
# config: /etc/postfix/main.cf
# config: /etc/postfix/master.cf

### BEGIN INIT INFO
# Provides: postfix MTA
# Required-Start: $local_fs $network $remote_fs
# Required-Stop: $local_fs $network $remote_fs
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: start and stop postfix
# Description: Postfix is a Mail Transport Agent, which is the program that 
#              moves mail from one machine to another.
### END INIT INFO
Dans l'exemple ci-dessus, seules les lignes commençant par # chkconfig et # description sont obligatoires, donc vous risquez de ne pas trouver le reste dans des fichiers init différents. Le texte situé entre les lignes ### BEGIN INIT INFO et ### END INIT INFO est appelé un en-tête LSB (« Linux Standard Base »). Si spécifiés, les en-têtes LSB contiennent des directives définissant la description du service, les dépendances, et les niveaux d'exécution. Ce qui suit est un ensemble de tâches analytiques visant à collecter les données nécessaires à un nouveau fichier d'unité. Le script init postfix est utilisé comme exemple. Veuillez consulter le fichier d'unité postfix résultant dans l'Exemple 9.17, « Fichier d'unité postfix.service ».

Trouver la description du service

Vous trouverez des informations descriptives concernant le script sur la ligne commençant par #description. Veuillez utiliser cette description avec le nom du service dans l'option Description de la section [Unit] du fichier d'unité. L'en-tête LSB peut contenir des données similaires sur les lignes #Short-Description et #Description.

Trouver les dépendances de service

L'en-tête LSB peut contenir plusieurs directives qui forment des dépendances entre services. La plupart d'entres elles peuvent être traduites en options d'unité systemd, veuillez consulter la Tableau 9.12, « Options de dépendances d'en-tête LSB »

Tableau 9.12. Options de dépendances d'en-tête LSB

Option LSBDescriptionÉquivalent de fichier d'unité
ProvidesSpécifie le nom de l'installation de démarrage du service, à qui il peut être fait référence dans d'autres scripts init (avec le préfixe « $ »). Ceci n'est plus nécessaire car les fichiers d'unité font référence aux autres unités par leur nom de fichier.–
Required-StartContient les noms des installations de démarrage des services requis. Ceci se traduit par une dépendance d'ordre, les noms d'installations de démarrage sont remplacés par les noms des fichiers d'unité des services correspondants ou les cibles auxquelles ils appartiennent. Par exemple, dans le cas de postfix, la dépendance « Required-Start » sur « $network » a été traduite sur la dépendance « After » sur « network.target ».After, Before
Should-StartConstitue des dépendances plus faibles que Required-Start. Les dépendances Should-Start échouées n'affecteront pas le démarrage du service.After, Before
Required-Stop, Should-StopConstitue des dépendances négatives.Conflicts

Trouver les cibles par défaut du service

La ligne commençant par #chkconfig contient trois valeurs numériques. La plus importante est le premier numéro qui représente les niveaux d'exécution par défaut dans lesquels le service est lancé. Veuillez utiliser la Tableau 9.6, « Comparaison des niveaux d'exécution SysV avec les cibles Systemd » pour faire correspondre ces niveaux d'exécution à leurs cibles systemd équivalentes. Puis, répertoriez ces cibles dans l'option WantedBy de la section [Install] du fichier d'unité. Par exemple, postfix avait auparavant été lancé dans les niveaux d'exécution 2, 3, 4, et 5, qui se traduisent par multi-user.target et graphical.target dans Red Hat Enterprise Linux 7. Veuillez remarquer que graphical.target dépend de multiuser.target, donc il n'est pas nécessaire de spécifier les deux, comme dans l'Exemple 9.17, « Fichier d'unité postfix.service ». Vous trouverez également des informations sur les niveaux d'exécution par défaut et interdits dans les lignes #Default-Start et #Default-Stop de l'en-tête LSB.
Les deux autres valeurs spécifiées sur la ligne #chkconfig représentent les priorités de démarrage et de fermeture du script init. Ces valeurs sont interprétées par systemd si le script init est chargé, mais il n'y a pas de fichier d'unité équivalent.

Trouver les fichiers utilisés par le service

Les scripts init requièrent le chargement d'une bibliothèque de fonction à partir d'un répertoire dédié et autorisent l'importation de configurations, d'environments, et de fichiers PID. Les variables d'environnement sont spécifiées sur la ligne commençant par #config dans l'en-tête du script init, qui se traduit par l'option du fichier d'unité EnvironmentFile. Le fichier PID spécifié sur la ligne du script init #pidfile est importé sur le fichier d'unité avec l'option PIDFile.
L'information-clé qui n'est pas incluse dans l'en-tête du script init est le chemin vers l'exécutable du service, et d'autres fichiers potentiellement requis par le service. Dans des versions précédentes de Red Hat Enterprise Linux, les scripts init utilisaient une déclaration de cas Bash pour définir le sur les actions par défaut, comme start, stop, ou restart, ainsi que des actions définies de manière personnalisées. L'extrait suivant du script init postfix affiche le bloc de code à exécuter lors du lancement du service. 
conf_check() {
    [ -x /usr/sbin/postfix ] || exit 5
    [ -d /etc/postfix ] || exit 6
    [ -d /var/spool/postfix ] || exit 5
}

make_aliasesdb() {
	if [ "$(/usr/sbin/postconf -h alias_database)" == "hash:/etc/aliases" ]
	then
		# /etc/aliases.db might be used by other MTA, make sure nothing
		# has touched it since our last newaliases call
		[ /etc/aliases -nt /etc/aliases.db ] ||
			[ "$ALIASESDB_STAMP" -nt /etc/aliases.db ] ||
			[ "$ALIASESDB_STAMP" -ot /etc/aliases.db ] || return
		/usr/bin/newaliases
		touch -r /etc/aliases.db "$ALIASESDB_STAMP"
	else
		/usr/bin/newaliases
	fi
}

start() {
	[ "$EUID" != "0" ] && exit 4
	# Check that networking is up.
	[ ${NETWORKING} = "no" ] && exit 1
	conf_check
	# Start daemons.
	echo -n $"Starting postfix: "
	make_aliasesdb >/dev/null 2>&1
	[ -x $CHROOT_UPDATE ] && $CHROOT_UPDATE
	/usr/sbin/postfix start 2>/dev/null 1>&2 && success || failure $"$prog start"
	RETVAL=$?
	[ $RETVAL -eq 0 ] && touch $lockfile
        echo
	return $RETVAL
}
L'extensibilité du script initi autorise la spécification de deux fonctions personnalisées, conf_check() et make_aliasesdb(), qui sont appelées à partir du bloc de la fonction start(). En examinant cela de plus près, plusieurs fichiers externes et plusieurs répertoires sont mentionnés dans le code ci-dessus : l'exécutable du service principal, /usr/sbin/postfix, les répertoires de configuration/etc/postfix/ et /var/spool/postfix/, ainsi que le répertoire /usr/sbin/postconf/.
Systemd prend uniquement en charge les actions prédéfinies, mais permet l'exécution d'exécutables personnalisés avec les options ExecStart, ExecStartPre, ExecStartPost, ExecStop, et ExecReload. Dans le cas de postfix dans Red Hat Enterprise Linux 7, /usr/sbin/postfix accompagné de scripts pris en charge sont exécutés pendant le lancement du service. Veuillez consulter le fichier d'unité postfix dans l'Exemple 9.17, « Fichier d'unité postfix.service ».
Convertir des scripts init complexes requiert une bonne compréhension du but de chaque déclaration présente dans le script. Certaines déclarations sont spécifiques à la version du système d'exploitation, vous ne devrez donc pas forcément les traduire. D'autre part, certains ajustements peuvent être nécessaire dans le nouvel environnement, dans le fichier d'unité, ainsi que dans l'exécutable du service et les fichiers de support.

9.6.4. Modifier les fichiers d'unité existants

Les services installés sur le système sont fournis avec des fichiers d'unité par défaut qui sont stockés dans le répertoire /usr/lib/systemd/system/. Les administrateurs systèmes ne doivent pas modifier ces fichiers directement, ainsi toute personnalisation doit être confinée aux fichiers de configuration dans le répertoire /etc/systemd/system/. Veuillez choisir l'une des approches suivantes, en fonction de l'étendue des changements requis :
  • Veuillez créer un répertoire pour les fichiers de configuration supplémentaires dans /etc/systemd/system/unit.d/. Cette méthode est recommandée pour la plupart des cas d'utilisation. Elle permet d'étendre la configuration par défaut avec des fonctionnalités supplémentaires, tout en continuant à faire référence au fichier d'unité d'origine. Les changements apportés à l'unité par défaut qui ont eu lieu lors d'une mise à niveau de paquet(s) sont ainsi appliqués automatiquement. Veuillez consulter la section intitulée « Étendre la configuration de l'unité par défaut » pour obtenir davantage d'informations.
  • Veuillez créer une copie du fichier d'unité d'origine /usr/lib/systemd/system/ dans /etc/systemd/system/ et effectuez-y les changements souhaités. La copie remplace le fichier d'origine, donc les changement introduits par la mise à jour du paquet ne sont pas appliqués. Cette méthode est utile pour effectuer des changements significatifs qui devront être persistants, quelles que soient les mises à jour de paquets se produisant. Veuillez consulter la section intitulée « Remplacer la configuration de l'unité par défaut » pour obtenir des détails.
Pour retourner à la configuration par défaut de l'unité, veuillez supprimer les fichiers de configuration créés de manière personnalisée dans /etc/systemd/system/. Pour appliquer les changements aux fichiers d'unité sans redémarrer le système, veuillez exécuter : 
systemctl daemon-reload
L'option daemon-reload recharge tous les fichiers d'unité et recrée la totalité de l'arbre de dépendances, ce qui est nécessaire pour appliquer immédiatement tout changement sur un fichier d'unité. Alternativement, le même résultat peut être atteint à l'aide de la commande suivante : 
init q
Si le fichier d'unité modifié appartient à un service en cours d'exécution, ce service doit être redémarré pour accepter les nouveaux paramètres : 
systemctl restart name.service

Étendre la configuration de l'unité par défaut

Pour étendre le fichier d'unité par défaut avec des options de configuration supplémentaires, veuillez commencer par créer un répertoire de configuration dans /etc/systemd/system/. Si vous étendez une unité de service, veuillez exécuter la commande suivante en tant qu'utilisateur root : 
mkdir /etc/systemd/system/name.service.d/
Veuillez remplacer name par le nom du service que vous souhaitez étendre. La syntaxe ci-dessus s'applique à tous les types d'unité.
Créez un fichier de configuration dans le répertoire créé lors de l'étape précédente. Remarquez que le nom du fichier doit se terminer par le suffixe .conf. Veuillez saisir : 
touch /etc/systemd/system/name.service.d/config_name.conf
Remplacez config_name par le nom du fichier de configuration. Ce fichier adhère à la structure normale du fichier d'unité, ainsi toutes les directives doivent être spécifiées sous les sections correspondantes. Veuillez consulter la Section 9.6.1, « Comprendre la structure des fichiers d'unité ».
Par exemple, pour ajouter une dépendance personnalisée, veuillez créer un fichier de configuration avec le contenu suivant : 
[Unit]
Requires=new_dependency
After=new_dependency
Où new_dependency correspond à l'unité devant être marquée comme une dépendance. Un autre exemple consiste en un fichier de configuration qui redémarre après que son processus principal se soit arrêté, avec un délai de 30 secondes : 
[Service]
Restart=always
RestartSec=30
Il est recommandé de créer des fichiers de configuration de petite taille se concentrant sur une seule tâche. De tels fichiers peuvent facilement être déplacés ou liés aux répertoires de configuration d'autres services.
Pour appliquer les changements effectués sur l'unité veuillez exécuter la commande suivante en tant que root : 
systemctl daemon-reload
systemctl restart name.service

Exemple 9.20. Étendre la configuration httpd.service

Pour modifier l'unité httpd.service de manière à ce qu'un script shell personnalisé soit automatiquement exécuté lors du lancement du service Apache, veuillez effectuer les étapes suivantes. Pour commencer, veuillez créer un répertoire et un fichier de configuration : 
~]# mkdir /etc/systemd/system/httpd.service.d/
~]# touch /etc/systemd/system/httpd.service.d/custom_script.conf
En supposant que le script que vous souhaitez lancer automatiquement avec Apache se situe dans /usr/local/bin/custom.sh, veuillez insérer le texte suivant dans le fichier custom_script.conf : 
[Service]
ExecStartPost=/usr/local/bin/custom.sh
Pour appliquer les changements d'unité, veuillez exécuter : 
~]# systemctl daemon-reload
~]# systemctl restart httpd.service

Note

Les fichiers de configuration des répertoires de configuration dans /etc/systemd/system/ ont priorité sur les fichiers d'unité dans /usr/lib/systemd/system/. Ainsi, si les fichiers de configuration contiennent une option qui peut être spécifiée une seule fois, comme Description ou ExecStart, la valeur par défaut de cette option sera remplacée. Remarquez que dans la sortie de la commande systemd-delta décrite dans la section intitulée « Surveiller les unités remplacées », de telles unités sont toujours marquées comme [EXTENDED], même si au total, certaines options sont remplacées.

Remplacer la configuration de l'unité par défaut

Pour effectuer des changements qui persisteront après la mise à jour du paquet fournissant le fichier d'unité, veuillez copier le ficher dans le répertoire /etc/systemd/system/. Pour cela, veuillez exécuter la commande suivante en tant qu'utilisateur root : 
cp /usr/lib/systemd/system/name.service /etc/systemd/system/name.service
Quand name correspond au nom de l'unité du service que vous souhaitez modifier, la syntaxe ci-dessus s'applique à tous les types d'unité.
Ouvrez le fichier copié avec un éditeur de texte, et effectuez les changements souhaités. Pour appliquer les changements d'unité, veuillez exécuter ceci en tant qu'utilisateur root : 
systemctl daemon-reload
systemctl restart name.service

Exemple 9.21. Modifier la limite du délai d'attente

Vous pouvez spécifier une valeur de délai d’attente par service pour empêcher un service défectueux de geler le système. Vous pouvez modifier le délai d'attente par défaut à 90 secondes pour les services normaux et à 300 secondes pour les services compatibles SysV. Pour prolonger cette limite, vous pouvez modifier le delai d'expiration par défaut en créant le fichier d'unité systemd /etc/systemd/system/network.service.d/timeout.conf et ajouter une ligne à la nouvelle configuration à ce endroit. La commande systemctl show network -p TimeoutStartUSec affichera le délai d’attente actuel maximum. Après avoir changé la limite à 10 secondes, comme dans l’exemple ci-dessous, pensez à redémarrer systemd avec systemctl daemon-reload pour que les modifications puissent entrer en vigueur : 
~]# systemctl show network -p TimeoutStartUSec
TimeoutStartUSec=5min
~]# mkdir /etc/systemd/system/network.service.d/
~]# echo -e '[Service]\nTimeoutStartSec=10' > /etc/systemd/system/network.service.d/timeout.conf
~]# systemctl daemon-reload
~]# systemctl show network -p TimeoutStartUSec
TimeoutStartUSec=10s

Surveiller les unités remplacées

Pour afficher une vue d'ensemble des fichiers d'unité remplacés ou modifés, veuillez utiliser la commande suivante : 
systemd-delta
Par exemple, la sortie de la commande ci-dessus pourrait ressembler à ce qui suit : 
[EQUIVALENT] /etc/systemd/system/default.target → /usr/lib/systemd/system/default.target
[OVERRIDDEN] /etc/systemd/system/autofs.service → /usr/lib/systemd/system/autofs.service

--- /usr/lib/systemd/system/autofs.service      2014-10-16 21:30:39.000000000 -0400
+++ /etc/systemd/system/autofs.service  2014-11-21 10:00:58.513568275 -0500
@@ -8,7 +8,8 @@
 EnvironmentFile=-/etc/sysconfig/autofs
 ExecStart=/usr/sbin/automount $OPTIONS --pid-file /run/autofs.pid
 ExecReload=/usr/bin/kill -HUP $MAINPID
-TimeoutSec=180
+TimeoutSec=240
+Restart=Always
 
 [Install]
 WantedBy=multi-user.target

[MASKED]     /etc/systemd/system/cups.service → /usr/lib/systemd/system/cups.service
[EXTENDED]   /usr/lib/systemd/system/sssd.service → /etc/systemd/system/sssd.service.d/journal.conf

4 overridden configuration files found.
La Tableau 9.13, « Types de différence systemd-delta » répertorie les types de remplacements qui peuvent apparaître dans la sortie de systemd-delta. Remarquez que si un fichier est remplacé, systemd-delta affiche par défaut un sommaire des changements similaires à la sortie de la commande diff.

Tableau 9.13. Types de différence systemd-delta

TypeDescription
[MASKED]
Fichiers d'unités masqués, veuillez consulter la Section 9.2.7, « Désactiver un service » pour une description du masquage d'unité.
[EQUIVALENT]
Copies non modifiées qui remplacent les fichiers d'origine mais dont le contenu, typiquement les liens symboliques, ne diffère pas.
[REDIRECTED]
Fichiers redirigés vers d'autres fichiers.
[OVERRIDEN]
Fichiers remplacés et modifiés.
[EXTENDED]
Fichiers étendus avec les fichiers .conf dans le répertoire /etc/systemd/system/unit.d/.
[UNCHANGED]
Fichiers non modifiés, uniquement affichés lorsque l'option --type=unchanged est utilisée.
L'exécution de systemd-delta après une mise à jour système pour vérifier si des mises à jour d'unités par défaut sont actuellement remplacées par une configuration personnalisée. Il est également possible de limiter la sortie à un certain type de différence uniquement. Par exemple, pour uniquement afficher les unités remplacées, veuillez exécuter : 
systemd-delta --type=overridden

9.6.5. Travailler avec des unités instanciées

Il est possible d'instancier plusieurs unités à partir d'un seul fichier de configuration modèle pendant le runtime. Le caractère « @ » est utilisé pour marquer le modèle et pour y associer des unités. Les unités instanciées peuvent être lancées à partir d'un autre fichier d'unité (à l'aide des options Requires ou Wants), ou par la commande systemctl start. Les unités de service instanciées sont nommées comme suit. 
template_name@instance_name.service
Quand template_name correspond au nom du fichier de configuration. Veuillez remplacer instance_name par le nom de l'instance de l'unité. Plusieurs instances peuvent pointer vers le même fichier modèle avec des options de configuration communes pour toutes les instances de l'unité. Le nom de l'unité modèle est sous le format suivant : 
unit_name@.service
Par exemple, le paramètre Wants suivant dans un fichier d'unité : 
Wants=getty@ttyA.service,getty@ttyB.service
cela lance avant tout une recherche systemd des unités de service données. Si de telles unités sont introuvables, la partie entre le caractère « @ » et le suffixe du type sera ignorée et systemd recherchera le fichier getty@.service, lira la configuration à partir de celui-ci, et lancera les services.
Les caractères génériques, aussi appelés des spécificateurs d'unité, peuvent être utilisés dans tout fichier de configuration. Les spécificateurs d'unité substituent certains paramètres d'unité et sont interprétés pendant le runtime. La Tableau 9.14, « Spécificateurs d'unités importantes » répertorie des spécificateurs d'unité qui sont particulièrement utiles pour les unités modèles.

Tableau 9.14. Spécificateurs d'unités importantes

Spécificateur d'unitéSignificationDescription
%nNom d'unité completCorrespond au nom d'unité complet, y compris le suffixe du type. %N possède la même signification mais remplace également les caractères interdits avec les codes ASCII.
%pNom du préfixeCorrespond à un nom d'unité avec le suffixe de type supprimé. Pour les unités instanciées, %p correspond à la partie du nom de l'unité avant le caractère « @ ».
%iNom d'instanceIl s'agit de la partie du nom d'unité instanciée entre le caractère « @ » et le suffixe du type. %I possède la même signification mais remplace également les caractères interdits par des codes ASCII.
%HNom d'hôteCorrespond au nom d'hôte du système en cours d'exécution au moment où la configuration de l'unité est chargée.
%tRépertoire du runtimeReprésente le répertoire du runtime, qui est /run pour l'utilisateur root, ou la valeur de la variable XDG_RUNTIME_DIR pour les utilisateur non-privilégiés.
Pour une liste complète des spécificateurs d'unité, veuillez consulter la page man de systemd.unit(5).
Par exemple, le modèle getty@.service contient les directives suivante : 
[Unit]
Description=Getty on %I
...
[Service]
ExecStart=-/sbin/agetty --noclear %I $TERM
...
Lorsque getty@ttyA.service et getty@ttyB.service sont instanciés à partir du modèle ci-dessus, Description= est résolu en tant que Getty on ttyA et Getty on ttyB.

9.7. Ressources supplémentaires

Pour obtenir davantage d'informations sur systemd et son utilisation sur Red Hat Enterprise Linux 7, veuillez consulter les ressources répertoriées ci-dessous.

Documentation installée

  • systemctl(1) — la page du manuel de l'utilitaire de ligne de commande systemctl fournit une liste complète des options et des commandes prises en charge.
  • systemd(1) — la page du manuel du gestionnaire de systèmes et services systemd fournit davantage d'informations sur ses concepts et documente les options de ligne de commande et les variables d'environnement disponibles, les fichiers de configuration et répertoires pris en charge, les signaux reconnus, ainsi que les options de noyau disponibles.
  • systemd-delta(1) — la page du manuel de l'utilitaire systemd-delta qui permet de trouver des fichiers de configuration étendus et remplacés.
  • systemd.unit(5) — la page du manuel nommée systemd.unit fournit des informations détaillées sur les fichiers d'unité systemd et documente toutes les options de configuration disponibles.
  • systemd.service(5) — la page du manuel nommée systemd.service documente le format des fichiers d'unité de service.
  • systemd.target(5) — la page du manuel nommée systemd.target documente le format des fichiers d'unité cibles.
  • systemd.kill(5) — la page du manuel nommée systemd.kill documente la configuration de la procédure de fermeture de processus (« process killing »).

Documentation en ligne

  • Guide de mise en réseau Red Hat Enterprise Linux 7 — le Guide de mise en réseau de Red Hat Enterprise Linux 7 documente les informations pertinentes à la configuration et à l'administration des interfaces réseau et des services réseau sur ce système. Il fournit une introduction à l'utilitaire hostnamectl et explique comment l'utiliser pour afficher et définir des noms d'hôtes sur la ligne de commande localement et à distance, et fournit des informations importantes sur la sélection des noms d'hôte et des noms de domaines
  • Guide de migration et d'administration de bureau Red Hat Enterprise Linux 7 — le Guide de migration et d'administration de bureau de Red Hat Enterprise Linux 7 documente la planification de la migration, le déploiement, la configuration, et l'administration du bureau GNOME 3 sur ce système. Le service logind y est également présenté, ses fonctionnalités les plus importantes sont énumérées, et la manière d'utiliser l'utilitaire loginctl pour répertorier les sessions actives et activer la prise en charge « multi-seat » est expliquée.
  • Guide de l'utilisateur et de l'administrateur SELinux Red Hat Enterprise Linux 7 — le Guide de l'utilisateur et de l'administrateur SELinux Red Hat Enterprise Linux 7 décrit les principes de base de SELinux et documente en détails comment configurer et utiliser SELinux avec divers services, tels que Apache HTTP Server, Postfix, PostgreSQL, ou OpenShift. Celui-ci explique comment configurer les permissions d'accès SELinux pour les services système gérés par systemd.
  • Guide d'installation Red Hat Enterprise Linux 7 — le Guide d'installation de Red Hat Enterprise Linux 7 documente comment installer le système d'exploitation sur des systèmes AMD64 et Intel 64, sur des serveurs IBM Power Systems 64 bits, ainsi que sur IBM System z. Il couvre également des méthodes d'installation avancées telles que les installations Kickstart, PXE, et les installations au moyen du protocole VNC. En outre, ce manuel décrit les tâches post-installation communes et explique comment résoudre les problèmes d'installation, il comprend également des instructions détaillées sur la manière de démarrer en mode de secours ou de récupérer le mot de passe root.
  • Guide de sécurité Red Hat Enterprise Linux 7 — le Guide de sécurité Red Hat Enterprise Linux 7 assiste les utilisateurs et les administrateurs dans leur apprentissage des processus et pratiques de sécurisation de leurs stations de travail et serveurs envers des intrusions locales et distantes, des exploitations, et autres activités malicieuses. Celui-ci explique également comment sécuriser des services de système critiques.
  • Page d'accueil systemd — la page d'accueil du projet fournit davantage d'informations sur systemd.

Voir aussi

  • Le Chapitre 1, Paramètres régionaux et configuration du clavier documente comment gérer les paramètres régionaux du système et les structures du clavier. Il explique également comment utiliser l'utilitaire localectl pour afficher les paramètres régionaux actuels sur la ligne de commande, pour répertorier les paramètres régionaux disponibles, et les définir sur la ligne de commande, ainsi que pour afficher la structure actuelle du clavier, répertorier les dispositions claviers, et activer une disposition clavier particulière sur la ligne de commande.
  • Le Chapitre 2, Configurer l'heure et la date documente comment gérer la date et l'heure du système. Il explique les différences entre une horloge temps réel et une horloge système, et décrit comment utiliser l'utilitaire timedatectl pour afficher les paramètres actuels de l'hologe système, configurer l'heure et la date, changer de fuseau horaires, et pour synchroniser l'horloge système avec un serveur distant.
  • Le Chapitre 5, Obtention de privilèges documente comment obtenir des privilèges administratifs en utilisant les commandes su et sudo.
  • Le Chapitre 10, OpenSSH décrit comment configurer un serveur SSH et comment utiliser les utilitaires client ssh, scp, et sftp pour y accéder.
  • Le Chapitre 20, Afficher et gérer des fichiers journaux fournit une introduction à journald. Il décrit le journal, introduit le service journald, et documente comment utiliser l'utilitaire journalctl pour afficher les entrées de journal, entrer en mode d'affichage en direct, et filtrer les entrées du journal. En outre, ce chapitre décrit comment autoriser les utilisateurs non root d'accéder aux journaux du système et comment activer le stockage persistant des fichiers journaux.

Chapitre 10. OpenSSH

SSH (Secure Shell) est un protocole qui facilite les communications sécurisées entre deux systèmes en utilisant une architecture client-serveur, et qui permet aux utilisateurs de se connecter à des systèmes hôtes de serveur à distance. À la différence d'autres protocoles de communication à distance tels que FTP ou Telnet, SSH codifie la session de connexion, ce qui la rend difficile d'accès aux intrus qui souhaiteraient récupérer les mots de passe.
Le programme ssh est conçu pour remplacer les applications de terminal les plus anciennes et les moins sécurisées qui sont utilisées pour la connexion à des hôtes distants, comme telnet ou rsh. Un programme connexe appelé scp remplace les anciens programmes conçus pour copier des fichiers entre les ordinateurs hôtes, comme rcp. Comme ces applications plus anciennes ne cryptent pas les mots de passe qui sont transmis entre le client et le serveur, évitez-les autant que possible. En utilisant des méthodes sûres pour vous connecter à des systèmes distants, vous diminuez les risques pour le système client et l'hôte distant à la fois.
Red Hat Enterprise Linux comprend le paquet OpenSSH général, openssh, ainsi que les paquets de serveur, openssh-server et des clients, openssh-clients. Noter que les paquets OpenSSH exigent la présence du paquet OpenSSL openssl-libs, qui installe plusieurs bibliothèques cryptographiques importantes, ce qui permet à OpenSSH de fournir des communications cryptées

10.1. Le protocole SSH

10.1.1. Pourquoi utiliser SSH ?

Les intrus potentiels ont une variété d'outils à leur disposition leur permettant de perturber, intercepter et re-router le trafic réseau dans le but d'accéder à un système. En règle générale, ces menaces peuvent être classées ainsi :
Interception de communication entre deux systèmes
L'attaquant peut être quelque part sur le réseau entre les parties communicantes, copiant des informations passées entre elles. Il peut intercepter et maintenir l'information, ou la modifier et l'envoyer à des destinataires designés.
Cette attaque est généralement réalisée à l'aide d'un renifleur de paquets (packet sniffer), un utilitaire de réseau plutôt commun, qui capte chaque paquet qui passe à travers le réseau et qui en analyse le contenu.
Emprunt d’identité d'un hôte particulier
Le système de l'attaquant est configuré pour se poser en tant que destinataire d'une transmission. Si cette stratégie fonctionne, le système de l'utilisateur ne sait pas qu'il communique avec le mauvais hôte.
Cette attaque peut être effectuée par une technique appelée un empoisonnement DNS, ou via ce que l'on appelle une usurpation d'adresse IP. Dans le premier cas, l'intrus utilise un serveur DNS qui aura failli dans le but de pointer les systèmes client à un hôte qui aura été malicieusement dupliqué. Dans le second cas, l'intrus envoie des paquets réseau falsifiés qui semblent provenir d'un hôte de confiance.
Les deux techniques interceptent des informations sensibles potentiellement, et, si l'interception a lieu à des fins hostiles, les résultats peuvent être désastreux. Si SSH est utilisé pour la connexion à un shell distant et pour la copie de fichiers, ces menaces à la sécurité peuvent être grandement diminuées. C'est parce que le client SSH et le serveur utilisent des signatures numériques pour vérifier leur identité. En plus, toutes les communications entre les systèmes client et serveur sont cryptées. Les tentatives d'usurpation l'identité de part et d'autre d'une communication ne fonctionnent pas, puisque chaque paquet est crypté à l'aide d'une clé connue seulement par les systèmes locaux et distants.

10.1.2. Fonctionnalités principales

Le protocole SSH offre les avantages suivants :
Personne ne peut se faire passer pour un serveur intentionnel
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.
Personne ne peut récupérer les données d'authentification
Le client transmet ses données d'authentification au serveur au moyen d'un chiffrement solide de 128 bits.
Personne ne peut intercepter la communication
Toutes les données envoyées et reçues lors d'une session sont transférées au moyen d'un chiffrement 128 bits, rendant ainsi le déchiffrement et la lecture de toute transmission interceptée extrêmement difficile.
De plus, il offre les options suivantes :
Il fournit des moyens sûrs d'utiliser les applications graphiques par l'intermédiaire d'un réseau.
En utilisant une technique appelée X11 forwarding, le client peut envoyer des applications X11 (X Window System) en partance du serveur.
Cela fournit un moyen de sécuriser des protocoles non sécurisés normalement
Le protocole SSH crypte tout ce qu'il envoie et reçoit. En utilisant une technique appelée port forwarding, un serveur SSH peut devenir un moyen de sécuriser des protocoles normalement non protégés, comme POP, tout en augementant la sécurité des données et du système en général.
Il peut être utilisé pour créer un canal sécurisé
Le serveur OpenSSH et le client peuvent être configurés afin de créer un tunnel semblable à un réseau virtuel privé pour permettre le trafic entre le serveur et les machines clientes.
Il prend en charge l'authentification Kerberos
Les clients et serveurs OpenSSH peuvent être configurés pour authentifier par l'interface GSSAPI (Generic Security Services Application Program Interface) du protocole d'authentification du réseau Kerberos.

10.1.3. Versions de protocole

Il existe actuellement deux sorts de SSH : version 1 et version 2 plus récente. La suite OpenSSH sous Red Hat Enterprise Linux utilise SSH la version 2, qui dispose d'un algorithme d'échange de clés amélioré non vulnérable à l'exploitation connue pour la version 1. Toutefois, pour des raisons de compatibilité, la suite OpenSSH prend en charge les connexions de la version 1 également.

Important

Pour assurer un maximum de sécurité au niveau de votre connexion, il est conseillé que seuls les clients et serveurs compatibles avec SSH version 2 soient utilisés si possible.

10.1.4. Séquence d'événements d'une connexion SSH

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.
  1. Une liaison cryptographique est établie afin de permettre au client de vérifier qu'il est bien en communication avec le serveur souhaité.
  2. La couche de transport de la connexion entre le client et tout hôte distant est chiffrée au moyen d'un moyen de chiffrement symétrique.
  3. Le client s'authentifie auprès du serveur.
  4. Le client peut interagir avec l'hôte distant au moyen d'une connexion chiffrée.

10.1.4.1. Couche de transport

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 chiffrement de clés publiques est déterminé
  • L'algorithme de chiffrement symétrique est déterminé
  • L'algorithme d'authentification de message est déterminé
  • L'algorithme de hachage est déterminé
Au cours de l'échange de clés, le serveur s'identifie au client par une clé d'hôte unique. Si le client n'a jamais communiqué avec ce serveur particulier auparavant, la clé du serveur hôte est inconnue au client et il ne se connecte pas. OpenSSH contourne ce problème en acceptant la clé du serveur hôte. Ceci est fait après que l'utilisateur ait été informé et a à la fois accepté et vérifié la nouvelle clé de l'hôte. Dans les connexions suivantes, la clé du serveur hôte est vérifiée par rapport la version enregistrée sur le client, pour s'assurer que le client communique avec le serveur voulu. Si, dans l'avenir, la clé de l'hôte ne correspond plus, l'utilisateur doit supprimer la version du client enregistrée avant qu'une connexion puisse avoir lieu.

Avertissement

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

10.1.4.2. Authentification

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.

10.1.4.3. Canaux

After a successful authentication over the SSH transport layer, multiple channels are opened via a technique called multiplexing[1]. Each of these channels handles communication for different terminal sessions and for forwarded X11 sessions.
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 principale 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.

10.2. Configuration d'OpenSSH

10.2.1. Fichiers de configuration

Il y a deux groupes de fichiers de configuration : pour les programmes clients (c-a-d ssh, scp, et sftp), et pour les serveurs (le démon sshd).
Les informations de configuration de SSH à l'échelle du système sont stockées dans le répertoire /etc/ssh/ comme décrit dans Tableau 10.1, « Fichiers de configuration du système dans son ensemble ». Les informations de configuration spécifiques à l'utilisateur SSH sont stockées dans ~/.ssh/ dans le répertoire d'accueil de l'utilisateur, comme décrit dans Tableau 10.2, « Fichiers de configuration spécifiques à l'utilisateur ».

Tableau 10.1. Fichiers de configuration du système dans son ensemble

FichierDescription
/etc/ssh/moduliContient les groupes Diffie-Hellman utilisés pour l'échange de clés Diffie-Hellman, ce qui est essentiel pour la création d'une couche de transport sécurisé. Lorsque les clés sont échangées au début d'une session SSH, une valeur partagée, secrète est alors créée ne pouvant être déterminée par l'une des parties seule. Cette valeur est ensuite utilisée pour fournir une authentification de l'hôte.
/etc/ssh/ssh_configLe fichier de configuration du client SSH par défaut. Notez qu'il sera remplacé par ~/.ssh/config si ce fichier existe.
/etc/ssh/sshd_configLe fichier de configuration du démon sshd.
/etc/ssh/ssh_host_ecdsa_keyLa clé ECDSA privée utilisée par le démon sshd.
/etc/ssh/ssh_host_ecdsa_key.pubLa clé ECDSA publique utilisée par le démon sshd.
/etc/ssh/ssh_host_keyLa clé privée RSA utilisée par le démon sshd pour la version 1 du protocole SSH.
/etc/ssh/ssh_host_key.pubLa clé publique RSA utilisée par le démon sshd pour la version 1 du protocole SSH.
/etc/ssh/ssh_host_rsa_keyLa clé privée RSA utilisée par le démon sshd pour la version 2 du protocole SSH.
/etc/ssh/ssh_host_rsa_key.pubLa clé publique RSA utilisée par le démon sshd pour la version 2 du protocole SSH.
/etc/pam.d/sshdLe fichier de configuration AM du démon sshd.
/etc/sysconfig/sshdFichier de configuration du service sshd.

Tableau 10.2. Fichiers de configuration spécifiques à l'utilisateur

FichierDescription
~/.ssh/authorized_keysContient une liste des clés publiques autorisées pour les serveurs. Quand le client se connecte à un serveur, le serveur authentifie le client en vérifiant sa clé publique stockée dans ce fichier.
~/.ssh/id_ecdsaContient la clé privée ECDSA de l'utilisateur
~/.ssh/id_ecdsa.pubLe clé publique de l'utilisateur.
~/.ssh/id_rsaLa clé privée RSA utilisée par ssh pour la version 2 du protocole SSH.
~/.ssh/id_rsa.pubLa clé publique RSA utilisée par ssh pour la version 2 du protocole SSH.
~/.ssh/identityLa clé privée RSA utilisée par ssh pour la version 1 du protocole SSH.
~/.ssh/identity.pubLa clé publique RSA utilisée par ssh pour la version 1 du protocole SSH.
~/.ssh/known_hostsContient les clés hôtes des serveurs SSH auquels l'utilisateur a accès. Ce fichier est important pour s'assurer que le client SSH est connecté au bon serveur SSH.
Pour obtenir des informations sur les différentes directives qui peuvent être utilisées par les fichiers de configuration SSH, voir les pages man ssh_config(5) et sshd_config(5).

10.2.2. Démarrage d'un serveur OpenSSH

Pour pouvoir exécuter un serveur OpenSSH, vous devez avoir le paquet openssh-server installé. Pour obtenir plus d'informations sur la façon d'installer des nouveaux paquets, voir Section 8.2.4, « Installation de paquets ».
Pour démarrer le démon sshd dans la session actuelle, veuillez saisir ce qui suit dans l'invite de shell en tant qu'utilisateur root : 
~]# systemctl start sshd.service
Pour stopper le démon sshd dans la session actuelle, veuillez saisir ce qui suit dans l'invite de shell en tant qu'utilisateur root : 
~]# systemctl stop sshd.service
Si vous souhaitez que le démon démarre automatiquement, saisir en tant qu'utilisateur root: 
~]# systemctl enable sshd.service
Created symlink from /etc/systemd/system/multi-user.target.wants/sshd.service to /usr/lib/systemd/system/sshd.service.
Le démon sshd dépend de l’unité cible network.target, ce qui suffit pour les interfaces réseau configuré statique et pour les options par défaut ListenAddress 0.0.0.0. Pour spécifier des adresses différentes dans la directive ListenAddress et utiliser une configuration de réseau dynamique plus lente, ajouter la dépendance sur l’unité cible de network-online.target dans le fichier d'unité de sshd.service. Pour ce faire, créez le fichier /etc/systemd/system/sshd.service.d/local.conf avec les options suivantes : 
  [Unit]
  Wants=network-online.target
  After=network-online.target
Ensuite, charger à nouveau la configuration du gestionnaire systemd par la commande suivante : 
~]# systemctl daemon-reload
Pour obtenir davantage d'informations sur la manière de gérer les services système sur Red Hat Enterprise Linux 7, veuillez consulter le Chapitre 9, Gérer les services avec systemd.
Notez que si vous réinstallez le système, un nouvel ensemble de clés d'identification sera créé. Ainsi, les clients qui étaient connectés au système avec les outils d'OpenSSH avant la réinstallation verront le message suivant s'afficher : 
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
Pour éviter cela, vous pouvez sauvegarder les fichiers qui conviennent à partir du répertoire /etc/ssh/. Voir Tableau 10.1, « Fichiers de configuration du système dans son ensemble » pour une liste complète, et restaurez les fichiers à chaque fois que vous réinstallez le système.

10.2.3. Utilisation nécessaire de SSH pour les connexions à distance

Pour que SSH soit vraiment efficace, les protocoles de connexions non sécurisées sont à proscrire. Sinon, un mot de passe d'utilisateur peut-être protégé par SSH pour une seule session, et ne sera capturé que plus tard avec Telnet. Certains services à désactiver sont telnet, rsh, rlogin et vsftpd.
Pour obtenir davantage d'informations sur la manière de configurer le service vsftpd, voir Section 14.2, « FTP ». Pour savoir comment gérer les services système, consulter Chapitre 9, Gérer les services avec systemd.

10.2.4. Authentification basée clés

Pour améliorer encore davantage la sécurité système, créer des paires de clés SSH et puis exécuter l'authentification basée clés en désactivant l'authentification de mot de passe. Pour ce faire, ouvrez le fichier /etc/ssh/sshd_config dans un éditeur de texte comme vi ou nano et modifiez l'option PasswordAuthentication comme suit : 
PasswordAuthentication no
Si vous travaillez sur un système différent de celui de la nouvelle installation par défaut, vérifiez que PubkeyAuthentication no n'ait pas été défini. Si connecté à distance, ne pas utiliser l'accès console ou out-of-band, il est conseillé de tester le processus de journalisation basé clé avant de désactiver l'authentification de mot de passe.
Pour pouvoir utiliser ssh, scp, ou sftp pour se connecter au serveur à partir d'une machine client, créer une paire de clé d'autorisation en suivant les étapes suivantes. Notez que les clés doivent être créées séparemment pour chaque utilisateur.
Red Hat Enterprise Linux 7 utilise SSH Protocol 2 et les clés RSA par défaut (voir Section 10.1.3, « Versions de protocole » pour plus d'informations).

Important

Si vous complétez les étapes en tant qu'utilisateur root, seul root pourra utiliser les clés.

Note

Si vous réinstallez votre système et que vous souhaitez garder des paires de clés générées auparavant, sauvegarder le répertoire ~/.ssh/. Après avoir réinstallé, recopiez-le sur votre répertoire personnel. Ce processus peut être fait pour tous les utilisateurs sur votre système, y compris l'utilisateur root.

10.2.4.1. Création de paires de clés

Suivez les étapes indiquées ci-dessous afin de créer une paire de clés DSA pour la version 2 du protocole SSH.
  1. La mise à jour d'un paquet est semblable à son installation. Saisir la commande suivante à l'invite du shell : 
    ~]$ ssh-keygen -t rsa
Création de la paire de clés publique/privée.
Saisir le fichier dans lequel sauvegarder la clé (/home/USER/.ssh/id_rsa):
  2. Appuyer sur la touche Entrée pour confirmer le chemin d'accès par défaut , ~/.ssh/id_rsa, pour la clé nouvellement créée.
  3. Saisissez une phrase de passe, et confirmez-là en la saisissant à nouveau quand on vous le demande. Pour des raisons de sécurité, évitez d'utiliser le même mot de passe que celui que vous aurez utilisé quand vous vous êtes connecté à votre compte.
    Après cela, vous verrez un message semblable à celui-ci : 
    Your identification has been saved in /home/USER/.ssh/id_rsa.
Your public key has been saved in /home/USER/.ssh/id_rsa.pub.
The key fingerprint is:
e7:97:c7:e2:0e:f9:0e:fc:c4:d7:cb:e5:31:11:92:14 USER@penguin.example.com
The key's randomart image is:
+--[ RSA 2048]----+
|             E.  |
|            . .  |
|             o . |
|              . .|
|        S .    . |
|         + o o ..|
|          * * +oo|
|           O +..=|
|           o*  o.|
+-----------------+
  4. Par défaut, les permissions du répertoire ~/.ssh/ sont définies à rwx------ ou 700 exprimées en notation octale. Ceci est pour s'assurer que l'utilisateur USER puisse voir les contenus. Si cela est nécessaire, on peut le confirmer par la commande suivante : 
    ~]$ ls -ld ~/.ssh
drwx------. 2 USER USER 54 Nov 25 16:56 /home/USER/.ssh/
  5. Pour copier une clé publique dans une machine distante, lancer la commande dans le format suivant : 
     ssh-copy-id user@hostname
    Cela aura pour effet de copier la clé publique ~/.ssh/id*.pub qui a été modifiée le plus récemment si elle n'a pas encore été installée. Sinon, indiquer le nom du fichier de clés publiques comme suit : 
    ssh-copy-id -i ~/.ssh/id_rsa.pub user@hostname
    Cela aura pour effet de copier le contenu de ~/.ssh/id_rsa.pub dans le fichier ~/.ssh/authorized_keys de la machine sur laquelle vous souhaitez vous connecter. Si le fichier existe déjà, les clés y seront ajoutées.
Suivez les étapes indiquées ci-dessous afin de créer une paire de clés ECDSA pour la version 2 du protocole SSH :
  1. Pour créer une paire de clés ECDSA, saisir la commande suivante à l'invite du shell : 
    ~]$ ssh-keygen -t ecdsa
Créer une paire de clés publique/privée ecdsa.
Saisir le fichier dans lequel vous souhaitez sauvegarder la clé (/home/USER/.ssh/id_ecdsa):
  2. Appuyer sur la touche Entrée pour confirmer le chemin d'accès par défaut , ~/.ssh/id_ecdsa, pour la clé nouvellement créée.
  3. Saisissez une phrase de passe, et confirmez-là en la saisissant à nouveau quand on vous le demande. Pour des raisons de sécurité, évitez d'utiliser le même mot de passe que celui que vous aurez utilisé quand vous vous êtes connecté à votre compte.
    Après cela, vous verrez un message semblable à celui-ci : 
    Votre identification a été sauvegardée dans /home/USER/.ssh/id_ecdsa.
Votre clé publique a été sauvegardée dans /home/USER/.ssh/id_ecdsa.pub.
L'empreinte de la clé est :
fd:1d:ca:10:52:96:21:43:7e:bd:4c:fc:5b:35:6b:63 USER@penguin.example.com
L'image randomart de la clé est :
+--[ECDSA  256]---+
|       .+ +o     |
|       . =.o     |
|        o o +  ..|
|         + + o  +|
|        S o o oE.|
|           + oo+.|
|            + o  |
|                 |
|                 |
+-----------------+
  4. Par défaut, les permissions du répertoire ~/.ssh/ sont définies à rwx------ ou 700 exprimées en notation octale. Ceci est pour s'assurer que l'utilisateur USER puisse voir les contenus. Si cela est nécessaire, on peut le confirmer par la commande suivante : 
    ~]$ ls -ld ~/.ssh
              ~]$ ls -ld ~/.ssh/
drwx------. 2 USER USER 54 Nov 25 16:56 /home/USER/.ssh/
  5. Pour copier une clé publique dans une machine distante, lancer la commande sous le format suivant : 
     ssh-copy-id USER@hostname
    Cela aura pour effet de copier la clé publique ~/.ssh/id*.pub qui a été modifiée le plus récemment si elle n'a pas encore été installée. Sinon, indiquer le nom du fichier de clés publiques comme suit : 
    ssh-copy-id -i ~/.ssh/id_ecdsa.pub USER@hostname
    Cela aura pour effet de copier le contenu de ~/.ssh/id_ecdsa.pub dans le fichier ~/.ssh/authorized_keys de la machine sur laquelle vous souhaitez vous connecter. Si le fichier existe déjà, les clés y seront ajoutées.
Voir Section 10.2.4.2, « Configurer les partages Samba  » pour obtenir des informations sur la façon d'installer votre système afin qu'il se souvienne de la phrase de passe.

Important

La clé privée est à but d'utilisation personelle uniquement, et il est important que vous ne la donniez à personne.

10.2.4.2. Configurer les partages Samba

Pour stocker votre mot de passe afin que vous n'ayiez pas à le saisir à chaque fois que vous vous connectez avec une machine distante, vous pouvez utiliser l'agent d'authentification ssh-agent. Si vous utilisez GNOME, vous pouvez la configurer pour qu'elle vous demande votre mot de passe chaque fois que vous ouvrez une session et pour qu'elle s'en souvienne tout au cours de la session. Sinon, vous pouvez stocker la phrase de passe pour une invite du shell en particulier.
Pour sauvegarder votre phrase de passe pendant votre session GNOME, suivez les étapes suivantes :
  1. Assurez-vous de bien avoir le paquet openssh-askpass installé. Sinon, voir Section 8.2.4, « Installation de paquets » pour obtenir plus d'informations sur la façon d'installer de nouveaux paquets dans Red Hat Enterprise Linux.
  2. Appuyez sur la touche Super pour entrer dans la vue d'ensemble des activités, tapez Startup Applications et appuyez sur Entrée. L'outil Startup Applications Preferences s'affiche. L'onglet contenant une liste de programmes de démarrage disponibles s'affichera par défaut. La touche Super apparait dans une variété de formes, selon le clavier et autre matériel, mais souvent en tant que touche Commande ou Windows, généralement à gauche de la barre d'espace.
    Préférences des applications au démarrage

    Figure 10.1. Préférences des applications au démarrage

  3. Cliquer sur le bouton Add à droite, et saisir /usr/bin/ssh-add dans le champ Command.
    Ajouter une nouvelle application

    Figure 10.2. Ajouter une nouvelle application

  4. Cliquer sur Add et vérifiez que la case qui se trouve à côté de l'élément qui vient d'être ajouté est sélectionnée.
    Activer l'application

    Figure 10.3. Activer l'application

  5. Déconnecter et reconnecter. Une boîte de dialogue apparaîtra pour vous demander de mettre votre phrase de passe. À partir de ce moment, vous ne devriez pas être sollicité de donner un mot de passe par les commandes ssh, scp, ou sftp.
    Saisir une phrase de passe

    Figure 10.4. Saisir une phrase de passe

Afin de sauvegarder votre phrase de passe pour une certaine invite de shell, utilisez la commande suivante : 
~]$ ssh-add
Saisir la phrase de passe pour /home/USER/.ssh/id_rsa :
Notez que lorsque vous vous déconnectez, votre phrase de passe sera oubliée. Vous devez exécuter la commande chaque fois que vous vous connectez à une console virtuelle ou à une fenêtre de terminal.

10.3. Clients OpenSSH

Pour vous connecter à un serveur OpenSSH depuis une machine cliente, vous devez avoir installé le paquet openssh-clients (voir Section 8.2.4, « Installation de paquets » pour plus d'informations sur la façon d'installer de nouveaux paquets dans Red Hat Enterprise Linux).

10.3.1. Comment se servir de l'utilitaire ssh

L'utilitaire ssh vous permet de vous connecter à une machine distante et à y exécuter des commandes à cet endroit. Cela remplace les programmes rlogin, rsh, et telnet.
De même que pour la commande telnet, connectez-vous à une machine distante par la commande suivante : 
ssh hostname
Ainsi, pour vous connecter à une machine distante nommée penguin.example.com, saisir ce qui suit quand on vous y invite : 
~]$ ssh penguin.example.com
Cela vous enregistrera avec le même nom d'utilisateur que vous utilisez sur votre machine locale. Si vous souhaitez spécifier un nom d'utilisateur différent, utilisez une commande de la forme suivante : 
ssh username@hostname
Ainsi, pour vous connecter à penguin.example.com en tant que USER, saisir : 
~]$ ssh USER@penguin.example.com
La première fois que vous initierez une connexion, vous verrez apparaître un message similaire à celui-ci : 
The authenticity of host 'penguin.example.com' can't be established.
ECDSA key fingerprint is 256 da:24:43:0b:2e:c1:3f:a1:84:13:92:01:52:b4:84:ff.
Are you sure you want to continue connecting (yes/no)?
Les utilisateurs doivent toujours vérifier si l'empreinte est correcte avant de répondre à la question dans cette boîte de dialogue. L'utilisateur peut demander à l'administrateur du serveur de bien confirmer que la clé est correcte. Cela devrait être fait de manière sécurisée et préalablement convenue. Si l'utilisateur a accès aux clés d'hôte du serveur, l'empreinte digitale peut être vérifiée à l'aide de la commande ssh-keygen, comme suit : 
~]# ssh-keygen -l -f /etc/ssh/ssh_host_ecdsa_key.pub
256 da:24:43:0b:2e:c1:3f:a1:84:13:92:01:52:b4:84:ff   (ECDSA)
Tapez yes pour accepter la clé et confirmer la connexion. Vous verrez une notice apparaître vous indiquant que le serveur a été ajouté à la liste des hôtes connus et une invite vous demandant votre mot de passe : 
Warning: Permanently added 'penguin.example.com' (ECDSA) to the list of known hosts.
USER@penguin.example.com's password:

Important

Si la clé de l'hôte du serveur SSH change, le client informera l'utilisateur que la connexion ne peut pas avoir lieu tant que la clé du serveur hôte n'est pas supprimée du fichier ~/.ssh/known_hosts. Avant de procéder, cependant, contactez l'administrateur systèmes du serveur SSH pour vérifier que le serveur n'est pas compromis.
Pour supprimer une clé du fichier ~/.ssh/known_hosts, lancez la commande suivante : 
~]# ssh-keygen -R penguin.example.com
# Host penguin.example.com found: line 15 type ECDSA
/home/USER/.ssh/known_hosts updated.
Original contents retained as /home/USER/.ssh/known_hosts.old
Une fois que vous aurez saisi le mot de passe, vous apercevrez une invite de shell pour la machine distante.
Sinon, le programme ssh peut être utilisé pour exécuter une commande sur la machine distante sans qu'il soit nécessaire de vous connecter à une invite de shell : 
ssh [username@]hostname command
Ainsi, le fichier /etc/redhat-release vous donne des informations sur la version Red Hat Enterprise Linux. Pour voir le contenu de ce fichier dans penguin.example.com, saisissez : 
~]$ ssh USER@penguin.example.com cat /etc/redhat-release
USER@penguin.example.com's password:
Red Hat Enterprise Linux Server release 7.0 (Maipo)
Une fois que vous aurez saisi le mot de passe qui convient, le nom d'utilisateur apparaîtra, et vous pourrez retourner à votre invite de shell locale.

10.3.2. rsh

La commande scp peut être utilisée pour transférer des fichers entre des machines à travers une connexion cryptée sécurisée. Le concept ressemble à celui de rcp.
Pour transférer un fichier local dans un système distant, utiliser une commande de la forme suivante : 
scp localfile username@hostname:remotefile
Ainsi, si vous souhaitez transférer taglist.vim vers une machine distante nommée penguin.example.com, saisissez ce qui suit dans l'invite de commande : 
~]$ scp taglist.vim USER@penguin.example.com:.vim/plugin/taglist.vim
USER@penguin.example.com's password:
taglist.vim                                   100%  144KB 144.5KB/s   00:00
Vous pouvez spécifier plusieurs fichiers à la fois. Pour transférer les contenus de .vim/plugin/ dans le même répertoire d'une machine distante penguin.example.com, saisissez la commande suivante : 
~]$ scp .vim/plugin/* USER@penguin.example.com:.vim/plugin/
USER@penguin.example.com's password:
closetag.vim                                  100%   13KB  12.6KB/s   00:00
snippetsEmu.vim                               100%   33KB  33.1KB/s   00:00
taglist.vim                                   100%  144KB 144.5KB/s   00:00
Afin d'autoriser les utilisateurs à créer des fichiers dans le répertoire, utilisez la commande suivante : 
scp username@hostname:remotefile localfile
Ainsi, pour télécharger le fichier de configuration .vimrc d'une machine distante, saisissez : 
~]$ scp USER@penguin.example.com:.vimrc .vimrc
USER@penguin.example.com's password:
.vimrc                                        100% 2233     2.2KB/s   00:00

10.3.3. rsh

L'utilitaire sftp peut être utilisé pour ouvrir une session FTP interactive, sécurisée. Dans le concept, c'est similaire à ftp sauf qu'on utilise une connexion sécurisée, cryptée.
Pour vous connecter à un système distant, utiliser une commande qui ressemble à ce qui suit : 
sftp username@hostname
Ainsi, pour vous connecter à une machine distante nommée penguin.example.com, avec USER comme nom d'utilisateur, saisissez ce qui suit : 
~]$ sftp USER@penguin.example.com
USER@penguin.example.com's password:
Connected to penguin.example.com.
sftp>
Une fois que vous aurez saisi le mot de passe qui convient, vous verrez une invite se présenter. L'utilitaire sftp accepte un ensemble de commandes qui ressemble à celles utilisées avec ftp (voir Tableau 10.3, « Une sélection de commandes sftp disponibles »).

Tableau 10.3. Une sélection de commandes sftp disponibles

CommandeDescription
ls [directory]Lister le contenu du directory (répertoire) distant. S'il n'y en aucun, on utilisera le répertoire de travail en cours par défaut.
cd directoryChanger le répertoire de travail distant à répertoire.
mkdir répertoire--smbservers=<server>
rmdir cheminSupprimer un répertoire distant.
put fichier local [fichier distant]Transférer le fichier local à une machine distante.
get fichier distant [fichier local]Transférer le fichier distant à partir d'une machine distante.
Pour obtenir une liste complète des commandes disponibles, voir la page man de sftp(1).

10.4. Beaucoup plus qu'un shell sécurisé

Une interface sécurisée en ligne de commandes 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. Sinon, 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.

10.4.1. Transfert X11

Pour ouvrir une session X11 sur une connexion SSH, utiliser une commande qui ressemble à ceci : 
ssh -Y nom d'utilisateur@nom d'hôte
Ainsi, pour vous connecter à une machine distante nommée penguin.example.com, avec USER comme nom d'utilisateur, saisissez ce qui suit : 
~]$ ssh -Y USER@penguin.example.com
mot de passe de USER@penguin.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.
Notez que le système X Window doit être installé sur le système distant avant que la transmission X11 puisse avoir lieu. Saisir la commande suivante en tant qu'utilisateur root pour installer le groupe de packages X11 : 
~]# yum group install "X Window System"
Pour obtenir plus d'informations sur les groupes de packages, voir Section 8.3, « Utiliser des groupes de paquets ».
Le transfert X11 peut être très utile. Par exemple, le transfert X11 peut être utilisé pour créer une session interactive, sécurisée de l'utilitaire Print Settings. Pour cela, connectez-vous au serveur en utilisant ssh et saisissez : 
~]$ system-config-printer &
L'outil Print Settings apparaîtra, permettant à l'utilisateur distant de configurer l'impression sur le système distant en toute sécurité.

10.4.2. Réacheminement de port

SSH peut sécuriser les protocoles TCP/IP normalement non sécurisés par le réacheminement de port. Quand vous utilisez cette technique, le serveur SSH fait figure de conduit crypté vers le client SSH.
La redirection de port fonctionne en mappant un port local du client à un port distant sur le serveur. SSH peut mapper n'importe quel port du serveur sur un port de client. Les numéros de port n'ont pas besoin de correspondre pour cette façon de travailler.

Note

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) root.
Pour créer un canal de réacheminement de port TCP/IP qui écoute les connexions sur le localhost, utiliser une commande de la forme suivante : 
ssh -L port-local:nom d'hôte distant:port-distant nom d'utilisateur@nom d'hôte
Ainsi, pour vérifier un email sur un serveur nommé mail.example.com qui utilise POP3 par l'intermédiaire d'une connexion cryptée, utiliser la commande suivante : 
~]$ ssh -L 1100:mail.example.com:110 mail.example.com
Une fois que le canal de réacheminement de port est mis en place entre la machine cliente et le serveur de messagerie, envoyez un mail client POP3 pour utiliser le port 1100 sur le localhost pour vérifier s'il y a de nouveaux messages. Toutes les requêtes envoyées au port 1100 sur le système client seront redirigées en toute sécurité vers le serveur mail.example.com.
Si mail.example.com n'exécute pas sur un serveur SSH, mais qu'une autre machine le fasse sur le même réseau, SSH peut toujours être utilisé pour sécuriser une partie de la connexion. Cependant, il vous faudra une commande légèrement différente : 
~]$ ssh -L 1100:mail.example.com:110 other.example.com
Dans cet exemple, les demandes POP3 du port 1100 de la machine cliente sont transmises via la connexion SSH sur le port 22 au serveur SSH, other.example.com. Ensuite, other.example.com se connectera au port 110 sur mail.exemple.com pour vérifier les nouveaux messages. Notez que lorsque vous utilisez cette technique, seule la connexion entre le système client et le serveur SSH other.example.com est sûre.
Le réacheminement de port peut également être utilisé pour obtenir des informations en toute sécurité à travers les pare-feu de réseau. Si le pare-feu est configuré pour autoriser le trafic SSH via son port standard (c'est-à-dire le port 22) mais bloque l'accès aux autres ports, une connexion entre deux hôtes utilisant les ports bloqués est toujours possible si on réoriente leur communication par une connexion SSH établie.

Important

L'utilisation de la fonctionnalité de réacheminement 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 de système qui s'inquiètent de la fonctionnalité de réacheminement de port peut désactiver cette fonctionnalité sur le serveur en spécifiant un paramètre No sur la ligne AllowTcpForwarding dans /etc/ssh/sshd_config et redémarrer le service sshd.

10.5. Ressources supplémentaires

Pour obtenir davantage d'informations sur la manière de configurer ou de se connecter au serveur OpenSSH sur Red Hat Enterprise Linux, veuillez consulter les ressources ci-dessous :

Documentation installée

  • sshd(8) — la page man des options de ligne de commande de documents de démon sshd disponibles et la liste complète des fichiers et répertoires de configuration pris en charge.
  • ssh(1) — la page man pour l'application client ssh fournit une liste complète des options de ligne de commande disponibles et des fichiers et répertoires de configuration.
  • scp(1) — la page man de l'utilitaire scp fournit une description plus détaillée de cet utilitaire et de son utilisation.
  • sftp(1) — la page man de l'utilitaire sftp.
  • ssh-keygen(1) — la page man de l'utilitaire ssh-keygen documente en détails comment l'utiliser pour générer, gérer, et convertir les clés d'authentification utilisées par ssh.
  • ssh_config(5) — la page man nommée ssh_config documente les options de configuration de client SSH disponibles.
  • sshd_config(5) — la page man nommée sshd_config fournit une description compléte des options de configuration de démon SSH disponibles.

Documentation en ligne

  • OpenSSH Home Page — la page d'accueil d'OpenSSH contient encore davantage de documentations, une foire aux questions, des liens aux listes d'email, des rapports de bogues, et autres informations utiles.
  • OpenSSL Home Page — page d'accueil d'OpenSSL contenant davantage de documentation, une foire aux questions, des liens de listes de diffusion, ainsi que d'autres ressources utiles.

Voir aussi


[1] A multiplexed connection consists of several signals being sent over a shared, common medium. With SSH, different channels are sent over a common secure connection.

Chapitre 11. TigerVNC

TigerVNC (de l'anglais, « Tiger Virtual Network Computing ») est un système pour le partage de bureau graphique vous permettant de contrôler d'autres ordinateurs à distance.
TigerVNC fonctionne sur le principe client-serveur : un serveur partage sa sortie (vncserver) et un client (vncviewer) se connecte au serveur.

Note

Contrairement aux distributions précédentes de Red Hat Enterprise Linux, sur Red Hat Enterprise Linux 7 TigerVNC utilise le démon de gestion de systèmes systemd pour sa configuration. Le fichier de configuration /etc/sysconfig/vncserver a été remplacé par /etc/systemd/system/vncserver@.service.

11.1. Serveur VNC

vncserver est un utilitaire qui lance un bureau VNC (Virtual Network Computing). Il exécute Xvnc avec les options appropriées et lance un gestionnaire de fenêtre sur le bureau VNC. vncserver autorise les utilisateurs à exécuter des sessions séparées en parallèle sur une machine qui peut ensuite être accédée par un nombre illimité de clients, quelle que soit leur origine.

11.1.1. Installer un serveur VNC

Pour installer le serveur TigerVNC, veuillez exécuter la commande suivante en tant qu'utilisateur root : 
~]# yum install tigervnc-server

11.1.2. Configurer un serveur VNC

Le serveur VNC peut être configuré pour lancer un affichage pour un ou plusieurs utilisateurs, à condition que les comptes de ces utilisateurs existent sur le système, avec des paramètres optionnels comme les paramètres d'affichage, l'adresse et le port réseau, et les paramètres de sécurité.

Procédure 11.1. Configurer un affichage VNC pour un utilisateur unique

  1. Un fichier de configuration nommé /etc/systemd/system/vncserver@.service est requis. Pour créer ce fichier, copiez le fichier /usr/lib/systemd/system/vncserver@.service en tant qu'utilisateur root : 
    ~]# cp /usr/lib/systemd/system/vncserver@.service /etc/systemd/system/vncserver@.service
    Il n'est pas nécessaire d'inclure le numéro d'affichage dans le nom du fichier car systemd crée automatiquement l'instance nommée de manière appropriée en mémoire à la demande, en remplaçant '%i' dans le fichier du service par le numéro d'affichage. Pour un utilisateur unique, il n'est pas nécessaire de renommer le fichier. Pour de multiples utilisateurs, un fichier de service nommé de manière unique est requis pour chaque utilisateur, par exemple, en ajoutant le nom d'utilisateur au nom du fichier. Veuillez consulter Section 11.1.2.1, « Configurer un serveur VNC pour deux utilisateurs » pour obtenir plus de détails.
  2. Modifiez /etc/systemd/system/vncserver@.service, en remplaçant USER par le nom de l'utilisateur. Veuillez laisser les lignes restantes du fichier intactes. L'argument -geometry spécifie la taille du bureau VNC à créer. Par défaut, celle-ci est définie sur 1024x768. 
    ExecStart=/usr/sbin/runuser -l USER -c "/usr/bin/vncserver %i -geometry 1280x1024"
PIDFile=/home/USER/.vnc/%H%i.pid
  3. Enregistrez les changements.
  4. Pour que les changements entrent en vigueur immédiatement, veuillez exécuter la commande suivante : 
    ~]# systemctl daemon-reload
  5. Paramétrez le mot de passe de l'utilisateur (ou des utilisateurs) défini(s) dans le fichier de configuration. Remarquez que vous devrez d'abord passer de l'utilisateur root à utilisateur USER. 
    ~]# su - USER
~]$ vncpasswd
Password:
Verify:

    Important

    Le mot de passe stocké n'est pas chiffré, toute personne ayant accès au fichier de mot de passe peut trouver le mot de passe en texte clair.
Procédez avec la Section 11.1.3, « Lancer le serveur VNC ».

11.1.2.1. Configurer un serveur VNC pour deux utilisateurs

Si vous souhaitez configurer plus d'un utilisateur sur la même machine, veuillez créer différents fichiers de service de type modèle, un par utilisateur.
  1. Créez deux fichiers de service, par exemple vncserver-USER_1@.service et vncserver-USER_2@.service. Veuillez substituer USER dans ces deux fichiers par le nom d'utilisateur correct.
  2. Définissez les mots de passe pour les deux utilisateurs : 
    ~]$ su - USER_1
~]$ vncpasswd
Password:
Verify:
~]$ su - USER_2
~]$ vncpasswd
Password:
Verify:

11.1.3. Lancer le serveur VNC

Pour lancer ou activer le service, spécifiez le numéro d'affichage directement dans la commande. Le fichier configuré ci-dessus dans Procédure 11.1, « Configurer un affichage VNC pour un utilisateur unique » sert de modèle, dans lequel %i est remplacé par le numéro d'affichage par systemd. Avec un numéro d'affichage valide, exécutez la commande suivante : 
~]# systemctl start vncserver@:display_number.service
Vous pouvez également autoriser le service à être lancé automatiquement lors du démarrage système. Puis, une fois connecté, vncserver est automatiquement lancé. En tant qu'utilisateur root, veuillez exécuter une commande comme suit : 
~]# systemctl enable vncserver@:display_number.service
À ce moment, d'autres utilisateurs sont en mesure d'utiliser un programme visionneur VNC pour se connecter au serveur VNC en utilisant le numéro d'affichage et le mot de passe défini. À condition qu'un bureau graphique soit installé, une instance de ce bureau sera affichée. Il ne s'agira pas de la même instance que celle qui est actuellement affichée sur la machine cible.

11.1.3.1. Configurer un serveur VNC pour deux utilisateurs et deux affichages différents

Pour les deux serveurs VNC configurés, vncserver-USER_1@.service et vncserver-USER_2@.service, vous pouvez activer différents numéros d'affichage. Par exemple, les commande suivantes amèneront le serveur VNC de l'utilisateur USER_1 à être lancé sur l'affichage 3, et au serveur VNC de l'utilisateur USER_2 à être lancé sur l'affichage 5 : 
~]# systemctl start vncserver-USER_1@:3.service
~]# systemctl start vncserver-USER_2@:5.service

11.1.4. Fermer une session VNC

De même que pour l'activation du service vncserver, il est possible de désactiver le lancement automatique du service pendant le démarrage système : 
~]# systemctl disable vncserver@:display_number.service
Sinon, lorsque votre système est en cours d'utilisation, vous pouvez arrêter le service en exécutant la commande suivante, en tant qu'utilisateur root : 
~]# systemctl stop vncserver@:display_number.service

11.2. Partager un Bureau existant

Dnas une installation normale, un utilisateur se connecte à un ordinateur de bureau fourni par un serveur X avec 0 affiché. Un utilisateur peut partager son ordinateur de bureau par l'intermédiaire du serveur TigerVNC x0vncserver.

Procédure 11.2. Partager un ordinateur de bureau X

Pour partager l'ordinateur de bureau en tant qu'utilisateur connecté, avec x0vncserver, procédez ainsi :
  1. Saisir la commande suivante en tant qu'utilisateur root 
    ~]# yum install tigervnc-server
  2. Voir le mot de passe VNC de l'utilisateur : 
    ~]$ vncpasswd
Password:
Verify:
  3. Exécutez la commande suivante en tant qu'utilisateur : 
    ~]$ x0vncserver -PasswordFile=.vnc/passwd -AlwaysShared=1
Si le parefeu est configuré de façon à atoriser des connexions au port 5900, le visionneur distant peut maintenant se connecter pour afficher 0, et voir le bureau utilisateur connecté. Voir Section 11.3.2.1, « Configurer le pare-feu pour VNC » pour obtenir des informations sur la façon de configurer le parefeu.

11.3. Visionneur VNC

vncviewer est un programme qui affiche les interfaces utilisateur graphique et contrôle vncserver à distance.
Pour opérer vncviewer, il existe un menu contextuel qui contient des entrées permettant d'effectuer diverses actions, comme basculer en et hors du mode plein écran, ou quitter le visionneur. Alternativement, il est possible d'opérer vncviewer via le terminal. Saisissez vncviewer -h sur la ligne de commande pour répertorier les paramètres de vncviewer.

11.3.1. Installer le visionneur VNC Viewer

Pour installer le client TigerVNC vncviewer, veuillez exécuter la commande suivante en tant qu'utilisateur root : 
~]# yum install tigervnc

11.3.2. Connexion au serveur VNC

Une fois que le serveur VNC est configuré, vous pouvez vous y connecter à partir de n'importe quel visionneur VNC.

Procédure 11.3. Connexion à un serveur VNC à l'aide d'une interface utilisateur graphique

  1. Saisissez la commande vncviewer sans le moindre argument, et l'utilitaire VNC Viewer: Connection Details s'affichera. Il demandera alors sur quel serveur VNC la connexion doit être établie.
  2. Si nécessaire, pour empêcher de déconnecter toute connexion VNC sur le même affichage, sélectionnez l'option permettant de partager le bureau, comme suit :
    1. Sélectionnez le bouton Options.
    2. Sélectionnez l'onglet Divers.
    3. Sélectionnez le bouton Partagé.
    4. Appuyez sur Valider pour retourner au menu principal.
  3. Veuillez saisir une adresse et un numéro d'affichage auquel vous connecter : 
    address:display_number
  4. Veuillez appuyer sur Connecter pour vous connecter à l'affichage du serveur VNC.
  5. Il vous sera demandé de saisir le mot de passe VNC. Ce sera le mot de passe VNC pour l'utilisateur correspondant au numéro d'affichage, à moins qu'un mot de passe VNC global par défaut n'ait été paramétré.
    Une fenêtre apparaît affichant le bureau du serveur VNC. Remarquez qu'il ne s'agit pas du bureau qu'un utilisateur normal peut voir, il s'agit d'un bureau Xvnc.

Procédure 11.4. Connexion à un serveur VNC à l'aide de l'interface de ligne de commande

  1. Veuillez saisir la commande viewer avec l'adresse et le numéro d'affichage comme arguments : 
    vncviewer address:display_number
    , où address est une adresse IP ou un nom d'hôte.
  2. Authentifiez-vous en saisissant le mot de passe VNC. Ce sera le mot de passe VNC de l'utilisateur correspondant au numéro d'affichage, à moins qu'un mot de passe VNC global par défaut n'ait été paramétré.
  3. Une fenêtre apparaît affichant le bureau du serveur VNC. Remarquez qu'il ne s'agit pas du bureau qu'un utilisateur normal peut voir, il s'agit du bureau Xvnc.

11.3.2.1. Configurer le pare-feu pour VNC

Lors de l'utilisation d'une connexion non chiffrée, firewalld peut bloquer la connexion. Pour autoriser firewalld à transférer les paquets VNC, vous pouvez ouvrir des ports spécifiques au trafic TCP. Lors de l'utilisation de l'option -via, le trafic est redirigé sur SSH, qui est activé par défaut dans firewalld.

Note

Le port par défaut du serveur VNC est le port 5900. Pour atteindre le port par lequel un bureau distant est accessible, faîtes la somme du port par défaut et du numéro d'affichage assigné à l'utilisateur. Par exemple, pour le second affichage : 2 + 5900 = 5902.
Pour les affichages 0 à 3, utilisez la prise en charge firewalld du service VNC par l'option service comme décrit ci-dessous. Remarquez que pour les numéros d'affichage supérieurs à 3, les ports correspondants devront être spécifiquement ouverts, comme expliqué dans Procédure 11.6, « Ouvrir des ports sur firewalld ».

Procédure 11.5. Activer le service VNC sur firewalld

  1. Veuillez exécuter la commande suivante pour afficher les informations concernant les paramètres firewalld : 
    ~]$ firewall-cmd --list-all
  2. Pour autoriser toutes les connexions VNC en provenance d'une adresse particulière, veuillez utiliser une commande comme suit : 
    ~]# firewall-cmd --add-rich-rule='rule family="ipv4" source address="192.168.122.116" service name=vnc-server accept'
success
    Veuillez noter que ces changements ne persisteront pas lors d'un nouveau démarrage. Pour rendre les changements au parefeu permanents, répétez la commande an ajoutant l'option --permanent. Veuillez consulter le Guide de sécurité Red Hat Enterprise Linux 7 pour obtenir davantage d'informations sur l'utilisation de commandes en langage riche pour pare-feux.
  3. Pour vérifier les paramètres ci-dessus, veuillez utiliser une commande comme suit : 
    ~]# firewall-cmd --list-all
public (default, active)
  interfaces: bond0 bond0.192
  sources:
  services: dhcpv6-client ssh
  ports:
  masquerade: no
  forward-ports:
  icmp-blocks:
  rich rules:
	rule family="ipv4" source address="192.168.122.116" service name="vnc-server" accept
Pour ouvrir un port spécifique ou une gamme de ports, utilisez l'option --add-port sur l'outil de ligne de commande firewall-cmd. Par exemple, l'affichage VNC 4 requiert que le port 5904 soit ouvert au trafic TCP.

Procédure 11.6. Ouvrir des ports sur firewalld

  1. Pour ouvrir un port au trafic TCP dans la zone publique, veuillez exécuter la commande suivante en tant qu'utilisateur root : 
    ~]# firewall-cmd --zone=public --add-port=5904/tcp
success
  2. Pour afficher les ports actuellement ouverts à la zone publique, veuillez exécuter une commande comme suit : 
    ~]# firewall-cmd --zone=public --list-ports
5904/tcp
Un port peut être supprimé en utilisant la commande firewall-cmd --zone=zone --remove-port=number/protocol.
Veuillez noter que ces changements ne persisteront pas lors d'un nouveau démarrage. Pour rendre les changements au parefeu permanents, répétez la commande an ajoutant l'option --permanent. Pour obtenir davantage d'informations sur l'ouverture et la fermeture des ports de firewalld, veuillez consulter le Guide de sécurité Red Hat Enterprise Linux 7 .

11.3.3. Connexion à un serveur VNC à l'aide de SSH

VNC est un protocole réseau en texte clair sans la moindre sécurité contre des attaques possibles sur les communications. Pour rendre ces communications sécurisées, vous pouvez chiffrer votre connexion serveur-client en utilisant l'option -via. Cela créera un tunnel SSH entre le serveur VNC et le client.
Le format de la commande pour chiffrer une connecion serveur-client VNC est comme suit : 
vncviewer -via user@host:display_number

Exemple 11.1. En utilisant l'option -via

  1. Pour se connecter à un serveur VNC en utilisant SSH, veuillez saisir une commande comme suit : 
    ~]$ vncviewer -via USER_2@192.168.2.101:3
  2. Lorsque cela vous est demandé, saisissez le mot de passe, et confirmez en appuyant sur Entrée.
  3. Une fenêtre avec un bureau distant s'affichera sur votre écran.

Restreindre l'accès VNC

Si vous souhaitez uniquement avoir des connexions chiffrées, il est possible d'empêcher les connexions non chiffrées en utilisant l'option -localhost dans le fichier systemd.service, la ligne ExecStart : 
ExecStart=/usr/sbin/runuser -l user -c "/usr/bin/vncserver -localhost %i"
Cela empêchera vncserver d'accepter toute connexion, sauf les connexions de l'hôte local et les connexions transférées par port ayant été envoyées à l'aide de SSH, conséquemment à l'utilisation de l'option -via.
Pour obtenir davantage d'informations sur l'utilisation de SSH, veuillez consulter le Chapitre 10, OpenSSH.

11.4. Ressources supplémentaires

Pour obtenir davantage d'informations sur TigerVNC, veuillez consulter les ressources répertoriées ci-dessous.

Documentation installée

  • vncserver(1) — la page du manuel de l'utilitaire du serveur VNC.
  • vncviewer(1) — la page du manuel du visionneur VNC.
  • vncpasswd(1) — la page du manuel de la commande du mot de passe VNC.
  • Xvnc(1) — la page du manuel des options de configuration du serveur Xvnc.
  • x0vncserver(1) — la page du manuel du serveur TigerVNC pour le partage de serveurs X existants.

Partie V. Serveurs

Cette partie traite des différents sujets liés aux serveurs, comme la manière de paramétrer un serveur web ou de partager des fichiers et répertoires sur un réseau.

Chapitre 12. Serveurs web

Un serveur web est un service réseau qui remet un contenu à un client à travers le web. Habituellement, cela signifie des pages web, mais tout autre document peut également être remis. Les serveurs web sont également appelés des serveurs HTTP , car ils utilisent le protocole de transport hypertexte (HTTP).

12.1. Serveur Apache HTTP

Le serveur web disponible sur Red Hat Enterprise Linux 7 est la version 2.4 du Serveur Apache HTTP, httpd, un serveur web open source développé par la Fondation Apache Software.
Si vous effectuez une mise à niveau à partir d'une version précédente de Red Hat Enterprise Linux, vous devrez mettre à jour la configuration du service httpd. Cette section traite de certaines nouvelles fonctionnalités ajoutées, souligne les changements importants entre les versions 2.2 et 2.4 du serveur Apache HTTP, et vous guide à travers la mise à jour des anciens fichiers de configuration.

12.1.1. Changements notables

Le serveur Apache HTTP sur Red Hat Enterprise Linux 7 propose les changements suivants comparé à Red Hat Enterprise Linux 6 :
Contrôle du service httpd
Avec la migration vers l'extérieur des scripts init SysV, les administrateurs de serveur devront se mettre à utiliser les commandes apachectl et systemctl pour contrôler le service, à la place de la commande service. Les exemples suivants sont spécifiques au service httpd.
La commande : 
service httpd graceful
est remplacée par 
apachectl graceful
. Le fichier unité systemd de httpd a un comportement différent du script init, comme suit :
  • Un redémarrage correct est utilisé par défaut lorsque le service est rechargé.
  • Un arrêt correct est utilisé par défaut lorsque le service est arrêté.
La commande : 
service httpd configtest
est remplacée par 
apachectl configtest
Répertoire /tmp privé
Pour améliorer la sécurité du système, le fichier unité systemd exécute le démon httpd en utilisant un répertoire privé /tmp, séparé du répertoire /tmp du système.
Structure de la configuration
Les fichiers de configuration qui chargent les modules sont désormais placés dans le répertoire /etc/httpd/conf.modules.d/. Les paquets fournissant des modules supplémentaires qui peuvent être chargés pour httpd, comme php, placeront un fichier dans ce répertoire. Une directive Include avant la section principale du fichier /etc/httpd/conf/httpd.conf est utilisée pour inclure les fichiers dans le répertoire /etc/httpd/conf.modules.d/. Cela signifie que tous les fichiers de configuration de conf.modules.d/ sont traités avant le corps principal de httpd.conf. Une directive IncludeOptional pour les fichiers dans le répertoire /etc/httpd/conf.d/ est placée à la fin du fichier httpd.conf. Cela signifie que les fichiers qui se trouvent dans /etc/httpd/conf.d/ sont désormais traités après le corps principal de httpd.conf.
Certains fichiers de configuration supplémentaires sont fournis par le paquet httpd :
  • /etc/httpd/conf.d/autoindex.conf — Permet de configurer l'indexation du répertoire mod_autoindex.
  • /etc/httpd/conf.d/userdir.conf — Permet de configurer l'accès aux répertoires utilisateurs. Par exemple, http://example.com/~username/ ; ce type d'accès est désactivé par défaut pour des raisons de sécurité.
  • /etc/httpd/conf.d/welcome.conf — Tout comme dans les versions précédentes, cela permet de configurer la page d'accueil affichée pour http://localhost/ lorsqu'aucun contenu n'est présent.
Configuration par défaut
Un fichier httpd.conf minimal est désormais fourni par défaut. De nombreux paramètres de configuration courants, comme Timeout ou KeepAlive, ne sont plus explicitement configurés dans la configuration par défaut ; au lieu de ceux-ci, les paramètres codés de manière irréversibles seront utilisés par défaut. Les paramètres codés de manière irréversible par défaut pour toutes les directives de configuration sont spécifiés dans le manuel. Veuillez consulter la section intitulée « Documentation installable » pour obtenir davantage d'informations.
Modifications incompatibles de la syntaxe
Lors de la migration d'une configuration existante de httpd 2.2 à httpd 2.4, un certain nombre de modifications incompatibles en arrière apportées à la syntaxe de la configuration httpd nécessiteront des changements. Veuillez consulter le document Apache suivant pour obtenir davantage d'informations concernant la mise à niveau de http://httpd.apache.org/docs/2.4/upgrading.html
Modèle de traitement
Dans les versions précédentes de Red Hat Enterprise Linux, différents modèles de multiples traitements (« multi-processing models », ou MPM) étaient disponibles aux différents binaires httpd : le modèle fourchu, « prefork », /usr/sbin/httpd ; et le modèle basé sur thread « worker », /usr/sbin/httpd.worker.
Sur Red Hat Enterprise Linux 7, seul un binaire httpd est utilisé, et trois MPM sont disponibles en tant que modules chargeables : « worker », « prefork » (par défaut), et « event ». Veuillez modifier le fichier de configuration /etc/httpd/conf.modules.d/00-mpm.conf comme requis, en ajoutant et supprimant le caractère dièse (#), afin qu'un seul des trois modules MPM soit chargé.
Modifications de paquets
Les modules d'authentification et d'autorisation LDAP sont désormais fournis dans un sous-paquet séparé, mod_ldap. Le nouveau module mod_session et les modules d'aide associés sont fournis dans un nouveau sous-paquet, mod_session. Les nouveaux modules mod_proxy_html et mod_xml2enc sont fournis dans un nouveau sous-paquet, mod_proxy_html. Ces paquets se trouvent tous dans le canal « Optional ».

Note

Avant de vous abonner aux canaux « Optional » et « Supplementary », veuillez consulter les Détails de l'étendue de la couverture. Si vous décidez d'installer des paquets à partir de ces canaux, veuillez suivre les étapes documentées dans l'article nommé Comment accéder aux canaux « Optional » et « Supplementary » et aux paquets -devel en utilisant Red Hat Subscription Manager (RHSM) ? sur le Portail Client Red Hat.
Empaquetage des structures de systèmes de fichiers
Le répertoire /var/cache/mod_proxy/ n'est plus fourni ; à la place, le répertoire /var/cache/httpd/ est empaqueté avec un sous-répertoire proxy et ssl.
Le contenu empaqueté avec httpd a été déplacé de /var/www/ à /usr/share/httpd/ :
  • /usr/share/httpd/icons/ — Le répertoire contenant un ensemble d'icônes avec des indices de répertoire, auparavant contenus dans /var/www/icons/, a été déplacé sur /usr/share/httpd/icons/. Disponible sur http://localhost/icons/ dans la configuration par défaut ; l'emplacement et la disponibilité des icônes est configurable dans le fichier /etc/httpd/conf.d/autoindex.conf.
  • /usr/share/httpd/manual/ — /var/www/manual/ a été déplacé sur /usr/share/httpd/manual/. Ce répertoire, qui fait partie du paquet httpd-manual, contient la version HTML du manuel de httpd. Disponible sur http://localhost/manual/ si le paquet est installé, l'emplacement et la disponibilité du manuel sont configurables dans le fichier /etc/httpd/conf.d/manual.conf.
  • /usr/share/httpd/error/ — /var/www/error/ a été déplacé sur /usr/share/httpd/error/. Pages d'erreurs HTTP de langues multiples personnalisées. Non configuré par défaut, le fichier de configuration exemple est fourni sur /usr/share/doc/httpd-VERSION/httpd-multilang-errordoc.conf.
Authentifications, autorisations et contrôle des accès
Les directives de configuration utilisées pour contrôler l'authentification, les autorisations et le contrôle des accès ont changé de manière significative. Les fichiers de configuration existants qui utilisent les directives Order, Deny et Allow doivent être adaptés afin de pouvoir utiliser la nouvelle syntaxe Require. Veuillez consulter le document Apache suivant pour obtenir davantage d'informations : http://httpd.apache.org/docs/2.4/howto/auth.html
suexec
Pour améliorer la sécurité du système, le binaire suexec n'est plus installé par l'équivalent de l'utilisateur root ; au lieu de cela, il possède une fonctionnalité  «bit Set» dans le système de fichiers, qui limite les restrictions. En conjonction avec ce changement, le binaire suexec n'utilise plus le fichier journal /var/log/httpd/suexec.log. Au lieu de cela, des messages de journalisation sont envoyés sur syslog. Par défaut, ceux-ci apparaîtront dans le fichier journal /var/log/secure.
Interface du module
Des modules binaires de tierce-partie créés avec httpd 2.2 ne sont pas compatibles avec httpd 2.4 à cause de changements apportés à l'interface du module httpd. De tels modules devront être ajustés comme nécessaire pour l'interface du module httpd 2.4, puis recréés. Une liste détaillée des changements d'API dans la version 2.4 sont disponibles ici : http://httpd.apache.org/docs/2.4/developer/new_api_2_4.html.
Le binaire apxs utilisé pour créer des modules source a été déplacé de /usr/sbin/apxs à /usr/bin/apxs.
Modules supprimés
Liste des modules httpd supprimés de Red Hat Enterprise Linux 7 :
mod_auth_mysql, mod_auth_pgsql
httpd 2.4 fournit la prise en charge de l'authentification de bases de données SQL de manière interne dans le module mod_authn_dbd.
mod_perl
mod_perl n'est pas officiellement pris en charge avec httpd 2.4 en amont.
mod_authz_ldap
httpd 2.4 offre la prise en charge LDAP dans le sous-paquet mod_ldap en utilisant mod_authnz_ldap.

12.1.2. Mettre à jour la configuration

Pour mettre à jour les fichiers de configuration à partir de la version 2.2 d'Apache HTTP Server, veuillez effectuer les étapes suivantes :
  1. Comme ils peuvent avoir été modifiés, assurez-vous que tous les noms de modules soient corrects. Ajustez la directive LoadModule pour chaque module dont le nom a changé.
  2. Compilez à nouveau tous les modules de tierce-partie avant de tenter de les charger. Typiquement, cela signifie des modules d'authentification et d'autorisation.
  3. Si vous utilisez le module mod_userdir, assurez-vous que la directive UserDir indiquant un nom de répertoire (habituellement public_html) soit effectivement fournie.
  4. Si vous utilisez Apache HTTP Secure Server, veuillez consulter la Section 12.1.8, « Activer le module mod_ssl » pour obtenir des informations importantes sur l'activation du protocole SSL (« Secure Sockets Layer »).
Remarquez qu'il est possible de vérifier les erreurs possibles de la configuration en utilisant la commande suivante : 
~]# apachectl configtest
Syntax OK
Pour obtenir davantage d'informations sur la mise à niveau de la configuration d'Apache HTTP Server depuis la version 2.2 à la version 2.4, veuillez consulter http://httpd.apache.org/docs/2.4/upgrading.html.

12.1.3. Exécuter le service httpd

Cette section décrit comment lancer, arrêter, redémarrer, et vérifier le statut actuel du serveur Apache HTTP Server. Pour être en mesure d'utiliser le service httpd, assurez-vous que httpd soit effectivement installé. Cela peut être effectué en utilisant la commande suivante : 
~]# yum install httpd
Pour obtenir davantage d'informations sur le concept des cibles et sur la manière de gérer les services système dans Red Hat Enterprise Linux, veuillez consulter le Chapitre 9, Gérer les services avec systemd.

12.1.3.1. Lancer le service

Pour exécuter le service httpd, veuillez saisir ce qui suit à l'invite de shell en tant qu'utilisateur root : 
~]# systemctl start httpd.service
Si vous souhaitez que le service soit automatiquement lancé pendant le démarrage, veuillez utiliser la commande suivante : 
~]# systemctl enable httpd.service
Created symlink from /etc/systemd/system/multi-user.target.wants/httpd.service to /usr/lib/systemd/system/httpd.service.

Note

Si Apache HTTP Server est exécuté en tant que serveur sécurisé, un mot de passe pourrait être requis après le démarrage de la machine si une clé SSL privée chiffrée est utilisée.

12.1.3.2. Arrêter le service

Pour arrêter le service en cours d'exécution httpd, veuillez saisir ce qui suit dans une invite de shell en tant qu'utilisateur root : 
~]# systemctl stop httpd.service
Pour empêcher le service d'être lancé automatiquement pendant le démarrage, veuillez saisir : 
~]# systemctl disable httpd.service
Removed symlink /etc/systemd/system/multi-user.target.wants/httpd.service.

12.1.3.3. Redémarrer le service

Il existe trois différentes manières de redémarrer un service httpd :
  1. Pour redémarrer le système entièrement, exécutez la commande suivante en tant qu'utilisateur root : 
    ~]# systemctl restart httpd.service
    Ceci arrête le service en cours d'exécution httpd et le lance immédiatement après. Veuillez utiliser cette commande après avoir installé ou supprimé un module chargé dynamiquement, comme le module PHP.
  2. Pour uniquement recharger la configuration, veuillez saisir en tant qu'utilisateur root : 
    ~]# systemctl reload httpd.service
    Ceci cause au service en cours d'exécution httpd de recharger son fichier de configuration. Toute requête actuellement en cours de traitement sera interrompue, ce qui pourrait causer à un navigateur client d'afficher un message d'erreur ou d'effectuer un rendu partiel de page.
  3. Pour recharger sa configuration sans affecter de requête active, veuillez saisir la commande suivante en tant qu'utilisateur root : 
    ~]# apachectl graceful
    Ceci cause au service en cours d'exécution httpd de recharger son fichier de configuration. Toute requête actuellement en cours de traitement continuera d'utiliser l'ancienne configuration.
Pour obtenir davantage d'informations sur la manière de gérer les services système sur Red Hat Enterprise Linux 7, veuillez consulter le Chapitre 9, Gérer les services avec systemd.

12.1.3.4. Vérifier le statut du service

Pour vérifier que le service httpdest effectivement en cours d'exécution, veuillez saisir ce qui suit dans l'invite du shell : 
~]# systemctl is-active httpd.service
active

12.1.4. Modifier les fichiers de configuration

Lorsque le service httpd est lancé, par défaut, il lit la configuration à partir d'emplacements répertoriés dans la Tableau 12.1, « Fichiers de configuration du service httpd ».

Tableau 12.1. Fichiers de configuration du service httpd

CheminDescription
/etc/httpd/conf/httpd.conf Fichier de configuration principal.
/etc/httpd/conf.d/ Répertoire auxiliaire pour les fichiers de configuration inclus dans le fichier de configuration principal.
Même si la configuration par défaut est convenable dans la plupart des situations, il est préférable de se familiariser avec certaines des options de configuration plus importantes. Remarquez que pour que tout changement puisse entrer en vigueur, le serveur web doit d'abord être redémarré. Veuillez consulter la Section 12.1.3.3, « Redémarrer le service » pour obtenir davantage d'informations sur la manière de redémarrer le service httpd.
Pour vérifier que la configuration ne contienne pas d'erreurs possibles, veuillez saisir ce qui suit dans une invite de shell : 
~]# apachectl configtest
Syntax OK
Pour faciliter la récupération après des erreurs, il est recommandé d'effectuer une copie du fichier d'origine avant de le modifier.

12.1.5. Utiliser des modules

Étant une application modulaire, le service httpd est distribué avec un certain nombre d'objets partagés dynamiques (« Dynamic Shared Objects », ou DSO), qui peuvent être chargés ou déchargés dynamiquement pendant le runtime, selon les besoins. Dans Red Hat Enterprise Linux 7, ces modules se trouvent dans /usr/lib64/httpd/modules/.

12.1.5.1. Charger un module

Pour charger un module DSO particulier, utilisez la directive LoadModule. Remarquez que les modules fournis par un paquet séparé possèdent souvent leur propre fichier de configuration dans le répertoire /etc/httpd/conf.d/.

Exemple 12.1. Charger mod_ssl DSO

LoadModule ssl_module modules/mod_ssl.so
Une fois que vous aurez terminé, redémarrez le serveur web pour recharger la configuration. Veuillez consulter la Section 12.1.3.3, « Redémarrer le service » pour obtenir davantage d'informations sur la manière de redémarrer le service httpd.

12.1.5.2. Écrire un module

Si vous comptez créer un nouveau module DSO, assurez-vous que le paquet httpd-devel soit installé. Pour faire cela, veuillez saisir la commande suivante en tant qu'utilisateur root : 
~]# yum install httpd-devel
Ce paquet contient les fichiers « include », les fichiers d'en-tête « header », et l'utilitaire APache eXtenSion (apxs) requis pour compiler un module.
Une fois écrit, le module peut être créé par la commande suivante : 
~]# apxs -i -a -c module_name.c
Si le build a été créé avec succès, vous devriez pouvoir charger le module de la même manière que tout autre module distribué avec le serveur Apache HTTP Server.

12.1.6. Paramétrer des hôtes virtuels

L'hébergement virtuel intégré d'Apache HTTP Server permet au serveur de fournir différentes informations basées sur l'adresse IP, le nom d'hôte, ou le port requis.
Pour créer un hôte virtuel basé nom, copiez l'exemple de fichier de configuration /usr/share/doc/httpd-VERSION/httpd-vhosts.conf dans le répertoire /etc/httpd/conf.d/, et remplacez les valeurs d'espaces réservés @@Port@@ et @@ServerRoot@@. Personnalisez les options selon vos besoins, comme affiché dans l'Exemple 12.2, « Exemple de configuration d'hôte virtuel ».

Exemple 12.2. Exemple de configuration d'hôte virtuel

<VirtualHost *:80>
    ServerAdmin webmaster@penguin.example.com
    DocumentRoot "/www/docs/penguin.example.com"
    ServerName penguin.example.com
    ServerAlias www.penguin.example.com
    ErrorLog "/var/log/httpd/dummy-host.example.com-error_log"
    CustomLog "/var/log/httpd/dummy-host.example.com-access_log" common
</VirtualHost>
Remarquez que ServerName doit être un nom DNS valide assigné à la machine. Le conteneur <VirtualHost> est hautement personnalisable, et accepte la plupart des directives disponibles dans la configuration du serveur principal. Les directives qui ne sont pas prises en charge dans ce conteneur incluent User et Group, remplacées par SuexecUserGroup.

Note

Si vous configurez un hôte virtuel pour qu'il écoute sur un port qui n'est pas un port par défaut, assurez-vous de mettre à jour la directive Listen dans la section des paramètres globaux du fichier /etc/httpd/conf/httpd.conf en conséquence.
Pour activer un nouvel hôte virtuel créé, le serveur web doit d'abord être redémarré. Veuillez consulter la Section 12.1.3.3, « Redémarrer le service » pour obtenir davantage d'informations sur la manière de redémarrer le service httpd.

12.1.7. Paramétrer un serveur SSL

Secure Sockets Layer (SSL) est un protocole de chiffrement permettant à un serveur et un client de communiquer de manière sécurisée. Avec sa version étendue et améliorée nommée Transport Layer Security (TLS), confidentialité et intégrité des données sont assurées. Le serveur Apache HTTP Server combiné à mod_ssl, un module qui utilise le kit de ressources OpenSSL pour fournir la prise en charge SSL/TLS, est couramment appelé un serveur SSL. Red Hat Enterprise Linux prend également en charge l'utilisation de Mozilla NSS comme implémentation TLS. La prise en charge de Mozilla NSS est fournie par le module mod_nss.
Contrairement à une connexion HTTP qui pourrait être lue et probablement modifiée par toute personne capable de l'intercepter, l'utilisation de SSL/TLS sur HTTP, également appelée HTTPS, empêche toute inspection ou modification du contenu transmis. Cette section fournit des informations de base sur la manière d'activer ce module dans la configuration du serveur Apache HTTP Server, et vous guide à travers le processus de génération de clés privées et de certificats auto-signés.

12.1.7.1. Vue d'ensemble des certificats et de la sécurité

Les communications sécurisées sont basées sur l'usage de clés. Avec le chiffrement symétrique ou conventionel, les deux côtés de la transaction ont la même clé et peuvent l'utiliser pour décoder les transmissions de l'un ou de l'autre. D'autre part, avec le chiffrement asymétrique ou public, deux clés coexistent : une clé privée qui est gardée secrète, et une clé publique qui est habituellement partagée publiquement. Même si les données sont chiffrées avec la clé publique, elles peuvent uniquement être déchiffrées avec la clé privée, et les données chiffrées avec la clé privée peuvent uniquement être déchiffrées avec la clé publique.
Pour fournir des communications sécurisées en utilisant SSL, un serveur SSL doit utiliser un certificat digital signé par une Autorité de certification (AC). Le certificat répertorie les divers attributs du serveur (c'est-à-dire, le nom d'hôte du serveur, le nom de l'entreprise, son emplacement, etc.), et la signature est produite en utilisant la clé privée de l'autorité de certification. Cette signature assure qu'une autorité de certification particulière a signé le certificat, et que le certificat n'a été modifié d'aucune manière.
Lorsqu'un navigateur web établit une nouvelle connexion SSL, il vérifie le certificat fourni par le serveur web. Si le certificat ne possède pas de signature d'une autorité de certification (AC) de confiance, ou si le nom d'hôte répertorié dans le certificat ne correspond pas au nom d'hôte utilisé pour établir la connexion, il refusera de communiquer avec le serveur et présentera normalement un message d'erreur approprié à l'utilisateur.
Par défaut, la plupart des navigateurs web sont configurés pour faire confiance à un ensemble d'autorités de certification (AC) couramment utilisées. Par conséquent, une AC appropriée devrait être choisie lors du paramétrage d'un serveur sécurisé, afin que les utilisateurs cibles puissent fait confiance à la connexion, sinon ils recevront un message d'erreur et devront accepter le certificat manuellement. Comme encourager des utilisateurs à outrepasser des erreurs de certification peut permettre à une personne malveillante d'intercepter la connexion, une autorité de certification de confiance devrait être utilisée dans la mesure du possible. Pour obtenir davantage d'informations sur cela, veuillez consulter la Tableau 12.2, « Informations sur les listes d'AC utilisées par des navigateurs web communs ».

Tableau 12.2. Informations sur les listes d'AC utilisées par des navigateurs web communs

Navigateur WebLien
Mozilla FirefoxListe d'AC root Mozilla.
OperaInformations sur les certificats root utilisés par Opera.
Internet ExplorerInformations sur les certificats root utilisés par Microsoft Windows.
ChromiumInformations sur les certificats root utilisés par le projet Chromium.
Lors du paramétrage d'un serveur SSL, vous devrez générer une requête de certificat et une clé privée, puis envoyez la requête de certificat, la preuve de l'identité de l'entreprise, et le paiement à l'autorité de certification. Une fois que l'AC aura vérifié la requête du certificat et votre identité, elle vous enverra un certificat signé que vous pourrez utiliser avec votre serveur. Alternativement, il est possible de créer un certificat auto-signé qui ne contient pas de signature d'AC, et qui devrait être uniquement utilisé pour effectuer des tests.

12.1.8. Activer le module mod_ssl

Si vous souhaitez paramétrer un serveur SSL ou HTTPS en utilisant mod_ssl, il n'est pas possible qu'une autre application ou qu'un autre module, comme mod_nss, soit configuré pour utiliser le même port. Le port 443 est le port par défaut pour HTTPS.
Pour paramétrer un serveur SSL en utilisant le module mod_ssl et le kit de ressources OpenSSL toolkit, veuillez installer les paquets mod_ssl et openssl. Saisissez la commande suivante en tant qu'utilisateur root : 
~]# yum install mod_ssl openssl
Cela créera le fichier de configuration mod_ssl sur /etc/httpd/conf.d/ssl.conf, qui est inclus dans le fichier de configuration principal du serveur Apache HTTP Server par défaut. Pour que le module soit chargé, veuillez redémarrer le service httpd comme décrit dans la Section 12.1.3.3, « Redémarrer le service ».

Important

À cause de la vulnérabilité décrite sur POODLE: SSLv3 vulnerability (CVE-2014-3566), Red Hat recommande de désactiver SSL et d'utiliser TLSv1.1 ou TLSv1.2 uniquement. Une rétrocompatibilité peut être effectuée en utilisant TLSv1.0. De nombreux produits pris en charge par Red Hat ont la capacité d'utiliser le protocole SSLv2 ou SSLv3, ou de les activer par défaut. Cependant, l'utilisation de SSLv2 ou de SSLv3 est désormais fortement déconseillée.

12.1.8.1. Activer et désactiver SSL et TLS sur mod_ssl

Pour activer et désactiver des versions particulières des protocoles SSL et TLS, veuillez le faire globalement en ajoutant la directive SSLProtocol dans la section « ## SSL Global Context » du fichier de configuration et en la supprimant partout ailleurs, ou modifiez l'entrée par défaut sous « # SSL Protocol support » dans toutes les sections « VirtualHost ». Si vous ne le spécifiez pas dans la section VirtualHost par domaine, les paramètres hérités proviendront de la section globale. Pour vous assurer qu'une version du protocole est en cours de désactivation, l'administrateur doit uniquement spécifier SSLProtocol dans la section « SSL Global Context », ou bien, le spécifier dans toutes les sections VirtualHost par domaine.

Procédure 12.1. Désactiver SSLv2 et SSLv3

Pour désactiver SSL version 2 et SSL version 3, ce qui implique de tout activer sauf SSL version 2 et SSL version 3 dans toutes les sections VirtualHost, veuillez procéder comme suit :
  1. En tant qu'utilisateur root, ouvrez le fichier /etc/httpd/conf.d/ssl.conf et recherchez toutes les instances de la directive SSLProtocol. Par défaut, le fichier de configuration contient une section qui ressemble à cela : 
    ~]# vi /etc/httpd/conf.d/ssl.conf
#   SSL Protocol support:
# List the enable protocol levels with which clients will be able to
# connect.  Disable SSLv2 access by default:
SSLProtocol all -SSLv2
    Cette section se trouve dans la section VirtualHost.
  2. Modifiez la ligne SSLProtocol comme suit : 
    #   SSL Protocol support:
# List the enable protocol levels with which clients will be able to
# connect.  Disable SSLv2 access by default:
SSLProtocol all -SSLv2 -SSLv3
    Répétez cette action pour toutes les sections VirtualHost. Enregistrez et fermez le fichier.
  3. Vérifiez que toutes les occurrences de la directive SSLProtocol ont été modifiées comme suit : 
    ~]# grep SSLProtocol /etc/httpd/conf.d/ssl.conf
SSLProtocol all -SSLv2 -SSLv3
    Cette étape est particulièrement importante si vous avez plus d'une section VirtualHost par défaut.
  4. Redémarrez le démon Apache comme suit : 
    ~]# systemctl restart httpd
    Remarquez que toutes les sessions seront interrompues.

Procédure 12.2. Désactiver tous les protocoles SSL et TLS sauf TLS 1 et ses versions supérieures

Pour désactiver toutes les versions des protocoles SSL et TLS sauf TLS version 1 et ses versions supérieures, veuillez procéder comme suit :
  1. En tant qu'utilisateur root, ouvrez le fichier /etc/httpd/conf.d/ssl.conf et recherchez toutes les instances de la directive SSLProtocol. Par défaut, le fichier contient une section qui ressemble à cela : 
    ~]# vi /etc/httpd/conf.d/ssl.conf
#   SSL Protocol support:
# List the enable protocol levels with which clients will be able to
# connect.  Disable SSLv2 access by default:
SSLProtocol all -SSLv2
  2. Modifiez la ligne SSLProtocol comme suit : 
    #   SSL Protocol support:
# List the enable protocol levels with which clients will be able to
# connect.  Disable SSLv2 access by default:
SSLProtocol -all +TLSv1 +TLSv1.1 +TLSv1.2
    Enregistrer et fermer le fichier.
  3. Vérifiez le changement comme suit : 
    ~]# grep SSLProtocol /etc/httpd/conf.d/ssl.conf 
SSLProtocol -all +TLSv1 +TLSv1.1 +TLSv1.2
  4. Redémarrez le démon Apache comme suit : 
    ~]# systemctl restart httpd
    Remarquez que toutes les sessions seront interrompues.

Procédure 12.3. Tester le statut des protocoles SSL et TLS

Pour vérifier quelles versions de SSL et TLS sont activées ou désactivées, assurez-vous d'utiliser la commande openssl s_client -connect. La commande se trouve sous le format suivant : 
openssl s_client -connect hostname:port -protocol
, où port correspond au port pour effectuer le test et protocol est la version du protocole à tester. Pour tester le serveur SSL exécuté localement, veuillez utiliser localhost comme nom d'hôte. Par exemple, pour tester le port par défaut pour des connexion HTTPS sécurisées, pour voir si SSLv3 est activé sur le port 443, exécutez la commande suivante : 
  1. ~]# openssl s_client -connect localhost:443 -ssl3
CONNECTED(00000003)
139809943877536:error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure:s3_pkt.c:1257:SSL alert number 40
139809943877536:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:s3_pkt.c:596:sortie omise
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : SSLv3
sortie tronquée
    La sortie ci-dessus indique que la tentative de connexion a échoué et qu'aucun chiffrement n'a été négocié. 
  2. ~]$ openssl s_client -connect localhost:443 -tls1_2
CONNECTED(00000003)
depth=0 C = --, ST = SomeState, L = SomeCity, O = SomeOrganization, OU = SomeOrganizationalUnit, CN = localhost.localdomain, emailAddress = root@localhost.localdomainsortie omise
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1.2sortie tronquée
    La sortie ci-dessus indique qu'aucun échec de tentative de connexion n'a eu lieu et qu'un ensemble de chiffrements a été négocié.
Les options de la commande openssl s_client sont documentées dans la page man de s_client(1).
Pour obtenir davantage d'informations sur la vulnérabilité SSLv3 et comment effectuer des tests pour la trouver, veuillez consulter l'article de la base de connaissances Red Hat POODLE: SSLv3 vulnerability (CVE-2014-3566).

12.1.9. Activer le module mod_nss

Si vous comptez paramétrer un serveur HTTPS en utilisant mod_nss, vous ne pourrez pas avoir le paquet mod_ssl installé avec ses paramètres par défaut car mod_ssl utilisera le port 443 par défaut, cependant ceci est le port HTTPS par défaut. Si possible, veuillez supprimer le paquet.
Pour supprimer mod_ssl, veuillez saisir la commande suivante en tant qu'utilisateur root : 
~]# yum remove mod_ssl

Note

Si mod_ssl est requis à d'autres fins, veuillez modifier le fichier /etc/httpd/conf.d/ssl.conf afin qu'il utilise un autre port que le port 443 pour empêcher que mod_ssl entre en conflit avec mod_nss lorsque son port d'écoute est changé sur le port 443.
Un seul module peut posséder un port, ainsi mod_nss et mod_ssl peuvent uniquement coexister au même moment s'ils utilisent des ports uniques. Pour cette raison, mod_nss utilise par défaut le port 8443, mais le port HTTPS par défaut est le port 443. Le port est spécifié par la directive Listen ainsi que dans le nom ou l'adresse VirtualHost.
Tout dans NSS est associé à un jeton (ou « token »). Un jeton logiciel existe dans la base de données NSS mais vous pouvez également avoir une clé physique contenant des certificats. Avec OpenSSL, des certificats discrets et des clés privées se trouvent dans les fichiers PEM. Avec NSS, ces fichiers sont stockés dans une base de données. Chaque certificat et chaque clé est associé à un jeton, et chaque jeton peut avoir un mot de passe le protégeant. Ce mot de passe est optionnel, mais si un mot de passe est utilisé, alors le serveur HTTP Apache aura besoin d'en avoir une copie afin de pouvoir ouvrir la base de données sans intervention de l'utilisateur pendant le démarrage système.

Procédure 12.4. Configurer mod_nss

  1. Installez mod_nss en tant qu'utilisateur root : 
    ~]# yum install mod_nss
    Cela créera le fichier de configuration mod_nss dans /etc/httpd/conf.d/nss.conf. Le répertoire /etc/httpd/conf.d/ est inclus dans le fichier de configuration principal du serveur Apache HTTP Server par défaut. Pour que le module soit chargé, veuillez redémarrer le service httpd comme décrit dans la Section 12.1.3.3, « Redémarrer le service ».
  2. En tant qu'utilisateur root, ouvrez le fichier /etc/httpd/conf.d/nss.conf et recherchez toutes les instances de la directive Listen.
    Modifiez la ligne Listen 8443 comme suit : 
    Listen 443
    Le port 443 est le port par défaut pour HTTPS.
  3. Modifiez la ligne VirtualHost _default_:8443 par défaut comme suit : 
    VirtualHost _default_:443
    Veuillez modifier toute autre section d'hôte virtuel qui n'est pas par défaut s'il en existe. Puis enregistrez et fermez le fichier.
  4. Mozilla NSS stocke les certificats dans une base de données de certificats de serveur indiquée par la directive NSSCertificateDatabase dans le fichier /etc/httpd/conf.d/nss.conf. Par défaut, le chemin est défini sur /etc/httpd/alias, la base de données NSS créée pendant l'installation.
    Pour afficher la base de données NSS par défaut, veuillez exécuter la commande suivante : 
    ~]# certutil -L -d /etc/httpd/alias

Certificate Nickname                                         Trust Attributes
                                                             SSL,S/MIME,JAR/XPI

cacert                                                       CTu,Cu,Cu
Server-Cert                                                  u,u,u
alpha                                                        u,pu,u
    Dans la sortie de commande ci-dessus, Server-Cert est le NSSNickname par défaut. L'option -L répertorie tous les certificats, ou affiche des informations sur un certificat nommé, dans une base de données de certificats. L'option -d spécifie le répertoire de la base de données contenant le certificat et les fichiers-clés de la base de données. Veuillez consulter la page man certutil(1) pour davantage d'options de ligne de commande.
  5. Pour configurer mod_nss de manière à utiliser une autre base de données, veuillez modifier la ligne NSSCertificateDatabase dans le fichier /etc/httpd/conf.d/nss.conf. Le fichier par défaut possède les lignes suivantes dans la section VirtualHost. 
    #   Server Certificate Database:
#   The NSS security database directory that holds the certificates and
#   keys. The database consists of 3 files: cert8.db, key3.db and secmod.db.
#   Provide the directory that these files exist.
NSSCertificateDatabase /etc/httpd/alias
    Dans la sortie la commande ci-dessus, alias est le répertoire de la base de données NSS par défaut, /etc/httpd/alias/.
  6. Pour appliquer un mot de passe à la base de données des certificats NSS par défaut, veuillez utiliser la commande suivante en tant qu'utilisateur root : 
    ~]# certutil -W -d /etc/httpd/alias
Enter Password or Pin for "NSS Certificate DB":
Enter a password which will be used to encrypt your keys.
The password should be at least 8 characters long,
and should contain at least one non-alphabetic character.

Enter new password:
Re-enter password:
Password changed successfully.
  7. Avant de déployer le serveur HTTPS, veuillez créer une nouvelle base de données de certificats en utilisant un certificat signé par une autorité de certification (AC).

    Exemple 12.3. Ajouter un certificat à la base de données Mozilla NSS

    La commande certutil est utilisée pour ajouter un certificat AC aux fichiers de la base de données NSS : 
    certutil -d /etc/httpd/nss-db-directory/ -A -n "CA_certificate" -t CT,, -a -i certificate.pem
    La commande ci-dessus ajoute un certificat AC stocké dans un fichier au format PEM nommé certificate.pem. L'option -d spécifie le répertoire de la base de données NSS contenant le certificat et les fichiers-clés de la base de données, l'option -n définit un nom pour le certificat, -t CT, signifie que le certificat est approuvé pour être utilisé dans les serveurs et clients TLS. L'option -A ajoute un certificat existant dans une base de données de certificats. Si la base de données n'existe pas, elle sera créée. L'option -a permet l'utilisation du format ASCII pour les entrées ou les sorties et l'option -i transmet le fichier d'entrée certificate.pem à la commande.
    Veuillez consulter la page man de certutil(1) pour obtenir davantage d'options de ligne de commande.
  8. La base de données NSS doit être protégée par un mot de passe afin de garantir la sécurité de la clé privée.

    Exemple 12.4. Définir un mot de passe pour la base de données Mozilla NSS

    L'outil certutil peut être utilisé pour définir un mot de passe pour une base de données NSS comme suit : 
    certutil -W -d /etc/httpd/nss-db-directory/
    Par exemple, pour la base de données par défaut, veuillez exécuter une commande en tant qu'utilisateur root, comme suit : 
    ~]# certutil -W -d /etc/httpd/alias
Enter Password or Pin for "NSS Certificate DB":
Enter a password which will be used to encrypt your keys.
The password should be at least 8 characters long,
and should contain at least one non-alphabetic character.

Enter new password: 
Re-enter password: 
Password changed successfully.
  9. Configurez mod_nss de manière à utiliser le jeton logiciel NSS interne en modifiant la ligne avec la directive NSSPassPhraseDialog, comme suit : 
    ~]# vi /etc/httpd/conf.d/nss.conf
NSSPassPhraseDialog file:/etc/httpd/password.conf
    Ceci sert à éviter la saisie manuelle de mots de passe pendant le démarrage système. Le jeton logiciel existe dans la base de données NSS, mais vous pouvez également posséder une clé physique contenant les certificats.
  10. Si le certificat du serveur SSL situé dans la base de données NSS est un certificat RSA, assurez-vous que le paramètre NSSNickname ne soit pas mis en commentaire et qu'il corresponde bien au nom affiché dans l'étape 4 ci-dessus : 
    ~]# vi /etc/httpd/conf.d/nss.conf
NSSNickname Server-Cert
    Si le certificat du serveur SSL situé dans la base de données NSS est un certificat ECC, assurez-vous que le paramètre NSSECCNickname ne soit pas mis en commentaire et qu'il corresponde bien au surnom affiché dans l'étape 4 ci-dessus : 
    ~]# vi /etc/httpd/conf.d/nss.conf
NSSECCNickname Server-Cert
    Assurez-vous que le paramètre NSSCertificateDatabase ne soit pas mis en commentaire et qu'il pointe vers le répertoire de la base de données NSS affiché dans l'étape 4 ou configuré dans l'étape 5 ci-dessus : 
    ~]# vi /etc/httpd/conf.d/nss.conf
NSSCertificateDatabase /etc/httpd/alias
    Remplacez /etc/httpd/alias par le chemin vers la base de données de certificats à utiliser.
  11. Créez le fichier /etc/httpd/password.conf en tant qu'utilisateur root : 
    ~]# vi /etc/httpd/password.conf
    Ajoutez une ligne sous le format suivant : 
    internal:password
    en remplaçant password par le mot de passe appliqué aux bases de données de sécurité NSS dans l'étape 6 ci-dessus.
  12. Veuillez appliquer l'appartenance et les permissions appopriées au fichier /etc/httpd/password.conf : 
    ~]# chgrp apache /etc/httpd/password.conf
~]# chmod 640 /etc/httpd/password.conf
~]# ls -l /etc/httpd/password.conf
-rw-r-----. 1 root apache 10 Dec  4 17:13 /etc/httpd/password.conf
  13. Pour configurer mod_nss de manière à utiliser le jeton logiciel NSS dans /etc/httpd/password.conf, veuillez modifier /etc/httpd/conf.d/nss.conf comme suit : 
    ~]# vi /etc/httpd/conf.d/nss.conf
  14. Redémarrez le serveur Apache pour que les changements entrent en vigueur, comme décrit dans la Section 12.1.3.3, « Redémarrer le service »

Important

À cause de la vulnérabilité décrite sur POODLE: SSLv3 vulnerability (CVE-2014-3566), Red Hat recommande de désactiver SSL et d'utiliser TLSv1.1 ou TLSv1.2 uniquement. Une rétrocompatibilité peut être effectuée en utilisant TLSv1.0. De nombreux produits pris en charge par Red Hat ont la capacité d'utiliser le protocole SSLv2 ou SSLv3, ou de les activer par défaut. Cependant, l'utilisation de SSLv2 ou de SSLv3 est désormais fortement déconseillée.

12.1.9.1. Activer et désactiver SSL et TLS sur mod_nss

Pour activer et désactiver des versions particulières des protocoles SSL et TLS, veuillez le faire globalement en ajoutant la directive NSSProtocol dans la section « ## SSL Global Context » du fichier de configuration et en la supprimant partout ailleurs, ou modifiez l'entrée par défaut sous « # SSL Protocol » dans toutes les sections « VirtualHost ». Si vous ne le spécifiez pas dans la section VirtualHost par domaine, les paramètres hérités proviendront de la section globale. Pour vous assurer qu'une version du protocole est en cours de désactivation, l'administrateur doit uniquement spécifier NSSProtocol dans la section « SSL Global Context », ou bien dans toutes les sections VirtualHost par domaine.

Procédure 12.5. Désactiver tous les protocoles SSL et TLS sauf TLS 1 et ses versions supérieures dans mod_nss

Pour désactiver toutes les versions des protocoles SSL et TLS sauf TLS version 1 et ses versions supérieures, veuillez procéder comme suit :
  1. En tant qu'utilisateur root, ouvrez le fichier /etc/httpd/conf.d/nss.conf et recherchez toutes les instances de la directive NSSProtocol. Par défaut, le fichier de configuration contient une section qui ressemble à cela : 
    ~]# vi /etc/httpd/conf.d/nss.conf
#   SSL Protocol:sortie omise
#   Since all protocol ranges are completely inclusive, and no protocol in the
#   middle of a range may be excluded, the entry "NSSProtocol SSLv3,TLSv1.1"
#   is identical to the entry "NSSProtocol SSLv3,TLSv1.0,TLSv1.1".
NSSProtocol SSLv3,TLSv1.0,TLSv1.1
    Cette section se trouve dans la section VirtualHost.
  2. Modifiez la ligne NSSProtocol comme suit : 
    #   SSL Protocol:
NSSProtocol TLSv1.0,TLSv1.1
    Répétez cette action pour toutes les sections VirtualHost.
  3. Modifiez la ligne Listen 8443 comme suit : 
    Listen 443
  4. Modifiez la ligne VirtualHost _default_:8443 par défaut comme suit : 
    VirtualHost _default_:443
    Veuillez modifier toute autre section d'hôte virtuel qui n'est pas par défaut s'il en existe. Puis enregistrez et fermez le fichier.
  5. Vérifiez que toutes les occurrences de la directive NSSProtocol ont été modifiées comme suit : 
    ~]# grep NSSProtocol /etc/httpd/conf.d/nss.conf
#   middle of a range may be excluded, the entry "NSSProtocol SSLv3,TLSv1.1"
#   is identical to the entry "NSSProtocol SSLv3,TLSv1.0,TLSv1.1".
NSSProtocol TLSv1.0,TLSv1.1
    Cette étape est particulièrement importante si vous possédez plus d'une section VirtualHost.
  6. Redémarrez le démon Apache comme suit : 
    ~]# service httpd restart
    Remarquez que toutes les sessions seront interrompues.

Procédure 12.6. Tester le statut des protocoles SSL et TLS dans mod_nss

Pour vérifier quelles versions de SSL et TLS sont activées ou désactivées dans mod_nss, veuillez utiliser la commande openssl s_client -connect. Installez le paquet openssl en tant qu'utilisateur root : 
~]# yum install openssl
La commande openssl s_client -connect se trouve sous le format suivant : 
openssl s_client -connect hostname:port -protocol
, où port correspond au port pour effectuer le test et protocol est la version du protocole à tester. Pour tester le serveur SSL exécuté localement, veuillez utiliser localhost comme nom d'hôte. Par exemple, pour tester le port par défaut pour des connexions HTTPS sécurisées, pour voir si SSLv3 est activé sur le port 443, exécutez la commande suivante : 
  1. ~]# openssl s_client -connect localhost:443 -ssl3
CONNECTED(00000003)
3077773036:error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number:s3_pkt.c:337:sortie omise
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : SSLv3
sortie tronquée
    La sortie ci-dessus indique que la tentative de connexion a échoué et qu'aucun chiffrement n'a été négocié. 
  2. ~]$ openssl s_client -connect localhost:443 -tls1
CONNECTED(00000003)
depth=1 C = US, O = example.com, CN = Certificate Shacksortie omise
New, TLSv1/SSLv3, Cipher is AES128-SHA
Server public key is 1024 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1sortie tronquée
    La sortie ci-dessus indique qu'aucun échec de tentative de connexion n'a eu lieu et qu'un ensemble de chiffrements a été négocié.
Les options de la commande openssl s_client sont documentées dans la page man de s_client(1).
Pour obtenir davantage d'informations sur la vulnérabilité SSLv3 et comment effectuer des tests pour la trouver, veuillez consulter l'article de la base de connaissances Red Hat POODLE: SSLv3 vulnerability (CVE-2014-3566).

12.1.10. Utiliser une clé existante et un certificat

Si vous avez créé au préalable une clé et un certificat, vous pouvez configurer le serveur SSL pour utiliser ces fichiers au lieu d'en générer de nouveaux. Il existe uniquement deux situations dans lesquelles cela n'est pas possible :
  1. Vous modifiez l'adresse IP ou le nom du domaine.
    Des certificats sont créés pour une paire adresse IP et nom de domaine particuliers. Si l'une de ces valeurs change, le certificat est invalide.
  2. Vous avez un certificat de VeriSign, et vous changez le logiciel du serveur.
    VeriSign, une autorité de certification largement utilisée, octroit des certificats pour un produit logiciel, une adresse IP, et un nom de domaine particulier. Modifier le produit logiciel rend le certificat invalide.
Dans les deux cas ci-dessus, vous devrez obtenir un nouveau certificat. Pour obtenir davantage d'informations sur ce sujet, veuillez consulter la Section 12.1.11, « Générer une nouvelle clé et un nouveau certificat ».
Si vous souhaitez utiliser une clé et un certificat existants, déplacez les fichiers correspondants sur les répertoires /etc/pki/tls/private/ et /etc/pki/tls/certs/, respectivement. Vous pouvez faire cela exécutant les commandes suivantes en tant qu'utilisateur root : 
~]# mv key_file.key /etc/pki/tls/private/hostname.key
~]# mv certificate.crt /etc/pki/tls/certs/hostname.crt
Puis ajoutez les lignes suivante au fichier de configuration /etc/httpd/conf.d/ssl.conf : 
SSLCertificateFile /etc/pki/tls/certs/hostname.crt
SSLCertificateKeyFile /etc/pki/tls/private/hostname.key
Pour charger la configuration mise à jour, redémarrez le service httpd comme décrit dans la Section 12.1.3.3, « Redémarrer le service ».

Exemple 12.5. Utiliser une clé et un certificat du serveur web sécurisé « Red Hat Secure Web Server »

~]# mv /etc/httpd/conf/httpsd.key /etc/pki/tls/private/penguin.example.com.key
~]# mv /etc/httpd/conf/httpsd.crt /etc/pki/tls/certs/penguin.example.com.crt

12.1.11. Générer une nouvelle clé et un nouveau certificat

Pour générer une nouvelle paire clé-certificat, le paquet crypto-utils doit être installé sur le système. Pour l'installer, veuillez saisir la commande suivante en tant qu'utilisateur root : 
~]# yum install crypto-utils
Ce paquet fournit un ensemble d'outils pour générer et gérer des certificats SSL et des clés privées, et inclut genkey, l'utilitaire de génération de paires de clés « Red Hat Keypair Generation », qui vous guidera à travers le processus de génération de clés.

Important

Si le serveur possède déjà un certificat valide et que vous le remplacez par un nouveau certificat, veuillez spécifier un numéro de série différent. Ceci permet de vous assurer que les navigateurs clients soient notifiés de ce changement, mis à jour au sujet de ce nouveau certificat comme prévu, et qu'ils réussissent à accéder à la page. Pour créer un nouveau certificat avec un numéro de série personnalisé, en tant qu'utilisateur root, veuillez utiliser la commande suivante au lieu de genkey : 
~]# openssl req -x509 -new -set_serial number -key hostname.key -out hostname.crt

Note

S'il existe déjà un fichier clé pour un nom d'hôte particulier dans votre système, genkey refusera de démarrer. Dans ce cas, veuillez supprimer le fichier existant en utilisant la commande suivante en tant qu'utilisateur root : 
~]# rm /etc/pki/tls/private/hostname.key
Pour exécuter l'utilitaire, veuillez saisir la commande genkey en tant qu'utilisateur root, suivie du nom d'hôte approprié (par exemple, penguin.example.com) : 
~]# genkey hostname
Pour terminer la création de la clé et du certificat, veuillez procéder aux étapes suivantes :
  1. Examinez les emplacements cibles dans lesquels la clé et le certificat seront stockés.
    Exécuter l'utilitaire genkey

    Figure 12.1. Exécuter l'utilitaire genkey

    Veuillez utiliser la touche Tab pour sélectionner le bouton Suivant, et appuyez sur Entrée pour passer à l'écran suivant.
  2. En utilisant les touches de flèches haut et bas, sélectionnez une taille de clé convenable. Remarquez que malgré qu'une clé de plus grande taille améliore la sécurité, celle-ci augmentera également le temps de réponse de votre serveur. L'organisme NIST recommande d'utiliser 2048 bits. Veuillez consulter le document NIST Special Publication 800-131A.
    Sélectionner la taille de la clé

    Figure 12.2. Sélectionner la taille de la clé

    Une fois terminé, veuillez utiliser la touche Tab pour sélectionner le bouton Suivant, et appuyez sur Entrée pour initier le processus de génération de bits aléatoire. Selon la taille de clé sélectionnée, ceci peut prendre longtemps.
  3. Décidez si vous souhaitez envoyer une requête de certificat à une autorité de certification.
    Générer une requête de certificat

    Figure 12.3. Générer une requête de certificat

    Utilisez la touche Tab pour sélectionner Oui afin de composer une requête de certificat, ou Non pour générer un certificat auto-signé. Puis appuyez sur Entrée pour confirmer votre choix.
  4. À l'aide de la barre d'espace, activez ([*]) ou désactivez ([ ]) le chiffrement de la clé privée.
    Chiffrer la clé privée

    Figure 12.4. Chiffrer la clé privée

    Veuillez utiliser la touche Tab pour sélectionner le bouton Suivant, et appuyez sur Entrée pour passer à l'écran suivant.
  5. Si vous avez activé le chiffrement de clé privée, veuillez saisir une phrase de passe convenable. Remarquez que pour des raisons de sécurité, celle-ci n'est pas affichée lorsque vous la saisissez, et doit faire 5 caractères au minimum.
    Saisir une phrase de passe

    Figure 12.5. Saisir une phrase de passe

    Veuillez utiliser la touche Tab pour sélectionner le bouton Suivant, et appuyez sur Entrée pour passer à l'écran suivant.

    Important

    Saisir la phrase de passe correctement est requis pour que le serveur démarre. Si vous la perdez, vous devrez générer une nouvelle clé et un nouveau certificat.
  6. Personnaliser les détails du certificat.
    Spécifier les informations du certificat

    Figure 12.6. Spécifier les informations du certificat

    Veuillez utiliser la touche Tab pour sélectionner le bouton Suivant, et appuyez sur Entrée pour terminer avec la génération de clé.
  7. Si vous avez activé la génération de requête de certificat, il vous sera demandé de l'envoyer à une autorité de certification.
    Instructions sur la manière d'envoyer une requête de certificat

    Figure 12.7. Instructions sur la manière d'envoyer une requête de certificat

    Appuyez sur Entrée pour retourner dans une invite shell.
Une fois généré, ajoutez les emplacements de la clé et du certificat au fichier de configuration /etc/httpd/conf.d/ssl.conf : 
SSLCertificateFile /etc/pki/tls/certs/hostname.crt
SSLCertificateKeyFile /etc/pki/tls/private/hostname.key
Finalement, redémarrez le service httpd comme décrit dans la Section 12.1.3.3, « Redémarrer le service » afin que la configuration mise à jour soit chargée.

12.1.12. Configurez le pare-feu pour HTTP et HTTPS en utilisant la ligne de commande

Par défaut, Red Hat Enterprise Linux n'autorise pas le trafic HTTP et HTTPS. Pour autoriser le système à agir en tant que serveur web, veuillez utiliser les services firewalld pris en charge pour que le trafic HTTP et que le trafic HTTPS soient autorisés à passer à travers le pare-feu comme requis.
Pour autoriser HTTP en utilisant la ligne de commande, veuillez exécuter la commande suivante en tant qu'utilisateur root : 
~]# firewall-cmd --add-service http
 success
Pour autoriser HTTPS en utilisant la ligne de commande, veuillez exécuter la commande suivante en tant qu'utilisateur root : 
~]# firewall-cmd --add-service https
 success
Remarquez que ces changements ne persisteront pas après le prochain démarrage système. Pour rendre ces changements permanents sur le pare-feu, veuillez répéter les commandes en ajoutant l'option --permanent.

12.1.12.1. Vérifier l'accès réseau de HTTPS et de HTTPS entrant en utilisant la ligne de commande

Pour vérifier quels services le pare-feu est configuré à autoriser, veuillez exécuter la commande suivante sur la ligne de commande en tant qu'utilisateur root : 
~]# firewall-cmd --list-all
public (default, active)
  interfaces: em1
  sources: 
  services: dhcpv6-client sshsortie tronquée
Dans cet exemple extrait d'une installation par défaut, le pare-feu est activé mais HTTP et HTTPS n'ont pas été autorisés à passer à travers.
Une fois les services de pare-feu HTTP et HTTP activés, la ligne services apparaîtra et sera similaire à ceci : 
services: dhcpv6-client http https ssh
Pour obtenir des informations supplémentaires sur l'activation des services de pare-feu, ou sur l'ouverture et la fermeture de ports sur firewalld, veuillez consulter le Guide de sécurité Red Hat Enterprise Linux 7 .

12.1.13. Ressources supplémentaires

Pour en savoir plus sur le serveur Apache HTTP, veuillez consulter les ressources suivantes.

Documentation installée

  • httpd(8) — la page du manuel du service httpd contenant la liste complète de ses options de ligne de commande.
  • genkey(1) — la page du manuel de l'utilitaire genkey, fournie par le paquet crypto-utils.
  • apachectl(8) — la page du manuel de l'interface de contrôle du serveur HTTP Apache.

Documentation installable

  • http://localhost/manual/ — documentation officielle du serveur HTTP Apache avec la description complète de ses directives et modules disponibles. Remarquez que pour accéder à cette documentation, le paquet httpd-manual doit être installé, et le serveur web doit être en cours d'exécution.
    Avant d'accéder à la documentation, veuillez exécuter la commande suivante en tant qu'utilisateur root : 
    ~]# yum install httpd-manual
~]# apachectl graceful

Documentation en ligne

  • http://httpd.apache.org/ — site web officiel du serveur HTTP Apache avec la documentation sur toutes les directives et tous les modules par défaut.
  • http://www.openssl.org/ — page d'accueil d'OpenSSL contenant davantage de documentation, une foire aux questions, des liens de listes de diffusion, ainsi que d'autres ressources utiles.

Chapitre 13. Serveurs de courrier

Red Hat Enterprise Linux offre de nombreuses applications avancées pour servir et accéder aux courriers électroniques. Ce chapitre décrit les protocoles de courriers électroniques modernes utilisés de nos jours, ainsi que certains des programmes conçus pour envoyer et recevoir des courriers électroniques.

13.1. Protocoles de courrier électronique

De nos jours, les courriers électroniques sont distribués en utilisant une architecture client/serveur. Un courrier électronique est créé à l'aide d'un programme de client de messagerie. Le serveur transfère ensuite le message sur le serveur de courrier du destinataire, où le message est finalement remis au client de messagerie du destinataire
Pour activer ce processus, une variété de protocoles réseau standard autorisent différentes machines, exécutant souvent différents systèmes d'exploitation, et utilisant différents programmes de courrier électronique à envoyer et recevoir des courriers électroniques.
Les protocoles dont il est question sont les plus couramment utilisés lors des transferts de courriers électroniques.

13.1.1. Protocoles de transport de courrier

La distribution du courrier à partir d'une application cliente sur un serveur, et à partir d'un serveur d'origine sur un serveur destinataire, est gérée par SMTP (Simple Mail Transfer Protocol).

13.1.1.1. SMTP

Le but principal de SMTP est de transférer les courriers électroniques entre serveurs de courrier. Cependant, ceci est critique pour les clients de courrier également. Pour envoyer un courrier, le client envoie le message sur un serveur de courrier sortant, qui contactera par la suite le serveur de courrier destinataire pour le lui remettre, donc il faut spécifier un serveur SMTP lors de la configuration d'un client de messagerie.
Dans Red Hat Enterprise Linux, un utilisateur peut configurer un serveur SMTP sur la machine locale pour gérer la remise de courrier. Il est également possible de configurer des serveurs SMTP distants pour le courrier sortant.
Un point important à souligner sur le protocole SMTP est qu'il ne nécessite pas d'authentification. Ceci permet à n'importe qui sur Internet d'envoyer des courriers électroniques à une personne ou à de grands groupes de personnes. C'est cette caractéristique de SMTP qui rend les courriers électroniques indésirables, ou spam possibles. Imposer des restrictions de relais limite les utilisateurs aléatoires envoyant des courriers électroniques via votre serveur SMTP vers d'autres serveurs sur internet. Les serveurs qui n'imposent pas de telles restrictions sont appelés des serveurs relais ouverts.
Red Hat Enterprise Linux 7 fournit les programmes Postfix et Sendmail SMTP.

13.1.2. Protocoles d'accès au courrier

Deux protocoles principaux sont utilisés par les applications clientes de courrier pour récupérer le courrier électronique en provenance des serveurs de courrier : POP (Post Office Protocol), et le protocole IMAP (Internet Message Access Protocol).

13.1.2.1. POP

Le serveur POP par défaut sous Red Hat Enterprise Linux se nomme Dovecot et est fourni par le paquet dovecot.

Note

Pour utiliser Dovecot, commencez par vous assurer que le paquet dovecot soit effectivement installé sur votre système en exécutant la commande suivante en tant qu'utilisateur root : 
~]# yum install dovecot
Pour obtenir davantage d'informations sur l'installation de paquets avec Yum, veuillez consulter la Section 8.2.4, « Installation de paquets ».
Lors de l'utilisation d'un serveur POP, les messages électroniques sont téléchargés par les applications clientes de courrier. Par défaut, la plupart des clients de courrier POP sont automatiquement configurés pour supprimer le message sur le serveur de courrier une fois son tranfert réussi. Ce paramètre peut toutefois être modifié.
POP est totalement compatible avec les standards de messagerie Internet importants, tels que MIME (Multipurpose Internet Mail Extensions), qui permet d'ajouter des pièces jointes aux courriers électroniques.
POP fonctionne mieux pour les utilisateurs qui possèdent un système sur lequel lire les courriers électroniques. Celui-ci fonctionne également mieux pour les utilisateurs qui ne possèdent pas de connexion persistante sur Internet ou sur le réseau contenant le serveur de courrier. Malheureusement, pour les personnes dont les connexions réseau sont lentes, POP exige que les programmes clients téléchargent la totalité du contenu de chaque message une fois l'authentification effectuée. Ceci peut prendre un long moment si un courrier contient une pièce jointe de grande taille.
La version la plus courante du protocole POP standard est POP3.
Cependant, il existe également des variantes moins utilisées du protocole POP :
  • APOP — POP3 avec une authentification MD5. Un hachage chiffré du mot de passe utilisateur est envoyé à partir du client de messagerie vers le serveur, plutôt que d'envoyer un mot de passe non chiffré.
  • KPOP — POP3 avec authentification Kerberos.
  • RPOP — POP3 avec authentification RPOP. Ceci utilise un ID par utilisateur, similairement à un mot de passe, mais pour authentifier les requêtes POP. Cependant, cet ID n'est pas chiffré, et RPOP n'est ainsi pas plus sécurisé que le protocole POP standard.
Pour une meilleure sécurité, il est possible d'utiliser le chiffrement SSL (Secure Socket Layer) pour l'authentification de client et les sessions de transferts de données. Ceci peut être activé en utilisant le service pop3s, ou en utilisant l'application stunnel. Pour obtenir davantage d'informations sur la sécurisation des communications par courrier électronique, veuillez consulter la Section 13.5.1, « Sécuriser les communications ».

13.1.2.2. IMAP

Le serveur IMAP par défaut sous Red Hat Enterprise Linux se nomme Dovecot et est fourni par le paquet dovecot. Veuillez consulter la Section 13.1.2.1, « POP » pour obtenir des informations sur la manière d'installer Dovecot.
Lors de l'utilisation d'un serveur de courrier IMAP, les messages électroniques restent sur le serveur, les utilisateurs peuvent donc les lire ou les supprimer. IMAP autorise également les applications clientes à créer, renommer, ou supprimer des répertoires de courrier sur le serveur pour organiser et stocker les courriers électroniques.
IMAP est particulièrement utile pour les utilisateurs accédant à leur courrier électronique à partir de plusieurs machines. Le protocole est également utile pour les utiisateurs se connectant au serveur de courrier via une connexion lente, car jusqu'à ce que le courrier soit ouvert, seules les informations de l'en-tête des courriers électroniques sont téléchargées, économisant ainsi de la bande passante. L'utilisateur a également la possibilité de supprimer des messages sans les voir ou sans les télécharger.
Pour plus de commodité, les applications clientes IMAP sont capables de mettre en cache des copies de messages localement, permettant ainsi à l'utilisateur de parcourir des messages précédemment lus sans pour autant être directement connecté au serveur IMAP.
IMAP, tout comme POP, est complètement compatible avec les standards de messagerie Internet importants, tels que MIME, qui autorise l'ajout de pièces jointes.
Pour une meilleure sécurité, il est possible d'utiliser le chiffrement SSL pour l'authentification de client et les sessions de transfert de données. Ceci peut être activé en utilisant le service imaps, ou en utilisant le programme stunnel. Pour obtenir davantage d'informations sur la sécurisation des communications par courrier électronique, veuillez consulter la Section 13.5.1, « Sécuriser les communications ».
D'autres clients et serveurs IMAP gratuits ou de type commercial sont également disponibles, et nombre d'entre eux étendent le protocole IMAP et fournissent des fonctionnalités supplémentaires.

13.1.2.3. dovecot

Les processus imap-login et pop3-login qui implémentent les protocoles IMAP et POP3 sont engendrés par le démon dovecot maître inclus dans le paquet dovecot. L'utilisation d'IMAP et de POP est configurée via le fichier de configuration /etc/dovecot/dovecot.conf ; par défaut dovecot exécute IMAP et POP3 avec leur version sécurisée en utilisant SSL. Pour configurer dovecot de manière à utiliser POP, veuillez appliquer les étapes suivantes :
  1. Modifiez le fichier de configuration /etc/dovecot/dovecot.conf de manière à vous assurer que la variable protocols ne se trouve pas dans un commentaire (supprimez le caractère dièse (#) au début de la ligne) et qu'elle contienne bien l'argument pop3. Exemple : 
    protocols = imap pop3 lmtp
    Lorsque la variable protocols ne se trouve plus dans un commentaire, dovecot utilisera les valeurs par défaut comme décrit ci-dessus.
  2. Rendre le changement opérationnel pour la session actuelle en exécutant la commande suivante en tant qu'utilisateur root : 
    ~]# systemctl restart dovecot
  3. Rendre le changement opérationnel après le prochain redémarrage en exécutant la commande : 
    ~]# systemctl enable dovecot
Created symlink from /etc/systemd/system/multi-user.target.wants/dovecot.service to /usr/lib/systemd/system/dovecot.service.

    Note

    Veuillez remarquer que dovecot rapporte uniquement qu'il a démarré le serveur IMAP, mais il lance également le serveur POP3.
Contrairement à SMTP, IMAP et POP3 nécessitent de connecter les clients pour s'authentifier en utilisant un nom d'utilisateur et un mot de passe.. Par défaut, les mots de passe de ces deux protocoles sont passés à travers le réseau de manière non-chiffrée.
Pour configurer SSL sur dovecot :
  • Modifiez le fichier de configuration /etc/dovecot/conf.d/10-ssl.conf pour vous assurer que la variable ssl_protocols est bien décommentée et contient les arguments !SSLv2 !SSLv3 : 
    ssl_protocols = !SSLv2 !SSLv3
    Ces valeurs permettent de s'assurer que dovecot évite SSL versions 2 et 3, qui sont toutes deux connues pour ne pas être sécurisées. Ceci est dû à la vulnérabilité décrite dans POODLE: SSLv3 vulnerability (CVE-2014-3566). Veuillez consulter la Résolution de la vulnérabilité SSL 3.0 POODLE (CVE-2014-3566) dans Postfix et Dovecot pour obtenir davantage de détails.
  • Modifiez le fichier de configuration /etc/pki/dovecot/dovecot-openssl.cnf selon vos préférences. Cependant, dans une installation typique, ce fichier ne requiert pas de modification.
  • Renommez, déplacez ou supprimez les fichiers /etc/pki/dovecot/certs/dovecot.pem et /etc/pki/dovecot/private/dovecot.pem.
  • Exécutez le script /usr/libexec/dovecot/mkcert.sh qui crée les certificats auto-signés dovecot. Ces certificats sont copiés dans les répertoires /etc/pki/dovecot/certs et /etc/pki/dovecot/private. Pour implémenter les changements, redémarrez dovecot en exécutant la commande suivante en tant qu'utilisateur root : 
    ~]# systemctl restart dovecot
Davantage de détails sur dovecot peuvent être trouvés en ligne sur http://www.dovecot.org.

13.2. Classifications des programmes de courrier électronique

En général, toutes les applications de courrier électronique font partie d'au moins une de trois classifications. Chaque classification joue un rôle particulier dans le déplacement et la gestion de messages électroniques. Même si la plupart des utilisateurs connaissent uniquement le logiciel de courrier électronique qu'ils utilisent pour envoyer et recevoir des messages, chaque logiciel est important pour que le courrier électronique puisse arriver à la destination correcte.

13.2.1. Agent de transport de courrier

Un agent de transport de courrier (ou MTA) transporte les courriers électroniques entre hôtes à l'aide du protocole SMTP. Un message peut impliquer plusieurs MTA pendant son déplacement vers la destination prévue.
Même si la remise de messages entre machines est relativement claire, le processus de décision pour savoir si un MTA particulier doit ou devrait accepter un message pour le remettre est assez compliqué. En outre, dû à des problèmes liés au courrier indésirable, l'utilisation d'un MTA particulier est habituellement limitée par la configuration du MTA ou par la configuration d'accès au réseau sur lequel le MTA réside.
De nombreux programmes clients de courrier électronique modernes peuvent agir en tant que MTA lors de l'envoi de courrier électronique. Cependant, cette action ne doit pas être confondue avec le rôle d'un réel MTA. La seule raison pour laquelle les programmes client de messagerie sont capables d'envoyer un courrier comme un MTA s'explique par le fait que l'hôte exécutant l'application ne possède pas son propre MTA. Ceci est particulièrement vrai des programmes clients de messagerie sur des systèmes d'exploitation non basés sur UNIX. Cependant, ces programmes client envoient uniquement des messages sortants sur un MTA qu'ils sont autorisés à utiliser et ne remettent pas le message directement au serveur de courrier du destinataire prévu.
Comme Red Hat Enterprise Linux propose deux MTA, Postfix et Sendmail, les programmes clients de messagerie n'ont pas besoin d'agir en tant que MTA. Red Hat Enterprise Linux inclut également un MTA à caractère particulier nommé Fetchmail.
Pour obtenir davantage d'informations sur Postfix, Sendmail, et Fetchmail, veuillez consulter la Section 13.3, « Agents de transport de courrier ».

13.2.2. Agent distributeur de courrier

Un agent distributeur de courrier (ou MDA) est invoqué par le MTA pour archiver le courrier entrant dans la bonne boîte à lettres de l'utilisateur. Dans de nombreux cas, le MDA est un Agent distributeur local (ou LDA), tel que mail ou Procmail.
Tout programme qui gère la remise d'un message jusqu'au moment où il peut être lu par une application cliente de messagerie peut être considéré comme un MDA. Pour cette raison, certains MTA (tels que Sendmail et Postfix) peuvent jouer le rôle d'un MDA lorsqu'ils ajoutent de nouveaux messages électroniques au fichier spool du courrier d'un utilisateur local. En général, les MDA ne transportent pas de messages entre systèmes et ne fournissent pas d'interface utilisateur ; les MDA distribuent et arrangent les messages sur la machine locale pour qu'une application cliente de messagerie puisse y accéder.

13.2.3. Agent d'utilisateur de messagerie

Un agent d'utilisateur de messagerie (MUA) est synonyme d'une application cliente de messagerie. Un MUA est un programme qui, au minimum, permet à un utilisateur de lire et de composer des messages électroniques. De nombreux MUA sont capables de récupérer des messages via les protocoles POP ou IMAP, paramétrant des boîtes à lettres pour stocker des messages, et envoyant des messages sortant vers un MTA.
Les MUA peuvent être graphiques, comme Evolution, ou être de simples interfaces basées texte, comme Mutt.

13.3. Agents de transport de courrier

Red Hat Enterprise Linux 7 offre deux principaux MTA : Postfix et Sendmail. Postfix est configuré en tant que MTA par défaut et Sendmail est considéré comme déconseillé. Si vous vous trouvez dans l'obligation de changer le MTA par défaut sur Sendmail, vous pouvez désinstaller Postfix ou utiliser la commande suivante en tant qu'utilisateur root pour basculer sur Sendmail : 
~]# alternatives --config mta
Vous pouvez également utiliser la commande suivante pour activer le service souhaité : 
~]# systemctl enable service
Similairement, pour désactiver le service, veuillez saisir ce qui suit dans une invite de shell : 
~]# systemctl disable service
Pour obtenir davantage d'informations sur la manière de gérer les services système sur Red Hat Enterprise Linux 7, veuillez consulter le Chapitre 9, Gérer les services avec systemd.

13.3.1. Postfix

Développé à l'origine par un expert en sécurité et programmeur chez IBM, Wietse Venema, Postfix est un MTA compatible avec Sendmail conçu de manière à être sécurisé, rapide, et facile à configurer.
Pour améliorer la sécurité, Postfix utilise un design modulaire, où de petits processus avec des privilèges limités sont lancés par un démon maître master. Les plus petits processus, moins privilégiés, effectuent des tâches très particulières liées aux différentes étapes de la remise du courrier et sont exécutés dans un environnement racine modifié pour limiter les effets de toute attaque.
Configurer Postfix pour accepter des connexions réseau en provenance d'hôtes autres que l'ordinateur local ne demande que quelques changements mineurs dans son fichier de configuration. Lorsque des besoins plus complexes se font sentir, Postfix fournit une variété d'options de configuration, ainsi que des greffons de tierces parties qui en font un MTA très versatile et avec des nombreuses fonctionnalités.
Les fichiers de configuration de Postfix sont lisibles par les humains et prennent en charge plus de 250 directives. Contrairement à Sendmail, aucun traitement macro n'est requis pour que les changements entrent en vigueur, et la majorité des options les plus couramment utilisées sont décrites dans les fichiers lourdement commentés.

13.3.1.1. Installation Postfix par défaut

L'exécutable Postfix se nomme postfix. Ce démon lance tous les processus nécessaires à la gestion de la remise du courrier.
Postfix stocke ses fichiers de configuration dans le répertoire /etc/postfix/. Voici une liste de fichiers les plus couramment utilisés :
  • access — utilisé pour le contrôle des accès, ce fichier spécifie les hôtes autorisés à se connecter à Postfix.
  • main.cf — fichier de configuration global de Postfix. La majorité des options de configuration sont spécifiées dans ce fichier.
  • master.cf — spécifie la manière par laquelle Postfix interagit avec les divers processus pour effectuer la remise du courrier.
  • transport — fait correspondre les adresses électroniques avec les hôtes de relais.
Le fichier aliases se trouve dans le répertoire /etc. Ce fichier est partagé entre Postfix et Sendmail. Il s'agit d'une liste configurable requise par le protocole de messagerie qui décrit les alias des ID utilisateurs.

Important

Le fichier /etc/postfix/main.cf par défaut n'autorise pas Postfix à accepter de connexions réseau d'un hôte autre que l'ordinateur local. Pour obtenir des instructions sur la configuration de Postfix en tant que serveur pour d'autres clients, veuillez consulter la Section 13.3.1.3, « Configuration de base Postfix ».
Redémarrez le service postfix après avoir modifié toute option des fichiers de configuration sous le répertoire /etc/postfix/ afin que les changements entrent en vigueur. Pour faire cela, veuillez exécuter la commande suivante en tant qu'utilisateur root : 
~]# systemctl restart postfix

13.3.1.2. Mettre à niveau à partir d'une version précédente

Les paramètres suivants de Red Hat Enterprise Linux 7 sont différents des versions précédentes :
  • disable_vrfy_command = no — ce paramètre est désactivé par défaut, ce qui est différent des valeurs par défaut de Sendmail. Si modifié sur yes, il peut empêcher certaines méthodes de récolte d'adresses électroniques.
  • allow_percent_hack = yes — ce paramètre est activé par défaut. Il permet la suppression des caractères % dans les adresses électroniques. Le bricolage du pourcentage est une ancienne solution de contournement qui permettait le routage contrôlé par l'envoyeur des messages électroniques. DNS et le routage de courrier sont désormais bien plus fiables, mais Postfix continue de prendre en charge ce bricolage. Pour désactiver la réécriture du pourcentage, veuillez définir allow_percent_hack sur no.
  • smtpd_helo_required = no — ce paramètre est désactivé par défaut, tout comme sur Sendmail, car il empêche certaines applications d'envoyer des courriers électroniques. Il peut être modifié sur yes pour requérir des clients qu'ils envoient des commandes HELO ou EHLO avant de tenter d'envoyer les commandes MAIL, FROM, ou ETRN.

13.3.1.3. Configuration de base Postfix

Par défaut, Postfix n'accepte pas de connexion réseau d'hôte différent que l'hôte local. Veuillez reproduire les étapes suivantes en tant qu'utilisateur root pour activer la remise de courrier pour d'autres hôtes sur le réseau :
  • Modifiez le fichier /etc/postfix/main.cf avec un editeur de texte, tel que vi.
  • Décommentez la ligne mydomain en supprimant le caractère dièse (#), et remplacez domain.tld par le domaine entretenu par le serveur de courrier, 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 la machine.
  • Décommentez la ligne mydestination = $myhostname, localhost.$mydomain.
  • Décommentez la ligne mynetworks, et remplacez 168.100.189.0/28 par un paramètre réseau valide pour les hôtes qui peuvent se connecter au serveur.
  • Décommentez la ligne inet_interfaces = all.
  • Mettez la ligne inet_interfaces = localhost en commentaire.
  • Redémarrez le service postfix.
Une fois ces étapes reproduites, l'hôte acceptera de remettre des courriers extérieurs.
Postfix offre un large éventail d'options de configuration. L'une des meilleures manières d'apprendre comment configurer Postfix consiste à lire les commentaires dans le fichier de configuration /etc/postfix/main.cf. Des ressources supplémentaires, y compris des informations sur la configuration de Postfix, l'intégration de SpamAssassin, ou des descriptions détaillées des paramètres /etc/postfix/main.cf sont disponibles en ligne sur http://www.postfix.org/.

Important

À cause de la vulnérabilité décrite dans POODLE: SSLv3 vulnerability (CVE-2014-3566), Red Hat recommande de désactiver SSL et d'utiliser TLSv1.1 ou TLSv1.2 uniquement. Voir Résolution de la vulnérabilité POODLE SSL 3.0 (CVE-2014-3566) dans Postfix et Dovecot pour obtenir plus de détails.

13.3.1.4. Utiliser Postfix avec LDAP

Postfix peut utiliser un répertoire LDAP en tant que source pour diverses tables de recherche (par exemple : aliases, virtual, canonical, etc.). Ceci permet à LDAP de stocker des informations utilisateur hiérarchiques et à Postfix de recevoir le résultat des requêtes LDAP uniquement lorsque nécessaire. En ne stockant pas ces informations localement, les administrateurs peuvent les maintenir plus facilement.
13.3.1.4.1. L'exemple de recherche /etc/aliases
Ci-dessous figure un exemple de base d'utilisation de LDAP pour rechercher le fichier /etc/aliases. Assurez-vous que le fichier /etc/postfix/main.cf contienne bien : 
alias_maps = hash:/etc/aliases, ldap:/etc/postfix/ldap-aliases.cf
Veuillez créer un fichier /etc/postfix/ldap-aliases.cf, si vous n'en possédez pas déjà un, et assurez-vous qu'il contiennent effectivement ce qui suit : 
server_host = ldap.example.com
search_base = dc=example, dc=com
où ldap.example.com, example, et com sont des paramètres qui doivent être remplacés avec la spécification d'un serveur LDAP existant et disponible.

Note

Le fichier /etc/postfix/ldap-aliases.cf peut spécifier divers paramètres, y compris des paramètres activant LDAP SSL et STARTTLS. Pour obtenir davantage d'informations, veuillez consulter la page man de ldap_table(5).
Pour plus d'informations sur LDAP, voir OpenLDAP dans le guide System-Level Authentication Guide.

13.3.2. Sendmail

Le but premier de Sendmail, tout comme les autres MTA, est de transférer le courrier entre les hôtes en toute sécurité, ce qui est habituellement fait à l'aide du protocole SMTP. Veuillez remarquer que l'utilisation de Sendmail est déconseillée et ses utilisateurs sont encouragés à utiliser Postfix lorsque possible. Veuillez consulter la Section 13.3.1, « Postfix » pour obtenir davantage d'informations.

13.3.2.1. Objectif et limites

Il est important de savoir ce que Sendmail est et peut faire, ainsi que de connaître ses limitations. De nos jours, avec des applications monolithiques remplissant de multiples rôles, Sendmail peut sembler être la seule application nécessaire pour exécuter un serveur de courrier électronique dans une organisation. Techniquement, cette affirmation est véridique, car Sendmail pour mettre en spool le courrier sur le répertoire de chaque utilisateur et distribuer le courrier sortant des utilisateurs. Cependant, la plupart des utilisateurs requièrent bien plus qu'une simple distribution du courrier. Les utilisateurs souhaitent habituellement interagir avec leur courrier électronique en utilisant un MUA, qui utilise POP ou IMAP pour télécharger les messages sur la machine locale. Ces utilisateurs peuvent également préférer d'utiliser une interface Web pour obtenir accès à leur boîte de réception. Les autres applications peuvent fonctionner en conjonction avec Sendmail, mais elles existent pour différentes raisons et peuvent opérer séparément les unes des autres.
Tout ce que Sendmail pourrait ou devrait être configuré à faire est au-delà de l'étendue de cette section. Des centaines d'options et de règles, et des volumes entiers ont été consacrés à expliquer tout ce qui peut être fait et comment résoudre les problèmes pouvant se produire. Veuillez consulter la Section 13.6, « Ressources supplémentaires » pour afficher une liste des ressources Sendmail.
Cette section examine les fichiers installés avec Sendmail par défaut et les changements de configuration de base, y compris comment arrêter de recevoir du courrier indésirable (spam) et comment étendre Sendmail avec le protocole LDAP (Lightweight Directory Access Protocol).

13.3.2.2. Installation Sendmail par défaut

Pour utiliser Sendmail, commencez par vous assurer que le paquet sendmail soit installé sur votre système en exécutant la commande suivante en tant qu'utilisateur root : 
~]# yum install sendmail
Pour configurer Sendmail, assurez-vous que le paquet sendmail-cf est installé sur votre système en exécutant la commande suivante en tant qu'utilisateur root : 
~]# yum install sendmail-cf
Pour obtenir davantage d'informations sur l'installation de paquets avec Yum, veuillez consulter la Section 8.2.4, « Installation de paquets ».
Avant d'utiliser Sendmail, le MTA par défaut doit être changé à partir de Postfix. Pour obtenir davantage d'informations sur la manière de changer le MTA par défaut, veuillez consulter la Section 13.3, « Agents de transport de courrier ».
L'exécutable Sendmail est nommé sendmail.
Le fichier de configuration Sendmail long et détaillé est nommé /etc/mail/sendmail.cf. Veuillez éviter de modifier le fichier sendmail.cf directement. Pour effectuer des changements de configuration sur Sendmail, veuillez modifier le fichier /etc/mail/sendmail.mc, effectuer une copie de sauvegarde du fichier /etc/mail/sendmail.cf d'origine, puis utiliser les alternatives suivantes pour générer un nouveau fichier de configuration :
  • Veuillez utiliser le fichier makefile inclus dans le fichier de configuration /etc/mail/ pour créer un nouveau fichier de configuration /etc/mail/sendmail.cf : 
    ~]# make all -C /etc/mail/
    Tous les autres fichiers générés dans /etc/mail (fichiers db) seront générés à nouveau si nécessaire. Les anciennes commandes makemap sont toujours utilisables. La commande make est automatiquement utilisée lorsque vous démarrez ou redémarrez le service sendmail.
Davantage d'information sur la configuration de Sendmail se trouve dans la Section 13.3.2.3, « Changements communs de la configuration Sendmail ».
Divers fichiers de configuration Sendmail sont installés dans le répertoire /etc/mail/, y compris :
  • access — indique quels systèmes peuvent utiliser Sendmail pour les courriers électroniques sortants.
  • domaintable — spécifie le mappage du nom de domaine.
  • local-host-names — spécifie les alias de l'hôte.
  • mailertable — spécifie les instructions qui outrepassent le routage de certains domaines particuliers.
  • virtusertable — spécifie une forme de crénelage spécifique aux domaines, permettant à de multiples domaines virtuels d'être hébergés sur une machine.
Plusieurs fichiers de configuration dans le répertoire /etc/mail/, comme access, domaintable, mailertable et virtusertable, doivent stocker leurs informations dans des fichiers de base de données avant que Sendmail puisse utiliser un changement de configuration. Pour inclure tout changement apporté à ces configurations dans leurs fichiers de base de données, veuillez exécuter les commandes suivantes en tant qu'utilisateur root : 
~]# cd /etc/mail/
~]# make all
Ceci mettra à jour virtusertable.db, access.db, domaintable.db, mailertable.db, sendmail.cf, et submit.cf.
Pour mettre à jour tous les fichiers de la base de données répertoriés ci-dessus, et pour mettre à jour un fichier personnalisé de base de données, veuillez utiliser une commande sous le format suivant : 
make name.db all
où name correspond au nom du fichier personnalisé de la base de données à mettre à jour.
Pour mettre à jour une seule base de données, veuillez utiliser une commande du format suivant : 
make name.db
où name.db correspond au nom du fichier de la base de données à mettre à jour.
Vous pouvez également redémarrer le service sendmail pour que les changements entrent en vigueur en exécutant : 
~]# systemctl restart sendmail
Par exemple, pour que tous les courriers électroniques adressés au domaine example.com soient remis à bob@other-example.com, veuillez ajouter la ligne suivante au fichier virtusertable : 
@example.com bob@other-example.com
Pour finaliser le changement, le fichier virtusertable.db doit être mis à jour : 
~]# make virtusertable.db all
L'utilisation de l'option all provoquera la mise à jour simultanée de virtusertable.db et access.db.

13.3.2.3. Changements communs de la configuration Sendmail

Lors de l'altération du fichier de configuration Sendmail, il vaut mieux ne pas modifier un fichier existant, mais générer un fichier /etc/mail/sendmail.cf complètement nouveau.

Avertissement

Avant de remplacer ou d'effectuer tout changement sur le fichier sendmail.cf, veuillez créer une copie de sauvegarde.
Pour ajouter la fonctionnalité souhaitée à Sendmail, veuillez modifier le fichier /etc/mail/sendmail.mc en tant qu'utilisateur root. Après avoir terminé, veuillez redémarrer le service sendmail, si le paquet m4 est installé, le processeur macro m4 générera automatiquement un nouveau fichier de configuration sendmail.cf : 
~]# systemctl restart sendmail

Important

Le fichier sendmail.cf par défaut interdit à Sendmail d'accepter des connexions réseau en provenance de tout autre hôte que l'ordinateur local. Pour configurer Sendmail en tant que serveur pour d'autres clients, veuillez modifier le fichier /etc/mail/sendmail.mc, et modifiez l'adresse spécifiée dans l'option Addr= de la directive DAEMON_OPTIONS en provenance de 127.0.0.1 par l'adresse IP d'un périphérique réseau actif ou mettez en commentaire la directive DAEMON_OPTIONS toute entière en plaçant dnl au début de la ligne. Une fois cela terminé, veuillez générer un nouveau fichier /etc/mail/sendmail.cf en redémarrant le service : 
~]# systemctl restart sendmail
La configuration par défaut dans Red Hat Enterprise Linux fonctionne pour la plupart des sites utilisant uniquement SMTP. Cependant, cela ne fonctionne pas pour les sites UUCP (« UNIX-to-UNIX Copy Protocol »). Si vous utilisez le transfert de courrier UUCP, le fichier /etc/mail/sendmail.mc doit être reconfiguré et un nouveau fichier /etc/mail/sendmail.cf doit être généré.
Veuillez consulter le fichier /usr/share/sendmail-cf/README avant de mettre à jour tout fichier dans les répertoires situés sous le répertoire /usr/share/sendmail-cf/, car ils peuvent affecter la future configuration du fichier /etc/mail/sendmail.cf.

13.3.2.4. Camouflage

Une configuration Sendmail commune consiste à faire en sorte qu'une seule machine agisse en tant que passerelle pour toutes les machines sur le réseau. Par exemple, une société pourrait souhaiter avoir une machine appelée mail.example.com qui gère tout le courrier électronique et assigne une adresse de retour cohérente à tout courrier sortant.
Dans cette situation, le serveur Sendmail doit camoufler les noms de machine sur le réseau de la société de manière à ce que l'adresse de retour affiche user@example.com au lieu de user@host.example.com.
Pour faire cela, veuillez ajouter 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(`example.com.')dnl
MASQUERADE_DOMAIN(`example.com.')dnl
MASQUERADE_AS(example.com)dnl
Après avoir généré un nouveau fichier sendmail.cf en utilisant le processeur macro m4, cette configuration fait apparaître tout le courrier intérieur au réseau comme s'il avait été envoyé par example.com.
Remarquez que les administrateurs de serveurs de courrier, des serveurs DNS et DHCP, ainsi que toute application de provisioning, doivent s'accorder sur le format des noms d'hôtes utilisé dans une organisation. Veuillez consulter le Guide de mise en réseau Red Hat Enterprise Linux 7 pour obtenir davantage d'informations sur les pratiques de dénomination recommandées.

13.3.2.5. Arrêter le courrier indésirable

Le courrier indésirable est le courrier non nécessaire et non solicité reçu par un utilisateur qui n'a jamais requis de communication. Il s'agit d'un abus perturbateur, coûteux et répandu des standards de communication internet.
Sendmail rend relativement facile le blocage des nouvelles techniques de spam utilisées pour envoyer du courrier indésirable. Il bloque également les méthodes de spam les plus courantes par défaut. Les principales fonctionnalités anti-spam disponibles sur Sendmail incluent la vérification des en-têtes (header checks), le déni de relais (relaying denial, par défaut la version 8.9), et les vérifications d'informations sur l'envoyeur et sur les bases de données d'accès (access database and sender information checks).
Par exemple, le transfert de messages SMTP, aussi appelé relais, a été désactivé par défaut depuis la version 8.9 de Sendmail. Avant ce changement, Sendmail ordonnait à l'hôte du courrier (x.edu) d'accepter les messages d'une partie (y.com) et de les envoyer à une autre partie (z.net). Cependant, Sendmail doit désormais être configuré pour autoriser à tout domaine de relayer le courrier à travers le serveur. Pour configurer les domaines de relais, veuillez modifier le fichier /etc/mail/relay-domains et redémarrer Sendmail 
~]# systemctl restart sendmail
Cependant les utilisateurs peuvent également recevoir du courrier indésirable provenant de serveurs sur internet. Dans ce cas, les fonctionnalités de contrôle d'accès de Sendmail disponibles à travers le fichier /etc/mail/access peuvent être utilisées pour empêcher des connexions d'hôtes indésirables. L'exemple suivant illustre comment utiliser ce fichier pour bloquer et spécifiquement 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 montre que tout courrier électronique envoyé à partir de badspammer.com est bloqué avec un code d'erreur de conformité 550 RFC-821, avec un message renvoyé. Le courrier électronique envoyé à partir du sous-domaine tux.badspammer.com est accepté. La dernière ligne affiche que tout courrier électronique envoyé depuis le réseau 10.0.*.* peut être relayé à travers le serveur de courrier.
Comme le fichier /etc/mail/access.db est une base de données, veuillez utiliser la commande makemap pour mettre à jour tout changement. Pour effectuer cela, veuillez utiliser la commande suivante en tant qu'utilisateur root : 
~]# makemap hash /etc/mail/access < /etc/mail/access
L'analyse d'en-tête de message vous permet de rejeter le courrier basé sur le contenu des en-têtes. Les serveurs SMTP stockent des informations sur le parcours d'un courrier électronique dans l'en-tête du message. Tandis que le messages se déplacent d'un MTA à un autre, chacun ajoute un en-tête Received (« Reçu ») au-dessus des autres en-têtes Received. Il est important de noter que ces informations peuvent être altérées par les expéditeurs du courrier indésirable.
Les exemples ci-dessus représentent uniquement une petite partie de ce que Sendmail peut faire lors de l'autorisation ou du blocage des accès. Veuillez afficher le fichier /usr/share/sendmail-cf/README pour obtenir davantage d'informations et d'exemples.
Comme Sendmail appelle le MDA Procmail lors de la remise du courrier, il est également possible d'utiliser un programme de filtrage de courrier indésirable, tel que SpamAssassin, pour identifier et archiver le courrier indésirable pour les utilisateurs. Veuillez consulter la Section 13.4.2.6, « Filtres du courrier indésirable » pour obtenir des informations supplémentaires sur l'utilisation de SpamAssassin.

13.3.2.6. Utiliser Sendmail avec LDAP

Utiliser LDAP est une manière rapide et puissante de trouver des informations spécifiques sur un utilisateur particulier dans un groupe de grande taille. Par exemple, un serveur LDAP peut être utilisé pour rechercher une adresse électronique particulière dans un annuaire d'entreprise commun en utilisant le nom de famille de l'utilisateur. Dans ce type d'implémentation, LDAP est relativement différent de Sendmail, avec LDAP stockant les informations hiérarchiques des utilisateurs et Sendmail ne reçevant que le résultat des requêtes LDAP dans des messages électroniques pré-adressés.
Cependant, Sendmail prend en charge une intégration bien plus importante avec LDAP, avec laquelle LDAP est utilisé pour remplacer des fichiers maintenus séparément, comme /etc/aliases et /etc/mail/virtusertables, sur différents serveurs de courrier fonctionnant ensemble pour prendre en charge une organisation de niveau moyen à niveau entreprise. Autrement dit, LDAP fait une abtraction du niveau de routage du courrier de Sendmail et de ses fichiers de configuration séparés sur un cluster LDAP puissant dont de nombreuses différentes applications peuvent tirer profit.
La version actuelle de Sendmail contient la prise en charge de LDAP. Pour étendre le serveur Sendmail utilisant LDAP, commencez par exécuter un serveur LDAP correctement configuré, tel que OpenLDAP. Puis modifiez /etc/mail/sendmail.mc de manière à inclure ceci : 
LDAPROUTE_DOMAIN('yourdomain.com')dnl
FEATURE('ldap_routing')dnl

Note

Ceci est uniquement destiné à une configuration très basique de Sendmail avec LDAP. La configuration peut être largement différente en fonction de l'implémentation de LDAP, particulièrement lors de la configuration de plusieurs machines Sendmail pour utiliser un serveur LDAP commun.
Veuillez consulter /usr/share/sendmail-cf/README pour des instructions et exemples de configuration du routage LDAP.
Ensuite, veuillez recréer le fichier /etc/mail/sendmail.cf en exécutant le macro processeur m4 et redémarrez Sendmail. Veuillez consulter la Section 13.3.2.3, « Changements communs de la configuration Sendmail » pour obtenir des instructions.
Pour plus d'informations sur LDAP, voir OpenLDAP dans le guide System-Level Authentication Guide.

13.3.3. Fetchmail

Fetchmail est un MTA qui récupère le courrier électronique se trouvant sur des serveurs distants et le remet au MTA local. De nombreux utilisateurs apprécient la capacité de séparer le processus de téléchargement de leurs messages se trouvant sur un serveur distant du processus de lecture et d'organisation du courrier électronique dans un MUA. Conçu à l'origine pour répondre aux besoins des utilisateurs accédant à internet par ligne téléphonique commutée, Fetchmail se connecte et télécharge rapidement tous les messages électroniques sur le fichier spool du courrier en utilisant un certain nombre de protocoles, y compris POP3 et IMAP. Il peut également transférer les messages électroniques sur un serveur SMTP si nécessaire.

Note

Pour utiliser Fetchmail, veuillez vous assurer que le paquet fetchmail est installé sur votre système en exécutant la commande suivante en tant qu'utilisateur root : 
~]# yum install fetchmail
Pour obtenir davantage d'informations sur l'installation de paquets avec Yum, veuillez consulter la Section 8.2.4, « Installation de paquets ».
Fetchmail est configuré pour chaque utilisateur à travers l'utilisation d'un fichier .fetchmailrc dams le répertoire personnel de l'utilisateur. S'il n'existe pas déjà, veuillez créer le fichier .fetchmailrc dans votre répertoire personnel
En utilisant les préférences dans le fichier .fetchmailrc, Fetchmail vérifie le courrier sur un serveur distant et le télécharge. Il le livre ensuite sur le port 25 de la machine locale, en utilisant le MTA local pour placer le courrier dans le fichier spool du bon utilisateur. Si Procmail est disponible, il est lancé pour filtrer le courrier électronique et le placer dans une boîte aux lettres afin qu'il soit lu par un MUA.

13.3.3.1. Options de Configuration Fetchmail

Malgré qu'il soit possible de passer toutes les options nécessaires sur la ligne de commande pour vérifier le courrier électronique sur un serveur distant pendant l'exécution de Fetchmail, l'utilisation d'un fichier .fetchmailrc est bien plus facile. Placez toutes les options de configuration souhaitées dans le fichier .fetchmailrc afin qu'elles soient utilisées chaque fois que la commande fetchmail est exécutée. Il est possible d'outrepasser ces commandes pendant l'exécution de Fetchmail en spécifiant cette option sur la ligne de commande.
Le fichier .fetchmailrc d'un utilisateur contient trois classes d'option de configuration :
  • options globales — celles-ci donnent à Fetchmail des instructions contrôlant l'opération du programme ou fournissent des paramètres pour chaque connexion vérifiant le courrrier électronique.
  • options du serveur — elles spécifient les informations nécessaires sur le serveur en cours d'interrogation, comme le nom d'hôte, ainsi que les préférences de serveurs de courrier électronique particuliers, comme le port à vérifier ou le nombre de secondes à attendre avant expiration. Ces options affectent tous les utilisateurs utilisant ce serveur.
  • options d'utilisateur — contient des informations nécessaires à l'authentification et à la vérification du courrier électronique, telles que le nom d'utilisateur et le mot de passe, en utilisant un serveur de courrier électronique spécifié.
Des options globales apparaissent en haut du fichier .fetchmailrc, suivies par une ou plusieurs options de serveur, qui désigne chacune un différent serveur de courrier électronique que Fetchmail devrait vérifier. Les options d'utilisateur suivent les options de serveur pour chaque compte utilisateur vérifiant ce serveur de courrier électronique. Tout comme les options de serveur, des options de multiples utilisateurs peuvent être spécifiées pour une utilisation avec un serveur particulier, ainsi que pour vérifier de multiples comptes utilisateur sur le même serveur.
Des options de serveur sont activées dans le fichier .fetchmailrc par l'utilisation d'un verbe spéciale option, poll (interroger) ou skip (ignorer), qui précède les informations serveur. L'action poll (interroger) ordonne à Fetchmail d'utiliser cette option de serveur lors de son exécution. Elle vérifie le courrier électronique en utilisant les options spécifiées par l'utilisateur. Cependant, toute option de serveur située après une action skip (ignorer), ne sera pas vérifiée, à moins que le nom d'hôte de ce serveur soit spécifié lorsque Fetchmail est invoqué. L'option skip est utile pendant des tests de configuration dans le fichier .fetchmailrc car elle ne vérifie que les serveurs ignorés si invoquée, et n'affecte aucune configuration fonctionnant actuellement.
Ci-dessous figure un exemple de fichier .fetchmailrc : 
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 indiquent que l'utilisateur reçoit du courrier électronique en dernier recours (option postmaster) et toutes les erreurs de courrier électronique sont envoyées au «postmaster » au lieu de l'envoyeur (option bouncemail). L'action set transmet à Fetchmail que cette ligne contient une option globale. Puis, deux serveurs de courrier sont spécifiés, l'un est paramétré pour vérifier en utilisant POP3, et l'autre pour tenter divers protocoles dans le but d'en trouver un qui fonctionne. Deux utilisateurs sont vérifés en utilisant la seconde option du serveur, mais tous le courrier trouvé pour un utilisateur quelconque est envoyé dans le spool du courrier de l'utilisateur user1. Ceci permet à de multiples boîtes aux lettres d'être vérifiées sur de multiples serveurs, tout en apparaissant comme n'étant qu'une seule boîte aux lettres MUA. Les informations spécifiques de chaque utilisateur commencent par l'action user.

Note

Les utilisateurs ne sont pas obligés de placer leur mot de passe dans le fichier .fetchmailrc. L'omission de la section with password 'password' cause à Fetchmail de demander un mot de passe lorsqu'il est lancé.
Fetchmail possède de nombreuses options globales, de serveur, et locales. Nombre de ces options sont rarement utilisées ou ne s'appliquent qu'à des situations très spécifiques. La page man fetchmail explique chaque option en détail, mais les plus communes sont répertoriées dans les trois sections suivantes.

13.3.3.2. Options globales

Chaque option globale doit être placée sur une seule ligne après une action set.
  • daemon seconds — spécifie le mode du démon, où Fetchmail reste en arrière-plan. Veuillez remplacer seconds par le nombre de secondes pendant lesquelles Fetchmail doit patienter avant d'interroger le serveur.
  • postmaster — Spécifie un utilisateur local à qui envoyer le courrier en cas de problème de remise du courrier électronique.
  • syslog — Spécifie le fichier journal pour les messages d'erreur et de statut. Par défaut, ce fichier est /var/log/maillog.

13.3.3.3. Options de serveur

Les options de serveur doivent être placées sur leur propre ligne dans .fetchmailrc, après une action poll ou skip.
  • auth auth-type — remplace 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, y compris kerberos_v5, kerberos_v4, et ssh. Si le type d'authentification any est utilisé, Fetchmail tentera d'abord des méthodes qui ne requièrent pas de mot de passe, puis des méthodes qui masquent le mot de passe, et tentera finalement d'envoyer le mot de passe non chiffré pour s'authentifier sur le serveur.
  • interval number — interroge le serveur spécifié toutes les number fois qu'il vérifie le courrier électronique sur tous les serveurs configurés. Cette option est généralement utilisée pour les serveurs de courrier sur lesquels l'utilisateur reçoit rarement de messages.
  • port port-number — remplace port-number par le numéro du port. Cette valeur remplace le numéro de port par défaut pour le protocole spécifié.
  • proto protocol — remplace protocol par le protocole à utiliser, comme pop3 ou imap, pendant les vérifications de messages sur le serveur
  • timeout seconds — remplace seconds par le nombre de secondes d'inactivité du serveur après lesquelles Fetchmail abandonnera une tentative de connexion. Si cette valeur n'est pas définie, la valeur par défaut de 300 sera utilisée.

13.3.3.4. Options d'utilisateur

Les options d'utilisateur peuvent être placées sur leurs propres lignes sous une option de serveur ou sur la même ligne que l'option de serveur. Dans les deux cas, les options définies doivent suivre l'option user (définie ci-dessous).
  • fetchall — ordonne à Fetchmail de télécharger tous les messages de la file, y compris les messages qui ont déjà été lus. Par défaut, Fetchmail ne télécharge que les nouveaux messages.
  • fetchlimit number — remplace number par le nombre de messages à récupérer avant d'arrêter.
  • flush — supprime tous les messages déjà vus qui se trouvent dans la file avant de récupérer les nouveaux messages.
  • limit max-number-bytes — remplace max-number-bytes par la taille de message maximale autorisée en octets lorsque les messages sont récupérés par Fetchmail. Cette option est utile avec les liens réseau lents, lorsqu'un message de grande taille prend trop de temps à télécharger.
  • password 'password' — remplace password par le mot de passe de l'utilisateur.
  • preconnect "command" — remplace command par la commande à exécuter avant de récupérer les messages pour l'utilisateur.
  • postconnect "command" — remplace command par la commande à exécuter après avoir récupéré les messages pour l'utilisateur.
  • ssl — active l'encodage. Au moment de la rédaction de cet ouvrage, l'action par défaut est d'utiliser soit SSL2, SSL3, SSL23, TLS1, TLS1.1 ou TLS1.2 suivant ce qu'il y a de mieux de disponible. Notez que SSL2 est considéré comme étant obsolète à cause de POODLE: Vulnérabilité SSLv3 (CVE-2014-3566), SSLv3 ne doit pas être utilisé. Cependant, il n'est pas utile de forcer l'utilisation de TLS1 ou version plus récente, donc, veillez bien à ce que le serveur de messagerie connecté soit configuré de façon à ne pas utiliser SSLv2 ou SSLv3. Utiliser stunnel quand le serveur ne peut pas être configuré à ne pas utiliser SSLv2 ou SSLv3.
  • sslproto — définit les protocoles SSL ou TLS autorisés. Les valeurs possibles sont SSL2, SSL3, SSL23 et TLS1. La valeur par défaut, si sslproto est omis, désactivé ou défini à une valeur non valide, est SSL23. L’action par défaut consiste à utiliser soit SSLv2, SSLv3, TLSv1, TLS1.1 ou TLS1.2. Notez que la définition de toute autre valeur pour SSL ou TLS désactive tous les autres protocoles. À cause de POODLE:ulnérabilité SSLv3 (CVE-2014-3566), il est recommandé d’omettre cette option, ou de la définir à SSLv23, et de configurer le serveur de messagerie correspondant à ne pas utiliser SSLv2 et SSLv3. Utilisez stunnel où le serveur ne peut pas être configuré à ne pas utiliser SSLv2 et SSLv3.
  • user "username" — Veuillez remplacer username par le nom d'utilisateur utilisé par Fetchmail pour récupérer les messages. Cette option doit précéder toutes les autres options d'utilisateur.

13.3.3.5. Options de commande Fetchmail

La plupart des options Fetchmail utilisées sur la ligne de commande lors de l'exécution de la commande fetchmail reflètent les options de configuration .fetchmailrc. Ainsi, Fetchmail peut être utilisé avec ou sans fichier de configuration. Ces options ne sont pas utilisées sur la ligne de commande par la plupart des utilisateurs car il est plus facile de les laisser dans le fichier .fetchmailrc.
Parfois, il est souhaitable d'exécuter la commande fetchmail avec d'autres options dans un but particulier. Il est possible d'exécuter des options de commande pour outrepasser de manière temporaire un paramètre .fetchmailrc qui causerait une erreur, comme toute option spécifiée sur la ligne de commande outrepasse les options du fichier de configuration.

13.3.3.6. Options de débogage ou à caractère informatif

Certaines options utilisées après la commande fetchmail peuvent fournir d'importantes informations.
  • --configdump — affiche toutes les options possibles en se basant sur les informations de .fetchmailrc et sur les valeurs par défaut de Fetchmail. Aucun courrier n'est récupéré pour un utilisateur lorsque cette option est utilisée.
  • -s — exécute Fetchmail en mode silence, empêchant tout message autre que des messages d'erreur d'apparaître après la commande fetchmail.
  • -v — exécute Fetchmail en mode détaillé, affichant toutes les communications entre Fetchmail et les serveurs de courrier distants.
  • -V — affiche des informations détaillées sur la version, répertorie ses options globales, et affiche les paramètres à utiliser avec chaque utilisateur, y compris le protocole du courrier et la méthode d'authentification. Aucun courrier n'est récupéré pour un utilisateur lorsque cette option est utilisée.

13.3.3.7. Options spéciales

Ces options sont parfois utiles pour remplacer les valeurs par défaut souvent trouvées dans le fichier .fetchmailrc.
  • -a — Fetchmail télécharge tous les messages du serveur de courrier distant, qu'ils soient nouveaux ou qu'ils aient déjà été vus. Par défaut, Fetchmail télécharge uniquement les nouveaux messages.
  • -k — Fetchmail laisse les messages sur le serveur de courrier distant après les avoir téléchargés. Cette option outrepasse le comportement par défaut qui consiste à supprimer les messages après les avoir téléchargés.
  • -l max-number-bytes — Fetchmail ne télécharge aucun message au-delà d'une taille particulière et les laisse sur le serveur de courrier distant.
  • --quit — quitte le processus du démon Fetchmail.
Davantage de commandes et d'options .fetchmailrc se trouvent sur la page man de fetchmail.

13.3.4. Configuration de l'agent de transport de courrier (« Mail Transport Agent », ou MTA)

Un MTA (« Mail Transport Agent ») est essentiel pour envoyer un courrier électronique. Un MUA (« Mail User Agent »), tel que Evolution ou Mutt, est utilisé pour lire et écrire des courriers électroniques. Lorsqu'un utilisateur envoie un courrier à partir d'un MUA, le message est remis au MTA, qui envoie le message à travers une série de MTA jusqu'à ce qu'il atteigne sa destination.
Même si un utilisateur ne planifie pas d'envoyer de courrier à partir du système, certaines tâches automatisées ou programmes du système peuvent devoir utiliser la commande mail pour envoyer du courrier contenant des messages de journalisation à l'utilisateur root du système local.
Red Hat Enterprise Linux 7 fournit deux MTA : Postfix et Sendmail. Si les deux sont installés, Postfix est le MTA par défaut. Veuillez remarquer que Sendmail est déconseillé dans Red Hat Enterprise Linux 7.

13.4. Agents de remise de courrier (« Mail Delivery Agents »)

Red Hat Enterprise Linux inclut deux MDA principaux, Procmail et mail. Ces deux applications sont considérées comme des LDA et déplacent le courrier depuis le fichier spool du MTA dans la boîte aux lettre de l'utilisateur. Cependant, Procmail offre un système de filtrage robuste.
Cette section détaille uniquement Procmail. Pour obtenir des informations sur la commande mail, veuillez consulter sa page man (man mail).
Procmail remet et filtre le courrier car il se trouve dans le fichier spool du courrier de l'hôte local. Il est puissant, léger pour les ressources système, et est largement utilisé. Procmail peut jouer un rôle critique dans la remise du courrier pour lecture par les applications client de courrier.
Procmail peut être invoqué de différentes manières. Lorsqu'un MTA place un courrier dans le fichier spool du courrier, Procmail est lancé. Puis, Procmail filtre et archive le courrier pour le MUA et quitte. Sinon, le MUA peut être configuré pour exécuter Procmail à chaque fois qu'un message est reçu de façon à ce que les messages soient déplacés dans la boîte aux lettres qui convient. Par défaut, la présence d'un fichier /etc/procmailrc ou ~/.procmailrc (également appelé un fichier rc) dans le répertoire personnel de l'utilisateur invoque Procmail chaque fois qu'un MTA reçoit un nouveau message.
Par défaut, aucun fichier rc global n'existe dans le répertoire /etc et aucun fichier .procmailrc n'existe dans les répertoires de base d'aucun utilisateur. Ainsi, pour utiliser Procmail, chaque utilisateur doit construire un fichier .procmailrc avec des variables et des règles d'environnement spécifiques.
La réaction de Procmail à la réception d'un courrier électronique dépend de si le message correspond à un ensemble spécifié de conditions ou de recettes (« recipes ») dans le fichier rc. Si un message correspond à une recette, alors le courrier est placé dans un fichier spécifié, supprimé, ou traité autrement.
Lorsque Procmail démarre, il lit le courrier et sépare le corps des informations de l'en-tête. Puis, Procmail recherche des variables et recettes d'environnement Procmail globales par défaut dans le fichier /etc/procmailrc et les fichiers rc du répertoire /etc/procmailrcs/. Procmail recherche ensuite un fichier .procmailrc dans le répertoire personnel de l'utilisateur. De nombreux utilisateurs créent également des fichiers rc supplémentaires pour Procmail auxquels il est fait référence dans le fichier .procmailrc de leur répertoire personnel.

13.4.1. Configuration Procmail

Le fichier de configuration Procmail contient des variables d'environnement importantes. Ces variables spécifient certaines choses, comme les messages à trier ou que faire avec les messages qui ne correspondent à aucune recette.
Ces variables d'environnement apparaissent habituellement au début du fichier ~/.procmailrc sous le format suivant : 
env-variable="value"
Dans cet exemple, env-variable est le nom de la variable et value définit la variable.
De nombreuses variables d'environnement n'étaient pas utilisées par la plupart des utilisateurs Procmail et nombre des variables d'environnement plus importantes sont déjà définies par une valeur par défaut. La plupart du temps, les variables suivantes sont utilisées :
  • DEFAULT — définit la boîte aux lettres par défaut où sont placés les messages ne correspondant à aucune recette.
    La valeur par défaut DEFAULT est la même que la valeur $ORGMAIL.
  • INCLUDERC — spécifie des fichiers rc supplémentaires contenant davantage de recettes avec lesquelles vérifier les messages. Ceci divise les listes des recettes Procmail en fichiers individuels qui remplissent différents rôles, comme bloquer le courrier indésirable et gérer les listes de courrier électronique, qui peuvent également être activés ou désactivés en utilisant les caractères de mise en commentaire dans le fichier de l'utilisateur ~/.procmailrc.
    Par exemple, les lignes du fichier ~/.procmailrc d'un utilisateur pourraient ressembler à celles-ci : 
    MAILDIR=$HOME/Msgs
INCLUDERC=$MAILDIR/lists.rc
INCLUDERC=$MAILDIR/spam.rc
    Pour désactiver le filtrage Procmail des listes de courrier électronique tout en laissant le contrôle du courrier indésirable en place, veuillez mettre en commentaire la première ligne INCLUDERC avec le caractère dièse (#). Remarquez que des chemins relatifs au répertoire actuel sont utilisés.
  • LOCKSLEEP — définit la durée, en secondes, qui doit s'écouler entre chaque tentative d'utilisation d'un fichier lockfile particulier par Procmail. La valeur par défaut s'élève à 8 secondes.
  • LOCKTIMEOUT — définit la durée, en secondes, qui doit s'écouler après la modification d'un fichier lockfile avant que Procmail considère que ce fichier lockfileest trop ancien et doit être supprimé. La valeur par défaut s'élève à 1024 secondes.
  • LOGFILE — fichier sur lequel toutes les informations et tous les messages d'erreur Procmail sont écrits.
  • MAILDIR — définit le répertoire de travail actuel de Procmail. Si défini, tous les autres chemins Procmail seront relatifs à ce répertoire.
  • ORGMAIL — spécifie la boîte aux lettres d'origine, ou un autre endroit où placer les messages s'ils ne peuvent pas être mis dans l'emplacement par défaut ou l'emplacement requis par la recette.
    Par défaut, une valeur de /var/spool/mail/$LOGNAME est utilisée.
  • SUSPEND — définit la durée, en secondes, pendant laquelle Procmail fait une pause si une ressource importante, 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 similaires à l'option INCLUDERC, sauf que la vérification de recette s'arrête sur le fichier de configuration reférant et seules les recettes se trouvant sur le fichier spécifié par SWITCHRC sont utilisées.
  • VERBOSE — amène Procmail à journaliser davantage d'information. Cette option est utile pour le débogage.
D'autres variables d'environnement importantes sont récupérées du shell, comme LOGNAME, le nom de connexion ; HOME, l'emplacement du répertoire personnel ; et SHELL, le shell par défaut.
Une explication complète de toutes les variables d'environnement et de leurs valeurs par défaut est disponible sur la page man de procmailrc.

13.4.2. Recettes Procmail

Les nouveaux utilisateurs trouvent fréquemment que la construction de recettes est la partie la plus difficile lors de l'apprentissage de l'utilisation de Procmail. Cette difficulté est souvent attribuée aux recettes qui font correspondre des messages en utilisant des expressions régulières utilisées pour spécifier des critères de correspondance de chaîne. Cependant, les expressions régulières ne sont pas très difficiles à construire, et encore moins difficiles à comprendre lorsqu'elles sont lues. En outre, la cohérence d'écriture des recettes Procmail, peu importe les expressions régulières , facilite l'apprentissage à l'aide d'exemples. Pour afficher des exemples de recettes Procmail, veuillez consulter la Section 13.4.2.5, « Exemples de recettes ».
Les recettes Procmail sont sous la forme suivante : 
:0 [flags] [: lockfile-name ]
* [ condition_1_special-condition-character condition_1_regular_expression ]
* [ condition_2_special-condition-character condition-2_regular_expression ]
* [ condition_N_special-condition-character condition-N_regular_expression ]
        special-action-character
        action-to-perform
Les deux premiers caractères d'une recette Procmail sont deux points suivis d'un zéro. Divers marqueurs peuvent être placés après le zéro pour contrôler la manière par laquelle Procmail traite la recette. Les deux points suivant la section flags indiquent qu'un fichier lockfile est créé pour ce message. Si un ficier lockfile est créé, le nom peut être spécifié en remplaçant lockfile-name.
Une recette peut contenir plusieurs conditions pour correspondre aux messages. S'il n'y a aucune condition, chaque message correspond à la recette. Les expressions régulières sont placées dans certaines conditions pour faciliter la correspondance de messages. Si de multiples conditions sont utilisées, elles doivent toutes correspondre pour que l'action soit appliquée. Les conditions sont vérifiées en se basant sur les marqueurs paramétrés dans la première ligne du destinataire. Des caractères spéciaux optionnels sont placés après l'astérisque (*).
L'argument action-to-perform spécifie l'action effectuée lorsque le message correspond à l'une des conditions. Il ne peut y avoir qu'une seule action par recette. Dans de nombreux cas, le nom d'une boîte aux lettres est utilisé pour diriger les messages correspondants vers ce fichier, triant ainsi le courrier électronique. Les caractères d'action spéciaux peuvent également être utilisés avant que l'action ne soit spécifiée. Veuillez consulter la Section 13.4.2.4, « Conditions et actions spéciales » pour obtenir davantage d'informations.

13.4.2.1. Recettes de remise vs. Recettes de non-remise

L'action utilisée si la recette correspond à un message particulier détermine s'il s'agit d'une recette de remise (« delivering recipe ») ou d'une recette de non-remise (« non-delivering »). Une recette de remise contient une action qui écrit le message sur un fichier, envoie le message à un autre programme, ou transfère le message sur une autre adresse électronique. Une recette de non-remise couvre toutes les autres actions, comme un bloc imbriqué (« nesting block »). Un bloc imbriqué est un ensemble d'actions, entre crochets { }, qui sont effectuées sur les messages correspondants aux conditions de la recette. Les blocs imbriqués peuvent être imbriqués à l'intérieur les uns des autres, offrant ainsi un meilleur contrôle pour identifier et effectuer des actions sur les messages.
Lorsque des messages correspondent à une recette de remise, Procmail effectue l'action spécifiée et arrête de comparer le message à d'autres recettes. Les messages qui correspondent aux recettes de non-remise continuent d'être comparées aux autres recettes.

13.4.2.2. Marqueurs

Les marqueurs sont essentiels pour déterminer si les conditions d'une recette sont comparées à un message et de quelle manière cela est fait. L'utilitaire egrep est utilisé de manière interne pour faire correspondre les conditions. Les marqueurs suivants sont couramment utilisés :
  • A — spécifie que cette recette est uniquement utilisée si la recette précédente sans marqueur A ou a correspondait également à ce message.
  • a — spécifie que cette recette est uniquement utilisée si la recette précédente avec un marqueur A ou a correspondait également à ce message et a été appliquée.
  • B — analyse le corps du message et recherche des conditions correpondantes.
  • b — utilise le corps dans toute action résultante, comme l'écriture du message sur un fichier ou son transfert. Il s'agit du comportement par défaut.
  • c — génère une copie carbone du courrier électronique. Ceci est utile avec les recettes de remise, car l'action requise peut être effectuée sur le message et une copie du message peut toujours être en cours de traitement dans les fichiers rc.
  • D — fait respecter la casse à la comparaison egrep. Par défaut, le processus de comparaison ne respecte pas la casse.
  • E — malgré des similarités avec le marqueur A, les conditions de la recette sont uniquement comparées au message si la recette la précédant immédiatement sans marqeur E ne correspondait pas. Ceci est comparable à une action else.
  • e — la recette est comparée au message uniquement si l'action spécifiée dans la recette la précédant immédiatement échoue.
  • f — utilise le tube (« pipe ») en tant que filtre.
  • H — analyse l'en-tête du message et recherche des conditions correspondantes. Ceci est le comportement par défaut.
  • h — utilise l'en-tête dans une action résultante. Ceci est le comportement par défaut.
  • w — ordonne à Procmail d'attendre que le filtre ou programme spécifié se termine, et rapporte si celui-ci a réussi ou non avant de considérer le message comme filtré.
  • W — est identique à w, sauf que les messages « Échec du programme » sont supprimés.
Pour une liste détaillée de marqueurs supplémentaires, veuillez consulter la page man de procmailrc.

13.4.2.3. Spécifier un fichier lockfile local

Les fichiers lockfiles sont très utiles avec Procmail pour vous assurer que plusieurs processus ne tentent pas d'altérer un message simultanément. Spécifiez un lockfile local en plaçant un caractère Deux-points (:) après tout marqueur se trouvant sur la première ligne d'une recette. Ceci crée un fichier lockfile local basé sur le nom du fichier destinataire plus ce qui a été défini dans la variable globale d'environnement LOCKEXT.
Alternativement, veuillez spécifier le nom du fichier lockfile local à utiliser avec cette recette après le caractère des deux-points.

13.4.2.4. Conditions et actions spéciales

Les caractères spéciaux utilisés avant les conditions et actions des recettes Procmail modifient la manière par laquelle celles-ci sont interprétées.
Les caractères suivants peuvent être utilisés après un astérisque (*) au début de la ligne de condition d'une recette :
  • ! — dans la ligne de condition, ce caractère inverse la condition. Ainsi, une correspondance ne se produira que si la condition ne correspond pas au message.
  • < — vérifie si le message fait moins qu'un nombre d'octets spécifié.
  • > — vérifie si le message fait plus qu'un nombre d'octets spécifié.
Les caractères suivants sont utilisés pour effectuer des actions spéciales :
  • ! — dans la ligne de l'action, ce caractère ordonne à Procmail de transférer le message vers les adresses électroniques spécifiées.
  • $ — fait référence à une variable précédemment définie dans le fichier rc. Souvent utilisé pour définir une boîte aux lettres commune à laquelle diverses recettes font référence.
  • | — lance un programme spécifié pour traiter le message.
  • { and } — permet de construire un bloc imbriqué, utilisé pour contenir des recettes supplémentaires pour appliquer des messages correspondants.
Si aucun caractère spécial n'est utilisé au début de la ligne de l'action, Procmail supposera que la ligne d'action spécifie la boîte aux lettre dans laquelle écrire le message.

13.4.2.5. Exemples de recettes

Procmail est un programme extrêmement flexible, mais cette flexibilité rend la composition de recettes Procmail difficile pour les nouveaux utilisateurs.
La meilleure manière de développer les compétences requises pour créer des conditions de recettes Procmail vient d'une bonne compréhension des expressions régulières combiné à un regard objectif sur les nombreux exemples produits par d'autres personnes. L'explication détaillée des expressions régulières est au-delà de l'étendue de cette section. La structure des recettes Procmail et des exemples de recettes Procmail utiles peuvent être trouvés sur internet. L'utilisation et l'adaptation correcte d'expressiosn régulière peuvent être dérivées de l'observation minutieuse de ces exemples de recettes. En outre, des informations d'introduction auxr règles des expressions régulières de base sont situées dans la page man de grep(1).
Les simples exemples suivants démontrent la structure de base des recettes Procmail et peuvent servir de fondation pour des constructions plus complexes.
Une recette de base peut même ne pas contenir de conditions, comme illustré dans l'exemple suivant : 
:0:
new-mail.spool
La première ligne spécifie qu'un lockfile local doit être créé mais ne spécifie pas de nom, Procmail utilise donc le nom du fichier destinataire et ajoute la valeur spécifiée dans la variable d'environnement LOCKEXT. Aucune condition n'est spécifiée, donc chaque message correspond à cette recette et est placé dans l'unique fichier spool nommé new-mail.spool, qui est situé dans un répertoire spécifié par la variable d'environnement MAILDIR. Un MUA peut ensuite afficher les messages dans ce fichier.
Une recette de base, comme celle-ci, peut être placée à la fin de tous les fichiers rc pour diriger les messages vers un emplacement par défaut.
L'exemple suivant faisait correspondre des messages d'une adresse électronique spécifique puis les jettait. 
:0
* ^From: spammer@domain.com
/dev/null
Dans cet exemple, tout message envoyé par spammer@domain.com est envoyé sur le périphérique /dev/null, qui les supprime.

Avertissement

Assurez-vous que les règles fonctionnent comme prévu avant d'envoyer des messages sur /dev/null pour une suppression permanente. Si une recette obtient des messages de manière non-intentionnelle et que ces messages disparaissent, il sera difficile de résoudre le problème de la règle.
Une meilleure solution consisterait à pointer l'action de la recette vers une boîte aux lettres spéciale, qui pourra être vérifiée de temps en temps pour chercher des faux positifs. Une fois que vous serez satisfait qu'aucun message ne sera accidentellement mis en correspondance, veuillez supprimer la boîte aux lettres et dirigez l'action pour que les messages soit envoyés dans /dev/null.
La recette suivante récupère le courrier électronique envoyé à partir d'une liste de diffusion particulière et le place dans un dossier spécifié. 
:0:
* ^(From|Cc|To).*tux-lug
tuxlug
Tout message envoyé à partir de la liste de diffusion tux-lug@domain.com est automatiquement placé dans la boîte aux lettres tuxlug pour le MUA. Veuillez remarquer que la condition dans cet exemple correspond au message si l'adresse de la liste de diffusion se trouve sur la ligne De (« From »), Cc, ou À (« To »).
Veuillez consulter les nombreuses ressources Procmail en ligne, disponibles dans la Section 13.6, « Ressources supplémentaires » pour obtenir des recettes plus détaillées et plus puissantes.

13.4.2.6. Filtres du courrier indésirable

Comme il est appelé par Sendmail, Postfix, et Fetchmail lors de la réception de nouveaux courriers électroniques, Procmail peut être utilisé comme outil puissant pour combattre le courrier indésirable.
Ceci est particulièrement vrai lorsque Procmail est utilisé en conjonction avec SpamAssassin. Lorsqu'utilisées ensemble, ces deux applications peuvent rapidement identifier le courrier indésirable et le trier ou le détruire.
SpamAssassin utilise des analyses d'en-tête, des analyses de texte, des listes noires, une base de données de suivi de courrier indésirable, et une analyse de courrier indésirable bayésienne pour identifier et baliser le courrier indésirable rapidement et précisément.

Note

Pour utiliser SpamAssassin, veuillez commencer par vous assurer que le paquet spamassassin est installé sur votre système en exécutant la commande suivante en tant qu'utilisateur root : 
~]# yum install spamassassin
Pour obtenir davantage d'informations sur l'installation de paquets avec Yum, veuillez consulter la Section 8.2.4, « Installation de paquets ».
Pour un utilisateur local, la manière la plus simple d'utiliser SpamAssassin consiste à placer la ligne suivante vers le haut du fichier ~/.procmailrc : 
INCLUDERC=/etc/mail/spamassassin/spamassassin-default.rc
Le fichier /etc/mail/spamassassin/spamassassin-default.rc contient une règle Procmail simple qui active SpamAssassin pour le courrier entrant. Si un courrier électronique est déterminé comme étant un courrier indésirable, son en-tête est balisé comme tel et le modèle suivant est ajouté au début de son titre : 
*****SPAM*****
Le contenu du message commence par un décompte des éléments qui le qualifient comme étant un courier indésirable.
Pour archiver le courrier marqué comme indésirable, une règle similaire à la suivante peut être utilisée : 
:0 Hw * ^X-Spam-Status: Yes spam
Cette règle dépose tous les messages dont l'en-tête est balisé comme courrier indésirable dans une boîte aux lettre nommée spam.
Comme SpamAssassin est un script Perl, il pourrait être nécessaire d'utiliser le démon binaire SpamAssassin (spamd) et l'application cliente (spamc) sur des serveurs occupés. Cependant, la configuration de SpamAssassin de cette manière, requiert un accès root à l'hôte.
Pour lancer le démon spamd, veuillez saisir la commande suivante : 
~]# systemctl start spamassassin
Pour lancer le démon SpamAssassin lorsque le système est démarré, veuillez exécuter : 
systemctl enable spamassassin.service
Veuillez consulter le Chapitre 9, Gérer les services avec systemd pour obtenir davantage d'informations sur le lancement et l'arrêt des services.
Pour configurer Procmail de manière à utiliser l'application cliente SpamAssassin au lieu du script Perl, veuillez placer la ligne suivante vers le haut du fichier ~/.procmailrc. Pour une configuration globale, veuillez la placer dans /etc/procmailrc : 
INCLUDERC=/etc/mail/spamassassin/spamassassin-spamc.rc

13.5. Mail User Agents (MUA)

Red Hat Enterprise Linux offre une variété de programmes de messagerie, des programmes client de messagerie graphique, comme Evolution, ainsi que des programme de messagerie basés texte, comme mutt.
Le reste de cette section concerne la sécurisation des communications entre un client et un serveur.

13.5.1. Sécuriser les communications

Les MUA populaires inclus avec Red Hat Enterprise Linux, comme Evolution et Mutt offrent des sessions de messagerie chiffrées avec SSL.
Comme tout autre service exécuté sur un réseau non chiffré, les informations importantes des courrier électroniques, comme les noms d'utilisateurs, les mots de passe et les messages entiers peuvent être interceptés et vus par les utilisateurs sur le réseau. En outre, comme les protocoles standards POP et IMAP passent des informations d'authentification non chiffrées, il est possible qu'une personne malveillante obtienne accès aux comptes des utilisateurs en récupérant les noms d'utilisateurs et mots de passe quand ils sont passés sur le réseau.

13.5.1.1. Clients de messagerie sécurisés

La plupart des MUA Linux conçus pour vérifier le courrier électronique sur les serveurs distants prennent en charge le chiffrement SSL. Pour utiliser SSL pendant la récupération du courrier, il doit être activé sur le client de messagerie et sur le serveur.
SSL est facile à activer côté client, ce qui est souvent fait simplement en cliquant sur un bouton dans la fenêtre de configuration du MUA ou via une option du fichier de configuration du MUA. Les protocoles sécurisés IMAP et POP ont des numéros de port (993 et 995, respectivement) utilisés par le MUA pour authentifier et télécharger des messages.

13.5.1.2. Sécurisation des communications des clients de messagerie

Offrir le chiffrement SSL aux utilisateurs IMAP et POP sur le serveur de messagerie est une simple question.
Premièrement, veuillez créer un certificat SSL. Ceci peut être fait de deux manières différentes en appliquant sur un CA (Certificate Authority) pour obtenir un certificat SSL ou en créant un certificat autosigné.

Avertissement

Les certificats autosignés doivent uniquement être utilisés pour des tests. Tout serveur utilisé dans un environnement de production doit utiliser un certificat SSL signé par un CA.
Pour créer un certificat autosigné pour IMAP ou POP, rendez-vous dans le répertoire /etc/pki/dovecot/, modifiez les paramètres du certificat dans le fichier de configuration /etc/pki/dovecot/dovecot-openssl.cnf selon vos préférences, puis saisissez les commandes suivantes en tant qu'utilisateur root : 
dovecot]# rm -f certs/dovecot.pem private/dovecot.pem
dovecot]# /usr/libexec/dovecot/mkcert.sh
Une fois terminé, assurez-vous d'avoir les configurations suivantes dans votre fichier /etc/dovecot/conf.d/10-ssl.conf : 
ssl_cert = </etc/pki/dovecot/certs/dovecot.pem
ssl_key = </etc/pki/dovecot/private/dovecot.pem
Veuillez exécuter la commande suivante pour redémarrer le démon dovecot : 
~]# systemctl restart dovecot
Alternativement, la commande stunnel peut être utilisée comme emballage de chiffrement autour des connexions standards non-sécurisées aux services IMAP ou POP.
L'utilitaire stunnel utilise des bibliothèques OpenSSL externes incluses avec Red Hat Enterprise Linux pour fournir un chiffrement fort et pour protéger les connexions réseau. Il est recommandé d'appliquer sur un CA pour obtenir un certificat SSL, mais il est également possible de créer un certificat autosigné.
Veuillez consulter Utiliser stunnel dans le Guide de sécurité Red Hat Enterprise Linux 7 pour obtenir des instructions sur l'installation de stunnel et pour créer sa configuration de base. Pour configurer stunnel comme emballage pour IMAPS et POP3S, veuillez ajouter les lignes suivantes au fichier de configuration /etc/stunnel/stunnel.conf : 
[pop3s]
accept  = 995
connect = 110

[imaps]
accept  = 993
connect = 143
Le Guide de sécurité explique également comment lancer et arrêter stunnel. Une fois lancé, il est possible d'utiliser un client de messagerie IMAP ou POP et de se connecter au serveur de messagerie en utilisant le chiffrement SSL.

13.6. Ressources supplémentaires

Voici une liste de documents supplémentaires sur les applications de messagerie.

13.6.1. Documentation installée

  • Des informations sur la configuration de Sendmail sont incluses avec les paquets sendmail et sendmail-cf.
    • /usr/share/sendmail-cf/README — contient des informations sur le processeur macro m4, les emplacements des fichiers pour Sendmail, les logiciels de messagerie pris en charge, sur les manières d'accéder aux fonctionnalités améliorées, et bien plus.
    En outre, les pages man de sendmail et aliases contiennent des informations utiles traitant des diverses options Sendmail et de la configuration correcte du fichier Sendmail /etc/mail/aliases.
  • /usr/share/doc/postfix-version-number/ — contient une grande quantité d'informations sur comment configurer Postfix. Remplacez version-number par le numéro de version de Postfix.
  • /usr/share/doc/fetchmail-version-number/ — contient une liste complète des fonctionnalités de Fetchmail dans le fichier FEATURES ainsi qu'une FAQ d'introduction. Remplacez version-number par le numéro de version de Fetchmail.
  • /usr/share/doc/procmail-version-number/ — contient un fichier README qui fournit une vue d'ensemble de Procmail, un fichier FEATURES qui explore toutes les fonctionnalités du programme, et un fichier FAQ avec les réponses à de nombreuses questions communes sur la configuration. Remplacez version-number par le numéro de version de Procmail.
    Lors de l'apprentissage de Procmail et de la création de nouvelles recettes, les pages man Procmail suivantes seront indispensables :
    • procmail — fournit une vue d'ensemble du fonctionnement de Procmail et des étapes impliquées dans le filtrage du courrier.
    • procmailrc — explique le format du fichier rc utilisé pour créer des recettes.
    • procmailex — donne un certain nombre d'exemples utiles et réels de recettes Procmail.
    • procmailsc — explique la technique de notation pondérée utilisée par Procmail pour faire correspondre une recette particulière à un message.
    • /usr/share/doc/spamassassin-version-number/ — contient une grande quantité d'informations pertinentes à SpamAssassin. Remplacez version-number par le numéro de version du paquet spamassassin.

13.6.2. Documentation en ligne

  • Comment configurer postfix avec TLS ? — un article de Red Hat Knowledgebase qui décrit comment configurer postfix pour utiliser TLS.
  • http://www.sendmail.org/ — offre une décomposition minutieuse des fonctionnalités, de la documentation, et des exemples de configuration de Sendmail.
  • http://www.sendmail.com/ — contient des informations, entretiens, et articles concernant Sendmail, y compris une vue étendue des nombreuses options disponibles.
  • http://www.postfix.org/ — la page d'accueil du projet Postfix contient une mine d'informations sur Postfix. La liste de diffusion est particulièrement utile pour rechercher des informations.
  • http://www.fetchmail.info/fetchmail-FAQ.html — FAQ détaillée sur Fetchmail.
  • http://www.procmail.org/ — page d'accueil de Procmail avec des liens vers les listes de diffusion dédiées à Procmail ainsi que divers documents FAQ.
  • http://www.uwasa.fi/~ts/info/proctips.html — contient une douzaine de conseils qui permettent une utilisation bien plus facile de Procmail. Y compris des instructions sur la manière de tester les fichiers .procmailrc et d'utiliser la notation Procmail pour décider si une action particulière doit être prise.
  • http://www.spamassassin.org/ — site officiel du projet SpamAssassin.

Chapitre 14. Serveurs de fichiers et d'impression

Ce chapitre vous guide à travers l'installation et la configuration de Samba, une implémentation Open Source des protocoles Server Message Block (ou SMB), common Internet file system (ou CIFS), et vsftpd, le principal serveur FTP fourni avec Red Hat Enterprise Linux. En outre, il explique comment utiliser l'outil Imprimer les paramètres pour configurer les imprimantes.

14.1. Samba

Samba est une suite de programmes d'intéropérabilité Windows en source libre du protocole server message block (SMB). SMB permet à Microsoft Windows®, Linux, UNIX, et à d'autres systèmes d'exploitation d'accéder à des fichiers et à des imprimantes partagés à partir de serveurs qui prennent en charge ce protocole. L'utilisation de SMB par Samba leur permet d'apparaître comme serveur Windows pour les clients Windows.

Note

Pour utiliser Samba, commencez par vous assurer que le paquet samba est installé sur votre système en exécutant la commande suivante en tant qu'utilisateur root : 
~]# yum install samba
Pour obtenir davantage d'informations sur l'installation de paquets avec Yum, veuillez consulter la Section 8.2.4, « Installation de paquets ».

14.1.1. Introduction à Samba

Samba est un composant clé qui facilite l'intégration des serveurs Linux et des Desktops dans des environnements Active Directory (AD). Peut fonctionner soit en contrôleur de domaine (NT4-style), soit en tant que membre de domaine standard (AD ou NT4-style).

Ce que Samba peut faire :

  • Servir des structures de répertoires et des imprimantes à des clients Linux, UNIX, et Windows
  • Assister lors de la navigation réseau (avec NetBIOS)
  • Authentifier les connexions aux domaines Windows
  • Fournir des résolutions de serveur de noms Windows Internet Name Service (WINS)
  • Agir en tant que contrôleur de domaine de sauvegarde (PDC) NT®-style Primary Domain Controller
  • Agir en tant que contrôleur de domaine de sauvegarde (BDC) Backup Domain Controller pour un PDC basé Samba
  • Agir en tant que serveur membre d'un domaine Active Directory
  • Joindre un serveur Windows NT/2000/2003/2008 PDC/Windows Server 2012

Ce que Samba ne peut pas faire :

  • Agir en tant que BDC pour un PDC Windows (et vice-versa)
  • Agir en tant que contrôleur de domaine Active Directory

14.1.3. Se connecter à un partage Samba

Vous pouvez utiliser la commande Nautilus ou l'utilitaire de ligne de commande pour vous connecter aux partages de Samba disponibles.

Procédure 14.1. Se connecter à un partage Samba via Nautilus

  1. Pour afficher une liste des groupes de travail Samba et des domaines sur votre réseau, veuillez sélectionner Places → Réseau dans le panneau GNOME, puis sélectionner le réseau souhaité. Vous pouvez également saisir smb: dans la barre Fichier → Ouvrir l'emplacement de Nautilus.
    Comme indiqué dans la Figure 14.1, « Groupes de travail SMB dans Nautilus », une icône s'affiche pour chaque groupe de travail ou domaine SMB sur le réseau.
    Groupes de travail SMB dans Nautilus

    Figure 14.1. Groupes de travail SMB dans Nautilus

  2. Faites un double clic sur l'icône de groupe de travail ou de domaine pour afficher la liste des ordinateurs dans ce groupe de travail ou dans ce domaine.
    Machines SMB dans Nautilus

    Figure 14.2. Machines SMB dans Nautilus

  3. Comme indiqué dans la Figure 14.2, « Machines SMB dans Nautilus », une icône existe pour chaque machine dans le groupe de travail. Faites un double clic sur une icône pour afficher les partages Samba sur la machine. Si une combinaison nom d'utilisateur et mot de passe est requise, celle-ci vous sera demandée.
    Alternativement, vous pouvez également spécifier le serveur Samba et le nom du partage dans la barre Location: de Nautilus en utilisant la syntaxe suivante (remplacez servername et sharename par les valeurs appropriées) : 
    smb://servername/sharename

Procédure 14.2. Se connecter à un partage Samba par l'interface en ligne de commande

  1. Pour se connecter à un partage Samba à partir d'une invite de shell, veuillez saisir la commande suivante : 
    ~]$ smbclient //hostname/sharename -U username
    Remplacez hostname par le nom d'hôte ou par l'adresse IP du serveur Samba auquel vous souhaitez vous connecter, sharename par le nom du répertoire partagé que vous souhaitez parcourir, et username par le nom d'utilisateur Samba du système. Saisissez le mot de passe correct ou appuyez sur Entrée si aucun mot de passe n'est requis pour l'utilisateur.
    Si vous voyez l'invite smb:\>, cela signifie que vous vous êtes connecté. Une fois connecté, veuillez saisir help pour obtenir la liste des commandes. Si vous souhaitez parcourir le contenu de votre répertoire personnel, remplacez sharename par votre nom d'utilisateur. Si le commutateur -U n'est pas utilisé, le nom d'utilisateur de l'utilisateur actuel sera transmis au serveur Samba.
  2. Pour quitter smbclient, saisissez exit à l'invite smb:\>.

14.1.4. Monter le partage

Parfois, il peut être utile de monter un partage Samba sur un répertoire afin que les fichiers puissent être traités comme s'ils faisaient partie du système de fichiers local.
Pour monter un partage Samba sur un répertoire, veuillez créer un répertoire pour le monter dessus (s'il n'existe pas déjà), et exécutez la commande suivante en tant qu'utilisateur root : 
mount -t cifs //nom du serveur/nom partage /mnt/point/ -o username=nom d'utilisateurmot de passe =mot de passe
Cette commande mont nom partage à partir de nom du serveur dans le répertoire local /mnt/point/.
For more information about mounting a samba share, see the mount.cifs(8) manual page.

Note

L'utilitaire mount.cifs est un RPM séparé (indépendant de Samba). Pour utiliser mount.cifs, commencez par vous assurer que le paquet cifs-utils soit installé sur votre système en exécutant la commande suivante en tant qu'utilisateur root : 
~]# yum install cifs-utils
Pour obtenir davantage d'informations sur l'installation de paquets avec Yum, veuillez consulter la Section 8.2.4, « Installation de paquets ».
Note that the cifs-utils package also contains the cifs.upcall binary called by the kernel in order to perform kerberized CIFS mounts. For more information on cifs.upcall, see the cifs.upcall(8) manual page.

Avertissement

Certains serveur CIFS requièremt des mots de passe en texte brut pour l'authentification. La prise en charge de l'authentification des mots passe en texte brut peut être activée en utilisant la commande suivante en tant qu'utilisateur root : 
~]# echo 0x37 > /proc/fs/cifs/SecurityFlags
AVERTISSEMENT : Cette opération peut exposer les mots de passe en supprimant le chiffrement de mot de passe.

14.1.5. Configurer un serveur Samba

Le fichier de configuration par défaut (/etc/samba/smb.conf) permet aux utilisateurs de voir leur répertoire personnel en tant que partage Samba. Il partage également toutes les imprimantes configurées pour le système en tant qu'imprimantes partagées Samba. Vous pouvez attacher une imprimante au système et l'utiliser à partir de machines Windows sur votre réseau.

14.1.5.1. Configuration graphique

Pour configurer Samba en utilisant une interface graphique, veuillez utiliser l'une des interfaces utilisateur graphique Samba disponibles. Une liste des GUI se trouve dans http://www.samba.org/samba/GUI/.

14.1.5.2. Configuration en ligne de commande

Samba utilise /etc/samba/smb.conf comme fichier de configuration. Si vous modifiez cela, les changements n'entreront en vigueur que lorsque vous redémarrez le démon Samba avec la commande suivante, en tant qu'utilisateur root : 
~]# systemctl restart smb.service
Pour spécifier le groupe de travail Windows et pour faire une brève description du serveur Samba, veuillez modifier les lignes suivantes dans votre fichier /etc/samba/smb.conf : 
workgroup = WORKGROUPNAME
server string = BRIEF COMMENT ABOUT SERVER
Remplacez WORKGROUPNAME par le nom du groupe de travail Windows auquel cette machine doit appartenir. BRIEF COMMENT ABOUT SERVER est optionnel et est utilisé comme commentaire Windows sur le système Samba.
Pour créer un répertoire de partage Samba sur votre système Linux, veuillez ajouter la section suivante à votre fichier /etc/samba/smb.conf (après l'avoir modifiée pour refléter vos besoins et ceux de votre système) :

Exemple 14.1. Exemple de configuration de serveur Samba

[nom partage]
commentaire = Insérer un commentaire ici
chemin = /home/share/
utilisateurs valides = tfox carole
écriture = yes
créer masque = 0765
L'exemple ci-dessus permet aux utilisateurs tfox et carole de lire et d'écrire sur le répertoire /home/share/, situé sur le serveur Samba, à partir d'un client Samba.

14.1.5.3. Mots de passe chiffrés

Les mots de passe chiffrés sont activés par défaut car il est plus sûr de les utiliser. Pour créer un utilisateur avec un mot de passe chiffré, veuillez utiliser la commande smbpasswd : 
smbpasswd -a username

14.1.6. Lancer et arrêter Samba

Pour lancer un serveur Samba, veuillez saisir la commande suivante dans une invite de shell en tant qu'utilisateur root : 
~]# systemctl start smb.service

Important

Pour paramétrer un serveur membre d'un domaine, vous devez tout d'abord joindre le domaine ou Active Directory en utilisant la commande net join avant de lancer le service smb. Il est également recommandé d'exécuter winbind avant smbd.
Pour arrêter le serveur, veuillez saisir la commande suivante dans une invite de shell en tant qu'utilisateur root : 
~]# systemctl stop smb.service
L'option restart est une façon rapide d'arrêter, puis de redémarrer Samba. Cette manière est la plus efficace pour que les changements de configuration puissent entrer en vigueur après avoir modifié le fichier de configuration de Samba. Remarquez que l'option de redémarrage lance le démon même s'il n'était pas exécuté à l'origine.
Pour redémarrer le serveur, veuillez saisir la commande suivante dans une invite de shell en tant qu'utilisateur root : 
~]# systemctl restart smb.service
L'option condrestart (redémarrage conditionnel, « conditional restart ») lance smb à condition d'être actuellement en cours d'exécution. Cette option est utile pour les scripts, car elle ne lance pas le démon s'il n'est pas en cours d'exécution.

Note

Lorsque le fichier /etc/samba/smb.conf est modifié, Samba le recharge automatiquement après quelques minutes. Exécuter un redémarrage manuel (« restart ») ou un rechargement manuel (« reload ») est tout autant efficace.
Pour redémarrer le serveur de manière conditionnelle, veuillez saisir la commande suivante dans une invite de shell en tant qu'utilisateur root : 
~]# systemctl try-restart smb.service
Un rechargement manuel du fichier /etc/samba/smb.conf peut être utile en cas d'échec du rechargement automatique effectué par le service smb. Pour vous assurer que le fichier de configuration du serveur Samba soit rechargé sans redémarrer le service, veuillez saisir la commande suivante en tant qu'utilisateur root : 
~]# systemctl reload smb.service
Par défaut, le service smb n'est pas lancé automatiquement pendant l'initialisation. Pour configurer Samba pour qu'il soit lancé pendant l'initialisation, veuillez saisir ce qui suit dans une invite de shell en tant qu'utilisateur root : 
~]# systemctl enable smb.service
Veuillez consulter le Chapitre 9, Gérer les services avec systemd pour obtenir davantage d'informations sur cet outil.

14.1.7. Mode de sécurité de Samba

Il y a seulement deux types de modes de sécurité pour Samba, au niveau du partage et au niveau utilisateur, collectivement connus en tant que niveaux de sécurité. La sécurité au niveau du partage est obsolète et a été suprimée de Samba. Les configurations contenant ce mode doivent être migrées pour utiliser la sécurité niveau utilisateur. La sécurité niveau utilisateur peut être implémentée d’une des trois manières. Les différentes façons d’appliquer un niveau de sécurité s'appellent les modes de sécurité

14.1.7.1. Sécurité Niveau utilisateur

La sécurité niveau utilisateur est la valeur par défaut et est recommandée avec Samba. Même si la directive security = user n’est pas répertoriée dans le fichier /etc/samba/smb.conf, elle sera utilisée par Samba. Si le serveur accepte le nom d'utilisateur et mot de passe du client, le client peut alors monter plusieurs partages sans spécifier un mot de passe pour chaque instance. Samba peut également accepter des demandes de noms et mots de passe basés sur une session utilisateur. Le client maintient plusieurs contextes d’authentification en utilisant un UID unique pour chaque ouverture de session.
Dans le fichier /etc/samba/smb.conf, la directive