Conceptos básicos del servidor web

Un servidor web es un programa que sirve para atender y responder a las diferentes peticiones de
los
navegadores, proporcionándo los recursos que soliciten usando el protocolo HTTP o el protocolo
HTTPS (la versióncifrada y autenticada). Un servidor web básico cuenta con un esquema de
funcionamiento muy simple, basado en ejecutar infinitamente el siguiente bucle:
1. Espera peticiones en el puerto TCP indicado (el estándar por defecto para HTTP es el 80).
2. Recibe una petición.
3. Busca el recurso.
4. Envía el recurso utilizando la misma conexión por la que recibió petición.
5. Vuelve al segundo punto.
Un servidor web que siga el esquema anterior cumplirá todos los requisitos básicos de los
servidores
HTTP, aunque sólo podrá servir ficheros estáticos.
A partir del anterior esquema se han diseñado y desarrollado todos los servidores de HTTP que
existen,
variando sólo el tipo de peticiones (páginas estáticas, CGIs, Servlets, etc.) que pueden atender,
en
función de que sean o no sean multi-proceso o multi-hilados, etc. A continuación se detallan
algunas de
las características básicas de los servidores web, que amplían, obviamente el esquema anterior.
Servicio de ficheros estáticos
Todos los servidores web deben incluir, al menos, la capacidad para servir los ficheros estáticos
que se
hallen en alguna parte del disco. Un requisito básico es la capacidad de especificar qué parte del
disco
se servirá. No resulta recomendable que el programa servidor obligue a usar un directorio
concreto,
aunque sí puede tener uno por defecto.
La mayoría de servidores web permiten añadir otros directorios o subdirectorios para servir,
especificando en qué punto del "sistema de ficheros" virtual del servidor se localizarán los
recursos.
Algunos servidores web permiten también especificar directivas de seguridad (quién puede
acceder a
los recursos), mientras que otros hacen posible la especificación de los ficheros que se deben
considerar
como índice del directorio.
Seguridad y autenticación
La mayoría de los servidores web actuales permiten controlar desde el programa servidor los
aspectos
relacionados con la seguridad y la autenticación de los usuarios.
Podemos, por ejemplo, tener la siguiente situación:
Directorio del disco Directorio web
/home/apache/html /
/home/empresa/docs /docs
/home/jose/informe /informe-2003
En este caso, el servidor debería traducir las direcciones web de esta manera:
URL Fichero de disco
/index.html /home/apache/html/index.ht
ml
/docs/manuales/pro
ducto.pdf
/home/empresa/docs/manua
les/producto.pdf
/empresa/quienes.ht
ml
/home/apache/html/empres
a/quienes.html
/informe-
2003/index.html
/home/jose/informe/index.h
tml
El modo más sencillo de control es el facilitado por el uso de ficheros .htaccess. Se trata de un
sistema
de seguridad que deriva de uno de los primeros servidores web ("NCSA httpd"), que consiste en
incluir
un fichero de nombre .htaccess en cualquier directorio del contenido web que se deba a servir,
indicando en este fichero qué usuarios o máquinas, etc. tienen acceso a los ficheros y a los
diferentes
subdirectorios del directorio donde está instalado el .htaccess. Como el "NCSA httpd" fue el
servidor
más utilizado durante mucho tiempo, la mayoría de servidores actuales permiten utilizar un
fichero
.htaccess respetando la sintaxis original del servidor de NCSA.
Hay otros servidores que permiten especificar reglas de servicio de directorios, subdirectorios y
ficheros en la configuración del programa servidor web, indicando qué usuarios, máquinas, etc.
tienen
acceso al recurso indicado. En cuanto a la autenticación (validación del nombre de usuario y la
contraseña o clave indicados por el cliente), las prestaciones ofrecidas por los difernetes
servidores web
son variopintas. La mayoría permite, al menos, facilitar al servidor web un fichero con nombres de
usuario y contraseñas mediante el cual se pueden validar los datos enviado desde el cliente. De
todas
formas, es frecuente que los servidores faciliten pasarelas que permiten delegar las tareas de
autenticación y validación en otro software (como RADIUS, LDAP, etc.). Si se utiliza un sistema
operativo como Linux, el cual dispone de una infraestructura para autenticación como PAM
("pluggable authentication modules"), se puede usar tal funcionalidad como modo de
autenticación del
servidor web, permitiéndo de este modo utilizar los múltiples métodos disponibles en PAM para
autenticar contra diversos sistemas de seguridad.
Contenido dinámico
Uno de los aspectos fundamentales del servidor web elegido es el nivel de soporte que ofrece
para
servir contenido dinámico. Puesto que la mayor parte del contenido web que se sirve no viene de
páginas estáticas, sino que se genera de forma dinámica, y esta tendencia se mueve claramente
al alza,
el soporte para contenido de tipo dinámico que ofrece un servidor web es uno de los puntos
críticos en
la elección.
La mayor parte de los servidores web ofrecen soporte para CGI (se debe recordar que los CGI son
el
método más antiguo y sencillo para generar contenido dinámico). Otros muchos ofrecen soporte
para
algunos lenguajes de programación (normalemente lenguajes interpretados) como PHP, JSP, ASP,
etc.
Es muy recomendable que el servidor web que vayamos a utilizar proporcione soporte para
algunos de
estos lenguajes, especialmente PHP, sin tener en cuenta JSP, que normalmente requerirá un
software
externo para funcionar (como un contenedor de Servlets). La oferta es muy amplia, pero antes de
elegir
un lenguaje de programación de servidor se debe plantear si se desea un lenguaje muy estándar
para
que la aplicación no dependa de un servidor web o una arquitectura concreta o si, al contrario, la
portabilidad no es prioritaria y sí lo es alguna otra prestación concreta que pueda ofrecer algún
lenguaje
de programación concreto.
Servidores virtuales
Una prestación que gana aceptación y usuarios rápidamente, muy especialmente entre los
proveedores
de servicios de Internet y las empresas de alojamiento de dominios, es la capacidad de algunos
servidores web de facilitar múltiples dominios con una única dirección IP, discriminando entre los
diferentes dominios alojados en función del nombre de dominio enviado en la cabecera HTTP. Esta
prestación permite la administración racional y ahorradora de un bien escaso, las direcciones IP.
Si se
necesitan muchos nombres de servidor (porque proporcionamos alojamiento o por cualquier otro
motivo) debemos asegurarnos de que el servidor web elegido ofrezca esta facilidad y que el
soporte que
ofrece para servidores virtuales permita una configuración distinta para cada servidor. Sería
perfecto
que cada servidor se comportara como si fuese un ordenador diferente.
Prestaciones extra
Son muchas las prestaciones que ofrecen los diferentes servidores web para diferenciarse de la
competencia. Algunas son realmente útiles y pueden decidir la elección de servidor. Hay que ser
conscientes, sin embargo, de que si utilizamos algunas de estas características, o si éstas
devienen
imprescindibles, ello nos puede ligar a un determinado servidor web e imposibilitar una migración
posterior.
Algunas características adicionales de ciertos servidores web de código libre son:
• Spelling (Apache). Esta prestación permite definir una página de error que se sirve cuando el
servidor no ha encontrado el recurso solicitado. Proporciona una página web configurable
generada por el servidor que muestra, por ejemplo, su estado de funcionamiento o su nivel de
respuesta.
• RXML Tags (Roxen). Añade al lenguaje HTML algunos tags (etiquetas, comandos de HTML),
mejorados que permiten generar contenido dinámico.
• SQL Tags (Roxen). Añade al HTML extendido de Roxen (RXML, antes mencionado), ciertos
comandos para acceder a bases de datos SQL desde las páginas HTML.
• Graphics (Roxen). Añade al HTML extendido de Roxen (RXML, antes mencionado), ciertos
comandos para generar gráficos, títulos, etc.
• Bfnsgd (AOLServer), mod_gd (Apache). Permite realizar gráficos partiendo de texto y de
fuentes True Type.
• mod_mp3 (Apache), ICECAST, MPEG (Roxen). Permiten convertir el servidor web en un
servidor eficiente de música (con streaming, etc.).
• Throttle (Roxen), mod_throttle (Apache). Facilitan herramientas para limitar la velocidad del
servicio de HTTP, en función del usuario, del servidor virtual, etc.
• Nsxml (AOLServer), tDOM (AOLServer), mod_xslt (Apache). Permiten transformar ficheros
XML a partir de XSL.
• Kill Frame (Roxen). Envía con cada página web un código que evita que la web quede
enmarcada (como "frame") dentro de otra página web. En cierto modo, evita que nos "roben"
nuestra página web.
Actuación como representantes
Algunos servidores permiten su uso como servidores intermedios (proxy servers). Se pueden usar
los
servidores intermedios para diferentes propósitos:
• Servir de aceleradores de navegación (uso como proxy-caché).
• Servir como aceleradores de acceso frontal para un servidor web, instalando diferentes
servidores web que repliquen los distintos accesos a un servidor maestro (reverse-proxy o
HTTP server acceleration).
• Como frontales a algún servidor o algún protocolo.
Ciertos servidores web permiten su uso como servidores intermedios para alguno de los usos
mencionados. Sin embargo, para los 2 primeros usos existen programas específicos de código
libre que
son más eficientes, entre los que destaca, por ejemplo, Squid (http://www.squid-cache.org/), que
se
considera unánimemente como uno de los mejores productos de proxy.
Hay módulos para diversos servidores web que permiten su uso como frontales para otros
servidores
especializados en otros servicios.
Protocolos adicionales
Algunos servidores, no sólo atienden y sirven peticiones HTTP (y HTTPS), sino que pueden servir
también peticiones basadas en otros protocolos o en protocolos implementados sobre HTTP.
Algunos
de estos protocolos pueden ser requisitos fundamentales de nuestro sistema (en función de
nuestras
necesidades) y decantar nuestra elección de un programa servidor.
Apache
Apache es un programa de servidor web de código libre, robusto, cuya implementación se ha
realizado
y se sigue realizando de forma colaborativa, con prestaciones, características y funcionalidades
equivalentes a las de cualquier servidor comercial. El proyecto está bajo el control de un grupo de
voluntarios de todo el mundo que, sirviéndose de Internet para comunicarse, desarrollan el
programa y
la documentación relacionada. A estos voluntarios se les conoce como el Apache Group. Además
del
Apache Group, mucha más gente ha contribuido al proyecto desarrollando código o
documentación y
aportando ideas.
Historia de Apache
En febrero del año 1995, el servidor web más popular era un servidor desarrollado por el NCSA
(National Center for Supercomputing Applications de la Universidad de Illinois). Sin embargo, al
dejar
el principal desarrollador del servidor, Rob McCool, la NCSA en el año 1994, la evolución del
programa había quedado seriamente comprometida. La responsabilidad del desarrollo recayó en
los
responsables de sitios web, que introdujeron mejoras progresivas en sus servidores. Un grupo de
ellos,
utilizando el correo electrónico como herramienta principal de coordinación, se pusieron de
acuerdo
para poner en común estas mejoras en forma de "patches" o parches. 2 de ellos, Cliff Skolnick y
Brian
Behlendorf, iniciaron una lista de correo, un espacio para compartir información y un servidor en
California donde los desarrolladores más importantes pudiesen trabajar. A principios del año
siguiente,
8 programadores fundaron lo que había de ser el Grupo Apache.
Éstos, utilizando como base de trabajo el servidor NCSA 1.3, incorporaron las correcciones de
errores
publicadas y las mejoras más importantes que encontraron y probaron el resultado final en sus
servidores. Después publicaron lo que había de ser la 1a versión oficial del servidor Apache (la
0.6.2,
en abril del año 1995). Casualmente, por esas fechas, la NCSA reemprendió el desarrollo de su
servidor
NCSA.
En aquel momento el desarrollo de Apache continuó por 2 líneas paralelas. Por un lado, algunos
desarrolladores siguieron trabajando en el Apache 0.6.2 para llegar a la serie 0.7, incorporando
diversas
mejoras. Otro grupo reescribió por completo el código de la primera versión, creando una nueva
arquitectura de tipo modular. En julio del año 1995 migraron a esta nueva arquitectura las
mejoras
desarrolladas para Apache 0.7, haciéndose público como Apache 0.8.
El día 1 de diciembre del año 1995, apareció Apache 1.0, que incluía abundante documentación y
muchas mejoras en forma de módulos que se podían incrustar. Después, Apache sobrepasó al
servidor
NCSA como el más popular en Internet, posición que ha mantenido hasta hoy. En el año 1999 los
miembros del Grupo Apache fundaron la Apache Software Foundation, que da soporte de tipo
legal y
financiero al desarrollo del servidor Apache y los proyectos relacionados que ha ido surgiendo.
Instalación de Apache
Existen 2 opciones principales para instalar Apache: compilar el código fuente o instalarlo a partir
de
un paquete binario apropiado para cada sistema operativo.
Compilación a partir de las fuentes
Para compilar Apache a partir de su código fuente, se debe obtener previamente de la web de
Apache la
versión más reciente (http:// httpd.apache.org). Una vez descargada, seguiremos estos pasos:
Descomprimir el fichero descargado, lo cual creará un directorio donde se encuentran las fuentes
del
servidor. Dentro de este directorio:
• Configurar el código para su compilación. Para ello ejecutaremos:
$ ./configure
Existen algunos parámetros que permiten ajustar la compilación de Apache. Los más
importantes son:
• --prefix Directorio donde instalar Apache
• --enable-modules=LISTA-MODULOS Módulos que se desean activar
• --enable-mods-shared=LISTA-MODULOS Módulos shared que se desean que activar
• --enable-cache Caché dinámica
• --enable-disk-cache Caché dinámica en el disco
• --enable-mem-cache Módulo de caché de la memoria
• --enable-mime-magic Determinación del tipo MIME automática
• --enable-usertrack Seguimiento de la sesión de usuario
• --enable-proxy Módulo Apache-proxy
• --enable-proxy-connect Módulo Apache-proxy para CONNECT
• --enable-proxy-ftp Módulo Apache-proxy para FTP
• --enable-proxy-http Módulo Apache-proxy HTTP
• --enable-ssl Soporte de SSL/TLS (mod ssl)
• --enable-http Manejo del protocolo HTTP
• --enable-dav Manejo del protocolo WebDAV
• --disable-cgid Soporte para CGI optimizado
• --enable-cgi Soporte para CGI
• --disable-cgi Soporte para CGI
• --enable-cgid Soporte para CGI optimizado
• --enable-vhost-alias Soporte de hosts virtuales
• Una vez configurado el código fuente, si no hay errores se procederá a compilarlo.
Ejecutaremos:
$ make
Se debe recordar que para compilar Apache se requiere, como mínimo, GNU Make y GNU CC.
• Una vez compilado, se puede instalar en el directorio que designado como destino en la
configuración anterior, mediante "configure". Esto se realiza mediante uno de los objetivos que
tiene definidos make. Concretamente lo realizaremos así:
$ make install
• Una vez instalado, disponemos, dentro del subdirectorio "bin" dentro del directorio de
instalación, el que hemos especificado con prefix, un programa denominado "apachectl" que
permite controlar el servidor. Para iniciarlo:
$cd <directorio de instalacion>/bin
$ ./apachectl start
Para detenerlo:
$cd <directorio de instalacion>/bin
$ ./apachectl stop
Instalación partiendo de los paquetes binarios
Casi todos los sistemas operativos de código libre, especialmente la mayor parte de las
distribuciones
existentes de Linux, incluyen el servidor Apache. Sin embargo, en muchos casos es necesario
instalar
Apache, porque quizá no lo instalásemos en su momento. En tal caso se necesita un nueva
versión.
También es posible que se desee reinstalarlo a raíz de problemas con algún fichero.
A continuación se ofrecen algunas indicaciones para la instalación de Apache en algunas de las
distribuciones más populares de Linux.
Redhat/Fedora
Las distribuciones de Redhat y Fedora incluyen Apache. El proceso de instalación es realmente
sencillo.
Se debe descargar del servidor correspondiente (redhat.com o de fedora.us) el paquete binario de
Apache (que encontraremos en formato RPM). Debemos estar seguros de que estamos
descargando la
última versión para nuestra distribución, ya que se publican actualizaciones que subsanan errores
detectados. Una vez en posesión de dicho paquete, se puede proceder a su instalación:
rpm -ihv httpd-x.x.x.rpm
Si ya estaba instalado, se puede actualizar mediante:
rpm -Uhv httpd-x.x.x.rpm
En el caso de Fedora, que utiliza un repositorio apt, se puede tanto actualizar como instalar
Apache
con:
apt-get install httpd
También se deben instalar los módulos adicionales que se deseen, como por ejemplo:
• mod_auth_*
• mod_jk2
• mod_perl
• php
• etc.
En Debian
La instalación de Apache para Debian es muy sencilla. Sólo hay que ejecutar este comando:
apt-get install apache
que instalará la última versión de Apache o lo actualizará, si ya estaba instalado.
Otros servidores web
Existen muchos servidores web de código libre, pero casi todos ellos han quedado eclipsados por
Apache. Algunos de ellos ofrecen características y funcionalidades que les hacen interesantes.
AOLServer
El servidor HTTP AOLServer es el servidor web de código libre de América Online, el proveedor de
Internet con más clientes en el mundo. AOL utiliza AOLServer como servidor web para uno de los
entornos de mayor tráfico de Internet. AOLServer es un servidor HTTP de tipo multihebra, basado
en
TCL, que incluye muchas facilidades de uso orientadas a entornos de gran escala y a sitios web
con
contenido dinámico. Hay que destacar que todos los dominios y servidores de AOL, que son más
de
200 y soportan miles de usuarios simultáneos y millones de conexiones funcionan con AOLServer.
AOLServer tiene muchos usuarios, gracias en especial a su integración con OpenACS, un software
de
gestión de contenidos de código libre muy potente, desarrollado por una empresa llamada
ArsDigita y
liberado bajo licencia GPL. La combinación AOLServer-OpenACS es la infraestructura de proyectos
web muy complejos y potentes, como por ejemplo dotLRN (campus virtual universitario de código
libre).
Roxen y Caudium
Roxen es un servidor web de licencia GNU, desarrollado por un grupo sueco que después
fundarían la
empresa Roxen Internet Services. Roxen (que antes se llamó Spider y después, Spinner) destaca
por su
gran cantidad de funcionalidades. Este servidor, desarrollado en el lenguaje "Pike", ofrece cientos
de
módulos que permiten el desarrollo sencillo de sitios web muy ricos y dinámicos, sin más
herramienta
que el servidor Roxen. Sus características más destacables son:
• Multiplataforma: puede ejecutarse en Windows, Linux, MAC OS/X, Solaris, etc.
• Código libre.
• Interfaz de administración basada en web, completa y fácil de usar.
• Soporte para gráficos integrado que posibilita, mediante etiquetas de RXML (la extensión de
HTML propia de Roxen), la generación de imágenes, títulos, gráficos, etc.
• Acceso integrado a bases de datos, que permite el acceso a PostgreSQL, Oracle, MySQL, etc.
• MySQL integrada.
• Programación de servidor con PHP, RXML, Java, Perl y CGI.
• Soporte criptográfico fuerte.
• Arquitectura modular, que permite la carga y descarga de extensiones del servidor cuando está
en marcha.
• Independencia con respecto a la plataforma en los módulos desarrollados por el propio usuario.
A mediados del año 2000, a causa de la aparición de la versión 2.0 de Roxen, que interrumpía la
compatibilidad con las versiones anteriores, especialmente con la 1.3, la más usada, un grupo de
desarrolladores, entre los cuales estaban algunos de los fundadores de Roxen, inició un proyecto
que
partía de la versión 1.3 para desarrollar un servidor que mantuviera la compatibilidad con esta
versión.
Este servidor web se llamó Caudium. Actualmente las dos plataformas, Roxen y Caudium, gozan
de
muy buena salud, de buenas relaciones entre ellas (los desarrolladores se esfuerzan por
mantener la
compatibilidad entre las APIs de ambas) y cuentan con una base fiel de usuarios.
Roxen es uno de los pocos casos en los que un excelente producto no ha triunfado por completo,
ya que
siempre se ha visto eclipsado por Apache.
thttpd
thttpd es un servidor web extremadamente pequeño, rápido, portable y seguro. Ofrece las
mismas
prestaciones que otros servidores, como Apache, aunque en situaciones de carga extrema su
rendimiento es más alto.
Su utilidad como servidor de propósito general es escasa. Su uso primordial suele ser el de
servidor
rápido de contenido estático, a veces como soporte de servidores Apache para servir contenido
binario
de tipo estático, como imágenes, dejando para Apache las páginas dinámicas o las más
complejas.
Utilizado como complemento de Apache para servir contenido de tipo estático ha logrado reducir
la
carga del servidor principal a sólo una centésima parte.
Jetty
Jetty es un servidor web programado totalmente en Java que incluye un contenedor de Servlets.
Es de
tamaño reducido y ofrece un rendimiento alto, lo cual lo ha convertido en uno de los favoritos
para
desarrollar productos embebidos que necesiten un servidor web. Aunque no suelen encontrarse
muchos
servidores Jetty funcionando solos, suelen encontrarse como servidores empotrados en otros
productos,
como:
• integrados con servidores de aplicaciones, como, por ejemplo, JBoss y Jonas.
• integrados en el proyecto JTXA, haciendo la función de base para el transporte HTTP.
• integrados como servidor HTTP en productos como MQ de Sonic, Tivoli de IBM, y SESM de
Cisco.
• en CDs de demostración en manuales sobre Java, Servlets, XML, etc.
• ejecutándose en ordenadores de mano y en muchos sistemas embebidos.
Práctica: instalación del servidor web
Enunciado práctico
1. Descargar de Internet el código del servidor Apache e instalarlo en algún subdirectorio dentro
del directorio de nuestro usuario. Debemos instalar la última versión disponible, además de
asegurarnos de que se ha realizado una instalación correcta de los siguientes módulos:
• mod_access
2. mod_cgi
3. Configurar el servidor previamente instalado para que responda a las peticiones HTTP en el
puerto 1234.
4. Configurar el servidor web para que sirva los documentos que se hallan en el subdirectorio web
dentro del directorio de trabajo de nuestro usuario.
5. Configurar el servidor web para que pueda ejecutar programas CGI del subdirectorio cgi dentro
de directorio de trabajo de nuestro usuario.
Resolución
Una vez hallamos obtenido el código fuente de Apache, lo descomprimimos:
[david@bofh m2]$ tar xvzf httpd-2.0.48.tar.gz
httpd-2.0.48/
httpd-2.0.48/os/
httpd-2.0.48/os/os2/
httpd-2.0.48/os/os2/os.h
httpd-2.0.48/os/os2/core.mk
httpd-2.0.48/os/os2/config.m4
httpd-2.0.48/os/os2/Makefile.in
httpd-2.0.48/os/os2/core_header.def
....
httpd-2.0.48/include/ap_release.h
httpd-2.0.48/include/.indent.pro
httpd-2.0.48/include/util_cfgtree.h
httpd-2.0.48/acconfig.h
[david@bofh m2]$
Una vez tengamos el código fuente dentro de nuestro directorio, podemos configurarlo para
compilarlo.
Le indicaremos a Apache dónde queremos instalarlo. Nosotros hemos escogido el subdirectorio
"apache" dentro nuestro directorio de trabajo.
Nos aseguraremos también de que se incluyan los módulos deseados.
[david@bofh m2]$ cd httpd-2.0.48
[david@bofh httpd-2.0.48]$ ./configure \
--prefix=/home/carlesm/apache \.
--enable-cgi
checking for chosen layout... Apache
checking for working mkdir -p... yes
checking build system type... i686-pc-linux-gnu
checking host system type... i686-pc-linux-gnu
....
creating srclib/pcre/Makefile
creating test/Makefile
config.status: creating docs/conf/httpd-std.conf
config.status: creating docs/conf/ssl-std.conf
config.status: creating include/ap_config_layout.h
config.status: creating support/apxs
config.status: creating support/apachectl
config.status: creating support/dbmmanage
config.status: creating support/envvars-std
config.status: creating support/log_server_status
config.status: creating support/logresolve.pl
config.status: creating support/phf_abuse_log.cgi
config.status: creating support/split-logfile
config.status: creating build/rules.mk
config.status: creating include/ap_config_auto.h
config.status: executing default commands
[david@bofh httpd-2.0.48]$
Ha llegado el momento de compilar.
[david@bofh httpd-2.0.48]$ make
Making all in srclib
make[1]: Entering directory ‘/srcs/httpd-2.0.48/srclib’
Making all in apr
make[2]: Entering directory ‘/srcs/httpd-2.0.48/srclib/apr’
Making all in strings
....
make[1]: Leaving directory ‘/srcs/httpd-2.0.48’
Si la compilación se ha realizado con éxito, instalamos Apache en el directorio elegido:
[david@bofh httpd-2.0.48]$ make install
Making install in srclib
make[1]: Entering directory ‘/srcs/httpd-2.0.48/srclib’
Making install in apr
make[2]: Entering directory ‘/srcs/httpd-2.0.48/srclib/apr’
Making all in strings
....
mkdir /home/carlesm/apache/man
mkdir /home/carlesm/apache/man/man1
mkdir /home/carlesm/apache/man/man8
mkdir /home/carlesm/apache/manual
Installing build system files
make[1]: Leaving directory ‘/srcs/httpd-2.0.48’
[david@bofh httpd-2.0.48]$ cd /home/carlesm/apache/
[david@bofh apache]$ ls
bin build cgi-bin conf error htdocs
icons include lib logs man manual
modules
[david@bofh apache]$
Seguidamente configuramos Apache con los parámetros solicitados.
Editamos el fichero /home/carlesm/apache/conf/httpd.conf y modificamos los siguientes
parámetros:
Listen 1234
ServerAdmin [email protected]
DocumentRoot "/home/carlesm/web"
<Directory "/home/carlesm/web">
Options Indexes FollowSymLinks
AllowOverride None
Order allow,deny
Allow from all
</Directory>
ScriptAlias /cgi-bin/ "/home/carlesm/cgi/"
<Directory "/home/carlesm/cgi">
AllowOverride None
Options None
Order allow,deny
Allow from all
</Directory>