From af95039e8d971ecf4159539028fcebba75e81b9a Mon Sep 17 00:00:00 2001 From: Jean-Frederic Clere Date: Thu, 16 Aug 2007 08:44:33 +0000 Subject: [PATCH] Translation submitted by Vincent Deffontaines (copied from trunk). git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/branches/2.2.x@566566 13f79535-47bb-0310-9956-ffa450edef68 --- docs/manual/handler.html.fr | 163 ++++++++++++++ docs/manual/handler.xml.fr | 167 +++++++++++++++ docs/manual/invoking.html.fr | 166 +++++++++++++++ docs/manual/invoking.xml.fr | 157 ++++++++++++++ docs/manual/mpm.html.fr | 129 +++++++++++ docs/manual/mpm.xml.fr | 116 ++++++++++ docs/manual/new_features_2_2.html.fr | 305 +++++++++++++++++++++++++++ docs/manual/new_features_2_2.xml.fr | 296 ++++++++++++++++++++++++++ docs/manual/stopping.html.fr | 275 ++++++++++++++++++++++++ docs/manual/stopping.xml.fr | 266 +++++++++++++++++++++++ 10 files changed, 2040 insertions(+) create mode 100644 docs/manual/handler.html.fr create mode 100644 docs/manual/handler.xml.fr create mode 100644 docs/manual/invoking.html.fr create mode 100644 docs/manual/invoking.xml.fr create mode 100644 docs/manual/mpm.html.fr create mode 100644 docs/manual/mpm.xml.fr create mode 100644 docs/manual/new_features_2_2.html.fr create mode 100644 docs/manual/new_features_2_2.xml.fr create mode 100644 docs/manual/stopping.html.fr create mode 100644 docs/manual/stopping.xml.fr diff --git a/docs/manual/handler.html.fr b/docs/manual/handler.html.fr new file mode 100644 index 00000000000..4c0d18f3a8e --- /dev/null +++ b/docs/manual/handler.html.fr @@ -0,0 +1,163 @@ + + + +Utilisation des gestionnaires d'Apache (handlers) - Serveur Apache HTTP + + + + + +

+Apache > Serveur HTTP > Documentation > Version 2.2

Utilisation des gestionnaires d'Apache (handlers)

Langues Disponibles: en | + es | + fr | + ja | + ko | + ru

+ +

Ce document décrit l'utilisation des gestionnaires d'Apache (handlers).

Qu'est-ce qu'un gestionnaire ?
Exemples
Note du programmeur

Qu'est-ce qu'un gestionnaire ?

Modules Apparentés	Directives Apparentées
`mod_actions` `mod_asis` `mod_cgi` `mod_imagemap` `mod_info` `mod_mime` `mod_negotiation` `mod_status`	`Action` `AddHandler` `RemoveHandler` `SetHandler`

+ + + + +

Un "gestionnaire" est une représentation interne à Apache de l'action + qui doit être entreprise quand un fichier est appelé. En général, les + fichiers ont des gestionnaires implicites, basés sur le type du fichier. + Normalement, tous les fichiers sont traités simplement par le serveur, + mais certains types de fichiers sont "gérés" séparément.

+ +

Les gestionnaires peuvent aussi être configurés explicitement, + soit en fonction des extensions des noms de fichier, soit en fonction + du chemin du fichier, + sans faire référence au type de fichier. Ceci a le double avantage d'être + une solution plus élégante, et aussi d'autoriser à associer à la fois + un type et un gestionnaire avec un fichier. (Voir aussi Fichiers avec extensions + multiples.)

+ +

Les gestionnaires peuvent être soit partie intégrante + du serveur ou inclus dans un module, soit ajoutés à l'aide de la directive + Action. Les gestionnaires + intégrés dans la distribution standard se présentent comme suit :

+ +

default-handler: envoie le fichier en utilisant + le default_handler(), qui est le gestionnaire utilisé par + défaut pour traiter les contenus statiques. (core)
send-as-is: envoie les fichiers avec en-têtes HTTP + tels quels. (mod_asis)
cgi-script: traite le fichier comme un + script CGI. (mod_cgi)
imap-file: Traite le fichier comme un ensemble + de règles de descriptions d'images (imagemap). + (mod_imagemap)
server-info: Extrait des informations sur la + configuration du serveur. (mod_info)
server-status: Rédige un rapport sur le statut + du serveur. (mod_status)
type-map: Traite le fichier comme une description + de type pour la négociation du contenu. + (mod_negotiation)

Exemples

+ + +

Modification d'un contenu statique à l'aide d'un script CGI

+ + +

Les directives suivantes vont faire en sorte que les requêtes pour + des fichiers possédant une extension html déclenchent + l'exécution du script CGI footer.pl.

+ +

+ Action add-footer /cgi-bin/footer.pl + AddHandler add-footer .html +

+ +

À ce moment-là, le script CGI se charge d'envoyer le document + initialement demandé (référencé par la variable d'environnement + PATH_TRANSLATED) et d'effectuer tous ajout ou modification + voulus.

+ + +

Fichiers avec en-têtes HTTP

+ + +

Les directives suivantes vont activer le gestionnaire + send-as-is, qui est utilisé pour les fichiers qui possèdent + leurs propres en-têtes HTTP. Tous les fichiers situés dans le répertoire + /web/htdocs/asis/ seront traités par le gestionnaire + send-as-is, sans tenir compte de l'extension + de leur nom de fichier.

+ +

+ <Directory /web/htdocs/asis> + SetHandler send-as-is + </Directory> +

+ + +

Note du programmeur

+ + +

Pour implémenter la fonctionnalité des gestionnaires, l' + API Apache a fait l'objet d'un ajout + que vous pourriez être amené à utiliser. + + Plus précisément, un nouvel enregistrement a été ajouté à la structure + request_rec :

+ +

+ char *handler +

+ +

Si vous voulez que votre module déclenche l'utilisation d'un + gestionnaire, il vous suffit de définir r->handler avec + le nom du gestionnaire à n'importe quel moment avant l'étape + invoke_handler + de la requête. Les gestionnaires sont implémentés comme auparavant, + quoique l'on utilise le nom du gestionnaire à la place d'un type + de contenu. Bien que ce ne soit pas obligatoire, la convention de nommage + des gestionnaires stipule l'utilisation d'un mot composé séparé par des + tirets, sans slashes, afin de ne pas interférer avec l'espace de nommage + des types de média.

Langues Disponibles: en | + es | + fr | + ja | + ko | + ru

+ \ No newline at end of file diff --git a/docs/manual/handler.xml.fr b/docs/manual/handler.xml.fr new file mode 100644 index 00000000000..55bee0d3887 --- /dev/null +++ b/docs/manual/handler.xml.fr @@ -0,0 +1,167 @@ + + + + + + + + + Utilisation des gestionnaires d'Apache (handlers) + +

Ce document décrit l'utilisation des gestionnaires d'Apache (handlers).

+ +

+ Qu'est-ce qu'un gestionnaire ? + + + mod_actions + mod_asis + mod_cgi + mod_imagemap + mod_info + mod_mime + mod_negotiation + mod_status + + + Action + AddHandler + RemoveHandler + SetHandler + + + + +

+ +

Les gestionnaires peuvent être soit partie intégrante + du serveur ou inclus dans un module, soit ajoutés à l'aide de la directive + Action. Les gestionnaires + intégrés dans la distribution standard se présentent comme suit :

+ +

