Versi�n 2.0 del Servidor HTTP Apache
El servidor HTTP Apache es un programa modular en el que el
administrador puede elegir qu� funcionalidades se incluyen
mediante la selecci�n de un conjunto de m�dulos. En
primer lugar, los m�dulos pueden compilarse de manera
est�tica en el binario httpd
. De forma
alternativa, los m�dulos tambi�n pueden compilarse como
Objetos Dinamicos Compartidos (DSOs) que existen de forma
independiente del archivo binario httpd
. Los
m�dulos que se deseen usar como objetos din�micos
compartidos pueden compilarse al mismo tiempo que el servidor, o
pueden compilarse en otro momento y ser a�adidos despu�s
usando la Herramienta de Extensi�n de Apache
(apxs
).
Este documento describe c�mo usar los m�dulos en forma de objeto din�mico compartido (DSO) as� como los fundamentos te�ricos que hay detr�s para explicar su funcionamiento.
M�dulos Relacionados | Directivas Relacionadas |
---|---|
Cargar m�dulos de Apache individualmente como objetos
din�micos compartidos (DSO) es posible gracias a un
m�dulo llamado mod_so
que debe compilarse
est�ticamente en el n�cleo (kernel) de Apache. Es el
�nico m�dulo junto con el m�dulo
core
que no se puede usar como objeto
din�mico compartido. Pr�cticamente todos los dem�s
m�dulos distribuidos con Apache se pueden usar como objetos
din�micos compartidos individualmente siempre y cuando se
haya activado la posibilidad de usarlos con la opci�n de
configure
--enable-module=shared
tal y como se
explic� en la documentaci�n de
instalaci�n. Una vez que haya compilado un m�dulo
como objeto din�mico compartido y le haya puesto un nombre
del tipo mod_foo.so
, puede cargarlo al iniciar o
reiniciar el servidor usando el comando LoadModule
de mod_so
en el fichero httpd.conf
.
Para simplificar la creaci�n de objetos din�micos
compartidos para Apache (especialmente m�dulos de terceras
partes) est� disponible un nuevo programa de soporte llamado
apxs
(APache eXtenSion). Puede usar
este programa para crear m�dulos como objetos din�micos
compartidos sin tener que crearlos al mismo tiempo que
compila su servidor Apache. La idea es simple: cuando se instala
Apache el procedimiento make install
de
configure
@@@ installs the Apache C header
files and puts the platform-dependent compiler and linker flags
for building DSO files into the apxs program / instala los
ficheros de cabecera de C de Apache y especifica las opciones de
compilaci�n y enlace dependientes de la plataforma para
generar objetos din�micos compartidos con
apxs
. De esta manera el usuario puede usar
apxs
para compilar el c�digo fuente de
m�dulos de Apache de manera independiente y sin tener que
preocuparse por las opciones de compilaci�n y enlace
dependientes de la plataforma que soportan objetos din�micos
compartidos.
Para que se haga una idea de lo que permite el soporte de objetos din�micos compartidos en Apache 2.0, aqu� tiene un resumen breve pero conciso:
mod_foo.c
, como un objeto din�mico
compartido de nombre mod_foo.so
:
$ ./configure --prefix=/path/to/install --enable-foo=shared
$ make install
mod_foo.c
, como
un objeto din�mico compartido de nombre
mod_foo.so
:
$ ./configure --add-module=module_type:/path/to/3rdparty/mod_foo.c --enable-foo=shared
$ make install
$ ./configure --enable-so
$ make install
mod_foo.c
, como
un objeto din�mico compartido de nombre
mod_foo.so
fuera de la estructura de
directorios de Apache usando apxs
:
$ cd /path/to/3rdparty
$ apxs -c mod_foo.c
$ apxs -i -a -n foo mod_foo.la
En todos los casos, una vez que se compila el objeto
din�mico compartido, debe usar una directiva LoadModule
en
httpd.conf
para activar dicho m�dulo.
En las versiones modernas de Unix, existe un mecanismo especialmente �til normalmente llamado enlazado/carga de Objetos Din�micos Compartidos (DSO). Este mecanismo ofrece una forma de construir trozos de c�digo de programa en un formato especial para cargarlo en tiempo de ejecuci�n en el espacio de direcciones de memoria de un programa ejecutable.
Esta carga puede hacerse de dos maneras: autom�ticamente
con un programa de sistema llamado ld.so
al inicio de
un programa ejecutable o manualmente desde dentro del programa en
ejecuci�n con una interfaz program�tica del sistema al
cargador de Unix mediante llamadas al sistema
dlopen()/dlsym()
.
Si se usa el primer m�todo, los objetos din�micos
compartidos se llaman normalmente librer�as
compartidas � librer�as DSO y se
nombran como libfoo.so
o
libfoo.so.1.2
. Residen en un directorio de
sistema (normalmente /usr/lib
) y el enlace con el
programa ejecutable se establece al construir la librer�a
especificando la opci�n-lfoo
al comando de
enlace. Esto incluye las referencias literales a las
librer�as en el programa ejecutable de manera que cuando
se inicie, el cargador de Unix ser� capaz de localizar
libfoo.so
en /usr/lib
, en rutas
referenciadas literalmente mediante opciones del linker como
-R
o en rutas configuradas mediante la variable
de entorno LD_LIBRARY_PATH
. Entonces se resuelven
los s�mbolos (todav�a no resueltos) en el programa
ejecutable que est�n presentes en el objeto din�mico
compartido.
Los s�mbolos en el programa ejecutable no est�n
referenciados normalmente en el objeto din�mico compartido
(porque son librer�as reusables de prop�sito general) y
por tanto, no se producen m�s resoluciones. El programa
ejecutable no tiene que hacer nada por s� mismo para usar los
s�mbolos del objeto din�mico compartido porque todo el
trabajo de resoluci�n lo hace @@@ Unix loader / el cargador
de Unix @@@. (De hecho, el c�digo para invocar
ld.so
es parte del c�digo que se ejecuta al
iniciar, y que hay en cualquier programa ejecutable que haya sido
construido de forma no est�tica). La ventaja de cargar
din�micamente el c�digo de las librer�as comunes es
obvia: el c�digo de las librer�as necesita ser almacenado
solamente una vez, en una librer�a de sistema como
libc.so
, ahorrando as� espacio en disco.
Por otro lado, los objetos din�micos compartidos
tambi�n suelen llamarse objetos compatidos o
ficheros DSO y se les puede nombrar con cualquier
extensi�n (aunque su nombre can�nico es
foo.so
). Estos archivos normalmente permanecen
dentro de un directorio espec�fico del programa y no se
establecen enlaces autom�ticamente con los programas
ejecutables con los que se usan. En lugar de esto, el
programa ejecutable carga manualmente el objeto din�mico
compartido en tiempo de ejecuci�n en su espacio de
direcciones de memoria con dlopen()
. En ese
momento no se resuelven los s�mbolos del objeto
din�mico compartido para el programa ejecutable. En lugar
de esto, el cargador de Unix resuelve autom�ticamente los
s�mbolos (a�n no resueltos en el objeto
din�mico compartido del conjunto de s�mbolos
exportados por el programa ejecutable y de las librer�as
DSO que tenga ya cargadas (especialmente todos los
s�mbolos de la omnipresente libc.so
). De
esta manera el objeto din�mico compartido puede conocer
el conjunto de s�mbolos del programa ejecutable como si
hubiera sido enlazado est�ticamente en un primer
momento.
Finalmente, para beneficiarse de la API de las DSOs, el
programa ejecutable tiene que resolver los s�mbolos
particulares de la DSO con dlsym()
para ser usado
m�s tarde dentro de tablas de direccionamiento (dispatch
tables) etc. En otras palabras: El programa ejecutable
tiene que resolver manualmente cada uno de los s�mbolos que
necesita para poder usarlo despu�s. La ventaja de ese
mecanismo es que las partes opcionales del programa no necesitan
ser cargadas (y por tanto no consumen memoria) hasta que se
necesitan por el programa en cuesti�n. Cuando es necesario,
estas partes del programa pueden cargarse din�micamente para
expandir las funcionalidades b�sicas del programa.
Aunque este mecanismo DSO parece muy claro, hay al menos un paso de cierta dificultad: la resoluci�n de los s�mbolos que usa el programa ejecutable por la DSO cuando se usa una DSO para extender la funcionalidad de una programa (segundo caso). Por qu�? Porque la resoluci�n inversa de s�mbolos de DSOs del conjunto de s�mbolos del programa ejecutable se hace en contra del dise�o de la librer�a (donde la librer�a no tiene conocimiento sobre los programas que la usan) y tampoco est� disponible en todas las plataformas no estandarizadas. En la pr�ctica los s�mbolos globales del programa ejecutable est�n disponibles para su uso en una DSO. El mayor problema que hay que resolver cuando se usan DSOs para extender un programa en tiempo de ejecuci�n es encontrar un modo de forzar al enlazador a exportar todos los s�mbolos globales.
El enfoque de las librer�as compartidas es bastante t�pico, porque es para lo que se dise�o el mecanismo DSO, por tanto se usa para casi todos los tipos de librer�as que incluye el sistema operativo. Por otro lado, no muchos programas usan objetos compartidos para expandir sus funcionalidades.
En 1998, hab�a solamente unos pocos programas disponibles que usaban el mecanismo DSO para extender su funcionalidad en tiempo de ejecucion: Perl 5 (por medio de su mecanismo XS y el m�dulo DynaLoader), Netscape Server, etc. A partir de la version 1.3, Apache se uni� a este grupo, Apache usa desde entonces una concepci�n modular para extender su funcionalidad e internamente usa un enfoque de tablas de direccionamiento (dispatch-list-based) para enlazar m�dulos externos con las funcionalidades propias del servidor. De esta manera, Apache puede usar el mecanismo DSO para cargar sus m�dulos en tiempo de ejecuci�n.
Las caracter�sticas de las librer�as din�micas compartidas arriba explicadas tienen las siguientes ventajas:
LoadModule
en
httpd.conf
en lugar de tener que hacerlo con las
opciones de configure
al compilar. Por
ejemplo, de esta manera uno puede ejecutar diferentes instancias
del servidor (est�ndar & SSL, m�nima & super
potente [mod_perl, PHP3], etc.) con una �nica
instalaci�n de Apache.apxs
se
puede trabajar fuera de la estructura de directorios de Apache y
�nicamente es necesario el comando apxs -i
seguido del comando apachectl restart
para probar
la nueva versi�n del m�dulo que se est�
desarrollando.DSO presenta los siguientes inconvenientes:
ld -lfoo
) en todas
las plataformas (por ejemplo en las plataformas basadas en a.out
normalmente no puede ser usada esta funcionalidad, mientras que
s� puede ser usada en las plataformas basadas en ELF) no se
puede usar el mecanismo DSO para todos los tipos de
m�dulos. En otras palabras, los m�dulos compilados
como ficheros DSO solamente pueden usar s�mbolos del
n�cleo (kernel) de Apache, los de las librer�as de C
(libc
) y de todas las demas librer�as
din�micas o est�ticas usadas por el n�cleo de
Apache, o de archivos de librer�as est�ticas
(libfoo.a
) que contengan c�digo independiente
de su posici�n. Las �nicas posibilidades para usar
otro c�digo es asegurarse de que el n�cleo de Apache
contiene una referencia a �l o cargar el c�digo por
medio de dlopen()
.