Adding .fr translations for suexec logs server-wide sections new_features_2_4... (ed6cd73b) · Commits · CYBER - Cyber Security / TS 103 523 MSP / TLMSP / TLMSP Apache Httpd

docs/manual/dso.xml.fr

0 → 100644

+328 −0

Changes for docs/manual/dso.xml.fr: 328 added lines, 0 removed lines.
Original line number	Diff line number	Diff line
		<?xml version="1.0" encoding="ISO-8859-1" ?>
		<!DOCTYPE manualpage SYSTEM "./style/manualpage.dtd">
		<?xml-stylesheet type="text/xsl" href="./style/manual.fr.xsl"?>
		<!-- French translation : Lucien GENTIS -->
		<!-- Reviewed by : Vincent Deffontaines -->
		<!-- English Revision : 587444 -->

		<!--
		Licensed to the Apache Software Foundation (ASF) under one or more
		contributor license agreements. See the NOTICE file distributed with
		this work for additional information regarding copyright ownership.
		The ASF licenses this file to You under the Apache License, Version 2.0
		(the "License"); you may not use this file except in compliance with
		the License. You may obtain a copy of the License at

		http://www.apache.org/licenses/LICENSE-2.0

		Unless required by applicable law or agreed to in writing, software
		distributed under the License is distributed on an "AS IS" BASIS,
		WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
		See the License for the specific language governing permissions and
		limitations under the License.
		-->

		<manualpage metafile="dso.xml.meta">

		<title>Support des objets dynamiques partagés (DSO)</title>

		<summary>
		<p>La conception modulaire du serveur HTTP Apache permet à l'administrateur
		de choisir les fonctionnalités à inclure dans le serveur en sélectionnant
		un certain nombre de modules. Les modules peuvent être soit intégrés
		statiquement dans le binaire <program>httpd</program> lors de la
		compilation du serveur, soit compilés en tant qu'objets
		dynamiques partagés (DSOs) qui existeront indépendamment du binaire
		principal <program>httpd</program>. Les modules DSO peuvent être compilés
		au moment de la construction du serveur, ou bien compilés séparément,
		à l'aide de l'utilitaire des extensions d'Apache (<program>apxs</program>),
		et associés au serveur ultérieurement.</p>

		<p>Ce document décrit l'utilisation des modules DSO ainsi que les dessous
		de leur fonctionnement.</p>
		</summary>


		<section id="implementation"><title>Implémentation</title>

		<related>
		<modulelist>
		<module>mod_so</module>
		</modulelist>
		<directivelist>
		<directive module="mod_so">LoadModule</directive>
		</directivelist>
		</related>

		<p>Le support DSO pour le chargement de modules individuels d'Apache est
		assuré par un module nommé <module>mod_so</module> qui doit être compilé
		statiquement dans le coeur d'Apache. Il s'agit du seul module avec le
		module <module>core</module> à ne pas pouvoir être compilé en tant que
		module DSO lui-même. Pratiquement tous les autres modules d'Apache
		distribués peuvent être compilés en tant que modules DSO en sélectionnant
		pour chacun d'entre eux le mode de construction DSO à l'aide de l'option
		<code>--enable-<em>module</em>=shared</code> du script
		<program>configure</program>, comme décrit dans la
		<a href="install.html">Documentation de l'installation</a>. Une fois
		compilé en tant que module DSO, un module peut être chargé en mémoire au
		démarrage ou redémarrage du serveur à l'aide de la commande
		<directive module="mod_so">LoadModule</directive> du module
		<module>mod_so</module>, placée
		dans votre fichier <code>httpd.conf</code>.</p>

		<p>Un nouvel utilitaire a été introduit afin de simplifier la création de
		fichiers DSO pour les modules d'Apache
		(particulièrement pour les modules tiers) ; il s'agit du programme nommé
		<program>apxs</program> (<dfn>APache
		eXtenSion</dfn>). On peut l'utiliser pour construire des modules de type
		DSO <em>en dehors</em> de l'arborescence des sources d'Apache. L'idée est
		simple : à l'installation d'Apache, la procédure <code>make install</code>
		du script <program>configure</program> installe les fichiers d'en-têtes
		d'Apache et positionne, pour la plateforme de compilation, les drapeaux du compilateur et de
		l'éditeur de liens à l'intérieur du programme
		<program>apxs</program>, qui sera utilisé pour la construction de fichiers DSO.
		Il est ainsi possible d'utiliser le programme <program>apxs</program>
		pour compiler ses sources de modules Apache sans avoir besoin de
		l'arborescence des sources de la distribution d'Apache, et sans avoir à
		régler les drapeaux du compilateur et de l'éditeur de liens pour le support DSO.</p>
		</section>

		<section id="usage"><title>Mode d'emploi succinct</title>

		<p>Afin que vous puissiez vous faire une idée des fonctionnalités DSO
		d'Apache 2.x, en voici un résumé court et concis :</p>

		<ol>
		<li>
		Construire et installer un module Apache <em>faisant partie de la
		distribution</em>, par exemple <code>mod_foo.c</code>,
		en tant que module DSO <code>mod_foo.so</code> :

		<example>
		$ ./configure --prefix=/chemin/vers/répertoire-installation
		--enable-foo=shared<br />
		$ make install
		</example>
		</li>

		<li>
		Construire et installer un module Apache <em>tiers</em>, par exemple
		<code>mod_foo.c</code>, en tant que module DSO <code>mod_foo.so</code> :

		<example>
		$ ./configure --add-module=<var>type_de_module</var>:
		/chemin/vers/module_tiers/mod_foo.c \<br />
		<indent>
		--enable-foo=shared<br />
		</indent>
		$ make install
		</example>
		</li>

		<li>
		Configurer Apache pour <em>pouvoir installer ultérieurement</em> des
		modules partagés :

		<example>
		$ ./configure --enable-so<br />
		$ make install
		</example>
		</li>

		<li>
		Construire et installer un module Apache <em>tiers</em>, par exemple
		<code>mod_foo.c</code>, en tant que module DSO
		<code>mod_foo.so</code> <em>en dehors</em> de l'arborescence des sources
		d'Apache à l'aide du programme <program>apxs</program> :

		<example>
		$ cd /chemin/vers/module_tiers<br />
		$ apxs -c mod_foo.c<br />
		$ apxs -i -a -n foo mod_foo.la
		</example>
		</li>
		</ol>

		<p>Dans tous les cas, une fois le module partagé compilé, vous devez
		ajouter une directive <directive module="mod_so">LoadModule</directive>
		dans le fichier <code>httpd.conf</code> pour qu'Apache active le module.</p>
		</section>

		<section id="background"><title>Les dessous du fonctionnement des DSO</title>

		<p>Les clônes modernes d'UNIX proposent un astucieux mécanisme
		communément appelé édition de liens et chargement dynamiques d'
		<em>Objets Dynamiques Partagés</em> (DSO), qui permet de construire un
		morceau de programme dans un format spécial pour le rendre chargeable
		à l'exécution dans l'espace d'adressage d'un programme exécutable.</p>

		<p>Ce chargement peut s'effectuer de deux manières : automatiquement par
		un programme système appelé <code>ld.so</code> quand un programme
		exécutable est démarré, ou manuellement à partir du programme en cours
		d'exécution via sa propre interface système vers le chargeur Unix à l'aide
		des appels système <code>dlopen()/dlsym()</code>.</p>

		<p>Dans la première méthode, les DSO sont en général appelés
		<em>bibliothèques partagées</em> ou encore <em>bibliothèques DSO</em>, et
		possèdent des noms du style
		<code>libfoo.so</code> ou <code>libfoo.so.1.2</code>. Ils résident dans un
		répertoire système (en général <code>/usr/lib</code>)
		et le lien avec le programme exécutable est établi à la compilation en
		ajoutant <code>-lfoo</code> à la commande de l'éditeur de liens. Les
		références à la bibliothèque sont ainsi codées en dur dans le fichier du
		programme exécutable de façon à ce qu'au démarrage du programme, le
		chargeur Unix soit capable de localiser <code>libfoo.so</code> dans
		<code>/usr/lib</code>, dans des chemins codés en dur à l'aide d'options de
		l'éditeur de liens comme <code>-R</code> ou dans des chemins définis par la
		variable d'environnement
		<code>LD_LIBRARY_PATH</code>. Le chargeur peut dès lors résoudre tous les symboles
		(jusque là non encore résolus) du DSO dans le programme exécutable.</p>

		<p>Les symboles du programme exécutable ne sont en général pas
		référencés par le DSO (car c'est une bibliothèque de code à usage général
		et réutilisable),
		et ainsi aucune résolution supplémentaire n'est nécessaire. De son côté,
		le programme exécutable ne doit accomplir aucune action particulière
		pour utiliser les
		symboles du DSO car toutes les résolutions sont effectuées par le chargeur
		Unix. En fait, le code permettant d'invoquer
		<code>ld.so</code> fait partie du code de démarrage pour l'exécution qui
		est lié dans tout programme exécutable non statiquement lié.
		L'avantage du chargement dynamique du code d'une bibliothèque partagée est
		évident : le code de la bibliothèque ne doit être stocké qu'une seule fois
		dans une bibliothèque système telle que <code>libc.so</code>, ce qui permet
		d'économiser de l'espace disque pour les autres programmes.</p>

		<p>Dans la seconde méthode, les DSO sont en général appelés <em>objets
		partagés</em> ou <em>fichiers DSO</em>, et peuvent être nommés avec
		l'extension de son choix (bien que le nom conseillé soit du style
		<code>foo.so</code>). Ces fichiers résident en général dans un répertoire
		spécifique à un programme, et aucun lien n'est automatiquement établi avec
		le programme exécutable dans lequel ils sont utilisés.
		Le programme exécutable charge manuellement le DSO à l'exécution dans son
		espace d'adressage à l'aide de l'appel système <code>dlopen()</code>.
		A ce moment, aucune résolution de symboles du DSO n'est effectuée pour le
		programme exécutable. Par contre le chargeur Unix
		résoud automatiquement tout symbole du DSO (non encore résolu)
		faisant partie de l'ensemble de symboles exporté par le programme
		exécutable et ses bibliothèques DSO déjà chargées (et en particulier tous
		les symboles de la bibliothèque à tout faire <code>libc.so</code>).
		De cette façon, le DSO prend connaissance de l'ensemble de symboles du
		programme exécutable comme s'il avait été lié statiquement avec lui
		auparavant.</p>

		<p>Finalement, pour tirer profit de l'API des DSO, le programme exécutable
		doit résoudre certains symboles du DSO à l'aide de l'appel système
		<code>dlsym()</code> pour une utilisation ultérieure dans les tables de
		distribution, <em>etc...</em> En d'autres termes, le programme exécutable doit
		résoudre manuellement tous les symboles dont il a besoin pour pouvoir les
		utiliser.
		Avantage d'un tel mécanisme : les modules optionnels du programme n'ont pas
		besoin d'être chargés (et ne gaspillent donc pas de ressources mémoire)
		tant qu'il ne sont pas nécessaires au programme en question. Si nécessaire,
		ces modules peuvent être chargés dynamiquement afin d'étendre les
		fonctionnalités de base du programme.</p>

		<p>Bien que ce mécanisme DSO paraisse évident, il comporte au moins une
		étape difficile : la résolution des symboles depuis le programme exécutable
		pour le DSO lorsqu'on utilise un DSO pour étendre les fonctionnalités d'un
		programme (la seconde méthode). Pourquoi ? Parce que la "résolution
		inverse" des symboles DSO à partir du jeu de symboles du programme
		exécutable dépend de la conception de la bibliothèque (la bibliothèque n'a
		aucune information sur le programme qui l'utilise) et n'est ni standardisée
		ni disponible sur toutes les plateformes. En pratique, les symboles globaux
		du programme exécutable ne sont en général pas réexportés et donc
		indisponibles pour l'utilisation dans un DSO. Trouver une méthode pour
		forcer l'éditeur de liens à exporter tous les symboles globaux est le
		principal problème que l'on doit résoudre lorsqu'on utilise un DSO pour
		étendre les fonctionnalités d'un programme au moment de son exécution.</p>

		<p>L'approche des bibliothèques partagées est la plus courante, parce que
		c'est dans cette optique que le mécanisme DSO a été conçu ; c'est cette
		approche qui est ainsi
		utilisée par pratiquement tous les types de bibliothèques que fournit le
		système d'exploitation. Par contre, les objets partagés sont relativement
		peu utilisés pour étendre les fonctionnalités d'un programme.</p>

		<p>En 1998, seule une poignée de logiciels distribués
		utilisaient le mécanisme DSO pour réellement étendre leurs fonctionnalités
		au moment de l'exécution : Perl 5 (via son mécanisme XS et le module
		DynaLoader), le serveur Netscape, <em>etc...</em> A partir de la
		version 1.3, Apache rejoignit ce groupe, car Apache
		présentait déjà un concept modulaire pour étendre ses fonctionnalités, et
		utilisait en interne une approche basée sur une liste de distribution pour
		relier des modules externes avec les fonctionnalités de base d'Apache.
		Ainsi, Apache était vraiment prédestiné à l'utilisation des DSO pour
		charger ses modules au moment de l'exécution.</p>
		</section>

		<section id="advantages"><title>Avantages et inconvénients</title>

		<p>Les fonctionnalités ci-dessus basées sur les DSO présentent les
		avantages suivants :</p>

		<ul>
		<li>Le paquetage du serveur est plus flexible à l'exécution car le
		processus serveur effectif peut être assemblé à l'exécution via la
		directive <directive module="mod_so">LoadModule</directive> du fichier de
		configuration <code>httpd.conf</code> plutôt que par des options du script
		<program>configure</program> à la compilation. Par exemple,
		on peut ainsi exécuter différentes instances du serveur
		(standard et version SSL, version minimale et version étoffée
		[mod_perl, PHP], <em>etc...</em>) à partir d'une seule installation
		d'Apache.</li>

		<li>Le paquetage du serveur peut être facilement étendu avec des modules
		tiers, même après l'installation. Ceci présente en tout cas un gros
		avantage pour les mainteneurs de paquetages destinés aux distributions,
		car ils peuvent créer un paquetage Apache de base, et des paquetages
		additionnels contenant des extensions telles que PHP, mod_perl, mod_fastcgi,
		<em>etc...</em></li>

		<li>Une facilité de prototypage des modules Apache car la paire
		DSO/<program>apxs</program> vous permet d'une part de travailler en
		dehors de l'arborescence des sources d'Apache, et d'autre part de n'avoir
		besoin que de la commande <code>apxs -i</code>
		suivie d'un <code>apachectl restart</code> pour introduire une nouvelle
		version de votre module fraîchement développé dans le serveur Apache
		en cours d'exécution.</li>
		</ul>

		<p>Inconvénients des DSO :</p>

		<ul>
		<li>Le mécanisme DSO n'est pas disponible sur toutes les plates-formes
		car tous les systèmes d'exploitation ne supportent pas le chargement
		dynamique de code dans l'espace d'adressage d'un programme.</li>

		<li>Le serveur est environ 20 % plus lent au démarrage
		à cause des résolutions de symboles supplémentaires que le chargeur
		Unix doit effectuer.</li>

		<li>Le serveur est environ 5 % plus lent à l'exécution
		sur certaines plates-formes, car le code indépendant de la position (PIC)
		nécessite parfois des manipulations compliquées en assembleur pour
		l'adressage relatif qui ne sont pas toujours aussi rapides que celles
		que permet l'adressage absolu.</li>

		<li>Comme les modules DSO ne peuvent pas être liés avec d'autres
		bibliothèques basées sur DSO (<code>ld -lfoo</code>) sur toutes les
		plates-formes
		(par exemple, les plates-formes basées sur a.out ne fournissent en
		général pas cette fonctionnalité alors que les plates-formes basées sur
		ELF le font), vous ne pouvez pas utiliser le mécanisme DSO pour tous les
		types de modules. Ou en d'autres termes, les modules compilés comme
		fichiers DSO sont contraints de n'utiliser que les symboles du coeur
		d'Apache, de la bibliothèque C
		(<code>libc</code>) et toutes autres bibliothèques statiques ou
		dynamiques utilisées par le coeur d'Apache, ou d'archives statiques
		(<code>libfoo.a</code>) contenant du code indépendant de la
		position (PIC).
		Il y a deux solutions pour utiliser un autre type de code : soit le
		coeur d'Apache contient déjà lui-même une référence au code, soit vous
		chargez le code vous-même via <code>dlopen()</code>.</li>
		</ul>

		</section>

		</manualpage>