default-handler: envoie le fichier en utilisant + le default_handler(), qui est le gestionnaire utilisé par + défaut pour traiter les contenus statiques. (core)
send-as-is: envoie les fichiers avec en-têtes HTTP + tels quels. (mod_asis)
cgi-script: traite le fichier comme un + script CGI. (mod_cgi)
imap-file: Traite le fichier comme un ensemble + de règles de descriptions d'images (imagemap). + (mod_imagemap)
server-info: Extrait des informations sur la + configuration du serveur. (mod_info)
server-status: Rédige un rapport sur le statut + du serveur. (mod_status)
type-map: Traite le fichier comme une description + de type pour la négociation du contenu. + (mod_negotiation)

+ Exemples + +

+ Modification d'un contenu statique à l'aide d'un script CGI + +

Les directives suivantes vont faire en sorte que les requêtes pour + des fichiers possédant une extension html déclenchent + l'exécution du script CGI footer.pl.

+ + + Action add-footer /cgi-bin/footer.pl
+ AddHandler add-footer .html + + +

+ +

+ Fichiers avec en-têtes HTTP + +

+ + + <Directory /web/htdocs/asis>
+ SetHandler send-as-is
+ </Directory> + + +

+ Note du programmeur + +

+ + + char *handler + + +

+ + + + + + diff --git a/docs/manual/invoking.html.fr b/docs/manual/invoking.html.fr new file mode 100644 index 00000000000..46ba7d2fe9a --- /dev/null +++ b/docs/manual/invoking.html.fr @@ -0,0 +1,166 @@ + + + +Démarrage d'Apache - Serveur Apache HTTP + + + + + +

+Apache > Serveur HTTP > Documentation > Version 2.2

Démarrage d'Apache

Langues Disponibles: de | + en | + es | + fr | + ja | + ko | + ru

+ +

Apache est habituellement lancé en tant que service + sous Windows NT, 2000 et XP, ou comme application en mode console sous + Windows 9x et ME. Pour plus de détails, voir Démarrer Apache en tant que service + et Démarrer Apache comme + Application en mode console.

+ +

Sous Unix, le programme httpd + est lancé en mode démon et s'exécute de manière permanente en + arrière-plan pour gérer les requêtes. Ce document décrit comment invoquer + httpd.

Comment Apache démarre
Erreurs en cours de démarrage
Lancement au démarrage du système
Informations supplémentaires

Voir aussi

Comment Apache démarre

+ +

Si la directive Listen + spécifiée dans le fichier de configuration est à sa valeur par défaut + de 80 (ou tout autre port inférieur à 1024), il est nécessaire de + posséder les privilèges root pour pouvoir démarrer apache, et lui + permettre d'être associé à ce port privilégié. Lorsque le serveur est + démarré, après avoir effectué quelques opérations préliminaires + comme ouvrir ses fichiers de log, il lance plusieurs processus + enfants qui ont pour rÃ´le d'écouter et de répondre aux + requêtes des clients. Le processus httpd principal + continue à s'exécuter sous l'utilisateur root, tandis que les processus + enfants s'exécutent sous un utilisateur aux privilèges restreints. + Ceci s'effectue par la voie du + Module Multi-Processus (MPM).

+ +

Il est recommandé d'utiliser le script de contrôle + apachectl pour invoquer l'exécutable + httpd. Avant d'invoquer le binaire + httpd, ce script définit certaines variables + d'environnement nécessaires pour permettre à + httpd de fonctionner correctement sous certains systèmes + d'exploitation. + apachectl accepte des arguments de ligne de commande, + ainsi toute option de httpd peut aussi être utilisée avec + apachectl. Vous pouvez aussi éditer directement le + script apachectl en modifiant la variable + HTTPD située en début de script pour spécifier la + localisation du binaire httpd et tout argument de ligne + de commande que vous souhaitez voir systématiquement présent.

+ +

La première chose qu'effectue httpd quand il est + invoqué et de localiser et lire le fichier de configuration + httpd.conf. La localisation de ce fichier est définie à la + compilation, mais il est possible d'en spécifier une autre à + l'exécution en utilisant l'option de ligne de commande -f comme suit:

+ +

/usr/local/apache2/bin/apachectl -f + /usr/local/apache2/conf/httpd.conf

+ +

