Matthias Arndt
Soy un entusiasta de Linux del Norte de Alemania.
Me gusta el rock 'n roll de los 50, escribir historias y publicar en Linux Gazette, por supuesto.
Estoy estudiando "computer science in conjunction with
economics".
Un servidor web personal. Hoy día, casi todos los usuarios de Linux tienen uno. Algunos lo utilizan realmente para servir contenido; otros lo usan para desarrollo de aplicaciones PHP o CGI. Otros como yo lo tenemos para leer la documentación via el navegador y para jugar con él. Llegué a la conclusión de que ejecutar Apache era un tanto exagerado para mis propósitos personales. Mi proveedor de servicios actualmente me proporciona PHP y CGI así que no necesito preocuparme por ello. Únicamente servir ficheros sin necesidad de ejecutar un pesado Apache en mi máquina.
Por ello, decidí dejar de ejecutar mi propio servidor Apache para optar por un micro servidor web cuyo único trabajo es responder peticiones cuando las hay. Esto me ahorra algo de espacio de disco y RAM, aunque esto ya no es un factor importante dado que mi máquina actual está repleta de recursos. Más que nada quería jugar con software nuevo y alguna solución pequeña pero eficaz.
Sólo un par de cosas normales, nada que tenga PHP o CGI de por medio:
Esto lleva a otro tema importante: el servidor web ha de soportar al menos algún tipo de indexación de directorios. Esto es, si la última parte de la URL es un directorio, que redirija a ese directorio (añadiendo la barra al final), y después muestre el index.html en ese directorio. (La redirección es importante para que los enlaces relativos en la página funcionen correctamente.) Aunque esto se pueda hacer con un script corriendo en el cron, prefiero una solución embebida. No tiene que ser tan complejo como las funciones de indexación de Apache, aunque son realmente buenas.
En resumen: puedo usar casi cualquier servidor web que soporte http pero sin necesidad de grandes características.
En realidad no. Todo esto se puede realizar estableciendo enlances simbólicos de los documentos en el directorio raíz del servidor web. Sin directivas "Alias" u otras complicadas opciones. Sólo la raíz del servidor y tendré suficiente. Posiblemente cambiar el puerto en el que el servidor escuche.
Pero nada más. Un simple comando en la consola sería suficiente para mi propósito: "binary /path/to/webserver/root".
Opté por la solución tcpd. Sólo se ejecuta el servidor cuando hay una petición. Nada de complicarme con scripts para arrancarlo. Una línea en /etc/inetd.conf y allá vamos.
Sin embargo, esta solución no es del todo eficaz desde el punto de vista del rendimiento. De hecho, si planea tener más que alguna visita esporádica a su servidor, entonces opte por un servidor autosuficiente.
Entre unas cuantas posibles soluciones a elegir (hay servidores web escritos en Java, bash o awk), decidí usar uno compilable por mí mismo.
Encontré un servidor llamado micro_httpd en http://www.acme.com/software/micro_httpd/. Está escrito en C, ocupa alrededor de 150 líneas de código y hace exactamente lo que quiero. Ejecutable desde TCP Wrappers, ni CGI ni PHP, servicio de ficheros con capacidad de indexación.
Añadí algunos tipos MIME en el código y funcionó a la perfección.
Descargue los fuentes de micro_http y descomprímalos.
"Su" a root y edite /etc/inetd.conf con su editor favorito. Añada la línea
http stream tcp nowait wwwrun /usr/sbin/tcpd /usr/local/sbin/micro_httpd /var/httpd/wwwroot/Y vuelva a ejecutar el super-servidor de Internet, inetd.
En mi SuSE 7.2, escribí "/etc/init.d/inetd restart" como root.
Hay que sustituir "/var/httpd/wwwroot/" en el ejemplo por la ruta correcta hacia la raíz de los documentos.
Sustituya el wwwrun con cualquier cuenta de usuario válida, preferiblemente una que no tenga ningún privilegio especial en el sistema por razones de seguridad.
Ahora probémoslo: ponga unos ficheros html en el directorio raíz y hágalos legibles por la cuenta de usuario anteriormente especificada. Ahora apunte su navegador favorito a http://localhost/. Deebería de obtener un índice de los contenidos o su fichero index.html.
Llegó hasta aquí? Bien, su pequeño servidor web está arriba y corriendo.
Nota:TCP wrappers loguea todas las conexiones al servidor en /var/log/messages. Pero no espere un completo log al estilo Apache de él. Sólo líneas como éstas:
micro_httpd[886]: connect from x.x.x.x (x.x.x.x)Sin embargo, con conocimiento del protocolo http y el código es posible desarrollar un programa que loguee más avanzadamente. Dejo esto a su gusto.
En general, cualquier servidor web que se ejecute desde inetd se puede configurar como micro_httpd. Así que eche un vistazo a Freshmeat.
Si sus necesidades son tan simples como éstas, sólo lleva unos minutos cambiar desde Apache a una solución tan minimalista como ésta.
Trabaja realmente bien, aunque tengo claro que esto se vendrá abajo si empiezan a haber muchas peticiones. Para un simple servidor web personal sin apenas tráfico será mas que suficiente.
Al menos estoy algo feliz. Decídase - posiblemente una solución como ésta cumpla sus necesidades también?
[There's also Tux, a micro web server in a Linux kernel module. It works similar to micro_http, and can chain to a bulkier web server for URLs it can't handle (e.g., CGI scripts). But note that Tux and micro_http serve different niches. Tux is for high-traffic sites that serve lots of simple files (e.g., images) and must keep per-request overhead low to avoid overloading the system. micro_http via inetd is for sites with light web traffic, where the greater overhead of running a separate process for each request is overshadowed by the no overhead at all when there are no requests. Of course, both micro_http and Tux serve a third niche: nifty small usable solutions you can play with. Or as LG contributing editor Dan Wilder would say, "small sharp tools that each do one thing well in the honorable UNIX toolbox tradition."For more information about Tux, see Red Hat's Tux 2.1 manual. I thought Tux was in the standard kernel but I can't find it in 2.4.17, so you'll have to look around for it. -Iron.]
Matthias Arndt