docs/manual/glossary.xml.fr

0 → 100644

+567 −0

File added.

Preview size limit exceeded, changes collapsed.

docs/manual/logs.xml.fr

0 → 100644

+669 −0

File added.

Preview size limit exceeded, changes collapsed.

docs/manual/new_features_2_4.xml.fr

0 → 100644

+77 −0

Changes for docs/manual/new_features_2_4.xml.fr: 77 added lines, 0 removed lines.
Original line number	Diff line number	Diff line
		<?xml version="1.0" encoding="ISO-8859-1" ?>
		<!DOCTYPE manualpage SYSTEM "./style/manualpage.dtd">
		<?xml-stylesheet type="text/xsl" href="./style/manual.fr.xsl"?>
		<!-- French translation : Lucien GENTIS -->
		<!-- Reviewed by : Vincent Deffontaines -->
		<!-- English Revision : 642717 -->

		<!--
		Licensed to the Apache Software Foundation (ASF) under one or more
		contributor license agreements. See the NOTICE file distributed with
		this work for additional information regarding copyright ownership.
		The ASF licenses this file to You under the Apache License, Version 2.0
		(the "License"); you may not use this file except in compliance with
		the License. You may obtain a copy of the License at

		http://www.apache.org/licenses/LICENSE-2.0

		Unless required by applicable law or agreed to in writing, software
		distributed under the License is distributed on an "AS IS" BASIS,
		WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
		See the License for the specific language governing permissions and
		limitations under the License.
		-->

		<manualpage metafile="new_features_2_4.xml.meta">

		<title>Vue d'ensemble des nouvelles fonctionnalités d'Apache 2.4</title>

		<summary>
		<p>Ce document décrit certaines modifications majeures entre les versions
		2.2 et 2.4 du serveur HTTP Apache. Pour les nouvelles fonctionnalités
		ajoutées depuis la version 2.0, se référer au document
		<a href="new_features_2_2.html">nouvelles fonctionnalités
		de la version 2.2</a>.</p>
		</summary>

		<section id="core">
		<title>Améliorations du noyau</title>
		<!-- <dl>
		</dl> -->
		</section>

		<section id="module">
		<title>Améliorations des modules</title>
		<!-- <dl>
		</dl> -->
		</section>

		<section id="programs">
		<title>Améliorations des programmes</title>
		<!-- <dl>
		</dl> -->
		</section>

		<section id="developer">
		<title>Modifications pour le développeur de modules</title>
		<dl>
		<dt>Ajout de code pour la vérification de la configuration</dt>

		<dd>Une nouvelle fonction, <code>check_config</code>, a été ajoutée et
		s'exécute entre les fonctions <code>pre_config</code> et
		<code>open_logs</code>. Elle s'exécute aussi avant la fonction
		<code>test_config</code> si l'option <code>-t</code> est passée au
		démon <program>httpd</program>. La fonction <code>check_config</code>
		permet aux modules de vérifier l'interdépendance des valeurs des
		directives de configuration et d'ajuster ces valeurs, alors que les
		messages du serveur peuvent encore être affichés sur la console.
		L'utilisateur est ainsi averti des erreurs de configuration avant que la
		fonction du noyau <code>open_logs</code> ne redirige les sorties de la
		console vers le journal des erreurs.</dd>
		<dt>Ajout d'un analyseur syntaxique d'expressions</dt>
		<dd>Nous disposons à présent d'un analyseur générique d'expressions, dont l'API
		est décrite dans <var>ap_expr.h</var>. Il s'agit d'une adaptation de
		l'analyseur qu'on trouvait auparavant dans <module>mod_include</module>.</dd>
		</dl>
		</section>
		</manualpage>

docs/manual/sections.xml.fr

0 → 100644

+564 −0

File added.

Preview size limit exceeded, changes collapsed.