Si tout se passe bien pendant le démarrage, le serveur va se dissocier + du terminal et l'invite de commande réapparaîtra presque immédiatement. + Ceci indique que le serveur a démarré et est en cours d'exécution. + À partir de ce moment, vous pouvez utiliser votre navigateur pour vous connecter + au serveur et afficher la page de test située dans le répertoire défini + par la directive DocumentRoot, + ainsi qu'une copie locale de la documentation sous forme d'un lien + situé sur cette page. + (note du traducteur : en fait, vous ne devriez voir que "It works !" + s'afficher sur votre écran !)

Erreurs en cours de démarrage

+ +

Si Apache rencontre un problème fatal pendant le démarrage, il va + afficher un message décrivant le problème sur la console ou + enregistrer ces informations dans le fichier défini par la directive + ErrorLog avant de quitter. + Un des messages d'erreur les plus courants est "Unable + to bind to Port ...". Ce message d'erreur est habituellement + provoqué par:

+ +

Une tentative de démarrage du serveur avec un port privilégié sans + être connecté root; ou
Une tentative de démarrage du serveur alors qu'une autre instance + d'Apache ou un autre serveur web est déjà associé au même port.

+ +

Pour plus d'instructions de dépannage, consultez la + FAQ Apache.

Lancement au démarrage du système

+ +

Si vous souhaitez que votre serveur continue de fonctionner après + un redémarrage du système, vous devez ajouter un appel à + apachectl à vos + fichiers de démarrage système (en général rc.local ou un + fichier dans un répertoire rc.N), ce qui démarrera Apache sous + l'utilisateur root. Avant de faire ceci, assurez-vous que votre serveur + est correctement configuré en ce qui concerne la sécurité et les + restrictions d'accès.

+ +

Le script apachectl est conçu pour fonctionner + comme un script d'initialisation SysV standard; il accepte les arguments + start, restart, et stop + et les traduit en signaux appropriés pour + httpd. Il est ainsi souvent possible d'installer + simplement un lien vers + apachectl dans le répertoire d'initialisation approprié. + Mais prenez soin de vérifier les besoins exacts de votre système + en la matière.

Informations supplémentaires

+ +

Des informations supplémentaires à propos des options en ligne de + commande de httpd et apachectl + ainsi que d'autres programmes support inclus dans la distribution + sont disponibles sur la page + Le serveur et ses programmes support. + Il existe aussi une documentation sur tous les modules inclus dans la distribution Apache + et les directives + qu'ils supportent.

Langues Disponibles: de | + en | + es | + fr | + ja | + ko | + ru

+ \ No newline at end of file diff --git a/docs/manual/invoking.xml.fr b/docs/manual/invoking.xml.fr new file mode 100644 index 00000000000..f6c78036a52 --- /dev/null +++ b/docs/manual/invoking.xml.fr @@ -0,0 +1,157 @@ + + + + + + + + + + + + Démarrage d'Apache + +

+ +

Sous Unix, le programme httpd + est lancé en mode démon et s'exécute de manière permanente en + arrière-plan pour gérer les requêtes. Ce document décrit comment invoquer + httpd.

+ +Arrêt et redémarrage +httpd +apachectl + +

Comment Apache démarre + +

Si la directive Listen + spécifiée dans le fichier de configuration est à sa valeur par défaut + de 80 (ou tout autre port inférieur à 1024), il est nécessaire de + posséder les privilèges root pour pouvoir démarrer apache, et lui + permettre d'être associé à ce port privilégié. Lorsque le serveur est + démarré, après avoir effectué quelques opérations préliminaires + comme ouvrir ses fichiers de log, il lance plusieurs processus + enfants qui ont pour rÃ´le d'écouter et de répondre aux + requêtes des clients. Le processus httpd principal + continue à s'exécuter sous l'utilisateur root, tandis que les processus + enfants s'exécutent sous un utilisateur aux privilèges restreints. + Ceci s'effectue par la voie du + Module Multi-Processus (MPM).

+ +

Il est recommandé d'utiliser le script de contrôle + apachectl pour invoquer l'exécutable + httpd. Avant d'invoquer le binaire + httpd, ce script définit certaines variables + d'environnement nécessaires pour permettre à + httpd de fonctionner correctement sous certains systèmes + d'exploitation. + apachectl accepte des arguments de ligne de commande, + ainsi toute option de httpd peut aussi être utilisée avec + apachectl. Vous pouvez aussi éditer directement le + script apachectl en modifiant la variable + HTTPD située en début de script pour spécifier la + localisation du binaire httpd et tout argument de ligne + de commande que vous souhaitez voir systématiquement présent.

+ +

+ +/usr/local/apache2/bin/apachectl -f + /usr/local/apache2/conf/httpd.conf + +

Si tout se passe bien pendant le démarrage, le serveur va se dissocier + du terminal et l'invite de commande réapparaîtra presque immédiatement. + Ceci indique que le serveur a démarré et est en cours d'exécution. + À partir de ce moment, vous pouvez utiliser votre navigateur pour vous connecter + au serveur et afficher la page de test située dans le répertoire défini + par la directive DocumentRoot, + ainsi qu'une copie locale de la documentation sous forme d'un lien + situé sur cette page. + (note du traducteur : en fait, vous ne devriez voir que "It works !" + s'afficher sur votre écran !)

+ +

Erreurs en cours de démarrage + +

Si Apache rencontre un problème fatal pendant le démarrage, il va + afficher un message décrivant le problème sur la console ou + enregistrer ces informations dans le fichier défini par la directive + ErrorLog avant de quitter. + Un des messages d'erreur les plus courants est "Unable + to bind to Port ...". Ce message d'erreur est habituellement + provoqué par:

+ +

Une tentative de démarrage du serveur avec un port privilégié sans + être connecté root; ou
Une tentative de démarrage du serveur alors qu'une autre instance + d'Apache ou un autre serveur web est déjà associé au même port.

+ +

Pour plus d'instructions de dépannage, consultez la + FAQ Apache.

+ +

Lancement au démarrage du système + +

Si vous souhaitez que votre serveur continue de fonctionner après + un redémarrage du système, vous devez ajouter un appel à + apachectl à vos + fichiers de démarrage système (en général rc.local ou un + fichier dans un répertoire rc.N), ce qui démarrera Apache sous + l'utilisateur root. Avant de faire ceci, assurez-vous que votre serveur + est correctement configuré en ce qui concerne la sécurité et les + restrictions d'accès.

+ +

Le script apachectl est conçu pour fonctionner + comme un script d'initialisation SysV standard; il accepte les arguments + start, restart, et stop + et les traduit en signaux appropriés pour + httpd. Il est ainsi souvent possible d'installer + simplement un lien vers + apachectl dans le répertoire d'initialisation approprié. + Mais prenez soin de vérifier les besoins exacts de votre système + en la matière.

+ +

Informations supplémentaires + +

Des informations supplémentaires à propos des options en ligne de + commande de httpd et apachectl + ainsi que d'autres programmes support inclus dans la distribution + sont disponibles sur la page + Le serveur et ses programmes support. + Il existe aussi une documentation sur tous les modules inclus dans la distribution Apache + et les directives + qu'ils supportent.

+ + diff --git a/docs/manual/mpm.html.fr b/docs/manual/mpm.html.fr new file mode 100644 index 00000000000..d872e8db51b --- /dev/null +++ b/docs/manual/mpm.html.fr @@ -0,0 +1,129 @@ + + + +Modules multi-processus (MPMs) - Serveur Apache HTTP + + + + + +

+Apache > Serveur HTTP > Documentation > Version 2.2

Modules multi-processus (MPMs)

Langues Disponibles: de | + en | + es | + fr | + ja | + ko

+ +

Ce document décrit ce qu'est un Module Multi-Processus, ainsi +que la manière dont ces modules sont utilisés par le serveur HTTP Apache.

Introduction
Choisir un MPM
MPM par défaut

Introduction

+ +

Le serveur HTTP Apache a été conçu comme un serveur web puissant et + flexible pouvant fonctionner sur une très grande variété de + plateformes et toute une gamme d'environnements différents. Plateformes + différentes et environnements différents signifient souvent fonctionnalités + différentes, ou utilisation de différentes méthodes pour + implémenter la même fonctionnalité le plus efficacement possible. + Apache s'est toujours accomodé d'une grande variété d'environnements + grâce à sa conception modulaire. Cette conception autorise le webmaster + à choisir quelles fonctionnalités seront incluses + dans le serveur en sélectionnant les modules à charger soit à la + compilation, soit à l'exécution.

+ +

Apache 2.0 étend cette conception modulaire aux fonctions les plus + élémentaires d'un serveur web. Certains Modules Multi-Processus (MPMs) + sont responsables de l'association aux ports réseau de la machine, + acceptent les requêtes, et se chargent de répartir ces dernières + entre les différents processus enfants.

+ +

L'extension de la conception modulaire à ce niveau du serveur + comporte deux avantages importants:

+ +

Apache peut supporter plus proprement et efficacement une grande + variété de systèmes d'exploitation. En particulier, la version Windows + d'Apache est maintenant beaucoup plus efficace, depuis que + mpm_winnt peut utiliser les fonctionnalités réseau + natives à la place de la couche POSIX utilisée par + Apache 1.3. Cet avantage s'étend aussi aux systèmes d'exploitation + qui implémentent des MPMs spécialisés.
le serveur est plus à même de répondre aux besoins d'un site + particulier. Par exemple, les sites qui sont très sollicités peuvent + utiliser un MPM threadé comme + worker ou event, tandis que les sites + qui privilégient la stabilité ou la compatibilité avec des logiciels + plus anciens peuvent utiliser un module comme + prefork.

+ +

Du point de vue de l'utilisateur, les MPMs ne sont pas différents des + autres modules Apache. La principale différence réside dans le fait qu'un + et un seul MPM à la fois doit être chargé dans le serveur. La liste des + MPMs disponibles est fournie dans module index page.

+ +

Choisir un MPM

+ +

Les MPMs doivent être choisis à la configuration, et compilés avec + le serveur. Les compilateurs peuvent optimiser de nombreuses fonctions + si les threads sont utilisés, mais seulement s'ils savent que les threads + sont utilisés.

+ +

Pour le choix proprement dit du MPM désiré, utiliser l'argument + --with-mpm=NOM du script + configure. NOM est le nom + du MPM désiré.

+ +

Une fois le serveur compilé, il est possible de savoir quel MPM + a été choisi à l'aide de la commande ./httpd -l. + Cette commande fournit la liste de tous les modules compilés + avec le serveur, y compris le MPM.

MPM par défaut

+ +

La table suivante fournit la liste des MPMs par défaut pour divers +systèmes d'exploitation. Il s'agit du MPM sélectionné si vous ne précisez +pas un choix différent à la compilation.

+ + + + + + + + +

BeOS	`beos`
Netware	`mpm_netware`
OS/2	`mpmt_os2`
Unix	`prefork`
Windows	`mpm_winnt`

Langues Disponibles: de | + en | + es | + fr | + ja | + ko

+ \ No newline at end of file diff --git a/docs/manual/mpm.xml.fr b/docs/manual/mpm.xml.fr new file mode 100644 index 00000000000..e38c800f6fb --- /dev/null +++ b/docs/manual/mpm.xml.fr @@ -0,0 +1,116 @@ + + + + + + + + + + + + Modules multi-processus (MPMs) + +

Ce document décrit ce qu'est un Module Multi-Processus, ainsi +que la manière dont ces modules sont utilisés par le serveur HTTP Apache.

+ +

Introduction + +

+ +

L'extension de la conception modulaire à ce niveau du serveur + comporte deux avantages importants:

+ +

Apache peut supporter plus proprement et efficacement une grande + variété de systèmes d'exploitation. En particulier, la version Windows + d'Apache est maintenant beaucoup plus efficace, depuis que + mpm_winnt peut utiliser les fonctionnalités réseau + natives à la place de la couche POSIX utilisée par + Apache 1.3. Cet avantage s'étend aussi aux systèmes d'exploitation + qui implémentent des MPMs spécialisés.
le serveur est plus à même de répondre aux besoins d'un site + particulier. Par exemple, les sites qui sont très sollicités peuvent + utiliser un MPM threadé comme + worker ou event, tandis que les sites + qui privilégient la stabilité ou la compatibilité avec des logiciels + plus anciens peuvent utiliser un module comme + prefork.

+ +

Choisir un MPM + +

+ +

Pour le choix proprement dit du MPM désiré, utiliser l'argument + --with-mpm=NOM du script + configure. NOM est le nom + du MPM désiré.

+ +

MPM par défaut + +

La table suivante fournit la liste des MPMs par défaut pour divers +systèmes d'exploitation. Il s'agit du MPM sélectionné si vous ne précisez +pas un choix différent à la compilation.

+ + + + + + + + +

BeOS	beos
Netware	mpm_netware
OS/2	mpmt_os2
Unix	prefork
Windows	mpm_winnt

+ + diff --git a/docs/manual/new_features_2_2.html.fr b/docs/manual/new_features_2_2.html.fr new file mode 100644 index 00000000000..bbf69c0c37b --- /dev/null +++ b/docs/manual/new_features_2_2.html.fr @@ -0,0 +1,305 @@ + + + +Aperçu des nouvelles fonctionnalités dans Apache 2.2 - Serveur Apache HTTP + + + + + +

+Apache > Serveur HTTP > Documentation > Version 2.2

Aperçu des nouvelles fonctionnalités dans Apache 2.2

Langues Disponibles: en | + fr | + ko | + pt-br

+ +

Ce document décrit quelques uns des changements principaux entre + les versions 2.0 et 2.2 du serveur HTTP Apache. Pour les + nouvelles fonctionnalités ajoutées depuis la version 1.3, se + référer au document + 2.0 new features.

Améliorations du système de base
Améliorations des modules
Améliorations des programmes
Changements pour le développeur de module

Améliorations du système de base

+ +

Authn/Authz

Les modules d'authentification et d'autorisation intégrés + ont été refondus. Le nouveau module + mod_authn_alias permet de + simplifier considérablement certaines configurations d'authentification. + Voir modification des noms de modules, + et + les changements pour le développeur + pour plus d'informations sur les conséquences de ces + changements pour les utilisateurs et les développeurs de + modules.

Mise en cache

mod_cache, mod_disk_cache, et + mod_mem_cache ont subi de nombreuses + modifications, et l'on considère qu'ils ont maintenant atteint + un degré de qualité suffisant pour leur mise en production. Le programme + htcacheclean a été ajouté afin de rendre + plus propre la configuration du module + mod_disk_cache.

Configuration

L'agencement de la configuration par défaut a été simplifié + et modularisé. Les portions de configuration qui peuvent être + utilisées pour activer des fonctionnalités courantes sont + maintenant intégrées à Apache, et peuvent être facilement + ajoutées à la configuration principale du serveur.

Arrêt en douceur

Les modules MPM prefork, + worker et event permettent + maintenant l'arrêt en douceur de httpd + au moyen du signal + graceful-stop. + La directive GracefulShutdownTimeout a été ajoutée dans le but + de spécifier un délai optionnel, après lequel + httpd s'arrêtera quel que soit le statut + des requêtes en cours.

Mise en oeuvre du proxy

Le nouveau module mod_proxy_balancer fournit + des services de répartition de charge (load balancing) pour le + module mod_proxy. + Le nouveau module mod_proxy_ajp ajoute le + support pour le + Protocole JServ de Apache version 1.3 qu'utilise + Apache Tomcat.

Mise à jour de la bibliothèque des expressions rationnelles

La version 5.0 de la + Perl Compatible Regular Expression + Library (PCRE) est maintenant disponible. + httpd peut être configuré pour utiliser une + PCRE choisie en passant l'option --with-pcre au + script configure.

Filtrage intelligent

Le module mod_filter permet la configuration + dynamique de la chaîne de filtrage en sortie. Il permet + d'insérer des filtres conditionnels basés sur toute + requête, en-tête de réponse ou variable + d'environnement, et fait table rase des problèmes de dépendances + et d'ordonnancement rencontrés avec l'architecture 2.0.

Support des gros fichiers

httpd supporte maintenant les fichiers d'une taille supérieure + à 2GB sur les systèmes 32 bits UNIX modernes. Le support des + corps de requête d'une taille supérieure à 2GB a aussi été + ajouté.

Module MPM Event

Le module MPM event utilise un thread séparé + pour gérer les requêtes "Keep alive" et accepter des connexions. + Les requêtes "Keep alive" requéraient traditionnellement un + processus httpd dédié pour leur gestion. Ce processus dédié + ne pouvait plus être réutilisé jusqu'à ce que le délai "Keep Alive" + soit écoulé.

Support des bases de données SQL

Le module

mod_dbd, associé à l'environnement + apr_dbd, fournit le support SQL direct aux modules + qui en ont besoin. Supporte la mise en commun des connexions + dans les modules MPM threadés.

Utilisateurs Windows : veuillez noter que ce + support n'est pas encore inclus dans l'implémentation Windows + standard. Si vous l'utilisez sur la plate-forme + Windows, merci de nous faire savoir comment vous vous y + prenez.

Améliorations des modules

+ +

Authn/Authz: Les modules du répertoire aaa ont été renommés et fournissent + un support amélioré pour la méthode d'authentification digest. Par exemple, mod_auth + est maintenant scindé en deux modules : mod_auth_basic et + mod_authn_file; mod_auth_dbm s'appelle maintenant + mod_authn_dbm; mod_access a été renommé en + mod_authz_host. Est également apparu le nouveau module + mod_authn_alias qui simplifie + certaines configurations d'authentification. +
mod_authnz_ldap: Ce module est un portage de la version 2.0 du module + mod_auth_ldap vers la version 2.2 du framework + Authn/Authz. + Les nouvelles fonctionnalités comprennent l'utilisation des valeurs + d'attributs LDAP et des filtres de recherche avancés dans la + directive Require.
mod_authz_owner: Ce nouveau module propose une gestion des droits d'accès aux ressources web selon leur appartenance + à un utilisateur au niveau du système de fichiers.
mod_version: Ce nouveau module permet de définir des blocs de configuration activables selon le numéro de version du serveur en fonctionnement.
mod_info: Un nouvel argument ?config a été ajouté, qui permettra d'afficher + les directives de configuration telles qu'elles sont interprétées + par Apache, y compris le nom de fichier et le numéro de ligne. + Le module montre aussi l'ordre des point d'entrée de traitement d'une + requête (request hooks) ainsi que des informations de construction + supplémentaires, d'une manière similaire à httpd -V.
mod_ssl: Le support de RFC 2817, a été ajouté, ce qui permet de passer d'une + connexion en clair au cryptage TLS.
mod_imagemap: mod_imap a été renommé en mod_imagemap afin + d'éviter une confusion pour les utilisateurs.

+ +

Améliorations des programmes

+ +

httpd: Une nouvelle option de ligne de commande -M + a été ajoutée, qui fournit la liste de tous les modules chargés + en fonction de la configuration réelle. À la différence de l'option + -l, cette liste inclut les Objets Dynamiques Partagés + (DSOs) chargés par l'intermédiaire du module + mod_so.
httxt2dbm: Un nouveau programme servant à générer des fichiers dbm à partir + d'une source texte, à utiliser avec la directive + RewriteMap + et le type de mise en correspondance dbm.

Changements pour le développeur de module

+ +

APR 1.0 API

Apache 2.2 utilise l'API APR 1.0. Toutes les fonctions et + symboles obsolètes ont été supprimés du code de APR et + APR-Util. Pour plus de détails, consultez le + site web de APR.

Authn/Authz

Les modules d'authentification et d'autorisation intégrés ont + été renommés de la manière suivante: +

mod_auth_* -> Modules qui implémentent un mécanisme + d'authentification HTTP
mod_authn_* -> Modules qui fournissent un dispositif + d'authentification en arrière-plan
mod_authz_* -> Modules qui implémentent l'autorisation (ou l'accès)
mod_authnz_*-> Module qui implémentent à la fois + l'authentification & l'autorisation

+ L'organisation des méthodes d'authentification a également été revue, ce qui va simplifier + grandement l'ajout de nouvelles méthodes d'authentification.

Journalisation des erreurs de connexion

Une nouvelle fonction a été ajoutée, ap_log_cerror, + afin de pouvoir enregistrer les erreurs qui surviennent au cours de + la connexion du client. Une fois enregistré, le message inclut l'adresse IP du client.

Ajout d'une portion de code pour la vérification de la configuration

Un nouvel élément de traitement a été ajouté, test_config, + afin d'aider les modules qui ne veulent exécuter un code spécial + que si l'utilisateur passe le paramètre -t à + httpd.

Définition de la taille de la pile pour les modules MPM threadés

Une nouvelle directive a été ajoutée, ThreadStackSize + afin de définir la taille de la pile pour tous les modules MPM threadés. + Ceci s'avère nécessaire pour certains modules tiers sur des plateformes + dont la taille de la pile des threads par défaut est + trop petite.

Gestion de protocole pour les filtres en sortie

Par le passé, chaque filtre devait s'assurer que les en-têtes de + réponse corrects étaient générés dans la mesure où il les affectait. + Les filtres peuvent maintenant déléguer la gestion courante du + protocole au module + mod_filter, à l'aide des appels + ap_register_output_filter_protocol ou + ap_filter_protocol.

Ajout d'un élément de traitement pour le processus père (monitor hook)

Ce nouvel élément de traitement permet aux modules de lancer + des jobs réguliers/planifiés au niveau du processus père + (root).

Modifications de l'API de traitement des expressions régulières

Le fichier d'en-tête pcreposix.h n'est plus disponible; + il a été remplacé par le nouveau fichier + d'en-tête ap_regex.h. L'implémentation + POSIX.2 regex.h exposée dans l'ancien fichier d'en-tête + est maintenant disponible dans l'espace de nommage ap_ + depuis ap_regex.h. Les appels à regcomp, + regexec, etc... peuvent être remplacés par des appels à + ap_regcomp, ap_regcomp.

Cadre d'application DBD (API pour base de données SQL)

Avec Apache 1.x et 2.0, les modules nécessitant un processus + SQL d'arrière-plan devaient s'en charger eux-mêmes. En dehors du fait + de réinventer la roue, ceci peut s'avérer très inefficace, par + exemple lorsque plusieurs modules maintiennent chacun leurs + propres connexions.

Apache 2.1 et supérieur fournissent l'API ap_dbd qui + permet la gestion des connexions à la base de données (y compris + les stratégies optimisées pour les modules MPM threadés + et non threadés), tandis que APR 1.2 et supérieur fournissent + l'API apr_dbd qui permet l'interaction avec la + base de données.

Les nouveaux modules DEVRAIENT désormais utiliser ces APIs pour + toutes les opérations liées aux bases de données SQL. + De même, les applications existantes DEVRAIENT être mises à jour + lorsque c'est possible, soit de manière transparente ou sous forme + d'une option recommandée à leurs utilisateurs.

Langues Disponibles: en | + fr | + ko | + pt-br

+ \ No newline at end of file diff --git a/docs/manual/new_features_2_2.xml.fr b/docs/manual/new_features_2_2.xml.fr new file mode 100644 index 00000000000..0cac54fcafe --- /dev/null +++ b/docs/manual/new_features_2_2.xml.fr @@ -0,0 +1,296 @@ + + + + + + + + + + + +Aperçu des nouvelles fonctionnalités dans Apache 2.2 + +

+ +

+ Améliorations du système de base +

Authn/Authz

Les modules d'authentification et d'autorisation intégrés + ont été refondus. Le nouveau module + mod_authn_alias permet de + simplifier considérablement certaines configurations d'authentification. + Voir modification des noms de modules, + et + les changements pour le développeur + pour plus d'informations sur les conséquences de ces + changements pour les utilisateurs et les développeurs de + modules.

Mise en cache

mod_cache, mod_disk_cache, et + mod_mem_cache ont subi de nombreuses + modifications, et l'on considère qu'ils ont maintenant atteint + un degré de qualité suffisant pour leur mise en production. Le programme + htcacheclean a été ajouté afin de rendre + plus propre la configuration du module + mod_disk_cache.

Configuration

Arrêt en douceur

Les modules MPM prefork, + worker et event permettent + maintenant l'arrêt en douceur de httpd + au moyen du signal + graceful-stop. + La directive GracefulShutdownTimeout a été ajoutée dans le but + de spécifier un délai optionnel, après lequel + httpd s'arrêtera quel que soit le statut + des requêtes en cours.

Mise en oeuvre du proxy

Le nouveau module mod_proxy_balancer fournit + des services de répartition de charge (load balancing) pour le + module mod_proxy. + Le nouveau module mod_proxy_ajp ajoute le + support pour le + Protocole JServ de Apache version 1.3 qu'utilise + Apache Tomcat.

Mise à jour de la bibliothèque des expressions rationnelles

La version 5.0 de la + Perl Compatible Regular Expression + Library (PCRE) est maintenant disponible. + httpd peut être configuré pour utiliser une + PCRE choisie en passant l'option --with-pcre au + script configure.

Filtrage intelligent

Le module mod_filter permet la configuration + dynamique de la chaîne de filtrage en sortie. Il permet + d'insérer des filtres conditionnels basés sur toute + requête, en-tête de réponse ou variable + d'environnement, et fait table rase des problèmes de dépendances + et d'ordonnancement rencontrés avec l'architecture 2.0.

Support des gros fichiers

Module MPM Event

Le module MPM event utilise un thread séparé + pour gérer les requêtes "Keep alive" et accepter des connexions. + Les requêtes "Keep alive" requéraient traditionnellement un + processus httpd dédié pour leur gestion. Ce processus dédié + ne pouvait plus être réutilisé jusqu'à ce que le délai "Keep Alive" + soit écoulé.

Support des bases de données SQL

Le module

mod_dbd, associé à l'environnement + apr_dbd, fournit le support SQL direct aux modules + qui en ont besoin. Supporte la mise en commun des connexions + dans les modules MPM threadés.

+ +

+ Améliorations des modules +

Authn/Authz: Les modules du répertoire aaa ont été renommés et fournissent + un support amélioré pour la méthode d'authentification digest. Par exemple, mod_auth + est maintenant scindé en deux modules : mod_auth_basic et + mod_authn_file; mod_auth_dbm s'appelle maintenant + mod_authn_dbm; mod_access a été renommé en + mod_authz_host. Est également apparu le nouveau module + mod_authn_alias qui simplifie + certaines configurations d'authentification. +
mod_authnz_ldap: Ce module est un portage de la version 2.0 du module + mod_auth_ldap vers la version 2.2 du framework + Authn/Authz. + Les nouvelles fonctionnalités comprennent l'utilisation des valeurs + d'attributs LDAP et des filtres de recherche avancés dans la + directive Require.
mod_authz_owner: Ce nouveau module propose une gestion des droits d'accès aux ressources web selon leur appartenance + à un utilisateur au niveau du système de fichiers.
mod_version: Ce nouveau module permet de définir des blocs de configuration activables selon le numéro de version du serveur en fonctionnement.
mod_info: Un nouvel argument ?config a été ajouté, qui permettra d'afficher + les directives de configuration telles qu'elles sont interprétées + par Apache, y compris le nom de fichier et le numéro de ligne. + Le module montre aussi l'ordre des point d'entrée de traitement d'une + requête (request hooks) ainsi que des informations de construction + supplémentaires, d'une manière similaire à httpd -V.
mod_ssl: Le support de RFC 2817, a été ajouté, ce qui permet de passer d'une + connexion en clair au cryptage TLS.
mod_imagemap: mod_imap a été renommé en mod_imagemap afin + d'éviter une confusion pour les utilisateurs.

+ +

+ Améliorations des programmes +

httpd: Une nouvelle option de ligne de commande -M + a été ajoutée, qui fournit la liste de tous les modules chargés + en fonction de la configuration réelle. À la différence de l'option + -l, cette liste inclut les Objets Dynamiques Partagés + (DSOs) chargés par l'intermédiaire du module + mod_so.
httxt2dbm: Un nouveau programme servant à générer des fichiers dbm à partir + d'une source texte, à utiliser avec la directive + RewriteMap + et le type de mise en correspondance dbm.

+ +

+ Changements pour le développeur de module +

APR 1.0 API

Apache 2.2 utilise l'API APR 1.0. Toutes les fonctions et + symboles obsolètes ont été supprimés du code de APR et + APR-Util. Pour plus de détails, consultez le + site web de APR.

Authn/Authz

Les modules d'authentification et d'autorisation intégrés ont + été renommés de la manière suivante: +

mod_auth_* -> Modules qui implémentent un mécanisme + d'authentification HTTP
mod_authn_* -> Modules qui fournissent un dispositif + d'authentification en arrière-plan
mod_authz_* -> Modules qui implémentent l'autorisation (ou l'accès)
mod_authnz_*-> Module qui implémentent à la fois + l'authentification & l'autorisation

+ L'organisation des méthodes d'authentification a également été revue, ce qui va simplifier + grandement l'ajout de nouvelles méthodes d'authentification.

Journalisation des erreurs de connexion

Ajout d'une portion de code pour la vérification de la configuration

Un nouvel élément de traitement a été ajouté, test_config, + afin d'aider les modules qui ne veulent exécuter un code spécial + que si l'utilisateur passe le paramètre -t à + httpd.

Définition de la taille de la pile pour les modules MPM threadés

Gestion de protocole pour les filtres en sortie

Par le passé, chaque filtre devait s'assurer que les en-têtes de + réponse corrects étaient générés dans la mesure où il les affectait. + Les filtres peuvent maintenant déléguer la gestion courante du + protocole au module + mod_filter, à l'aide des appels + ap_register_output_filter_protocol ou + ap_filter_protocol.

Ajout d'un élément de traitement pour le processus père (monitor hook)

Ce nouvel élément de traitement permet aux modules de lancer + des jobs réguliers/planifiés au niveau du processus père + (root).

Modifications de l'API de traitement des expressions régulières

Cadre d'application DBD (API pour base de données SQL)

+ diff --git a/docs/manual/stopping.html.fr b/docs/manual/stopping.html.fr new file mode 100644 index 00000000000..d8182e2f15e --- /dev/null +++ b/docs/manual/stopping.html.fr @@ -0,0 +1,275 @@ + + + +Arrêt et redémarrage - Serveur Apache HTTP + + + + + +

+Apache > Serveur HTTP > Documentation > Version 2.2

Arrêt et redémarrage

Langues Disponibles: de | + en | + es | + fr | + ja | + ko

+ +

Ce document couvre l'arrêt et le redémarrage d'Apache sur + les systèmes Unix et similaires. Les utilisateurs de Windows NT, 2000 + and XP doivent consulter + Exécuter Apache en tant que + service et les utilisateurs de Windows 9x et ME doivent consulter + Exécuter Apache comme une + application de type console pour plus d'informations sur le contrôle + d'Apache à partir de ces plateformes.

Introduction
Arrêter immédiatement
Redémarrage en douceur
Redémarrer immédiatement
Arrêt en douceur

Voir aussi

Introduction

+ +

Afin d'arrêter ou redémarrer Apache, vous devez envoyer un signal aux + processus httpd en cours d'exécution. Les signaux + peuvent être envoyés de deux manières. Tout d'abord, vous pouvez + utiliser la commande unix kill + pour envoyer directement des signaux aux processus. Vous pouvez remarquer + que plusieurs processus httpd s'exécutent sur votre + système, mais il vous suffit d'envoyer les signaux au processus parent, + dont le PID est enregistré dans le fichier précisé par la directive + PidFile. C'est à dire que vous + n'aurez jamais besoin d'envoyer des signaux à aucun de ces processus, + sauf au processus parent. Trois types de signaux peuvent être envoyés + au processus parent : + TERM, + USR1, + HUP, et + WINCH, qui + sera décrit plus loin.

+ +

Pour envoyer un signal au processus parent, vous devez entrer une commande + du style :

+ +

kill -TERM `cat /usr/local/apache2/logs/httpd.pid`

+ +

La seconde méthode permettant d'envoyer des signaux aux processus + httpd + consiste à utiliser les options de ligne de commande -k : + stop, + restart, graceful et graceful-stop, + comme décrit ci-dessous. Ce sont des arguments du binaire + httpd, mais il est recommandé de les utiliser + avec le script de contrôle apachectl, qui se + chargera de les passer à httpd.

+ +

Après avoir envoyé un signal à httpd, vous pouvez + suivre le cours de son action en entrant :

+ +

tail -f /usr/local/apache2/logs/error_log

+ +

Adaptez ces exemples en fonction de la définition de vos directives + ServerRoot et + PidFile.

Arrêter immédiatement

+ +

Signal: TERM: apachectl -k stop

+ +

L'envoi du signal TERM ou stop au + processus parent induit chez celui-ci une tentative immédiate + de tuer tous ses processus enfants. Cela peut durer plusieurs secondes. + Après cela, le processus parent lui-même se termine. Toutes les requêtes + en cours sont terminées, et plus aucune autre n'est traitée.

Redémarrage en douceur

+ +

Signal: USR1: apachectl -k graceful

+ +

L'envoi du signal USR1 ou graceful au + processus parent lui fait envoyer aux processus enfants + l'ordre de se terminer une fois leur requête courante + traitée (ou de se terminer immédiatement s'ils n'ont plus rien à traiter). + Le processus parent relit ses fichiers de configuration et + réouvre ses fichiers de log. Chaque fois qu'un enfant s'éteint, le + processus parent le remplace par un processus + enfant de la nouvelle génération de la + configuration, et celui-ci commence immédiatement à traiter les + nouvelles requêtes.

+ +

Ce code est conçu pour toujours respecter la directive de contrôle + de processus des modules MPMs, afin que les nombres de processus et de + threads + disponibles pour traiter les demandes des clients soient maintenus à + des valeurs appropriées tout au long du processus de démarrage. + En outre, il respecte la directive + StartServers de la manière + suivante : si après une seconde au moins StartServers nouveaux processus + enfants n'ont pas été créés, un nombre suffisant de processus + supplémentaires est créé pour combler le manque. Ainsi le code + tente de maintenir à la fois le nombre approprié de processus enfants + en fonction de la charge du serveur, et vos souhaits définis par la + directive StartServers.

+ +

Les utilisateurs du module mod_status + noteront que les statistiques du serveur ne sont pas + remises à zéro quand un signal USR1 est envoyé. Le code + a été conçu à la fois pour minimiser la durée durant laquelle le + serveur ne peut pas traiter de nouvelles requêtes (elle sont mises en + file d'attente par le système d'exploitation, et ne sont ainsi jamais + perdues) et pour respecter vos paramètres de personnalisation. + Afin d'accomplir ceci, il doit conserver le + tableau utilisé pour garder la trace de tous les processus + enfants au cours des différentes générations.

+ +

Le module status utilise aussi un G afin d'indiquer + quels processus enfants ont encore des traitements de requêtes en cours + débutés avant que l'ordre graceful restart ne soit donné.

+ +

Pour l'instant, il est impossible pour un script de rotation + des logs utilisant + USR1 de savoir de manière certaine si tous les processus + enfants inscrivant des traces de pré-redémarrage sont terminés. + Nous vous suggérons d'attendre un délai suffisant après l'envoi du + signal USR1 + avant de faire quoi que ce soit avec les anciens logs. Par exemple, + si la plupart de vos traitements durent moins de 10 minutes pour des + utilisateurs empruntant des liaisons à faible bande passante, alors vous + devriez attendre 15 minutes avant de faire quoi que ce soit + avec les anciens logs.

+ +

+ Si votre fichier de configuration comporte des erreurs lorsque vous + effectuez un redémarrage, votre processus parent ne redémarrera pas + et se terminera avec une erreur. Dans le cas d'un redémarrage en douceur + (graceful restart), il laissera les processus enfants + s'exécuter quand il s'arrêtera. (Ce sont les processus enfants qui + "s'arrêtent en douceur" en terminant de traiter leur dernière requête.) + Ceci provoquera des problèmes si vous tentez de redémarrer le serveur + -- il ne pourra pas s'associer à ses ports d'écoute. Avant d'effectuer un + redémarrage, vous pouvez vérifier la syntaxe des fichiers de + configuration à l'aide de l'argument de ligne de commande -t + (voir httpd). + + Ceci ne garantit pas encore que le serveur va redémarrer + correctement. Pour vérifier la sémantique des fichiers de configuration + en plus de leur syntaxe, vous pouvez essayer de démarrer + httpd sous un utilisateur non root. + S'il n'y a pas d'erreurs, il tentera d'ouvrir ses sockets et ses fichiers + de log et échouera car il n'a pas les privilèges root (ou parce que + l'instance actuelle de + httpd est déjà associée à ces ports). S'il échoue + pour toute autre raison, il y a probablement une erreur dans le + fichier de configuration et celle-ci doit être corrigée avant de lancer + le redémarrage en douceur.

Redémarrer immédiatement

+ +

Signal: HUP: apachectl -k restart

+ +

L'envoi du signal HUP ou restart au + processus parent lui fait tuer ses processus enfants comme pour le signal + TERM, mais le processus parent ne se termine pas. + Il relit ses fichiers de configuration, et réouvre ses fichiers de log. + Puis il donne naissance à un nouveau jeu de processus enfants + et continue de traiter les requêtes.

+ +

Les utilisateurs du module mod_status + noteront que les statistiques du serveur sont remises à zéro quand un + signal HUP est envoyé.

+ +

Si votre fichier de configuration comporte des erreurs quand vous +effectuez un redémarrage, votre processus parent ne redémarrera pas, +il se terminera avec une erreur. Voir plus haut la méthode à employer +pour éviter ce problème.

Arrêt en douceur

+ +

Signal : WINCH: apachectl -k graceful-stop

+ +

L'envoi du signal WINCH ou graceful-stop + au processus parent lui fait aviser les processus enfants + de s'arrêter après le traitement de leur requête en cours + (ou de s'arrêter immédiatement s'ils n'ont plus de requête à traiter). + Le processus parent va alors supprimer son fichier + PidFile et cesser l'écoute + de tous ses ports. Le processus parent va continuer à s'exécuter, + et va surveiller les processus enfants + qui ont encore des requêtes à traiter. Lorsque tous les processus enfants + ont terminé leurs traitements et se sont arrêtés ou lorsque le délai + spécifié par la directive GracefulShutdownTimeout a été atteint, + le processus parent s'arrêtera à son tour. Si ce délai est atteint, + tout processus enfant encore en cours d'exécution se verra envoyer + le signal TERM + afin de le forcer à s'arrêter.

+ +

L'envoi du signal TERM va arrêter immédiatement + les processus parent et enfants en état "graceful". Cependant, + comme le fichier PidFile + aura été supprimé, vous ne pourrez pas utiliser + apachectl ou httpd pour envoyer ce signal.

+ +

Le signal graceful-stop vous permet d'exécuter + simultanément plusieurs instances de httpd + avec des configurations identiques. Ceci s'avère une fonctionnalité + puissante quand vous effectuez des mises à jour "en douceur" d'Apache; + cependant, cela peut aussi causer des blocages fatals et des + situations de compétition (race conditions) + avec certaines configurations.

+ +

On a pris soin de s'assurer que les fichiers sur disque + comme ceux définis par les directives + Lockfile et + ScriptSock contiennent le PID + du serveur dans leurs noms donc ils coexistent sans problème. + Cependant, si une directive de + configuration , un module tiers ou une CGI résidente utilise un autre + verrou ou fichier d'état sur disque, il faut prendre soin de s'assurer + que chaque instance de httpd qui s'exécute + n'écrase pas les fichiers des autres instances.

+ +

Vous devez aussi prendre garde aux autres situations de compétition, + comme l'utilisation de l'enregistrement des logs avec un transfert de ceux-ci + dans le style rotation des logs. Plusieurs instances + du programme de rotation des logs qui tentent d'effectuer + une rotation des mêmes fichiers de log en même temps peuvent détruire + mutuellement leurs propres fichiers de log.

Langues Disponibles: de | + en | + es | + fr | + ja | + ko

+ \ No newline at end of file diff --git a/docs/manual/stopping.xml.fr b/docs/manual/stopping.xml.fr new file mode 100644 index 00000000000..b3a34d847e6 --- /dev/null +++ b/docs/manual/stopping.xml.fr @@ -0,0 +1,266 @@ + + + + + + + + + + + + Arrêt et redémarrage + +

+ +httpd +apachectl +Démarrage + +

Introduction + +

Afin d'arrêter ou redémarrer Apache, vous devez envoyer un signal aux + processus httpd en cours d'exécution. Les signaux + peuvent être envoyés de deux manières. Tout d'abord, vous pouvez + utiliser la commande unix kill + pour envoyer directement des signaux aux processus. Vous pouvez remarquer + que plusieurs processus httpd s'exécutent sur votre + système, mais il vous suffit d'envoyer les signaux au processus parent, + dont le PID est enregistré dans le fichier précisé par la directive + PidFile. C'est à dire que vous + n'aurez jamais besoin d'envoyer des signaux à aucun de ces processus, + sauf au processus parent. Trois types de signaux peuvent être envoyés + au processus parent : + TERM, + USR1, + HUP, et + WINCH, qui + sera décrit plus loin.

+ +

Pour envoyer un signal au processus parent, vous devez entrer une commande + du style :

+ +kill -TERM `cat /usr/local/apache2/logs/httpd.pid` + +

La seconde méthode permettant d'envoyer des signaux aux processus + httpd + consiste à utiliser les options de ligne de commande -k : + stop, + restart, graceful et graceful-stop, + comme décrit ci-dessous. Ce sont des arguments du binaire + httpd, mais il est recommandé de les utiliser + avec le script de contrôle apachectl, qui se + chargera de les passer à httpd.

+ +

Après avoir envoyé un signal à httpd, vous pouvez + suivre le cours de son action en entrant :

+ +tail -f /usr/local/apache2/logs/error_log + +

Adaptez ces exemples en fonction de la définition de vos directives + ServerRoot et + PidFile.

+ +

Arrêter immédiatement + +

Signal: TERM: apachectl -k stop

+ +

Redémarrage en douceur + +

Signal: USR1: apachectl -k graceful

+ +

Ce code est conçu pour toujours respecter la directive de contrôle + de processus des modules MPMs, afin que les nombres de processus et de + threads + disponibles pour traiter les demandes des clients soient maintenus à + des valeurs appropriées tout au long du processus de démarrage. + En outre, il respecte la directive + StartServers de la manière + suivante : si après une seconde au moins StartServers nouveaux processus + enfants n'ont pas été créés, un nombre suffisant de processus + supplémentaires est créé pour combler le manque. Ainsi le code + tente de maintenir à la fois le nombre approprié de processus enfants + en fonction de la charge du serveur, et vos souhaits définis par la + directive StartServers.

+ +

Les utilisateurs du module mod_status + noteront que les statistiques du serveur ne sont pas + remises à zéro quand un signal USR1 est envoyé. Le code + a été conçu à la fois pour minimiser la durée durant laquelle le + serveur ne peut pas traiter de nouvelles requêtes (elle sont mises en + file d'attente par le système d'exploitation, et ne sont ainsi jamais + perdues) et pour respecter vos paramètres de personnalisation. + Afin d'accomplir ceci, il doit conserver le + tableau utilisé pour garder la trace de tous les processus + enfants au cours des différentes générations.

+ +

Le module status utilise aussi un G afin d'indiquer + quels processus enfants ont encore des traitements de requêtes en cours + débutés avant que l'ordre graceful restart ne soit donné.

+ +

+ + + Si votre fichier de configuration comporte des erreurs lorsque vous + effectuez un redémarrage, votre processus parent ne redémarrera pas + et se terminera avec une erreur. Dans le cas d'un redémarrage en douceur + (graceful restart), il laissera les processus enfants + s'exécuter quand il s'arrêtera. (Ce sont les processus enfants qui + "s'arrêtent en douceur" en terminant de traiter leur dernière requête.) + Ceci provoquera des problèmes si vous tentez de redémarrer le serveur + -- il ne pourra pas s'associer à ses ports d'écoute. Avant d'effectuer un + redémarrage, vous pouvez vérifier la syntaxe des fichiers de + configuration à l'aide de l'argument de ligne de commande -t + (voir httpd). + + Ceci ne garantit pas encore que le serveur va redémarrer + correctement. Pour vérifier la sémantique des fichiers de configuration + en plus de leur syntaxe, vous pouvez essayer de démarrer + httpd sous un utilisateur non root. + S'il n'y a pas d'erreurs, il tentera d'ouvrir ses sockets et ses fichiers + de log et échouera car il n'a pas les privilèges root (ou parce que + l'instance actuelle de + httpd est déjà associée à ces ports). S'il échoue + pour toute autre raison, il y a probablement une erreur dans le + fichier de configuration et celle-ci doit être corrigée avant de lancer + le redémarrage en douceur. +

+ +

Redémarrer immédiatement + +

Signal: HUP: apachectl -k restart

+ +

Les utilisateurs du module mod_status + noteront que les statistiques du serveur sont remises à zéro quand un + signal HUP est envoyé.

+ +Si votre fichier de configuration comporte des erreurs quand vous +effectuez un redémarrage, votre processus parent ne redémarrera pas, +il se terminera avec une erreur. Voir plus haut la méthode à employer +pour éviter ce problème. +

+ +

Arrêt en douceur + +

Signal : WINCH: apachectl -k graceful-stop

+ +

L'envoi du signal WINCH ou graceful-stop + au processus parent lui fait aviser les processus enfants + de s'arrêter après le traitement de leur requête en cours + (ou de s'arrêter immédiatement s'ils n'ont plus de requête à traiter). + Le processus parent va alors supprimer son fichier + PidFile et cesser l'écoute + de tous ses ports. Le processus parent va continuer à s'exécuter, + et va surveiller les processus enfants + qui ont encore des requêtes à traiter. Lorsque tous les processus enfants + ont terminé leurs traitements et se sont arrêtés ou lorsque le délai + spécifié par la directive GracefulShutdownTimeout a été atteint, + le processus parent s'arrêtera à son tour. Si ce délai est atteint, + tout processus enfant encore en cours d'exécution se verra envoyer + le signal TERM + afin de le forcer à s'arrêter.

+ +

L'envoi du signal TERM va arrêter immédiatement + les processus parent et enfants en état "graceful". Cependant, + comme le fichier PidFile + aura été supprimé, vous ne pourrez pas utiliser + apachectl ou httpd pour envoyer ce signal.

+ +

Le signal graceful-stop vous permet d'exécuter + simultanément plusieurs instances de httpd + avec des configurations identiques. Ceci s'avère une fonctionnalité + puissante quand vous effectuez des mises à jour "en douceur" d'Apache; + cependant, cela peut aussi causer des blocages fatals et des + situations de compétition (race conditions) + avec certaines configurations.

+ +

On a pris soin de s'assurer que les fichiers sur disque + comme ceux définis par les directives + Lockfile et + ScriptSock contiennent le PID + du serveur dans leurs noms donc ils coexistent sans problème. + Cependant, si une directive de + configuration , un module tiers ou une CGI résidente utilise un autre + verrou ou fichier d'état sur disque, il faut prendre soin de s'assurer + que chaque instance de httpd qui s'exécute + n'écrase pas les fichiers des autres instances.

+ +

Vous devez aussi prendre garde aux autres situations de compétition, + comme l'utilisation de l'enregistrement des logs avec un transfert de ceux-ci + dans le style rotation des logs. Plusieurs instances + du programme de rotation des logs qui tentent d'effectuer + une rotation des mêmes fichiers de log en même temps peuvent détruire + mutuellement leurs propres fichiers de log.

+ + -- 2.47.3